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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, . [I-D.jeskey-anml] Jeskey, A., "Agentic Notation Markup Language (ANML) 1.0", Work in Progress, Internet-Draft, draft-jeskey-anml-01, May 2026, . Author's Address Leonard Gebauer Independent Germany Email: leonard.gebauer.ha@gmail.com Gebauer Expires 29 January 2027 [Page 13]