[scott00]

The missing important details: for reasons I do not completely understand, FIDO uses very non-obvious definitions of the words password and PIN. To them a password is a text string provided to an online service for authentication purposes and a PIN is a text string provided to a physically near hardware device to authenticate to that hardware device, after which that hardware device can sign challenges that can be used to authenticate to an online service. When they talk about passwordless they are not precluding the use of a PIN. The PIN gets you your second factor without being stored on a bunch of different services, and with hardware assisted protection from exfiltration and brute force cracking.

Relying parties (aka online services using FIDO protocols) have a lot of freedom to define exactly how restrictive they want to be by making choices about which devices they accept. Through choosing which devices they accept they can choose to require any combination of token, PIN, biometric, and password.

[joshyeager]

Thanks, that is helpful! You’re right that terminology is confusing.

[MrStonedOne]

>Relying parties (aka online services using FIDO protocols) have a lot of freedom to define exactly how restrictive they want to be by making choices about which devices they accept.

This, in my view, is the problem with FIDO.

They shouldn't be able to make that choice.

[dwaite]

https://www.chromium.org/security-keys/ , under 'Site Attestation Requirements'

For anything consumer facing (vs employee/contractor facing), the expectation is that a relying party site accepts everything, or supports a set with a clear industry-defined set of limitations (e.g. must have gone through certification and achieved a certain level such that they meet our security regulations).

The set of limitations which you can set during an authentication request are pretty minimal, on purpose - so you will typically have more prompts and more user errors if you decide to try and limit consumer choice.

Other than that, the expectation is that you do not block end users if they e.g. are using one vendor or the other. You may still ask them to perform additional authentication steps, but the goal is that people do not get conflicting requirements across relying parties that leads them to have to carry a key ring of different vendor USB authenticators in order to be able to do their business.

[tialaramex]

Then don't provide the attestation. No sites I've used (Facebook, GitHub, login.gov, Google, and so on) require attestation. It's unfortunate that the WebAuthn standard requires it be possible for them to ask, but you can just say "No" and I do.