“Last year, I wrote about securing the software supply chain and how SCITT, SPIFFE, and WIMSE fit together. At the time, I described WIMSE—the IETF’s Workload Identity in Multi System Environments working group—as one of the important pieces in making sure software workloads can establish and use identities securely.”
That is still true, but WIMSE has gotten a lot more interesting since then.
The working group now has seven active adopted Internet-Drafts, another document making its way through the IETF publication process to become an RFC, and a growing collection of individual drafts orbiting the group. And if you look at the mailing list, you will see discussions not just about workload credentials and authentication, but also AI agents, delegation, cross-organization trust, attestation, authorization evidence, audit records, discovery, and post-quantum requirements.
So, yes, there is a lot going on. If you work on non-human identity, authorization, AI agents, cloud security, or anything involving software talking securely to other software, WIMSE is a group worth following.
You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.
And be sure to leave me a Rating and Review!
First, What Is a Workload?
A workload is software executing to perform some particular function. That might be a microservice running in Kubernetes, a function running in a cloud platform, software in a CI/CD pipeline, or an AI agent calling tools and services. Unlike a human user, a workload generally needs to authenticate without someone sitting there typing a password or approving a login prompt.
And modern workloads move around, sometimes quite a bit. They run across cloud providers, clusters, service meshes, and administrative domains. They are created and destroyed dynamically. They call other services, which call still more services. Long-lived API keys and manually provisioned secrets become both operationally painful and dangerous pretty quickly. Which makes this a fascinating architectural problem. How do you build an environment to do all this safely and securely?
The WIMSE charter describes the goal as enabling fine-grained, least-privilege access control for workloads operating across multiple service platforms, including public and private clouds. The group is explicitly trying to bridge gaps between existing technologies rather than invent an entirely separate identity universe.
WIMSE lives in an Internet architecture already built on things like URIs, TLS, HTTP, JSON Web Tokens, OAuth, and X.509 certificates. Its job is largely to define how those pieces can be used coherently when the thing on the other end is software rather than a person. I appreciate them not reinventing those pieces where they don’t have to.
Building the Basic WIMSE Stack
I adore architecture documentation. The way my brain works requires me to start with that, then figure out what pieces are missing or need adjusting. So, you can probably guess that when there is such a document for an area of work, I’m going to suggest starting there to understand what’s going on. And sure enough, the WIMSE Architecture draft describes the overall model for conveying workload identity and security context information across environments.
From there, the group needs to answer a basic question: What do we call a workload? You would think this should be easy, but alas, words are hard.
The Workload Identifier draft defines a URI-based identifier that identifies a workload within a trust domain. A trust domain is basically the administrative boundary within which some authority controls the identities it issues. The URI approach also means WIMSE does not have to invent an entirely isolated naming system. The specification explicitly allows schemes such as SPIFFE IDs as well as WIMSE identifiers.
Which is necessary and good, but an identifier alone does not prove anything.
That brings me to WIMSE Workload Credentials. This draft defines credentials that bind a workload identity to cryptographic key material. The important idea here is that these are proof-of-possession credentials. Stealing the credential itself should not be enough; the workload must also demonstrate that it controls the associated private key.
Then WIMSE needs ways to actually use those credentials. There are currently three approaches.
The mutual TLS draft uses X.509 certificates and mutual TLS, or mTLS. Normal TLS lets a client authenticate the server it is connecting to. With mutual TLS, both sides authenticate, allowing one workload to establish the identity of another during the connection.
The Workload Proof Token draft takes an application-layer approach. A workload has a Workload Identity Token and produces a signed Workload Proof Token demonstrating possession of the corresponding private key and binding that proof to an HTTP request.
And the HTTP Signatures draft provides another application-layer mechanism, this time using HTTP Message Signatures.
That gives WIMSE something resembling a stack: an architecture, an identifier, credentials, and multiple ways to authenticate workloads using those credentials.
There is also Workload Identity Practices, which documents how workload identities are already being handled in container orchestration systems, cloud platforms, and similar environments. That document has progressed beyond the working-group drafting stage and is currently with the IESG, which means it is well on its way to becoming an informational RFC. Importantly, it documents current industry practice rather than the new WIMSE architecture itself.
So far, so sensible. Then the AI agents stirred the pot. Bless their little electronic hearts.
Are AI Agents Workloads?
WIMSE’s answer, increasingly, is: yes. In September, the group formally adopted AI Identity Management System, or AIMS. AIMS starts from the proposition that an AI agent is a type of workload and asks how the existing WIMSE and OAuth building blocks can be applied to agent authentication and authorization.
I think this is one of the most important aspects of the work.
There is enormous pressure right now to treat AI agents as an entirely new category requiring entirely new identity protocols. Sometimes new mechanisms really will be necessary. But starting with “what do we already know how to do?” is generally much healthier Internet engineering. AIMS tries to establish that baseline.
An agent needs an identifier. It needs credentials cryptographically bound to that identifier. It needs to authenticate when interacting with tools, services, and resources. It may also need OAuth when seeking authorization to access something. Once you have that model, you can start asking the harder questions.
The Interesting Problems Are Moving Outward
Look at the related Internet-Drafts on the WIMSE page, and you get a remarkably good view of where people think the unsolved problems are.
To be clear: these are individual drafts, not adopted WIMSE work. Some may eventually be adopted, some may belong elsewhere in the IETF, some may merge with other work, and some may go nowhere. These drafts have no formal standing whatsoever.
But as a map of the problem space, the list is fascinating.
There are drafts exploring cross-organizational delegation and delegation chains. These concepts are important when an agent acting under some authority delegates part of a task to another agent, which delegates something else again. How does the ultimate service know where that authority came from? How can each step narrow the authority rather than accidentally expand it?
One proposal describes verifiable attenuated delegation, where each successive delegation can carry no more authority than the previous one.
Other drafts look at authorization evidence and audit records: not just whether an agent was authenticated, but what authorization decision was made, why, and what actually happened afterward. One recent proposal defines an audit record for AI agent authorization decisions because AIMS identifies the need for those records without specifying their format.
There is work on attestation, too. Authentication can tell you which workload possesses a credential. Attestation tries to provide trustworthy evidence about the environment or software that workload is actually running. One proposal explores carrying that evidence through deployments where TLS-terminating proxies would otherwise break the direct connection between the workload and verifier.
And then there is trust discovery. (I do love discovery.)
Within one organization, distributing trusted keys and configuring trust relationships is manageable. Across organizations, it becomes much harder. A proposal for WIMSE Trust Domain Discovery explores how a relying party could securely discover the trust anchors associated with a workload’s trust domain when the two sides do not already have a relationship.
That problem should sound familiar to anyone who has followed my earlier writing about discovery. Finding something is only the first step. The much more interesting question is what you know about what you found and why you should trust it.
Identity Is Not Authorization
There is another boundary getting a lot of attention: the one between proving what a workload is and deciding what that workload is allowed to do. Those are not the same thing. I’m not entirely certain why the industry has to keep re-learning that point, but here we are.
WIMSE’s original foundation is strongly focused on workload identity and authentication. But once authenticated workloads need to act across systems, authorization inevitably appears.
One particularly interesting individual draft is the Workload Authorization Grant. It explores how a workload hosted on one platform could obtain OAuth access tokens from another organization’s authorization server without administrators having to manually provision every individual workload in advance. AI agents are the motivating use case, but the underlying problem is broader.
That draft is important enough that WIMSE had an interim meeting specifically to discuss it on 7 October 2026.
The existence of that draft is an interesting architectural boundary. How much authorization work belongs in WIMSE? How much belongs in OAuth? When is an agent-specific problem really a workload-identity problem? When is delegation part of identity infrastructure, and when does it belong somewhere else? Definitely a space to keep an eye on.
Why Follow WIMSE?
The interesting thing about WIMSE right now is not that the architecture is undefined. The group has an architecture draft, and the core workload identity machinery is becoming increasingly concrete: identifiers, credentials, proof of possession, mTLS, and HTTP-layer authentication. That’s a lot of excellent work from a bunch of smart people.
What is still being worked out, however, is how far that architecture needs to reach.
AI agents and cross-organizational use cases are pushing on the edges of the model and exposing everything that sits around workload identity: authorization, delegation, discovery, attestation, auditability, cross-domain trust, and the boundaries between those functions.
Some of the current proposals will survive. Others will not. Some will probably move to different working groups once the IETF decides where they fit. But the questions themselves are not going away.
If you are responsible for cloud infrastructure, non-human identity, API security, authorization, or agentic systems, WIMSE provides a useful view of where the architecture beneath all those things is being worked out.
And, as I said when I wrote about WIMSE last year, this is the kind of standards work that rarely gets flashy headlines. It is the kind that ends up underneath everything.
📩 If you’d like to be notified of new posts rather than hoping you catch it on social media, I have an option for you! Subscribe to get a notification when new posts go live. No spam, just announcements of new posts. [Subscribe here]
Transcript
Welcome to the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. I’m Heather Flanagan, and every week I break down interesting topics in the field of digital identity, from credentials and standards to browser weirdness and policy twists.
If you work with digital identity but don’t have time to follow every specification or hype cycle, you’re in the right place.
Let’s get into it.
Last year, I wrote about securing the software supply chain. As part of that, I discussed a few different standards efforts trying to make software itself more trustworthy.
One of those efforts is WIMSE, an IETF working group focused on workload identity in multi-system environments.
It was interesting because it addressed a problem that sounded fairly specialized until you realized how much modern infrastructure depends on it: software needs identities too.
A year later, WIMSE has become even more interesting.
The group has a growing stack of adopted work around workload identity credentials and authentication. However, its mailing list also includes discussions about AI agents, delegation, authorization, attestation, audit records, trust discovery, and interactions across organizational boundaries.
Not all of those topics will become standards. In fact, not all of the proposals will necessarily be adopted by the working group and continue forward.
Deciding which ideas belong in WIMSE, and where its scope should end, is part of the discussion.
I think that’s precisely why the group is worth watching.
What Is Workload Identity?
First, let’s back up for a moment. What exactly is a workload?
A workload is software running to perform a task. For example, it might be:
- A microservice running in Kubernetes
- A function running in a cloud environment
- Software operating in a CI/CD pipeline
- An AI agent calling tools and services on behalf of a person or organization
The important point is that there generally isn’t a human sitting there logging in.
The software still needs to establish who or what it is. Other systems, in turn, need confidence in that identity before deciding whether to allow it to do anything.
Historically, we haven’t handled this particularly well.
We’ve used API keys, shared secrets, long-lived credentials, and configuration files containing passwords. Sometimes those secrets get copied between environments and left somewhere they absolutely shouldn’t be, such as a public GitHub repository.
That situation gets increasingly ugly when software is created and destroyed dynamically, moves across cloud providers and clusters, and makes requests across organizational boundaries.
This is the basic architectural problem WIMSE is addressing.
Building a Workload Identity Architecture
When I say architecture, I mean that quite literally.
WIMSE has an architecture draft describing how workload identity and related security contexts can be conveyed across different environments.
The important thing about that architecture is that it doesn’t assume WIMSE gets to replace everything already on the Internet.
Quite the opposite.
It builds on things we already have, including:
- URIs
- TLS
- HTTP
- OAuth
- X.509 certificates
That’s generally a good sign. Standards work tends to go better when the first instinct isn’t, “Clearly, what the Internet needs is an entirely new identity universe.”
From that architecture, WIMSE starts answering some fairly fundamental questions.
First, how do you identify a workload?
Workload Identifiers and Trust Domains
The working group has adopted a draft for workload identifiers. It defines a URI-based way to identify a workload within a trust domain.
In this context, a trust domain is essentially an administrative boundary within which some authority controls the issuance of identities.
Using URIs means WIMSE can work with existing identifiers rather than insisting everyone adopt one new global naming scheme.
SPIFFE identifiers, for example, can fit into this model.
However, an identifier is really just a name.
Saying, “I am this workload,” doesn’t prove that you actually are that workload.
That’s where credentials come in.
Workload Credentials and Proof of Possession
WIMSE is defining workload credentials that bind a workload identity to cryptographic key material.
These are essentially proof-of-possession credentials.
This concept is worth understanding because it comes up constantly in modern identity systems.
Proof of possession means that having the credential by itself isn’t enough. You also have to prove that you control the private cryptographic key associated with it.
As a result, stealing a credential becomes less immediately useful to an attacker.
Once you have an identifier and a credential, you need a way to use them when workloads communicate.
WIMSE is working on several approaches.
Authenticating Workloads with Mutual TLS and HTTP Signatures
One approach uses mutual TLS, usually shortened to mTLS.
In ordinary TLS, which secures HTTPS connections, the client typically authenticates the server.
With mutual TLS, both sides authenticate. This allows two workloads to establish each other’s identity as part of creating the connection.
There are also mechanisms that operate higher up, at the HTTP layer.
One uses something called a workload proof token. The workload signs information to demonstrate that it possesses the relevant key and that the proof applies to a particular HTTP request.
Another mechanism uses HTTP message signatures.
You don’t need to remember all those protocol names. The useful point is that WIMSE is putting together something that resembles a coherent stack:
- An architecture for workload identity
- Workload identifiers
- Credentials tied to cryptographic keys
- Multiple ways for workloads to authenticate when they communicate
There’s also work documenting how workload identity is already handled in existing cloud and container environments.
That’s useful because standards should ideally understand what people are actually doing before declaring how everyone ought to do it instead.
Why AI Agents Are Part of the Workload Identity Conversation
So far, this has mostly been a story about infrastructure.
Then the AI agents show up.
WIMSE has adopted a draft called AIMS, the AI Identity Management System, which starts from an interesting position: an AI agent is a type of workload.
That sounds pretty simple, but it pushes back on a tendency I’m seeing everywhere right now.
Because AI agents feel new, there’s an assumption that every part of their identity infrastructure and architecture must also be new.
Hmm. I have questions.
Sometimes new mechanisms will absolutely be necessary. However, we already know a lot about identifying software, binding credentials to keys, authenticating clients, and authorizing access to resources.
AIMS starts there.
An agent needs an identifier. It needs credentials. It needs to authenticate when it calls another service. And, where appropriate, it may use OAuth to obtain authorization to access something.
That brings us to the really interesting part.
Authentication only gets you so far.
Delegation and Authorization Across Organizations
Once software starts acting more autonomously, particularly across organizational boundaries, the questions expand very quickly.
Consider delegation.
Suppose I authorize an agent to perform a task. That agent calls another agent, which calls a service. Perhaps that service invokes something else.
Eventually, some resource receives a request and has to decide whether to allow it.
At that point, several questions arise:
- Where did the authority behind the request come from?
- What exactly was delegated?
- Can each hop narrow the permissions it receives?
- Can a hop accidentally expand those permissions?
- Can the ultimate service determine who originally authorized the activity?
These are all delegation questions.
Individual drafts being discussed around WIMSE explore these problems. However, those drafts haven’t all been adopted by the working group.
Some proposals may eventually become WIMSE documents. Others may go to OAuth or another IETF working group, merge with other proposals, or simply disappear.
That’s normal in standards development.
Looking at the individual drafts is still useful because they show where implementers are finding gaps, or at least where they think gaps exist.
Delegation is definitely one of those areas. Authorization is another.
It may not be enough to know that an agent successfully authenticated.
It certainly won’t be enough in every situation.
A system may also need to know what authorization decision was made, under what authority, and perhaps why.
Why Authorization Audit Records Matter
Once an autonomous system starts doing significant things, auditability becomes important.
One proposal being discussed, for example, looks at standardized audit records for agent authorization decisions.
This is a natural extension of the broader authorization problem.
If software acts on behalf of a person or organization, and that activity involves multiple agents or services, it becomes increasingly important to understand how a decision was reached.
Authentication tells you something about the identity of the workload.
Authorization determines what that workload is allowed to do.
Audit records can help establish what decision was made and provide a record of the activity.
These concerns are related, but they aren’t interchangeable.
Workload Attestation and the Environment
Then there’s attestation.
Authentication answers questions such as, “Does this workload control the keys associated with this credential?”
Attestation tries to answer a somewhat different question about the environment in which that workload is running.
For example:
- What software is running?
- What platform is it running on?
- Is the environment in an expected state?
Those claims can also be useful, but they make the trust model more complicated.
Knowing which key a workload controls is not the same as knowing what software is running or whether its environment meets particular requirements.
As workload identity expands into more complex environments, these distinctions become increasingly important.
Trust Discovery Across Organizational Boundaries
Discovery is another area worth watching.
I’ve spent quite a bit of time writing about discovery because it’s almost never just a matter of finding something within one organization.
Configuring which authorities you trust may be manageable across organizations. It gets harder when an unfamiliar workload appears with an identity from another trust domain.
How do you discover the right trust information?
And after you discover it, why should you believe it?
There are proposals exploring that problem, too.
This is where WIMSE starts connecting to a much broader set of architectural questions.
The challenge isn’t simply finding a workload identifier or locating a credential. It’s understanding which authority issued the information, what that authority means in context, and whether the information should influence a trust decision.
Identity Is Not Authorization
One boundary deserves particular attention: the difference between identity and authorization.
Proving what a workload is and deciding what a workload is allowed to do are very different problems.
They’re related, but different.
Collapsing them together tends to produce systems that are difficult to reason about.
WIMSE began primarily from the workload identity and authentication side. However, the moment authenticated workloads need to act across organizations, authorization and delegation become unavoidable.
There’s already an individual proposal for something called a workload authorization grant.
The basic idea is to allow a workload hosted in one environment to obtain an OAuth access token from another organization without requiring administrators to manually provision every workload in advance.
AI agents are one motivating use case, but the underlying problem is broader.
And I think that’s where the WIMSE mailing list becomes particularly valuable to follow.
Where Should WIMSE Draw the Line?
The WIMSE discussions raise a series of important architectural questions.
How far should workload identity architecture extend?
Which delegation problems belong here?
Which authorization problems belong in OAuth instead?
What does WIMSE need to standardize to support trust across organizations?
And where should attestation fit?
Finally, when someone brings in a new AI agent problem, is it actually a new problem at all?
None of these boundaries are completely settled. That’s not a criticism.
The core architecture is becoming pretty solid. What the group is working through now is how that architecture behaves when it encounters increasingly complicated real-world systems.
That makes WIMSE useful, even if you never implement a WIMSE specification directly.
Why Workload Identity Matters Beyond AI
If you work on non-human identity, cloud infrastructure, API security, authorization, or agentic systems, watching this group gives you a fairly good view of the problems emerging underneath all these areas.
Some of the proposals currently being discussed will survive. Others won’t.
Some will end up somewhere else in the IETF because, after discussion, it turns out that’s where they belong.
However, the underlying questions they’re trying to answer aren’t going to go away.
That’s one of the reasons I like to follow standards work in the first place.
The interesting part isn’t just seeing the finished protocol after all the arguments have stopped. It’s seeing which assumptions break when people try to apply the architecture to the next problem.
What to Watch in WIMSE Next
For links to the WIMSE Working Group, its current drafts, and the earlier post where I put WIMSE into the broader software supply chain context, take a look at the written version of this post.
Do have a look, because there’s a lot of interesting work happening in WIMSE right now, and I suspect there will be a lot more soon.
About the Digital Identity Digest
And that’s it for this week’s episode of the Digital Identity Digest.
If it helps make things a little clearer, or at least a little more interesting, share it with a friend or colleague and connect with me on LinkedIn @hlflanagan.
If you enjoyed the show, be sure to subscribe and leave me a rating and review on Apple Podcasts or wherever you listen to podcasts.
You can also find the written full post at Spherical Cow Consulting.
Stay curious, stay engaged, and let’s get these conversations going.