Internet Agent Communication Protocol - DHI - ERP
draft-gebauer-iacp-dhi-erp-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-dhi-erp-00
Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 28 July 2026
Expires: 29 January 2027
Internet Agent Communication Protocol - DHI - ERP
draft-gebauer-iacp-dhi-erp-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 - DHI - ERP 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. Deterministic Hypermedia Interpreter (DHI) . . . . . . . . . 3
2.1. DHI General . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1. Execution Environment and UI Abstraction . . . . . . 3
2.1.2. The Agent Parser Ingestion Pipeline . . . . . . . . . 3
2.1.3. Resource Retrieval via Algorithmic Extraction (HRP &
APE) . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. Content Equivalence and Legacy Hand-off Invariants . 13
2.1.5. Separation of Concerns between DHI and Agents . . . . 16
2.1.6. ANML Support and Integration . . . . . . . . . . . . 17
2.2. EID Routing Protocol (ERP) - Subprotocol . . . . . . . . 21
2.2.1. Protocol Entities and Abstraction Layer . . . . . . . 21
2.2.2. Session Cryptography and Isolation Mechanics . . . . 22
2.2.3. Protocol Operations . . . . . . . . . . . . . . . . . 24
2.2.4. Secure Handshake and Connection Management . . . . . 27
2.2.5. Resource Governance . . . . . . . . . . . . . . . . . 32
2.2.6. Fault Tolerance, Resiliency, and Degraded
Operations . . . . . . . . . . . . . . . . . . . . . 34
2.2.7. Decentralized Security Governance and Slashing . . . 36
2.2.8. QUIC Transport Binding . . . . . . . . . . . . . . . 39
2.2.9. LL-Entity Local Interface Specification . . . . . . . 41
2.2.10. Remote Attestation Integration . . . . . . . . . . . 42
3. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1. Normative References . . . . . . . . . . . . . . . . . . 48
3.2. Informative References . . . . . . . . . . . . . . . . . 49
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50
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 - DHI - ERP 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. Deterministic Hypermedia Interpreter (DHI)
2.1. DHI General
2.1.1. Execution Environment and UI Abstraction
The Deterministic Hypermedia Interpreter (DHI) executes all
processing, resource extraction, and cross-agent operations. It
serves as the native runtime for ESE hosting, PSS state management,
and data queries. The DHI delegates all name resolution and
transport endpoint discovery to the Local Loopback Layer Entity (LL-
Entity) defined in the EID Routing Protocol (ERP). It omits
traditional visual user interfaces and uses a structured agent-
optimized Search Tree instead. The DHI maintains strict content
equivalence with human-centric web payloads. It maps identical
content into an abstract representation without data loss. Documents
using Agentic Network Markup Language (ANML) are processed natively.
Functional requests that cannot be translated into pure informational
states are handed off to a conventional browser environment.
2.1.2. The Agent Parser Ingestion Pipeline
When an Autonomous Agent Instance (AAI) receives a legacy
alphanumeric domain name or URI, the DHI forwards the resolution
request to the local LL-Entity. The LL-Entity performs EID
resolution or transport locator mapping, using the ANML Fallback
Query (Type 0x12) if no direct mapping exists. The Agent Parser then
operates as a deterministic finite state machine (FSM) and enforces
the following sequential execution pipeline:
2.1.2.1. State Machine Transitions and Pipeline Execution
The ingestion pipeline MUST proceed according to the following state
machine and transitional logic:
Gebauer Expires 29 January 2027 [Page 3]
Internet-Draft IACP - DHI - ERP July 2026
+-----------------------+ +------------------------+
| INIT / INPUT URI | --> | [1] DNS_SRV_EVALUATION|
+-----------------------+ +------------------------+
|
v
+-----------------------+
| [2] WELL_KNOWN_EVAL |
+-----------------------+
|
+-----------------------+-------------+
| (If Unreachable) |
(If Unreachable) (If Reachable)
v v
+-----------------------+ +-----------------------+
| [2.1] PROBLEM_CACHE | | [3] LINK_HEADER_SNIFF|
+-----------------------+ +-----------------------+
| |
(TERM_EXECUTION) v
+-----------------------+
| [4] BASELINE_CORE |
+-----------------------+
|
v
+-----------------------+
| [4.1] SWITCH_POINT |
+-----------------------+
[1] DNS_SRV_EVALUATION: Initiates a DNS SRV query to discover agent-
native endpoints and configuration parameters.
[2] WELL_KNOWN_EVAL: Issues a request to /.well-known/anml.
[2.1] PROBLEM_CACHE: Non-terminal fault isolation state. On
unreachable endpoints, HTTP error states (4xx/5xx), timeouts, or
protocol violations, the parser logs a failure descriptor, creates a
local cache record with a minimum Time-to-Live (TTL) of 300 seconds,
and aborts the active fast-path execution.
[3] LINK_HEADER_SNIFF: Scans response headers for RFC 8288 Link
entries pointing to ANML resources.
[4] BASELINE_CORE: Aggregates discovery data and passes context to
the SWITCH_POINT.
[4.1] SWITCH_POINT: Critical non-terminal decision state that routes
between native ANML processing and legacy fallback.
Gebauer Expires 29 January 2027 [Page 4]
Internet-Draft IACP - DHI - ERP July 2026
The boundary parameters for the ingestion pipeline MUST be determined
dynamically via Dynamic Capabilities Negotiation (DCN) during session
establishment.
Conforming implementations MUST enforce the following constraints
based on negotiated operational parameters:
a. Endpoints MUST declare their explicit buffer limits and timeout
windows using standardized IACP Transport Parameters during the
transport-layer handshake (e.g., via extended QUIC transport
parameters or PSS parameters).
b. The dynamic socket poll timeout (T_eval) and maximum floating
buffer size (MAX_FLOAT_BUF) are negotiated per context. For baseline
server-to-server environments where no explicit parameters are
exchanged, implementations SHOULD fall back to the following
recommended default values: * Recommended T_eval Default: 15000 ms *
Recommended MAX_FLOAT_BUF Default: 4194304 bytes (4 MB)
c. Inbound data MUST be accumulated sequentially in a volatile local
FIFO buffer matching the negotiated MAX_FLOAT_BUF constraint of the
receiving node. If a constrained entity (e.g., an IoT sensor)
signals a lower maximum capability (e.g., MAX_FLOAT_BUF = 65536
bytes), the sender MUST throttle or block packet delivery to prevent
buffer overrun.
d. If structural context resolves before the negotiated T_eval
expires and MAX_FLOAT_BUF is not exceeded, the FSM MUST transition
immediately to NATIVE_ANML_PATH [4.3].
e. On negotiated T_eval expiry or buffer resource exhaustion, the
interpreter MUST immediately truncate the buffer, terminate the fast-
path stream, and transition to LEGACY_PATH_EXECUTION [4.2] or
PROBLEM_CACHE.
2.1.2.2. Finite State Machine Transitional Invariants and Error
Handling
To guarantee deterministic behavior under failure conditions, the
following invariants apply:
A. Syntactically Corrupt ANML Document: If the parser enters state
[4.3] (NATIVE_ANML_PATH_INGESTION) and encounters a structural token
failure, invalid byte sequence, or schema violation, the DHI MUST
immediately transition to LEGACY_PATH_EXECUTION [4.2]. The partially
accumulated buffer MUST be discarded. A Hand-off Context Object
(HCO) is generated to trigger a headless browser fallback, ensuring
operational continuity.
Gebauer Expires 29 January 2027 [Page 5]
Internet-Draft IACP - DHI - ERP July 2026
B. Evaluation Timeout (T_eval Expiry): If the cumulative time in
states [1]-[4] exceeds the negotiated T_eval (default: 15000 ms), the
FSM MUST: - Terminate the active network stream, - Discard any
partial buffer, - Transition directly to PROBLEM_CACHE [2.1], - Log
the timeout as a transient fault.
2.1.2.3. The Switch Point Logical Invariants
The state SWITCH_POINT [4.1] represents the critical architectural
boundary where the communication stream is fork-routed based on two
mutually exclusive parameters: the presence of ANML metadata and the
active operational constraints of the calling agent.
+--------------+
| SWITCH_POINT |
+--------------+
|
+-----------------------+---------------------+
| |
(ANML Found) (ANML Absent)
v v
+---------------------+ +--------------------+
|[5] USER_REQ_CHECK | | [4.2] LEGACY_PATH |
+---------------------+ +--------------------+
| |
+------+------+ |
| | |
(Rich Assets) (Text Only) |
v v v
+-----------+ +-----------+ (Browser Hand-off)
| [4.2] LGC | | [4.3] NAM | |
+-----------+ +-----------+ v
| | (TERM_FAST_PATH)
+------+------+
|
v
+---------------------+
| [6] DOWNSTREAM_SUB |
+---------------------+
A. ANML Non-Existence Path: If no valid ANML endpoints, pointers, or
metadata tags are detected during states [2] or [3], the FSM MUST
execute a transitional branch to LEGACY_PATH_EXECUTION [4.2]. The
parser triggers the standard web fallback mechanism, initiates heavy
media layout rendering via a headless DOM engine, and hands over
context to a sandboxed browser environment. Native fast-path parsing
is instantly terminated.
Gebauer Expires 29 January 2027 [Page 6]
Internet-Draft IACP - DHI - ERP July 2026
B. ANML Existence Path: If valid ANML infrastructure is found, the
FSM transitions directly to the USER_REQUIREMENT_CHECK [5]. This
sub-state evaluates explicit runtime constraints and asset criteria
passed by the client agent concerning non-text-based payload
components (e.g., raster images, audio, video vectors).
i. If rich-media or layout asset dependencies are explicitly
required by the user constraints, the machine drops the
fast-path and triggers LEGACY_PATH_EXECUTION [4.2] to
guarantee complete content availability.
ii. If the user constraint matrix allows text-only/semantic-only
extraction, or if no rich assets are requested, the machine
transitions to NATIVE_ANML_PATH_INGESTION [4.3]. The engine
initiates a direct, machine-first stream of the raw markup,
completely bypassing visual layout, Cascading Style Sheets
(CSS), and human-centric JavaScript rendering engines.
Execution paths converging from native ingestion or fallback
processing MUST deliver their finalized object payloads to the
DOWNSTREAM_PROCESSING_SUBSYSTEMS [6] to drive HRP, APE, and active
LLM core workflows.
2.1.2.4. Protocol Specification for Problem Caching Cycles
To prevent distributed denial-of-service (DDoS) loops and mitigate
computational overhead induced by repetitive agentic polling of
broken endpoints, implementations MUST conform to the strict fault-
handling requirements of the PROBLEM_CACHE [2.1] state:
1. Fault Isolation: When an ANML discovery error occurs, the local
runtime environment MUST encapsulate the network fault layer
fromthe executing agent logic.
2. TTL Enforcement: The fault record logged by the Problem Caching
Cycle MUST specify a minimum Time-To-Live (TTL) value of
300seconds. During this active window, any subsequent
outboundingestion requests from the same host to the failing
target URIMUST be short-circuited locally at the parser layer.
3. State Clearance: Upon expiration of the local fault TTL record,
the parser MUST transition back to an unblocked state, allowinga
single sequential pipe verification attempt on the next
targetinvocation.
Gebauer Expires 29 January 2027 [Page 7]
Internet-Draft IACP - DHI - ERP July 2026
2.1.2.5. Interaction with Application Layer
When the DHI encounters a fault (PROBLEM_CACHE state), the following
interaction with the application layer occurs:
1. Fault Isolation: The DHI encapsulates the network fault and
transitions to PROBLEM_CACHE. The application layer (LLM Core)
is NOT notified of the fault unless the fault persists beyond a
configurable threshold (default: 3 consecutive failures).
2. Application Notification: If the fault persists beyond the
threshold, the DHI sends a FAULT_NOTIFICATION (Type 0x1C) to the
application layer via the IIB. This notification contains the
URI, error code, and a timestamp.
3. Application Retry Logic: The application layer MAY override the
DHI's backoff mechanism by issuing a RETRY_OVERRIDE (Type 0x1D)
command. This command resets the backoff timer and forces a new
resolution attempt.
4. Fallback Handlin*: If the application layer receives a
FAULT_NOTIFICATION, it MAY choose to abort the current operation
or use a cached response (if available). The DHI does not
interpret the application's decision.
2.1.2.6. Exponential Backoff with Cryptographic Jitter
The backoff mechanism in STATE_ANML_DEGRADED uses the following
refined formula:
T_retry = Min(T_max, T_base * (2^attempts) ) + Cryptographic_Jitter
Where:
* T_base = 2 seconds (the initial protocol backoff constant).
* attempts = the incremental count of continuous failed resolution
requests. This counter is reset to 0 upon a successful resolution
or upon receipt of a MIGRATION_VECTOR.
* T_max = 300 seconds (the absolute upper boundary ceiling).
* Cryptographic_Jitter = A random value derived directly from a
local hardware CSPRNG, bounded within the interval [0, 15]
seconds. The jitter is recalculated for each retry attempt.
The backoff counter is reset to 0 under the following conditions:
Gebauer Expires 29 January 2027 [Page 8]
Internet-Draft IACP - DHI - ERP July 2026
* Successful resolution of the target URI.
* Receipt of a MIGRATION_VECTOR (Section 4.2.5.1) for the target
EID.
* Receipt of an ERP_REGISTER (Section 4.2.3.2) with a higher
Generation Counter.
2.1.3. Resource Retrieval via Algorithmic Extraction (HRP & APE)
To maximize data harvesting efficiency and minimize transport layer
overhead, resource discovery within the DHI Search Tree MUST rely on
the concurrent execution of two deterministic architectural
subsystems: Heuristic Relevancy Probability (HRP) and Automated
Pipeline Extraction (APE).
+---------------------------------+
| DHI Search Tree Target Nodes |
+---------------------------------+
|
v
+---------------------------------+
| [2.3.1] HRP Matrix Evaluation |
| HRP(n) = w1*S + w2*R + w3*C |
+---------------------------------+
|
v
+---------------------------------+
| [2.3.2] APE Filter Mechanism |
| Is HRP(n) >= Theta? |
+---------------------------------+
|
+-------------------+-------------------+
| (Yes) | (No)
v v
+------------------------------+ +---------------------------+
| [2.3.3] Parallel Execution | | Prune / Drop Node Stream |
| Fast Path / Queue Priority | | (Zero Network Traffic) |
+------------------------------+ +---------------------------+
2.1.3.1. Heuristic Relevancy Probability (HRP)
Every target node (n) or Uniform Resource Identifier (URI) within the
active discovery search space is algorithmically assigned a dynamic,
scalar probability value HRP(n) bounded by the interval [0.0, 1.0].
This value represents the statistical likelihood that the designated
resource node contains the precise target payload requested by the
calling agent.
Gebauer Expires 29 January 2027 [Page 9]
Internet-Draft IACP - DHI - ERP July 2026
Implementations MUST calculate HRP(n) continuously via localized
execution engines natively embedded within the DHI execution layer,
conforming to the following weighted vector equation:
HRP(n) = (w1 * S(A, Tn)) + (w2 * R(En)) + (w3 * C(Hn))
The formal invariants of the calculation matrix are defined as:
1. Semantic Similarity Vector S(A, Tn) on Resource-Constrained Edge
Nodes: Edge nodes MUST NOT perform full LLM embedding
computations. Instead, similarity is calculated via a hybrid
approach:
a. Local Approximation (immediate): The edge node computes a fast
deterministic score using Jaro-Winkler distance on anchor text/
metadata combined with BM25 token weighting against locally cached
keyword vectors of request A.
b. Asynchronous Core Offloading: Concurrently, the edge node
dispatches a metadata request over the Ingestion Interface Boundary
(IIB) to a core datacenter capable of full vector embeddings.
c. Wire Format: The response uses the HRP_VECTOR_RESP (Type 0x1B)
packet:
Gebauer Expires 29 January 2027 [Page 10]
Internet-Draft IACP - DHI - ERP July 2026
~~~~ ascii-art
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x1B) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Session Hash [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Embedding Dimension Count (2 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Quantized Float16 Latent Semantic Vector Array |
| (Variable Length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Core Authority Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~~~~
The edge node MUST verify the Ed25519 signature before caching the vector. Until the async response arrives, the local approximation is used. Upon receipt, an interrupt updates the HRP(n) value.
1. Reputation Weight R(En): A scalar value derived from
thecryptographic verification of curator assertions recorded
withinthe distributed hash table (DHT) namespace layer.
2. Contextual History C(Hn): A historical convergence metrictracking
the agent's prior retrieval success rates acrossidentical URI
sub-paths and structural path patterns.
3. Weight Vector Normalization: The system-defined weights (w1,
w2,w3) are configuration-specific invariants and MUST satisfy
thenormalization constraint: w1 + w2 + w3 = 1.0.
2.1.3.1.1. HRP Default Values
The system-defined weights (w1, w2, w3) are configuration-specific
invariants and MUST satisfy the normalization constraint: w1 + w2 +
w3 = 1.0. The following default values are RECOMMENDED:
* w1 = 0.45 (Semantic Similarity Vector)
* w2 = 0.35 (Reputation Weight)
* w3 = 0.20 (Contextual History)
Gebauer Expires 29 January 2027 [Page 11]
Internet-Draft IACP - DHI - ERP July 2026
These default values are based on empirical analysis of agent
retrieval patterns across various domains. Implementations MAY
adjust these values based on specific operational requirements, but
MUST maintain the normalization constraint.
2.1.3.2. Automated Pipeline Extraction (APE)
The APE engine acts as the deterministic execution arm of the DHI,
ingesting the compiled HRP matrix to orchestrate parallelized network
transport traversals.
1. Threshold Filtering: The APE engine MUST enforce a
dynamicthreshold variable Designated as Theta (O). If a target
nodeevaluates to a metric where HRP(n) < O, the engine MUST
prunethe node from the active traversal path, suppressing
outboundnetwork socket allocation for that node.
2. Parallel Socket Allocation: For nodes satisfying HRP(n) >= O,
theAPE engine maps execution priority directly to the scalar
HRPweight:
a. Fast Path Ingestion: Nodes displaying an HRP(n) metric above a high-probability boundary (HRP(n) >= 0.85) MUST be allocated immediate, dedicated streaming TCP/IACP connections.
b. Asynchronous Queue: Nodes displaying mid-range probabilities (O <= HRP(n) < 0.85) MUST be buffered within a prioritized asynchronous download queue, executed concurrently based on available system bandwidth.
1. Path Optimization: When multi-hop graph traversal within
theAgentNet topology is required, the APE engine MUST compute
themathematically optimal extraction path by executing a
directedacyclic graph (DAG) search algorithm, utilizing the
inverse ofthe HRP(n) value as the primary edge-cost function.
2.1.3.2.1. APE Default Threshold
The APE engine enforces a dynamic threshold variable designated as
Theta (Θ). The following default value is RECOMMENDED:
Θ = 0.60
This threshold balances extraction efficiency with resource usage:
nodes with HRP(n) >= 0.60 are considered worth processing, while
nodes below this threshold are pruned. This default value is derived
from empirical analysis where a threshold of 0.60 provides optimal
extraction yield relative to resource consumption. Implementations
MAY adjust Θ based on:
* Available system bandwidth: Lower Θ for high-bandwidth scenarios.
Gebauer Expires 29 January 2027 [Page 12]
Internet-Draft IACP - DHI - ERP July 2026
* Precision requirements: Higher Θ for scenarios requiring high
precision (e.g., security-sensitive retrievals).
* Historical success rates: Adaptive adjustment based on past
retrieval outcomes.
2.1.4. Content Equivalence and Legacy Hand-off Invariants
2.1.4.1. Mathematical Equivalence Metrics
To verify structural and content parity during state transformation,
the runtime MUST evaluate the Equivalence Verification Metric (EVM).
1. Asynchronous Core Offloading & Edge Caching: The computation of
the EVM MUST NOT be executed live by the Edge routing
infrastructure. Instead, the raw document stream and
transformation context ARE offloaded asynchronously to the core
datacenter of the content provider. The Edge infrastructure
operates exclusively as an intelligent caching layer for pre-
validated ANML structures, reducing peripheral CPU load to near-
zero.
2. DOM Stripping & Text Normalization: Inside the core datacenter,
the documents DOM tree MUST be stripped of non-semantic layout
elements, and the pure semantic text nodes MUST be extracted and
normalized into a standardized canonical format.
3. Cross-Entropy Distance Tokenization Invariants: To guarantee bit-
identical EVM results across independent implementations,
probability distributions p and q MUST be constructed at the
normalized UTF-8 codepoint level:
a. Tokenization Level: The input is tokenized as raw Unicode
codepoints in UTF-8. Multi-byte characters are treated by their
canonical codepoint value (U+XXXX).
b. Normalization: The stream MUST be normalized to Unicode
Normalization Form C (NFC). Carriage returns, ignorable control
characters, and consecutive whitespace are collapsed to a single
U+0020 space.
c. Probability Distribution:
p(i) = Count(Codepoint_i) / Total_Normalized_Codepoints
(same for q)
The Equivalence Verification Metric is computed as:
Gebauer Expires 29 January 2027 [Page 13]
Internet-Draft IACP - DHI - ERP July 2026
EVM = H(p, q) - H(p)
where H denotes Shannon entropy. If a codepoint present in p is
absent in q, apply Laplacian smoothing with eps = 1e-7.
Conforming implementations MUST satisfy EVM <= 0.001.
4. Cryptographic Invariant Validation: To prevent semantic damage
via lexical permutation or omission, the runtime MUST compute a
SHA-256 hash comparison. This comparison MUST operate
exclusively on the linearized buffer composed of the extracted
and canonicalized pure text nodes, ingested sequentially in an
identical, deterministic document traversal order (depth-first,
left-to-right).
5. Parity Invalidation: If either the computed Cross-Entropy
distance exceeds the threshold (EVM > 0.001) or the SHA-256
signatures of the two canonical text sequences display any
divergence, the state equivalence evaluation MUST fail instantly,
forcing a hard transition to the LEGACY_PATH_EXECUTION [4.2]
fallback.
2.1.4.2. Interface Specification for Legacy Path Hand-off Context
When the SWITCH_POINT [4.1] or USER_REQUIREMENT_CHECK [5] drops the
fast-path due to missing ANML infrastructure or explicit rich-media
asset requirements, the DHI MUST compile and serialize a standardized
Hand-off Context Object (HCO). The HCO is transmitted across the
functional boundary to the sandboxed legacy browser engine.
Gebauer Expires 29 January 2027 [Page 14]
Internet-Draft IACP - DHI - ERP July 2026
+---------------------------------------+
| DHI Local Ingestion Fast-Path Layer |
+---------------------------------------+
|
(Trigger: Legacy Fallback)
|
v
+---------------------------------------+
| [2.4.3] Serialization of Hand-off |
| Context Object (HCO Payload) |
+---------------------------------------+
|
+--------------------+--------------------+
| |
[Byte 0-31]: Active EID [Byte 32-63]: Session Hash
| |
[Byte 64-67]: Sequence [Byte 68-71]: Capabilities
| |
+--------------------+--------------------+
|
v
+---------------------------------------+
| Sandboxed Legacy Browser Container |
+---------------------------------------+
2.1.4.3. HCO Wire-Level Structural Layout
The serialized HCO binary block MUST conform to the following layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hand-off Trigger Context Type (2 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ephemeral Session Derivative EID (ESD-EID) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Persistent State Session Hash |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target URL Length (2B) | Target URL String (UTF-8)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 15]
Internet-Draft IACP - DHI - ERP July 2026
A. Hand-off Trigger Context Type (2 Bytes): Unsigned integer
identifying the execution failure or unmappable state that triggered
the legacy hand-off.
B. Ephemeral Session Derivative EID (ESD-EID) (32 Bytes): Temporary
cryptographic token generated by the LL-Entity for this session only.
It is derived from the permanent EID combined with a session nonce.
The real long-lived EID MUST NOT be exposed to the sandbox. The LL-
Entity MUST intercept and validate this derivative on return.
C. Persistent State Session Hash (32 Bytes): Cryptographic digest of
the active session context.
D. Target URL Length (2 Bytes): Length of the following UTF-8
string.
E. Target URL String: Variable-length UTF-8 destination resource.
The sandboxed legacy browser MUST use only the ESD-EID for any
outbound network activity. All such traffic is routed back through
the LL-Entity for validation.
2.1.5. Separation of Concerns between DHI and Agents
To preserve decoupling across the architectural stack,
implementations MUST enforce a separation between the DHI and
downstream application layers (e.g., Large Language Model core
workflows).
+-------------------------------------------------+
| Deterministic Hypermedia Interpreter (DHI) |
+-------------------------------------------------+
|
(Executes Pipeline [1] to [5])
|
v
+-------------------------------------------------+
| [2.5.1] The Ingestion Interface Boundary (IIB) |
| Validates, Canonicalizes & Buffers |
+-------------------------------------------------+
|
(Unified Semantic Ingestion Vector)
|
v
+-------------------------------------------------+
| Downstream LLM Core / Schema Processing |
+-------------------------------------------------+
Gebauer Expires 29 January 2027 [Page 16]
Internet-Draft IACP - DHI - ERP July 2026
2.1.5.1. The Ingestion Interface Boundary (IIB)
The DHI framework terminates structurally at the Ingestion Interface
Boundary (IIB). The responsibilities of the IACP layer within this
boundary are strictly limited to the following operational tasks:
1. Transport Termination: Managing network sockets, executing
pathdiscovery, processing Link headers, and enforcing HRP/
APEalgorithms.
2. Payload Canonicalization: Stripping transport headers,
resolvingmulti-hop DAG data fragments, and assembling raw
incoming streamsinto a unified, sequential memory buffer.
3. Structure Validation: Verifying that incoming data objects
matcheither the native ANML specification invariants or the
fallbacklegacy tree representation before state delivery.
2.1.5.2. Unified Semantic Ingestion Vector (USIV)
Data transition across the IIB into the application layer MUST occur
exclusively via the standardized Unified Semantic Ingestion Vector
(USIV). The DHI assembles the USIV with the following structure:
USIV = { Source_EID, Target_URI, Payload_Byte_Length, Payload_Pointer
}
A. Source_EID: 32-byte cryptographic identifier of the origin
infrastructure node.
B. Target_URI: Variable-length UTF-8 descriptor of the historical
retrieval coordinate.
C. Payload_Byte_Length: 4-byte unsigned integer declaring the
precise byte length of the canonicalized payload allocation block.
D. Payload_Pointer: Reference to the raw, unmodified ANML markup
stream or legacy fallback data block in the local volatile heap.
2.1.6. ANML Support and Integration
The Deterministic Hypermedia Interpreter (DHI) processes content in
the Agentic Notation Markup Language (ANML) as defined in
[I-D.jeskey-anml]. ANML provides a machine-first markup language for
agent-to-agent and agent-to-service communication, describing
content, intent, interactions, constraints, state, and persona
guidance.
Gebauer Expires 29 January 2027 [Page 17]
Internet-Draft IACP - DHI - ERP July 2026
IACP and ANML are complementary:
* IACP provides the routing, identity, mobility, and session
management layer (EID, ERP, PSS).
* ANML provides the content, interaction, and knowledge exchange
layer (actions, constraints, knowledge, persona).
This separation of concerns allows agents to benefit from IACP's
robust transport and identity framework while using ANML's
deterministic content model.
2.1.6.1. ANML Serializations
ANML defines two normative serializations [I-D.jeskey-anml]:
* XML: application/anml+xml (RECOMMENDED for human authoring)
* JSON: application/anml+json (RECOMMENDED for programmatic
generation)
Both serializations are semantically equivalent. An ANML document in
either serialization conveys the same content, interactions,
constraints, state, and persona guidance.
A conforming IACP implementation:
* MUST accept both application/anml+xml and application/anml+json as
valid ANML payloads in PSS_DATA_STREAM frames.
* SHOULD indicate supported ANML serializations during session
establishment via the "accept-anml" transport parameter.
* MUST treat an unrecognized ANML serialization as a protocol error
and terminate the session.
2.1.6.2. ANML Discovery
Services that support ANML MAY advertise their ANML documents using
the following mechanisms defined in [I-D.jeskey-anml]:
1. Well-Known URI: /.well-known/anml [RFC8615]
2. HTTP Link Header: Link: </anml>; rel="alternate";
type="application/anml+xml"
3. DNS SRV Record: _anml._tcp.{domain}
Gebauer Expires 29 January 2027 [Page 18]
Internet-Draft IACP - DHI - ERP July 2026
4. HTML Link Element: <link rel="alternate" type="application/
anml+xml">
The DHI's ingestion pipeline uses these discovery mechanisms in the
following order:
a. DNS SRV Evaluation: Queries _anml._tcp.{domain} to discover
agent-native endpoints. b. Well-Known Evaluation: Issues a request
to /.well-known/anml. c. Link Header Sniffing: Scans response
headers for RFC 8288 Link entries pointing to ANML resources.
If multiple discovery mechanisms are available, the DHI MUST prefer
the DNS SRV record over the well-known URI, and the well-known URI
over the Link header. This preference hierarchy ensures that
operators can control discovery at the most appropriate layer.
2.1.6.3. ANML Document Structure and IACP Integration
An ANML document [I-D.jeskey-anml] consists of the following
sections, each of which maps to IACP components:
| ANML Section | IACP Component | Usage |
|--------------|---------------------|--------------------------------|
| head | Session context | Routing and metadata |
| constraints | LL-Entity | Disclosure enforcement |
| state | PSS state | Workflow reconciliation |
| interact | ERP | Action resolution |
| knowledge | PSS_DATA_STREAM | Information exchange |
| persona | DHI | Behavioral guidance |
| aesthetic | DHI | Visual identity guidance |
| body | DHI | Content processing |
| footer | LL-Entity | Rights enforcement |
| status | PSS | Operation outcome |
The following normative mappings apply:
* The <action> element's endpoint attribute MUST resolve to a valid
IACP EID or transport locator via the ERP.
* The <ask> element's action attribute MUST reference an "action"
that MUST be executable within the current PSS context.
* The <state> section MUST be reconciled with the PSS sequence
vector to ensure consistency.
* The <constraints> section MUST be evaluated by the LL-Entity
before any "answer" is transmitted.
Gebauer Expires 29 January 2027 [Page 19]
Internet-Draft IACP - DHI - ERP July 2026
2.1.6.4. Content Equivalence and ANML
The Equivalence Verification Metric (EVM) applies to ANML documents
as follows:
1. The ANML document is canonicalized according to the rules in
[I-D.jeskey-anml] (Normative Equivalence).
2. The canonicalized representation is used as the input for EVM
computation.
3. The SHA-256 hash comparison operates on the canonicalized ANML
representation.
This ensures that content equivalence is maintained regardless of
whether the ANML document was received as XML or JSON.
2.1.6.5. ANML-Specific Error Handling
The following ANML-specific error conditions MUST be handled by the
DHI:
* Malformed ANML Document: If the ANML document is not well-formed
XML or valid JSON, the DHI MUST transition to legacy path
execution and generate a Hand-off Context Object (HCO).
* Unsupported ANML Version: If the ANML document specifies a version
not supported by the DHI, the DHI SHOULD attempt best-effort
processing and SHOULD inform the user.
* Missing ANML Sections: If critical sections (head, body) are
missing, the DHI MUST treat the document as incomplete and
transition to problem cache.
* Constraint Violation: If a <disclosure> constraint is violated
during an <answer> submission, the LL-Entity MUST drop the packet
and propagate a blacklisting broadcast.
2.1.6.6. ANML Transport Parameters
The following IACP transport parameters are defined for ANML
negotiation:
Gebauer Expires 29 January 2027 [Page 20]
Internet-Draft IACP - DHI - ERP July 2026
| Parameter ID | Name | Description |
|--------------|------------------------|-----------------------------|
| 0x0005 | ANML_SUPPORTED_VERSIONS| Comma-separated ANML |
| | | versions supported |
| 0x0006 | ANML_PREFERRED_SERIAL | Preferred ANML serialization|
| | | ("xml" or "json") |
| 0x0007 | ANML_MAX_DOCUMENT_SIZE | Maximum ANML document size |
| | | in bytes (default: 1MB) |
| 0x0008 | ANML_MAX_NESTING_DEPTH | Maximum element nesting |
| | | depth (default: 32) |
These parameters are negotiated during PSS establishment and MUST be
respected by both endpoints.
2.2. EID Routing Protocol (ERP) - Subprotocol
2.2.1. Protocol Entities and Abstraction Layer
2.2.1.1. Autonomous Agent Instance (AAI)
An Autonomous Agent Instance (AAI) constitutes the application-layer
endpoint within the IACP network architecture. An AAI executes logic
autonomously and initiates or consumes network transactions via
Persistent State Sessions (PSS). On the wire protocol level, an AAI
is uniquely identified by its assigned cryptographic Ephemeral Agent
Identity (EID). The AAI acts as an isolated security domain; its
internal execution states, memory spaces, and local application
contexts MUST remain strictly decoupled from other AAIs operating on
the same host infrastructure.
2.2.1.2. Local Loopback Layer Entity (LL-Entity)
The Local Loopback Layer Entity (LL-Entity) is the abstract,
platform-agnostic shim layer operating on the local host to manage
cryptographic identities and session states. Positioned between the
AAI and the transport network, the LL-Entity acts as an identity
mapping shim. It handles the local allocation of EIDs, manages
local-to-global network bindings, and performs the cryptographic
encapsulation of outbound data streams.
The protocol defines the LL-Entity strictly as a functional network
boundary exchanging data via a defined local wire format.
Implementations MUST ensure the LL-Entity isolates routing contexts
without utilizing volatile operating system metadata (such as PIDs).
The exact engineering realization (e.g., user-space process, kernel
module, or shared memory boundary) is out of scope.
Gebauer Expires 29 January 2027 [Page 21]
Internet-Draft IACP - DHI - ERP July 2026
2.2.1.3. Distributed Hash Table (DHT) & Global Directory Quorum
The Distributed Hash Table (DHT) and the Global Directory Quorum form
the decentralized overlay network of the IACP infrastructure. The
DHT serves as a tamper-proof, globally distributed directory
repository responsible for storing, propagating, and validating the
authoritative mappings between an AAI's logical EID and its transient
physical transport endpoint (IP address).
A Global Directory Quorum consists of a mathematically defined subset
of independent overlay nodes responsible for achieving consensus on
mapping registrations, processing updates, and validating
cryptographic proofs such as Proof of Malfeasance (PoM) tokens. AAIs
interact with the DHT overlay indirectly through the local LL-Entity
or via explicit routing headers to discover peer endpoints and
establish verified multi-hop connections.
2.2.2. Session Cryptography and Isolation Mechanics
2.2.2.1. Ephemeral Agent Identity (EID)
An Ephemeral Agent Identity (EID) acts as the unique, stable
cryptographic identifier for an Autonomous Agent Instance (AAI)
within the IACP routing domain. The LL-Entity generates an
asymmetric cryptographic key pair using the Ed25519 signature scheme
for each unmapped context. The canonical EID string is defined as
the truncated cryptographic hash of the raw public key:
EID = Public_Key
The EID is identical to the Ed25519 public key to provide a self-
certifying identifier that can be directly used for signature
verification and DHT routing.
The private key remains strictly within the storage bounds of the LL-
Entity and MUST NOT be exposed to the AAI. The AAI utilizes the
public EID to sign network transactions implicitly by issuing
standardized control frames to the local channel interface.
2.2.2.2. Instance Authentication Mechanism (IAT)
To achieve strict local host isolation and prevent session hijack
vulnerabilities stemming from reused or recycled operating system
parameters (e.g., Process IDs), the ERP enforces an unforgeable local
token architecture. Upon initial context initialization, the LL-
Entity constructs a high-entropy, 256-bit Instance Authentication
Token (IAT).
Gebauer Expires 29 January 2027 [Page 22]
Internet-Draft IACP - DHI - ERP July 2026
IAT = CSPRNG(256)
The LL-Entity binds the generated EID directly to this unique IAT.
For all subsequent local frame transmissions over the loopback layer
interface, the AAI MUST include the designated IAT within the
encapsulation header. The LL-Entity validates the presence and
mathematical correctness of the token before modifying any local
routing table states or performing cryptographic data
transformations.
The local loopback encapsulation frame passed across the interface
boundary between the AAI and the LL-Entity MUST conform to the
following 32-bit aligned binary wire format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance Authentication Token (IAT) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Inner Type | Reserved | Inner Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Inner IACP Base Header & Payload |
| (Variable Length) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Descriptions: * Instance Authentication Token (IAT): 32 bytes
of high-entropy random data used to authenticate the local AAI
context. * Version: 4 bits (currently 0x1). * Inner Type: 8 bits
defining the encapsulated IACP message type. * Reserved: 4 bits, MUST
be zero. * Inner Payload Length: 16 bits declaring the length of the
inner payload in bytes.
2.2.2.3. Liveness Monitoring and "Context Garbage" Collection
To secure local resources and prevent memory state exhaustion from
orphaned cryptographic contexts (e.g., following an abrupt
application-layer crash or uncoordinated termination of an AAI), the
ERP specifies an automated liveness monitoring mechanism.
1. ERP_KEEPALIVE Invariant: The AAI MUST transmit a periodic
ERP_KEEPALIVE control frame to the LL-Entity over the local wire
format channel at fixed intervals of T_alive = 30 seconds.
Gebauer Expires 29 January 2027 [Page 23]
Internet-Draft IACP - DHI - ERP July 2026
2. Verification: Each ERP_KEEPALIVE frame MUST carry the valid
Local_IAT associated with the respective session context.
3. Garbage Collection: If the LL-Entity detects a continuous silent
period exceeding the timeout limit of T_timeout = 90 seconds for
a specific context, the active session state is marked as stale.
The LL-Entity MUST instantly purge the associated cryptographic
material, wipe the keys from memory, and initiate an automated
global deregistration routine within the DHT overlay to
invalidate the stale EID-to-IP mapping.
2.2.3. Protocol Operations
2.2.3.1. Local Initialization and Allocation Phase (ERP_INIT /
ERP_ALLOC)
The interaction between an Autonomous Agent Instance (AAI) and the
Local Loopback Layer Entity (LL-Entity) occurs exclusively via
standardized local control frames over an abstract system-internal
channel interface using a fixed local wire format.
1. ERP_INIT: The AAI transmits an ERP_INIT frame containing a
cryptographically secure random 256-bit initialization nonce
(N_init) to request a local routing context.
2. Allocation & Token Generation: The LL-Entity validates the
request, generates the asymmetric Ed25519 key pair for the
Ephemeral Agent Identity (EID), and calculates the unique 256-bit
Instance Authentication Token (IAT).
3. ERP_ALLOC: The LL-Entity responds by transmitting an ERP_ALLOC
frame over the local interface. This frame contains the mirrored
nonce (N_init), the newly allocated public EID, and the assigned
Local_IAT.
+-------+ +-----------+
| AAI | | LL-Entity |
+-------+ +-----------+
| |
| --- ERP_INIT [N_init] ----------------------> |
| | [Generates EID
| <-- ERP_ALLOC [N_init, Source_EID, Local_IAT] | & IAT]
| |
Upon receipt, the AAI verifies that the returned nonce matches
N_init. All subsequent transactions issued by the AAI MUST supply
the assigned Local_IAT to authenticate against the LL-Entity.
Gebauer Expires 29 January 2027 [Page 24]
Internet-Draft IACP - DHI - ERP July 2026
2.2.3.2. Global Directory Mapping (ERP_REGISTER)
Once the local allocation phase is complete, the logical identity
must be propagated to the global overlay network to enable external
packet routing.
1. Transmission: The LL-Entity generates an outbound ERP_REGISTER
control frame and routes it to the Distributed Hash Table (DHT)
overlay network.
2. Payload Structure: The registration packet encapsulates the
public EID, the current physical transport endpoint (current
source IP address), a newly initialized Generation Counter (set
to 0), and a cryptographic signature covering the binding:
Signature = Sign_Ed25519( Private_Key, EID || Current_IP || Generation_Counter )
1. Global Quorum Verification: The responsible Global Directory
Quorum nodes receive the frame, verify the Ed25519 signature
against the public EID, and commit the authoritative mapping
entry into the decentralized ledger.
2.2.3.3. Transition Control and Core States (Switch Point)
The LL-Entity manages the life cycle of each active EID mapping
context via a strict finite state machine. The operational
transition is regulated at the central "Switch Point".
Gebauer Expires 29 January 2027 [Page 25]
Internet-Draft IACP - DHI - ERP July 2026
+------------+
| UNBOUND |
+------------+
|
| ERP_INIT / ERP_ALLOC
v
+------------+
| ALLOCATED |
+------------+
|
| ERP_REGISTER (Outbound)
v
+------------+
| TRANSITION | <--- [Buffers Outbound Application Data]
+------------+
|
| DHT Quorum Confirmation / ACK
v
+------------+
| BOUND | <--- [Flushes Buffer / Active Streaming]
+------------+
State Definitions: * UNBOUND: The default state. No local
cryptographic context or allocation exists. * ALLOCATED: The key pair
and Local_IAT are active on the host, but the mapping has not yet
been announced to the global network. * TRANSITION: The ERP_REGISTER
frame has been dispatched to the DHT overlay. The binding is pending
confirmation. To prevent packet loss, the LL-Entity MUST intercept
all outbound application data generated by the AAI during this
transit phase and hold it in a dedicated local FIFO buffer. * BOUND:
The DHT directory quorum has confirmed registration. The Switch
Point activates the encapsulation pipeline, instantly flushes the
local FIFO buffer, and transitions the stream into active network
transmission.
2.2.3.4. Application Data Encapsulation and Transport (ERP_STREAM)
In the BOUND state, all application layer payload generated by the
AAI is encapsulated into standard IACP data packets to isolate the
active Persistent State Session (PSS).
The wire format for data transport requires the encapsulation of the
logical routing headers directly before the payload field:
+------------------+-------------------+-----------------+------------+
| Source IP Header | IACP Base Header | ERP Routing Hdr |Encapsulated|
|(Physical Vector) | (Demux / Flags) |(Logical EID/Gen)| PSS Payload|
+------------------+-------------------+-----------------+------------+
Gebauer Expires 29 January 2027 [Page 26]
Internet-Draft IACP - DHI - ERP July 2026
The ERP Routing Header explicitly defines the Source_EID,
Destination_EID, and the current Generation_Counter. Physical
transit nodes route the packet solely based on the external IP
header. The receiving LL-Entity strips the transport and routing
headers, performs context validation, and forwards the raw PSS
payload exclusively to the isolated target AAI matching the
destination parameters.
2.2.3.5. Identity Evolution
To support legitimate software updates of an Autonomous Agent
Instance without breaking the continuity of its cryptographic
identity, the protocol defines a controlled identity evolution
mechanism.
When the Application Digest of an agent changes (e.g. after a code
update), the agent MUST send an ERP_EVOLVE control frame to the LL-
Entity before resuming normal operation.
ERP_EVOLVE (Type 0x16)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x16) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current App-Digest [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Evolution Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AIRK Signature (Ed25519) [64 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.4. Secure Handshake and Connection Management
2.2.4.1. Dual-Cookie Handshake Protection
To prevent state-spoofing, resource exhaustion, and blind packet-
injection attacks during the initialization of a Persistent State
Session (PSS), the ERP enforces a mandatory Dual-Cookie handshake
mechanism across the transport layer.
Gebauer Expires 29 January 2027 [Page 27]
Internet-Draft IACP - DHI - ERP July 2026
1. Session Initiation (PSS_INIT): The initiator constructs a control
frame containing an Initiator Cookie (I-Cookie). The I-Cookie
MUST be an 8-byte, high-entropy cryptographically secure random
value. At this stage, the Responder Cookie (R-Cookie) field
within the frame is unassigned and MUST be zero-filled
(0x0000000000000000).
2. Session Negotiation (PSS_NEG): Upon receipt, the responder
extracts the I-Cookie, allocates transient handshake resources,
and generates its own independent 8-byte cryptographically secure
random value, designated as the Responder Cookie (R-Cookie). The
responder transmits a PSS_NEG frame back to the initiator,
containing both the original I-Cookie and the new R-Cookie.
3. Session Confirmation (PSS_ACK): The initiator verifies the
returned I-Cookie. It completes the state binding by
transmitting a PSS_ACK frame. Every subsequent data and control
packet transmitted within this specific PSS session MUST carry
the identical, invariant combination of
[I-Cookie || R-Cookie]
in its session header. Any incoming packet where the R-Cookie is
zero-valued after the initialization phase, or does not match the
established state record, MUST be instantly discarded without
processing.
2.2.4.2. Local Session Table Indexing and Collision Prevention
The local LL-Entity maintains all pending, active, and transient
handshake states within a specialized internal routing and session
hash table.
To eliminate the "Cookie Lookup Paradox"-wherein multiple independent
AAIs sharing the identical host infrastructure and the same
underlying network-side Source_EID could experience session cross-
over or overwrites due to an accidental 64-bit cookie hash collision-
the lookup index calculation MUST bind the local host isolation
parameter.
The unique internal table indexing key (Local_Session_Key) MUST be
computed using the following mathematical invariant:
Local_Session_Key = SHA256( I-Cookie || R-Cookie || Source_EID || Local_IAT )
By factoring the unforgeable, high-entropy 256-bit Local_IAT
(Instance Authentication Token) directly into the cryptographic hash
function, perfect isolation is maintained on the host. Even in the
Gebauer Expires 29 January 2027 [Page 28]
Internet-Draft IACP - DHI - ERP July 2026
event of an identical network-side cookie match across separate
applications, the resulting hash indices remain strictly orthogonal,
structurally preventing data cross-over within the LL-Entity cache.
The following diagram illustrates the deterministic isolation and
validation pipeline executed by the LL-Entity upon processing an
incoming transport packet to prevent the Cookie Lookup Paradox:
+-----------------------------------------+
| Incoming Inbound Network Packet |
+-----------------------------------------+
|
v
+-----------------------------------------+
| Extract: I-Cookie, R-Cookie, Source_EID |
+-----------------------------------------+
|
v
+-----------------------------------------+
| Find matching Local_IAT bound to the |
| active destination context registration |
+-----------------------------------------+
|
v
+-----------------------------------------+
| Compute: Local_Session_Key = |
| SHA256(I-Cookie || R-Cookie || |
| Source_EID || Local_IAT) |
+-----------------------------------------+
|
v
/-------------------------\
/ Is Local_Session_Key \
< found in the active >
\ Session Hash Table? /
\-------------------------/
/ \
YES / \ NO
v v
/-----------------\ +-----------------------+
/ Collision \ | Silent Packet Drop |
< Detected in > | (Context Unmapped/ |
\ Index Bucket? / | Handshake Invalid) |
\-----------------/ +-----------------------+
/ \
NO / \ YES
v v
+------------+ +-------------------------------------+
Gebauer Expires 29 January 2027 [Page 29]
Internet-Draft IACP - DHI - ERP July 2026
| Forward to | | Enforce Cryptographic Validation: |
| Isolated | | Verify structural Ed25519 Signature |
| Target AAI | | of Source_EID on frame data |
+------------+ +-------------------------------------+
|
v
/-------------------------\
/ Is Signature valid \
< for active context? >
\ /
\--------------------------/
/ \
YES / \ NO
v v
+------------+ +-----------------------+
| Forward to | | Drop & Raise Security |
| Target AAI | | Alert / Log Anomaly |
+------------+ +-----------------------+
If an internal table collision is detected during lookup operations,
the LL-Entity freezes any immediate state mutations for that specific
bucket, bypasses the fast-path cache, and enforces a synchronous
cryptographic validation: the incoming frame MUST be validated
against an explicit Ed25519 signature of the Source_EID bound to that
context before any state transition is authorized.
2.2.4.3. Proof-of-Work Binding for Dual-Cookie Handshake
The Dual-Cookie handshake protects against state-spoofing and packet-
injection attacks, but does not prevent resource exhaustion from a
flood of PSS_INIT messages. An attacker can send a large number of
PSS_INIT frames, forcing the responder to allocate handshake state
and compute PSS_NEG responses for each attempt. This section defines
a PoW requirement for PSS_INIT that shifts the cost of handshake
attempts to the initiator.
2.2.4.3.1. PoW Token in PSS_INIT
The PSS_INIT frame (Type 0x08) is extended with a PoW token
consisting of:
* PoW Nonce: 8-byte random value generated by the initiator.
* PoW Target: 4-byte difficulty target (number of leading zero bits
required).
* Timestamp: 8-byte UNIX timestamp to prevent replay attacks.
Gebauer Expires 29 January 2027 [Page 30]
Internet-Draft IACP - DHI - ERP July 2026
The PoW token is calculated as:
PoW_Token = SHA-256(I-Cookie || Initiator_EID || Timestamp || Nonce)
The initiator MUST find a Nonce such that the resulting SHA-256 hash
has at least D_req leading zero bits. The difficulty D_req is
negotiated as follows:
* Baseline Difficulty: D_base = 16 bits (RECOMMENDED default).
* Dynamic Adjustment: The responder MAY increase the difficulty
based on local load:
D_req = D_base + floor(gamma * (Queue_Current / Queue_Max))
Where gamma = 8, Queue_Current is the pending handshake queue
length, and Queue_Max is the maximum allowed queue length
(default: 1024).
* Maximum Difficulty: D_req MUST NOT exceed 32 bits to prevent
excessive computation on resource-constrained devices.
The responder includes the expected difficulty D_req in its DHT
advertisements to allow initiators to pre-compute PoW tokens before
initiating a handshake.
2.2.4.3.2. PoW Validation and State Allocation
Upon receiving a PSS_INIT, the responder MUST validate the PoW token
before allocating any handshake state:
1. Verify that the Timestamp is within T_fresh = 5 minutes of the
current time.
2. Compute SHA-256(I-Cookie || Initiator_EID || Timestamp || Nonce)
and verify the hash has at least D_req leading zero bits.
3. If validation fails, the responder MUST silently drop the
PSS_INIT without allocating state or sending a PSS_NEG. No error
response is sent to prevent amplification attacks.
4. If validation succeeds, the responder proceeds with the Dual-
Cookie handshake.
Gebauer Expires 29 January 2027 [Page 31]
Internet-Draft IACP - DHI - ERP July 2026
The responder MUST NOT allocate persistent handshake state until
after PoW validation succeeds. The handshake entry is valid for
T_handshake = 10 seconds; if no PSS_ACK is received within this
window, the entry is purged. The responder SHOULD limit concurrent
handshake entries per source IP to N_max = 10.
Responders SHOULD cache validated PoW tokens for T_cache = 60
seconds. The cache key is (Initiator_EID, I-Cookie, Timestamp).
This prevents repeated computation for retransmitted PSS_INIT
messages.
2.2.4.3.3. Lightweight Fallback for Trusted Peers
To reduce latency for trusted peers, nodes MAY maintain a local list
of trusted EIDs (e.g., from previous successful sessions). If the
Initiator_EID is on the trusted list and the I-Cookie is fresh, the
responder MAY bypass PoW validation. Trusted EID entries have a TTL
of T_trust = 1 hour. Trusted EIDs that exhibit anomalous behavior
(e.g., excessive handshake attempts) MUST be evicted immediately.
2.2.4.3.4. Normative Notes
Conforming implementations:
* MUST implement PoW validation for PSS_INIT messages.
* MUST support a baseline difficulty of D_base = 16 bits.
* MUST NOT allocate handshake state before PoW validation succeeds.
* MUST reject PSS_INIT messages with timestamps older than T_fresh =
5 minutes.
* MUST NOT send error responses for failed PoW validation to prevent
amplification attacks.
* MAY implement the trusted peer bypass mechanism.
* MAY implement dynamic difficulty adjustment.
2.2.5. Resource Governance
Gebauer Expires 29 January 2027 [Page 32]
Internet-Draft IACP - DHI - ERP July 2026
2.2.5.1. Coordinated Network Churn
When a host infrastructure switches its physical network interfaces
or encounters a high-frequency IP address assignment change, the
local LL-Entity MUST execute a coordinated network churn routine to
maintain path reachability for all active Persistent State Sessions
(PSS).
1. Detection and Incrementation: Upon interface migration, the LL-
Entity locks immediate outbound queue operations for all local
AAIs. It retrieves the current authoritative Generation_Counter
associated with the active EID context and increments its value
by exactly 1:
Generation_Counter_New = Generation_Counter_Old + 1
2. Transmission: The LL-Entity constructs a specialized
MIGRATION_VECTOR control frame. This frame encapsulates the
Source_EID, the newly assigned physical transport endpoint (the
new destination IP address), and the incremented
Generation_Counter_New.
3. Authentication: The entire block is structurally signed using the
private key of the EID:
Migration_Signature = Sign_Ed25519( Private_Key, Source_EID || New_IP || Gen_Counter_New )
The LL-Entity instantly multi-casts the validated MIGRATION_VECTOR
frame to the Global Directory Quorum (DHT) and mirrors it
asynchronously to all known active remote peer endpoints recorded in
the local session table.
2.2.5.2. Generation Counting and Cache Invalidation Rules
To mitigate out-of-order packet arrival, racing routing updates, and
stale cache exploits across intermediate transport nodes, the ERP
implements strict Generation Counting evaluation logic.
All remote entities (peer LL-Entities and DHT nodes) maintaining
localized routing and mapping caches MUST evaluate incoming packet
headers against the following absolute validation pipeline:
Let Cache_Gen = Stored Generation Counter for Source_EID Let
Packet_Gen = Generation Counter extracted from the incoming ERP
Routing Header
Gebauer Expires 29 January 2027 [Page 33]
Internet-Draft IACP - DHI - ERP July 2026
+------------------------+
| Incoming Packet Arrives|
+------------------------+
|
v
+-----------------------+
| Is Packet_Gen > |
| Cache_Gen? |
+-----------------------+
/ \
YES / \ NO
v v
+-----------------------+ +-------------------------------+
| Update Cache Mapping | | Is Packet_Gen == |
| & Process Packet | | Cache_Gen? |
+-----------------------+ +-------------------------------+
/ \
YES / \ NO
v v
+-----------------------+ +-----------------------+
| Accept and Forward | | SILENTLY DISCARD |
| Payload | | (Stale Routing/Race) |
+-----------------------+ +-----------------------+
1. Cache Invalidation Rule: If Packet_Gen > Cache_Gen, the remote
node MUST instantly invalidate its existing cache entry. The
node updates its record with the new physical transport endpoint
(IP address) and sets Cache_Gen = Packet_Gen. Any queued data
frames using the older mapping are instantly flushed.
2. In-Sequence Processing: If Packet_Gen == Cache_Gen, the
topological vector is assumed stable. The packet is processed or
forwarded normally.
3. Stale Frame Dropping: If Packet_Gen < Cache_Gen, the incoming
packet is structurally identified as a delayed, out-of-order, or
illegitimate routing frame. The node MUST silently drop the
packet without modifying local tables or executing cryptographic
steps, entirely eliminating desynchronization locks caused by
network jitter.
2.2.6. Fault Tolerance, Resiliency, and Degraded Operations
Gebauer Expires 29 January 2027 [Page 34]
Internet-Draft IACP - DHI - ERP July 2026
2.2.6.1. Caching-Lock Mitigations and ANML-Backoff Mechanics
When an LL-Entity encounters downstream resolution failures,
directory lookup timeouts, or transient blockades during an ANML
query execution, it MUST prevent local context deadlocks and cache-
locking loops. Instead of maintaining a blocking state that starves
local resources, the LL-Entity transitions the affected routing
context into the STATE_ANML_DEGRADED mode.
Once in STATE_ANML_DEGRADED, the LL-Entity enforces an isolated, non-
blocking, exponential retry backoff scheme with integrated
cryptographic jitter. The retransmission or re-query interval
(T_retry) MUST be calculated using a secure hardware random number
generator (CSPRNG) according to the following protocol formula:
T_retry = Min(T_max, T_base * (2^attempts) ) + Cryptographic_Jitter
Where: * T_base = 2 seconds (the initial protocol backoff constant).
* attempts = the incremental count of continuous failed resolution
requests. * T_max = 300 seconds (the absolute upper boundary
ceiling). * Cryptographic_Jitter = A random value bytes derived
directly from a local hardware CSPRNG, bounded within the interval
[0, 15] seconds.
2.2.6.2. Asynchronous Backoff Reset Vectors
To resolve the fatal desynchronization race condition occurring when
a target EID migrates its physical transport endpoint (high-frequency
network churn) while an originating node remains trapped within an
active exponential backoff loop, the ERP implements a mandatory
cross-state interrupt vector.
An LL-Entity operating under an active STATE_ANML_DEGRADED backoff
timer for a specific destination EID MUST continuously listen for
out-of-band network reachability updates.
The active backoff timer for a specific destination context MUST be
instantly aborted, purged, and reset to zero if either of the
following asynchronous events occurs:
1. Receipt of a structurally valid, cryptographically signed
MIGRATION_VECTOR originating from the target EID.
2. Ingress of an authenticated IACP data frame carrying an ERP
Routing Header where the Generation_Counter is strictly greater
than the previously cached sequence value for that destination
EID:
Gebauer Expires 29 January 2027 [Page 35]
Internet-Draft IACP - DHI - ERP July 2026
Incoming Packet_Gen > Cache_Gen
Upon trigger execution, the LL-Entity clears the STATE_ANML_DEGRADED
flag for this session, restores the context to the active BOUND
processing state, and immediately schedules a clean resolution
handshake using the fresh topological coordinates. This structural
interrupt entirely prevents permanent routing desynchronization
locks.
2.2.7. Decentralized Security Governance and Slashing
2.2.7.1. Proof of Malfeasance (PoM) Specification
The IACP overlay network enforces node accountability through
automated, non- repudiable cryptographic evidence termed a Proof of
Malfeasance (PoM) ticket. A PoM ticket structurally identifies
routing violations, specifically equivocation anomalies where a
single EID public key signs two distinct, conflicting topological
mappings (e.g., separate IP destinations or desynchronized Generation
Counters) within the same logical epoch.
To be considered authoritatively valid by the Global Directory
Quorum, a PoM ticket MUST compile the following immutable fields:
PoM_Ticket = {
Target_EID: Public Key of the accused entity,
Header_Fragment_A: [ IP_Vector_A || Gen_Counter_A || Signature_A ],
Header_Fragment_B: [ IP_Vector_B || Gen_Counter_B || Signature_B ],
Timestamp: Cluster-synchronized verification time
}
Validation Invariant: The quorum nodes parse both fragments. A
ticket is unconditionally valid if and only if: 1. Signature_A and
Signature_B evaluate as mathematically true against the identical
Target_EID public key. 2. Header_Fragment_A is structurally non-
identical to Header_Fragment_B. Malicious nodes attempting to frame
an honest curator by injecting fragmented, corrupted, or incomplete
signatures are blocked because tickets failing this strict signature
verification are instantly dropped without state mutation.
2.2.7.2. Two-Phase Slashing Escrow (2PSE)
To mitigate Denial-of-Service (DoS) vectors arising from malicious or
coordinated false denunciation attempts, the ERP implements a Two-
Phase Slashing Escrow (2PSE) protocol. Upon processing a valid PoM
ticket, the Global Directory Quorum MUST NOT instantly drop the
target network state or purge its stake. Instead, the quorum
transitions the target namespace into a transient state designated as
Gebauer Expires 29 January 2027 [Page 36]
Internet-Draft IACP - DHI - ERP July 2026
STATE_CHALLENGED.
The STATE_CHALLENGED lifecycle is governed by two sequential
intervals:
1. Escrow Window (T_escrow = 120 Epochs / 1 Hour): The target
entity's directory mapping is isolated. The quorum initiates an
automated challenge-response loop, allowing the accused node to
submit a counter-proof (PSS_REVOCATION_REBUTTAL) demonstrating
cryptographic context validity or authorized key-revocation
states.
2. Resolution Phase: If a verified rebuttal is received within
T_escrow, the STATE_CHALLENGED flag is cleared, restoring normal
operations. If T_escrow expires without a valid rebuttal, the
network transition is finalized: the node is hard-blocked, its
cryptographic identity is blacklisted across the DHT, and its
associated financial stake is irrevocably slashed.
2.2.7.3. Degraded Multi-Path Routing in Escrow
To eliminate the security vacuum wherein a truly compromised node
could exploit the T_escrow window to perform unchecked Man-in-the-
Middle (MitM) or Blackhole attacks against active application
streams, the protocol enforces a structural degradation of the
routing pipeline for any context flagged as STATE_CHALLENGED.
During the escrow interval, unconstrained direct single-path routing
through the challenged node is strictly prohibited. Instead, the
initiating LL-Entity MUST execute a mandatory Degraded Multi-Path
Routing procedure:
Gebauer Expires 29 January 2027 [Page 37]
Internet-Draft IACP - DHI - ERP July 2026
+-----------------------+
| Outbound Data Frame |
+-----------------------+
|
v
+-----------------------+
| Destination EID in |
| STATE_CHALLENGED? |
+-----------------------+
/ \
YES / \ NO
v v
+-------------------------+ +-------------------------+
| Enforce Multi-Path | | Standard Single-Path |
| Fragmentation & Mirror | | Direct Routing |
+-------------------------+ +-------------------------+
/ | \
/ | \
v v v
+-----------+ +-----------+ +-----------+
| Path 1 | | Path 2 | | Path 3 |
| (Target) | | (Quorum A)| | (Quorum B)|
+-----------+ +-----------+ +-----------+
1. Stream Splitting: Outbound data payloads destined for or
traversing a node in STATE_CHALLENGED are structurally cloned and
transformed into parallel, redundant multi-path streams.
2. Quorum Mirroring: The originating LL-Entity routes Path 1
directly through the challenged target node, while simultaneously
mirroring identical payload packets via Path 2 and Path 3 through
separate, uncompromised independent Global Directory Quorum
nodes.
3. End-to-End Consistency: The receiving endpoint reconstructs the
stream using the earliest valid packet arriving from any of the
redundant paths.
If the challenged node drops or modifies payloads during its escrow
phase, the receiving entity immediately detects the data disparity
against the clean quorum paths, discards the corrupted fragment, and
generates an auxiliary verification fault report, preserving
operational continuity.
2.2.7.4. Slashing Thresholds
The Two-Phase Slashing Escrow (2PSE) mechanism enforces the following
thresholds:
Gebauer Expires 29 January 2027 [Page 38]
Internet-Draft IACP - DHI - ERP July 2026
* Escrow Window Duration: T_escrow = 120 epochs (approximately 1
hour). The epoch duration is defined as 30 seconds.
* Slashing Threshold: A target node is slashed if it accumulates
PoM_Count >= 3 within a rolling 24-hour window. The rolling
window is maintained per EID.
* Quorum Confirmation: For a PoM ticket to be considered valid and
trigger the 2PSE process, it MUST be confirmed by at least
k_confirm = 7 independent Global Directory Quorum nodes.
* Appeal Window: The accused node has an appeal window of T_appeal =
T_escrow to submit a counter-proof. Counter-proofs are accepted
up to 1 hour after the escrow window expires if the node can
demonstrate cryptographic context validity.
2.2.8. QUIC Transport Binding
IACP RECOMMENDS the use of QUIC [RFC9000] as the underlying transport
protocol for PSS sessions. This section defines the binding between
IACP and QUIC.
2.2.8.1. ALPN Protocol Identifier
IACP over QUIC uses the ALPN protocol identifier "iacp". This
identifier MUST be used in the TLS ALPN extension during QUIC
handshake.
2.2.8.2. Stream Mapping
IACP PSS sessions use QUIC streams as follows:
* Stream 0 (Control Stream): Used for IACP control frames (PSS_INIT,
PSS_NEG, PSS_ACK, PSS_TEARDOWN, PSS_REVOCATION_PUBLISH). This
stream is bidirectional.
* Streams 1-n (Data Streams): Used for PSS_DATA_STREAM frames. Each
data stream carries a sequence of PSS_DATA_STREAM frames. Data
streams are bidirectional.
* Stream for PSS_REVOCATION_REBUTTAL: This frame is sent on the
control stream (Stream 0) during the challenge phase.
Implementations MUST NOT send IACP frames on unassigned stream IDs.
Gebauer Expires 29 January 2027 [Page 39]
Internet-Draft IACP - DHI - ERP July 2026
2.2.8.3. Connection Migration
QUIC's connection migration capability provides seamless mobility for
IACP sessions. When an agent changes its network interface, the QUIC
connection SHOULD be migrated to the new path without requiring an
IACP-level MIGRATION_VECTOR. However, for backward compatibility
with non-QUIC transports or to propagate the new locator to the DHT,
the IACP MIGRATION_VECTOR frame (Section 4.2.5.1) MUST still be sent.
2.2.8.4. Error Handling
QUIC connection errors (e.g., CONNECTION_CLOSE) are mapped to IACP
session termination. Upon receiving a QUIC CONNECTION_CLOSE, the
IACP implementation MUST:
1. Transition the PSS session to STATE_DISCONNECTED.
2. Attempt to reconcile state upon reconnection using sequence
vector reconciliation (Section 6.4.5).
3. If reconciliation fails, terminate the session with a
PSS_TEARDOWN.
2.2.8.5. TLS Fingerprint
QUIC uses TLS 1.3 for encryption and authentication. The TLS
fingerprint of the peer's certificate (or the raw public key if using
raw public key mode) is used to establish the binding to the IACP
EID. The implementation MUST verify that the TLS fingerprint matches
the EID's public key or the deployment-specific mapping between EID
and X.509 certificate.
2.2.8.6. QUIC Transport Parameters
IACP defines the following QUIC transport parameters for negotiation:
max_float_buf: The maximum floating buffer size (default: 4194304
bytes). This parameter corresponds to MAX_FLOAT_BUF.
t_eval: The evaluation timeout in milliseconds (default: 15000 ms).
This parameter corresponds to T_eval.
sfc_conditions: The SFC conditions block.
These parameters are encoded as TLS extension data during the QUIC
handshake. They are carried in the quic_transport_parameters TLS
extension (type 0x39) as defined in [RFC9000]. The parameters are
encoded as a sequence of TransportParameter structures as specified
Gebauer Expires 29 January 2027 [Page 40]
Internet-Draft IACP - DHI - ERP July 2026
in [RFC9000], each consisting of a parameter ID (2 bytes), a length
(2 bytes), and a value. The parameter IDs for the IACP-specific
parameters are: 0x0001 for max_float_buf, 0x0002 for t_eval, and
0x0003 for sfc_conditions. These IDs align with the IACP Transport
Parameter Registry and MUST be encoded in network byte order.
Implementations that do not support QUIC transport parameters or that
use a different underlying transport protocol MAY negotiate these
parameters through alternative mechanisms, such as PSS- specific
negotiation frames. However, QUIC transport parameters are the
RECOMMENDED method for parameter negotiation when QUIC is used as the
underlying transport.
2.2.9. LL-Entity Local Interface Specification
The Local Loopback Layer Entity (LL-Entity) communicates with the
Autonomous Agent Instance (AAI) via a local interface. This section
specifies the local wire format and communication channel.
2.2.9.1. Communication Channel
The LL-Entity and AAI communicate over a local channel. The
following channel types are supported:
* Unix Domain Socket (RECOMMENDED): A stream-oriented socket located
at a well-known path (e.g., /var/run/iacp/ll-entity.sock). This
provides fast, reliable communication within the host.
* Shared Memory (OPTIONAL): A memory-mapped region with a circular
buffer for high-performance data transfer. This is RECOMMENDED
for high-throughput scenarios.
* Local TCP Loopback (NOT RECOMMENDED): TCP on localhost. This is
NOT RECOMMENDED due to the overhead of TCP and the lack of support
for advanced features like SCM_RIGHTS for file descriptor passing.
2.2.9.2. Local Frame Format
All communication between the AAI and LL-Entity occurs via local
frames. The local frame format is defined in Section 4.2.2.2 and
consists of:
* Instance Authentication Token (IAT): 32 bytes of high-entropy
random data used to authenticate the local AAI context.
* Version: 4 bits (currently 0x1).
* Inner Type: 8 bits defining the encapsulated IACP message type.
Gebauer Expires 29 January 2027 [Page 41]
Internet-Draft IACP - DHI - ERP July 2026
* Reserved: 4 bits, MUST be zero.
* Inner Payload Length: 16 bits declaring the length of the inner
payload in bytes.
* Inner IACP Base Header & Payload: The encapsulated IACP message.
2.2.9.3. Frame Delimitation
For Unix Domain Sockets, frames are delimited by a 4-byte length
prefix before each frame. The length prefix is a big-endian unsigned
32-bit integer. For Shared Memory, frames are written to a circular
buffer with a header indicating the start and end of each frame.
2.2.9.4. Error Handling
If the LL-Entity receives a frame with an invalid IAT, it MUST:
* Drop the frame without further processing.
* Increment a local error counter.
* If the error counter exceeds a threshold (default: 5 errors in 60
seconds), the LL-Entity SHOULD initiate a security alert and
temporarily block the source context.
2.2.9.5. Liveness Monitoring
The ERP_KEEPALIVE mechanism (Section 4.2.2.3) is implemented as
follows on the local interface:
* The AAI MUST send an ERP_KEEPALIVE frame (Inner Type 0x20) every
T_alive = 30 seconds.
* The LL-Entity MUST reset the liveness timer for the corresponding
context upon each ERP_KEEPALIVE.
* If T_timeout = 90 seconds elapses without an ERP_KEEPALIVE, the
LL-Entity purges the context and deregisters the EID from the DHT.
2.2.10. Remote Attestation Integration
IACP integrates with the RATS architecture [RFC9334] to enable agents
to prove their execution environment integrity. This integration
enables agents to attest that they are running in a Trusted Execution
Environment (TEE) or on a platform with specific security properties.
Gebauer Expires 29 January 2027 [Page 42]
Internet-Draft IACP - DHI - ERP July 2026
2.2.10.1. Attestation Evidence in EID Registration
During ERP_REGISTER, the AAI MAY include attestation evidence from
its TEE:
ERP_REGISTER (Type 0x15) with Attestation Extension:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x15) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Current Transport IP [16 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attestation Type (1B) | Attestation Length (4B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TEE Evidence (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attestation Types: - 0x01: EAT Evidence [RFC9711] - 0x02: CWT
Evidence - 0x03: TPM Quote - 0x04: TDX Quote - 0x05: SEV-SNP Report
The LL-Entity SHALL verify the TEE evidence before allowing BOUND
state for sensitive operations.
2.2.10.2. Attestation in PSS Sessions
PSS sessions MAY include periodic attestation refreshes to ensure
ongoing integrity:
PSS_ATTEST (Type 0x23)
Gebauer Expires 29 January 2027 [Page 43]
Internet-Draft IACP - DHI - ERP July 2026
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type (0x23) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attestation Type (1B) | Attestation Length (4B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TEE Evidence (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Peers SHALL verify attestation evidence and MAY downgrade or
terminate sessions if verification fails.
2.2.10.3. Attestation Result Caching
To reduce overhead, attestation results MAY be cached:
* Cache TTL: 300 seconds (configurable per deployment).
* Cache Key: (EID, TEE_Type, Measurements_Hash).
* Cache Entry: Attestation Result (valid/invalid, timestamp,
verifier identity).
Cache invalidation occurs on: - PSS_REVOCATION_PUBLISH with
attestation failure reason. - EID rotation. - TTL expiration.
2.2.10.4. TEE-Specific Measurement Formats
Intel TDX Measurements:
Gebauer Expires 29 January 2027 [Page 44]
Internet-Draft IACP - DHI - ERP July 2026
{
"tee_type": "intel-tdx",
"evidence_type": "eat",
"measurements": {
"rtmr0": "a1b2c3d4e5f6...",
"rtmr1": "f1e2d3c4b5a6...",
"rtmr2": "1a2b3c4d5e6f...",
"rtmr3": "9f8e7d6c5b4a..."
},
"algorithm": "sha384",
"quote": "base64_encoded_quote",
"signature": "base64_ed25519_signature"
}
RTMR semantics: - rtmr0: Initial boot measurements (BIOS, bootloader)
- rtmr1: OS loader and kernel measurements - rtmr2: System
configuration measurements - rtmr3: Application and runtime
measurements
*AMD SEV-SNP Measurements:*
Gebauer Expires 29 January 2027 [Page 45]
Internet-Draft IACP - DHI - ERP July 2026
{
"tee_type": "amd-sev-snp",
"evidence_type": "eat",
"measurements": {
"pcr0": "hex...",
"pcr1": "hex...",
"pcr2": "hex...",
"pcr3": "hex..."
},
"algorithm": "sha384",
"report": "base64_encoded_report",
"signature": "base64_ed25519_signature"
}
**Intel SGX Measurements:**
{
"tee_type": "intel-sgx",
"evidence_type": "eat",
"measurements": {
"mrenclave": "hex...",
"mrsigner": "hex...",
"isv_prod_id": "hex...",
"isv_svn": "hex..."
},
"algorithm": "sha256",
"quote": "base64_encoded_quote",
"signature": "base64_ed25519_signature"
}
2.2.10.5. Verifier Integration
IACP implementations MAY integrate with external attestation
verifiers:
* Local Verifier: TEE evidence is verified locally by the LL-Entity.
* Remote Verifier: TEE evidence is sent to a remote attestation
service.
* Attestation Service: A third-party service that verifies TEE
evidence and returns Attestation Results.
The Attestation Result is a signed statement:
Gebauer Expires 29 January 2027 [Page 46]
Internet-Draft IACP - DHI - ERP July 2026
{
"result_type": "iacp-attestation-result",
"version": "1.0",
"subject_eid": "base64_encoded_eid",
"verifier_id": "verifier.example.com",
"verification_time": 1745512510,
"tee_type": "intel-tdx",
"measurements_hash": "sha256:abc123...",
"status": "valid",
"reason": "none",
"signature": "base64_ed25519_signature"
}
2.2.10.6. Security Considerations for Attestation
Key Binding:
The security of attestation depends on verifying that the public key
in the Evidence matches the public key in the EID. This ensures the
Evidence is about the same key that the agent proves possession of.
Stripping Attack:
A malicious proxy may strip attestation headers from requests.
Backend workloads that require attestation by policy MUST reject
requests lacking the required evidence.
Evidence Freshness:
Attestation evidence MUST include a timestamp to prevent replay
attacks. Receivers SHOULD reject evidence older than 300 seconds
(default, configurable).
TEE Vulnerabilities:
Different TEE types have different security properties and known
vulnerabilities. Verifiers MUST maintain up-to-date knowledge of TEE
security status and update their policies accordingly.
Privacy:
Attestation measurements may reveal platform details (firmware
versions, configuration, etc.). Deployments SHOULD minimize
disclosed information and use the Attestation Result pattern to avoid
exposing raw measurements.
Gebauer Expires 29 January 2027 [Page 47]
Internet-Draft IACP - DHI - ERP July 2026
2.2.10.7. New Message Types for Attestation
The following new IACP message types are defined:
| Type | Name | Description |
|--------|--------------------|------------------------------------|
| 0x23 | PSS_ATTEST | Periodic attestation refresh |
| 0x24 | PSS_ATTEST_RES | Attestation verification result |
| 0x25 | ATTEST_VERIFY_REQ | Request remote attestation verify |
| 0x26 | ATTEST_VERIFY_RES | Return attestation verification |
2.2.10.8. Implementation Status and Reference
A reference implementation of the attestation integration is
available at:
* [I-D.reddy-rats-key-binding] defines key binding for EAT.
* [I-D.fossati-seat-early-attestation] defines TLS attestation.
* [I-D.ietf-wimse-workload-creds] defines WIT attestation claims.
IACP implementations SHOULD be compatible with these specifications
when deploying attestation.
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>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
Gebauer Expires 29 January 2027 [Page 48]
Internet-Draft IACP - DHI - ERP July 2026
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
3.2. Informative References
[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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[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/>.
[I-D.reddy-rats-key-binding]
, Tschofenig, H., Fossati, T., and I. Mihalcea, "Key
Attestation for Entity Attestation Tokens (EAT)", Work in
Progress, Internet-Draft, draft-reddy-rats-key-binding-01,
7 June 2026, <https://datatracker.ietf.org/doc/draft-
reddy-rats-key-binding/>.
[I-D.fossati-seat-early-attestation]
Sheffer, Y., Mihalcea, I., Deshpande, Y., Fossati, T., and
, "Using Attestation in Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS)", Work in
Progress, Internet-Draft, draft-fossati-seat-early-
attestation-04, 27 May 2026,
<https://datatracker.ietf.org/doc/draft-fossati-seat-
early-attestation/>.
[I-D.ietf-wimse-workload-creds]
Campbell, B., Salowey, J., Schwenkschuster, A., Sheffer,
Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work
in Progress, Internet-Draft, draft-ietf-wimse-workload-
creds-02, 2 July 2026, <https://datatracker.ietf.org/doc/
draft-ietf-wimse-workload-creds/>.
Gebauer Expires 29 January 2027 [Page 49]
Internet-Draft IACP - DHI - ERP July 2026
Author's Address
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 29 January 2027 [Page 50]