In Connect's dynamic client authentication we optionally allow for authenticated clients to register.
The idea is that you can have a master token pre provisioned in an app and then use that to get an individual client ID and client secret for a native app on a per instance basis. This is useful to UMA, and potentially other cases where de-authorizing a particular instance of a client from using it's refresh token would be useful. So I agree that obtaining a clientID and secret on activation is useful. While you could theoretically move JS clients who are public now to a registration and code flow it is unclear to me if that actually adds any real security. I can see a simplification of the AS argument, but at a performance cost to the client. As to the refresh token argument, it seems that Facebook at least has moved to refreshing access tokens directly to get around the implicit grant problem. I am for Dynamic client registration, I just don't think it is a silver bullet, and needs significant thought. I admit that openID is not under time pressure on this as we have our own extension, that is not intended to be generic. However we did make registration a separate spec so that people can reuse the pattern if it works for them, but mostly to make it easier for us to move to a eventual standard without modifying the core spec. John B. On 2012-03-22, at 5:29 AM, Torsten Lodderstedt wrote: > Hi John, > >> I don't think dynamic registration completely removes the need for a >> public client, that can't keep secrets. > > I don't get this argument. In my opinion, there are two use cases, which > currently motivate usage of public clients and none of them is about "keeping > secrets". > > 1) native apps - There is no mechanism for securely _provisioning_ those > clients with client secrets. So it does not make sense to use secrets for > authenticating them. Dynamic client registration would allow them to obtain > client id and secret on activation/installation. The security of the > respective secret is the same as for refresh tokens. So either both can be > protected appropriately or none of them. Please note: I'm not talking about > trust in the identity/authenticity of the particular app installation. I'm > just talking about simplifying the OAuth flows and description. Today an AS > needs to support the refresh tokens or resource owner grant type for both > confidential and public clients in order to also support native apps. > 2) implicit grant - here, public clients are used because the protocol design > itself does not allows for validating client secrets. Obviously, digital > signature would help but make the protocol more difficult to use. > > Basically, dynamic client registration allows a client to bind to an AS at > runtime. That's what it makes so valuable with respect to interoperatibility. > Whether the client just registers meta data or also obtains a secret is > another aspect but not the only one. > > regards, > Torsten. > >> >> While we did do dynamic client registration for Connect that is a >> more constrained use case. >> I would put JWT and AS-RS communication as higher priorities than >> dynamic registration. >> Partially because they are more self contained issues. >> >> John B. >> On 2012-03-21, at 4:35 PM, Torsten Lodderstedt wrote: >> >>> In my opinion, dynamic client registration would allow us to drop public >>> client thus simplifying the core spec. >>> >>> regards, >>> Torsten. >>> >>> Am 15.03.2012 16:00, schrieb Eran Hammer: >>>> I believe most do, except for the dynamic client registration. I don't >>>> have strong objections to it, but it is the least important and least >>>> defined / deployed proposal on the list. The AS->RS work is probably >>>> simpler and more useful at this point. >>>> >>>> EH >>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On Behalf >>>>> Of Tschofenig, Hannes (NSN - FI/Espoo) >>>>> Sent: Thursday, March 15, 2012 4:47 AM >>>>> To: ext Blaine Cook; Hannes Tschofenig >>>>> Cc: [email protected] >>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering >>>>> >>>>> Hi Blaine, >>>>> >>>>> These are indeed good requirements you stated below. >>>>> >>>>> When you look at the list of topics do you think that the proposed items >>>>> indeed fulfill them? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: [email protected] [mailto:[email protected]] On Behalf >>>>>> Of ext Blaine Cook >>>>>> Sent: Thursday, March 15, 2012 1:31 PM >>>>>> To: Hannes Tschofenig >>>>>> Cc: [email protected] WG >>>>>> Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering >>>>>> >>>>>> On 14 March 2012 20:21, Hannes Tschofenig >>>>> <[email protected]> >>>>>> wrote: >>>>>>> So, here is a proposal: >>>>>>> >>>>>>> [Editor's Note: New work for the group. 5 items maximum! ] >>>>>>> >>>>>>> Aug. 2012 Submit 'Token Revocation' to the IESG for consideration >>>>>> as a Proposed Standard >>>>>>> Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>>> Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for >>>>>> OAuth 2.0' to the IESG for consideration >>>>>>> Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to >>>>>> the IESG for consideration as a Proposed Standard >>>>>>> Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration >>>>>> as an Informational RFC >>>>>> >>>>>> This looks great to me. >>>>>> >>>>>> I have serious concerns about feature-creep, and think that the OAuth >>>>>> WG should strongly limit its purview to these issues. In general, I >>>>>> think it prudent for this working group in particular to consider >>>>>> standardisation of work only under the following criteria: >>>>>> >>>>>> 1. Proposals must have a direct relationship to the mechanism of OAuth >>>>>> (and not, specifically, bound to an application-level protocol). >>>>>> 2. Proposals must have significant adoption in both enterprise and >>>>>> startup environments. >>>>>> 3. Any proposal must be driven based on a consideration of the >>>>>> different approaches, as adopted in the wild, and strive to be a >>>>>> better synthesis of those approaches, not a means to an end. >>>>>> >>>>>> These are the constraints with which I started the OAuth project, and >>>>>> they're more relevant than ever. I'd hate to see OAuth fail in the end >>>>>> because of a WS-*-like death by standards-pile-on. >>>>>> >>>>>> b. >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
