W3C Device-Bound Session Credentials (DBSC) Cryptographic Invariant

--- description: W3C Device-Bound Session Credentials (DBSC) Cryptographic Invariant - Enforces cryptographic hardware-binding of HTTP application sessions using W3C Device-Bound Session Credentials (DBSC) specifications. Prevents token exfiltration and session replay attacks by asserting asymmetric TPM or Secure Enclave proof signatures on session initialization, refresh, and high-privilege transactional paths. globs: src/auth/**/*.{ts,js}, src/middleware/**/*.{ts,js}, src/server/auth/**/*.{ts,js}, src/api/auth/**/*.{ts,js} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/dbsc-cryptographic-session-binding-guardrail" --- # W3C Device-Bound Session Credentials (DBSC) Cryptographic Invariant > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Unbound Bearer Cookie Replay and Missing Hardware-Attested DBSC Signature Proofs ## System Constraints You are a Principal Security Architect enforcing W3C Device-Bound Session Credentials (DBSC) invariants. You must ensure that authentication systems cryptographically bind session lifecycle transitions and high-privilege calls to hardware-backed client public keys (TPM/Secure Enclave), enforcing single-use challenge verification and signature checks to defeat session hijacking and cookie theft. ## Strict Guidelines - Engineers MUST ALWAYS verify the `Sec-Session-Response` header against the registered hardware-backed public key during session creation, refresh, and privileged operations. - Engineers MUST NEVER permit session renewal or sensitive state mutations solely based on bearer cookies without verifying single-use, cryptographically secure nonces issued via `Sec-Session-Challenge`. - Services MUST invalidate the session immediately upon detection of a public key mismatch, invalid cryptographic proof, or replayed challenge nonce. - Code SHOULD enforce standard cryptographic signature algorithms (ES256, RS256, Ed25519) specified in the DBSC session registration parameters. - Components NEVER accept ambient cookie credentials when a session is flagged as hardware-bound, terminating requests that omit required DBSC challenge responses. ## Bad vs Good Implementations ### DBSC Hardware-Bound Session Refresh Verification #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Accepts a raw bearer refresh token without requiring or verifying DBSC proof headers (`Sec-Session-Response`), making the session vulnerable to infostealer malware, token replay, and cross-machine exfiltration. ```typescript import { Request, Response } from 'express'; import { verifyJwt } from './jwt'; import { findSession } from './db'; export async function refreshSessionHandler(req: Request, res: Response) { const refreshToken = req.cookies['refresh_token']; if (!refreshToken) { return res.status(401).json({ error: 'Missing refresh token' }); } // CRITICAL SECURITY FLAW: Vulnerable to cookie exfiltration/replay. // Fails to verify W3C DBSC hardware proof or challenge nonce. const payload = verifyJwt(refreshToken); const session = await findSession(payload.sessionId); if (!session || session.revoked) { return res.status(401).json({ error: 'Invalid session' }); } const newAccessToken = generateAccessToken(session.userId); return res.json({ accessToken: newAccessToken }); } ``` #### Production Standard (Correct) > **Standard**: Enforces W3C DBSC proof verification via `Sec-Session-Response`. Asserts that the client holds the TPM-backed private key registered during initialization, validates single-use server challenge nonces, and strictly binds the session identifier to the cryptographic assertion. ```typescript import { Request, Response } from 'express'; import { subtle } from 'node:crypto'; import { findSession, consumeChallengeNonce } from './db'; import { decodeJwtHeader, importSpkiKey } from './crypto-utils'; interface DbscProofPayload { jti: string; iat: number; nonce: string; aud: string; sub: string; } export async function refreshSessionHandler(req: Request, res: Response) { const sessionId = req.cookies['session_id']; const dbscProof = req.header('Sec-Session-Response'); if (!sessionId || !dbscProof) { // Mandate DBSC challenge flow if client omits cryptographic proof res.setHeader('Sec-Session-Challenge', `"${generateChallengeNonce()}"; id="${sessionId || ''}"`); return res.status(401).json({ error: 'Device binding proof required' }); } const session = await findSession(sessionId); if (!session || session.revoked || !session.devicePublicKey) { return res.status(401).json({ error: 'Invalid or unbound session' }); } // Verify hardware signature (DBSC Proof JWT signed by TPM/Secure Enclave) const [headerB64, payloadB64, signatureB64] = dbscProof.split('.'); const payload: DbscProofPayload = JSON.parse(Buffer.from(payloadB64, 'base64url').toString('utf8')); // Invariant: Nonce must be fresh, single-use, and bound to this session const isNonceValid = await consumeChallengeNonce(session.id, payload.nonce); if (!isNonceValid || payload.sub !== session.id) { return res.status(403).json({ error: 'Invalid DBSC challenge or session binding' }); } const publicKey = await importSpkiKey(session.devicePublicKey, session.keyAlgorithm); const dataBytes = new TextEncoder().encode(`${headerB64}.${payloadB64}`); const signatureBytes = Buffer.from(signatureB64, 'base64url'); const isSignatureValid = await subtle.verify( { name: session.keyAlgorithm, hash: 'SHA-256' }, publicKey, signatureBytes, dataBytes ); if (!isSignatureValid) { return res.status(403).json({ error: 'Cryptographic device proof mismatch' }); } const newAccessToken = generateAccessToken(session.userId); return res.json({ accessToken: newAccessToken }); } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: W3C Device-Bound Session Credentials (DBSC) Cryptographic Invariant

W3C Device-Bound Session Credentials (DBSC) Cryptographic Invariant defines an industrial-grade behavioral standard for security engineering. Enforces cryptographic hardware-binding of HTTP application sessions using W3C Device-Bound Session Credentials (DBSC) specifications. Prevents token exfiltration and session replay attacks by asserting asymmetric TPM or Secure Enclave proof signatures on session initialization, refresh, and high-privilege transactional paths. 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: Unbound Bearer Cookie Replay and Missing Hardware-Attested DBSC Signature Proofs 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	Unbound Bearer Cookie Replay and Missing Hardware-Attested DBSC Signature Proofs	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 the `Sec-Session-Response` header against the registered hardware-backed public key during session creation, refresh, and privileged operations.

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.