Self-Certifying Identity and Capability-Based Delegation for Autonomous AI Agents

Introduction Agent-to-agent communication is expected to become a major component of the emerging Internet of Agents, where autonomous AI agents discover services, exchange information, and perform tasks on behalf of users and organizations. This evolution raises fundamental challenges in identity management, trust establishment, delegation, authentication, and authorization at a scale potentially exceeding that of today's Internet users. Existing mechanisms based on certificates, federated identity systems, and bearer tokens were primarily designed for human users and service-oriented architectures and do not adequately address the requirements of highly dynamic, autonomous, and short-lived AI agents. In this draft, we present an identity and delegation framework for secure AI agent communications. It relies on the following key entities: AI agents, their providers, and brokers that support discovery and coordination. All entities are identified with self-certifying identifiers derived from public keys, with key material resolved through a distributed, mutable, and integrity-protected store. Building on this foundation, we describe a three-step approach to secure AI agent interaction: i) discovery through indexed metadata describing agent capabilities, ii) establishment of jointly defined credentials enabling authentication and authorization, and iii) a secure communication protocol between AI agents. The framework enables trustworthy, interoperable, and policy-constrained collaboration between autonomous AI agents in open environments. The framework further introduces two complementary protocols. The Delegation and Authorization Protocol (DAP) enables trusted entities to negotiate mission-specific capabilities that define participating agents, permissions, constraints, and operational controls. The Identity and Authentication Protocol (IDAP) uses self-certifying identities, capability validation, proof of possession of cryptographic keys, and ephemeral Diffie-Hellman key exchange to provide authentication, authorization, replay protection, and forward secrecy. Together, these mechanisms establish a foundation for interoperable, auditable, and trustworthy AI agent ecosystems, enabling secure delegation and communication across organizational and administrative boundaries.

Terminology The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this document are to be interpreted as described in and .

Architecture for AI Agent Identities

Identity and Trust A fundamental requirement for secure AI agent communications is a robust notion of identity. At its core, an identity consists of two elements: an identifier and a public key. The identifier provides a stable and globally unique reference to an agent, while the public key enables cryptographic operations such as authentication, signature verification, and secure key establishment. The public key gives the identity its cryptographic verifiability: an agent can prove possession of the corresponding private key, allowing other parties to verify that they are communicating with the intended entity. However, an identifier and a public key alone are insufficient. To make the identity usable, there must be a reliable mechanism for storing and retrieving the binding between the identifier and the public key. Without such a binding, an attacker could substitute a different key and impersonate the agent.

Entities We assume two classes of providers in the agent ecosystem: Client AI Agent Providers and Service AI Agent Providers. A Client AI Agent Provider manages a set of Client AI Agents that act on behalf of users or organizations and may delegate tasks to other agents. Conversely, a Service AI Agent Provider manages Service AI Agents that offer specialized capabilities to external agents. Both types of providers can serve as trust anchors, establishing the identity of the agents they manage and taking responsibility for their operation. In this model, individual AI agents are lightweight entities that possess cryptographic identities and credentials, while the stronger trust relationships are associated with the providers that operate them. Both Client and Service AI Agents are designed to have lightweight identities and to interact autonomously. A Client AI Agent initiating a delegation must present cryptographic evidence that it possesses the necessary authority to request the service. Likewise, a Service AI Agent must verify that the requesting agent holds the appropriate capabilities and delegation rights before executing the requested task. This capability-based model enables fine-grained authorization and controlled delegation while maintaining cryptographic accountability. To facilitate cooperation among independently operated agents, we introduce an additional entity, the Agent Broker. The Agent Broker acts as a trusted intermediary between Client and Service Providers by maintaining an index of AI agent descriptions, capabilities, service endpoints, and trust-related metadata. When a Client AI Agent needs to delegate a task, it first queries the Agent Broker to discover suitable Service AI Agents capable of performing the requested operation. The broker does not necessarily participate in the execution of the task itself; rather, it supports discovery, selection, and trust establishment by providing reliable information about available agents and their providers. In this way, the Agent Broker plays a role analogous to a directory service, while Client Providers and Service Providers remain the primary trust anchors responsible for the identities and behavior of the agents they manage.

