Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Or, are you saying reg access token is a signed assertion echoing back the registration?

I have to think about that. Still don't see the value since there should be only one registration per client cred. 

To me the client token can also be the registration more easily with less complexity. 

Phil

Ps. Apologies just noticed I didn't reply all to group earlier. 

On 2013-05-17, at 1:16, Mike Jones <Michael.Jones@microsoft.com> wrote:

> I think you must understand something here.  The token in the registration spec *is* the token issued to the client by the registration server to represent the client's registration.
> 
> -- Mike
> 
> From: Phil Hunt
> Sent: 5/17/2013 9:53 AM
> To: Mike Jones
> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
> 
> Well why not just use the client token?  
> 
> Phil
> 
> On 2013-05-17, at 0:19, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
>> Its not there for reasons related to expiration. It's there as an access token so the client can access and possibly update its client registration information.
>> 
>> -- Mike
>> 
>> From: Phil Hunt
>> Sent: 5/17/2013 1:02 AM
>> To: Mike Jones
>> Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
>> 
>> Sure. It isn't a new token format.  But it is yet another token with specific usage and security considerations.
>> 
>> I'm concerned about whether it makes sense to create yetanuthertoken just to handle expiry of a token whose expiry wasn't called for in the group or in the threat model (6749 or 6819).
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> 
>> On 2013-05-16, at 3:26 PM, Mike Jones wrote:
>> 
>> > 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-bounces@ietf.org [mailto:oauth-bounces@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.hunt@oracle.com
>> > 
>> > 
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth