Intent to Prototype: [FedCM] Support web-identity.<registrable domain> subdomain for well-known file discovery

22 views

Skip to first unread message

Chromestatus

unread,

1:10 AM (6 hours ago) 1:10 AM

to blin...@chromium.org, sures...@microsoft.com

Contact emails

sures...@microsoft.com

Explainer

https://github.com/w3c-fedid/FedCM/pull/828

Specification

https://github.com/w3c-fedid/FedCM/pull/823

Summary

FedCM today requires the well-known file at https://<registrable-domain>/.well-known/web-identity (the apex). This blocks deployments where: - the apex cannot host files (apex domains can't use CNAME, breaking modern CDN/cloud onboarding), - the apex and the auth subdomain are owned by different teams, or - a white-label IDP is CNAME'd onto a customer subdomain and has no control over the customer apex. Proposal (per PR #823): Chromium should fetch the well-known file from https://web-identity.<registrable-domain>/.well-known/web-identity first, and fall back to the existing apex URL if the subdomain fetch fails (DNS/TLS/HTTP error, malformed JSON, or provider_urls length > 1). The fallback runs in parallel with the config fetch; request shape (opaque origin, credentials: omit, no-referrer, Sec-Fetch-Dest: webidentity) is unchanged. The same-site skipWellKnown shortcut is preserved. Why it's safe: The label is fixed (web-identity.), so the IDP cannot encode RP identity in the discovery URL — the existing anti-fingerprinting guarantee holds.

Blink component

Blink>Identity>FedCM

Web Feature ID

fedcm

Motivation

https://github.com/w3c-fedid/FedCM/issues/809

Initial public proposal

No information provided

Goals for experimentation

None

Requires code in //chrome?

False