Overview

Topics: Consumer, Passkeys, Account Creation
Relevant moments in the customer journey: Awareness > Consideration > Enrollment > Management > Authentication
Created: 6 May 2023

Allow people to create new accounts with a passkey (and no password).

  • Request username without showing a password field.
  • Reassure people that creating a passkey is part of the account creation to enhance interest and trust in passkeys.
  • Passkeys are new, but signing in with touch or face was familiar to all and trusted by many.
  • Include fallback authentication method(s) based on your security policy and business needs.

Outcomes

  • Decrease account creation times by removing the need to create a password and increasing passkey creation success.
  • Increase the use of phishing resistant authentication and achieve authentication assurance level 2 (AAL2) without multiple authentication steps.
  • Reduce account recovery concerns as passkeys may be synced across a cloud provider to enable passwordless sign-ins across the user’s devices. 
  • Reduce user cognitive load by eliminating auth methods like SMS OTP.
UX architectural diagram of the workflow for deprecate SMS OTP.

Flow

Step 1

Select the “Sign in or create account” button.

Step 2

Enter an identifier (email in the case of DigitalBiz) to “Sign in or create account.”

Step 3

Confirm displayed email address to “Create Account.”

Step 4 (a)

Create a passkey for the displayed email address.

Step 4 (b)

Android: “Use your screen lock” dialog.

Step 4 (c)

Android: “Use your screen lock” success.

Step 4 (d)

iOS: “Sign In” dialog.

Step 4 (e)

iOS: “Sign in”, “done.”

Step 5 (a)

Account created confirmation: close overlay or View account confirmation.

Step 5 (b)

Confirmation of account created without a passkey.

Step 6

View the passkeys “card” in account settings.

To view full screen, hover the prototype, then tap the expand icon.

To view full screen, hover the prototype, then tap the expand icon.

  • Step 1: Select the “Sign in or create account” button.
    On the homepage, when people are in an unauthenticated state, display a single, discoverable call to action to sign in or create a new account.
  • Step 2: Enter an identifier (email in the case of DigitalBiz) to “Sign in or create account.”
    After a person selects the “Sign in or Create Account” button, display a page with the headline “Sign in or Create Account,” with an editable text field titled “Email address,” filled with the instructional text, “Enter email address” as a call to action to begin signing in or creating an account. Before people enter a valid email, display an action button titled, “Continue,” in an inactive state to emphasize that entering an email is the first step to signing in or creating an account. If they entered a valid email address, display the “Continue” button in an actionable state. If the email is not recognized by your systems, create a new account associated with the email address entered.
  • Step 3: Confirm displayed email address to “Create Account.”
    Prior to displaying the passkey creation OS dialogs, display a page that emphasizes an account is being created with the email address shown. Use the headline “Create account” and instructional text “Create your account using ” displayed prominently, to prime and reassure people that they’re on the right path toward account creation, prior to encountering the unfamiliar concept of passkeys. Allow the people to confirm or update their unique identifier to help ensure successful account creation.
  • Step 4: Create a passkey for the displayed email address.
    Display the passkey OS dialogs to allow people the choice to create or decline creating a passkey for the specified email. If they opt to create a passkey (by selecting the “Continue” button on Android and the “Confirm” button on iOS), the mobile OS prompts them to use their screen lock to authenticate. Android people can decline to create a passkey by selecting the “Cancel” button and iOS people can decline to create a passkey by selecting the “X” in the upper right of the dialog. If the passkey creation was successful, a passkey creation confirmation messaging from the OS is displayed, and disappears automatically; no action is needed.
  • Account created confirmation: close overlay or View account confirmation.
    For all people, both those who created a passkey and those who declined to create a passkey, display an “Account created” confirmation message via an overlay on top of the homepage, with the authenticated profile icon visible. Lead with a “Welcome” headline that matches your brand voice and tone. At this point, all people, those who opt to create a passkey and those who don’t, are authenticated. Offer a “View your account” button as the primary action, to navigate people to view information about or disable their new passkey within Settings. List all the sign-in methods available. Display an “X” affordance to close the dialog, to allow people to get started with their site activities as well.
  • Step 6: View the passkeys “card” in account settings.
    If people select the “View account” button in Step 5, navigate to Security Settings. To confirm that a passkey has been created with the new account, display a passkey logo with a check mark as well as the text “Passkey created,” and a link titled “View passkeys” that navigates down the Settings page to the passkeys “card.” Under the heading, “Sign-in options,” specify all of the methods they have available to authenticate on your site, including a passkey and the alternative method of your choice when a passkey is not available. Provide the option for people to disable passkeys and include messaging that describes how they would access their account after disabling a passkey. For example, “If you disable passkeys, you’ll sign in with your password or with a code DigitalBiz sends to your email.” Passkeys are a new term, a new visual icon, and a new authentication method for consumers. Whenever possible, help people understand the nature and value of passkeys by comparing them to familiar concepts, visuals, and experiences. For example, Use the passkeys icon (unknown) alongside device icons and a lock icon. In Settings permanently display messaging that explains why use passkeys, what is a passkey, and where are passkeys saved.

