> What we actually need is for the WebAuthn spec to include a signal that tells credential managers "this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion. Right now credential managers treat all passkeys identically.

This feels more like CYA/shifting the blame for me. If a service is designed so that I will lose all my data if I lose the passkey, then a "yo, don't lose that passkey, like, ever!" warning is the minimum, but doesn't solve the problem.

I found the initial suggestion "don't ever use passkeys for encryption of persistent data" more reasonable.

(Or what the sibling comment describes: Design the encryption in such a way there is an alternate key that could be used for decrypting)

I think the idea behind PRF was something like "use this as one of several keys", never as "use this the only key". I don't think this was explicitly called out in the specs, though.

> this passkey is load-bearing for encryption, not just auth" so they can surface appropriate warnings before deletion

That sounds like a reasonable idea, but still doesn't help with the case of a completely deleted/destroyed authenticator, e.g. a lost Apple/Google account or Yubikey.

The only viable solution to me for mass adoption is restricting (by recommendation, since there's no way to programmatically enforce it) PRF to scenarios where it's only one out of several ways to get access back. Some password managers do this, e.g. they encrypt their master secret under a PRF-derived key, but this is not the only way/place to get to the master secret, and they also encourage printed key backups etc.