TAG review request for the IDP signin status API

[cbiesinger]

Draft: TAG review request for the IDP SignIn status API

こんにちは TAG-さん!

I'm requesting a TAG review of the IDP SignIn status API (addition to the Federated Credential Management API).

This API provides a way to prevent RPs from silently making cross-site credentialed requests to IdPs using the FedCM API while minimizing user annoyance for users who are not logged in to the requested IDP. We call this problem the timing attack problem. In this proposal under review, specifically, when the user agent was not notified that the user is signed in to the IDP, no network request is made and so no UI has to be shown. Otherwise, whenever a credentialed request is made, UI is shown. This discourages use of the API for tracking. (Note, for Chrome’s implementation we allow a once-per-IDP potentially-silent request for bootstrapping purposes)

• Explainer¹ (minimally containing user needs and example code): https://github.com/fedidcg/FedCM/blob/83f30cccb3b48e66f2760030906e2853b124d9c8/proposals/idp-sign-in-status-api.md
• Specification URL: https://github.com/fedidcg/FedCM/pull/436
• Tests: TBD
• User research: n/a
• Security and Privacy self-review²: The original FedCM questionnaire is at https://github.com/fedidcg/FedCM/blob/main/privacy_questionnaire.md. This addition does not expose any new information to origins; it stores one additional per-IDP bit that is not readable with web APIs.
• GitHub repo (if you prefer feedback filed there): https://github.com/fedidcg/FedCM/issues
• Primary contacts (and their relationship to the specification):
  • Christian Biesinger (@cbiesinger), Google (Engineer designing and implementing the spec)
  • Sam Goto (@samuelgoto), Google (Engineer designing and implementing the spec)
• Organization(s)/project(s) driving the specification: Google Chrome
• Key pieces of existing multi-stakeholder review or discussion of this specification: Discussion in https://github.com/fedidcg/FedCM/pull/436
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5177628008382464

Further details:

• [X] I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: We’d like to ship this in Chrome 119, branching on Tue, Oct 3, 2023
• The group where the work on this specification is currently being done: https://github.com/fedidcg
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): Unknown
• Major unresolved issues with or opposition to this specification: We are still working on the relationship to the Login Status API aka isLoggedIn (https://github.com/privacycg/is-logged-in). We are planning to use an API that integrates seamlessly with that API as described in https://github.com/privacycg/is-logged-in/pull/54
• This work is being funded by: Google LLC

You should also know that...

https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM_%20Options%20for%20the%20Timing%20Attack%20Problem%202022-08-31.pdf contains a lot of background reading

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[cbiesinger]

I should have mentioned in the initial request:

We (Chrome) think that this proposal in combination with measuring user metrics is sufficient to address the timing attack. We are tracking per-RP and per-IDP metrics to detect abusive IDPs; combined with this proposal (which shows a dialog when a credentialed requested was made) solves the silent timing attack problem and makes the "loud" timing attack impractical.

We understand that other browsers have different privacy tradeoffs and have (tried to) write the spec such that they can gate FedCM requests on user interaction before credentialed requests are sent.

[torgo]

Hi @cbiesinger : a few questions came up in our discussion today on this one:

1. Our understanding is that this is designed to prevent an IDP from tracking users. However, the mechanism provided allows the IDP to optionally signal the signed in status of the user to the UA. Couldn't an IDP that wants to track users simply not send the signed-out signal and thus still get the silent requests?

2. Regarding multi-stakeholder support, we see from ChromeStatus that Firefox is listed as "under consideration" - however I don't actually see a Mozilla standards position on this - is there one? Is there a webkit standards position?

3. What is the general status of FedCM from an implementation stand-point? What is the multi-stakeholder story with FedCM right now and when do we expect to achieve "critical mass" for FedCM? This is especially relevant to the discussion on deprecation of third party cookies, as federated sign-in is often cited as a use case supported by third party cookies.

4. Small addition question - you've reference a PR against is-logged-in in your explainer - however the is-logged-in API itself seems to not be very active – and we haven't been asked to review it. Can you shed some light on the status of this API?

[cbiesinger]

1. Yes, an IDP could decide not to send the signed-out signal, however this would not give them silent requests, the browser would show a "mismatch" dialog. See the "If the sign-in state was “signed in" bullet point in https://github.com/fedidcg/FedCM/blob/main/proposals/idp-sign-in-status-api.md#effect-on-fedcm-requests. We think this dialog will encourage IDPs to send the signed-out signal, but again, even if they do not this is not silent and it's also a onetime thing (we set the status to signed-out in this situation)

2. I just filed https://github.com/WebKit/standards-positions/issues/250. We had informal conversations with Mozilla and they seem supportive; they prefer commenting on PRs instead of standards positions for changes to FedCM. We want to continue these conversations at TPAC.

3. Firefox is prototyping FedCM, current work behind a pref (dom.security.credentialmanagement.identity.enabled). Safari is “generally supportive”. Brave also seems supportive towards a “more promising future”.

4. We are hoping to make some progress on this during TPAC and had discussions in the Privacy CG; we are in the somewhat unfortunate position that we are trying to not ship something that is similar to but incompatible with is-logged-in, but at the same time is-logged-in is not ready. Hence, we are trying to specify something that is likely compatible with that API, should it end up shipping.

[cbiesinger]

FYI we're making some minor naming changes in https://github.com/fedidcg/FedCM/pull/505/files

[rhiaro]

Hi there, we were just getting back to this, and we've lost track of the explainer as the current link is a 404. Are we right in thinking the name of the feature has changed to Login Status API? We can see a few linked issues and PRs, but none of them are clearly an explainer for this feature, as well as this explainer in the privacy cg for a feature with the same name, although I don't think this is recent. Can you clarify what we should be looking at at this point? Thanks.

[cbiesinger]

Sorry about that, you can use https://github.com/fedidcg/FedCM/blob/83f30cccb3b48e66f2760030906e2853b124d9c8/proposals/idp-sign-in-status-api.md

We were aiming at producing an API that can also satisfy the goals of the privacycg proposal; however, our proposal is more mature (Chrome is now shipping it). See also https://github.com/privacycg/is-logged-in/issues/53#issuecomment-1747670589 and https://github.com/fedidcg/login-status which more directly integrates the privacycg proposal and other extensions.

[plinss]

Hi @cbiesinger, we discussed this on our call today; we're happy with the direction the work is going, so we're closing this review. Thanks for flying TAG.