?! /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<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05>
>> ______________________________**_________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>> ______________________________**_________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>>
>
> ______________________________**_________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/**listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
