This feels overly cynical to me. The article is a bit rambly so let me try to distill the problems:
1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.
2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.
3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.
Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:
1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.
2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.
3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be that confused when their unsupported key doesn't work.
I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?
If the underlying technology is poorly specified and confusing enough that it doesn’t get implemented well in 95% of cases, then yes, that does indict the technology. See also: PGP and email encryption in general.
But even if on balance the tech is worth implementing, it’s clearly not easy and your suggestions to “just” do several things that aren’t happening ring a little hollow.
I only used "just" twice, and they were both justified. Having people remember their email addresses, and explaining something in a couple of sentences, are both pretty easy.
Points #1 and #2 are not entirely trivial, but they're not much more complicated than the alternatives. A relying party has to store the public key counterpart to a user's private passkey no matter what. Is it really that much harder to associate that public key with their user ID? Point #2 is probably the hardest to overcome if you already baked in the assumption of 1 key per user. That's concerning. But that problem can also be mitigated by the authenticator, by supporting export.
I'm not saying the article fails to identify real issues. I'm saying it fails to identify insurmountable issues. The nice thing about software is that a good canonical implementation can be used by everybody for free.
1. Most relying parties support resident keys only. This makes a bad user experience because users are surprised when they run out of space, and may have to wipe their device to get more.
2. Most authenticators do not allow you to export your keys. If a relying party only allows a single credential per account, this creates authenticator lock-in, which is a bad user experience.
3. Chrome is uncooperative about the Authenticator Selection Extension, and that can make a bad user experience if the relying party rejects the device attestation after enrollment.
Yes, these are all bad user experiences, but they don't indict the technology. It sounds to me like the relying party can mitigate all of these issues:
1. Support non-resident keys. Seems like it really doesn't have to be a bad user experience. Usernames are easy to remember. Just use their email address.
2. Support multiple keys per account. Most users will have multiple authenticators. Let them enroll several and they're not locked into any one in particular. Most users won't care about this, but for important services it's an option.
3. As a relying party with strict authenticator requirements, just explain those requirements on the passkey registration page. People can read. They don't have to be that confused when their unsupported key doesn't work.
I get that there's nothing users can do when the relying party creates a bad experience, but if a relying party has all the power to create a good experience, is it really worth being this gloomy about the technology?