Workload Identity in Multi System Environments (wimse)
| WG | Name | Workload Identity in Multi System Environments | |
|---|---|---|---|
| Acronym | wimse | ||
| Area | Applications and Real-Time Area (art) | ||
| State | Active | ||
| Charter | charter-ietf-wimse-01 Approved | ||
| Document dependencies | |||
| Additional resources |
GitHub Organization Working Group Home Page |
||
| Personnel | Chairs | Justin Richer, Pieter Kasselman | |
| Area Director | Murray Kucherawy | ||
| Tech Advisor | Paul Wouters | ||
| Mailing list | Address | wimse@ietf.org | |
| To subscribe | https://www.ietf.org/mailman/listinfo/wimse | ||
| Archive | https://mailarchive.ietf.org/arch/browse/wimse/ | ||
| Chat | Room address | https://zulip.ietf.org/#narrow/stream/wimse |
Charter for Working Group
Background & Motivation
The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This working group will focus on the unique identity and access management aspects of workloads at runtime and their execution context, particularly focusing on the propagation, representation, and processing of workload identities. Though the following items are relevant to the context of workloads, these items are not workloads and this working group will not define:
-
Static software identities and provenance, such as software bill of materials (SBOM)
-
Personal identities
-
Deployment chains
-
Supply chain management
The rise of diverse service platforms and the drive for business flexibility, cost-efficiency, resilience, and compliance make maintaining least privilege access for workloads increasingly complex. As a result of the adoption of microservice architectures, services are composed of multiple workloads that need to authenticate to each other while making authorization decisions based on the original caller, their context, and the actions of other workloads that acted on a transaction. These workloads are often distributed across trust boundaries, without a single centralized controller managing the different identities or authorization policies.
Workloads are often associated with complex context, including user identity, software origin, and hardware-based attestation. Communicating this context involves a unique set of challenges across different scenarios including multi-hop, long-lived and asynchronous transactions.
While several standards and open-source projects offer foundational elements for secure workload identity, there remains a lack of clarity in their interoperation and combination. These technologies (specifically: OAuth, JWT, and SPIFFE) have been combined in a variety of ways in practice, but the solutions have existed in relative isolation. This ambiguity can lead to inconsistencies, interoperability issues, and potential security vulnerabilities.
Goals
The Workload Identity in Multi-Service Environments (WIMSE) working group is chartered to address the challenges associated with implementing fine-grained, least privilege access control for workloads deployed across multiple service platforms, spanning both public and private clouds. The work will build on existing standards, open source projects, and community practices, focusing on combining them in a coherent manner to address multi-service workload identity use cases such as those identified in the Workload Identity Use Cases I-D (draft-gilman-wimse-use-cases).
The goal of the WIMSE working group is to identify, articulate, and bridge the gaps and ambiguities in workload identity problems and define solutions across a diverse set of platforms and deployments, building on various protocols used in workload environments. The WG will standardize solutions (as proposed standard) and document existing or best practices (as informational or BCP) per the Program of Work.
While recognizing that the broader workload ecosystem uses a variety of application protocols (e.g., gRPC, Kafka and GraphQL), the WG will focus on only specific REST-based technologies using HTTP.
WIMSE will also serve as a standing venue to discuss operational experience and requirements with workload identity. These discussions need not be restricted to technologies currently in scope to this charter.
Dependencies and Liaisons
The WIMSE working group will closely collaborate with:
-
Other IETF working groups that address topics related to identity, authentication, and authorization, including, but not limited to, OAuth, SCIM, SCITT, and RATS.
-
The Cloud Native Computing Foundation (CNCF), particularly with regard to the SPIFFE/SPIRE project.
-
The OpenID Foundation.
Program of Work
The WIMSE WG will focus on the following program of work:
-
[I] WIMSE architecture: The group will develop a document that defines common terminology, discusses workload attestation and identity, specifies a threat model, and defines a set of architectural components and several compositions of those components. The document will describe 2-3 scenarios and for each of them, it will identify key points needed for interoperability.
-
[PS] Securing service-to-service traffic: a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls, within and across trust domains. The document should support identification of microservices and cryptographic binding of the token to the caller’s identity and optionally, binding to the transaction. It should support associating context with the token, including but not limited to user identity, platform attestation, and SBOM artifacts. This deliverable includes both a token format and its usage, including binding to the caller’s identity.
-
[PS] Token issuance: A document describing a method for local issuance of WIMSE tokens where the local issuer operates with limited authority. The local issuer can be the workload itself or another workload deployed nearby.
-
[PS] Token exchange: Specify a protocol for exchanging an incoming token of one format for a workload-specific WIMSE token at security boundaries (possibly based on RFC 8693). Additionally, this token exchange will require specifying as proposed standard a small set of token exchange profiles (mapping of claims) between existing and new WIMSE token formats.
-
[I or BCP] Document and make recommendations based on operational experience to existing token distribution practices for workloads.
Milestones
| Date | Milestone | Associated documents |
|---|---|---|
| Jul 2026 | Submit informational document describing the WIMSE architecture to the IESG | |
| Nov 2025 | Submit a protocol as proposed standard for exchanging an incoming token of one format for a workload-specific token at security boundaries to the IESG | |
| Mar 2025 | Submit a proposed standard for a token exchange profile mapping the JWT BCP [RFC9068] to the JOSE-based WIMSE token to the IESG | |
| Mar 2025 | Submit proposed standard document specifying a token exchange profile that maps claims from SPIFFE-identified services to OAuth-protected resources, and vice versa to the IESG | |
| Mar 2025 | Submit proposed standard for a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls for workloads to the IESG | |
| Nov 2024 | Submit informational document describing considerations for filesystem-based JWT delivery in Kubernetes to the IESG |