> Passkeys aren't a standard or protocol
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.