No. Passkeys aren't device bound but they are a challenge response protocol so no token transits the wire during auth flows. It’s why they are cryptographically more secure than a shared secret (token). However most implementations take the result of a passkey login and issue a session token so…
AFAIK passkeys are not a protocol. They are cryptographic key pairs (public and private keys). Private key is stored on a device and public key on a server. Private key often is device bound, and it never leaves the device. That's where a challenge response protocol comes in. It enables to provide proof of private key ownership without exposing the private key and it should also prevent replay attacks.
Yes “passkeys” is a marketing term that refers to the consumer oriented subset of webauthn. You can colloquially refer to an individual key pair as a passkey, when used in this context.
> However most implementations take the result of a passkey login and issue a session token so…
Is there a way to avoid this and use token for every request in real world?
I mean, that’s an interesting idea, but I think it’s not going to work in practice (can’t make user show face or touch a token on every request). Please let me know if I’m wrong here!
Well, every mutual TLS handshake authenticates again. And then establishes a session key. But if you fire up a new session (new tab?), boom, new mutual authentication. It's just that the private key is stored in a keystore, and not on a device, and you don't need to keep your finger on the fingerprint reader all the time.
You could have every message signed with the sending party's private key, at some performance cost. And that signing could happen in a hardware device. Essentially what happens with hardware wallets for bitcoin.
