I agree, and the "must include client_id" gels with the other discussion
of doing a full-replace for the PUT operation for updates from another
thread.
-- Justin
On 02/12/2013 01:37 PM, Mike Jones wrote:
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
