Proposal: Leveraging FIDO User Verification Index (UVI) as a Cross-Browser PSD2 "Possession Factor" for Passkeys

[JeanDim]

Introduction and Problem Statement

The adoption of passkeys marks a significant step forward in secure and user-friendly authentication. However, their synchronization capabilities, while beneficial for user experience and recovery, introduce complexities when aligning with stringent regulatory requirements like PSD2's Strong Customer Authentication (SCA).

As highlighted in discussions such as #271, synced passkeys pose a challenge to the "possession factor" under SCA, particularly concerning Article 7(2) of the RTS, which aims to "prevent the replication" of authentication elements. If a private key can be "cloned" to the cloud and then deployed across multiple devices, the exclusivity of "something only the user possesses" on a single device becomes ambiguous for high-assurance scenarios.

The ongoing work on Browser Bound Keys (BBK) is a promising solution to address this by cryptographically binding the credential to a specific browser instance on a device. While BBK will provide a robust signal for browser-based transactions, it's inherently a browser-level binding and not cross-browser.

This proposal seeks to explore whether the User Verification Index (UVI) within WebAuthn can serve as an additional, complementary signal for the "possession factor" for passkeys, particularly in scenarios where browser-level binding might not be sufficient or when a browser-agnostic approach is desired. This could help foster broader adoption of passkeys for payment authentication by strengthening their regulatory compliance profile.

Background

PSD2 mandates SCA to use at least two independent elements from three categories: knowledge, possession, and inherence. The EBA Q&A 2019_4532 (https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2019_4532) provides crucial clarification on what constitutes a "possession" element, emphasizing "the use of a dynamic validation element on the device" and strong device binding.

The FIDO Alliance's WebAuthn specification (https://www.w3.org/TR/webauthn-1/), specifically the UVI extension (https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension), defines a mechanism to signal the specific user verification data used during an authentication event. The UVI is designed to be privacy-preserving and uniquely linked to the user's biometric or PIN data and the specific credential on the authenticator.

UVI as a "Possession Factor" for Passkeys: Addressing EBA Requirements

The FIDO User Verification Index (UVI) offers a compelling argument for contributing to the "possession factor" for passkeys, especially when considering the specific requirements outlined in the EBA Q&A 2019_4532:

1. "Something only the user possesses":

EBA Requirement: "the means of validating the authenticity of the possession factor need to be based on the use of a unique element possessed by the payment service user." (EBA Q&A 2019_4532)

How UVI seems to fit: The rawUVI (from which the UVI is derived) is computed based on unique biometric data (or PIN) and is tied to the operating system-level identity (OSLevelUserID) associated with that specific user and biometric enrollment. Crucially, the rawUVI is never transmitted outside the authenticator's secure boundaries, as explained in https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension. This means the underlying source of the UVI, which is the unique biometric/PIN enrollment on that specific device, is truly "something only the user possesses" on that device and is not synced. The UVI itself acts as a unique, dynamic fingerprint of this specific possession.

2. "Not leaving the environment" / Secure Storage & Non-Replication:

EBA Requirement (Article 7(2)): "The use by the payer of those elements shall be subject to measures designed to prevent the replication of the elements." The EBA Q&A further implies the element should be "securely linked to the payment service user's mobile device."

How UVI seems to fit: The rawUVI (and the biometric templates/PIN) are not leaving the authenticator. They inherit from the secured storage mechanisms required by FIDO authenticator certification requirements (e.g., Secure Elements, TEEs, TPMs). These environments are designed to be tamper-resistant and prevent the extraction or replication of sensitive data, including the rawUVI. While the passkey private key can be synced, the rawUVI – the specific identity of the user verification data record on the authenticator that performed the verification – remains bound to that specific authenticator and its secure execution environment. It cannot be replicated across devices via cloud sync.

3. "Unique connection" / Uniqueness of Value:

EBA Requirement: The possession factor should allow for a "unique connection" between the element and the payment service user.

How UVI seems to fit: The UVI value is designed to be unique per device (specifically, the OS-level user ID / authenticator instance), user (the specific biometric data used), and the private key/credential used, as defined in https://www.w3.org/TR/webauthn-1/#sctn-uvi-extension. If a different finger is used, or if the user authenticates on a different device (even if it's synced with the same passkey), the UVI should change. This uniqueness provides a strong signal of the specific "possessed" instance that performed the verification.

4. "Dynamic validation element" & Cryptographic Proof:

EBA Requirement: Validation must be based on "the generation or receipt of a dynamic validation element on the device."

How UVI seems to fit: The UVI is included within the authData (Authenticator Data) structure, which is a core part of the signed WebAuthn assertion, as detailed in https://www.w3.org/TR/webauthn-1/#authenticator-data. This authData is cryptographically signed by the passkey's private key on the device. Therefore, the UVI is an attested, dynamically generated part of the cryptographic proof that originates from the possessed authenticator, confirming both possession and successful user verification on that specific authenticator.

Conclusion and Open Question

While Browser Bound Keys (BBK) offer a crucial path for strong browser-level binding for SCA, they are browser-specific. The User Verification Index (UVI), conversely, provides a signal that is authenticator-bound and device-specific at the OS-level user identity, irrespective of the specific browser used. This capability makes UVI a strong candidate for being considered as an additional possession signal, especially in scenarios where:

• A passkey is synced across devices, and a strict interpretation of PSD2's "non-replication" for the private key needs mitigation.
• A browser-agnostic or application-level assessment of the possession factor is desired.
• The transaction benefits from an explicit signal about which specific user verification record on which specific device performed the authentication.

Open Question: Given the detailed mechanisms of the FIDO UVI, its inherent binding to the specific user verification data on a particular authenticator instance, and its potential for providing a browser-agnostic possession signal, could the reintroduction of UVI into the SPC specification be considered a key step towards fostering broader adoption of passkeys for payment authentication under PSD2 SCA? This would enable us to leverage the convenience and security of passkeys while enhancing compliance, particularly for synced passkeys where the underlying private key roams.

[ianbjacobs]

@ve7jtb, @rlin1, welcome your input on this issue!

[iinuwa]

I'm new to this discussion, so let me know if I'm missing other things.

I see that FIDO2 certification is mentioned here: is it an expectation that FIDO2 certification would be required for these ceremonies? I think that as the extension was written in L1, UVI does not give the intended properties unless the authenticator model is attested and verified, and a specific relationship is made between the PSP. (This relationship could just be querying a list of certified FIDO2 models and verifying that the authenticator can attest to one of those.) For example, the WebAuthn spec encourages authenticators to make these values device bound, but the authenticator can store the authenticator anywhere it wants, but the RP/PSP would never know. (This is the same issue as synced passkeys.)

Generally, I'm not in favor of enforcing certified authenticator attestation in a consumer context, since users will not adopt it, and first-party and third-party passkey providers either will not or cannot provide certifiable attestation.

Given that, an uncertified UVI extension does not have many more properties than the normal UV flag present in WebAuthn/CTAP already.

I personally think that the UV flag is sufficient for strong authentication, but I see that we're working in a regulatory context where my opinions don't really matter too much. 😄 Wherever possible, I think that we should push the industry away from thinking only in terms of factors and emphasize strength of the authentication ceremony, where multiple factors contribute, but do not constitute the strength.

Another thing to note is that UVI was removed in WebAuthn Level 2 and is still absent in Level 3. (A Level 4 spec is probably a ways off.)

[ianbjacobs]

@iinuwa, thanks for adding to this thread!