Re: [OAUTH-WG] OAuth v2 Authorization Header Credentials

"Manger, James H" <> Thu, 28 October 2010 05:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9677D3A67D7 for <>; Wed, 27 Oct 2010 22:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.543
X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vFVvxwFxkcY8 for <>; Wed, 27 Oct 2010 22:28:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 419C73A682C for <>; Wed, 27 Oct 2010 22:28:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.58,249,1286110800"; d="scan'208";a="18464785"
Received: from unknown (HELO ([]) by with ESMTP; 28 Oct 2010 16:30:26 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6149"; a="12115034"
Received: from ([]) by with ESMTP; 28 Oct 2010 16:30:25 +1100
Received: from ([]) by ([]) with mapi; Thu, 28 Oct 2010 16:30:25 +1100
From: "Manger, James H" <>
To: Mark Lentczner <>, "" <>
Date: Thu, 28 Oct 2010 16:30:24 +1100
Thread-Topic: [OAUTH-WG] OAuth v2 Authorization Header Credentials
Thread-Index: Act2MPRZVlUjg/E2RnyJUM5Sj5QJ6gAJbJMw
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, en-AU
Content-Language: en-US
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth v2 Authorization Header Credentials
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Oct 2010 05:28:40 -0000


§5.1.1 (where the ABNF for credentials is defined) will move out of the OAuth core spec in the doc split.
I would like to see the bearer spec use a non-OAuth scheme name when it defines its Authorization header.

I strongly favour restricting tokens to a much smaller alphabet, such as the 66 unreserved chars (A-Z a-z 0-9 - _ . ~). Anything more means we need escaping mechanisms in all the places a token can go. Anything more still doesn't support arbitrary binary data or arbitrary Unicode text so you still need an encoding such as base64url.

Supporting 'quoted-string' would not be strictly necessary for an access-token parameter if values were restricted to those 66 chars. However, I would be happy enough to require parsers to support (token | quoted-string).

I don't think we need 'realm' as an auth-key. It is defined for WWW-Authenticate response headers, but isn't necessary for Authorization request headers.

I'm in favour of only using name=value pairs after the scheme name, even if there is only 1 parameter (the bearer token). It enables parameters to be added in the future.

My variant of your proposal:

    credentials    = "BEARER" RWS #auth-param
    auth-param     = auth-key "=" ( token | quoted-string )
    auth-key       = "a" | future-key
    future-key     = token

The "a" parameter holds an access token that MUST only consist of chars from the set of 66 unreserved chars [should probably express that in the ABNF]. Examples:
  Authorization: BEARER a=vF9dft4qmT
  Authorization: BEARER a="vF9dft4qmT"

James Manger

-----Original Message-----
From: [] On Behalf Of Mark Lentczner
Sent: Thursday, 28 October 2010 10:44 AM
Subject: [OAUTH-WG] OAuth v2 Authorization Header Credentials

In my work implementing OAuth v2 to draft 10, I have had to review the
definition of credentials included in an Authorization header. I
believe this current definition has some significant issues for
parsers. However, with some small clean up of the definition, proposed
below, I believe that the credentials can be made robust and more
compatible for existing and future implementations.