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

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 28 October 2010 05:28 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9677D3A67D7 for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 22:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.543
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFVvxwFxkcY8 for <oauth@core3.amsl.com>; Wed, 27 Oct 2010 22:28:37 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by core3.amsl.com (Postfix) with ESMTP id 419C73A682C for <oauth@ietf.org>; 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 ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 28 Oct 2010 16:30:26 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6149"; a="12115034"
Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbni.tcif.telstra.com.au with ESMTP; 28 Oct 2010 16:30:25 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Thu, 28 Oct 2010 16:30:25 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Mark Lentczner <mzero@google.com>, "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 28 Oct 2010 16:30:24 +1100
Thread-Topic: [OAUTH-WG] OAuth v2 Authorization Header Credentials
Thread-Index: Act2MPRZVlUjg/E2RnyJUM5Sj5QJ6gAJbJMw
Message-ID: <255B9BB34FB7D647A506DC292726F6E11273A607B8@WSMSG3153V.srv.dir.telstra.com>
References: <AANLkTi=d9jBES+f0ynxuH8+XDPHi4swE8LbnhGdiY1On@mail.gmail.com>
In-Reply-To: <AANLkTi=d9jBES+f0ynxuH8+XDPHi4swE8LbnhGdiY1On@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 28 Oct 2010 05:28:40 -0000

Mark,

§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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mark Lentczner
Sent: Thursday, 28 October 2010 10:44 AM
To: oauth@ietf.org
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.
...