It is a useful debug and sanity check. Leave it in for now. John B.
On 2013-06-27, at 3:14 PM, Justin Richer <[email protected]> wrote: > That's a very good point -- the extra layer of sanity checking is valuable in > many cases. > > -- Justin > > On 06/27/2013 10:58 AM, Mike Jones wrote: >> I believe that we should leave it as-is. For many implementations, it’s >> important to communicate the client_id value. >> >> -- Mike >> >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Justin Richer >> Sent: Thursday, June 27, 2013 7:31 AM >> To: Vladimir Dzhuvinov / NimbusDS >> Cc: [email protected] >> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt >> >> Not all URLs will have the client_id in them (even though it's recommended >> and the common examples do) -- some systems will just re-use the >> Registration Endpoint's URL and switch behavior based on the presence of a >> valid registration_access_token and look up the client_id based on the token >> itself. >> >> My initial thought was that having the client leave out the client_id from >> the data model seems to be asking for trouble. However, we already preclude >> people from sending back some other fields: >> The Client MUST NOT include the >> "registration_access_token", "registration_client_uri", >> "client_secret_expires_at", or "client_id_issued_at" fields described >> in Client Information Response (Section 5.1). >> >> So an argument might be to have clients send *only* the fields described in >> Client Metadata (2) and not the extra fields in the Client Information >> Response (5.1). We need to decide whether these fields MUST NOT be sent, or >> if they MAY be sent and if sent they MUST match. The former would get rid of >> the paragraph saying that the client_id and client_secret have to be >> checked, and get rid of the invalid_client_id parameter. >> >> Do we want this change, or do we want to leave it as it is? >> >> -- Justin >> >> On 06/26/2013 11:32 PM, Vladimir Dzhuvinov / NimbusDS wrote: >> Hi Justin, >> >> >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2 >> >> Error code invalid_client_id obsolete? >> >> This is sent if the client_id in the posted object doesn't match the one >> referenced by the registration_client_uri and registration_access_token. >> I should add text to clarify that. >> >> How about removing the requirement to have client_id in the PUT body of >> client update requests? The ID can be derived from the registration URL >> and servers will certainly have to support that in order to process >> client delete requests. That way the invalid_client_id error code will >> no longer be needed, and we can simply return HTTP status 404, as a >> RESTful API would do. >> >> Vladimir >> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
