> Every device is supposed to have its own unique private key, stored in TPM, released only when passing the user challenge (biometrics or pin, or a yubikey).

This is a misconception. A particular service can choose to enforce those class of passkeys, but most don't need that and shouldn't.

Passkeys are primarily meant to replace passwords and be hard (but not necessarily impossible) to exfiltrate.

The key difference is during normal usage you don't have to type the secret in anywhere, it's strictly asymmetric, so a unwitting user is far less likely to get fooled into accidentally leaking the actual credential.

▲

unscaled 2 days ago | parent | next [-]

Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and password pairs. This is in contrast from 2FA, but even before Apple started marketing Passkeys the FIDO standard supported the concept of Passwordless authentication, alongside 2FA.

Passkeys came together with multi-device syncing when Apple introduced them and IIRC it was pushed as their killer feature by Apple back then, but passkeys can also be completely device-bound. The marketing around this was all quite confusing, but it's a bit too late to fix now.

What we got, as far as the average consumer should be concerned, is that "passkey" is any authentication mechanism (not the actual credential) that can replace a password. And it's still confusing.

	▲	ivlad 2 days ago \| parent \| next [-]
		I think in Apple stack they cannot be made hardware bound anymore. Platform claim is ignored on creation and the keypair is always in Keychain and syncable unless iCloud sync is disabled.
	▲	marysol5 2 days ago \| parent \| prev [-]
		Lest we forget that enterprises have had passwordless auth long before any of this

▲

michaelt 2 days ago | parent | prev | next [-]

> Passkeys are primarily meant to replace passwords

Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

Also they decided they should be cloud-synchronised, so the something-you-have second factor doesn't impose the burdensome requirement for you to have something, which was apparently a big usability problem.

▲

packetlost 2 days ago | parent [-]

> Unfortunately, the designers of passkeys decided they should replace passwords and usernames and second factors.

They obviate the need for a user identifier as the key is itself unique, but removing the 2nd factor is a choice of the service, not the designers of the Webauthn standard.

> Also they decided they should be cloud-synchronised

The earlier versions of the spec required that the keys be resident in hardware, but it was updated to allow "roaming" keys. The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud). Most do not.

The usability problems are actually larger than that, see sibling comments for why. Passkeys, even when cloud synced, are still better than cloud synced passwords and still give the option of hardware backed keys for those whose threat model warrants it.

▲

ivlad 2 days ago | parent [-]

> The important part is it's up to the service to decide on whether they want to require hardware resident keys (which cannot be synced via the cloud).

From what I know, Apple ignores `platform` and `ResidentKeyRequirement` claims and always creates cloud-synced key pairs.

Moreover, the strongest claim value allowed for the `ResidentKeyRequirement` is “discouraged”, which per spec is treated as SHOULD in RFC 2119 since. In other words, browsers are free to ignore it when “they know better”, which Apple always does.

	▲	atanasi a day ago \| parent \| next [-]
		The service may require attestation and verify the actual authenticator metadata. If the passkey is not accepted by the service, it can use the signaling API to indicate that the passkey was not registered validly.
	▲	packetlost a day ago \| parent \| prev [-]
		Sure, but you can still use a Titan T3 or recent Yubikey model on an iPhone. If I had the threat model to justify it, I would not set up the passkey in Apple's infrastructure. It is too bad they ignore that though. That's really disappointing.

▲

account42 2 days ago | parent | prev [-]

> A particular service can choose to enforce those class of passkeys

And that's exactly why the technology should be rejected while we can. It's no business of a particular service how I use my devices.