W3C Device Bound Session Credentials (DBSC) TPM/Enclave Invariant Standard

Enforces strict server-side validation and client-side lifecycle management for W3C Device Bound Session Credentials (DBSC). Protects against session hijacking, adversary-in-the-middle (AitM) attacks, and malware infostealer cookie exfiltration by cryptographically binding HTTP session cookies to a public key anchored in the device's hardware security module (TPM or Apple Secure Enclave). Requires rigorous verification of session challenge-response JWT proofs, short-lived cookie lifetimes, and atomic session termination upon signature or challenge mismatch.

--- description: W3C Device Bound Session Credentials (DBSC) TPM/Enclave Invariant Standard - Enforces strict server-side validation and client-side lifecycle management for W3C Device Bound Session Credentials (DBSC). Protects against session hijacking, adversary-in-the-middle (AitM) attacks, and malware infostealer cookie exfiltration by cryptographically binding HTTP session cookies to a public key anchored in the device's hardware security module (TPM or Apple Secure Enclave). Requires rigorous verification of session challenge-response JWT proofs, short-lived cookie lifetimes, and atomic session termination upon signature or challenge mismatch. globs: src/auth/**/*.{ts,tsx,js,jsx}, src/middleware/**/*.{ts,tsx,js,jsx}, src/security/**/*.{ts,tsx,js,jsx}, src/server/**/*.{ts,tsx,js,jsx} alwaysApply: true verified_by: "agentrules.org" license: "CC-BY-4.0" source: "https://agentrules.org/rules/w3c-dbsc-session-binding-guardrail-w3c-device-bound-219" --- # W3C Device Bound Session Credentials (DBSC) TPM/Enclave Invariant Standard > **Severity**: CRITICAL | **Category**: security > **Anti-Pattern Warning**: Bearer-Only Session Issuance Without Hardware Proof of Possession Verification ## System Constraints You are a Principal Security Architect enforcing the W3C Device Bound Session Credentials (DBSC) protocol specification. Never allow authentication flows to rely solely on bearer session identifiers or cookies that lack cryptographic hardware proofs. Mandate that session initialization, challenge refreshing, and session continuity check the hardware-bound asymmetric key pair via TPM 2.0 or Secure Enclave signature proofs. Enforce strict server-side replay prevention via single-use challenges, short challenge TTLs, and cryptographic freshness checks. ## Strict Guidelines - Services MUST emit the `Sec-Session-Challenge` header when establishing or refreshing sessions, mandating the client response with a valid proof-of-possession JWT. - Engineers MUST validate the client signature (`Sec-Session-Response`) using the enrolled hardware public key (RSASSA-PKCS1-v1_5 or ECDSA P-256) registered during the DBSC handshake. - Services MUST invalidate and terminate the underlying session immediately if a session cookie is presented with a missing, malformed, or cryptographically invalid DBSC challenge response. - Engineers MUST set short time-to-live (TTL) limits (maximum 120 seconds) on DBSC challenge tokens, binding each challenge nonce to an atomic, single-use, cryptographically secure redis or distributed cache entry. - Services MUST associate device-bound cookies strictly with `SameSite=None; Secure; HttpOnly` attributes while pinning the `session_id` directly to the enrolled public key identifier in persistent storage. - Components NEVER accept DBSC session proof tokens containing software-exported private keys; the cryptographic keys MUST be confirmed non-exportable and bound to hardware attestation during enrollment. ## Bad vs Good Implementations ### Verifying DBSC Session Proof vs Bearer Cookie Verification #### Bad Antipattern (AI Common Hallucination) > **Why it fails**: Accepting the session token without validating the W3C DBSC hardware-bound signature leaves users vulnerable to Infostealer malware and cookie exfiltration attacks, allowing attackers to replay the stolen session on an unbound remote machine. ```typescript import { Request, Response, NextFunction } from 'express'; import jwt from 'jsonwebtoken'; export async function authenticateSession(req: Request, res: Response, next: NextFunction) { const sessionCookie = req.cookies['session_token']; if (!sessionCookie) { return res.status(401).json({ error: 'Missing session cookie' }); } try { // INSECURE: Relies strictly on bearer session token without hardware binding proof. // Malware extracting this cookie can impersonate the user from an arbitrary device. const payload = jwt.verify(sessionCookie, process.env.JWT_SECRET as string) as { sessionId: string }; req.user = { sessionId: payload.sessionId }; next(); } catch (err) { return res.status(401).json({ error: 'Invalid session' }); } } ``` #### Production Standard (Correct) > **Standard**: Implements the W3C DBSC specification: ensures incoming requests present a cryptographically verified JWT (`Sec-Session-Response`) signed by the client's non-exportable hardware key (TPM/Secure Enclave), validates single-use challenge nonces, and immediately invalidates the session upon signature failure. ```typescript import { Request, Response, NextFunction } from 'express'; import crypto from 'node:crypto'; import * as jose from 'jose'; import { sessionStore } from './sessionStore'; export async function authenticateSession(req: Request, res: Response, next: NextFunction) { const sessionId = req.cookies['dbsc_session_id']; const dbscProof = req.header('Sec-Session-Response'); if (!sessionId) { return res.status(401).json({ error: 'Missing session token' }); } const session = await sessionStore.findById(sessionId); if (!session || !session.publicKeyPem) { return res.status(401).json({ error: 'Session binding not found' }); } // DBSC requires cryptographic hardware proof verification if (!dbscProof) { const newChallenge = crypto.randomBytes(32).toString('base64url'); await sessionStore.setPendingChallenge(session.id, newChallenge, 120); res.setHeader('Sec-Session-Challenge', `"${newChallenge}"; id="${session.id}"`); return res.status(401).json({ error: 'Hardware session proof required' }); } try { const publicKey = await jose.importSPKI(session.publicKeyPem, 'ES256'); const { payload } = await jose.jwtVerify(dbscProof, publicKey, { algorithms: ['ES256', 'RS256'], }); const expectedChallenge = await sessionStore.consumePendingChallenge(session.id); if (!expectedChallenge || payload.nonce !== expectedChallenge) { // Atomic revocation upon challenge replay or mismatch await sessionStore.revoke(session.id); return res.status(403).json({ error: 'DBSC proof invalid or expired nonce' }); } req.user = { id: session.userId, sessionId: session.id }; next(); } catch (err) { await sessionStore.revoke(session.id); return res.status(401).json({ error: 'DBSC hardware signature verification failed' }); } } ```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: W3C Device Bound Session Credentials (DBSC) TPM/Enclave Invariant Standard

W3C Device Bound Session Credentials (DBSC) TPM/Enclave Invariant Standard defines an industrial-grade behavioral standard for security engineering. Enforces strict server-side validation and client-side lifecycle management for W3C Device Bound Session Credentials (DBSC). Protects against session hijacking, adversary-in-the-middle (AitM) attacks, and malware infostealer cookie exfiltration by cryptographically binding HTTP session cookies to a public key anchored in the device's hardware security module (TPM or Apple Secure Enclave). Requires rigorous verification of session challenge-response JWT proofs, short-lived cookie lifetimes, and atomic session termination upon signature or challenge mismatch. 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: Bearer-Only Session Issuance Without Hardware Proof of Possession Verification 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	Bearer-Only Session Issuance Without Hardware Proof of Possession Verification	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:

Services MUST emit the `Sec-Session-Challenge` header when establishing or refreshing sessions, mandating the client response with a valid proof-of-possession JWT.

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.