@adamshostack : apart from marketing purposes, I fail to see the advantage of using public keys for WebAuthn (FIDO2 and passkeys).
IMO *the* advantage of WebAuthn is that software refuses to authenticate if the domain name is incorrect (AitM attacks are possible only if the attacking server possesses a certificate considered valid by the user's browser).
The fact that a (WebAuthn) public key is (hopefully) randomly chosen, and is a lot longer than most passwords are, has nothing to do with cryptography.
Of course, if an attacker is able to copy a (Webauthn) public key from a server, it is of no use to them. However, the same applies to a randomly chosen unique password (in the end, the attacker already had access to the user's account on the server).
OTOH, if an attacker obtains access to a server, they may silently *add* their own public key (something typically not possible in the case of a password). They may choose to *replace* the public key (or password), but that would lock out the user - which may not be what the attacker wants.
Even if it is typically extremely hard for an attacker (with remote access to a user device) to obtain a (WebAuthn) private key, grabbing a session cookie (or JWT etc.) is likely a lot easier. That is, until we have Device Bound Session Credentials (https://wicg.github.io/dbsc/).
But even then, if a user device is sufficiently compromised, the user may be fooled by what they see and how the attacker manipulates their input. Device compromise means game over.
Another aspect is that the better the WebAuthn private keys are protected, the harder it is to make backups of them, increasing the risk of account lockout and vendor lock-in.
@andre