Skip to main content
  • IETF email infrastructure transition planned for 11 September

    A transition to a new modern, modular, and containerized infrastructure for email services provided for ietf.org, iab.org, irtf.org, rfc-editor.org (including email lists) is scheduled for 11 September 2026 starting at 2200UTC, with message delivery delayed up to 60 minutes. Further updates will be provided closer to the transition.

    28 Aug 2026
  • Post-Quantum Authentication: Up Next

    Post-quantum key establishment has moved from standards into deployment. Post-quantum authentication has not moved nearly as far, and specification work is no longer the only constraint. The IAB is holding a workshop in Prague on 11 and 12 October 2026 to bring deployment experience together with the people working on the relevant protocols and standards.

    27 Aug 2026
  • IETF 126 post-meeting survey: what we heard

    The IETF 126 Vienna meeting was held 18-24 July 2026 and the results of the post-meeting survey are now available.

    27 Aug 2026
  • Meet our new IETF NOC Lead

    Joe Clarke has been appointed as the new IETF NOC Lead and in this post Joe introduces himself and sets out his priorities for the IETF Network.

    10 Aug 2026
  • Secretariat restructuring and staffing update

    There have been a few changes in IETF Administration LLC staffing since January of this year (2026) including the recent insourcing of the Secretariat, which are summarised here to give an overall view of the staffing structure.

    30 Jul 2026

Filter by topic and date

Filter by topic and date

WIMSE Working Group: Serious business for cloud computing

15 Oct 2024

Chartered in March 2024, the IETF Workload Identity in Multi System Environments (WIMSE) working group aims to address challenges of implementing fine-grained access control across platforms in the public and private clouds, which is increasingly important to how complex software functions are built and deployed.

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—instances of software executing for a specific purpose, across multiple service platforms. 

pexels-brett-sayles-buildingblock-wimse

WIMSE focuses 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 identity. While several standards and open-source projects—such as OAuth, JWT, and SPIFFE—offer foundational elements for this work, there are no established standards on how to combine these standards, or any guidance on how to bridge the gaps between them. . This can lead to inconsistencies, interoperability issues, and potential security vulnerabilities.

WIMSE formed from a Birds of a Feather session held during the IETF 118 meeting in Prague and first met as a working group during IETF 119 in Brisbane. Work has progressed rapidly since then and the group has already adopted three documents that identify, articulate, and bridge the gaps and ambiguities in multi-cloud workload identity deployments and define solutions that can be adopted across a diverse set of platforms and deployments. WIMSE is scheduled to meet during IETF 121 Dublin in November 2024.

WIMSE Service to Service Authentication“ defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi-tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely.

Workload Identity in a Multi System Environment (WIMSE) Architecture“ discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. 

Best Current Practice for OAuth 2.0 Client Authentication in Workload Environments” describes the current best practices to avoid client_secret provisioning and leverage platform attestation to receive access tokens from an OAuth 2.0 authorization server via RFC 7523. 

Work is ongoing…. If you are interested in working on these issues and contributing ideas and solutions, please sign up for the mailing list and plan to attend the session during IETF 121


Share this page