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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
