[ecesena]

Microsoft supports passwordless login (you can try it out on outlook.com — some ppl refer to this as username less).

Dropbox is also an early adopter.

Plus you have all the u2f that are back compat, including facebook, twitter, aws, gitlab... (I may have confuse some u2f that already moved to webauthn, if so, sorry).

Considering that webauthn was standardized last March and that ios still has no in-app support, that’s a pretty good start, I think.

[tialaramex]

So the reason for the usernameless / passwordless distinction goes like this:

U2F was explicitly designed only as a second factor. ("Universal 2nd Factor") but WebAuthn is not.

Even with U2F you could (it wasn't recommended) just not actually have passwords. Use their second factor as your only factor. In this scenario the user needs to provide their username (email address, whatever you're using) because their FIDO token doesn't know who they are either -- it needs to be presented with a cookie [which it gave the site when the user registered to use this FIDO token], and you've probably got a database table mapping users to cookies and public keys.

In FIDO2 the token is capable of handling resident credentials. No cookie, resident credentials are permanently inside the token itself.

The massive downside of this is that obviously the token has finite storage for such credentials, a Yubikey can store 25. Whereas for ordinary FIDO (all the WebAuthn deployments I've seen outside Microsoft) there's no practical limit.

The upside is that since the token has your credentials it can now do the entire sign-in, no need for even a username so the login flow is much nicer.

Of course while convenient on its own that's arguably worse security - if a bad guy steals your token they're in without even knowing your username, much like the proximity card badges often used for site access. So the fix is that a FIDO2 token in this mode can be (usually will be) set to require a PIN or some other factor. This seems like we're back to passwords again, but it's different because the extra factor is local to your device. Bad guys can't steal PINs from devices in bulk or brute force them, they need to steal your FIDO2 token and then brute force that somehow.

[StavrosK]

This comment is accurate. Also, hardware keys can require biometrics or any other way of authenticating you. Currently, Yubikeys erase themselves if you get the PIN wrong three times (if I'm not mistaken on the number), so it's very hard to brute force.

[throw7]

Is this right... so in FIDO2, the website only has to store the public key of the token (which will get sent on registration/signup and mapped to a userid)?

[tialaramex]

Not the public key, that would violates FIDO's design requirement forbidding correlation. A key pair is minted during registration and the relying party (web site) remembers that specific public key. The FIDO2 device remembers which site it was and its corresponding private key.

That's why it needs storage for each such resident credential on the FIDO2 token.