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 < tors...@lodderstedt.net> 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- [image: Ping Identity logo] <https://www.pingidentity.com/> Brian Campbell [Enter Title] @ bcampb...@pingidentity.com [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/>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
