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
<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
