On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
> > 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.
Your earlier point was that developers may incorrectly use base64 instead of
base64url. If they used base64, and if there is a + / = or % in the string, the
server can send a useful note saying what is wrong. There may not be one of
those characters depending on the input string, but if there is, then the
server can suggest what the error might be using base64 instead of base64url.
If the token contains ANY character that is not in base64url, then the server
can say that it is not base64url encoded.
That seems pretty fool proof to detect. Note that you should never get any %7B
or other encoding in the token as it is url safe.
>
> 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 used a standard CPAN 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
Glad we agree on that.
> >
> > * 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.
Size limit I am assuming? Since the size of the signature is known, this makes
it safer to have it first? Makes sense to me.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
