Re: [OAUTH-WG] Understanding the reasoning for Base64

[Paul Tarjan <[e-mail]>]

>> 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 +.
> 
> 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.

Most web frameworks that I know of urldecode the inputs before they even hit application code. 



>> 
>> 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.
> 
> we won't have pluses

I think Naitik is saying that accidentally doing base64 and not base64url will 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')
=> "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4"




> I am unclear on what your point is. 
> 
> 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)

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.

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 aren't allowed inside strings, and most language encoders won't even output them by default). 

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. 



So to sum up:

* We'd like the signature first (so you can left split instead of right split)
* We'd like the signature to be hex encoded instead of base64url because that'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