Passkeys will come at a cost

I have always understood that Apple defined a Passkey to be a key pair that is synced through iCloud Keychain. Even their WWDC 2021 presentation distinguishes passkeys to be different than security keys because they are "always with you" (the device sync aspect) and "recoverable". I think the definition was later extended to other cloud sync methods.

I also think the article makes the wrong trade-offs. Security keys are not important [1]. They are only used by a negligible number of technical users and a small number of companies that really care about security. Getting people off passwords is necessary for improving web safety and 99% of the population is never going to use security keys unless they are forced to. Passkeys do have a good chance of getting people off passwords, especially with deep OS integration. We shouldn't optimize authentication for that 1% or less because they'd be running out of resident key slots.

[1] I am the owner of 3 Yubikeys, 3 Yubico security keys and a SoloKey.

This flies in the face of previous promises where 'every key can handle an unlimited amount of accounts'. In my eyes, this looks like a big push towards phones as passkeys, and nothing else. Would fit with the Bluetooth sync strategy as well.

you have a backup of a _different_ secret with a similar degree of "authority" (or if it's "copyable" with the only authority to be used for restoring 2FA once or similar)

then if you backup gets stolen you can just go into you account management API and disable/delete/flag it, in that case even if encryption is broken as long as you act fast enough the damage is trivially and conveniently contained (e.g. some password managers had insecure backup/storage in the past)

with the same key not only do you have to disable it, you first have to create a new key and then sync it to all your new devices and backups and then disable the old key, which isn't grate if you have more then one device or some of you devices are temporary out of reach (e.g. you one a business trip)

it's like reintroducing the "physical" problem of having to replace all locks when you loose your house key in a situation where you could have all the benefits one key per lock and a different door for each person (i.e. device) without any of the overhead/drawbacks this would normally introduce

Resident keys allow the browser to query the secure element for a list of usernames for a domain. It’s a nice feature, but you have to setup the protocol to reliably fallback to non-resident keys on secure elements that are space constrained.

But then they came up with these resident key “preferred” and “discouraged” keywords which are sent by the site?! And then the various clients all interpret them differently so there’s no obvious way for a site to let clients with secure elements with practically unlimited storage to opt-in to resident keys while limited storage secure elements stick with the wrapped/derived key.

The current situation is if you send “preferred” you’ll fill up limited space YubiKeys, and if you send “discouraged” then Androids with practically unlimited storage won’t use resident keys.

Clients should decide based on their capabilities and should always opt for residency if they have unlimited storage. The protocol should have been defined with just a boolean ‘required’ field for residency, which would only be used in highly unusual circumstances (which I’m not sure what those are — what’s the justification for a site requiring residency?)

One day we’ll get it right…