WIMSE

Summary

This interim meeting was a follow-up to discussions in Madrid regarding agentic AI use cases for the Workload Identity in Multi-System Environments (WIMSE) Working Group. The primary goal was to delve deeper into the challenges and opportunities presented by AI agents in relation to WIMSE's architecture and protocol. Key discussion areas included agent identity, attestation, authorization models, and integration with agent-to-agent protocols like MCP. While no new work items were chartered, the chairs encouraged continued discussion on the mailing list and the submission of drafts exploring these topics within the IETF framework.

Key Discussion Points

Introduction to Agentic AI and WIMSE:
- The meeting focused on agentic AI use cases, a topic of sufficient interest arising from the Madrid IETF meeting.
- The premise is that a significant portion of future service-to-service traffic will involve AI agents, making their security relevant to WIMSE.
- The problem was framed in four parts: Identity, Attestation, Authorization, and Transport/Integration.
Workload Identity for Agents:
- Agent identity is considered complex, potentially more so than microservices, due to autonomy, operation on behalf of individuals/roles/organizations, and the need for stricter policies.
- Yaron's opinion was that the information modeling of complex agent identity (e.g., how agents represent individuals, delegation models) is likely outside the appropriate scope for WIMSE and potentially the IETF.
- Discussion: Participants acknowledged WIMSE's draft on identifiers and the need for coordination with the broader identity ecosystem. It was clarified that while information modeling might be out of scope, the protocol mechanisms for identity and delegation (like OAuth) could be relevant.
Attestation for Agents:
- The concept of agent marketplaces was introduced, where agents might be developed by one organization, verified by another, and deployed by a third, requiring multiple layers of attestation for authorization policies.
- Yaron's opinion was that WIMSE should initially focus on simpler, traditional attestation for service code (e.g., security posture in confidential computing) rather than the more complex attestation of agent providence (origin, verification, deployment) for which industry requirements are still emerging.
- Discussion: Peter (with I) questioned the distinction between attesting agent capabilities vs. underlying systems. Yaron clarified that traditional attestation (underlying systems) is the proposed starting point. The relationship with the RATS working group was also discussed, with Yaron suggesting RATS provides attestation infrastructure, but WIMSE would be responsible for its application in service-to-service contexts. It was suggested that agent providence attestation might be more akin to a supply chain problem.
Authorization for Agents:
- Authorization was identified as perhaps the most important problem for AI agents due to their common "over-permissioned" state and the need to control their capabilities (tools).
- The current WIMSE service-to-service protocol does not define authorization beyond allowing implementers to handle it, unlike OAuth.
- Yaron asked if WIMSE should add mechanisms to carry authorization decisions or policies.
- Discussion: The chairs noted that the WIMSE charter explicitly placed authorization out of scope due to its vastness, but acknowledged that some aspects related to how workloads process requests or carry authorization information might fit. Participants were encouraged to bring forward drafts on how WIMSE could address these boundaries. Peter (chair) also highlighted that external ecosystems like MCP are heavily leaning into OAuth for authorization.
Transport and MCP Integration:
- MCP (Mechanism for Composable Protocols) is an open protocol for AI agents to connect with tools and data, with security based on OAuth 2.1. It's widely deployed, mainly for IDE-to-local service interaction, but growing for production agent-to-agent use.
- Yaron's assessment was that while MCP's OAuth-based security works for inter-organization scenarios, there's an opportunity for WIMSE to provide a simpler, more seamless intra-organization connection, particularly by streamlining discovery.
- Yaron proposed a "WIMSE profile for MCP" that could replace OAuth for authentication and authorization across MCP within an organization.
- Discussion:
  - Challenges include the WIMSE protocol not being finalized and MCP's rapid development pace.
  - Justin (chair) clarified that MCP is controlled by a commercial entity (Anthropic) and is not an open standards organization with IETF's rigor or IPR protections. He distinguished between IETF referring to external documents (which has rules) and IETF doing work within an external, commercially controlled project (which is not how IETF operates). Individual WIMSE participants can engage with MCP.
  - Peter (with I) noted active discussions in the MCP community on authentication, with interest in various levels of security (e.g., proof of possession, cryptographic mechanisms), suggesting WIMSE's work is relevant.
  - Bo highlighted correlations between MCP's machine use cases and existing WIMSE mechanisms for machine identity (e.g., MAC address, certificates for proving manager's intent).

Decisions and Action Items

No formal decision was made to adopt new work items related to agentic AI during this meeting.
Action Item: Yaron (presenter) to continue the discussion on agentic AI use cases and potential WIMSE relevance on the WIMSE mailing list.
Action Item: Working Group participants are encouraged by the chairs to submit drafts proposing how agentic AI use cases, particularly regarding authorization aspects or WIMSE/MCP connections, could be addressed within the WIMSE scope, following IETF processes and language.

Next Steps

