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

[Torsten Lodderstedt <[e-mail]>]

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
>
> From: Torsten Lodderstedt <[e-mail] 
> <mailto:[e-mail]>>
> Date: Wed, 27 Jul 2011 10:38:36 -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
>
>     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]://www.ietf.org/mailman/listinfo/oauth
>