User verification is the process by which the Authenticator confirms the user’s identity locally before authorizing the use of Authenticator functionality. This confirmation can come in to form various authorization gestures; some examples are having the user interact with a fingerprint reader, enter a PIN or password, or use facial recognition. User verification is not necessary but it acts as a secondary layer of security to make sure the Authenticator is not being used by a someone other than the intended user. Allowed values:

• required: Must have user verification. This means that if an Authenticator is not able to perform user verification then operations will be rejected by the FIDO2 Server. The benefit of this option is the added security it brings to the FIDO2 operations. By only selecting this option, you can guarantee that all users of the RP have this added level of security, making their transaction potentially more trustworthy than those with Authenticators without user verification. The downsides to picking this option are that it will cause SKFS to reject operations from Authenticators without user verification, potentially reducing the user base; also, by forcing the user verification process it will slow the user experience.
• preferred: Verify users if possible; otherwise don't. If user verification is possible then the Authenticator must use it. If user verification is not possible then the Authenticator can perform the operation without user verification without issue. Including this option has all Authenticators that can use user verification do so without outright rejecting Authenticators that can’t use user verification. This gives the potentially increased security of user verification without the negatives of possibly rejecting a user’s Authenticator of choice and impairing the user experience.
• discouraged: Don't verify users. Even if user verification is possible the Authenticator should not use user verification. The advantage of this option is that it can improve the ease of the user experience. Instead of potentially having to input a PIN or password, the user might be able to bypass this step if the Authenticator allows it.