[Openid-specs-ab] Comments on Registration (-14) Release Candidate D

Brian Campbell bcampbell at pingidentity.com
Wed Feb 6 19:29:19 UTC 2013


My point was more generally that the client_secret gets used for more than
just token endpoint authentication.

Or at least that was what I thought. Thought earlier today I noticed that
http://openid.net/specs/openid-connect-messages-1_0-15.html#sigs says "The
client and server MUST establish a shared secret out of band" for Symmetric
Signatures (HMAC). Shouldn't Symmetric Signatures use the client secret? I
thought I'd read text that said as much but maybe I was just assuming.
Maybe there's a ticket to be filed on that?

Symmetric Encryption at
http://openid.net/specs/openid-connect-messages-1_0-15.html#enc does use
the client_secret, so the main point stands.

I'm not sure about suggested text change, to be honest. What's there isn't
quite right. But basically saying the client_secret is not required only if
the client and server aren't doing anything that needs the shared secret.
We could try and enumerate those. Off the top of my head, the secret is
needed for client_secret_jwt, client_secret_post, and client_secret_basic
authn methods, as well as any HMAC signing in either direction, and any
straight symmetric encryption in either direction. I think that's all but
there may be others.





On Wed, Feb 6, 2013 at 11:54 AM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  Hi Brian,****
>
> ** **
>
> There’s one part of your comments that I didn’t know how to address.  Per
> the comment in the issue:****
>
> **1.     **You wrote:****
>
> 2.2.1. Client Register Operation Response****
>
> says that "[client_secret] is not required for clients selecting a
> token_endpoint_auth_method of private_key_jwt" but what if they've selected
> HS256 (or other HSxxx) for request_object_signing_alg or any of the *
> signed* or *singing* parameters?****
>
> Do you have a suggested text change in response to this issue?****
>
> ** **
>
>                                                             Thanks,****
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Mike Jones
> *Sent:* Monday, January 28, 2013 12:21 PM
> *To:* Brian Campbell; <openid-specs-ab at lists.openid.net>
> *Subject:* RE: [Openid-specs-ab] Comments on Registration (-14) Release
> Candidate D****
>
> ** **
>
> I’ve created
> http://hg.openid.net/connect/issue/727/registration-brian-campbells-reviewto track these review comments.
> ****
>
> ** **
>
>                                                                 -- Mike***
> *
>
> ** **
>
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:
> openid-specs-ab-bounces at lists.openid.net] *On Behalf Of *Brian Campbell
> *Sent:* Thursday, January 24, 2013 3:48 PM
> *To:* <openid-specs-ab at lists.openid.net>
> *Subject:* [Openid-specs-ab] Comments on Registration (-14) Release
> Candidate D****
>
> ** **
>
> Some comments/questions on
> http://openid.net/specs/openid-connect-registration-1_0-14.html follow:
>
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration
> 2.1.  Client Registration and Client Update Request
>
> The definition of access_token and the text near the bottom about
> registration_access_token seem to suggest that the (registration) access
> token need only be sent on client_update requests. But surly it's also
> needed for rotate_secret?
>
> Changing from requiring client id and secret on client_update (and I
> assume rotate_secret) to needed the registration access token suggests that
> (short of some additional work) clients provisioned by some other means
> than this registration endpoint cannot update themselves or rotate their
> secret via the registration endpoint. I guess that could be a feature or a
> bug (or just meh) depending on how you look at it. But it just occurred to
> me and the change is relatively recent so I thought I'd mention it.
>
> Honestly, it feels pretty awkward that the nature of the access token and
> if it's required or not differs based on the value of the operation
> parameter. It can work but means that the code that's doing the authn/z
> will need to examine the operation parameter in the request body in order
> to know what to do and the content of the token and how it's processed
> might be very different based on the operation.  Anyway, I'm not
> necessarily objecting to it but still feel compelled to mention that it
> leaves kind of a bad taste.
>
> jwk_url and x509_url say they are used for "signing Token Endpoint
> Requests" but there's nothing specified anywhere about signing Token
> Endpoint Requests, is there? Is it intended to mean signing the jwt when
> authenticating to the token endpoint using the private_key_jwt method?
>
> All the jwk and x509 basically say that if both jwk and x509 are
> registered then. "the keys contained in both formats SHOULD be the same"
> but Messages 4.2
> http://openid.net/specs/openid-connect-messages-1_0-15.html#sigenc.keyhas a MUST. Shouldn't these be consistent?
>
> Issues 703 and 704 likely will impact the key parameters too.
>
> A number of places say "The valid values are listed in Section 3.1 of JWA<http://openid.net/specs/openid-connect-registration-1_0-14.html#JWA>[JWA]" with respect to signing. But is "none" an acceptable/reasonalbe
> value for any or all of these?
>
>
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegisterResponse
> 2.2.1.  Client Register Operation Response
>
> says that "[client_secret] is not required for clients selecting a
> token_endpoint_auth_method of private_key_jwt" but what if they've selected
> HS256 (or other HSxxx) for request_object_signing_alg or any of the
> *signed* or *singing* parameters?
>
> This section and 2.2.3 have "Additionally, the server MUST include all
> registered metadata about a client as described in Section 2.1<http://openid.net/specs/openid-connect-registration-1_0-14.html#ClientRegistration>,
> including any fields that the server has provisioned on the client's
> behalf." What is the expected behavior for default values from 2.1 (that
> very well might not be stored anywhere).
>
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#ErrorResponse
> 2.3.  Client Registration Error Response
>
> I don't think invalid_client_id or invalid_client_secret are valid anymore?
>
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#Security
> 5.  Security Considerations
> "Requests to the Registration Endpoint for client_update MUST have some
> rate limiting on failures to prevent the Client secret from being disclosed
> though repeated access attempts." Which is true, I suppose, but no longer
> applies to the client secret but rather to the registration access token.
> Also doesn't it apply to rotate_secret as well?
>
>
>
> http://openid.net/specs/openid-connect-registration-1_0-14.html#Acknowledgements
> Appendix A.  Acknowledgements
>
> Is empty. What does it take to get on there? ;) I'm sure I'm not the only
> one either...
>
>
> Thanks,
> Brian
>
>
> P.S. I'll try and look at the other RC docs in the next few days but it's
> very time consuming and not the only thing on my (or anyone's I'm sure)
> plate. I just happened to be trying to update some of my (limited)
> registration code today so it was right in front of me.
>
>
> ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130206/5170a720/attachment.html>


More information about the Openid-specs-ab mailing list