> 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.