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

[Joseph Salowey <[e-mail]>]

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]> 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]>
> *Date: *Thursday, 7 March 2024 at 10:46
> *To: *"[e-mail]" <[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]> 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]>
>
> 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
>
>
>
> --
> Wimse mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wimse
>