Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE521F8AFF for ; Wed, 27 Jul 2011 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjRdOsNxqHcW for ; Wed, 27 Jul 2011 09:09:18 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 6A38521F8B11 for ; Wed, 27 Jul 2011 09:09:18 -0700 (PDT) Received: (qmail 6498 invoked from network); 27 Jul 2011 16:09:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jul 2011 16:09:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 27 Jul 2011 09:09:10 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Wed, 27 Jul 2011 09:08:59 -0700 Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification Thread-Index: AcxMd4R6pcBSZpDhQ16BrrauZTkC4Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA55845717485eranhueniversecom_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] treatment of client_id for authentication and identification X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 16:09:19 -0000 --_000_CA55845717485eranhueniversecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The way I've set it up in =9618 is that the client_id parameter in the auth= orization 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 wh= en Basic is not available. So the idea is that the only place you should be using client_id is with th= e authorization endpoint to reference the client registration information (= needed to lookup the redirection URI). I have argued in the past that a fut= ure extension to remove the need to register clients should make this param= eter optional but that's outside our current scope. The token endpoint performs client authentication instead of "client identi= fication" using the client identifier as username. Hope this helps. EHL From: Brian Campbell > Date: Wed, 27 Jul 2011 04:32:42 -0700 To: Eran Hammer-lahav > Cc: oauth > Subject: Re: [OAUTH-WG] treatment of client_id for authentication and ident= ification 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 > wrote: Not exactly. The current setup was pretty stable up to =9615. In =9616 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 =9617 I reverted back to the =9615 approach. What makes this stand out in =9620 is that all the examples now use HTTP Ba= sic 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 muc= h different from =9615 on. Client authentication is still performed the same way, and the role of client_id is just as an alternative to using HTTP Basi= c 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 > Date: Tue, 26 Jul 2011 10:16:21 -0700 To: Eran Hammer-lahav > Cc: oauth > 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 > 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. --_000_CA55845717485eranhueniversecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The way I've set it up in =9618= is that the client_id parameter in the authorization endpoint is used to i= dentify the client registration record. The identifier is described in sect= ion 2.3. Then in section 2.4.1 the parameter is "extended" f= or 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 t= he client registration information (needed to lookup the redirection URI). = I have argued in the past that a future extension to remove the need to reg= ister clients should make this parameter optional but that's outside our cu= rrent scope.

The token endpoint performs client au= thentication instead of "client identification" using the client = identifier as username.

Hope this helps.

EHL


From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 04:32:42 -0700
To: Eran Hammer-lahav <eran@hueniverse.com>
Cc: oauth <oauth@i= etf.org>
Subject: Re: [O= AUTH-WG] treatment of client_id for authentication and identification

Okay, looking at some of those drafts again, I see that now. Exc= ept
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.&n= bsp; I'd propose some
text but I'm still not fully sure I un= derstand what is intended.

If a client doesn't hav= e a secret, is client_id a SHOULD NOT, a MUST
NOT or OPTIONAL to = be included on token endpoint requests?

Here's a s= pecific question/example to illustrate my continued
confusion - i= t would seem like the majority of clients that would use
the Reso= urce Owner Password Credentials grant (although 4.3.2 shows
the u= se of HTTP Basic) would be "public" clients.  How is it= expected
that such clients Identify themselves to the AS? &= nbsp;The client identity,
even if not something that can be stron= gly relied on, is useful for
things like presenting a list of acc= ess grants to the user for
revocation.

<= br>



On Tue, Jul = 26, 2011 at 12:17 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Not exactly.
The current setup wa= s pretty stable up to =9615. In =9616 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 =9617 I reverted back to the = =9615
approach.
What makes this stand out in =9620 is= that all the examples now use HTTP Basic
instead of the paramet= ers (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 =9615 on. Client authentication is still performed the sam= e
way, and the role of client_id is just as an alternative to us= ing HTTP Basic
on the token endpoint.
I think the cur= rent text is sufficient, but if you want to provide specific
add= itions I'm open to it.
EHL
From: Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com= >
Date: Tue, 26 Jul 2011 10:16:21 -0700
To: Eran H= ammer-lahav <eran@hueniverse.com<= /a>>
Subject: Re: [OAUTH-WG] treatment of client_id fo= r 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 f= eel it's wroth
mentioning that it's likely an incompatible one.<= /div>
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 <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com>
wrote:

The client_id is currently only defined = for password authentication on the
token endpoint. If you are us= ing Basic or any other form of authentication
(or no authenticat= ion at all), you are not going to use the client_id
parameter.


--_000_CA55845717485eranhueniversecom_--