serialization produces invalid base64

[rogpeppe]

The base64 does not have the required padding characters to
allow it to be parsed by standard base64 decoders.

Verify by taking some serialization from the example README.md:

echo 'MDAxY2xvY2F0aW9uIGh0dHA6Ly9teWJhbmsvCjAwMjZpZGVudGlmaWVyIHdlIHVzZWQgb3VyIHNlY3JldCBrZXkKMDAyZnNpZ25hdHVyZSDj2eApCFJsTAA5rhURQRXZf91ovyujebNCqvD2F9BVLwo' | base64 -d

produces an error.

[rescrv]

We switched to the URL Base64 format so tokens can be put into URLs. See here for more discussion: #20.

This library will handle both, but produces the URL format.

[rogpeppe]

Thanks. I hadn't appreciated that the URL encoding conventionally omits padding.

I think there might be a benefit to exposing functions that don't do any
base64 encoding or decoding at all. If you're sending binary data, the
base64 encoding adds unnecessary overhead, and JSON is already ASCII,
so likewise does not necessarily need armoring.

[rescrv]

I'm up for adding a (possibly hidden) function that can directly output non-base64 tokens so binary data can be sent in the clear. Ditto for the JSON format once it settles.

I went for base64 by default because it's the easiest to use safely under the widest variety of scenarios I can imagine. The lack of whitespace or non-ascii characters means its easy to parse a complete token, and use it in every place I could imagine a token being used. Developers who want to do things more cleverly than that are certainly welcome to do so, but we shouldn't make it the default.

[nitram509]

Interesting discussion. I also want to add my 2 cts.

I prefer Base64, because its plain ASCII and can be easily transported (nearly) everywhere on the web.
AFAIK, JSON isn't ASCII but Unicode (according to http://json.org/). So every developer has to think about post serialization processing (at least), to make a safe transport possible. Think about HTTP headers etc.

When we're talking about character encoding, I prefer JSON, because it's solved there. The current macaroon binary format doesn't specify this.Besides this, I don't see any values in using JSON. But I'm interested to hear yours. (context: macaroon serialization)

In the future I would like to see only one preferred transport format, which eases the cross platform or cross language implementation adoption of macaroons.