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.
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. -- 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
