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).
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.
The client device is the hardware hosting a given strong authentication. Laptops and phones are examples of client devices.
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.
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.
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.
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:
Other options are cool and might be useful in the future, but haven't been seen in the wild yet:
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).
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:
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.
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.
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
Stay tuned for more fun and excitement in the Identity Standards world!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.