[WIMSE] Re: Review of draft-klrc-aiagent-auth (editor's copy)

[Songbo Bu <[e-mail]>]

Hi Pieter,

Thanks, that makes sense to me.

My main concern was less the existence of the term and more making
sure the AIMS text makes clear when that trust-domain boundary is
enough for a WIMSE-only baseline, and when tenant, user, mission, or
delegation context has to be carried separately.

Issue #140 looks like the right place to capture that. I'll follow
there, and I'm happy to help with wording if useful.

Best,
Songbo Bu

On Mon, 8 Jun 2026 11:43:13 +0100, Pieter Kasselman
<[e-mail]> wrote:
> The term "trust domain" is defined in the WIMSE architecture draft and is used in that context. I opened an issue to add that clarification: https://github.com/PieterKas/agent2agent-auth-framework/issues/140
>
> Cheers
>
> Pieter
>
> On Sat, Jun 6, 2026 at 8:23 AM Songbo Bu <[e-mail]> wrote:
>
> Hi Andrii, Yaron, all,
>
> I agree tenant context is a useful additional axis. My read is that “same-domain” is not quite enough unless the draft says what domain means for this purpose.
>
> Maybe the baseline could be phrased more narrowly: WIMSE-only is enough when the call is same trust domain, non-delegated, and the callee does not need cryptographically carried tenant/user/mission context beyond the workload identity. Once tenant, principal, or delegation context must be carried or constrained, OAuth/token exchange or another signed authorization context becomes necessary.
>
> That would keep the baseline useful without making multi-tenant cases look simpler than they are.
>
> Best,
>
> Songbo Bu
>
> On Fri, 5 Jun 2026 11:51:56 -0700, Andrii Deinega [e-mail] wrote:
>
> Hi Yaron,
>
> My 2 cents on your [MAJOR-1], and partially, on [MAJOR-2].
>
> Are there cases where WIMSE identity alone is sufficient for access control, without an OAuth access token?
>
> I tend to think one of those use cases is when an AI Agent is a single-tenant application. If your agent happens to be a multi-tenant app where it needs to maintain and provide tenant context to the callee separately, then you won’t get much further… especially if you have a requirement to validate tenant claims cryptographically.
>
> Therefore, a valid baseline needs to be extended to include this aspect.
>
> WIMSE-only as a valid baseline for same-domain, non-delegated calls, with OAuth layered on top only when delegation context needs to be conveyed
>
> unless the “same-domain’ you used already covers it.
>
> All the best,
>
> Andrii
>
> On Wed, Jun 3, 2026 at 11:08 AM Yaron Sheffer [e-mail] wrote:
>
> Hi Authors,
>
> Thank you for this very impressive work on agents-as-workloads. As I mentioned in the meeting earlier today, I am very supportive of this work and of doing it within WIMSE.
>
> I also have a bunch of comments, below (in ietf-comment format). Please let me know if you prefer that I upload them as GitHub issues.
>
> Thanks,
>
> Yaron
>
> ————
>
> Yaron Sheffer’s review of draft-klrc-aiagent-auth (editor’s copy, 2026-06-01)
>
> CC @yaronf
>
> Major
>
> [MAJOR-1] WIMSE/OAuth interaction is underspecified
>
> The draft uses WIMSE and OAuth 2.0 throughout but never clearly defines how they relate to one another, or when each is required. Several questions go unanswered:
>
> -
>
> Are there cases where WIMSE identity alone is sufficient for access control, without an OAuth access token?
>
> -
>
> Are there cases where OAuth alone is sufficient, without a WIMSE workload credential?
>
> -

>
> When both are used together, how do the tokens relate? For example, should the WIMSE WIT and the OAuth access token carry the same sub claim?
>
> For the first question specifically: in plain workload-to-workload authentication, the callee sees a verified workload identity and makes an authorization decision locally — one round trip, no additional infrastructure. The draft is implicitly arguing that
>
> agents need OAuth on top because authorization is dynamic and fine-grained, delegation chains must be carried and verified, and authorization decisions may need to cross trust domain boundaries. Those are valid arguments, but the draft never states them explicitly,
>
> and never tells implementers when they can skip the OAuth layer.
>
> Suggested resolution: Add a section (or major appendix) that explicitly defines a tiered model — WIMSE-only as a valid baseline for same-domain, non-delegated calls, with OAuth layered on top only when delegation context needs to be conveyed. Complement this
>
> with a set of detailed use cases including sequence diagrams showing exactly which tokens flow where and what claims they carry.
>
> [MAJOR-2] Applicability to third-party/composed agent environments is not addressed
>
> The workload identity model is a good fit for traditional enterprise environments where workloads are home-grown, managed, and attested by the organization that deploys them. It is much less of a fit for environments where agents are purchased or rented from
>
> third-party vendors and composed into a system (the “agent marketplace” vision). In those cases the deploying organization may have limited ability to attest the agent, provision WIMSE credentials into it, or control its identity lifecycle.
>
> The draft should acknowledge this limitation and discuss what, if anything, the framework offers in that scenario.
>
> [MAJOR-3] Document status and use of normative language
>
> The document uses RFC 2119 language extensively, which is unusual for an Informational document and potentially confusing, since Informational documents are not standards-track. Moreover, many of the normative statements restate requirements already defined
>
> in the referenced specifications, making them redundant. This points to a deeper question the authors should address explicitly: what is the intended status of this document? If it is meant to seed new standardization work and describe best current practice,
>
> BCP status would be more appropriate. If it is meant to be a normative standard showing in detail how all the pieces of a complicated architecture fit together, Standards Track would be warranted. The current Informational framing fits neither goal well.
>
> Technical
>
> [TECH-1] Authorization policy left out of scope without adequate justification
>
> Section 11 excludes authorization policy from scope on the grounds that it is “deployment and risk-model-specific.” This mirrors a long-standing position of the OAuth community. However, the complexity of multi-agent systems — spanning organizations, trust
>
> domains, and dynamic delegation chains — means that even smaller deployments will need automated policy management. The main determinant of whether standardization is needed is not whether policies are deployment-specific, but whether interoperability requires
>
> a common policy language or exchange format, particularly for cross-domain scenarios.
>
> The draft should either scope in policy interoperability for cross-domain cases, or explain why it has concluded that no standard is needed there.
>
> [TECH-2] Deprovisioning is absent
>
> The document discusses credential provisioning and rotation (Section 7) but says nothing about deprovisioning. Section 7 should add a third phase — credential deprovisioning — even if it simply means stopping rotation when the agent is terminated. Beyond that,
>
> the identifier lifecycle is a distinct concern: when an agent is retired, its identifier needs to remain referenceable for forensic and audit purposes. The document should discuss how long an agent identifier should be retained, and in what registry, after
>
> the agent is gone.
>
> [TECH-3] Token exchange circularity in Section 9.5
>
> Section 9.5 describes exchanging access tokens for transaction tokens and then using transaction tokens to obtain access tokens (for downstream calls). This is architecturally circular and raises unresolved questions about how authorization scope is preserved
>
> or narrowed across this chain. Transaction tokens (draft-ietf-oauth-transaction-tokens) do not carry a standard scope claim, so it is unclear how scope semantics are maintained when re-obtaining an access token from a transaction token. This should be resolved
>
> or at least explicitly flagged as an open issue.
>
> [TECH-4] LLM must not have access to agent credentials
>
> Section 7 (Credential Provisioning, which now encompasses attestation/posture assessment) should state explicitly that the LLM inference component of an agent MUST NOT have access to the agent’s cryptographic credentials. The LLM is the most vulnerable part
>
> of the agent to prompt injection attacks; a compromised prompt could cause the LLM to exfiltrate credentials or use them for unauthorized actions. Credential access must be strictly separated from the data flow that passes through the LLM. This is a security
>
> property that the architecture should mandate, not leave to implementers.
>
> [TECH-5] Live posture assessment not mentioned
>
> Section 7 discusses posture assessment only in the context of credential issuance and rotation. The document should also mention the possibility of continuous or live posture assessment, bound to individual workload-to-workload messages — for example, including
>
> a fresh attestation assertion in a WPT or HTTP Message Signature. This is particularly relevant in high-risk or cross-domain scenarios.
>
> [TECH-6] Streaming interactions not addressed
>
> Section 3 and Figure 1 depict agents that exchange discrete messages. Many real agent interactions involve streaming — text token streams, audio, and video are common. The document should clarify whether streaming interactions are in scope and, if so, how the
>
> authentication and authorization model applies to a long-lived streaming session.
>
> [TECH-7] User consent not mentioned
>
> User consent — distinct from user delegation via OAuth — is not discussed. Whether or not it is in scope for this framework, it deserves at least a brief mention, including a pointer to relevant work (e.g., MCP’s user confirmation model, or emerging consent
>
> frameworks).
>
> [TECH-8] CIBA not cited from text; human-in-the-loop model too narrow (Section 9.7)
>
> Section 9.7 mentions CIBA by name but does not include an inline citation to [OpenIDConnect.CIBA], even though that reference exists in the references list. Please add the citation.
>
> Additionally, the CIBA-based model may be too constrained. CIBA assumes a push notification to a separate device, but the main agent flow may already be running on a mobile device. More importantly, the threat model here is different from typical 2FA: the primary
>
> concern is not an external attacker but the agent itself acting outside its authorized scope. Explicit user consent mechanisms should be discussed in light of that threat.
>
> [TECH-9] MCP reference in Section 9.7 is too vague
>
> The reference to MCP’s user-solicitation pattern should point to a specific section or feature of the MCP specification rather than the top-level spec URL.
>
> Editorial
>
> [EDIT-1] Section 3, last paragraph: add OpenID Connect
>
> The list of standards the document builds on (SPIFFE, WIMSE, OAuth, SSF) should include OpenID Connect, which is used extensively in Section 9.
>
> [EDIT-2] Figure 2: Observability belongs in the vertical, not a layer
>
> In Figure 2, “Monitoring, Observability & Remediation” is shown as a horizontal layer. It is better characterized as a cross-cutting vertical, as it applies across all other layers, similar to how Policy and Compliance are depicted.
>
> [EDIT-3] Section 4: AIMS is defined but never used
>
> Section 4 defines the term “Agent Identity Management System (AIMS)” but the acronym does not appear again in the document (except once). Either use it consistently throughout, or drop it. Additionally, the word “system” implies a single centralized entity;
>
> “framework” or “model” would be more accurate given the explicitly distributed nature of the components described.
>
> [EDIT-4] Section 6: SPIFFE credential paragraph is imprecise
>
> The paragraph conflates SPIFFE credential types. SPIFFE WIT-SVID is a WIMSE credential. Other SPIFFE credential formats (X.509-SVID, JWT-SVID) are not WIMSE credentials. The text should be more precise about which formats are which.
>
> –
>
> WIMSE mailing list – [e-mail]
>
> To unsubscribe send an email to [e-mail]
>
> --
>
> WIMSE mailing list -- [e-mail]
>
> To unsubscribe send an email to [e-mail]