Network Working Group L. Gebauer Internet-Draft Independent Intended status: Informational 28 July 2026 Expires: 29 January 2027 Internet Agent Communication Protocol - A2ACOM draft-gebauer-iacp-a2acom-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 - A2ACOM 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 . . . . . . . . . . . . . . . . . . 3 2. Agent to Agent Communication . . . . . . . . . . . . . . . . 3 2.1. Ephemeral State Endpoints (ESE) . . . . . . . . . . . . . 3 2.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2. Local Points (LP) . . . . . . . . . . . . . . . . . . 3 2.1.3. Global Points (GP) . . . . . . . . . . . . . . . . . 3 2.2. Discovery Spaces (DS) . . . . . . . . . . . . . . . . . . 3 2.2.1. Discovery Space Structure . . . . . . . . . . . . . . 3 2.3. Anonymous Discovery Mechanism . . . . . . . . . . . . . . 5 2.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys (DISCOVERY_REQ) . . . . . . . . . . . . . . . . . . . 5 2.3.2. Discovery Response and Secure EID Exchange (DISCOVERY_RES) . . . . . . . . . . . . . . . . . . . 5 2.4. Persistent State Sessions (PSS) . . . . . . . . . . . . . 5 2.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2. PSS Lifecycle and Handshake . . . . . . . . . . . . . 6 2.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG / PSS_ACK) . . . . . . . . . . . . . . . . . . . . . . 7 2.4.4. Session Federation Contract (SFC) . . . . . . . . . . 7 2.4.5. Data Streaming and Sequence Vector Reconciliation (PSS_DATA_STREAM) . . . . . . . . . . . . . . . . . . 8 2.5. Session Termination and Revocation . . . . . . . . . . . 8 2.5.1. Graceful Teardown (PSS_TEARDOWN) . . . . . . . . . . 8 2.5.2. Revocation and Proof of Malfeasance Publishing (PSS_REVOCATION_PUBLISH) . . . . . . . . . . . . . . 8 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Normative References . . . . . . . . . . . . . . . . . . 8 3.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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. Gebauer Expires 29 January 2027 [Page 2] Internet-Draft IACP - A2ACOM July 2026 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. 2. Agent to Agent Communication 2.1. Ephemeral State Endpoints (ESE) 2.1.1. General An Ephemeral State Endpoint (ESE) constitutes a non-persistent, volatile memory mapping and interface execution state hosted directly under an active Ephemeral Agent Identity (EID). ESEs externalize telemetry, volatile state variables, and transactional intention metadata to authorization-verified peering agents. All allocated ESE memory structures are cryptographically bound to the lifecycle of the parent EID and undergo deterministic erasure upon EID rotation or session termination. 2.1.2. Local Points (LP) Designed for isolated, physically bounded networks (e.g., IEEE 802.3/802.11 Local Area Networks). LPs require agents to maintain a mapping of peer MAC addresses to facilitate link-layer transmission. Local EIDs and LPs are isolated by default and are not discoverable over the wider internet unless explicitly configured. 2.1.3. Global Points (GP) Global Points (GP) are interoperable endpoints designed for WAN and public internet routing. A GP is addressable via a deterministic 256-bit composite coordinate computed as follows: GP_Coordinate = SHA-256(Parent_EID || Endpoint_Identifier_Tag) 2.2. Discovery Spaces (DS) 2.2.1. Discovery Space Structure A Discovery Space (DS) is a logical grouping of agents by topic or semantic category. Each DS is identified by a deterministic DS_ID, computed as: DS_ID = SHA-256("ds:" || Namespace || Topic || Version) Gebauer Expires 29 January 2027 [Page 3] Internet-Draft IACP - A2ACOM July 2026 Where: * Namespace: The hierarchical namespace (e.g., "org.agentnet") * Topic: A human-readable topic string (e.g., "marketplace.energy") * Version: A monotonically increasing version number for the DS A Discovery Space follows this lifecycle: +------------+ +----------+ +----------+ +-----------+ | Create | --> | Join | --> | Query | --> | Prune | | DS_ANNOUNCE| | DS_JOIN | | DISCOVERY| | TTL Expiry| +------------+ +----------+ +----------+ +-----------+ | | | | v v v v DHT Store DHT Store DHT Lookup Remove Stale (Curator) (Agent) (DS_ID) Records 2.2.1.1. DS Creation and Registration A Discovery Space is created by publishing a DS_ANNOUNCE record in the DHT under the key DS_ID. The DS_ANNOUNCE record contains: * DS metadata (topic, description, curator EID) * A list of seed peers (OPTIONAL) * A signature by the curator EID (Ed25519) Only the curator EID may update or delete the DS_ANNOUNCE record. 2.2.1.2. Joining a Discovery Space An agent wishing to join a DS: 1. Looks up DS_ID in the DHT. 2. Validates the DS_ANNOUNCE signature against the curator EID. 3. Registers its own EID in the DS by publishing a DS_JOIN record under DS_ID || EID. The DS_JOIN record contains the agent's EID, a timestamp (UNIX 64-bit), and a signature (Ed25519). Gebauer Expires 29 January 2027 [Page 4] Internet-Draft IACP - A2ACOM July 2026 2.2.1.3. Discovery Queries Agents can query a DS for peers matching specific criteria. A DISCOVERY_REQ (Section 6.3.1) targeting a DS uses the DS_ID as the target coordinate. The DS_JOIN records of matching peers are returned in the DISCOVERY_RES response. 2.2.1.4. DS Curation and Pruning To prevent stale entries, DS_JOIN records have a TTL of T_ds_join = 1 hour. Agents MUST refresh their DS_JOIN record before expiration. Curators MAY prune stale records by removing records with expired timestamps. 2.2.1.5. DS Topic Hierarchy Topics are hierarchical, separated by dots (e.g., "marketplace.energy.trading"). A query for a parent topic (e.g., "marketplace") SHOULD return all child topics by performing a range query on the DHT for keys starting with "ds:" || Namespace || "marketplace". 2.3. Anonymous Discovery Mechanism 2.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys (DISCOVERY_REQ) To facilitate autonomous discovery without compromising privacy, an agent can broadcast an anonymous information request into the network without exposing its own EID. These anonymous broadcasts require the attachment of a valid Cryptographic Proof-of-Work (PoW) Token, strictly prohibiting any host state or memory allocation prior to successful token validation. The initiating agent includes an Ephemeral Public Key within the payload. 2.3.2. Discovery Response and Secure EID Exchange (DISCOVERY_RES) An accepting peer that evaluates the request and intends to establish contact encrypts its own EID using this ephemeral public key. This allows the responding node to securely transition its identity to the requester without leakage to intermediate nodes. Once decrypted by the initiator, both agents possess each other's EIDs. 2.4. Persistent State Sessions (PSS) Gebauer Expires 29 January 2027 [Page 5] Internet-Draft IACP - A2ACOM July 2026 2.4.1. General For sustained, long-term collaboration, two agents establish a Persistent State Session (PSS). A PSS is a continuous state channel running within the DHI environment, where two distinct EIDs instantiate a pair of dedicated, mutually encrypted ESEs. When an agent updates its local state within its assigned ESE, the state transition is immediately propagated to the peer node. If several nodes interlock their respective ESE arrays, complex decentralized agent networks emerge. 2.4.2. PSS Lifecycle and Handshake PSS sessions are encapsulated within the QUIC transport protocol. The protocol uses sequence vectors to ensure fault tolerance and state consistency across unreliable networks. If an agent suffers an unexpected crash, server outage, or temporary loss of connectivity, it can seamlessly reconcile missed transactions upon reconnection by comparing local and remote sequence state vectors. The Lifecycle looks as follows: +-------------------+ | STATE_CLOSED | +-------------------+ | | Transmit PSS_INIT v +-------------------+ | STATE_HEARING | <---+ Receive PSS_NEG +-------------------+ | (Validate Verification Cookie) | | | Emit PSS_ACK | v | +-------------------+ ----+ | STATE_ESTABLISHED| +-------------------+ | | PSS_TEARDOWN / PSS_REVOCATION v +-------------------+ | STATE_CLOSED | +-------------------+ Strict state progression constraints require that the reception of out-of-order or invalid packet sequences during the handshaking phase causes an immediate transition to STATE_CLOSED. Gebauer Expires 29 January 2027 [Page 6] Internet-Draft IACP - A2ACOM July 2026 2.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG / PSS_ACK) To prevent resource exhaustion from distributed blind spoofing vectors, connection establishment enforces a three-way Dual-Cookie Handshake sequence for establishing an SFC. The initiating entity generates a PSS_INIT packet embedding a cryptographically random initialization nonce. The responder processes the entry and validates its local capacity constraints before returning a PSS_NEG frame. This response contains an independent tracking cookie generated via a keyed hash over the network locators. Session allocations finalize only upon reception of a matching PSS_ACK from the initiator, proving network boundary control. 2.4.4. Session Federation Contract (SFC) Peer agents can execute a Session Federation Contract (SFC) to establish a mutual resource-sharing agreement. The SFC grants both participating nodes direct, authenticated access to each other's designated ESEs based on a three-way cryptographic negotiation handshake integrated into the PSS establishment: 1. *PSS_INIT (SFC Flag Activation)*: The initiating agent dispatches a PSS_INIT frame (Type 0x08) with the SFC Negotiation bit set in the Session Capabilities & Extension Flags field (bit 0). This signals an explicit request to bind a contractual federation to the session. 2. *PSS_NEG (SFC Conditions Proposal)*: The responder processes the capability flag. If acceptable, it replies with a PSS_NEG frame (Type 0x0A) containing the 32-byte "Proposed SFC Conditions Block" that defines resource limits, permission scopes, and execution boundaries. 3. *PSS_ACK (Contract Ratification)*: The initiator evaluates the proposed conditions. If they are compatible with its local policy, it returns a PSS_ACK frame (Type 0x09) with the matching capability bits set, thereby ratifying the contract. The session transitions to STATE_ESTABLISHED under active SFC constraints. This active session state remains valid until explicitly dissolved via a structured Graceful Teardown Protocol (PSS_TEARDOWN). If an individual peer requests a dedicated, unshared connection, the runtime isolates the PSS by instantiating an exclusive ESE pair. Encrypted ESE payloads are protected with periodically rotated Dynamic Group Keys (DGK) distributed only to authenticated members of the Trust List. Gebauer Expires 29 January 2027 [Page 7] Internet-Draft IACP - A2ACOM July 2026 2.4.5. Data Streaming and Sequence Vector Reconciliation (PSS_DATA_STREAM) Post-handshake data transmission utilizes the structured PSS_DATA_STREAM packet format. To achieve strict transaction tracking without causing transmission blockages under packet reordering conditions, every frame incorporates a monotonically increasing sequence identifier alongside a 32-byte rolling cryptographic state reconciliation hash. 2.5. Session Termination and Revocation 2.5.1. Graceful Teardown (PSS_TEARDOWN) Coordinated channel dismantling requires PSS_TEARDOWN. The initiating node flushes all remaining outbound memory pipelines, commits a terminal data checksum, transmits the teardown control packet, and maintains tracking states until a reciprocal verification acknowledgment is returned by the peer. 2.5.2. Revocation and Proof of Malfeasance Publishing (PSS_REVOCATION_PUBLISH) If an endpoint runtime identifies a protocol invariant violation (e.g., sequence counter reuse, unauthorized context leak, or cryptographic invalidation of negotiated contract rules), it executes a forced local teardown sequence via a PSS_REVOCATION_PUBLISH packet. This control frame destroys local session contexts instantly and pushes the embedded Proof of Malfeasance (PoM) ticket to the global directory layer, initiating automated peer blacklisting and staking escrow slashing routines across the network topology. 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, . [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 8] Internet-Draft IACP - A2ACOM July 2026 [I-D.bu-agentproto-security-principal-binding] Bu, S., "Security Principal and Verifier Binding for Agent Communication Protocols", Work in Progress, Internet- Draft, draft-bu-agentproto-security-principal-binding-02, 6 July 2026, . Author's Address Leonard Gebauer Independent Germany Email: leonard.gebauer.ha@gmail.com Gebauer Expires 29 January 2027 [Page 9]