Device Bound Session Credentials

A source-separated server implementation reference for the evolving Device Bound Session Credentials (DBSC) HTTP protocol.

Implementation status and naming

Do not deploy the obsolete Sec-Session-Registration name. The current W3C Editor’s Draft and current Chrome developer guide use Secure-Session-Registration; Sec-Secure-Session-Id is the one request header retaining the Sec- prefix. This is an evolving protocol, not a JavaScript API.

Source hierarchy and current status
Item	Requirement / behavior
Normative source	W3C DBSC Editor’s Draft defines the current grammar and algorithms; it labels itself an early draft.
Chrome developer guide	Chrome for Developers is dated 2025-04-15 and is useful deployment guidance; where it is less exact, the draft is cited as the grammar source.
Chromium behavior	current Chromium registration/refresh fetcher implements additional limits and transient retry behavior. Treat those as Chromium behavior, not portable requirements.
Shipping and intent record	ChromeStatus currently says “In development” and records Chrome desktop milestone 145, an Android milestone that is null/unknown, and Working Draft status. This is DBSC protocol availability, not static layout support for this documentation. Its public Blink intent trail includes Intent to Prototype, Intent to Experiment, and Intent to Ship. The presence of those messages does not by itself settle current availability or protocol grammar.

Protocol surface

Implement the server endpoints, not page JavaScript. Each stable route below is a complete local reference for a server-facing surface.

Secure-Session-Registration: opt-in and algorithm offer.
Secure-Session-Challenge, Secure-Session-Response, Sec-Secure-Session-Id, and Secure-Session-Skipped.
JSON session-instructions root; session scope; scope rule; and session credential. DBSC proof JWT is the proof field carried by Secure-Session-Response.
Registration exchange, refresh exchange, and state / error algorithms.
Federated key sharing and /.well-known/device-bound-sessions.

Minimal single-origin exchange

POST /login HTTP/1.1
Host: app.example

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256);path="/dbsc/register";challenge="registration-nonce"
Set-Cookie: sid=long-lived-bootstrap; Path=/; Secure; HttpOnly; SameSite=Lax

# Chrome asynchronously POSTs /dbsc/register, with Secure-Session-Response.
# The endpoint returns JSON instructions plus a short-lived sid cookie.
# Later, a missing protected sid causes Chrome to POST /dbsc/refresh and retry the deferred request.

Security, privacy, and compatibility boundary

DBSC reduces replay of an exported short-lived cookie on another device; it does not stop a live local attacker from using the browser or signing oracle, nor an attacker present at registration. Do not equate “hardware-backed” with device attestation: the ordinary protocol does not send a TPM certificate or stable device identifier. DBSC follows cookie policy: if the bound credential would not apply (including cookie policy), DBSC behavior must not create a bypass.

DBSC availability and standards position
Item	Requirement / behavior
Chrome	DBSC availability, not page-layout support: ChromeStatus lists DBSC as in development, with Chrome desktop milestone 145. Its Android milestone is null/unknown; availability remains controlled by implementation and feature configuration.
Firefox	No signal; the Mozilla standards-position issue is the public evidence, not an implementation commitment.
Safari	No signal; the WebKit standards-position issue is the public evidence, not an implementation commitment.
Other engines	Unknown. The W3C document is an Editor’s Draft, not a final interoperable Recommendation.

Primary sources: spec · chrome · ChromeStatus · Intent to Prototype · Intent to Experiment · Intent to Ship · chromium. External sources open in a new tab.