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.