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

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


But again, what about HSxxx JWSs and AxxxKW (and do we allow for 'dir'?)
JWEs? AFAICK, the client_secret is needed for those too.


On Wed, Feb 6, 2013 at 12:29 PM, Justin Richer <jricher at mitre.org> wrote:

>  I think the problem stems from the fact that these values are defined in
> Messages. Maybe instead of defining it in terms of the exception, it should
> be defined as:
>
> "client_secret is required for auth_methods of type client_secret_basic,
> client_secret_post, and client_secret_jwt, and is forbidden otherwise."
>
>  -- Justin
>
>
> On 02/06/2013 02:27 PM, Mike Jones wrote:
>
>  Do you have a specific text change in mind that would address this,
> Justin?****
>
> ** **
>
>                                                             Thanks,****
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Justin Richer [mailto:jricher at mitre.org <jricher at mitre.org>]
> *Sent:* Wednesday, February 06, 2013 11:00 AM
> *To:* Mike Jones
> *Cc:* 'Brian Campbell'; '<openid-specs-ab at lists.openid.net><openid-specs-ab at lists.openid.net>
> '
> *Subject:* Re: [Openid-specs-ab] Comments on Registration (-14) Release
> Candidate D****
>
> ** **
>
> 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><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<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><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.
>
>
>
> ****
>
>
>
>
> ****
>
> _______________________________________________****
>
> 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/19352275/attachment-0001.html>


More information about the Openid-specs-ab mailing list