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

> Which defeats part of the point of passkeys in the first place in that they are supposed to be device-bound

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.

Right; but THAT idea is consumer hostile by design.

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.

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

This is exactly all the stuff normal people don't care about.

If your system requires any basic intelligence or interest scrap it and go back to the drawing board because you just lost your customers.

Seems like the flow should be:

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…

Device-bound would be a nightmare. I don’t want to have to think about different credential for phone vs. laptop, etc.

In the Apple ecosystem, passkeys are stored in your iCloud, and access to the passkeys is device bound. So if I generate a passkey on a MacBook, I can then use it from my iPhone as well, because it's encrypted to all my hardware devices.

I don't want my computer to be able to decide I'm not allowed to access something. I'll never use these.

I do not want my identity to be device-bound. I want it to be me-bound.

Wouldn’t it be better to use envelope encryption and sync the passkeys? I mean with envelope encryption somebody would probably be able to create a rfc that would support cross browser/password manager sync a passkey by using a encrypted envelope that would be able to be deceptively wither via tpm or by using credentials so when syncing it would ask for upn/password of the original device or something so it can even be e2e encrypted, so some kind of federation protocol for password managers that you own