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

Mike Jones <> Sat, 31 December 2011 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A54021F84A5 for <>; Sat, 31 Dec 2011 11:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4-Xvp7jHMo7 for <>; Sat, 31 Dec 2011 11:40:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9BA9C21F84A2 for <>; Sat, 31 Dec 2011 11:40:18 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server id; Sat, 31 Dec 2011 19:40:17 +0000
Received: from mail88-va3 (localhost []) by (Postfix) with ESMTP id 81E0470016F; Sat, 31 Dec 2011 19:40:19 +0000 (UTC)
X-SpamScore: -34
X-BigFish: VS-34(zz9371I1415J936eK542M98dKzz1202hzz1033IL8275dhz2fh2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
Received-SPF: pass (mail88-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail88-va3 (localhost.localdomain []) by mail88-va3 (MessageSwitch) id 132536041847895_32322; Sat, 31 Dec 2011 19:40:18 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 05B4268004B; Sat, 31 Dec 2011 19:40:18 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 31 Dec 2011 19:40:15 +0000
Received: from ([]) by ([]) with mapi id 14.02.0247.005; Sat, 31 Dec 2011 11:40:15 -0800
From: Mike Jones <>
To: Julian Reschke <>
Thread-Topic: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?
Date: Sat, 31 Dec 2011 19:40:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
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: Mark Nottingham <>, Barry Leiba <>, OAuth WG <>
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
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: Sat, 31 Dec 2011 19:40:19 -0000

Maybe I misunderstood your position.  If you agree that '\' may not occur in the INPUT string, then that issue can be closed.  That was the working group consensus position, per the cited e-mails.  I thought that you were arguing that syntax restrictions on the parameters should only be placed upon the OUTPUT string - which forces all implementations to support unnecessary encodings like "\a\b\c" for "abc".  Please let me know whether you're fine with the working group prohibiting the use of '\' in the input string as the spec presently currently does.

				Happy New Year!
				-- Mike

-----Original Message-----
From: Julian Reschke [] 
Sent: Saturday, December 31, 2011 3:59 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15?

On 2011-12-31 00:19, Mike Jones wrote:
> I did already back the statement that this is the working group consensus with the e-mails attached in this note sent to you on December 12, 2011:
>    -

I replied in

"I'm not disagreeing with the decision not to allow "\" in the value. 
What I'm disagreeing with is writing the ABNF in a way that will make it likely for implementers to special-case OAuth parameters when they should not."

So you're citing a consensus for a related but different question. I recommend to read the mailing thread to the end.

> As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was already in place).  However, it is not violating any MUST clauses in the HTTPbis spec.  Given that no MUSTS are violated, I don't see it mandatory for this tension to be resolved in favor of one spec or the other in order for both to be approved as RFCs.  I look forward to seeing that happen soon in both cases (and for the OAuth core spec as well).

As a matter of fact, the HTTPbis P7 text on considerations for new schemes doesn't use any BCP14 keywords at all. That's on purpose, because we think they should be used with care, and in particular that they should only be used to discuss the protocol, not the style of other specifications.

So it's really not relevant; what's essential is the intent of the spec text, and I believe that is VERY clear:

    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.

(Note the "cannot").

So again, if you disagree with this statement, please argue your case in the HTTPbis WG.

If you *do* agree, but somehow feel that the bearer spec can't do this, the bearer spec should document the reason (just like when an implementation fails to implement a SHOULD).

As to the question of timing (when certain paragraphs were added): yes, HTTPbis P7 changed based on feedback and review of the OAuth bearer spec (triggered by James Manger). That's a feature.

If it hadn't, for instance, the bearer spec wouldn't conform to the base grammar *at all*. See <>.

Best regards, Julian