So, I think we agree in general, but to be explicit: I want a server to
be free to include the client_id as an input parameter if it wants to,
but I would rather not have the client be required to compose that
parameter onto the base registration URL on its own. This is to preserve
the flexibility on the server side to deploy things as you describe
below, but also to have URL path components as the identifier (common in
REST frameworks) if it so chooses. The client shouldn't ever care which
pattern the server wants to use. This is the motivation behind providing
the client management URL as part of the response (separate discussion).
Also, for the record, OAuth 2.0 does not use the same endpoint for
different things in the way you describe. To refresh a token, you send a
request to the token endpoint with grant_type=refresh_token (section 6).
The "grant_type" parameter is explicitly designed as a mode-switch
parameter (for instance, see the discussion in section 4.5) and the
refresh token flow is no different. Some early drafts of the OAuth 2.0
core document even called out refresh token as a parallel "flow" with
the rest of them, like authorization_code and implicit, but that seemed
to confuse people more than it helped, so Eran pulled it into a separate
section entirely. Nevertheless, the structure and syntax remains parallel.
-- Justin
On 02/11/2013 08:26 PM, Mike Jones wrote:
At most, there should be two endpoints - creation and management - for a client, but the protocol
should be structured such that they *can* be at the same URL, if the server so chooses. A simple
way to accomplish this is to require that the client_id value be provided as an input parameter on
update operations. Then for implementations that use a single endpoint, they can distinguish
"create" and "update" operations on the management endpoint by the presence or
absence of the client_id value.
If you want to have separate endpoints and don't need the client_id because you
have somehow encoded it into the management endpoint URL, that's fine. It
still can serve as a useful cross-check that the client (or an attacker) is
requesting a change to a client that matches the bearer token used. But
including it is necessary for implementations that want to use a single
registration endpoint, rather than having a proliferation of per-client
endpoints.
BTW, just for the record, OAuth 2.0 uses the same endpoint for initial access
token requests and requests for refreshed access tokens - with the operations
being distinguished by whether a refresh_token parameter is present. So
there's a useful OAuth precedent for doing things this way.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:15 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Registration: Endpoint Definition (& operation parameter)
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
