Comment by lxgr

There are some truths in there (attestation exists, passkeys are complicated), but in general, the article strikes me as bad faith.

Various dimensions (copyable vs non-copyable, transferable vs. non-transferable, hardware bound vs. software only, attestation vs. non-attestation) are presented as if they all exist as distinct specification or implementation properties, yet at least half of these don't, at a first glance.

"User-Present vs Non-User-Present passkeys [...] Both kinds exist.": Nope, all WebAuthN credentials require user presence verification:

> requireUserPresence

> The constant Boolean value true. It is included here as a pseudo-parameter to simplify applying this abstract authenticator model to implementations that may wish to make a test of user presence optional although WebAuthn does not.

"Transferable vs Non-Transferable passkeys [...] Both kinds exist.": There's no such property in WebAuthN or FIDO. Passkey implementations may or may not implement the optional password manager migration flow, but the website has nothing to do with that.

"Hardware-Backed vs Software-Backed passkeys [...] Both kinds exist.": Also no, or rather, this point is redundant with "Attested vs Non-Attested passkeys": A non-attested passkey can tell you what it wants about being hardware backed, so they're effectively the same property. The same applies to "Copyable vs Non-Copyable passkeys [...] Both kinds exist."

So let's unpack this statement:

"This means Twitter (formally X) can say to you, “sorry, we only accept the User-Present User-Verified Non-Copyable Hardware-Backed varieties of passkey here."

User-present: redundant, as all passkeys are.

User-verified: This part is true. Sites can choose to demand this, make it optional, or discourage it. Quite reasonable, given that the optimal value probably depends on whether there's also a password being entered, i.e. whether the passkey is supposed to be a single factor (possession of/access to some device) or two factors (being able to authenticate to that device biometrically or using a knowledge factor, usually).

Non-copyable/hardware-backed: Realistically, a site won't be able to make you use attestation, as that would mean excluding the by far most popular implementations in the wild, i.e. Android and iOS's native solutions. By extension, they can't enforce anything about copyability either (or to be precise, nothing they can't already with user agent sniffing and device fingerprinting).

So what's left? Websites can effectively decide whether to require/use passkeys for two factor or single factor authentication. Doesn't sound as scary to me anymore.

All in all, the article makes a few valid points, but arrives at them via heavy handwaving and a lot of motivated reasoning to back it up. This article could have been 70% shorter and would have probably made a stronger or at least equally strong and more accurate point. Generally, I really do agree that there are many possibilities for user-hostile traps in WebAuthN, but if we want to successfully navigate them, critics need to step up their epistemology. The specs are really byzantine and confusing enough.