[UC] Causal Capability and Authorization that Survives where bearer tokens dissolve

[ngallo]

Summary

A Message-Centric Capability Model That Defines the Trust Rails for Autonomous Agents

This use case introduces a paradigm shift in enterprise authorization.

It deliberately avoids AI hype and focuses on the foundational layer of trust: secure capability delegation between autonomous agents and workloads operating across synchronous and asynchronous distributed systems.

Bearer token models (OAuth/OIDC, SPIFFE/SVID, mTLS session identity, embedded JWT claims) dissolve when they cross asynchronous boundaries. Event-driven architectures break their semantics:

• No holder binding
• Subject substitution
• Silent impersonation by downstream services
• Token replay across transport boundaries
• Credential leakage into logs and DLQs

Instead of stretching HTTP-centric identity protocols across brokers and streams, this use case embraces the reality of distributed systems:

• A capability token is valid only within the distributed transaction in which it was delegated.
• Outside that transaction, the capability is inert.

This replaces identity as the core primitive with capability plus causality:
Capability is contextual

• Capability is contextual
• Capability is cryptographically delegated
• Capability is tied to a transaction boundary
• Capability is revocable at any hop
• Capability cannot be replayed by entities that cannot prove they are in the chain.

The model becomes a superset security paradigm. It ingests any input (OAuth tokens, SPIFFE workload identities, mTLS client certificates, Verifiable Credentials / Presentations, SD-JWTs, enterprise attestations) and converts them into verifiable delegated capability preserved through:

• DIDComm Trust Envelopes (TDE)
• Message-based provenance
• Hash-linked continuity across hops

These are the new trust rails:

• Rails that survive message flows where bearer tokens dissolve
• Rails that define a single security model across public internet and private enterprise environments
• Rails that treat workloads and agents (including AI Agents) as first-class principals
• Rails governed by distributed transaction semantics, not static identity snapshots

On top of this substrate, higher layers of trust (governance, AI safety, risk models, prompt provenance) can be built. But without this substrate, none of those layers can operate safely in real distributed systems.

Driving User Story

As an Enterprise Software Architect,
I want to integrate AI Agents and internal workloads across security boundaries using asynchronous messaging,
with scoped, delegated capabilities instead of bearer-token snapshots,
so that identity continuity, safety constraints, and compliance are preserved across distributed transactions without replay, impersonation, or credential leakage.

Context

• [X ] I have looked for similar use cases and feel this issue is a distinct use-case, rather than best encoded as a variant or "alternate path" to an existing one.

Modern enterprise systems do not operate in pure synchronous HTTP request/response patterns. Real workloads depend on:

• Message brokers and queues
• Durable event logs and streaming systems
• Microservice choreography and orchestration
• Cross-domain integrations between enterprises
• Autonomous internal agents that continue processes

Bearer token–based models (OAuth, OIDC, SAML, SPIFFE/SVID, mTLS sessions) answer the question:

“Who were you at the moment this token was minted?”

Distributed systems instead require:

“How did you arrive here, and who delegated capability to you along the way?”

When asynchronous boundaries are involved:

• The consumer is not the same component that validated the original token
• Tokens lose their holder binding
• Service accounts silently replace human subjects
• New principals appear without explicit provenance
• The original user’s intent is lost

This is not an edge case; it is the dominant reality of enterprise integration.

A message-centric capability model addresses this by:

• Making capability the atomic security primitive, rather than identity or token possession
• Using the distributed transaction as the guardrail that defines capability scope
• Ensuring that capability tokens are valid only inside their transaction, and inert outside it
• Preserving identity continuity via verifiable provenance, not by forwarding credentials

AI Agents participate in this model as DID-anchored principals. They are not merely token holders; they are autonomous actors that can receive, use, and forward delegated capability inside a distributed transaction—subject to governance and constraints.

This use case does not attempt to solve higher-level AI trust problems (alignment, safety, prompt integrity, reputational trust). It defines the base security layer required to make any higher trust layer meaningful in distributed, message-driven environments.

Related Use Cases

<--! Leave empty if none; otherwise, a bullet list is best, whether annotated or not. -->

Terminology

Distributed Transaction
A multi-hop execution context spanning agents, services, and transports that must preserve continuity.

Capability
Permission to perform a contextual action inside a transaction; it does not directly encode personal identity.

Capability Token
A delegated authorization artifact that is valid only within the distributed transaction that created it; outside that scope it is inert.

Trust Plane
A trust continuity anchor, represented by a DID, that signs and validates hop contributions to the trust chain. It is not an IdP, workload, or user—its role is to maintain continuity, not to impersonate actors.

Trust Envelope (TDE)
A DIDComm-based message profile that carries:

• Self DID (the actor performing the action at this hop)
• Peer DID (the upstream actor at the previous hop)
• Capability reference (the delegated capability being exercised)
• Trust Plane DID (the continuity anchor)
• Previous hop hash (linking this hop to the existing chain)

