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
