[amluto]

I disagree. Not necessarily in principle, but because there is no good way for a passkey app to distinguish between a competent user and a malicious actor pretending to be a competent user. Passkeys are, in a sense, very very dangerous — with passwords, everyone knows that a password can be compromised, and any competent security system needs to tolerate passwords getting compromised. But passkeys (and TOTP secrets and such) are treated as long term secrets. If a website enrolls a passkey supposedly attached to an Apple keychain, then that website would like to be able to trust that a compromise of the Apple account that is subsequently recovered will not result in a persistent compromise of a passkey that predates the compromise and recovery.

If a passkey can have its private key exported, by anyone at all, then this property is lost. I do not want access even to my own passkey private keys!

I certainly don’t love having a few gatekeepers in charge, but the protocol (currently?) does not really support a good alternative. And doing better is hard!

[socksy]

> If a passkey can have its private key exported, by anyone at all

But it's not by anyone at all. It's only by users that have unlocked their database. I really don't see the attack vector here.

It's not like the Apple Keychain at all, since your interaction with Keychain is very different than KeePassXC, which makes the locked vs unlocked state very explicit (and you're almost always auto locking anyway), whereas Keychain is something happening in the background that sometimes prompts me for my password/fingerprint. I have no idea what the state is there and would be very annoyed if someone could leak all my secrets just by accessing my computer.

With KeePassXC I'm always aware if it's open or not, because I can't use it without knowing that, and I had to make a very explicit opening of it. Because it uses local files and not the cloud, it's very important to me to be able to import and export the contents. Without that ability, I will lose access to my passwords.

[shmerl]

Passkeys are advertised as more convenient form of private / public keys approach. So how is that any different from other usage of private keys which are considered long term secrets? Incompetent users can compromise them now too.

It doesn't mean it should be easy to do, but it's also completely unacceptable to make a requirement like "users are forbidden to access their private keys".

> by anyone at all

What do you mean by anyone at all? By the owner of the private key. Not by anyone.

[amluto]

> What do you mean by anyone at all? By the owner of the private key. Not by anyone.

If I log into my computer and turn my private key into a plaintext blob, as a file or a Python object or something on a USB stick or a QR code that I photograph, then anyone who happens to have compromised my computer at the time has my public key, too. Even if I subsequently fix the compromise, they still have my public key.

I do not want this to happen.

[csande17]

IMO one of the biggest issues with the Passkey spec is that it doesn't provide a way to automatically rotate credentials. The entire security model relies on Apple/Google/[insert name of nonprofit they end up allowing through the DRM gates to avoid antitrust suits] being completely infallible, forever.

[shmerl]

That's why normally private keys (like when used with ssh for example) are paired with something like a passphrase that should offer an additional layer of protection. But still, you (the owner of the private key) can access it. You should keep both your key and your passphrase secret. Not sure what passkeys are doing about it, but I still don't see any valid reason for the owner not to have full access to the key.

If someone has sufficient access to your computer (like being able to keylog and stuff) - it's somewhat late to worry about keys being compromised.