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:
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 <tors...@lodderstedt.net
<mailto:tors...@lodderstedt.net>>
Date: Wed, 27 Jul 2011 15:21:16 -0700
To: Brian Campbell <bcampb...@pingidentity.com
<mailto:bcampb...@pingidentity.com>>
Cc: Eran Hammer-lahav <e...@hueniverse.com
<mailto:e...@hueniverse.com>>, oauth <oauth@ietf.org
<mailto:oauth@ietf.org>>
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...@hueniverse.com
<mailto:e...@hueniverse.com>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
