I think the author is taking the argument too far and also not being precise in their language which is the exactly the "passkey hype" they fault Apple and "Fido" for doing. Maybe just cut the exposition out of the article I don't think it helps the argument and makes the author sound angsty rather than contribute to the well thought out considerations towards the end. Point being, I think there's a point but it was hard to get there.
Anyway:
1. Passkeys, to me, are the private key. It doesn't matter whether it's resident or not, or whether it's device bound (non-extractable) or not, whether a "genuine" authenticator made the signature or not, or whether user presence was verified or not. A Passkey is not the authenticator/library as the author claims, and it's not the protocol or some set of protocol features.
2. The world is better off if everyone uses WebAuthN instead of passwords irrespective of how the passkey is stored. Full stop. So let's start there. Additionally, where I diverge from the author, I don't think preserving the sanctity of decade old hardware keys which only conform to older versions of a TPM spec is of paramount concern, either. The author's fixation on that is a little strong, but it's understandable.
3. I don't think you need to discourage resident keys. But I also don't think RPs need to care about whether the key is resident or not. Let the library on the user's browser/device decide how to find the key. An RP wanting to verify user presence is one thing, but saying this key must be stored with the user IMO is a step too far. It's likely that RPs don't even care and are just avoiding wanting to store some extra bytes in their DB. Or their security team overly cares and is making up reasons why the RP needs to require resident keys (IMO bad security take all things considered) but I can see the tin-foil angle).
So I think the simple solution is probably to, for WebAuthN specifically, deprecate the ability for the RP to specify that it needs a resident key. Problem solved.
Oh and while we're at it, forbid hardware attestation. The web doesn't need that. If rk=required and hardware attestation need to exist for tightly controlled enterprise use cases then whatever, but relegate them there preferably in some non-required protocol extension.
I'm not clear on what you mean by this. Do you mean hardware-backed non-extractable resident keys? Or the more simple idea that your WebAuthN agent can store a key?
I don't see a problem with a WebAuthN agent storing a key (ideally locally encrypted at rest with a hardware resident key from a user or device TPM). Having users have a passkey database that they sync across devices is not really a problem as far as I can tell. Do you feel like that's a problem?
It's suboptimal: it basically creates the same situation as password managers where compromising that database is game over. It's a much better situation if instead you enroll multiple different keys. The main issue is if you want to automate this you need a standard way to enroll one device on all sites another device is enrolled in, which AFAIK doesn't exist. (you'd also want to have an automated way to revoke another device in the case that it is compromised).
Having multiple keys enrolled would also allow for better recovery from websites in the case of a suspected compromised device: they can simply disable one key, allowing another key to still log in (and either vouch for or disable the other). You could also have flows where certain actions require multiple keys for authentication.
> it basically creates the same situation as password managers where compromising that database is game over.
So your solution is to split the DB up and store it encrypted, using the same key, on each services servers? I'm dubious that does anything for your case (not to be confused with me agreeing that it's totally okay to have non-resident keys).
You can only compromise the encrypted passkey DB if you compromise the hardware key, or by brute force. If the DB is encrypted at rest using a hardware key, the security model is essentially isomorphic to that of storing encrypted keys on a server. You're just playing with where the key sits at rest. It's still ultimately encrypted by a device's hardware resident key (assuming a sane "soft" WebAuthN implementation by the PW manager).
Unless I misunderstand you, I think you're letting the perfect be the enemy of the good.
EDIT: I think I misunderstood you. It appears you're arguing for resident keys. The person I'm responding to is arguing against resident keys (and I'm asking why they think it's a security mistake) so your response doesn't really make sense.
I understand that technically in a raw security sense it's better for a user to enroll multiple devices with HW resident keys that never leave the authenticator/TPM hardware.
The argument these days is more about what's an acceptable compromise that will get people to actually use Passkeys, because users carrying HW keys around is obviously a failed solution.
Encrypting a soft DB of Passkeys at rest with a user-bound key, and encrypting that user-bound key at rest with a device-bound resident key, and syncing that DB and user-bound key between devices seems like an acceptable compromise that's effectively isomorphic to resident keys everywhere.
No, the alternative being argued for (by OP primarily, but I understand his point) is to only have master keys on devices which can't be moved between them, and enroll seperate devices (and I think this really needs thought from a standardisation point of view). Resident keys are a mistake in that they can be moved between devices. If you allow that then you basically just have a password vault, just maybe with a slightly better lock on it. It's a heck of a lot better than the status quo but it's not the best option.
Anyway:
1. Passkeys, to me, are the private key. It doesn't matter whether it's resident or not, or whether it's device bound (non-extractable) or not, whether a "genuine" authenticator made the signature or not, or whether user presence was verified or not. A Passkey is not the authenticator/library as the author claims, and it's not the protocol or some set of protocol features.
2. The world is better off if everyone uses WebAuthN instead of passwords irrespective of how the passkey is stored. Full stop. So let's start there. Additionally, where I diverge from the author, I don't think preserving the sanctity of decade old hardware keys which only conform to older versions of a TPM spec is of paramount concern, either. The author's fixation on that is a little strong, but it's understandable.
3. I don't think you need to discourage resident keys. But I also don't think RPs need to care about whether the key is resident or not. Let the library on the user's browser/device decide how to find the key. An RP wanting to verify user presence is one thing, but saying this key must be stored with the user IMO is a step too far. It's likely that RPs don't even care and are just avoiding wanting to store some extra bytes in their DB. Or their security team overly cares and is making up reasons why the RP needs to require resident keys (IMO bad security take all things considered) but I can see the tin-foil angle).
So I think the simple solution is probably to, for WebAuthN specifically, deprecate the ability for the RP to specify that it needs a resident key. Problem solved.
Oh and while we're at it, forbid hardware attestation. The web doesn't need that. If rk=required and hardware attestation need to exist for tightly controlled enterprise use cases then whatever, but relegate them there preferably in some non-required protocol extension.