Refine JSON serialization to use UTF-8 encoding for `user.id` and `userHandle` about webauthn

[emlun]

I don't think a minor convenience improvement is worth breaking the pattern and making user handles behave differently from all other binary values. In my own software development experience, exceptions (AKA broken invariants) are the root of (almost) all evil. I don't think this exception seems valuable enough to defy that principle.

Also in my own experience developing apps around WebAuthn, I find it convenient enough to just use the base64 encoding of the user handle as the canonical representation of it - not least because strings in JavaScript can be compared using the === operator while Uint8Arrays cannot. I don't think it needs special treatment just in case its binary form also happens to be human-readable.

[lgarron]

I agree with @emlun. The spec treats the user handle as a binary string (rather than an encoded text string) in various ways, and I think it would be a liability to change that.

Further, supporting UTF-8 would imply that it is reasonable to encode something more structured or even user-provided instead of random. This could be sufficiently secure, but the use of an opaque binary string encourages a secure implementation by default.

[MasterKale]

A side effect of this change might be that RP's feel empowered to use PII-containing identifiers here since they're already strings. However I think we could easily enough suggest base64url-encoding 64 random bytes and then using that string as user.id when calling parseCreationOptionsFromJSON() and the user privacy considerations in https://w3c.github.io/webauthn/#sctn-user-handle-privacy are maintained.

[arianvp]

The spec is pretty clear that userId should not be a string identifier but a random array buffer. Those will almost never be valid UTF-8 strings. Encoding as UTF-8 seems incompatible with what the spec wants? Or do we also want to change that?

the Relying Party MUST NOT include personally identifying information, e.g., e-mail addresses or usernames, in the user handle. This includes hash values of personally identifying information, unless the hash function is salted with salt values private to the Relying Party, since hashing does not prevent probing for guessable input values. It is RECOMMENDED to let the user handle be 64 random bytes, and store this value in the user account.

[kreichgauer]

It took me a minute to understand what's going on here. Basically the chosen value for userID (USER2ML8P7C08R) is 14 base64 characters (sextets) long. Each group of 4 base64 sextets decodes to 3 octets/bytes, but 14 is not a multiple of 4. And so the final two sextets ('8R') decode to one octet, with remaining 4 bits remaining as padding. The base64 spec requires that any encoder must set these padding bits to zero (yielding 'Q' instead of 'R' for the final sextet); but decoders can choose to ignore or reject the non-zero padding bits. (See RFC 4648, 3.5)

So if you pass the userID string through Go's encoding/base64 in strict mode e.g., it will reject the string. Presumably, browser base64 decoders are more forgiving and accept the non-zero padding bits, but then when the re-encode the user handle bytes, they follow the spec and correctly produce 'Q' as the last sextet.

I agree with the other comments here. Consistency seems more important, and we shouldn't handle encoding of these individual fields differently.

(I will look into whether we can make Chromium's base64 decoder stricter for the JSON parsing methods.)

[arianvp]

You need to use base64.RawURLEncoding . That's the one that discards padding

[kreichgauer]

The issue is with padding bits within a final sextet. RawURLEncoding I think controls the '=' padding character to pad the string into multiples of 4.

[kreichgauer]

(Sorry, I mixed up some things in my original response above. Updated for correctness.)

[MasterKale]

Alright, this isn't necessarily a hill I want to die on, but I figured I'd give it a shot. I know WebAuthn has recommended user.id being 64 random bytes for a long time now, I just thought there might be a developer experience win in here for RP's that have effectively random identifiers already in play.

Thanks for humoring me ✌️

[emlun]

Yeah, I do agree that this could be useful. Many applications I've worked with use UUIDv4s as primary account identifiers and just use the UTF-8 encoding of those as the user handle. It is sometimes a bit of a hassle to have to juggle the various representations of that, but ultimately I think that introducing a special case for user handles in JSON I/O would replace a small problem with a much bigger one.