Re: [Wimse] Updated Proposed Charter Text

[Justin Richer <[e-mail]>]

Hi everyone, updated text from today’s discussion is on the URL and I’ve pasted it here below. Please provide comments on the updated sections if you have them, and we’ll work with Murray to update the proposed text in the tracker as appropriate.


Background & Motivation

The increasing prevalence of cloud computing and micro service architectures has lead 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 micro-service 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.

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.

Scope

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 leverage 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 (draft-gilman-wimse-use-cases) I-D.

Goals

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. Though initial deliverables will focus on specific REST-based technologies and HTTP, the group will also consider deliverables that use non-HTTP transport protocols that are found in workload deployments, such as GraphQL, gRPC, and Kafka.

The WIMSE working group aims to address the following major considerations through near-term and long-term deliverables:

    Establish Best Current Practices (BCPs): Define guidelines on effectively combining existing standards from different ecosystems to cater to various workload identity scenarios.

    Identify and Advocate for Gap-filling Work: Engage with other relevant working groups to pinpoint and address gaps in current standards. This will involve thorough collaboration, ensuring that emerging standards are consistent, holistic, and interoperable.

    Standardize New Solutions: Initiate and develop new standards that provide the needed functionality and ensure their widespread adoption to address propagating, representing, and processing of workload identity (unless there is a more direct fit in another working group).

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. WIMSE will consider this context in authorization decisions, record keeping and auditing solutions, and wire formats and protocols between elements of a workload, both within and across security boundaries.

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, and RATS.

    The Cloud Native Computing Foundation (CNCF), particularly with regard to the SPIFFE/SPIRE project.

    The OpenID Foundation and other organizations working on similar standards.

Initial Deliverables

Please note that the order of items does not reflect their priority or expected delivery order.

    WIMSE architecture: The group will develop an Informational document that defines common terminology, discusses workload attestation and identity, and specifies a threat model. The WIMSE architecture will be drawn from experience with other working group documents and is not intended as a prerequisite for their completion. The document will describe 2-3 scenarios and for each of them, it will identify existing standards and gaps where a new standard (or a profile) is needed for interoperability. The document’s goals and format are inspired by the RATS architecture, RFC 9334.

    Securing service-to-service traffic: a JOSE-based token solution for service authn/authz to protect a chain of HTTP/REST calls, within and across trust domains. The document should support strong identification of microservices and cryptographic binding of the token to the caller’s identity and optionally, binding to the transaction. It should support associating arbitrary context with the token, including but not limited to user identity, platform attestation and SBOM artifacts. Context may also include authorization information, however defining the semantics of such information is out of scope. This deliverable includes both a token format and usage, including binding to the caller’s identity.

    Token issuance: A document describing a method for issuance of tokens within a workload component. In addition to generic token issuance, the deliverable will describe local token issuance where the issuer operates with limited authority in order to reduce risk, improve latency and enhance reliability.

    Token exchange: A document describing a method for exchanging an incoming token for a workload-specific token at security boundaries in the context of workload identities (possibly based on RFC 8693). It will include a small set of token exchange profiles (mapping of claims) that enable authorization in call chains, in addition to interoperable access from SPIFFE-identified services to OAuth-protected resources and vice versa.

    Document existing local token distribution practices for workloads: An Informational deliverable describing the considerations and best practices for filesystem-based token delivery in Kubernetes. A proposed starting point is draft-hofmann-wimse-workload-identity-bcp-00.



— Justin

On Feb 7, 2024, at 3:23 PM, Justin Richer <[e-mail]> wrote:

Hi all, I’ve put together an update to the WIMSE charter text based on the recent thread, please read and review ahead of tomorrow’s call:

https://notes.ietf.org/s/lpjvjT_mA#

— Justin

--
Wimse mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/wimse