WG Action: Formed Workload Identity in Multi System Environments (wimse)

[The IESG <[e-mail]>]

A new IETF WG has been formed in the Applications and Real-Time Area. For
additional information, please contact the Area Directors or the WG Chair.

Workload Identity in Multi System Environments (wimse)
-----------------------------------------------------------------------
Current status: BOF WG

Chairs:
  Justin Richer <[e-mail]>

Assigned Area Director:
  Murray Kucherawy <[e-mail]>

Applications and Real-Time Area Directors:
  Murray Kucherawy <[e-mail]>
  Francesca Palombini <[e-mail]>

Technical advisors:
  Paul Wouters <[e-mail]>

Mailing list:
  Address: [e-mail]
  To subscribe: https://www.ietf.org/mailman/listinfo/wimse
  Archive: https://mailarchive.ietf.org/arch/browse/wimse/

Group page: https://datatracker.ietf.org/group/wimse/

Charter: https://datatracker.ietf.org/doc/charter-ietf-wimse/

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:

  Nov 2024 - Submit informational document describing considerations for
  filesystem-based JWT delivery in Kubernetes 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

  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 a proposed standard for a token exchange profile mapping
  the JWT BCP [RFC9068] to the JOSE-based WIMSE token 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

  Jul 2026 - Submit informational document describing the WIMSE architecture
  to the IESG