This is nothing more than an RFC 6750 bearer token.  These can expire, as 
explained in that draft.  (The can also be issued an a manner that they don't 
expire.)  Nothing new is being invented in this regard.

                                -- Mike

-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Thursday, May 16, 2013 2:35 PM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Client Credential Expiry and new Registration Access Token 
- draft-ietf-oauth-dyn-reg-10

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

Reply via email to