Secure-Session-Challenge header

Syntax — unresolved source divergence

The Editor’s Draft header section gives SecureSessionChallenge = sf-string. Its cache algorithm instead obtains an RFC 9651 list. Current Chromium parser code calls ParseList and accepts a string list member with or without id. These are conflicting source descriptions, not an established grammar.

# Editor’s Draft header subsection
Secure-Session-Challenge = sf-string
Secure-Session-Challenge: "bare-challenge"

# Editor’s Draft cache algorithm and Chromium parser
Secure-Session-Challenge = sf-list
Secure-Session-Challenge: "challenge-with-session";id="session-42"

Inputs and constraints

Outputs

For ordinary responses, the draft cache algorithm needs a matching session ID before it can cache a challenge. On a refresh 403, Chromium can parse a bare or identified list member; the current sources do not settle which bare form is portable or how it should map to a session beyond the ordinary cache path. Do not represent either behavior as cross-browser normative.

Errors and recovery

Malformed list members and non-string values are rejected by Chromium’s list parser. The Editor’s Draft ordinary cache algorithm ignores a member without a usable string id, an unknown session ID, or a response that could not set the bound cookie. A 403 without a challenge usable by the browser cannot produce a proof; the current Chromium fetcher reports invalid challenge rather than inventing one.

Explicit divergence: the Editor’s Draft header section says sf-string; its cache algorithm parses sf-list and requires id for ordinary response caching; Chromium parses sf-list and accepts a bare member; the Chrome developer guide shows a bare challenge. None is labelled settled or older here. Servers needing ordinary-response cache behavior should include id, while independently testing bare 403 behavior against their enabled Chrome population.

Context

Servers may return the header on responses in the session’s context. The draft’s ordinary-response cache path identifies a session using the response URL plus id; a bare parsed value has no such documented ordinary-cache mapping. The value is not a cross-site routing mechanism.

Lifecycle

Cache now for the next refresh, or return 403 to force the next signing round. A server must accept a recent previous challenge as well as the newest one because concurrent deferred requests and latency can race. Chromium’s current implementation limits challenge rounds per fetch; that numerical limit is implementation behavior, not a portable server contract.

Examples

HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "refresh-nonce-2";id="session-42"

# Cache a next challenge without forcing an immediate refresh:
HTTP/1.1 200 OK
Secure-Session-Challenge: "next-nonce";id="session-42"

Compatibility

Security and privacy

Challenges are proof nonces, not session credentials. Make them unpredictable, expire them quickly, bind them to the server session and expected public key, and consume them on successful verification. Do not make challenge acceptance a device fingerprinting oracle.