From what I have seen deployed, there are four common flows for registration.
1 2 developer uses a tool to register a client ID and place that in the client code for deployment of a native App that is distributed via an app store for a 3rd party API. The developer may later need to make changes to the registration as they develop the client and add functionality without changing the client_id which would effectively invalidate all user consent as consent is by client_id. 2 A client such as a web server (Think SAML SP) has a user turn up and identify themselves via a email address that be de-refrenced by say web finger to find a service for the API the client knows about and wants permission to access. The client learns the registration endpoint and registers itself for a client_id at the endpoint and can then do OAuth 2 autherization with the AS for the user. 3 A client such as a web server wants to connect to a new AS. They try 2 but get an error for dynamic registration indicating they need a credential to register. A admin is notified and goes to some AS portal for developers and register an account perhaps validating a email and phone number for contact as well as agreeing to the AS's terms of service. They then receive an access token for the registration endpoint that they cut and paste into there app to do the actual registration. 4 A client such as a web server wants to connect to a new AS. They try 2 but get an error for dynamic registration indicating they need a credential to register. A admin is notified and goes to some AS portal for developers and register an account perhaps validating a email and phone number for contact as well as agreeing to the AS's terms of service. The developer must then enter all there redirect URI keys and other configuration info manually into a form. Then gets another form or email with a key and client_id that they use to configure the app. If the client secret expires they must use there developer account to login and get a new client secret. This is what we are trying to automate with dynamic client registration. Uncommon but needed: In a version of 3 the developer may be registering a client class with certain constraints that override the dynamic registration of the class. They then get back the "Registration Access Token" and put that in a native app to be distributed. The native app may then create its own keypair unique to that instance and proceed to register itself and get a per instance client_id (but bound to the class at the AS) this would allow a native app to be confidential( Some might see that as a good thing). The native app then uses the new "Registration Access Token" it is granted to manage its settings. The original API developer based on there developer credentials that generated the original or class "Registration Access Token" could manage the class including revoking it. This higher level class management design is allowed by the current spec but needs another spec to flesh it out. This is perhaps part of the 5% you are looking for. The "Registration Access Token" is for a different resource than what ever the actual API is. It is also not a client secret password and may have much higher entropy as it is a token and not subject to limitations of http basic implementations. The initial "Registration Access Token" manages a class (might only be one entity in the class) it is an access token so can have scopes. A possibility for 5 would be something like crate, update and read. In 5 the token would only have create. The second "Registration Access Token" that is instance specific would have more rights but only for its instance client_id. In the design there are two "Registration Access Token" that are separate form client credentials at the token endpoint because they are possibly used by different entities for operations on different subjects in the registration API. It is possible that in an extension we could allow for the developer portal to provide access tokens with perhaps a delete scope for the class rather than the instance if that is perhaps one of the things you are looking for. I think the higher level management of classes of clients deserves it's own profile. We need to ensure we are not blocking it with what we are doing in dynamic registration. John B. On 2013-05-18, at 1:29 AM, Phil Hunt <phil.h...@oracle.com> wrote: > John, > > Thanks for jumping in. > > 1. I do buy the implied argument that some client credential types do expire > (eg. bearer assertions). Therefore the expiry issue has to be dealt with. I > would prefer to handle this by allowing an exception whereby expired > assertions could be used to re-register (only). This shouldn't be a big > security issue since we're talking about an expired client refreshing with > its issuer rather then a third party trusting an expired token. > > I just don't think adding another token, the registration access token, that > in turn (by your argument) should expire, actually helps. It just adds > another layer to the problem and increases complexity. It solves nothing. > > 2. You seem to be describing a different usage than Justin is. The way he > explains the draft, there is no developer cycle at all. He's saying every > client gets a registration token and a client token. > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > > > On 2013-05-17, at 10:40 AM, John Bradley wrote: > >> 1 No reasonable security profile is going to let you use the same symmetric >> password over long time periods. It will be brute forced given enough time. >> >> The rotation time will depend on entropy and the rate an attacker can submit >> attempts. I would expect profiles to look at SP-800-63 for guidance as >> essentially a password for the client. >> >> 2 the registration interface is likely used by a developer who probably >> doesn't want the client instances (say native clients) to be able to update >> the configuration directly. using the client secret credential for updates >> would break the separation. Registration my be done by the client itself >> or by a developer as a separate process. >> >> John B. >> >> On 2013-05-17, at 7:27 PM, Phil Hunt <phil.h...@oracle.com> wrote: >> >>> Justin, >>> >>> Your reason was you copied connect. Ok. I was looking for a technical >>> reason. A security reason. >>> >>> BTW. Mike Jones says expiry wasn't the reason. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>> >>> >>> On 2013-05-17, at 9:01 AM, Justin Richer wrote: >>> >>>> The separation between these two is necessary: Not all clients have >>>> client_secret, and you want the lifecycle/management of the registration >>>> to be protected. This is what the registration access token was made for. >>>> In older versions of Connect's registration, the client_secret was forced >>>> on all clients in order to provide this, but then you had public clients >>>> with a client_secret that they couldn't use to get tokens, and it was a >>>> bad disconnect. >>>> >>>> The requirement for client secrets to expire or otherwise be rotated by >>>> the server came from several implementors in the Connect WG. There's an >>>> easy way to indicate that they don't expire, and a fairly straightforward >>>> way for them to be rotated (client does a GET on its client configuration >>>> endpoint url, with its registration access token as auth). >>>> >>>> -- Justin >>>> >>>> On 05/16/2013 05:35 PM, Phil Hunt wrote: >>>>> All, >>>>> >>>>> In the dynamic registration draft, a new token type is defined called the >>>>> "registration access token". Its use is intended to facilitate clients >>>>> being able to update their registration and obtain new client credentials >>>>> over time. The client credential is issued on completion of the initial >>>>> registration request by a particular client instance. >>>>> >>>>> It appears the need for the registration access token arises from the >>>>> implied assertion that client credentials should expire. >>>>> --> Is anyone expiring client credentials? >>>>> >>>>> To date, we haven't had much discussion about client credential expiry. >>>>> It leads me to the following questions: >>>>> >>>>> 1. Is there technical value with client credential/token expiry? Keep >>>>> in mind that client credential is only used with the token endpoint over >>>>> TLS connection. It is NOT used to access resources directly. >>>>> >>>>> 2. If yes, on what basis should client credential/token expire? >>>>> a. Time? >>>>> b. A change to the client software (e.g. version update)? >>>>> c. Some other reason? >>>>> >>>>> 3. Is it worth the complication to create a new token type (registration >>>>> access token) just to allow clients to obtain new client tokens? Keep in >>>>> mind that client tokens are only usable with the AS token endpoint. Why >>>>> not instead use a client token for dyn reg and token endpoint with the >>>>> rule that once a client token has expired (if they expire), an expired >>>>> token may still be used at the registration end-point. >>>>> >>>>> 4. Are there other reasons for the registration token? >>>>> >>>>> Thanks, >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
