- From: Felix Magedanz via GitHub <noreply@w3.org>
- Date: Thu, 10 Jul 2025 10:05:54 +0000
- To: public-webauthn@w3.org
**Our experiences from years of running passkeys.io and other consumer-oriented passkey deployments:** First, we designed the passkey.io demo with a combined login/sign up flow, meaning a UI presenting an email input, a "Continue" button, and a "Sign in with a passkey" button. Passkey autofill was enabled on the email input field. A new user is supposed to fill in their email address to create a new account, and create a passkey in the next step. To experience a passkey sign in, they'd have to sign out from the demo's profile management (authenticated state), and then use passkey autofill or the "Sign in with a passkey" button on the combined login/sign up UI (unauthenticated state). <img width="378" height="288" alt="Image" src="https://github.com/user-attachments/assets/bad27a4b-319f-4ef7-bbb9-1ca45ad63432" /> Since the website's whole purpose is to inform users about passkeys and let them try "the real thing" in their browsers, many users didn't know that you first need to create a passkey in order to sign in with it. So new users happily clicked "Sign in with a passkey"[^1] and were utterly disappointed to find themselves presented with a QR code which, even if they tried scanning it with their phone, wouldn't get them them any further. That was usually the point where frustration got the upper hand and the user quit the attempt to "try passkeys" and said to themselves "This is supposed to be the password replacement my Grandma should be able to use? I don't think so". [^1]: Similar to what they've been used to since forever from 3rd-party OAuth login buttons, which usually don't care if the user already has an account or not, and, after successfully authenticating with the 3rd-party, either create a new account, or sign in the user if an existing account is linked to the 3rd-party email address. To improve the situation, we decided to go back to a more "classic" login with separate login and signup UIs and links to alternate between them. That way, there would be no passkey button for new users that need to create an account first. <img width="350" height="302" alt="Image" src="https://github.com/user-attachments/assets/fe7dcedd-51bd-4d46-9b52-55e252d1d524" /> <img width="360" height="211" alt="Image" src="https://github.com/user-attachments/assets/26243093-9dd4-4c97-967d-3d8a3754e44f" /> So far, so good. But this design also has drawbacks. Now the user has to remember if they already have an account. And are required to make an active decision whether they want to "Create an account" or "Sign in". Sure, that's nothing new, but still. On the majority of real login/sign up pages, this problem sort-of solved itself by 80+% of users simply choosing "Sign in with Google" and be done with it. How cool would it be if passkeys could be improved to offer the same "fire and forget" convenience of 3rd-party OAuth buttons, but without the need to actually involve a 3rd party? Exactly what we've been hoping for with "get or create". IF the relying party want's to collect a username or email address (we speak to more and more RPs who don't care and would be fine with a random username for authentication), they can prompt the user for it later and even update the passkey via the new APIs. We think "get or create" to enable this use case would significantly help further adoption of passkeys, and finally enable a truly simplified yet secure onboarding and login UX. -- GitHub Notification of comment by FlxMgdnz Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1568#issuecomment-3056711200 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 10 July 2025 10:05:55 UTC