Markdown Version | Transcript | Session Recording
WIMSE
Summary
The WIMSE Interim meeting was held to receive updates on working group progress and discuss a proposed individual draft on the Workload Authorization Grant (WAG).
Co-chairs Justin Richer and Pieter Kasselman opened the session with administrative updates and planning for IETF 121. The main technical presentation was delivered by Paul Carleton on "Workload Authorization Grant (WAG)", an individual draft co-authored with Nick Steele, Aaron Parecki, Arndt Schwenkschuster, and Brian Campbell. The working group discussed the scoping of the draft, its relationship to the active draft [draft-ietf-wimse-aims], potential extension profiles (e.g., for assistive and autonomous agents), and the path forward for adoption. An informal poll showed strong support for the problem space and the proposed document as a starting point.
Chair Updates
Justin Richer presented the Welcome and Chair Updates slides and reminded participants of the IETF Note Well.
Pieter Kasselman updated the group on preparation for IETF 121. The chairs are coordinating a dedicated WIMSE session as well as a joint WIMSE-OAuth session. Participants were encouraged to submit proposals for topics to the chairs, indicating which session would be the best fit.
Workload Authorization Grant (WAG)
Paul Carleton presented the slides for Workload Authorization Grant (WAG) - WIMSE Interim.
Problem Statement
The motivating problem is that platforms have many workloads (or agents) that need to access third-party systems across a trust boundary. Third-party systems must be able to tell these workloads apart for auditing, applying policy, assigning resource ownership, and managing billing/rate limits.
WAG aims to standardize the connection from the workload to the third-party system with little-to-no per-workload setup, preventing a default fallback to a single shared API key.
Technical Presentation
- Relationship to OAuth Identity Assertion: Aaron Parecki explained that WAG builds on the identity assertion JWT authorization grant (RFC 7523) and the OAuth ID-assertion draft. While ID-assertion is designed for human SSO flows, WAG mirrors this pattern for workloads acting on their own behalf without a user present. This allows authorization servers to reuse existing token endpoint logic and trust models.
- Workload Identity Federation (WIF) Patterns: Arndt Schwenkschuster highlighted similarities to industry patterns (e.g., AWS IAM, Google Workload Identity Pools, Azure Managed Identities) using RFC 7523 assertions. WAG leverages centralized trust establishment and standard OpenID Connect discovery to handle access for ephemeral workloads without needing individual life cycle management for every workload in the target system.
- Scope: The draft focuses purely on standardizing the assertion token and its exchange at the token endpoint. Out of scope are: how the workload obtains the WAG, fine-grained authorization, and the specific claims used to convey workload attributes.
Key Discussion Points
Relationship to the AIMS Draft ([draft-ietf-wimse-aims])
- Pete Resnick raised a question regarding how WAG plugs into the architecture of [draft-ietf-wimse-aims].
- Aaron Parecki and Pieter Kasselman noted that WAG fits directly within Section 10.4.2 of [draft-ietf-wimse-aims] ("Agent Obtains Own Authorization"). While [draft-ietf-wimse-aims] references the JWT authorization grant at a high level, the WAG draft provides the specific technical details and clarity required to implement it.
Scoping and Agent Use Cases (Autonomous vs. Assistive)
- Jiyun Yao noted that enterprises are increasingly trying to differentiate autonomous agents (taking action independently) from assistive agents (impersonating users) and requested clarity on how WAG handles this and drives adoption among SaaS/agent providers.
- Sean O'Dell and Nate Barbettini emphasized that distinguishing assistive use cases (acting on behalf of a human) from pure autonomous workloads is a critical industry problem. They noted that incorporating an actor claim (referencing RFC 8693 token exchange concepts) is essential for assistive cases.
- Paul Carleton responded that WAG treats the subject claim as opaque for now to establish a baseline workload identifier, leaving advanced attribute and delegation mapping out of the core draft to preserve simplicity.
- Flemming Andreasen expressed support for the problem space, noting that the draft generalizes patterns seen in Spiffe to multiple platforms, but cautioned that namespace concerns must be carefully considered.
Extensibility and Profiles
- George Fletcher inquired whether the draft should be structured as a baseline framework with specific vertical profiles (e.g., for assistive vs. autonomous agents) to prevent conflicting extensions.
- Paul Carleton agreed that keeping WAG tightly scoped allows it to serve as a baseline. Profile documents could subsequently define how a WAG is retrieved, or how specific claims (like actor claims or deferred token responses) are integrated.
- Jiyun Yao raised adoption concerns regarding how third-party vendors handle grant lifecycle management, such as cleaning up grants when an agent is retired. Paul Carleton acknowledged these as valid challenges, though currently out of scope for the core WAG exchange.
Working Group Venue
- Nick Steele, Arndt Schwenkschuster, and Brian Campbell strongly supported WIMSE as the correct venue for this work, emphasizing the rapid pace of the agent space and the utility of standardizing the wire protocol.
- Justin Richer noted that taking on new work is contingent on progress and completion of the working group's current in-flight documents.
Session Polls
The chairs conducted a poll to gauge interest in the problem space and the proposed document:
Poll 1:
- Question: Are we interested in the problem targeted by this document and this document as a starting point for addressing it?
- Result: yes: 16, no: 0, no_opinion: 2 (total: 21)
Decisions and Next Steps
- IETF 121 Presentation: The authors plan to present the WAG draft at IETF 121. The chairs will coordinate whether to place the presentation in the dedicated WIMSE session or the joint WIMSE-OAuth session.
- Adoption Path: The co-chairs will consult with the Area Director (AD) regarding working group bandwidth and the process for adoption.
- Mailing List Discussion: To prepare for a future call for adoption, the chairs will initiate a dedicated discussion thread on the mailing list to refine the problem statement and gather broader working group feedback on [draft-ietf-wimse-aims] alignment.