Continue the discussion on the WIMSE mailing list.
Members interested in pursuing these topics are encouraged to develop and submit individual drafts for the Working Group's consideration.
The next WIMSE interim meeting is scheduled for October 7th, followed by one more prior to the Montreal IETF meeting in November.

Session Date/Time: 25 Sep 2025 16:00

WIMSE

Summary

Key Discussion Points

Introduction to Agentic AI and WIMSE:
- The meeting focused on agentic AI use cases, a topic of sufficient interest arising from the Madrid IETF meeting.
- The premise is that a significant portion of future service-to-service traffic will involve AI agents, making their security relevant to WIMSE.
- The problem was framed in four parts: Identity, Attestation, Authorization, and Transport/Integration.
Workload Identity for Agents:
- Agent identity is considered complex, potentially more so than microservices, due to autonomy, operation on behalf of individuals/roles/organizations, and the need for stricter policies.
- Yaron's opinion was that the information modeling of complex agent identity (e.g., how agents represent individuals, delegation models) is likely outside the appropriate scope for WIMSE and potentially the IETF.
- Discussion: Participants acknowledged WIMSE's draft on identifiers and the need for coordination with the broader identity ecosystem. It was clarified that while information modeling might be out of scope, the protocol mechanisms for identity and delegation (like OAuth) could be relevant.
Attestation for Agents:
- The concept of agent marketplaces was introduced, where agents might be developed by one organization, verified by another, and deployed by a third, requiring multiple layers of attestation for authorization policies.
- Yaron's opinion was that WIMSE should initially focus on simpler, traditional attestation for service code (e.g., security posture in confidential computing) rather than the more complex attestation of agent providence (origin, verification, deployment) for which industry requirements are still emerging.
- Discussion: Peter (with I) questioned the distinction between attesting agent capabilities vs. underlying systems. Yaron clarified that traditional attestation (underlying systems) is the proposed starting point. The relationship with the RATS working group was also discussed, with Yaron suggesting RATS provides attestation infrastructure, but WIMSE would be responsible for its application in service-to-service contexts. It was suggested that agent providence attestation might be more akin to a supply chain problem.
Authorization for Agents:
- Authorization was identified as perhaps the most important problem for AI agents due to their common "over-permissioned" state and the need to control their capabilities (tools).
- The current WIMSE service-to-service protocol does not define authorization beyond allowing implementers to handle it, unlike OAuth.
- Yaron asked if WIMSE should add mechanisms to carry authorization decisions or policies.
- Discussion: The chairs noted that the WIMSE charter explicitly placed authorization out of scope due to its vastness, but acknowledged that some aspects related to how workloads process requests or carry authorization information might fit. Participants were encouraged to bring forward drafts on how WIMSE could address these boundaries. Peter (chair) also highlighted that external ecosystems like MCP are heavily leaning into OAuth for authorization.
Transport and MCP Integration:
- MCP (Mechanism for Composable Protocols) is an open protocol for AI agents to connect with tools and data, with security based on OAuth 2.1. It's widely deployed, mainly for IDE-to-local service interaction, but growing for production agent-to-agent use.
- Yaron's assessment was that while MCP's OAuth-based security works for inter-organization scenarios, there's an opportunity for WIMSE to provide a simpler, more seamless intra-organization connection, particularly by streamlining discovery.
- Yaron proposed a "WIMSE profile for MCP" that could replace OAuth for authentication and authorization across MCP within an organization.
- Discussion:
  - Challenges include the WIMSE protocol not being finalized and MCP's rapid development pace.
  - Justin (chair) clarified that MCP is controlled by a commercial entity (Anthropic) and is not an open standards organization with IETF's rigor or IPR protections. He distinguished between IETF referring to external documents (which has rules) and IETF doing work within an external, commercially controlled project (which is not how IETF operates). Individual WIMSE participants can engage with MCP.
  - Peter (with I) noted active discussions in the MCP community on authentication, with interest in various levels of security (e.g., proof of possession, cryptographic mechanisms), suggesting WIMSE's work is relevant.
  - Bo highlighted correlations between MCP's machine use cases and existing WIMSE mechanisms for machine identity (e.g., MAC address, certificates for proving manager's intent).

Decisions and Action Items

No formal decision was made to adopt new work items related to agentic AI during this meeting.
Action Item: Yaron (presenter) to continue the discussion on agentic AI use cases and potential WIMSE relevance on the WIMSE mailing list.
Action Item: Working Group participants are encouraged by the chairs to submit drafts proposing how agentic AI use cases, particularly regarding authorization aspects or WIMSE/MCP connections, could be addressed within the WIMSE scope, following IETF processes and language.

Next Steps

Continue the discussion on the WIMSE mailing list.
Members interested in pursuing these topics are encouraged to develop and submit individual drafts for the Working Group's consideration.
The next WIMSE interim meeting is scheduled for October 7th, followed by one more prior to the Montreal IETF meeting in November.