diff --git a/application-workflow.md b/application-workflow.md
index c26b41f..0d3acfe 100644
--- a/application-workflow.md
+++ b/application-workflow.md
@@ -16,7 +16,7 @@ In this example, Alice is already logged into her identity provider (e.g. via so
 2. DecentPhotos is an autonomous agent that runs on its own (from some cloud provider). To do this, Alice needs to give DecentPhotos some authority to access the photos in her pod on her behalf.
 3. Alice goes to `www.decentphotos.example` to connect it to her pod. She enters her WebID so DecentPhotos can lookup who her IdP (Identity Provider) is, and clicks a 'Connect' button.
 4. `decentphotos.example` (RP) reacts to the 'Connect' button being clicked by responding with a redirect. This redirect sends Alice's browser to the authorization endpoint at `alice.example` because it is her IdP, including in the request a client_id of the DecentPhotos application/agent WebID (`https://decentphotos.example/appid#this`).
-5. Alice’s browser makes the request to the redirect URL (which is the authorization endpoint at IdP), identifying itself by the application WebID (client_id), and also passing along an optional scope and the redirect_uri, which is a callback to `decentphotos.example`, to be used after Alice has proved she has control of `alice.example` (RS)
+5. Alice’s browser makes the request to the redirect URL (which is the authorization endpoint at IdP), identifying itself by the application WebID (client_id), and also passing along an optional scope and the redirect_uri, which is a callback to `decentphotos.example`, to be used after Alice has proved she has control of `alice.example` (RS). The redirect_uri MUST have the same host as the client_id.
 6. Because Alice is already logged in at her IdP, she doesn’t need to enter her username and password again (she’s already got a token proving she is THE ALICE).
 7. The authorization endpoint at `alice.example` (IdP) asks Alice if she wants to authorize DecentPhotos (RP) to access her Pod at a given scope. She has the ability here to further narrow this to only a subset of her photo library if she likes. Upon her confirmation here, DecentPhotos will be added as a trusted application in her WebID Profile, identified by its application/agent WebID (`https://decentphotos.example/appid#this`), and Alice's private photos folder at `https://alice.example/pics/private` will have its ACL updated to allow DecentPhotos (RP), identified by `https://decentphotos.example/appid#this`, read/write access to that folder and its contents.
 8. Alice submits this and is sent (redirected) to the redirect_uri / callback which was provided by DecentPhotos (RP) in Step #5, along with an authorization code. Alice's browser now makes a new GET request to `decentphotos.example` (RP), with that authorization code included.
diff --git a/example-workflow.md b/example-workflow.md
index c761b1c..45591fc 100644
--- a/example-workflow.md
+++ b/example-workflow.md
@@ -81,7 +81,9 @@ Relying Party (`bob.example`) have interacted, `bob.example` must dynamically re
 itself *as a client/relying party* to `alice.example`. Bob's POD (in the RP role)
 performs dynamic registration with Alice's POD (in the Provider role), and as
 a result `bob.example` receives its very own `client_id` which identifies it
-uniquely as a Relying Party to `alice.example`.
+uniquely as a Relying Party to `alice.example`. The `client_id` MUST be identical to the host
+of the client's `Origin` header (`bob.example`). This will be used later to validate
+redirects.
 
 If this is the first time a Provider and a Relying Party are encountering each
 other, the RP must perform
@@ -122,10 +124,10 @@ verification.
 
 *Example 1:* `alice.example`, in the Provider role, verifies the Relying Party
 (`bob.example`) that initiated the authentication process, and redirects Alice's
-browser to a pre-registered `redirect_uri` that `bob.example` provided during
-the previous Dynamic Registration step. So, Alice's browser gets redirected
-to `https://bob.example/auth-callback` (which is the URI Bob's POD uses as an OIDC
-`redirect_uri` endpoint).
+browser to a `redirect_uri` provided by `bob.example`. The `redirect_uri` MUST
+have the same host as the application's `client_id`. So, Alice's browser gets
+redirected to `https://bob.example/auth-callback` (which is the URI Bob's POD uses
+as an OIDC `redirect_uri` endpoint).
 
 (**Optimization**) The Relying Party may choose to establish a user session
 (via a browser cookie), so that the user can skip Steps 1-5 in subsequent