Chrome Conditional UI: isConditional MediationAvailable() Returns True on Windows 10

1. Introduction

At Corbado, we continuously try to provide the best passkey-first solution for every device and browser. One of the significant hurdles for wide passkey adoption has been navigating the heterogeneous system of Windows 10 versions and features. Windows 10 presents unique challenges for passkey implementation, mainly due to its lack of a Trusted Platform Module (TPM) requirement and missing upgrades for Windows Hello that Windows 11 got. This diversity in the operating system's architecture and capabilities means that not all Windows 10 devices are passkey-ready or do not support all passkey features, particularly Conditional UI. In fact, as of March 2024, Windows in general only supports single-device passkeys (which are not synced e.g. via a Windows / Microsoft account).

When testing on a Windows 10 device, we recently made a suprising discovery. Unlike our previous experiences, this particular device, equipped with Chrome 123, indicated through the PublicKeyCredential. isConditionalMediationAvailable() check that it was, surprisingly, Conditional-UI-ready. This unexpected finding sparked our interest and led us into a deeper investigation.

After reaching out to a developer from the Chromium team, we gained new insights that we want to share with others in this blog post.

2. Discovery: All Windows 10 Devices with Chrome Show Conditional UI Readiness

Our test device:

• Was running on Windows 10
• Has no Bluetooth support
• Could create passkeys (single-device passkeys) before but did not support conditional UI
• Now, it displayed Conditional UI support

Our interest deepened upon noticing this behavior was not isolated to Chrome. When we extended our observations to Firefox, the same unexpected readiness for Conditional UI was apparent, suggesting a pattern that noticeable across browsers. This broader consistency hinted at an underlying change in the Windows 10 operating system itself, rather than browser-specific updates or modifications.

To uncover the root of this change, we started to review the recent changelogs for both Windows and the browsers in question. Despite our examination, we found no direct references to significant changes that could explain the newfound Conditional UI support.

We then started to analyze the webauthn.dll file, the library for WebAuthn in Windows 10. An update to this file in mid- February caught our eye, which was a cumulative update for the .NET framework. The webauthn.dll is important for developers working on integrating secure user authentication methods, as it provides the necessary functions to interact with authenticators and manage credentials. The update to this file was a potential reason in understanding the sudden emergence of Conditional UI support on Windows 10. A change in the webauthn.dll would have been very surprising due to Windows 10 getting only security updates and is not receiving new feature updates.

3. WebAuthn API Versions in Windows Have not Changed

The webauthn.dll contain the WebAuthNGetPlatformCredentialList entry. Moreover, various WebAuthn API versions (WEBAUTHN_API_VERSION_X, where X stands for the version number) are defined, each version introducing new data structures, their subversions and extensions. Specifically, WEBAUTHN_API_VERSION_7 marks a significant leap forward, introducing new data structures such as WEBAUTHN_AUTHENTICATOR_MAKE_ CREDENTIAL_OPTIONS and WEBAUTHN_AUTHENTICATOR_GET_ ASSERTION_OPTION S, both introduced in version 7, alongside WEBAUTHN_CREDENTIAL_ATTESTATION (version 6) and WEBAUTHN_ASSERTION (version 5). These structures are foundational for the conditional UI capabilities.

Moreover, as of WEBAUTHN_API_VERSION_4 , the API provided essential functions like WebAuthNGetPlatformCredentialList , WebAuthNFreePlatformCredentialList , and WebAuthNDeletePlatformCredential , which are integral for managing credentials on the platform and, by extension, critical for enabling or enhancing conditional UI support as they allowed to silently discover credentials on the authenticator.

Chrome's approach to determining conditional UI availability is tied to the WebAuthn API version supported by the underlying operating system. The browser conducts a silent check for a specific WebAuthn API version, using this information to decide whether conditional UI features can be enabled. This process, however, revealed an anomaly: our testing showed that Chrome was indicating conditional UI readiness on Windows 10 devices that, according to their WebAuthn API version, should not support these features.

This discrepancy led us to reach out to the Chromium developer team for insights. The team's response revealed something interesting, as in one of the latest Chromium version passkey metadata from Android phones is synced to Chrome desktops. This functionality allows Chrome to autofill passkeys for websites if the user has enabled sync on their desktop and has a corresponding passkey on their Android phone:

To protect user privacy and prevent websites from detecting whether this sync is enabled, Chrome now always returns true for the PublicKeyCredential. isConditionalMediationAvailable() call, regardless of the actual WebAuthn API version on the device.

4. Implications of Chromiums New Behavior

The revelation from the Chromium team has implications for developers and product managers. As the UX might be improved due to the synchronization of passkey metadata between mobile and desktop environments, the usage of PublicKeyCredential. isConditionalMediationAvailable() does not provide valid results anymore (for now). Determining the true conditional UI readiness of a device based solely on its WebAuthn API version number is not possible anymore.

5. Conclusion

In summary, the technical exploration into the updated webauthn.dll file and the interactions with the Chromium developer team shed light on the evolving landscape of web authentication. It highlights the innovative approaches being adopted to streamline user experiences across platforms while also pointing to the need for developers to stay informed about these changes to effectively implement and leverage the full potential of passkeys and conditional UI.