Architectural Invariant Design: Enforce WebAuthn Level 3 PRF Extension for Zero-Knowledge E2EE Key Derivation
Enforce WebAuthn Level 3 PRF Extension for Zero-Knowledge E2EE Key Derivation defines an industrial-grade behavioral standard for security engineering. Mandates client-side deterministic cryptographic key derivation via the WebAuthn Level 3 Pseudo-Random Function (PRF) extension for end-to-end encryption. Guarantees that neither raw authenticator PRF outputs nor derived encryption master keys are ever transmitted to Relying Parties (IdPs) or stored in unmanaged persistent client storage. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.
Hazard Analysis: What Breaks Without This Rule
The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:
| Failure Mode | AI Symptom (The Anti-Pattern) | Severity | Production Impact & Remedy |
|---|---|---|---|
| AI Hallucination & Deprecation Drift | Exposing Raw PRF Outputs to Identity Providers or Omitting HKDF Domain Separation | Critical | Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production. Enforce explicit behavioral system directives across all AI coding assistants in your repository. |
| Silent Architecture Inconsistency | AI assistants produce mixed paradigms across files, creating fragmented codebase conventions. | Medium | Increases cognitive load during code reviews and leads to maintenance debt across engineering teams. Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails. |
Step-by-Step Production Directives
Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:
Engineers MUST ALWAYS process WebAuthn PRF outputs exclusively within the client-side Web Cryptography API (`crypto.subtle`) and NEVER transmit raw PRF outputs to the server or Relying Party.
Engineers MUST ALWAYS process WebAuthn PRF outputs exclusively within the client-side Web Cryptography API (`crypto.subtle`) and NEVER transmit raw PRF outputs to the server or Relying Party.
Engineers MUST ALWAYS pass raw PRF output (`results.prf.results.first`) into an HKDF (RFC 5869) key derivation step with an explicit application domain separation string (`info`) before generating symmetric cipher keys (e.g., AES-GCM-256).
Engineers MUST ALWAYS pass raw PRF output (`results.prf.results.first`) into an HKDF (RFC 5869) key derivation step with an explicit application domain separation string (`info`) before generating symmetric cipher keys (e.g., AES-GCM-256).
Engineers MUST NOT use the raw PRF evaluation bytes directly as an encryption or authentication key.
Engineers MUST NOT use the raw PRF evaluation bytes directly as an encryption or authentication key.
Engineers MUST NOT serialize derived keys, intermediate PRF outputs, or unencrypted private key material into `localStorage`, `sessionStorage`, or indexed storage without envelope encryption.
Engineers MUST NOT serialize derived keys, intermediate PRF outputs, or unencrypted private key material into `localStorage`, `sessionStorage`, or indexed storage without envelope encryption.
Code MUST verify `clientExtensionResults.prf?.enabled` during registration and verify `clientExtensionResults.prf?.results?.first` existence before attempting key derivation.
Code MUST verify `clientExtensionResults.prf?.enabled` during registration and verify `clientExtensionResults.prf?.results?.first` existence before attempting key derivation.
Services MUST reject authentication payloads that attempt to include PRF execution secrets, raw salt outputs, or derived client keys in the credential transport body.
Services MUST reject authentication payloads that attempt to include PRF execution secrets, raw salt outputs, or derived client keys in the credential transport body.
Components NEVER fall back to weak password-derived keys or insecure pseudo-random generators if the authenticator does not support the PRF extension
Components NEVER fall back to weak password-derived keys or insecure pseudo-random generators if the authenticator does not support the PRF extension; they MUST raise an explicit unsupported hardware error.
Frequently Asked Technical Questions
Common questions developers face when configuring AI coding assistants for this stack:
Q:Why is Enforce WebAuthn Level 3 PRF Extension for Zero-Knowledge E2EE Key Derivation critical for AI coding assistants?
Mandates client-side deterministic cryptographic key derivation via the WebAuthn Level 3 Pseudo-Random Function (PRF) extension for end-to-end encryption. Guarantees that neither raw authenticator PRF outputs nor derived encryption master keys are ever transmitted to Relying Parties (IdPs) or stored in unmanaged persistent client storage. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.
Q:How does adopting this rule prevent AI hallucinations?
This rule explicitly declares what the AI must avoid (Exposing Raw PRF Outputs to Identity Providers or Omitting HKDF Domain Separation) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.
Q:Which AI coding environments are supported?
This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).
Q:Can I combine this rule with other technology stacks?
Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.