Trust Anchors and Naming In an Internet of Agents, a similar model is likely to emerge. AI agents may be associated with Agent Providers or Agent Brokers that act as trusted intermediaries, vouching for the identity, capabilities, or reputation of the agents they host or manage. These entities can serve as recognizable trust anchors for other participants in the ecosystem. Trust is therefore not attached solely to an agent's cryptographic identity, but also to the chain of entities standing behind it. An organization may trust an agent because it trusts its provider, and it may trust the provider because it is associated with a well-known domain or institution. Trust relationships must also support transitivity and reasoning. If entity A trusts entity B, and entity B delegates authority to entity C, then A may decide to trust C under specific conditions. Such trust chains require cryptographic continuity and integrity guarantees at every step. Delegations, endorsements, and attestations must be cryptographically bound to identities so that their authenticity and provenance can be verified. In this model, trust becomes a verifiable graph of relationships rooted in recognized trust anchors and maintained through cryptographically protected delegation chains. Consequently, identity answers the question "Who is this agent?", while trust answers the more difficult question "Why should I believe this agent and accept its actions?". In the proposed framework, AI agent identities are based on identifiers bound to public keys, while trust is rooted in domain names, organizations, Agent Providers, and Agent Brokers that act as trust anchors. This separation allows identity to remain cryptographically verifiable and globally interoperable, while enabling trust to be established, delegated, and reasoned about through accountable and verifiable relationships. The relationship between naming and trust is fundamental in any large-scale digital ecosystem. Trust cannot be established solely from cryptographic identifiers, as humans and organizations reason about trust using meaningful names rather than cryptographic keys. A global namespace provides the bridge between machine-verifiable identities and human-understandable entities. The Domain Name System (DNS) already fulfills this role on today's Internet by providing globally unique and semantically meaningful names that can be associated with organizations, services, and users. In an Internet of Agents, DNS can serve as a unifying namespace for all participants in the ecosystem. Every entity, including Client and Service AI Agents, Agent Providers, and Agent Brokers-, can be identified by a DNS name as its primary identifier. Unlike opaque identifiers or public-key fingerprints, DNS names carry semantic information that can be interpreted by humans and automated systems alike. For example, an agent associated with travel.booking.com immediately conveys more information than a random cryptographic identifier, allowing participants to reason about ownership, responsibility, and organizational affiliation. This semantic meaningfulness is essential for trust reasoning. When evaluating whether an agent should be trusted, a participant may not know the agent directly, but it may recognize and trust the organization controlling the associated domain name. Trust can therefore be derived from a chain of relationships rooted in well-known domains and institutions. An organization may trust a Service AI Agent because it is operated by a recognized Agent Provider, which in turn is associated with a reputable domain. Similarly, Agent Brokers can leverage domain-based identities to establish trust relationships across administrative boundaries. DNS names thus provide the contextual information needed to interpret cryptographic identities and support trust transitivity. Combining DNS-based naming with cryptographic identities yields a powerful model: public keys provide cryptographic verifiability, while DNS names provide semantic context and accountability. DNSSEC can further strengthen this relationship by protecting the integrity of the bindings between names, keys, and delegations. In this way, DNS becomes not only a naming infrastructure but also a foundation for scalable trust establishment, delegation, and discovery in the emerging Internet of Agents.

Trust Relationships To illustrate the relationships between Agents and their Providers, let us consider an example of an AI agent responsible for protecting an organization's infrastructure. Such an Agent may need to perform several tasks, including scanning networks, analyzing threats, mitigating attacks, and monitoring systems. A Client AI Agent Provider could therefore manage agents such as React, Mitigate, and Scan, each specialized in a particular aspect of incident response. When the Scan agent identifies a suspicious condition requiring more advanced analysis, it may decide to delegate part of its mission to an external service. Rather than implementing all capabilities locally, the agent can rely on specialized Service AI Agents managed by a Service AI Agent Provider. In our example, the Service Provider offers agents such as Detect, Analyze, and Monitor, which provide advanced threat detection, forensic analysis, and continuous monitoring services. We can observe that trust is not directly established between individual agents but it is instead rooted in a set of trusted entities and the infrastructure: the Client AI Agent Provider, the Service AI Agent Provider, the Agent Broker, and a Trustful Mutable Store, which acts as a common source of truth for identities, public keys, and metadata. The Agents themselves possess lightweight identities and are not expected to maintain long-term reputations. Instead, trust is derived from the entities that manage, discover, and authenticate them. The first level of trust exists between an AI agent and its provider. Client AI Agents such as React, Mitigate, and Scan trust their Client Provider to establish and maintain their identities, credentials, and delegated authorities. Similarly, Service AI Agents such as Detect, Analyze, and Monitor trust their Agent Provider to manage their identities and publish accurate information about their capabilities. In this sense, both Providers act as Trust Anchors responsible for the Agents operating under their control. A second trust relationship exists between the Providers and the Agent Broker. It maintains an index of agent descriptions, capabilities, and service metadata, allowing agents to discover suitable service providers. Agent Providers trust the Agent Broker to correctly index and publish metadata, while the Agent Broker trusts the Agent Providers as authoritative sources of information about the Agents they manage. This relationship is essential because agent discovery precedes any cooperation or delegation. Alongside agent entities, we introduce the notion of the Trustful Mutable Store. Both Providers interact with this store and trust its integrity and availability. The store provides cryptographic continuity by maintaining the bindings between identifiers, public keys, Agent Providers, and delegations. As a result, identities and trust assertions can be independently verified rather than relying solely on statements made by individual Agents. Initially, there may be no direct trust between these two agents. Trust is established indirectly through a chain of trusted intermediaries. A Client AI Agent may trust a Service AI Agent because it trusts its own Provider, which trusts the Agent Broker and the Trustful Mutable Store, and because the Service AI Agent is vouched for by its Service Provider. This creates a form of trust transitivity in which trust is derived from verifiable relationships among trusted entities rather than from direct prior knowledge of a remote AI Agent. The Service AI Agent performs a symmetrical reasoning process before accepting a delegated task. Consequently, the framework separates identity from trust. Identity is established through cryptographic bindings between identifiers and public keys stored in the Trustful Mutable Store, a highly distributed and available infrastructure that guarantees the integrity of stored information, while trust emerges from a graph of relationships involving Agent Providers, Agent Brokers, and other recognized trust anchors. The resulting trust chain can be verified cryptographically and traced back to accountable organizations, typically identified through DNS domain names, which provide the semantic context necessary for human and machine trust reasoning. Trust extends beyond identity. Knowing an identifier and a public key allows a party to verify who an agent is, but not whether it should be trusted. We therefore define trust as the combination of a name, an identifier, and a public key. Names, provided through a global namespace such as DNS, introduce semantic meaning and organizational context that are absent from cryptographic identifiers alone. They enable agents, organizations, and users to reason about ownership, responsibility, and reputation. Trust can then be anchored in recognized entities associated with these names, such as Agent Providers, Agent Brokers, or other well-known organizations. These trusted entities act as trust anchors and intermediaries, allowing trust to propagate through verifiable delegation chains. As a result, trust becomes a graph of cryptographically protected relationships rooted in globally unique and semantically meaningful names, enabling scalable trust reasoning and cooperation in the Internet of Agents. Figure below illustrates the identity and delegation layer usable by A2A, MCP, ACP, or other agent communication protocols. It presents the entities and their relationships in the framework.

