Intent to Ship: FedCM Privacy Enforcement for Client Metadata
suresh potti
Contact emails
sures...@microsoft.com
Specification
https://github.com/w3c-fedid/FedCM/pull/760
Summary
To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700.
Migration Plan
Chrome will enforce this rule in two phases:
Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
Chrome 145 (Enforcement Phase): The requirement becomes mandatory. FedCM configurations missing these endpoints will be blocked, preventing authentication flows.
Blink component
Web Feature ID
TAG review
None
Risks
Interoperability and Compatibility
IdPs failing to update .well-known/web-identity for FedCM client metadata risk breaking authentication flows. Chrome 143 issues warnings, but starting Chrome 145, missing accounts_endpoint or login_url will block configurations entirely. Immediate migration is critical to maintain compatibility and avoid service disruptions for relying parties and end-users.
Gecko: No signal (Firefox does not wish to support the client metadata endpoint of the FedCM API so this would not be a change applicable to them)
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
FedCM does not work in WebView.
Ongoing technical constraints
None
Debuggability
Same as other FedCM features. The network view in devtools would be especially helpful for debugging this feature.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No, FedCM in general is not supported on webview. Supported on all other blink platforms.
Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/fedcm/fedcm-well-known-validation?label=experimental&label=master
Flag name on about://flags
fedcm-well-known-endpoint-validation
Finch feature name
FedCmWellKnownEndpointValidation
Requires code in //chrome?
False
Estimated milestones
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4614417052467200
This intent message was generated by Chrome Platform Status.
Mike Taylor
Contact emails
sures...@microsoft.com Specification
https://github.com/w3c-fedid/FedCM/pull/760 Summary To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700.
Migration Plan Chrome will enforce this rule in two phases:
Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
Chrome 145 (Enforcement Phase): The requirement becomes mandatory. FedCM configurations missing these endpoints will be blocked, preventing authentication flows.
Blink component
Web Feature ID
TAG review
None
Risks
Interoperability and Compatibility
IdPs failing to update .well-known/web-identity for FedCM client metadata risk breaking authentication flows. Chrome 143 issues warnings, but starting Chrome 145, missing accounts_endpoint or login_url will block configurations entirely. Immediate migration is critical to maintain compatibility and avoid service disruptions for relying parties and end-users.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bb953b88-ddd6-4d4d-9d7a-f1384dae2511n%40chromium.org.
Nicolás Peña Moreno
Rick Byers
Responding for Suresh since he's OOO this week. We have UKM metrics that tell us which IDPs would break today due to this change. We plan to document this change through our public devrel outreach and also reach out to IDPs that we detected through our metrics. While the number of sites that would break today due to this is relatively high, the number of IDPs is fairly small, so we are confident we can deploy once we know it would cause no breakage.
On Friday, October 17, 2025 at 1:04:59 PM UTC-4 mike...@chromium.org wrote:
On 10/17/25 10:41 a.m., suresh potti wrote:
Contact emails
sures...@microsoft.com Specification
https://github.com/w3c-fedid/FedCM/pull/760 Summary To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700.
Migration Plan Chrome will enforce this rule in two phases:
Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
Chrome 145 (Enforcement Phase): The requirement becomes mandatory. FedCM configurations missing these endpoints will be blocked, preventing authentication flows.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/27918dd1-04ae-4e90-9daf-22fb8f27b6f4n%40chromium.org.
Christian Biesinger
On Mon, Oct 20, 2025 at 2:19 PM 'Nicolás Peña Moreno' via blink-dev <blin...@chromium.org> wrote:Responding for Suresh since he's OOO this week. We have UKM metrics that tell us which IDPs would break today due to this change. We plan to document this change through our public devrel outreach and also reach out to IDPs that we detected through our metrics. While the number of sites that would break today due to this is relatively high, the number of IDPs is fairly small, so we are confident we can deploy once we know it would cause no breakage.Except we've now had at least one web compat incident due to a major RP who doesn't depend on an IDP-served SDK, right?
On Friday, October 17, 2025 at 1:04:59 PM UTC-4 mike...@chromium.org wrote:
On 10/17/25 10:41 a.m., suresh potti wrote:
Contact emails
sures...@microsoft.com Specification
https://github.com/w3c-fedid/FedCM/pull/760 Summary To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700.
Migration Plan Chrome will enforce this rule in two phases:
Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
Chrome 145 (Enforcement Phase): The requirement becomes mandatory. FedCM configurations missing these endpoints will be blocked, preventing authentication flows.
Does this apply to both passive mode and active mode? "Preventing authentication flows" for passive mode seems like a completely trivial severity of breakage since it just means an optional extra UI doesn't show up. But any breakage for active mode (where a user has just clicked on a "sign-in") button seems very serious. So if the latter, I think we'd want to see UseCounter data proving that the usage has been migrated before approving a breaking change.
Rick Byers
On Wed, Oct 22, 2025 at 11:28 AM Rick Byers <rby...@chromium.org> wrote:On Mon, Oct 20, 2025 at 2:19 PM 'Nicolás Peña Moreno' via blink-dev <blin...@chromium.org> wrote:Responding for Suresh since he's OOO this week. We have UKM metrics that tell us which IDPs would break today due to this change. We plan to document this change through our public devrel outreach and also reach out to IDPs that we detected through our metrics. While the number of sites that would break today due to this is relatively high, the number of IDPs is fairly small, so we are confident we can deploy once we know it would cause no breakage.Except we've now had at least one web compat incident due to a major RP who doesn't depend on an IDP-served SDK, right?This change does not depend on an SDK, it is purely server-side (requires certain fields in the well-known file)
On Friday, October 17, 2025 at 1:04:59 PM UTC-4 mike...@chromium.org wrote:
On 10/17/25 10:41 a.m., suresh potti wrote:
Contact emails
sures...@microsoft.com Specification
https://github.com/w3c-fedid/FedCM/pull/760 Summary To address cross-site identity correlation risks in the FedCM API, Identity Providers (IdPs) that utilize client_metadata within their FedCM configuration are required to implement the direct endpoints format in the .well-known/web-identity file. This mandate ensures that both accounts_endpoint and login_url are explicitly defined whenever a client_metadata_endpoint is present. This approach strengthens privacy protections by preventing relying parties from exploiting metadata to correlate user identities across multiple sites. For further details and discussion, refer to https://github.com/w3c-fedid/FedCM/issues/700.
Migration Plan Chrome will enforce this rule in two phases:
Chrome 143 (Warning Phase): If client_metadata_endpoint exists but accounts_endpoint or login_url is missing, the browser will display console warnings. This gives IdPs time to update configurations.
Chrome 145 (Enforcement Phase): The requirement becomes mandatory. FedCM configurations missing these endpoints will be blocked, preventing authentication flows.
Does this apply to both passive mode and active mode? "Preventing authentication flows" for passive mode seems like a completely trivial severity of breakage since it just means an optional extra UI doesn't show up. But any breakage for active mode (where a user has just clicked on a "sign-in") button seems very serious. So if the latter, I think we'd want to see UseCounter data proving that the usage has been migrated before approving a breaking change.It does apply to both, yeah.
Mike Taylor
On 10/17/25 10:41 a.m., suresh potti wrote:
Specification
I have a question about how this is specified - it seems like normative requirements (for all extensions) are captured as issues in the spec. I don't really know how to think about that, i.e., https://w3c-fedid.github.io/FedCM/#issue-81964997, https://w3c-fedid.github.io/FedCM/#idp-api-client-id-metadata-endpoint, etc.
How is that different than other more traditional issues (i.e., "there's a known problem we need to fix) like https://w3c-fedid.github.io/FedCM/#issue-7ded5c77? Is the plan to eventually promote those to normative text, or non-normative Notes (if all extensions are optional?)
I think I know what an extension is in this context (presumably some optional functionality), but it's also not defined anywhere.
Nicolás Peña Moreno
Mike Taylor
I see, thanks. Marking them as extensions totally makes sense, but doing that inside of spec Issues is perhaps confusing (and makes their normative status unclear, but they're all optional I guess?). That said, that's up to the WG and spec editor to solve, not me. :)
LGTM2
