Registration exchange

Wire sequence

1. POST /login → 200 Secure-Session-Registration: (ES256);path="/dbsc/register";challenge="r1"
2. Browser POST /dbsc/register
   Secure-Session-Response: "<registration dbsc+jwt with header.jwk, payload.jti=r1>"
   Authorization: Bootstrap abc123                 # only when supplied
3. 200 JSON instructions + Set-Cookie: sid=short; ...

Server inputs

Login establishes a server-authenticated bootstrap context. Registration receives normal applicable cookies, optional copied Authorization, and a signed proof, but its DBSC session id input is null. For ES256/RS256 the proof exposes a fresh JWK; bind it to a new opaque session identifier only after signature, type, algorithm, challenge, and bootstrap authorization validation.

Server outputs

Return JSON session instructions and ordinary short-lived Set-Cookie headers. Use Content-Type: application/json and Cache-Control: no-store as defensive deployment practice. The browser creates a DBSC session only if config validation and cookie-setting eligibility succeed; it cannot replace one through this null-ID registration path.

Failure handling

Registration is not a replacement for login. On invalid proof, bootstrap state, response JSON, continue:false, or terminal response status, the draft’s terminate operation receives a null session ID and is a no-op: no DBSC session is created, removed, or replaced. Preserve the normal login’s explicit application policy. Empty registration bodies are not a valid “unchanged config” in Chromium; current code reports an empty session config. Do not issue a DBSC config before the public key is durably associated with the authenticated server session.

Context and endpoint rules

The browser POST is same-site with the initiating request. Registration URL validation uses the final redirect URL in current Chromium; configure redirects deliberately and keep the endpoint HTTPS. If site-scoped registration originates from a subdomain, the draft/current Chromium flow requires /.well-known/device-bound-sessions authorization.

Idempotency and key loss

Make the endpoint safe against duplicate delivery of the same valid registration proof/challenge: return the same session config or atomically recognize the already-created binding. Before a valid response is stored, registration has no existing DBSC session to terminate or replace. On client key loss or cleared site data, DBSC cannot refresh; ordinary login/recovery must create a new session/key. Never silently associate a new JWK with an old authenticated session without fresh authentication policy.

Worked HTTP exchange

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="/dbsc/register";challenge="r-73"
Set-Cookie: bootstrap=b1; Path=/; Secure; HttpOnly; SameSite=Lax

POST /dbsc/register HTTP/1.1
Host: app.example
Cookie: bootstrap=b1
Secure-Session-Response: "<JWT: typ=dbsc+jwt, alg=ES256, jwk=..., jti=r-73>"

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Set-Cookie: sid=s1; Path=/; Max-Age=600; Secure; HttpOnly; SameSite=Lax

{"session_identifier":"session-42","refresh_url":"/dbsc/refresh","scope":{"include_site":false},"credentials":[{"type":"cookie","name":"sid","attributes":"Path=/; Secure; HttpOnly; SameSite=Lax"}]}

# Registration failure: the algorithm was called with session_id = null.
HTTP/1.1 400 Bad Request

# terminate(null) is a no-op: no DBSC session was created, removed, or replaced.
# Any login cookie/application-session action remains the server's separate policy.

Compatibility

Security and privacy

Consume the registration nonce and store the public key transactionally. Keep bootstrap authorization short-lived and audience-bound. Do not log JWTs or Set-Cookie values. The protocol does not prove physical-device identity or protect a device already compromised during registration.