Re: [OAUTH-WG] treatment of client_id for authentication and identification
Brian Campbell <bcampbell@pingidentity.com> Wed, 27 July 2011 17:47 UTC
Return-Path: <bcampbell@pingidentity.com>
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 5A91421F8AD6 for <oauth@ietfa.amsl.com>; Wed, 27 Jul 2011 10:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.955
X-Spam-Level:
X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 a9N213TnHbEP for <oauth@ietfa.amsl.com>; Wed, 27 Jul 2011 10:47:13 -0700 (PDT)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0B21F873E for <oauth@ietf.org>; Wed, 27 Jul 2011 10:47:09 -0700 (PDT)
Received: from mail-qy0-f182.google.com ([209.85.216.182]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTjBPHXnZr5P5TtaiQStYPuFIffbL0OTU@postini.com; Wed, 27 Jul 2011 10:47:10 PDT
Received: by mail-qy0-f182.google.com with SMTP id 38so1149801qyk.20 for <oauth@ietf.org>; Wed, 27 Jul 2011 10:47:09 -0700 (PDT)
Received: by 10.224.211.197 with SMTP id gp5mr60136qab.293.1311788829172; Wed, 27 Jul 2011 10:47:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.11.68 with HTTP; Wed, 27 Jul 2011 10:46:39 -0700 (PDT)
In-Reply-To: <4E304D1C.3020407@lodderstedt.net>
References: <CA558457.17485%eran@hueniverse.com> <4E304D1C.3020407@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 11:46:39 -0600
Message-ID: <CA+k3eCQYsqS=z6vd-FOJhdS22cFhpNfa7qeV313si=6pN+4ScA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: oauth <oauth@ietf.org>
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 <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 17:47:14 -0000
That was more or less what I was trying to say as well. There are times when "client identification" is needed at the token endpoint and it's not clear if or how, short of actual authentication, the current spec allows for it. On Wed, Jul 27, 2011 at 11:38 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > 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 <bcampbell@pingidentity.com> > Date: Wed, 27 Jul 2011 04:32:42 -0700 > To: Eran Hammer-lahav <eran@hueniverse.com> > Cc: oauth <oauth@ietf.org> > 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 <eran@hueniverse.com> > 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 <bcampbell@pingidentity.com> > Date: Tue, 26 Jul 2011 10:16:21 -0700 > To: Eran Hammer-lahav <eran@hueniverse.com> > Cc: oauth <oauth@ietf.org> > 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 <eran@hueniverse.com> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] treatment of client_id for authenticat… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Torsten Lodderstedt
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Torsten Lodderstedt
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Torsten Lodderstedt
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Torsten Lodderstedt
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Torsten Lodderstedt
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav
- Re: [OAUTH-WG] treatment of client_id for authent… Brian Campbell
- Re: [OAUTH-WG] treatment of client_id for authent… Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] treatment of client_id for authent… Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] treatment of client_id for authent… Richer, Justin P.
- Re: [OAUTH-WG] treatment of client_id for authent… Eran Hammer-Lahav