Identifiers and Protocols In this section, we present the details of identifiers and protocols for secure communication between AI Agents.

Self-Certifying Agent Identifiers Assume that an entity generates a pair of keys: public key P and secret key S. We define a SID (Self-Certifying Identifier) as a concatenation of the Context and the Context-dependent Identifier (CI):

where sha256 and ripemd160 are hash functions resulting in 256 and 160 bits, respectively, and base32 is a binary-to-text encoding scheme. The Context represents the algorithm used for the generation of the keys and key sizes (just 1 in example domain names below). The base32 encoding represents a binary string with 0-9 digits and some lower case letters (excluding characters hard to distinguish like i, l, o). The advantage of SID is that a Server AI Agent can trust another Client AI Agent because it can prove the possession of the private key associated with the public key from which SID is derived. Nevertheless, security depends on the trustful binding of the SID and the public key.

Trustful Mutable Store In addition to Self-Certifying Identifiers (SID), the framework requires a trustworthy mechanism for maintaining the binding between an SID and the corresponding public key. While the SID itself can be derived from the public key, agents interacting for the first time must still be able to resolve an identifier into the current public key material and associated metadata. To support this functionality, we introduce a Trustful Mutable Store, responsible for storing and distributing SID-to-public-key bindings. The Trustful Mutable Store must satisfy several fundamental requirements. First, it must be distributed and highly available, as agent communications are expected to occur at Internet scale and cannot depend on a single centralized service. Second, it must provide strong integrity guarantees, ensuring that any public key material or metadata retrieved from the store can be cryptographically verified and has not been tampered with. Third, unlike traditional public-key infrastructures that assume relatively stable identities, AI agent ecosystems are characterized by highly dynamic and often short-lived agents. Consequently, the store must support mutability, allowing key bindings, metadata, and delegation information to be updated efficiently while preserving verifiability and accountability. Several existing systems illustrate different subsets of these properties. Blockchain-based systems such as Bitcoin and Ethereum provide highly distributed, highly available, and integrity-protected storage through consensus mechanisms. However, their data model is fundamentally immutable, making them less suitable for managing rapidly evolving agent identities and delegations. At the other end of the spectrum, DNS combined with DNSSEC offers a globally distributed, highly available, integrity-protected, and inherently mutable infrastructure. DNSSEC protects the authenticity of records through cryptographic signatures while allowing records to be updated as identities and services evolve. Similarly, the InterPlanetary File System (IPFS) provides a distributed and integrity-protected storage substrate. Combined with mutable naming mechanisms such as IPNS, it can support updates while preserving content authenticity. These observations suggest that a Trustful Mutable Store for AI Agents should combine the scalability and availability of Internet-scale distributed systems with cryptographic integrity guarantees and support for controlled updates. Such a store provides the missing link between self-certifying identities and trust establishment by enabling participants to securely resolve identifiers, retrieve public keys, verify delegations, and discover associated metadata. It therefore forms a critical component of the identity infrastructure required for a large-scale Internet of Agents. A Trustful Mutable Store can be realized using different distributed infrastructures, each offering a different balance between naming, integrity, availability, and mutability. Two particularly relevant candidates are DNS and IPFS. DNS provides a globally deployed and operationally proven naming infrastructure that combines distributed administration with hierarchical delegation. Through DNSSEC, it offers integrity protection for records while retaining the ability to update information over time. In this implementation, SID can be represented as domain names or associated with domain names, while public keys, delegation information, and metadata can be stored in DNS records, for example as structured tag=value attributes in TXT records. DNS also naturally supports organizational delegation: Agent Providers can manage their own namespace slices, operate their own authoritative DNS services, and independently create, update, or remove agent identities. This hierarchical model aligns well with the need to manage large numbers of agents and their highly dynamic lifecycles. An alternative approach is provided by IPFS and its naming layer, the InterPlanetary Naming System (IPNS). IPFS stores content under content-derived identifiers (CIDs), the cryptographic hashes of the content itself that provide strong integrity guarantees and high availability through a peer-to-peer network. Because CIDs are immutable, IPNS introduces a mutable naming mechanism in which a name is derived from a public key and resolved through records stored and replicated in a Distributed Hash Table (DHT). An IPNS record can bind an IPNS name to an IPFS CID containing immutable metadata, including public keys, validity periods, purposes, delegation information, and cryptographic signatures. This model naturally supports self-certifying identities, as the name itself is derived from the public key. Consequently, both DNS/DNSSEC and IPFS/IPNS satisfy the core requirements of a Trustful Mutable Store---distribution, availability, integrity protection, and support for updates---while offering different trade-offs between human-readable naming, administrative delegation, and cryptographic self-certification.

Delegation, Authentication, and Authorization Protocols Before a Client AI Agent can delegate a task to a Service AI Agent, their respective Providers must first establish a common authorization framework. This goal can be achieved with the Delegation and Authorization Protocol (DAP), executed between the Client Provider and the Service Provider. DAP results in the creation of a Capability, a cryptographically protected authorization token that specifies the entities participating in the mission, including the Client Provider, Service Provider, Client AI Agent, and Service AI Agent. The Capability also defines the authority granted for the mission, such as permitted actions, roles, quotas, spending limits, validity periods, and auditing requirements, as well as protocol-level controls including nonces, sequence numbers, replay protection, and one-time or repeated use constraints. The Capability is jointly approved, signed by both providers, and ecrypted, ensuring that the delegation is explicitly authorized by the organizations responsible for the participating Agents. Once the Capability has been established, the Client AI Agent can autonomously initiate the delegated task. The agent possesses its own cryptographic identity and presents the Capability as proof of authorization when interacting with the selected Service AI Agent. Authentication and secure communication are performed using the Identity and Authentication Protocol (IDAP), which allows agents to authenticate each other based on their identifiers and public keys while establishing a forward-secure session key. During this process, the Service AI Agent verifies both the identity of the requesting agent and the validity of the Capability before executing the requested operation. This separation of responsibilities allows DAP to govern delegation and authorization at the provider level, while IDAP enables secure and autonomous agent-to-agent communications at the operational level.

Capability We define CAP, an authorization Capability as

where cp and sp identify the Client and Service Providers, ca and sa identify the participating Agents. Other parameters are as follows: authority specifies the permissions and limits (allowed actions, roles, quotas, budgets, time window, audit requirements, etc.) and control defines protocol-level requirements such as replay and usage protections (nonces, sequence numbers, validity periods, one-time or repeated use, auditing obligations, quotas, budgets, and other operational limits. The capability is jointly approved by both providers and is therefore jointly signed using their private keys S_sp,S_cp, thus establishing a cryptographically verifiable agreement on the delegated mission. It is also encrypted with the public key P_sa of the Service Agent:

Overall Architecture The architecture consists of four main entities: a Client Provider, a Service Provider, an Agent Broker, and a Trustful Mutable Store. The Client Provider manages a set of Client AI Agents, with the Client Agent identified as ca. Similarly, the Service Provider manages a set of Service AI Agents and the Service Agent is identified as sa. Each provider and each agent possesses a self-certifying identifier derived from a public key. The bindings between identifiers and public keys (e.g., ca - P_ca, sa - P_sa, cp - P_cp, and sp - P_sp) are stored in the Trustful Mutable Store, which can be implemented using infrastructures such as DNS/DNSSEC or IPFS/IPNS. The store provides globally accessible, integrity-protected, and updatable identity information. To facilitate discovery, both Client and Service AI Agents publish metadata describing their capabilities so that an Agent Broker can gather this information and maintain an index of available services. When a Client AI Agent needs to delegate a task, it first queries the Agent Broker to identify a suitable Service AI Agent. So for example, the Client Agent (ca) can discover through the broker's metadata index the Service Agent (sa) as a suitable executor of a given task. The Agent Broker therefore acts as a discovery service and a trusted intermediary that enables cooperation among independently managed agents. The cooperation of agents requires two protocols: i) DAP (Delegation and Authorization Protocol) for negociating the terms of the mission and creating Capability for further authorization of Agents and ii) IDAP (IDentity and Authentication Protocol) for secure authentication and authorization of the Client Agent based on Capability so the Service Agent can perform a given task. Before performing the task, Client Provider uses DAP to to establish a mission-specific Capability that defines: i) the entities involved in the mission (ca, sa, cp, sp), ii) the authority that specifies conditions and limits of the mission (allowed actions, roles, quotas, budgets, time window, audit requirements, etc.), and iii) control that specifies protocol requirements (nonce, sequence number, one-time or repeated use, etc.). Capability is jointly signed by the secret keys of the Service and Client Providers and encrypted with the public key of the Service Agent. The Client Agent then uses IDAP for authentication and secure connection to the Service Agent. It authenticates itself based on its identifier (ca) and uses ephemeral Diffie-Hellman to create a session key. The Detect Agent checks the Capability signatures by getting the corresponding public keys from the Trustful Mutable Store (e.g., P_ca corresponding to ca). Based on the validated Capability, the target agent accepts the authorized mission and executes the tasks following the terms in Capability (limits, conditions). The capability therefore serves as the authorization artifact for the mission, while IDAP provides secure authentication and key establishment. Together, DAP and IDAP separate authorization from communication security, allowing Agent Providers to define delegation policies while enabling their Agents to interact autonomously and securely.

DAP (Delegation and Authorization Protocol) The Delegation and Authorization Protocol (DAP) is executed between a Client Provider and a Service Provider before any agent-to-agent interaction takes place. Its purpose is to establish a mutually agreed authorization framework governing a delegated mission. Before negotiating a Capability, the Client Provider and the Service Provider first authenticate each other using their identifiers and public keys resolved from the Trustful Mutable Store. Each side proves possession of its private key by signing an ephemeral Diffie-Hellman contribution and the current protocol transcript, which prevents impersonation and binds the negotiation to the authenticated Providers. After authentication, both Providers derive K_dap, a shared session key using ephemeral Diffie-Hellman:

where eph_cp, eph_sp are ephemeral Diffie-Hellman shares of Client and Service Providers, respectively, and KDF is the Key Derivation Function. All subsequent negotiation messages are encrypted and integrity-protected with K_dap, which ensures that the proposed mission, identities of the participating agents, roles, budgets, limits, and operational conditions are not exposed to third parties. The negotiation can then proceed through proposal, counterproposal, acceptance, and finalization messages inside the protected channel. The final output of the protocol is a signed Capability defining the mission:

where authority defines conditions and limits of the mission (allowed actions, roles, quotas, budgets, time window, audit requirements, etc.), and control supports lifecycle management, replay protection, auditing, discovery, and protocol operation: nonce, sequence number, one-time or repeated use. The signed Capabilityis then encrypted with the encryption key P_sa of the Service AI Agent:

It can then be delivered only to authorized parties, for example the Service AI Agent. It must be able to decrypt or unwrap the Capability when IDAP starts, while unauthorized observers cannot learn the mission content. The protocol flow between the Client Provider (CP) and the Service Provider (SP) is as follows: CP -> SP: CP identifier, eph_cp ephemeral DH share, signature with S_cp SP -> CP: SP identifier, eph_sp ephemeral DH share, signature with S_sp CP and SP: verify identities, derive K_dap CP left-> SP: encrypted negotiation of mission, authority, limits, control parameters CP and SP: jointly sign Capability CP/SP: encrypt Capability with P_sa for authorized use CP -> Client Agent: encrypted signed Capability DAP provides the following security properties: mutual authentication between Client Provider and Service Provider, confidential negotiation, because all mission parameters are exchanged under an ephemeral session key, forward secrecy, since K_dap comes from ephemeral Diffie--Hellman, capability confidentiality, because the resulting capability is encrypted, integrity and non-repudiation, because the capability is signed by both Providers, replay protection, through nonces, sequence numbers, timestamps, and expiry, clear delegation chain in which the Client Provider empowers the Client AI Agent and the Service Provider empowers the Service AI Agent.

IDAP (IDentity and Authentication Protocol) The Identity and Authentication Protocol (IDAP) is executed directly between a Client AI Agent and a Service AI Agent once a valid Capability has been established through DAP. Its purpose is to authenticate the participating agents, verify authorization, and establish a secure communication channel. The protocol begins when the Client AI Agent sends the Capability together with an ephemeral Diffie--Hellman public share. To prove possession of its identity, the agent signs the transmitted information using its private key. Upon receiving the request, the Service AI Agent resolves the identifiers contained in the message through the Trustful Mutable Store, retrieves the corresponding public keys, and verifies the signature of the Client AI Agent. The Service AI Agent then validates the Capability, including the identities of the participating entities, the authorization constraints, validity conditions, and the signatures of the Client and Service Providers. If the Capability is valid and the requested mission is authorized, the Service AI Agent accepts the delegation request, generates its own ephemeral Diffie--Hellman share, derives a shared session key, and returns its share signed with its private key. Upon receiving the response, the Client AI Agent resolves the identifier of the Service AI Agent, retrieves its public key from the Trustful Mutable Store, and verifies the signature on the received Diffie--Hellman share. It then derives the same shared session key, completing the mutual authentication and key establishment procedure. At the end of the protocol, both Agents have a cryptographically authenticated and confidential communication channel bound to their identities and to the delegated mission defined by the Capability. CA -> SA: sends [Enc-CAP, ca, sa, g^x, nonce_ca]{S_ca} SA: resolves ca, cp, sp to get their keys, verifies signature, decrypts Enc-CAP, validates CAP SA -> CA: sends [sa, g^y, nonce_sa]{S_sa} CA: resolves sa to get its key, verifies signature Both derive: K_master = KDF[g^xy, hash (transcript)], K_cap_ca = KDF(K_master, "IDAP ca to sa encryption"), K_cap_sa = KDF(K_master, "IDAP sa to ca encryption") IDAP provides several important security properties. First, it mitigates token theft by combining authorization with proof-of-possession: possession of a Capability alone is insufficient, as the requesting agent must also demonstrate control of the private key corresponding to the identity specified in the Capability. Second, replay attacks are prevented through the use of nonces, sequence numbers, timestamps, and validity intervals carried by the Capability and protocol messages. Third, the use of ephemeral Diffie-Hellman key exchange provides forward secrecy, ensuring that compromise of long-term private keys does not enable an attacker to recover past session keys or decrypt previously recorded communications. As a result, IDAP establishes a secure and authenticated communication channel while preserving the delegation and authorization guarantees provided by DAP.

DNS/DNSSEC as the Trustful Mutable Store We propose to use DNS as the Trustful Mutable Store for SID identifiers. DNS has been an operationally viable and highly distributed infrastructure, the cornerstone of the Internet since its origins. It is: scalable, highly available, resilient, and provides trust with the DNSSEC security extension. For SID identifiers, the Trustful Mutable Store is under control of Agents and Providers to keep all public identity data up-to-date. We propose to use the TXT record to store all the identifiers and public keys. The format of the TXT records is based on RFC 6763---it uses DNS TXT records to store arbitrary tag/value pairs conveying additional information about the named service. Each key/value pair is encoded as its own constituent string within the DNS TXT record in the form of tag=value. We use a simple syntax: a number of semi-colon (;) separated tag=value fields like in DKIM, RFC 6376:

First, we can use the well-known name of _agents to list all Agents of a given Agent Provider. So, _agents.openai.com may contain the following SID identifiers:

Then, the description of a given Agent is stored in the TXT record associated with its SID identifier:

An example TXT record for the Agent could be as follows:

This description provides the public key associated with the SID and provides basic metadata of the Detect Agent. It also indicates that more metadata can be found in the following URL:

The resolution of a SID consist of retrieving its corresponding public key. For instance, the resolution of the Detect Agent SID:

will result in the following public key:

that will enable Agent authentication.

IPFS/IPNS as the Trustful Mutable Store The InterPlanetary File System (IPFS) can serve as a Trustful Mutable Store by combining distributed storage, cryptographic integrity, and decentralized name resolution. IPFS is a peer-to-peer storage system in which every object is identified by a Content Identifier (CID) derived from a cryptographic hash of its content. Because the identifier is computed from the content itself, any modification of the content results in a different CID, making stored objects inherently immutable and integrity-protected. Content is distributed across a network of peers, while a Distributed Hash Table (DHT) maps CIDs to the peers currently storing the corresponding content objects. This architecture provides high availability and resilience without relying on a centralized infrastructure. While immutable content is desirable for integrity, identity systems require the ability to update keys and metadata over time. IPFS addresses this requirement through the InterPlanetary Naming System (IPNS), which introduces a mutable naming layer above immutable IPFS content. An IPNS name is derived from a public key, typically as a hash of the public key itself, creating a self-certifying identifier. The corresponding IPNS record is stored in the DHT and contains a reference to an IPFS CID holding immutable metadata. The record also includes the public key, validity information, purpose, binding signatures, sequence numbers, expiration times, and a signature generated with the corresponding private key. Updates are performed by publishing a new IPNS record with an increased sequence number and a new CID, while preserving cryptographic verifiability. In the proposed framework, an SID can be represented as an IPNS name, we call them in this case IID, IPFS IDentifiers. Resolving an IID yields an IPNS record that points to immutable metadata stored in IPFS. This metadata can contain public keys, capabilities, delegations, service descriptions, and other trust-related information. The integrity of the information is guaranteed at two levels: the CID ensures that the content itself has not been modified, while the IPNS signature ensures that updates originate from the legitimate owner of the identifier. As a result, the IPFS/IPNS combination provides a distributed, highly available, integrity-protected, and mutable infrastructure that naturally supports self-certifying identities and can therefore serve as a Trustful Mutable Store for AI Agents.

IID - IPFS IDentifiers In the IPFS-based implementation of the Trustful Mutable Store, each entity generates public key P and secret key S. The entity identifier, called the IPFS Identifier (IID), is directly derived from the public key and therefore constitutes a self-certifying identifier. Formally, the IID is constructed as:

where sha256 and ripemd160 are hash functions resulting in 256 and 160 bits, respectively, and base32 is a binary-to-text encoding scheme. For example, public key P:

results in the following IID:

The IID serves as a stable, self-certifying identifier whose ownership can be verified by demonstrating possession of secret key S. To associate metadata with the identifier, the entity creates a metadata object containing its public key and descriptive information:

The metadata object is signed using secret key S and stored in IPFS, producing an immutable IPFS Content Identifier (metadata-CID):

IID--Public Key Binding through IPNS In the IPFS-based identity framework, the binding between an IPFS Identifier (IID) and the corresponding public key is established indirectly through an IPNS record. The IID itself is an IPNS name derived from the entity's public key and serves as the stable identifier of the entity. The public key and additional metadata are stored in an immutable IPFS object, while the IPNS record provides the mutable binding between the identifier and the current metadata object. The metadata object stored in IPFS contains the entity's public key and associated metadata. Since the object is stored in IPFS, its CID is derived from its content and therefore guarantees integrity. The relationship between the IID and the metadata object is maintained through an IPNS record stored in the Distributed Hash Table (DHT). We can observe that IID is self-certifying: the identifier itself is cryptographically bound to the public key, while IPNS provides mutability and IPFS provides integrity-protected storage of metadata. Updates to metadata are performed by publishing a new IPFS object and updating the corresponding IPNS record, preserving both authenticity and continuity of the identifier. Let us consider the following example: /ipns/bafzbeia... is an IID and the /ipfs/wxdmyaqr... is the IPFS CID of the metadata object. Thus, their binding is represented in the following IPNS record stored in DHT:

The record is signed with secret key S corresponding to the public key associated with the IID. It contains the mapping:

together with management information such as a sequence number, expiration time, and a digital signature generated with secret key S. The sequence number enables updates of the binding over time, while the expiration time limits the validity period of the record. Because the record is signed by the owner of the identifier, only the holder of secret key S can modify the association between the IID and the metadata object. When another entity wants to resolve the /ipns/bafzbeia... IID, it retrieves the corresponding IPNS record from the DHT, verifies the signature, and obtains the CID of the metadata object. The metadata object is then fetched from IPFS and its integrity is verified through the CID. Public key P contained in the metadata can subsequently be used to verify signatures generated by the entity. In this way, we have a complete chain of trust: P -> IID -> /ipns/bafzbeia... -> /ipfs/wxdmyaqr..., where: IID is a stable identifier, IPNS provides a mutable and signed binding, IPFS provides immutable and integrity-protected storage, and secret key S establishes ownership and control of the entire identity. This scheme for IIDs provides several important properties. First, it establishes a cryptographically verifiable binding between the IID and the public key contained in the metadata object. Second, it supports mutability: if the entity updates its metadata, a new IPFS object is created and a new IPNS record is published with an incremented sequence number and a new CID. Third, the expiration field prevents the use of stale bindings and enables key rotation or identity revocation. Finally, because IPNS records are signed by the identifier owner, only the legitimate holder of the secret key can modify the IID--metadata association. Consequently, the IPNS record acts as the equivalent of a directory entry in the Trustful Mutable Store, binding an IID to the current public key and metadata while preserving the integrity, availability, and update capabilities required by large-scale AI Agent ecosystems.

Trust Binding in IPNS While self-certifying identifiers provide a cryptographic binding between an IID and a public key, they do not by themselves establish trust. A natural way to associate trust with an IID in the IPFS/IPNS framework is through signed metadata objects. The metadata object referenced by the IPNS record contains the public key corresponding to the IID, descriptive information about the entity, and a signature generated with the associated secret key. In the previous example, the signature of the metadata object:

was done with secret key S corresponding to public key P of the IID:

However, it can also by done by another entity, e.g., an Agent Provider, or a trust anchor, with its public key:

The signature proves that the holder of the secret key corresponding to the public key approves the metadata and controls the associated IID. This mechanism establishes authenticity and integrity, allowing any participant to verify that the metadata originates from the owner of the identifier. However, authenticity alone does not imply trust. To enable trust establishment, the metadata object can be additionally signed by another trusted entity, such as an Agent Provider, Agent Broker, certification authority, or other recognized trust anchor. In this case, the metadata becomes a form of cryptographic attestation stating that the trusted entity has verified certain properties of the agent and is willing to associate its reputation with it. The resulting structure may contain one or more endorsements:

The trust associated with the IID is then derived not only from the self-certifying relationship between the identifier and the public key, but also from the entities that endorse the metadata. A relying party may not know the agent directly, yet it may trust the Agent Provider that manages the agent or the Agent Broker that validated its capabilities. Trust reasoning therefore becomes a matter of evaluating chains of cryptographically verifiable attestations. If an organization trusts a particular Agent Provider, it can extend a corresponding level of trust to agents whose metadata has been endorsed by that provider. This approach preserves the decentralized nature of IPFS and IPNS while introducing a flexible trust layer. The IID remains self-certifying and independent of any central authority, whereas trust is expressed through signed endorsements attached to the metadata. As a result, identity and trust remain distinct concepts: the IID and public key establish who the entity is, while third-party signatures provide evidence of why the entity should be trusted. An alternative approach to establishing trust for IPFS-based identifiers is to leverage the existing DNS and DNSSEC infrastructure. In this approach, an Agent Provider publishes the association between an IID and its corresponding public key within a DNSSEC-protected domain under its administrative control. For example, if the Agent Provider controls the domain openai.com, it can create a DNS record such as:

The DNS name acts as a trust anchor linking the Agent Provider's domain to the IID. Because the DNS record is protected by DNSSEC, any party can verify its authenticity and integrity through the DNSSEC chain of trust. The resulting trust relationship can be expressed as:

Domain Name -> IID ]]> In other words, an entity may trust the IID not because it directly knows the agent, but because it trusts the organization controlling the DNS domain that publishes the binding. The DNSSEC signatures provide cryptographic evidence that the IID--public-key association has indeed been published by the domain owner. This approach naturally complements the IPFS/IPNS identity model. The IID remains a self-certifying identifier derived from a public key and resolved through IPNS, while DNSSEC provides an independent trust layer that associates the IID with a recognizable organization. The corresponding IPFS metadata object can continue to store descriptive information about the agent, such as capabilities, supported protocols, service endpoints, and indexing information used by Agent Brokers. DNS therefore provides organizational trust and accountability, whereas IPFS provides decentralized storage and discovery metadata. Combining the two mechanisms yields a particularly attractive model for an Internet of Agents. IPFS/IPNS provides decentralized, globally resolvable, and self-certifying identities, while DNSSEC anchors those identities in a namespace that is globally unique, semantically meaningful, and already associated with real-world organizations. This allows relying parties to perform both cryptographic verification and trust reasoning: the IID proves control of a public key, while the DNSSEC-protected domain identifies the organization that stands behind the agent. Consequently, trust can be established through well-known Agent Providers and their domains without sacrificing the decentralized properties of the underlying IPFS-based identity infrastructure.

