>(…)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.
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.
>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.
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 keys; enough with this bullcrap double-standard about what does and doesn't count as a phishing risk.
----
> The sky is falling, yet no one discusses how freedom and attestation might coexist, and so the majority use case (end users) is winning.
Sure, I'll start the ball on that conversation. There's a straightforward indication now that attestation and certification can be used to punish and block spec deviations (https://github.com/keepassxreboot/keepassxc/issues/10406#iss...). This comment could not possibly be more clear, FIDO Alliance is looking for ways to force providers to implement in specific ways.
And that's interesting because in the past I have been told that interoperability and universal import/export cannot be required by the spec because the FIDO alliance has no way to force providers to interoperate, and because interoperability is out-of-scope. The only thing we can do (I'm told) is hope that companies support export/import out of the goodness of their hearts.
Well, now we know that those arguments are wrong. FIDO members are willing to get involved in discussions about how projects do or don't handle migration so this is very clearly "in-scope", and FIDO members are willing to get forcefully involved, and are actively working on mechanisms to require independent projects that are not members of the FIDO alliance to seek certification. FIDO is going to have a level of control over how providers act.
So if we must have attestation, is anyone involved in the spec process for WebAuthn willing to publicly commit right now that export/import for roaming keys will be a required part of the spec and that failure to implement export/import will result in blocking certification? Why is it that attestation is being used to shut down user agency, but for corporations we have to just trust that they'll do the right thing?
We've apparently got this amazing tool for forcing compliance. That implies to me that user freedom can be part of the spec and those compliance tools can be used to safeguard it. If we're talking about using attestation to enhance user freedom, then using attestation to require universal export/import controls with every single certified provider would be a pretty big selling point for attestation, and would go a long ways towards avoiding the mistakes that were made with 2FA, where many apps straight up never provided a way to export keys. I wouldn't be thrilled with it, attestation would still be dangerous, but at least it could be used to ensure that the ecosystem guarantees user rights as well as restricts them.
But I'm not holding my breath that the FIDO Alliance is going to require that kind of thing.
It is not for lack of conversation that attestation is primarily used today to curb user freedom and agency. It is that the technology is naturally prone to abuse if it isn't coupled with adequate safeguards. Early on during TPP debates, proposals were made for ways to make TPPs that coexisted with user freedoms and enhanced user freedoms. It is not that Linux communities aren't involved, it's that we correctly recognize at this point that practically every single real-world implementation of attestation has been used to shut down user freedom because it is fundamentally prone to abuse. So what safeguards is FIDO going to put in place? How is FIDO going to use attestation this time to actually help user freedom?
Because I can think of ways: mandate interoperability, require implementations to be open and documented, require cross-platform support for most providers, require fall-back methods of authentication for users who do not own hardware that can handle attestation requests, publicly commit to making attestation available to De-Googled phones and to "authorized" 3rd-party ROMs.
While we're at it, require clients to support multiple keys per-domain which by extension would effectively force domains to accept multiple keys. Today, there are domains that only allow registering one passkey, which is wildly irresponsible given that registering multiple keys is the only way right now to simulate portability. If we're going to use attestation to threaten non-compliant implementations, then at the very least we could also use attestation to threaten implementations that deny user freedom and agency.
Will FIDO commit to any of that? Or do I have to simultaneously watch Open Source provider implementations get threatened by attestation while also listening to advocates tell me that there's nothing the FIDO alliance can do to require an Open ecosystem with universal data-portability?
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 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.
>> "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 should have been able to tell what I was referring to:
> The challenge is that the current attestation model needs some updating to work with synced passkey authenticators.
This is a conversation that should be happening out in the open. Is it good for the attestation model to be updated to cover that use-case? Is some degree of friction in front of attestation a positive thing for the ecosystem? Is it good for security-critical applications and industries to use roaming keys instead of device-bound keys in the first place?
And is that conversation happening publicly in a place where regular users can join in, or are we just going to let industry decide the answers? Is the public even aware that there's a conversation about updating and expanding attestation for roaming keys?
I cannot stress how much of a literal betrayal I feel reading about the expansion of that system after passkey advocates repeatedly told me that roaming keys were not going to be subject to attestation.
----
> My goal with that is to bring that feedback into the WebAuthn spec work, which happens in public.
No, it doesn't happen in the public; I'm going to dispute that. If you're wrapping passkeys up into WebAuthn, you can't say that this is public when there are zero open meeting notes or published work or draft specs that I can find online about portability. If they exist somewhere, please, point me to them.
I am so hecking tired of having to do hecking detective work to find out what the direction of passkeys is going to be. I only found this issue because I researched Bitwarden's implementation and found out that they didn't have exporting, and then I searched KeePassXC and found out export wasn't documented and so I didn't know if they supported export/import, and then finally I searched on Github and...
Holy crap, how on earth is this process so dysfunctional? I know that the companies involved in passkey advocacy are capable of putting together Github repos and publishing mailing lists. There is no excuse for this. There is no excuse that the definitive information about 1Password's involvement in portability for months was a single Reddit post. There is no excuse for the fact that I have to dig into Bitwarden's user docs in order to find out that its implementation doesn't support export. "We're working on it" doesn't cut it anymore. There is no excuse for this complete lack of documentation or public involvement or honesty about the very real limitations of these implementations.
----
Look, I don't bear you any ill will about your work with Passkeys, I don't think you're trying to threaten Open providers, I don't think that you don't care about portability.
But the process you are involved in is dysfunctional and is bleeding trust from FOSS advocates and none of this is helping, and it does really feel accurate at this point to say that the FIDO alliance overall does not care about portability. People have been asking about portability since the word "passkey" was first used and the best answer we have ever gotten is "wait." And the FIDO alliance and passkey advocates are now encouraging regular users to use a technology without any portability standards, and are actively pushing back on an attempt to fill in a gap that the FIDO alliance created. If you're willing to ship without a feature, that says something about how much you value that feature. At the very least, its absence is not a blocker.
So all of this is just talk. The actual reality on the ground is that nobody exports passkeys, the entire ecosystem is locked down, and attestation is being used as a threat against a project that deviates from that standard in order to address what is a completely critical need.
When portability eventually does get supported, whenever the heck that happens, I've seen no real guarantee that it'll be a required part of the spec or that proprietary providers for mainstream roaming keys won't be able to just decide not to have an export option. It's pretty hard for me to imagine Google getting threatened with having its provider blocked via attestation because it doesn't support export.
And that's the state of passkeys today.
I don't know if this is over-blunt or mean, but it is is a thing that needs to be said: the FIDO alliance is basically out of good will. At some point, people involved in that process need to have a harsh reality check about how FOSS advocates outside of the project see what is happening, because in its current state I can't recommend anyone that I know -- at all -- use passkeys. They are an almost entirely proprietary ecosystem, currently rife with vendor lock-in, and there is a strong potential for lock-out of individual implementations, and there are no portability guarantees. That is the real state of passkeys today. Maybe they'll be different in the future, but we're not in the future. And I desperately need people involved in the spec to actually understand that and to understand why it's a problem, and to understand why it's a problem why there is still no official timeline or documentation about how portability is going to work.
And if you actually understand that, you should understand why "we're gonna put a tech talk online" is -- yeah, welcome, I do want the information -- but it's also on some level just kind of rubbing salt in the wound.
> My goal with that is to bring that feedback into the WebAuthn spec work
We are at the point where this is not sufficient. I don't want to hear about the feedback after it happens, I don't want to hear that the feedback is reflected in the final spec or some bullcrap. The feedback should be public. The feedback should happen in public.
The companies involved in FIDO all know how to operate a mailing list. It is wild that conversations on portability are happening behind closed doors while general observers are being told just told "trust us, we all want portability" -- and when we complain the response to that criticism is to say, "trust us, it'll be public eventually."
I desperately need you to understand why that is not a sufficient response.
> 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.
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 communicated. It is work even just to find out what is and isn't supported right now. Would you argue that Bitwarden's current FAQ on passkeys (https://bitwarden.com/resources/passkeys-faq/) communicates the difference between in-ecosystem sync and cross-ecosystem sync clearly enough that an ordinary user would understand the difference?
----
> The best place to argue this “in the open” is by raising issues in the w3c/webauthn repo, or meetings, which is open.
What am I missing here? I apologize if there's some thread that I just haven't been able to find, but... if this is an open process, where is the conversation happening? I don't want to be a jerk about this; should I be showing up at w3c meetings and complaining about other meetings that aren't happening there? That doesn't seem helpful to anyone, I don't see how that would be productive. But if this is genuinely happening as part of the w3c/webauthn space, then where in that space are the conversations about portability and export? What issues should I be following?
Is the problem that nobody has raised an issue in that space? Because that's a very weird thing if true; I've been told for nearly a year that work is ongoing on migration/export. In all that time, none of that conversation ended up on the webauthn repo, the ostensibly official place for the spec to be discussed?
This just feels like a dismissal; if the webauthn repository is where these conversation should be happening, then why aren't they happening there? This isn't Bitwarden's fault, I'm speaking broadly to anyone involved in this process -- this is a multi-company process that has been happening for months and months and months and I would love to know where those industry-spanning conversations actually exist, so that I can stay up to date on what's going on without needing to search for crumbs of developer updates on Reddit, Mastodon, and Twitter.
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).
> 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.
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.