Original text:
Abstract <del> The use of the OAuth 2.0 framework for workload orchestration systems poses a challenge as managing secrets, such as client_id and </del>  client_secret, can be complex and error-prone.  "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads. <del> This document specifies the use of JWTs for client credentials in workload orchestration systems to improve interoperability in orchestration systems, to reduce complexity for developers, and motivates authorization server to support RFC 7523. </del>  1. In workload scenarios dedicated management entities, also called "control plane" entities, are used to start, monitor and stop <del> workloads dynamically.  These workloads typically run micro services that interact with each other and with other entities on the corporate network or on the Internet.  When one workload, acting as an OAuth client, wants to gain access to a protected resource hosted on another workload or on the Internet (referred here generically as a resource server) then authorization is typically required. OAuth has been designed to offer help in scenarios where access to protected resources needs to be managed dynamically in a distributed system. Each workload instance has to be provisioned with unique credentials. However, these credentials have to be configured prior and are then attached to the workload.  In addition, these credentials do not have an automated rotation mechanism and are valid for an unspecified amount of time. This requires manual configuration effort and the missing automated rotation mechanism introduce inconvenience and increase the attack surface. "Service account token volume projection" is a feature of workload orchestration systems that allows users to create JSON Web Tokens (JWTs) for their workloads.  These JWTs, referred as Service Account Tokens, can be used as client credentials, as specified in RFC 7523 RFC7523.  As these tokens are managed by the "control plane" and simply mounted to the filesystem, a workload just needs to consume this file and present it to the authorization server.  In addition, service account token volume projection allows an expiration time on these JWTs to be set, allowing automated rotation of these credentials.  Finally, the private key for signing these tokens is managed by the "control plane", hence removing the manual effort of configuring the client_id and client_secret. However, there is currently no standardized way to manage these Service Account Tokens across workload orchestrators.  This leads to inconsistencies, and additional effort for developers as they need to support different client authentication mechanisms.  In the worst case, this approach is ignored in favor of client_id and client_secret. </del>  This specification specifies the use of Service Account Tokens in <del> workload orchestration systems, which provides a secure and scalable </del>  way to create and manage these tokens, and ensures interoperability with existing OAuth-based authorization systems. <del> When OAuth is used as part of the control plane entities, a Service Account Token is provisioned to the workload via the Agent.  This interaction is shown in fig-arch. </del> To distinguish the entities, we use the term "Control Plane" to refer to the OAuth 2.0 Authorization Server that is part of the cluster's control plane.  Since there are also two access tokens in play, we

Reviewer comments:
Taking our last conversation into account I wanted to contribute my take on the problem and wrote the introduction the way I see it. This is not a version that can be merged, but the best way to show it in a diff and allow comments. Let me know what you think.

Revised text:
Abstract  <ins> The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and </ins> client_secret, can be complex and error-prone.  "Service account token volume projection", a term introduced by Kubernetes, provides a way of injecting JSON Web Tokens (JWTs) to workloads.  <ins> This document describes the current best practices to avoid client_secret provisioning and leverage platform attestation to receive access tokens from an OAuth 2.0 authorization server via RFC 7523. </ins> 1. In workload scenarios dedicated management entities, also called "control plane" entities, are used to start, monitor and stop  <ins> workloads dynamically.  These workloads often communicate with one another and with other entities within the company network or online. When one workload, acting as an OAuth client, wants to gain access to a protected resource hosted on another workload or on the Internet (referred here generically as a resource server) then authorization is typically required. In order to authenticate workloads accessing resources, each workload instance has to be provisioned with unique credentials.  This is a challenge in environments where workloads start, stop, relocate and scale dynamically.  Manual configuration, rotation and overall management comes with at best management overhead, at worst results in security risks such as credential exposure. "Service account token volume projection" is a feature of the container orchestration system Kubernetes that allows users to attach platform attestated tokens to their workloads.  Workloads can use this token to authenticate themselves towards APIs of the platform control plane.  Even though this token is used for access it can be more considered an ID Token rather than an Access Token in the OAuth context.  Workloads don't get issued a refresh token nor does authorization or consent play a role.  It is merely a proof that the workloads is who it claims to be.  Workloads have various options available to retrieve such token from the Kubernetes platform, for example via a "TokenRequest" API invoked by business logic or "Token volume projection" which mounts the token into the file system of the workloads and keeps it up to date there.  "Token volume projection" having the advantage of not requiring any manual effort by the application besides reading a file. Whilst the original purpose of the service account token was to authenticate access to the control plane API the industry has recognized its low maintainance and platform attestation capabilities and started using it as a JWT client assertion as specified in RFC7523.  The token is presented to a authorization server as a client assertion.  The authorization servers validates the signature of the presented assertion via OIDC metadata or RFC8414 and leverages the claims in the token to authenticate the client.  Overall, the authorization server trusts the platform control plane with the issuance and delivery of these credentials.  The authorization server responds with an Access Token the workload can use to access a OAuth2 protected resource on a resource server. fig-arch illustrates the interaction in the architecture graphically. </ins> This specification specifies the use of Service Account Tokens in  <ins> container orchestration systems, which provides a secure and scalable </ins> way to create and manage these tokens, and ensures interoperability with existing OAuth-based authorization systems.  To distinguish the entities, we use the term "Control Plane" to refer to the OAuth 2.0 Authorization Server that is part of the cluster's control plane.  Since there are also two access tokens in play, we