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

[Torsten Lodderstedt <[e-mail]>]

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.

>
> Hope this helps.
>
> EHL
>
>
> From: Brian Campbell <[e-mail] 
> <mailto:[e-mail]>>
> Date: Wed, 27 Jul 2011 04:32:42 -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
>
>     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
>     <[e-mail] <mailto:[e-mail]>> 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.
>         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.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth