The core issue here is a category error that the industry keeps making: treating authentication credentials and encryption keys as interchangeable. They have fundamentally different lifecycle requirements.

Authentication is recoverable by design - you can always reset, re-verify identity, issue new credentials. Encryption keys are the opposite: lose the key, lose the data. Full stop. No amount of UX polish changes this mathematical reality.

The PRF extension makes this worse because it blurs the line even further. Users interact with passkeys as "login things" - the mental model is authentication. But when PRF derives an encryption key from that same passkey, you've silently upgraded a replaceable credential into an irreplaceable secret. The user's mental model doesn't update.

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.

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.