Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer

"Manger, James H" <James.H.Manger@team.telstra.com> Mon, 05 March 2012 23:33 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70DB21E804D for <oauth@ietfa.amsl.com>; Mon, 5 Mar 2012 15:33:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.563
X-Spam-Level:
X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45bOoGWeQbg4 for <oauth@ietfa.amsl.com>; Mon, 5 Mar 2012 15:33:07 -0800 (PST)
Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id EC50B21E8053 for <oauth@ietf.org>; Mon, 5 Mar 2012 15:32:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.73,537,1325422800"; d="scan'208";a="64121055"
Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipocni.tcif.telstra.com.au with ESMTP; 06 Mar 2012 10:32:56 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6640"; a="1203406"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcani.tcif.telstra.com.au with ESMTP; 06 Mar 2012 10:32:56 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Tue, 6 Mar 2012 10:32:56 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
Date: Tue, 06 Mar 2012 10:32:54 +1100
Thread-Topic: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
Thread-Index: Acz7IQo6kb65NrOMT92lUwLW39DciQAA3VLA
Message-ID: <255B9BB34FB7D647A506DC292726F6E114EDF66EE8@WSMSG3153V.srv.dir.telstra.com>
References: <CA+k3eCTTsqJZ7XzjA1qgxEJcyU0uio5EN2=yvs+h6ja1JEymiQ@mail.gmail.com>
In-Reply-To: <CA+k3eCTTsqJZ7XzjA1qgxEJcyU0uio5EN2=yvs+h6ja1JEymiQ@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
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, 05 Mar 2012 23:33:07 -0000

Brian,

> On casual reading of "The OAuth 2.0 Authorization Protocol: Bearer
> Tokens"* I've encountered several people (including myself) who have
> made the assumption that the name b64token implies that some kind of
> base64 encoding/decoding on the access token is taking place between
> the client and RS.
> 
> Digging a bit deeper in to "HTTP/1.1, part 7: Authentication"**,
> however, I see that b64token is just an ABNF syntax definition
> allowing for characters typically used in base64, base64url, etc.. So
> the b64token doesn't define any encoding or decoding but rather just
> defines what characters can be used in the part of the Authorization
> header that will contain the access token.
>
> Do I read this correctly?

Yes.

> If so, I feel like some additional clarifying text in the Bearer
> Tokens draft might help avoid what is (based on my small sample) a
> common point of misunderstanding.

Changing the example bearer token should be a simple way to avoid some confusion by showing that it does not have to be base64 encoding. How about changing:
  Authorization: Bearer vF9dft4qmT
to
  Authorization: Bearer vF9.dft4.qmT

The Bearer spec has lots of (unnecessary) text about OAuth, but doesn't quite manage to be precise about how OAuth and Bearer connect. It could explicitly state that the string value of the "access_token" member of an access token response is the bearer token. The "access_token" string value (after unescaping any JSON-escapes) MUST match the b64token ABNF so it can be used with the Bearer HTTP scheme. Such text could be put in §5.1.1 where the "Bearer" OAuth access token type is defined.


> Also, does the use of b64token implicitly limit the allowed characters
> that an AS can use to construct a bearer access token?

Yes.


> * http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-17#section-2.1
> ** http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-18#section-2.1

--
James Manger