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•1h ago
Ugly indeed, hopefully a successor that is actually open can emerge.
coldpie•1h 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•1h 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•1h 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•1h 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.
coldpie•1h 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•1h 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•1h ago
coldpie•1h ago
jerf•1h 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•1h 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•1h 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.