DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=subject:mime-version:content-type:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to:x-mailer;
 b=Vpao3HJD3DQNLQSr+UtVLhiRuuuK+8tHdnEdrYdnZc1VtdCTWiTvYkoVmZd7w0WEwg
 7ulOzYY9dhAa43/PNno3z1pNpIgFNOouycW14PpCgOKAmcrAYjgcJMpn6V7z/nEs59xR
 7tNg+Q9iERVo28y8YiIkV+0Vt7RzIlWLiGtGk=
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com>
Date: Sat, 3 Jul 2010 09:02:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C66A9854-02EB-4CCE-8338-382AEEC7EA61@gmail.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>
 <BA564125-9FBB-4B1A-93AC-7DD1A754A5E1@facebook.com>
To: Paul Tarjan <paul.tarjan@facebook.com>
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64
Precedence: list

On 2010-07-02, at 5:04 PM, Paul Tarjan wrote:

>>> 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 =
base64 encoding. At least with the wrong base64 encoding, what was done =
wrong is more obvious right away. The + will not be in the string.
>=20
> Most web frameworks that I know of urldecode the inputs before they =
even hit application code.=20
>=20
>=20
>=20
>>>=20
>>> So it will maybe work, maybe not. Maybe they'll do urlencoding after =
anyways, 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
>=20
> I think Naitik is saying that accidentally doing base64 and not =
base64url will send some '+'s along.

if there are '+'s in the token, then it is easy for someone helping to =
spot the problem. also easy for servers to send back an error message =
saying, "hey, looks like you are using base64 instead of base64url =
encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to =
detect as an error

>=20
>=20
>=20
>=20
>> why hex? ... why not base64url?
>=20
> It seems to be the encoding format in languages:
>=20
> python:
>>>> hmac.new('secret', 'payload', hashlib.sha256).hexdigest()
> 'b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4'
>=20
> php:
> print hash_hmac('sha256', 'payload', 'secret');
> b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba
>=20
> ruby:
>>> HMAC::SHA256.hexdigest('secret', 'payload')
> =3D> =
"b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4"

When I wrote a sample in Perl, it was pretty easy to make it base64url =
which then provides a consistent encoding.

>=20
>> I am unclear on what your point is.=20
>>=20
>> The token would be included as one of the headers. This is often =
preferable as it separates the authorization layer (in header) from =
application layer parameters (query string or message body)
>=20
> 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 not do the encoding as part of the sig spec, and let the =
transport choice dictate which encoding to use.

I understand what you are saying. having multiple encodings makes =
libraries harder, and leads to the issues that motivated base64url over =
url-encoding

>=20
> Therefore, I think we should make the signature:
>=20
>    hash + '.' + json string
>=20
> 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 aren't allowed inside strings, and most language =
encoders won't even output them by default).=20
>=20
> This way, this is a general signature spec, regardless of how it is =
being sent. You could send it as a DNS record and do the proper encoding =
for that scenario, or carrier pigeon encoded in Navajo, etc.=20
>=20
>=20
>=20
> So to sum up:
>=20
> * We'd like the signature first (so you can left split instead of =
right split)

What are the advantages of left split vs right split?

> * We'd like the signature to be hex encoded instead of base64url =
because that's how the common usage is nowadays

one encoding for everything seems simpler to do

> * 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.

I don't understand why you think this is a good idea.


>=20
> Sound good?

nope