Atomic Distributed Revocation and Invalidation Sync for WebAuthn Conditional Mediation

--- description: Atomic Distributed Revocation and Invalidation Sync for WebAuthn Conditional Mediation - Enforces atomic distributed revocation and epoch validation across synchronized cloud passkeys to prevent stale client authenticator states from completing WebAuthn conditional mediation (autofill). Eliminates authorization bypasses where locally cached passkeys generate valid cryptographically signed assertions against recently revoked or deregistered server credentials. globs: src/auth/**/*.{ts,tsx}, src/server/auth/**/*.ts, src/client/hooks/**/usePasskey*.ts, src/pages/api/auth/**/*.ts alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/webauthn-conditional-mediation-invalidation-sync" --- # Atomic Distributed Revocation and Invalidation Sync for WebAuthn Conditional Mediation > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Trusting In-Flight Conditional Assertions Without Atomic Credential Tombstoning and Epoch Validation ## System Constraints You are a Principal Security Architect enforcing zero-trust invariants on WebAuthn and FIDO2 passkey lifecycles. Synced passkeys (iCloud Keychain, Google Password Manager) retain cryptographic material across client instances even after server-side credential revocation. You MUST enforce atomic revocation checks, client AbortController teardown for conditional mediation, challenge-to-credential binding, and instant invalidation propagation across distributed stores. ## Strict Guidelines - Engineers MUST ALWAYS verify credential validity against an authoritative, non-stale database or atomic cache lookup within the assertion verification transaction before accepting any WebAuthn conditional mediation signature. - Engineers MUST NOT rely on client-side state or read-replica eventual consistency to determine if a public key credential ID has been revoked or deregistered. - Services MUST maintain an atomic credential tombstone registry with a monotonic revocation epoch (counter or high-resolution timestamp) per user account to instantly invalidate active conditional mediation challenges. - Client components MUST attach an AbortController to every navigator.credentials.get({ mediation: 'conditional' }) call and immediately abort the listener upon receiving a revocation signal, logout event, or 401/410 authentication response. - Services MUST return an explicit HTTP 410 Gone with an invalid_credential error payload when a revoked credential assertion is submitted, triggering immediate client authenticator cache invalidation where supported (such as PublicKeyCredential.signalUnknownCredential). ## Bad vs Good Implementations ### Server-side WebAuthn assertion verification with atomic distributed tombstone validation #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: The code queries credentials without an atomic lock or tombstone check, ignoring user credential epoch invalidations. If a passkey is revoked on device A, device B using autofill (conditional mediation) can still successfully complete the assertion verification if the server only checks presence in a non-authoritative read. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import type { AuthenticationResponseJSON } from '@simplewebauthn/types'; import { db } from './db'; export async function verifyPasskeyAssertion( response: AuthenticationResponseJSON, expectedChallenge: string, userId: string ) { // Flaw: Reading from stale replica or non-transactional cache without revocation check const credential = await db.credentials.findFirst({ where: { credentialId: response.id } }); if (!credential) { throw new Error('Credential not found'); } // Security Flaw: Does not check if the credential is deleted, revoked, or tombstoned // during an active distributed session or conditional mediation race condition const verification = await verifyAuthenticationResponse({ response, expectedChallenge, expectedOrigin: 'https://example.com', expectedRPID: 'example.com', credential: { id: credential.credentialId, publicKey: credential.publicKey, counter: credential.counter } }); return verification.verified; } ``` #### Production Standard (Correct) > **Standard**: Enforces an atomic tombstone lookup via Redis and a transactional check against the primary database. Validates that the credential is not marked revoked and matches the user's current monotonic authEpoch, completely mitigating stale autofill assertions from synced cloud passkeys. ```typescript import { verifyAuthenticationResponse } from '@simplewebauthn/server'; import type { AuthenticationResponseJSON } from '@simplewebauthn/types'; import { redis } from './redis'; import { prisma } from './db'; export class StaleCredentialRevokedError extends Error { readonly code = 'CREDENTIAL_REVOKED'; constructor(public readonly credentialId: string) { super(`Credential ${credentialId} has been explicitly revoked or tombstoned.`); } } export async function verifyPasskeyAssertion( response: AuthenticationResponseJSON, expectedChallenge: string, userId: string, requestEpoch: number ): Promise<{ verified: boolean; revoked: boolean }> { const credentialId = response.id; // Invariant 1: Atomic check against distributed tombstone registry (Redis Cluster / Primary) const isTombstoned = await redis.sismember(`revoked_credentials:${userId}`, credentialId); if (isTombstoned) { throw new StaleCredentialRevokedError(credentialId); } // Invariant 2: Transactional read against primary DB verifying monotonic epoch const result = await prisma.$transaction(async (tx) => { const user = await tx.user.findUniqueOrThrow({ where: { id: userId }, select: { authEpoch: true } }); if (user.authEpoch > requestEpoch) { throw new StaleCredentialRevokedError(credentialId); } const credential = await tx.passkeyCredential.findFirst({ where: { id: credentialId, userId, revokedAt: null, status: 'ACTIVE' } }); if (!credential) { throw new StaleCredentialRevokedError(credentialId); } const verification = await verifyAuthenticationResponse({ response, expectedChallenge, expectedOrigin: process.env.AUTH_RP_ORIGIN!, expectedRPID: process.env.AUTH_RP_ID!, credential: { id: credential.id, publicKey: credential.publicKey, counter: credential.counter } }); if (verification.verified) { await tx.passkeyCredential.update({ where: { id: credential.id }, data: { counter: verification.authenticationInfo.newCounter, lastUsedAt: new Date() } }); } return verification; }); return { verified: result.verified, revoked: false }; } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: Atomic Distributed Revocation and Invalidation Sync for WebAuthn Conditional Mediation

Atomic Distributed Revocation and Invalidation Sync for WebAuthn Conditional Mediation defines an industrial-grade behavioral standard for security engineering. Enforces atomic distributed revocation and epoch validation across synchronized cloud passkeys to prevent stale client authenticator states from completing WebAuthn conditional mediation (autofill). Eliminates authorization bypasses where locally cached passkeys generate valid cryptographically signed assertions against recently revoked or deregistered server credentials. 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: Trusting In-Flight Conditional Assertions Without Atomic Credential Tombstoning and Epoch Validation 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	Trusting In-Flight Conditional Assertions Without Atomic Credential Tombstoning and Epoch Validation	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 verify credential validity against an authoritative, non-stale database or atomic cache lookup within the assertion verification transaction before accepting any WebAuthn conditional mediation signature.

Engineers MUST ALWAYS verify credential validity against an authoritative, non-stale database or atomic cache lookup within the assertion verification transaction before accepting any WebAuthn conditional mediation signature.

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.