Can We Specify the Authentication Method?

[MarklearnML]

Hello, thank you for your excellent work. I would like to know whether it is possible to specify the authentication method when initiating registration/authentication, that is, to use only face recognition or only a PIN code for authentication. Alternatively, after successful authentication, is it possible to obtain the user's authentication method?

Looking forward to your reply.

Best wishes

[emlun]

Hi!

It is not possible to specify this in the input parameters; this is not a limitation of the library but an intentional limitation in the WebAuthn standard.

It is theoretically possible to obtain the information from the success response - but note, theoretically. This could be done in one of two ways:

1. Request attestation during the registration, and verify that the attestation is trusted. This will let you know for certain what kind of authenticator the user is using. Thus by extension you'll know that the user must have used one of the forms of UV that authenticator supports - for example, a YubiKey 5 could only perform UV using PIN. If the authenticator supports more than one method, then you cannot know which of the two was used - for example, a YubiKey Bio could perform UV using either PIN or fingerprint, and there is no way to tell which was used.

2. Request the uvm extension. If supported by the authenticator, this extension will return a representation of which user verification method(s) were used, as defined in the extension definition.

   However, the caveat here is that very few authenticators support this extension, so you can't count on getting this extension output in most cases. YubiKeys do not support this extension, for example. Also, the browser may or may not pass the extension through; I don't know which browsers currently do and don't.

Those are the only two options as far as I know.

[MarklearnML]

Thank you for your quick response. I will try the method you suggested. Thanks!

[MarklearnML]

Hi!

1. I tried setting the

publicKeyCredentialRequestOptions = {
  ...
  extensions: {
     uvm: true
  },
  ...
}

parameter and observed that this.flags.ED = 0 in AuthenticatorData.class. I got similar results on Win Hello/iPhone + Chrome/Edge/Firefox. Does this mean that the device or browser does not implement this extension, or is there something wrong with my setup?

2. We are currently aiming to perform authentication using only the authenticator’s face recognition feature. I saw that the Policy.accepted parameter in the UAF protocol seems to provide this functionality. Is there a specific reason why WebAuthn might have abandoned this feature? Do you think WebAuthn might consider adding this functionality in the future? Do you have any other suggestions for implementing this feature?

Apologies for the many questions, and I look forward to your response. Once again, thank you for your excellent work.

Best wishes!

[emlun]

Does this mean that the device or browser does not implement this extension

Yes.

2. the Policy.accepted parameter in the UAF protocol seems to provide this functionality. Is there a specific reason why WebAuthn might have abandoned this feature?

WebAuthn was not designed with UAF in mind, but instead for the much narrower scope of U2F (CTAP1) and its successor CTAP2. And in short, the WebAuthn WG has chosen to be very conservative with what filtering options are given to RPs, because ecosystem fragmentation is seen as one of the greatest threats to adoption. If 10 RPs have 10 different and incompatible policies, causing users to have to carry 10 different authenticators with different properties, then no-one will want to use WebAuthn because of the hassle.

2. Do you think WebAuthn might consider adding this functionality in the future?

Most likely not, especially considering the uvm and uvi extensions already exist (uvi was dropped from the spec in L2 and uvm is being dropped in L3, but the extension specs still exist) and have not seen much adoption.

3. Do you have any other suggestions for implementing this feature?

No. I would first question why this feature is desired:

• Is it for security, under the assumption that facial recognition is somehow more secure than other methods and you need to prove to some auditor that you satisfy their requirements? Then you need more than just a filtering option, because a filtering option could be ignored or overridden by the user agent. You need attestation in order to have cryptographic proof of the authenticator's capabilities and guarantees. Even without an up-front filtering option, you can inspect the attestation statement in the response and refuse the registration if the authenticator does not satisfy your policy. The user experience will be worse because it'll first seem like the registration succeeded and then it fails after the fact, but that's the price you pay for fragmenting the ecosystem in this way (see above).

• Is it for convenience, under the assumption that most users would prefer using facial recognition? Then why spend effort preventing other methods if it's really just meant as a convenience shortcut? If a user's platform presents facial recognition as a primary method and the user chooses that, great; if the user goes out of their way to choose a different method and is refused, they'll just be frustrated and won't want to use your app. If a user's platform doesn't even offer facial recognition, then they won't be able to use your app at all. You're spending active effort on making a worse user experience.

  Just don't set any preference (indeed you can't anyway, precisely for these reasons), and the user, user agent and authenticator will cooperate to pick whatever method is most convenient for that user.

• Is it for something else? Then I'm really curious about what that could be. Please elaborate!