Session Date/Time: 07 Oct 2025 16:00

WIMSE

Summary

The WIMSE interim meeting on October 7th, 2025, focused on the WIMSE architecture document with the goal of moving it towards Working Group Last Call (WGLC). Key discussions revolved around recent updates to the document, including new cross-domain and AI agent use cases, as well as crucial terminology and consistency issues with the Spiffy standard. A significant point of discussion was the proposal to split the "WIMSE identifier" work into a separate Standards Track document.

Key Discussion Points

Architecture Document Revision Updates
- A new revision of the architecture document was published, incorporating several updates:
  - Refined definitions.
  - Alignment with OAuth cross-domain work, introducing an external token service for Workload 2 to interact with external services.
  - Reworked the education section and added information on audit.
  - Added a new AI use case.
- Remaining open issues include terminology, key management, attestation, bound tokens, and identity.
- Cross-Domain Use Case: The update introduces an external token service to align with the OAuth cross-domain identity chaining draft. A sense of those present indicated support for this direction.
  - One participant noted that the current description may not fully cover patterns involving mutual trust of signing keys (e.g., with mutual TLS) where no token service is explicitly involved, as seen in some Spiffy deployments. It was suggested this might be a distinct case or require clarification in the text.
- AI Agent Use Case: A new use case for AI agents was added, defining them as a special kind of workload. The distinction between delegated and autonomous AI agents was introduced, with emphasis on AI-to-AI delegation chains and the handling of security context. The aim is to highlight potential pitfalls and encourage good practices without being prescriptive about specific protocols.
  - A participant mentioned external proposals, such as a paper by CSA/Microsoft, that discuss ambitious approaches to AI agent identity (e.g., decentralized identities, verifiable credentials, zero-knowledge proofs, agent naming services), noting their claims of OAuth/OIDC/SAML limitations for delegation. The group was encouraged to familiarize themselves with diverse proposals.
  - Concern was raised that the referenced external document was gated behind a login/registration.
Consistency with Spiffy
- The working group's goal is for Spiffy IDs to be valid WIMSE IDs, with WIMSE IDs potentially forming a superset. Explicit consistency goals need to be defined in the architecture document.
- Specific prescriptive restrictions in Spiffy were discussed, including:
  - Mandated minimum length and recommended maximum length (2048 bytes) for endpoints.
  - Prohibition of usernames and ports within hostnames.
  - Character set restrictions in hostnames and paths (e.g., no percent-encoded characters).
  - Allowance for IPv4 addresses but not IPv6 addresses in hostnames due to the presence of colons.
- The group acknowledged that Spiffy's restrictions stem from painful deployment experiences, particularly regarding URI parsing. WIMSE might allow for more relaxed requirements for general WIMSE identifiers, provided specific schemes (like Spiffy) remain valid.
- A sense of those present was that WIMSE should support both the Spiffy ID scheme and a WIMSE ID scheme, with a clear scheme identifier indicating which processing rules apply.
- A participant questioned the utility of allowing IP addresses in hostnames for trust domains and suggested avoiding this unless a clear use case emerges.
Proposed Separate Identifier Draft
- Discussion centered on whether to advance the "WIMSE identifier" as a separate Standards Track document, distinct from the Informational Track architecture document. A BCP document for path constructs was also suggested.
- Arguments for a separate draft included providing a dedicated venue for detailed discussions specific to identifiers and enabling other working groups to reference WIMSE Identifier without needing to refer to the broader architecture.
- The authors of the architecture and identifier drafts expressed a desire to avoid an excessive number of documents but saw merit in a separate identifier specification, especially if a specific WIMSE scheme were to be defined.
Workload Definition Terminology
- The current draft lacks a strict definition of "workload." A proposed definition: "independently addressable executable software entity."
- The intent is for this to cover microservices, containers, virtual machines, functions, and services composed of multiple workloads.
- Ambiguity arose regarding whether multiple instances behind a load balancer constitute a single workload or multiple. It was clarified that this depends on the point of view (external vs. internal).
- Chairs encouraged moving detailed wordsmithing of definitions to the mailing list or issue tracker.
Gateway Service vs. External Endpoint Terminology
- The "transaction token" draft uses "external endpoint," which is similar to the WIMSE architecture's "gateway service" and "identity proxy."
- Discussion explored whether these terms need to be reconciled. Some participants felt "gateway" implies an aggregation point, while "external endpoint" is more granular.
- It was suggested that an API gateway might function as both a gateway and an identity proxy, potentially requiring its own workload identity.
- The chairs noted that if terms are primarily scoped to the context of individual documents, less synchronization might be needed compared to establishing "ecosystem-level" terms.
Other Open Issues (briefly noted)
- Key management, attestation, and bound tokens are significant open issues. These topics might require separate drafts if explored in depth.

Decisions and Action Items

The authors of the architecture and identifier drafts will make a formal request to the chairs for an adoption call for a separate "WIMSE Identifier" draft.
Arndt will review the text accompanying the cross-domain use case to determine if it adequately addresses the pattern of mutually trusting signing keys in the absence of a token service.
The service-to-service document authors will coordinate with the WIMSE chairs if the topic or schedule of next week's interim meeting (currently set for service-to-service WGLC discussion) needs to change.

Next Steps

The working group aims for another draft of the architecture document before the Montreal IETF meeting.
The chairs will facilitate an adoption call for the proposed separate WIMSE Identifier document once the formal request is received.
Discussions on remaining open issues (key management, attestation, bound tokens) will continue on the mailing list, GitHub issues, or in future meetings.
The working group will assess its readiness for a Working Group Last Call for the architecture document, potentially in conjunction with the advancement of the service-to-service work.
Further discussions are expected at the Montreal IETF meeting.