Subject: [OAUTH-WG] treatment of client_id for authentication and identification

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Jul 2011 08:02:01 -0600

I need to revisit a question that came up about two months ago.  I
thought I had a clear understanding of when client_id was and wasn't
included in access token requests but drafts 18/19 seemed to have
changed things (or my understanding of 16 was wrong).

The question is, when is client_id a required parameter on requests to
the token endpoint and when can/should it be omitted?

In -16 I was under the impression that client_id was always to be
included even when using HTTP Basic or other means of authentication.
See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1 and
http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html for
example.

But the text and examples in -18/-19 would suggest that client_id is
to be omitted when using HTTP Basic.  Text in
http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and
example in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3

I don't have a strong preference for either direction but do feel it
needs to be more explicitly spelled out.  Scenarios that should be
accounted for are, for both clients in possession of a client password
and clients without, using client_id/client_secret, using  HTTP Basic
and using other means of authentication/identification.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 09:25:01 -0700

client_id is only required on the authorization endpoint, not the token endpoint. -18 cleaned up how the document talked about client authentication in general. So you should remove client_id from your draft and instead mention client authentication (if appropriate).

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Campbell
> Sent: Monday, July 25, 2011 7:02 AM
> To: oauth
> Subject: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> I need to revisit a question that came up about two months ago.  I thought I
> had a clear understanding of when client_id was and wasn't included in
> access token requests but drafts 18/19 seemed to have changed things (or
> my understanding of 16 was wrong).
> 
> 
> The question is, when is client_id a required parameter on requests to the
> token endpoint and when can/should it be omitted?
> 
> In -16 I was under the impression that client_id was always to be included
> even when using HTTP Basic or other means of authentication.
> But the text and examples in -18/-19 would suggest that client_id is to be
> omitted when using HTTP Basic.  Text in
> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1 and example
> in http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3
> 
> I don't have a strong preference for either direction but do feel it needs to
> be more explicitly spelled out.  Scenarios that should be accounted for are,
> for both clients in possession of a client password and clients without, using
> client_id/client_secret, using  HTTP Basic and using other means of
> authentication/identification.
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Jul 2011 10:28:23 -0600

How should HTTP Basic be used for a client not in possession of a
client secret?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 09:50:35 -0700

It shouldn't. You are still allowed to reuse client_id outside the specific password credentials use case. Just make sure the way the parameter is defined in v2 is consistent.

EHL

> From: Brian Campbell [mailto:[email-masked]]
> Sent: Monday, July 25, 2011 9:28 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> How should HTTP Basic be used for a client not in possession of a client
> secret?
> 
> 
> 
> > client_id is only required on the authorization endpoint, not the token
> endpoint. -18 cleaned up how the document talked about client
> authentication in general. So you should remove client_id from your draft
> and instead mention client authentication (if appropriate).
> >
> > EHL
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Brian Campbell
> >> The question is, when is client_id a required parameter on requests
> >> to the token endpoint and when can/should it be omitted?
> >>
> >> example in
> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3
> >>
> >> accounted for are, for both clients in possession of a client
> >> password and clients without, using client_id/client_secret, using
> >> HTTP Basic and using other means of authentication/identification.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 25 Jul 2011 11:39:24 -0600

I'm asking from both an implementation perspective as well as the spec
perspective.

On the spec side, draft-ietf-oauth-assertions will deal with client_id
and while it's currently required I'd guess it will become optional or
even forbidden.

On the implementation side, let me make sure I understand.  Clients
without a secret must present client_id on token endpoint requests and
must use only that method of identifying themselves?   HTTP Basic and
other means of client authentication are reserved for clients that
actually have some secret to authenticate with?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 25 Jul 2011 15:18:00 -0700

> Sent: Monday, July 25, 2011 10:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> On the spec side, draft-ietf-oauth-assertions will deal with client_id and
> while it's currently required I'd guess it will become optional or even
> forbidden.

Can't help with this one.

> On the implementation side, let me make sure I understand.  Clients without
> a secret must present client_id on token endpoint requests and
> other means of client authentication are reserved for clients that actually
> have some secret to authenticate with?

The client_id is currently only defined for password authentication on the token endpoint. If you are using Basic or any other form of authentication (or no authentication at all), you are not going to use the client_id parameter.

EHL

