> I've changed the title back to my original text to stay on the record here that this is a really bad idea and I strongly recommend you temporarily disable thi

> I've changed the title back to my original text to stay on the record here that this is a really bad idea and I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption. > To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406). This cements a lot of criticism I have of Passkeys as a standard. As of now, KeePassXC is the only implementer I'm aware of that makes it easy to export passkeys. There is no standardized import/export mechanism from any other provider and no timeline of when that will happen other than "we're working on it." I've been told before that Open implementations of Passkey providers would come and we wouldn't have to worry about the spec being largely proprietary, locked-down implementations. But with an Open implementation that serves the user in allowing them to export and import that data, there's pushback that the implementation shouldn't exist, and suggestion that even an encrypted export should be a "temporary minimum bar". So it does not seem to me that the Open implementations matter. In particular, the threat of blocking KeePassXC by relying parties should be interpreted as a threat against Open implementations that deviate from the spec (even though I know Tim has good intentions and does not intend it that way). ---- > Passkey provider certification, migration, spec development, etc is part of the FIDO Alliance. Please reach out directly and I we can talk about how to get you engaged in the discussion We are long past the point where these conversations should be happening completely in the open. The continued lack of portability in the Passkey ecosystem is only made worse by the closed and private nature of the conversation surrounding it. As time continues to tick on and on and more and more articles suggest that users move over to what is, frankly, an incomplete specification with a fatal flaw, it becomes harder and harder to see the continued delay of real universal portability guarantees as a temporary setback. At the very least, these kinds of conversations should serve as a warning against assuming that Open Source providers of Passkeys are necessarily going to be able to paper over the real flaws in the spec, particularly around data portability, attestation requirements, and hardware requirements. Half-baked promises are a large part of Passkey advocacy. With KeePassXC allowing real export and direct user access to encrypted keys, we get to see the actual industry reaction when an org tries to fulfill those half-baked promises. To be clear, I do not think that Tim Cappalli is operating in anything other than good faith and that he wants anything other than the best for the product. This is not Tim being evil, but the FIDO spec and approach to standardizing Passkeys is necessarily flawed and results in these kinds of threatening outcomes and requirements on user agents regardless of the intentions of any individual members or advocates. You don't have to think less of Tim Cappalli or think that he's operating in bad faith to understand that this kind of rhetoric is still threatening. ---- Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap.