The biggest problem I see with OIDC for agents is delegation—specifically, how one agent delegates authority to another agent acting on its behalf.
The microservice identity model breaks down when you have chains of agents, each potentially operating with different levels of autonomy and trust. OIDC was designed for human-to-service flows, not for dynamic agent-to-agent delegation where the context, scope, and risk profile can shift rapidly.
I've been thinking we might need something closer to capability-based security or macaroons—where delegation is explicit, scoped, and auditable at each step. The key difference: instead of "who is this agent?" we should be asking "what specific action is this agent authorized to perform right now, and who in the chain vouches for it?"
I have been experimented with SPIFFE/SPIRE for agent identity or explored using verifiable credentials for delegation chains.
You’re mixing models that don’t really fit together. SPIFFE isn’t designed for delegation at all—it’s a PKI-style system: centralized issuance, short-lived certs, and a single trust root per domain. It gives workloads authenticated identity, not transitive authority. There’s no notion of “A acts on behalf of B” baked into SPIFFE.
Verifiable Credentials (VCs) solve a different problem. They’re decentralized, flexible, and can express explicit delegation chains like “A asserts B may perform X.” That’s capability-style reasoning, not identity issuance.
Trying to bolt VC-style delegation onto SPIFFE breaks both systems’ assumptions:
SPIFFE’s hierarchical trust model doesn’t mesh with the web-of-trust VC model.
Its short-lived SVIDs don’t persist long enough for meaningful delegation chains.
SPIRE doesn’t understand VC proofs (JSON-LD, linked data signatures).
You’d need a whole external policy and capability layer to make it work.
SPIFFE nails workload identity; VCs and capability systems handle delegation and contextual authority. Mixing them because “they both do identity” misses the point—they live at different layers of the trust stack.
If you’re trying to make SPIFFE handle delegation, you’re forcing the wrong layer to do the wrong job. SPIFFE gives you workload identity and attestation, full stop. It’s PKI for machines — not a delegation framework.
A better model is to separate identity from capability:
SPIFFE/SPIRE handles who the agent is (short-lived, attested identity).
Capabilities / Macaroons / ZCAP-LD handle what that agent is allowed to do, and who delegated it.
OPA or Cedar enforces policy at runtime.
VCs come in only if you need cross-domain delegation (federated or multi-issuer trust).
So SPIFFE issues identities, and those identities mint or receive verifiable capabilities that describe explicit rights. You get composable, auditable delegation without breaking SPIFFE’s short-lived cert model or pretending it can do web-of-trust semantics.
Trying to bake delegation into SPIFFE itself is just reimplementing capability security badly.
I do understand what you are saying, but in my head feels a bit too overcomplicated to just tell any developer doing AI agents to do all this stuff, there most be a cleaner way to do it.
Thanks, that is what I was looking for. Been playing with delegation chains using tokens, and was wondering what else has been done. The only down side I see to the google approach is TLS from a verified CA, rotation of certs is always a pain. But I guess they figured that building in top of what is already there is better than inventing a new way.
The biggest problem I see with OIDC for agents is delegation—specifically, how one agent delegates authority to another agent acting on its behalf.
The microservice identity model breaks down when you have chains of agents, each potentially operating with different levels of autonomy and trust. OIDC was designed for human-to-service flows, not for dynamic agent-to-agent delegation where the context, scope, and risk profile can shift rapidly. I've been thinking we might need something closer to capability-based security or macaroons—where delegation is explicit, scoped, and auditable at each step. The key difference: instead of "who is this agent?" we should be asking "what specific action is this agent authorized to perform right now, and who in the chain vouches for it?"
I have been experimented with SPIFFE/SPIRE for agent identity or explored using verifiable credentials for delegation chains.
You’re mixing models that don’t really fit together. SPIFFE isn’t designed for delegation at all—it’s a PKI-style system: centralized issuance, short-lived certs, and a single trust root per domain. It gives workloads authenticated identity, not transitive authority. There’s no notion of “A acts on behalf of B” baked into SPIFFE.
Verifiable Credentials (VCs) solve a different problem. They’re decentralized, flexible, and can express explicit delegation chains like “A asserts B may perform X.” That’s capability-style reasoning, not identity issuance.
Trying to bolt VC-style delegation onto SPIFFE breaks both systems’ assumptions:
SPIFFE’s hierarchical trust model doesn’t mesh with the web-of-trust VC model.
Its short-lived SVIDs don’t persist long enough for meaningful delegation chains.
SPIRE doesn’t understand VC proofs (JSON-LD, linked data signatures).
You’d need a whole external policy and capability layer to make it work.
SPIFFE nails workload identity; VCs and capability systems handle delegation and contextual authority. Mixing them because “they both do identity” misses the point—they live at different layers of the trust stack.
what will be a better approach then?
If you’re trying to make SPIFFE handle delegation, you’re forcing the wrong layer to do the wrong job. SPIFFE gives you workload identity and attestation, full stop. It’s PKI for machines — not a delegation framework.
A better model is to separate identity from capability:
SPIFFE/SPIRE handles who the agent is (short-lived, attested identity).
Capabilities / Macaroons / ZCAP-LD handle what that agent is allowed to do, and who delegated it.
OPA or Cedar enforces policy at runtime.
VCs come in only if you need cross-domain delegation (federated or multi-issuer trust).
So SPIFFE issues identities, and those identities mint or receive verifiable capabilities that describe explicit rights. You get composable, auditable delegation without breaking SPIFFE’s short-lived cert model or pretending it can do web-of-trust semantics.
Trying to bake delegation into SPIFFE itself is just reimplementing capability security badly.
I do understand what you are saying, but in my head feels a bit too overcomplicated to just tell any developer doing AI agents to do all this stuff, there most be a cleaner way to do it.
Search "A2A", it was proposed by Google and seeing adoption
Thanks, that is what I was looking for. Been playing with delegation chains using tokens, and was wondering what else has been done. The only down side I see to the google approach is TLS from a verified CA, rotation of certs is always a pain. But I guess they figured that building in top of what is already there is better than inventing a new way.