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

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

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 <[e-mail]<mailto:[e-mail]>>
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran Hammer-lahav <[e-mail]<mailto:[e-mail]>>
Cc: oauth <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification

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.

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

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.