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

From: Naitik Shah <[email-masked]>
Date: Thu, 1 Jul 2010 12:52:30 -0700

Searching for base64url does make it better. Thanks for that pointer Dick.

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

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.

For example, this doesn't give me back what I put in:

  base64_decode(urldecode(base64_encode('-+>')))

Because the base64_encode returns something containing a +, and the usual
urldecode logic will convert this into a space. In fact, looking at the PHP
docs for base64 decode, there are a bunch of comments talking about pluses:
http://php.net/manual/en/function.base64-decode.php.

The approach I'm thinking is something like:

  function getSignedToken($params, $secret) {
    $json = json_encode($params);
    // Moving the signature to be before the payload makes the
separator/split
    // logic be: "everything before the first dot is the sig". also, it's
hex.
    return hash_hmac('sha256', $json, $secret) . '.' . $json;
  }

  function parseSignedToken($token, $secret) {
    list($sig, $json) = explode('.', $token, $limit=2);
    if (hash_hmac('sha256', $json, $secret) !== $sig) {
      throw new Exception('Bad Sig');
    }
    return json_decode($json);
  }

[UNTESTED!] Where url encoding and decoding happens outside of the signature
process.

I'm not convinced adding the request as a header is going to be used often.
Headers are always sent uncompressed. I imagine signatures to be used for
those that are perf sensitive and don't want the SSL overhead. So this minor
detail will matter to them. This is especially true because unlike OAuth1,
the header doesn't just contain a signature, but contains the entire signed
payload. But there's nothing stopping us from using the same format above
for sending the payload as a header.

One of the arguments was wrt detecting double url encoding. Since the thing
we're signing is a JSON object, we always know it will start with %7B and if
it's double encoded, it will be %257B.

-Naitik

On Fri, Jun 25, 2010 at 5:21 PM, Dick Hardt <[email-masked]> wrote:

