- From: Felix Magedanz via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Jan 2023 14:45:52 +0000
- To: public-webauthn@w3.org
Where things are headed with passkeys, a passkey-first auth flow that presents only an email input with passkey autofill is becoming a reasonable choice and the way we're pursuing with Hanko. We don't want to limit passkey creation to platform/hybrid authenticators because we think that if users own a security key and decide to store the passkey there, they should be able to do so. We also prefer to not differentiate between authenticator types in onboarding and profile UI, and instead just offer "Create a passkey" and let the users decide (via the native UIs) where to store it. Here's the problem: If we offer to create a passkey on a security key, and the user does that, it would be very confusing if this "passkey" is in fact not a discoverable credential, in other words not compatible with the passkey-first auth flow described above. So we decided to go with `residentKey: required`. From our point of view, the proposed changes would not help with the issue of limited storage on physical security keys when it comes to passkeys, because a passkey *needs to be a discoverable credential* for the passwordless flows to make sense. -- GitHub Notification of comment by FlxMgdnz Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1822#issuecomment-1371019535 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 January 2023 14:45:54 UTC