2013/2/14 Justin Richer <jric...@mitre.org>: > Duly noted, and while there seems to be solid support behind the > semantics of returning a URL, I'm not convinced the syntax argument is > over yet either. I have seen support and good arguments from both sides > and there isn't a clear winner there (see the other thread). Speaking as > an individual member, I could go with either approach and I'd like to > see what the rest of the WG wants.
Thank you. I wanted to raise a voice that while the need for the returning the URL seemed to have come to a consensus, the syntax has not, unlike Mike wrote. > > Speaking now as an editor: It's been suggested off-list that we adopt > the simplified (bespoke) mechanism of the "registration_access_url" > syntax for the next draft and continue to move discussion forward for > the inclusion of the more-general mechanism (beit HAL based or something > similar like JSON-LD) here on the list. Would you and the other HAL > supporters be amenable to this solution? I wouldn't be opposed to adding > a kind of "note for discussion" section to the -06 draft to help > facilitate moving forward in a concrete manner, with the assumption that > the text would be either removed or incorporated in a later draft. I > just have to put a stake down somewhere on the syntax, and I'm leaning > towards the one that doesn't add a normative dependency on an unfinished > (as of right now) work. FYI, I have not suggested to reference HAL or other unfinished specifications, but incorporate the syntax. If there is to be a reference, then that is for the curtesy and will be an informational reference. As to the actual editing is concerned, may I suggest the reverse: i.e., keep the current text (-05) and add a note for discussion. It is customary in the standardization process that the change to the text is not to be incorporated until the resolution from the comments are reached. If the text is changed, then it means that the resolution is reached, which is not the case. Even "ne bis in idem" may kick in, which effectively prohibit the change back. Nat > > -- Justin > > On 02/13/2013 01:27 PM, Nat Sakimura wrote: >> I am against the syntax of registration_access_url . >> >> =nat via iPhone >> >> Feb 13, 2013 3:37、Mike Jones <michael.jo...@microsoft.com> のメッセージ: >> >>> Then I think we've reached an acceptable resolution on this one. By having >>> the server return the registration_access_url upon create and having the >>> client be required to include the client_id upon update, servers are free >>> to manage their registration endpoint(s) as they see fit and clients always >>> do the same thing. >>> >>> Thanks all, >>> -- Mike >>> >>> -----Original Message----- >>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> Nat Sakimura >>> Sent: Tuesday, February 12, 2013 9:15 AM >>> To: Justin Richer >>> Cc: oauth@ietf.org >>> Subject: Re: [OAUTH-WG] Registration: RESTful client lifecycle management >>> >>> 2013/2/13 Justin Richer <jric...@mitre.org>: >>>> On 02/12/2013 11:30 AM, John Bradley wrote: >>>>> To some extent we want the server to have the flexibility it needs. >>>>> >>>>> If the server knows it is going to need client_id for GET it needs to >>>>> encode it in the resource URI ether as part of the path or as a query >>>>> parameter (that is up to the server) >>>>> >>>>> When doing updates the client MUST include the client_id as an >>>>> additional integrity check. Some servers may switch on that but that is >>>>> up to them. >>>> So if by this you mean that the client still simply follows whatever >>>> update url the server hands it (which may or may not include the >>>> client_id in some form, but the client doesn't care), and that the >>>> client MUST include its client_id in the request body (top-level >>>> member of a JSON object, at the >>>> moment) when doing a PUT (or POST/PATCH? see below) for the update >>>> action, then I'm totally fine with that. Is this what you're suggesting? >>> As far as I understand, yes. That is what we discussed last Thursday face >>> to face. >>> >>> >>> -- >>> 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 > -- 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
