Add support for a mixed base64 and base64url encoding?

[lucacasonato]

Elsewhere, @bakkot says that apparently Node.js's Buffer.from(x, "base64"), as well as CSP, support mixing base64 and base64 URL in the same string, when decoding. That might be an encoding worth supporting as well.

Cross-linking to tc39/proposal-arraybuffer-base64#7 (comment) for related analysis.

Originally posted by @domenic in #6 (comment)

[lucacasonato]

Did some digging:

• Go does not seem to have a built in API for this.
• Dart also does not have a built in API for this.
• Node seems to do this by default, with no way to opt out:
  
• Deno allows decoding base64 with the base64url decoder, but not the other way around (open bug):
  
• atob does not support base64url at all.

We could consider a base64mixed encoding (that is only valid for decoding) that behaves like Node "base64".

[TotallyNotChase]

I don't think there's a real usecase for base64mixed. Most languages seem to explicitly differentiate between the 2 encodings. base64mixed would seem like a made up encoding, created just for node "compatibility". What would the encoder even be? Does it choose the base64 characters, or base64url characters during encoding? Why one but not the other?

Also, on a completely different note, why does base64url.decode have an extra step to add padding - isn't this already handled by base64.decode, due to the usage of atob?

[panva]

Within the JOSE family of specifications, only url-safe base64 (aka base64url) is used.

A mixed decoding is however very useful to cope with non-standard compliant JOSE producers. Usually it's easy enough to reach out to a small vendor to have them fix their implementation or dismiss the problem as non-conform. Unfortunately though, a very widely known and used cloud IaaS provider stubbornly refuses to fix their JOSE-producing implementation and so JOSE verification libraries need to cope with their implementation which 1) uses the url safe base64 alphabet (62 and 63) but 2) unfortunately includes a padding 😠.