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.

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

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.