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

William Mills <> Wed, 07 March 2012 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E3D11E8072 for <>; Wed, 7 Mar 2012 10:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.228
X-Spam-Status: No, score=-17.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qeTwbcatFJYI for <>; Wed, 7 Mar 2012 10:45:32 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 1255B11E8073 for <>; Wed, 7 Mar 2012 10:45:31 -0800 (PST)
Received: from [] by with NNFMP; 07 Mar 2012 18:45:26 -0000
Received: from [] by with NNFMP; 07 Mar 2012 18:45:26 -0000
Received: from [] by with NNFMP; 07 Mar 2012 18:45:26 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 10064 invoked by uid 60001); 7 Mar 2012 18:45:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1331145925; bh=5yRmmE9g9/Qw2My4raifMhFy9uwV+oSpE3zhomS9lsw=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=biFqvTCcuRZQocjaESluo+uAnjfvm/8PjhUQqhs62s/Hy2Nr2YPnYAGdcxqAj42XOgQDNtc0GT8PCv7hyY4DC5V0IWrOwQKC5yrqdh9VV9G5C3UKTW288Ut6HJhry/b41kw5/n8XJNONozPfEfUFo8XySnIUbUvX4Y7GDpd5MKs=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024;; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Yfxh2wGEfjrkphPxHMyEzSyu8mz1slldyvdhmgFX7IJGRob/yHM6EuQGXh6NLBgcTTkEtZ+4BWeko6CGnqFmUPal+QflazYO+NI25W7oDZWVw9FJ1vABxcLEgQCsVdTEqAL7JhLYtIsYoDEh6acJKbRKMnnAf6CFyI8x0HbAr6g=;
X-YMail-OSG: Ah6mEzoVM1kO.Jt2ylBuy.0YI6odV4QPunvOWoQOhNtjhX2 pJRrrcPK3TByE9DBZ6_19vVe96tE2P8OLv9JN1z_m2DrARY61c2P80C41Yj3 lI.aigOc5i3cRw6JboFTWsVB2ow6I2w3nT21rEKUnQCSII.m0dxXpnRHFtK1 Qls2AiOvDNqOwD6n53sURAamBrrIF.I2B33WYdBQ1tnJBZeyUJpWTZ5Qq5_Y P3xkeXQCn8vhq70la6pcKjQI9ZDuQgrLt8P.KU0Ls11Ae_Y2kihTSlXQ7Y2F lgEdyyG.Zk8CwFOrQ5MwVx41NomkB3JE7RZFJOB3TzYmqvWjEdAzr7RBKOee CtwyqOU5vLK9PCQIGHwpqCV.jiiEaWZcFwvCCWJE5wXWxVNbUEtO87tHt70T 8YqB3FDAp7mTa3lOgtYkTNFZriIAtbaEefkiNGNY4IN9INAIN3.E9RVpXu16 QEukNn3hAQ0OmlJq0Z57snB7FbYM4VAMLKGVTQMK.DtKxE33iYyyTk5Yw8fm TExDQjrYRh9.YXJ.ZF0sjbafQpLJzPMazd3PhgsRxO5Aj8IoRjB4VttSoxhY aLpvtUO0-
Received: from [] by via HTTP; Wed, 07 Mar 2012 10:45:25 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <> <> <> <> <>
Message-ID: <>
Date: Wed, 7 Mar 2012 10:45:25 -0800 (PST)
From: William Mills <>
To: Brian Campbell <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-5876745-1331145925=:9591"
Cc: oauth <>
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills <>
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Mar 2012 18:45:33 -0000

works for me.


P.S. Please start using the  for new requests like product and feature  reviews.

 From: Brian Campbell <>
To: William Mills <> 
Cc: Mike Jones <>om>; oauth <> 
Sent: Wednesday, March 7, 2012 9:16 AM
Subject: Re: [OAUTH-WG] question about the b64token syntax in draft-ietf-oauth-v2-bearer
I'd like to propose the following changes and additions, derived
largely from Bill and James suggestions, to
draft-ietf-oauth-v2-bearer-17.  These changes have no normative impact
and only aim to add additional clarity and explanation the workings
and implications of the current spec.  I'm definitely open to changes
or improvements in the wording here (not my strong suit by any means)
but I think it's important that these general ideas be conveyed in the

==> Insert the following text at the beginning of §2:

To make a protected resource request, the client must be in possession
of a valid bearer token. Typically a bearer token is returned to the
client as part of an access token response as defined in OAuth 2.0
[I-D.ietf-oauth-v2]. When the "token_type" parameter of the access
token response is "Bearer", the string value of the "access_token"
parameter becomes the bearer access token used to make protected
resource requests.

==> Change the value of the token in the Authorization header example to this:

Authorization: Bearer vF_9.5dCf-t4.qbcmT_k1b

==> Insert the following text before the last paragraph of §2.1:

Note that the name b64token does not imply base64 encoding but rather
is the name for an ABNF syntax definition from HTTP/1.1, Part 7
[I-D.ietf-httpbis-p7-auth]. Because of its use, the "access_token"
string value from an access token response MUST match the b64token
ABNF so it can be used with the Bearer HTTP scheme.


On Tue, Mar 6, 2012 at 11:45 AM, William Mills <> wrote:
> Yeah, something as simple as, "Note that the name 'b64token' does not imply
> base64 encoding, see the definition in [[INSERT REFERENCE HERE]]." would do
> it.
> -bill
> ________________________________
> From: Brian Campbell <>
> To: Mike Jones <>
> Cc: oauth <>
> Sent: Tuesday, March 6, 2012 8:23 AM
> Subject: Re: [OAUTH-WG] question about the b64token syntax in
> draft-ietf-oauth-v2-bearer
> Thanks Mike, I think changing the example would be helpful.
> However I think that including some text along the lines of what James
> suggested would also be very valuable. I agree that the connection
> between OAuth and Bearer could and should be made more explicit. And
> that the implications of the b64token syntax, particularly on what AS
> can use to construct ATs, could/should be made more clear.
> I can propose some specific text (building on James') if others in the WG
> agree?
> On Mon, Mar 5, 2012 at 5:32 PM, Mike Jones <>
> wrote:
>> I'm fine with changing the example to make it clearer that b64token allows
>> a wider range of characters than just those legal for base64 and base64url
>> encodings of data values.
>> I'll add it to my to-do list for any additional edits for the Bearer spec.
>>                                -- Mike
>> -----Original Message-----
>> From: [] On Behalf Of
>> Manger, James H
>> Sent: Monday, March 05, 2012 3:33 PM
>> To: Brian Campbell; oauth
>> Subject: Re: [OAUTH-WG] question about the b64token syntax in
>> draft-ietf-oauth-v2-bearer
>> 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.
>>> *
>>> **
>> --
>> James Manger
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list