Update draft-ietf-wimse-workload-identity-bcp.md

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

@@ -1,5 +1,5 @@
 ---
-title: Best Current Practice for Workload Identity
+title: Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments
 abbrev: Workload Identity
 docname:  draft-ietf-wimse-workload-identity-bcp-latest
 category: std
@@ -32,7 +32,7 @@ author:
  -
       ins: H. Tschofenig
       name: Hannes Tschofenig
-      email: hannes.tschofenig@siemens.com
+      email: hannes.tschofenig@gmx.net
       org: Siemens
 
  -
@@ -69,16 +69,16 @@ informative:
 
 --- abstract
 
-The use of the OAuth 2.0 framework for container orchestration systems poses a challenge as managing secrets, such as client_id and client_secret, can be complex and error-prone.
+The use of the OAuth 2.0 framework for workload orchestration systems poses a challenge as managing secrets, such as client_id and 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.
 
-This document specifies the use of JWTs for client credentials in container orchestration systems to improve interoperability in orchestration systems, to reduce complexity for  developers, and motivates authorization server to support RFC 7523.
+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.
 
 --- middle
 
 # Introduction
 
-In workload scenarios dedicated management entities, also called  "control plane" entities, are used to start, monitor and stop workloads dynamically.
+In workload scenarios dedicated management entities, also called "control plane" entities, are used to start, monitor and stop 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.
 
@@ -90,16 +90,16 @@ In addition, these credentials do not have an automated rotation mechanism and a
 
 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 container orchestration systems that allows users to create JSON Web Tokens (JWTs) for their workloads.
+"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 container orchestrators.
+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.
 
-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.
+This specification specifies the use of Service Account Tokens in workload orchestration systems, which provides a secure and scalable way to create and manage these tokens, and ensures interoperability with existing OAuth-based authorization systems.
 
 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}}.
 
@@ -163,21 +163,24 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 BCP 14 {{RFC2119}} {{RFC8174}} when, and only when, they appear in all
 capitals, as shown here.
 
+The term container is sometimes used instead of workloads. These two
+terms can be used interchangably.
+
 # Architecture and Recommendations {#recommendations}
 
 This specification relies on the use of OAuth 2.0 {{RFC6749}} and
 {{RFC7523}} for client authentication using a JWT.
 
-Service Account Tokens used in container orchestration systems are vulnerable to different types of threats, as shown in this list:
+Service Account Tokens used in workload orchestration systems are vulnerable to different types of threats, as shown in this list:
 
 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.
 2. Token reuse: Tokens can be reused by attackers to gain access to the system. However, expiration times limited the token reuse time.
 3. Misconfigured service accounts: Similar to misconfigured access to secrets, misconfigured service accounts can lead to applications gaining more privileges then necessary.
-4. 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 container orchestration system. Hence, resulting in the same impact for use of client_id and client_secret compared to using Service Account Tokens.
+4. 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.
 
 The following fields are populated in the Service Account Token:
 
-1. The 'iss' claim MUST contain a string identifying the container orchestrator.
+1. The 'iss' claim MUST contain a string identifying the worklod orchestrator.
 2. The 'sub' claim MUST contain a string identifying the workload. This is also the client_id according to {{RFC7523}}.
 3. The 'aud' claim MUST identify one or multiple authorization servers that are intended recipients of the Service Account Token for client authorization.