> The RFC term is base64url which turns up much better results when
> searching. "URL safe base64" is also a good search term.
>
> Note that the token may also be included in the HTTP header. base64url
> encoding works well for HTTP headers. Note that the token is opaque to the
> client, so being plain text is not as useful as it may seem. Unlike URL
> encoding, it is pretty easy to see if a string is base64url or not. With URL
> encoding, it may or may not be encoded which sometimes leads to double
> encoding / mismatched encoding.
>
> -- Dick
>
> On 2010-06-25, at 4:42 PM, Naitik Shah wrote:
>
> So my litmus test was looking on the web for "web base 64" or "web base64".
> Both yield nothing useful. Looking at the docs for PHP, it doesn't seem to
> support it, Python does, Ruby doesn't seem to. Java doesn't seem to have a
> native base64, and the C# one doesn't seem to have the web version (a bit
> unsure about these two). The point I'm trying to make is to someone who
> comes and reads the docs for an API where we're talking about signature, web
> base64 will need to be explained in detail.
>
> I agree eliminating encoding problems is a good goal. But if we do have to
> teach the developer a new, or slightly modified encoding scheme, why not
> have it be URL encoding? It seems more valuable in the long term, since it's
> a spec that shows up more frequently on the web. And OAuth 1 has already
> taught this spec to at least some of the target audience.
>
> While encoding/decoding with any format will result in some learning, I
> think if we sign a JSON blob sans urlencoding or web-base64, it might work
> out to be easier. The fact that it's still mostly plain text is also a plus
> imho.
>
>
> -Naitik
>
>
> On Fri, Jun 25, 2010 at 1:36 PM, John Panzer <[email-masked]> wrote:
>
>> There are 2 characters that are different between base64 and base64url.
>>  Many good libraries support both (as they're both useful, and both are in
>> the base64 RFC spec); the ability to eliminate a class of encoding problems
>> seems like a good trade-off for, in some languages without full base64
>> support, an additional substitution of 2 characters.
>>
>> --
>> John Panzer / Google
>> [email-masked] / abstractioneer.org <http://www.abstractioneer.org/>/ @jpanzer
>>
>>
>>
>> On Fri, Jun 25, 2010 at 12:15 PM, Naitik Shah <[email-masked]> wrote:
>>
>>> On Fri, Jun 25, 2010 at 11:39 AM, Breno <[email-masked]>wrote:
>>>
>>>> On Fri, Jun 25, 2010 at 10:49 AM, Luke Shepard <[email-masked]>
>>>> wrote:
>>>> > Brian, Dirk - just wondering if you had thoughts here?
>>>> >
>>>> > The only strong reason I can think of for base64 encoding is that it
>>>> allows for a delimiter between the body and the signature. Is there any
>>>> other reason?
>>>>
>>>> Without base64 encoding we have to define canonicalization procedures
>>>> around spaces and we still have to URL encode separator characters
>>>> such as {. There is also the risk that developers might be confused
>>>> whether the URL encoding is to be performed before or after
>>>> computation of the signature.  If you say that the signature is
>>>> computed on the base64 encoded blob, there's less scope for confusion
>>>> and interoperability issues.
>>>>
>>>>
>>> Yep, I get that the "web" version makes the url encoding a no op. But I
>>> fear we're trading one spec (urlencoding) to another one (web base64). I'm
>>> imagining the sample code (that does not rely on an SDK) we'ed give out to
>>> developers in our docs, and the thing that stands out is the "web" part in
>>> the web_base64. It means that our sample code will look like
>>>
>>>   str_replace("+", "_", base64(json_encode(data))))
>>>
>>> or for validating signatures:
>>>
>>>   json_decode(decode64(str_replace("_", "+", data)))
>>>
>>> The str_replace() really stands out. From my quick read, it seemed like
>>> there were one or two other characters that needed to get replaced too.
>>> While some languages (like PHP) support arrays to specify multiple
>>> replacement patterns, in other languages you'll end up with a few
>>> str_replace calls. It would be nice if that wasn't necessary.
>>>
>>> I'm wondering if we can get away with "urlencode(json_encode(data) + '.'
>>> + sig)" as the value. then, instead of str_replace for getting normal base64
>>> logic to work, we would instead need a rsplit or something, since the dot is
>>> not a reserved character in the json blob. Was that approach considered?
>>>
>>>
>>> -Naitik
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 1 Jul 2010 16:43:11 -0700

On 2010-07-01, at 12:52 PM, Naitik Shah 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.

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

> Because the base64_encode returns something containing a +, and the usual urldecode logic will convert this into a space. In fact, looking at the PHP docs for base64 decode, there are a bunch of comments talking about pluses: http://php.net/manual/en/function.base64-decode.php.
> 
>     // Moving the signature to be before the payload makes the separator/split
>     // logic be: "everything before the first dot is the sig". also, it's hex.

why hex? ... why not base64url?

> [UNTESTED!] Where url encoding and decoding happens outside of the signature process.
> 
> I'm not convinced adding the request as a header is going to be used often. Headers are always sent uncompressed. I imagine signatures to be used for those that are perf sensitive and don't want the SSL overhead. So this minor detail will matter to them. This is especially true because unlike OAuth1, the header doesn't just contain a signature, but contains the entire signed payload. But there's nothing stopping us from using the same format above for sending the payload as a header.

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)

> 
> One of the arguments was wrt detecting double url encoding. Since the thing we're signing is a JSON object, we always know it will start with %7B and if it's double encoded, it will be %257B.

So you really think a developer will remember the spot that it is  not %7B and is %257B  but will NOT to use base64url?

---

From: Paul Tarjan <[email-masked]>
Date: Sat, 3 Jul 2010 00:04:46 +0000

> 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 t…

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 ri…

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"

> 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

---

From: Dick Hardt <[email-masked]>
Date: Sat, 3 Jul 2010 09:02:51 -0700

> 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

> => "b82fcb791acec57859b989b430a826488ce2e479fdf92326bd0a2e8375a42ba4"

