Proposal: signature in serialized macaroon as hex-string (hexlyfied)

[nitram509]

Hi,

in the readme.md of libmacaroon, there is an example of a Base64 serialized macaroon (look for "M.serialize()").
When decoding this Base64 string everything is human readable, except the signature.
The signature is 32 bytes, which may contain everything, from white spaces to Greek letters.

My team and I plan to adopt macaroons for our growing microservice application landscape. As written in the research paper, there are a lot of benefits, which are very attractive for us.
BUT, when implementing, debugging and tracing macaroons based requests, we prefer to see human readable plain text only. It makes their handling easier. (IMHO, Base64 is transparent, I want to inspect macaroons)

So, I propose to change the signature and 'vid' packets to be packed as hex strings (e.g. cafebabe42),
which encourages better human readability.

What do you think?

PS: You may copy&paste the Base64 example to www.base64decode.org and see for yourself.

[rescrv]

I'd suggest not making this change, and instead rely upon the "inspect" method to generate a robust, human-readable form that you need. We can add other debugging methods, but the raw macaroon representation underneath base64 is not guaranteed to be human readable. In fact, caveats are 8-bit safe bytestrings, so it's always possible to have a macaroon without human readable plaintext.

Doubling the space used for vid and signature strings is not good for our use case.

BTW, the current form is in use both in our implementation, and in @rogpeppe's implementation. I'm roping him in here to get his opinion on this change, but I would prefer to maintain the current format that is compatible with both of our implementations.

Another way we could go is to standardize the JSON format, finish that code, and then you can use the JSON format for all of your macaroons, as the JSON format will be significantly more verbose and human-readable. Thoughts?

[nitram509]

Makes totally sense to me.
To my understanding, using the default serialization is preferred for smaller size.
And using the JSON serialization is suites better in cases where human readability and verboseness counts.
When there will be progress in standardizing the JSON format, I will adopt this for jmacaroons.
For now, I also will maintain the current format for jmacaroons.

Thanks for clarifying this.