Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The

Mike Jones <> Wed, 25 January 2012 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2F3121F847B; Tue, 24 Jan 2012 16:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.781
X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TVV73AkIrWQ3; Tue, 24 Jan 2012 16:52:30 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9794521F8478; Tue, 24 Jan 2012 16:52:29 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Wed, 25 Jan 2012 00:52:28 +0000
Received: from mail72-db3 (localhost []) by (Postfix) with ESMTP id 78C4922024D; Wed, 25 Jan 2012 00:52:28 +0000 (UTC)
X-SpamScore: -40
X-BigFish: VS-40(zz9371I148cM542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail72-db3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail72-db3 (localhost.localdomain []) by mail72-db3 (MessageSwitch) id 1327452746637940_8243; Wed, 25 Jan 2012 00:52:26 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 8E1DF420048; Wed, 25 Jan 2012 00:52:26 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 25 Jan 2012 00:52:26 +0000
Received: from ([]) by ([]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 16:52:25 -0800
From: Mike Jones <>
To: "" <>
Thread-Topic: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
Thread-Index: AQHM2vhYmAz+4G7gQ0GW7eeS0JEwvZYcPXxg
Date: Wed, 25 Jan 2012 00:52:24 +0000
Message-ID: <>
References: <> from "Mike Jones" at Jan 25, 12 00:03:15 am <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
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:52:31 -0000

Thanks for asking, Martin.  That's effectively what the spec does already.  It restricts the input values of these parameters to be quoted strings containing no backslashes.

As long as that syntax restriction remains in place, it wouldn't actually matter whether the BNF for "scope", "error", "error_description", and "error_uri" continues to be defined as "quoted-string", is defined as "token / quoted-string", per HTTPbis, or defined by referencing the HTTPbis "auth-param" definition and containing no parameter-specific BNF declarations.  The meaning of the spec would remain the same.

It's written the way it is, at present, because it would seem to be clearer to implementers what the restrictions are by using the "quoted-string" BNF production, rather than by imposing the restriction only in prose.  But if deleting the BNF definitions and leaving the syntax restrictions in the prose would resolve this issue for people, I'm pretty sure the working group would be fine with that, as it would be a non-normative change.

				Best wishes,
				-- Mike

-----Original Message-----
From: Martin Rex [] 
Sent: Tuesday, January 24, 2012 4:29 PM
To: Mike Jones
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The

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 [...]

I'm slightly confused...

Instead of inappropriately re-specifying the WWW-Authenticate:, how about referencing the original specification an rules, and then add your desired requirements for *creation* of the contents on top of that, so that oauth-bearer can permit recipients to reject stuff that doesn't fit the additional "send-requirements" when processing the request.

I would assume that pretty much all authentication schemes will effectively require subsetting of what can be conveyed to what they can parse, and further subset this to what they can successfully verify, and reject everything else -- without having to rewrite the WWW-Authenticate syntax.