It can be argued that /foo and /foo?provider=abc are different URI resources.
Nat and I were recommending that the registration return a update URI that can
be unique per client.
In the Apps for domains or Salesforce case the hosting client could be encoded
into the path or a parameter if required, or it could even be a different host
name if some client's data needed to be kept in a particular jurisdiction like
Canada. (honestly there are laws to prevent you hosing data in the US)
The update URI returned may also be exactly the same as the original create URI
that should be left up to the Registration server.
Allowing the Registration server to set the update URI is the most flexible for
supporting multi tenant and other use-cases.
the only downside is that the client needs to remember what it is. As the
client needs to remember a secret and the locations of the endpoint's I don't
think that is a large burden.
In reality the only clients possibly having a issue with that are going to be
native clients, but they are generally registered and managed by a developer
and not by individual client instances.
The problem is a native client is not going to keep it's secret for updating
safe. It would work if client instances create their own unique client_id,
but at that point managing another parameter is the least of your worries.
John B.
On 2013-02-12, at 11:43 AM, Tim Bray <twb...@google.com> wrote:
> ?! /foo and /foo/bar are obviously distinct endpoints.
>
> On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" <sberyoz...@gmail.com> wrote:
> Hi Mike,
> On 12/02/13 01:26, 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.
>
> Perhaps the text can be relaxed somehow to not refer to
>
> /register
> and
> /register/{client_id}
>
> as two different endpoints ? I think it is a single endpoint from the
> implementation point of view :-).
>
> Or may be the spec can indeed be relaxed a bit and allow for a PUT form
> payload be sent directly to /register
>
> Cheers, Sergey
>
> 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
>
> _______________________________________________
> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
