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
