Original text:
2.2. <del> The Identity Chaining flow outlined below describes how these specifications are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used when the resource server acts as the client an another that describes what happens when the authorization server acts as the client. </del>  The flow illustrated in Figure 1 shows the steps the client in trust <del> domain A needs to perform to access a protected resource in trust </del>  domain B.  In this flow, the client has a way to discover the <del> authroization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g. through federation).  It includes the following: </del>  (A) The client of Domain A needs to discover the authorization server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of its own domain (Domain A) for an authorization grant that can be <del> used with the authorization server in Domain B.  See token- exchange. </del>  (C) The authorization server of Domain A processes the request and <del> returns an authorization grant that the client can use with Domain B.  This requires a trust relationship between Domain A and Domain B (e.g. through federation). </del>  (D) The client presents the authorization grant to the <del> authorization server of Domain B.  See present-authorization- grant. </del>  (E) Authorization server of Domain B validates the authorization grant and returns an access token.

Reviewer comments:
Includes updates based on
Original: URL Kelly's editorial changes: identity-chaining-draft-URL

Revised text:
2.2.  <ins> The Identity Chaining flow outlined below describes how a combination of OAuth 2.0 Token Exchange RFC8693 and Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants RFC7521 are used to address the use cases identified.  The appendix include two additional examples that describe how this flow is used.  In one example, the resource server acts as the client and in the other, the authorization server acts as the client. </ins> The flow illustrated in Figure 1 shows the steps the client in trust  <ins> Domain A needs to perform to access a protected resource in trust </ins> domain B.  In this flow, the client has a way to discover the  <ins> authorization server in Domain B and a trust relationship exists between Domain A and Domain B (e.g., through federation).  It includes the following: </ins> (A) The client of Domain A needs to discover the authorization server of Domain B.  See authorization-server-discovery. (B) The client exchanges its token at the authorization server of its own domain (Domain A) for an authorization grant that can be  <ins> used at the authorization server in Domain B.  See token-exchange. </ins> (C) The authorization server of Domain A processes the request and  <ins> returns an 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). </ins> (D) The client presents the authorization grant to the  <ins> authorization server of Domain B.  See authorization-grant. </ins> (E) Authorization server of Domain B validates the authorization grant and returns an access token.