IETF Logo Mail Archive

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

Mike Jones <Michael.Jones@microsoft.com> Thu, 20 October 2011 15:33 UTC

Return-Path: <Michael.Jones@microsoft.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 E465E21F8C2D for <oauth@ietfa.amsl.com>; Thu, 20 Oct 2011 08:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.098
X-Spam-Level:
X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ZRGaOH1ubj7T for <oauth@ietfa.amsl.com>; Thu, 20 Oct 2011 08:33:33 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 648E621F8C1E for <oauth@ietf.org>; Thu, 20 Oct 2011 08:33:33 -0700 (PDT)
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Oct 2011 08:33:33 -0700
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.243]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0339.002; Thu, 20 Oct 2011 08:33:32 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Julian Reschke <julian.reschke@gmx.de>
Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10
Thread-Index: AcyOuBvrce+R9JZJS5GdKjqOZuv3GwAekJcAAA6gPVD//5G+AIAAdPAw//+S9AD///kYEA==
Date: Thu, 20 Oct 2011 15:33:32 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435C24D2C4@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435C24B1CA@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FC9FA.8030001@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CAE6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FCFA4.7050706@gmx.de> <4E1F6AAD24975D4BA5B16804296739435C24CBB6@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E9FD642.9070100@gmx.de>
In-Reply-To: <4E9FD642.9070100@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10
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, 20 Oct 2011 15:33:34 -0000

By design, implementations can use existing quoted-string parsers, as these accept and correctly process all legal scope values.

The spec is silent on what to do with illegal values, such as those containing \ or those not surrounded by ".  Conforming implementations will not produce such values, and so there's no actual problem in practice, whether you use an off-the-shelf parameter parser or one specific to the Bearer scheme.

Thanks for sweating the details, by the way.  The spec is better for it.

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Thursday, October 20, 2011 1:05 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -10

On 2011-10-20 09:41, Mike Jones wrote:
> Your proposed wording for 2.4 misses the point:  \ MUST NOT occur at all in the input string.  No quoting may occur.
 > ...

No, it doesn't miss the point.

You need to tell implementers whether they can use a quoted-string processor. Those processors will accept all the values you want to support, plus values that contain "\c" (representing "c"). Is this ok, or are recipients supposed to reject these values?


Furthermore, it's not clear what recipients are supposed to do with values that are not quoted, for instance for scope. The ABNF makes them illegal, but I promise you that many recipients will accept them nevertheless (unless you manage them to become draconian using a very good test suite).

See <http://greenbytes.de/tech/tc/httpauth/#simplebasictok> for a test case checking this for the realm parameter. It's already bad for many existing headers, please let's do things right with new ones.

Best regards, Julian

v2.23.0 | Report a Bug | By Email