WebAuthn & Passkey Debugger
Interactive client-side diagnostics to test browser secure enclave readiness, platform authenticator status, and FIDO2 credentials.
Diagnostic Control
This tool queries local browser APIs to inspect biometric enclaves. No data is sent to any server.
System Specifications
- API: WebAuthn (L2/L3)
- Encapsulation: Client-Side JS
- Platform: Browser Sandbox
How WebAuthn Platform Authenticators & Secure Enclaves Work
Modern WebAuthn (FIDO2) passkeys provide phishing-resistant public-key authentication by decoupling cryptographic key generation from browser software storage. When a decentralized application or Web3 smart wallet requests passkey registration, the browser delegates credential synthesis to the host operating system's platform authenticator:
- Windows Hello (TPM 2.0): The Windows Cryptographic Next Generation (CNG) layer commands the discrete or firmware TPM to generate an isolated NIST P-256 (secp256r1) keypair. Private keys are mathematically locked inside TPM hardware registers and will never be exposed in RAM or kernel memory space.
- Apple Secure Enclave (Touch ID / Face ID): iOS and macOS route passkey operations through a dedicated hardware coprocessor running its own isolated microkernel (L4-family OS). Cryptographic signing requires biometric match confirmation before authorizing ECDSA signatures.
- Android Keystore & Titan M2: Android leverages StrongBox Keymaster backed by dedicated hardware security modules to safeguard user credentials against physical side-channel extraction.
Because these hardware enclaves operate with zero-knowledge constraints, the web application only ever receives the public key, the Relying Party identifier (rp.id), a unique credential ID, and client-signed assertion payloads verified against a server challenge nonce.
In account abstraction architectures (ERC-4337 and native smart contract wallets), these P-256 assertions are evaluated on-chain using RIP-7212 precompiles or modular verifier contracts (such as Biconomy, ZeroDev, or Circle Modular Wallets).
Decoding Common WebAuthn Exceptions & Enclave Reverts
NotAllowedError: Request Cancelled or Timed Out
Thrown when the operating system user cancels the biometric prompt, cancels the Windows Hello PIN dialog, or leaves the prompt open until the browser's timeout deadline (typically 60 seconds) expires. In dual-transport hybrid workflows, this exception fires if Bluetooth handshakes fail between desktop and mobile devices.
InvalidStateError: Credential Already Exists or Excluded
Occurs during passkey creation when the relying party passes an excludeCredentials array containing a credential ID already registered on the active authenticator. This defensive check prevents duplicate key generation for the same user account.
SecurityError: Relying Party (rp.id) Domain Mismatch
The W3C WebAuthn specification strictly prohibits an application hosted on app.example.com from generating credentials for an unrelated domain like auth.other.com. The rp.id must either equal the active origin hostname or be an allowable top-level domain suffix. Embedded iframes without allow="publickey-credentials-get" will automatically trigger this security block.
Hardware Isolation: Device-Bound vs Synced Credentials
Device-bound credentials generated inside discrete TPMs cannot sync to cloud password managers. If a user relies on a desktop Windows Hello authenticator without registering a secondary companion passkey, reformatting Windows destroys the private key, permanently locking access to accounts that lack multi-owner recovery contracts.
Diagnostic Guides for Passkey & Enclave Failures
Encountering enclave locks or transport failures? Review our step-by-step technical guides:
Frequently Asked Passkey Debugging Questions
What causes a WebAuthn NotAllowedError during passkey authentication?
A NotAllowedError (DOMException code 0) typically indicates that the user cancelled the biometric or PIN prompt, the platform authenticator timed out waiting for input, or the browser session timed out during challenge verification.
Why does passkey registration fail with an rp.id mismatch error?
The WebAuthn specification strictly requires that the Relying Party identifier (rp.id) matches or is a registrable suffix of the current origin domain. If an application serves authentication requests from an unauthorized subdomain, iframe, or unproxied localhost port without proper rp.id configuration, browsers raise a SecurityError to prevent cross-origin impersonation.
How does Windows Hello TPM 2.0 store passkey private keys differently from cloud sync passkeys?
Windows Hello platform authenticators generate non-exportable secp256r1 (P-256) or RSA keypairs bound directly to the hardware Trusted Platform Module (TPM 2.0) chip. Unlike multi-device synchronized passkeys stored in iCloud Keychain or Google Password Manager, hardware-bound TPM credentials cannot leave the host machine, requiring fallback signers or recovery contracts if the Windows installation is reinstalled.
What is the difference between a platform authenticator and a roaming cross-platform authenticator?
A platform authenticator is integrated directly into the operating device (such as Windows Hello TPM, Apple Touch ID/Face ID Secure Enclave, or Android BiometricPrompt). A cross-platform roaming authenticator is an external physical security token (such as a YubiKey) or a mobile phone connected via FIDO Cross-Device Authentication (hybrid QR transport over Bluetooth and WebSockets).