Intent to Experiment: FedCM Sign-in Status API

Skip to first unread message

Christian Biesinger

Jun 8, 2023, 5:39:15 PM6/8/23
to blink-dev

Contact emails




This origin trial is intended to cover the IdP Sign-in Status API, which is our proposal to address the last remaining privacy leak of FedCM before we feel comfortable enabling it without third party cookies: The Timing Attack Problem (issue, presentation).

The Timing Attack Problem is an attack that a tracker can perform by using the FedCM API in such a way that allows them to track users invisibly. The attack works by correlating the time between credentialed and uncredentialed requests and abusing the API to prevent it from being observed by users.

While we explored many variations and options (presentation), in this proposal, the IdP Sign-in Status API allows an Identity Provider to signal to the browser when their users are logging in and logging out (in a top level frame). 

This signal allows the FedCM API to (a) avoid making any credential requests when the user is logged out of the IdP (and hence, fully mitigate timing correlations) an (b) provide a guarantee that every credentialed request it makes will have a user-visible outcome (e.g. an account chooser or a dialog to sign in to the IdP) given that the assumption is that the user is logged in.

We believe this will make the Timing Attack economically impractical (e.g. it requires the user to (a) have logged-in to the attacker in a top level frame as well as to (b) be recognized as an IdP in the account chooser), and in doing so enables FedCM to operate when third party cookies are blocked.

Blink component


TAG review

We have an open spec PR that is currently under review, and in that process, Firefox suggested that we reframe the API in terms of the Login Status API which Chrome/Firefox/Safari seem to be in directional agreement. We are planning to kick-off our TAG review once this settles a bit more into concrete spec terms while we are running the origin trial but before we send our I2S.

TAG review status



Interoperability and Compatibility

Gecko: Under consideration ( Firefox raised early on the Timing Attack Problem and possible ways we can address it. The IdP Sign-in Status API is intended as a signal that the user agent can use to mitigate the Silent Timing Attacks which are executed through correlating the time between credentialed and uncredentialed requests without the user’s knowledge. The API sufficiently mitigates the problem for Chrome by showing a prompt (e.g. account chooser or dialog to sign in to the IdP) every time it makes a credentialed request within the FedCM API. We are working with Firefox to write the spec in such a way that different user agents can have the flexibility to make different trade-offs in terms of how often to prompt users.


WebKit: No signal. Safari has so far shown overall support for FedCM, but haven't yet formed a position on this specific extension of FedCM. We are generally in agreement of the API shape using the Login Status API, but we haven't yet gotten signals from them on how FedCM, specifically, is going to be using this signal. We are planning to send a webkit standards position after we resolve this and before we I2S. 

Web developers: Positive We have been working with the FedID CG to develop this API and running experiments with the Google Identity Services team.

Other signals:


This is an API that is designed to be used by identity providers, when their users login in to their websites. We exposed an HTTP header, since we heard from them that logins are often made through 302 redirects. There is also a JS API that is equivalent to the HTTP headers.

WebView application risks

FedCM is not currently supported on WebView, so no change or risk to Android WebViews.

Goals for experimentation

The main goal for the experiment is to gather data on the user interfaces that we introduced with this API. We introduce, specifically, a dialog which allows users to open a pop-up window to login to their IdP whenever there is a mismatch between the signal we have in the IdP Sign-in Status API and what the IdP server returns that we’d like to feel confident about how it performs with users.

We have run enough devtrials in preparation for this origin trial that we have learned enough about ergonomics for Identity Providers and Relying Parties.

Ongoing technical constraints


The presence of the HTTP header can be checked in the network panel in devtools and the JS API calls can be debugged as usual.

When we don’t send a network request due the user being logged out or if we detect a mismatch, we are planning to add a console message in bug 1453353

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?


We are intending to start our origin trials on desktop-only and extend to mobile during the origin trial (possibly in M117).

Is this feature fully tested by web-platform-tests?

Not currently: we are working on it (blocked by 

DevTrial instructions

Flag name

FedCM - FedCM enabled with FedCM IDP sign-in status


Requires code in //chrome?


Estimated milestones

OriginTrial desktop last


OriginTrial desktop first


DevTrial on desktop


Link to entry on the Chrome Platform Status

Links to previous Intent discussions

Mike Taylor

Jun 9, 2023, 10:00:09 AM6/9/23
to Christian Biesinger, blink-dev

LGTM to experiment from M116 to M119 inclusive.

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
To view this discussion on the web visit

Christian Biesinger

Jul 5, 2023, 3:43:55 PM7/5/23
to Mike Taylor, Mathias Bynens, Vladimir Nechaev, blink-dev
(+mathiasb, and since he's OOO also adding Vladimir)

We would also like to add a small webdriver extension for this feature and I am unsure how to proceed with that in the new process.

What I would like to do:
- Add a vendor-prefixed webdriver command nowish (while we do the origin trial)
- Make it non-prefixed when we ship this API

What is the process for this? Should I send a separate I2P (or I2E...?) for the commands? And for shipping (unprefixing) later on, should I send an I2S just for the webdriver part or will that be covered by the I2S for the API itself?


Christian Biesinger

Jul 19, 2023, 11:35:53 AM7/19/23
to Mike Taylor, Mathias Bynens, Vladimir Nechaev, blink-api-owners-discuss, blink-dev
ping? also +blink-api-owners-discuss to clarify the process

Christian Biesinger

Aug 1, 2023, 1:25:28 PM8/1/23
to Mike Taylor, blink-dev
FYI, we are extending this origin trial to Android (excluding webview) in Chrome 117. I understand we do not need a new LGTM for that.


On Fri, Jun 9, 2023 at 10:00 AM Mike Taylor <> wrote:

Mike Taylor

Aug 1, 2023, 1:30:52 PM8/1/23
to Christian Biesinger, blink-dev

Yep, sounds good. Thanks for the heads up!

Reply all
Reply to author
0 new messages