Natanael

There's more ways such as scanning a Qr code to establish a connection from the app to the computer, or by presenting a number on one device which must be entered on the other

Tell that to cops at traffic stops

Yes it's a thing

The main point is all those attacks need to attack the local software or hardware implementation on one of the two ends (or a cert issuer), and even then it's replay protected so for example an XSS attack lasts only for one session, so it's more robust.

Webauthn has domain bindings and single use challenges which prevents MITM credential stealing, etc

The credential needs to be set as discoverable and some other stuff to work for passwordless login (the token must store site specific data)

You would need to reregister it as passwordless to not just use it as 2FA after having entered a password (meanwhile standard 2FA with webauthn don't store anything on the token, the website sends encrypted credentials to the token which only the token can decrypt and then authenticate with)

The original spec is resident keys including TPM protected or hardware token protected keys designed to be impossible to copy. That's why there's a distinction.

You haven't seen good public transit then, are you being satirical or are you really that dimwitted?

That's a library bug, not a format bug

Also it generates unique keys per site so it doesn't help anybody track you

Both the website and your physical security token must support the right type of webauthn credentials (the token has storage for a certain number of slots with "discoverable credentials").

Passkeys is a variant of the same which is bound to your device's own TPM / SE security chip or equivalent, plus a synchronization feature for backups.

No it's literally in the spec. Passkeys are designed for cross device synchronization. You have to go out of your way to make it local only (or use a different webauthn spec like physical security keys)

The same webauthn standard allows you to use a security key with PIN luck