Re: [OAUTH-WG] review comments on draft-ietf-oauth-dyn-reg-11.txt

["Richer, Justin P." <[e-mail]>]

On May 30, 2013, at 11:18 AM, Torsten Lodderstedt <[e-mail]> wrote:

> Hi Justin,
> 
> see below :-)
> 
> Justin Richer <[e-mail]> schrieb:
> 
>> Torsten, thanks -- responses inline.
>> 
>> On 05/30/2013 06:34 AM, Torsten Lodderstedt wrote:
>>> Hi Justin,
>>> 
>>> comments inline.
>>> 
>>>>> 
>>>>> section 1.4
>>>>> 
>>>>> How is the client supposed to identify/distinguish authorization 
>>>>> servers? Based on the Client Registration Endpoint URI? 
>>>>> Authorization server identification is necessary in order to map 
>>>>> client_ids to authorization servers for clients, which are
>> connected 
>>>>> to multiple authorization servers.
>>>> That's a great question -- but I think it's entirely dependent on
>> how 
>>>> discovery and configuration is set up for a client, which is 
>>>> ultimately orthogonal to registration. The way that I've implemented
>> 
>>>> it in our client is based on the OpenID Connect discovery process, 
>>>> which bases everything in the server's configuration off of an 
>>>> "issuer" URL. It would be easy enough to point out here that 
>>>> discovery and differentiation of different servers is out of scope.
>>> 
>>> At least this should be pointed out. I would rather prefer a 
>>> definition how to relate client_id and authz server.
>>> 
>>> I don't think your solution can be generalized for generic OAuth
>> since 
>>> the issuer is only known to OpenID Connect clients. In my opinion, a 
>>> simple, generic concept could be based on the authorization server's 
>>> client registration URL. A more sophisticated approach would be to 
>>> introduce authorization server meta data discovery (as a subset of 
>>> 
>> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata),
>> 
>>> which might contain an OAuth authz server id.
>> 
>> I'm not comfortable with specifying a discovery or server 
>> differentiation method, but we can at least point out that the means by
>> 
>> which the client differentiates servers is out of scope.
> 
> OK, wfm.
> 
>>>>> section 1.4.1 f
>>>>> 
>>>>> Why does the client secret expire while the access token ist still 
>>>>> valid? Secret and token are stored at the same
>>>>> locations so an attacker may obtain both at once.
>>>> Secrets are used at the token endpoint, so the attack surface is 
>>>> slightly different. Since you can only use the registration access 
>>>> token at the registration endpoint, you can use it to rotate your 
>>>> other credentials.
>>> 
>>> I understand the mechanism. I don't see the benefit given the
>> _slight_ 
>>> difference in attack surface. In my opinion, the only difference
>> might 
>>> be on the server side, between HTTPS termination and actual endpoint 
>>> business logic. So it might limit the impact if an attacker, for 
>>> example, obtains client secrets from server log files. Is this threat
>> 
>>> worth to use different credentials with different lifecycles?
>> 
>> That's getting into a different question, the question of the utility
>> of 
>> the registration access token. We need that because not all clients
>> have 
>> a client_secret (some just don't have any authn, some will use signing 
>> or assertions), among other reasons talked about in section 1.3. The 
>> fact that their lifecycles are independent simply stems from the fact 
>> that they're separate credentials, and that it's more likely desirable 
>> to have the client_secret expire in the real world. Also, note that you
>> 
>> don't have to expire either of them. Or you can expire both of them at 
>> the same time but have some way to keep an expired credential around
>> for 
>> one-last-refresh-call or something, you can do that.
> 
> I understand. After thinking about it again I think it makes sense to have different credentials in order to keep client mgnt and the OAuth flow independent.
> 
>>>>> "token_endpoint_auth_method"
>>>>> What is the use case for dynamic registration of public clients? In
>> 
>>>>> my opinion, public clients exist because OAuth 2.0 core does not 
>>>>> provided a mechanism to provision secrets to the different
>> instances 
>>>>> of an installed/native app. Dynamic registration closes this gap,
>> so 
>>>>> any installed app may retrieve a distinct secret.
>>>> 
>>>> This gap-closing is true for some classes of client that used to
>> have 
>>>> to be public, like many native apps. But there are still clients
>> that 
>>>> have no use for a client secret, like in-browser clients that use
>> the 
>>>> implicit flow. Now if these clients are also talking to multiple
>> auth 
>>>> servers, they'll each need a client_id at the auth server (because 
>>>> there's no practical way to publish a "public" client ID to *all* 
>>>> auth servers). A discussion in the security considerations about the
>> 
>>>> limitations and usefulness of this use case is probably worthwhile, 
>>>> so I'll make a note to do that.
>>> 
>>> yes, clients using the implicit grant need a way to register. But
>> they 
>>> don't use the token endpoint. As this is about token endpoint 
>>> authentication, I still don't see the need to have a "none" method
>> there.
>> 
>> The "none" method is needed because without it, a server will grant
>> (and 
>> expect) a client_secret from a client that has no business having one 
>> (and no need for one).
> 
> So you are saying this parameter is used to distinguish public and confidential clients?