> > It shouldn't. You are still allowed to reuse client_id outside the specific
> password credentials use case. Just make sure the way the parameter is
> defined in v2 is consistent.
> >
> > EHL
> >
> >> authentication in general. So you should remove client_id from your
> >> draft and instead mention client authentication (if appropriate).
> >> >
> >> > EHL
> >> >
> >> >> thought I had a clear understanding of when client_id was and
> >> >> wasn't included in access token requests but drafts 18/19 seemed
> >> >> to have changed things (or my understanding of 16 was wrong).
> >> >>
> >> >>
> >> >> The question is, when is client_id a required parameter on
> >> >> requests to the token endpoint and when can/should it be omitted?
> >> >>
> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html
> for example.
> >> >>
> >> >> But the text and examples in -18/-19 would suggest that client_id
> >> >> is to be omitted when using HTTP Basic.  Text in
> >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1
> >> >> and example in
> >> >> I don't have a strong preference for either direction but do feel
> >> >> it needs to be more explicitly spelled out.  Scenarios that should
> >> >> be accounted for are, for both clients in possession of a client

---

From: Brian Campbell <[email-masked]>
Date: Tue, 26 Jul 2011 11:16:21 -0600

I'm probably somewhat biased by having read previous version of the
spec, previous WG list discussions, and my current AS implementation
(which expects client_id) but this seems like a fairly big departure
from what was in -16.  I'm okay with the change but feel it's wroth
mentioning that it's likely an incompatible one.

That aside, I feel like it could use some more explanation in
draft-ietf-oauth-v2 because, at least to me and hence my question, it
wasn't entirely clear how client_id should be used for those cases.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 26 Jul 2011 11:17:59 -0700

Not exactly.

The current setup was pretty stable up to –15. In –16 I tried to clean it up by moving the parameter into each token endpoint type definition. That didn't work and was more confusing so in –17 I reverted back to the –15 approach.

What makes this stand out in –20 is that all the examples now use HTTP Basic instead of the parameters (since we decided to make them NOT RECOMMENDED). So it feels sudden that client_id is gone, but none of this is actually much different from –15 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basic on the token endpoint.

I think the current text is sufficient, but if you want to provide specific additions I'm open to it.

EHL

From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2011 05:32:42 -0600

Okay, looking at some of those drafts again, I see that now. Except
for -16 they are all pretty similar on client_id back to -10.
Apparently it was my misunderstanding.  Maybe I'm the only one who
doesn't get it but I do think it could be clearer.  I'd propose some
text but I'm still not fully sure I understand what is intended.

If a client doesn't have a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to be included on token endpoint requests?

Here's a specific question/example to illustrate my continued
confusion - it would seem like the majority of clients that would use
the Resource Owner Password Credentials grant (although 4.3.2 shows
the use of HTTP Basic) would be "public" clients.  How is it expected
that such clients Identify themselves to the AS?  The client identity,
even if not something that can be strongly relied on, is useful for
things like presenting a list of access grants to the user for
revocation.

http://tools.ietf.org/html/draft-ietf-oauth-v2-20#section-4.3.2

On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Not exactly.
> The current setup was pretty stable up to –15. In –16 I tried to clean it up
> by moving the parameter into each token endpoint type definition. That
> didn't work and was more confusing so in –17 I reverted back to the –15
> approach.
> What makes this stand out in –20 is that all the examples now use HTTP Basic
> instead of the parameters (since we decided to make them NOT RECOMMENDED).
> So it feels sudden that client_id is gone, but none of this is actually much
> different from –15 on. Client authentication is still performed the same
> way, and the role of client_id is just as an alternative to using HTTP Basic
> on the token endpoint.
> From: Brian Campbell <[email-masked]>
> To: Eran Hammer-lahav <[email-masked]>
> Cc: oauth <[email-masked]>
> The client_id is currently only defined for password authentication on the
> token endpoint. If you are using Basic or any other form of authentication
> (or no authentication at all), you are not going to use the client_id
> parameter.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jul 2011 09:08:59 -0700

The way I've set it up in –18 is that the client_id parameter in the authorization endpoint is used to identify the client registration record. The identifier is described in section 2.3. Then in section 2.4.1 the parameter is "extended" for use with the token endpoint for client authentication when Basic is not available.

So the idea is that the only place you should be using client_id is with the authorization endpoint to reference the client registration information (needed to lookup the redirection URI). I have argued in the past that a future extension to remove the need to register clients should make this parameter optional but that's outside our current scope.

