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

[Torsten Lodderstedt <[e-mail]>]

Hi Justin,

the drafts looks very good.

Just some questions/comments from my side:

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.

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.

"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.

"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?

"jwks_uri"
What is this data used for? the OAuth JWT Bearer Token Profiles?

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