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

3.1. 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.¶

3.2. 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.¶

3.3. 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.¶

3.4. 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.¶

+------------------+
| agent metadata   |           +-------------------------+
| identities-keys  |-----------|     AI Agent Providers  |
+------------------+           +-------------------------+
         |                        |                   |
         | identity binding       | Capability        | Capability
         | public keys            |                   |
         v                        v                   v
+------------------+      +------------------+      +------------------+
| Trustful Mutable |      |     Client       |      |     Service      |
|       Store      |<---->|                  |----->|                  |
| identities-keys  |      |     AI Agent     | task |     AI Agent     |
|     metadata     |      |                  |      |                  |
+------------------+      +------------------+      +------------------+

4.1. 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):¶

SID = Context || CI,

CI = base32(ripemd160(sha256(P))),

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.¶

4.2. 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.¶

4.3. 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.¶

4.4. Capability

We define CAP, an authorization Capability as¶

CAP = [sp, cp, ca, sa, authority, control],

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:¶

Enc-CAP =  {[CAP]S_sp,S_cp}P_sa

4.5. 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.¶

8.1. 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:¶

IID = Context || CI,

CI = base32(ripemd160(sha256(P))),

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:¶

1caac9c64711f66e6ed...

results in the following IID:¶

/ipns/bafzbeia...

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:¶

{
  public_key: 1caac9c64711f66e6ed...,
  metadata: {
      name: "Detect",
      proto: "MCP"
      ...
  },
  signature: g43wxdm35yxtjyuje72...
}

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

/ipfs/wxdmyaqr...

8.2. 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:¶

{
  name: /ipns/bafzbeia...
  value: /ipfs/wxdmyaqr...
  sequence number: 42
  expiry: 1/7/2026
  signature: 6ed71b37dc5e69c51...
}

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

name:  /ipns/bafzbeia...
value: /ipfs/wxdmyaqr...

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.¶

8.3. 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:¶

/ipfs/wxdmyaqr...

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

{
  public_key: 1caac9c64711f66e6ed...,
  metadata: {
      name: "Detect",
      proto: "MCP"
  },
  signature: g43wxdm35yxtjyuje72...
}

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

{
  public_key: 1caac9c64711f66e6ed...,
  metadata: {
      name: "Detect",
      proto: "MCP"
  },
  signature: dc5e69c5124fe93au75...
}

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:¶

{
  public_key: P,
  metadata: {
      name: "Detect",
      proto: "MCP"
  },
  owner_signature: Sig_Sa(...),
  provider_signature: Sig_Sp(...),
  broker_signature: Sig_Sb(...)
}

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:¶

bafzbeia....openai.com. IN TXT
   "iid=bafzbeia..."
   "key=1caac9c64711f66e6ed..."

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:¶

Agent Provider -> 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.¶

12.1. 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.¶

12.2. 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.¶

12.3. 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.¶

12.4. 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.¶

12.5. 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.¶

12.6. 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.¶

12.7. 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.¶

12.8. 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.¶

12.9. 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.¶

12.10. 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.¶