Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Sat, 22 Jun 2013 00:32:17 -0700

I have three more notes after going through the version 12 draft:

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-3.1

Missing comma in the JSON example after "redirect_uris".

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-4.4

Header "Accept: application/json" not required.

http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-12#section-5.2

Error code invalid_client_id obsolete?

Thanks,

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

---

From: Justin Richer <[email-masked]>
Date: Mon, 24 Jun 2013 09:47:57 -0400

> Missing comma in the JSON example after "redirect_uris".

You're right -- thought I fixed this one already, guess I missed it again.

> Header "Accept: application/json" not required.

Good point, copypaste mistake.

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

Thanks for the careful review,

   -- Justin

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Vladimir Dzhuvinov / NimbusDS <[email-masked]>
Date: Thu, 27 Jun 2013 06:32:38 +0300

Hi Justin,

> 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 27 Jun 2013 10:30:52 -0400

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 27 Jun 2013 14:58:05 +0000

I believe that we should leave it as-is.  For many implementations, it’s important to communicate the client_id value.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, June 27, 2013 7:31 AM
To: Vladimir Dzhuvinov / NimbusDS
Cc: [email-masked]
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:

   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.

 -- Justin

Hi Justin,

RESTful API would do.

Vladimir

---

From: Justin Richer <[email-masked]>
Date: Thu, 27 Jun 2013 15:14:30 -0400

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-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Richer
> *Sent:* Thursday, June 27, 2013 7:31 AM
> *To:* Vladimir Dzhuvinov / NimbusDS
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-12.txt
>
> 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.
>
> from the data model seems to be asking for trouble. However, we 
> already preclude people from sending back some other fields:
>
> 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.
>

---

From: John Bradley <[email-masked]>
Date: Thu, 27 Jun 2013 15:30:58 -0400

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-masked]> wrote:

> That's a very good point -- the extra layer of sanity checking is valuable in many cases. 
> 
>  -- Justin
> 
>>    in Client Information Response (Section 5.1).
>>

---

From: Vladimir Dzhuvinov / NimbusDS <[email-masked]>
Date: Fri, 28 Jun 2013 10:52:01 +0300

Hi guys,

On Thu, 2013-06-27 at 15:30 -0400, John Bradley wrote:
> It is a useful debug and sanity check.  Leave it in for now

> John B.

If we look at the client delete request, it relies solely on the request
URL and / or the access token to identify the client, and the client_id
is not duplicated on the body:

DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483

Servers that handle dynamic registration will still have to implement a
reliable lookup method that is based on the URL / access token anyway,
which becomes the lowest common denominator, and from that perspective
encoding the client_id into the request body does seem redundant. This
is what I ended up doing in the NimbusDS OAuth 2.0/ OIDC SDK.

As a developer I also like the simplicity of not having to deal with an
extra parameter + error, which is perceived to have some debugging value
to server implementations, but is otherwise an extra bit of spec and
code that client-side developers will have to live with. Which brings me
to my final argument for removing the client_id and the
invalid_client_id error, the principle that seems to be established here
in regard to OAuth 2.0 and OIDC, to push complexity away from clients
and to servers.

Thanks,

Vladimir
> > > I believe that we should leave it as-is.  For many
> > > implementations, it’s important to communicate the client_id
> > > value.
> > > 
> > >  
> > > 
> > >                                                             --
> > > Mike
> > > 
> > >  
> > > 
> > > 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:
> > > 
> > > 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. 
> > >

---

From: Vladimir Dzhuvinov / NimbusDS <[email-masked]>
Date: Fri, 28 Jun 2013 10:58:25 +0300

> Do we want this change, or do we want to leave it as it is?

Requiring only the client metadata needs to be included in the update
request will definitely simplify the spec and implementations. I like
that.

What is the argument for including client_secret in the request? 

Vladimir

---

From: Justin Richer <[email-masked]>
Date: Fri, 28 Jun 2013 09:18:46 -0400

> What is the argument for including client_secret in the request?

The argument (and initial design of this) was based around what we saw 
as the data model on the client side and how we think clients are 
generally going to store things. What I've seen (and what I've 
implemented) splits things into two parts: the client information, and 
the registration API information. The former contains client_id, 
client_secret, client_name, redirect_uris, and all that -- everything 
you need to act like an OAuth client. The latter contains the 
registration_access_token, registration_client_uri, and the 
issued/expires timestamps -- everything you need to access the 
registration API. By taking the information in the former and turning 
into a JSON object you can call the update part of the API.

  -- Justin