From c77faf6c177d01fdf7b862bf5b974b9a3f0a19e3 Mon Sep 17 00:00:00 2001
From: PieterKas <90690777+PieterKas@users.noreply.github.com>
Date: Tue, 10 Dec 2024 09:59:00 +0000
Subject: [PATCH] Clarify text describing Step F in Figure 1 (#113)

See issue #104
---
 draft-ietf-oauth-identity-chaining.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/draft-ietf-oauth-identity-chaining.md b/draft-ietf-oauth-identity-chaining.md
index 6ad9153..b2f1c89 100644
--- a/draft-ietf-oauth-identity-chaining.md
+++ b/draft-ietf-oauth-identity-chaining.md
@@ -128,7 +128,7 @@ The flow illustrated in Figure 1 shows the steps the client in trust Domain A ne
 
 * (E) Authorization server of Domain B validates the JWT authorization grant and returns an access token.
 
-* (F) The client now possesses an access token to access the protected resource in Domain B.
+* (F) The client in Domain A uses the access token received from the authorization server in Domain B to access the protected resource in Domain B.
 
 ## Authorization Server Discovery
 This specification does not define authorization server discovery. A client MAY maintain a static mapping or use other means to identify the authorization server. The `authorization_servers` property in {{I-D.ietf-oauth-resource-metadata}} MAY be used.