toBase64 with base64url alphabet and padding

[panva]

Is it an intended API design that after base64url alphabet toBase64() one needs to remove padding with string manipulation if they need to?

I would expect a padding option in toBase64 to control the behaviour (emit vs omit).

As a module developer / implementer of the various security token formats such as JOSE (JWS/JWE/JWT, ... etc) and PASETO I was hoping this API would not require any further string manipulation to achieve the buffer encoding used in so many standards.

[bakkot]

Yes, that option was removed for simplicity since it is trivial to do in userland, though we could always add it back. See some discussion on the Python tracker of the same issue.

[panva]

I'd much prefer for the option to be in the API.

Trivial or not regular users will not think that's something they need to do, having an option might at least prompt a decision by the user.

I would even go as far as having omit be the default for base64url alphabet since that's what most base64url uses in the internet specifications dictate.

[bakkot]

The default will definitely continue to be including padding. Most uses of base64, url or otherwise, are not in internet specifications, and many decoders enforce presence of padding.

[panva]

That's fair, I'm just coming from a place where it's the absolute opposite. Hence my surprise when the option to omit padding is not even present.

[jasnell]

+1 to adding this option back as suggested

[bakkot]

I'll put something together for the next meeting. Thoughts on naming here? W3C design principles say that optional boolean arguments should default to false, so it would have to be something like omitPadding: true.

[jasnell]

That works, we could also do noPadding = true

[panva]

I'll put something together for the next meeting. Thoughts on naming here? W3C design principles say that optional boolean arguments should default to false, so it would have to be something like omitPadding: true.

That works.

[bakkot]

Opened #60 and put it on the agenda for next month.

[annevk]

I'm a bit concerned that this and other features go beyond exposing internal API to actually requiring new internal API around base64 encoding to be added.

In browsers base64url does not come with padding on encode.

I thought we had come to some kind of understanding on this in #5, but maybe not.

cc @domenic

[bakkot]

The default behavior for padding is not going to depend on the alphabet used, and the default when no options specified is to include padding, to match bota. So yes, that does mean this requires browsers to support "base64url + padding", which they didn't previously (when encoding, anyway; you can, for example, specify a CSP hash-src with base64url + padding). That's intentional; it's necessary to talk to many other systems, e.g. Python.

In #5 we were discussing the default, not the full list of possible behaviors. The default continues to precisely match btoa.

[annevk]

I'm not sure I like that as it makes it more likely the ways we encode data end up diverging even further.

[bakkot]

This isn't a way we encode data. It's a way for users to encode data, for use in talking to other systems. Many of those systems require padding.

[annevk]

I know. I'm saying it makes it more likely. (And it also seems those systems would already be incompatible with various web platform features in that case.)

[bakkot]

It is a goal of this feature to be able to talk to existing systems which speak base64, including some which require padding for base64url. I think that's an important goal. I don't want to make it harder for users to talk to those systems just because they work slightly differently from some other web platform features; that really doesn't seem like a sufficient reason to me. It's certainly important that this feature be able to talk to the web platform feature, but that goal is achieved either way.

[bakkot]

Done in #60.