Proposal: Converge DBSC for SSO with DBSC(E)

[Veena11]

Proposal: Converge DBSC for SSO with DBSC(E) — unified trust-anchor selection and binding-statement format

Status: High-level alignment on this convergence direction is complete within Microsoft; detailed design is still being ironed out. Filing this issue now to start engagement with Google and gather early feedback on the overall shape before we lock the details.

📎 Full proposal for review (PDF): Converged Proposal Unifying DBSC(E) and DBSC for SSO- GoogleDoc.pdf

Summary

There are currently three DBSC variants in flight: DBSC (base), DBSC(E) (enterprise extension), and DBSC for SSO (cross-origin IdP↔RP binding). DBSC(E) and DBSC for SSO are solving overlapping problems — both extend base DBSC to address malware that base DBSC explicitly puts out of scope — but with different vocabularies and trust anchors. Without convergence we end up with two parallel specs, two browser code paths, and two integration paths for IdPs and RPs.
This issue proposes a small set of additive changes to DBSC for SSO that allow it to operate over a DBSC(E) trust anchor when one exists, without breaking any of the existing consumer/TOFU flows.

Motivation

DBSC(E) and DBSC for SSO differ primarily in how they establish the device trust anchor; the downstream cryptographic mechanics (per-session binding keys, AIK-attested co-residency, binding statements) are nearly identical.
Leaving them as separate specs has real costs:

• Two specs, two implementations, two integration paths for IdPs and RPs.
• Enterprise IdPs that already have device registration have to operate in a "half-DBSC(E)" state — using TOFU at sign-in despite a stronger trust anchor being available.
• Browsers duplicate code paths (native AIK generation vs. LKH dispatch).
• Standards bodies see two competing proposals from Google and Microsoft instead of one aligned spec.

Goal: a single spec where the consumer (TOFU) and enterprise (clean-room) trust anchors are selectable per request via a small protocol switch, and the rest of the flow is shared.

Converged flow

Three zones:

1. IdP session establishment — diverges based on device registration state. Enterprise path skips Secure-Session-Registration entirely if session already bound via device registration; consumer path runs the existing TOFU registration.
2. RP key generation — single header Secure-Session-GenerateKey carries aik_provider, which selects browser-native generation or LKH delegation.
3. Token issuance + RP binding — unchanged from DBSC for SSO.

Proposed changes

Four changes; (1) and (2) are load-bearing, (3) and (4) follow.

1. Bind IdP session via existing device registration or LKH-backed Secure-Session-Registration

• 1A. IdP MAY skip Secure-Session-Registration when it already has device-auth (e.g., a DeviceKey-signed PRT) proving the device is registered. The IdP↔device binding is established by the DeviceKey; the AIK co-generated during the same registration is reused to attest future RP binding keys.
• 1B. When the device is not registered, IdP MUST trigger Secure-Session-Registration but MAY route key generation through a Local Key Helper via a new aik_provider parameter and Sec-Session-HelperIdList companion header. A new Sec-Session-Proof (JWS, signed by AIK or DeviceKey — open question) lets the IdP recognize the just-registered device.

2. Add aik_provider to Secure-Session-GenerateKey

Secure-Session-GenerateKey: rp_url="https://rp.example.com/", idp_url="https://idp.example.com/", challenge="", aik_provider=("browser" | "lkh"), extra_params=... Sec-Session-HelperIdList: helper-id-1, helper-id-2 ; only when aik_provider=lkh

• aik_provider=browser (default) → browser generates AIK natively in TEE (current DBSC-for-SSO / TOFU path).
• aik_provider=lkh → browser delegates to a Local Key Helper using the pre-provisioned AIK from clean-room registration.
• IdP-only field; absence ⇒ browser (backward compatible). Open token value space leaves room for future providers (webauthn, platform, …).

Naming: DBSC(E) uses nonce, DBSC-for-SSO uses challenge. The merged spec uses challenge as the single term — no aliasing.

3. Single converged binding statement

{
  "stmt": "<base64url signed payload>",
  "challenge": "<base64url>",
  "sub_key_digest": "<sha256 of RP public key>",
  "aik_provider": "browser | lkh",
  "sig_key": "<JWK or key id>",
  "sig_type": "aik | attestation_service",
  "fmt": "tpm | secure_enclave | keyguard",
  "extra_claims": {
    "helper_id": "...",
    "binding_type": "public | private",
    "attestation_format": "..."
  }
}

Preserves DBSC-for-SSO's AIK-based binding, adds DBSC(E)'s multi-signer and extra_claims extensibility, and keeps a single validation model across all flows. Splits the existing aik_key field into sig_key + sig_type so AIK vs. attestation-service signing is explicit.

4. Native, platform-level LKH integration

Today the spec assumes the browser can discover and invoke LKHs, but doesn't standardize how.
The proposal formalizes:

• Reuse existing OS-level identity brokers as LKHs (Windows WAM/CloudAP, macOS/iOS ASAuthorizationProviderExtension, Android AccountAuthenticator/Keystore broker, ChromeOS chrome.enterprise.platformKeys + Verified Access). These already hold device-bound keys, are MDM-deployable, and support host-based routing — they just don't yet expose DBSC(E)-specific operations.
• Reuse each platform's existing IdP-host → broker routing (com.apple.extensiblesso MDM payload, CloudAP/WAM registration, Android account-type, Chrome enterprise policy). No new routing config format.
• Standardize two new LKH operations — establish_bound_idp_session and generate_binding_key — vendor-neutrally (XPC / COM / AIDL implementations vary, but request/response schemas are specified).

What I'm asking for

• Early reactions to the two load-bearing changes (skippable Secure-Session-Registration + aik_provider on Secure-Session-GenerateKey) — does this direction work as additive extensions to DBSC for SSO, in principle? Detail-level review can follow once we converge on the shape.
• Feedback on the converged binding-statement shape (Change 3).
• Whether native/OS-broker LKH integration (Change 4) belongs in this spec or in DBSC(E) — happy to file a sibling issue on w3c/webappsec-dbsc and link them.

cc: @lucasrsant (and please tag any other DBSC-for-SSO maintainers)