[cyberax]

> Passkeys support an attestation anti-feature, enshrined in the spec. This feature can be abused (and will be IMO, why put it in the spec otherwise?) to limit which providers can access a service.

The problem is that Passkeys really conflate two separate feature sets:

1. Synchronized password replacements. They _have_ to be represented as accessible clear-text to be synced between devices, at least during transit. So they can be stolen, for example, by malware that scans RAM for keys.

2. Keys that never leave a hardened hardware devices. Since they never leave the device, they can't be synced. But they're completely secure.

[lxgr]

This is largely a problem because the specification does not cleanly call these out as two completely different feature sets, e.g. via "profiles" or a similar mechanism.

Effectively implementations already do that, and the spec could clear things up a lot by clearly defining one profile for synchronizing, non-attestation-capable, discoverable credentials called "passkeys", and another for hardware-backed, non-exportable, attestation-supporting ones called something else.

[cyberax]

Yes, clearly separating these two use-cases would have helped immensely.

This technically is true because Passkeys are just a subset of WebAuth.