Secure-Session-Response header

The request Structured Field carrying the DBSC proof JWT. ES256/RS256 proofs are signed; none is unsigned and has no device-binding guarantee, so do not use it to issue protected authorization.

Syntax

The field is an RFC 9651 sf-string whose string value contains only a compact JWS/JWT. Header parameters should be ignored. The JWT header uses typ: "dbsc+jwt" and alg ES256, RS256, or none.

Secure-Session-Response = sf-string
Secure-Session-Response: "base64url(header).base64url(payload).base64url(signature)"

Inputs and shape

Proof validation inputs
Item	Requirement / behavior
Registration proof	For ES256/RS256, protected JWT header must include public `jwk`; for `none`, it must not. `none` therefore has no signing key or JWK possession proof and gives no device-binding security guarantee. Servers should not offer it for protected authorization. Payload `jti` copies the registration challenge.
Refresh proof	JWT header must not include `jwk`; verify against the public key stored at registration. Payload `jti` is the cached/new refresh challenge.
`authorization` claim	Required only if that string was present in the registration header; compare/consume it in the login binding logic.
Signature	Validate an explicit algorithm allowlist, JWS signature, required type/claims, session binding, freshness, and replay state. Do not accept an algorithm merely because a JWT says so; omit `none` from protected-authorization offers.

Outputs

A valid signed registration proof yields a public key to store against the new server session. A valid signed refresh proof authorizes ordinary Set-Cookie renewal and, optionally, replacement JSON instructions. An unsigned none message provides neither a key nor device-binding security; route any intentionally non-binding authorization through a separate ordinary path. The browser never exposes this proof to page JavaScript as an API result.

Errors and recovery

Reject malformed structured fields/JWTs, wrong typ, unsupported algorithm, missing/forbidden JWK, bad signature, stale or replayed jti, and mismatched session. A failed registration is sent with a null session ID, so the draft termination step is a no-op and creates/replaces no DBSC session. For refresh, a server can return 403 plus a new challenge to request a new proof; a different 4xx terminates and removes the existing session in the draft algorithm.

Context

The browser adds this request header only to its registration/refresh POST. Refresh also includes Sec-Secure-Session-Id. Treat it as a browser-provided protocol message, but authenticate and validate it exactly like hostile network input.

Lifecycle

Protected registration associates one fresh public key with one session. Refresh verifies the existing stored key and normally has no JWK. A none registration has no stored signing key and cannot meet a device-binding authorization policy; servers should not offer it as a protected-session fallback. The draft may still create a DBSC session with a null key pair; that is not an automatic redirect to an ordinary path. Chromium may reuse a cached signed proof for the same key/challenge after transient failure; therefore replay protection must be challenge-based and allow the intentional retry semantics you choose, not assume every valid signature is unique in transit.

Decoded shape and HTTP example

POST /dbsc/refresh HTTP/1.1
Host: app.example
Sec-Secure-Session-Id: "session-42"
Secure-Session-Response: "eyJ0eXAiOiJkYnNjK2p3dCIsImFsZyI6IkVTMjU2In0.eyJqdGkiOiJyZWZyZXNoLW5vbmNlIn0.signature"

// Refresh JWT protected header
{"typ":"dbsc+jwt","alg":"ES256"}
// Refresh JWT payload
{"jti":"refresh-nonce"}

// Registration additionally carries header.jwk; refresh MUST NOT.

Compatibility

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.

Security and privacy

Use a hardened JWT/JWS library with explicit allowed algorithms and JWK parsing limits. Do not log full proof headers. The standard protocol provides possession proof for a signed-key path, not TPM certificate attestation or a stable hardware identity. none has no signing key or JWK possession proof at all: do not offer it for protected authorization; use a separate ordinary authorization path if non-binding behavior is intentional.

Primary sources: response · jwt · chromium · chrome · rfc9651. External sources open in a new tab.