I agree that DELETE is potentially problematic. I'd leave it out.
-- Mike
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of John
Bradley
Sent: Wednesday, February 13, 2013 7:10 AM
To: Justin Richer
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management
I am not violently opposed to PUT as a option that completely replaces the
resource setting all unsent claims back to the defaults.
I don't have a good feeling about DELETE, I think we still need more
discussion on what it means, what privileges it takes to invoke it etc.
It could be a bad thing if we get wrong or is not implemented consistently.
Personally I don't think a client should ever be able to DELETE it's record.
I think marking a client_id as pending provisioning, suspended, revoked etc is
better and that can be done with a claim in the update endpoint.
It should only be the server that deletes a record after satisfying it's audit
requirements.
John B.
On 2013-02-13, at 12:00 PM, Justin Richer <jric...@mitre.org> wrote:
> Would it be reasonable to mark the PUT and DELETE methods as optional for the
> server to implement, but with defined semantics if they do? I want to keep
> GET and POST(create) as mandatory, as I think that's the minimal set of
> functionality required.
>
> -- Justin
>
> On 02/11/2013 08:51 PM, John Bradley wrote:
>> I would always include the client_id on update.
>>
>> I think it is also us full to have other tokens used at the update endpoint.
>> I can see the master token used to update all the clients it has registered
>> as part of API management.
>> Relying on the registration_access_token is probably a design that will
>> cause trouble down the road.
>>
>> I think GET and POST are relatively clear. I don't know about expelling
>> PUT to developers. I think POST with a client_id to a (separate discussion)
>> update_uri works without restricting it to PUT.
>>
>> I think DELETE needs to be better understood. I think a status that can be
>> set for client lifecycle is better than letting a client delete a entry.
>> In some cases there will be more than one instance of a client and letting
>> them know they have been turned off for a reason is better than making there
>> registration disappear.
>> So for the moment I would levee out DELETE.
>>
>> John B.
>>
>> On 2013-02-11, at 6:14 PM, Justin Richer <jric...@mitre.org> wrote:
>>
>>> Draft -05 of OAuth Dynamic Client Registration [1] defines several
>>> operations that the client can take on its behalf as part of the
>>> registration process. These boil down to the basic CRUD operations that you
>>> find in many APIs: Create, Read, Update, Delete. Draft -00 defined only the
>>> "Create" operation, draft -01 through -04 added the "Update" operation,
>>> switched using the "operation=" parameter.
>>>
>>> Following several suggestions to do so on the list, the -05 draft defines
>>> these operations in terms of a RESTful API for the client. Namely:
>>>
>>> - HTTP POST to registration endpoint => Create (register) a new client
>>> - HTTP PUT to update endpoint (with registration_access_token) => Update
>>> the registered information for this client
>>> - HTTP GET to update endpoint (with registration_access_token) => read the
>>> registered information for this client
>>> - HTTP DELETE to update endpoint (with registration_access_token) => Delete
>>> (unregister/de-provision) this client
>>>
>>> The two main issues at stake here are: the addition of the READ and DELETE
>>> methods, and the use of HTTP verbs following a RESTful design philosophy.
>>>
>>> Pro:
>>> - RESTful APIs (with HTTP verbs to differentiate functionality) are the
>>> norm today
>>> - Full lifecycle management is common and is going to be expected by many
>>> users of this protocol in the wild
>>>
>>> Cons:
>>> - Update semantics are still under debate (full replace? patch?)
>>> - Somewhat increased complexity on the server to support all operations
>>> - Client has to understand all HTTP verbs for full access (though plain
>>> registration is just POST)
>>>
>>>
>>> Alternatives include using an operational switch parameter (like the old
>>> drafts), defining separate endpoints for every action, or doing all
>>> operations on a single endpoint using verbs to switch.
>>>
>>> -- 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
