[bensyverson]

I think the distinction is that a passkey is meant to be used for authentication (logging in), and is usually not the only way you can authenticate. If you delete your password, passkey, or 2FA method, you can still go through a "forgot password" flow.

Encryption is different. If you encrypt data with a generated password and then delete it, you're toast, and passkeys are no different. I think the author is arguing that users may not even realize that the passkey itself is needed to decrypt, possibly because they're so associated with login.

[dansjots]

for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.

[johncolanduoni]

Most of these systems already do this, especially since very few applications have a flat encryption key hierarchy regardless of passkeys. The counterpoint would be that not everyone will set up multiple passkeys unless you require it on sign-up, but you're going to have that problem with any other method of storing end-to-end encryption keys. Might as well piggy-back on the password manager's replication methods.

[halapro]

You're just saying that the user needs to be aware that you cannot forget or delete a password, which applies just the same way to passkeys.

Passkeys are effectively just long passwords you cannot see. The mechanism is just gravy.

[Borealid]

I think there is a difference.

Sites usually have the user SEND their password to the site to authenticate. There is no need for sites to be written that way, but that is how they are written.

Passkeys cannot, by design, be sent to the site. Instead they use a challenge-response protocol.