What cookies are passed in the Sign In API call?

[dickhardt]

https://fedidcg.github.io/FedCM/#browser-api-rp-sign-in
9.3.1

In the POST to the IdP to mint an ID Token -- which cookies are being passed? Some IdPs that use 1P cookies lock down the cookies with sameSite -- will the browser send any cookies that would be sent in a 1P call to the IdP with the POST?

[ritou]

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

To achieve seamless identity federation in a world where 3rd party cookies do not exist, I believe that cookies handled only by 1st party should be sent.

This Issue seems to point out this problem.
#212

[samuelgoto]

We are still investigating our implementation, but I believe this is the case:

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

SameSite=None seems overly permissive to me, because FedCM isolates sites enough prior to user interaction (e.g. keeps the IDP blind to the RP and vice versa), that I'm thinking that something along the lines of SameSite=Federated (or just a Federated attribute to cookies) more accurately labels it (rather than push IDPs to use SameSite=None).

[johannhof]

SameSite=None seems overly permissive to me, because FedCM isolates sites enough prior to user interaction (e.g. keeps the IDP blind to the RP and vice versa), that I'm thinking that something along the lines of SameSite=Federated (or just a Federated attribute to cookies) more accurately labels it (rather than push IDPs to use SameSite=None).

Note that per my understanding, we can't add new SameSite values because old browsers aren't handling that well. A new attribute might work technically, but I'm not sure what is too permissive about SameSite=None that would be fixed with Federated, are there additional security considerations here, since the two should be equivalent for privacy?

We're having an extended discussion in PrivacyCG around how to make SameSite work in edge cases with 3rd party cookie blocking that might be worth following as well (updates probably appear on privacycg/meetings#19)

[samuelgoto]

@cbiesinger found recently some resolution here for this question:

In the POST to the IdP to mint an ID Token -- which cookies are being passed? Some IdPs that use 1P cookies lock down the cookies with sameSite -- will the browser send any cookies that would be sent in a 1P call to the IdP with the POST?

Yes.

Because the prompt is mediated by the browser (and keeps the guarantees of separating the RP from the IDP up until the user consents), the browser will send the cookies to the IDP as if it were loaded in a first party context (e.g. ignoring the SameSite, because it is being used in a first party context).

At this time (2022/4/17) Chrome Canary appears to only send SameSite=None cookies for accounts _list_endpoint / id_token_endpoint.

That's correct.

With @cbiesinger 's resolution, we'll treat this behavior as a bug and fix it in the next few weeks.

Resolving this with this resolution, feel free to re-open if this doesn't work for you.