Two typical use cases of Passkey and their required features • UX challenges when introducing Passkey into consumer services • The relationship between Passkey and ID Federation 3
• Generation of hard-to-guess strings • Memorization of multiple passwords • Countermeasures against phishing • Risks of leaks from services and secondary damage • Passkey authentication solves these challenges 5
is vulnerable • System-managed credential management is required • Use of a password manager solves most problems, but it's dif fi cult to make it mandatory • Passkey assumes system-managed credential management and can enforce it on users 6
the service requests authentication with an available Passkey • In the browser dialog, the user selects a Passkey to use, or uses another device's Passkey 18
Passkeys near the HTML input form or when focused, and the user selects from them or uses another device's Passkey • Passkey available with the same UX as password suggestions by Password Manager 21
nearby mobile device are connected via BLE, the mobile device's Passkey can be used • A UX that requires multiple Hybrid fl ows is too bad. It is also important to seamlessly require Passkey registration for each device 23
Utilizing functions/libraries provided for app developers from each platform • https://developer.android.com/training/sign-in/passkeys • Native apps can provide a similar UX using the same credentials as web apps • https://developer.android.com/design/ui/mobile/guides/patterns/passkeys • Web Application integration • Requesting passkey authentication in web browser • Dependent on browser usage patterns and support status 29
Utilizing functions/libraries provided for app developers from each platform • Native apps can provide a similar UX using the same credentials as web apps • Web Application integration • Requesting passkey authentication in web browser • Dependent on browser usage patterns and support status 34
registration • More seamless Passkey registration is required (so that Google automatically generates a passkey when you log in to your Android device) 36
registration • Achieves a single sign-on-like user experience (UX) in authentication • Shares attribute information of the IdP account with the Relying Party (RP) under appropriate consent (such as pro fi le information, email, etc.) 41
not want to use a speci fi c IdP and wish to avoid privacy issues that could arise from consolidating identities • Impact when the IdP account is unavailable (due to outages or account BAN) • Re-authentication requirements are de fi ned in speci fi cations, but are rarely implemented in toC IdPs 42
of ID Federation • Alternative measures when Federation is unavailable • Re-authentication • Applying ID Federation to the weaknesses of Passkeys • Federation w/ Platform Accounts as a recovery method for Passkeys 45
of ID Federation • Alternative measures when Federation is unavailable • Re-authentication • Applying ID Federation to the weaknesses of Passkeys • Federation w/ Platform Accounts as a recovery method for Passkeys 46
their FIDO credentials through the system. It offers the security of public key cryptography along with the convenience of local authentication, and it is evolving to support cross-device and cross-platform use. 48
to choose from several patterns to match the existing sign-in UX. • Passkey can be used for re-authentication to protect speci fi c functions and for fi ne-tuned session management. 49
it needs to be easier and less stressful to register. • For users who are not familiar with Passkey, it's essential to reduce error messages and guide them toward fallback options or recovery methods. • Information that might be changed, like usernames, should be simultaneously updated in both the RP and the Authenticator, and unnecessary Passkeys should be deleted at the same time. 50