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<http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#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
