The tempting shortcut in agent identity is a long name. spiffe://example.com/ns/prod/team/payments/role/reconciler/service/reconciliation looks self-describing, and relying parties can authorize on the path — until a team is renamed, a role narrows, or an auditor asks what an identifier meant two years ago. On 16 October 2026, an Internet-Draft proposed by engineers from Palo Alto Networks and Zscaler sets out to separate the identifier from the attributes it keeps being asked to carry.
What happened
The document, draft-heigh-wimse-workload-identity-metadata-00, is an individual Internet-Draft with Standards Track intended status, authored by Shlomo Heigh and Joseph Salowey (Palo Alto Networks) and Yaroslav Rosomakho (Zscaler). It expires on 19 April 2027 and is discussed on the WIMSE (Workload Identity in Multi System Environments) working group list, but it is not a working-group document.
Its premise is one sentence: an identifier denotes a workload; metadata describes it — different things with different lifetimes, authorities and exposure. The draft lists six reasons not to encode attributes in identifiers, and they are independent, so fixing one does not fix the others:
- Path semantics are not guaranteed. The WIMSE identifier specification requires consumers to compare the complete URI, and warns that prefix matching “may lead to incorrect authorization”.
- Lifetimes differ. Identifiers are stable and are what grants and audit records refer to; attributes change. Either re-identify (breaking every grant and historical record) or let the identifier assert something no longer true.
- Cardinality multiplies. n encoded attributes give an identifier space that is their cross product.
- Exposure is maximal. The identifier appears in every audit log on the call path, in certificate subject alternative names during TLS handshakes, and in diagnostics.
- Authority differs. Whoever assigns an identifier need not be the authority for a role.
The proposed alternative reuses claims that already exist instead of inventing new ones: groups, roles and entitlements as registered in the OAuth JWT claims registry (defined by reference to SCIM), carried either in a JWT-based Workload Identity Credential — a WIMSE workload identity token or JWT-SVID, with a metadata_uri claim naming the endpoint — or retrieved from an authenticated metadata endpoint. X.509-authenticated workloads reach the same endpoint through a Subject Alternative Name URI extension. The endpoints are selected in a fixed order: an out-of-band configured URI first, then the URI carried in a validated credential, then a default.
Two rules in the model do most of the KYA work. First, the claims describe the workload, not any person or system associated with it: a relying party “MUST NOT interpret them as describing any associated principal.” Second, an unrecognized value “conveys no authority rather than as a wildcard.”
The draft has a dedicated Agentic Use Cases section. AI agents are workloads: they may run as long-lived services, ephemeral tasks, or several concurrent instances. Three cases are spelled out — autonomous operation under the agent’s own workload identity; delegated operation, where the credential still identifies the agent while a separate authorization context expresses the delegation (following the WIMSE AI identity framework’s OAuth profile, where the agent’s identifier appears in the access token’s client_id and the delegating principal in sub); and shared execution environments, where agents needing separate authorization or attribution must have distinct identifiers. In all three, the agent’s groups and roles “do not become those of the delegating principal.”
Why it matters for KYA
This is the least glamorous and most load-bearing part of knowing your agent: getting the identifier’s job right so that everything built on top of it — grants, logs, revocation — refers to something stable.
- It draws the line KYA depends on, in protocol terms. “Who is the agent” (a WIMSE identifier, one per agent) and “who is it acting for right now” (an authorization context, per request) are different fields in different artifacts. Every agent-onboarding review that starts by asking how the agent is identified should ask where the delegated principal is expressed, and this draft says that belongs in the access token, not the identity credential.
- An owner is not an authority. The draft is explicit that a durable owner or operator association “does not itself confer authority to act on that principal’s behalf,” and it declines to define a claim for that association yet, listing it as an open issue. That is the distinction between accountability (“who answers for this agent?”) and authorization (“what may it do?”), which are routinely merged in vendor scorecards. It also means the accountability half of KYA has no standard claim to point at today — useful to know when a vendor claims otherwise.
- Authority in an identity credential changes what the credential is. The security considerations note that metadata expressing authority turns an identity credential into a capability, with three consequences: a permission revoked at the authorization server is still asserted by any unexpired credential carrying it; the credential and the relying party’s policy become two sources of truth for one decision; and because an identity credential is presented to every relying party, enumerating permissions discloses the workload’s full authority to each of them. Keep authority in the authorization context, and the identity credential stays an identity credential.
Sources
- IETF Datatracker, draft-heigh-wimse-workload-identity-metadata-00, “Workload Identity Metadata”, Heigh, Salowey, Rosomakho, 16 October 2026 — datatracker.ietf.org; full text at ietf.org.
- IETF, RFC 8693, “OAuth 2.0 Token Exchange” — the mechanism the draft points to for expressing delegation in tokens — rfc-editor.org.
- IETF WIMSE working group — the group the draft is aimed at, and home of the workload identity and AI identity framework documents it builds on — datatracker.ietf.org.
- Draft source and issue tracker — github.com.
Note: scope, wording and the open issues are as stated in the draft itself. It is an individual submission with no working-group status; the WIMSE workload identity and AI identity framework documents it references are works in progress.
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.