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
