WebAuthn virtual authenticator UV behavior diverges from platform authenticator modalities

The WebAuthn Virtual Authenticator API via Chrome DevTools Protocol (CDP) is designed for functional testing, not high-fidelity hardware emulation. The divergence you observe between platform authenticators (like Windows Hello) and virtual authenticators occurs because the latter acts as a simplified state-machine rather than a bridge to the OS-level security modules.

Why UV Behavior Diverges

The primary reason the virtual authenticator does not replicate platform-specific UV modalities or retry limits is that it lacks a connection to the Trusted Execution Environment (TEE) or Secure Element. When you call WebAuthn.setUserVerified(true), you are manually flipping the uv flag in the virtual device's internal state. It does not trigger the underlying biometric or PIN logic because there is no hardware-backed interface to invoke.

Addressing Specific Testing Constraints

• Can virtual authenticators be configured to simulate specific UV modalities and retry counters? No. There is currently no CDP command or configuration option in addVirtualAuthenticator to define specific modalities (e.g., Fingerprint vs. PIN) or to increment a retry-limit counter. The UV state is binary in the context of the virtual authenticator API.
nn
• Is there a mechanism to toggle the UP flag independently? In the current CDP implementation, the User Presence (UP) flag is often hardcoded to true once the session is initiated. To test UP-only scenarios (where UV is absent), you must rely on the assertion response returned by the browser, but the virtual authenticator does not provide a granular toggleUP command.
• WebAuthn Level 3 extension points for UV behavior? While WebAuthn L3 introduces more complex scenarios (like synched passkeys and specific key extensions), Chrome's virtual authenticator has not yet exposed hooks for low-level UV modality-specific logic. The implementation focuses on the core protocol flow (request/assertion/flags).
nn

Recommended Strategy for Testing Logic

If your relying party logic branches based on authenticatorAttachment or UV status, use the following approach to bridge the gap:

1. Mock the Attachment: Since the virtual authenticator can be initialized with instrument: 'platform' or cross-platform', ensure your test script explicitly sets this to trigger your branching logic.
2. Manual Flag Injection: Instead of relying on the authenticator to "fail" a UV check, use your test framework to intercept the assertionResult response and manually modify the uv boolean to test how your application handles a false state.
3. Simulate Lockouts manually: Since the virtual authenticator will not lockout, you must mock the lockout state in your application's database layer or server-side API after a set number of simulated failed attempts.

Note: If you are testing the enforcement of the userVerification: required requirement, ensure your virtual authenticator was created with hasUserVerification: true, otherwise the browser will reject the request.