From: Paul Tarjan <paul.tarjan@facebook.com>
To: Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [OAUTH-WG] Understanding the reasoning for Base64
Thread-Index: AQHLGVg7NcljKnju2kGxsi3dQJmpwJKdMPyAgAGYXQA=
Date: Sat, 3 Jul 2010 00:04:46 +0000
Message-ID: <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com>
References: <AANLkTimMruKyblUWROkPMDapFKtTztOXqL64PpQxCmKO@mail.gmail.com>
 <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com>
 <AANLkTinvLOV0f3I-aWpeAbfIpfGyxZSB2RHu52iw5mDC@mail.gmail.com>
 <AANLkTilWNneonIRX21U1RZcE80FuVSJWXU7CNm5pV275@mail.gmail.com>
 <AANLkTin-7PNLv-Hc229JJcOrIBh4fJqY5CMaLCMbmoIk@mail.gmail.com>
 <AANLkTikh_nQ8dXSp7QXJ79kCdbX1zeyPKAl_kgplb25x@mail.gmail.com>
 <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com>
 <AANLkTimpvWCbCBEWdI1Id5Ig_xCUW2hvKDro5LyhufMV@mail.gmail.com>
 <FE47FED0-3850-4393-9C79-DE06F0F7B6CA@gmail.com>
In-Reply-To: <FE47FED0-3850-4393-9C79-DE06F0F7B6CA@gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <609f9a2a-2e81-4959-a567-1663b960bb6c>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64
Precedence: list

>> We don't think base64url will work, because the most common error we'll =
see is that developers forget the "url" part and just do plain base64, and =
that's not sufficient because the stock set includes +.
>=20
> I think forgetting to url-decode is more likely than doing the wrong base=
64 encoding. At least with the wrong base64 encoding, what was done wrong i=
s more obvious right away. The + will not be in the string.

Most web frameworks that I know of urldecode the inputs before they even hi=
t application code.=20



>>=20
>> So it will maybe work, maybe not. Maybe they'll do urlencoding after any=
ways, since if they are passing this as a query param, or post data, client=
 libraries will take a dict and try to "do the right thing". And we end up =
with pluses, and we're not quite sure if they should be urldecoded or not.
>=20
> we won't have pluses

I think Naitik is saying that accidentally doing base64 and not base64url w=
ill send some '+'s along.




> why hex? ... why not base64url?

It seems to be the encoding format in languages:

python:
>>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest()
'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4'

php:
print hash_hmac('sha256', 'payload', 'secret');
b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba

ruby:
>> HMAC::SHA256.hexdigest('secret', 'payload')
=3D> "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4"




> I am unclear on what your point is.=20
>=20
> The token would be included as one of the headers. This is often preferab=
le as it separates the authorization layer (in header) from application lay=
er parameters (query string or message body)

With our proposal, we were focussed on url parameters (hence the choice of =
urlencode after it was all put together). I think it makes total sense to n=
ot do the encoding as part of the sig spec, and let the transport choice di=
ctate which encoding to use.

Therefore, I think we should make the signature:

    hash + '.' + json string

And then if you are putting it in a url parameter, you should urlencode the=
 whole thing. If you are putting it in an HTTP header you should remove all=
 the "\r" and "\n" in the json output (which are only whitespace as they ar=
en't allowed inside strings, and most language encoders won't even output t=
hem by default).=20

This way, this is a general signature spec, regardless of how it is being s=
ent. You could send it as a DNS record and do the proper encoding for that =
scenario, or carrier pigeon encoded in Navajo, etc.=20



So to sum up:

* We'd like the signature first (so you can left split instead of right spl=
it)
* We'd like the signature to be hex encoded instead of base64url because th=
at's how the common usage is nowadays
* We'd like to not encode the payload (other than JSON) and let the choice =
of transport layer dictate how to handle encoding the whole thing.

Sound good?

Paul=