> I've changed the title back to my original text to stay on the record here that this is a really bad idea and I strongly recommend you temporarily disable this feature or at a minimum require file protection/encryption.
> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).
This cements a lot of criticism I have of Passkeys as a standard. As of now, KeePassXC is the only implementer I'm aware of that makes it easy to export passkeys. There is no standardized import/export mechanism from any other provider and no timeline of when that will happen other than "we're working on it."
I've been told before that Open implementations of Passkey providers would come and we wouldn't have to worry about the spec being largely proprietary, locked-down implementations.
But with an Open implementation that serves the user in allowing them to export and import that data, there's pushback that the implementation shouldn't exist, and suggestion that even an encrypted export should be a "temporary minimum bar". So it does not seem to me that the Open implementations matter.
In particular, the threat of blocking KeePassXC by relying parties should be interpreted as a threat against Open implementations that deviate from the spec (even though I know Tim has good intentions and does not intend it that way).
----
> Passkey provider certification, migration, spec development, etc is part of the FIDO Alliance. Please reach out directly and I we can talk about how to get you engaged in the discussion
We are long past the point where these conversations should be happening completely in the open. The continued lack of portability in the Passkey ecosystem is only made worse by the closed and private nature of the conversation surrounding it. As time continues to tick on and on and more and more articles suggest that users move over to what is, frankly, an incomplete specification with a fatal flaw, it becomes harder and harder to see the continued delay of real universal portability guarantees as a temporary setback.
At the very least, these kinds of conversations should serve as a warning against assuming that Open Source providers of Passkeys are necessarily going to be able to paper over the real flaws in the spec, particularly around data portability, attestation requirements, and hardware requirements. Half-baked promises are a large part of Passkey advocacy. With KeePassXC allowing real export and direct user access to encrypted keys, we get to see the actual industry reaction when an org tries to fulfill those half-baked promises.
To be clear, I do not think that Tim Cappalli is operating in anything other than good faith and that he wants anything other than the best for the product. This is not Tim being evil, but the FIDO spec and approach to standardizing Passkeys is necessarily flawed and results in these kinds of threatening outcomes and requirements on user agents regardless of the intentions of any individual members or advocates. You don't have to think less of Tim Cappalli or think that he's operating in bad faith to understand that this kind of rhetoric is still threatening.
----
Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement.
Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap.
>> "Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement. Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap."
There was a public Authenticate Conference session today that talked about the status of the credential migration specification drafts.
Looking forward to watching it if/when it's posted online. That being said, a tech conference "where are we" video recording is a far cry away from an Open standardization process.
The lack of real details on this has been infuriating, especially given that Passkey advocates are pushing Passkeys for regular users and enterprise customers right now. Portability should be a blocking feature -- if it had been treated like an essential feature instead of a post-launch nice-to-have, we wouldn't still be waiting for an answer on it a year after people started raising these complaints.
The lack of transparency allowed a lot of advocates to dismiss what were in retrospect extremely valid concerns about how portability was going to be handled. Advocates dismissed those concerns by talking about how the ecosystem was still young, this was all beta, solutions were coming. And then gradually the "beta" talk vanished, but the solutions never came -- it played out exactly as critics predicted.
This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come; it turns a technology that should be a clear and easy security win into an ideological fight about open standards and user control over their accounts and their identities -- none of that fight was necessary. It's wild to me how this kind of stuff has been handled; there is absolutely no excuse at all for these conversations to be happening behind closed doors.
Tech conference talks are nice and I welcome getting any information at all about progress on portability. Genuinely, I am so hungry for even just a crumb of information about portability, I'll be very happy if that talk gets put online. But this is all a far cry from timelines, open discussions, open calls for feedback, or open implementations. Tech talks are not a standardization process.
I mean, heck, step away from portability even. This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard. That is a conversation that should be happening openly and publicly with public input through official forums or issue trackers. That is not a conversation that should be happening just amongst FIDO members, and it's absurd to learn about the existence of that conversation through an unrelated Github issue.
But I'm just shouting into the void, I guess. The Github issue ends with "I will send you a dm/email". So that's another conversation that will be moved behind closed doors. Well, what's another year? We'll all just wait patiently while we're constantly told that we should be using what is today a locked down, proprietary ecosystem that is actively pushing back on Open implementations trying to solve the problems that the FIDO alliance either won't or can't currently address by threatening disqualification from the ecosystem. Of course, Open providers being threatened via attestation was another thing that I was told by advocates not to worry about, but whatever, we'll all just keep trusting people.
Nearly all work to support passkeys is via the WebAuthn specification, which is developed entirely in public via a GitHub repo (https://github.com/w3c/webauthn).
Passkeys aren't a standard or protocol. A passkey is the name of a type of credential that can be used via the WebAuthn API, an open industry standard for phishing-resistant authentication on the web platform.
>> "This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come"
Passkey adoption is currently growing exponentially. Faster than we could have ever imagined when we started this work 3 years ago. New ideas will help adoption with organizations that have certain regulatory requirements for strong authentication (e.g. banks and lenders).
>> "This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard"
Many of the highly regulated relying parties that need attestation aren't even members of the FIDO Alliance. Attestation is already supported (and has been since day 1) for any WebAuthn credential and is widely deployed by many authenticators. WebAuthn is an open standard. The challenge is that the current attestation model needs some updating to work with synced passkey authenticators. Previous iterations of this technology used credentials which were device-bound (now called device-bound passkeys).
>> "Genuinely, I am so hungry for even just a crumb of information about portability,"
I think you will be very happy with the content of the session from today then.
>> "The Github issue ends with "I will send you a dm/email""
My goal with that is to bring that feedback into the WebAuthn spec work, which happens in public.
This is a silly distinction to make. Passkeys are the standard word that most ordinary people use when talking about this specification. And this changes nothing about the fact that the conversations about portability have not been happening in the open.
If WebAuthn is an open industry standard, why am I getting news about the conversations about standardization from a tech talk? Where are the meeting notes? What's the mailing list I can join?
This is part of what's frustrating about these conversations. It feels like the words are constantly changing depending on what advocates need to say. The linked issue is not shy about talking about export as a standard. This is not something that we need to debate, everyone reading these conversations knows what is meant when we are talking about a passkey standard.
And even if you for some reason don't want to use that word -- again, this changes nothing about the nature of the conversations that have happened around portability.
----
> Passkey adoption is currently growing exponentially. Faster than we could have ever imagined when we started this work 3 years ago.
This is exactly what early critics were worried about and warned about. There is a hecking reason we all pushed for portability to be built into the webauthn spec from day 1. Because we knew that this would happen, and everyone said, "no, it won't it's just early days, we're working on it." Well...
So now people are deploying this to production. It is not early days anymore, and portability still shows no sign of shipping. Talk is cheap, and we were all promised that the lack of portability was just because the spec was too new. And we're still waiting.
> New ideas will help adoption with organizations that have certain regulatory requirements for strong authentication (e.g. banks and lenders).
Sure, this is exactly what I have been told over and over again by advocates. Nobody is going to do attestation other than banks and governments.
Now, put aside the fact that a consumer bank or lender having the ability to require a proprietary passkey provider is itself a dubious concept for user freedom. Put aside the fact that we are discussing a standard that could potentially have the consequence of making it impossible for me to sign into my bank using only FOSS software. Put aside that most banks I've interacted with don't follow these kinds of standards anyway (when was the last time you saw a bank with actual compliant 2FA support?) Put aside that it's not completely clear which regulations would block banks from using a standard without attestation (they use passwords today). Put all that aside, and it turns out that attestation also goes beyond regulatory requirements for niche orgs.
In this very issue you raise the possibility of providers being blocked for spec deviations. That is a step beyond banks and lenders wanting specific apps, and it's exactly what advocates told me wasn't going to happen. And normally I'd try to be more diplomatic about this, but I have been having this gosh-darned conversation for years and at some point you have to call a spade a hecking spade.
If providers are being threatened (and I know you didn't mean it as a threat, but it is still a threat) for spec deviations, then attestation is a heck of a lot bigger than regulatory requirements for banks. And that is a conversation that needs input from ordinary everyday users, not just from tech companies.
> Attestation is already supported (and has been since day 1) for any WebAuthn credential and is widely deployed by many authenticators.
And has been critiqued since day 1 over the exact fears that are raised in this issue. And genuinely, I think the tone of the conversation on this Github issue justifies all of those fears. But also, expansion of that system is just as consequential, and I do sort of want to call out that I think you shou...
I'm not trying to do callout posts or anything here, I know that the people involved are genuinely trying to do their best. I'm grateful that Bitwarden is involved with passkeys. But, for all of that gratitude, I still have to say: Bitwarden got a huge amount of attention for being the Open Source implementation of this, and Bitwarden and 1Password were both used as examples that shut down criticisms about portability, and lack of communication and clarity is a big part of how Bitwarden/1Password got used to spread what I would genuinely consider to be misinformation about the current state of the passkey ecosystem.
It's not just that export wasn't supported, it's that this giant limitation that was in many ways the reason why people were so excited about Open implementations in the first place was quietly left unsaid.
I really genuinely do appreciate the work everyone is doing. But at no point when Bitwarden was writing posts and releases about passkey support did anyone writing that stuff think, "people will think this means export is supported, we should clarify that."?
It's so hard not to look at this communication and not feel that these kinds of details were deliberately omitted. I'm sure they weren't! I know that my emotions are incorrect and that everyone involved means the best. But crud, that is how it feels.
How many people who got excited about Bitwarden's implementation even know that they still can't export and import their passkeys? Maybe that'll be a fun surprise for them next time they try to do an import into a new account. Bitwarden's announcements didn't mention this limitation, and as a result no press coverage of Bitwarden mentioned this, and any casual observer who didn't know to go read the documentation and deliberately ask about it would come away from this coverage thinking that export was supported -- and in fact I would argue people did. People think the portability problem is solved because Bitwarden and 1Password exist.
Needing to double-check this kind of stuff, not having transparency or open conversations about any of it is part of the regular frustration of trying to learn about the passkey ecosystem. Very often when I talk to people in industry about passkeys, I will get answers that really sound like they are addressing people's concerns. And then you dig into them, and... they don't. But that's never communicated unless you do the research. So much of the advocacy is saying stuff that is technically true, but has huge unmentioned caveats or that doesn't actually when you dig into it address the concerns that people have or is using some weird definition that isn't what most people would use.
"Passkeys are portable now!"
"So I can export them?"
"Well, that depends on what your definition of portable is."
Bitwarden never technically said that it supported export, but I'm going to go out on a limb and say that a lot of casual observers reading about portability and sync and OS-independence think that Bitwarden does support export, and Bitwarden really isn't going out of its way to avoid that impression. I mean, props for having it in the user docs, that is better than 1Password. +1 for Open Source being more transparent than proprietary software, genuinely I appreciate it. But the only reason I know that Bitwarden doesn't currently support export... is because I knew that I couldn't assume it and I knew that I needed to check the docs. It's not something that's communicated in the announcement, it's not something that's communicated in the FAQ, it's not something that's communicated in any press coverage, it's not something that's communicated unless you know what to Google search.
I'm excited and eager for more of the actual work to be public and open, but I also kind of have to frank about how low the bar is right now. Nothing is communicat...
> And genuinely, I think the tone of the conversation on this Github issue justifies all of those fears.
I found that conversation to be straight up chilling.
> because in its current state I can't recommend anyone that I know -- at all -- use passkeys.
In the end, personally, it's about whether or not I am willing to use passkeys. If I am not willing to use them, I certainly am not willing to recommend that others do so.
To use passkeys already means giving up quite a lot. That's not necessarily a showstopper, if the benefits outweigh the drawbacks. Personally, right now, it's not an easy call at all.
The attestation issue, as well as the sentiments expressed in the github thread, don't exactly help.
>(…)the need for functional and security certification, and the lack of identifying passkey provider attestation (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations).
What a nice guy… Basically saying do what we say or we will make the treacherous part of your device do it against your will.
I don't think that Tim meant it that way, but I do think it's an indication that attestation can be used that way. I think it's somewhat missing the point to say that Tim is being mean; Tim could be entirely supportive and this would still be a danger and would still be a risk that FIDO has to address and that it's currently ignoring.
This is a spec issue. There are (as far as I can tell) no penalties or mechanisms to guard against businesses using attestation punitively to punish actors that deviate from the spec even when that deviation is in the interest of users. We are relying on corporate good will, and corporate good will is not something that ought to be relied on. Now, what that comment reveals is that there are multiple actors pushing to extend attestation to roaming keys and to have even fewer safeguards against excluding clients from the ecosystem.
That's scary, and that's a much bigger problem than one person.
When Apple zeroed out attestation requests for its roaming keys, I was told by multiple advocates that this meant that attestation would not be coming for roaming keys, and that attestation would never be used this way. After all, attestation was primarily intended (they told me) for regulatory compliance in industries that were primarily worried about device-bound keys. "What is Apple changes its mind" was dismissed as fearmongering.
But here we see the danger of setting expectations about an ecosystem based on Apple deciding randomly not to do something. There was no public commitment from FIDO not to pursue additional attestation for roaming keys, and behind the scenes it looks like players calling for that attestation have more sway than advocates let on.
So we end up with essentially a threat against implementations that deviate from the standard even when they are deviating in the clear interest of users. I don't think Tim meant it as a threat, if anything he was probably trying to be helpful. But it is still a threat regardless of the intention. And it's a threat because the ecosystem explicitly exposes tools to enable this kind of behavior. It's not a threat because of Tim, it's a threat because it's plausible. And it shouldn't be plausible.
This is why attestation is dangerous without safeguards; and the FIDO alliance has completely ignored the need for safeguards. Maybe there are conversations that I'm not privy to -- there probably are. But from the outside, it looks like a lot of people hoping that Google and Apple and Netflix and your bank will all magically care about not locking users to hardware and will completely voluntarily choose not abuse attestation. And I'm sorry, that's just not in their nature to do. If the spec directly gives these companies tools to be abusive, then they're going to be abusive.
>This is why attestation is dangerous without safeguards
Exactly. And these safeguards would need be legal. Seeing that the EU can't even force Apple to let me install a .ipa file on iOS without jailbreaking, I think it's safe to say we are fucked.
Being able to zero-effort cleartext a passkey strips it of the HSM-lite properties that make it safer than passwords. Attestation reintroduces those properties, by restricting use to those that adhere to them. Of course they’re going to pivot to attestation — there was no other possible outcome given the passion invested into total freedom — but it was still kind of them to try and let people voluntarily adhere to their principles first. Non-compliance is too valuable a niche for that to work, both for believers and for profit, so of course here we are.
I’ve already posted at length on HN about the risks of treating attestation as evil and refusing to discuss its benefits at all, and how that manner of engagement will lead to it being widely adopted over the objections of an uncoordinated minority. The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
I still expect the big wake up call is going to be in a couple years when Steam enables attestation in their Linux product and VAC begins requiring it, but at least the ripples of LXC’s approach are being seen at all.
> I’ve already posted at length on HN about the risks of treating attestation as evil and refusing to discuss its benefits at all
I've seen lots of discussion about the benefits on HN.
But attestation really is fundamentally opposed to freedom. It allows someone else to dictate how you use your own machines. So, the debate necessarily revolves around whether or not it's worth it to give some freedom up for this.
Some people will say it is, others will say it's not.
> yet no one discusses how freedom and attestation might coexist
How could they coexist? I honestly don't see it, but that's likely a result of my own lack of imagination.
Is this intended to be a password replacement or not? Because attestation requirements for roaming keys are incompatible with a password replacement.
> Being able to zero-effort cleartext a passkey strips it of the HSM-lite properties that make it safer than passwords.
You might have an argument if we were talking about device-bound keys. But the second we start talking about roaming keys, this just becomes a bad excuse. iCloud accounts can be phished, Google accounts can be phished. Roaming keys are vulnerable to phishing. The ability to export a key (encrypted or not) does not change that.
Device-level attestation and platform control over keys is out-of-scope and inappropriate for a credential that is fundamentally designed to live on multiple devices. We aren't talking about Yubikeys or device-bound keys, we're talking about roaming keys that are designed to get synchronized to the cloud and moved between devices at the direction of the user. Necessarily, there is going to be some level of phishing risk. We've accepted that because device-bound keys are unacceptable for most average users even if they're more secure.
Notably, this does not mean that passkeys are useless or that they are not phishing resistant. There are a large number of security benefits from passkeys even though they are not completely phishing proof. Those benefits do not go away if attestation is not supported for roaming keys, nor do they go away if users are able to decrypt their own keys. And given that companies like Apple led on zeroing out attestation requests for roaming keys, there clearly is not consensus in the FIDO Alliance about whether attestation is desirable or necessary for roaming keys.
Passkeys in a world where users can inspect and access their own keys are still a meaningful security improvement over passwords. And importantly, the lack of attestation makes it more feasible that they will actually be used. The goal is not to make something perfectly secure, the goal is to replace passwords with something better. I am continually surprised to see how little people understand about the myriads of use-cases that passkeys will need to support if they are going to actually replace passwords, and how little they seem to care about the ability of an attestation-encumbered system to handle those niche cases.
I've been in this space for a while. First, advocates told me that roaming keys were never going to happen because the whole point was for keys to be device-bound. Then it turned out, well, that's a dealbreaker, so we can compromise on that. Then I was told that sharing passkeys was never going to happen because it would destroy the security benefits. Well... okay, now we support sharing. Then I was told that migration was out-of-scope and the FIDO Alliance was not going to get involved. Now the FIDO Alliance is involved. Then I was told that export was fundamentally insecure, and any migration between providers would need to happen via a secure channel online or without ever putting the passkey on disk. And now I'm told that, okay, we can put the passkey on disk, but the problem is that it's zero-effort to get a cleartext. And at every step of that process, I'm told that these are non-negotiable security properties of WebAuthn.
Well, after a while these all start to feel less like security principles and more like excuses for why export isn't happening. It's weird how these security principles only get brought up in regards to user freedom, and not in regards to Apple supporting passkey sharing over Airdrop. I'm sorry, that doesn't open up phishing risks?
Tim suggests in this issue encrypting the passkey with some kind of additional key on export. How does that mean that HSM properties are preserved? The horse is out the barn, we are not doing HSM security on roaming passkeys, we are just pretending to. HSM gets brought up as this important feature but passkeys are already ignoring it. So let us export the key...
I wish I had more upvotes to offer this reply. I want to see more of this sort of comment happening here, rather than the simple hostility and disregard that is common. Not because I love or loathe attestation, but because your reply is the kind of conversation that needs to occur.
>I still expect the big wake up call is going to be in a couple years when Steam enables attestation in their Linux product and VAC begins requiring it, but at least the ripples of LXC’s approach are being seen at all.
I have a feeling this is coming down the line too. But I also don't see the coexistence part in any of this. There is no compromise, it's do what we say or else. You can call this coexistence, but Stockholm syndrome is more apt I think.
Web Integrity failed so now they are trying to lock down the internet by refusing authentication to anyone not using "trusted" passkey implementation (eventually the only trusted implementation will be TPM with unmodified Windows/MacOS/Chrome OS/Android/iOS).
20 comments
[ 2.6 ms ] story [ 61.9 ms ] thread> To be very honest here, you risk having KeePassXC blocked by relying parties (similar to #10406).
This cements a lot of criticism I have of Passkeys as a standard. As of now, KeePassXC is the only implementer I'm aware of that makes it easy to export passkeys. There is no standardized import/export mechanism from any other provider and no timeline of when that will happen other than "we're working on it."
I've been told before that Open implementations of Passkey providers would come and we wouldn't have to worry about the spec being largely proprietary, locked-down implementations.
But with an Open implementation that serves the user in allowing them to export and import that data, there's pushback that the implementation shouldn't exist, and suggestion that even an encrypted export should be a "temporary minimum bar". So it does not seem to me that the Open implementations matter.
In particular, the threat of blocking KeePassXC by relying parties should be interpreted as a threat against Open implementations that deviate from the spec (even though I know Tim has good intentions and does not intend it that way).
----
> Passkey provider certification, migration, spec development, etc is part of the FIDO Alliance. Please reach out directly and I we can talk about how to get you engaged in the discussion
We are long past the point where these conversations should be happening completely in the open. The continued lack of portability in the Passkey ecosystem is only made worse by the closed and private nature of the conversation surrounding it. As time continues to tick on and on and more and more articles suggest that users move over to what is, frankly, an incomplete specification with a fatal flaw, it becomes harder and harder to see the continued delay of real universal portability guarantees as a temporary setback.
At the very least, these kinds of conversations should serve as a warning against assuming that Open Source providers of Passkeys are necessarily going to be able to paper over the real flaws in the spec, particularly around data portability, attestation requirements, and hardware requirements. Half-baked promises are a large part of Passkey advocacy. With KeePassXC allowing real export and direct user access to encrypted keys, we get to see the actual industry reaction when an org tries to fulfill those half-baked promises.
To be clear, I do not think that Tim Cappalli is operating in anything other than good faith and that he wants anything other than the best for the product. This is not Tim being evil, but the FIDO spec and approach to standardizing Passkeys is necessarily flawed and results in these kinds of threatening outcomes and requirements on user agents regardless of the intentions of any individual members or advocates. You don't have to think less of Tim Cappalli or think that he's operating in bad faith to understand that this kind of rhetoric is still threatening.
----
Frankly, I'm done with the "wait and see" approach to the FIDO alliances constant foot-dragging on portability and their continuous indication through their actions that they do not see portability as a user requirement.
Timelines, open discussions, open calls for feedback, and open implementations. Talk is so ridiculously cheap.
> You absolutely should be preventing users from being able to copy a private key!
A what now?
There was a public Authenticate Conference session today that talked about the status of the credential migration specification drafts.
I believe it was recorded: https://authenticatecon.com/event/authenticate-virtual-summi...
The lack of real details on this has been infuriating, especially given that Passkey advocates are pushing Passkeys for regular users and enterprise customers right now. Portability should be a blocking feature -- if it had been treated like an essential feature instead of a post-launch nice-to-have, we wouldn't still be waiting for an answer on it a year after people started raising these complaints.
The lack of transparency allowed a lot of advocates to dismiss what were in retrospect extremely valid concerns about how portability was going to be handled. Advocates dismissed those concerns by talking about how the ecosystem was still young, this was all beta, solutions were coming. And then gradually the "beta" talk vanished, but the solutions never came -- it played out exactly as critics predicted.
This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come; it turns a technology that should be a clear and easy security win into an ideological fight about open standards and user control over their accounts and their identities -- none of that fight was necessary. It's wild to me how this kind of stuff has been handled; there is absolutely no excuse at all for these conversations to be happening behind closed doors.
Tech conference talks are nice and I welcome getting any information at all about progress on portability. Genuinely, I am so hungry for even just a crumb of information about portability, I'll be very happy if that talk gets put online. But this is all a far cry from timelines, open discussions, open calls for feedback, or open implementations. Tech talks are not a standardization process.
I mean, heck, step away from portability even. This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard. That is a conversation that should be happening openly and publicly with public input through official forums or issue trackers. That is not a conversation that should be happening just amongst FIDO members, and it's absurd to learn about the existence of that conversation through an unrelated Github issue.
But I'm just shouting into the void, I guess. The Github issue ends with "I will send you a dm/email". So that's another conversation that will be moved behind closed doors. Well, what's another year? We'll all just wait patiently while we're constantly told that we should be using what is today a locked down, proprietary ecosystem that is actively pushing back on Open implementations trying to solve the problems that the FIDO alliance either won't or can't currently address by threatening disqualification from the ecosystem. Of course, Open providers being threatened via attestation was another thing that I was told by advocates not to worry about, but whatever, we'll all just keep trusting people.
Passkeys aren't a standard or protocol. A passkey is the name of a type of credential that can be used via the WebAuthn API, an open industry standard for phishing-resistant authentication on the web platform.
>> "This and the attestation talk that I've seen around providers risks damaging Passkey adoption for years to come"
Passkey adoption is currently growing exponentially. Faster than we could have ever imagined when we started this work 3 years ago. New ideas will help adoption with organizations that have certain regulatory requirements for strong authentication (e.g. banks and lenders).
>> "This Github issue drops the nugget that enterprise members of FIDO are now pushing for provider attestation, which would have massive implications for Passkey as an Open standard"
Many of the highly regulated relying parties that need attestation aren't even members of the FIDO Alliance. Attestation is already supported (and has been since day 1) for any WebAuthn credential and is widely deployed by many authenticators. WebAuthn is an open standard. The challenge is that the current attestation model needs some updating to work with synced passkey authenticators. Previous iterations of this technology used credentials which were device-bound (now called device-bound passkeys).
>> "Genuinely, I am so hungry for even just a crumb of information about portability,"
I think you will be very happy with the content of the session from today then.
>> "The Github issue ends with "I will send you a dm/email""
My goal with that is to bring that feedback into the WebAuthn spec work, which happens in public.
This is a silly distinction to make. Passkeys are the standard word that most ordinary people use when talking about this specification. And this changes nothing about the fact that the conversations about portability have not been happening in the open.
If WebAuthn is an open industry standard, why am I getting news about the conversations about standardization from a tech talk? Where are the meeting notes? What's the mailing list I can join?
This is part of what's frustrating about these conversations. It feels like the words are constantly changing depending on what advocates need to say. The linked issue is not shy about talking about export as a standard. This is not something that we need to debate, everyone reading these conversations knows what is meant when we are talking about a passkey standard.
And even if you for some reason don't want to use that word -- again, this changes nothing about the nature of the conversations that have happened around portability.
----
> Passkey adoption is currently growing exponentially. Faster than we could have ever imagined when we started this work 3 years ago.
This is exactly what early critics were worried about and warned about. There is a hecking reason we all pushed for portability to be built into the webauthn spec from day 1. Because we knew that this would happen, and everyone said, "no, it won't it's just early days, we're working on it." Well...
So now people are deploying this to production. It is not early days anymore, and portability still shows no sign of shipping. Talk is cheap, and we were all promised that the lack of portability was just because the spec was too new. And we're still waiting.
> New ideas will help adoption with organizations that have certain regulatory requirements for strong authentication (e.g. banks and lenders).
Sure, this is exactly what I have been told over and over again by advocates. Nobody is going to do attestation other than banks and governments.
Now, put aside the fact that a consumer bank or lender having the ability to require a proprietary passkey provider is itself a dubious concept for user freedom. Put aside the fact that we are discussing a standard that could potentially have the consequence of making it impossible for me to sign into my bank using only FOSS software. Put aside that most banks I've interacted with don't follow these kinds of standards anyway (when was the last time you saw a bank with actual compliant 2FA support?) Put aside that it's not completely clear which regulations would block banks from using a standard without attestation (they use passwords today). Put all that aside, and it turns out that attestation also goes beyond regulatory requirements for niche orgs.
In this very issue you raise the possibility of providers being blocked for spec deviations. That is a step beyond banks and lenders wanting specific apps, and it's exactly what advocates told me wasn't going to happen. And normally I'd try to be more diplomatic about this, but I have been having this gosh-darned conversation for years and at some point you have to call a spade a hecking spade.
If providers are being threatened (and I know you didn't mean it as a threat, but it is still a threat) for spec deviations, then attestation is a heck of a lot bigger than regulatory requirements for banks. And that is a conversation that needs input from ordinary everyday users, not just from tech companies.
> Attestation is already supported (and has been since day 1) for any WebAuthn credential and is widely deployed by many authenticators.
And has been critiqued since day 1 over the exact fears that are raised in this issue. And genuinely, I think the tone of the conversation on this Github issue justifies all of those fears. But also, expansion of that system is just as consequential, and I do sort of want to call out that I think you shou...
I lead our work on passkey portability, which I work on daily.
Give me and my colleagues a couple more weeks to get the code up and running (standard/cross-industry collaboration takes calendar time).
I’m sorry that our initial work is not happening fully in the open *yet*, but we’re all pushing for it and it will be, hopefully sooner than later.
The best place to argue this “in the open” is by raising issues in the w3c/webauthn repo, or meetings, which is open.
It's not just that export wasn't supported, it's that this giant limitation that was in many ways the reason why people were so excited about Open implementations in the first place was quietly left unsaid.
I really genuinely do appreciate the work everyone is doing. But at no point when Bitwarden was writing posts and releases about passkey support did anyone writing that stuff think, "people will think this means export is supported, we should clarify that."?
It's so hard not to look at this communication and not feel that these kinds of details were deliberately omitted. I'm sure they weren't! I know that my emotions are incorrect and that everyone involved means the best. But crud, that is how it feels.
How many people who got excited about Bitwarden's implementation even know that they still can't export and import their passkeys? Maybe that'll be a fun surprise for them next time they try to do an import into a new account. Bitwarden's announcements didn't mention this limitation, and as a result no press coverage of Bitwarden mentioned this, and any casual observer who didn't know to go read the documentation and deliberately ask about it would come away from this coverage thinking that export was supported -- and in fact I would argue people did. People think the portability problem is solved because Bitwarden and 1Password exist.
Needing to double-check this kind of stuff, not having transparency or open conversations about any of it is part of the regular frustration of trying to learn about the passkey ecosystem. Very often when I talk to people in industry about passkeys, I will get answers that really sound like they are addressing people's concerns. And then you dig into them, and... they don't. But that's never communicated unless you do the research. So much of the advocacy is saying stuff that is technically true, but has huge unmentioned caveats or that doesn't actually when you dig into it address the concerns that people have or is using some weird definition that isn't what most people would use.
"Passkeys are portable now!"
"So I can export them?"
"Well, that depends on what your definition of portable is."
Bitwarden never technically said that it supported export, but I'm going to go out on a limb and say that a lot of casual observers reading about portability and sync and OS-independence think that Bitwarden does support export, and Bitwarden really isn't going out of its way to avoid that impression. I mean, props for having it in the user docs, that is better than 1Password. +1 for Open Source being more transparent than proprietary software, genuinely I appreciate it. But the only reason I know that Bitwarden doesn't currently support export... is because I knew that I couldn't assume it and I knew that I needed to check the docs. It's not something that's communicated in the announcement, it's not something that's communicated in the FAQ, it's not something that's communicated in any press coverage, it's not something that's communicated unless you know what to Google search.
I'm excited and eager for more of the actual work to be public and open, but I also kind of have to frank about how low the bar is right now. Nothing is communicat...
I found that conversation to be straight up chilling.
> because in its current state I can't recommend anyone that I know -- at all -- use passkeys.
In the end, personally, it's about whether or not I am willing to use passkeys. If I am not willing to use them, I certainly am not willing to recommend that others do so.
To use passkeys already means giving up quite a lot. That's not necessarily a showstopper, if the benefits outweigh the drawbacks. Personally, right now, it's not an easy call at all.
The attestation issue, as well as the sentiments expressed in the github thread, don't exactly help.
What a nice guy… Basically saying do what we say or we will make the treacherous part of your device do it against your will.
This is a spec issue. There are (as far as I can tell) no penalties or mechanisms to guard against businesses using attestation punitively to punish actors that deviate from the spec even when that deviation is in the interest of users. We are relying on corporate good will, and corporate good will is not something that ought to be relied on. Now, what that comment reveals is that there are multiple actors pushing to extend attestation to roaming keys and to have even fewer safeguards against excluding clients from the ecosystem.
That's scary, and that's a much bigger problem than one person.
When Apple zeroed out attestation requests for its roaming keys, I was told by multiple advocates that this meant that attestation would not be coming for roaming keys, and that attestation would never be used this way. After all, attestation was primarily intended (they told me) for regulatory compliance in industries that were primarily worried about device-bound keys. "What is Apple changes its mind" was dismissed as fearmongering.
But here we see the danger of setting expectations about an ecosystem based on Apple deciding randomly not to do something. There was no public commitment from FIDO not to pursue additional attestation for roaming keys, and behind the scenes it looks like players calling for that attestation have more sway than advocates let on.
So we end up with essentially a threat against implementations that deviate from the standard even when they are deviating in the clear interest of users. I don't think Tim meant it as a threat, if anything he was probably trying to be helpful. But it is still a threat regardless of the intention. And it's a threat because the ecosystem explicitly exposes tools to enable this kind of behavior. It's not a threat because of Tim, it's a threat because it's plausible. And it shouldn't be plausible.
This is why attestation is dangerous without safeguards; and the FIDO alliance has completely ignored the need for safeguards. Maybe there are conversations that I'm not privy to -- there probably are. But from the outside, it looks like a lot of people hoping that Google and Apple and Netflix and your bank will all magically care about not locking users to hardware and will completely voluntarily choose not abuse attestation. And I'm sorry, that's just not in their nature to do. If the spec directly gives these companies tools to be abusive, then they're going to be abusive.
Exactly. And these safeguards would need be legal. Seeing that the EU can't even force Apple to let me install a .ipa file on iOS without jailbreaking, I think it's safe to say we are fucked.
I’ve already posted at length on HN about the risks of treating attestation as evil and refusing to discuss its benefits at all, and how that manner of engagement will lead to it being widely adopted over the objections of an uncoordinated minority. The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
I still expect the big wake up call is going to be in a couple years when Steam enables attestation in their Linux product and VAC begins requiring it, but at least the ripples of LXC’s approach are being seen at all.
I've seen lots of discussion about the benefits on HN.
But attestation really is fundamentally opposed to freedom. It allows someone else to dictate how you use your own machines. So, the debate necessarily revolves around whether or not it's worth it to give some freedom up for this.
Some people will say it is, others will say it's not.
> yet no one discusses how freedom and attestation might coexist
How could they coexist? I honestly don't see it, but that's likely a result of my own lack of imagination.
> Being able to zero-effort cleartext a passkey strips it of the HSM-lite properties that make it safer than passwords.
You might have an argument if we were talking about device-bound keys. But the second we start talking about roaming keys, this just becomes a bad excuse. iCloud accounts can be phished, Google accounts can be phished. Roaming keys are vulnerable to phishing. The ability to export a key (encrypted or not) does not change that.
Device-level attestation and platform control over keys is out-of-scope and inappropriate for a credential that is fundamentally designed to live on multiple devices. We aren't talking about Yubikeys or device-bound keys, we're talking about roaming keys that are designed to get synchronized to the cloud and moved between devices at the direction of the user. Necessarily, there is going to be some level of phishing risk. We've accepted that because device-bound keys are unacceptable for most average users even if they're more secure.
Notably, this does not mean that passkeys are useless or that they are not phishing resistant. There are a large number of security benefits from passkeys even though they are not completely phishing proof. Those benefits do not go away if attestation is not supported for roaming keys, nor do they go away if users are able to decrypt their own keys. And given that companies like Apple led on zeroing out attestation requests for roaming keys, there clearly is not consensus in the FIDO Alliance about whether attestation is desirable or necessary for roaming keys.
Passkeys in a world where users can inspect and access their own keys are still a meaningful security improvement over passwords. And importantly, the lack of attestation makes it more feasible that they will actually be used. The goal is not to make something perfectly secure, the goal is to replace passwords with something better. I am continually surprised to see how little people understand about the myriads of use-cases that passkeys will need to support if they are going to actually replace passwords, and how little they seem to care about the ability of an attestation-encumbered system to handle those niche cases.
I've been in this space for a while. First, advocates told me that roaming keys were never going to happen because the whole point was for keys to be device-bound. Then it turned out, well, that's a dealbreaker, so we can compromise on that. Then I was told that sharing passkeys was never going to happen because it would destroy the security benefits. Well... okay, now we support sharing. Then I was told that migration was out-of-scope and the FIDO Alliance was not going to get involved. Now the FIDO Alliance is involved. Then I was told that export was fundamentally insecure, and any migration between providers would need to happen via a secure channel online or without ever putting the passkey on disk. And now I'm told that, okay, we can put the passkey on disk, but the problem is that it's zero-effort to get a cleartext. And at every step of that process, I'm told that these are non-negotiable security properties of WebAuthn.
Well, after a while these all start to feel less like security principles and more like excuses for why export isn't happening. It's weird how these security principles only get brought up in regards to user freedom, and not in regards to Apple supporting passkey sharing over Airdrop. I'm sorry, that doesn't open up phishing risks?
Tim suggests in this issue encrypting the passkey with some kind of additional key on export. How does that mean that HSM properties are preserved? The horse is out the barn, we are not doing HSM security on roaming passkeys, we are just pretending to. HSM gets brought up as this important feature but passkeys are already ignoring it. So let us export the key...
I have a feeling this is coming down the line too. But I also don't see the coexistence part in any of this. There is no compromise, it's do what we say or else. You can call this coexistence, but Stockholm syndrome is more apt I think.