[OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?

Julian Reschke <julian.reschke@gmx.de> Mon, 19 December 2011 10:37 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAB21F8B50 for <oauth@ietfa.amsl.com>; Mon, 19 Dec 2011 02:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.199
X-Spam-Status: No, score=-105.199 tagged_above=-999 required=5 tests=[AWL=-2.600, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lf8A4bJRyGWL for <oauth@ietfa.amsl.com>; Mon, 19 Dec 2011 02:37:45 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net []) by ietfa.amsl.com (Postfix) with SMTP id BD42421F8B46 for <oauth@ietf.org>; Mon, 19 Dec 2011 02:37:44 -0800 (PST)
Received: (qmail invoked by alias); 19 Dec 2011 10:37:43 -0000
Received: from p3EE2691F.dip.t-dialin.net (EHLO []) [] by mail.gmx.net (mp056) with SMTP; 19 Dec 2011 11:37:43 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19R7Kg+gqlRSHQUdXUr5pZmkB8yhVN4PxnzUWxXpd J5mpzp1Sf4emYc
Message-ID: <4EEF13F1.7030409@gmx.de>
Date: Mon, 19 Dec 2011 11:37:37 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435F763122@TK5EX14MBXC283.redmond.corp.microsoft.com> <F6FCE30E-20FE-4FCD-AC31-AB227A42F2D2@mnot.net> <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739435F772D1D@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: Mark Nottingham <mnot@mnot.net>, Barry Leiba <barryleiba@computer.org>, OAuth WG <oauth@ietf.org>
Subject: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
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: Mon, 19 Dec 2011 10:37:46 -0000

On 2011-12-19 02:00, Mike Jones wrote:
> ...
> I understand and agree with your desire to promote code reuse.  You cite HTTPbis P7 2.3.1 to support adding a requirement for supporting token serialization in addition to quoted-string serialization for all parameters.  I believe that the relevant text there is:
>        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.
>        Note: the fact that the value syntax for the "realm" parameter is
>        restricted to quoted-string was a bad design choice not to be
>        repeated for new parameters.
> First, it's my understanding that this text was added between -16 and -17 explicitly to try to force a change the definitions used in the Bearer spec.  While this seems heavy-handed, be that as it may.   Assuming the specification remains as-is, I think there are two code reusability cases to consider:
> ...

The text change was caused by both the early interactions with OAuth 
(mainly thanks to James), and the fact that we see that was defined for 
Realm isn't implemented in practice 

(Note: we had a working feedback loop between WG's here; that's a feature)

If you disagree with what HTTPbis P7 now says than you really really 
ought to come over to the HTTPbis WG's mailing list (*) and argue your 

(*) Similarly to how I'm arguing my point over here.

> Recipient Case:  Recipients are able to use code capable of parsing both token and quoted-string syntax to parse fields that may only contain quoted string syntax.  Thus, the rationale for this requirement given in P7 is actually incorrect; recipients *can* use a generic parser that applies to all authentication schemes.  (Perhaps P7 should be corrected?)  There is no code-reuse problem for recipients.

Yes, there is. As the test case above shows, all UA recipients accept 
both forms; none of them rejects the token syntax. This is a problem as 
people frequently do not code against specs but just do "what works".

I'm pretty sure that changing a UA's behavior here would cause breakage 
in practice.

> Producer Case:  I will grant that it is possible for generic parameter producer code to exist that does not give the caller control over how the parameter is serialized.  If such code is used, it would be possible for a parameter value such as "xyz" to be erroneously serialized as xyz, thus creating an interoperability problem.  Note however, that serialization of the HTTP-defined realm parameter MUST occur using quoted-string serialization.  Thus, in practice, it would seem that generic frameworks still need to enable callers to control the serialization formats of specific parameters.  Hence, I doubt that this problem-in-theory is actually a problem-in-practice.  I'd be interested in data points from the working group about whether HTTP frameworks they use would have his problem in practice or not.
> It seems that there are two possible resolutions to this issue:
> 1.  Change the spec to allow both quoted-string and token serialization for these parameters.
> 2.  Leave the specification as-is.
> ...

3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined 
in HTTPbis. Just state the names of the parameters, their syntax *after* 
parsing and their semantics.

Best regards, Julian