John Thanks. This is *very* helpful. I will consider for next week.
Phil On 2013-05-17, at 23:56, John Bradley <ve7...@ve7jtb.com> wrote: > 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. > > 5 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 delet e 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
