I wrote about this here[1] but it seems like Passkeys are fundamentally incompatible with open source software. I tried them out, and was initially quite excited for them. But it turns out the spec has first-class support for banning passkey clients, which I feel makes the spec incompatible with open source software. The spec authors feel this is a good thing and regularly threaten open source software with bans for not following the spec, and they even maintain a list of non-compliant clients[2], which relying parties could use to ban clients that allow users to manage their own data how they wish instead of how the spec demands.
It's a pretty ugly situation, and I'm quite disappointed by this. It could've been a cool technology, but until they straighten out the story of whether users are allowed to own their own data, I cannot support it.
[1] I initially wrote this as a pro-Passkey article, explaining how the marketing around Passkeys is ludicrously confusing for what is actually a pretty simple tech. But then I found the spec authors threatening open-source implementations with bans and had to revoke my endorsement. https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
> I suspect we’ll see [biometrics] required by regulation in some geo-regions.
I don't know a ton about the implementation, but the above or the “option” of requiring some kind of TPM or secure enclave worries me. I think it’s only a matter of time before a few select companies usurp control of identity.
Ultimately, I think we’ll be forced into subscriptions for authentication once government services are captured.
nand_gate•1mo ago
Ugly indeed, hopefully a successor that is actually open can emerge.
coldpie•1mo ago
I think all they need to do is remove attestation from the spec, or at least put very strong language around it that it should only be used for extremely secure environments where the data is not considered to be owned by the user, for example an account at your job. For end-user software, where they're currently promoting Passkeys, attestation is unacceptable. But, their behavior on the bug trackers indicates they don't even seem interested in having the conversation.
jerf•1mo ago
An open successor is basically impossible at this point. Years and years.
What can happen is that the open source and "noncompliant" passkey implementations spread to the point that it becomes impractical to block them, or something that can only be deployed to internal security where an organization can control their authentication mechanisms tightly because they provide the authentication tokens to their employees, and regardless of what the spec writers think or want, the de facto spec simply diverges from the de jure spec. It's not like that hasn't happened to basically every spec ever.
The good news is, I think the market is going to pushed pretty heavily in this direction for a long time. Bitwarden right now provides pretty much exactly the experience I am looking for from passkeys; I auth with my tool, and as long as I am authed, it provides the passkey. It already has mechanisms for not staying logged in indefinitely and requiring periodic refreshes, and I think passkey mechanisms that involve people basically still having to authenticate every time are going to be systematically disfavored in the market to ones that don't. Passkeys are a legitimate advance if I can do one log in in the browser or my password manager and be logged in to all my sites without further intervention; they're actually a downgrade if I now have to go through the effort of setting up a passkey and also still authenticating every time I want to use one. Whether or not it is abstractly a good idea, you can't just spec your way to something like this in practice.
blibble•1mo ago
I wouldn't worry about this too much, at least whilst the attestations in the spec remain anonymous
this necessitates sharing attestation signing keys between many devices
if someone starts banning non-trusted attestations then attackers will extract and leak yubikey's/microsoft's/... attestation signing keys
and which point anyone can sign whatever attestation they want
then the other side has to decide whether they lock out & ban thousands of innocent users, or accept the loss of control
coldpie•1mo ago
> then the other side has to decide whether they lock out & ban thousands of innocent users, or accept the loss of control
My worry is more that relying parties will ban all providers except for (more or less) iOS and Android and Windows clients. That would cover probably 99% of users, but as a side-effect, effectively completely ban open source software from logging in to the service. It's not hard to see a well-meaning person flipping the switch to only allow big-name providers in the name of "security," especially given the existence of the spooky non-compliant list actively maintained by the spec authors.
It's true we could work around this by stealing the tokens from approved software, but I am extremely uninterested in having my authentication rely on stolen attestation tokens.
WorldMaker•1mo ago
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•1mo 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.
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•1mo 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•1mo 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.
coldpie•1mo ago
It's a pretty ugly situation, and I'm quite disappointed by this. It could've been a cool technology, but until they straighten out the story of whether users are allowed to own their own data, I cannot support it.
[1] I initially wrote this as a pro-Passkey article, explaining how the marketing around Passkeys is ludicrously confusing for what is actually a pretty simple tech. But then I found the spec authors threatening open-source implementations with bans and had to revoke my endorsement. https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
[2] https://passkeys.dev/docs/reference/known-issues/
donmcronald•1mo ago
I don't know a ton about the implementation, but the above or the “option” of requiring some kind of TPM or secure enclave worries me. I think it’s only a matter of time before a few select companies usurp control of identity.
Ultimately, I think we’ll be forced into subscriptions for authentication once government services are captured.
nand_gate•1mo ago
coldpie•1mo ago
jerf•1mo ago
What can happen is that the open source and "noncompliant" passkey implementations spread to the point that it becomes impractical to block them, or something that can only be deployed to internal security where an organization can control their authentication mechanisms tightly because they provide the authentication tokens to their employees, and regardless of what the spec writers think or want, the de facto spec simply diverges from the de jure spec. It's not like that hasn't happened to basically every spec ever.
The good news is, I think the market is going to pushed pretty heavily in this direction for a long time. Bitwarden right now provides pretty much exactly the experience I am looking for from passkeys; I auth with my tool, and as long as I am authed, it provides the passkey. It already has mechanisms for not staying logged in indefinitely and requiring periodic refreshes, and I think passkey mechanisms that involve people basically still having to authenticate every time are going to be systematically disfavored in the market to ones that don't. Passkeys are a legitimate advance if I can do one log in in the browser or my password manager and be logged in to all my sites without further intervention; they're actually a downgrade if I now have to go through the effort of setting up a passkey and also still authenticating every time I want to use one. Whether or not it is abstractly a good idea, you can't just spec your way to something like this in practice.
blibble•1mo ago
this necessitates sharing attestation signing keys between many devices
if someone starts banning non-trusted attestations then attackers will extract and leak yubikey's/microsoft's/... attestation signing keys
and which point anyone can sign whatever attestation they want
then the other side has to decide whether they lock out & ban thousands of innocent users, or accept the loss of control
coldpie•1mo ago
My worry is more that relying parties will ban all providers except for (more or less) iOS and Android and Windows clients. That would cover probably 99% of users, but as a side-effect, effectively completely ban open source software from logging in to the service. It's not hard to see a well-meaning person flipping the switch to only allow big-name providers in the name of "security," especially given the existence of the spooky non-compliant list actively maintained by the spec authors.
It's true we could work around this by stealing the tokens from approved software, but I am extremely uninterested in having my authentication rely on stolen attestation tokens.
WorldMaker•1mo ago
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•1mo ago
> 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#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•1mo ago
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•1mo ago
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.