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

[Eran Hammer-Lahav <[e-mail]>]

-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



From: Torsten Lodderstedt <[e-mail]<mailto:[e-mail]>>
Date: Thu, 28 Jul 2011 07:24:37 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: Brian Campbell <[e-mail]<mailto:[e-mail]>>, oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

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

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

regards,
Torsten.

Am 27.07.2011 18:45, schrieb Eran Hammer-Lahav:
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 <[e-mail]<mailto:[e-mail]>>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <[e-mail]<mailto:[e-mail]>>
Cc: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>, oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

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:
I think that would be helpful, thanks.


On Wed, Jul 27, 2011 at 12:43 PM, Eran Hammer-Lahav<[e-mail]<mailto:[e-mail]>>  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