Script updating gh-pages from ef4a18f. [ci skip]

draft-ietf-wimse-workload-identity-bcp.html

@@ -1138,7 +1138,7 @@ <h2 id="name-copyright-notice">
             <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-terminology" class="internal xref">Terminology</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-architecture-and-recommenda" class="internal xref">Architecture and Recommendations</a></p>
+            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-recommendations" class="internal xref">Recommendations</a></p>
 </li>
           <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
             <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
@@ -1175,10 +1175,10 @@ <h2 id="name-copyright-notice">
       <h2 id="name-introduction">
 <a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
       </h2>
-<p id="section-1-1">In workload scenarios dedicated management entities, also called  "control plane" entities, are used to start, monitor and stop 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
-<p id="section-1-2">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.<a href="#section-1-2" class="pilcrow">¶</a></p>
-<p id="section-1-3">"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 <code>TokenRequest</code> API invoked by business logic or <code>Token volume projection</code> which mounts the token into the file system of the workloads and keeps it up to date there. <code>Token volume projection</code> having the advantage of not requiring any manual effort by the application besides reading a file.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<p id="section-1-4">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 <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>. The token is presented to a authorization server as a client assertion. The authorization servers validates the signature of the presented assertion via <span>[<a href="#OIDC" class="cite xref">OIDC</a>]</span> metadata or <span>[<a href="#RFC8414" class="cite xref">RFC8414</a>]</span> 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.<a href="#section-1-4" class="pilcrow">¶</a></p>
+<p id="section-1-1">In workload scenarios dedicated management entities, also referred to as "control plane" entities, are used to start, monitor and stop workloads dynamically. These workloads frequently interact with each other and other entities within the corporate 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
+<p id="section-1-2">To authenticate workloads accessing resources, each workload instance requires unique credentials. This poses challenges in environments where workloads start, stop, relocate, and scale dynamically. Manual configuration, rotation, and management efforts can result in management overhead at best and security risks such as credential exposure at worst.<a href="#section-1-2" class="pilcrow">¶</a></p>
+<p id="section-1-3">"Service account token volume projection" is a feature in the Kubernetes container orchestration system that enables users to attach platform-attested tokens to their workloads. Workloads use these tokens to authenticate themselves to APIs within the platform's control plane. While this token is used for access, it functions more like an ID Token rather than an Access Token in the OAuth context. Workloads do not receive a refresh token, and there is no involvement of authorization or consent; it simply serves as proof of the workload's identity. Workloads have several methods to obtain such tokens from Kubernetes, including through the TokenRequest API invoked by business logic or Token volume projection, which mounts the token into the workload's file system and ensures it remains up-to-date. Token volume projection offers the advantage of requiring no manual intervention by the application beyond reading a file.<a href="#section-1-3" class="pilcrow">¶</a></p>
+<p id="section-1-4">Initially designed to authenticate access to the control plane API, the industry has recognized the service account token for its low maintenance and platform attestation capabilities and has started using it as a JWT client assertion, as specified in <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>. This token is presented to an authorization server as a client assertion. The authorization server validates the assertion's signature using <span>[<a href="#OIDC" class="cite xref">OIDC</a>]</span> metadata or <span>[<a href="#RFC8414" class="cite xref">RFC8414</a>]</span> and uses the claims within the token to authenticate the client. Overall, the authorization server trusts the platform control plane for issuing and delivering these credentials. The authorization server then responds with an Access Token that the workload can use to access an OAuth2-protected resource on a resource server.<a href="#section-1-4" class="pilcrow">¶</a></p>
 <p id="section-1-5"><a href="#fig-arch" class="auto internal xref">Figure 1</a> illustrates the interaction in the architecture graphically.<a href="#section-1-5" class="pilcrow">¶</a></p>
 <span id="name-protocol-interaction"></span><div id="fig-arch">
 <figure id="figure-1">
@@ -1226,11 +1226,9 @@ <h2 id="name-introduction">
 <a href="#name-protocol-interaction" class="selfRef">Protocol Interaction.</a>
         </figcaption></figure>
 </div>
-<p id="section-1-7">This specification specifies the use of Service Account Tokens in container orchestration systems, which provides a secure and scalable way to create and manage these tokens, and ensures interoperability with existing OAuth-based authorization systems.<a href="#section-1-7" class="pilcrow">¶</a></p>
-<p id="section-1-8">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 use the term "Service Account Token" to refer to the token issued by the Control Plane and thereby distinguish it from the other access token issued to an OAuth 2.0 client running inside the workload by the second authorization server.<a href="#section-1-8" class="pilcrow">¶</a></p>
-<p id="section-1-9">In <a href="#recommendations" class="auto internal xref">Section 3</a> we provide more details about how the
-content of the tokens and the offered security properties.<a href="#section-1-9" class="pilcrow">¶</a></p>
+<p id="section-1-7">This specification defines the utilization of Service Account Tokens within container orchestration systems, providing a secure and scalable method for creating and managing these tokens while ensuring interoperability with existing OAuth-based authorization systems.<a href="#section-1-7" class="pilcrow">¶</a></p>
+<p id="section-1-8">To distinguish between entities, we refer to the OAuth 2.0 Authorization Server within the cluster's control plane as the "Control Plane." Given the presence of two distinct access tokens, we specifically designate the token issued by the Control Plane as the "Service Account Token," thereby differentiating it from the access token issued to an OAuth 2.0 client operating within the workload by a separate authorization server.<a href="#section-1-8" class="pilcrow">¶</a></p>
+<p id="section-1-9">In <a href="#recommendations" class="auto internal xref">Section 3</a>, further details are provided regarding the token content and the associated security properties.<a href="#section-1-9" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="terminology">
@@ -1248,24 +1246,24 @@ <h2 id="name-terminology">
 </div>
 <div id="recommendations">
 <section id="section-3">
