Re: [whatwg/fetch] Allow Origin and Access-Control-Allow-Origin to have multiple values (Issue #1790)

> I don't understand how this setup works with third-party cookie deprecation.

Just to clarify, site1.com, site2.com, and auth.com set cookies for themselves through redirects. There is no iap.com in the view of the browser, since it is only used for resolution. There was a small error in the first flow diagram, which I fixed to clear it up. 

The flow that is problematic with third-party cookie deprecation is when Site 1 makes a CORS request to Site 2, requiring a third party cookie. This likely works currently because of a few reasons:
- IAP is used in enterprises for internal resource access, where there are limited second level domains. Most CORS requests likely occur within the eTLD+1 domain space, and hence not considered third-party cookies (eg: app.xyz.com -> api.xyz.com -> auth.xyz.com). 

-   Browsers that have “tracking prevention policy” block third-party cookies only when set in third-party contexts without user intent, which is not the case with the workaround where the user accesses Site B first and then Site A. The other two workarounds don’t have the third party cookie problem. 

-  As documented [here](https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/#allow-third-party-cookies-in-the-browser), enterprises probably add exceptions to this since they’d typically manage browser settings through MDMs. 

While the last two measures won’t help in the long term, and IAP architectures may need to evolve as the new PrivacyCG standards mature, the core issue remains: Browsers cannot properly follow redirects during a CORS request without forcing applications to rely on a wildcard Access-Control-Allow-Origin.  

As mentioned above, this limitation even restricts credentialed redirects between subdomains within an eTLD+1 domain, which third-party cookie deprecation does not affect. 

> Provided it somehow works, we can't change how Origin works without opt-in. The original RFC has long been considered obsolete. (There's a desire to allow multiple values for Access-Control-Allow-Origin, but that would mainly be as a cache benefit and would not help with this case. I think if we decided to pursue this case we'd use a space-separated value, not comma-separated.)

This is reasonable. Does my suggestion in the initial description help as an opt-in strategy: Add another parameter to fetch redirect “fetch_cors”? Setting this would cause the browser to create Multiple Origins for the request upstream and since this is always going to be in a cross origin context, the server should be aware of the multiple origins, else it won’t set the appropriate Access-Control-Allow-Origin headers causing failure.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1790#issuecomment-2540104861
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1790/2540104861@github.com>