The "jwks" meta-data parameter may also be required for some of the Proof of Possession flows. Allowing a client to register its public key is important for reducing the number of long term symetric keys that need to be maintained.
On Apr 30, 2014, at 5:15 PM, Brian Campbell <bcampb...@pingidentity.com> wrote: > 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 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Brian Campbell > [Enter Title] > @ bcampb...@pingidentity.com > +1 720.317.2061 > Connect with us… > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
