Comment by lxgr

> Having to dump authenticator state at regular intervals [...]

Again, you don't inherently have to do this if you only use non-resident keys (which many sites allow; my hardware authenticator does not even support resident keys).

Synchronized resident keys are not the only possible WebAuthN implementation, even though they are getting currently heavily pushed by big stakeholders. The big advantage they come with, though, is that they lost hardware attestation in the process, so everybody is free to use their own implementation instead.

Thinking about it some more: I'm pretty sure that there are crypto wallets that support FIDO (or maybe just U2F, i.e. the predecessor of CTAP2?) as a secondary application, and they are almost always based on a passphrase you can back up and replicate across authenticators as you wish.

> Seems like a shit ton of complexity and effort to work around a problem OpenSSH elegantly solved 30 years ago.

There are very good reasons for requiring the private key at registration time and for mandatory per-site keys in WebAuthN/FIDO, which are arguably the two main differences between WebAuthN and SSH at a protocol level:

Global keys would be a privacy nightmare (as they would become global identifiers), and being able to register a public key without a private key risks both users accidentally registering a key they don't have access to (i.e. availability), and getting social engineered into registering somebody else's key that is not even physically present with them.

But again, per-site keys can absolutely be implemented without having to keep state on the authenticator, since they can be deterministically derived from a root secret.