This is a great week to be working in Identity Standards, as we at Microsoft celebrate the release of our first ever WebAuthn Relying Party. This one relying party enables standards-based passwordless authentication at Xbox, Skype, Outlook.com and more. But what are the actual pieces of the puzzle and how do they fit? Read on for the big picture of how the W3C WebAuthn and FIDO2 CTAP2 specifications interact. We will start with the industry standards perspective, and then at the end we will summarize how Microsoft implements the various roles.
To understand how FIDO2 authenticators work, you need knowledge of two specifications in two different standards bodies. The WebAuthentication (aka WebAuthn) spec lives at W3C (where the browser makers meet) while the Client-to-Authenticator (aka CTAP2) spec lives at the FIDO Alliance (where hardware and platform folks have joined to solve the problem of Fast IDentity Online).
The Big Picture
CTAP2 and WebAuthn define an abstraction layer that creates an ecosystem for strongly authenticated credentials. Any interoperable client (such as a native app or browser) running on a given “client device” can use a standardized method to interact with any interoperable authenticator – which could mean a platform authenticator that is built into the client device or a roaming authenticator that is connected to the client device through USB, BLE, or NFC. Authenticators securely create and locally store strong cryptographic keys at the request of clients, under the condition that the user must consent to the operation via the performance of a ‘user gesture’. Once these client-specific keys are created, attestations can be requested and sent to the clients for the purposes of registration and authentication; the type of signature performed by the private key reflects the user gesture performed.
When CTAP and WebAuthn are drawn, it looks something like the picture below. The light blue dotted arrows are light blue and dotted because the exact way in which platform APIs are exposed to clients is an implementation choice.
The cast of characters in a combined WebAuthn/CTAP2 dance are:
Relying Parties & Clients
Relying parties are web or native applications that wish to consume strong credentials. In the native case, the relying party running on the client device can also act as a WebAuthn client to make direct WebAuthn calls. In the web case, the entity that wants to consume the credential cannot directly interact with the WebAuthn API, and so must broker the deal through the browser. Do not confuse FIDO relying parties with federated relying parties, there is no single sign-on in the above picture.
Client Device
The client device is the hardware hosting a given strong authentication. Laptops and phones are examples of client devices.
Platform Authenticator
A platform authenticator is usually resident on a client device and cannot be accessed via cross-platform transport protocols such as USB, NFC or BLE. Examples of platform authenticators include built-in laptop fingerprint readers or facial recognition using smartphone cameras.
Roaming Authenticator
A roaming authenticator can connect to multiple client devices, and interaction must be negotiated over a supported transport protocol. Examples of roaming authenticators might include USB security keys, BLE-enabled smartphone applications, or NFC-enabled proximity cards. Authenticators may support CTAP1, CTAP2, or both protocols.
CTAP2 Platform/Host
The platform (also called the host in the CTAP2 spec) is the part of the client device that negotiates with authenticators. The platform is responsible for securely reporting the origin of the request and for calling the CTAP2 Cbor APIs. In cases where the platform is not CTAP2-aware, the clients themselves must take on more of the burden and the internals of this diagram might best be drawn a little differently.
Many relying parties and clients can interact with many authenticators on a single client device. A user might install multiple browsers that support WebAuthn, and might simultaneously have access to a built-in fingerprint reader, a plugged-in security key, and a BLE-enabled mobile app. The WebAuthn API enables clients to make requests to authenticators - to create a key, get an assertion about a key, report capabilities, manage a PIN, and so on.
About that Interoperability Thing
Before there was WebAuthn and CTAP2, there was U2F and CTAP1. U2F is the FIDO Alliance’s universal second factor specification and there are a lot of authenticators that speak CTAP1 and manage U2F credentials. WebAuthn was designed to be interoperable with CTAP1 Authenticators, and U2F credentials can still be used, as long as no FIDO2-only functionality is required by the relying party.
Some of the options that FIDO2 authenticators have already implemented and that WebAuthn relying parties might require include:
- Keys for multiple accounts can be stored per relying party
- Client PIN
- Location (the authenticator returns a location)
- HMAC-secret (this enables offline scenarios)
Other options are cool and might be useful in the future, but haven't been seen in the wild yet:
- Transactional approval
- User Verification index (this allows servers to understand if locally stored biometrics have changed over time)
- User Verification Method (the authenticator returns the exact method)
- Biometric Performance Bounds (the relying party can specify acceptable false acceptance and false rejection rates)
Future blog posts will explore the benefits and the inner working of these interoperability points (some of which are documented in the specification but have not been implemented anywhere).
Microsoft Implementation
The Microsoft FIDO2 implementation has been years in the making: software and services are implemented independently as standards-compliant entities. As of the Windows 10 October 2018 release, all Microsoft components are updated to use the latest WebAuthn Candidate Release, which is a stable release not expected to normatively change before the specification is finally ratified. Because Microsoft is among the first in the world to deploy FIDO2, some combinations of popular non-Microsoft components won’t be interoperable yet – but give it time. Please remember that alignment on specifications like this does not happen overnight. As an industry, we will get to a place where all the components speak all the specs with all the right extensions supported, and then things will be fun.
Here is an approximate layout of where the Microsoft bits go:
- Microsoft Account plays the part of a WebAuthn Relying Party. If you aren’t familiar with Microsoft Account, it is the login service for services like Skype, Xbox, Outlook, and many other sites. The login experience uses client-side javascript to trigger Edge to talk to the WebAuthn APIs. Microsoft Account requires that authenticators have the following capabilities:
- Keys must be stored locally on the authenticator and not on a server somewhere
- Offline scenarios must work (see: hmac-secret)
- Users must be able to put keys for multiple user accounts on the same authenticator
- Authenticators must be capable of unlocking a TPM with a clientPIN if necessary
Note that these are the requirements as of today; for the authoritative and maintained list of the extension support needed to be considered “microsoft-compatible”, please see the docs. Because Microsoft Account requires features and extensions unique to FIDO2 CTAP2 authenticators, this site will not accept CTAP1 (U2F) credentials.
- Microsoft Edge plays the part of a WebAuthn Client. Edge can handle the UI for the above listed WebAuthn/CTAP2 features, and also supports the AppID extension. Edge is capable of interacting with both CTAP1 and CTAP2 authenticators, which means that it can facilitate the creation and use of both U2F and FIDO2 credentials, however Edge does not speak the U2F protocol, so relying parties must use the WebAuthn specification only. Edge on Android sadly does not support WebAuthn.
- Authoritative information on Edge support for WebAuthn and CTAP can be found in the Dev Guide.
- Windows 10 plays the part of the platform, hosting Win32 Platform WebAuthn APIs that enable clients to interact with Windows Hello in order for users to be prompted and interactions with authenticators to take place. The inner workings of Windows Hello are definitely worthy of a blog entry of their own.
- Roaming Authenticators
You might notice that there is no “Microsoft” roaming authenticator. That is because there is already a strong ecosystem of products that specialize in strong authentication, and every one of our customers (whether corporations or individuals) have different requirements for security, ease of use, distribution, and account recovery. If you want to see the ever-growing list of FIDO2 certified authenticators, you can find that list here: https://fidoalliance.org/certification/fido-certified-products/. The list contains built-in authenticators, roaming authenticators, and even chip manufacturers with certified designs, and this is just the start! While USB security keys are the most common roaming authenticator today, they may not be tomorrow; stay tuned for lots of innovation in the areas of NFC and BLE, and the integration of FIDO2 into smartphone apps, smart cards, fitness trackers, and who knows what else.
While the diagram above is academically interesting, it is real-world interoperability and the ability for end users to leverage their authenticators at many services that will make Microsoft’s investment truly worthwhile. The industry is gunning for ubiquitous standards-based passwordless authentication, and by gum we’re on our way.
What’s Next
This overview covers the entities at play in a WebAuthn/CTAP2 interaction – but these roles are just the tip of the iceberg. In future blog posts we will dig into details of the interaction itself, including
- How keys are stored and why resident keys are important
- How exactly U2F/CTAP1 backwards compatibility works
- What specific extensions do and what is the business value
- Differences in how WebAuthn is used for first vs. second factor auth
- How Developers can become WebAuthn and CTAP relying parties
- How the security mitigations keep it all safe
Stay tuned for more fun and excitement in the Identity Standards world!