When I wrote a sample in Perl, it was pretty easy to make it base64url which then provides a consistent encoding.

> 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…

I understand what you are saying. having multiple encodings makes libraries harder, and leads to the issues that motivated base64url over url-encoding

> * 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?

> * We'd like the signature to be hex encoded instead of base64url because that's how the common usage is nowadays

one encoding for everything seems simpler to do

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

I don't understand why you think this is a good idea.

> Sound good?

nope

---

From: Naitik Shah <[email-masked]>
Date: Sat, 3 Jul 2010 09:13:39 -0700

On Sat, Jul 3, 2010 at 9:02 AM, Dick Hardt <[email-masked]> 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
> >> 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.
> >
> 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"
>

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.

> 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?

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

> > 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:
> >

Built in split function with a limit is more common, which makes the left
split easier.

-Naitik

---

From: Ben Laurie <[email-masked]>
Date: Sat, 3 Jul 2010 17:27:10 +0100

Let's not lose sight of the underlying reason to choose base64:
avoiding the issue of canonicalisation. If you use an encoding that
various software layers can choose to decode and operate on, then you
open the canonicalisation can of worms. The point of using base64 is
so the blob you hand around is just that: a blob, which no-one can
process except the guy who actually wants to process it.

And a more general plea: can we please stop trimming everything down
to the bare minimum we can get away with? This is equivalent to
maximising fragility, which is a bad idea and has led to several
notable failures of late.

On 3 July 2010 17:13, Naitik Shah <[email-masked]> 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 +.
>> >>
>> 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"
>>
>> I understand what you are saying. having multiple encodings makes
>> libraries harder, and leads to the issues that motivated base64url over
>> url-encoding
>>
>>
>>
>> >
>> > 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:
>> >

---

From: Dick Hardt <[email-masked]>
Date: Sat, 3 Jul 2010 09:42:33 -0700

On 2010-07-03, at 9:13 AM, Naitik Shah wrote:
> 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.
> Did it involve a string replace call? Or a third party library?

I used a standard CPAN library.

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

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

---

From: Dick Hardt <[email-masked]>
Date: Sat, 3 Jul 2010 11:36:03 -0700

On 2010-07-03, at 11:28 AM, Luke Shepard wrote:

> Sounds like we agree on this point at least.

sortof, I don't disagree :)

> 
> The main reason is that it's easier to restrict the delimiter from appearing in the signature than in the payload. This way the delimiter (period) can show up in the payload and a left split can still work.

if each string is base64url, then the period is always the separator

I am still and advocate for a separate string which is the payload. I consider this mechanism to be more generic than OAuth request signatures. I think it can be used for OAuth tokens as well.

---

From: Luke Shepard <[email-masked]>
Date: Sat, 3 Jul 2010 11:28:18 -0700

---

From: Naitik Shah <[email-masked]>
Date: Sat, 3 Jul 2010 12:14:38 -0700

On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <[email-masked]> wrote:

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

>> libraries harder, and leads to the issues that motivated base64url over

I agree multiple encodings makes libraries harder :)

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.

> 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.
>
>
Yep, this and all the reasons you and Luke mentioned in the parallel thread.

-Naitik

---

From: Dick Hardt <[email-masked]>
Date: Sat, 3 Jul 2010 12:45:29 -0700

On 2010-07-03, at 12:14 PM, Naitik Shah wrote:

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

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

---

From: Evan Gilbert <[email-masked]>
Date: Tue, 6 Jul 2010 21:17:24 -0700

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 <[email-masked]> wrote:

> 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.
>
>
>
>
>
>>
> 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. :)
>
>
>
>
>>
>>
>>
>>
>>> >
> 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

---

From: Naitik Shah <[email-masked]>
Date: Tue, 6 Jul 2010 23:12:22 -0700

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 <[email-masked]> wrote:

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

---

From: Dick Hardt <[email-masked]>
Date: Tue, 6 Jul 2010 23:45:48 -0700

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