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

Brian Campbell <bcampbell@pingidentity.com> Mon, 25 July 2011 17:39 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 04CC221F86A2 for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 10:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.95
X-Spam-Level:
X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.027, 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 L-AxaGaYx3rt for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2011 10:39:55 -0700 (PDT)
Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9721F863C for <oauth@ietf.org>; Mon, 25 Jul 2011 10:39:55 -0700 (PDT)
Received: from mail-qy0-f179.google.com ([209.85.216.179]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTi2qankZw/kbGoo9+VN9OvT29qLb1aEb@postini.com; Mon, 25 Jul 2011 10:39:55 PDT
Received: by mail-qy0-f179.google.com with SMTP id 29so3092188qyk.10 for <oauth@ietf.org>; Mon, 25 Jul 2011 10:39:54 -0700 (PDT)
Received: by 10.224.183.206 with SMTP id ch14mr2415708qab.343.1311615594182; Mon, 25 Jul 2011 10:39:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.11.68 with HTTP; Mon, 25 Jul 2011 10:39:24 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723450245F5799@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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 25 Jul 2011 11:39:24 -0600
Message-ID: <CA+k3eCQDGpuiCQr5tNfdDed87Q1waqsFz+ZOpPEmASe7onFCjA@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
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: Mon, 25 Jul 2011 17:39:56 -0000

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.

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?



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
>> >
>