-      <h2 id="name-architecture-and-recommenda">
-<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-architecture-and-recommenda" class="section-name selfRef">Architecture and Recommendations</a>
+      <h2 id="name-recommendations">
+<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-recommendations" class="section-name selfRef">Recommendations</a>
       </h2>
 <p id="section-3-1">This specification relies on the use of OAuth 2.0 <span>[<a href="#RFC6749" class="cite xref">RFC6749</a>]</span> and
 <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span> for client authentication using a JWT.<a href="#section-3-1" class="pilcrow">¶</a></p>
-<p id="section-3-2">Service Account Tokens used in workload orchestration systems are vulnerable to different types of threats, as shown in this list:<a href="#section-3-2" class="pilcrow">¶</a></p>
+<p id="section-3-2">Service Account Tokens used in container orchestration systems are vulnerable to various threats, as outlined below:<a href="#section-3-2" class="pilcrow">¶</a></p>
 <ol start="1" type="1" class="normal type-1" id="section-3-3">
 <li id="section-3-3.1">
-          <p id="section-3-3.1.1">Token theft: Tokens can be stolen by attackers who have already gained access to a workload. These attackers can then use these tokens to impersonate the workload and gain access to resources they should not have access to.<a href="#section-3-3.1.1" class="pilcrow">¶</a></p>
+          <p id="section-3-3.1.1">Token theft: Attackers who compromise a workload can steal tokens to impersonate it and gain unauthorized access to resources.<a href="#section-3-3.1.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-3-3.2">
-          <p id="section-3-3.2.1">Token reuse: Tokens can be reused by attackers to gain access to the system. However, expiration times limited the token reuse time.<a href="#section-3-3.2.1" class="pilcrow">¶</a></p>
+          <p id="section-3-3.2.1">Token reuse: Stolen tokens may be reused within their expiration period to gain repeated unauthorized access. However, the expiration time limits the token reuse time window.<a href="#section-3-3.2.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-3-3.3">
-          <p id="section-3-3.3.1">Misconfigured service accounts: Similar to misconfigured access to secrets, misconfigured service accounts can lead to applications gaining more privileges then necessary.<a href="#section-3-3.3.1" class="pilcrow">¶</a></p>
+          <p id="section-3-3.3.1">Misconfigured service accounts: mproperly configured service accounts can grant applications excessive privileges.<a href="#section-3-3.3.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-3-3.4">
-          <p id="section-3-3.4.1">Theft of token signing key: The token signing key can be stolen by attackers who have already gained access to the control plane. However, such attackers also have access to all secrets in the workload orchestration system. Hence, resulting in the same impact for use of client_id and client_secret compared to using Service Account Tokens.<a href="#section-3-3.4.1" class="pilcrow">¶</a></p>
+          <p id="section-3-3.4.1">Theft of token signing key: Attackers gaining control plane access can steal the token signing key, akin to compromising client_id and client_secret in OAuth, potentially accessing all secrets in the orchestration system.<a href="#section-3-3.4.1" class="pilcrow">¶</a></p>
 </li>
       </ol>
 <p id="section-3-4">The following fields are populated in the Service Account Token:<a href="#section-3-4" class="pilcrow">¶</a></p>
@@ -1274,13 +1272,13 @@ <h2 id="name-architecture-and-recommenda">
           <p id="section-3-5.1.1">The 'iss' claim MUST contain a string identifying the worklod orchestrator.<a href="#section-3-5.1.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-3-5.2">
-          <p id="section-3-5.2.1">The 'sub' claim MUST contain a string identifying the workload. This is also the client_id according to <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>.<a href="#section-3-5.2.1" class="pilcrow">¶</a></p>
+          <p id="section-3-5.2.1">The 'sub' claim MUST contain a string identifying the workload, also serving as the client_id per <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>.<a href="#section-3-5.2.1" class="pilcrow">¶</a></p>
 </li>
         <li id="section-3-5.3">
-          <p id="section-3-5.3.1">The 'aud' claim MUST identify one or multiple authorization servers that are intended recipients of the Service Account Token for client authorization.<a href="#section-3-5.3.1" class="pilcrow">¶</a></p>
+          <p id="section-3-5.3.1">The 'aud' claim MUST identify one or multiple authorization servers intended to receive and authorize the Service Account Token.<a href="#section-3-5.3.1" class="pilcrow">¶</a></p>
 </li>
       </ol>
-<p id="section-3-6">Further processing requirements are specified in <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>.<a href="#section-3-6" class="pilcrow">¶</a></p>
+<p id="section-3-6">Additional processing requirements are specified in <span>[<a href="#RFC7523" class="cite xref">RFC7523</a>]</span>.<a href="#section-3-6" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="security-considerations">