Yeah!
On 2010-07-06, at 11:12 PM, Naitik Shah wrote:
> I was hoping to avoid needing str_replace -- but I've been convinced. I'm
> happy with base64url :)
>
>
> Thanks,
> -Naitik
>
> On Tue, Jul 6, 2010 at 9:17 PM, Evan Gilbert <uid...@google.com> wrote:
> Hi all - having a little bit of a hard time following the full thread, but
> I'm strongly in favor of base64url encoding.
>
> A big advantage of this encoding is that, if token is base64url encoded, then
> urlencode(token) == token.
>
> This allows developers to avoid a large class of problems in dealing with URL
> encoding / decoding issues - it is very easy to accidentally double encode /
> decode values, and also easy to get tripped up on the different encoding
> rules in different parts of a URL. For example, different characters are OK
> before and after the hash, and not all browsers decode the hash the same way.
>
> Also being able to copy a value from a URL and use it directly in a tool or
> Authorization header is invaluable for debugging.
>
> Per notes above, the transformation is very straightforward.
>
> Evan
>
> On Sat, Jul 3, 2010 at 12:45 PM, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> On 2010-07-03, at 12:14 PM, Naitik Shah wrote:
>
>> On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.ha...@gmail.com> wrote:
>>
>> 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.
>>
>> The thing I was trying to say was that it's less predictable. That it might
>> work just fine when you're experimenting with the API because at that point
>> your token did not contain any pluses, but then suddenly started failing
>> after you sent a link to your app to someone because their encoded token
>> contains a plus. This hit-or-miss to me is worse than being able to tell by
>> looking at the first few characters of the urlencoded JSON blob which will
>> give a definitive answer as to how many times the token has been urlencoded.
>
> I understand your point. I still think base64url encoding makes it really
> clear that it is encoded (nothing is legible anymore), allows there to be one
> encoding format for all data, makes it easy to support encryption.
>
>
>>
>>
>>>
>>> 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.
>>
>>
>> Exactly :) I'm imagining our documentation where we want to be library
>> agnostic, and have almost psuedo code like code snippets. I said this
>> earlier -- while base64 may be common in standard libraries built into
>> languages, the base64url version isn't. In order to not have a "cpan install
>> base64url" (and gem install, easy_install, mvn install..) -- we'ed most
>> likely document a str_replace() call in addition to a base64 call. And I'm
>> worried that developers will miss this detail.
>
> Likely they will install an OAuth library that will deal with it if they are
> going to have to sign rather than using a bearer token (I believe most people
> will use a bearer token if they can -- soooo much easier!)
>
> Besides base64url, there is HMAC256 and JSON -- not all of which are built in
> -- but are becoming more built in as time goes on, and if OAuth signing uses
> base64url, I would expect these will all be part of standard distributions in
> the future ...
>
> (... in case you are unfamiliar with my backgroud, I have delivered Perl,
> Python and Tcl distributions in the past -- what goes into a packages is what
> is heavily used or what we thought was a good thing to promote -- and
> assuming that making base64url more available is a good thing, than using it
> in OAuth is a good thing to do. :)
>
>>
>>
>>>
>>>
>>>
>>>
>>> >
>>> >> 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.
>>
>> I agree multiple encodings makes libraries harder :)
>
> glad we agree there
>
>
>>
>> But I think the stark difference between OAuth1 vs 2 wrt to signing actually
>> makes the Authorization header less valuable (again, for signing only). I'm
>> pretty happy with this because I thought this header was more complex for
>> developers anyways (while big corporations with authentication
>> infrastructure love it) :) But the reason I think so is that now the header
>> is not just the signature, but also the signed payload. This means an
>> application isn't just making a http request as before with a bunch of query
>> or post parameters. It's instead making a "JSON request" that may or may not
>> have query/post params. It's just not as separate as before.
>
> I am confused on what point you are trying to make here.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
