Original text:
2.5. <del> fig-arch shows how Txn-Tokens are used in an a multi-workload environment. (A) The user accesses a resource server and present an Access Token obtained from an Authorization Server using an OAuth 2.0 or an OpenID Connect flow. (B) The resource server is implemented as a workload (Workload 1) and requests a Leaf Txn-Token from the Transaction Token Server using the Token Exchange protocol RFC8693. (C) The Transaction Token Service returns a Leaf Txn-Token containing the requested claims that establish the identity of the original caller as well as additional claims that can be used to make authorization decisions and establish the call chain. (D) The Resource Server (Workload 1) calls Workload 2 and passes the Leaf Txn-Token for Workload 1.  Workload 2 validates the Txn- Token and makes an authorization decision by combining contextual information at its disposal with information in the Txn-Token to make an authorization decision to accept or reject the call. (E) Workload 2 is not required to add aditional information to the Txn-Token and passes the unmodified Txn-Token for Workload 1 to Workload 3.  Workload 3 validates the Txn-Token and makes an authorization decision by combining contextual information at its disposal with information in the Txn-Token to make an authorization decision to accept or reject the call. (F) Workload 3 generates a Nested Txn-Token that includes additional call chain information. (G) Workload 3 sends the Nested Txn-Token to Workload 4.  Workload 4 validates the Nested Txn-Token and makes an authorization decision by combining contextual information at its disposal with information in the Nested Txn-Token to make an authorization decision to accept or reject the call. (H) Workload 4 needs a Txn-Token containing information from the Authroization Server and requests a new Leaf Transaction Token (Leaf Txn-Token) from the Transaction Token Server using the Token Exchange protocol RFC8693. (I) The Transaction Token Service returns a Leaf Transaction Token (Leaf Txn-Token) containing the requested claims that include the call chain information included in the Txn-Token as well as additional claims needed. (J) Workload 4 sends the Txn-Token to the Workload 5, who verifies it and extracts claims and combine it with contextual information for use in authroization decisions.  Other workloads continue to pass Txn-Tokens, generate Nested Txn-Tokens or request new Txn- Tokens. </del>  <del> (K) Workload n is the final workload in the call chain.  It verifies the received Txn-Token, extracts claims and combine it with contextual information for use in authroization decisions. </del>  3.

Reviewer comments:
Based on discussion and feedback in the IETF 117 Session, I've split the single flow diagram into three different flow diagrams.

Revised text:
2.5.  <ins> 2.5.1. fig-arch-basic shows the basic flow of how Txn-Tokens are used in an a multi-workload environment. External endpoint is invoked using conventional authorization scheme such as access token External endpoint provides context and incoming authorization (e.g. access token) to the Txn-Token Service Txn-Token Service mints a Txn-Token that provides immutable context for the transaction and returns it to the requester The external endpoint initiates a call to an internal microservice and provides the Txn-Token as authorization Subsequent calls to other internal microservices use the same Txn- Token to authorize calls Responses are provided to callers based on successful authorization by the invoked microservices. External client is provided a response to the external invocation 2.5.2. fig-arch-nested shows an internal microservice generating a Nested Txn-Token in the flow In the diagram above, steps 1-5 are the same as in basic-flow. An internal microservice determines it needs to generate a Nested Txn-Token.  It uses its own private key to generate a Nested Txn- Token. The internal microservice uses the Nested Txn-Token to authorize calls to downstream services Responses are provided to callers based on successful authorization by the invoked microservices. External client is provided a response to the external invocation 2.5.3. An intermediate service may decide to obtain a replacement Txn-Token from the Txn-Token service.  That flow is described below in In the diagram above, steps 1-5 are the same as in An intermediate service determines that it needs to obtain a Replacement Txn-Token.  It requests a Replacement Txn-Token from the Txn-Token Service.  It passes the incoming Txn-Token in the request, along with any additional context it needs to send the Txn-Token Service. The Txn-Token Service responds with a replacement Txn-Token The service that requested the Replacement Txn-Token uses that Txn-Token for downstream call authorization Responses are provided to callers based on successful authorization by the invoked microservices. </ins>  <ins> External client is provided a response to the external invocation </ins> 3.