w3c
New `userVerification` value with conditional behavior
Description
Currently when an authenticator utilizes a PIN and has multiple credentials for the same RP and navigator.credentials.get() is called with userVerification: 'discouraged', the authenticator returns an anonymized list of credentials for the user to choose from (at least with a Yubikey and Firefox in my test environment).
To improve that situation, one can set userVerification: 'required', at which point the user is forced to enter their PIN but then is at least able to see sensible credential user (display) names so that they can make a more informed choice.
However, if there is only one credential in an authenticator for a specific RP, then for convenience it is ideal to use userVerification: 'discouraged' because there is no need to show real user (display) names because there is only one to choose.
The problem is that (AFAIK) there is no way to know in advance whether there is one or multiple credentials for an RP, so I cannot conditionally change the userVerification value, so my request is this: it would be nice to have a new userVerification value that basically instructs the authenticator to act as if 'required' was set but only when there is more than one matching credential for the RP, otherwise it acts as if 'discouraged' was set.
This seems like it shouldn't be the RP's responsibility to worry about. The issue is deeply entangled with particular implementations and the CTAP protocol specifically - that's not something we should introduce new parameters to handle, rather we should clarify the spec where needed, i.e., where implementations diverge.
Which it seems they do: in my testing, Chrome does not behave the same way you describe. Even with credProtect: "userVerificationOptional", Chrome seems to always prompt for PIN when authenticating with a discoverable key on a security key, so it always displays the names in the credential picker. Of course at the cost of a PIN prompt even when it could probably be skipped, technically; maybe that choice was made to make the UX more consistent, I don't know.
Also: a new userVerification value wouldn't help much in the near term, because browsers not yet updated to understand the new value would just fall back to the default ("preferred") which seems like the opposite of what you're asking for. We would have to introduce a whole new parameter in order for RPs to express this new preference in a backwards-compatible way.
As an fyi, after years of testing, trying to mix and match UV modes is simply impossible, and many credentials confuse users by sometimes having a PIN or not. Just set UV=required, and that's it. It's the only way to ensure a consistent experience.
