demo · v142

Refresh Loop Simulator

DBSC's headline trick is short-lived cookies that silently re-derive themselves. The browser holds a private key (TPM / Strongbox / Secure Enclave) and proves possession on every refresh — the server returns a new Set-Cookie with a tight expiry. If the user disconnects, swaps device, or has their TPM go offline, the refresh fails and the session lapses on its own. Step through the lifecycle and break it in different ways.

Origin trial. DBSC ships behind an origin trial in Chrome 142. To exercise the real protocol enable chrome://flags/#enable-bound-session-credentials. This page simulates the state machine deterministically — the real Chrome implementation calls TPM APIs on the device.
cookie age
0s
refreshes
0
final state
—

lifecycle

1.
Login. Server sends Sec-Session-Registration. Browser generates an in-TPM keypair.
2.
Bind. Browser POSTs a signed JWT containing the public key + challenge. Server stores the binding.
3.
Short cookie. Server issues a session cookie with a very short max-age.
4.
Refresh. Before expiry, Chrome calls the refresh endpoint with a JWS proving control of the key.
5.
Rotate. Server validates the signature and issues a fresh short-lived cookie. Loop.
6.
Failure. If any step fails, the cookie lapses naturally. Stolen cookies don't help an attacker without the TPM key.

timeline

protocol shape

// 1. Login response (registration)
Sec-Session-Registration: (RS256 ES256); challenge="abcd"; path="/session/refresh"

// 2. Browser → /session/refresh
POST /session/refresh
Sec-Session-Response: <JWS containing { iat, aud, jti, key_id }>

// 3. Server → browser
HTTP/1.1 200 OK
Set-Cookie: auth=...; Max-Age=60; HttpOnly; Secure; SameSite=Strict

// 4. Loop steps 2-3 every < max-age seconds until the user leaves or refresh fails.

see also