Intent to Experiment: FedCM Sign-in Status API

300 views
Skip to first unread message

Christian Biesinger

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

Contact emails

cbies...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md


Specification

https://github.com/fedidcg/FedCM/pull/436


Summary


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

Blink>Identity>FedCM


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

Pending


Risks



Interoperability and Compatibility


Gecko: Under consideration (https://github.com/fedidcg/FedCM/pull/436). 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:


Ergonomics

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



Debuggability

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)?

No

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 https://crbug.com/1451884). 


DevTrial instructions

https://github.com/fedidcg/FedCM/blob/main/explorations/HOWTO-chrome.md#idp-sign-in-status-api


Flag name

FedCM - FedCM enabled with FedCM IDP sign-in status

chrome://flags/#fedcm


Requires code in //chrome?

False


Estimated milestones

OriginTrial desktop last

119

OriginTrial desktop first

116

DevTrial on desktop

115






Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5177628008382464


Links to previous Intent discussions


Mike Taylor

unread,
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 blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XHJ-LMsCa-PMf1Ft51DCJK1dkzRrFZmRZuzL_Qe2WK2iA%40mail.gmail.com.

Christian Biesinger

unread,
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?

Thanks!
Christian

Christian Biesinger

unread,
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

unread,
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.

Christian

On Fri, Jun 9, 2023 at 10:00 AM Mike Taylor <mike...@chromium.org> wrote:

Mike Taylor

unread,
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
Forward
0 new messages