Draft -05 of OAuth Dynamic Client Registration [1] defines three
fundamental operations that a client can undertake: Client Registration,
Client Update, and Secret Rotation. Each of these actions needs to be
differentiated *somehow* by the client and server as part of the
protocol. Draft -00 defined only the "register" operation, drafts -01
through -04 made use of an "operation" parameter on a single endpoint,
which brought up a long discussion on the list on whether or not that
was an appropriate design. Draft -05 did away with the definition of the
"operation" parameter on a single endpoint and instead opted for
separating the base functionality into three different endpoints.
Pro:
- Closer to RESTful semantics of having one URL for creation and
another URL for management of an item (eg, most REST APIs use /object
for creation and /object/object_id for manipulation)
- The rest of OAuth (and its extensions) defines separate endpoints
for different actions (Authorization, Token, Revocation, Introspection)
as opposed to a single endpoint with a mode-switch parameter
- Client doesn't have to generate a URL string for different endpoints
by combining parameters with a base URL
Con:
- Not quite exactly RESTful as the spec doesn't dictate the client_id
be part of the update or rotate URL (though and implementor's note
suggests this)
- Client has to track different URLs for different actions
- Server must be able to differentiate actions based on these
different URLs.
Alternatives include using different HTTP verbs (see other thread) or
defining an operational switch parameter, like older drafts, on a single
endpoint URL. Another suggested alternative is to look for the presence
of certain parameters, such as client_id or the registration access
token, to indicate that a different operation is requested.
There's also question of whether the Secret Rotation action needs to
have its own endpoint, or if it can be collapsed into one of the others.
It has been suggested off-list that the secret rotation should never be
initiated by the Client but instead the client should simply request its
latest secret from the server through the update (or read) semantics.
-- 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
