Proposal: Use padding free Base64 encoding/decoding about biscuit-rust

[divarvel]

Thanks for the report. The spec indeed mentions the preferred encoding to be url-safe base64, which refers to base64 with an URL-safe alphabet, according to the relevant RFC. This base64-variant still uses = as padding char, which is indeed a self-own from the base64 spec, no doubt about it.

So, while not being a bug, I think the current situation could be improved. My suggestion:

• make serialization not use padding in biscuit rust
• continue accepting padding when deserializing in biscuit rust
• modify the spec accordingly (libs should not use padding when serializing, but must accept both padded and unpadded values)

Optionally we could add a padded variant for encoding but i don't think it's warranted.

wdyt?

@Geal

[baranyildirim]

I changed the title to reflect the nature of the issue. For my use-cases, I've solved this issue by discarding all the = characters doing the issuance process. I think anyone who uses biscuits to authenticate browser based clients will have to do the same. This usability improvement would be nice.

modify the spec accordingly (libs should not use padding when serializing, but must accept both padded and unpadded values)

Yeah, I think the spec change would be great. My only concern would be maintaining backwards compatibility for applications that are already deployed - I guess accepting both padded and un-padded values should take care of that?

[Geal]

accepting padded and non padded in deserialization, but only producing non padded base64 should be fine. The option would only add unneeded complexity and require a new major version since it changes the public API, so let's not add an option for that

[baranyildirim]

accepting padded and non padded in deserialization, but only producing non padded base64 should be fine.

This is only fine if you are assuming people are only using Rust right?
For example, if we are using a Rust token issuer that starts to not pad base64, will the clients/consumers from other languages be able to parse it? I'm fine with making this change, but I just want to make sure we understand that it can break backwards compatibility.