Back in #4966 we introduced "top-level origin" as a field of environments. The setup is roughly:

• For window environment settings objects: this is clearly well-defined, and is often used, e.g. for showPicker() or COOP protections.
• For dedicated workers or worklets: it is set to the top-level origin of its creator. It does not appear to be used for them, yet.
• For shared workers and service workers: it is set to an implementation-defined value, meant to represent the outcome of whatever we do with storage partitioning. It does not appear to be used for them, yet.

As storage partitioning gets more concrete, I think this setup is not going to work out. Since we plan to partition primarily on top-level site, it will be possible for any "shared" resource to have multiple top-level values that are important. That is, if a.example.com and b.example.com both embed example.org, which itself creates a shared worker or service worker, then both a.example.com and b.example.com are arguably the "top level origin" for that shared or service worker. And, because dedicated workers can be nested inside shared workers, the same problem occurs for them.

I think instead we should:

• Move "top-level origin" to Window, similar to Remove "responsible document" concept #7694, since there is only a single unambiguous top-level origin for windows. (I guess we could also do it for worklets, but so far it isn't needed.) This can be used by a variety of things, e.g. COOP checks.

• Create a "top-level site" field on environments, which we can populate unambiguously for shared, service, and dedicated workers.

/cc @wanderview @annevk