From 4e36abe600440f1a85871295ccad954e0790d5ea Mon Sep 17 00:00:00 2001
From: PieterKas <90690777+PieterKas@users.noreply.github.com>
Date: Mon, 16 Dec 2024 12:55:53 +0000
Subject: [PATCH] Clarifying origin of initial client token (#114)

Proposed text to clarify what "its token" might be and where it comes from as raised in issue #75 by @aaronpk
---
 draft-ietf-oauth-identity-chaining.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/draft-ietf-oauth-identity-chaining.md b/draft-ietf-oauth-identity-chaining.md
index b2f1c89..f741301 100644
--- a/draft-ietf-oauth-identity-chaining.md
+++ b/draft-ietf-oauth-identity-chaining.md
@@ -116,11 +116,11 @@ The identity and authorization chaining flow outlined below describes how a comb
 ~~~~
 {: title='Identity and Authorization Chaining Flow'}
 
-The flow illustrated in Figure 1 shows the steps the client in trust Domain A needs to perform to access a protected resource in trust domain B. In this flow, the client has a way to discover the authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation). It includes the following:
+The flow illustrated in Figure 1 shows the steps the client in trust Domain A needs to perform to access a protected resource in trust domain B. In this flow, the client is in posession of a token that an authorization server will accept as part of a token exchange flow as defined in [Token Exchange](#token-exchange). How the client obtained this token is out of scope of this specification. The client has a way to discover the authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation). It includes the following:
 
 * (A) The client of Domain A needs to discover the authorization server of Domain B. See [Authorization Server Discovery](#authorization-server-discovery).
 
-* (B) The client exchanges its token at the authorization server of its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B. See [Token Exchange](#token-exchange).
+* (B) The client exchanges a token it has in its posession at the authorization server of its own domain (Domain A) for a JWT authorization grant that can be used at the authorization server in Domain B. See [Token Exchange](#token-exchange).
 
 * (C) The authorization server of Domain A processes the request and returns a JWT authorization grant that the client can use with the authorization server of Domain B. This requires a trust relationship between Domain A and Domain B (e.g., through federation).