Relationship to Agent Communication Protocols This draft does not define a new agent communication protocol. Instead, it provides an identity, authentication, authorization, and delegation framework that can be used by existing and future agent communication protocols. Recent efforts in the AI agent ecosystem, including Agent-to-Agent (A2A), Model Context Protocol (MCP), and other emerging agent communication frameworks, primarily focus on message exchange, service discovery, task execution, and interaction patterns among autonomous agents. While such protocols define how agents communicate, they generally assume the existence of mechanisms that allow agents to identify themselves, authenticate their peers, establish trust relationships, and determine the scope of actions that an agent is authorized to perform. This document addresses these concerns by defining: self-certifying agent identifiers derived from cryptographic public keys, two mechanisms for publishing agent identities and distributing agent metadata: DNS/DNSSEC and IPNS/IPFS, capability-based authorization tokens that support fine-grained delegation, verifiable delegation chains that allow an agent to act on behalf of another entity. The framework is transport-independent and AI agent protocol-independent. It can be used with HTTP-based, message-based, or future agent communication protocols without modifying the protocol semantics. In particular, the framework supports several capabilities that are commonly required by autonomous agents: establishment of persistent and globally unique agent identities, cryptographic authentication of communicating agents, discovery of agent metadata and public keys, delegation of authority between users and agents, and among cooperating agents, verification of authorization decisions across administrative domains, auditable proof of delegated authority. The framework therefore complements agent communication protocols by providing a common trust and authorization layer. Agent communication protocols define how messages are exchanged, whereas this draft defines how communicating parties establish identity, trust, and delegated authority. The mechanisms specified in this document may be used by agent communication protocols to support secure multi-agent interactions, cross-domain delegation, agent marketplaces, service brokers, and autonomous task execution on behalf of users or organizations.

Agent Discovery and Metadata Publication Autonomous agents require mechanisms to discover peer agents, obtain their metadata, validate their identities, and retrieve information necessary to establish secure communications. Existing agent communication frameworks frequently rely on proprietary registries, centralized directories, agent cards, or application-specific discovery mechanisms. This draft defines a decentralized mechanism for agent discovery and metadata publication based on DNS/DNSSEC and IPNS/IPFS. Agent discovery is performed through the following sequence:

The DNSSEC-signed identity record binds an agent identifier to metadata required for communication and authorization. Such metadata may include: public keys, supported communication protocols, service endpoints, capability requirements, delegation policies, trust anchors, references to additional metadata objects. The metadata object MAY contain similar information to agent cards used by existing agent ecosystems, including supported protocols or services, authentication requirements, semantic descriptions, and policy information. DNSSEC provides origin authentication and integrity protection for the binding between the Agent Identifier and the metadata pointer. IPFS provides content integrity through content-addressed storage, while IPNS enables controlled updates to metadata without requiring changes to the agent identity. The approach based on DNS/DNSSEC or IPNS/IPFS enables decentralized agent discovery without requiring centralized registries or proprietary directory services. The mechanism is independent of the communication protocol used by the agent and can support MCP, A2A, ACP, AGNTCY, and future agent communication protocols. The framework does not mandate a specific metadata schema. Agent ecosystems may define protocol-specific metadata formats while reusing the identity, publication, and discovery mechanisms defined in this document. The figure below illustrates the process of agent discovery.

