> Also, there is no way to know which related site the user is logged in to, so they would have to prompt for every one of their sites.
This is not how it works. The mechanism is about allowing a cluster of websites to choose a single first party domain and have all of them share cookies together, not sharing arbitrary cookie from arbitrary domain, otherwise it would create loopholes in connected components that bring back the downsides of third-party cookies. What you mentioned should be done using SSO.
After thinking about it a bit more, I have a clearer picture of how it should work in my mind:
* All cookies are double-keyed: the primary key is the origin of the top-level page and the secondary key is the origin of the page that sets the cookie, just like how partitioned cookies work right now.
* stackoverflow.com uses a header, meta tag or script to request changing its primary key domain to “stackexchange.com”
* The browser makes a request to https://stackexchange.com/domains.txt and make sure that “stackoverflow.com” is in the list, authorising this first-party domain change
* When the user agrees to the change, the page is reloaded with stackexchange.com as the primary key, thus stackoverflow.com can obtain login details from stackexchange.com via CORS or cross site cookies.
* A side effect is that all cookies and state are lost when switching the first-party domain. Should stackoverflow.com be acquired by a new owner, say x.com and changes its first-party domain to x.com, all cookies on stackoverflow.com are lost and the user will have to login on x.com again, maybe using credentials from stackexchange.com. It’s unfortunate but it works around the issues mentioned in the post in a clean way, avoiding loopholes that transfer cookies by switching the first-party domain frequently.
This is not how it works. The mechanism is about allowing a cluster of websites to choose a single first party domain and have all of them share cookies together, not sharing arbitrary cookie from arbitrary domain, otherwise it would create loopholes in connected components that bring back the downsides of third-party cookies. What you mentioned should be done using SSO.
After thinking about it a bit more, I have a clearer picture of how it should work in my mind:
* All cookies are double-keyed: the primary key is the origin of the top-level page and the secondary key is the origin of the page that sets the cookie, just like how partitioned cookies work right now.
* stackoverflow.com uses a header, meta tag or script to request changing its primary key domain to “stackexchange.com”
* The browser makes a request to https://stackexchange.com/domains.txt and make sure that “stackoverflow.com” is in the list, authorising this first-party domain change
* When the user agrees to the change, the page is reloaded with stackexchange.com as the primary key, thus stackoverflow.com can obtain login details from stackexchange.com via CORS or cross site cookies.
* A side effect is that all cookies and state are lost when switching the first-party domain. Should stackoverflow.com be acquired by a new owner, say x.com and changes its first-party domain to x.com, all cookies on stackoverflow.com are lost and the user will have to login on x.com again, maybe using credentials from stackexchange.com. It’s unfortunate but it works around the issues mentioned in the post in a clean way, avoiding loopholes that transfer cookies by switching the first-party domain frequently.