Re: [Wimse] WG Action: Formed Workload Identity in Multi System Environments (wimse)

[Pieter Kasselman <[e-mail]>]

Thanks Joe and Yaron for your leadership throughout the chartering process.

From: Wimse <[e-mail]> On Behalf Of Joseph Salowey
Sent: Thursday, March 7, 2024 10:45 PM
To: Yaron Sheffer <[e-mail]>
Cc: Justin Richer <[e-mail]>; [e-mail]
Subject: Re: [Wimse] WG Action: Formed Workload Identity in Multi System Environments (wimse)

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Congratulations to all involved, this was a real team effort and I'm looking forward to participating in the official working group.  Thank You Yaron for being an excellent BOF co-chair and Justin for stepping up to chair the group!

Cheers,

Joe

On Thu, Mar 7, 2024 at 1:41 PM Yaron Sheffer <[e-mail]<mailto:[e-mail]>> wrote:
This has been quite a journey, and I’m very happy – and proud – we got the working group chartered, and in time for Brisbane, too. Thanks to everybody who contributed to countless discussions, and thank you Joe for your partnership.

And congratulations to our incoming WG chair, Justin. I’m looking forward to continue contributing to this working group under your leadership.

See you all in Brisbane, in person or virtually!

                Yaron


From: Justin Richer <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 7 March 2024 at 10:46
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Wimse] WG Action: Formed Workload Identity in Multi System Environments (wimse)

Greetings, WIMSE! It is my great pleasure to welcome all of you to the brand-newly-formed WIMSE Working Group! I am honored to be serving as chair, and my co-chair will be announced soon. Apologies for the wait while we get some administrative details sorted out in the background.

We will be meeting in Brisbane in about a week and a half, and the chairs will be pulling together an agenda for our first meeting. If you have a proposal for that, please reply to the list here and the chairs will collate the proposals into an agenda.

I want to apologize in advance that things might be a little rough around the edges due to the compressed time frame, but the chairs will be working to get as much put together for the first meeting as we can. Overall, I am thrilled that we have been able to produce an initial charter and pass it in time. A huge thanks to everyone who contributed to the many rounds of work.

And finally, I want to publicly give a GIGANTIC thank you to Yaron and Joe for chairing the BoF and leading the effort for collecting the deliverables and collating the charter text. Your leadership has been exemplary and I look forward to continuing to work with you both in this space.

For those coming to Brisbane, I’ll see you down under! For those that can’t make it, I hope that you can at least join us virtually as we kick things off.

Whimsically,
— Justin

On Mar 7, 2024, at 1:25 PM, The IESG <[e-mail]<mailto:[e-mail]>> wrote:

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]<mailto:[e-mail]>>

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

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

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

Mailing list:
 Address: [e-mail]<mailto:[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


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