> 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.