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 · 3h ago
Ugly indeed, hopefully a successor that is actually open can emerge.
coldpie · 3h 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 · 3h 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.
WorldMaker · 24m 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 · 2m 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 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 ban users using that client. They even maintain a list of clients they feel violate the spec for UV.
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 come 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.
blibble · 3h 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 · 3h 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.
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/
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.
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.
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".
> 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 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 ban users using that client. They even maintain a list of clients they feel violate the spec for UV.
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 come 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.
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
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.