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
