What’s new here

Cookie theft is a bearer-token problem: grab the cookie, use it from a different device. DBSC closes that gap by tying a session to a private key that, under normal circumstances, cannot be exported from the user’s device. The browser holds the key, runs the refresh loop, and defers outbound requests until it has a fresh short-lived cookie backed by proof of key possession. The server sees the same cookie-based auth it always did; the difference is that the cookie is short-lived and the proof of possession happens in the background, browser-to-server. The README notes this allows deployment on complex existing setups, often with no changes to non-auth related endpoints.

What it does

DBSC is a W3C specification (written in Bikeshed), not a library. It defines:

• A Secure-Session-Registration response header the server sends at sign-in time, naming the algorithm, an HTTP endpoint, and an optional challenge.
• A browser flow that generates a device-bound key pair (backed by a TPM on Windows, or another secure store at the browser’s discretion), calls the registration endpoint with a signed JWT (typ: dbsc+jwt), and receives a session identifier plus a list of cookies to maintain.
• A refresh protocol: when a scoped request is about to go out without the required cookie, the browser holds that request, posts to the refresh endpoint with a Sec-Secure-Session-Id header, optionally responds to a Secure-Session-Challenge, and releases the held request once it has a fresh Set-Cookie.
• Session termination via {"continue": false} in a refresh response, Clear-Site-Data headers, or user-initiated data clearing.

Chrome’s Windows implementation backs keys with a TPM. Published numbers from that research: ~60% of Windows users have a TPM available, signing latency P50 200 ms / P95 600 ms, error rate ~0.001%, using ECDSA P256.

Who it’s for

Server engineers adding DBSC support to an auth stack, browser engineers implementing the protocol, and security architects evaluating session-binding schemes. The spec notes that non-auth endpoints often need no changes; only the sign-in handler and a new refresh endpoint are required. There is also a DBSC(E) extension document in the repo for enterprise scenarios that need device-key chaining.

Try it

This is a specification repository, not an installable package. The rendered spec lives at the homepage listed in FACTS: https://w3c.github.io/webappsec-dbsc/. To contribute, the README points to the Issue tracker. The source is Bikeshed markup. There is no build or install command in the README.

How mature is it

498 stars, 50 forks, 23 contributors. Created July 2023, last pushed September 2026. No formal releases. 2 commits in the past 90 days, 30 open issues, no open PRs. License listed as “Other” on GitHub. The spec is authored by two Google engineers (Kristian Monsen and Arnar Birgisson). Recent commit activity is low (2 commits in 90 days), though the last push was about a month before these FACTS were collected.