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

William Mills <> Tue, 06 March 2012 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C18F21F85ED for <>; Tue, 6 Mar 2012 10:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.218
X-Spam-Status: No, score=-17.218 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zaPlSfjP0oLo for <>; Tue, 6 Mar 2012 10:45:29 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id CBB8321F8501 for <>; Tue, 6 Mar 2012 10:45:29 -0800 (PST)
Received: from [] by with NNFMP; 06 Mar 2012 18:45:29 -0000
Received: from [] by with NNFMP; 06 Mar 2012 18:45:29 -0000
Received: from [] by with NNFMP; 06 Mar 2012 18:45:29 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 92354 invoked by uid 60001); 6 Mar 2012 18:45:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ginc1024; t=1331059529; bh=+4679B/Zt6gVACZZ7Cm2GFPKuCNf7b7TX13vq9qka/4=; 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=GBkbhgnEYF9FuyeNY23l//Ps6t3fTuyyBAYlYd+ie27rlzAQxw6si7mXRJ2sNB+2AtTRU0ncwvhHk8QoGPQkHypJH+RsuCAwOk7UoIlr72yoOEmTxs44/ROtp0WPbITU7ZxU5R50/QFaXsca9/Uw9QHIss0DVT2Hqf4karYgMKU=
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=HuAZyexVEAba7wzuq3dHwXF0mSw0gMZmp2XM7eV4SsJ0/4DvBA+tKFvkS6UTdgq/5wcc88FFk1UlPMQckPiRIZXtwgAcqZW4rtETlaEfLG6smipkAVwW759wKrw3GKtVGfVqtSV2veBcbQXH0C4O1xHAYZmEO+/R9ZcFTIDMWo0=;
X-YMail-OSG: toE5Es4VM1l10eJavYdRnjISNAKcJAXTsVwRqW6ASDRnZbp WxcIwvV9clYJ9BX3hTrsig9bCTXyyMdDVgqYSwxAlDfHEqfv6_FWVnioiVSq 6_2AfKaijcSXZhQNYzUdKmHCPOE5PL0Ik.MGu2kq8XlhEY4a.GEeJigHsPOn f7NDpyi0_dU2X9EJYTUgYz3WHGflPCgNi7NyKv62G.PjP976AcWcSbpDnq.e Hlfpv4mSCkHEzLdEHxA9DUK4OQ0._L94BktvyuYX4PZnvSOHSncPwhdss35Q TGlYfCaxyIBxFWbeF25yHAqes0dQWzUEJdpc..sW7NTEWxx4yCYTKQ5Ezy4e DUYAe9MrTl.ZHJzWMgn81efOooNeU5X2XVp4P8VS.Lb1jrSrh1pnH977mq4n gEXiDvgH9eRY8kw5uDyjGp1xnfUVNHWpdmnNGtxnHBWGXXLrMIA--
Received: from [] by via HTTP; Tue, 06 Mar 2012 10:45:28 PST
X-RocketYMMF: william_john_mills
X-Mailer: YahooMailWebService/
References: <> <> <> <>
Message-ID: <>
Date: Tue, 6 Mar 2012 10:45:28 -0800 (PST)
From: William Mills <>
To: Brian Campbell <>, Mike Jones <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-1055047407-743777887-1331059528=:92345"
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: Tue, 06 Mar 2012 18:45:31 -0000

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.


 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