Is the user.id parameter a printable string or a opaque sequence of bytes?

[acsellers]

I was trying to use this library to simplify the JSON decoding/encoding associated with registering/authenticating quirks in the browser with webauthn, but I ran into a weird issue.

Based on the Spec, I filled the user.id field with 64 bytes of random data, but when your library decodes the field, it doesn't use the base64URLStringToBuffer function like I would have expected. Instead it appears to decode the field as a printable string (utf8StringToBuffer)?

Is there something I'm missing?

[MasterKale]

My thinking here has been that how the Relying Party chooses to identify users during registration should be easy to see when debugging (in the browser console) during auth. If the RP has a privacy-preserving, prescribed format for user identifiers (e.g. "USER12345") that should continue to be supported, but an RP could just as easily generate unique identifiers from base64url-encoded random bytes (e.g. "aW93dTM1YmhucTt3ajRrdG5ocXVvNDZuaHBpcXU0Nmg".) I didn't want SimpleWebAuthn to impose requirements for user identifiers that might put undue burden on RP's implementing WebAuthn for the first time.

That said I've had this conversation recently over in the py_webauthn project that I professionally maintain at my day job:

duo-labs/py_webauthn#187 (comment)

tl;dr: I ended up updating that library to accept an optional bytes (i.e. Uint8Array in JS) for user ID when generating registration options, and that method will return a random user identifier if one is not provided. This behavior was in line with the JSON serialization logic I championed into L3 of the WebAuthn spec.

It's probably time I make a similar change here for the same reasons 🤔

[Ajz316]

Good day,
Not sure if it is related, but posting here @MasterKale as you suggested.

I came across this conversation (fix/simplify-encoding-user-handle-in-assertion-response) while debugging an issue in reusing a passkey that was created by another client layer on the same machine/laptop. It seems the other client layer (another JavaScript library that persisted or created the passkey) is doing what this library was doing prior to this pull request i.e. converting the user.id from Base64Encoding to its original value and using that as passkey ID.
So, my understanding is that user.id is generally a RP generated unique code, could be a HEX string as well. But for correct transmission and consistent interpretation we use Base64encoded version for communication (over the HTTP layer) purposes. It is up to the client to then decode it and store the correct ID on user device. Now, with this pull request(PR 120) my understanding is we have kept it simple and no longer decoding Base64Encoded string but storing it on client device straightaway, as that is what the RP needs anyway in all communications. Seems simple, well contained and should work in majority of the cases, but I think with synced passkeys it might fail? Just seeing if it will be a possibility to restore the original implementation may be controlled by a flag so that it is backward compatible with existing consumers of this library?

[Ajz316]

Hi @MasterKale
Have you been able to progress in this space or considered bringing the ability to pass base64Encoded string in userHandle? We have a release in about a month's time and given that synced passkeys are a mandatory requirement for us this feature will really help. Currently, it is failing for cross-device interoperability i.e. where a passkey is created in Android device (native app) and attempted to use in Portal (simplewebauthn/browser library). I guess if this line could support both (bufferToBase64URLString and bufferToUTF8String) based on a flag so that it remains backwards compatible for consumers who may already be using bufferToUTF8String flavour.

Thanks and regards

[MasterKale]

Hello @Ajz316, the fate of userID is captured in #530, I'm still inclined to make it an optional Uint8Array to discourage use of PII and make it easier to understand how it's used especially as WebAuthn has evolved.

No ETA on a release though. I'm slowly building up a v10 release that'll include some breaking changes and this will be one of them.