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

[Mike Jones <[e-mail]>]

I’m saying that we issue an access token granting access to the registration state for the client and a separate client_id (and sometimes client_secret) used for accessing the Authorization Server.  The first is used by the party writing/registering the client.  The second is used by the client.  Both the resources accessed and the parties accessing the resources are different.

I’m puzzled why you would propose combining/overloading them, given the security differences.  Especially, I wouldn’t want to bake the registration access token into the client – especially a mobile client – because it would mean anyone in possession of an instance of the client could change/deface/maliciously-intentionally-break the client registration for all instances.  Whereas, I *must* bake the client_id and potentially the client_secret into the client.

                                                            -- Mike

From: Phil Hunt [mailto:[e-mail]]
Sent: Friday, May 17, 2013 2:57 AM
To: Mike Jones
Cc: [e-mail] WG
Subject: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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<http://www.independentid.com>
[e-mail]<mailto:[e-mail]>





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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Phil Hunt
> Sent: Thursday, May 16, 2013 2:35 PM
> To: [e-mail]<mailto:[e-mail]> 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<http://www.independentid.com>
> [e-mail]<mailto:[e-mail]>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth