From d68616b155a7cb4942b842b4af34842a706a00e6 Mon Sep 17 00:00:00 2001
From: Jessie Mongeon <133128541+jessiemongeon1@users.noreply.github.com>
Date: Thu, 25 Apr 2024 10:12:08 -0500
Subject: [PATCH 1/2] Update alternative-origins.mdx

---
 .../internet-identity/alternative-origins.mdx          | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx b/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
index 7832c7a40b..0783223f0b 100644
--- a/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
+++ b/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
@@ -31,11 +31,15 @@ For more information, see the [Internet Identity specification](https://github.c
 
 ## Configuring alternative origins
 
-For this example, you will have two domains, **A** and **B**. **A** will be the canonical origin, and **B** will be the alternative domain. To help illustrate this model, consider this website, which is hosted both at https://internetcomputer.org and https://hwvjt-wqaaa-aaaam-qadra-cai.icp0.io.
+For this example, you will have two domains, **A** and **B**. **A** will be the canonical origin, and **B** will be the alternative domain. To help illustrate this model, consider this website, which is hosted both at `https://yourcustomdomain.com` and `https://www.yourdomain.com`.
 
-In this example, **A** would be the canister ID, or https://hwvjt-wqaaa-aaaam-qadra-cai.icp0.io.
+In this example, **A** would be `https://yourcustomdomain.com`.
 
-**B** would be the alternative origin, or https://internetcomputer.org.
+**B** would be the alternative origin, or `https://www.yourdomain.com`.
+
+:::info
+Your custom domains must be registered with the boundary nodes.
+:::
 
 ### Listing origins
 

From fdf19e97f2c661d330a8ae1378c0051f0197985b Mon Sep 17 00:00:00 2001
From: Jessie Mongeon <133128541+jessiemongeon1@users.noreply.github.com>
Date: Mon, 29 Apr 2024 09:13:48 -0500
Subject: [PATCH 2/2] Update alternative-origins.mdx

---
 .../user-login/internet-identity/alternative-origins.mdx      | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx b/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
index 0783223f0b..c7fa5f3ef6 100644
--- a/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
+++ b/docs/developer-docs/web-apps/user-login/internet-identity/alternative-origins.mdx
@@ -43,7 +43,7 @@ Your custom domains must be registered with the boundary nodes.
 
 ### Listing origins
 
-For origin **A**, you will need to provide a file that tells Internet Identity that **B** is a valid origin. You'll be placing the config files in `src/assets` directory of your frontend canister. If your frontend canister is currently configured to deploy assets from a `dist` folder, make sure to update the `sources` for your canister to include both:
+On origin **A**, you will need to provide a file that tells Internet Identity that **B** is a valid alternative origin. You'll be placing the config files in `src/assets` directory of your frontend canister. If your frontend canister is currently configured to deploy assets from a `dist` folder, make sure to update the `sources` for your canister to include both:
 
 ```json
 "source": [
@@ -116,4 +116,4 @@ Then, configure the `.well-known` directory to be included, with:
 
 This includes a general rule to not ignore the `.well-known` directory, and rules to deliver the `ii-alternative-origins` with access control and content-type headers.
 
-Then, all you need to do is deploy your canister. When you attempt to authenticate from origin **B** from then on, you will get back the same principal you get while using **A**.
+Then, all you need to do is deploy your canister. When you attempt to authenticate from origin **B** from then on, you will get back the same principal you get while using **A**. This needs to be supplemented with the information configured with the `AuthClient` to specifically request to use domain **A** when authenticating from **B**, i.e. set `derivationOrigin` in call options to `login`.