Remove "A UNIQUE constraint on (webAuthnUserID + user) also achieves maximum user privacy"?

[kentcdodds]

I might be misunderstanding something here. But it seems like putting a unique constraint on the webAuthnUserId and the user means that users can only have a single passkey. It's my understanding that the webAuthnUserId is the same regardless of which passkey manager you're using. Am I wrong?

The docs I'm referring to:

SimpleWebAuthn-homepage/docs/packages/server.md

Line 74 in 3227716

// SQL: Store as `TEXT`. Index this column. A UNIQUE constraint on

[MasterKale]

Hello @kentcdodds, I want to fully quote the second part of that comment:

A UNIQUE constraint on (webAuthnUserID + user) also achieves maximum user privacy

The idea behind this suggestion is that an RP that wants to achieve a higher bar of user privacy can maintain separate, random user IDs for a given internal user ID, such that the internal user ID isn't ever revealed in the course of registering and authenticating with a passkey. As sometimes internal user IDs can be considered PII (usernames, email addresses, etc... which the spec specifically discourages) I'm trying to encourage RPs here to consider using random IDs instead when registering passkeys.

I'd say whether you map "WebAuthn user IDs" to "internal user IDs" 1:1, or even N:1 if you're aiming for a higher privacy bar, is left up to RPs to decide if it's worth it or not to keep the effort to implement.

Does this all make sense? It's been a while since I've talked about this, I'm happy for some back-and-forth on this if it means clearer documentation.

[kentcdodds]

Thank you very much for explaining this to me. I think it makes sense.

I think it makes sense if the user ID is not randomly generated. How common is that really? I don't think that's actually all that common. That said, we do use the user name or user email address when creating the pass key so the manager knows who to associate with or what account to associate this pass key to. People can have multiple user accounts for a single service, and typically they want to differentiate those pass keys by the username or their email rather than some randomly generated ID. I'm a little bit confused at why the spec discourages using those values for the display name information.

[kentcdodds]

I closed this by accident. I am still curious, and I think there could be some update to the docs necessary here.