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

Wed Feb 6 19:29:10 UTC 2013

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]
> *Sent:* Wednesday, February 06, 2013 11:00 AM
> *To:* Mike Jones
> *Cc:* 'Brian Campbell'; '<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>
>     <mailto: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>
>     [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>
>     <mailto: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  <mailto: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/019265a1/attachment.html>