diff --git a/files/en-us/web/api/document/hasstorageaccess/index.md b/files/en-us/web/api/document/hasstorageaccess/index.md
index 3ac71359508e0c3..c9259cad9519126 100644
--- a/files/en-us/web/api/document/hasstorageaccess/index.md
+++ b/files/en-us/web/api/document/hasstorageaccess/index.md
@@ -8,7 +8,7 @@ browser-compat: api.Document.hasStorageAccess
 
 {{APIRef("Storage Access API")}}
 
-The **`hasStorageAccess()`** method of the {{domxref("Document")}} interface returns a {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to unpartitioned cookies.
+The **`hasStorageAccess()`** method of the {{domxref("Document")}} interface returns a {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to [third-party](/en-US/docs/Web/HTTP/Cookies#third-party_cookies), [unpartitioned](/en-US/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) cookies.
 
 This method is part of the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API).
 
@@ -24,12 +24,12 @@ None.
 
 ### Return value
 
-A {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to unpartitioned cookies — `true` if it does, and `false` if not.
+A {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to third-party cookies — `true` if it does, and `false` if not.
 
 The result returned by this method can be inaccurate in a couple of circumstances:
 
-1. The user may have browser settings active that block unpartitioned cookies entirely — in this case `true` may be returned even though unpartitioned cookies are still inaccessible. To handle such a situation, you should gracefully handle any errors resulting in cookie values being unretrievable; for example, inform the user that access to their personalized settings is blocked and invite them to sign in again to use them.
-2. The browser might not block third-party cookie access by default — in this case `false` may be returned even though unpartitioned cookies are accessible, and storage access wouldn't need to be requested (i.e. via {{domxref("Document.requestStorageAccess()")}}). To get around this issue, you could query {{domxref("Document.cookie")}} to find out whether your cookies are accessible, and call {{domxref("Document.requestStorageAccess()")}} if they are not.
+1. The user may have active browser settings that block third-party cookies; in this case, `true` may be returned even though third-party cookies are still inaccessible. To handle such a situation, you should gracefully handle any errors resulting in cookie values being unretrievable; for example, inform the user that access to their personalized settings is blocked and invite them to sign in again to use them.
+2. The browser might not block third-party cookie access by default; in this case, `false` may be returned even though third-party cookies are accessible, and storage access wouldn't need to be requested (i.e., via {{domxref("Document.requestStorageAccess()")}}). To get around this issue, you could query {{domxref("Document.cookie")}} to find out whether your cookies are accessible, and call {{domxref("Document.requestStorageAccess()")}} if they are not.
 
 > **Note:** If the promise gets resolved and a user gesture event was being processed when the function was originally called, the resolve handler will run as if a user gesture was being processed, so it will be able to call APIs that require user activation.
 
@@ -63,5 +63,6 @@ document.hasStorageAccess().then((hasAccess) => {
 
 ## See also
 
+- {{domxref("Document.requestStorageAccess()")}}, {{domxref("Document.requestStorageAccessFor()")}}
 - [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using)
 - [Introducing Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit blog)
diff --git a/files/en-us/web/api/document/index.md b/files/en-us/web/api/document/index.md
index 64fb98e65c14255..7759df1ba63e1e0 100644
--- a/files/en-us/web/api/document/index.md
+++ b/files/en-us/web/api/document/index.md
@@ -256,6 +256,8 @@ _This interface also inherits from the {{DOMxRef("Node")}} and {{DOMxRef("EventT
   - : Replaces the existing children of a document with a specified new set of children.
 - {{DOMxRef("Document.requestStorageAccess()")}}
   - : Allows a document loaded in a third-party context (i.e. embedded in an {{htmlelement("iframe")}}) to request access to unpartitioned cookies, in cases where user agents by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy.
+- {{DOMxRef("Document.requestStorageAccessFor()")}} {{Non-standard_Inline}}
+  - : Allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
 - {{domxref("Document.startViewTransition()")}} {{Experimental_Inline}}
   - : Starts a new {{domxref("View Transitions API", "view transition", "", "nocode")}} and returns a {{domxref("ViewTransition")}} object to represent it.
 
diff --git a/files/en-us/web/api/document/requeststorageaccess/index.md b/files/en-us/web/api/document/requeststorageaccess/index.md
index 4fcb7225b83256b..1a96b61f79d78f3 100644
--- a/files/en-us/web/api/document/requeststorageaccess/index.md
+++ b/files/en-us/web/api/document/requeststorageaccess/index.md
@@ -8,9 +8,9 @@ browser-compat: api.Document.requestStorageAccess
 
 {{APIRef("Storage Access API")}}
 
-The **`requestStorageAccess()`** method of the {{domxref("Document")}} interface allows a document loaded in a third-party context (i.e. embedded in an {{htmlelement("iframe")}}) to request access to unpartitioned cookies.
+The **`requestStorageAccess()`** method of the {{domxref("Document")}} interface allows content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to third-party cookies. This is relevant to user agents that, by default, block access to [third-party](/en-US/docs/Web/HTTP/Cookies#third-party_cookies), [unpartitioned](/en-US/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) cookies to improve privacy (e.g., to prevent tracking), and is part of the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API).
 
-This is relevant to user agents that by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy (e.g. to prevent tracking), and is part of the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API).
+To check whether permission to access third-party cookies has already been granted, you can call {{domxref("Permissions.query()")}}, specifying the feature name `"storage-access"`.
 
 > **Note:** Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server. In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics, or prompting the user for explicit permission.
 
@@ -26,7 +26,7 @@ None.
 
 ### Return value
 
-A {{jsxref("Promise")}} that fulfills with `undefined` if the access to unpartitioned cookies was granted, and rejects if access was denied.
+A {{jsxref("Promise")}} that fulfills with `undefined` if the access to third-party cookies was granted, and rejects if access was denied.
 
 `requestStorageAccess()` requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click ({{Glossary("transient activation")}}), or unless permission was already granted previously. If permission was not previously granted, they need to be run inside a user gesture-based event handler. The user gesture behavior depends on the state of the promise:
 
@@ -70,5 +70,6 @@ document.requestStorageAccess().then(
 
 ## See also
 
+- {{domxref("Document.hasStorageAccess()")}}, {{domxref("Document.requestStorageAccessFor()")}}
 - [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using)
 - [Introducing Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit blog)
diff --git a/files/en-us/web/api/document/requeststorageaccessfor/index.md b/files/en-us/web/api/document/requeststorageaccessfor/index.md
new file mode 100644
index 000000000000000..236fb45c1d5fdff
--- /dev/null
+++ b/files/en-us/web/api/document/requeststorageaccessfor/index.md
@@ -0,0 +1,120 @@
+---
+title: "Document: requestStorageAccessFor() method"
+short-title: requestStorageAccessFor()
+slug: Web/API/Document/requestStorageAccessFor
+page-type: web-api-instance-method
+status:
+  - non-standard
+browser-compat: api.Document.requestStorageAccessFor
+---
+
+{{APIRef("Storage Access API")}}{{non-standard_header}}
+
+The **`requestStorageAccessFor()`** method of the {{domxref("Document")}} interface allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). It returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
+
+## Syntax
+
+```js-nolint
+requestStorageAccessFor(requestedOrigin)
+```
+
+### Parameters
+
+- `requestedOrigin`
+  - : A string representing the URL of the origin you are requesting third-party cookie access for.
+
+### Return value
+
+A {{jsxref("Promise")}} that fulfills with `undefined` if the access to third-party cookies was granted and rejects if access was denied.
+
+`requestStorageAccessFor()` requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click ({{Glossary("transient activation")}}), or unless permission was already granted previously. If permission was not previously granted, they must run inside a user gesture-based event handler. The user gesture behavior depends on the state of the promise:
+
+- If the promise resolves (i.e., permission was granted), then the user gesture has not been consumed, so the script can subsequently call APIs requiring a user gesture.
+- If the promise is rejected (i.e., permission was not granted), then the user gesture has been consumed, so the script can't do anything that requires a gesture. This prevents scripts from calling `requestStorageAccessFor()` again if permission is denied.
+
+### Exceptions
+
+- `InvalidStateError` {{domxref("DOMException")}}
+  - : Thrown if the current {{domxref("Document")}} is not yet active.
+- `NotAllowedError` {{domxref("DOMException")}}
+  - : Thrown if:
+    - The document's window is not a [secure context](/en-US/docs/Web/Security/Secure_Contexts).
+    - The document is not the top-level document.
+    - The document has a `null` origin.
+    - The supplied `requestedOrigin` is [opaque](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque).
+    - The top-level and embedded sites are not in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
+    - The embedding {{htmlelement("iframe")}} is sandboxed, and the `allow-storage-access-by-user-activation` token is not set.
+    - Usage is blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy).
+    - Usage is denied by the user agent's permission request to use the API.
+- `TypeError`
+  - : Thrown if `requestedOrigin` is not a valid URL.
+
+## Description
+
+The `requestStorageAccessFor()` method addresses challenges in adopting the Storage Access API on top-level sites that use cross-site images or scripts requiring cookies. It is relevant to user agents that by default block access to [third-party](/en-US/docs/Web/HTTP/Cookies#third-party_cookies), [unpartitioned](/en-US/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) cookies to improve privacy (e.g. to prevent tracking), and is a proposed extension of the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API).
+
+`requestStorageAccessFor()` can enable third-party cookie access for cross-site resources directly embedded into a top-level site that are unable to request storage access themselves, for example {{htmlelement("img")}} elements. Cross-site content embedded in `<iframe>`s that has its own logic and resources and needs third-party cookie access should request storage access via {{domxref("Document.requestStorageAccess()")}}.
+
+To check whether permission to access third-party cookies has already been granted via `requestStorageAccessFor()`, you can call {{domxref("Permissions.query()")}}, specifying the feature name `"top-level-storage-access"`. This is different from the feature name used for the regular {{domxref("Document.requestStorageAccess()")}} method, which is `"storage-access"`.
+
+The `Permissions.query()` call must specify the embedded origin; for example:
+
+```js
+navigator.permissions.query({
+  name: "top-level-storage-access",
+  requestedOrigin: "https://www.example.com",
+});
+```
+
+> **Note:** Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server (the same one that controls the rest of the Storage Access API). In addition, the document must pass additional browser-specific checks such as allowlists, blocklists, on-device classification, user settings, or anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics.
+
+## Examples
+
+```js
+function rSAFor() {
+  if ("requestStorageAccessFor" in document) {
+    document.requestStorageAccessFor("https://example.com").then(
+      (res) => {
+        // Use storage access
+        doThingsWithCookies();
+      },
+      (err) => {
+        // Handle errors
+      },
+    );
+  }
+}
+```
+
+After a successful `requestStorageAccessFor()` call, cross-site requests will include cookies if they include [CORS](/en-US/docs/Web/HTTP/CORS) / [`crossorigin`](/en-US/docs/Web/HTML/Attributes/crossorigin), so sites may want to wait before triggering a request. Such requests must use the [`credentials: "include"`](/en-US/docs/Web/API/fetch#credentials) option and resources must include the `crossorigin="use-credentials"` attribute.
+
+For example:
+
+```js
+function checkCookie() {
+  fetch("https://example.com/getcookies.json", {
+    method: "GET",
+    credentials: "include",
+  })
+    .then((response) => response.json())
+    .then((json) => {
+      // Do something
+    });
+}
+```
+
+> **Note:** See [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for a more complete example.
+
+## Specifications
+
+{{Specifications}}
+
+## Browser compatibility
+
+{{Compat}}
+
+## See also
+
+- {{domxref("Document.hasStorageAccess()")}}, {{domxref("Document.requestStorageAccess()")}}
+- [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using)
+- [Introducing Storage Access API](https://webkit.org/blog/8124/introducing-storage-access-api/) (WebKit blog)
diff --git a/files/en-us/web/api/permissions_api/index.md b/files/en-us/web/api/permissions_api/index.md
index 68e7f0753ea2464..d381b1c44a6c4d2 100644
--- a/files/en-us/web/api/permissions_api/index.md
+++ b/files/en-us/web/api/permissions_api/index.md
@@ -41,14 +41,14 @@ A non-exhaustive list of permission-aware APIs includes:
 - [Payment Handler API](/en-US/docs/Web/API/Payment_Handler_API): `payment-handler`
 - [Push API](/en-US/docs/Web/API/Push_API): `push`
 - [Sensor APIs](/en-US/docs/Web/API/Sensor_APIs): `accelerometer`, `gyroscope`, `magnetometer`, `ambient-light-sensor`
-- [Storage Access API](/en-US/docs/Web/API/Storage_Access_API): `storage-access`
+- [Storage Access API](/en-US/docs/Web/API/Storage_Access_API): `storage-access`, `top-level-storage-access`
 - [Storage API](/en-US/docs/Web/API/Storage_API): `persistent-storage`
 - [Web MIDI API](/en-US/docs/Web/API/Web_MIDI_API): `midi`
 - [Window Management API](/en-US/docs/Web/API/Window_Management_API): `window-management`
 
 ## Examples
 
-We have made a simple example available called Location Finder. You can [run the example live](https://chrisdavidmills.github.io/location-finder-permissions-api/), or [view the source code on GitHub](https://github.com/chrisdavidmills/location-finder-permissions-api/tree/gh-pages).
+We have created a simple example called Location Finder. You can [run the example live](https://chrisdavidmills.github.io/location-finder-permissions-api/), or [view the source code on GitHub](https://github.com/chrisdavidmills/location-finder-permissions-api/tree/gh-pages).
 
 Read more about how it works in our article [Using the Permissions API](/en-US/docs/Web/API/Permissions_API/Using_the_Permissions_API).
 
diff --git a/files/en-us/web/api/storage_access_api/index.md b/files/en-us/web/api/storage_access_api/index.md
index 58e4b037061a256..ca2056e51e79500 100644
--- a/files/en-us/web/api/storage_access_api/index.md
+++ b/files/en-us/web/api/storage_access_api/index.md
@@ -5,51 +5,63 @@ page-type: web-api-overview
 browser-compat:
   - api.Document.hasStorageAccess
   - api.Document.requestStorageAccess
+  - api.Document.requestStorageAccessFor
+  - api.Permissions.permission_storage-access
+spec-urls: https://privacycg.github.io/storage-access/
 ---
 
 {{DefaultAPISidebar("Storage Access API")}}
 
-The Storage Access API provides a way for cross-site content loaded in a third-party context (i.e. embedded in an {{htmlelement("iframe")}}) to gain access to _unpartitioned cookies_ that it would normally only have access to in a first-party context (i.e. when loaded directly in a browser tab).
+The Storage Access API provides a way for cross-site content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to gain access to [third-party cookies](/en-US/docs/Web/HTTP/Cookies#third-party_cookies) that it would typically only have access to in a first-party context (i.e., when loaded directly in a browser tab).
 
-> **Note:** When we say _unpartitioned cookies_, we are talking about cookies stored in the traditional way they have historically been stored since the early web — all cookies set on the same site are stored in the same cookie jar. This is in contrast to _partitioned cookies_, where embedded resources under each top-level site are given a unique cookie storage space (see for example [Cookies Having Independent Partitioned State (CHIPS)](/en-US/docs/Web/Privacy/Partitioned_cookies)).
+The Storage Access API is relevant to user agents that, by default, block access to third-party cookies to improve privacy (for example, to prevent tracking). There are legitimate uses for third-party cookies that we still want to enable, even with these default restrictions in place. Examples include single sign-on (SSO) with federated identity providers (IdPs), or persisting user details such as location data or viewing preferences across different sites.
 
-The Storage Access API is relevant to user agents that by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy (for example, to prevent tracking). There are legitimate uses for unpartitioned cookie access by third-party content that we still want to enable, even with these default restrictions in place. Examples include SSO with federated IdPs, or persisting user details such as location data or viewing preferences across different sites.
-
-The API provides methods that allow embedded resources to check whether they currently have access to unpartitioned cookies and, if not, to request access from the user agent.
+The API provides methods that allow embedded resources to check whether they currently have access to third-party cookies and, if not, to request access from the user agent.
 
 > **Note:** The _Storage Access API_ name may seem like somewhat of a misnomer, given that it only provides access to cookies, and not other client-side storage mechanisms such as {{domxref("Web_Storage_API", "Web Storage", "", "nocode")}} or {{domxref("IndexedDB_API", "IndexedDB", "", "nocode")}}. The name has been kept generic because it may provide access to other forms of client-side storage in the future.
 
 ## Concepts and usage
 
-Browsers implement several storage access features and policies that restrict access to unpartitioned cookies by embedded, cross-site resources. These range from giving embedded resources under each top-level origin a unique cookie storage space (_partitioned cookies_), to outright blocking of cookie access when resources are loaded in a third-party context.
+Browsers implement several storage access features and policies restricting access to third-party cookies. These range from giving embedded resources under each top-level origin a unique cookie storage space ([partitioned cookies](#unpartitioned_versus_partitioned_cookies)) to outright blocking of cookie access when resources are loaded in a third-party context.
+
+The semantics around third-party cookie-blocking features and policies differ from browser to browser, but the core functionality is similar. Cross-site resources embedded in a third-party context are not given access to the same cookies that they would have access to when loaded in a first-party context. This is done with good intent — browser vendors want to take steps to better protect their user's privacy and security. Examples include leaving them less open to having their activity tracked across different sites, and less vulnerable to exploits such as cross-site request forgery ({{glossary("CSRF")}}).
+
+However, there are legitimate uses for embedded cross-site content accessing third-party cookies, which the above features and policies are known to break. Let's say you've got a series of different sites that provide access to different products — `heads-example.com`, `shoulders-example.com`, `knees-example.com`, and `toes-example.com`.
+
+Alternatively, you might separate your content or services into different country domains for localization purposes — `example.com`, `example.ua`, `example.br`, etc. — or in some other way.
+
+You might have accompanying utility sites with components embedded in all the other sites, for example, to provide SSO (`sso-example.com`) or general personalization services (`services-example.com`). These utility sites will want to share their state with the sites they are embedded in via cookies. They cannot share first-party cookies because they are on different domains, and third-party cookies will no longer work in browsers that block them.
+
+In such situations, site owners often encourage users to add their site as an exception or to disable third-party cookie-blocking policies entirely. Users who wish to continue interacting with their content must significantly relax their blocking policy for resources loaded from all embedded origins and possibly across all websites.
 
-The semantics around unpartitioned cookie blocking features/policies differ from browser to browser, but the core functionality is similar: cross-site resources embedded in a third-party context are not given access to the same cookies that they would have access to when loaded in a first-party context. This is done with good intent — browser vendors want to take steps to better protect their user's privacy and security, for example leaving them less open to having their activity tracked across different sites, and less vulnerable to exploits such as cross-site request forgery ({{glossary("CSRF")}}).
+The Storage Access API is intended to solve this problem; embedded cross-site content can request unrestricted access to third-party cookies on a frame-by-frame basis via the {{domxref("Document.requestStorageAccess()")}} method. It can also check whether it already has access via the {{domxref("Document.hasStorageAccess()")}} method.
 
-However, there are legitimate uses for embedded cross-site content accessing unpartitioned cookies, which the above features/policies are known to break. As an example, federated logins often require access to authentication cookies, and will require the user to sign in on each site separately (or completely break) if those cookies are not available. As a result, site owners often encourage users to add their site as an exception or to disable such policies entirely. Users who wish to continue to interact with embedded content are forced to greatly relax their blocking policy for resources loaded from all embedded origins and possibly across all websites.
+### Unpartitioned versus partitioned cookies
 
-The Storage Access API is intended to solve this problem; embedded cross-site content can request unrestricted access to unpartitioned cookies on a frame-by-frame basis, for a particular top-level embedding site, via the {{domxref("Document.requestStorageAccess()")}} method. It can also check whether it already has access via the {{domxref("Document.hasStorageAccess()")}} method.
+It is important to note that the Storage Access API is only needed to provide access to _unpartitioned_ third-party cookies. This means cookies stored in the traditional way since the early web — all cookies set on the same site are stored in the same cookie jar. This is in contrast to _partitioned_ cookies, where embedded resources under each top-level site are given a unique cookie storage space, thereby making tracking users across sites via these cookies impossible.
 
-## How it works
+Browsers have various mechanisms to partition third-party cookie access, for example [Firefox Total Cookie Protection](https://blog.mozilla.org/products/firefox/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/) and [Cookies Having Independent Partitioned State (CHIPS)](/en-US/docs/Web/Privacy/Partitioned_cookies).
 
-As explained above, modern browsers implement various features and policies to restrict or block access to unpartitioned cookies by embedded content. Such content that has a legitimate need for cookie access can get around this problem using the Storage Access API as follows:
+When we talk about third-party cookies in the context of the Storage Access API, we implicitly mean _unpartitioned_ third-party cookies.
+
+### How it works
+
+Embedded content that has a legitimate need for third party cookie access can request access using the Storage Access API as follows:
 
 1. It can call the {{domxref("Document.hasStorageAccess()")}} method to check whether it has the access it needs already.
 2. If not, it can request access via the {{domxref("Document.requestStorageAccess()")}} method.
 3. Depending on the browser, the user will be asked whether to grant access to the requesting embed in slightly different ways.
    - Safari shows prompts for all embedded content that has not previously received storage access.
    - Firefox only prompts users after an origin has requested storage access on more than a threshold number of sites.
-   - At the time of writing, Chrome doesn't prompt the user. Instead, it only resolves `requestStorageAccess()` calls that come from domains within a [first-party set](https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/). This behavior will change as the implementation is developed further.
-4. Access is granted or denied based on whether the content meets all the security requirements (see [Security measures](#security_measures), below). The {{jsxref("Promise")}}-based nature of `requestStorageAccess()` allows you to run code to handle success and failure cases.
-   - Modern spec behavior dictates that access is granted **per-frame** — every separate content embed has its unpartitioned cookie access blocked by default, and needs to call `requestStorageAccess()` to opt-in to access. If a content embed has received access, and same-site embeds then call `requestStorageAccess()`, their promises will fulfill automatically. But they still need to opt-in.
-   - In older versions of the spec, the access was **per-page**. As soon as one embed received unpartitioned cookie access via `requestStorageAccess()`, all other same-site embeds would automatically receive access. This was not desirable behavior from a security standpoint — for example, if `shop.example.com` embedded `locator.users.com` to allow users to use their location info while shopping, and `locator.users.com` called `requestStorageAccess()`, `shop.example.com` and any other sites it embeds would be able to access its cookies, but also access cookies from `private.users.com`, which is not intended to be embedded. [Read more about the motivations](https://github.com/privacycg/storage-access/issues/113) behind this change.
-   - Consult the [Browser compatibility information](#browser_compatibility) to see which browsers implement which behavior.
+   - Chrome shows prompts for all embedded content that has not previously received storage access. It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
+4. Access is granted or denied based on whether the content meets all the security requirements — see [Security measures](#security_measures) for general requirements, and [Browser-specific variations](#browser-specific_variations) for some browser-specific security requirements. The {{jsxref("Promise")}}-based nature of `requestStorageAccess()` allows you to run code to handle success and failure cases.
+   - Modern spec behavior dictates that access is granted _per-frame_ — every separate content embed has its third-party cookie access blocked by default, and needs to call `requestStorageAccess()` to opt in to access. If a content embed has received access, and same-site embeds then call `requestStorageAccess()`, their promises will fulfill automatically. But they still need to opt in.
+   - The only exception to the "blocked by default" behavior is when a content embed makes a successful `requestStorageAccess()`, but then performs a same-origin navigation (for example reloading itself). In such cases, the storage access is carried over from the previous navigation.
+   - In older spec versions, the access was _per-page_ (Safari is the only browser still using this model). When one embed received third-party cookie access via `requestStorageAccess()`, all other same-site embeds would automatically receive access. This was not desirable behavior from a security standpoint — for example, if `shop.example.com` embedded `locator.users.com` to allow users to use their location info while shopping, and `locator.users.com` called `requestStorageAccess()`, `shop.example.com` and any other sites it embeds would be able to access its cookies, but also access cookies from `private.users.com`, which is not intended to be embedded. [Read more about the motivations](https://github.com/privacycg/storage-access/issues/113) behind this change.
 5. Once access is granted, a permission key is stored in the browser with the structure `<top-level site, embedded site>`. For example, if the embedding site is `embedder.com`, and the embed is `locator.example.com`, the key would be `<embedder.com, example.com>`. Same-site embeds (`docs.example.com`, `profile.example.com`, etc.) would then be able to call `requestStorageAccess()` and the promise would fulfill automatically, as mentioned earlier.
-   - Older versions of the spec used the more specific permission key structure `<top-level site, embedded origin>`, which meant that same-site, cross-origin embeds didn't match the permission key and had to go through the whole process separately.
-   - At the time of writing, only Chromium browsers had implemented the new behavior.
-
-> **Note:** The only exception to the "blocked by default" behavior is when a content embed makes a successful `requestStorageAccess()`, but then performs a same-origin navigation (for example reloading itself). In such cases, the storage access is carried over from the previous navigation.
+   - Older spec versions used the more specific permission key structure `<top-level site, embedded origin>`, which meant that same-site, cross-origin embeds didn't match the permission key and had to go through the whole process separately.
 
-> **Note:** In cases where a top-level site has its cookies partitioned (for example via [CHIPS](/en-US/docs/Web/Privacy/Partitioned_cookies) or [Total Cookie Protection](https://blog.mozilla.org/en/mozilla/firefox-androids-new-privacy-feature-total-cookie-protection-stops-companies-from-keeping-tabs-on-your-moves/)), the Storage Access API isn't required, as sharing the cookies by default has no privacy risk.
+> **Note:** In cases where a top-level site has its cookies [partitioned](#unpartitioned_versus_partitioned_cookies), the Storage Access API isn't required, as sharing the cookies by default has no privacy risk.
 
 ## Security measures
 
@@ -73,19 +85,22 @@ Several different security measures could cause a {{domxref("Document.requestSto
    ```
 
 6. Usage of this feature may be blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Permissions_Policy) set on your server.
-7. At the time of writing, Chrome only resolves `requestStorageAccess()` calls that come from domains within a [first-party set](https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/). This restriction is intended to be relaxed as the implementation is developed further.
 
 > **Note:** The document may also be required to pass additional browser-specific checks. Examples: allowlists, blocklists, on-device classification, user settings, anti-[clickjacking](/en-US/docs/Glossary/Clickjacking) heuristics, or prompting the user for explicit permission.
 
-## Browser storage access policy variations
+## Browser-specific variations
 
-Although the API surface is the same, websites using the Storage Access API should expect differences in the level and extent of unpartitioned cookie access they receive between different browsers, due to differences in their storage access policies.
+Although the API surface is the same, websites using the Storage Access API should expect differences in the level and extent of third-party cookie access they receive between different browsers, due to differences in their storage access policies.
 
-### Firefox
+### Chrome
+
+- Cookies must have [`SameSite=None`](/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value) explicitly set on them, because the default value for Chrome is `SameSite=Lax` (`SameSite=None` is the default in Firefox and Safari).
+- Cookies must have the [`Secure`](/en-US/docs/Web/HTTP/Headers/Set-Cookie#secure) attribute set on them.
+- The storage access grants are phased out after 30 days of browser usage passed without user interaction. Interaction with the embedded content extends this limit by another 30 days. This doesn't occur when {{domxref("Document.requestStorageAccessFor()")}} is called because the user is already on the page.
 
-Design properties unique to Firefox are summarized here:
+### Firefox
 
-- If the embedded origin `tracker.example` has already obtained unpartitioned cookie access on the top-level origin `foo.example`, and the user visits a page from `foo.example` embedding a page from `tracker.example` again in less than 30 days, the embedded origin will have unpartitioned cookie access immediately when loading.
+- If the embedded origin `tracker.example` has already obtained third-party cookie access on the top-level origin `foo.example`, and the user visits a page from `foo.example` embedding a page from `tracker.example` again in less than 30 days, the embedded origin will have third-party cookie access immediately when loading.
 - The storage access grants are phased out after 30 calendar days have passed.
 
 Documentation for Firefox's new storage access policy for blocking tracking cookies includes [a detailed description](/en-US/docs/Web/Privacy/Storage_Access_Policy#storage_access_grants) of the scope of storage access grants.
@@ -96,21 +111,26 @@ Documentation for Firefox's new storage access policy for blocking tracking cook
 
 ## Examples
 
-See [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for an implementation guide with code examples.
+- See [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for an implementation guide with code examples.
+- See [Storage Access API Demo](https://storage-access-api-demo.glitch.me/) for a live demo.
 
 ## API methods
 
 - {{domxref("Document.hasStorageAccess()")}}
-  - : Returns a {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to unpartitioned cookies.
+  - : Returns a {{jsxref("Promise")}} that resolves with a boolean value indicating whether the document has access to third-party cookies.
 - {{domxref("Document.requestStorageAccess()")}}
-  - : Returns a {{jsxref("Promise")}} that resolves if the access to unpartitioned cookies was granted, and rejects if access was denied.
+  - : Allows content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to third-party cookies; returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
+- {{domxref("Document.requestStorageAccessFor()")}} {{experimental_inline}}
+  - : A proposed extension to the Storage Access API that allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). Returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied.
 
-> **Note:** User interaction propagates to the promise returned by both of these methods, allowing the callers to take actions that require user interaction without requiring a second click from the user. For example, a caller could open a pop-up window from the resolved promise without triggering Firefox's pop-up blocker.
+> **Note:** User interaction propagates to the promise returned by these methods, allowing the callers to take actions requiring user interaction without requiring a second click. For example, a caller could open a pop-up window from the resolved promise without triggering Firefox's pop-up blocker.
 
 ### Additions to other APIs
 
-- {{domxref("Permissions.query()")}}
-  - : You can call `Permissions.query()` with a value of `"storage-access"` to query whether unpartitioned cookie access has been granted in general, i.e. to another same-site embed. If so, you can call `requestStorageAccess()` without user interaction, and the promise will resolve automatically.
+- {{domxref("Permissions.query()")}}, the `"storage-access"` feature name
+  - : In supporting browsers, this can query whether third-party cookie access has been granted in general, that is, to another same-site embed. If so, you can call `requestStorageAccess()` without user interaction, and the promise will resolve automatically.
+- `Permissions.query()`, the `"top-level-storage-access"` feature name {{experimental_inline}}
+  - : A separate feature name used to query whether permission to access third-party cookies has already been granted via `requestStorageAccessFor()`. If so, you don't need to call `requestStorageAccessFor()` again.
 
 ## Specifications
 
diff --git a/files/en-us/web/api/storage_access_api/related_website_sets/index.md b/files/en-us/web/api/storage_access_api/related_website_sets/index.md
new file mode 100644
index 000000000000000..12c6a62de4bd188
--- /dev/null
+++ b/files/en-us/web/api/storage_access_api/related_website_sets/index.md
@@ -0,0 +1,163 @@
+---
+title: Related Website Sets
+slug: Web/API/Storage_Access_API/Related_website_sets
+page-type: guide
+status:
+  - non-standard
+browser-compat: api.document.requestStorageAccessFor
+spec-urls: https://wicg.github.io/first-party-sets/
+---
+
+{{DefaultAPISidebar("Storage Access API")}}
+
+> **Warning:** One or more browser vendors oppose this feature — in its current state, it will never be implemented across all browsers. See [Standards positions](#standards_positions) for details of opposition.
+
+Related website sets are a mechanism for defining a set of related sites that share trusted content. As a result, browsers will grant default access for these sites to [third-party cookies](/en-US/docs/Web/HTTP/Cookies#third-party_cookies) when they have content embedded in other set members.
+
+## Concepts and usage
+
+Let's consider situations where you have a series of related websites with different domain names, and you want to give site content access to third-party cookies when loaded in a third-party context inside other related sites (i.e., embedded in an {{htmlelement("iframe")}}). Typical use cases are:
+
+- App sites: A single application may be deployed over multiple sites, aiming to allow users to navigate between them seamlessly in a single session.
+- Brand sites: A set of brand assets may be contained in a single site but then deployed over multiple domains, including session data relating to user preferences, customization, etc.
+
+Third-party cookie access is commonly blocked by browser cookie-blocking policies. Still, you can work around it using the Storage Access API — see [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for details.
+
+Related website are a progressive enhancement mechanism that works alongside the Storage Access API. Supporting browsers grant third-party cookie access between websites in the same set _without_ having to go through the usual user permission prompt workflow, once {{domxref("Document.requestStorageAccess()")}} (or {{domxref("Document.requestStorageAccessFor()")}}) is called. This results in a more user-friendly experience for users of sites in the set.
+
+You should bear in mind that:
+
+- The Chrome-only {{domxref("Document.requestStorageAccessFor()")}} method — which allows top-level sites to request storage access on behalf of embedded origin content — is only supported on domains within a related website set. See [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for an example.
+- When Chrome first supported the standard Storage Access API (that is, the {{domxref("Document.hasStorageAccess()")}} and {{domxref("Document.requestStorageAccess()")}}methods), it required calling sites to be part of a related website set. This is no longer the case.
+
+## How does RWS work?
+
+A related website set consists of one primary site and up to five associated sites.
+
+### JSON structure
+
+A set is represented by a JSON structure. A hypothetical example is as follows:
+
+```json
+{
+  "sets": [
+    {
+      "contact": "email address or group alias if available",
+      "primary": "https://primary1.com",
+      "associatedSites": [
+        "https://associateA.com",
+        "https://associateB.com",
+        "https://associateC.com"
+      ],
+      "serviceSites": ["https://servicesiteA.com"],
+      "rationaleBySite": {
+        "https://associateA.com": "Explanation of affiliation with primary site",
+        "https://associateB.com": "Explanation of affiliation with primary site",
+        "https://associateC.com": "Explanation of affiliation with primary site",
+        "https://serviceSiteA.com": "Explanation of service functionality support"
+      },
+      "ccTLDs": {
+        "https://associateA.com": [
+          "https://associateA.ca",
+          "https://associateA.co.uk"
+        ],
+        "https://associateB.com": [
+          "https://associateB.ru",
+          "https://associateB.co.kr"
+        ],
+        "https://primary1.com": ["https://primary1.co.uk"]
+      }
+    }
+  ]
+}
+```
+
+> **Note:** The affiliation explanations must include a clear description of how the affiliation to the primary site is presented to users of those sites.
+
+To use a set, its JSON must be added to the `related_website_sets.JSON` file available on the [Related Website Sets GitHub repository](https://github.com/GoogleChrome/related-website-sets/blob/main/related_website_sets.JSON), which Chrome then consumes to get the list of sets to apply RWS behavior to.
+
+### `.well-known` files
+
+Each site in the set must also serve a [`.well-known`](https://en.wikipedia.org/wiki/Well-known_URI) file at `/.well-known/related-website-set.json`, which serves to verify the set structure and the relationship between the sites in the set.
+
+The primary site's `.well-known` file must explicitly list out the full set structure. `https://primary1.com` in the above example would need a `https://primary1.com/.well-known/related-website-set.json` file similar to the following:
+
+```json
+{
+  "primary": "https://primary1.com",
+  "associatedSites": [
+    "https://associateA.com",
+    "https://associateB.com",
+    "https://associateC.com"
+  ],
+  "serviceSites": ["https://servicesiteA.com"],
+  "rationaleBySite": {
+    "https://associateA.com": "Explanation of affiliation with primary site",
+    "https://associateB.com": "Explanation of affiliation with primary site",
+    "https://associateC.com": "Explanation of affiliation with primary site",
+    "https://serviceSiteA.com": "Explanation of service functionality support"
+  },
+  "ccTLDs": {
+    "https://associateA.com": [
+      "https://associateA.ca",
+      "https://associateA.co.uk"
+    ],
+    "https://associateB.com": [
+      "https://associateB.ru",
+      "https://associateB.co.kr"
+    ],
+    "https://primary1.com": ["https://primary1.co.uk"]
+  }
+}
+```
+
+Each associate and service site needs to specify its primary site in a `.well-known` file. Each non-primary site in the above example (e.g. `https://associateA.com`) would need a `/.well-known/related-website-set.json` file like this:
+
+```json
+{
+  "primary": "https://primary1.com"
+}
+```
+
+For full details of the process, JSON syntax, and other requirements for submitting sets, see the [submission guidelines](https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md). Only domain administrators can create a set containing their sites.
+
+Bear in mind that the `.well-known` files are also verified as part of the submission process, so they need to be put in place before the associated set is submitted.
+
+### Active set benefits
+
+Once a set is active:
+
+- Requests from sites in the set (via {{domxref("Document.requestStorageAccess()")}}) to access third-party cookies that belong to sites in the set are automatically granted, and no user permission step is required.
+- {{domxref("Document.requestStorageAccessFor()")}} calls can be made from top-level sites in the set to request third-party cookie access for other sites in the set.
+
+## RWS security
+
+RWS has been designed with security in mind. It would be disasterous if a bad actor site were able to claim to be part of a set and gain the privileges that entails. Lets consider a theoretical bad actor site, `evilsite.example.com`, and look at some examples of attacks it could try to make, all of which would fail:
+
+- **`evilsite.example.com` claims to be an associated site in another set**: If a site claiming to be in a set (`i.e.` by listing a primary in a `.well-known` file) is not included in the set submission and/or primary's `.well-known` file, it won't get the benefits of being in the set.
+- **`evilsite.example.com` claims to be a primary site, and submits a set that includes some would-be victim sites**: The submission process requires that `.well-known` files hosted by non-primary sites explicitly list out their primary. If this primary doesn't match the set submission (i.e. if the associated/service sites expect to have a different primary, or don't expect to be in a set at all), the submission will be rejected.
+- **`site1.example.com` and `site2.example.com` are intentionally in the same set, but `site1.example.com` gets hijacked by `evilsite.example.com`**: The impact of a site hijacking attack within a set isn't any worse than it would usually be, once the other sites are updated accordingly:
+  - The regular [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) requires an active opt-in by the embedded site, so `site2.example.com` can stop calling `document.requestStorageAccess()` when it's embedded in `site1.example.com`, avoiding a {{glossary("CSRF")}} attack.
+  - Use of `requestStorageAccessFor()` requires [CORS](/en-US/docs/Web/HTTP/CORS), so `site2.example.com` could choose not to respond with the appropriate CORS headers when network requests are coming from `site1.example.com`, thereby avoiding a CSRF attack.
+
+## Examples
+
+- The [Related Website Sets demo](https://related-website-sets.glitch.me/) demonstrates how RWS is used.
+- Also see [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using).
+
+## Specifications
+
+{{Specifications}}
+
+### Standards positions
+
+One or more vendors oppose this specification. Known positions are as follows:
+
+- Mozilla (Firefox): [Negative](https://mozilla.github.io/standards-positions/#first-party-sets)
+- Apple (Safari): [Negative](https://webkit.org/standards-positions/#position-93)
+
+## See also
+
+- [Storage Access API](/en-US/docs/Web/API/Storage_Access_API)
+- [Related Website Sets](https://developer.chrome.com/docs/privacy-sandbox/related-website-sets/) on developer.chrome.com (2023)
+- [Related Website Sets: developer guide](https://developer.chrome.com/docs/privacy-sandbox/related-website-sets-integration/) on developer.chrome.com (2023)
diff --git a/files/en-us/web/api/storage_access_api/using/index.md b/files/en-us/web/api/storage_access_api/using/index.md
index c20834c2d1d347e..b0d8332606c20f6 100644
--- a/files/en-us/web/api/storage_access_api/using/index.md
+++ b/files/en-us/web/api/storage_access_api/using/index.md
@@ -6,13 +6,15 @@ page-type: guide
 
 {{DefaultAPISidebar("Storage Access API")}}
 
-The [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) can be used by embedded cross-site documents to verify whether they have access to unpartitioned cookies and, if not, to request access. We'll briefly look at a common storage access scenario.
+The [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) can be used by embedded cross-site documents to verify whether they have access to [third-party](/en-US/docs/Web/HTTP/Cookies#third-party_cookies) cookies and, if not, to request access. We'll briefly look at a common storage access scenario.
+
+> **Note:** When we talk about third-party cookies in the content of the Storage Access API, we implicitly mean [_unpartitioned_](/en-US/docs/Web/API/Storage_Access_API#unpartitioned_versus_partitioned_cookies) third-party cookies.
 
 ## Usage notes
 
-The Storage Access API is designed to allow embedded content to request access to unpartitioned cookies — most modern browsers block such access by default to protect user privacy. Since embedded content won't know what a browser's behavior is going to be in this regard, it's best to always check whether the embedded {{htmlelement("iframe")}} has storage access before attempting to read or write a cookie. This is particularly true for {{domxref("Document.cookie")}} access, as browsers will often return an empty cookie jar when third-party cookie access is blocked.
+The Storage Access API is designed to allow embedded content to request access to third-party cookies — most modern browsers block such access by default to protect user privacy. Since embedded content won't know what a browser's behavior is going to be in this regard, it's best to always check whether the embedded {{htmlelement("iframe")}} has storage access before attempting to read or write a cookie. This is particularly true for {{domxref("Document.cookie")}} access, as browsers will often return an empty cookie jar when third-party cookie access is blocked.
 
-In the example below, we show how an embedded cross-site {{htmlelement("iframe")}} can access unpartitioned cookies under a browser storage access policy that blocks third-party cookie access.
+In the example below, we show how an embedded cross-site {{htmlelement("iframe")}} can access third-party cookies under a browser storage access policy that would otherwise block access to them.
 
 ## Allowing a sandboxed \<iframe> to use the API
 
@@ -34,10 +36,10 @@ Now on to the code executed inside the embedded document. In this code:
 1. We first use feature detection (`if (document.hasStorageAccess) {}`) to check whether the API is supported. If not, we run our code that accesses cookies anyway, and hope that it works. It should be coded defensively to deal with such eventualities anyway.
 2. If the API is supported, we call `document.hasStorageAccess()`.
 3. If that call returns `true`, it means this {{htmlelement("iframe")}} has already obtained access, and we can run our code that accesses cookies right away.
-4. If that call returns `false`, we then call {{domxref("Permissions.query()")}} to check whether permission to access unpartitioned cookies has already been granted (i.e. to another same-site embed). We wrap this whole section in a [`try...catch`](/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) block because some browsers don't support the `"storage-access"` permission, which can cause the `query()` call to throw. If it throws, we report that to the console and try running the cookie code anyway.
+4. If that call returns `false`, we then call {{domxref("Permissions.query()")}} to check whether permission to access third-party cookies has already been granted (i.e., to another same-site embed). We wrap this whole section in a [`try...catch`](/en-US/docs/Web/JavaScript/Reference/Statements/try...catch) block because [some browsers don't support the `"storage-access"` permission](/en-US/docs/Web/API/Storage_Access_API#api.permissions.permission_storage-access), which can cause the `query()` call to throw. If it throws, we report that to the console and try running the cookie code anyway.
 5. If the permission state is `"granted"`, we immediately call `document.requestStorageAccess()`. This call will automatically resolve, saving the user some time, then we can run our code that accesses cookies.
 6. If the permission state is `"prompt"`, we call `document.requestStorageAccess()` after user interaction. This call may trigger a prompt to the user. If this call resolves, then we can run our code that accesses cookies.
-7. If the permission state is `"denied"`, the user has denied our requests to access unpartitioned cookies, and our code cannot make use of them.
+7. If the permission state is `"denied"`, the user has denied our requests to access third-party cookies, and our code cannot use them.
 
 ```js
 function doThingsWithCookies() {
@@ -52,10 +54,10 @@ async function handleCookieAccess() {
   } else {
     const hasAccess = await document.hasStorageAccess();
     if (hasAccess) {
-      // We have access to unpartitioned cookies, so let's go
+      // We have access to third-party cookies, so let's go
       doThingsWithCookies();
     } else {
-      // Check whether unpartitioned cookie access has been granted
+      // Check whether third-party cookie access has been granted
       // to another same-site embed
       try {
         const permission = await navigator.permissions.query({
@@ -80,7 +82,7 @@ async function handleCookieAccess() {
             }
           });
         } else if (permission.state === "denied") {
-          // User has denied unpartitioned cookie access, so we'll
+          // User has denied third-party cookie access, so we'll
           // need to do something else
         }
       } catch (error) {
@@ -92,4 +94,88 @@ async function handleCookieAccess() {
 }
 ```
 
-> **Note:** `requestStorageAccess()` requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click ({{Glossary("transient activation")}}), or if permission was already granted previously. If permission was not previously granted, they need to be run inside some kind of user gesture-based event handler, as shown above.
+> **Note:** `requestStorageAccess()` requests are automatically denied unless the embedded content is currently processing a user gesture such as a tap or click ({{Glossary("transient activation")}}), or if permission was already granted previously. If permission was not previously granted, `requestStorageAccess()` requests must be run inside a user gesture-based event handler, as shown above.
+
+### Related website sets
+
+The Chrome-only [related website sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) feature can be considered a progressive enhancement mechanism that works alongside the Storage Access API — supporting browsers grant default third-party cookie access between websites in the same set. This means not having to go through the usual user permission prompt workflow described above, meaning a more user-friendly experience for users of sites in the set.
+
+## Requesting storage access from the top-level site on behalf of embedded resources
+
+The Storage Access API features above allow an embedded document to request its own third-party cookie access. There is an additional experimental method available, {{domxref("Document.requestStorageAccessFor()")}}, a proposed extension to the Storage Access API that allows top-level sites to request storage access on behalf of specific related origins.
+
+The `requestStorageAccessFor()` method addresses challenges in adopting the Storage Access API on top-level sites that use cross-site images or scripts requiring cookies. It can enable third-party cookie access for cross-site resources directly embedded into the top-level site that are unable to request their own storage access, for example via {{htmlelement("img")}} or {{htmlelement("script")}} elements.
+
+For `requestStorageAccessFor()` to work, both the calling top-level page and the embedded resource it is requesting storage access for need to be part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets).
+
+Typical usage of `requestStorageAccessFor()` looks like this (this time written in regular promise-style rather than async/await):
+
+```js
+navigator.permissions
+  .query({
+    name: "top-level-storage-access",
+    requestedOrigin: "https://example.com",
+  })
+  .then((permission) => {
+    if (permission.state === "granted") {
+      // Permission has already been granted
+      // No need to call requestStorageAccessFor() again, just start using cookies
+      doThingsWithCookies();
+    } else if (permission.state === "prompt") {
+      // Need to call requestStorageAccessFor() after a user interaction
+      btn.addEventListener("click", () => {
+        // Request storage access
+        rSAFor();
+      });
+    } else if (permission.state === "denied") {
+      // User has denied third-party cookie access, so we'll
+      // need to do something else
+    }
+  });
+
+function rSAFor() {
+  if ("requestStorageAccessFor" in document) {
+    document.requestStorageAccessFor("https://example.com").then(
+      (res) => {
+        doThingsWithCookies();
+      },
+      (err) => {
+        // Handle errors
+      },
+    );
+  }
+}
+```
+
+> **Note:** Unlike with `requestStorageAccess()`, Chrome doesn't check for an interaction in a top-level document within the last 30 days when `requestStorageAccessFor()` is called because the user is already on the page. See [Browser-specific variations > Chrome](/en-US/docs/Web/API/Storage_Access_API#chrome) for more details of this behavior.
+
+When querying permission status for storage access requests made on behalf of another origin, the permission name used is different from the rest of the Storage Access API: `"top-level-storage-access"` rather than `"storage-access"`. In the above code, we use the following call:
+
+```js
+navigator.permissions.query({
+  name: "top-level-storage-access",
+  requestedOrigin: "https://example.com",
+});
+```
+
+to discover if the origin has previously been granted permission or if cookie access still needs to be requested.
+
+- If the permission status is `"granted"` we can start using cookies; `requestStorageAccessFor()` was already called, so there is no need to call it again.
+- If the permission status is `"prompt"` we need to call `document.requestStorageAccessFor("https://example.com")` from within a user gesture, such as a button click.
+
+After the `"top-level-storage-access"` permission is granted, cross-site requests will include cookies if they include [CORS](/en-US/docs/Web/HTTP/CORS) / [`crossorigin`](/en-US/docs/Web/HTML/Attributes/crossorigin), so sites may want to wait before triggering a request. Such requests must use the [`credentials: "include"`](/en-US/docs/Web/API/fetch#credentials) option and resources must include the `crossorigin="use-credentials"` attribute.
+
+For example:
+
+```js
+function checkCookie() {
+  fetch("https://example.com/getcookies.json", {
+    method: "GET",
+    credentials: "include",
+  })
+    .then((response) => response.json())
+    .then((json) => {
+      // Do something
+    });
+}
+```
diff --git a/files/en-us/web/http/cookies/index.md b/files/en-us/web/http/cookies/index.md
index 2d86e16566f6e88..06ce8484240d140 100644
--- a/files/en-us/web/http/cookies/index.md
+++ b/files/en-us/web/http/cookies/index.md
@@ -198,9 +198,13 @@ A cookie is associated with a particular domain and scheme (such as `http` or `h
 If the cookie domain and scheme match the current page, the cookie is considered to be from the same site as the page, and is referred to as a _first-party cookie_.
 
 If the domain and scheme are different, the cookie is not considered to be from the same site, and is referred to as a _third-party cookie_.
-While the server hosting a web page sets first-party cookies, the page may contain images or other components stored on servers in other domains (for example, ad banners) that may set third-party cookies.
-These are mainly used for advertising and tracking across the web.
-For example, the [types of cookies used by Google](https://policies.google.com/technologies/types).
+While the server hosting a web page sets first-party cookies, the page may contain components stored on servers in other domains, such as images or other documents embedded in {{htmlelement("iframe")}}s. These components may set third-party cookies.
+
+> **Note:** Third-party cookies are sometimes referred to as _cross-site cookies_. This is arguably a more accurate name, as _third-party cookies_ imply ownership by a third-party company or organization. However, the behavior and potential issues are the same whether or not you own all the involved sites.
+
+Typical use cases for third-party cookies include sharing user profile information or collecting analytics across different related domains. They are also often used for advertising and tracking users across the web.
+
+> **Note:** Companies should disclose the types of cookies they use on their sites for transparency purposes and to comply with [regulations](#cookie-related_regulations). For example, see [Google's notice on the types of cookies it uses](https://policies.google.com/technologies/types) and Mozilla's [Websites, Communications & Cookies Privacy Notice](https://www.mozilla.org/en-US/privacy/websites/#cookies).
 
 A third-party server can create a profile of a user's browsing history and habits based on cookies sent to it by the same browser when accessing multiple sites.
 Firefox, by default, blocks third-party cookies that are known to contain trackers.
diff --git a/files/en-us/web/privacy/index.md b/files/en-us/web/privacy/index.md
index 6a4c59dbfd542df..e0547c1f0cf536b 100644
--- a/files/en-us/web/privacy/index.md
+++ b/files/en-us/web/privacy/index.md
@@ -125,8 +125,8 @@ Some of the most developed parts of the privacy sandbox project are as follows:
 
 - [Cookies Having Independent Partitioned State (CHIPS)](/en-US/docs/Web/Privacy/Partitioned_cookies)
   - : Also known as **partitioned cookies**, CHIPs allows developers to opt a cookie into partitioned storage, with a separate cookie jar per top-level site.
-- [First-party sets](https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/)
-  - : A mechanism for a company to declare relationships between different origins. Supporting browsers will then allow limited third-party cookie access across those origins for specific purposes.
+- [Related website sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets)
+  - : A mechanism for a company to declare relationships between different sites. Supporting browsers will then allow limited third-party cookie access across those sites for specific purposes, via the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API).
 - Third-party cookie default
   - : Chrome does not yet block third-party cookies by default, but this can be set by users in Chrome settings.
 
@@ -203,7 +203,7 @@ Earlier on we discussed tracking, and some of the unethical purposes they are us
 Also recall from earlier that browsers are implementing a number of technologies to limit the usage of tracking cookies, especially cross-site cookies, with the eventual aim of removing them altogether. It is a good idea to prepare for this, by limiting the amount of tracking activities you rely on, and/or implementing desired information persistence in other ways. For example:
 
 - Use an alternative client-side storage mechanism such as [Web Storage](/en-US/docs/Web/API/Web_Storage_API) to persist data. This does have the downside that the data is stored per-origin, so it can't be shared.
-- Use a technology such as [IFrame credentialless](/en-US/docs/Web/Security/IFrame_credentialless), [First-party sets](https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/) and/or the [Storage access API](/en-US/docs/Web/API/Storage_Access_API) to allow your sites to opt in to using cross-site cookies in a safe, controlled way, or block them altogether. These currently have limited browser support.
+- Use a technology such as the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) to allow your sites to opt-in to using cross-site cookies in a safe and controlled way.
 - Use a server-side solution for data persistence.
 
 > **Note:** To reiterate what we said earlier, make sure you clearly communicate to your users what you are doing via your privacy policy, allow them to opt-in, and easily delete their data if they change their mind at a later date.
diff --git a/files/en-us/web/privacy/partitioned_cookies/index.md b/files/en-us/web/privacy/partitioned_cookies/index.md
index 64e7b14e5f89eeb..0ee0a3b4e0587b3 100644
--- a/files/en-us/web/privacy/partitioned_cookies/index.md
+++ b/files/en-us/web/privacy/partitioned_cookies/index.md
@@ -54,8 +54,6 @@ Blocking all third-party cookies would currently be problematic, for example in
 2. The storage key for the cookie would be `{("https://shoppy.example"), ("3rd-party.example/chat")}`.
 3. The user visits various subdomains in the quest to solve their problem that also embed `https://3rd-party.example/chat`, including `https://support.shoppy.example` and `https://checkout.shoppy.example`. The new embedded instances are able to access the cookie because the partition key still matches.
 
-> **Note:** [First-party sets](https://github.com/WICG/first-party-sets) is a proposal that aims to allow site owners to declare a collection of related domains that will act like they are a single top-level site, for the purposes of cookie access mechanisms like CHIPS.
-
 ## Specifications
 
 {{Specifications}}
diff --git a/files/en-us/web/security/index.md b/files/en-us/web/security/index.md
index 394fdf09ebdc7ac..c39828b06d256c1 100644
--- a/files/en-us/web/security/index.md
+++ b/files/en-us/web/security/index.md
@@ -92,7 +92,7 @@ You should prepare for the removal of cross-site cookies by limiting the amount
 For example:
 
 - Use an alternative client-side storage mechanism such as the [Web Storage API](/en-US/docs/Web/API/Web_Storage_API) to persist data. Web storage does have the downside that the data is stored per-origin, so it can't be shared. Note that web storage has two variants — `sessionStorage` and `localStorage`. We would recommend using `sessionStorage` for extra security, as data only persists for the lifetime of the window or tab it exists in. `localStorage` data persists even after the window or tab is closed and reopened. This means that there is a higher chance of it falling into the wrong hands, for example on a shared workstation.
-- Use a technology such as [IFrame credentialless](/en-US/docs/Web/Security/IFrame_credentialless), [First-party sets](https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/) and/or the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) to allow your sites to opt-in to using cross-site cookies in a safe and controlled way or block them altogether. These technologies currently have limited browser support.
+- Use a technology such as the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) to allow your sites to opt-in to using cross-site cookies in a safe and controlled way.
 - Use a server-side solution for data persistence.
 
 See our [privacy guide](/en-US/docs/Web/Privacy) and particularly [Cut down on tracking cookies](/en-US/docs/Web/Privacy#cut_down_on_tracking_cookies) for more context around this.
diff --git a/files/jsondata/GroupData.json b/files/jsondata/GroupData.json
index 734b1ac00d31034..be461b74ca8290b 100644
--- a/files/jsondata/GroupData.json
+++ b/files/jsondata/GroupData.json
@@ -1351,11 +1351,15 @@
     },
     "Storage Access API": {
       "overview": ["Storage Access API"],
-      "guides": ["/docs/Web/API/Storage_Access_API/Using"],
+      "guides": [
+        "/docs/Web/API/Storage_Access_API/Using",
+        "/docs/Web/API/Storage_Access_API/Related_website_sets"
+      ],
       "interfaces": [],
       "methods": [
         "Document.hasStorageAccess()",
-        "Document.requestStorageAccess()"
+        "Document.requestStorageAccess()",
+        "Document.requestStorageAccessFor()"
       ],
       "properties": [],
       "events": []