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

[Brian Campbell <[e-mail]>]

As Mike and Torsten have said, and for the same reasons, I would also like
to see the "jwks" metadata parameter added.


On Sun, Apr 20, 2014 at 4:14 AM, Torsten Lodderstedt <
[e-mail]> wrote:

>  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 Protocolhttp://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>
> * OAuth 2.0 Dynamic Client Registration Metadatahttp://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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
   [image: Ping Identity logo] <https://www.pingidentity.com/>
Brian Campbell
[Enter Title]
  @ [e-mail]  [image: phone] +1 720.317.2061  Connect
with us…  [image: twitter logo] <https://twitter.com/pingidentity> [image:
youtube logo] <https://www.youtube.com/user/PingIdentityTV> [image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: Facebook
logo] <https://www.facebook.com/pingidentitypage> [image: Google+
logo]<https://plus.google.com/u/0/114266977739397708540> [image:
slideshare logo] <http://www.slideshare.net/PingIdentity> [image: flipboard
logo] <http://flip.it/vjBF7> [image: rss feed
icon]<https://www.pingidentity.com/blogs/>
   [image: Register for Cloud Identity Summit 2014 | Modern Identity
Revolution | 19–23 July, 2014 | Monterey,
CA]<https://www.cloudidentitysummit.com/>