The token endpoint performs client authentication instead of "client identification" using the client identifier as username.

Hope this helps.

EHL

Date: Wed, 27 Jul 2011 04:32:42 -0700

On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Not exactly.
I think the current text is sufficient, but if you want to provide specific
additions I'm open to it.

On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>>
wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 27 Jul 2011 13:38:36 -0400

Am 27.07.2011 12:08, schrieb Eran Hammer-Lahav:
> The way I've set it up in --18 is that the client_id parameter in the 
> authorization endpoint is used to identify the client registration 
> record. The identifier is described in section 2.3. Then in section 
> 2.4.1 the parameter is "extended" for use with the token endpoint for 
> client authentication when Basic is not available.
>
> So the idea is that the only place you should be using client_id is 
> with the authorization endpoint to reference the client registration 
> information (needed to lookup the redirection URI). I have argued in 
> the past that a future extension to remove the need to register 
> clients should make this parameter optional but that's outside our 
> current scope.
>
> The token endpoint performs client authentication instead of "client 
> identification" using the client identifier as username.

It can do so for confidential clients only. What about public clients 
using e.g. the Resource Owners Password flow? I see the need to identify 
them as well. For example, if the authz server issues a refresh token to 
such a client there must be a way to relate this token to a certain 
client in order to give the user a chance to revoke this specific token.

regards,
Torsten.

> To: Eran Hammer-lahav <[email-masked] <mailto:[email-masked]>>
> Cc: oauth <[email-masked] <mailto:[email-masked]>>
>     On Tue, Jul 26, 2011 at 12:17 PM, Eran Hammer-Lahav
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Not exactly.
>         The current setup was pretty stable up to --15. In --16 I
>         tried to clean it up
>         didn't work and was more confusing so in --17 I reverted back
>         to the --15
>         approach.
>         What makes this stand out in --20 is that all the examples now
>         use HTTP Basic
>         different from --15 on. Client authentication is still
>         performed the same
>         Cc: oauth <[email-masked] <mailto:[email-masked]>>
>         On Mon, Jul 25, 2011 at 4:18 PM, Eran Hammer-Lahav
>         <[email-masked] <mailto:[email-masked]>>
>         wrote:
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jul 2011 10:45:01 -0700

You just issue them a set of password credentials (which can include an empty or fixed password). There is nothing preventing you from doing that and once you do, the spec requires them to use those credentials.

EHL

From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Date: Wed, 27 Jul 2011 10:38:36 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

It can do so for confidential clients only. What about public clients using e.g. the Resource Owners Password flow? I see the need to identify them as well. For example, if the authz server issues a refresh token to such a client there must be a way to relate this token to a certain client in order to give the user a chance to revoke this specific token.

regards,
Torsten.

Hope this helps.

EHL

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

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2011 11:46:39 -0600

That was more or less what I was trying to say as well.  There are
times when "client identification" is needed at the token endpoint and
it's not clear if or how, short of actual authentication, the current
spec allows for it.

On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> The way I've set it up in –18 is that the client_id parameter in the
> authorization endpoint is used to identify the client registration record.
> The identifier is described in section 2.3. Then in section 2.4.1 the
> parameter is "extended" for use with the token endpoint for client
> authentication when Basic is not available.
> So the idea is that the only place you should be using client_id is with the
> authorization endpoint to reference the client registration information
> (needed to lookup the redirection URI). I have argued in the past that a
> future extension to remove the need to register clients should make this
> parameter optional but that's outside our current scope.
> It can do so for confidential clients only. What about public clients using
> e.g. the Resource Owners Password flow? I see the need to identify them as
> well. For example, if the authz server issues a refresh token to such a
> client there must be a way to relate this token to a certain client in order
> to give the user a chance to revoke this specific token.
>
> regards,
> Torsten.
>
>
> Hope this helps.
> EHL
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 27 Jul 2011 14:02:18 -0400

There is no need and I don't intend to "pro-forma" issue client secrets 
just to conform to some text of the spec. I thought we are beyond that 
point.

The obvious approach would be to use the client_id the same way as it is 
used on the authz endpoint.

regards,
Torsten.

