- From: Martin Kreichgauer via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jan 2024 18:26:42 +0000
- To: public-webauthn@w3.org
It took me a minute to understand what's going on here. Basically the chosen value for `userID` (`USER2ML8P7C08R`) is 16 octets long, which is not a multiple of 3, and so the last octet ('R') contains 2 bits of the final sextet, and 6 bits of padding. The base64 spec requires that any encoder must set these padding bits to zero (yielding 'Q' instead of 'R'); but decoders can choose to ignore or reject the non-zero padding bits. (See [RFC 4648, 3.5](https://www.rfc-editor.org/rfc/rfc4648#:~:text=3.5.%20%20Canonical%20Encoding,a%0A%20%20%20specific%20behaviour))
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 octet.
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.)
--
GitHub Notification of comment by kreichgauer
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2013#issuecomment-1885396021 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 January 2024 18:26:44 UTC