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
