If you watch the original Apple WWDC talk presenting passkeys, you will find that they were always intended to sync, at least for the consumer use-case.
What you are describing is how the WebAuthn standard had been implemented by Yubico and Google up until the point of the introduction of “passkeys” by Apple.
The reason passkeys have their own name and definition is because they are meant to be a phishing-resistant primary factor that competes with the UX of passwords. And a great usability trait of passwords is that they’re convenient to use across all your devices. With a technology involving public/private keypairs, the only possible way to compete with that UX is to sync the private key across the user’s devices.
This is my issue with passkeys. Either we lessen security to improve UX (syncing across devices implies extracting private keys from secure enclaves, at which point it’s no different to password syncing), or we have a proliferation of different keys per website across devices (assuming the website supports multiple passkeys).
Perhaps this trade off is not resolvable in a way that happily satisfies both the security constraint and the UX requirement.
> 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).
1) When I buy a new device, how do I create 2000 new Passkeys for that device?
2) Can I still do that if I don't have access to the old device? Maybe it was destroyed, stolen, or lost.
3) How about if the new device is from a different vendor than the original device? E.g. switching from Apple to Android?
The biggest point of confusion in my opinion comes from Windows especially having lacked a way (and kind of still does) to save the private key of a passkey to your password manager, defaulting to saving it to Windows Hello, which saves the private key to your PC's TPM. In this scenario you can no longer easily copy the private key to other devices, and if you lose that Windows PC, you also lose the private key and the whole passkey as a result.
So your account is now tied to a physical device; great, but the device is dead, or you own a dozen devices, now what? Each vendor has their own idea about what THIS means. Heck I have a couple that allow, max, a single Passkey at a time.
No argument from me there, just stating what the design actually calls for.
It was never meant to be consumer friendly in the first place, it's an enterprise standard. It was just shoehorned onto consumers with the synced credential compromise to make it easier, instead of coming up with something better, and then just calling it a "Passkey" which now has dual meaning.
But the real solve is difficult. If a system requires a consumer user to manage, remember, or safely store something extra, it will fail.
1. PayPal was looking for a physical authentication solution for their users, Michael Barrett was their CISO at that point and he became the president of FIDO.
2. Google developed Gnubby (which was internal, and therefore enterprise) and they wanted to push a similar authentication to their end-users, supported directly on Chrome. They wanted this to become a standards, so donated the underpinnings of the Gnubby technology which became FIDO U2F.
I might be wrong but at least these are the two parts I know.
And while the original FIDO could be called dual-use, Webauthn and especially Passkeys were developed to be first and foremost a customer-facing standard.
It doesn't mean they are not confusing, but they are clearly designed with end users in mind.
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.
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.
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.
1. All passwords stored in password manager. 2. Login with password manager when logging in for the first time on a device. 3. Combination of OS and site/app notice that no passkey has been created for this account and offers to create one. This is presented to the user as “setting up the current device for password-less log ins.” 4. OS negotiates with site/app to install the passkey and use it for future log ins on the device.
It’s presented to the user as a convenience clearly tied to this device.
…but you still have your text password stored in the password manager’s servers…
If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.
But the original FIDO2 standard wasn't made with consumers in mind in the first place, it was driven by enterprises that wanted high-assurance security. It works in that environment because, well, a big IT department controls it, can support the employees, and you can mandate and control its use.
It was just sort of haphazardly shoehorned onto general users/consumers, prematurely IMO, via synced credentials as a compromise instead of coming up with something better.