Add a way for RPs to ensure registration of certain authenticator-supported UV methods #2482

Proposed Change

For a while now there's been this unmet need for high assurance RPs (financial sector, etc...) to know which UV method was used during auth, as a signal to decide whether to let the user through. The uvm extension came and went, and there still hasn't been a good reason to provide such a signal because a knowledge factor entry of some kind still backs biometric enrollment on most platforms and authenticators.

I was talking with such a customer recently that understood the reason why we as a WG are unlikely to ever add back a signal like uvm. But they also noted that, based on their experiences, when certain security keys had both a PIN and biometric enrolled, authentication ceremonies almost always led to users being prompted by the platform/browser to perform biometric UV. However based on my observations, while e.g. macOS Chrome will facilitate both PIN and biometric setup during security key registration, Windows only prompts the user to complete PIN setup during security key registration...

Based on this conversation, here's the question I wanted to bring to the group: could we see ourselves adding an option to .create() that would let RPs signals/requires whatever client that orchestrates the registration flow to ensure all of the authenticator's supported UV methods are set up during the ceremony?

Something like this...

const response = await navigator.credentials.create({
  publicKey: {
    // ...
    authenticatorSelection: {
      uvMethods: ['pin', 'biometric'],
    },
  },
});

...paired with the attempted registration of, say, a YubiKey Bio would yield the following results:

1. The ceremony would succeed if the user set up both PIN and biometric, because the Bio supported both.
2. The ceremony would fail if the user only set up PIN, because the client knows the Bio supports it but maybe the user cancelled setting it up.
3. For sake of completeness, I imagine the ceremony would succeed if the user set up only PIN because the security key only supported PIN, but not biometric. There could be an alternative interpretation that has the ceremony fail instead because the authenticator did not have all of the UV capabilities that the RP is signaling it wishes that authenticators have.

The way the customer conversation went, the values in the "uvMethods" array would be determined by the RP and change as new keys go out. And this was also definitely a workforce deployment scenario, not a B2C deployment.

The impact of a new registration option like this would be admittedly indirect: the RP would rely on the vetted security key behavior (as part of the company's deploying these preselected security keys out to users) that sees the security key prompting for biometric UV during auth; this would provide an implicit assurance that users are completing biometric UV, even as WebAuthn continues to not provide any such uvm-like signal in the auth response.