>> 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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
