• Core Argument: Passkeys are excellent for phishing-resistant authentication, but using them as the primary key for data encryption (via the PRF extension) creates a "disaster waiting to happen."
• The "Blast Radius" Problem: Overloading a passkey for encryption significantly increases the risk. If a user loses or deletes their passkey, they don't just lose access to an account—they permanently lose the underlying data (photos, documents, crypto wallets, etc.).
• User Misunderstanding: Most users do not realize that deleting a passkey from a manager (like Apple, Google, or Bitwarden) is equivalent to destroying the encryption key for their backed-up data.
• Recovery Failures: In scenarios where a user recovers an account via phone or email, they may successfully log in but will be unable to decrypt their history/backups without the original passkey, leading to irreversible data loss.
• Appropriate Use Cases: The PRF (Pseudo-Random Function) extension is legitimate when used for "durable" purposes, such as unlocking credential managers that have separate robust recovery mechanisms (master passwords, recovery keys).
• Call to Action for Industry:
  • Identity Industry: Stop promoting passkeys as a primary encryption tool for user data.
  • Credential Managers: Implement explicit warnings when a user attempts to delete a passkey that utilizes PRF.
  • Service Providers: If using PRF, provide clear documentation (e.g., via prfUsageDetails endpoints) and warn users during the setup process that the passkey is tied to data access.

[[Alper Cugun p]] on why he does not use passkeys

Good list of issues in this article. This issue of Credential Exchange Protocol / Format is so key to me, and so timely for this article, since the initial 1.0 was done a year ago. AFAIK there aren't implementations yet, Passkeys are locked on a device.