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

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 25 July 2011 22:18 UTC

Return-Path: <eran@hueniverse.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 36BC711E80D8 for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 15:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
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 swo2X2Jrl+dU for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 15:18:49 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 7283611E80D7 for <oauth@ietf.org>; Mon, 25 Jul 2011 15:18:49 -0700 (PDT)
Received: (qmail 21343 invoked from network); 25 Jul 2011 22:18:49 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jul 2011 22:18:47 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 25 Jul 2011 15:18:38 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 25 Jul 2011 15:18:00 -0700
Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification
Thread-Index: AcxK8ekaMXXxmOT8RpCYHyxzRKdiaQAJqVzg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723450245F58E0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CA+k3eCT6u2Zq676b6s12A=gOFEyBSZLEqK3Erq48mUeyUW+9AQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723450245F5786@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CA+k3eCQxhi0bF+EwFYKyupMY0p2qe1a3htsHwLQKdqFkYZNQcA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723450245F5799@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CA+k3eCQDGpuiCQr5tNfdDed87Q1waqsFz+ZOpPEmASe7onFCjA@mail.gmail.com>
In-Reply-To: <CA+k3eCQDGpuiCQr5tNfdDed87Q1waqsFz+ZOpPEmASe7onFCjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 25 Jul 2011 22:18:50 -0000

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Monday, July 25, 2011 10:39 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
> identification
> 
> I'm asking from both an implementation perspective as well as the spec
> perspective.
> 
> On the spec side, draft-ietf-oauth-assertions will deal with client_id and
> while it's currently required I'd guess it will become optional or even
> forbidden.

Can't help with this one.

> On the implementation side, let me make sure I understand.  Clients without
> a secret must present client_id on token endpoint requests and
> must use only that method of identifying themselves?   HTTP Basic and
> other means of client authentication are reserved for clients that actually
> have some secret to authenticate with?

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.

EHL

> 
> 
> On Mon, Jul 25, 2011 at 10:50 AM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> > It shouldn't. You are still allowed to reuse client_id outside the specific
> password credentials use case. Just make sure the way the parameter is
> defined in v2 is consistent.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> >> Sent: Monday, July 25, 2011 9:28 AM
> >> To: Eran Hammer-Lahav
> >> Cc: oauth
> >> Subject: Re: [OAUTH-WG] treatment of client_id for authentication and
> >> identification
> >>
> >> How should HTTP Basic be used for a client not in possession of a
> >> client secret?
> >>
> >>
> >>
> >> On Mon, Jul 25, 2011 at 10:25 AM, Eran Hammer-Lahav
> >> <eran@hueniverse.com> wrote:
> >> > client_id is only required on the authorization endpoint, not the
> >> > token
> >> endpoint. -18 cleaned up how the document talked about client
> >> authentication in general. So you should remove client_id from your
> >> draft and instead mention client authentication (if appropriate).
> >> >
> >> > EHL
> >> >
> >> >> -----Original Message-----
> >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> >> Behalf Of Brian Campbell
> >> >> Sent: Monday, July 25, 2011 7:02 AM
> >> >> To: oauth
> >> >> Subject: [OAUTH-WG] treatment of client_id for authentication and
> >> >> identification
> >> >>
> >> >> I need to revisit a question that came up about two months ago.  I
> >> >> thought I had a clear understanding of when client_id was and
> >> >> wasn't included in access token requests but drafts 18/19 seemed
> >> >> to have changed things (or my understanding of 16 was wrong).
> >> >>
> >> >>
> >> >> The question is, when is client_id a required parameter on
> >> >> requests to the token endpoint and when can/should it be omitted?
> >> >>
> >> >> In -16 I was under the impression that client_id was always to be
> >> >> included even when using HTTP Basic or other means of
> authentication.
> >> >> See http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1
> >> >> and
> >> >> http://www.ietf.org/mail-archive/web/oauth/current/msg06328.html
> for example.
> >> >>
> >> >> But the text and examples in -18/-19 would suggest that client_id
> >> >> is to be omitted when using HTTP Basic.  Text in
> >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-2.4.1
> >> >> and example in
> >> >> http://tools.ietf.org/html/draft-ietf-oauth-v2-19#section-4.1.3
> >> >>
> >> >> I don't have a strong preference for either direction but do feel
> >> >> it needs to be more explicitly spelled out.  Scenarios that should
> >> >> be accounted for are, for both clients in possession of a client
> >> >> password and clients without, using client_id/client_secret, using
> >> >> HTTP Basic and using other means of authentication/identification.
> >> >> _______________________________________________
> >> >> OAuth mailing list
> >> >> OAuth@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/oauth
> >> >
> >