Allow sending SameSite=Lax cookies for certain POST requests

[cbiesinger]

(context: w3c-fedid/FedCM#587)

While SameSite behavior seems to be specified in the fetch spec now, I wanted to keep this group updated on this proposal:

For credentialed FedCM requests (using Sec-Fetch-Dest: webidentity), we would like to send SameSite=Lax cookies in addition to SameSite=Strict, including the post-user confirmation POST request.

Motivation

Currently, many identity providers implement signing in to a website using redirects (from the relying party to the identity provider, and after user confirmation back to the relying party with a signed token).

Because this is using toplevel redirects, these sites can and often do use SameSite=Lax cookies for this purpose. This increases security over SameSite=None because they will not get send for any other cross-site requests such as subresource requests.

However, as currently specified and implemented, this makes it impossible to migrate to FedCM. FedCM provides various desirable privacy properties and a better user experience, so it would be desirable to allow this so that more identity providers can adopt FedCM without lowering their cookie security properties.

Why this is safe

FedCM requires "opt in" by having a file at the eTLD+1 at /.well-known/web-identity with the correct content.

Requests to this file are made without credentials. If this file does not exist, or does not have the correct content, browsers abort the request and do not send any further credentialed FedCM requests for this flow.

Therefore, the scope of this change is very limited: Only servers who have specifically opted in to FedCM on their eTLD+1 will see any changes to the sent cookies. (and of course, from a caller perspective this only affects requests made due to a navigator.credentials.get() call for an identity credential).

By eTLD+1 I specifically mean https://example.tld; https://accounts.example.tld/ is not sufficient, although we do follow redirects for this specific file.

Note: FedCM is currently implemented in Blink (i.e. Chrome/Edge/other derived browsers). Firefox has prototyped an implementation but is not currently pursuing shipping FedCM.

Please share any feedback you may have on this proposal.

[johannhof]

From my perspective I think this is a good idea - it actually improves security in practice by allowing servers to avoid setting their cookies to SameSite=None (making all their endpoints potentially vulnerable to CSRF) to make FedCM work.

It comes with the slight compromise of adding a precedent for extending SameSite=Lax to cover new functionality. While it's safe in this instance, I think we should be very explicit that this is NOT meant as an invitation for others to revisit SameSite rules and that future attempts to change SameSite should be viewed with the same level of scrutiny as before.

[sbingler]

To be clear: you're proposing that SameSite=Strict and SameSite=Lax cookies for the IdP's server will be sent cross-site during, and only during, a valid FedCM login flow; thus allowing the IdP server to avoid having to store its state in SameSite=None cookies?

I agree with Johann, this seems reasonable (even if it does complicate the story of when SameSite cookies get sent).

I think we should be very explicit that this is NOT meant as an invitation for others to revisit SameSite rules and that future attempts to change SameSite should be viewed with the same level of scrutiny as before.

I strongly agree

[cbiesinger]

To be clear: you're proposing that SameSite=Strict and SameSite=Lax cookies for the IdP's server will be sent cross-site during, and only during, a valid FedCM login flow; thus allowing the IdP server to avoid having to store its state in SameSite=None cookies?

Yes that's correct, a better summary than I was able to write!