Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

Julian Reschke <> Tue, 24 January 2012 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7F9111E809F for <>; Tue, 24 Jan 2012 15:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.468
X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h7lEok1Cl767 for <>; Tue, 24 Jan 2012 15:24:06 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B5CCD11E809A for <>; Tue, 24 Jan 2012 15:24:05 -0800 (PST)
Received: (qmail invoked by alias); 24 Jan 2012 23:24:04 -0000
Received: from (EHLO []) [] by (mp028) with SMTP; 25 Jan 2012 00:24:04 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+XfokYg2GXmtZex/QIvMdvr6dE14RR6CtUtd/Hzx /ySMTdF+SONJ+n
Message-ID: <>
Date: Wed, 25 Jan 2012 00:23:48 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: The IESG <>,
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jan 2012 23:24:07 -0000

On 2012-01-23 16:58, Julian Reschke wrote:
> On 2012-01-23 16:46, The IESG wrote:
>> The IESG has received a request from the Web Authorization Protocol WG
>> (oauth) to consider the following document:
>> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
>> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard
>> ...
> Please see my comments in
> <>
> which I think have not been addressed.
> ...

In an off-list conversation I heard that what I said before may not be 
as clear as it could be.


1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.

2) In the IANA considerations, it references the registration procedure 
defined in 
(now -18, but that doesn't matter here).

3) That document recommends in 

    o  The parsing of challenges and credentials is defined by this
       specification, and cannot be modified by new authentication
       schemes.  When the auth-param syntax is used, all parameters ought
       to support both token and quoted-string syntax, and syntactical
       constraints ought to be defined on the field value after parsing
       (i.e., quoted-string processing).  This is necessary so that
       recipients can use a generic parser that applies to all
       authentication schemes.

4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has 
been mentioned that it might not have ignored it if it had UPPERCASE 
requirements, but in HTTPbis we try to restrict BCP14 keywords to the 
actual protocol, not on recommendations on other specs.

5) The registration requirement for a new scheme is "IETF review", which 
RFC 5226 defines in <> as:

       IETF Review - (Formerly called "IETF Consensus" in
             [IANA-CONSIDERATIONS]) New values are assigned only through
             RFCs that have been shepherded through the IESG as AD-
             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
             intention is that the document and proposed assignment will
             be reviewed by the IESG and appropriate IETF WGs (or
             experts, if suitable working groups no longer exist) to
             ensure that the proposed assignment will not negatively
             impact interoperability or otherwise extend IETF protocols
             in an inappropriate or damaging manner.

In this case the WG exists (it's HTTPbis), and the OAuth got two reviews 
from HTTPbis pointing out the problem  -- from Mark Nottingham, the WG 
chair, and myself, one of the authors.

And yes, I believe the way OAuth defines the syntax *will* impact 

Also, I haven't seen any explanation why OAuth can not follow the 
recommendation from HTTPbis.

Hope this clarifies things,