3 ms·

Thanks for your reply. I do want this tech to work, so I keep hoping I'm wrong here. Unfortunately, you haven't convinced me yet. > some of them may reject Pas

Thanks for your reply. I do want this tech to work, so I keep hoping I'm wrong here. Unfortunately, you haven't convinced me yet. > some of them may reject Passkeys without certain metadata or attestations. But you will find out quickly on sign up with that key. I don't think that's applicable to the case I'm talking about. A relying party could change their implementation to ban the client you are using, after you set up the passkey. When you try to log in later using your private key via an implementation they have now banned, they could reject your log in. The main (though not only) spec compliance at issue is the truth of the "User Verification" boolean when submitting your unlocked private key to the site for authentication. While it's true that your client could lie about this and the RP would not know, the spec authors view this as a violation of the spec, and a valid reason for RPs to reject users using that client. As I linked earlier, they even maintain a list of clients they feel violate the spec for UV. > the spec doesn't help and can't actually threaten anyone to comply with "my Passkeys are always two factor". The spec authors are very explicit that clients not meeting their standards are at risk of being blocked by relying parties. See: >> RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference > It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture. https://github.com/keepassxreboot/keepassxc/issues/10406#issuecomment-1994313373 https://github.com/keepassxreboot/keepassxc/issues/10406#iss... The spec authors' comments on these issues make it very clear that they feel RPs may correctly block users for using clients that do not handle user data in the way the spec authors want them to. This isn't some corner case, it is explicitly built into the spec. I consider that to be incompatible with open source. It's my data and my software. It's my choice what software to use and how to handle my data. If I may be prevented from logging in to my online services because I use software on the naughty list, then that is not an acceptable authentication method to me.

WorldMaker 1y ago
It still feels to me like you are maybe too worried to be using Lynx (in all its open source glory) for all your web browsing because of the possibility that one or two websites may block the User Agent for Lynx because they don't want to support text browsers. User Agent strings are part of many HTTP specs. Enforcing User Agent strings isn't a part of the specs and is a huge mess that is wild and chaotic and varies from webserver to webserver. You are far more at risk of a webserver serving a website to Lynx that is simply broken by accident than outright "banning" it intentionally, and the "bans" are distributed and handled in different ways by a million different webservers, some of which are themselves open source, such as Apache or nginx. I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. There are open source Relying Parties. I've written an open source Relying Party. I've used an open source provider. This part of the spec is complicated and there's some fights over it, but part of the reason we're even seeing some of the fights is because open source cares on every side of this debate.
- coldpie 1y ago
  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.

WorldMaker 1y ago

It still feels to me like you are maybe too worried to be using Lynx (in all its open source glory) for all your web browsing because of the possibility that one or two websites may block the User Agent for Lynx because they don't want to support text browsers. User Agent strings are part of many HTTP specs. Enforcing User Agent strings isn't a part of the specs and is a huge mess that is wild and chaotic and varies from webserver to webserver. You are far more at risk of a webserver serving a website to Lynx that is simply broken by accident than outright "banning" it intentionally, and the "bans" are distributed and handled in different ways by a million different webservers, some of which are themselves open source, such as Apache or nginx. I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. There are open source Relying Parties. I've written an open source Relying Party. I've used an open source provider. This part of the spec is complicated and there's some fights over it, but part of the reason we're even seeing some of the fights is because open source cares on every side of this debate.

coldpie 1y ago
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.