I don't think that's a fair analogy. Unlike Lynx, which lacks a ton of modern browser features, KeepassXC is a fully functional Passkey client. There is no tech

I don't think that's a fair analogy. Unlike Lynx, which lacks a ton of modern browser features, KeepassXC is a fully functional Passkey client. There is no technical reason to reject KeepassXC logins, while there are legitimate reasons to reject a browser that doesn't support graphics or javascript. Yet the Passkey spec authors are making threats about KeepassXC being banned and listing it on their non-compliant client page, because it allows users to handle their own data in a way the spec authors dislike. A better analogy would be a website blocking Firefox users because Firefox stores cookies in a way the website owner dislikes. A website intended for use by anybody, that chooses not to serve content based on the user's browser client, would be correctly considered broken. On the other hand, the Passkey spec authors are explicitly saying RPs should make rejection decisions based solely on the client. I agree implementations can be all over the map here, but what's giving me pause is the explicit endorsement of banning clients by the authors of the spec. > I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. The incompatibility is that the spec requires the client software to behave in a certain way, or RPs may choose to reject logins from it. Open source software simply cannot make those guarantees. I have the freedom to make my implementation non-compliant. If an RP wants strict compliance from the providers they accept (which is a position explicitly endorsed by the spec authors), then they must only accept closed-source software.