User cookie should not be sent to the IDP before explicit consent is gathered

[bvandersloot-mozilla]

In the create-credential algorithm, the user sends their cookie to the IDP during Step 2, when the user fetches their account list. This is before any user consent is gathered.

In the most clear attack the IDP operates an independent API for each RP and can then tell by the URL of the request which RP it is associated with. This discloses a (IDP user id, RP) pair to the IDP.

More subtly, the IDP has tuples of (user id, time, client IP address). This can be joined with tuples from the RPs (RP, time, client IP address), to disclose (IDP user id, RP) pairs to the IDP.

[dj2]

How do you see the API per RP working? The API comes from the fedcm.json file which is served without credentials and without client_id or referrer information. How does the IDP provide differing RP information to FedCM?

The second point is an issue we need to work throught.

[samuelgoto]

In the most clear attack the IDP operates an independent API for each RP and can then tell by the URL of the request which RP it is associated with. This discloses a (IDP user id, RP) pair to the IDP.

Is it fair for me to assume that this specific attack vector is more or less isomorphic to this?

More subtly, the IDP has tuples of (user id, time, client IP address). This can be joined with tuples from the RPs (RP, time, client IP address), to disclose (IDP user id, RP) pairs to the IDP.

Yeah, that's certainly a massive problem that we are dealing with right now. We are trying to make an assessment of the options we have here as well as the feasibility of this attack vector at scale.

There were two options that occurred to us (none of them are great):

The Push Vs Pull

One option that occurred to us was what we've been calling "The Push vs Pull" models. What we have in the spec right now is what we call the "Pull" model, because it "pulls the accounts on demand". The "Push" model, on the other hand, allows an IDP to "push accounts beforehand", such that, in the moment that they are needed, they are pulled from a cache, rather than a server. e.g.:

FederatedCredential.registerAccount({
  "name": ...,
  "email": ...,
  "picture": ...
});

We believe the "push model" would deal with the timing attack, but we heard from IDPs that it makes the integration and maintenance of the system much much harder, so not something that we wanted to start from.

But yeah, agreed on the attack vector and that our "Pull model" design right now is not resilient to it.

IDP Registration

The other option that occurred to us was to have the IDP register their endpoints at some point, e.g.:

// This gets used across all RPs:
FederatedCredential.registerIDP("https://idp.example");

[bvandersloot-mozilla]

How do you see the API per RP working? The API comes from the fedcm.json file which is served without credentials and without client_id or referrer information. How does the IDP provide differing RP information to FedCM?

I see it working similar to Sam's comment in #230. It could even be simpler. An IDP could tell each RP to use a different endpoint. So RP A would have provider URL https://idp.example/RP-A/ and RP B would have provider URL https://idp.example/RP-B/.

[bvandersloot-mozilla]

In the most clear attack the IDP operates an independent API for each RP and can then tell by the URL of the request which RP it is associated with. This discloses a (IDP user id, RP) pair to the IDP.

Is it fair for me to assume that this specific attack vector is more or less isomorphic to this?

Yep!

[npm1]

This has been discussed quite a bit. Chrome has been working on various heuristics to mitigate privacy attacks that could result from IDPs attempting to track the user via FedCM. In addition, the user agent can choose a two-click model where the user needs to first tap into the IDP name in order to gain access to the list of accounts. Finally, as mentioned above we are working towards a push model so that we can move all pull-model interactions to use the privacy-preserving two-click model while still enabling IDPs that wish one-click to enable it via the push model.

[cbiesinger]

Chrome's proposal to fix this is the IDP sign-in status API. I have split that out into issue #447 and the pull request linked there.

[tttzach]

With the IDP login status API #447 and the affordance detailed in the spec for the user agent to be able to present UX before network requests, this issue can be solved. Closing this for now, feel free to re-open if needed.