Async-DTE
A minimal, hash-linked continuity record suitable for message brokers and async transports. It contains no bearer tokens or embedded credentials, only identity continuity and capability references.

Subject Substitution
The silent replacement of the original subject (e.g., a user) with a new principal (e.g., a service account) at an asynchronous boundary, breaking identity continuity.

Actors

• Alice — Human Subject initiating the business action
• RedBank API — Internal workload acting as Verifier and capability holder at the first hop
• Trust Plane 1 — RedBank’s trust continuity anchor, represented by a DID
• Kafka Broker — Asynchronous, non-verifying message transport
• AI Agent — Delegated autonomous agent, DID-anchored, acting inside the transaction
• GreenPay API — External partner workload acting as Verifier and capability consumer
• Trust Plane 2 — GreenPay’s trust continuity anchor

Other Stakeholders

• Compliance and regulatory teams
• Corporate risk and governance bodies
• Security operations centers (SOC) and forensics teams
• Financial and audit stakeholders
• Enterprise security and architecture leadership

Flows

0 - Preconditions

• Alice can authenticate to RedBank using any enterprise-approved mechanism (e.g., OAuth, SAML, SPIFFE, VC, mTLS).
• RedBank and GreenPay communicate using asynchronous transports (e.g., Kafka, Pulsar, SQS).
• AI Agents are assigned DIDs and associated trust ontologies or constraints.
• Trust Plane 1 and Trust Plane 2 each expose DIDs and appropriate assertion methods in their DID Documents.
• There is no assumption of a shared identity provider or shared PKI between RedBank and GreenPay.

1 - Trigger

Alice initiates a sensitive workflow at RedBank (for example, authorizing a cross-domain payment that requires multi-hop processing, asynchronous messaging, and execution by an internal AI Agent and an external partner service).

2A - Happy Path

1. Initial Authentication and Ingestion

• Alice authenticates to the RedBank API via OAuth, SPIFFE, or another mechanism.
• The RedBank API validates the credential locally.
• The token or credential is treated as input only and is not forwarded downstream.

2. Trust Envelope Creation at the Boundary

• The RedBank Trust Plane (Trust Plane 1) creates a Trust Envelope (TDE) that includes:
  • self DID (RedBank API)
  • peer DID (Alice)
  • A capability reference describing what actions are allowed in this transaction
  • The Trust Plane DID
  • prev_hash = null (this is the root of the chain)

3. Asynchronous Propagation with Async-DTE

• Instead of sending tokens, the API publishes an Async-DTE to Kafka.
• The Async-DTE carries only:
  • The continuity material (hash-linked reference)
  • The capability context
  • References to the involved DIDs.
• No bearer tokens, no VCs, and no sensitive credentials are placed on the message.

4. AI Agent Consumption and Capability Use

• The AI Agent consumes the Kafka message.
• The Agent uses Trust Plane 1 to validate the TDE and confirm:
  • That the capability was delegated in this transaction.
  • That it is a legitimate delegate for this capability.
• The Agent then acts as a continuation of the same distributed transaction, not as a new subject.

5. Cross-Domain Call to GreenPay

• The AI Agent now calls GreenPay's API.
• Before the call, it asks Trust Plane 1 to create a new TDE for this outbound hop, where:
  • self DID = AI Agent's DID
  • peer DID = RedBank API (previous hop)
  • capability is narrowed or preserved as needed
  • prev_hash links to the previous TDE
• GreenPay receives the TDE and verifies it via Trust Plane 2.
• Trust Plane 2 validates the full chain of causality and capability delegation from $Alice \to RedBank \to AI Agent \to GreenPay$.
• The operation proceeds under a single distributed transaction, without minting new tokens on behalf of Alice and without subject substitution.

---

2B - Alternative Paths

2B.1 - Governance-Based Denial

• The AI Agent has a DID-attached ontology or policy stating that it is not allowed to perform financial operations.
• Even if the Agent can present a valid capability, the Trust Plane enforces this constraint and denies the action.
• The transaction is terminated, and an appropriate error or compensating action is produced.

2B.2 - Multi-Hop Asynchronous Flow

• The Async-DTE may pass through multiple brokers, topics, or queues (e.g., internal routing layers).
• Messages may be retired, parked in dead-letter queues, or replayed for recovery.
• Identity continuity is not based on bearer token presence, but on hash-linked provenance and signed TDEs.
• Attackers replaying old messages without valid chain context and Trust Plane validation cannot gain additional capabilities.

2B.3 - Delegation Termination

• At any hop, the Trust Plane or a policy engine may decide to terminate the chain:
  • risk escalation
  • revocation
  • anomaly detection
  • regulatory requirement
• Once the distributed transaction is terminated, any capability token derived from it becomes inert and cannot be reactivated by downstream actors.

---

3A - Challenges and Key Risks

Token Replay

• Classic bearer tokens, if placed on message payloads, can be replayed by any consumer with access to the message.
• This turns transport or storage surfaces into credential leakage and impersonation channels.

Subject Substitution

• At asynchronous boundaries, systems often mint new service identities or use generic service accounts.
• This silently introduces new principals and breaks continuity with the original subject (Alice).

AI Autonomy vs. AI Safety

• An AI Agent may be technically capable of performing actions, but not trusted for certain risk classes (e.g., financial operations).
• Capability alone is not sufficient; it must be interpreted under governance and constraints.

Cross-Domain Validation

• Traditional federation relies mostly on shared IDPs (Identity Providers) or PKI (Public Key Infrastructure).
• This use case must support cross-domain verification based on DIDs and Trust Planes without assuming shared identity providers.

---

3B - Success Criteria

• Identity continuity is preserved across synchronous and asynchronous hops.
• Capability is verified cryptographically rather than inferred from token possession.
• No bearer tokens are forwarded or re-minted on behalf of the subject at downstream hops.
• AI Agents are treated as first-class principals with DIDs and verifiable provenance.
• Chain-of-custody for the transaction can be audited end-to-end across organizations.
• Delegation and capability can be revoked at any hop.
• Credentials are never leaked into messaging systems as reusable secrets.

3C - Acceptable Outcomes

• The transaction is safely terminated when ontology, risk policy, or governance requirements are not satisfied.
• Local-only fallback behaviors (e.g., internal logging, compensating actions) are allowed when cross-domain trust cannot be established.
• Logs capture, at minimum:
  • hash chain identifiers
  • capability references and scope
  • DIDs and hop relationships
  • Trust Plane signatures and validation outcomes
• Original credentials (e.g., OAuth tokens, VCs) never appear in logs, messages, or DLQs (Dead Letter Queues).

---

References

Prior Art

• OAuth, OIDC, SAML — identity snapshot models
• SPIFFE/SPIRE — workload identity in a trust domain
• mTLS — transport-layer mutual authentication
• Verifiable Credentials / DIDs — decentralized subject attestations
• DIDComm v2 — authenticated, end-to-end encrypted messaging

Annotated Bibliography

• Research and practice on distributed transactions
• Event-driven architectures and choreography vs. orchestration
• Zero Trust architectures and continuous verification models

[andorsk]

I agree on the requirement, but I think we can improve the framing. The use case leads with a lot of assumptions about technology, which the work item should evaluate, not the use case.

We can anchor this use case into something more concrete and real, and we should take out the proposed flow and leave it for the work item to evaluate.

[TomCJones]

the following assertion seems to imply that we have a relationship/session ID to bind the messages? Right?

"Instead of stretching HTTP-centric identity protocols across brokers and streams, this use case embraces the reality of distributed systems:
A capability token is valid only within the distributed transaction in which it was delegated."

[bumblefudge]

I love this, but it feels like the rough sketch of a work-item proposal and the blog post recruiting participants to the work item got mixed into the usecase definition again by an agent with too many tokens and too much context 😉. Let's see if we can edit those out (and set them aside for later, because we'll need a blog post and a proposal if people sign up for the shortened version!)

the following assertion seems to imply that we have a relationship/session ID to bind the messages? Right?

This is the kernel of the proposal, by my reading-- in the terminology section, I see this mentioned as a required field in the proposed DIDComm envelope:
Trust Plane DID (the continuity anchor)
and also this term is defined:
Async-DTE: A minimal, hash-linked continuity record suitable for message brokers and async transports. It contains no bearer tokens or embedded credentials, only identity continuity and capability references.

I also really like this section:

The model becomes a superset security paradigm. It ingests any input (OAuth tokens, SPIFFE workload identities, mTLS client certificates, Verifiable Credentials / Presentations, SD-JWTs, enterprise attestations) and converts them into verifiable delegated capability preserved through:

• DIDComm Trust Envelopes (TDE)
• Message-based provenance
• Hash-linked continuity across hops

I like the Driving User Story and I think we should lead with that (should we add a maximum length/character-count to some of the sections in the template?).

What if we called this use-case "minimal distributed transaction infrastructure" or something like that?

We should hone in on the problem more and argue for the minimum requirements instead of jumping to solution shapes. I think it makes sense to use DIDComm as the messaging format because it's so extensible and plays nicely with almost any DID and VC stuff to date, but I can imagine many different ways of skinning the other cats. For example, should the trust-plane identifiers (which Tom rightly called the "identifier" of the distributed transaction) looks an awful lot like a DID, and that async-DTE could well be a DID Document, but is that necessarily the right or only way to model those two terms? Does it need to be one DID method, or something more generally? Could did:dht work for this? Could you just use IPFS or DASL (a simplified version of IPFS's content-addressing scheme) or RFC 6920 to refer to each async-DTE by its hash? Those are work-item questions 😎

As for what's missing, I think maybe we should contrive a single-sentence context for why Redbank and Greenpay don't want to run the whole transaction "under one roof" so it's more obvious why this justifies new ways of doing things...