Use the FIDO Four
FIDO experiences consist of: (1) people (2) browsers (3) relying parties (4) devices. Each have a broad spectrum of needs. Let’s look at a few examples of these four at play.
Example: Registration
Alex has never heard of FIDO and has not previously used her phone’s device unlock to sign in to a website. Her phone supports face biometric and she uses the default Chrome browser on her phone. The relying party doesn’t yet know if she uses face biometric, fingerprint biometric, passcode, or pattern to unlock her phone. So, the relying party uses a fingerprint symbol to indicate a new sign-in method is available. FIDO Alliance has tested this scenario and people see a fingerprint symbol to mean that any number of different device unlock modalities are available.
Related resource
Use the source asset in the UI Kit.
Example: Authentication
Alex previously used her phone’s device unlock to sign in to a website and is now accessing the same website for the first time on her Windows laptop. She uses a Windows Hello PIN to unlock the laptop and uses the Edge browser. The relying party doesn’t yet know if she uses face biometric, fingerprint biometric, passcode, or PIN to unlock her device. The relying party does know that people who use PIN as the device unlock mechanism for FIDO experiences may wonder if the PIN is shared with the RP. So, the RP includes this message in their content: “Once you’ve registered your computer’s PIN, facial recognition, fingerprint, or security key, FIDO verifies it’s really you and doesn’t transmit any of your sign-in information over the internet.”
Related resource
Use the source asset in the UI Kit.
Use FIDO UI controllers
FIDO interfaces are controlled by (1) browsers, (2) operating systems, (3) additional hardware, and (4) the replying party’s website. It’s the relying party’s job to orchestrate how people transition between them.
Example: Registration
A relying party creates a web interface that asks Alex if she’d like to register for a simpler sign-in experience. Alex clicks a button on the website to “Register” and the relying party transitions Alex to the browser interface. The browser interface asks if Alex would like to proceed. Alex chooses “Continue” in the browser interface. She is then transitioned to an operating system interface that asks for her to use Touch ID to continue. She’s using an Apple iPhone in this case. She touches her Touch ID. When the operating system process is complete, the operating system transitions Alex back to the relying party website. Knowing this, the relying party shows a “Success” message and illustration.
1: RP: “Register” ▶ 2: Browser: “Continue” ▶ 3: OS: “Touch ID” ▶ 4: RP: “Success”
The relying party doesn’t need to include step number four, but does so because it makes the experience seamless for Alex. In some cases, the relying party doesn’t need step number one either, but does so for the same reasons.
Example: Authentication
Alex clicks a button on the website to “Sign in” and the relying party transitions Alex to an operating system interface that asks for her to use Touch ID to continue. She’s using an Apple iPhone in this case. She touches her Touch ID. When the operating system process is complete, the operating system transitions Alex back to the relying party website. Knowing this, the relying party shows a “Success” message and illustration.
1: RP: “Login” ▶ 2: OS: “Touch ID” ▶ 3: RP: “Success”.
The relying party doesn’t need to include step number three, but does so because it makes the experience seamless for Alex. In some cases, the relying party doesn’t need step number one either, but does so for the same reasons.
Promote FIDO registration
To ease user adoption of FIDO, it’s important to promote FIDO registration at multiple points along a user’s journey through your website. Take advantage of biometric iconography – differentiated based on the user’s platform, Mac or Windows – to help explain and show the value of FIDO authentication.
Example: Spotlight
It’s the first day that an RP has turned on FIDO. Alex has never used FIDO and goes to sign into her website. She signs in on a computer that is capable of using Touch ID. She sees an attention-grabbing spotlight page takeover that asks her to register.
Related resource
Use the source asset in the UI Kit.
Example: Callout
It’s the second day that an RP has turned on FIDO. Alex has never used FIDO and goes to sign into her website. She signs in on a computer that is capable of using Touch ID. When she does so, she notices a subtle call-to-register at the page’s bottom.
Related resource
Use the source asset in the UI Kit.
Example: Toast notification
It’s the second day that an RP has turned on FIDO. Alex has never used FIDO and goes to visit her website’s “settings” page. One day, she does so on a computer that is capable of using Touch ID. When she does so, she notices a toast notification prompting her to register.
Related resource
Use the source asset in the UI Kit.
Give users control
All message invitations should include a way for the user to dismiss the message for the current session. Users expect dismissed messages to re-appear across the next few sessions (e.g., three sessions total).
Example: Ability to dismiss
Alex is signing into the website when she encounters a “pop-up” message prompting her to register for FIDO authentication. The message includes an option to proceed or dismiss. Alex is in a rush and clicks dismiss, knowing she can resume in the future.
Related resource
Use the source asset in the UI Kit.
Use consistent navigation
Given the number of interfaces (e.g. browser, operating system, additional hardware) that a person experiences during a FIDO authentication, it’s important for relying parties to use consistent navigation – especially when it comes to allowing users to go back, switch authentication methods, or exit the sign-in entirely. Doing so gives users a sense of control and freedom during their sign-in experience.
Example: Switching methods
Alex changes her mind when attempting to use Touch ID (provided by FIDO), and now prefers to use her Security Key. The relying party evokes the browser to give her the option to easily switch authentication methods.
Related resource
Use the source asset in the UI Kit.
Confirm success or failure
Given the number of interfaces (e.g. browser, operating system, etc.) needed to register or use a FIDO authenticator, it’s important to maintain a high visibility of system status. In past research, we’ve discovered a lot of variability in how much information they provide about the interaction to relying parties. A browser, for example, may communicate an instance of failure without providing an exact reason. A relying party can handle this by using the following messages.
Example: Registration success
Alex successfully sets up a FIDO authenticator after clicking on the “Register” button on the website (i.e. she has clicked “Continue” on the browser interface, transitioned to her operating system interface, and used Touch ID). The relying party displays a success message.
Related resource
Use the source asset in the UI Kit.
Example: Registration failure
Alex fails to set up a FIDO authenticator while using her operating system interface. She is unable to register her Security Key. This failure is communicated back to the relying party, who now displays an error message.
Related resource
Use the source asset in the UI Kit.
Example: Authentication success
Alex successfully authenticates using FIDO. To celebrate her success and make the simpler sign-in feel satisfying, the relying party displays a success message on a 2-second timer before logging her in.
Related resource
Use the source asset in the UI Kit.
Example: Authentication failure
Alex fails to authenticate using FIDO. Her Apple iPhone’s Touch ID sensor might be broken. To communicate this failure and provide effective next steps, the relying party displays the following error message.
Related resource
Use the source asset in the UI Kit.
Pair symbols with methods
For the easiest experience with FIDO authentication, it’s important for relying parties to show an icon that represents the authentication method that is available for registration and use. For example, if only biometric is available, then a fingerprint icon should display; similarly, if only security keys are available, then a key icon should display.
Related resource
Use the source asset in the UI Kit.
Ensure experiences are usable for all, not just some
One billion people or 15% of the world’s population can’t use the full potential of the digital world because they experience some form of disability. To ensure that all users can enjoy the benefits of FIDO authentication, it’s important for relying parties to follow accessibility best practices using the Web Content Accessibility Guidelines is an open, international standard maintained by the World Wide Web Consortium.
Example: Visual difficulties
Alex has low vision and requires a screen reader, voice control, or screen magnification software to sign in to her website. To help Alex do so, the relying parties follow the latest guidelines to ensure that each page works for assistive technologies, including screen text magnification.
Example: Mobility difficulties
Alex has an inability to use her hands fully and requires alternatives to mouse or trackpad navigation. To help her sign-in, the relying party follows the latest guidelines to ensure she can navigate using a switch system or head mouse.
