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 <> Wed, 25 January 2012 00:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14EAE21F861C for <>; Tue, 24 Jan 2012 16:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.482
X-Spam-Status: No, score=-103.482 tagged_above=-999 required=5 tests=[AWL=-0.883, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q75fl9iPmgZS for <>; Tue, 24 Jan 2012 16:19:27 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 9311E21F862D for <>; Tue, 24 Jan 2012 16:19:26 -0800 (PST)
Received: (qmail invoked by alias); 25 Jan 2012 00:19:25 -0000
Received: from (EHLO []) [] by (mp027) with SMTP; 25 Jan 2012 01:19:25 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+8EXdxkGm8eWzdgG72aTFQQKnIszhaoyp6NWIqJE O/qELnxkCapN9G
Message-ID: <>
Date: Wed, 25 Jan 2012 01:19:07 +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
To: Mike Jones <>
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: Wed, 25 Jan 2012 00:19:28 -0000

On 2012-01-25 01:03, Mike Jones wrote:
> Per the discussion at, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when producing them is as follows:
> "Once again, the current text reflects a consensus decision of the working group.  It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it."

Mike, you continue to ignore that WWW-Authenticate needs to be processed 
by generic parsers, as a single instance can contain challenges for 
different schemes.

If you disagree with the text below:

    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.

(which is from the text defining the registry you are using), then 
please come over to the HTTPbis WG and ask for a change. It's 

> Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to a subset of the syntax allowed by HTTPbis.  No non-standard code is needed to use parameters in the manner described in the Bearer spec.

That is not true. Using standard components will cause recipients to 
accept invalid field instances, which *is* an interoperability problem.

This has happened before: RFC 2617 states that the realm parameter needs 
to be quoted, but we see that all browsers accept the token form as well 
(<>). That's not a 
surprise because it's the natural thing to do with a generic parser.

Please don't add to the mess. In particular when there really is no 
reason to do so. All I heard from you is: "we prefer it that way". I'm 
sorry, but that's not sufficient.

> ...

Best regards, Julian