> Approximately nobody thinks users shouldn't be able to access their keys in the general case

Citation needed. To me it seems to be the quiet part that they aren't saying out loud. If it's just a consequence of the spec being unfinished, then they shouldn't threaten to ban KeepassXC for this. The purpose of a system is what it does, and commercial passkey implementations lock users out of their credentials and uses it to strengthen vendor lock-in.

> Is it a super useful feature? No

It's security theater and a way for websites to annoy users unnecessarily.

> KeePassXC is not "being threatened with being banned via attestation".

https://github.com/keepassxreboot/keepassxc/issues/10406#iss...

It's a thinly veiled threat. Making a certification process and refusing to certify KeepassXC is exactly the same as banning it.

I’m not happy with everything about passkeys either. I am fine with them as an additional method, but I would never use them as the only method.

That said, I had a much easier time getting my kids onboard with a FIDO2 security key than I would have a password manager.

Enter your email and touch this is easy to understand.

I do get that there are use cases for actual hardware bound keys for enterprise settings. But having non-exportable credentials (effectively non-ownable) is not acceptable in a consumer setting. This is a thinly veiled attempt at strengthening platform lock-in.

Look, the spec says you can't export the keys to a file! Too bad, go re-register your 120 websites if you want to stop using iCloud/Google!

> they want the keys stored in an encrypted way, is that too much to ask for

Well, they are encrypted but the issue is talking about exports. The maintainer of KeepassXC already mentions the issue with that: portability. A backup of such sensitive data (a password manager) is going to be stored somewhere secure (to the user) already. Why would you encrypt the contents and add another layer of complexity that other tools may not be able to handle? I want to be able to rely on those backups in the future and copy paste them around manually if needed. It's user choice, put simply.

A specification committee should never be deciding what a user does with their data, period. The security maximalist is always going to advocate for the most secure thing but most of the time that's not practical or friendly to humans.

That's the thing, they can't yet.

They are proposing an attestation scheme. I'm not sure the details are out yet, but the authenticator would presumably use one of the hardware security mechanisms (like a TPM bound key) to "certify" its own authenticity along with the challenge.

This will effectively ban all open-source implementations, and end user freedom if widely adopted. Fortunately for us it seems like Apple isn't cooperating here for now, and without Apple signing on, it wouldn't get anywhere.

Well, it's stored in an encrypted way - in the encrypted password database. Much like a password, everyone already knows not to share a passkey. But also like a password, as the owner, sometimes I want to look at it!

> ask for

That's the key difference. If it mattered, they would make it part of the spec, not threaten a ban. That's even more concerning, there is a central group of people who get to decide who can and cannot use Passkeys.

It's an export format. The storage is always encrypted with the database key. And you can view the key directly anyway just like you can view passwords, and copy it from there.

No, the private key is generated and stored client-side, and never sent to the server. Even if that wasn't the case, how I store my credentials is none of the websites' business, and my own hardware should do as I say.