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

[Songbo Bu <[e-mail]>]

Hi Yaron, authors,

Yaron’s TECH-4 matches one of the boundaries I would also expect the draft
to make explicit.

One small way to frame it: the LLM-facing part of an agent should be
treated as untrusted input/output processing, not as the component that
directly holds or exercises workload credentials. Credentials, WITs, token
exchange, signing keys, and proof-of-possession operations should sit
behind a policy-enforcing component that receives a constrained request
from the model/runtime and can reject it independently.

That distinction would also help with delegated and third-party agent
cases: even if the agent’s natural-language planner is compromised or
confused by prompt injection, the credential-using component still has a
narrower execution context and authorization policy to enforce.

Best,
Songbo Bu

On Wed, 3 Jun 2026 18:06:57 +0000, 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.