I agree with Tim that is the behaviour I would expect to see with DELETE though I have a rd time seeing a server ever honouring it.
I guess that we need to clarify what happens with PUT and claims the server has defaults for, perhaps some that are not changeable by the client. Is not including a claim in a PUT the same as not including it in registration, and it is set to the default. If you want to set a claim to null then you must explicitly include the claim with null as the value. That is the previous logic we had for replace as the client wasn't getting back all the config in the response and couldn't know about defaults it wasn't setting. Perhaps PUT causes unsent claims to be interpreted as if they are sent with a null value (I think that is a likely to cause tears personally). In ether case the client is not deleted and can still be recovered and the client_id and associated permissions are still active. DELETE to be used correctly is I think going to delete the client_id and all associated tokens and cause a ripple effect in removing grants associated with that client_id. It is a big difference and understanding what a AS is supposed to do to delete a client still seems a touch vague to me. I understand the http verb but there is more to it than that if we want interoperability. John On 2013-02-14, at 12:31 AM, Nat Sakimura <sakim...@gmail.com> wrote: > I thought your concern about DELETE was whether the client should be > allowed to erase the registration data. > I thought PUT with an empty values would achieve a similar effect. > Or did you mean that with PUT, the server default kicks in and > parameters are set to the defaults? > If that is the case, they are quite different, I agree. > > On the effect of DELETE, +1 to Tim's comment. > > Nat > > 2013/2/14 John Bradley <ve7...@ve7jtb.com>: >> DELETE is removing the record not resetting it to defaults. They are quite >> diffrent. >> >> I want to agree on what the expected behaviour of DELETE is. I think we >> have agreement on PUT and POST. >> >> The general not in that a client can DELETE it's record is a implication I >> don't like. I think that is for the server to decide and if it is not >> actually deleting it then DELETE is the wrong verb to use. >> >> John B. >> >> On 2013-02-13, at 3:31 PM, Nat Sakimura <sakim...@gmail.com> wrote: >> >>> Generally speaking, mapping PUT to replace and POST to change is an >>> acceptable practice so I am fine with it. >>> >>> Now, what I still do not understand is why you think it is fine to do >>> PUT or POST and not DELETE. Doing PUT with empty content is almost the >>> same as DELETE. Could you explain? >>> >>> =nat via iPhone >>> >>> Feb 14, 2013 0:10、John Bradley <ve7...@ve7jtb.com> のメッセージ: >>> >>>> 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 >> > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