Am 27.07.2011 13:45, schrieb Eran Hammer-Lahav:
> You just issue them a set of password credentials (which can include 
> an empty or fixed password). There is nothing preventing you from 
> doing that and once you do, the spec requires them to use those 
> credentials.
>
> EHL
>
> Cc: Brian Campbell <[email-masked] 
> <mailto:[email-masked]>>, oauth <[email-masked] 
> <mailto:[email-masked]>>
>>     The way I've set it up in –18 is that the client_id parameter in
>>     the authorization endpoint is used to identify the client
>>     registration record. The identifier is described in section
>>     2.3. Then in section 2.4.1 the parameter is "extended" for use
>>     with the token endpoint for client authentication when Basic is
>>     not available.
>>
>>     So the idea is that the only place you should be using client_id
>>     is with the authorization endpoint to reference the client
>>     registration information (needed to lookup the redirection URI).
>>     I have argued in the past that a future extension to remove the
>>     need to register clients should make this parameter optional but
>>     that's outside our current scope.
>>
>>     The token endpoint performs client authentication instead of
>>     "client identification" using the client identifier as username.
>
>     It can do so for confidential clients only. What about public
>     clients using e.g. the Resource Owners Password flow? I see the
>     need to identify them as well. For example, if the authz server
>     issues a refresh token to such a client there must be a way to
>     relate this token to a certain client in order to give the user a
>     chance to revoke this specific token.
>
>     regards,
>     Torsten.
>
>>
>>     Hope this helps.
>>
>>     EHL
>>
>>
>>     [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jul 2011 11:43:57 -0700

This is the best way to keep the protocol simple and secure of the main use cases it explicitly addresses.

There is not clean way to introduce the client_id parameter at the token endpoint without making it confusing for developers. The problem is how do explain when to perform authentication and when to perform identification and the different trust levels in each. I have no interest in going down that road.

The current language allows you to do exactly what you want but issuing a set of password credentials and supporting the client_id/client_secret parameters. You should support the client sending an empty client_secret and omitting it when no secret is issued.

If you want, we can tweak section 2.4.1 to make client_secret optional if the secret is the empty string. That will give you exactly what you want without making the document any more confusing.

EHL

Date: Wed, 27 Jul 2011 11:02:18 -0700

There is no need and I don't intend to "pro-forma" issue client secrets just to conform to some text of the spec. I thought we are beyond that point.

The obvious approach would be to use the client_id the same way as it is used on the authz endpoint.

regards,
Torsten.

EHL

regards,
Torsten.

Hope this helps.

EHL

---

From: Brian Campbell <[email-masked]>
Date: Wed, 27 Jul 2011 16:17:48 -0600

I think that would be helpful, thanks.

On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>
> If you want, we can tweak section 2.4.1 to make client_secret optional if
> the secret is the empty string. That will give you exactly what you want
> without making the document any more confusing.
> EHL

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 27 Jul 2011 18:21:16 -0400

I personally think that would be more confusing than just adding the 
client_id parameter to the token endpoint request (independent of client 
authentication credentials).

Am 27.07.2011 18:17, schrieb Brian Campbell:
> On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav<[email-masked]>  wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jul 2011 15:45:18 -0700

There is not clean way of adding it.

First where? In each flow of the token endpoint or just in 3.2? Then how is it defined? Optional? Required for public clients? How does it work alongside authentication? If you use client_password or Basic then it becomes authentication but otherwise identification? What about duplication between Basic and the parameter? It also means adding a new section discussing client authentication vs identification which is currently implicit.

I strongly believe that it is better to have a simple model as the one already defined in –20 and let other use case find their way around it instead of producing a confusing document that is trying to hard to solve every possible combination.

As I said before, we can tweak the definition of client_secret to make it more esthetically pleasing (the server doesn't mind having an empty parameter included, just people), but that's as far am I'm (as wg member) willing to support, especially at this point.

EHL

From: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav<[email-masked]<mailto:[email-masked]>>  wrote:
If you want, we can tweak section 2.4.1 to make client_secret optional if
the secret is the empty string. That will give you exactly what you want
without making the document any more confusing.
EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 27 Jul 2011 15:46:34 -0700

I'll take this as –20 last call comment.

From: Brian Campbell <[email-masked]<mailto:[email-masked]>>
Date: Wed, 27 Jul 2011 15:17:48 -0700
To: Eran Hammer-lahav <[email-masked]<mailto:[email-masked]>>
Cc: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>, oauth <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 28 Jul 2011 10:24:37 -0400

the client_id parameter had been added to the token endpoint in -16. As 
far as I remember, the reason was to properly separate client 
identification and authentication in order to support further client 
authentication methods.

quote from 
"http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html":
"The goal is a cleaner protocol design. The protocol design separates 
client identification as part of the flow (URI parameter) and originator 
authentication. While the client_id parameter is required, the 
authentication can be omitted (unauthenticated access) or performed 
using other authentication mechanisms. And such mechanisms not 
neccessarily use client_id's. Moreover, the spec just says, "The 
authorization server MUST ensure the two identifiers belong to the same 
client". So the client_id's (request parameter and header) may differ. "

You removed the parameter in -17, can you please explain why?

regards,
Torsten.

Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav:
> First where? In each flow of the token endpoint or just in 3.2? Then 
> how is it defined? Optional? Required for public clients? How does it 
> work alongside authentication? If you use client_password or Basic 
> then it becomes authentication but otherwise identification? What 
> about duplication between Basic and the parameter? It also means 
> adding a new section discussing client authentication vs 
> identification which is currently implicit.
>
> I strongly believe that it is better to have a simple model as the one 
> already defined in –20 and let other use case find their way around it 
> instead of producing a confusing document that is trying to hard to 
> solve every possible combination.
>
> As I said before, we can tweak the definition of client_secret to make 
> it more esthetically pleasing (the server doesn't mind having an empty 
> parameter included, just people), but that's as far am I'm (as wg 
> member) willing to support, especially at this point.
>
> EHL
>
>
> Cc: Eran Hammer-lahav <[email-masked] 
> <mailto:[email-masked]>>, oauth <[email-masked] 
> <mailto:[email-masked]>>
>         On Wed, Jul 27, 2011 at 12:43 PM, Eran
>         Hammer-Lahav<[email-masked]
>         <mailto:[email-masked]>>  wrote:
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jul 2011 08:20:02 -0700

-16 was a failed attempt to accomplish this separation of authentication and identification. It didn't work. When working on –17 I had about 5 messages in my queue with questions and issues regarding the duplication of client identifier information between Basic and the parameter, the fact that the parameter was now required where previously it was optional or even not recommended, and overall confusion.

My goal with –16 was to simplify things without making normative changes and it didn't work. In –17 on I fixed it by reverting the change and expanding the concept of the client identifier. When I had to decide how to fix the issues introduced by this change in –16, I came up with the list of questions I asked you below and decided that it was just too complicated for practically no gain.

You are free, of course, to try and suggest alternative language. My suggestion is to simply allow client_secret to be omitted when there is no secret assigned, and I can also add a short note that public clients may use the client_id for the purpose of identification with the token endpoint. This will give full endorsement to the practice without making the rest of the protocol any more complex.

EHL

Date: Thu, 28 Jul 2011 07:24:37 -0700

the client_id parameter had been added to the token endpoint in -16. As far as I remember, the reason was to properly separate client identification and authentication in order to support further client authentication methods.

quote from "http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html"<http://www.ietf.org/mail-archive/web/oauth/current/msg06346.html>:
"The goal is a cleaner protocol design. The protocol design separates client identification as part of the flow (URI parameter) and originator authentication. While the client_id parameter is required, the authentication can be omitted (unauthenticated access) or performed using other authentication mechanisms. And such mechanisms not neccessarily use client_id's. Moreover, the spec just says, "The authorization server MUST ensure the two identifiers belong to the same client". So the client_id's (request parameter and header) may differ. "

regards,
Torsten.

EHL

---

From: Brian Campbell <[email-masked]>
Date: Thu, 28 Jul 2011 13:10:44 -0600

I would be very much in favor of that addition/clarification.

On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav <[email-masked]> wrote:
>
> [...] and I can also add a short note that public clients may use
> the client_id for the purpose of identification with the token endpoint.
> EHL
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 28 Jul 2011 15:59:19 -0400

+1

Am 28.07.2011 15:10, schrieb Brian Campbell:
> On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav<[email-masked]>  wrote:

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 28 Jul 2011 13:22:21 -0700

Perfect. I'll make this change after the last call before sending this to IETF LC.

EHL

Date: Thu, 28 Jul 2011 12:59:19 -0700

+1

On Thu, Jul 28, 2011 at 9:20 AM, Eran Hammer-Lahav<[email-masked]<mailto:[email-masked]>>  wrote:
[...] and I can also add a short note that public clients may use
the client_id for the purpose of identification with the token endpoint.
EHL