What will happen to SameSite: None and how should we go about it?

[samuelgoto]

This was an email that we got from @bc-pi. I'm trying to capture this email thread into a github issue so that it is easier to track and make sure it doesn't fall through the cracks

From @bc-pi:

In identity protocols, a cross-site navigation resulting in a POST request is typically happens by the first site returning an HTML page that has a form that is auto-submitted via javascript to the second site. That's how SAML Post binding works. And so does the OIDC/OAuth form post response mode.

(As best I understand it anyway) a previously set cookie with SameSite=None will be sent by the browser on such a top-level cross-site POST request. Some folks have suggested that that will change with 3rd party cookies going away and that even a SameSite=None cookie will no longer be sent in that situation. But in my mental model of this stuff, the situation will be unchanged by 3rd party cookies going away - it's a cross-site request but because it is a top-level navigation the cookies are 1st party. SameSite enforcement is in place so SameSite=None cookies will be sent. But it's not 3rd party so is not impacted by disappearance or partitioning of 3rd party cookies.

Anyway, that's what I'm hoping Sam can provide clarification on. Mostly for the benefit of my own understanding but also for the benefit of the group here as recent discussions have suggested that folks have divergent understanding and expectations of things.

That behaviour changing would be problematic, for example and as others have pointed out, because OIDC RPs receiving an ID token via the form post response mode need the 'nonce cookie' value (which ties the ID token to the browser the SSO flow was initiated on) at that point in validating the token. Maybe further confusing things is that at least in Chrome there was a temporary(?) exception made for the nonce cookie case with the rollout of the SameSite default change to Lax - the "Lax + POST mitigation" section at https://www.chromium.org/updates/same-site/faq and it looks like there's an attempt to capture that in the coming update to RFC 6265 https://github.com/httpwg/http-extensions/pull/1435/files

[bvandersloot-mozilla]

But in my mental model of this stuff, the situation will be unchanged by 3rd party cookies going away - it's a cross-site request but because it is a top-level navigation the cookies are 1st party.

Do you mean because a new window is opened with a new first-party context that is the IDP that that window then will send all of its cookies because it is a first-party connection? If so, I agree. And that leaves no issue with this change?

The Lax+POST mitigation was created as SameSite=Lax became the default, fixing breakage that appeared when a bunch of cookies that didn't have a SameSite property set started being treated as Lax instead of None. So if a cookie is explicitly None, that space shouldn't be a concern (I think).

This raises a question in my mind, and I'm curious if there has been discussion on it (searching issues shows nothing). Are the connections made to the IDP by the User Agent made in the browsing context of the IDP or RP? This is very important with state partitioning and/or third-party cookie removal.

[bc-pi]

@bvandersloot-mozilla the email was from last May and I was looking for clarification/confirmation that Chrome's deprecation of 3rd party cookies would not change SameSite treatment for top-level navigation in the same window.

[johannhof]

Note that the Privacy CG has started discussing/investigating how SameSite should interact with 3rd party cookies, see privacycg/meetings#19 and minutes at https://github.com/privacycg/meetings/blob/main/2022/telcons/05-12-minutes.md. This could help inform what happens for FedCM

[cbiesinger]

The current behavior is that we only send SameSite=None cookies in credentialed fetches. #587 is discussing whether to relax this to also send SameSite=Lax.

However, this is not clear in the spec, and actually that contradicts the last paragraph in https://fedidcg.github.io/FedCM/#browser-api. Keeping this open so that @npm1 can address this.

[bc-pi]

On a related question over in w3ccommunity.slack.com @johannhof provided the following useful info/pointers indicating that SameSite=None cookies will continue to be sent in top-level cross-site requests.

Yup, those cookies are fine. We wrote up all the details of how 3PC blocking should actually work in browsers at https://github.com/explainers-by-googlers/standardizing-cross-site-cookie-semantics, lacking a proper specification right now (which we're also working on) (edited)

See https://github.com/explainers-by-googlers/standardizing-cross-site-cookie-semantics?tab=readme-ov-file#top-level-cross-site-post-requests for top-level cross-site POST requests

[samuelgoto]

I think these pointers resolve the original question in this issue here, which was asking for clarification on how SameSite=None is going to work post 3PCD, which hopefully @johannhof 's pointers address in #212 (comment).

Feel free to reopen if there are still open questions.

[bc-pi]

Thanks @samuelgoto, I agree that the original question was answered and closing this issue is appropriate. I was honestly pretty surprised to learn it was still open two years later:)