Internet Agent Communication Protocol - EID
draft-gebauer-iacp-eid-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) | |
|---|---|---|---|
| Author | Leonard Gebauer | ||
| Last updated | 2026-07-28 | ||
| 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-gebauer-iacp-eid-00
Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 28 July 2026
Expires: 29 January 2027
Internet Agent Communication Protocol - EID
draft-gebauer-iacp-eid-00
Abstract
Ever since 1969 and the ARPANET, the internet has repeatedly been
faced with challenges that it has had to overcome—and has overcome.
Year after year, the number of users has grown, and year after year,
the complexity and range of ways in which the internet can be used
have expanded. With the advent of AI, we not only have a new type of
user, we have a different form of communication; the internet itself
is being attributed a completely different significance. If they are
not already, AIs will make up the majority of internet users in the
foreseeable future. The question of an ‘AgentNet,’ is not merely a
question concerning the internet; it is a question of how AIs will
interact within a global network in the future.
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."
This Internet-Draft will expire on 29 January 2027.
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.
Gebauer Expires 29 January 2027 [Page 1]
Internet-Draft IACP - EID July 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Ephemeral Agent Identity (EID) . . . . . . . . . . . . . . . 3
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. EID Generation and Properties . . . . . . . . . . . . . . 4
2.3. Identity-Locator Separation Principles . . . . . . . . . 4
2.4. EID Persistence and Rotation Rules . . . . . . . . . . . 5
2.5. Forwarding Tickets and DHT-based Asynchronous
Resolution . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. EID Reputation and Cryptographic Ledger Attestation . . . 7
2.6.1. Cryptographic Attestation and Metrics . . . . . . . . 7
2.6.2. Threshold Enforcement and Session Downgrade . . . . . 8
2.7. Cross-Domain Identity Federation . . . . . . . . . . . . 8
2.7.1. Trust Anchor Document . . . . . . . . . . . . . . . . 8
2.7.2. Federation Protocol Flow . . . . . . . . . . . . . . 9
2.7.3. Federation Gateway Mode . . . . . . . . . . . . . . . 10
2.7.4. Trust Domain Curator Roles . . . . . . . . . . . . . 11
2.7.5. Trust Anchor Rotation and Revocation . . . . . . . . 11
2.7.6. Privacy Considerations for Federation . . . . . . . . 11
2.7.7. New Message Types for Federation . . . . . . . . . . 12
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Normative References . . . . . . . . . . . . . . . . . . 12
3.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
This document is merely a sub-I-D of the main I-D. For appendices,
acknowledgments, Security Considerations, IANA Considerations and
other information, please refer to the main I-D. This sub-I-D
contains only a 1:1 copy of the chapter it covers, to provide a
better basis for discussion.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Gebauer Expires 29 January 2027 [Page 2]
Internet-Draft IACP - EID July 2026
2. Ephemeral Agent Identity (EID)
2.1. General
To interact with the underlying network infrastructure, the Internet
Agent Communication Protocol (IACP) enforces a strict identity-
locator separation based on the core architectural principles of the
Host Identity Protocol (HIP, RFC 7401). Traditional internet
architectures conflate identity and location within a single IP
address layer, creating significant vulnerabilities and
inefficiencies for autonomous multi-agent workflows.
IACP addresses this structural flaw by decoupling an agent's
persistent logical identity from its volatile physical routing state.
An agent utilizes its current, transient IP address solely as an
ephemeral transport locator. This locator is bound via cryptographic
primitives to a unique, self-certifying pseudonym known as the
Ephemeral Agent Identity (EID).
+------------------------------------------------------------------+
| Application / LLM Context |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Ephemeral Agent Identity (EID) Layer |
| [Cryptographic permanence / Stable Identity] |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Transport Locator Layer |
| [Volatile IP Routing State / Dynamic Topology] |
+------------------------------------------------------------------+
While transport locators shift dynamically with network topology and
routing handovers, the EID operates as a long-lived logical
identifier. This structural separation abstracts network-level
transitions away from the application state. Every active agent
maintains an operational EID that is temporarily mapped to its host
IP address, providing continuous access to the global network,
Ephemeral State Endpoints (ESEs), and Persistent State Sessions
(PSS).
Gebauer Expires 29 January 2027 [Page 3]
Internet-Draft IACP - EID July 2026
2.2. EID Generation and Properties
The Ephemeral Agent Identity (EID) is structured as a self-certifying
cryptographic identifier. It consists of a 32-byte public key
derived from an asymmetric keypair, specifically optimized using the
Ed25519 signature scheme for identity validation.
EID Cryptographic Properties: * Mathematical Decoupling: The EID
contains no routing metadata, geographic indicators, or topological
constraints. It is bound to network locators via authenticated,
dynamic mappings. * Verification Permanence: Any active peer can
verify the authenticity of protocol control packets by validating the
attached Ed25519 signature directly against the initiating EID. *
Integrity Vectors: The EID serves as the unique index key for
tracking distributed reputation matrices within the shared network
ledger, binding behavioral history directly to the identity.
2.3. Identity-Locator Separation Principles
The protocol operates a clean layer split where transport-layer
stream multiplexing and sequence verification are handled inside the
cryptographic umbrella of the EID, while IP routing tables process
the transport locators. This ensures that network anonymity is
preserved without sacrificing session stability.
+-----------------------+ +-----------------------+
| Initiator (Alice) | | Responder (Bob) |
| Stable Identity: EID | | Stable Identity: EID |
+-----------------------+ +-----------------------+
| |
================== IDENTITY-LOCATOR SEPARATION ==================
| |
+-----------------------+ +-----------------------+
| Transport Locator (IP)| | Transport Locator (IP)|
| [Volatile Routing] | | [Volatile Routing] |
+-----------------------+ +-----------------------+
When an agent alters its physical connection point or moves across
network bounds, the upper session layer remains completely unaware of
the physical interface change. By absorbing routing transitions
within the decoupled identity layer, ongoing computations, resource
extraction pipelines, and active state allocations remain
uninterrupted.
Gebauer Expires 29 January 2027 [Page 4]
Internet-Draft IACP - EID July 2026
2.4. EID Persistence and Rotation Rules
To prevent longitudinal tracking and mitigate profiling risks across
the public routing topology, EID ephemerality is strictly bounded.
However, to maintain session stability, the EID remains persistent
across simple network handovers. EID rotation is explicitly
restricted and only triggered under the following three conditions:
1. Administrative Instruction: Upon an explicit administrative
directive issued by the managing user or parent orchestration
system.
2. Cryptographic Compromise: Immediately following a detected
security anomaly, private key exfiltration, or cryptographic
compromise.
3. Context Termination: Upon the successful completion or
termination of a designated operational task, autonomous session,
or Persistent State Session (PSS) context.
If an agent changes its network locator due to a simple routing
transition (such as migrating from Wi-Fi to mobile data networks),
identity persistence is managed directly between active peers. The
agent transmits a Signed Binding Update containing the new IP mapping
directly to its active communication partners. This optimization
keeps the EID stable during short-term handovers, preventing session
drops without requiring a full identity renegotiation or public
registration update.
To prevent malicious entities from utilizing rapid identity rotation
to evade accountability, EID ephemerality is bounded by a distributed
reputation architecture. Protocol deviations-such as unverified
session terminations or state invalidations-are signed and indexed
against the initiating EID within a decentralized substrate.
Rational nodes execute pre-flight validation of a target EID's
integrity vector before allocating state bounds or initializing
transitions.
2.5. Forwarding Tickets and DHT-based Asynchronous Resolution
Because direct binding updates require both endpoints to be
concurrently online, the architecture utilizes a decentralized
Distributed Hash Table (DHT) substrate (structured via Kademlia's XOR
metric) to resolve asynchronous identity-location decoupling. This
addresses real-world network constraints where nodes frequently cycle
offline or undergo asymmetric routing handovers.
Gebauer Expires 29 January 2027 [Page 5]
Internet-Draft IACP - EID July 2026
Before an agent rotates its network parameters or enters an extended
offline state, it generates a cryptographic Forwarding Ticket. This
ticket contains the agent's updated routing metadata, is signed via
the Ed25519 secret key associated with the active EID, and is
deposited at the agent's last known coordinate within the DHT. The
precise routing coordinate within the DHT substrate is derived
deterministically via:
KEY = SHA-256(EID_AGENT)
The storage transaction uses the DHT_TICKET_STORE format (Type 0x05).
The 36 bytes of Encrypted Forwarding Data are protected using an
Diffie-Hellman key exchange over X25519 combined with AES-GCM-256.
The cryptographic pipeline MUST be executed as follows:
1. *Key Derivation*: The initiating agent generates a fresh
ephemeral X25519 keypair (d_eph, Q_eph). It extracts the peers
static public key Q_peer from the active PSS context and computes
the shared secret:
K_shared = HKDF-SHA256(X25519(d_eph, Q_peer), salt="",
info="IACP_FORWARDING_TICKET_v1")
2. *Payload Encryption*: The raw forwarding vector (Target IP +
Port, 20 bytes) is encrypted with AES-GCM-256 using K_shared and
the 12-byte AEAD Nonce from the ticket header. The resulting
16-byte authentication tag is appended, producing the 36-byte
Encrypted Forwarding Data block.
3. *Signature*: The signature covers the concatenation of Target
Storage Key, Target Agent EID, TTL, AEAD Nonce and Encrypted
Forwarding Data using the owners Ed25519 private key.
The ephemeral public key Q_eph MUST be included in the ticket payload
(e.g., as an additional field) to allow the receiving peer to
reconstruct K_shared.
When a peer wakes up or reconnects after an extended offline period,
it queries the DHT at the historical coordinate of the targeted agent
by dispatching a DHT_TICKET_QUERY packet (Type 0x06).
The querying node populates the target key field, attaches an 8-byte
Transaction ID, and logs its own EID. The responding DHT node
returns a DHT_TICKET_RESP packet (Type 0x07) containing matching
transaction metadata, a 4-byte Status Code, and the encrypted ticket
payload.
Gebauer Expires 29 January 2027 [Page 6]
Internet-Draft IACP - EID July 2026
Upon retrieval, the querying peer decrypts the Forwarding Ticket
using the pre-established shared session key. This structural lookup
reveals the targeted agent's updated network locator and current
routing parameters. The communication channel is subsequently
restored via a sequential state synchronization routine utilizing
sequence state vector reconciliation, ensuring complete state
continuity without corruption.
+--------------------------+
| [0x05] DHT_TICKET_STORE |
+--------------------------+
|
v (Agent Goes Offline / Rotates Locator Parameters)
+--------------------------+
| [0x06] DHT_TICKET_QUERY |
+--------------------------+
|
v (DHT Fabric Processes XOR Routing Metrics)
+--------------------------+
| [0x07] DHT_TICKET_RESP |
+--------------------------+
2.6. EID Reputation and Cryptographic Ledger Attestation
EID is bound to a dynamic, non-repudiable transaction reputation
metric managed within the distributed directory overlay layer.
Because EIDs are decoupled from the network transport locators (IP
addresses), reputation tracking is executed directly against the
256-bit EID public key coordinate. This prevents malicious instances
from shedding negative operational history through transport
interface rotation or routing hop modification.
2.6.1. Cryptographic Attestation and Metrics
Reputation states are mathematically computed at the end of each
evaluation epoch (t) as a weighted Exponential Moving Average (EMA)
to incorporate temporal history while remaining responsive to recent
behavior:
R_State(t) = a * M(t) + (1 - a) * R_State(t-1)
where a = 0.12 (smoothing factor). The instantaneous metrics vector
M(t) is defined as:
M(t) = w1*S_Verify(t) + w2*A_Telemetry(t) - w3*PoM_Score(t)
Gebauer Expires 29 January 2027 [Page 7]
Internet-Draft IACP - EID July 2026
The formal invariants are: * S_Verify(t) im [0.0, 1.0]: Ratio of
cryptographically valid signatures on critical control frames
(PSS_INIT, PSS_ACK) during the epoch. * A_Telemetry(t) in [0.0, 1.0]:
Verified processing availability under active Session Federation
Contracts (SFC). * PoM_Score(t) = min(1.0, PoM_Count(t) / k) with k =
5 (normalized penalty; older tickets decay exponentially). * Weights:
w1 = 0.45, w2 = 0.35, w3 = 0.20. Baseline: R_State(0) = 1.0.
2.6.2. Threshold Enforcement and Session Downgrade
Peering nodes evaluating a connection initialization vector
(PSS_INIT) MUST query the target EID's current reputation coordinate
inside the directory keyspace before moving from STATE_HEARING to
STATE_ESTABLISHED.
If the reputation metric falls below a pre-configured local
threshold, the incoming packet ingestion layer MUST enforce one of
the following deterministic circuit-breaker states: 1. *Dynamic PoW
Escalation:* The host interface enforces a deterministic bitwise
difficulty escalation. For every 0.1 units the reputation falls
below the baseline threshold (R_Threshold = 0.7), the required
trailing-zero bit length increases by exactly 4 bits:
D_escalated = D_base + max(0, ceil((R_Threshold - R_State) * 40))
The maximum escalation is capped at +32 bits to prevent complete
denial-of-service through reputation poisoning. If R_State < 0.3,
the node SHOULD immediately reject new sessions in addition to the
escalated PoW requirement. 2. *Channel Micro-Throttling:* The local
engine restricts bandwidth and token-bucket allocation values via
hardcoded execution shims, forcing a degraded multi-path transport
pipeline. 3. *Immediate Block and Slashing Routing:* Upon detection
of an unexpired curator quarantine flag or active 2PSE ticket
reference, the protocol runtime drops the packet without volatile
memory allocation and propagates an immediate blacklisting broadcast
across the network topology.
2.7. Cross-Domain Identity Federation
IACP supports federated identity across trust domains through a
decentralized trust anchor exchange mechanism. This enables agents
from different administrative domains to authenticate and establish
secure sessions without pre-existing bilateral agreements.
2.7.1. Trust Anchor Document
Each trust domain publishes a Trust Anchor Document containing the
domain's identity roots, namespace roots, and trust anchors:
Gebauer Expires 29 January 2027 [Page 8]
Internet-Draft IACP - EID July 2026
{
"document_type": "iacp-trust-anchor",
"version": "1.0",
"domain": "org.agentnet.production",
"domain_id": "sha256:abc123...",
"trust_anchors": [
{
"type": "ed25519",
"key": "base64_encoded_public_key",
"valid_from": "2026-01-01T00:00:00Z",
"valid_until": "2027-01-01T00:00:00Z",
"purpose": "eid-validation"
},
{
"type": "ed25519",
"key": "base64_encoded_public_key",
"valid_from": "2026-01-01T00:00:00Z",
"valid_until": "2027-01-01T00:00:00Z",
"purpose": "namespace-validation"
}
],
"namespace_root": "sha256:def456...",
"curator_eid": "base64_encoded_curator_eid",
"federation_policy": {
"allowed_domains": ["org.agentnet.staging", "org.agentnet.test"],
"required_trust_tier": 1,
"max_delegation_depth": 5
},
"signature": "base64_ed25519_signature"
}
The Trust Anchor Document is signed by the domain curator and
published at a well-known DHT location:
KEY = SHA-256("iacp-federation:" || Domain_ID)
2.7.2. Federation Protocol Flow
Two agents from different trust domains establish trust:
1. Domain Discovery:
Agent A queries the DHT for Agent B's trust domain root:
DHT_QUERY { "key": "iacp-federation:" || Agent_B.Domain_ID,
"requestor_eid": Agent_A.EID }
1. Trust Anchor Retrieval:
Gebauer Expires 29 January 2027 [Page 9]
Internet-Draft IACP - EID July 2026
Agent A retrieves the Trust Anchor Document from Agent B's domain:
DHT_RESP { "trust_anchor_document": { ... }, "freshness": {
"timestamp": 1745512510, "ttl": 3600 } }
1. Validation:
Agent A validates the Trust Anchor Document:
a. Verify the Ed25519 signature against the curator EID. b. Verify
the trust_anchors are valid (not expired). c. Verify the
namespace_root matches the domain. d. Check federation_policy for
allowed_domains.
1. EID Verification:
Agent A validates Agent B's EID:
a. Retrieve Agent B's EID public key. b. Verify Agent B's EID
signature against the trust anchor.
*5. Session Establishment:*
PSS is established with cross-domain trust:
PSS_INIT { "initiator_eid": Agent_A.EID, "target_eid": Agent_B.EID,
"cross_domain": true, "trust_domain": Agent_B.Domain_ID,
"trust_anchor_fingerprint": sha256(Trust_Anchor_Document) }
2.7.3. Federation Gateway Mode
For deployments where direct trust anchor exchange is not possible, a
Federation Gateway MAY act as a trust broker:
+-------------------+ +-------------------+ +-----------------+
| Domain A Agent | | Federation Gateway| | Domain B Agent |
| | | | | |
| 1. Request Access |---->| 2. Validate Domain|---->| 3. Request Trust|
| | | A Trust Anchor | ___/| Anchor B |
| | | |/ | |
| | | 4. Validate |---->| 5. Return Trust |
| | | Domain B | | Anchor B |
| | | Trust Anchor | | |
| | | | | |
| 6. Return |<----| 7. Forward |---->| 8. Establish |
| Trust Anchor | | Trust Anchor | | Session |
| B | | B to A | | |
+-------------------+ +-------------------+ +-----------------+
Gebauer Expires 29 January 2027 [Page 10]
Internet-Draft IACP - EID July 2026
The Federation Gateway maintains a cache of Trust Anchor Documents
and performs trust validation on behalf of agents.
2.7.4. Trust Domain Curator Roles
The following curator roles are defined:
Root Curator: - Maintains the authoritative namespace registry for a
trust domain. - Signs and publishes the Trust Anchor Document. -
Rotates trust anchors when necessary. - Revokes trust anchors in case
of compromise.
Federation Gateway: - Translates between trust domains. - Performs
identity mapping and policy enforcement. - Provides trust anchor
discovery and validation services. - MAY cache Trust Anchor Documents
for performance.
Trust Broker: - Provides trust anchor discovery services across
domains. - Maintains a global index of trust domains. - Does not
perform policy enforcement (unlike Federation Gateway).
2.7.5. Trust Anchor Rotation and Revocation
Trust anchors have bounded validity (valid_from, valid_until).
Domains MUST publish updated Trust Anchor Documents before existing
anchors expire:
* Rotation Window: 24 hours before expiration.
* Validity Overlap: New anchor MUST be valid for at least 48 hours
after old anchor expires. -*Revocation: Domains MAY publish
revocation records for compromised anchors.
Revocation records are published at:
KEY = SHA-256("iacp-revocation:" || Domain_ID || Anchor_Fingerprint)
The revocation record contains: - Anchor fingerprint (revoked) -
Revocation timestamp - Reason code - Curator signature
2.7.6. Privacy Considerations for Federation
Cross-domain federation MAY expose sensitive information:
* Domain Exposure: The domain ID reveals organizational affiliation.
* Trust Anchors: Public keys are published for discovery.
Gebauer Expires 29 January 2027 [Page 11]
Internet-Draft IACP - EID July 2026
* Access Patterns: Federation requests reveal which domains agents
interact with.
Deployments SHOULD consider:
* Using ephemeral domain IDs for sensitive operations.
* Encrypting Trust Anchor Documents for authorized agents only.
* Rate-limiting federation requests to prevent enumeration attacks.
* Using Federation Gateways to hide internal domain structure.
2.7.7. New Message Types for Federation
The following new IACP message types are defined:
| Type | Name | Description |
|--------|-------------------------|----------------------------------|
| 0x1C | FED_TRUST_ANCHOR_REQ | Request Trust Anchor Document |
| 0x1D | FED_TRUST_ANCHOR_RES | Return Trust Anchor Document |
| 0x1E | FED_DISCOVERY_REQ | Discover trust domain by name |
| 0x1F | FED_DISCOVERY_RES | Return domain ID and metadata |
| 0x20 | FED_REVOCATION | Publish trust anchor revocation |
| 0x21 | FED_VALIDATE_REQ | Request EID validation by gateway|
| 0x22 | FED_VALIDATE_RES | Return EID validation result |
3. References
3.1. 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/info/rfc2119>.
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
<https://www.rfc-editor.org/info/rfc7401>.
[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/info/rfc8174>.
3.2. Informative References
Gebauer Expires 29 January 2027 [Page 12]
Internet-Draft IACP - EID July 2026
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[I-D.jeskey-anml]
Jeskey, A., "Agentic Notation Markup Language (ANML) 1.0",
Work in Progress, Internet-Draft, draft-jeskey-anml-01,
May 2026,
<https://datatracker.ietf.org/doc/draft-jeskey-anml/>.
Author's Address
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 29 January 2027 [Page 13]