On 02/14/2013 09:05 AM, John Bradley wrote: > 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.
What I had in mind from this conversation is something like this: When sending an update, a client MUST send all metadata fields returned from the server in its initial registration or previous read or update call, including its client_id. A server MAY replace any missing or invalid fields with default values, or it MAY return an error as described in the Error Response section. A server MUST return all provisioned fields in its response. A server MUST NOT change the client_id field. A server MAY change the client_secret and/or refresh_access_token fields. > > 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. This is how I would interpret it as well. It's de-provisioning the client, not resetting it. -- Justin > > 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
