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.

@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?

@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.

@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.

@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.

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