Original text:
authorization by verifying that the authenticated identity has the appropriate permissions to access the requested resources and perform required actions.  This process involves evaluating the security <del> context described previously.  The workload validates security context, checks validity of permissions against its security policies to ensure that only authorized actions are allowed. </del>  3.2.4. <del> TBD. </del>  3.2.5. <del> TBD. </del>  3.2.6.

Reviewer comments:
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.

Revised text:
authorization by verifying that the authenticated identity has the appropriate permissions to access the requested resources and perform required actions.  This process involves evaluating the security  <ins> context described previously.  The workload validates the security context, and checks the validity of permissions against its security policies to ensure that only authorized actions are allowed. </ins> 3.2.4.  <ins> When source workloads send authenticated requests to destination workloads, those destination workloads may rely on upstream dependencies to fulfill such requests.  Such access patterns are increasingly common in a microservices architecture.  While X.509 certificates can be used for point-to-point authentication, such services relying on upstream microservices for answers, may use delegation and/or impersonation semantics as described in RFC 8693 OAuth 2.0 Access Token Exchange. WIMSE credentials constrain the subjects and actors identified in delegation and impersonation tokens to be bound by TrustDomains, and to follow their issuing authorities' trust configurations.  Upstream workloads should consider the security context of delegation and/or impersonation tokens within and across Trust Domains, when arriving at authorization decisions. </ins> 3.2.5.  <ins> Source workloads may send authenticated asynchronous and batch requests to destination workloads.  A destination workload may need to fulfill such requests with requests to authorized upstream protected resources and workloads, after the source workload credentials have expired.  Credentials identifying the original source workload as subject may need to be obtained from the credential issuing authority with appropriately-downscoped context needed access to upstream workloads.  These credentials should identify the workload as the actor in the actor chain, but may also identify other principals that the action is taken on behalf.  To mitigate risks associated with long-duration credentials, these credentials should be bound to the workload identity credential such as an X.509 certificate or Workload Identity Token (WIT) of the acting service performing asynchronous computation on the source workload's behalf. </ins> 3.2.6.