Self-Certifying Identity and Capability-Based Delegation for Autonomous AI Agents
draft-duda-agent-id-framework-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Andrzej Duda , Maciej Korczynski , Hureau Olivier , Simon Fernandez , zhang jun , Houda Labiod | ||
| Last updated | 2026-06-26 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-duda-agent-id-framework-00
Internet Engineering Task Force A. Duda
Internet-Draft M. Korczynski
Intended status: Informational O. Hureau
Expires: 28 December 2026 S. Fernandez
Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
J. Zhang
H. Labiod
Huawei Technologies France S.A.S.U.
26 June 2026
Self-Certifying Identity and Capability-Based Delegation for Autonomous
AI Agents
draft-duda-agent-id-framework-00
Abstract
We present an identity and delegation framework for secure AI agent
communications. The framework introduces a set of entities including
Client AI Agents, Service AI Agents, Agent Providers, and Agent
Brokers, together with a Trustful Mutable Store responsible for
maintaining cryptographically verifiable identity bindings. We
propose self-certifying identifiers derived from public keys,
realized as DNS-based Self-certifying Identifiers (SIDs) and IPFS-
based Identifiers (IIDs), which provide lightweight decentralized
identities for agents. To support trust establishment, we
distinguish identity from trust and introduce a model that combines
globally meaningful names, cryptographic identities, and trusted
intermediaries such as Agent Providers and Agent Brokers. We show
how DNS/DNSSEC and IPFS/IPNS can be used as distributed, highly
available, integrity-protected, and mutable infrastructures for
managing AI agent identities and trust metadata.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Duda, et al. Expires 28 December 2026 [Page 1]
Internet-Draft MyDraft June 2026
This Internet-Draft will expire on 28 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture for AI Agent Identities . . . . . . . . . . . . 4
3.1. Identity and Trust . . . . . . . . . . . . . . . . . . . 4
3.2. Entities . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Trust Anchors and Naming . . . . . . . . . . . . . . . . 5
3.4. Trust Relationships . . . . . . . . . . . . . . . . . . . 7
4. Identifiers and Protocols . . . . . . . . . . . . . . . . . . 10
4.1. Self-Certifying Agent Identifiers . . . . . . . . . . . . 10
4.2. Trustful Mutable Store . . . . . . . . . . . . . . . . . 10
4.3. Delegation, Authentication, and Authorization
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Capability . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Overall Architecture . . . . . . . . . . . . . . . . . . 14
5. DAP (Delegation and Authorization Protocol) . . . . . . . . . 15
6. IDAP (IDentity and Authentication Protocol) . . . . . . . . . 17
7. DNS/DNSSEC as the Trustful Mutable Store . . . . . . . . . . 18
8. IPFS/IPNS as the Trustful Mutable Store . . . . . . . . . . . 20
8.1. IID - IPFS IDentifiers . . . . . . . . . . . . . . . . . 21
8.2. IID--Public Key Binding through IPNS . . . . . . . . . . 22
8.3. Trust Binding in IPNS . . . . . . . . . . . . . . . . . . 23
9. Relationship to Agent Communication Protocols . . . . . . . . 26
10. Agent Discovery and Metadata Publication . . . . . . . . . . 27
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12.1. Trust Anchors . . . . . . . . . . . . . . . . . . . . . 31
12.2. Agent Key Compromise . . . . . . . . . . . . . . . . . . 31
12.3. DNS-Based Attacks . . . . . . . . . . . . . . . . . . . 31
12.4. IPFS and IPNS Attacks . . . . . . . . . . . . . . . . . 32
12.5. Capability Abuse . . . . . . . . . . . . . . . . . . . . 32
Duda, et al. Expires 28 December 2026 [Page 2]
Internet-Draft MyDraft June 2026
12.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 32
12.7. Delegation Chains . . . . . . . . . . . . . . . . . . . 32
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 33
12.9. Denial-of-Service Attacks . . . . . . . . . . . . . . . 33
12.10. Cryptographic Agility . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
14. Normative References . . . . . . . . . . . . . . . . . . . . 33
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. 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.
Duda, et al. Expires 28 December 2026 [Page 3]
Internet-Draft MyDraft June 2026
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.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this
document are to be interpreted as described in [RFC2119] and
[RFC8174].
3. Architecture for AI Agent Identities
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.
Duda, et al. Expires 28 December 2026 [Page 4]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 5]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 6]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 7]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 8]
Internet-Draft MyDraft June 2026
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 | | | | |
+------------------+ +------------------+ +------------------+
Duda, et al. Expires 28 December 2026 [Page 9]
Internet-Draft MyDraft June 2026
4. Identifiers and Protocols
In this section, we present the details of identifiers and protocols
for secure communication between AI Agents.
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,
Duda, et al. Expires 28 December 2026 [Page 10]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 11]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 12]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 13]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 14]
Internet-Draft MyDraft June 2026
(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.
5. 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:
K_dap = KDF[DH(eph_cp, eph_sp), transcript],
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:
CAP = [sp, cp, ca, sa, authority, control],
Duda, et al. Expires 28 December 2026 [Page 15]
Internet-Draft MyDraft June 2026
Sig-CAP = [CAP]{S_sp,S_cp}
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:
Enc-CAP = [Sig-CAP]P_sa
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:
1. CP -> SP: CP identifier, eph_cp ephemeral DH share, signature
with S_cp
2. SP -> CP: SP identifier, eph_sp ephemeral DH share, signature
with S_sp
3. CP and SP: verify identities, derive K_dap
4. CP left-> SP: encrypted negotiation of mission, authority,
limits, control parameters
5. CP and SP: jointly sign Capability
6. CP/SP: encrypt Capability with P_sa for authorized use
7. 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,
Duda, et al. Expires 28 December 2026 [Page 16]
Internet-Draft MyDraft June 2026
* 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.
6. 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.
1. CA -> SA: sends [Enc-CAP, ca, sa, g^x, nonce_ca]{S_ca}
2. SA: resolves *ca*, *cp*, *sp* to get their keys, verifies
signature, decrypts Enc-CAP, validates CAP
Duda, et al. Expires 28 December 2026 [Page 17]
Internet-Draft MyDraft June 2026
3. SA -> CA: sends [sa, g^y, nonce_sa]{S_sa}
4. CA: resolves *sa* to get its key, verifies signature
5. 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.
7. 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:
tag-list = tag-spec *( ";" tag-spec ) ";" .
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:
Duda, et al. Expires 28 December 2026 [Page 18]
Internet-Draft MyDraft June 2026
_agents TXT "sid=1exq5yqbl6l48pf0fu7juhltjkrbu2rxf";
"sid=1g43wxdm35yxtjyuje72j64esenyneplk";
"sid=1svmtrshch3g43wxdm35yxtjyuje7g43w";
"sid=16ed71b37dc5e69c5124fe93ee12446e1";
Then, the description of a given Agent is stored in the *TXT* record
associated with its SID identifier:
1exq5yqbl6l48pf0fu7juhltjkrbu2rxf.openai.com.
An example *TXT* record for the Agent could be as follows:
1exq5yqbl6l48pf0fu7juhltjkrbu2rxf.openai.com.
1exq5yqbl6l48pf0fu7juhltjkrbu2rxf TXT
"sid=1exq5yqbl6l48pf0fu7juhltjkrbu2rxf";
"key=1caac9c64711f66e6ed71b37dc5e69c5124fe93ee12446e1a47ad4b650dd861d";
"proto="MCP";
"name="Detect";
"desc="Analyzes scanned data and detects malicious URLs";
"in-type="txt";
"out-type="JSON/MISP";
"meta="http://openai.com/_agents/1exq5yqbl6l48pf0fu7juhltjkrbu2rxf";
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:
http://openai.com/_agents/1exq5yqbl6l48pf0fu7juhltjkrbu2rxf
The resolution of a SID consist of retrieving its corresponding
public key. For instance, the resolution of the Detect Agent SID:
1exq5yqbl6l48pf0fu7juhltjkrbu2rxf
will result in the following public key:
1caac9c64711f66e6ed71b37dc5e69c5124fe93ee12446e1a47ad4b650dd861d
that will enable Agent authentication.
Duda, et al. Expires 28 December 2026 [Page 19]
Internet-Draft MyDraft June 2026
8. 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.
Duda, et al. Expires 28 December 2026 [Page 20]
Internet-Draft MyDraft June 2026
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...
Duda, et al. Expires 28 December 2026 [Page 21]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 22]
Internet-Draft MyDraft June 2026
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...
Duda, et al. Expires 28 December 2026 [Page 23]
Internet-Draft MyDraft June 2026
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(...)
}
Duda, et al. Expires 28 December 2026 [Page 24]
Internet-Draft MyDraft June 2026
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
Duda, et al. Expires 28 December 2026 [Page 25]
Internet-Draft MyDraft June 2026
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.
9. 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,
Duda, et al. Expires 28 December 2026 [Page 26]
Internet-Draft MyDraft June 2026
* 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.
10. 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:
Duda, et al. Expires 28 December 2026 [Page 27]
Internet-Draft MyDraft June 2026
Agent Identifier (SID or IID)
|
v
DNSSEC-signed Identity Record
|
v
Agent Metadata Pointer
|
v
IPNS Name
|
v
IPFS Metadata Document
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.
Duda, et al. Expires 28 December 2026 [Page 28]
Internet-Draft MyDraft June 2026
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.
+----------------------+
| Agent Identifier |
+----------------------+
|
v
+------------------+
| DNSSEC Record |
+------------------+
|
v
+------------------+
| IPNS Pointer |
+------------------+
|
v
+------------------+
| Agent Metadata |
| (IPFS Object) |
+------------------+
|
+--> Public Keys
+--> Endpoints
+--> Policies
+--> Agent Card
11. 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
Duda, et al. Expires 28 December 2026 [Page 29]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 30]
Internet-Draft MyDraft June 2026
12. 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.
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.
Duda, et al. Expires 28 December 2026 [Page 31]
Internet-Draft MyDraft June 2026
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.
Duda, et al. Expires 28 December 2026 [Page 32]
Internet-Draft MyDraft June 2026
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.
13. IANA Considerations
This document has no IANA actions.
14. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Duda, et al. Expires 28 December 2026 [Page 33]
Internet-Draft MyDraft June 2026
Appendix A. References
Authors' Addresses
Andrzej Duda
Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
Email: andrzej.duda@univ-grenoble-alpes.fr
Maciej Korczynski
Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
Email: Maciej.Korczynski@univ-grenoble-alpes.fr
Olivier Hureau
Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
Email: Olivier.Hureau@univ-grenoble-alpes.fr
Simon Fernandez
Univ. Grenoble Alpes, CNRS, Grenoble INP, LIG
Email: Simon.Fernandez@univ-grenoble-alpes.fr
Jun Zhang
Huawei Technologies France S.A.S.U.
Email: junzhang1@huawei.com
Houda Labiod
Huawei Technologies France S.A.S.U.
Email: houda.labiod@huawei.com
Duda, et al. Expires 28 December 2026 [Page 34]