so, in a discussion elsewhere, it came up that everyone talks about "passkeys" as if they're highly secure and impossible to copy. unfortunately, this is true in some cases (hardware tokens...) and not at all true in others. so, why has it been such a popular claim?
well, partially, we think, ... marketers can get away with saying it. nobody has been calling them on it, in part because people who understand the situation still largely do want to see some of these technologies adopted and are hesitant to criticize "passkeys" as a whole
personally there are some things we want adopted, and some we don't, but it's hard to talk about that because the term "passkey" conflates them as if they're the same thing
so we propose to break down the word "passkey", to strike it repeatedly with a metaphorical pickaxe in order to separate it into its component parts in order to work towards a situation where we and you can talk about the parts individually, and be understood.
you can think of this blog post as kind-of a first blow in that effort; we're not technical writers, so providing a well-organized conceptual overview of a large topic like this is hard for us, and we may not be the best people to do it. our goal right now is just to get these thoughts out in a durable form, showing where the important dividing lines between the pieces are in the hope others can take it further.
for example, there was a neat post last year which talked about how resident credentials risk overwhelming the storage capacity of hardware tokens (unfortunately, we've been unable to find it again; web search only turns up marketing documents...)
we felt like it didn't get the traction it should have, and although we have no way to quantify public sentiment, subjectively in discussions on social media we felt like that was because the public heard it saying "passkeys are bad! don't use them" and then when later commentary fact-checked that, it turns out, guess what, passkeys are not synonymous with resident credentials (or with any specific technology), so the takeaway was that the critique wasn't true
except the critique was true, but the marketing terminology we've all been convinced to use for simplicity's sake, "passkey", only makes it easy to express vacuous things. ideas with substance become impossible to state.
broadly speaking we would say that this is an intentional attribute of most marketing terms for complex technologies, it is reflective of marketers being good at their jobs.
it's not necessarily that anyone specifically wanted to make it hard to communicate this kind of thing, it's that they were following generally-accepted principles in their field which were refined over many years towards that end, because for business purposes it's not actually a good thing if the public understands what companies are selling, it's better for profit if the only thing we know about products is that we need them. otherwise we might go point out dangerous flaws, realizing we'd be better off with competitors, building our own free alternatives from scratch, all that bad stuff.
anyway, we describe all this not to complain but because it's important to understand the structure of oppression if we wish to fight effectively
for the record: we personally want to see hardware tokens become more widely used, and we think webauthn is a solid vehicle towards that end.
we are against discoverable credentials because (though we realize there are counter-arguments on this point, and more could be written) we don't consider them an acceptable privacy tradeoff and we don't see browsers implementing adequate transparency features.
we are also against the stronger forms of manufacturer attestation, although we like the ability to require specific **features**, such as a hardware-backed PIN check or a mandatory touch, as long as it's enforced voluntarily on the browser side, rather than by certificates rooted in the hierarchical authority of a device manufacturer or OS vendor. similar to how Linux implements cpuid but also provides a way to spoof it, we shouldn't adopt tools of oppression just because we like some ways they're used, we should be skeptical of techniques which seek to secure things against ourselves.
military organizations, and megacorps which like to pretend they're military organizations, may want to secure things against their workers, and we do support the principle of minimum necessary privilege, but mechanisms for limiting technology choice don't benefit any actual people, not even the ones nominally in charge. it's for the anthill's sake, not for the ants.
we are very strongly against OS-provided credential stores because the ecosystem lock-in effects are counter to public welfare.
we don't have a strong opinion on resident credentials as such; we note that their core use-case is precisely to give OS vendors an advantage over hardware token manufacturers in popularizing their closed ecosystems, and we're against that outcome but we think it's important not to oversimplify everything down to just "good" or "bad".
we've become convinced that it's necessary to use these individual terms for the pieces, and do public education about them, like everyone did back in the old days when there was reason for people to get excited about new technologies. unfortunately, even though we sympathize with the lack of excitement these days, this particular cluster of technologies are dangerous when misapplied, so we can't just treat them as a lump.
okay! hope that helps! if you read this, drop us a line and let us know :) it does not help us materially in any way, we aren't a youtuber who does this for profit, it just gives us a warm feeling deep inside that somebody connected with our work. we're looking forward to hearing from you!
[this post originated on fedi in someone else's replies, at https://adhd.irenes.space/@ireneista/statuses/01JTY0H2QGW1XV8YVYPC7KW628; if you go there from here, please respond only to us and not to the other participants]