Internet Agent Communication Protocol - A2ACOM
draft-gebauer-iacp-a2acom-00

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,
              <https://www.rfc-editor.org/info/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/info/rfc8174>.

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, <https://datatracker.ietf.org/doc/draft-bu-
              agentproto-security- principal-binding/>.

Author's Address

   Leonard Gebauer
   Independent
   Germany
   Email: leonard.gebauer.ha@gmail.com

Gebauer                  Expires 29 January 2027                [Page 9]