Data encoding question

[paulf69487623]

Hello,

In another thread I asked about cold start performance in Lambda. I've also been experimenting with the go-webauthn/webauthn fork of the DuoLabs Go library. That library doesn't have any client-side support, so I've been using SimpleWebAuthn/Browser with it. While working on that, I discovered a difference in how the UserHandle is encoded.

In SimpleWebAuthn/Browser, the UserHandle is encoded as a UTF8 string, while in go-webauthn/webauthn, it is encoded as URL-safe base64. Based on the w3c docs, these are all ArrayBuffers. For all of the others fields in this type, SimpleWebAuthn uses URL-safe base64. Only this one type seems to be handled differently. Links below to the specific lines of code and the section of the docs I was referring to.

I'm just curious if this was an intentional design choice, or just a difference between implementations. Other than this one type, the encodings seem to be pretty consistent. I'm able to work around it if this is by design.

Thanks,

Paul

https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/methods/startAuthentication.ts#L93
https://github.com/go-webauthn/webauthn/blob/master/protocol/assertion.go#L35
https://w3c.github.io/webauthn/#dom-authenticatorassertionresponse-userhandle

[MasterKale]

My decision to treat userHandle differently was intentional, it changed in PR #120. It was a question of developer ergonomics:

While dogfooding my own library it confused me why I'd pass in '5c240dc4-bfdf-474b-929c-c4484008a302' as user.id in attestation options, but get back 'NWMyNDBkYzQtYmZkZi00NzRiLTkyOWMtYzQ0ODQwMDhhMzAy' as userHandle in the assertion.

I realized that userHandle, returned in an assertion response, is Base64URL-encoded before coming out of startAssertion() for transmission back to the RP. It doesn't make any sense to do this, though, as the value is never Base64URL-encoded coming out of generateAttestationOptions() or within startAttestation(). This PR fixes this behavior so that the value of userHandle in an assertion response is the same as the value of user.id passed into navigator.credentials.create().

No one complained so it's been that way ever since.