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

"Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com> Thu, 18 August 2011 20:44 UTC

Return-Path: <huilan.lu@alcatel-lucent.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 AE40B11E8095 for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 13:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrestpWul9RY for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 13:44:22 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0A76E11E8091 for <oauth@ietf.org>; Thu, 18 Aug 2011 13:44:21 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p7IKj8Gj022493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Aug 2011 15:45:09 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p7IKj8VU020321 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 18 Aug 2011 15:45:08 -0500
Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.135]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 18 Aug 2011 15:45:08 -0500
From: "Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com>
To: 'Eran Hammer-Lahav' <eran@hueniverse.com>, Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 18 Aug 2011 15:45:08 -0500
Thread-Topic: [OAUTH-WG] treatment of client_id for authentication and identification
Thread-Index: AcxNWiAmwaoXWhpRRLSIm3Z69CEQXANudKkQALSSvmA=
Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F058F244272@USNAVSXCHMBSB3.ndc.alcatel-lucent.com>
References: <4E317125.7080006@lodderstedt.net> <CA56CA21.1758B%eran@hueniverse.com> <CA+k3eCTguAGGC1xGuuA0Z2sRu7MNCdtsUnb-3V9vmz4CFwxBYw@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234502498CDD9@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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: Thu, 18 Aug 2011 20:44:22 -0000

Eran Hammer-Lahav wrote:
> Added to 2.4.1:
> 
> client_secret
>                 REQUIRED. The client secret. The client MAY omit the parameter if the
> client secret
>                 is an empty string.

I would suggest rewording the above as follows:
client_secret 
	REQUIRED unless it is an empty string. The client secret.

> Added to 3.2.1:
> 
>             A public client that was not issued a client password MAY use the
>             'client_id' request parameter to identify itself when sending
>             requests to the token endpoint.

It is difficult to parse the last sentence of 3.2.1: "The security ramifications of allowing unauthenticated access by public clients to the token endpoint MUST be considered, as well as the issuance of refresh tokens to public clients, their scope, and lifetime."

I think it should be rewritten and reference relevant parts of security considerations.

Huilan