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

Brian Campbell <bcampbell@pingidentity.com> Wed, 27 July 2011 11:33 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 5F3A721F8AF6 for <oauth@ietfa.amsl.com>; Wed, 27 Jul 2011 04:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.954
X-Spam-Level:
X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=0.023, 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 1+dZ4KHHLjUq for <oauth@ietfa.amsl.com>; Wed, 27 Jul 2011 04:33:15 -0700 (PDT)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9260721F8ACE for <oauth@ietf.org>; Wed, 27 Jul 2011 04:33:13 -0700 (PDT)
Received: from mail-qy0-f173.google.com ([209.85.216.173]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTi/3eGHy2Zr2c1x7PrJmHkDVhtR1mCpb@postini.com; Wed, 27 Jul 2011 04:33:13 PDT
Received: by qyk10 with SMTP id 10so2530054qyk.11 for <oauth@ietf.org>; Wed, 27 Jul 2011 04:33:12 -0700 (PDT)
Received: by 10.224.207.193 with SMTP id fz1mr5685002qab.43.1311766392075; Wed, 27 Jul 2011 04:33:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.11.68 with HTTP; Wed, 27 Jul 2011 04:32:42 -0700 (PDT)
In-Reply-To: <CA545154.173D2%eran@hueniverse.com>
References: <CA+k3eCToGfx-O-72gg_OHqdJMTc-gdEkTZRv6vtXGZM4B=575g@mail.gmail.com> <CA545154.173D2%eran@hueniverse.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 27 Jul 2011 05:32:42 -0600
Message-ID: <CA+k3eCQUDR2HXTMqtksXyk5tCSb15wZterow6nw12BhFS0VM1w@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
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 11:33:16 -0000

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