With WebAuthN is it possible to deny certain types of authentication methods FIDO2)

When using WebAuthN (https://w3c.github.io/webauthn/) to authenticate, is it possible to hide certain authentication options?

For example, when testing on webauthn.io, my android device shows available authentication types like hardware keys, Bluetooth, and fingerprint. Is it possible for me to configure it somehow to not accept hardware keys and bluetooth.

Also, when selecting and using my fingerprint to login, if I force it to fail by using the wrong finger, it defaults to then asking for my unlock pattern and if I enter my unlock pattern, I still get a success. In my opinion an unlock pattern is not secure as a dirty screen leaves the pattern on the screen with a smudge mark. Also parents give the pin to children. Can I stop this behaviour and if the fingerprint fails error instead?

Not an expert but this is what I discovered when I recently implemented WebAuthn/FIDO2 support in our identity provider:

1. authenticatorSelection.authenticatorAttachment - When you create the request for navigator.credentials.create() you can specify whether it should use platform (i.e. built-in biometric/PIN) or cross-platform (e,g, an external USB/BT/NFC device). Note this just gives the user agent a hint about what you're after.
2. authenticatorSelection.userVerification - set this to required and it will require the user of an additional factor beyond mere verification of presence - i.e. a PIN or biometric challenge
3. Attestation - A FIDO2 compliant device can provide attestation information that can be verified via the Metadata Service. This will expose the capabilies of the device and you can base policy on that. E.g. you could insist that it must use tamperproof hardware to protect the private key.
4. Authentication result - can provide information about how the user was verified so you could build a policy around that. The spec for this extension is here: https://www.w3.org/TR/webauthn/#sctn-uvm-extension

The recommenation is not to specifically black/white-list devices yourself but the MDS does support revocation of certification and that should be respected by relying parties.