4 ms·

Attestations are "Enterprise-grade" specs that mostly only impact "Enterprise Passkeys". Apple has made it very clear that they will never support Attestation

Attestations are "Enterprise-grade" specs that mostly only impact "Enterprise Passkeys". Apple has made it very clear that they will never support Attestation on consumer hardware. So long as Apple is a leader in consumer hardware, consumer apps can't rely on any sort of cryptographically-signed Attestation data being meaningful. > I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails. This is most of what is wrong with your argument, I think. "Relying Party" is just fancy security lingo for "website or app that accepts Passkeys" (someone that relies on a passkey, as opposed to provides one), as in any or all of them. There's no "spec" for blocking clients. What you saw wasn't really a "threat" that a banhammer might come down. There's just the million different ways that websites can implement them, and some of them may reject Passkeys without certain metadata or attestations. But you will find out quickly on sign up with that key. It's kind of like some websites blocking passwords without a symbol in them and others don't care if you like symbols or not. That said, it's also a lot like blocking users based on User Agent string. It's a wild west out there of different mixtures of metadata and/or attestation, some Passkeys just outright lie or pretend to be like the key of someone else. Apple has made it clear their consumer-grade Passkeys send the bare minimum and not much else. If a website wants to support average iOS users, they can't rely on any fingerprinting from Attestations and they have a bare minimum of other key data. But there will be (already are) "Enterprise-Grade solutions" from companies like Microsoft and Google that want to keep corporate networks "extra secure" and will require you to use Genuine Microsoft Passkeys for Enterprise 2025 Edition Pro or Google Workspace Passkey Manager for Google Authenticator on Android Ultra Secure. It wasn't a "threat", I don't think, it was an acknowledgement that things are complicated. Also complicated, the "threat" wasn't even directly about Enterprise-grade (cryptographic) Attestations but the "Passkeys can be both first and second factor and Passkeys can claim that they did that" feature. It's mostly a simple boolean field "checked the user had a second factor" and the open source tools can mostly just lie and there is no way to cryptographically verify that. Apple does lie the other direction (so far as I've seen, Passkeys always use the biometric unlock on iOS, but the keys themselves don't state that they did). It is part of both sides of the ongoing debate about whether or not Passkeys count as one or two factors, websites are making both choices today, and no one can agree, and the spec doesn't help and can't actually threaten anyone to comply with "my Passkeys are always two factor".

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

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.