6 ms·

>> "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

>> "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. I believe it was recorded: https://authenticatecon.com/event/authenticate-virtual-summit-demystifying-passkey-implementations/ https://authenticatecon.com/event/authenticate-virtual-summi...

danShumway 3y ago
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.
- timmyc123 3y ago
  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 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.
  - danShumway 3y ago
    > 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.

danShumway 3y ago

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.

timmyc123 3y ago
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 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.
- danShumway 3y ago
  > 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.