Secure-Session-Registration header

The response Structured Field that starts an asynchronous registration. It is processed after a normal response; the page does not call it.

Syntax

This is an RFC 9651 List Structured Field. Each list member must be an inner list of supported algorithm tokens; current draft values are ES256, RS256, and none.

Secure-Session-Registration = sf-list

Secure-Session-Registration: (ES256 RS256);path="/dbsc/register";challenge="opaque-registration-nonce";authorization="optional-bootstrap"

Inputs and constraints

Registration parameters
Item	Requirement / behavior
`path`	Required `sf-string`. Relative to the response URL or a full URL; entries without it are ignored.
`challenge`	Optional `sf-string`. Becomes JWT `jti` when present. Use a server-generated, single-use value.
`authorization`	Optional `sf-string`. The UA copies it to the registration JWT claim and an `Authorization` request header.
`provider_key`, `provider_session_id`, `provider_url`	Draft federation parameters; do not use for ordinary same-origin registration. Current draft requires all three together, while current Chromium has SSO-related implementation changes: see the federation route.

Outputs

The browser chooses a supported algorithm, creates or selects a key, then POSTs to the resolved endpoint. A successful endpoint response must contain valid JSON session instructions; it can set the short-lived cookies in ordinary Set-Cookie headers.

`none` algorithm semantics

none has no signing key, JWK possession proof, or device-binding security guarantee. The registration header may offer none; if selected, the key-generation algorithm returns no key pair. A DBSC proof using alg: "none" has no signature and a registration proof must not carry jwk. Servers should not offer it for protected authorization. For a flow that deliberately lacks this property, use a separate ordinary authorization path; do not call it DBSC-protected authorization.

Source-defined `none` behavior
Dimension	Behavior
Syntax and inputs	Offer `(none)` as a registration algorithm token; the JWT protected header uses `"alg":"none"` and no registration `jwk`. The resulting message is neither a signature nor a JWK possession proof.
Outputs and lifecycle	The user agent has no session signing key. The send-request algorithm creates a proof when challenged but only signs it when a key pair exists; `none` cannot provide DBSC’s device-binding guarantee. The draft can still create a DBSC session with a null key pair.
Errors and context	A server that requires protected authorization should reject or avoid this offer; it cannot verify cryptographic possession for `none`. That is server policy: the draft does not automatically send a `none` registration to another endpoint. Handle any intentionally non-binding authorization through a separate ordinary endpoint/policy that does not offer DBSC registration.
Compatibility	The Editor’s Draft lists `none`; current Chrome enablement and interoperable deployment behavior remain unknown.
Security and privacy	Do not offer `none` for protected authorization or sessions whose purpose is resistance to exported-cookie replay. It creates no device-bound secret, gives no device-binding security guarantee, and must not be described as hardware-backed.

Secure-Session-Registration: (none);path="/dbsc/register";challenge="r-1"

# Registration proof shape if the user agent selects none
{"typ":"dbsc+jwt","alg":"none"}
{"jti":"r-1"}
# No jwk; no signing key; no cryptographic signature.
# Do not grant DBSC-protected authorization from this message.

# Protected authorization: do not offer none.
Secure-Session-Registration: (ES256 RS256);path="/dbsc/register";challenge="r-2"

# Intentionally non-binding authorization belongs on a separate ordinary path,
# for example /login/ordinary, with its own cookie/bearer threat model.

Malformed and unsupported input

The draft skips a list entry that is not an inner list, has no string path, or has non-string challenge/authorization. If no offered algorithm is supported, key creation fails and registration is not sent. Chromium also rejects invalid JSON/configuration and cannot create a session unless at least one declared bound cookie can be set.

Context

Send it in a response to an ordinary request after authentication. The registration POST is same-site with the initiating request; endpoints must be HTTPS (or localhost for the draft’s validation). It is browser-network behavior, not fetchable from JavaScript by constructing these forbidden protocol headers.

Lifecycle

Registration is asynchronous. A registration request has no session identifier; it may carry the initial signed proof if a challenge or authorization is supplied. A failed registration does not make the original login response fail and cannot remove or replace a DBSC session: termination with its null ID is a no-op. A later valid config stores the returned session identifier when a declared cookie can be set (and may replace a same-ID record).

Complete response example

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256);path="/dbsc/register";challenge="r-7f4c";authorization="Bootstrap abc123"
Set-Cookie: bootstrap=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

# Multiple registrations may be separate header lines or comma-separated list members.
# Do not send an unquoted challenge: Structured Field strings require quotes.

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

Bind registration to the completed login transaction. Validate the JWT and its challenge server-side before associating its public JWK with a session. A registration-time malware attacker is outside DBSC’s protection; do not claim attestation from a standard DBSC JWK. Never put a reusable bearer secret in a challenge. A none registration has no signing key or JWK possession proof: do not offer it for protected authorization, and keep any deliberate non-binding flow on a separate ordinary authorization path.

Primary sources: registration · spec · algorithms · key-pair algorithm · session-request algorithm · create-session algorithm · DBSC proof JWT · chrome · chromium · rfc9651. External sources open in a new tab.