Why is WebAuthn 2FA hardcoded to UserVerificationPolicy::Discouraged for both registration and login?

[kuchida1981]

Environment

• Vaultwarden 1.37.1, Docker Compose, behind Caddy as reverse proxy, hosted on a small GCP VM (e2-micro)
• Client OS: Ubuntu 24.04
• Chrome 151.0.7922.75 (Official Build) (64-bit)
• Firefox 153.0.1 (64-bit)
• Authenticator: Google Titan Security Key (USB)

Context

generate_webauthn_challenge (registration) and generate_webauthn_login (login) both explicitly force UserVerificationPolicy::Discouraged_DO_NOT_USE on every WebAuthn 2FA ceremony, regardless of what the authenticator is capable of:

// registration
if let Some(asc) = challenge.public_key.authenticator_selection.as_mut() {
    asc.user_verification = UserVerificationPolicy::Discouraged_DO_NOT_USE;
}

// login
response.public_key.user_verification = UserVerificationPolicy::Discouraged_DO_NOT_USE;

I traced this back to #1840 (2021), where a wave of different security keys (YubiKey, NitroKey, SoloKey) started failing login with UserNotVerified after get_require_uv_consistency defaulted to true in the webauthn-rs 0.3.x config at the time. @dani-garcia's own reply there frames disabling it (false) as "the more compatible option," and that's what shipped in ffdcafa. The webauthn-rs 0.5.x migration (#5934) carried the same discouraged choice forward without revisiting it.

What we ran into

A Google Titan Security Key registers fine as FIDO2 WebAuthn 2FA, but every login attempt afterwards hangs at the touch prompt and eventually fails with NotAllowedError.

Root cause, confirmed by a controlled re-registration test: registering the same physical key via Chrome (which honors the discouraged hint literally and never performs UV - no PIN prompt) produces a credential that can never complete login. Registering it via Firefox instead (which prompts for the PIN despite the same discouraged hint) produces a credential that works from both browsers. The two DB records differ specifically in user_verified (false vs true) and credential ID length (160 vs 288 bytes) - this key's firmware apparently can't correctly handle a later GetAssertion against a credential ID that was wrapped without UV having been performed at registration.

The fix we tested

Changed both registration and login to request UserVerificationPolicy::Preferred instead: kuchida1981/vaultwarden#1.

• Registration now prompts for the key's PIN in Chrome (previously it silently skipped UV).
• Login: our first attempt only patched registration, and that alone made things worse - the newly-verified credential's registration_policy was now stored as preferred, which activates an enforcement branch in webauthn-rs-core's verify_credential_internal (cred.user_verified && !data.authenticator_data.user_verified => UserNotVerified) - but since login was still forcing discouraged, neither browser was ever asked to perform UV during the login ceremony, so every login failed regardless of browser. Switching login to Preferred too resolved this: whichever browser is used now actually prompts for the PIN, and login succeeds.
• Confirmed working end-to-end (Chrome registration + Chrome login, Chrome registration + Firefox login) after the full fix.
• Credentials registered before this change keep registration_policy: discouraged in the DB, which structurally bypasses that enforcement branch entirely - so existing keys shouldn't be affected either way.

Question

Given #1840's history, was Discouraged chosen deliberately as a durable policy (e.g. because some authenticators are known to misbehave under Preferred, and the "more compatible option" framing was meant to stick long-term), or was it more of a quick, broad fix for the 2021 wave of failures that just never got revisited since? I want to understand whether switching the default to Preferred risks reintroducing that same class of failure for other authenticators, before proposing it as a real PR - happy to open one if there's interest and no known landmine here.