[Openid-specs-ab] client_id and statelessness (was Registration: how does client_secret rotation work?)

Brian Campbell bcampbell at pingidentity.com
Thu Dec 19 14:38:09 UTC 2013


Oh, and can the client_id value change? There seems to be nothing
explicitly forbidding it nor anything stating that it could happen.

Allowing it to change enables secret rotation and other changes and
eventually update capability for stateless (to the AS) clients.

A few of us discussed the concept during IETF Vancouver and, if I recall
correctly, there seemed to be some general consensus that it'd be a good
idea. But no actual action or text has come of that in the connect specs or
the IETF registration.


On Thu, Dec 19, 2013 at 7:08 AM, Brian Campbell
<bcampbell at pingidentity.com>wrote:

> It's my understanding that, while general update/delete management
> functionality was removed from Registration , the Client Read Request was
> put or left in largely to facilitate rotation of the client_secret value.
> Sec 4.3. Client Read Response calls out the secret specifically in, "Upon a
> successful read operation, the Authorization Server SHOULD return all
> registered Metadata about this Client, including any fields provisioned by
> the Authorization Server itself. Some values, including the client_secret
> value, might have been updated since the initial registration." Please
> correct me, if I'm wrong here.
>
> But how does that really work?
>
> Is the client expected to make a read request at exactly the instance
> indicated previously with the client_secret_expires_at response parameter?
> That seems fragile. To avoid the fragility, should the AS be expected to
> keep both the old and new secret for a given client for some grace period
> around the client_secret_expires_at time?
>
> Or does a read request actually (sometimes) trigger the change in
> client_secret? While perhaps practical in some cases, I think that'd bring
> a tear to the eye of even the most casual RESTafarian.
>
> Or is a client expected to do a read request anytime token endpoint
> authentication or a symmetric crypto operation is unsuccessful and then
> retry it? That seems very complicated. And the client is supposed to be
> simple(er).
>
> Or something else?
>
> Or am I missing the point somewhere?
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131219/59ba0ded/attachment.html>


More information about the Openid-specs-ab mailing list