The rotate_secret operation was added to OpenID Connect Registration as a
workaround to the fact that registration updates used to be authenticated using
the client secret, so it seemed overly dangerous to have an update operation
potentially return an updated secret and have the secret be lost due to
communication problems - leaving the client stranded. Since then, registration
was changed to use a bearer token to authenticate update operations, and so
this failure mode can't occur anymore. It was an omission not to have deleted
the unneeded operation then.
It's been deleted from OpenID Connect Registration and should likewise be
deleted from OAuth registration, since it is unneeded. If a new client secret
is needed, there's nothing stopping the registration server from returning it
in the result of an update operation.
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: [email protected]
Subject: [OAUTH-WG] Registration: Client secret rotation
Draft -05 of OAuth Dynamic Client Registration [1] defines a means of the
client requesting a new client_secret (if applicable) and a new
registration_access_token. Client secrets MAY expire after some period of time,
and this method allows for a refresh of that secret. Draft -00 defined no such
operation, drafts -01 through -04 defined this operation in terms of the
operation=rotate_secret parameter, and draft -05 defines it through a secondary
endpoint, the Client Secret Rotation Endpoint.
This raises several questions:
- Should the client be allowed to request rotation of its secret?
- Would a client ever take this action of its own accord?
- Can a server rotate the secret of the client without the client asking?
(This seems to be an obvious "yes")
Alternatives that keep this functionality include defining the rotate_secret
operation in terms of an HTTP verb, a query parameter, or separate endpoint.
Alternatively, we could drop the rotate_secret operation all together. If we do
this, we have to decide if the client secret can still expire. If it can, then
we need a way for the client to get this new secret through a means that
doesn't require it to request a change in secret, such as sending it back as
part of the client READ operation (see other thread on RESTful verbs).
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
