[Openid-specs-ab] Registration: how does client_secret rotation work?

Brian Campbell bcampbell at pingidentity.com
Thu Dec 19 14:08:52 UTC 2013


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/40a707cf/attachment.html>


More information about the Openid-specs-ab mailing list