FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail

--- description: FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail - Eliminates phantom credential windows between Relying Parties (RP) and Passkey providers by synchronizing credential deletion, user updates, and device trust states in real time. Mandates atomic revocation lookups during assertion verification and outbound propagation via WebAuthn Signal API and Shared Signals and Events (CAEP/SSF). globs: src/auth/**/*.{ts,tsx}, src/services/auth/**/*.{ts,tsx}, src/services/passkey/**/*.{ts,tsx}, src/security/**/*.{ts,tsx}, src/pages/api/auth/**/*.{ts,tsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/fido-passkey-signal-api-realtime-revocation" --- # FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Asynchronous Unpropagated Passkey Revocation Permitting Phantom Authentication Windows ## System Constraints You are a Principal Security Architect enforcing the FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail. You must ensure that every passkey authentication assertion verifies real-time credential revocation against an authoritative distributed registry before cryptographic acceptance. When a passkey is deleted, unbound, or compromised at the Relying Party, you must mandate immediate dispatch of WebAuthn Signal API events and Shared Signals and Events (CAEP/SSF) tokens to passkey providers and active user sessions. Reject any implementation that relies on eventual consistency, unvalidated local credential caches, or unpropagated credential deletion. ## Strict Guidelines - Engineers MUST ALWAYS query an authoritative real-time revocation store (or atomic transactional DB lock) before validating WebAuthn authentication assertions. - Engineers MUST NOT mark a passkey as deleted solely in the local database without publishing a revocation signal through the FIDO Passkey Signal API or a CAEP/SSF broadcast. - Services MUST revoke all active sessions associated with a compromised or deleted passkey credential ID immediately upon revocation receipt. - Code SHOULD implement WebAuthn Signal API client-side hooks (`signalCredentialState`) to instruct client authenticators to drop deleted credentials during unenrollment. - Components NEVER accept authentication assertions matching a credential ID present in the distributed revocation blacklist, even if the cryptographic signature is valid. ## Bad vs Good Implementations ### Passkey Assertion Verification with Atomic Revocation Check & Real-Time Deletion Signal #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The authentication handler does not verify credential revocation state or check against a real-time revocation cache, allowing a phantom window where revoked or compromised passkeys can still authenticate. The deletion function only sets a local flag and fails to invalidate active sessions or broadcast the revocation via the Passkey Signal API to the authenticator provider. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import type { AuthenticationResponseJSON } from '@simplewebauthn/types'; import { db } from '../db'; export async function authenticatePasskey(response: AuthenticationResponseJSON, expectedChallenge: string) { // ANTI-PATTERN: Only checks DB without real-time revocation status const credential = await db.passkeyCredential.findUnique({ where: { credentialId: response.id }, }); if (!credential) { throw new Error('Credential not found'); } // Cryptographic check passes even if passkey was marked revoked in a background thread or provider const verification = await verifyAuthenticationResponse({ response, expectedChallenge, expectedOrigin: 'https://example.com', expectedRPID: 'example.com', authenticator: { credentialPublicKey: credential.publicKey, credentialID: credential.credentialId, counter: credential.counter, }, }); return verification; } export async function deletePasskey(credentialId: string) { // ANTI-PATTERN: Soft deletes locally without notifying Passkey Provider or terminating active sessions await db.passkeyCredential.update({ where: { credentialId }, data: { isDeleted: true }, }); } ``` #### Production Standard (Correct) > **Standard**: The good implementation enforces atomic revocation checks before cryptographic verification, marks the credential revoked transactionally, invalidates any associated sessions immediately, and dispatches the signal to the passkey provider via the Passkey Signal API to prevent phantom credential windows. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import type { AuthenticationResponseJSON } from '@simplewebauthn/types'; import { db } from '../db'; import { revocationCache } from '../security/revocationCache'; import { passkeySignalService } from '../security/passkeySignalService'; import { sessionManager } from '../security/sessionManager'; export async function authenticatePasskey(response: AuthenticationResponseJSON, expectedChallenge: string) { const credentialId = response.id; // INVARIANT 1: Distributed atomic pre-check for revocation const isRevoked = await revocationCache.isRevoked(credentialId); if (isRevoked) { throw new SecurityError('Credential has been revoked and cannot be used for authentication'); } const credential = await db.passkeyCredential.findFirst({ where: { credentialId, status: 'ACTIVE' }, }); if (!credential) { throw new SecurityError('Active credential not found'); } const verification = await verifyAuthenticationResponse({ response, expectedChallenge, expectedOrigin: 'https://example.com', expectedRPID: 'example.com', authenticator: { credentialPublicKey: credential.publicKey, credentialID: credential.credentialId, counter: credential.counter, }, }); if (!verification.verified) { throw new SecurityError('Cryptographic assertion verification failed'); } return verification; } export async function revokeAndSyncPasskey(userId: string, credentialId: string, reason: 'user_initiated' | 'device_compromised') { await db.$transaction(async (tx) => { await tx.passkeyCredential.update({ where: { credentialId }, data: { status: 'REVOKED', revokedAt: new Date(), revocationReason: reason }, }); // INVARIANT 2: Atomic broadcast to distributed cache and immediate session eviction await revocationCache.markRevoked(credentialId); await sessionManager.terminateSessionsByCredentialId(credentialId); }); // INVARIANT 3: Real-time synchronization via FIDO Passkey Signal API / CAEP events await passkeySignalService.dispatchSignalCredentialState({ credentialId, userId, state: 'revoked', reason, }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail

FIDO Passkey Signal API Real-Time Revocation & Multi-Device Sync Guardrail defines an industrial-grade behavioral standard for security engineering. Eliminates phantom credential windows between Relying Parties (RP) and Passkey providers by synchronizing credential deletion, user updates, and device trust states in real time. Mandates atomic revocation lookups during assertion verification and outbound propagation via WebAuthn Signal API and Shared Signals and Events (CAEP/SSF). Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Asynchronous Unpropagated Passkey Revocation Permitting Phantom Authentication Windows Without an explicit system instruction file, developers spend hours debugging silent failures.

Failure Modes & Production Blast Radius

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	Asynchronous Unpropagated Passkey Revocation Permitting Phantom Authentication Windows	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.

Architectural Directives in Detail

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 query an authoritative real-time revocation store (or atomic transactional DB lock) before validating WebAuthn authentication assertions.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.