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. 


FIDO2 Overview.png 

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:


FIDO2 Overview-MSFTversion.pngCurrent MSFT WebAuthn/CTAP2 Functionality

  • 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! 




Senior Member

This is a great start!  I was able to use Edge to successfully associate a Yubico FIDO2 key, and Windows Hello with my consumer account.  I was not, however, able to associate any of the various FIDO2 Feitian keys like ePass and BioPass I have lying around, which I have successfully used in other test applications (like https://fido2.azurewebsites.net).


For the "Microsoft compatible" bit, are you looking at the extensions that the device provides, or is there a whitelist of device AAGUIDs? 


I am definitely looking forward to seeing how this will work in the enterprise!

Occasional Visitor

There has been some great traction with WebAuthn in 2018.  The main benefits being the ability to change authenticators seamlessly.  A big issue with MFA and strong authentication in general, was always the cost of transition - rolling out custom and point vendors in the MFA space.  Changing application logic, redeploying SDK's and so on.  ForgeRock added WebAuthn support this year to great response.

Occasional Visitor

For windows native application, is there any accessible platform APIs for FIDO2? I cannot find it in any places. Please let me know the way to implement native RP application with Windows 10 APIs.

Occasional Visitor


May I know if it is the sample we gave to you during trade show? This is probably because it is an old version of firmware not the released one. 

Respond on behalf of FEITIAN Technologies.


In the diagram related to Microsoft Account, should not 'Windows Hello' will be in place of 'Platform Authenticator'?

Senior Member

@nickhu1395Not at a trade show specifically, but via a very similar path.  I have since noticed that the AAGUID emitted by this sample device does not match the AAGUID in the MDS entry for the certified product of the same name, which makes sense if that is being checked in the registration process.


Hey @Raman Jindal - I drew that diagram exactly as you commented the first time - with Windows Hello in the platform authenticator box.  But both the Windows Hello team and my standards team convinced me it wasn't the right way to convey things.  The actual physical authenticators are only ever available through the platform, and in fact platform authenticators are only ever a WebAuthn concept, not a CTAP2 concept. It is really up to the platform to decide how those authenticators are made available, they are not really standards-based participants, so I think the next rev of the diagram would have them embedded completely in the platform rather than adjacent in any way to the WebAuthn APIs.  Do you think that would help?


Thanks for the thoughts - it helps a lot to know what resonates and what doesn't.







Hey @aseigler and @kieunn,  I just wanted to ACK that I am checking on answers to both the whitelist question and a deep dive into what exactly can be done with native apps.  There has also been a lot of twitter questions on why certain things work and certain things don't.  I will get back with answers ASAP.






Hello @Pamela Dingle, as you mentioned I am of the same understanding that platform authenticators like Windows Hello is different from CTAP2 host/platform and should be represented as platform authenticator in the diagram. Thanks.


Hi @Pamela Dingle, when webauthn is used with windows hello face identification do you know if the user has to do something to ensure he is actually trying to log in? Like when touching a usb authenticator?


I’m afraid someone could try to make you log in while you are standing in front of the windows hello camera.


Hi @fgervais, what you're talking about is an authorization gesture, and authentication without an authorization gesture is called silent access. The simple answer is that Windows Hello always prompts the end user in a way that allows them to authorize (or dismiss) an authentication request.  Beyond that, however, there is a ton of specification coolness - different kinds of authorization gestures and different requirements and failsafes for preventing silent access.  I will be digging into silent access in depth, in a future blog post.

Occasional Visitor

The diagram about the Microsoft implementation says "Microsoft Account"; I think of this as a consumer/MSA account, NOT an org-owned, Azure Active Directory account.  Is that the intent? 


Hi @MartinBH you are right - we were talking about Microsoft Account because you can use FIDO2 and WebAuthn at MSa today so it is a real-life example.  With respect to Azure Active Directory, we've finished a private preview and are in the process of getting to the next phase, but when we get there AAD will play the same protocol role but with additional administrative & policy controls.

Regular Visitor

Hi Pamela


any update on the likely timescales for public preview?