Federated sessions and well-known configuration

Syntax

# RP response: use an existing Session Provider key (draft federation form)
Secure-Session-Registration: (ES256);path="/dbsc/register";challenge="r1";provider_key="base64url-jwk-thumbprint";provider_session_id="sp-session";provider_url="https://id.example"

# https://id.example/.well-known/device-bound-sessions
{"relying_origins":["https://app.example"]}

# https://app.example/.well-known/device-bound-sessions
{"provider_origin":"https://id.example"}

Inputs and constraints

Outputs

When all checks pass, the user agent reuses the Session Provider session key for the new Relying Party DBSC session. The ordinary registration endpoint still returns JSON instructions and cookies. This does not send a hardware certificate or establish a general cross-site identity API.

Errors and unknowns

Missing/invalid parameters, absent provider session, thumbprint mismatch, denied permission, malformed/unavailable well-known response, or a failed mutual authorization stop key sharing. The current Chromium implementation has active DBSC SSO/attestation work and has changed parameter validation relative to the current draft; therefore exact SSO extensions are not a stable server contract. Do not infer them from internal source.

Context

The draft asks user agents to request device-bound-session-key-sharing permission and fetches well-known files without credentials. It also recommends limiting registrable-origin labels to resist coordinated key-guessing; Chromium source currently uses an implementation limit. Deploy only between parties with a real authenticated relationship.

Lifecycle

First establish the provider session before the RP registration. The RP supplies the provider binding, both sites’ well-known files authorize the relationship, and a successful RP registration shares the key. Provider logout/key loss/revocation must be reflected in RP authorization design; the draft does not define a cross-site server revocation protocol.

Site-scoped authorization example

# Registration endpoint is https://login.example.com/dbsc/register
# Its instructions request origin https://example.com with include_site:true.
# https://example.com/.well-known/device-bound-sessions must return:
{"registering_origins":["https://login.example.com"]}

# If the file is missing, non-200, malformed, or does not list that exact origin,
# the DBSC session is not created for the whole site.

Compatibility

Security and privacy

Key sharing has a high-entropy cross-site correlation risk. Mutual well-known opt-in, permission, quotas/backoff, and origin limits are privacy controls, not optional decoration. Avoid it unless federation is required; use normal same-origin DBSC otherwise. Never use it to test whether a person has a particular provider key.