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