Content

Learn what user-tested button labels, phrases help people. Copy and edit content examples to suit your needs.


Why should I use passkeys?
With passkeys, you don’t need to remember complex passwords.

What are passkeys?
Passkeys are encrypted digital keys you create using your fingerprint, face, or screen lock.

Where are passkeys saved?
Passkeys are saved in your password manager, so you can sign in on other devices.

UX Research

On the homepage, offer one affordance for both sign-in and account creation when people are in an unauthenticated state.

The research indicated that the action of creating an account was more discoverable on DigitalBiz when the sign-in and account creation options were combined, rather than surfacing the account creation option after people opted to sign in. In addition, some participants reported that occasionally they are uncertain whether they have an account, and a multipurpose button serves their needs.

Eliminate the password field.

The research indicated that beginning both the sign-in and account creation processes with only a prompt to enter an email address (no password field) helped foster the perception that account creation and signing in with a passkey are simple and short processes that do not require passwords. This practice is sometimes referred to as an “identifier-first” approach or “home realm discovery.”

Reassurance from the RP that creating a passkey is part of account creation enhances interest and trust in passkeys.

The research indicated that being prompted to create an (unfamiliar) passkey instead of a password violated participants’ expectations about how account creation works. When testing early iterations of the account creation design, we discovered that moving directly from Step 2 (enter email to sign in or create an account) to the unfamiliar “Create a passkey” OS dialog (Step 4), while shorter, was disorienting for participants. It undermined their confidence that they were on the right path to create an account, and led some participants to abandon account creation prior to creating a passkey.

Passkeys are new, but signing in with touch or face was familiar to all and trusted by many.

The research indicated that being prompted to create an (unfamiliar) passkey instead of a password violated participants’ expectations about how account creation works. None of the participants had heard of passkeys, and many initially expressed uncertainty about the nature and purpose of a passkey as it related to their new account.

Based on the text and symbols in the “Create a passkey” OS dialogs, most participants inferred that a passkey was a new sign-in option that involved the OS using their device’s authentication system (e.g., face or touch) to confirm their identity instead of a password. For many participants, signing in with face or touch was a familiar and trusted process, perceived to be fast, easy, and secure, based on previous experiences with mobile apps or password managers. Several participants mentioned that signing in with face or touch is fast and easy compared to using a password, and biometrics are unique identifiers that are difficult to hack.

“Screen lock” was an unfamiliar term for many consumers, which made it difficult for PIN, passcode, or pattern people to recognize that passkeys would also work for their current device settings.

The research indicated that many participants spontaneously mentioned not knowing what the term “screen lock” meant. This lack of understanding could serve as a barrier to passkey adoption for consumers who use a PIN, passcode, or pattern as a screen lock on their passkeys-eligible devices.

Privacy and security concerns are potential barriers to passkey adoption for some consumers.

The research indicated that although many participants expressed feeling comfortable creating a passkey based on positive experiences signing in via face or touch on mobile apps, privacy and security concerns led some participants to decline creating a passkey.

Some participants viewed a passkey as single-factor authentication, which they perceived to be less secure than MFA involving a password and a code or link. Other reluctant participants described being uncomfortable using face, touch, PIN, or passcode to sign in to a mobile-based shopping site due to uncertainty about where that information was stored and who might have access to it (i.e., the RP, Apple, or Google). As adoption of passkeys becomes more common, these privacy and security concerns could be addressed through education outside of the account creation process. 

Anticipate that some new people who seek to create a new account on your site will decline to create a passkey. For new people who decline to create a passkey, allow passkey creation to gracefully fallback to another authentication model.

Rollout strategy

  • For service providers may choose phased rollout strategy which initially only allows people to create passkeys from their account settings. Then, as data is gathered about the passkey sign in experiences unique to their needs, they can expand the number of places where a passkey can be created, including during account creation.

Ecosystem

  • Passkeys may require specific hardware or software support on users’ devices. Ensure that users are aware of the compatibility requirements for using passkeys and provide guidance on compatible devices and browsers.
  • In the native mobile app context, signing in with a passkey differs from the biometric sign-in experience that has existed for many years. Signing in with a passkey requires an additional tap.

Security

  • DigitalBiz gracefully falls back to an email OTP. The graceful fallback option you choose should match your unique security and business goals. Plan your UX in accord with your unique security and business needs. The guidelines focus on UX concepts that are unique to FIDO with synced passkeys. You will see various forms of identity proofing and non-FIDO authentication examples throughout this work. The guidelines do not intend to prescribe security guidelines for identity proofing or other non-FIDO authentication mechanisms as they are unique to each RP and based on their own unique business needs and security policy. 

Code

Passkeys.dev contains the basics to get started with passkey development as well as links to several tools, libraries, references, and demos.

It’s created by the W3C WebAuthn Community Adoption Group and members of the FIDO Alliance.

https://passkeys.dev