I have a situation involving integration between two partner enterprise software vendors that is broken by deprecation of 3rd-party cookies. Please bare with me, because this takes quite a while to set the scene and explain the problem.

Setting the Scene

Let's call the two vendors/sites "A" and "B". "A" is the "host" vendor into which "B"'s product is integrated as 3rd-party IFrame content.

Vendor "A" provides the authentication for users, and "B" is configured to redirect to an authentication URL from vendor "A", which then redirects back to "B" with verified user info/tokens/etc. Although "A" does maintain the (first-party) cookies related to authentication, "B" still needs to setup its own session cookies (3rd party, because embedded in a 3rd-party IFrame) after authenticating via "A".

Just to be clear: the intent here is only for "B" to consistently have access to its own cookies within the context of being embedded in "A". There is no intent, attempt, or desire to have access to any cross-site tracking 3rd-party cookies. If site "B" is accessed either as a 1st-party top-level site, or embedded in some other partner site "X", then we explicitly do NOT want to have access to the same cookies or user session across all of those contexts.

So the solution seems obvious: CHIPS! If "B" simply flags all of its cookies as Partitioned, then we should get exactly the behavior we want.

The Problem

However, there is one use case that fails: On some pages in the embedded 3rd-party content from vendor "B", clicking on certain UX controls (links, menu items, etc) will open a page from "B"'s site in a new tab or window. The current behavior of CHIPS is that this new tab/window is a brand new top-level first-party context. So the page from "B" in that new tab/window does not have access to the same partitioned session cookies that were setup by the 3rd-party embedded IFrame of "B' inside of "A".

The resulting behavior is, depending on specifics of how the authentication integration is configured between "A" and "B", either:

1. The content of the new tab/window simply displays a "not logged in" error page because there are no top-level 1st-party session cookies setup for "B".
2. The new tab/window redirects to the authentication URL from site "A" because there are no top-level 1st-party session cookies setup for "B". There ARE top-level 1st-party authentication cookies for site "A", so it immediately redirects to site "B" with the verified user info/tokens, and site "B" sets up a NEW session for the user (new session ID, new top-level 1st-party session cookies).

Behavior 1 is clearly bad/broken.

Behavior 2 appears good on the surface, except is is broken in the worst way: subtly. The server for site "B" is a stateful server that maintains session state, including cached calculated results, state of user workflow, etc.. So the new tab/window opened by "B" needs to share the same session to ensure that all side-effects of any user actions performed in the new tab/window are also applied to the session used by the "main" view of site "B" in the 3rd-party IFrame embedded in "A". Very strange, seemingly intermittent, and unpredictable bugs can occur if the same user is logged in twice under different sessions and actively going back and forth between the two sessions, performing operations, and expecting both sessions to stay in sync with each other.

Firefox

It's worth noting that our integration of sites "A" and "B" works perfectly fine in Firefox with its "Enhanced Tracking Protection" set to "Strict" such that it automatically partitions 3rd-party cookies.

A Proposed Solution

If site "B" could open a new tab/window in a way that it "inherits" the 3rd-party cookie partitioning context of its opener, then everythign would work as we desire. The new tab/window would have the same user session in site "B" as the embedded 3rd-party iframe of site "B" that opened it.

I understand there may be security concerns with this, and I understand why the default behavior should be to NOT inherit the cookie partitioning context of the opener. I'm also not an expert on security issues/attacks involving new tabs/windows, but I think it may be reasonably manageable with some simple rules:

A new tab/window will inherit the cookie partitioning context of its owner if and only if both conditions are met:

1. The opener explicitly requested that the new window/tab inherit the cookie partitioning context (e.g., via some new parameter in the windowFeatures argument to the window.open function).
2. The URL being opened into the new tab/window is from the same site as the opener (may be a different subdomain on the same site).

Alternative Solutions Considered

1. Related Website Sets: This is not appropriate for this situation because "A" and "B" are completely different independent companies with no relationship to each other except a partnership deal to integrate their products together. Related Website Sets is for a set of related sites all owned by the same person/company.
2. Storage Access API: This is not appropriate because we are NOT attempting to access a single user session of site "B" across multiple 3rd-party embeds as widgets in multiple different embedding "host" sites. We specifically want the cookies to be partitioned by each 3rd-part embed context, and also separate from a top-level 1st-party access to site "B". Even if used as a hacky workaround, it would both introduce architectural/implementation complexity to site "B" to properly implement Storage Access API, and the placeholder pages that require the user to click on something to request access would completely break the presentation of the integration. There are other issues, like some browsers requireing that the user had somewhat recently visited the embedded site as a tope-level first party site in order to grant access. With the "A"/"B" integration , a user would NEVER directly visit site "B". All access to site "B" would be through embedded 3rd-party iframes in site "A". The intent is for "B" to be tightly integrated into "A" such that it appears as a single cohesive application, and we have gone to great lengths to ensure that it is marketed and presented in every way possible such that users are not even really aware that it is an embedded 3rd-party integration.
3. Don't embed "B" in "A" at all. Instead, configure "A" to launch "B" in a new tab/window so that "B" is in a top-level first-party context, and any new tabs/windows opened by "B" will have access to those same tip-level first-party cookies. This is not acceptable at all (see 2 above where I explain the tight integration).
4. Rework web app "B" so that it never opens a page in a new tab/window: This is really the last resort. It won't be easy. It won't be good UX. There's good reason that "B" opens some pages in a new window. It may be a complex screen where the user can perform complex operations, but they also need to be able to simultaneously look back at the opener page for reference, and common use cases may be to have both the opener window and the new window arranged on one or two monitors side-by-side for simultaneous viewing of both. Making changes in the new window communicates changes back to the opener to keep the two in sync, and it is important to be able to review the summarized representation of data in the opener window as changes are made in the new window.

Reproducing/Demonstrating The Problem

Due to the nature of enterprise software, and the fact that we have currently opted out of 3rd-party cookie deprecation and have enrolled into the grace period, it will be a challenge to present a workign example of this problem. With some coordination, it would be possible to temporarily set up one of our test accounts to demonstrate this problem and share private URL and login info. Please let me know if you'd like to coordinate something.