Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

[Torsten Lodderstedt <[e-mail]>]

Hi all,

I also believe both documents should be merged.

Nevertheless, here are my comments on the current drafts:

*  OAuth 2.0 Dynamic Client Registration Core Protocol 
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

1.2.  Terminology

  " Multiple instances of the same piece of client software MAY use
       the same Client ID value at an authorization server, provided that
       the Redirection URI values and potentially other values dictated
       by authorization server policy are the same for all instances."

Which entity determines whether the same client id is used for different 
instances? Given the current protocol design, I would assume it is at 
the discretion of the authz server. Other opinions?

"Software Statement ... It may also be accepted by some authorization 
servers
       directly as a Client ID value, without prior registration."

under which circumstances does an authz server accept a software 
statement as client_id? How does the client know? I think the idea is 
valuable but needs much more text in order to come up with an 
interoperable protocol design.

1.3. Protocol Flow

Initial Access Token vs. Software Statement: In my opinion, those 
concepts are two different ways to authorize client registration. 
Although there are the typical differences between tokens and assertions 
(such as opaque content vs. defined syntax), I feel software statements 
could supersede initial access tokens.
Thoughts?

2.  Client Metadata

"redirect_uris  ...  It is
       RECOMMENDED that clients using these flows register this
       parameter, and an authorization server SHOULD require ..."

I consider this a rather weak statement - does this foster interop? Why 
not requiring registration of redirect_uris for all clients using 
web-based grant types.

last paragraph:
"If the same client metadata name is present in both
    locations, the value in the software statement SHOULD take
    precedence."

why not MUST?

3.  Software Statement

Is there a need to require a certain signature method for JWTs used as 
software statement (interop)? JWT itself requires "HMAC" and "none", 
which both are of no or limited value in this context. RSA is just 
recommended by the JWT spec.

5.1

"If a software statement was used as part of the registration, its
    value SHOULD be returned in the response and its value MUST be
    returned if the authorization server supports registration management
    operations [OAuth.Registration.Management] that would require its
    presence in subsequent operations."

I don't get the connection between software statements and the 
management API. In the management API spec, I only found a reference to 
software statements in the introduction. Should this text just be removed?

5.2

error codes - invalid_client_metadata

I consider this underspecified. How is the client supposed to react if 
this error occurs? I would expect the authz server to give more detailed 
information regarding error conditions, e.g. notify the client if 
particular requested grant types are not supported. Otherwise, the 
client cannot handle those error differently.

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

I would suggest to add "jwks" (as defined in 
http://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata) 
in order to support native clients.

regards,
Torsten.

Am 04.04.2014 11:13, schrieb Hannes Tschofenig:
> Hi all,
>
> This is a Last Call for comments on the dynamic client registration
> documents:
>
> * OAuth 2.0 Dynamic Client Registration Core Protocol
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>
> * OAuth 2.0 Dynamic Client Registration Metadata
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>
> Since we have to do the last call for these two documents together we
> are setting the call for **3 weeks**.
>
> Please have your comments in no later than April 25th.
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth