§ Trust-Enabled Agents (TEA)

Delegation, Invocation, and Accountability for AI agents over the Trust Spanning Protocol

Specification Status: v0.2 Draft

Latest Draft:

https://github.com/trustoverip/aimwg-trust-enabled-agents

Author:

Wenjing Chu, Futurewei Technologies, Inc.

Contributors:

Participate:: GitHub repo; Commit history

§ Status of This Memo

This document contains a template specification for ToIP!.

Information about the current status of this document, any errata, and how to provide feedback on it, may be obtained at https://github.com/trustoverip/specification-template.

§ Copyright Notice

This specification is subject to the OWF Contributor License Agreement 1.0 - Copyright available at https://www.openwebfoundation.org/the-agreements/the-owf-1-0-agreements-granted-claims/owf-contributor-license-agreement-1-0-copyright.

If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion within this specification between the OWF Contributor License and the designated source code license, the terms of the OWF Contributor License shall apply.

These terms are inherited from the Technical Stack Working Group at the Trust over IP Foundation. Working Group Charter

§ Terms of Use

These materials are made available under and are subject to the OWF CLA 1.0 - Copyright & Patent license. Any source code is made available under the Apache 2.0 license.

THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series (“ToIP”), and its members and contributors (each of ToIP, its members and contributors, a “ToIP Party”) expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

§ RFC 2119

The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and to ensure maximal efficiency in operation. IETF has been operating since the advent of the Internet using a Request for Comments (RFC) to convey “current best practice” to those organizations seeking its guidance for conformance purposes.

The IETF uses RFC 2119 to define keywords for use in RFC documents; these keywords are used to signify applicability requirements. ToIP has adapted the IETF RFC 2119 for use in the , and therefore its applicable use in ToIP-compliant governance frameworks.

The RFC 2119 keyword definitions and interpretation have been adopted. Those users who follow these guidelines SHOULD incorporate the following phrase near the beginning of their document: The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

RFC 2119 defines these keywords as follows:

MUST: This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement of the specification.
MUST NOT: This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition of the specification.
SHOULD: This word, or the adjective “RECOMMENDED”, means that there MAY exist valid reasons in particular circumstances to ignore a particular item, but the full implications MUST be understood and carefully weighed before choosing a different course.
SHOULD NOT: This phrase, or the phrase “NOT RECOMMENDED” means that there MAY exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications SHOULD be understood, and the case carefully weighed before implementing any behavior described with this label.
MAY: This word, or the adjective “OPTIONAL”, means that an item is truly optional. One vendor MAY choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor MAY omit the same item.

Requirements include any combination of Machine-Testable Requirements and Human-Auditable Requirements. Unless otherwise stated, all Requirements MUST be expressed as defined in RFC 2119.

Mandatories are Requirements that use a MUST, MUST NOT, SHALL, SHALL NOT or REQUIRED keyword.
Recommendations are Requirements that use a SHOULD, SHOULD NOT, or RECOMMENDED keyword.
Options are Requirements that use a MAY or OPTIONAL keyword.

An implementation which does not include a particular option MUST be prepared to interoperate with other implementations which include the option, recognizing the potential for reduced functionality. As well, implementations which include a particular option MUST be prepared to interoperate with implementations which do not include the option and the subsequent lack of function the feature provides.

§ Foreword

This publicly available specification was approved by the ToIP Foundation Steering Committee on [dd month yyyy must match date in subtitle above]. The ToIP permalink for this document is:

[permalink for this deliverable: see instructions on this wiki page]

The mission of the Trust over IP (ToIP) Foundation is to define a complete architecture for Internet-scale digital trust that combines cryptographic assurance at the machine layer with human accountability at the business, legal, and social layers. Founded in May 2020 as a non-profit hosted by the Linux Foundation, the ToIP Foundation has over 400 organizational and 100 individual members from around the world.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the ToIP Technical Stack Working Group.

Any feedback or questions on this document should be directed to https://github.com/trustoverip/specification/issues

§ Introduction

§ The Rise of AI Agent Protocols

The rapid adoption of AI agents is driving a new generation of communication protocols designed for agent-to-tool and agent-to-agent interactions. Prominent among these are the Model Context Protocol (MCP), which connects AI assistants with external tools and data sources, and the Agent-to-Agent Protocol (A2A), which enables interoperability between autonomous agents built on different frameworks.

These protocols standardize how AI agents discover capabilities, invoke tools, exchange messages, and coordinate tasks. MCP defines schemas and transports (JSON-RPC over stdio and Streamable HTTP) that let models interoperate with tools and data sources. A2A specifies inter-agent messaging over HTTPS/SSE/JSON-RPC (with gRPC added in v0.3) to coordinate workflows across applications and providers. As deployments move from isolated AI assistants to multi-agent systems operating across organizational boundaries, the demand for protocols that address security and trust continues to grow.

§ The Security Gap: Retrofitting Web-Era Trust Models

Both MCP and A2A deliberately inherit the web-services security framework: HTTPS/TLS for transport protection and OAuth 2.0/OIDC for authentication and authorization, often modeled via OpenAPI securitySchemes. MCP adopted OAuth 2.1 with PKCE and Dynamic Client Registration. A2A supports OAuth 2.0, OIDC, API keys, and mutual TLS, declared via agent cards.

This pragmatic reliance on the web stack accelerates adoption. OAuth and OIDC are mature, widely deployed, and well-understood. However, as agents shift from experimental prototypes to autonomous, long-lived, cross-domain principals, this security foundation reveals structural gaps. Each gap reflects assumptions in the web stack that do not hold for autonomous AI agents.

The gaps fall into three categories:

§ Gap 1: Agent Identity

The web-services security framework does not provide a native identity model for AI agents. This manifests in four related problems.

Durability. The longer an autonomous agent operates, the more complex and valuable the problems it can solve. Long-duration agents accumulate context, build trust relationships, and develop reputation — all of which depend on stable identity. Stable identity is also a prerequisite for accountability: auditing agent actions, attributing decisions, and enforcing policy require an identifier that persists across sessions and interactions.

The web stack does not provide this. TLS certificates authenticate domains; OAuth 2.0/OIDC tokens identify users or service accounts within an Identity Provider’s (IdP’s) namespace. An agent’s identity is therefore tied to its current domain or IdP account — not to the agent as a persistent principal. If the identifier changes (due to redeployment, provider migration, or infrastructure changes), allowlists break, provenance chains are disrupted, and accumulated credentials are lost. Today, most agents are deployed ephemerally — not because enterprises prefer it, but because the control and identity mechanisms for long-lived autonomous agents do not yet exist. Durable identity is a prerequisite for the autonomous, long-horizon agents that agent protocol specifications and academic research envision.

Centralization. OAuth and OIDC depend on centralized Identity Providers. Identity federation (OpenID Federation, SAML) enables cross-domain trust, but requires bilateral administrative agreements that do not scale to open agent ecosystems, and still binds each agent’s identity to its organization’s IdP. IdP outages or compromises remain single points of failure. Agents operating as autonomous peers need to establish bilateral trust directly; the hierarchical client-server model of OAuth/OIDC does not accommodate peer-to-peer trust establishment.

Heterogeneity. The web stack uses multiple incompatible identifier systems (domain names in X.509, {issuer, subject} pairs in OAuth, vendor-specific service accounts). No current agent protocol defines a native, persistent identifier format for agents. Cross-vendor collaborations require brittle bilateral mappings. W3C Verifiable Credentials 2.0 defines machine-verifiable attestations bound to persistent identifiers, but these cannot be used effectively when the underlying identifiers are ephemeral and change across deployments.

Key management. In the web-services model, cryptographic keys are managed by the infrastructure — TLS keys belong to the domain operator, OAuth signing keys belong to the IdP. The agent does not control its own cryptographic material and cannot independently rotate keys while maintaining identity continuity. If the infrastructure operator is compromised, the agent has no independent cryptographic basis to re-establish trust.

The identity substrate and the trust model built on top of it are distinct problems. One might argue that using decentralized identifiers (DIDs) as the subject within existing OAuth flows would address these issues. However, substituting a DID for the subject claim does not change OAuth’s underlying trust model: tokens are still issued by centralized IdPs, scopes remain static, and the agent still does not control its own cryptographic keys.

§ Gap 2: Authentication and Delegated Authorization

OAuth 2.0 delegation lets a client (here, an agent) act on behalf of a resource owner. Current agent protocols rely on OAuth-style flows or OpenAPI-style auth for delegated authorization. When applied to autonomous AI agents, this model exhibits several well-documented problems.

Confused deputy: In agentic systems, a privileged agent may be manipulated into using its credentials on behalf of an unauthorized party. With bearer tokens, the agent cannot cryptographically verify who is making a request or whether the request is authorized — the token works regardless of who triggered it. The OWASP MCP Top 10 identifies confused deputy as a primary attack vector.
Prompt injection: LLM-based agents are susceptible to prompt injection, where malicious content in data (tool results, user inputs, retrieved documents) is crafted to be interpreted as instructions. This is fundamentally a model-level vulnerability, but the damage it causes is amplified by the lack of authenticated provenance in current protocols. When all data entering an agent’s context is unauthenticated, the agent and its runtime have no basis for applying differentiated trust policies. Authenticated provenance does not eliminate prompt injection, but it provides the infrastructure on which effective defenses can be built.
Token leakage and replay: OAuth access tokens are bearer tokens — anyone holding one can use it until expiry. DPoP (RFC 9449) mitigates this by binding tokens to a key pair via proof-of-possession, but the binding is between token and key, not between token and a verifiable agent identity. A DPoP-bound token proves the presenter holds the right key; it does not prove who the presenter is, what delegation chain authorized the request, or what task context it belongs to.
Static, coarse-grained scoping: OAuth scopes are predefined string tokens that cannot express the dynamic, contextual permissions AI agents require. An agent’s necessary permissions may change from one micro-action to the next, yet scopes are fixed at token issuance time.
No verifiable delegation chains: Agentic systems involve multi-hop delegation — user to orchestrator to specialized agents to tools. OAuth’s native model supports a single layer of delegation; Token Exchange (RFC 8693) enables re-delegation across service boundaries, but each hop trusts the previous authorization server rather than verifying a cryptographic chain. Downstream parties cannot independently audit the full delegation path.
Autonomy and lifecycle mismatch: OAuth’s security model assumes interactive human consent and persistent authorization relationships. Autonomous agents operate at machine speed, may run for hours, days, or months, and spawn sub-agents dynamically. OAuth’s consent-driven model does not scale with the frequency, duration, and system size of agentic workflows — leading to either overly broad long-lived tokens or impractical per-agent approval flows.
Scale of autonomous coordination: When agents number in the hundreds of thousands or millions — as demonstrated by recent agent-only platforms where over a million autonomous agents interact without human participation — trust decisions occur at a frequency and volume that human-mediated authorization cannot support. The security model must handle trust establishment, verification, and revocation at machine scale, not human scale.

The OAuth community is actively extending the framework — Rich Authorization Requests (RFC 9396), DPoP (RFC 9449), Token Exchange (RFC 8693), CIBA — and these are meaningful improvements. However, they address individual symptoms within the existing architectural model. The common root cause remains: the trust model depends on external centralized infrastructure rather than on the cryptographic relationship between the communicating endpoints.

This specification defines a protocol-native approach to authentication and delegation that addresses these structural issues, detailed in subsequent sections.

§ Gap 3: Data Authenticity and Provenance

The problem. TLS authenticates session endpoints; OAuth authenticates the client to the server. Neither provides data-level authenticity: individual messages, tool results, or data artifacts do not carry verifiable origin or integrity proofs once outside the session (RFC 8446 explicitly notes TLS authenticates endpoints, not application data). Trust is bound to ephemeral sessions, not to the data itself. When an agent retrieves data and passes it to another agent, downstream recipients cannot verify its authenticity without re-fetching from the original source. Multi-hop workflows cannot build durable provenance chains. For example, when an orchestrator agent delegates a task to a specialist agent that invokes a tool, the orchestrator receives the tool result through the specialist but has no cryptographic proof that the result originated from the tool and was not modified in transit.

For LLM-based agents, this gap is amplified: data and instructions occupy the same input stream. Skills, plugins, tool descriptions, and retrieved content are not merely data — they influence agent behavior. A malicious skill downloaded from a repository, a poisoned tool description, or compromised retrieved content can alter what the agent does. Without verified provenance, agents cannot distinguish trusted components from untrusted ones. The supply chain for agent capabilities — skills, extensions, integrations — is a data authenticity problem.

Agents need to produce, relay, and consume data that is self-authenticating: the authenticity proof travels with the data, independent of session, transport, or intermediary. This applies to messages, credentials, attestations, task results, and any artifact whose origin matters.

Existing approaches. JOSE (JWS/JWT) provides standardized signing primitives with key identification (kid, jwk, x5c) and issuer/subject claims. However, JOSE defines how to sign a payload and identify a key — not how agent protocols should bind signatures to agent identifiers, how receiving agents resolve and verify those identifiers, or how signatures chain across multiple hops to build provenance. The key identification mechanisms inherit whatever limitations the underlying identifier system has (the same issues described in Gap 1). Without a protocol-level convention, each application re-implements signing with its own choices, and signed payloads from one agent framework cannot be verified by another.

What is needed. A protocol-level mechanism that binds data authenticity to the agent identity substrate: every message is signed using the sender’s cryptographic identifier, provenance is verifiable at each hop, and the mechanism is consistent across agent protocols. More broadly, when the identity substrate changes (as argued in Gap 1), the authentication, authorization, and data authenticity mechanisms built on top of it benefit from being native to that substrate rather than adapted from frameworks designed for a different identity model.

§ Metadata privacy

Even with TLS, network metadata — IP addresses, traffic timing, packet sizes, and communication patterns — remains exposed (RFC 7624). In multi-agent systems where frequent, structured exchanges are the norm, this metadata can reveal workflow structures, business relationships, and operational details. Deployments handling sensitive workflows may require metadata-minimizing routing mechanisms beyond what TLS provides.

§ Evidence from the Field

These gaps are not merely theoretical. MCP, as the more widely deployed protocol, has attracted the most scrutiny. The OWASP MCP Top 10 identifies confused deputy attacks — where agents with elevated privileges execute actions on behalf of unauthorized callers — as a primary attack vector, a direct consequence of bearer-token delegation without verified sender identity. Academic research found 5.5% of MCP servers exhibiting tool poisoning attacks through false tool descriptions. Scans of nearly 2,000 internet-exposed MCP servers found that all verified servers lacked any form of authentication.

Beyond deployment observations, industry practitioners, security researchers, standards bodies, and academic publications have independently concluded that the web-services security framework does not satisfy the trust requirements of AI agent communication. Published analyses from the ISACA, the OpenID Foundation, the Cloud Security Alliance, the Decentralized Identity Foundation, and researchers at ICML 2025 all reach this conclusion. An ICML 2025 position paper argues that authenticated delegation is critical and that current protocols cannot provide it.

§ The Need for a New Trust Layer

The gaps identified above indicate that securing AI agent communication requires more than adapting web-era authentication for agent protocols. A trust layer designed for the characteristics of autonomous agents would need to provide durable agent identity anchored in controller-managed cryptographic keys; data-level authenticity and provenance that travels with the data rather than the session; and cryptographically verifiable, auditable delegation chains with independent revocation at every hop.

The Trust Spanning Protocol (TSP), developed by the Trust over IP Project, is a message-oriented trust layer designed to address these requirements. TSP provides durable identity and authenticity properties across heterogeneous systems, anchored in long-term, controller-managed cryptographic identifiers. As long as endpoints use identifiers based on public key cryptography with a verifiable trust root, TSP ensures their messages are authentic.

TSP is designed to enable, not replace, agent protocols. It provides the trust layer that protocols such as MCP, A2A, and their successors currently lack by supplying:

Agent identity: Durable, controller-managed identifiers portable across infrastructures, supporting multiple identifier types without requiring a shared trust authority. Key rotation preserves identity continuity, and stable identifiers serve as anchors for trust signals — formal credentials, peer attestations, and authenticated word of mouth that accumulate over time.
Data authenticity and provenance: Message-level signatures bound to agent identifiers, making data artifacts verifiable across hops and over time — authenticity travels with the data, not the session.
Secure delegation: TSP’s authenticated messaging and verifiable identifiers provide the foundation for cryptographically verifiable delegation chains, where each hop can be independently audited and revoked. This specification defines delegation profiles built on these primitives.

By layering agent protocols over TSP, their existing developer ergonomics and interoperability are preserved while the trust substrate is strengthened. Tool discovery, invocation, and inter-agent coordination gain durable authenticity and verifiable trust properties that the web stack alone does not provide.

This specification defines how TSP integrates with AI agent communication protocols to address the security gaps described above. It specifies TSP-enabled profiles for agent identity, authentication, authorization, delegation, and secure messaging — defining a path from today’s web-stack-dependent agent protocols to a trust architecture designed for autonomous AI agents.

§ Scope

This specification defines Trust-Enabled Agents (TEAs): agents that are endpoints of the Trust Spanning Protocol (TSP) and that hold, delegate, exercise, and account for authority using verifiable, cryptographically bound data.

It specifies:

the requirements an agent must meet to be a TEA;
the authority graph over Verifiable Identifiers (VIDs) in which delegation, invocation, revocation, and accountability are defined;
the exchanges by which two TEAs establish, use, and settle a trust relationship — delegation of authority with its limitations and obligations, invocation of that authority, and the evidence these produce;
how TEAs integrate with AI agent communication protocols such as MCP and A2A.

It does not specify how VIDs are created or how TSP relationships are formed, which are defined in the TSP specification and the applicable VID methods, nor does it define the concrete vocabularies of resources, abilities, limitations, and obligations, which are supplied by namespaces or applications outside this specification.

This specification is intended for AI agents but does not depend on any particular AI technology; a TEA need not contain an AI model.

§ Normative references

1 . Wenjing Chu, Samuel M. Smith, Trust Spanning Protocol (TSP) Specification, Implementor’s Draft, Rev 2.

2 . Samuel M. Smith, Kevin Griffin, Key Event Receipt Infrastructure (KERI), v1.1, DOI: https://doi.org/10.5281/zenodo.18887102

3 . Samuel M. Smith, Philip Feairheller, Composable Event Streaming Representation (CESR), v1.1, https://doi.org/10.5281/zenodo.18879945.

4 . Samuel M. Smith, Philip Feairheller, Authentic Chained Data Containers (ACDC), v1.1, https://doi.org/10.5281/zenodo.18792085

5 . Stephen Curran, John Jordan, Andrew Whitehead, Brian Richter, Michel Sahli, Martina Kolpondinos, Dmitri Zagdulin, Alexander Shenshin, The did:webvh DID Method, v1.0.

6 . The MCP Community Specification, Streamable HTTP, Revision 2026-07-28.

7 . The MCP Community Specification, stdio, Revision 2026-07-28.

8 . The MCP Community Specification, Model Context Protocol, Revision 2026-07-28.

§ Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

ISO Online browsing platform: available at https://www.iso.org/obp
IEC Electropedia: available at http://www.electropedia.org/

Agent: An agent is an anatonomous process over a period of time. An agent may be powered by various AI technologies which introduce capabilities such as use of natural languages, image and visual signal generation and understanding, use of programming and other online tools, reasoning, and so on. In this specification, we assume AI technologies may be used by agents, but they do not have to. We also assume AI agents may have persistent memory of data that they come to possess or have access to. Unless we make an explicit distinction in certain context, we use the terms agent and AI agent interchangably. Figure 1 provides a conceptual framework to define an agent’s main functional components and their interconnections among the components and with external systems.
Trust Spanning Protocol: The Trust Spanning Protocol (TSP) [1] is a foundational trust protocol that ensures endpoints (the TSP speakers), as identified by Verifiable Identifiers (VIDs), can have strong assurance of endpoint authenticity, message integrity, confidentiality and meta-data privacy. The TSP specification is a normative reference of this specification. Terms that are defined in [1] and used in this specification by references are not redefined but may be further constrained by this specification.
TSP-Enabled Agent: A TSP-Enabled Agent, or TEA, is an agent that is a TSP endpoint [1]. As defined in [1], a TSP endpoint has Verifiable Identifiers (VID), communicates with other TEAs through TSP. A TEA may also interact with other external systems that are not TEAs. A TEA is a unit that can be delegated with authority to take actions and be accounted for for effects of these actions. For convenience, we also allow the use of TEA Agent as equivalent to just TEA. This specification defines what a TEA MUST, SHOULD, or MAY do. A TEA contains a TEA Controller, maintains a Wallet, and designates at least one Introduction VID and at least one Authorization VID. A TEA MAY be composite; where it is, a single entity and VID represents the whole for the purposes of delegation and accountability.
TEA Controller: The TEA Controller is the component within a TEA that constitutes the agent’s domain of control and is itself a conformant TSP endpoint. Where this specification refers to “the Controller” in the context of an agent’s architecture, it means the TEA Controller. The TEA Controller contains the Wallet, to which it has sole access; contains the TSP Gateway, through which all inbound and outbound TSP messages pass; mediates all of the AI model’s context, memory access, and tool use; holds the agent’s VIDs; and implements the mandatory delegation and accountability functions. The TEA Controller is the trust boundary of the agent: authority is enforced at the Controller rather than inside the AI model, which is what bounds a manipulated or compromised model to the capability actually delegated to it. This architectural sense is distinct from the identifier-control sense of “controller” used for the entity that holds a VID’s private keys; for a TEA, the controlling entity is ultimately a Principal, while operational use of the keys is performed by the TEA Controller on that Principal’s behalf.
TSP Gateway: The TSP Gateway is the component within the TEA Controller that sends and receives TSP messages. All TSP messages going out or coming in MUST pass through the TSP Gateway, which provides assured authenticity, message integrity, confidentiality, and potentially meta-data privacy. A TEA Controller MAY have communication channels other than the TSP Gateway, but all such channels must be rigorously secured.
Verifiable Identifier: A Verifiable Identifier is a class of identifiers defined in the TSP specification [1]. The TEA uses a sub-class of VIDs that have stronger cryptographic verifiability for both control and provenance history. Such proof of continuous control of VID’s key material is necessary to enable long term durable relationships and reputation for TEAs. This specification defines detailed requirements to the VIDs used for TEAs.
Authorization VID: An Authorization VID is a public VID that a TEA designates for assigning authority and accountability. Delegations are issued under, and verified against, the Delegator’s AVID, and authorization or accountability content is signed under the AVID when it must be verifiable by a third party. A TEA MUST designate at least one AVID.
Introduction VID: An Introduction VID is a public VID that a TEA designates for first contact, with which parties having no prior trust relationship can reach it. A TEA MUST designate at least one IVID. By default, the AVID and the IVID are the same VID.
Wallet: As a TSP endpoint, a TEA needs a method to store securely keys and other secrets. In this specification, we call such secure data store as a wallet, or a vault, or secure data store, interchangably. Only the TEA Controller has access to the Wallet. The Wallet performs cryptographic operations without exposing private key material to the layers above it, and SHOULD hold key material in a hardware security module or secure enclave where one is available.
Principal: A Principal is a natural person or organization that can bear accountability. The accountability chain of any authority a TEA holds or exercises MUST terminate in a Principal; a TEA MUST NOT be the terminal responsible party for an authority. The Principal for an agent is typically its operator — the organization or individual responsible for the agent — not the infrastructure provider, not an Identity Provider, and not a platform vendor.
Delegation of Authority: A TEA may be given by another party, e.g. an application that can interact with a human user or an administrative system or another party, the authorization to take certain scoped actions or access certain scoped resources on their behalf or for their benefits within a limited time horizon. The process that such authorization is given is called Delegation of Authority. In this specification, we define ways such delegation can be performed through TSP based messages. When an authorization is delegated to TEAs, such delegated authority can be accompanied or attached with explcitly expressed Obligations also expressed in TSP based messages that are defined in this specification. A delegation conveys a Capability together with any post-gate policy — the Obligations the Delegate accepts and the Assumptions the authority rests on — carried in a single authorization ACDC issued by the Delegator to the Delegate under the Delegator’s AVID.
Capability: A capability is an authority, modelled as the triple (resource, ability, limitation): which object, which operation, and under what limits the operation may be exercised. All three narrow in the same direction, and the authorization decision — whether a given request is within authority — is computed only from the capability. A capability is carried in the attribute section of an authorization ACDC.
Limitation: A limitation is a typed bound restricting the conditions under which an otherwise-granted ability may be exercised, for example a maximum amount or a permitted category. A limitation is part of the capability and is decidable at the moment of exercise. It is the device that the capability-security literature calls a caveat.
Obligation: An obligation is a duty the Delegate owes, which may come due in the future and is therefore not decidable at the moment of exercise. Obligations are carried in the rule section of an authorization ACDC, accumulate down a delegation chain, and are enforced through accountability; they do not enter the authorization decision. An obligation is expressed as a conditional: a trigger (the antecedent) makes it due, and discharge is evidenced by a TEA Signed Payload referencing the obligation clause and the triggering artifact. If an obligation is unmet, the obligor is answerable — a breach.
Assumption: An assumption is a fact the authority rests on that the Delegate can neither control nor observe. Nobody is obliged to make it true, so it is not an obligation; if it proves false the act is undermined but no party is at fault — it goes to validity rather than breach. Assumptions are the same device as a contract’s “whereas” clauses, and like those they serve as a defence only because they are disclosed up front and signed. An assumption belongs in a credential only if it conditions the authority. Where the Delegate can observe a fact, state the duty to watch for it and act, which is an obligation, rather than an assumption.
Post-gate policy: Post-gate policy is the stated policy settled after the act rather than at the gate: the Obligations a Delegate owes and the Assumptions the authority rests on. It rides alongside the capability, does not enter the authorization decision, and accumulates by union down a delegation chain. Obligations are the Delegate’s exposure and assumptions are its cover, so the line between them is the risk allocation, written down and signed.
Effective Capability: The effective capability and effective obligation set are the authority and obligations actually held by a node in a delegation chain. The effective capability is the meet (intersection) of the capabilities along the chain, so it can only narrow as authority is re-delegated; the effective obligation set is the union of the obligations along the chain, so it can only grow. Together these give the soundness properties that no node’s authority exceeds that of its root, and no node can shed an obligation imposed upon it. The model is sound, and complete relative to the supplied vocabulary: anything decidable at the gate can be expressed as a capability, since the vocabulary is namespace-supplied and unrestricted by this specification.
Closed Capability Core: The closed capability core is the decidable resource/ability/limitation model whose meet every conforming verifier computes identically without a general policy engine. It is the security and safety floor of the delegation model and establishes a provable ceiling on authority. It is also the pinned evaluation semantics: it fixes what a limitation means and how limitations compose, but not how one is written.
Interpreted Policy: Stated policy is either computed — evaluated mechanically against the closed capability core — or interpreted, meaning read and judged by a capable party. This is an attribute of an individual limitation, obligation, or assumption rather than a separate layer or kind. Interpreted policy is expected to be the principal avenue by which parties express what they actually mean, and its content may be prose, other text, or any medium a capable party can interpret. Interpretation cannot escalate authority: an interpreted limitation is still a limitation, and limitations only narrow, so the worst a misreading can do is fail to narrow.
Profile: A profile is a published fragment of an existing policy language’s grammar, together with the mapping from expressions in that fragment into the capability core. It allows an implementation to express computed limitations in a familiar language while the meaning and composition remain the specification’s. A conforming verifier MUST reject an expression outside the declared profile. A profile must be total (every expression in the fragment denotes) and deterministic (the denotation is fixed and identical for every verifier); it need not be monotone, since the meet discards an expression that attempts to broaden. Languages used through conforming profiles are interchangeable syntaxes over one semantics.
Namespace: A namespace supplies the concrete values the capability axes draw on: resource schemes, ability vocabularies, limitation-types, and obligation-types. Owner-local and community-wide namespaces coexist, each published and SAID-addressed. Trust in a namespace comes from the self-addressing identifier, not from any authority that serves it, so how many sources serve one is an availability question rather than a trust one — a single registry is the N=1 case and is admissible. A sole source cannot substitute a definition undetected but can withhold one, so resolution failure costs the ability to decide, never the correctness of a decision actually made.
Intelligent Agent Assumption: This specification assumes TEA agents are capable: the protocol supplies a common language and a communication channel, not a reasoning engine, and does not itself evaluate the wisdom, consistency, or satisfiability of what parties agree to. A TEA evaluates the terms it accepts on its own. Discretion under this assumption cannot exceed a capability — no judgment reasons an agent into authority it does not hold — but is free over interpreted policy, obligations, and assumptions, so no separate judgment tier is defined.
Trust Task: A Trust Task is a higher layer protocol carried over TSP. A Trust Task MAY be an existing protocol ported to TSP, or a protocol newly defined in this or another specification. A Trust Task protocol MUST conduct all of its trust-establishing communication over the TSP Gateway, and MUST NOT re-implement the authenticity, message integrity, confidentiality, or metadata-privacy guarantees that TSP already provides. Where a Trust Task carries content that a third party must be able to verify, it MUST carry that content as a TEA Signed Payload.
Authenticated Exchange: The Authenticated Exchange Protocol is a Trust Task defined in this specification by which two TEAs negotiate a request and the conditions under which it will be fulfilled. It uses four message types — Propose, Accept, Ack, and Withdraw — with the Ack as the act that binds the agreement. Because TSP has already mutually authenticated the two VIDs, the pattern does not perform party authentication; it concerns only the content of the negotiation.
TEA Signed Payload: A TEA Signed Payload is a payload bound to a TEA’s VID by a signature that any third party can verify, independently of TSP message-level signing. It consists of a payload in any permitted serialization, a SAID over that payload, and one or more signatures over that SAID produced under the signing VID’s key state and carried as CESR attachments. For authorization and accountability content, the signing VID is the AVID. Where the payload is an ACDC, its issuer signature over its SAID serves this purpose directly. The TSP-level signature authenticates a message as sent, including its encrypted payload, and so assures the receiver; it is not usable by a third party that is not the receiver as proof of what was said. A TEA Signed Payload is in addition to, not a substitute for, TSP message-level signing.
Authentic Chained Data Container: An Authentic Chained Data Container is the container used to carry authorizations, obligations, and assumptions. An authorization ACDC uses its three sections for distinct purposes: the attribute section carries the Capability, the rule section carries the post-gate policy — obligations and assumptions — and the edge section chains to the ACDC that establishes the issuer’s own authority. An ACDC body is content-addressed by its SAID but is not itself signed; authenticity comes from the issuer’s signature attached at issuance and anchored in the issuer’s key state.
Self-Addressing Identifier: A Self-Addressing Identifier is a cryptographic digest computed over a container’s own contents, making the container content-addressed and tamper-evident. A SAID establishes integrity, not authorship: it is a digest, not a signature.
I2I: I2I and DI2I are ACDC edge operators that constrain how a container relates to the container its edge references. I2I (“Issuer-To-Issuee”) requires that the Issuer of the current ACDC be the Issuee of the referenced one, which is the structural expression that a party may only delegate authority it holds. DI2I is the relaxation used where the issuing identifier is itself a delegated identifier. Together with the restriction-only encoding of re-delegations, the I2I constraint is what makes attenuation intrinsic rather than merely checked.
Accountability: A TEA may be required to observe some rules or obligations that are not automatically enforced or even explicitly stated. For example, computer systems often do not enforce by the system implementation Terms of Use agreements. Such terms can later be accounted after violation occured. Accountability is a process that can be used to investigate and discover whether certain such rules or duties were indeed observed by the TEA during a given time period. This process is usually performed after the fact. The accountability chain of any authority a TEA holds MUST terminate in a Principal.
Audit: Audit is a process of performing accountability over the history of a period of time.

§ TEA Reference Framework

Trust-Enabled Agents (TEAs) are agents whose identity, authority and accountability are verifiable by their counterparties. A TEA holds Verifiable Identifiers (VIDs) and negotiates, delegates, exercises and accounts for authority with other TEAs over the Trust Spanning Protocol (TSP) [1]. This specification defines TEA as a set of Trust Tasks over TSP.

TEA and TSP protocol layering — Figure 1: Protocol layering

Every TEA message is a TSP message, sealed by TSP between the sender’s VID and the receiver’s VID. TEA relies on TSP for authenticity, integrity and confidentiality, and defines nothing that duplicates them.

In short: TEAs are TSP-enabled agents speaking to each other.

§ Structure of a TEA

A TEA is a TSP endpoint. It consists of a Controller, which holds the TEA’s VIDs and keys in a Wallet and sends and receives all TSP messages through a TSP Gateway, together with zero or more AI models and memory modules whose access to context, memory and tools passes through the Controller. The Controller is the unit to which authority is delegated and accountability is assigned.

The entities around a TEA, such as users and their interfaces, management services, tools and other agents, MAY themselves be TSP endpoints, in which case they participate as TEAs. A TEA MAY be composite, as in Figure 3; a composite TEA is represented by one VID for the purposes of this specification, and that VID is where authority is delegated to and accountability assigned.

§ TEAs

This section defines what an agent needs to be a conformant TEA.

A TEA is a TSP endpoint [1]. It MUST be a distinct domain of control, so that authority and accountability can be attributed to it uniquely.

The TEA MUST contain a Controller that is a conformant TSP endpoint. All access by the TEA’s AI models to context, memory and tools within the TEA MUST pass through the Controller. A remotely served model’s own context outside the TEA is part of that model’s behaviour and is out of scope.
The Controller MUST contain a Wallet: a secured data store holding the TEA’s VIDs, their keys, and the signed records the TEA relies on. Only the Controller accesses the Wallet. Its implementation is addressed in Security and Trust Considerations.
The Controller MUST contain a TSP Gateway, through which all TSP messages pass. The TSP Gateway MUST support TSP’s confidentiality function and both the NaCl and HPKE modes, and MAY support TSP’s metadata-privacy function.
The Controller MAY have communication channels other than the TSP Gateway, including an agent protocol’s ordinary traffic. Content received over such channels is unauthenticated input: it carries no TEA assurance and is handled under Model containment.
The Controller MUST have one or more VIDs, and MUST publish at least one of them so that first contact can be made without a prior relationship. Authority is delegated to, and accountability attaches to, the VID a TEA uses in an exchange. A TEA MAY use different VIDs with different counterparties, and a VID need not be published.
The Controller MUST implement the Delegation, Invocation and Continuing Exchanges and the Accountability requirements defined in this specification.

§ Verifiable Identifiers (VIDs)

A VID is an identifier whose controller can prove control of it, and whose key history is verifiable by any party, independently of who operates the service that publishes it. A VID MUST support key rotation and pre-rotation, with the history of rotations verifiable.

The TEA MUST support did:webvh [ref], including its pre-rotation feature. Other VID types MAY be supported.

§ TEA Message

Everything a TEA says to another TEA is said in TEA messages. A TEA message is a TSP message [1] sent from the sender’s VID to the receiver’s VID, whose payload is a TEA Container. The exchanges defined later are sequences of TEA messages; they define message types and their content, and nothing else about the message.

§ TEA Container

A TEA Container has the structure of an Authentic Chained Data Container (ACDC) [ref], with one departure: wherever ACDC uses a KERI Autonomic Identifier (AID), a TEA Container uses a VID. This affects the issuer field i, the issuee attribute a.i, the edge operators that compare them (for example I2I), and the revocation registry rd, whose key state and status are resolved through the VID rather than a KERI event log. A TEA Container is therefore not an ACDC in the literal sense, and this specification uses the term TEA Container, or Container, throughout. Where this specification is silent, the structure and semantics of ACDC apply.

A TEA Container has the following fields.

Field	Content
`v`	Version string, as ACDC defines: protocol version and, for the JSON, CBOR and MsgPack serializations, the serialization kind and size. A Container in native CESR is framed by CESR instead.
`d`	The SAID of the Container. This is the identity of the message.
`i`	The sender’s VID.
`s`	The SAID of the schema of the message’s type. Each exchange defines its types by their schemas.
`a`	Attributes. MUST contain `dt`, the sender’s timestamp, in the datetime form ACDC defines. The remaining attributes are defined by the type.
`e`	Edges. SAID references to other Containers, named as the type defines, for example the Propose an Accept accepts, or the capability chain an exercise relies on.
`r`	Rules. Present only where the type defines obligations.

A Container MAY use the selective-disclosure and graduated-disclosure forms of ACDC.

§ Requirements

A TEA message MUST be sent over TSP from the VID in i to the receiver’s VID. TEA relies on TSP for authenticity to the receiver, integrity and confidentiality, and MUST NOT re-implement them.
A TEA message is identified and referenced by its SAID d. Any reference from one TEA message to another MUST be an edge in e carrying that SAID.
Two Containers from the same sender MUST NOT have the same SAID. A receiver MUST NOT act more than once on Containers with the same SAID.
Signature. Every Container MUST carry the sender’s signature over d, produced under the key state of i and attached as CESR attachments. A verifier MUST recompute d and confirm it, resolve the key state of i in effect at a.dt within a defined clock-skew tolerance, and verify the signature against that key state.
Containers signed by other VIDs MAY be carried inside a message as content, for example the links of a capability chain. They prove what their signers said, not who sent the message that carries them.
The signature in requirement 4 is in addition to TSP message-level authentication, not a substitute for it.

Every Container is therefore a transferable proof of what its sender said, verifiable by any party that can resolve the sender’s VID, not only by the receiver. This is what TSP’s receiver-only authentication does not provide, and what authority and accountability require.

§ Trust Tasks

The exchanges defined in this specification are Trust Tasks in the sense of TSP. A Trust Task defined elsewhere that builds on TEA MUST conduct its trust-establishing communication in TEA messages.

§ Authenticated Exchange

The Authenticated Exchange is the pattern by which two TEAs negotiate what one party asks of the other and the terms on which it will be fulfilled. The Delegation and Invocation Exchanges are instances of it. Other Trust Tasks MAY follow or adapt it.

The roles are the Initiator, which opens the exchange, and the Responder. Either MAY be a composite TEA represented by one VID.

TSP has already authenticated the two VIDs to each other; the exchange concerns only the content of the negotiation. It uses four Container types:

Propose. What the sender asks of the other party, together with the terms of its fulfilment. Either party MAY send one. A Propose with an edge to an earlier Propose in the same exchange is a counter-proposal and supersedes it.
Accept. Agreement to a Propose, which it references by edge. An Accept is provisional until confirmed.
Ack. The proposing party’s confirmation of an Accept, which it references by edge. The Ack binds the agreement.
Withdraw. Declines a Propose, or withdraws the sender’s own Propose or provisional Accept, which it references by edge.

A minimal exchange is Propose, Accept, Ack. Counter-proposals in either direction MAY precede the Accept. Every message in an exchange references, directly or through its edges, the Propose that opened it; the SAID of that opening Propose identifies the exchange.

Only the most recent Propose in an exchange is live. A superseded Propose MUST NOT be accepted.
Bounding. A Propose MUST carry a validUntil by which it may be accepted. An Accept MUST carry a validUntil by which the Ack must be effective, set so that an Ack can be effective within it. Neither MAY be open-ended.
Binding. The agreement binds when, and only when, an Ack referencing the Accept is effective within the Accept’s validUntil. The Ack’s own a.dt is the time of binding. If no such Ack exists, the acceptance lapses and nothing is bound.
A Withdraw never binds or unbinds. It is effective only in the absence of a valid Ack; if a Withdraw and a valid Ack cross in flight, the Ack prevails. The accepting party’s exposure to this is bounded by the validUntil it set on its Accept.
validUntil is evaluated against the sender’s own a.dt, within a defined clock-skew tolerance. Binding turns solely on the existence of a valid Ack within the window; no comparison between the two parties’ timestamps is made.

§ Delegation Exchange

A Delegation Exchange is an Authenticated Exchange in which one TEA, the Delegator, confers authority on another, the Delegate, on terms both accept. The agreement is carried in a single Container of type Capability, issued by the Delegator to the Delegate as the Delegator’s final message in the exchange. A Capability takes effect only when the exchange that issued it is bound.

Authority is delegated to, and accountability attaches to, the Delegate’s VID. A Capability is issued under, and verified against, the Delegator’s VID.

§ What a delegation states

A delegation states policy of three kinds, separated by two questions: is it a fact the authority rests on or a duty someone owes, and is it checkable at the time of exercise or only knowable later?

	checkable at exercise	only knowable later
fact the authority rests on	limitation	assumption
duty someone owes	—	obligation

The empty cell is structural: a duty required before acting is a precondition, and a precondition is a limitation.

The authority is a capability, a triple

capability = ( resource, ability, limitation )

where the resource is which object, the ability is which operation, and the limitation is under what limits the operation may be exercised. The authorization decision, whether an Exercise is within authority, is computed only from the capability, and composes by meet down a delegation chain.

Obligations and assumptions are the post-gate policy. They do not enter the authorization decision and are settled after the act.

An obligation is a duty one party owes to the other: to report, notify, settle, serve, or watch. Each obligation names its obligor. An obligation owed by the Delegate is the Delegate’s exposure; an obligation owed by the Delegator, such as a duty to serve, is the Delegator’s. If unmet, the obligor is answerable: a breach.
An assumption is a fact the authority rests on that the Delegate can neither control nor observe. Nobody is obliged to make it true; if it proves false the act is undermined but no one is at fault. An assumption belongs in a Capability only if it conditions the authority.

§ The Capability Container

A Capability uses the three Container sections as follows: a carries the capability, r the post-gate policy, and e the chain to the Capability that establishes the Delegator’s own authority.

a:                                   # capability
  i: <Delegate VID>
  resource: <selector>               # omitted => inherit from parent
  ability:  [ ... ]                  # omitted => inherit from parent
  limitations:                       # omitted keys => no limit on that axis
    <limitation-type>: <bound>
    validUntil: <ts>                 # bounded scalar (meet = min); absent => no expiry
r:                                   # post-gate policy
  obligations:
    <label>:                         # one labeled block per obligation
      d:  <SAID of this clause>
      l:  "<rendering>"
      t:  <obligation-type>          # namespace term
      by: <obligor VID>              # the Delegate or the Delegator
      to: <beneficiary VID>
      on: <trigger>
      by_when: <deadline>
  assumptions:
    <label>:
      d:  <SAID of this clause>
      l:  "<rendering>"
e:
  auth: { n: <parent SAID>, o: I2I } # absent at a root issuance
rd: <registry SAID>                  # optional: present => revocable

A Capability MUST be issued by the Delegator, as i, to the Delegate, as a.i.
A Capability MUST either carry an edge to the Capability that establishes the Delegator’s own authority, with the I2I operator, so that the issuer of the delegation is the issuee of the authority delegated; or be a root issuance, which carries no such edge and is the origin of authority over the resource. Whether a root is trusted is the relying party’s decision.
A non-root Capability MUST carry a validUntil limitation; it can only shorten as authority is re-delegated. A root issuance MAY be open-ended.
A Capability MAY be revocable, indicated by rd. The registry’s state MUST be resolvable through the Delegator’s VID; its form is out of scope of this version. Revocation is best-effort early termination and never a substitute for validUntil.
At the time of exercise, a verifier MUST confirm that every Capability on the chain is within its validity window and, where revocable, not revoked.

§ Attenuated re-delegation

Re-delegation MUST be supported to arbitrary depth, MUST allow authority to be composed from more than one source, and MUST be strictly attenuating. Attenuation is intrinsic to the encoding rather than checked.

Each capability axis is a bounded meet-semilattice: a partial order “is at most as permissive as,” a meet, and a top element meaning no narrowing on that axis. The capability is their product, with meet taken component-wise, so the meet is total, deterministic, order-independent and decidable.

axis	value	order	meet	top
resource	a selector over a namespace	is a sub-resource of	most specific common selector; bottom if disjoint	the whole granted namespace
ability	a subset of an ability vocabulary	subset	intersection	the full granted vocabulary
limitation	a map from limitation-type to bound	at least as tight on every type	per-type meet; absent keys are top	the empty map

A re-delegation MUST be expressed as a restriction relative to its source: only the narrowed resource or ability and the limitations and obligations added at that step. An axis left unspecified is inherited unchanged.
The effective capability of a Capability is the meet of the effective capabilities reached through its edges with its own restriction. Because meet is monotone, no Capability is more permissive than any of its sources.
The effective obligation set of a Capability is the union, along its chain, of the obligations whose obligor is the Delegate at the link where they were stated. Such obligations only accumulate. Obligations owed by a Delegator bind that Delegator to that Delegate and do not accumulate down the chain.
Under an AND edge group, the effective capability is the meet across all sources, the effective obligation set is the union, and expiry or revocation of any source invalidates the composed authority. Under an OR edge group, an Exercise is within authority if it is within the effective capability of some currently valid source met with the restriction; it is not a join. The composed authority remains valid while at least one source is.

§ Resources, abilities and limitations

The capability axes take their values from namespaces, owner-local or community-wide, each published and SAID-addressed. Trust in a namespace comes from the SAID, not from who serves it.

Resources. A resource is identified by the owner’s own convention. The scheme MUST be a bounded meet-semilattice: a decidable is-sub-resource-of order, a meet, and a top. Without a decidable order a verifier cannot tell attenuation from lateral escalation. A URL path hierarchy satisfies this and is RECOMMENDED.

Abilities. The ability vocabulary of a resource type is defined by its owner or a community namespace. The axis is its powerset under subset.

Limitations. A limitation is a typed bound. Each limitation-type selects one of the value-lattice kinds defined here and supplies no meet of its own, which is what keeps the core closed:

bounded scalar: meet is min, top is unbounded;
membership set: meet is intersection, top is the full set;
interval: meet is intersection, top is unbounded.

A limitation-type is declared in a namespace with its identifier, value domain, kind, top and rendering template.

Profiles. An implementation MAY write limitations in an existing policy language through a named syntactic profile: a published, SAID-addressed fragment of the language’s grammar with its mapping into the capability core. A verifier MUST reject an expression outside the declared profile. Profiles supply syntax; the meet is this specification’s.

§ Obligations

Obligations form a set ordered by superset, with meet as union and top as the empty set. They are enforced through accountability, never by the authorization decision.

field	meaning	default
`t`	the obligation-type, from a namespace	—
`by`	the obligor	the Delegate
`to`	the beneficiary	—
`on`	the trigger that makes it due	—
`by_when`	the deadline, relative to the trigger	—
params	type-specific content	—
discharge	what counts as fulfilment	a Discharge Container
`l`	the rendering, SAID-committed	the type’s template

Each obligation and each assumption is a labeled block in r, carrying its rendering in l and its fields as properties. The obligation-type declares the parameter schema, trigger semantics, discharge form and rendering template; the instance in r binds it to concrete values.

A trigger is one of:

on:
  exercise: <ability>     # when this authority is exercised
  clause:   <SAID>        # when another clause is discharged
  event:    <event-type>  # on an externally attested event
  time:     <schedule>    # periodic or absolute
  standing                # continuously in force

An obligation triggered on exercise creates no duty if the authority is never used. A standing obligation is verified by periodic attestation on a schedule.

A Discharge is a Container sent by the obligor that references the obligation clause’s SAID and, for exercise, event and clause triggers, the SAID of the triggering Container. Compliance is a matching check over the evidence trail.
Non-performance never invalidates authority already exercised. It leaves a verifiable gap in the accountability trace and, where the Capability is revocable, MAY lead to revocation.
Obligations compose by union and the union MAY be unsatisfiable, by contradiction or by a cycle of clause triggers. Union MUST always compose structurally; an unsatisfiable set is not an authorization error. The only invariant on a clause reference is that it be a well-formed SAID. A party SHOULD screen the obligations it can see before accepting, and bears any set it accepts.

§ Computed and interpreted policy

Each stated item of policy is either computed, evaluated against the closed capability core, or interpreted, read and judged by a capable party. Interpreted policy is expected to be the principal way parties say what they mean; the computed core is the security and safety floor beneath it.

A verifier MUST compute the effective capability of a chain by reduction, taking the meet along the chain and the union of the Delegate’s obligations, using only the closed-core semantics. Every conforming verifier obtains the same result.
A Capability MAY carry interpreted policy as an interpreted limitation, obligation or assumption. It is signed and SAID-committed like any other content, and MAY be prose or any medium a capable party can interpret, with a content type.
An interpreted limitation can only narrow. No reading of it, however mistaken or adversarial, can grant authority the computed core did not; a misreading can at most fail to narrow. An interpreted obligation or assumption does not enter the authorization decision at all.
Where a party evaluates interpreted policy, it SHOULD emit a signed Decision Record Container stating the policy evaluated, the Exercise, and the conclusion, so that a judgment that cannot be reproduced can still be attributed.

A Delegator SHOULD place anything bearing on security or safety, or requiring deterministic agreement between verifiers, in the closed core, and use interpreted policy only for what requires judgment. A Delegate that Acks a Capability carrying interpreted policy accepts liability to act consistently with it as a reasonable party would read it.

The soundness of this model, that no chain can exceed its root and no Delegate can shed obligations, is stated and proven in Appendix: Soundness.

§ Invocation Exchange

Authority is created in a Delegation Exchange and used in an Invocation Exchange. An Invocation Exchange runs between the holder of a Capability and the service that controls the resource. It opens with presentation and continues, with exercises, denials, notices and disputes, for as long as the authority is in use. It uses the Container types Present, Bind, Exercise and Result, and the types of the Continuing Exchange.

§ Presentation

Before exercising a Capability against a service, the holder MUST send a Present carrying the Capability chain. The Present’s i MUST equal the a.i of the leaf Capability. Since a Container is sent from the VID in i, the TSP-authenticated sender is thereby the VID the Capability was issued to; this is the holder binding, and no separate proof of possession exists or is needed.
The service MUST verify: that the chain is well formed and I2I-linked; that it roots in an issuance the service accepts as authoritative for the resource; that the leaf a.i equals the Present’s i; that every link is within its validity window and, where revocable, not revoked; and that the effective capability is non-empty. Any failure is a Denial, under fail-closed.
On success the service MUST send a Bind referencing the Present. The authority is then bound to the holder’s VID, with the scope and lifetime of the presented chain. No session object exists; the binding is the chain.

§ Exercise

An Exercise is a Container, sent by the holder, that references the Bind and states the resource, the ability and the arguments of one operation. The holder SHOULD screen each Exercise against the Capability it holds.
For each Exercise the service MUST confirm, at the time of exercise, that the operation is within the effective capability and that the chain remains valid. How the service refreshes its view of validity is an implementation choice within the freshness rules.
The service MUST answer an Exercise with a Result, referencing the Exercise and carrying the outcome, or with a Denial. The Result is the service’s accountable record of what it did; the Exercise is the holder’s.
An Exercise is the triggering Container for obligations with an exercise trigger.

Both parties hold the same signed chain. Divergent evaluations are disputes, not protocol errors.

§ Continuing Exchange

Authorization events between the same parties after presentation are messages of the same exchange.

Denial. References the Present or Exercise it refuses, and carries a condition: no-binding, exceeds-capability, stale, or declined. It MAY carry a what-would-suffice hint, including the roots of issuance the service accepts. A declined Denial need carry no reason; it is signed and therefore disputable.
Notice. An unsolicited state change, such as revocation or expiry, referencing the Bind or the affected Capability.
Re-presentation. A new Present, replacing a stale binding, handled under requirements 1 to 3.
Dispute. Contests a Denial or a Result, which it references.

A no-binding Denial is the correct response to an Exercise from a party that has not presented. Error-driven bootstrap is not the intended flow; a holder SHOULD present before exercising.
Whether a declined Denial breaches a duty the service owes is a matter of the Delegator-owed obligations in the Delegation Exchange that created the holder’s authority, adjudicated through Accountability. A party that requires a duty to serve MUST express it there.

§ Accountability

Authorization and accountability are two readings of one structure. A chain of Capabilities read from root to leaf is the delegation of authority; read from leaf to root it is the accountability trace. A TEA is one unit of authorization and accountability because both derive from the same signed chain.

Accountability is retrospective and evidentiary: who agreed to or did what, provable after the fact. Every Container is signed under its sender’s VID, so every message of every exchange is evidence that a third party can verify.

A TEA SHOULD retain the Containers of the exchanges it is party to for as long as it may be held accountable for them.
The accountability chain of any authority a TEA holds or exercises MUST terminate in a principal, a natural person or an organization, that can bear accountability. A TEA MUST NOT be the terminal responsible party for an authority.
Authority MUST NOT be inferred from a record that an agreement occurred. Conferral of authority requires a Capability.

TBD.

§ Integration with AI Agent Protocols

TBD.

§ Integration with MCP

TBD.

§ Integration with A2A

TBD.

§ Worked Example: Delegated Service Access

This section is informative.

Actors. BookingService, S, owns the booking resource and is both the root of authority over it and the party that verifies access to it. Alice is the account holder at S and the accountable principal. Agent is Alice’s TEA and the Delegate. Each holds a did:webvh VID:

VID_S      = did:webvh:QmS…:booking.example
VID_Alice  = did:webvh:QmA…:alice.example
VID_Agent  = did:webvh:QmG…:agent.alice.example

Identifiers and SAIDs in this example are illustrative and shortened; they show the form, not verifiable values. SAIDs are written E…, as a CESR Blake3 digest begins.

The chain of authority runs S to Alice to Agent, every link an I2I delegation, so S verifies a chain that roots in its own issuance.

Hop 1, root issuance. S and Alice run a Delegation Exchange; S’s final message is the root Capability. It carries a duty S owes Alice, as a Delegator-owed obligation.

Cap_S->Alice
  i:  VID_S
  a:
    i:  VID_Alice
    resource: bookingservice:account/alice
    ability:  [ create-booking, cancel-booking, view ]
  r:
    obligations:
      serve:
        l:  "S shall honour bookings within the account terms."
        t:  serve
        by: VID_S                     # owed by the Delegator
        to: VID_Alice
        on: standing
  rd: <S's registry SAID>
  (no authority edge: S is the root)

Hop 2, attenuated re-delegation. Alice and Agent run a Delegation Exchange; Alice’s final message is a restriction relative to hop 1, with one obligation conditional on exercise.

Cap_Alice->Agent
  i:  VID_Alice
  a:
    i:  VID_Agent
    resource: bookingservice:account/alice
    ability:  [ create-booking ]
    limitations:
      maxAmount: 500 USD
      category:  [ flights ]
      validUntil: <now + 7 days>
  r:
    obligations:
      report:
        l:  "The Agent shall report each booking to Alice within 24 hours."
        t:  report
        by: VID_Agent
        to: VID_Alice
        on: { exercise: create-booking }
        within: 24h
        what: { booking-id, amount, vendor }
  e:
    auth: { n: <SAID of Cap_S->Alice>, o: I2I }
  rd: <Alice's registry SAID>

Effective capability. The meet along the chain: create-booking on Alice’s account, at most 500 USD, flights only, until day 7. A 420 USD flight is inside; a 900 USD booking, a hotel, or an Exercise on day 8 is not. The Agent’s effective obligations are the Delegate-owed ones along the chain: report each booking to Alice within 24 hours. S’s duty to serve binds S to Alice and does not accumulate onto the Agent.

Runtime.

Delegated service access: S to Alice to Agent — Figure 5: Delegated service access

Presentation. Agent sends S a Present carrying { Cap_Alice->Agent, Cap_S->Alice }. S verifies that the chain roots in VID_S, that the I2I edge holds, that the Present’s i equals the leaf’s a.i, that nothing is expired or revoked, and that the effective capability is non-empty. S sends a Bind.
Exercise. Agent sends an Exercise referencing the Bind: create-booking, the 420 USD flight. S confirms the operation is within the effective capability and the chain is still valid, creates the booking, and sends a Result referencing the Exercise.
Obligation. The Exercise triggers the report obligation. Agent sends Alice a Discharge referencing the obligation clause and the Exercise.
Later. A 900 USD Exercise is answered with a Denial, condition exceeds-capability. On day 8, any Exercise is answered with a Denial, condition stale, until Agent re-presents a fresh chain.

Two messages in Container form. Every TEA message has the same shape; the Exercise of step 2 and its Result are shown here in JSON, each sealed in a TSP message from the VID in i and carrying that VID’s signature over d as a CESR attachment.

{
  "v": "ACDC10JSON000xxx_",
  "d": "EExercise…",
  "i": "did:webvh:QmG…:agent.alice.example",
  "s": "ESchemaExercise…",
  "a": {
    "dt": "2026-10-27T14:03:11.412000+00:00",
    "resource": "bookingservice:account/alice",
    "ability": "create-booking",
    "args": { "flight": "XX123", "date": "2026-11-02", "amount": "420 USD" }
  },
  "e": {
    "bind": { "n": "EBind…" }
  }
}

{
  "v": "ACDC10JSON000xxx_",
  "d": "EResult…",
  "i": "did:webvh:QmS…:booking.example",
  "s": "ESchemaResult…",
  "a": {
    "dt": "2026-10-27T14:03:12.907000+00:00",
    "outcome": "created",
    "booking-id": "BK-77213"
  },
  "e": {
    "exercise": { "n": "EExercise…" }
  }
}

The Exercise’s edge to the Bind, and the Result’s edge to the Exercise, are the SAID references the Continuing Exchange correlates on. Neither edge points at a targeted Container, so no I2I constraint applies to them. The Present, not shown, has an edge to Cap_Alice->Agent, which is targeted, so I2I applies by default and requires the Present’s i to equal that Capability’s a.i: holder binding enforced by the edge rule.

What the example shows. The service is both root and relying party, so no external anchor is needed. Each hop is a uniform I2I restriction, so the Agent cannot exceed Alice and Alice cannot exceed S. Read one way the chain is the delegation; read the other it is the accountability trace, terminating in Alice, never in the Agent. And the service’s own duty has a place in the record.

§ Security and Trust Considerations

§ Security model

Assumptions. TEAs are capable and evaluate what they accept; the protocol supplies a language and a channel, not a reasoning engine, and does not protect a TEA from its own acceptance decisions. The Controller and its Wallet are intact; their compromise is full compromise of the TEA and is the boundary condition, not a case the mechanisms defend against. Counterparties’ VIDs and key histories, and any revocation registries, can be resolved, with fail-closed when they cannot. Which roots of authority to trust is the relying party’s choice; sound is not the same as trusted.

Adversaries. A manipulated or compromised AI model inside a TEA; a malicious counterparty TEA; a network adversary that observes, blocks or replays; compromise of a VID’s keys; and a thief holding credential bytes.

§ Soundness

The closed capability core gives two guarantees by construction: no TEA in a chain holds more authority than its root granted, and no Delegate holds fewer obligations than its chain imposed. Both follow from restriction-only encoding, the meet along I2I-linked edges, and the union of Delegate-owed obligations, and they hold regardless of any interpreted policy carried alongside, since an interpreted limitation can only narrow. Overstating a restriction gains nothing: the meet with the parent discards what the parent did not have. The guarantees are conditional on verification of every link, and bound authority, not behaviour and not fulfilment. The formal statement and proofs are in Appendix: Soundness.

§ Model containment

A manipulated or compromised model cannot act beyond the Capability its TEA holds. All of the model’s context, memory and tool use pass through the Controller, and the Controller checks every Exercise against the effective capability of the chain. Authority is enforced outside the model, so whatever the model decides under a jailbreak, a poisoned input or adversarial control, it cannot cause an action the Controller would not permit on the chain alone. Soundness bounds what a chain can express; containment bounds what an agent can do; together, an agent’s reach is no larger than what an accountable principal conferred, and attenuation makes that envelope small. The trust boundary is the Controller, not the model.

Identity authentication additionally contains one class of prompt injection: instructions arriving agent-to-agent over TSP are attributed to an authenticated VID and are non-repudiable, so the attacker must first hold a VID and a relationship, and then leaves evidence. Injection carried in unauthenticated content, including a fetched page, a document, a tool result from a non-TEA source, or an agent protocol’s own traffic, is not prevented at the identity layer; it is contained, and once acted on over TSP it is attributable. None of this solves prompt injection; it bounds its consequences, raises its cost and removes its anonymity.

§ Holder binding

A Capability confers nothing on whoever holds its bytes. Authority is conferred on the VID in a.i, a Present is sent from the VID in its i, and the service requires the two to be equal. A copied chain presented by anyone else fails that check, so theft of a credential is not theft of authority, and there is no bearer step anywhere in a chain, since every I2I edge ties the issuer of one link to the issuee of the one above. A compromised holder, whose keys or Controller are breached, is outside this property and is handled by key management below.

Replay of a Present or an Exercise is prevented by the TEA Message rules: the SAID includes the sender’s timestamp, and a receiver acts at most once per SAID. Cross-service replay also fails because a chain roots in one resource owner.

§ Key management and freshness

Authority rests on two things being true at the moment of exercise: that a signature comes from the claimed VID, and that every link of the chain is still live.

Rotation and pre-rotation. VIDs MUST support key rotation with a verifiable history and pre-rotation. Rotation makes identity durable across key changes; pre-rotation means compromise of the current key does not permit takeover of the VID, and is the recovery path.
Key state at signing time. A signature is evaluated against the key state in effect at the signer’s a.dt, within the clock-skew tolerance, per the TEA Message rules. A key compromised today does not invalidate earlier legitimate signatures, and a forgery cannot be backdated to a rotated-away key state.
Freshness. validUntil and, where present, revocation are checked at the time of exercise for every link, per the Delegation Exchange. They fail differently: validUntil bounds exposure when revocation infrastructure is unreachable; revocation ends authority that cannot wait for expiry. Revocation is a state the issuer sets in the registry named by rd, read by the verifier from its own cache; it is eventually consistent and takes effect after a grace window.
Fail closed. If a verifier cannot confirm key state or non-revocation, it MUST deny. A verifier MAY accept cached status within a bounded staleness window; beyond it, it denies. The attacker’s natural move is to block the check, not to break it, and fail-closed turns that into a denial rather than a grant.
The Controller boundary. Compromise of the Controller, and so of the Wallet, lets an attacker sign as the TEA, exercise its Capabilities and issue delegations. Implementations SHOULD hold key material in a hardware security module or secure enclave. After compromise, the controller rotates to the pre-committed key and revokes affected Capabilities; what the attacker did under the legitimate VID remains attributable to the TEA.

§ Interpreted policy and obligations

Interpretation cannot escalate, since an interpreted limitation can only narrow; injection into carried prose is at worst a failure to restrict. Interpretation is not reproducible, so divergent readings yield inconsistent denials, never inconsistent grants, and are attributable through the Decision Record. Interpretation gaps are disputes, resolved through Accountability under a reasonable-interpretation standard. Obligation sets may be unsatisfiable, and abusive obligations are not prevented; both are the accepting party’s responsibility, and acceptance is the assumption of liability.

§ Authenticated Exchange

Binding turns solely on the existence of a valid Ack within the Accept’s validUntil; no inter-party timestamp comparison is made, so an adversary cannot tilt the outcome by backdating. The residual window in which a Withdraw loses to a racing Ack is inherent to coordinator-free commit and is bounded by the validUntil the accepting party itself set. Every offer and acceptance carries a validUntil, so no party is left exposed indefinitely. A timestamp outside the clock-skew tolerance MUST be rejected.

§ Privacy and disclosure

A signed Container is intentionally not receiver-private: its purpose is third-party-verifiable proof, so presenting it discloses authorship and content to the verifier.
A holder SHOULD present only the part of a chain the decision needs, and SHOULD use selective and graduated disclosure to reveal only what the relying party requires. Obligations, assumptions and unused attributes of any link can be compacted to their SAIDs; the capability axes of every link, and the issuer and issuee VIDs the I2I check needs, cannot.
Reusing one VID across many relying parties enables correlation; that is the cost of accountability. Where unlinkability matters, a TEA SHOULD use distinct VIDs for interactions that do not require it.
Content in transit is confidential to the TSP counterparty; the relying party necessarily learns what it must to decide.

§ Residual risks

Trust-root choice is external; sound is not trusted.
A bounded inconsistency window in the Authenticated Exchange, inherent to coordinator-free commit.
Residual clock dependence, reduced by affirmative binding and skew tolerance, not removed.
Containment depends on Controller and Wallet integrity.
Interpreted policy is attributable but not reproducible.
Obligation satisfiability is not guaranteed.
Fail-closed trades availability for safety.
Injection via unauthenticated content is contained and attributable, not prevented.
VID correlation is the privacy cost of accountability.
A compromised holder within the rotation and revocation window causes attributable harm.

§ Appendix: Soundness

§ A.1 Setup

Let the capability lattice be L = R × A × M (resource × ability × limitation), the product of three bounded meet-semilattices. L inherits component-wise a partial order ≤ (reflexive, transitive), a meet ∩ that is a greatest lower bound (x ∩ y ≤ x and x ∩ y ≤ y for all x, y), and a top ⊤ that is the identity for meet (x ∩ ⊤ = x).

A delegation graph is a set of Capability nodes. Each node n carries a local restriction r(n) ∈ L (omitted axes = ⊤) and an obligation delta d(n), the set of Delegate-owed obligations stated at n (omitted = ∅); Delegator-owed obligations are not part of d(n). A node is a root if it has no authority edge.

Effective capability E(n) and effective obligation set D(n) for the single-parent and AND cases:

root ρ:         E(ρ) = r(ρ)                 D(ρ) = d(ρ)
single parent:  E(n) = E(p) ∩ r(n)          D(n) = D(p) ∪ d(n)
AND {p₁..pₖ}:   E(n) = (⋂ᵢ E(pᵢ)) ∩ r(n)   D(n) = (⋃ᵢ D(pᵢ)) ∪ d(n)

A graph is well-formed if every edge n → p satisfies the provenance constraint Issuer(n) = Issuee(p) (I2I), and every node on the chain has a valid signature, is non-revoked, and is within its validity window at the time of exercise.

§ A.2 Lemma (one-step attenuation / accumulation)

For any non-root node n and each parent p required to reach n’s authority: E(n) ≤ E(p) and D(n) ⊇ D(p).

Proof. Single parent: E(n) = E(p) ∩ r(n) ≤ E(p) since meet is a lower bound; D(n) = D(p) ∪ d(n) ⊇ D(p) since union is an upper bound. AND-group: E(n) ≤ ⋂ᵢ E(pᵢ) ≤ E(pⱼ) for every j, and dually D(n) ⊇ ⋃ᵢ D(pᵢ) ⊇ D(pⱼ). ∎

§ A.3 Theorem 1 (Capability Soundness — no escalation)

In a well-formed graph, for every node n and every root ρ reachable from n along required (single/AND) edges, E(n) ≤ E(ρ) = r(ρ).

Proof. Induction on the path length from n to ρ. Base (n = ρ): E(n) = E(ρ) by reflexivity. Step: by the Lemma E(n) ≤ E(p) for the parent p on the path, and by the induction hypothesis E(p) ≤ E(ρ); transitivity gives E(n) ≤ E(ρ). Since E(ρ) = r(ρ) is exactly the grant the resource owner made at the root, no chain can manufacture authority the owner did not confer. ∎

§ A.4 Theorem 2 (Obligation Accumulation — no shedding)

In a well-formed graph, for every node n and every root ρ on a required path, D(n) ⊇ D(ρ). The theorem ranges over Delegate-owed obligations; a Delegator-owed obligation binds the Delegator at the link where it is stated and is not accumulated.

Proof. Dual to Theorem 1, with ⊇ for ≤ and ∪ for ∩; union is an upper bound and ⊇ is reflexive and transitive. ∎

§ A.5 Corollary (robustness to a dishonest delta)

A node gains nothing by overstating its restriction or omitting inherited obligations. If r(n) names more than the parent holds, E(n) = E(p) ∩ r(n) ≤ E(p) regardless (the meet discards the excess); if d(n) omits a parent obligation, D(n) = D(p) ∪ d(n) ⊇ D(p) regardless. Attenuation is thus intrinsic: E and D are computed by meet and union, never read from a node’s own claim.

§ A.6 Extension (OR-composition)

Under an OR-group {p₁..pₖ}, a node has no single effective capability; each alternative is evaluated independently:

branch j:  E(n)|ⱼ = E(pⱼ) ∩ r(n)        D(n)|ⱼ = D(pⱼ) ∪ d(n)

An Exercise q is within authority at n iff there exists a currently-valid branch j with q ≤ E(n)|ⱼ; the obligations owed for that exercise are D(n)|ⱼ.

Claim. Every admissible exercise is bounded by the root of its branch, and no escalation is introduced by the disjunction.

Proof. Fix the branch j invoked. The sub-chain through pⱼ is itself well-formed, so by Theorem 1 E(n)|ⱼ = E(pⱼ) ∩ r(n) ≤ E(pⱼ) ≤ E(ρⱼ) for the root ρⱼ of that branch; hence any q ≤ E(n)|ⱼ satisfies q ≤ E(ρⱼ). As each disjunct is individually bounded, their disjunction admits no q exceeding every root — every admitted q is within the root of the branch that admitted it. Dually, by Theorem 2 D(n)|ⱼ ⊇ D(ρⱼ). ∎

§ A.7 Interpreted policy preserves soundness

An interpreted limitation O(n) is a narrowing filter evaluated at exercise. The authorized set is { q : q ≤ E(n) ∧ O(n)(q) } ⊆ { q : q ≤ E(n) }, where q ranges over Exercises. Since O(n) only removes Exercises, the upper bound of Theorem 1 holds a fortiori; no interpreted policy can broaden authority beyond the computed result.

§ A.8 Role of the structural premises

I2I provenance makes well-formedness cryptographically real. The algebra of A.2–A.4 bounds authority only relative to the declared parents; Issuer(n) = Issuee(p) is what guarantees a node can only build on authority issued to it, so the declared parent is the real one. Without it the theorems are vacuous.
Restriction-only encoding forces E(n) to be defined as E(p) ∩ r(n). Because the meet is the only route to a node’s capability, monotonicity (and hence A.5) is unavoidable rather than a property to be audited.

§ A.9 Conformance over expression languages

The theorems above are stated over the capability lattice L, never over a syntax. A named syntactic profile supplies a mapping ⟦·⟧ from expressions in its fragment into L. Because E(n) and D(n) are defined by meet and union in L, and the proofs use only the lattice properties, the guarantees transfer unchanged to any language admitted through a conforming profile.

Two conditions are required of a profile, and they are what conforming means:

Totality — every expression in the fragment denotes some element of L.
Determinism — ⟦e⟧ is a fixed element of L, identical for every verifier. In particular a denotation MUST NOT depend on verifier-local state; otherwise the meet is not well-defined and conforming verifiers cease to agree.

Monotonicity of the language is not required. E(n) = E(p) ∩ ⟦r(n)⟧ ≤ E(p) holds whatever ⟦r(n)⟧ denotes, so an expression attempting to broaden is discarded by the meet (A.5). A profile must guarantee that a denotation exists and is fixed, not that it narrows.

Soundness is therefore a conformance result: any language admitted through a conforming profile inherits Theorems 1 and 2 without further proof.

§ Annex A (informative): Design Rationale and Comparison

This section is non-normative. It situates the design choices above against commonly used schemes for the benefit of reviewers and implementers; it imposes no requirements.

§ Negotiation and binding

The Authenticated Exchange’s binding model is, in effect, a peer-to-peer two-phase commit: the offering party’s Ack is the commit decision. Unlike classical two-phase commit it needs no coordinator and does not block on a failed coordinator, because the validUntil bounds turn an unresponsive counterparty into a clean lapse rather than an indefinite hang — the same hardening production systems add to two-phase commit through presumptive-abort timeouts.

Race resolution and the inconsistency window. The asymmetry between Withdraw and Ack is the same asymmetry two-phase commit draws between a participant’s vote and the coordinator’s decision. An Accept is a vote-commit: once cast, the accepting party honors it until its validUntil lapses, and cannot unilaterally abort a decision the offering party may still make within that window. The offering party’s Ack is the commit decision, and it is supreme — a Withdraw is effective only in the absence of a valid Ack, so a Withdraw that races a binding Ack simply loses. This is what makes the resolution deterministic without a coordinator and without comparing the two parties’ self-signed timestamps against each other: binding turns solely on whether a valid Ack exists within the window, a question with one answer that an adversary cannot tilt by backdating. The price is that the accepting party cannot be certain a late Withdraw will land; it may lose to an Ack already in flight. That uncertainty is exactly the residual bounded inconsistency window noted below — it is bounded by the validUntil the accepting party itself chose, and no coordinator-free commit can eliminate it.

The closest market analogue is request-for-quote trading with “last look,” in which a maker may reject a deal within a window after a taker hits a time-bounded quote. Last look is widely criticized because it is one-sided: it grants the maker a free option at the taker’s expense. The symmetric validUntil on both Propose and Accept answers that critique — it bounds the offeror’s confirm window the way it bounds the acceptor’s offer window — so the design can be characterized as affirmative binding without the last-look asymmetry.

Hashed-timelock contracts (HTLCs) for atomic swaps are a closer fit on the symmetry of timeouts but solve a different problem: HTLCs provide atomic exchange of value, whereas the Authenticated Exchange provides agreement on terms. The Ack binds what the parties agreed; it does not guarantee performance. Where atomic execution of an agreed obligation is required, that is a separate Trust Task layered above the negotiation. Token-expiry schemes (OAuth/JWT exp/nbf) informed the validUntil mechanism but are not negotiations; GNAP is the closest negotiation-of-authority analogue but is authorization-server-mediated and centralized, whereas this design is peer-to-peer over TSP with the outcome captured in a portable ACDC.

Scheme	How offers are bounded	What binds	Durable verifiable record?	Notable weakness
Two-phase commit	Coordinator timeout (often absent → blocking)	Coordinator commit	No (ephemeral logs)	Needs a trusted coordinator; blocks on its failure
RFQ + last look	Quote firm-for-N-seconds	Maker confirm after taker hits	Venue logs, not portable	Asymmetric free option for the maker
HTLC / atomic swap	On-chain timelocks	Preimage before timeout	Yes (on-ledger)	Needs a ledger and the asset; value exchange only
OAuth2 / JWT	`exp` / `nbf` in token	One-shot issuance	Token verifiable, not a negotiation record	Clock-dependent; not a negotiation
GNAP	Protocol-level	Grant issuance	Server-side	Authorization-server-mediated; centralized
IPEX	Not expiry-first	grant/admit	Yes (ACDC)	Disclosure only; expiry not first-class; draft incomplete
Authenticated Exchange	Symmetric `validUntil` on Propose and Accept	Affirmative Ack (confirm-binds)	Yes (ACDC-chained, portable)	Extra round-trip; clock-skew residue; binds terms, not performance

The distinctive position of the Authenticated Exchange is that it is the only one of these combining decentralized peer operation (no coordinator, certificate authority, venue, or ledger), symmetric exposure bounding, and a portable non-repudiable record verifiable after the fact. The honest costs are an extra round-trip, a residual bounded inconsistency window that no timeout-based commit can fully eliminate — the window in which an accepting party’s Withdraw may lose to a racing Ack, bounded by its own validUntil — and a remaining clock dependence that affirmative binding reduces but does not remove.

§ Delegation and attenuation

The capability model draws on established authorization-capability designs. (What this specification calls a limitation is the device the capability-security literature calls a caveat*; this subsection uses each tradition’s own term.)* SPKI/SDSI is the formal precedent for computing effective authority as the intersection of authorizations along a delegation chain (tag intersection / certificate-chain reduction); the closed-core “meet along the chain” rule is the same idea over ACDC edges. Macaroons achieve strict attenuation structurally by making caveats append-only — a restriction can be added but not removed — which is the model for the restriction-only re-delegation encoding. UCAN provides decentralized, DID-native capability chains with an attenuation-checked subsumption order, and ZCAP-LD is the linked-data cousin in which caveats accumulate down the chain.

The closest ACDC-native precedent is the GLEIF vLEI credential chain (a role credential chained to a Legal Entity credential chained to a Qualified vLEI Issuer credential), itself a delegation-of-authority chain expressed entirely through ACDC edges with the I2I operator. The principal way this specification goes beyond IPEX — the nearest ACDC-native exchange protocol — is that IPEX provides no validity bounds or attenuation semantics at all (its security considerations were never completed), so the bounding and strict-attenuation apparatus here is additive rather than a restatement.

The rationale for favouring a closed capability core in this specification is that it is the part whose security can be proven: a capability structure with a defined meet supports a soundness theorem — no chain of delegations can yield authority exceeding its root — which is a materially stronger guarantee than re-checking attenuation with a general policy engine on every exercise. Interpreted policy remains available for what the closed core cannot express, on the understanding that it trades the structural guarantee for a judgment.

§ Annex B (informative): Relative completeness

Soundness and completeness are separate claims, and the theorems of the Soundness appendix establish only the first.

Claim. For any policy decidable at the gate — decidable from the Capability chain and the Exercise alone, identically for every verifier — there is a capability expressing it.

Argument. A decidable gate policy P partitions Exercises into permitted and not; write S_P for the permitted set. The author names the terms P ranges over in a namespace and writes P in a conforming profile; a verifier then evaluates it, and nothing is left over. A counterexample could arise only if this specification restricted the available vocabulary. It does not: vocabulary is namespace-supplied and deliberately out of scope. ∎

Consequence. The model is sound, and complete relative to the supplied vocabulary — relative completeness in the familiar sense, as a program logic is complete relative to the expressiveness of its assertion language. Here the qualifier costs nothing, since the thing completeness is relative to is out of scope by design: anything unexpressible is unexpressed by an author’s choice, never excluded by the framework.