On 2013-02-14, at 11:20 AM, Justin Richer <jric...@mitre.org> wrote:
> > 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. Yes that covers it. > >> >> 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. That is what I would expect I don't know if it is a good idea, and adds to the size of the spec. Having a not supported response is better but, I don't have a good feeling about it yet. > > -- 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
