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

Justin Richer jricher at mitre.org
Wed Feb 6 19:00:12 UTC 2013


That's not private_key_jwt anymore, that's client_secret_jwt, which is a 
different value. We probably want to have this be more explicitly called 
out where these values are defined.

  -- Justin


On 02/06/2013 01:54 PM, Mike Jones 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-review 
> to 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.key 
> has 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.
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130206/9e062cdb/attachment.html>


More information about the Openid-specs-ab mailing list