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:[email protected]]
Sent: Friday, May 17, 2013 2:57 AM
To: Mike Jones
Cc: [email protected] 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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>
[email protected]<mailto:[email protected]>
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: [email protected]<mailto:[email protected]>
> [mailto:[email protected]] On Behalf Of Phil Hunt
> Sent: Thursday, May 16, 2013 2:35 PM
> To: [email protected]<mailto:[email protected]> 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>
> [email protected]<mailto:[email protected]>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