Yes, that's one key way that it can be used. On the grand scale, this parameter just says what kind of authn credential the client is using. In core OAuth, the only real distinction is "it has one or not", which is the difference between a public and confidential client. This parameter lets you make that distinction as well as going deeper.

> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> "client_secret_post vs client_secret_basic"
>>>>> BASIC and POST are essentially the same just different ways to send
>> 
>>>>> the client secret. If an authorization server supports both, both 
>>>>> should work for any client. So are both methods treated
>> differently?
>>>> I agree, and this was one of my original arguments for making this 
>>>> field plural (or plural-able), but there hasn't been WG support for 
>>>> that so far.
>>> 
>>> I'm not arguing to make it plural. I think the authentication method 
>>> is just "client_secret".
>> 
>> That was also an option that was brought up, but in the OIDC WG the 
>> counter-argument was (as I recall) that the two are syntactically 
>> separate and there's a desire to restrict to a single type, such as 
>> disabling client_secret_post. Basically, to make it unambiguous.
> 
> Ok. 
> 
> Best regards,
> Torsten.
> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> "jwks_uri"
>>>>> What is this data used for? the OAuth JWT Bearer Token Profiles?
>>>> 
>>>> That's one, but it's really for any higher-level protocol that uses 
>>>> signing and encryption. There are several out there that are using 
>>>> JOSE on top of OAuth to do things, so we felt it was worthwhile to 
>>>> have one standard place to have the client say "here's my public
>> key".
>>> 
>>> ok, understood.
>>> 
>>> best regards,
>>> Torsten.
>>>> 
>>>> -- Justin
>>>> 
>>>>> 
>>>>> best regards,
>>>>> Torsten.
>>>>> 
>>>>> Am 24.05.2013 23:10, schrieb Richer, Justin P.:
>>>>>> New Dynamic Registration draft is published, incorporating much of
>> 
>>>>>> the discussion from the group this week.
>>>>>> 
>>>>>> Some normative changes that should have minimal impact:
>>>>>>  - "expires_at" is now "client_secret_expires_at"
>>>>>>  - "issued_at" is now "client_id_issued_at"
>>>>>>  - creation of an IANA registry for token_endpoint_auth_method
>>>>>>  - removal of two underdefined values from 
>>>>>> token_endpoint_auth_method (client_secret_jwt and
>> private_key_jwt), 
>>>>>> these are now defined in an extension (OpenID Connect
>> Registration)
>>>>>> 
>>>>>> And several editorial changes:
>>>>>> 
>>>>>>  - new "client lifecycle" section that describes how different 
>>>>>> kinds of clients can use the dynamic registration protocol, how a 
>>>>>> client's credentials get refreshed, and the relationship between 
>>>>>> the Client Identifier and the Client software
>>>>>>  - new "registration tokens and credentials" section describing 
>>>>>> the different kinds of tokens and credentials used in the 
>>>>>> registration process, what they're for, and why they're all
>> separate
>>>>>>  - clarified the definitions of several fields like policy_uri
>> and 
>>>>>> tos_uri
>>>>>> 
>>>>>> Thanks for all the great feedback, and please keep the
>> constructive 
>>>>>> commentary coming!
>>>>>>  -- Justin
>>>>>> 
>>>>>> On May 24, 2013, at 4:36 PM, <[e-mail]>
>>>>>>  wrote:
>>>>>> 
>>>>>>> A New Internet-Draft is available from the on-line
>> Internet-Drafts 
>>>>>>> directories.
>>>>>>> This draft is a work item of the Web Authorization Protocol 
>>>>>>> Working Group of the IETF.
>>>>>>> 
>>>>>>>    Title           : OAuth 2.0 Dynamic Client Registration
>> Protocol
>>>>>>>    Author(s)       : Justin Richer
>>>>>>>                          John Bradley
>>>>>>>                          Michael B. Jones
>>>>>>>                          Maciej Machulak
>>>>>>>    Filename        : draft-ietf-oauth-dyn-reg-11.txt
>>>>>>>    Pages           : 34
>>>>>>>    Date            : 2013-05-24
>>>>>>> 
>>>>>>> Abstract:
>>>>>>>   This specification defines an endpoint and protocol for
>> dynamic
>>>>>>>   registration of OAuth 2.0 Clients at an Authorization Server
>> and
>>>>>>>   methods for the dynamically registered client to manage its
>>>>>>>   registration.
>>>>>>> 
>>>>>>> 
>>>>>>> The IETF datatracker status page for this draft is:
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>>>>>> 
>>>>>>> There's also a htmlized version available at:
>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-11
>>>>>>> 
>>>>>>> A diff from the previous version is available at:
>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-11
>>>>>>> 
>>>>>>> 
>>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> 
>>>> 
>>> 
>