- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Mon, 24 Jul 2023 11:13:49 +0000
- To: public-webauthn@w3.org
> - **Why not make those fields NOT required?** > - What would break, what speaks for leaving them required? > - Is it bad for some reason to leave them blank? This:  That's what you get if you create two passkeys with `name: "", displayName: ""` with Chrome's virtual authenticator. And similarly, if you create two passkeys with `name: "Passkey for demo.yubico.com", displayName: "Passkey for demo.yubico.com"` on a YubiKey, this is what you'll see in Firefox:  How do you propose that "UX programmers [...] think about usernameless entries" when there's more than one? Remember, **the browser cannot assume that the user will have only one credential per domain**. > in my opinion multiple accounts in a domain are not normal Nevertheless, there are many valid reasons a user may have them. When they do, the UI needs to be equipped to help the user distinguish which passkey goes to which account. That is why these fields are required. > * What is the actual solution for usernameless services? What should I do with these 2 username fields? Ask the user for a value, maybe describe it as a "passkey label". You do not need to store that value; it will never be conveyed back to you. Or set all three to the same user ID, if you have one suitable for human consumption. Or generate a random name for the account and its passkeys. As long as there's something the user can use to distinguish passkeys for different accounts. -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1647710746 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 24 July 2023 11:13:51 UTC