Compatibility Lab

/* Device Bound Session Credentials — server-side pattern */ /* DBSC is browser-managed: no direct JS API. The browser handles key generation and signing internally. Use HTTP headers to negotiate the session binding. */ /* 1. Server sends Sec-Session-Registration header: */ // HTTP/1.1 200 OK // Sec-Session-Registration: (ES256);challenge="server-nonce-abc"; // authorization="https://example.com/dbsc/refresh" /* 2. Browser generates device-bound P-256 keypair and sends a signed registration to the authorization URL. The registration is a signed JWT with the public key. */ /* 3. Server stores the public key, binds it to the session, and returns a short-lived session cookie. */ /* 4. On every refresh, server returns: Sec-Session-Challenge: "new-nonce";id="session-id" Browser signs the challenge with the device key. */ /* 5. If proof-of-possession fails → session terminated. A copied cookie without the device key cannot refresh. */ /* Detect if browser will attempt DBSC registration */ const DBSC_LIKELY = window.isSecureContext && typeof crypto !== 'undefined' && typeof crypto.subtle !== 'undefined'; /* The actual key generation is browser-internal. For application-layer ECDSA (e.g. custom binding): */ async function generateDeviceKey() { return crypto.subtle.generateKey( { name: 'ECDSA', namedCurve: 'P-256' }, false, // non-extractable — key stays in device ['sign', 'verify'] ); } async function signChallenge(privateKey, challenge) { const enc = new TextEncoder(); const sig = await crypto.subtle.sign( { name: 'ECDSA', hash: 'SHA-256' }, privateKey, enc.encode(challenge) ); return btoa(String.fromCharCode(...new Uint8Array(sig))); }