Public Keys +--> Endpoints +--> Policies +--> Agent Card ]]>

Conclusion In this draft, we have presented an identity and delegation framework for secure AI agent communications based on the separation of identity, trust, authentication, and authorization. At the foundation of the architecture lies the notion of a cryptographically verifiable identity defined as an Identifier--Public Key pair. Identifiers may take the form of DNS-based Self-certifying Identifiers (SIDs) or IPFS-based Identifiers (IIDs), both derived from public keys and therefore constituting a particular class of decentralized identifiers. The bindings between identifiers and public keys are maintained in a Trustful Mutable Store, which provides distribution, availability, integrity protection, and support for updates. We have shown that both DNS/DNSSEC and IPFS/IPNS provide suitable realizations of such a store, offering complementary trade-offs between hierarchical naming, organizational delegation, and decentralized self-certification. The framework further distinguishes identity from trust. While identifiers and public keys enable cryptographic authentication, trust requires additional context that allows participants to reason about the entities behind the identities. We therefore define trust as the combination of a Name, an Identifier, and a Public Key. DNS plays a central role as a globally unique and semantically meaningful namespace that links cryptographic identities to recognizable organizations. Trust is anchored in accountable entities such as AI Agent Providers and Agent Brokers, which act as trust anchors and intermediaries. Through signed attestations, DNSSEC-protected bindings, and verifiable metadata, trust can be propagated across organizational boundaries while preserving cryptographic continuity and accountability. To support secure cooperation among autonomous agents, we introduce two complementary protocols. The Delegation and Authorization Protocol (DAP) enables trusted entities to negotiate and establish a cryptographically protected Capability defining the participants, permissions, constraints, and operational controls associated with a mission. In many respects, a Capability plays a role similar to a Verifiable Credential, but it is specifically designed to express delegation and authorization relationships between agents and their providers. The Identity and Authentication Protocol (IDAP) then allows agents to authenticate one another, validate capabilities, and establish forward-secure communication channels based on proof of possession of cryptographic keys. Rather than defining a new agent communication protocol, the framework provides a common trust layer that can be used by existing and emerging agent ecosystems, including MCP, A2A, AGNTCY, and future agent communication protocols. The framework combines self-certifying agent identifiers, DNSSEC-protected identity records, and IPNS/IPFS-based metadata publication to enable decentralized agent discovery and verifiable identity management without relying on centralized registries. In addition, capability-based authorization and delegation mechanisms allow agents to securely act on behalf of users or other agents while providing cryptographic proof of authority. Together, these mechanisms establish a foundation for secure, interoperable, and scalable multi-agent systems operating across administrative and organizational boundaries.

