search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.18k stars 171 forks source link

Enforce specific user verification methods #1211

Closed Kieun closed 5 years ago

Kieun commented 5 years ago

RP would like to leverage specific user verification methods (UVMs) especially biometrics such as fingerprint, face, and etc. Even the authenticator may support multiple user verifications, RP wants to enforce the specific UVM. The reason for this is for RP is that RP already has some authentication schemes like online pattern or PIN (like payment services) and introduce WebAuthn as an alternative authentication methods. For usability (to avoid mislead), RP wants to disallow local pattern or PIN for the authentication. Because sometimes users cannot distinguish between online authentication and local authentication. This requirement is more about mobile use cases (web and native).

FYI, Android and iOS have such kind of options (not to show fallback like passcode or PIN) for biometric authentication.

selfissued commented 5 years ago

Typically the RP doesn't have sufficient knowledge of the authenticator's capabilities to make intelligent choices. Having the RP try to do this could result in degraded user experiences. We should discourage RPs attempting to control the authenticator's behaviors.

Kieun commented 5 years ago

@selfissued we already define the authnSel extension for specifying the authenticator for registration. Although such extension has not been provided by any browser, we have a way to check the capability and set it. RP caring about biometric authentication especially for mobile usually expect WeAuthn works similar to biometric authentication. Such platform biometric authentications have an option for enabling/disabling fallback feature.

If it is concern for platform and browser sides, what about introducing some parameters for indicating fallback preference?

hgomi53 commented 5 years ago

@Kieun @selfissued It would be great if RPs can control the behaviors of authenticators for users by specifying a UVM used for authentication.

If an RP may have knowledge of a user's context, the RP can use the information to provide the user with better user experience on authentication.

For example, let's consider a case in which a user browses a recipe site while she is cooking. In this case, it is difficult for her to use the finger to sign in to the site.

If the RP knows this situation about her, it would like to specify "voice'' or "face'' as a UVM in the Authenticator Selection extension of an authn request (excluding the fingerprint UVM). This should contribute to better user experience for her than that of her selecting one among verification options.

emlun commented 5 years ago

@hgomi53: For example, let's consider a case in which a user browses a recipe site while she is cooking. In this case, it is difficult for her to use the finger to sign in to the site.

If the RP knows this situation about her, it would like to specify "voice'' or "face'' as a UVM in the Authenticator Selection extension of an authn request (excluding the fingerprint UVM). This should contribute to better user experience for her than that of her selecting one among verification options.

For use cases like this I think it should be up to the client and authenticator to provide those options in a usable way, it should not be the RP's decision to limit the options based on what the RP thinks the user is doing. That is bound to create a frustrating user experience if the user can't override the RP's guesswork, and even if the RP would allow some configuration of this behaviour, at that point we're just stacking up more and more complexity to solve something that shouldn't be a problem in the first place.

I think a better motivation is security requirements on UV methods, but I'm not convinced that's a big issue either. If an RP cares about the UV method for security reasons, then they necessarily also require device attestation and can already enforce that only authenticators with allowable UV methods are used.

@kieun: For usability (to avoid mislead), RP wants to disallow local pattern or PIN for the authentication. Because sometimes users cannot distinguish between online authentication and local authentication.

This is an interesting point, but again I think it should probably be the client's responsitbility to help the user make this distinction.

Kieun commented 5 years ago

@emlun For UX point of view, RP really cares about such features, especially for mobile cases. If we fully adopt WebAuthn for all authentication, it makes sense to leverage WebAuthn including such authenticator's fallback. But, even we are adopting WebAuthn now, still we have fallbacks or alternative authentication methods since we all know that it takes time to replace old authentication (which is not secure and usable) with WebAuthn and there are cases where WebAuthn does not work. The thing is that the client never know the RP's context without explicit information.

akshayku commented 5 years ago

As discussed on call 6/19/2019, group agreed with current state and decided not to implement this.