On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> 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 +.
> >>
> >> 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.
>
> 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
>
The pluses are not guaranteed. They may or may not be there depending on the
data stream you're encoding. If you don't urlencode the JSON, you'll get a
"{", if you do it once, you'll get a "%7B", if you do it twice, you'll get a
"%257B" -- seems easier to detect.
> >
> >
> >
> >
> >> 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"
>
> When I wrote a sample in Perl, it was pretty easy to make it base64url
> which then provides a consistent encoding.
>
Did it involve a string replace call? Or a third party library?
> >
> >> 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.
>
> I understand what you are saying. having multiple encodings makes libraries
> harder, and leads to the issues that motivated base64url over url-encoding
> >
> > 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)
>
> What are the advantages of left split vs right split?
>
Built in split function with a limit is more common, which makes the left
split easier.
-Naitik
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