Security Considerations The security of this framework relies on the authenticity and integrity of cryptographic public keys, DNSSEC-signed identity records, capability tokens, and content-addressed objects stored in IPFS.

Trust Anchors The framework assumes that DNSSEC validation is performed correctly and that validating parties possess an authentic DNSSEC trust anchor. Compromise of DNSSEC signing keys can allow an attacker to publish fraudulent identity records, delegation policies, or capability metadata. The framework also relies on the collision resistance of the hash functions used to derive self-certifying identifiers and content identifiers. A successful collision attack could enable identifier impersonation or substitution attacks.

Agent Key Compromise Compromise of an agent's private key allows an attacker to impersonate the agent and to authenticate protocol messages as that agent. A compromised key may also be used to issue fraudulent capability delegations, impersonate service providers, or authorize malicious actions. Implementations SHOULD support key rotation and SHOULD provide mechanisms for revoking compromised credentials and capabilities. Short-lived capability tokens reduce the impact of key compromise.

DNS-Based Attacks The framework uses DNS to publish identity bindings, policy information, and delegation metadata. Attackers may attempt DNS spoofing, cache poisoning, or record manipulation attacks. DNSSEC validation mitigates such attacks by providing origin authentication and data integrity. Availability attacks against authoritative DNS servers remain possible. Operators SHOULD deploy redundant authoritative name servers and SHOULD use standard DNS operational practices to improve resilience.

IPFS and IPNS Attacks IPFS provides content integrity through content-addressed identifiers. An attacker cannot modify stored content without changing its content identifier. However, attackers may attempt content withholding, eclipse attacks, routing manipulation, or denial-of-service attacks against IPFS infrastructure. Implementations SHOULD verify all retrieved content using the expected content identifier and SHOULD reject content that fails verification. IPNS records MUST be validated using the corresponding public key before use.

Capability Abuse Capability tokens grant specific permissions to agents. Theft or disclosure of a valid capability token may enable unauthorized actions. Capability tokens SHOULD be bound to the public key of the authorized holder and SHOULD require proof-of-possession during protocol execution. Capability tokens SHOULD include expiration times, audience restrictions, and policy constraints.

Replay Attacks An attacker may attempt to replay previously observed protocol messages, capability assertions, or delegation records. Implementations SHOULD include nonces, timestamps, sequence numbers, or challenge-response mechanisms to detect and reject replayed messages. Capability tokens SHOULD have limited validity periods.

Delegation Chains Long delegation chains increase verification complexity and expand the attack surface. Implementations SHOULD impose limits on delegation depth and SHOULD detect delegation loops. Each delegation step MUST be cryptographically verified before authorization decisions are made.

Privacy Considerations Publishing identity records, delegation relationships, or capability metadata in DNS may reveal operational relationships between agents. Operators SHOULD minimize publicly exposed metadata and SHOULD avoid publishing sensitive policy information unless necessary. Where privacy requirements exist, encrypted capability payloads and privacy-preserving credential mechanisms MAY be employed.

Denial-of-Service Attacks Attackers may attempt to exhaust computational resources by triggering repeated DNS lookups, IPFS retrievals, signature verifications, or delegation-chain validation. Implementations SHOULD employ caching, rate limiting, validation timeouts, and resource consumption limits.

Cryptographic Agility The framework SHOULD support replacement of cryptographic algorithms used for signatures, hashing, identifier derivation, and capability protection. Implementations SHOULD be designed to permit migration to new algorithms, including post-quantum cryptographic algorithms, without requiring redesign of the protocol architecture.

IANA Considerations This document has no IANA actions.