Subject: p7: rename b64token (to token68) to avoid misunderstandings

From: "Manger, James H" <[email-masked]>
Date: Wed, 18 Jul 2012 17:27:51 +1000

HTTPbis part 7 (Authentication) introduces a new piece of ABNF labelled "b64token" [http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-20#section-2.1]. It is also referenced/repeated in the OAuth2 Bearer draft spec. The new ABNF is necessary and explained quite clearly in the spec. However, the "b64token" label has already led at least a handful of people to mistakenly assume it always holds a base64-encoding. The examples in the OAuth2 Bearer spec were even changed so they were not base64-encodings to try to minimise the misunderstanding, but others have still made the mistaken assumption.

How about renaming the ABNF production to "token68"?

This label reflects the fact that it supports an alphabet of 68 characters (plus equal signs at the end).

The new text in part 7 would become:

   token68       = 1*( ALPHA / DIGIT /
                        "-" / "." / "_" / "~" / "+" / "/" ) *"="

   The "token68" syntax allows the 66 unreserved URI characters
   ([RFC3986]), plus a few others, so that it can hold a base64,
   base64url (URL and filename safe alphabet), base32, or base16 (hex)
   encoding, with or without padding, but excluding whitespace
   ([RFC4648]).

--
James Manger

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 09:39:57 +0200

>     token68       = 1*( ALPHA / DIGIT /

Sounds good to me; if this reduces potential confusion we should to that.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 18 Jul 2012 21:14:35 +1200

On 18/07/2012 7:39 p.m., Julian Reschke wrote:
>> HTTPbis part 7 (Authentication) introduces a new piece of ABNF 
>> labelled "b64token" 
>> [http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-20#section-2.1]. 
>> It is also referenced/repeated in the OAuth2 Bearer draft spec. The 
>> new ABNF is necessary and explained quite clearly in the spec. 
>> However, the "b64token" label has already led at least a handful of 
>> people to mistakenly assume it always holds a base64-encoding. The 
>> examples in the OAuth2 Bearer spec were even changed so they were not 
>> base64-encodings to try to minimise the misunderstanding, but others 
>> have still made the mistaken assumption.
>>
>> This label reflects the fact that it supports an alphabet of 68 
>> characters (plus equal signs at the end).
>>

+1 from me too.

AYJ

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Jul 2012 10:39:46 +0100

>     token68       = 1*( ALPHA / DIGIT /
I like that.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 21:43:22 +0200

>> Sounds good to me; if this reduces potential confusion we should to that.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1815>

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 19 Jul 2012 04:49:52 +0900

+1, very good direction.

Additional comment:
Its use in -p7 is only for legacy direct tokens for challenge and credentials.
If there is a good-sounding name suggesting its legaciness or its specific
use case, it seems better for me than name based on 68 possible characters.

# I imagined "legacy-raw-auth-token", but it's not sounding good :-(

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability Research Group
                             Research Institute for Secure Systems (RISEC)
   National Institute of Advanced Industrial Science and Technology (AIST)
                     Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 22:00:22 +0200

On 2012-07-18 21:49, Yutaka OIWA wrote:
> ...

Point taken, but in the end what's important is the prose, and that 
already says:

"The "token68" notation was introduced for compatibility with existing 
authentication schemes and can only be used once per 
challenge/credentials. New schemes thus ought to use the "auth-param" 
syntax instead, because otherwise future extensions will be impossible."

(and yes, the OAuth bearer spec ignores that advice)

Best regards, Julian

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 19 Jul 2012 05:04:57 +0900

Dear Julian,

Yes, I know the existence of that important text.
So, I am enough satisfied even with the current name, too.

Thank you.

2012/7/19 Julian Reschke <[email-masked]>:
> Point taken, but in the end what's important is the prose, and that already
> says:
>
> authentication schemes and can only be used once per challenge/credentials.
> New schemes thus ought to use the "auth-param" syntax instead, because
> otherwise future extensions will be impossible."
>