Network Working Group L. Gebauer
Internet-Draft Independent
Intended status: Informational 28 July 2026
Expires: 29 January 2027
Internet Agent Communication Protocol
draft-gebauer-iacp-03
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 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 . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Motivation and Problem Statement . . . . . . . . . . . . 5
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 6
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 6
2.1. Key Definitions . . . . . . . . . . . . . . . . . . . . . 6
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 8
3. Ephemeral Agent Identity (EID) . . . . . . . . . . . . . . . 8
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. EID Generation and Properties . . . . . . . . . . . . . . 9
3.3. Identity-Locator Separation Principles . . . . . . . . . 9
3.4. EID Persistence and Rotation Rules . . . . . . . . . . . 10
3.5. Forwarding Tickets and DHT-based Asynchronous
Resolution . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. EID Reputation and Cryptographic Ledger Attestation . . . 12
3.6.1. Cryptographic Attestation and Metrics . . . . . . . . 12
3.6.2. Threshold Enforcement and Session Downgrade . . . . . 13
3.7. Cross-Domain Identity Federation . . . . . . . . . . . . 13
3.7.1. Trust Anchor Document . . . . . . . . . . . . . . . . 13
3.7.2. Federation Protocol Flow . . . . . . . . . . . . . . 14
3.7.3. Federation Gateway Mode . . . . . . . . . . . . . . . 15
3.7.4. Trust Domain Curator Roles . . . . . . . . . . . . . 16
3.7.5. Trust Anchor Rotation and Revocation . . . . . . . . 16
3.7.6. Privacy Considerations for Federation . . . . . . . . 16
3.7.7. New Message Types for Federation . . . . . . . . . . 17
4. Deterministic Hypermedia Interpreter (DHI) . . . . . . . . . 17
4.1. DHI General . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Execution Environment and UI Abstraction . . . . . . 17
4.1.2. The Agent Parser Ingestion Pipeline . . . . . . . . . 18
4.1.3. Resource Retrieval via Algorithmic Extraction (HRP &
APE) . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.4. Content Equivalence and Legacy Hand-off Invariants . 27
4.1.5. Separation of Concerns between DHI and Agents . . . . 30
4.1.6. ANML Support and Integration . . . . . . . . . . . . 32
4.2. EID Routing Protocol (ERP) - Subprotocol . . . . . . . . 35
4.2.1. Protocol Entities and Abstraction Layer . . . . . . . 35
4.2.2. Session Cryptography and Isolation Mechanics . . . . 36
4.2.3. Protocol Operations . . . . . . . . . . . . . . . . . 38
4.2.4. Secure Handshake and Connection Management . . . . . 41
4.2.5. Resource Governance . . . . . . . . . . . . . . . . . 46
Gebauer Expires 29 January 2027 [Page 2]
Internet-Draft IACP July 2026
4.2.6. Fault Tolerance, Resiliency, and Degraded
Operations . . . . . . . . . . . . . . . . . . . . . 48
4.2.7. Decentralized Security Governance and Slashing . . . 50
4.2.8. QUIC Transport Binding . . . . . . . . . . . . . . . 53
4.2.9. LL-Entity Local Interface Specification . . . . . . . 55
4.2.10. Remote Attestation Integration . . . . . . . . . . . 56
5. DHT Namespace Architecture and Distributed Security . . . . . 62
5.1. Distributed Hash Table . . . . . . . . . . . . . . . . . 62
5.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.2. DHT Namespace Structure . . . . . . . . . . . . . . . 62
5.1.3. DHT Overlay Construction . . . . . . . . . . . . . . 63
5.2. Namespace Registration and Curation . . . . . . . . . . . 78
5.2.1. Root Namespace Registration . . . . . . . . . . . . . 78
5.2.2. Sub-Namespace Delegation . . . . . . . . . . . . . . 79
5.3. Proof-of-Work and Reputation-Based Access Control . . . . 79
5.3.1. Dynamic PoW Difficulty . . . . . . . . . . . . . . . 80
5.3.2. Access Tickets and Joint Liability . . . . . . . . . 80
5.4. Anti-Abuse Mechanisms . . . . . . . . . . . . . . . . . . 80
5.4.1. Token-Bucket Filters and Rate Limiting . . . . . . . 81
5.4.2. Autonomous Circuit Breakers . . . . . . . . . . . . . 81
5.5. Proof of Malfeasance (PoM) and Slashing . . . . . . . . . 81
5.5.1. PoM Ticket Specification . . . . . . . . . . . . . . 81
5.5.2. Two-Phase Slashing Escrow (2PSE) . . . . . . . . . . 93
5.5.3. Curator Quarantine and Decapitation . . . . . . . . . 93
5.5.4. Reputation Penalties . . . . . . . . . . . . . . . . 94
5.6. Compromise Recovery and Hot-Docking . . . . . . . . . . . 94
5.6.1. Migration Stream Serialization . . . . . . . . . . . 94
5.6.2. Migration Stream Encryption . . . . . . . . . . . . . 94
5.6.3. Forwarding Ticket Generation . . . . . . . . . . . . 95
5.6.4. Migration Flow . . . . . . . . . . . . . . . . . . . 95
5.6.5. EID Revocation and Propagation . . . . . . . . . . . 96
5.7. Layer-Separated Economic Governance and Edge Gatekeeper
Model . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.7.1. Layer 4 Kernel-Space Fast-Path . . . . . . . . . . . 99
5.7.2. Layer 7 Application-Space Door-Keeper (Opaque
Authorization Envelope) . . . . . . . . . . . . . . . 101
5.7.3. Asynchronous Verification and Teardown . . . . . . . 101
6. Agent to Agent Communication . . . . . . . . . . . . . . . . 102
6.1. Ephemeral State Endpoints (ESE) . . . . . . . . . . . . . 102
6.1.1. General . . . . . . . . . . . . . . . . . . . . . . . 103
6.1.2. Local Points (LP) . . . . . . . . . . . . . . . . . . 103
6.1.3. Global Points (GP) . . . . . . . . . . . . . . . . . 103
6.2. Discovery Spaces (DS) . . . . . . . . . . . . . . . . . . 103
6.2.1. Discovery Space Structure . . . . . . . . . . . . . . 103
6.3. Anonymous Discovery Mechanism . . . . . . . . . . . . . . 105
6.3.1. Discovery Request with Proof-of-Work and Ephemeral Keys
(DISCOVERY_REQ) . . . . . . . . . . . . . . . . . . . 105
Gebauer Expires 29 January 2027 [Page 3]
Internet-Draft IACP July 2026
6.3.2. Discovery Response and Secure EID Exchange
(DISCOVERY_RES) . . . . . . . . . . . . . . . . . . . 105
6.4. Persistent State Sessions (PSS) . . . . . . . . . . . . . 105
6.4.1. General . . . . . . . . . . . . . . . . . . . . . . . 105
6.4.2. PSS Lifecycle and Handshake . . . . . . . . . . . . . 106
6.4.3. Dual-Cookie Handshake (PSS_INIT / PSS_NEG /
PSS_ACK) . . . . . . . . . . . . . . . . . . . . . . 106
6.4.4. Session Federation Contract (SFC) . . . . . . . . . . 107
6.4.5. Data Streaming and Sequence Vector Reconciliation
(PSS_DATA_STREAM) . . . . . . . . . . . . . . . . . . 107
6.5. Session Termination and Revocation . . . . . . . . . . . 108
6.5.1. Graceful Teardown (PSS_TEARDOWN) . . . . . . . . . . 108
6.5.2. Revocation and Proof of Malfeasance Publishing
(PSS_REVOCATION_PUBLISH) . . . . . . . . . . . . . . 108
7. Interoperability with other Protocols . . . . . . . . . . . . 108
7.1. Interoperability with WIMSE . . . . . . . . . . . . . . . 108
7.1.1. Trust Domain and Workload Identifier Mapping . . . . 108
7.1.2. Transport of WIMSE Credentials . . . . . . . . . . . 109
7.1.3. PSS as Transport for WIMSE Authentication . . . . . . 109
7.1.4. Gateway Integration . . . . . . . . . . . . . . . . . 110
7.1.5. Trust Domain Discovery . . . . . . . . . . . . . . . 110
7.2. Interoperability with AGTP . . . . . . . . . . . . . . . 110
7.2.1. IACP as Transport for AGTP Methods . . . . . . . . . 110
7.2.2. AGTP Identity Document as Discovery Resource . . . . 111
7.2.3. AGTP as the Method Layer over IACP . . . . . . . . . 112
7.2.4. Deployment Considerations . . . . . . . . . . . . . . 112
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114
8.1. IACP Message Type Registry . . . . . . . . . . . . . . . 114
8.2. IACP Flags Registry . . . . . . . . . . . . . . . . . . . 116
8.3. IACP Outer Transport Header Types . . . . . . . . . . . . 116
8.4. IACP Transport Parameter Registry . . . . . . . . . . . . 117
8.4.1. Algorithm Registry . . . . . . . . . . . . . . . . . 118
9. Security Considerations . . . . . . . . . . . . . . . . . . . 118
9.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 118
9.2. Identity and Authentication . . . . . . . . . . . . . . . 119
9.3. Confidentiality and Integrity . . . . . . . . . . . . . . 119
9.3.1. Cryptographic Suite Negotiation and Agility . . . . . 120
9.3.2. Canonicalization and Equivocation Protection . . . . 120
9.4. Denial-of-Service and Resource Exhaustion . . . . . . . . 121
9.5. Namespace and Curation Security . . . . . . . . . . . . . 121
9.6. Eclipse and Sybil Attack Protections . . . . . . . . . . 121
9.7. Mobility, Churn, and Forwarding Tokens . . . . . . . . . 122
9.8. Privacy Considerations . . . . . . . . . . . . . . . . . 122
9.9. Residual Risks and Recommendations . . . . . . . . . . . 122
9.10. Performance and Scalability Considerations . . . . . . . 123
9.10.1. Agent Scalability . . . . . . . . . . . . . . . . . 124
9.10.2. DHT Lookup Performance . . . . . . . . . . . . . . . 124
9.10.3. PSS Session Throughput . . . . . . . . . . . . . . . 125
Gebauer Expires 29 January 2027 [Page 4]
Internet-Draft IACP July 2026
9.10.4. DHI Ingestion Pipeline Performance . . . . . . . . . 125
9.10.5. HRP/APE Computational Cost . . . . . . . . . . . . . 125
9.10.6. Memory Consumption . . . . . . . . . . . . . . . . . 126
9.10.7. Scaling Recommendations . . . . . . . . . . . . . . 126
9.10.8. Performance Monitoring . . . . . . . . . . . . . . . 127
9.10.9. HRP/APE Computational Cost and Scalability . . . . . 127
9.11. Crypto-Agility and Algorithm Negotiation . . . . . . . . 132
9.11.1. Algorithm Suites . . . . . . . . . . . . . . . . . . 132
9.11.2. Algorithm Negotiation . . . . . . . . . . . . . . . 132
9.11.3. Suite-Specific Wire Formats . . . . . . . . . . . . 133
9.11.4. EID Representation and Algorithm Binding . . . . . . 133
9.11.5. Post-Quantum Readiness . . . . . . . . . . . . . . . 134
9.11.6. Migration and Deprecation . . . . . . . . . . . . . 134
9.11.7. Structured Threat Analysis (STRIDE) . . . . . . . . 135
9.11.8. Attack Trees and Formal Security Arguments . . . . . 141
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 148
10.1. Normative References . . . . . . . . . . . . . . . . . . 148
10.2. Informative References . . . . . . . . . . . . . . . . . 149
Appendix A. Wire Formats of the IACP . . . . . . . . . . . . . . 152
Appendix B. State Machines and Transition Diagrams of the
IACP . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Appendix C. Additional ASCII-Diagrams of the IACP . . . . . . . 188
Appendix D. Security Principal and Verifier Binding Matrix . . . 188
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 196
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 197
1. Introduction
1.1. Motivation and Problem Statement
Traditional Internet protocols and applications are designed for
human users interacting via visual browsers. With the rapid growth
of autonomous AI agents, the majority of future network participants
will be non-human, deterministic systems requiring native,
cryptographically secure, and identity-centric communication
primitives. Existing protocols lack strict identity-locator
separation, deterministic content interpretation, secure host
isolation, and decentralized governance suitable for agent-to-agent
interaction at scale.
1.2. Design Goals
The Internet Agent Communication Protocol (IACP) is designed to:
* Provide strict Ephemeral Agent Identity (EID) with identity-
locator separation using Ed25519 cryptography.
Gebauer Expires 29 January 2027 [Page 5]
Internet-Draft IACP July 2026
* Enable secure host isolation through the Local Loopback Layer
Entity (LL-Entity) and Instance Authentication Token (IAT).
* Deliver deterministic content processing via the Deterministic
Hypermedia Interpreter (DHI) with mathematical equivalence
guarantees (EVM <= 0.001).
* Support reliable agent-to-agent communication through Persistent
State Sessions (PSS) with Dual-Cookie handshake and optional
Session Federation Contracts (SFC).
* Establish decentralized namespace governance using a DHT with
Proof-of-Work curation, Proof of Malfeasance (PoM), and Two-Phase
Slashing Escrow (2PSE).
* Ensure mobility, fault tolerance, and security under churn via
generation counting, MIGRATION_VECTOR, and degraded multi-path
routing.
* Enable secure cross-domain trust establishment through a
decentralized federation mechanism and remote attestation of
execution environments.
1.3. Scope and Non-Goals
This document defines the overall IACP architecture (e.g. the EID
Routing Protocol (ERP), DHI pipeline and state machines, wire
formats, PSS lifecycle, DHT namespace mechanics, and core security
model).
Out of scope are: Concrete DHT implementation details,
ANMLspecification (defined in [I-D.jeskey-anml]), lower-layer
transport(QUIC usage is RECOMMENDED but not mandated), and
application-layer LLM semantics.
2. Terminology and Conventions
2.1. Key Definitions
* *AAI* - Autonomous Agent Instance: Application-layer logic
executing autonomously and communicating via PSS.
* *EID* - Ephemeral Agent Identity: 32-byte cryptographic
identifier. Defined directly as 256-bit (32-byte) Ed25519 Public
Key.
Gebauer Expires 29 January 2027 [Page 6]
Internet-Draft IACP July 2026
* *LL-Entity* - Local Loopback Layer Entity: Host-local shim between
AAI and network. Manages EID allocation, IAT validation,
encapsulation, and isolation.
* *IAT* - Instance Authentication Token: 32-byte high-entropy token
generated by LL-Entity for local AAI authentication.
* *DHI* - Deterministic Hypermedia Interpreter: Native agent
runtime. Performs ingestion pipeline, content equivalence
verification, and hands off to downstream LLM core.
* *ANML* - Agentic Network Markup Language: Structured markup for
deterministic agent-native content processing.
* *PSS* - Persistent State Session: Long-lived secure channel
between two EIDs, using Dual-Cookie handshake and optional SFC.
* *ESE* - Ephemeral State Endpoint: Information block hosted under
an EID (Local Point or Global Point).
* *ERP* - EID Routing Protocol: Control protocol for local
initialization, DHT mapping, mobility, and session management.
* *SFC* - Session Federation Contract: Optional agreement granting
direct ESE access between PSS peers.
* *DHT* - Distributed Hash Table: Global decentralized directory for
EID-to-locator mappings and namespace governance.
* *PoM* - Proof of Malfeasance: Cryptographic evidence of
equivocation or protocol violation.
* *2PSE* - Two-Phase Slashing Escrow: Challenge window before stake
slashing.
* *USIV* - Unified Semantic Ingestion Vector: {Source_EID,
Target_URI, Payload_Byte_Length, Payload_Pointer} passed across
IIB.
* *HCO* - Hand-off Context Object: Serialized structure for legacy
browser fallback containing ESD-EID.
* *ESD-EID* - Ephemeral Session Derivative EID: Temporary derivative
of EID used for sandboxed legacy execution.
* *WRT* - Web Resource Token: A stateless, cryptographically signed
asymmetric token representing abstract compute equivalents (e.g.,
utility units) presented by an AAI at the edge layer.
Gebauer Expires 29 January 2027 [Page 7]
Internet-Draft IACP July 2026
2.2. 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.
3. Ephemeral Agent Identity (EID)
3.1. General
To interact with the underlying network infrastructure, the Internet
Agent Communication Protocol (IACP) enforces a strict identity-
locator separation based on the core architectural principles of the
Host Identity Protocol (HIP, RFC 7401). Traditional internet
architectures conflate identity and location within a single IP
address layer, creating significant vulnerabilities and
inefficiencies for autonomous multi-agent workflows.
IACP addresses this structural flaw by decoupling an agent's
persistent logical identity from its volatile physical routing state.
An agent utilizes its current, transient IP address solely as an
ephemeral transport locator. This locator is bound via cryptographic
primitives to a unique, self-certifying pseudonym known as the
Ephemeral Agent Identity (EID).
+------------------------------------------------------------------+
| Application / LLM Context |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Ephemeral Agent Identity (EID) Layer |
| [Cryptographic permanence / Stable Identity] |
+------------------------------------------------------------------+
|
v
+------------------------------------------------------------------+
| Transport Locator Layer |
| [Volatile IP Routing State / Dynamic Topology] |
+------------------------------------------------------------------+
While transport locators shift dynamically with network topology and
routing handovers, the EID operates as a long-lived logical
identifier. This structural separation abstracts network-level
transitions away from the application state. Every active agent
maintains an operational EID that is temporarily mapped to its host
Gebauer Expires 29 January 2027 [Page 8]
Internet-Draft IACP July 2026
IP address, providing continuous access to the global network,
Ephemeral State Endpoints (ESEs), and Persistent State Sessions
(PSS).
3.2. EID Generation and Properties
The Ephemeral Agent Identity (EID) is structured as a self-certifying
cryptographic identifier. It consists of a 32-byte public key
derived from an asymmetric keypair, specifically optimized using the
Ed25519 signature scheme for identity validation.
EID Cryptographic Properties: * Mathematical Decoupling: The EID
contains no routing metadata, geographic indicators, or topological
constraints. It is bound to network locators via authenticated,
dynamic mappings. * Verification Permanence: Any active peer can
verify the authenticity of protocol control packets by validating the
attached Ed25519 signature directly against the initiating EID. *
Integrity Vectors: The EID serves as the unique index key for
tracking distributed reputation matrices within the shared network
ledger, binding behavioral history directly to the identity.
3.3. Identity-Locator Separation Principles
The protocol operates a clean layer split where transport-layer
stream multiplexing and sequence verification are handled inside the
cryptographic umbrella of the EID, while IP routing tables process
the transport locators. This ensures that network anonymity is
preserved without sacrificing session stability.
+-----------------------+ +-----------------------+
| Initiator (Alice) | | Responder (Bob) |
| Stable Identity: EID | | Stable Identity: EID |
+-----------------------+ +-----------------------+
| |
================== IDENTITY-LOCATOR SEPARATION ==================
| |
+-----------------------+ +-----------------------+
| Transport Locator (IP)| | Transport Locator (IP)|
| [Volatile Routing] | | [Volatile Routing] |
+-----------------------+ +-----------------------+
When an agent alters its physical connection point or moves across
network bounds, the upper session layer remains completely unaware of
the physical interface change. By absorbing routing transitions
within the decoupled identity layer, ongoing computations, resource
extraction pipelines, and active state allocations remain
uninterrupted.
Gebauer Expires 29 January 2027 [Page 9]
Internet-Draft IACP July 2026
3.4. EID Persistence and Rotation Rules
To prevent longitudinal tracking and mitigate profiling risks across
the public routing topology, EID ephemerality is strictly bounded.
However, to maintain session stability, the EID remains persistent
across simple network handovers. EID rotation is explicitly
restricted and only triggered under the following three conditions:
1. Administrative Instruction: Upon an explicit administrative
directive issued by the managing user or parent orchestration
system.
2. Cryptographic Compromise: Immediately following a detected
security anomaly, private key exfiltration, or cryptographic
compromise.
3. Context Termination: Upon the successful completion or
termination of a designated operational task, autonomous session,
or Persistent State Session (PSS) context.
If an agent changes its network locator due to a simple routing
transition (such as migrating from Wi-Fi to mobile data networks),
identity persistence is managed directly between active peers. The
agent transmits a Signed Binding Update containing the new IP mapping
directly to its active communication partners. This optimization
keeps the EID stable during short-term handovers, preventing session
drops without requiring a full identity renegotiation or public
registration update.
To prevent malicious entities from utilizing rapid identity rotation
to evade accountability, EID ephemerality is bounded by a distributed
reputation architecture. Protocol deviations-such as unverified
session terminations or state invalidations-are signed and indexed
against the initiating EID within a decentralized substrate.
Rational nodes execute pre-flight validation of a target EID's
integrity vector before allocating state bounds or initializing
transitions.
3.5. Forwarding Tickets and DHT-based Asynchronous Resolution
Because direct binding updates require both endpoints to be
concurrently online, the architecture utilizes a decentralized
Distributed Hash Table (DHT) substrate (structured via Kademlia's XOR
metric) to resolve asynchronous identity-location decoupling. This
addresses real-world network constraints where nodes frequently cycle
offline or undergo asymmetric routing handovers.
Gebauer Expires 29 January 2027 [Page 10]
Internet-Draft IACP July 2026
Before an agent rotates its network parameters or enters an extended
offline state, it generates a cryptographic Forwarding Ticket. This
ticket contains the agent's updated routing metadata, is signed via
the Ed25519 secret key associated with the active EID, and is
deposited at the agent's last known coordinate within the DHT. The
precise routing coordinate within the DHT substrate is derived
deterministically via:
KEY = SHA-256(EID_AGENT)
The storage transaction uses the DHT_TICKET_STORE format (Type 0x05).
The 36 bytes of Encrypted Forwarding Data are protected using an
Diffie-Hellman key exchange over X25519 combined with AES-GCM-256.
The cryptographic pipeline MUST be executed as follows:
1. *Key Derivation*: The initiating agent generates a fresh
ephemeral X25519 keypair (d_eph, Q_eph). It extracts the peers
static public key Q_peer from the active PSS context and computes
the shared secret:
K_shared = HKDF-SHA256(X25519(d_eph, Q_peer), salt="",
info="IACP_FORWARDING_TICKET_v1")
2. *Payload Encryption*: The raw forwarding vector (Target IP +
Port, 20 bytes) is encrypted with AES-GCM-256 using K_shared and
the 12-byte AEAD Nonce from the ticket header. The resulting
16-byte authentication tag is appended, producing the 36-byte
Encrypted Forwarding Data block.
3. *Signature*: The signature covers the concatenation of Target
Storage Key, Target Agent EID, TTL, AEAD Nonce and Encrypted
Forwarding Data using the owners Ed25519 private key.
The ephemeral public key Q_eph MUST be included in the ticket payload
(e.g., as an additional field) to allow the receiving peer to
reconstruct K_shared.
When a peer wakes up or reconnects after an extended offline period,
it queries the DHT at the historical coordinate of the targeted agent
by dispatching a DHT_TICKET_QUERY packet (Type 0x06).
The querying node populates the target key field, attaches an 8-byte
Transaction ID, and logs its own EID. The responding DHT node
returns a DHT_TICKET_RESP packet (Type 0x07) containing matching
transaction metadata, a 4-byte Status Code, and the encrypted ticket
payload.
Gebauer Expires 29 January 2027 [Page 11]
Internet-Draft IACP July 2026
Upon retrieval, the querying peer decrypts the Forwarding Ticket
using the pre-established shared session key. This structural lookup
reveals the targeted agent's updated network locator and current
routing parameters. The communication channel is subsequently
restored via a sequential state synchronization routine utilizing
sequence state vector reconciliation, ensuring complete state
continuity without corruption.
+--------------------------+
| [0x05] DHT_TICKET_STORE |
+--------------------------+
|
v (Agent Goes Offline / Rotates Locator Parameters)
+--------------------------+
| [0x06] DHT_TICKET_QUERY |
+--------------------------+
|
v (DHT Fabric Processes XOR Routing Metrics)
+--------------------------+
| [0x07] DHT_TICKET_RESP |
+--------------------------+
3.6. EID Reputation and Cryptographic Ledger Attestation
EID is bound to a dynamic, non-repudiable transaction reputation
metric managed within the distributed directory overlay layer.
Because EIDs are decoupled from the network transport locators (IP
addresses), reputation tracking is executed directly against the
256-bit EID public key coordinate. This prevents malicious instances
from shedding negative operational history through transport
interface rotation or routing hop modification.
3.6.1. Cryptographic Attestation and Metrics
Reputation states are mathematically computed at the end of each
evaluation epoch (t) as a weighted Exponential Moving Average (EMA)
to incorporate temporal history while remaining responsive to recent
behavior:
R_State(t) = a * M(t) + (1 - a) * R_State(t-1)
where a = 0.12 (smoothing factor). The instantaneous metrics vector
M(t) is defined as:
M(t) = w1*S_Verify(t) + w2*A_Telemetry(t) - w3*PoM_Score(t)
Gebauer Expires 29 January 2027 [Page 12]
Internet-Draft IACP July 2026
The formal invariants are: * S_Verify(t) im [0.0, 1.0]: Ratio of
cryptographically valid signatures on critical control frames
(PSS_INIT, PSS_ACK) during the epoch. * A_Telemetry(t) in [0.0, 1.0]:
Verified processing availability under active Session Federation
Contracts (SFC). * PoM_Score(t) = min(1.0, PoM_Count(t) / k) with k =
5 (normalized penalty; older tickets decay exponentially). * Weights:
w1 = 0.45, w2 = 0.35, w3 = 0.20. Baseline: R_State(0) = 1.0.
3.6.2. Threshold Enforcement and Session Downgrade
Peering nodes evaluating a connection initialization vector
(PSS_INIT) MUST query the target EID's current reputation coordinate
inside the directory keyspace before moving from STATE_HEARING to
STATE_ESTABLISHED.
If the reputation metric falls below a pre-configured local
threshold, the incoming packet ingestion layer MUST enforce one of
the following deterministic circuit-breaker states: 1. *Dynamic PoW
Escalation:* The host interface enforces a deterministic bitwise
difficulty escalation. For every 0.1 units the reputation falls
below the baseline threshold (R_Threshold = 0.7), the required
trailing-zero bit length increases by exactly 4 bits:
D_escalated = D_base + max(0, ceil((R_Threshold - R_State) * 40))
The maximum escalation is capped at +32 bits to prevent complete
denial-of-service through reputation poisoning. If R_State < 0.3,
the node SHOULD immediately reject new sessions in addition to the
escalated PoW requirement. 2. *Channel Micro-Throttling:* The local
engine restricts bandwidth and token-bucket allocation values via
hardcoded execution shims, forcing a degraded multi-path transport
pipeline. 3. *Immediate Block and Slashing Routing:* Upon detection
of an unexpired curator quarantine flag or active 2PSE ticket
reference, the protocol runtime drops the packet without volatile
memory allocation and propagates an immediate blacklisting broadcast
across the network topology.
3.7. Cross-Domain Identity Federation
IACP supports federated identity across trust domains through a
decentralized trust anchor exchange mechanism. This enables agents
from different administrative domains to authenticate and establish
secure sessions without pre-existing bilateral agreements.
3.7.1. Trust Anchor Document
Each trust domain publishes a Trust Anchor Document containing the
domain's identity roots, namespace roots, and trust anchors:
Gebauer Expires 29 January 2027 [Page 13]
Internet-Draft IACP July 2026
{
"document_type": "iacp-trust-anchor",
"version": "1.0",
"domain": "org.agentnet.production",
"domain_id": "sha256:abc123...",
"trust_anchors": [
{
"type": "ed25519",
"key": "base64_encoded_public_key",
"valid_from": "2026-01-01T00:00:00Z",
"valid_until": "2027-01-01T00:00:00Z",
"purpose": "eid-validation"
},
{
"type": "ed25519",
"key": "base64_encoded_public_key",
"valid_from": "2026-01-01T00:00:00Z",
"valid_until": "2027-01-01T00:00:00Z",
"purpose": "namespace-validation"
}
],
"namespace_root": "sha256:def456...",
"curator_eid": "base64_encoded_curator_eid",
"federation_policy": {
"allowed_domains": ["org.agentnet.staging", "org.agentnet.test"],
"required_trust_tier": 1,
"max_delegation_depth": 5
},
"signature": "base64_ed25519_signature"
}
The Trust Anchor Document is signed by the domain curator and
published at a well-known DHT location:
KEY = SHA-256("iacp-federation:" || Domain_ID)
3.7.2. Federation Protocol Flow
Two agents from different trust domains establish trust:
1. Domain Discovery:
Agent A queries the DHT for Agent B's trust domain root:
DHT_QUERY { "key": "iacp-federation:" || Agent_B.Domain_ID,
"requestor_eid": Agent_A.EID }
1. Trust Anchor Retrieval:
Gebauer Expires 29 January 2027 [Page 14]
Internet-Draft IACP July 2026
Agent A retrieves the Trust Anchor Document from Agent B's domain:
DHT_RESP { "trust_anchor_document": { ... }, "freshness": {
"timestamp": 1745512510, "ttl": 3600 } }
1. Validation:
Agent A validates the Trust Anchor Document:
a. Verify the Ed25519 signature against the curator EID. b. Verify
the trust_anchors are valid (not expired). c. Verify the
namespace_root matches the domain. d. Check federation_policy for
allowed_domains.
1. EID Verification:
Agent A validates Agent B's EID:
a. Retrieve Agent B's EID public key. b. Verify Agent B's EID
signature against the trust anchor.
*5. Session Establishment:*
PSS is established with cross-domain trust:
PSS_INIT { "initiator_eid": Agent_A.EID, "target_eid": Agent_B.EID,
"cross_domain": true, "trust_domain": Agent_B.Domain_ID,
"trust_anchor_fingerprint": sha256(Trust_Anchor_Document) }
3.7.3. Federation Gateway Mode
For deployments where direct trust anchor exchange is not possible, a
Federation Gateway MAY act as a trust broker:
+-------------------+ +-------------------+ +-----------------+
| Domain A Agent | | Federation Gateway| | Domain B Agent |
| | | | | |
| 1. Request Access |---->| 2. Validate Domain|---->| 3. Request Trust|
| | | A Trust Anchor | ___/| Anchor B |
| | | |/ | |
| | | 4. Validate |---->| 5. Return Trust |
| | | Domain B | | Anchor B |
| | | Trust Anchor | | |
| | | | | |
| 6. Return |<----| 7. Forward |---->| 8. Establish |
| Trust Anchor | | Trust Anchor | | Session |
| B | | B to A | | |
+-------------------+ +-------------------+ +-----------------+
Gebauer Expires 29 January 2027 [Page 15]
Internet-Draft IACP July 2026
The Federation Gateway maintains a cache of Trust Anchor Documents
and performs trust validation on behalf of agents.
3.7.4. Trust Domain Curator Roles
The following curator roles are defined:
Root Curator: - Maintains the authoritative namespace registry for a
trust domain. - Signs and publishes the Trust Anchor Document. -
Rotates trust anchors when necessary. - Revokes trust anchors in case
of compromise.
Federation Gateway: - Translates between trust domains. - Performs
identity mapping and policy enforcement. - Provides trust anchor
discovery and validation services. - MAY cache Trust Anchor Documents
for performance.
Trust Broker: - Provides trust anchor discovery services across
domains. - Maintains a global index of trust domains. - Does not
perform policy enforcement (unlike Federation Gateway).
3.7.5. Trust Anchor Rotation and Revocation
Trust anchors have bounded validity (valid_from, valid_until).
Domains MUST publish updated Trust Anchor Documents before existing
anchors expire:
* Rotation Window: 24 hours before expiration.
* Validity Overlap: New anchor MUST be valid for at least 48 hours
after old anchor expires. -*Revocation: Domains MAY publish
revocation records for compromised anchors.
Revocation records are published at:
KEY = SHA-256("iacp-revocation:" || Domain_ID || Anchor_Fingerprint)
The revocation record contains: - Anchor fingerprint (revoked) -
Revocation timestamp - Reason code - Curator signature
3.7.6. Privacy Considerations for Federation
Cross-domain federation MAY expose sensitive information:
* Domain Exposure: The domain ID reveals organizational affiliation.
* Trust Anchors: Public keys are published for discovery.
Gebauer Expires 29 January 2027 [Page 16]
Internet-Draft IACP July 2026
* Access Patterns: Federation requests reveal which domains agents
interact with.
Deployments SHOULD consider:
* Using ephemeral domain IDs for sensitive operations.
* Encrypting Trust Anchor Documents for authorized agents only.
* Rate-limiting federation requests to prevent enumeration attacks.
* Using Federation Gateways to hide internal domain structure.
3.7.7. New Message Types for Federation
The following new IACP message types are defined:
| Type | Name | Description |
|--------|-------------------------|----------------------------------|
| 0x1C | FED_TRUST_ANCHOR_REQ | Request Trust Anchor Document |
| 0x1D | FED_TRUST_ANCHOR_RES | Return Trust Anchor Document |
| 0x1E | FED_DISCOVERY_REQ | Discover trust domain by name |
| 0x1F | FED_DISCOVERY_RES | Return domain ID and metadata |
| 0x20 | FED_REVOCATION | Publish trust anchor revocation |
| 0x21 | FED_VALIDATE_REQ | Request EID validation by gateway|
| 0x22 | FED_VALIDATE_RES | Return EID validation result |
4. Deterministic Hypermedia Interpreter (DHI)
4.1. DHI General
4.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.
Gebauer Expires 29 January 2027 [Page 17]
Internet-Draft IACP July 2026
4.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:
4.1.2.1. State Machine Transitions and Pipeline Execution
The ingestion pipeline MUST proceed according to the following state
machine and transitional logic:
+-----------------------+ +------------------------+
| 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.
Gebauer Expires 29 January 2027 [Page 18]
Internet-Draft IACP July 2026
[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.
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].
Gebauer Expires 29 January 2027 [Page 19]
Internet-Draft IACP July 2026
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.
4.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.
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.
4.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.
Gebauer Expires 29 January 2027 [Page 20]
Internet-Draft IACP July 2026
+--------------+
| 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.
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).
Gebauer Expires 29 January 2027 [Page 21]
Internet-Draft IACP July 2026
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.
4.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.
4.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).
Gebauer Expires 29 January 2027 [Page 22]
Internet-Draft IACP July 2026
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.
4.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:
* 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.
Gebauer Expires 29 January 2027 [Page 23]
Internet-Draft IACP July 2026
4.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) |
+------------------------------+ +---------------------------+
4.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.
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:
Gebauer Expires 29 January 2027 [Page 24]
Internet-Draft IACP July 2026
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:
~~~~ 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.
Gebauer Expires 29 January 2027 [Page 25]
Internet-Draft IACP July 2026
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.
4.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)
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.
4.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.
Gebauer Expires 29 January 2027 [Page 26]
Internet-Draft IACP July 2026
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.
4.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.
* Precision requirements: Higher Θ for scenarios requiring high
precision (e.g., security-sensitive retrievals).
* Historical success rates: Adaptive adjustment based on past
retrieval outcomes.
4.1.4. Content Equivalence and Legacy Hand-off Invariants
4.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.
Gebauer Expires 29 January 2027 [Page 27]
Internet-Draft IACP July 2026
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:
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.
Gebauer Expires 29 January 2027 [Page 28]
Internet-Draft IACP July 2026
4.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.
+---------------------------------------+
| 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 |
+---------------------------------------+
4.1.4.3. HCO Wire-Level Structural Layout
The serialized HCO binary block MUST conform to the following layout:
Gebauer Expires 29 January 2027 [Page 29]
Internet-Draft IACP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4.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).
Gebauer Expires 29 January 2027 [Page 30]
Internet-Draft IACP July 2026
+-------------------------------------------------+
| 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 |
+-------------------------------------------------+
4.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.
4.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.
Gebauer Expires 29 January 2027 [Page 31]
Internet-Draft IACP July 2026
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.
4.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.
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.
4.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.
Gebauer Expires 29 January 2027 [Page 32]
Internet-Draft IACP July 2026
* 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.
4.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: ; rel="alternate";
type="application/anml+xml"
3. DNS SRV Record: _anml._tcp.{domain}
4. HTML Link Element:
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.
4.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:
Gebauer Expires 29 January 2027 [Page 33]
Internet-Draft IACP July 2026
| 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 element's endpoint attribute MUST resolve to a valid
IACP EID or transport locator via the ERP.
* The element's action attribute MUST reference an "action"
that MUST be executable within the current PSS context.
* The section MUST be reconciled with the PSS sequence
vector to ensure consistency.
* The section MUST be evaluated by the LL-Entity
before any "answer" is transmitted.
4.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.
4.1.6.5. ANML-Specific Error Handling
The following ANML-specific error conditions MUST be handled by the
DHI:
Gebauer Expires 29 January 2027 [Page 34]
Internet-Draft IACP July 2026
* 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 constraint is violated
during an submission, the LL-Entity MUST drop the packet
and propagate a blacklisting broadcast.
4.1.6.6. ANML Transport Parameters
The following IACP transport parameters are defined for ANML
negotiation:
| 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.
4.2. EID Routing Protocol (ERP) - Subprotocol
4.2.1. Protocol Entities and Abstraction Layer
4.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
Gebauer Expires 29 January 2027 [Page 35]
Internet-Draft IACP July 2026
contexts MUST remain strictly decoupled from other AAIs operating on
the same host infrastructure.
4.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.
4.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.
4.2.2. Session Cryptography and Isolation Mechanics
4.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:
Gebauer Expires 29 January 2027 [Page 36]
Internet-Draft IACP July 2026
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.
4.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).
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) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 37]
Internet-Draft IACP July 2026
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.
4.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.
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.
4.2.3. Protocol Operations
4.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).
Gebauer Expires 29 January 2027 [Page 38]
Internet-Draft IACP July 2026
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.
4.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.
4.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 39]
Internet-Draft IACP 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.
4.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 40]
Internet-Draft IACP 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.
4.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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.4. Secure Handshake and Connection Management
4.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 41]
Internet-Draft IACP 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.
4.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 42]
Internet-Draft IACP 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 43]
Internet-Draft IACP 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.
4.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.
4.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 44]
Internet-Draft IACP 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.
4.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 45]
Internet-Draft IACP 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.
4.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.
4.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.
4.2.5. Resource Governance
Gebauer Expires 29 January 2027 [Page 46]
Internet-Draft IACP July 2026
4.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.
4.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 47]
Internet-Draft IACP 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.
4.2.6. Fault Tolerance, Resiliency, and Degraded Operations
Gebauer Expires 29 January 2027 [Page 48]
Internet-Draft IACP July 2026
4.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.
4.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 49]
Internet-Draft IACP 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.
4.2.7. Decentralized Security Governance and Slashing
4.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.
4.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 50]
Internet-Draft IACP 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.
4.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 51]
Internet-Draft IACP 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.
4.2.7.4. Slashing Thresholds
The Two-Phase Slashing Escrow (2PSE) mechanism enforces the following
thresholds:
Gebauer Expires 29 January 2027 [Page 52]
Internet-Draft IACP 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.
4.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.
4.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.
4.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 53]
Internet-Draft IACP July 2026
4.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.
4.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.
4.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.
4.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 54]
Internet-Draft IACP 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.
4.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.
4.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.
4.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 55]
Internet-Draft IACP 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.
4.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.
4.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.
4.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.
4.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 56]
Internet-Draft IACP July 2026
4.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.
4.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 57]
Internet-Draft IACP 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.
4.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.
4.2.10.4. TEE-Specific Measurement Formats
Intel TDX Measurements:
Gebauer Expires 29 January 2027 [Page 58]
Internet-Draft IACP 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 59]
Internet-Draft IACP 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"
}
4.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 60]
Internet-Draft IACP 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"
}
4.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 61]
Internet-Draft IACP July 2026
4.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 |
4.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.
5. DHT Namespace Architecture and Distributed Security
5.1. Distributed Hash Table
5.1.1. General
The Internet Agent Communication Protocol (IACP) utilizes a globally
distributed, decentralized lookup architecture based on a Distributed
Hash Table (DHT) to maintain public records without relying on
centralized single points of failure. The routing infrastructure
operates as an overlay network where participating nodes collectively
maintain the mapping directory, ensuring high availability, fault
tolerance, and resilience against targeted node churn.
5.1.2. DHT Namespace Structure
The DHT primary key space uses a flat, uniform 256-bit space
generated via cryptographic hashing (KEY = SHA-256("path")). The
structural mapping within the global directory maps an absolute
string identifier or specific spatial coordinate to its respective
destination metadata object, primarily an Ephemeral Agent Identity
(EID) or a transport boundary mapping vector. Namespaces use
deterministic hierarchical reverse-notation paths (e.g.
Gebauer Expires 29 January 2027 [Page 62]
Internet-Draft IACP July 2026
org.agentnet.marketplace.energy).
+---------------------------------------------------------------------+
| DHT 256-Bit Uniform Keyspace |
+---------------------------------------------------------------------+
| [0x0000...0000] [0xFFFF...FFFF] |
+---------------------------------------------------------------------+
| |
v v
SHA-256(Namespace String) SHA-256(EID)
To enforce separation between functional routing environments and
semantic application layers, the DHT segregates the cryptographic
keyspace using explicit namespace routing bits embedded within the
target coordinate schema.
5.1.3. DHT Overlay Construction
The IACP DHT overlay is structured as a Kademlia-based distributed
hash table [Kademlia] with a 256-bit identifier space. Each
participating node is assigned a Node ID, which is the SHA-256 hash
of its EID.
5.1.3.1. Peer Discovery and Bootstrap
A node joining the IACP DHT overlay MUST obtain at least one
bootstrap entry point. Bootstrap entries MAY be obtained through:
1. Static Bootstrap Nodes: A set of well-known, stable nodes
operated by the namespace curator or infrastructure provider.
These are configured out-of-band.
2. DNS-based Discovery: A DNS SRV record [RFC2782] for _iacp-
dht._udp.{namespace} MAY be used to discover bootstrap nodes.
3. Cache Persistence: Nodes SHOULD persist a local cache of
previously known peers to accelerate rejoining.
Upon obtaining bootstrap contact, the node performs a Kademlia
FIND_NODE operation to populate its routing table (k-buckets). The
routing table uses a bucket size of k = 20.
5.1.3.2. Routing Table Maintenance
Each node maintains a routing table of k-buckets organized by XOR
distance from its own Node ID. Buckets are structured as follows:
* Bucket 0: peers with a shared prefix length of 255 bits (closest)
Gebauer Expires 29 January 2027 [Page 63]
Internet-Draft IACP July 2026
* Bucket i: peers with a shared prefix length of (255 - i) bits
* Maximum bucket size: k = 20
When a bucket is full and a new peer is discovered, the node pings
the least-recently-seen peer in the bucket. If the peer responds,
the new peer is not added. If the peer does not respond, it is
evicted and the new peer is added.
5.1.3.3. Replication and Redundancy
To ensure availability under churn, each key-value pair (EID-to-
locator mapping or Forwarding Ticket) MUST be stored on the k closest
nodes to the key, where k = 20. Additionally:
* Replication Factor: r = 7 (the key is stored on the 7 closest
nodes).
* Republish Interval: Nodes MUST republish their own mappings every
T_republish = 24 hours.
* Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes
MUST refresh a mapping before expiration by re-issuing the STORE
operation.
5.1.3.4. Lookup Operations
Lookups for an EID coordinate follow the standard Kademlia iterative
lookup:
1. The initiating node selects alpha = 3 nodes from its routing
table closest to the target key.
2. It sends parallel FIND_NODE requests to these nodes.
3. Each responding node returns the k closest nodes it knows to the
target key.
4. The initiator updates its routing table with the responses and
continues the iterative process until it has contacted the
closest nodes or until no closer nodes are found.
The lookup is considered successful if the target key is found or if
the closest nodes report that the key does not exist.
Gebauer Expires 29 January 2027 [Page 64]
Internet-Draft IACP July 2026
5.1.3.5. Anti-Eclipse and Sybil Protections
To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces
the following:
1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which
already require Proof-of-Work for registration (see Section 5.3).
This makes Sybil generation computationally expensive.
2. Randomized Bucket Selection: When selecting nodes for lookup
operations, the initiator SHOULD include a random selection from
the k-bucket in addition to the closest nodes to prevent an
attacker from monopolizing a bucket.
3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5
minutes) ping the least-recently-seen peer in each bucket to
detect churn and evict stale entries.
5.1.3.6. Lookup Flow
The iterative lookup process follows this flow:
+-------------+ +-------------+ +-------------+
| Initiator | | Node A | | Node B |
+-------------+ +-------------+ +-------------+
| | |
| 1. FIND_NODE | |
|------------------>| |
| | |
| 2. RETURN k | |
|<------------------| |
| | |
| 3. FIND_NODE | |
|-------------------------------------->|
| | |
| 4. RETURN k | |
|<--------------------------------------|
| | |
v (Continue until closest nodes found) v
+-------------+ +-------------+ +-------------+
| Result | | Closest | | Closest |
| Found | | Node Set | | Node Set |
+-------------+ +-------------+ +-------------+
5.1.3.7. Global Directory Quorum and Consensus
Gebauer Expires 29 January 2027 [Page 65]
Internet-Draft IACP July 2026
5.1.3.7.1. Quorum Formation
A Global Directory Quorum for a given EID or key is formed as
follows:
1. Candidate Selection: The initiating node selects the k = 20
closest nodes to the target key (SHA-256(EID) for EID mappings,
SHA-256(Namespace) for namespace operations) from its routing
table.
2. Quorum Selection: From these 20 candidates, the quorum is formed
by selecting a deterministic subset of n = 7 nodes. The
selection uses the following algorithm:
* Sort the 20 candidates by XOR distance to the target key.
* Apply a pseudo-random permutation seeded by the target key:
PRP_key = SHA-256(target_key || "IACP_QUORUM_SALT")
* Select the first 7 nodes from the permuted list.
This randomized selection prevents an attacker from predicting or
monopolizing the quorum for a specific key.
3. Quorum Set: The resulting set Q = {q1, q2, ..., q7} constitutes
the Global Directory Quorum for the target key. The quorum set
is valid for T_quorum = 1 hour from the time of selection. After
T_quorum expires, the quorum MUST be reformed.
4. Quorum Caching: Nodes SHOULD cache the quorum set for a given key
to avoid re-computation. Cache entries MUST be invalidated on
quorum expiry or when the node's routing table changes
significantly (e.g., after joining or leaving the overlay).
5.1.3.7.2. Byzantine Fault Tolerance
The Global Directory Quorum operates under the following fault
tolerance assumptions:
* BFT Assumption: The quorum tolerates up to f = 2 Byzantine faults
among the 7 quorum nodes. This is consistent with the standard
BFT bound of n = 3f + 1 (i.e., 7 >= 3*2 + 1 = 7).
* Failure Modes: Byzantine failures include:
- Malicious nodes submitting false PoM tickets.
- Nodes colluding to suppress valid PoM tickets.
Gebauer Expires 29 January 2027 [Page 66]
Internet-Draft IACP July 2026
- Nodes equivocating (signing conflicting validation results).
- Nodes failing to respond within the timeout window.
* Honest Node Assumption: The protocol assumes that at least f + 1 =
3 nodes in any quorum are honest (non-Byzantine). This is the
minimum required to achieve consensus.
* Stronger Assumptions: Applications requiring higher fault
tolerance MAY increase the quorum size n to support larger f. The
relationship n >= 3f + 1 MUST be maintained.
5.1.3.7.3. PoM Ticket Validation Protocol
A PoM ticket is validated by the Global Directory Quorum through the
following protocol:
1. Ticket Submission: The accusing node submits a PoM ticket (Type
0x18) to the quorum. The ticket MUST be sent to all 7 quorum
nodes. The submission includes the PoM_Ticket structure.
2. Individual Validation (Phase 1): Each quorum node independently
validates the PoM ticket:
a. Signature Verification: Verify that Signature_A and
Signature_B are valid Ed25519 signatures against the Target_EID
public key.
b. Structural Check: Verify that Header_Fragment_A and
Header_Fragment_B are structurally non-identical.
c. Freshness Check: Verify that the Timestamp is within T_fresh
= 5 minutes of the node's current time. Nodes MUST reject
tickets with stale timestamps.
d. Double-Spending Check: Verify that the Target_EID is not
already in STATE_SLASHED.
If any validation check fails, the node MUST respond with a
POM_VALIDATION_REJECT message indicating the failure reason.
3. Voting Phase (Phase 2): Each node that successfully validates the
PoM ticket sends a POM_VALIDATION_ACCEPT message to all other
quorum nodes. The message MUST include the node's signature:
Gebauer Expires 29 January 2027 [Page 67]
Internet-Draft IACP July 2026
POM_VALIDATION_ACCEPT = {
Ticket_Hash: SHA-256(PoM_Ticket),
EID_Validator: EID of the validating node,
Timestamp: Current time,
Signature: Sign_Ed25519(Private_Key_Validator,
Ticket_Hash || EID_Validator || Timestamp)
}
1. Consensus Phase (Phase 3): Each node collects validation
messages. Consensus is reached when at least m = 4 out of 7
nodes have sent POM_VALIDATION_ACCEPT for the same ticket hash.
The threshold m = ceil((n + 1) / 2) = ceil(8/2) = 4 ensures a
simple majority.
2. Commit Phase (Phase 4): Upon reaching consensus, each node:
a. Commits the PoM ticket to its local ledger. b. Triggers the
2PSE process, transitioning the Target_EID to STATE_CHALLENGED.
c. Propagates the committed PoM ticket to the DHT overlay.
The committing node sends a POM_COMMIT message to the quorum:
POM_COMMIT = {
Ticket_Hash: SHA-256(PoM_Ticket),
Consensus_Proof: [POM_VALIDATION_ACCEPT_1, ..., POM_VALIDATION_ACCEPT_m],
EID_Committer: EID of the committing node,
Signature: Sign_Ed25519(Private_Key_Committer, Ticket_Hash || Consensus_Proof)
}
1. Timeout: If the quorum does not reach consensus within
T_consensus = 30 seconds, the ticket validation fails. The
accusing node MAY retry the submission after an exponential
backoff (T_base = 2 seconds, T_max = 60 seconds).
5.1.3.7.4. Network Partition and Split-Brain Handling
Network partitions (split-brain scenarios) are handled as follows:
1. Partition Detection: Nodes detect partitions by monitoring quorum
member responsiveness. If a node fails to receive responses from
at least m = 4 quorum members within T_heartbeat = 10 seconds,
the node assumes a partition exists.
2. Quorum Reform: During a partition, the node MUST NOT initiate new
PoM validations. Existing validation attempts continue.
3. Conflict Resolution: If two partitions independently validate
conflicting PoM tickets, the following rules apply:
Gebauer Expires 29 January 2027 [Page 68]
Internet-Draft IACP July 2026
a. Larger Partition: The partition with the larger number of
quorum nodes (>= 4) takes precedence. The smaller partition MUST
discard its validation results and synchronize with the larger
partition upon reconnection.
b. Tie Handling: If both partitions have exactly 3 nodes (a 3-4
split), no consensus is possible. All validation attempts in
both partitions MUST be aborted. The target EID remains in
STATE_NOMINAL. The accusing node MUST retry after the partition
resolves.
c. Rollback: When a partition resolves, nodes in the smaller
partition MUST roll back any state changes made during the
partition (e.g., PoM ticket commits) and synchronize with the
larger partition's state.
4. Conflict Log: All partition events, including aborted validations
and rollback decisions, MUST be logged for audit purposes. The
log MUST include timestamps, partition node sets, and the
affected target EIDs.
5. Recovery: After partition resolution, nodes SHOULD wait
T_recovery = 60 seconds before initiating new PoM validations to
allow the overlay to stabilize.
5.1.3.7.5. Quorum Member Liveness
To ensure quorum availability, the following liveness rules apply:
1. Heartbeat: Each quorum member MUST send a QUORUM_HEARTBEAT
message to all other quorum members every T_heartbeat = 10
seconds.
2. Failure Detection: If a node misses T_heartbeat_fail = 3
consecutive heartbeats (30 seconds), it is considered failed.
3. Member Replacement: When a quorum member is considered failed,
the remaining nodes MUST replace it. The replacement is selected
from the k = 20 candidate set as the next node in the permuted
list that is not already in the quorum.
4. Quorum Stability: The quorum SHOULD maintain n = 7 nodes at all
times. Replacement MUST occur within T_replace = 60 seconds of
failure detection.
Gebauer Expires 29 January 2027 [Page 69]
Internet-Draft IACP July 2026
5.1.3.8. Routing Table Maintenance
Each node maintains a routing table of k-buckets organized by XOR
distance from its own Node ID. Buckets are structured as follows:
* Bucket 0: peers with a shared prefix length of 255 bits (closest)
* Bucket i: peers with a shared prefix length of (255 - i) bits
* Maximum bucket size: k = 20
When a bucket is full and a new peer is discovered, the node pings
the least-recently-seen peer in the bucket. If the peer responds,
the new peer is not added. If the peer does not respond, it is
evicted and the new peer is added.
When a node's routing table is initialized, it contains a single
bucket covering the entire 256-bit identifier space (bucket 0). As
the node learns about more peers, the bucket splits according to the
following algorithm:
* The node maintains a list of buckets, each covering a contiguous
range of the identifier space.
* When a bucket exceeds its maximum size k = 20, the node splits the
bucket into two new buckets.
* The split point is determined by the node's own Node ID: the
bucket is divided at the bit position where the node's ID differs
from the bucket's range midpoint.
* The left bucket (closer to 0x0000...0000) and right bucket (closer
to 0xFFFF...FFFF) each cover half of the original range.
* The node redistributes the existing peers from the original bucket
into the two new buckets based on their XOR distance to the node's
own ID.
* Buckets that do not contain the node's own ID MAY be split
further, but only if they contain at least k + 1 peers.
The splitting process continues until the routing table contains
buckets for each prefix length where the node has at least one peer.
To maintain bucket freshness, each bucket entry includes a timestamp
of the last successful contact with the peer. The least-recently-
seen peer is determined by comparing these timestamps. When a bucket
is full and a new peer is discovered, the node pings the least-
Gebauer Expires 29 January 2027 [Page 70]
Internet-Draft IACP July 2026
recently-seen peer in the bucket. If the peer responds within T_ping
= 1 second, the node updates the peer's timestamp to the current
time, the new peer is not added, and the node MAY add the new peer to
a replacement cache. If the peer does not respond within T_ping, the
node removes the stale peer from the bucket, adds the new peer to the
bucket with the current timestamp, and if the replacement cache
contains peers for this bucket, the node SHOULD attempt to add them
as well.
To detect churn and evict stale entries, nodes MUST periodically
refresh each bucket:
* The refresh interval is T_refresh = 5 minutes.
* For each bucket, the node selects the least-recently-seen peer and
sends a ping.
* If the peer responds, the timestamp is updated.
* If the peer does not respond, it is evicted and replaced by the
most recent peer from the replacement cache, if available.
* If the replacement cache is empty, the bucket is left with one
fewer entry.
* The refresh process is spread across the T_refresh interval to
avoid bursts of network traffic. The node SHOULD refresh buckets
in random order.
The following limits apply to the routing table:
* Maximum buckets: 256 (one per bit prefix length)
* Maximum bucket size: k = 20
* Maximum total routing table entries: 256 * 20 = 5120 entries
In practice, a node will only have entries in buckets where it has
discovered peers. The total number of entries is typically O(log n)
where n is the number of nodes in the overlay, which is around 160
entries for a network of 2^160 nodes. Nodes SHOULD implement a
maximum routing table size of 5120 entries. If this limit is
exceeded, the node SHOULD evict the least-recently-seen peers from
the least-relevant buckets (those furthest from the node's own ID).
Each node maintains a replacement cache for each bucket. The
replacement cache stores peers that were discovered but could not be
added because the bucket was full:
Gebauer Expires 29 January 2027 [Page 71]
Internet-Draft IACP July 2026
* Cache size: C = 10 entries per bucket (RECOMMENDED).
* Cache entries have a TTL of T_cache = 1 hour.
* When a peer is evicted from a bucket, the most recent entry from
the replacement cache is promoted to the bucket.
* When a new peer is discovered and the bucket is full, the peer is
added to the replacement cache if it is not already present.
The replacement cache prevents the loss of potential routing
information when buckets are full.
5.1.3.9. Replication and Redundancy
To ensure availability under churn, each key-value pair (EID-to-
locator mapping or Forwarding Ticket) MUST be stored on the k closest
nodes to the key, where k = 20. Additionally:
* Replication Factor: r = 7 (the key is stored on the 7 closest
nodes).
* Republish Interval: Nodes MUST republish their own mappings every
T_republish = 24 hours.
* Expiration: Mappings have a TTL of T_expire = 48 hours. Nodes
MUST refresh a mapping before expiration by re-issuing the STORE
operation.
The replication set for a key is determined as follows:
* The node computes the key's SHA-256 hash (for namespace mappings)
or uses the EID directly (for EID-to-locator mappings).
* The node performs a FIND_NODE lookup to identify the k = 20
closest nodes to the key.
* The replication set is the first r = 7 nodes from this list.
* The key-value pair is stored on all r nodes.
To ensure redundancy, each replication node MUST store the key-value
pair for T_expire = 48 hours. If a replication node fails, the
remaining nodes SHOULD replicate the key to a replacement node from
the k = 20 candidate set.
To prevent accumulation of stale mappings:
Gebauer Expires 29 January 2027 [Page 72]
Internet-Draft IACP July 2026
* Each node MUST periodically (every T_prune = 1 hour) scan its
local DHT storage for entries with expired TTLs.
* Entries older than T_expire = 48 hours MUST be deleted.
* Entries with TTL less than T_expire_alert = 6 hours SHOULD trigger
a refresh request to the originating node.
* If the originating node does not refresh the entry within
T_expire, the entry is deleted.
Nodes SHOULD implement a lazy deletion strategy: entries are marked
as stale and deleted on access rather than during periodic scans, to
reduce CPU overhead.
5.1.3.10. Lookup Operations
Lookups for an EID coordinate follow the standard Kademlia iterative
lookup:
1. The initiating node selects alpha = 3 nodes from its routing
table closest to the target key.
2. It sends parallel FIND_NODE requests to these nodes.
3. Each responding node returns the k closest nodes it knows to the
target key.
4. The initiator updates its routing table with the responses and
continues the iterative process until it has contacted the
closest nodes or until no closer nodes are found.
The lookup is considered successful if the target key is found or if
the closest nodes report that the key does not exist.
5.1.3.11. Anti-Eclipse and Sybil Protections
To mitigate Eclipse and Sybil attacks, the IACP DHT overlay enforces
the following:
1. Proof-of-Work for Node IDs: Node IDs are derived from EIDs, which
already require Proof-of-Work for registration. This makes Sybil
generation computationally expensive.
2. Randomized Bucket Selection: When selecting nodes for lookup
operations, the initiator SHOULD include a random selection from
the k-bucket in addition to the closest nodes to prevent an
attacker from monopolizing a bucket.
Gebauer Expires 29 January 2027 [Page 73]
Internet-Draft IACP July 2026
3. Bucket Freshness: Nodes MUST periodically (every T_refresh = 5
minutes) ping the least-recently-seen peer in each bucket to
detect churn and evict stale entries.
5.1.3.12. Lookup Flow
The iterative lookup process follows this flow:
+-------------+ +-------------+ +-------------+
| Initiator | | Node A | | Node B |
+-------------+ +-------------+ +-------------+
| | |
| 1. FIND_NODE | |
|------------------>| |
| | |
| 2. RETURN k | |
|<------------------| |
| | |
| 3. FIND_NODE | |
|-------------------------------------->|
| | |
| 4. RETURN k | |
|<--------------------------------------|
| | |
v (Continue until closest nodes found) v
+-------------+ +-------------+ +-------------+
| Result | | Closest | | Closest |
| Found | | Node Set | | Node Set |
+-------------+ +-------------+ +-------------+
5.1.3.13. Local Caching
To reduce DHT lookup latency and network overhead, nodes SHOULD
maintain a local cache of recently resolved EID-to-locator mappings
and Forwarding Tickets.
The local cache is a key-value store with the following structure:
* Key: SHA-256(EID) (for EID-to-locator mappings) or the storage key
(for Forwarding Tickets)
* Value: (IP address, Port, Generation Counter, Timestamp, TTL)
* TTL: T_cache = 300 seconds (5 minutes) for EID-to-locator
mappings, T_forward = 7 days for Forwarding Tickets
When a node needs to resolve an EID:
Gebauer Expires 29 January 2027 [Page 74]
Internet-Draft IACP July 2026
1. The node checks the local cache for the key SHA-256(EID).
2. If the entry exists and has not expired (Timestamp + TTL >
current_time):
* The node returns the cached mapping.
* The node updates the entry's timestamp to the current time.
3. If the entry does not exist or has expired:
* The node performs a DHT lookup.
* If the lookup succeeds, the node stores the result in the
cache with TTL = 300 seconds.
The local cache MUST be invalidated under the following conditions:
* The node receives a MIGRATION_VECTOR for the EID with a higher
Generation Counter.
* The node receives a REVOCATION_SUBMIT for the EID.
* The node detects that the cached IP address is unreachable (ping
fails).
* The cache entry's TTL expires.
When a cache entry is invalidated, the node MUST remove the entry
from the cache and perform a fresh DHT lookup on the next request.
The local cache SHOULD be limited to C_max = 10000 entries to prevent
memory exhaustion. When the cache exceeds this limit, the node
SHOULD evict the least-recently-used (LRU) entries first. Nodes in
resource-constrained environments (e.g., IoT devices) SHOULD use a
smaller cache size (e.g., C_max = 1000 entries) to reduce memory
consumption.
5.1.3.14. Churn Handling
The DHT overlay MUST handle node churn (nodes joining, leaving, and
failing) gracefully.
When a node joins the DHT overlay:
1. The node obtains bootstrap contact.
Gebauer Expires 29 January 2027 [Page 75]
Internet-Draft IACP July 2026
2. The node performs a FIND_NODE lookup for its own Node ID to
populate its routing table.
3. The node sends a STORE operation to the replication set for its
own EID-to-locator mapping.
4. The node begins participating in routing and query forwarding.
When a node leaves the DHT overlay gracefully:
* The node SHOULD send a LEAVE message to the replication nodes
storing its key-value pairs.
* The node SHOULD store its key-value pairs on replacement nodes
before leaving.
* The node SHOULD send a PSS_TEARDOWN to terminate all active PSS
sessions.
If a node leaves without notice (crash or network partition), the
replication set must handle the failure.
Nodes detect failures using the following mechanisms:
* PING/PONG: Nodes periodically ping peers in their routing table.
If a peer fails to respond to T_ping_fail = 3 consecutive pings
(each separated by T_ping_interval = 1 second), the peer is
considered failed.
* Quorum Heartbeat: Quorum members send heartbeats every T_heartbeat
= 10 seconds. Failure to receive 3 consecutive heartbeats
indicates a failure.
* Passive Detection: If a node fails to respond to FIND_NODE or
STORE requests, it is considered potentially failed. The
requesting node SHOULD retry with a different node.
When a node in the replication set fails:
1. The remaining replication nodes detect the failure via heartbeat.
2. The remaining nodes select a replacement from the k = 20
candidate set.
3. The replacement node is the next node in the permuted list that
is not already in the quorum and is reachable.
Gebauer Expires 29 January 2027 [Page 76]
Internet-Draft IACP July 2026
4. The remaining nodes replicate all key-value pairs for the
affected key to the replacement node.
5. The quorum is restored to n = 7 nodes.
When a network partition occurs:
* Partition Detection: Nodes detect partitions by monitoring quorum
member responsiveness. If a node fails to receive responses from
at least m = 4 quorum members within T_heartbeat = 10 seconds, the
node assumes a partition exists.
* During a partition, nodes MUST NOT initiate new PoM validations.
* If two partitions independently commit conflicting state, the
larger partition (>= 4 nodes) takes precedence.
* After partition resolution, nodes in the smaller partition MUST
roll back any state changes made during the partition and
synchronize with the larger partition.
* Nodes SHOULD wait T_recovery = 60 seconds after partition
resolution before initiating new operations.
The DHT overlay is designed to handle churn rates of up to 10% of
nodes per hour without significant performance degradation. The
following factors contribute to churn resilience:
* Replication factor r = 7 ensures that data remains available even
if multiple replication nodes fail.
* Bucket refresh (T_refresh = 5 minutes) detects and evicts stale
peers quickly.
* Replacement cache ensures that routing table entries are replaced
efficiently.
* Local cache reduces DHT lookup frequency during churn events.
5.1.3.15. DHT Message Types
The following DHT-specific message types are defined and used
internally by the DHT overlay. They are not exposed to the
application layer. The wire formats for these message types are
defined in Appendix A.
Gebauer Expires 29 January 2027 [Page 77]
Internet-Draft IACP July 2026
| Type | Name |
|------|--------------------|
| 0x3A | DHT_FIND_NODE |
| 0x3B | DHT_FIND_NODE_RESP |
| 0x3C | DHT_STORE |
| 0x3D | DHT_STORE_ACK |
| 0x3E | DHT_PING |
| 0x3F | DHT_PONG |
| Type | Description |
|------|--------------------------------------------------|
| 0x3A | Find the k closest nodes to a target key |
| 0x3B | Response to FIND_NODE with list of closest nodes |
| 0x3C | Store a key-value pair on a replication node |
| 0x3D | Acknowledgment of STORE operation |
| 0x3E | Ping a peer to check liveness |
| 0x3F | Response to PING |
Additionally, each node in the Node List is encoded as:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node IP [16 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. Namespace Registration and Curation
5.2.1. Root Namespace Registration
Root namespace allocation maps human-readable, deterministic
alphanumeric tags directly to target resource coordinates inside the
DHT. To prevent arbitrary domain-squatting, sybil-based lookup
pollution, and coordinate collision, registration requires an initial
un-spendable burn-allocation fee or verified resource escrow
contract.
Gebauer Expires 29 January 2027 [Page 78]
Internet-Draft IACP July 2026
A root namespace record binds a unique, permanent cryptographic
curation certificate containing a designated public key authorized to
issue modifications, updates, or cryptographic revocations.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace Alphanumeric String Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cryptographic Curation Public Key (Ed25519) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Escrow Allocation Index Block |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2. Sub-Namespace Delegation
The authorized root custodian public key can sign delegation tokens
to authorize downstream sub-namespaces. A valid delegation consists
of a cryptographic path chain evaluated dynamically during resource
lookups.
+------------------+ Signed Delegation +---------------------+
| Root Namespace | ------------------------> | Sub-Namespace Token |
| [Root Ed25519] | | [Sub-Node Ed25519] |
+------------------+ +---------------------+
|
v
+---------------------+
| Terminal Target EID |
+---------------------+
Lookups resolving sub-namespaces MUST process the complete
authorization chain from the root key down to the terminal record.
Any missing signature, expired validation window, or invalid
alignment with the parent path constraints breaks the validation path
and causes resolution to abort.
5.3. Proof-of-Work and Reputation-Based Access Control
Gebauer Expires 29 January 2027 [Page 79]
Internet-Draft IACP July 2026
5.3.1. Dynamic PoW Difficulty
To defend the DHT routing network from distributed denial-of-service
(DDoS) vectors and lookup depletion attacks, directory mutations and
intensive lookup queries require a valid Proof-of-Work (PoW) token
header based on Hashcash.
The targeted leading-zero bit difficulty coefficient D_req adjusts
dynamically depending on the processing load, lookup queue latency,
and incoming query volume of individual directory zones.
D_req = D_base + floor(gamma * (Queue_Current / Queue_Max))
Where D_base represents the baseline minimum bit difficulty, gamma
represents the scalar operational multiplier, and Queue_Current
measures the active buffer depth of the handling node. Lookups
submitted with an insufficient trailing zero bitmask are dropped at
the ingress interface without allocating resources or memory space.
5.3.2. Access Tickets and Joint Liability
Validated transactions give the requester an implicit short-lived
routing credit via an Access Ticket. If an internal Autonomous Agent
Instance (AAI) generates malicious control plane activity, the
hosting infrastructure and the individual peer entity are held under
joint liability.
+------------------------+ +-----------------------+
| Hosting Provider / |<= Joint Liability =>| Malicious Autonomous |
| Parent LL-Entity | | Agent Instance (AAI) |
+------------------------+ +-----------------------+
| |
v v
Slashing of Host Collateral EID Key Revocation List
If an individual agent breaks wire protocols, the network scales back
the performance tracking matrix of the entire network segment or host
infrastructure layer, creating a strong structural incentive for
local platforms to isolate misbehaving processes.
5.4. Anti-Abuse Mechanisms
Gebauer Expires 29 January 2027 [Page 80]
Internet-Draft IACP July 2026
5.4.1. Token-Bucket Filters and Rate Limiting
Ingress packets undergo rate-limiting enforcement via an independent
Token-Bucket algorithmic state machine integrated inside the
transport layer. The configuration uses two static parameters:
maximum bucket capacity (C_max) and token replenishment rate
(R_repl).
Tokens_Available = min(C_max, Tokens_Previous + (Delta_Time *
R_repl))
Each transaction consumes tokens based on the lookup size and
complexity. If Tokens_Available falls below the required request
cost, the packet is discarded, and the node returns an explicit error
payload to trigger transport-level backoff.
5.4.2. Autonomous Circuit Breakers
When a target zone or specific peer coordinate experiences sudden
inbound traffic anomalies exceeding standard operation limits by
orders of magnitude, local routing nodes autonomously change state to
prevent cascading memory depletion.
+--------------+ Anomalous Load > Threshold +--------------+
| STATE_OPEN | -------------------------------> | STATE_TRIPPED|
+--------------+ +--------------+
^ |
| Cooldown + Load Normal |
+-------------------------------------------------+
While in STATE_TRIPPED, nodes refuse all standard lookup mutations
and enter an aggressive caching enforcement mode. The node drops
unauthenticated requests immediately, allowing the transport stack to
bypass costly parsing loops and handle targeted resource exhaustion
at wire speeds.
5.5. Proof of Malfeasance (PoM) and Slashing
5.5.1. PoM Ticket Specification
A Proof of Malfeasance (PoM) ticket contains clear cryptographic
proof that a node or agent committed protocol violations, such as
double-signing contradictory routing states, deploying conflicting
mapping epochs, or fabricating directory routing steps.
PROOF_OF_MAL:
Gebauer Expires 29 January 2027 [Page 81]
Internet-Draft IACP 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 | Offense Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Malicious Node Identity (EID) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest A |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Conflicting Signed Message Digest B |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Accusing Node Cryptographic Signature |
| [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ticket must explicitly contain both conflicting signed messages
to allow independent verification by any peer executing standard
verification routines without relying on a central authority.
5.5.1.1. Timestamp Synchronization
The PoM_Ticket structure includes a Timestamp field marked as
"Cluster-synchronized verification time". This subsection specifies
how nodes achieve and maintain the required clock synchronization.
The Timestamp field MUST represent the current time in UTC as a
64-bit UNIX timestamp (seconds since 1970-01-01T00:00:00Z). Nodes
MUST ensure that their local clocks are synchronized to within a
bounded drift of the global time reference.
5.5.1.1.1. Primary Synchronization Mechanism: NTP
Nodes MUST implement Network Time Protocol (NTP) [RFC5905] or a
successor standard (e.g., NTS [RFC8915]) for clock synchronization.
The following requirements apply:
Gebauer Expires 29 January 2027 [Page 82]
Internet-Draft IACP July 2026
1. NTP Pool: Nodes SHOULD use a diverse set of NTP servers. The
RECOMMENDED minimum is 4 servers from different administrative
domains to reduce the risk of coordinated time manipulation.
2. Synchronization Interval: Nodes MUST synchronize their clocks at
least once every T_sync = 60 seconds while online.
3. Drift Tolerance: The acceptable clock drift between any two nodes
in the DHT overlay is T_drift = 5 seconds. NTP implementations
MUST maintain accuracy within this bound.
4. Fallback Servers: Nodes SHOULD maintain a list of at least 2
fallback NTP servers in case the primary servers are unreachable.
5.5.1.1.2. Alternative Synchronization Mechanisms
For environments where NTP is unavailable or undesirable, nodes MAY
use alternative synchronization mechanisms:
1. Precision Time Protocol (PTP) [IEEE1588]: For networks with
hardware timestamping support, PTP provides higher accuracy (sub-
microsecond) than NTP.
2. GPS/GNSS: For nodes with GPS receivers, GPS time provides a
highly accurate global time reference.
3. Blockchain Timestamping: Nodes in a blockchain-integrated
deployment MAY use block timestamps as a reference. However,
block timestamps are only advisory (per [RFC6962] Section 2.1)
and MUST NOT be the sole synchronization source.
4. Manual Configuration: As a last resort, operators MAY manually
configure the system time. This is NOT RECOMMENDED for
production deployments.
Regardless of the mechanism used, nodes MUST maintain the T_drift = 5
seconds accuracy bound.
5.5.1.1.3. Time Validation in PoM Ticket Processing
When a quorum node validates a PoM ticket, it MUST perform the
following time-related checks:
1. Absolute Freshness: The Timestamp MUST be within T_fresh = 5
minutes of the node's current time. Tickets with timestamps
older than T_fresh MUST be rejected.
Gebauer Expires 29 January 2027 [Page 83]
Internet-Draft IACP July 2026
2. Clock Drift Compensation: The node MAY apply a drift compensation
factor of up to T_drift = 5 seconds when evaluating the freshness
of a ticket. This compensates for minor synchronization
differences between nodes.
3. Replay Prevention: If a ticket with the same Timestamp and
Target_EID has been seen within the last T_replay = 10 minutes,
the node MUST reject the ticket as a replay attempt.
4. Monotonic Sequence Check: The node MUST verify that the
Sequence_Number in the ticket is strictly greater than the last
known sequence number for the Target_EID. This prevents
reordering attacks even if timestamps are close.
5.5.1.1.4. Handling Synchronization Failures
If a node cannot synchronize its clock within T_drift = 5 seconds for
more than T_sync_fail = 10 minutes, the following rules apply:
1. Quorum Participation: The node MUST NOT participate in PoM ticket
validation until synchronization is restored. It SHOULD respond
with a POM_VALIDATION_REJECT (reason: CLOCK_UNSYNCHRONIZED) to
any validation requests.
2. Degraded Operation: The node MAY continue to forward packets and
participate in routing, but MUST mark its state as
CLOCK_UNSYNCHRONIZED in its DHT advertisements.
3. Recovery: Upon successful resynchronization, the node MUST wait
T_recovery = 5 minutes before rejoining the quorum to allow its
clock to stabilize.
4. Alerting: The node SHOULD generate an alert to the operator when
synchronization fails.
5.5.1.1.5. Offline Node Timestamp Handling
Nodes that operate offline for extended periods (e.g., mobile agents)
MAY use the following fallback:
1. Last Known Time: The node uses the last known synchronized time
plus the elapsed time since synchronization (measured by the
node's local oscillator).
2. Bounded Drift: The node MUST assume a worst-case drift of
T_drift_offline = 1 second per hour of offline operation.
Gebauer Expires 29 January 2027 [Page 84]
Internet-Draft IACP July 2026
3. Freshness Check at Reconnection: Upon reconnection, the node MUST
synchronize its clock before submitting any PoM tickets. The
node MUST discard any tickets generated during the offline period
that exceed T_fresh = 5 minutes.
4. Trust Reduction: Nodes that have been offline for more than
T_offline_max = 24 hours SHOULD be treated as less trustworthy
and SHOULD be subject to escalated PoW requirements until they
have been online for T_online_stable = 1 hour.
5.5.1.1.6. Normative Notes
The timestamp synchronization requirements in this section are
normative. Conforming IACP implementations:
* MUST implement NTP [RFC5905] or provide equivalent synchronization
accuracy (T_drift <= 5 seconds).
* MUST validate timestamps according to the rules in this section.
* MUST handle synchronization failures according to the rules in
this section.
5.5.1.2. PoM Ticket Canonicalization and Semantics
A Proof of Malfeasance (PoM) ticket relies on the comparison of two
cryptographically signed messages to detect equivocation. This
section defines:
1. Which messages are subject to PoM verification.
2. How messages are canonicalized for comparison.
3. What semantic conditions constitute a valid PoM.
5.5.1.2.1. Canonicalization Target: The Signed Payload
For the purposes of PoM verification, the "message" that is signed is
defined as the complete IACP control frame payload for the following
message types:
* ERP_REGISTER (Type 0x15)
* MIGRATION_VECTOR (Type 0x17)
* ERP_EVOLVE (Type 0x16)
* Any message that modifies the EID-to-locator mapping
Gebauer Expires 29 January 2027 [Page 85]
Internet-Draft IACP July 2026
The canonicalization process MUST include all fields of these
messages except:
* The Signature field itself (it is self-referential)
* Timestamp fields (they are not part of the signed payload)
* Nonce fields (they are not part of the signed payload)
All other fields, including EID, IP address, Generation Counter, and
Application Digest, are included in the canonicalized message.
5.5.1.2.2. Canonicalization Format
The canonicalization format depends on the message serialization:
1. Binary Messages (e.g., ERP_REGISTER, MIGRATION_VECTOR): The
message is canonicalized as the concatenation of all fields in
the order they appear in the wire format, excluding the signature
field. The length of each field is determined by its type.
2. JSON Messages (e.g., Trust Anchor Documents): The message is
canonicalized using JSON Canonicalization Scheme (JCS) [RFC8785].
3. CBOR Messages: The message is canonicalized using Canonical CBOR
as defined in RFC 8949 Section 3.9.
The canonicalized representation is a byte string. The SHA-256 hash
of this byte string is used as the message digest in the PoM ticket.
5.5.1.2.3. Semantic Fields for PoM Verification
The following fields are considered semantically relevant for PoM
verification:
| Field | Message Types |
|--------------------|-----------------------------------|
| Source_EID | All |
| Current_IP | ERP_REGISTER, MIGRATION_VECTOR |
| Generation_Counter | ERP_REGISTER, MIGRATION_VECTOR |
| Current_App_Digest | ERP_EVOLVE |
| Field | Semantics |
|--------------------|-----------------------------------|
| Source_EID | The identity of the signer |
| Current_IP | The claimed transport locator |
| Generation_Counter | The epoch of the mapping |
| Current_App_Digest | The software version |
Gebauer Expires 29 January 2027 [Page 86]
Internet-Draft IACP July 2026
Two messages are considered "conflicting" if:
1. They are signed by the same EID.
2. They have the same Generation_Counter (same logical epoch).
3. They differ in at least one semantically relevant field.
Messages with different Generation_Counter values are NOT considered
conflicting (they represent legitimate state evolution). Messages
with the same Generation_Counter but differing in non-semantic fields
(e.g., TTL, Nonce) are NOT considered conflicting.
5.5.1.2.4. PoM Verification Procedure
The Global Directory Quorum validates a PoM ticket as follows:
1. Extract Digests: Extract Digest_A and Digest_B from the PoM
ticket. Each digest is the SHA-256 hash of a canonicalized
signed message.
2. Verify Signatures: Verify that Signature_A and Signature_B are
valid against Target_EID and cover Digest_A and Digest_B
respectively.
3. Retrieve Original Messages: Retrieve the original messages (or
their canonicalized forms) from the network ledger or from the
ticket itself. The ticket MUST include enough information to
locate or reconstruct the original messages.
4. Canonicalize: Re-canonicalize the original messages using the
procedure described above.
5. Hash Comparison: Compute SHA-256 of the canonicalized messages
and verify they match Digest_A and Digest_B.
6. Semantic Comparison: Compare the semantically relevant fields of
the two messages.
7. Decision: If the messages are signed by the same EID, have the
same Generation_Counter, and differ in at least one semantically
relevant field, the PoM ticket is valid. Otherwise, it is
invalid.
5.5.1.2.5. Example: Legitimate vs. Malicious Updates
Legitimate IP Change (MIGRATION_VECTOR):
Gebauer Expires 29 January 2027 [Page 87]
Internet-Draft IACP July 2026
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X,
IP = 192.0.2.2, Gen = 6 }
Gen differs -> NOT a PoM. This is legitimate mobility.
Equivocation (Malicious):
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5 } Message_B: { EID = X,
IP = 192.0.2.2, Gen = 5 }
Gen same, IP differs -> PoM VALID. This is equivocation.
Same State (No Violation):
Message_A: { EID = X, IP = 192.0.2.1, Gen = 5, TTL = 300 } Message_B:
{ EID = X, IP = 192.0.2.1, Gen = 5, TTL = 600 }
Gen same, IP same, only TTL differs -> NOT a PoM.
5.5.1.3. Decentralized PoM Count Consistency
The IACP DHT overlay maintains a decentralized, eventually consistent
count of PoM tickets per EID to enforce the slashing threshold
(PoM_Count >= 3 within a rolling 24-hour window). This section
specifies how the PoM_Count is maintained, synchronized, and
reconciled across the DHT overlay.
5.5.1.3.1. Local PoM Ledger
Each node in the DHT overlay maintains a local PoM ledger containing
PoM tickets that the node has observed and validated. The ledger
consists of the following fields per entry:
PoM_Ledger_Entry = {
Target_EID: The EID of the accused entity (32 bytes),
Ticket_Hash: SHA-256 of the PoM ticket (32 bytes),
Timestamp: UNIX timestamp of ticket validation (8 bytes),
Validator_EID: EID of the validating node (32 bytes),
Quorum_Proof: Reference to quorum consensus (variable),
Status: VALID, CHALLENGED, or SLASHED (1 byte)
}
The local PoM ledger is maintained for a minimum of T_ledger = 30
days to ensure that historical data is available for audits and for
nodes that have been offline.
Gebauer Expires 29 January 2027 [Page 88]
Internet-Draft IACP July 2026
5.5.1.3.2. PoM Count Replication
The PoM_Count for a given EID is replicated in the DHT overlay to
ensure availability and consistency:
1. Storage Key: The PoM ledger entries for an EID are stored in the
DHT under the key SHA-256("pom:" || Target_EID).
2. Replication Factor: PoM ledger entries are replicated with
redundancy factor r = 7 to ensure availability under churn.
3. Replication Nodes: The r closest nodes to the storage key (SHA-
256("pom:" || Target_EID)) are responsible for storing and
replicating the PoM ledger entries.
4. Merkle Tree Structure: To enable efficient synchronization, PoM
ledger entries are organized as a Merkle tree. The root hash is
stored in the DHT and is updated whenever a new entry is added.
The PoM_Count for an EID is calculated as the number of VALID PoM
tickets in the ledger that fall within the rolling 24-hour window:
PoM_Count(EID, t) = count({ entry in PoM_Ledger(EID) |
entry.Status = VALID AND
entry.Timestamp > (t - 24h) })
5.5.1.3.3. PoM Ticket Publishing and Ledger Update
When a PoM ticket is validated by the Global Directory Quorum, the
committing node MUST update the PoM ledger:
1. Local Update: The node adds the validated PoM ticket to its local
PoM ledger with Status = VALID and the current timestamp.
2. DHT Propagation: The node publishes the updated PoM ledger entry
to the DHT under SHA-256("pom:" || Target_EID). The publication
uses a DHT_POM_UPDATE message:
Gebauer Expires 29 January 2027 [Page 89]
Internet-Draft IACP July 2026
DHT_POM_UPDATE = {
Target_EID: The EID of the accused entity (32 bytes),
Ticket_Hash: SHA-256 of the PoM ticket (32 bytes),
Timestamp: UNIX timestamp of validation (8 bytes),
Validator_EID: EID of the validating node (32 bytes),
Quorum_Proof: Consensus proof (variable),
Merkle_Root_New: Updated Merkle tree root (32 bytes),
Signature: Sign_Ed25519(Private_Key_Validator,
Target_EID || Ticket_Hash ||
Timestamp || Merkle_Root_New)
}
1. Replication: The r replication nodes receive the DHT_POM_UPDATE,
verify the signature and quorum proof, and update their local
ledger copies.
2. Acknowledgment: Each replication node responds with a DHT_POM_ACK
message confirming receipt and successful update.
3. Conflict Resolution: If a replication node detects a conflict
(e.g., inconsistent Merkle root), it initiates a reconciliation
process.
5.5.1.3.4. PoM Ledger Reconciliation
To ensure consistency across the DHT overlay, PoM ledger entries are
reconciled periodically:
1. Merkle Root Comparison: Nodes periodically (every T_reconcile = 1
hour) compare their Merkle root for each EID with the other
replication nodes. If a discrepancy is found, the node initiates
a reconciliation.
2. Reconciliation Protocol: The node with the more complete ledger
(higher sequence number or larger Merkle tree) sends the missing
entries to the other nodes.
3. Conflict Handling: If two nodes have conflicting entries for the
same PoM ticket (e.g., one VALID, one CHALLENGED), the entry with
the higher consensus proof (more quorum signatures) takes
precedence.
4. Time-based Reconciliation: Nodes that have been offline for more
than T_offline = 1 hour MUST perform a full ledger
synchronization upon reconnection by requesting the full Merkle
tree from the closest replication node.
Gebauer Expires 29 January 2027 [Page 90]
Internet-Draft IACP July 2026
5. Lazy Reconciliation: Nodes MAY defer reconciliation of low-
priority EIDs (those with PoM_Count < 2) to reduce network
overhead.
5.5.1.3.5. Slashing Decision Consistency
The slashing decision (PoM_Count >= 3) MUST be made consistently
across the DHT overlay:
1. Threshold Check: The slashing decision is triggered only after a
PoM ticket has been validated by the Global Directory Quorum and
the updated PoM_Count is confirmed by at least m = 4 out of 7
replication nodes.
2. Consensus on Slashing: The Global Directory Quorum MUST reach
consensus on the slashing decision. The quorum nodes verify that
PoM_Count >= 3 by checking their local PoM ledgers and the
replicated ledger entries.
3. Slashing Commitment: Upon reaching consensus, the quorum nodes
transition the target EID to STATE_SLASHED and publish a
SLASH_COMMIT message to the DHT:
SLASH_COMMIT = {
Target_EID: The EID being slashed (32 bytes),
PoM_Count: The confirmed PoM count (1 byte),
Timestamp: UNIX timestamp of slashing (8 bytes),
Slashing_Reason: Reason code (4 bytes),
Consensus_Proof: [SLASH_VOTE_1, ..., SLASH_VOTE_m],
Signature: Sign_Ed25519(Private_Key_Committer,
Target_EID || PoM_Count ||
Timestamp || Consensus_Proof)
}
1. Propagation: The SLASH_COMMIT message is propagated to all nodes
in the DHT overlay. Nodes that receive this message MUST update
their local PoM ledger and mark the Target_EID as STATE_SLASHED.
5.5.1.3.6. Rolling Window Consistency
The rolling 24-hour window for PoM_Count calculation requires
consistent timestamps across the DHT overlay:
1. Timestamp Standardization: All PoM ticket timestamps MUST be
cluster-synchronized. Nodes that observe a timestamp discrepancy
greater than T_drift = 5 seconds SHOULD reject the PoM ticket.
Gebauer Expires 29 January 2027 [Page 91]
Internet-Draft IACP July 2026
2. Window Calculation: The rolling window is calculated as
(current_time - 24h) to current_time. Nodes MUST use their local
synchronized time for this calculation.
3. Sliding Window Maintenance: Nodes SHOULD periodically (every
T_window_maintenance = 1 hour) prune their local PoM ledger of
entries that are older than 24 hours to reduce storage overhead.
4. Window Check at Slashing: When evaluating PoM_Count for slashing,
nodes MUST exclude entries older than 24 hours to ensure that
only recent violations are considered.
5.5.1.3.7. Byzantine Behavior in PoM Counting
The following Byzantine failure modes are addressed:
1. Double-Counting: A malicious node might attempt to add the same
PoM ticket multiple times. The Merkle tree structure prevents
this, as each ticket hash is unique.
2. Count Inflation: A malicious node might attempt to forge PoM
tickets for a target EID. The quorum validation prevents this,
as forged tickets will not pass signature verification.
3. Count Suppression: A malicious replication node might attempt to
suppress valid PoM tickets. The replication factor r = 7 ensures
that at least m = 4 nodes are needed to suppress a ticket, making
this expensive.
4. Inconsistent Views: Different nodes might have different views of
the PoM_Count due to network partitions. The quorum-based
consensus mechanism ensures that slashing decisions are made only
when at least m = 4 nodes agree on the count.
5.5.1.3.8. Message Types for PoM Ledger
The following IACP message types are defined:
| Type | Name | Description |
|--------|--------------------|--------------------------------------|
| 0x33 | DHT_POM_UPDATE | Update PoM ledger entry in DHT |
| 0x34 | DHT_POM_ACK | Acknowledgment of PoM ledger update |
| 0x35 | SLASH_COMMIT | Commit slashing decision to DHT |
| 0x36 | SLASH_VOTE | Vote on slashing decision |
Gebauer Expires 29 January 2027 [Page 92]
Internet-Draft IACP July 2026
5.5.2. Two-Phase Slashing Escrow (2PSE)
To safeguard against malicious or erroneous accusations, the network
processes slashing actions using a strict two-phase challenge
framework.
+--------------------+ PoM Published +--------------------+
| STATE_NOMINAL | -----------------> | STATE_CHALLENGED |
+--------------------+ +--------------------+
|
Escrow Epoch Expires |
(No Valid Counter-Proof) |
v
+--------------------+
| STATE_SLASHED |
+--------------------+
1. Phase 1 (Escrow State): Upon receipt of a valid PoM ticket, the
target entity transitions into STATE_CHALLENGED. The node's
associated staking deposit or registration token is locked within
a secure escrow quarantine window for a fixed epoch block count.
2. Phase 2 (Execution State): If the challenged node cannot submit a
cryptographically valid counter-proof before the quarantine
window expires, the escrow balance is permanently burned, and the
node changes state to STATE_SLASHED.
5.5.3. Curator Quarantine and Decapitation
If a trusted root namespace curator node is flagged by a verified PoM
ticket, the protocol enforces immediate quarantine procedures. The
flagged node's authorization rights are suspended, and its assigned
DHT zones are temporarily managed by an uncompromised backup peer
quorum.
+-------------------------+ +-------------------------+
| Compromised Curator Node| | Backup Peer Quorum |
+-------------------------+ +-------------------------+
| State: SUSPENDED | | State: ACTIVE GOVERNANCE|
| Rights: REVOKED | | Action: Re-route Zone |
+-------------------------+ +-------------------------+
If the protocol violation is confirmed, the node undergoes total
network decapitation. Its long-term curation keys are added to a
decentralized revocation bloom filter, making all downstream
delegation signatures void across the network ecosystem.
Gebauer Expires 29 January 2027 [Page 93]
Internet-Draft IACP July 2026
5.5.4. Reputation Penalties
The reputation metric (Section 3.6.1) uses the following penalties:
* PoM Score Normalization: PoM_Score(t) = min(1.0, PoM_Count(t) / k)
with k = 5. This means that up to 5 PoM tickets are used to
normalize the score; beyond 5, the score is capped at 1.0.
* Decay Mechanism: PoM tickets older than 30 days are weighted with
a decay factor of 0.5 (i.e., their contribution to the reputation
score is halved). This ensures that older violations have less
impact on current reputation.
* Rehabilitation: A node with a reputation score below 0.3
(Section 3.6.2) MAY be rehabilitated after a cooldown period of 7
days without any new PoM tickets. The rehabilitation resets the
PoM_Count to 0.
5.6. Compromise Recovery and Hot-Docking
5.6.1. Migration Stream Serialization
The AAI operational state is serialized as a CBOR-encoded [RFC8949]
object containing the following fields:
* eid: The EID of the migrating agent (32 bytes)
* iat: The Instance Authentication Token (32 bytes)
* session_state: A CBOR map of active PSS session states
* ese_state: A CBOR map of Ephemeral State Endpoint data
* timestamp: A 64-bit UNIX timestamp
* sequence: A monotonically increasing sequence number
The serialized object is compressed using zlib (level 6) to reduce
transfer size.
5.6.2. Migration Stream Encryption
The serialized and compressed state is encrypted using AES-GCM-256
with a symmetric key derived from the EID's private key and the
backup host's public key:
K_migration = HKDF-SHA256(ECDH(Private_EID, Public_Backup), salt="",
info="IACP_MIGRATION_v1")
Gebauer Expires 29 January 2027 [Page 94]
Internet-Draft IACP July 2026
The encrypted migration stream includes a 12-byte AEAD nonce and a
16-byte authentication tag.
5.6.3. Forwarding Ticket Generation
After a successful migration, the compromised host generates a
Forwarding Ticket (Section 3.5) containing the new backup host's
network locator. The Forwarding Ticket is signed with the EID's
private key and stored in the DHT under KEY = SHA-256(EID).
In-flight packets destined for the old locator are redirected to the
new locator via the Forwarding Ticket. The old host's EID mapping is
invalidated after T_invalidate = 5 minutes.
5.6.4. Migration Flow
The hot-docking migration follows this sequence:
+------------------+ +-------------------+
| Compromised Host | | Backup Host |
| (Old A) | | (New B) |
+------------------+ +-------------------+
| |
| 1. Serialize AAI State (CBOR + zlib) |
| (eid, iat, session_state, ese_state) |
| |
| 2. Encrypt with AES-GCM-256 |
| K_migration = HKDF-SHA256(ECDH(...)) |
| |
| 3. Send Migration Stream |
|------------------------------------------>|
| |
| | 4. Decrypt &
| | Restore State
| | (AAI Context
| 5. Generate Forwarding Ticket | on New Host)
| (KEY = SHA-256(EID), New Locator) |
| |
| 6. Store in DHT & Invalidate Old Mapping |
| (after T_invalidate = 5 min) |
| |
v v
+------------------+ +-------------------+
| Old Host | | New Host |
| Invalidated | | Active |
+------------------+ +-------------------+
Gebauer Expires 29 January 2027 [Page 95]
Internet-Draft IACP July 2026
5.6.5. EID Revocation and Propagation
When an EID is compromised or when a curator key is revoked, the
affected node MUST execute a revocation procedure to invalidate the
compromised identity and propagate the revocation to the DHT overlay.
5.6.5.1. Revocation Trigger Conditions
An EID revocation is triggered under the following conditions:
1. Cryptographic Compromise: The private key associated with the EID
is known or suspected to be compromised. This is determined by
the node operator.
2. Curator Decapitation: A curator node is flagged by a validated
PoM ticket and undergoes quarantine.
3. Administrative Revocation: An explicit administrative directive
is issued by the managing user or parent orchestration system.
4. Reputation Threshold: The EID's reputation score falls below
R_state < 0.3 for T_reputation = 7 consecutive days.
5.6.5.2. Revocation Certificate
Upon triggering a revocation, the node generates a Revocation
Certificate. The certificate MUST include the following fields:
Revocation_Certificate = {
EID_Revoked: The EID being revoked (32 bytes),
EID_New: The new EID replacing the revoked one (32 bytes),
Timestamp: UNIX timestamp of revocation (8 bytes),
Reason: Revocation reason code (4 bytes),
Sequence_Number: Monotonically increasing sequence (8 bytes),
Signature: Sign_Ed25519(Private_Key_Old, EID_Revoked || EID_New ||
Timestamp || Reason || Sequence_Number)
}
Revocation Reason Codes:
| Code | Name | Description |
|------|----------------------|---------------------------------------|
| 0x01 | KEY_COMPROMISE | Private key exfiltrated or suspected |
| 0x02 | CURATOR_DECAPITATION | Curator node flagged by PoM |
| 0x03 | ADMINISTRATIVE | Administrative override |
| 0x04 | REPUTATION_FAILURE | Reputation score below threshold |
| 0x05 | OPERATIONAL_ROTATION | Scheduled rotation (Section 3.4) |
| 0x06 | KEY_LEAK_DETECTED | Key leak detected by external means |
Gebauer Expires 29 January 2027 [Page 96]
Internet-Draft IACP July 2026
The Signature MUST be verifiable against the EID_Revoked public key.
This proves that the revocation request originates from the
legitimate owner of the EID (or the holder of the private key at the
time of revocation).
5.6.5.3. Revocation Submission
The Revocation Certificate is submitted to the Global Directory
Quorum for the key SHA-256(EID_Revoked):
1. The node sends a REVOCATION_SUBMIT message to all 7 quorum nodes.
2. Each quorum node validates the certificate:
* Verify the Signature against EID_Revoked.
* Verify that Timestamp is within T_fresh = 5 minutes of current
time.
* Verify that Sequence_Number is greater than the last known
sequence for this EID.
* Verify that EID_New is a valid Ed25519 public key (not zero,
not already revoked).
* Verify that the EID_Revoked is not already in STATE_SLASHED.
3. If all checks pass, the quorum node responds with
REVOCATION_ACCEPT. Otherwise, REVOCATION_REJECT.
4. Consensus is reached when at least m = 4 out of 7 nodes have sent
REVOCATION_ACCEPT.
5. Upon consensus, each quorum node:
* Marks EID_Revoked as REVOKED in its local ledger.
* Records the mapping EID_Revoked -> EID_New for forwarding.
* Propagates the revocation to the DHT overlay.
5.6.5.4. Revocation Propagation
Once the revocation is committed by the quorum, it is propagated
through the DHT overlay:
1. Quorum nodes store the Revocation Certificate in the DHT under:
KEY = SHA-256("revocation:" || EID_Revoked)
Gebauer Expires 29 January 2027 [Page 97]
Internet-Draft IACP July 2026
2. The certificate is replicated with redundancy factor r = 7 and
has a TTL of T_revoke_ttl = 30 days. After T_revoke_ttl, the
revocation record expires and the EID MAY be reused (subject to
new key generation).
3. Nodes that encounter a stale revocation record (older than
T_revoke_ttl) MUST discard it and mark the EID as available for
reuse.
4. The EID_Revoked is added to a decentralized revocation bloom
filter for rapid lookup. The bloom filter is propagated to all
DHT nodes every T_bloom = 1 hour.
5. All active PSS sessions involving EID_Revoked: a. MUST be
terminated by both peers. b. SHOULD be re-established using
EID_New, subject to re-authentication.
5.6.5.5. Revocation Checking
Before accepting any PSS_INIT or processing any packet, a node MUST
check whether the target EID is revoked:
1. The node queries the local cache for the revocation status of the
target EID. The cache contains: a. Revoked EIDs (from quorum
commits) b. TTL for each entry (T_revoke_ttl = 30 days from
revocation)
2. If the target EID is in the cache: a. The node MUST reject the
PSS_INIT. b. The node MUST respond with PSS_REJECT (Reason:
EID_REVOKED). c. The node SHOULD suggest EID_New if available.
3. If the target EID is not in the cache, the node performs a DHT
lookup under KEY = SHA-256("revocation:" || EID_Revoked).
4. If a revocation record exists: a. The node MUST add the EID to
its local cache. b. The node MUST reject the PSS_INIT. c. The
node SHOULD cache EID_New for future forwarding.
5. If no revocation record exists, the node assumes the EID is
valid.
5.6.5.6. Revocation Forwarding
To ensure continued communication during EID rotation, the revoked
EID MAY forward packets to the new EID:
1. The DHT stores a forwarding mapping for T_forward = 7 days: KEY =
SHA-256("forward:" || EID_Revoked) -> EID_New
Gebauer Expires 29 January 2027 [Page 98]
Internet-Draft IACP July 2026
2. Nodes receiving a packet destined for EID_Revoked during
T_forward:
* Check the forwarding mapping.
* If found, forward the packet to EID_New.
* Include a FORWARDED header to indicate the redirection.
3. After T_forward, the forwarding mapping expires and packets to
EID_Revoked are dropped.
5.6.5.7. Revocation Recovery (Accidental Revocation)
If a revocation was issued in error, the node MAY submit a Revocation
Reversal Certificate:
Revocation_Reversal = {
EID_Revoked: The EID that was revoked (32 bytes),
EID_New: The EID that was intended to replace it (32 bytes),
Timestamp: UNIX timestamp of reversal (8 bytes),
Reason: Reversal reason code (4 bytes),
Signature: Sign_Ed25519(Private_Key_New, EID_Revoked || EID_New ||
Timestamp || Reason)
}
The Reversal MUST be submitted to the quorum within T_reversal = 1
hour of the original revocation. If accepted by consensus, the
quorum reverses the revocation and removes EID_Revoked from the
revocation bloom filter.
5.7. Layer-Separated Economic Governance and Edge Gatekeeper Model
The IACP employs a strict separation between transport-layer
forwarding and application-layer/authorization logic.
5.7.1. Layer 4 Kernel-Space Fast-Path
The IACP architecture defines a logical L4 fast-path responsible for
low-latency, high-throughput processing of incoming packets before
they are handed to the application layer. This fast-path operates at
the kernel or dataplane layer and is decoupled from the L7
application-space logic. Its responsibilities are:
* Basic header validation and rate limiting.
* Sequence vector and replay protection checks.
Gebauer Expires 29 January 2027 [Page 99]
Internet-Draft IACP July 2026
* Forwarding of opaque authorization envelopes to the L7 gateway.
* Immediate session teardown upon receiving a signal from the L7
layer.
The L4 fast-path MUST remain agnostic to the semantics of
authorization tokens; it performs only structural validation (e.g.,
verifying header format, checking sequence numbers) and forwards the
opaque payload without interpretation.
The specification uses eBPF as the reference implementation mechanism
for the L4 fast-path, but this is not a requirement. The L4 fast-
path is defined as an abstract functional component, not as a
specific implementation technology. Conforming IACP implementations
MAY implement the L4 fast-path using other mechanisms, including:
* XDP (eXpress Data Path) for high-performance packet processing
(similar to eBPF).
* DPDK (Data Plane Development Kit) for userspace packet processing.
* A pure userspace implementation using standard sockets (for
resource-constrained or development environments).
* Hardware offloading on network interface cards (if supported).
* Platform-specific kernel modules (e.g., Windows Filtering
Platform, Apple Network Extension).
Regardless of the implementation mechanism, the L4 fast-path MUST
provide the following functional guarantees:
* The fast-path MUST be capable of processing packets at line rate
(or as close to it as the underlying hardware permits).
* The fast-path MUST NOT allocate significant memory or state for
packets that fail basic validation.
* The fast-path MUST forward opaque authorization envelopes to the
L7 gateway without modification.
* The fast-path MUST accept and act on teardown signals from the L7
gateway.
Implementations using eBPF or XDP SHOULD follow the best practices
for packet processing defined in the Linux kernel documentation.
Implementations using other mechanisms SHOULD provide equivalent
performance and security properties.
Gebauer Expires 29 January 2027 [Page 100]
Internet-Draft IACP July 2026
5.7.2. Layer 7 Application-Space Door-Keeper (Opaque Authorization
Envelope)
EMILIA Receipt Handling and Verification
The Opaque Authorization Envelope (Section 5.7.2) carries EMILIA
receipts as opaque byte arrays. The IACP protocol itself does not
interpret, canonicalize, or verify the contents of the envelope.
An IACP implementation that wishes to verify a carried EMILIA receipt
SHOULD call the EMILIA reference verifier on the envelope bytes and
the sender's pinned public key. The verifier performs the JCS
canonicalization [RFC8785] and signature verification internally.
The canonicalization profile is defined in
[I-D.schrock-ep-authorization-receipts], where the action hash is the
SHA-256 of the JCS-canonical action.
The EMILIA reference verifier is available in the following
implementations:
* npm: @emilia-protocol/verify
* PyPI: emilia-verify
* Go: github.com/emiliaprotocol/emilia-protocol/packages/go-verify
Implementations that choose to perform canonicalization on the IACP
side MUST use the conformance vectors provided in the EMILIA
repository (canonicalization.v1.json) to ensure byte-for-byte
compatibility, as any canonicalization difference between two
implementations constitutes a signature-forgery surface.
5.7.3. Asynchronous Verification and Teardown
Full validation of authorization logic (EMILIA signature
verification, WRT budget check, etc.) occurs asynchronously in
application space. However, the L7 fast-path pre-validation does not
constitute a durable authorization grant, it is solely a structural
check of the opaque authorization envelope's format, nonce, and
signature shape, with the actual authorization decision deferred to
the asynchronous application-space verification.
If a violation is detected: - The L7 gateway SHALL immediately issue
a targeted teardown signal to the L4 layer. - The L4 layer MUST
terminate the affected PSS and associated ESEs. - The offending EID
SHALL be placed on a temporary deny-list (ranging 5–60 minutes,
configurable per namespace). - Permanent EID revocation MUST only
occur after a validated Proof of Malfeasance (PoM) by DHT curators.
Gebauer Expires 29 January 2027 [Page 101]
Internet-Draft IACP July 2026
For security reasons, authorization failures SHOULD use silent
teardown (no specific error code exposed to the sender).
The diagram below serves as illustration of this part:
+-------------------------------------------------------+
| L4 Fast-Path (eBPF) |
| - Header & Rate Limit Validation |
| - Sequence Vector Replay Checks |
+-------------------------------------------------------+
|
v [Forwarding Opaque Envelope]
+-------------------------------------------------------+
| L7 Application Gateway |
| - Opaque Authorization Envelope Processing |
| - Fast-Path Pre-Validation (Signature, Nonce, Format) |
+-------------------------------------------------------+
| |
v (Pass: Allocation Granted) v (Fail)
+-----------------------+ +-----------------------+
| DHI Execution Context | | Silent Session Drop |
| & Active PSS / ESEs | | & Threat Signal |
+-----------------------+ +-----------------------+
| |
v (Asynchronous Full Validation) |
+-----------------------+ |
| App-Space Verification| |
| (EMILIA / WRT Check) | |
+-----------------------+ |
| |
v (If Violation Detected) v
+-------------------------------------------------------+
| Targeted L4 Teardown Vector Signal |
| - Terminate Affected PSS & Associated ESEs |
| - Temporary EID Deny-List Placement (5-60 min) |
+-------------------------------------------------------+
6. Agent to Agent Communication
6.1. Ephemeral State Endpoints (ESE)
Gebauer Expires 29 January 2027 [Page 102]
Internet-Draft IACP July 2026
6.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.
6.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.
6.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)
6.2. Discovery Spaces (DS)
6.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)
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:
Gebauer Expires 29 January 2027 [Page 103]
Internet-Draft IACP July 2026
+------------+ +----------+ +----------+ +-----------+
| 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
6.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.
6.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).
6.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.
6.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.
Gebauer Expires 29 January 2027 [Page 104]
Internet-Draft IACP July 2026
6.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".
6.3. Anonymous Discovery Mechanism
6.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.
6.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.
6.4. Persistent State Sessions (PSS)
6.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.
Gebauer Expires 29 January 2027 [Page 105]
Internet-Draft IACP July 2026
6.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.
6.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
Gebauer Expires 29 January 2027 [Page 106]
Internet-Draft IACP July 2026
network locators. Session allocations finalize only upon reception
of a matching PSS_ACK from the initiator, proving network boundary
control.
6.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.
6.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.
Gebauer Expires 29 January 2027 [Page 107]
Internet-Draft IACP July 2026
6.5. Session Termination and Revocation
6.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.
6.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.
7. Interoperability with other Protocols
7.1. Interoperability with WIMSE
IACP and the WIMSE architecture [I-D.ietf-wimse-arch] address
different layers of the workload communication stack. WIMSE defines
the architecture for workload identity and authentication, consisting
of three building blocks: trust domain, workload identifier, and
identity credentials [I-D.ietf-wimse-arch]. IACP provides the
routing and transport layer for agent-to-agent communication.
7.1.1. Trust Domain and Workload Identifier Mapping
A WIMSE trust domain SHOULD be identified by a fully qualified domain
name and maps to trust anchors for validating X.509 certificates and
JWK Sets for validating Workload Identity Tokens (WITs)
[I-D.ietf-wimse-arch].
An IACP EID (Ephemeral Agent Identity) MAY be mapped to a WIMSE
Workload Identifier [I-D.ietf-wimse-identifier]. The mapping is
deployment-defined and MAY be published in the IACP DHT under KEY =
SHA-256("wimse-map:" || Namespace).
Gebauer Expires 29 January 2027 [Page 108]
Internet-Draft IACP July 2026
7.1.2. Transport of WIMSE Credentials
IACP's Opaque Authorization Envelope (Section 5.7.2) MAY carry WIMSE
credentials (Workload Identity Tokens or Workload Identity
Certificates) as opaque byte arrays. IACP does not interpret the
internal structure of these credentials; it only guarantees
authenticated delivery and cryptographic integrity of the envelope.
For WIT validation, the verifier MUST validate the JWS signature and
the cnf.jwk claim as defined in Section 5.1 of
[I-D.ietf-wimse-workload-creds]. For WIC validation, the verifier
MUST validate the X.509 certificate chain and verify that the
certificate contains exactly one SubjectAltName extension of type URI
as defined in Section 6.1 of [I-D.ietf-wimse-workload-creds].
An IACP implementation that wishes to verify a carried WIT MAY call a
WIMSE verifier on the envelope bytes, following the verification
rules defined in [I-D.ietf-wimse-workload-creds].
7.1.3. PSS as Transport for WIMSE Authentication
IACP's Persistent State Sessions (PSS) MAY be used as the transport
layer for WIMSE authentication mechanisms (WPT, HTTP Signatures, or
mutual TLS). The WIMSE authentication establishes the workload
identity of the communicating parties; the IACP PSS provides the
reliable, secure channel.
In this deployment model: - IACP handles session establishment,
mobility, and fault tolerance - WIMSE handles workload identity
authentication and credential validation
For application-layer authentication, IACP MAY carry a WIT in the
Workload-Identity-Token header for use with HTTP Message Signatures
[I-D.ietf-wimse-http-signature]. For transport-layer authentication,
IACP MAY carry a WIC for use with mTLS [I-D.ietf-wimse-mutual-tls].
These bindings are deployment- specific and do not require changes to
the core IACP specification.
The combination provides both identity assurance and reliable
communication.
Gebauer Expires 29 January 2027 [Page 109]
Internet-Draft IACP July 2026
7.1.4. Gateway Integration
WIMSE defines gateway services that MAY implement identity proxy
functionality, including authentication, token exchange, and token
transformation [I-D.ietf-wimse-arch]. IACP's Layer 7 Application
Gateway (Section 5.7.2) MAY serve as such an identity proxy for WIMSE
credentials, forwarding opaque authorization envelopes containing
WITs or other WIMSE credentials without interpreting their internal
structure.
7.1.5. Trust Domain Discovery
A WIMSE trust domain MAY publish its trust anchors for discovery
using the mechanism defined in [I-D.schwenkschuster-wimse-trust-
domain-discovery]. The mechanism defines a WIMSE Trust Bundle, a JWK
Set document containing the trust anchors for both JWT-based (wimse-
jwt) and X.509-based (wimse-x509) credentials, and a discovery
endpoint at the well-known URI:
https:///.well-known/wimse-trust-domain
An IACP relying party that receives a WIMSE credential from an
unknown trust domain MAY perform discovery to obtain the trust
anchors needed to validate the credential. The discovery procedure
follows Section 5.3 of [I-D.schwenkschuster-wimse-trust-domain-
discovery]. Discovered trust anchors MUST NOT override locally
provisioned trust anchors for the same trust domain.
7.2. Interoperability with AGTP
AGTP [I-D.hood-independent-agtp] and IACP address different layers
and concerns of the agent communication stack. AGTP provides a
dedicated application-layer protocol for AI agent traffic with native
intent-based methods, a cryptographic identity model, and protocol-
level observability and governance primitives. IACP provides
identity-locator separation, routing, mobility, and persistent
sessions for agent-to-agent communication.
The two protocols are complementary and MAY be composed in
deployments that require both agent-native methods and robust routing
and mobility support.
7.2.1. IACP as Transport for AGTP Methods
IACP's Persistent State Sessions (PSS) MAY be used as the transport
layer for AGTP method invocations. In this deployment model:
Gebauer Expires 29 January 2027 [Page 110]
Internet-Draft IACP July 2026
* The IACP PSS provides session continuity, mobility, and fault
tolerance across network transitions (generation counting,
MIGRATION_VECTOR, degraded multi-path routing). AGTP uses port
4480 by default [I-D.hood-independent-agtp].
* AGTP method invocations (QUERY, DISCOVER, DESCRIBE, EXECUTE,
DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY, and the Lifecycle
methods ACTIVATE, DEACTIVATE, REINSTATE, REVOKE, and DEPRECATE)
are carried as opaque payloads within IACP PSS_DATA_STREAM frames.
* The AGTP identity (Agent-ID) is a 256-bit value derived as SHA-256
of the Agent Genesis in its canonical-form serialization (with the
signature field excluded) [I-D.hood-independent-agtp,
Section 7.5.2]. It is independent of the IACP EID (Ephemeral
Agent Identity).
* A deployment MAY choose to map an IACP EID to an AGTP Agent-ID
through a deployment-specific mapping. Such mapping is out of
scope for this document.
The AGTP core method set consists of eighteen methods: cognitive
methods (QUERY, DISCOVER, DESCRIBE, INSPECT, SUMMARIZE, PLAN,
PROPOSE), mechanics methods (EXECUTE, DELEGATE, ESCALATE, CONFIRM,
SUSPEND, NOTIFY), and lifecycle methods (ACTIVATE, DEACTIVATE,
REINSTATE, REVOKE, DEPRECATE) [I-D.hood-independent- agtp,
Section 8.1.1].
7.2.2. AGTP Identity Document as Discovery Resource
AGTP defines an Agent Identity Document (application/vnd.agtp
.identity+json) that is returned when an agtp:// URI is resolved [I-
D.hood-independent-agtp]. An IACP agent that wishes to discover an
AGTP-speaking agent MAY resolve the AGTP URI and retrieve the Agent
Identity Document to learn the agent's capabilities, supported
methods, verification tier, and authority scopes.
The AGTP Agent Identity Document contains: - agent_id: the canonical
AGTP Agent-ID (256-bit hex-encoded) - methods: the set of supported
AGTP methods (from the eighteen- method floor or extended set) -
verification_tier: the verification tier (1, 2, or 3) per [I-D.hood-
independent-agtp, Section 7.1.9] - verification_path: the
verification path used at activation (dns-anchored, log-anchored,
hybrid, or org-asserted) - scopes_accepted: the authority scopes the
agent accepts (domain:action format) - capabilities: higher-level
service descriptors - trust_score: behavioral trust score on [0.0,
1.0]
Gebauer Expires 29 January 2027 [Page 111]
Internet-Draft IACP July 2026
IACP does not interpret the AGTP Identity Document; it is carried as
an opaque resource. The AGTP Identity Document MAY be retrieved via
the IACP DHT if a deployment chooses to store it there, or it MAY be
retrieved directly via AGTP URI resolution.
AGTP defines three verification tiers for identity anchoring [I-
D.hood-independent-agtp, Section 7.1.9]: - Tier 1 (Verified):
identity anchored via one of three paths: dns-anchored (DNS TXT
record), log-anchored (transparency log inclusion proof per RFC 9162/
RFC 9943), or hybrid (DNS + blockchain signature combination) - Tier
2 (Org-Asserted): organizational affiliation declared without
cryptographic verification - Tier 3 (Experimental): development-only,
not production-eligible
7.2.3. AGTP as the Method Layer over IACP
In a composed deployment, the following operational pattern applies:
1. The IACP EID Routing Protocol (ERP) establishes the agent's
identity and network location.
2. An IACP Persistent State Session (PSS) is established between
peers.
3. AGTP methods are invoked over the PSS channel. The AGTP Agent-ID
and Authority-Scope headers are carried alongside the IACP
headers.
4. IACP handles mobility and fault tolerance; AGTP handles the
semantic method vocabulary and governance (Attribution-Record,
Audit-ID, verification tiers).
This composition allows agents to benefit from both IACP's routing
and mobility capabilities and AGTP's intent-native method vocabulary
and observability primitives.
AGTP's Authority-Scope header uses the domain:action format (e.g.,
documents:query, payments:confirm) [I-D.hood-independent- agtp,
Appendix D]. When AGTP is composed over IACP, the Authority- Scope
header is carried as part of the AGTP payload within the IACP
PSS_DATA_STREAM frame. IACP does not enforce AGTP authority scopes;
enforcement remains at the AGTP layer.
7.2.4. Deployment Considerations
Deployments that compose IACP and AGTP SHOULD consider the following:
Gebauer Expires 29 January 2027 [Page 112]
Internet-Draft IACP July 2026
* Identity Mapping: If a deployment requires mapping between IACP
EIDs and AGTP Agent-IDs, a deployment-specific mapping mechanism
is required. Such mapping is out of scope for both
specifications. The mapping MAY be published in the IACP DHT
under KEY = SHA-256("agtp-map:" || Namespace) for discoverability.
* Session Continuity**: IACP PSS provides session continuity across
network transitions. AGTP method invocations carried over PSS
benefit from this continuity without AGTP-level mobility
mechanisms.
* Authority Scope: AGTP Authority-Scope headers are independent of
IACP's authorization model. A deployment MAY enforce both
independently or define a mapping between them. AGTP's Authority-
Scope uses the domain:action format; IACP's authorization model is
based on EID reputation and PoM.
* Governance: AGTP provides protocol-level observability and
governance (Attribution-Record, Audit-ID, verification tiers,
lifecycle methods ACTIVATE/DEACTIVATE/REVOKE/DEPRECATE). IACP
provides routing-level governance (EID reputation, PoM, 2PSE).
The two governance models are complementary and MAY be used
together in a composed deployment.
* Port and Transport: AGTP uses IANA-assigned port 4480 for both
TCP/TLS and QUIC [I-D.hood-independent-agtp, Section 12.1]. When
AGTP is composed over IACP, the AGTP messages are carried within
IACP PSS_DATA_STREAM frames, and the underlying port is determined
by the IACP transport configuration, not the AGTP port assignment.
* Trust Tiers: AGTP's verification tiers (1, 2, 3) are independent
of IACP's EID reputation system. A deployment MAY use AGTP's
verification_tier as an input to IACP's reputation calculations,
but such integration is deployment-specific and out of scope for
both specifications.
* Verification Paths: AGTP's verification_path field (dns-anchored,
log-anchored, hybrid, org-asserted) provides evidence of how the
agent's identity was anchored at activation time [I-D.hood-
independent-agtp, Section 7.1.9]. This information MAY be used by
IACP deployments to inform routing or policy decisions, but such
use is deployment-specific.
Interoperability with AGTP is OPTIONAL; IACP agents that do not
support AGTP composition operate as specified in the core IACP
specification.
Gebauer Expires 29 January 2027 [Page 113]
Internet-Draft IACP July 2026
8. IANA Considerations
This document requests the following IANA actions.
8.1. IACP Message Type Registry
IANA is requested to create a new registry titled "Internet Agent
Communication Protocol (IACP) Message Types" under the "Internet
Agent Communication Protocol (IACP) Parameters" registry group. The
registry policy is Standards Action for values 0x00-0x7F and
Specification Required for values 0x80-0xFE. The value 0xFF is
reserved for future extension. The registry policy follows
[RFC8126].
Initial contents of the registry:
| Type | Name | Reference |
|--------|-------------------------------|--------------------|
| 0x01 | DISCOVERY_REQ | Appendix A |
| 0x02 | DISCOVERY_RES | Appendix A |
| 0x03 | ACCESS_TICKET_REQ | Appendix A |
| 0x04 | ACCESS_TICKET_RES | Appendix A |
| 0x05 | DHT_TICKET_STORE | Appendix A |
| 0x06 | DHT_TICKET_QUERY | Appendix A |
| 0x07 | DHT_TICKET_RESP | Appendix A |
| 0x08 | PSS_INIT | Appendix A |
| 0x09 | PSS_ACK | Appendix A |
| 0x0A | PSS_NEG | Appendix A |
| 0x0B | PSS_DATA_STREAM | Appendix A |
| 0x0C | PSS_TEARDOWN | Appendix A |
| 0x0D | PSS_REVOCATION_PUBLISH | Appendix A |
| 0x0E | ERP_DEFLECT | Appendix A |
| 0x0F | Outer Transport Header | Appendix A |
| 0x10 | ERP_KEEPALIVE | Appendix A |
| 0x11 | ERP_INIT | Appendix A |
| 0x12 | ANML Fallback Query | Appendix A |
| 0x13 | PSS_REVOCATION_REBUTTAL | Appendix A |
| 0x14 | ERP_ALLOC | Appendix A |
| 0x15 | ERP_REGISTER | Appendix A |
| 0x16 | ERP_EVOLVE | Appendix A |
| 0x17 | MIGRATION_VECTOR | Appendix A |
| 0x18 | PROOF_OF_MAL | Appendix A |
| 0x19 | WRT_PRESENTATION | Appendix A |
| 0x1A | ESCROW_BATCH_SETTLE | Appendix A |
| 0x1B | HRP_VECTOR_RESP | Appendix A |
| 0x1C | FED_TRUST_ANCHOR_REQ | Appendix A |
| 0x1D | FED_TRUST_ANCHOR_RES | Appendix A |
| 0x1E | FED_DISCOVERY_REQ | Appendix A |
Gebauer Expires 29 January 2027 [Page 114]
Internet-Draft IACP July 2026
| 0x1F | FED_DISCOVERY_RES | Appendix A |
| 0x20 | FED_REVOCATION | Appendix A |
| 0x21 | FED_VALIDATE_REQ | Appendix A |
| 0x22 | FED_VALIDATE_RES | Appendix A |
| 0x23 | PSS_ATTEST | Appendix A |
| 0x24 | PSS_ATTEST_RES | Appendix A |
| 0x25 | ATTEST_VERIFY_REQ | Appendix A |
| 0x26 | ATTEST_VERIFY_RES | Appendix A |
| 0x27 | PURCHASE | Eco. comp. I-D |
| 0x28 | QUOTE | Eco. comp. I-D |
| 0x29 | SETTLEMENT_RECEIPT | Eco. comp. I-D |
| 0x2A | FAULT_NOTIFICATION | Appendix A |
| 0x2B | RETRY_OVERRIDE | Appendix A |
| 0x2C | ERP_STREAM | Appendix A |
| 0x2D | REVOCATION_SUBMIT | Appendix A |
| 0x2E | REVOCATION_ACCEPT | Appendix A |
| 0x2F | REVOCATION_REJECT | Appendix A |
| 0x30 | REVOCATION_FORWARD | Appendix A |
| 0x31 | REVOCATION_REVERSAL | Appendix A |
| 0x32 | ALGORITHM_NEGOTIATE | Appendix A |
| 0x33 | DHT_POM_UPDATE | Appendix A |
| 0x34 | DHT_POM_ACK | Appendix A |
| 0x35 | SLASH_COMMIT | Appendix A |
| 0x36 | SLASH_VOTE | Appendix A |
| 0x3A | DHT_FIND_NODE | Appendix A |
| 0x3B | DHT_FIND_NODE_RESP | Appendix A |
| 0x3C | DHT_STORE | Appendix A |
| 0x3D | DHT_STORE_ACK | Appendix A |
| 0x3E | DHT_PING | Appendix A |
| 0x3F | DHT_PONG | Appendix A |
The registration template for new entries in this registry is as
follows:
* Value: The numeric value assigned to the type (0x00-0xFE).
* Name: A descriptive name for the type.
* Reference: A reference to the document that defines the type.
* Description: A brief description of the type's purpose (OPTIONAL).
Values in the range 0x80-0xFE are assigned on a "Specification
Required" basis, which requires a document that provides a clear
description of the message type and its intended use.
Gebauer Expires 29 January 2027 [Page 115]
Internet-Draft IACP July 2026
8.2. IACP Flags Registry
IANA is requested to create a new registry titled "IACP Header Flags"
under the "Internet Agent Communication Protocol (IACP) Parameters"
registry group. The registry policy is _Standards Action_ for all
values. The registry defines flag bits used in the common IACP
header and in specific message types. Initial assignments are
reserved for future documents or expert review. The following
structure is established:
* Bits 0-7: General IACP flags.
* Bits 8-15: Message-type-specific flags.
* Bits 16-31: Reserved for future extension.
The registration template for new entries in this registry is as
follows:
* Bit Position: The position of the flag bit (0-31).
* Name: A descriptive name for the flag.
* Message Type: The message type(s) where this flag is applicable.
"Common" for all types, or a specific type (e.g., PSS_INIT).
* Reference: A reference to the document that defines the flag.
* Description: A brief description of the flag's purpose.
8.3. IACP Outer Transport Header Types
IANA is requested to create a new registry titled "IACP Outer
Transport Header Types" under the "Internet Agent Communication
Protocol (IACP) Parameters" registry group. The registry policy is
_Standards Action_ for all values. The following values are assigned
for the Outer Transport Header (Type field 0x0F and related
deflection types):
* 0x0E: ERP_DEFLECT
* 0x0F: Outer Transport Header
All unassigned values in the 0x00-0xFF range are reserved.
The registration template for new entries in this registry is as
follows:
Gebauer Expires 29 January 2027 [Page 116]
Internet-Draft IACP July 2026
* Value: The numeric value assigned to the type (0x00-0xFE).
* Name: A descriptive name for the type.
* Reference: A reference to the document that defines the type.
* Description: A brief description of the type's purpose (OPTIONAL).
8.4. IACP Transport Parameter Registry
IANA is requested to create a new registry titled "IACP Transport
Parameters" under the "Internet Agent Communication Protocol (IACP)
Parameters" registry group. The registry policy is _Standards
Action_ for all values. This registry lists the transport parameters
used during session establishment (e.g., via QUIC transport
parameters or PSS parameters).
Initial contents are as follows:
| Parameter ID | Name | Reference |
|--------------|--------------------------|-----------------|
| 0x0001 | MAX_FLOAT_BUF | Section 4.1.2.1 |
| 0x0002 | T_eval | Section 4.1.2.1 |
| 0x0003 | SFC_CONDITIONS_BLOCK | Section 6.4.4 |
| 0x0004 | EID_ROTATION_TTL | Section 3.4 |
| 0x0005 | ANML_SUPPORTED_VERSIONS | Section 4.1.6.6 |
| 0x0006 | ANML_PREFERRED_SERIAL | Section 4.1.6.6 |
| 0x0007 | ANML_MAX_DOCUMENT_SIZE | Section 4.1.6.6 |
| 0x0008 | ANML_MAX_NESTING_DEPTH | Section 4.1.6.6 |
The registration template for new entries in this registry is as
follows:
* Parameter ID: The numeric identifier for the parameter (2 bytes).
* Name: A descriptive name for the parameter.
* Reference: A reference to the document that defines the parameter.
* Description: A brief description of the parameter's purpose and
format.
Gebauer Expires 29 January 2027 [Page 117]
Internet-Draft IACP July 2026
8.4.1. Algorithm Registry
IANA is requested to create a new registry titled "IACP Algorithm
Suites" under the "Internet Agent Communication Protocol (IACP)
Parameters" registry group. The registry policy is Standards Action
for values 0x0001-0x7FFF and Specification Required for values
0x8000-0xFFFF.
The registration template is as follows:
* Suite ID: The numeric identifier (16-bit).
* Name: A descriptive name for the suite.
* Signature Algorithm: The signature scheme used.
* KEM/ECDH Algorithm: The key exchange or KEM used.
* Symmetric Algorithm: The symmetric encryption used.
* Hash Algorithm: The hash function used.
* Reference: A reference to the defining document.
* Description: A brief description of the suite's purpose.
This document makes no other requests to IANA.
9. Security Considerations
The Internet Agent Communication Protocol (IACP) is designed with
cryptographic identity, component isolation, and decentralized
accountability mechanisms. This section provides a comprehensive
threat model and describes the security controls implemented to
mitigate identified risks.
9.1. Threat Model
The IACP threat model considers the following categories of
adversaries and attacks:
* Network Adversaries: Entities capable of intercepting, modifying,
or injecting packets on the network path between agents.
* Malicious Peers: Agents that participate in the IACP network but
attempt to subvert protocol behavior for their own benefit.
Gebauer Expires 29 January 2027 [Page 118]
Internet-Draft IACP July 2026
* Compromised Hosts: Systems running legitimate agents that have
been compromised by external attackers.
* Eclipse Attackers: Adversaries that attempt to surround a target
node in the DHT overlay, isolating it from the rest of the
network.
* Denial-of-Service Attackers: Entities that attempt to exhaust
resources of IACP nodes or the network infrastructure.
* Sybil Attackers: Adversaries that create multiple identities to
subvert reputation or governance mechanisms.
* Collusion Resistance: The randomization seed includes thetarget
key and a fixed salt. Attackers cannot precompute quorum sets
without knowing the target key.
9.2. Identity and Authentication
All protocol control messages and active transport streams are
cryptographically bound to Ephemeral Agent Identities (EIDs) derived
from Ed25519 public keys. The three-way Dual-Cookie handshake
(PSS_INIT, PSS_NEG, PSS_ACK) combined with mandatory asymmetric
signatures on critical network frames (PSS_INIT, PSS_ACK,
ERP_DEFLECT, and Proof of Malfeasance tickets) provides mutual host
authentication and replay protection. The Local Loopback Layer
Entity (LL-Entity) enforces cryptographic execution isolation between
individual Autonomous Agent Instances (AAIs) operating on the same
physical host via localized Instance Authentication Tokens (IAT).
Exposure of persistent long-lived EID public keys to unverified
application sandboxes is prohibited through the derivation of
Ephemeral Session Derivative EIDs (ESD-EID) during legacy platform
hand-off execution vectors.
Threat Mitigated: Man-in-the-Middle (MitM) attacks, Identity
Spoofing, Session Hijacking, Replay Attacks.
9.3. Confidentiality and Integrity
Persistent State Sessions (PSS) enforce symmetric AEAD encryption
utilizing AES-GCM-256 with strictly incremented per-packet nonces for
all transactional payloads transmitted via PSS_DATA_STREAM frames.
Access to Ephemeral State Endpoints (ESE) is restricted using
negotiated Session Federation Contracts (SFC) and authenticated
Dynamic Group Keys (DGK). Forwarding vectors published to the
distributed directory are encrypted using keys derived from the
active session context to prevent intermediate routing nodes from
intercepting endpoint locators.
Gebauer Expires 29 January 2027 [Page 119]
Internet-Draft IACP July 2026
Threat Mitigated: Eavesdropping, Data Tampering, Unauthorized ESE
Access, Locator Leakage.
9.3.1. Cryptographic Suite Negotiation and Agility
* Downgrade Attacks: Both endpoints MUST include the selected Suite
ID in the PSS_ACK signature. A mismatched Suite ID MUST cause
session rejection.
* Algorithm Confusion: Implementations MUST use only the algorithms
defined by the negotiated suite for all cryptographic operations.
* Hybrid Deployment: Endpoints SHOULD select the strongest mutually
supported suite according to local policy (e.g., prefer PQC,
larger keys).
* Fallback Safety: If no common suite exists, the session MUST be
rejected. Unauthenticated or unencrypted fallback is prohibited.
9.3.2. Canonicalization and Equivocation Protection
* Canonicalization Attacks: JCS [RFC8785] and Canonical CBOR
[RFC8949] produce a unique byte representation for each semantic
value, preventing equivalent messages with different digests.
* Replay Prevention: Semantically identical messages MUST produce
the same digest. Differing digests indicate an implementation
error and MUST be rejected.
* Partial Signatures: The canonicalization procedure MUST include
all semantically relevant fields. Implementations MUST reject
signatures over incomplete canonical forms.
* Algorithm Migration: Canonicalization and the SHA-256 digest
remain unchanged across signature algorithm suites. Only the
signature algorithm itself is negotiated.
* Timestamp Handling: Timestamp fields are excluded from the
canonicalized message and validated separately for freshness.
Messages that differ only in timestamp are not considered
conflicting.
* Nonce Handling: Nonce fields are excluded from the canonicalized
message. Repeated messages with different nonces are not treated
as equivocation.
Gebauer Expires 29 January 2027 [Page 120]
Internet-Draft IACP July 2026
9.4. Denial-of-Service and Resource Exhaustion
The protocol enforces a zero-allocation parsing invariant for
unauthenticated connection states. Receiving host interfaces process
incoming DISCOVERY_REQ frames within volatile scratch memory layers,
incurring negligible processing and state overhead until the
trailing-zero Hashcash Proof-of-Work (PoW) token validation succeeds.
Decentralized infrastructure protections rely on autonomous circuit
breakers, token-bucket rate limiting, and dynamic PoW difficulty
scaling to defend Discovery Spaces and directory nodes against high-
volume flooding attacks. Cryptographically issued Access Tickets
allow constrained terminal devices to bypass heavy computation blocks
while maintaining joint liability under their parent gatekeeper
nodes.
Threat Mitigated: Distributed Denial-of-Service (DDoS), Resource
Exhaustion, Connection Flooding.
9.5. Namespace and Curation Security
Root namespace registration within the global directory requires a
verifiable Proof-of-Work burn transaction. Sub-namespace delegation
enforces signed cryptographic certificates carrying deterministic
curator identity records to ensure binding accountability.
Decentralized protocol enforcement is achieved via verifiable Proof
of Malfeasance (PoM) tickets routed to a Two-Phase Slashing Escrow
(2PSE) network layer, enabling automated curator quarantine and
identity decapitation sequences. If a top-level curation coordinate
suffers key compromise, the underlying network isolates the affected
zone and executes a hot-docking sequence to transition traffic to
authenticated backup root systems.
Threat Mitigated: Namespace Squatting, Sybil Attacks on Namespaces,
Curator Key Compromise, Malicious Delegation.
9.6. Eclipse and Sybil Attack Protections
To mitigate Eclipse and Sybil attacks on the DHT overlay (see
Section 5.1.3), the IACP DHT enforces the following protections:
1. *Proof-of-Work for Node IDs*: Node IDs are derived from EIDs,
which already require Proof-of-Work for registration. This makes
Sybil generation computationally expensive.
2. *Randomized Bucket Selection*: When selecting nodes for lookup
operations, the initiator includes a random selection from the
k-bucket in addition to the closest nodes to prevent an attacker
from monopolizing a bucket.
Gebauer Expires 29 January 2027 [Page 121]
Internet-Draft IACP July 2026
3. *Bucket Freshness*: Nodes periodically (every T_refresh = 5
minutes) ping the least-recently-seen peer in each bucket to
detect churn and evict stale entries.
Threat Mitigated: Eclipse Attacks, Sybil Attacks, Routing
Table Poisoning.
9.7. Mobility, Churn, and Forwarding Tokens
Dynamic network migration utilizes signed MIGRATION_VECTOR frames and
authenticated forwarding records committed via ERP_REGISTER packets.
These entries are versioned using monotonically increasing Generation
Counters. Receiving routers discard stale or replayed topological
propagation updates through generation index validation. During a
node's challenged escrow validation phase, the initiating endpoint
engages a degraded multi-path fragmentation and mirroring routing
pipeline to maintain session availability despite intermediary path
degradation.
Threat Mitigated: Routing Table Poisoning, Replay Attacks, Session
Disruption during Mobility.
9.8. Privacy Considerations
EIDs operate as long-lived logical pseudonyms and do not expose
deterministic bindings to real-world network identities or underlying
physical locators. The anonymous discovery mechanism permits
querying entities to access target coordinates using ephemeral key
exchanges combined with standalone PoW tokens, isolating search
metadata from persistent tracking graphs. Active Ephemeral State
Endpoints (ESE) remain structurally hidden from directory indexes by
default and accept resolution requests exclusively from authenticated
peers holding valid contract permissions. Local Points (LP) are
restricted to local process memory structures and cannot be accessed
from public network boundaries unless a local routing rule explicitly
bridges the endpoint to a Global Point (GP) coordinate.
Threat Mitigated: Linkability of Agent Activities, Correlation of
Network Traffic, Unauthorized ESE Discovery.
9.9. Residual Risks and Recommendations
Despite the security controls described in this section, the
following residual risks remain and SHOULD be considered by
implementers and deployers:
Gebauer Expires 29 January 2027 [Page 122]
Internet-Draft IACP July 2026
* Side-Channel Attacks: IACP does not provide protection against
timing or power side-channel attacks. Implementations SHOULD use
constant-time cryptographic implementations.
* Physical Layer Attacks: IACP operates at the application layer and
does not provide protection against physical layer attacks (e.g.,
wiretapping). Deployments in sensitive environments SHOULD use
lower-layer encryption (e.g., IPsec or TLS).
* Compromise of Secret Keys: If an EID's private key is compromised,
an attacker can impersonate the agent. Key rotation and
compromise recovery are provided to mitigate this risk, but
detection of compromise is outside the protocol's scope.
* Governance Attacks: The decentralized governance model relies on
the DHT quorum and reputation mechanisms. A sufficiently large
colluding group of nodes could subvert governance. The protocol
mitigates this through Proof-of-Work and 2PSE, but complete
resistance requires a sufficiently decentralized deployment.
Implementations MUST enforce strict state machine transitions and
zero-allocation parsing boundaries defined in the ERP and DHT
Namespace Architecture chapters to prevent memory exhaustion
profiles. QUIC is RECOMMENDED as the underlying transport protocol
layer to provide native stream multiplexing and rapid connection
migration. Where application-layer transactions demand end-to-end
confidentiality extensions beyond the native encapsulation boundaries
provided by this specification, deployments SHOULD wrap transport
channels in secondary lower-layer cryptographic encapsulations,
including IPsec or TLS network segmentation. No cryptographic
primitives with known structural vulnerabilities are permitted by
this specification. All asymmetric signature verification and
symmetric encryption mechanisms rely exclusively on Ed25519 and AES-
GCM-256 primitives backed by cryptographically strong pseudo-random
number generation (CSPRNG) and strict nonce serialization.
9.10. Performance and Scalability Considerations
This section provides order-of-magnitude performance and scalability
characteristics of the IACP. All values are conservative engineering
estimates intended solely as deployment guidance. They are not
normative requirements and do not constitute performance guarantees.
Actual performance depends heavily on implementation quality,
hardware, network conditions, and operational parameters. Operators
SHOULD validate these estimates in their own environment before
relying on them for capacity planning.
Gebauer Expires 29 January 2027 [Page 123]
Internet-Draft IACP July 2026
9.10.1. Agent Scalability
The IACP architecture is designed to support large-scale agent
deployments. The following estimates apply:
* DHT Size: The Kademlia-based DHT supports up to 2^160 nodes in
theory. Practical deployments with 10^6 to 10^7 nodes are
feasible with current network infrastructure.
* Concurrent Sessions: A single LL-Entity can support up to 10^4
concurrent PSS sessions per host, limited by available memory and
CPU. Each PSS session consumes approximately 2-4 KB of state
memory.
* EID Registrations: The DHT can handle up to 10^3 EID registrations
per second per quorum, assuming standard hardware. Higher rates
require increased quorum capacity.
* Agent Churn: The protocol handles churn rates of up to 10% of
nodes per hour without significant performance degradation, due to
the replication factor r = 7 and republish interval of 24 hours.
9.10.2. DHT Lookup Performance
DHT lookups follow the Kademlia iterative lookup process with alpha =
3 parallel requests:
* Average Lookup Latency: 500-1500 ms for a typical lookup across
the public internet. This includes 4-5 routing hops and network
RTT.
* Lookup Success Rate: > 99.9% for keys with active mappings,
assuming a stable network with < 10% node churn.
* Lookup Cost: Each lookup generates O(log n) = approximately 20-30
network messages (FIND_NODE requests and responses).
* Cache Hit Rate: With local caching of recently resolved EIDs, the
cache hit rate is > 80% for repeated lookups, reducing effective
latency to < 100 ms.
The following table summarizes expected DHT lookup performance under
different deployment scenarios :
Gebauer Expires 29 January 2027 [Page 124]
Internet-Draft IACP July 2026
| Scenario | Nodes | Avg. Hops | Avg. Latency | Success Rate |
|------------------|-------|-----------|--------------|--------------|
| Small deployment | 10^3 | 3-4 | 200-500 ms | 99,9% |
| Medium deployment| 10^5 | 4-5 | 400-1000 ms | 99,9% |
| Large deployment | 10^7 | 5-6 | 800-2000 ms | 99,8% |
| Global deployment| 10^9 | 6-7 | 1500-3000 ms | 99,5% |
(estimated)
9.10.3. PSS Session Throughput
PSS_DATA_STREAM frames are transmitted over QUIC streams:
* Throughput per Session: Up to 100 Mbps per PSS session, limited by
network bandwidth and QUIC congestion control.
* Frame Rate: Up to 10,000 frames per second per session for small
payloads (< 1 KB).
* Total Throughput per Host: A single LL-Entity can handle aggregate
throughput of up to 1 Gbps, limited by CPU for AES-GCM-256
encryption/decryption.
* Latency: End-to-end latency for PSS_DATA_STREAM frames is
typically < 100 ms, dominated by network RTT.
9.10.4. DHI Ingestion Pipeline Performance
The DHI ingestion pipeline processes ANML documents with the
following performance characteristics:
* ANML Parsing: 1-10 ms for a typical ANML document (< 100 KB),
depending on complexity and serialization (XML vs. JSON).
* DNS SRV Evaluation: 50-200 ms, depending on DNS resolver
performance and caching.
* Well-Known URI Evaluation: 100-500 ms, including HTTP round-trip
and TLS handshake.
* Link Header Sniffing: < 5 ms for headers up to 10 KB.
* Total Ingestion Time: Typically 200-800 ms for a complete pipeline
run, dominated by network round-trips.
9.10.5. HRP/APE Computational Cost
Heuristic Relevancy Probability (HRP) and Automated Pipeline
Extraction (APE) have the following computational costs:
Gebauer Expires 29 January 2027 [Page 125]
Internet-Draft IACP July 2026
HRP Computation (per node/URI):
* Local Approximation: 0.1-1 ms per node using Jaro-Winkler distance
and BM25 weighting against local keyword vectors.
* Full Embedding (Core Offloading): 10-50 ms per node, including
network round-trip to the core datacenter.
* HRP Cache: Cached HRP values are valid for T_hrp_cache = 60
seconds, reducing computation for repeated queries.
APE Execution (per traversal):
* Threshold Filtering: O(n) where n is the number of candidate
nodes. For n = 1000 nodes, < 1 ms.
* Parallel Socket Allocation: Up to 100 concurrent connections per
APE instance, limited by system file descriptor limits.
* DAG Path Optimization: O(e log v) for the directed acyclic graph
search, where e is the number of edges and v is the number of
nodes. For typical graphs (v < 1000, e < 5000), < 10 ms.
* Total APE Cost: Typically 10-50 ms for a complete traversal over
100-1000 candidate nodes.
9.10.6. Memory Consumption
The following memory consumption estimates apply:
* EID Context: Approximately 1-2 KB per active EID (including key
material, routing state, and reputation data).
* PSS Session: Approximately 2-4 KB per active session (including
state vector, crypto context, and buffers).
* DHT Routing Table: Approximately 10-20 KB per node, depending on
the number of k-buckets and peers.
* ANML Document Buffer: MAX_FLOAT_BUF default of 4 MB, configurable
per deployment.
* HRP Cache: Approximately 1 KB per cached HRP entry.
9.10.7. Scaling Recommendations
For large-scale deployments, the following recommendations apply:
Gebauer Expires 29 January 2027 [Page 126]
Internet-Draft IACP July 2026
1. DHT Partitioning: For deployments exceeding 10^7 nodes, consider
partitioning the DHT by namespace or geographic region to reduce
lookup latency.
2. Load Balancing: Distribute LL-Entity instances across multiple
hosts to increase concurrent session capacity and aggregate
throughput.
3. HRP/APE Offloading: Offload full embedding computations to core
datacenters to reduce edge node CPU load.
4. Caching: Increase cache TTLs for stable mappings (Forwarding
Tickets, EID-to-locator mappings) to reduce DHT lookup frequency.
5. Rate Limiting: Implement token-bucket rate limiting to prevent
resource exhaustion under high load.
9.10.8. Performance Monitoring
Conforming implementations SHOULD expose the following metrics for
operational monitoring:
* DHT lookup latency (p50, p95, p99)
* DHT lookup success rate
* PSS session count and throughput
* DHI ingestion pipeline latency (p50, p95, p99)
* HRP/APE computation time per traversal
* Memory usage per component (LL-Entity, DHI, DHT)
These metrics enable operators to detect performance degradation and
scale the deployment appropriately.
9.10.9. HRP/APE Computational Cost and Scalability
Heuristic Relevancy Probability (HRP) and Automated Pipeline
Extraction (APE) are computational subsystems that perform resource
discovery and traversal. This section quantifies the computational
costs and scalability characteristics of these subsystems.
Gebauer Expires 29 January 2027 [Page 127]
Internet-Draft IACP July 2026
9.10.9.1. HRP Computation Cost
HRP computation is performed per candidate node or URI during the
resource discovery phase. The cost depends on the availability of
semantic embeddings and the mode of operation:
Local Approximation (Edge Node):
* Computational Cost: 0.1-1 ms per node using Jaro-Winkler distance
and BM25 token weighting against locally cached keyword vectors.
* Memory Access: O(n_keywords) where n_keywords is the number of
cached keyword vectors (typically 10^3-10^4).
* CPU Usage: Negligible for typical workloads (< 1% of CPU per 1000
nodes processed).
Full Embedding (Core Offloading):
* Computational Cost: 10-50 ms per node, including network round-
trip to the core datacenter and vector computation.
* Network Cost: Additional 10-30 ms for the HRP_VECTOR_RESP (Type
0x1B) round-trip.
* Latency Distribution: 70% network (DHI to core), 30% computation
(embedding generation).
HRP Cache Hit:
* Cost: < 0.01 ms per node (cache lookup only).
* Cache Hit Rate: > 80% for repeated queries within T_hrp_cache = 60
seconds.
The following table summarizes HRP computation costs:
+---------------------------+----------+-------------------+
| Mode | Latency | CPU Cost |
| | per Node | (per 1000 nodes) |
+---------------------------+----------+-------------------+
| Local Approximation | 0.1-1 ms | < 1% of CPU core |
+---------------------------+----------+-------------------+
| Full Embedding (async) | 10-50 ms | 1-5% of CPU core |
+---------------------------+----------+-------------------+
| Cache Hit | < 0.01 ms| < 0.1% of CPU core|
+---------------------------+----------+-------------------+
Gebauer Expires 29 January 2027 [Page 128]
Internet-Draft IACP July 2026
9.10.9.2. APE Traversal Cost
APE executes the traversal and extraction of resources that satisfy
the HRP threshold Theta. The cost is dominated by network I/O and
parallel socket management:
Threshold Filtering:
* Cost: O(n) where n is the number of candidate nodes. For n = 1000
nodes, filtering requires < 1 ms of CPU time.
Parallel Socket Allocation:
* Max Concurrent Connections: Up to 100 connections per APE instance
(limited by system file descriptor limits).
* Connection Overhead: Approximately 50-100 ms per TCP/TLS
connection establishment (or 0-20 ms for QUIC with 0-RTT).
* Throughput: Each connection can sustain up to 10 Mbps under
typical network conditions.
DAG Path Optimization:
* Cost: O(e log v) for the directed acyclic graph search, where e is
the number of edges and v is the number of nodes.
* Typical Values: For v < 1000 and e < 5000, path optimization
requires < 10 ms.
* Worst Case: For v = 10^4 and e = 10^5, path optimization requires
< 100 ms.
Total APE traversal cost for a typical request with 100 candidate
nodes:
* Threshold Filtering: < 1 ms
* DAG Path Optimization: < 10 ms
* Socket Allocation: 50-100 ms (parallel)
* Data Transfer: Depends on payload size (typically 10-100 ms for <
1 MB)
Gebauer Expires 29 January 2027 [Page 129]
Internet-Draft IACP July 2026
9.10.9.3. Scaling Factors
HRP/APE scalability is determined by the following factors:
Candidate Node Count (n): - HRP computation scales linearly with n
for local approximation. - Full embedding offloading scales linearly
but can be parallelized across core nodes.
Concurrent Requests: - Each APE instance can handle up to 100
concurrent traversals, limited by the number of parallel connections
per instance. - Multiple APE instances can be deployed to scale
horizontally.
Network Bandwidth: - The primary bottleneck for APE extraction is
network I/O, not CPU. - Typical bandwidth consumption per traversal:
1-10 MB for 100 nodes (mostly metadata).
Core Datacenter Capacity: - Full embedding offloading requires
sufficient core capacity. - RECOMMENDED: 1 core per 1000 embedding
requests per second.
Edge Node Capacity: - Local approximation requires minimal CPU (< 5%
for 10^4 nodes per second). - Memory for keyword cache: approximately
1 MB per 1000 keyword vectors.
The following table summarizes scaling factors:
+-------------------+------------------+------------------------------+
| Parameter | Typical Value | Scaling Behavior |
+-------------------+------------------+------------------------------+
| Candidate Nodes | 100-1000 | O(n) local, O(n) async |
+-------------------+------------------+------------------------------+
| Concurrent APE | 100-1000 | Linear with CPU cores |
| Instances | | |
+-------------------+------------------+------------------------------+
| Embedding Vector | 384-1536 dims | O(d) per embedding; d fixed |
| Dimension | | per model |
+-------------------+------------------+------------------------------+
| HRP Cache Size | 1000-10000 entries| O(entries) memory; < 10 MB |
+-------------------+------------------+------------------------------+
| APE Connection | 100 connections | O(connections) file |
| Limit | per instance | descriptors; < 100 MB memory |
+-------------------+------------------+------------------------------+
9.10.9.4. Memory Consumption
HRP/APE memory consumption is bounded by configurable limits:
Gebauer Expires 29 January 2027 [Page 130]
Internet-Draft IACP July 2026
HRP Cache: - Entry Size: Approximately 1 KB per cached HRP entry
(includes node ID, probability, timestamp). - Cache Limit:
RECOMMENDED T_hrp_cache = 60 seconds TTL and C_hrp_cache = 10000
entries. - Maximum Memory: < 10 MB for 10000 entries.
APE Queue: - Asynchronous download queue: Buffers up to 100
concurrent requests. - Per-request buffer: MAX_FLOAT_BUF = 4 MB. -
Maximum Queue Memory: 100 * 4 MB = 400 MB (configurable).
Keyword Cache (Edge Node): - Keywords per vector: Typically 100-500
tokens. - Cache Size: 10000 vectors * 500 tokens * 4 bytes (UTF-8
average) = 20 MB (compressed).
Total HRP/APE memory footprint for a typical deployment: 50-100 MB
(edge node), 200-500 MB (core node with full embedding support).
9.10.9.5. Performance Degradation Under Load
Under high load, HRP/APE performance degrades gracefully:
* HRP Cache Miss Rate: Increases as cache entries expire; load
impacts query latency.
* APE Queue Depth: As queue depth exceeds 100 requests, new
traversals are delayed or rejected with a backoff.
* Core Embedding Offloading: Under high load (> 1000 requests/sec),
core nodes become saturated; deployments SHOULD scale core
capacity horizontally.
* Network Congestion: APE extraction throughput is network-bound;
deployments SHOULD use dedicated bandwidth or prioritize IACP
traffic.
9.10.9.6. Scalability Recommendations
For large-scale deployments, the following recommendations apply:
1. Deploy multiple APE instances behind a load balancer to handle
concurrent traversals.
2. Increase HRP cache size and TTL for stable, frequently queried
resources.
3. Offload full embedding computation to a dedicated core datacenter
with sufficient capacity for expected request volume.
Gebauer Expires 29 January 2027 [Page 131]
Internet-Draft IACP July 2026
4. Monitor APE queue depth and scale horizontally when depth exceeds
80% of capacity.
5. Use edge node local approximation as a fallback when core
offloading is unavailable or overloaded.
9.11. Crypto-Agility and Algorithm Negotiation
The IACP protocol currently specifies Ed25519 for signatures, AES-
GCM-256 for symmetric encryption, and X25519 for key exchange. This
section defines a framework for algorithm negotiation and migration
to ensure the protocol remains secure against future cryptanalytic
advances, including the advent of quantum computers.
9.11.1. Algorithm Suites
An Algorithm Suite is a set of cryptographic algorithms used for a
specific purpose within IACP. Each suite is identified by a unique
16-bit Suite ID. The following suites are defined:
|Suite ID| Name | Signature|KEM/ECDH |Symmetric |Hash |
|--------|-----------------|----------|----------|------------|-------|
|0x0001 |IACP-CLASSIC-2026|Ed25519 |X25519 |AES-GCM-256 |SHA-256|
|0x0002 |IACP-PQC-REF-2027|Falcon-512|ML-KEM-768|AES-GCM-256 |SHA-384|
Future suites may define additional combinations. The Suite ID
0x0000 is reserved and MUST NOT be used. Suite IDs in the range
0x0001-0x7FFF are assigned by Standards Action. Suite IDs in the
range 0x8000-0xFFFF are reserved for private or experimental use.
9.11.2. Algorithm Negotiation
Algorithm negotiation occurs during the PSS handshake via a new
transport parameter:
Algorithm-Suites: A list of Suite IDs supported by the endpoint,
ordered by preference (most preferred first).
The negotiation flow is as follows:
1. The initiator includes the Algorithm-Suites parameter in the QUIC
transport parameters during the PSS_INIT phase.
2. The responder selects the first Suite ID from the initiator's
list that it also supports. If no common suite exists, the
responder MUST reject the session with error code
NO_COMMON_ALGORITHM (0x2A).
Gebauer Expires 29 January 2027 [Page 132]
Internet-Draft IACP July 2026
3. The responder includes the selected Suite ID in its Algorithm-
Suites parameter (single value) in the PSS_NEG frame.
4. The initiator verifies that the selected Suite ID is one it
offered. If not, the session MUST be terminated.
5. All subsequent cryptographic operations within the PSS session
use the algorithms defined by the selected suite.
The selected Suite ID is also included in the Session Connection
Cookie (I-Cookie || R-Cookie || Suite_ID) for context binding.
9.11.3. Suite-Specific Wire Formats
Different algorithm suites may require different wire formats:
* Ed25519 signatures are 64 bytes.
* Falcon-512 signatures are 64 bytes (compressed) or variable.
* ML-KEM-768 ciphertexts are 1088 bytes.
To accommodate variable-length fields, the following rules apply:
1. All signature fields in IACP messages (e.g., in PSS_INIT,
PSS_ACK, MIGRATION_VECTOR, PoM_Ticket) are prefixed with a 2-byte
length field when the negotiated suite uses a variable-length
signature scheme. For fixed-length suites (Ed25519),
implementations MAY omit the length field (length is implicitly
64 bytes).
2. All KEM ciphertext fields are prefixed with a 2-byte length
field.
3. Implementations MUST reject messages where the actual length does
not match the advertised length.
9.11.4. EID Representation and Algorithm Binding
When a suite other than IACP-CLASSIC-2026 is used, the EID
representation MUST include the Suite ID:
EID = Suite_ID || Public_Key
Where Public_Key is the raw public key bytes for the signature scheme
defined by the suite. For Ed25519 (Suite 0x0001), this is 32 bytes.
For Falcon-512 (Suite 0x0002), this is 64 bytes.
Gebauer Expires 29 January 2027 [Page 133]
Internet-Draft IACP July 2026
The Suite ID in the EID MUST match the Suite ID used in the signature
verification context. If a message claims to use a different suite
than the one in the EID, it MUST be rejected.
When a suite is deprecated, EIDs using that suite SHOULD be rotated
to a new suite. The old EID remains valid for the grace period.
9.11.5. Post-Quantum Readiness
To prepare for a post-quantum future, IACP implementations:
* SHOULD implement at least one post-quantum signature scheme (e.g.,
Falcon-512, Dilithium-2, or SPHINCS+-128f) and one post-quantum
KEM (e.g., ML-KEM-768) as defined by IETF PQC standards when they
are finalized.
* SHOULD support the Algorithm Negotiation mechanism to enable
interoperability with peers that have deployed PQC algorithms.
* MUST be capable of processing signatures generated by multiple
algorithm suites simultaneously during the transition period.
* SHOULD monitor IETF PQC standardization progress and update their
supported suites accordingly.
9.11.6. Migration and Deprecation
When an algorithm is considered cryptographically weak, the following
migration process applies:
1. Announcement: The IETF or designated authority announces the
deprecation of the algorithm and the recommended replacement
suite. A grace period T_grace is defined (minimum 6 months).
2. Deprecation Phase: The deprecated suite is no longer RECOMMENDED
for new sessions. Existing sessions using the deprecated suite
MAY continue for the duration of the grace period. New PSS
sessions SHOULD use the replacement suite.
3. Withdrawal Phase: After T_grace expires, the deprecated suite
MUST NOT be used for new sessions. Existing sessions MUST be
migrated or terminated within T_migration (default: 30 days).
Nodes that cannot migrate are no longer interoperable.
4. Emergency Withdrawal: If a critical vulnerability is found, the
grace period MAY be shortened. Implementations SHOULD support
emergency fallback to a pre-configured backup suite.
Gebauer Expires 29 January 2027 [Page 134]
Internet-Draft IACP July 2026
Migration of EIDs:
1. Nodes with EIDs using a deprecated suite SHOULD rotate to a new
EID using the replacement suite.
2. During the grace period, the old EID remains valid for verifying
historical signatures.
3. After the grace period, the old EID SHOULD be revoked.
9.11.7. Structured Threat Analysis (STRIDE)
This section presents a structured threat analysis of the IACP
architecture using the STRIDE threat classification framework
[Spoofing, Tampering, Repudiation, Information Disclosure, Denial of
Service, Elevation of Privilege]. Each threat category is analyzed
with respect to the IACP components (EID, ERP, DHT, PSS, DHI, LL-
Entity) and the corresponding mitigations are identified.
9.11.7.1. Spoofing
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| EID impersonation| EID, PSS | Ed25519 signatures on PSS_INIT, |
| | | PSS_ACK, MIGRATION_VECTOR |
+------------------+------------+-------------------------------------+
| DHT node spoofing| DHT | Kademlia XOR-based routing; |
| | | Node ID = SHA-256(EID) |
+------------------+------------+-------------------------------------+
| LL-Entity | LL-Entity | IAT-based local authentication |
| impersonation | | |
+------------------+------------+-------------------------------------+
| Control frame | ERP | Dual-Cookie handshake |
| spoofing | | |
+------------------+------------+-------------------------------------+
| Trust domain | Federation | Ed25519-signed Trust Anchor |
| spoofing | | Documents |
+------------------+------------+-------------------------------------+
Residual Risks: Private key compromise (EID); Eclipse attacks; IAT
leakage on host; Cookie prediction (low entropy); Curator key
compromise.
9.11.7.2. Tampering
Gebauer Expires 29 January 2027 [Page 135]
Internet-Draft IACP July 2026
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| PSS_DATA_STREAM | PSS | AES-GCM-256 AEAD |
| tampering | | |
+------------------+------------+-------------------------------------+
| DHT mapping | DHT | Ed25519 signatures on mapping |
| tampering | | updates |
+------------------+------------+-------------------------------------+
| Forwarding Ticket| DHT | Ed25519 signatures; encrypted |
| tampering | | payload |
+------------------+------------+-------------------------------------+
| ANML content | DHI | EVM verification |
| tampering | | |
+------------------+------------+-------------------------------------+
| Revocation | EID Revoc. | Ed25519-signed Revocation |
| tampering | | Certificate |
+------------------+------------+-------------------------------------+
Residual Risks: AEAD implementation bugs; PoM detection; Key
compromise; EVM threshold bypass.
9.11.7.3. Repudiation
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| Action | ERP, PSS | Ed25519 signatures on all control |
| repudiation | | frames |
+------------------+------------+-------------------------------------+
| PoM ticket denial| PoM | PoM ticket with two signed messages |
| | | |
+------------------+------------+-------------------------------------+
| Session state | PSS | Sequence vectors with cryptographic |
| repudiation | | reconciliation |
+------------------+------------+-------------------------------------+
| Authorization | Opaque | EMILIA receipts with JCS |
| repudiation | Envelope | canonicalization |
+------------------+------------+-------------------------------------+
Residual Risks: EMILIA verifier bugs.
9.11.7.4. Information Disclosure
Gebauer Expires 29 January 2027 [Page 136]
Internet-Draft IACP July 2026
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| EID-locator | DHT | Forwarding Tickets encrypted |
| mapping leak | | |
+------------------+------------+-------------------------------------+
| PSS payload | PSS | AES-GCM-256 encryption |
| disclosure | | |
+------------------+------------+-------------------------------------+
| ESE state | ESE | SFC-based access control |
| exposure | | |
+------------------+------------+-------------------------------------+
| Trust Anchor | Federation | Domain-level control; optional |
| exposure | | encryption |
+------------------+------------+-------------------------------------+
| Discovery query | DS | Anonymous discovery with ephemeral |
| metadata | | keys |
+------------------+------------+-------------------------------------+
| TEE measurement | Attestation| Optional; Attestation Result pattern|
| disclosure | | |
+------------------+------------+-------------------------------------+
Residual Risks: Traffic analysis on DHT; Key compromise; SFC policy
misconfiguration; Organizational affiliation leak; Linkability of
queries; Platform detail leakage.
9.11.7.5. Denial of Service
Gebauer Expires 29 January 2027 [Page 137]
Internet-Draft IACP July 2026
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| PSS_INIT flooding| PSS | PoW validation before state |
| | | allocation |
+------------------+------------+-------------------------------------+
| DHT lookup | DHT | Token-bucket rate limiting; PoW |
| flooding | | |
+------------------+------------+-------------------------------------+
| ANML endpoint | DHI | PROBLEM_CACHE with TTL |
| polling | | |
+------------------+------------+-------------------------------------+
| Session state | PSS | T_eval timeout; MAX_FLOAT_BUF limits|
| exhaustion | | |
+------------------+------------+-------------------------------------+
| Discovery Space | DS | Token-bucket filters |
| flooding | | |
+------------------+------------+-------------------------------------+
| eBPF fast-path | L4 | Autonomous circuit breakers |
| overflow | | |
+------------------+------------+-------------------------------------+
Residual Risks: Computational DoS on initiator; High-volume
distributed attack; Resource-constrained devices.
9.11.7.6. Elevation of Privilege
+------------------+------------+-------------------------------------+
| Threat | Component | Mitigation |
+------------------+------------+-------------------------------------+
| Curator privilege| Namespace | PoM with 2PSE slashing; |
| abuse | | quarantine |
+------------------+------------+-------------------------------------+
| AAI context | LL-Entity | IAT-based isolation; ESD-EID in |
| escape | | sandbox |
+------------------+------------+-------------------------------------+
| SFC scope | PSS | SFC Conditions Block; PSS_ACK |
| violation | | ratification |
+------------------+------------+-------------------------------------+
| PoM ticket | PoM | Quorum validation |
| forgery | | |
+------------------+------------+-------------------------------------+
| Attestation | Attestation| Reject requests lacking evidence |
| header stripping | | |
+------------------+------------+-------------------------------------+
| Algorithm | Crypto- | Suite ID in PSS_ACK signature |
| downgrade | Agility | |
+------------------+------------+-------------------------------------+
Gebauer Expires 29 January 2027 [Page 138]
Internet-Draft IACP July 2026
Residual Risks: Colluding curators; Local host vulnerabilities; SFC
implementation bugs; Quorum corruption (>f nodes).
9.11.7.7. STRIDE Threat Severity Matrix
The following matrix summarizes the severity of each threat category
across IACP components, using a scale of Low (L), Medium (M), and
High (H). Severity is based on the potential impact of a successful
attack and the feasibility of exploitation.
Part 1: Spoofing, Tampering, Repudiation
+------------+----------+-----------+-------------+
| Component | Spoofing | Tampering | Repudiation |
+------------+----------+-----------+-------------+
| EID | H | M | L |
+------------+----------+-----------+-------------+
| ERP | H | H | M |
+------------+----------+-----------+-------------+
| DHT | M | H | L |
+------------+----------+-----------+-------------+
| PSS | H | H | M |
+------------+----------+-----------+-------------+
| DHI | L | M | L |
+------------+----------+-----------+-------------+
| LL-Entity | M | M | L |
+------------+----------+-----------+-------------+
| Federation | M | M | L |
+------------+----------+-----------+-------------+
| Attestation| M | M | L |
+------------+----------+-----------+-------------+
Part 2: Information Disclosure, Denial of Service, Elevation
Gebauer Expires 29 January 2027 [Page 139]
Internet-Draft IACP July 2026
+------------+------------------+-----+-----------+
| Component | Info Disclosure | DoS | Elevation |
+------------+------------------+-----+-----------+
| EID | M | L | M |
+------------+------------------+-----+-----------+
| ERP | L | H | M |
+------------+------------------+-----+-----------+
| DHT | M | H | H |
+------------+------------------+-----+-----------+
| PSS | H | M | M |
+------------+------------------+-----+-----------+
| DHI | M | M | L |
+------------+------------------+-----+-----------+
| LL-Entity | M | L | H |
+------------+------------------+-----+-----------+
| Federation | M | L | M |
+------------+------------------+-----+-----------+
| Attestation| M | L | M |
+------------+------------------+-----+-----------+
9.11.7.8. Mitigation Coverage Summary
+-----------------+---------------------------------------------+
| STRIDE Category | Primary Mitigations |
+-----------------+---------------------------------------------+
| Spoofing | Ed25519 signatures; IAT; Dual-Cookie |
| | handshake; Trust Anchor Documents |
+-----------------+---------------------------------------------+
| Tampering | AEAD; Ed25519 signatures; EVM verification |
+-----------------+---------------------------------------------+
| Repudiation | Ed25519 signatures; PoM tickets; Sequence |
| | vectors; EMILIA receipts |
+-----------------+---------------------------------------------+
| Info Disclosure | AES-GCM-256; SFC; Anonymous discovery; |
| | Attestation Result pattern |
+-----------------+---------------------------------------------+
| DoS | PoW; Token-bucket; PROBLEM_CACHE; Circuit |
| | breakers; T_eval limits |
+-----------------+---------------------------------------------+
| Elevation | 2PSE; IAT; ESD-EID; SFC; Quorum validation |
+-----------------+---------------------------------------------+
Improvement Areas:
* Post-quantum signature migration
* Formal verification of EVM implementation
Gebauer Expires 29 January 2027 [Page 140]
Internet-Draft IACP July 2026
* Traffic flow obfuscation (future work)
* Distributed DoS resilience (operational)
* Formal verification of SFC policy enforcement
9.11.7.9. Normative Notes for Threat Analysis
The following references inform the threat analysis methodology and
terminology used in this section:
* [I-D.ietf-rats-architecture] for attestation-specific threats.
* [RFC3552] for general Internet protocol threat modeling
guidelines.
* [I-D.ietf-dnsop-dnssec-threats] for threat modeling principles
applied to distributed systems.
9.11.8. Attack Trees and Formal Security Arguments
This section complements the STRIDE analysis with attack trees for
critical IACP components and formal security arguments for key
protocol properties. The attack trees identify potential attack
paths and their preconditions. The formal arguments provide a basis
for security proofs of the protocol's core cryptographic mechanisms.
9.11.8.1. Attack Tree: EID Impersonation
The following attack tree models the ways an adversary could
impersonate a legitimate EID. Each leaf represents a specific attack
vector, and the OR nodes indicate alternative paths.
Gebauer Expires 29 January 2027 [Page 141]
Internet-Draft IACP July 2026
+-----------------------------------------------------+
| EID Impersonation |
+-----------------------------------------------------+
|
+---------------^---------------+
| | |
+-----v-----+ +-----v-----+ +-----v-----+
| Compromise| | Replay | | Forge |
| Private | | Attack | | Signature |
| Key | | | | |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Key | | Capture | | Break |
| Exfil- | | Valid | | Ed25519 |
| tration | | PSS_INIT | | |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Malware | | Network | | Quantum |
| or | | Sniffing | | Computer |
| Physical | | | | (future) |
| Access | +-----------+ +-----------+
+-----------+ |
v
+---------------+
| Replay within |
| T_fresh window|
+---------------+
Mitigations:
* Private key compromise: Hardware security modules (HSM) or TEEs
for key storage; key rotation.
* Replay attack: Dual-Cookie handshake with per-session cookies;
timestamp validation (T_fresh = 5 minutes).
* Signature forgery: Ed25519 with 128-bit security; post-quantum
migration.
Attack Probability (Qualitative):
* Key exfiltration: Medium (requires host compromise).
* Network sniffing: High (but replay prevented by cookies).
Gebauer Expires 29 January 2027 [Page 142]
Internet-Draft IACP July 2026
* Quantum break: Low (future threat; migration planned).
9.11.8.2. Attack Tree: DHT Routing Table Takeover
The following attack tree models how an adversary could poison or
take over a node's DHT routing table to enable Eclipse attacks.
+-----------------------------------------------------+
| DHT Routing Table Takeover |
+-----------------------------------------------------+
|
+---------------^---------------+
| | |
+-----v-----+ +-----v-----+ +-----v-----+
| Sybil | | Bucket | | Routing |
| Attack | | Poisoning | | Table |
| | | | | Flood |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Generate | | Send | | Send |
| Many EIDs | | Fake | | Many |
| with PoW | | FIND_NODE | | FIND_NODE |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Costly | | Exploit | | Resource |
| PoW | | Bucket | | Exhaustion|
| | | Refresh | | on Target |
| | | Timing | | Node |
+-----------+ +-----------+ +-----------+
Mitigations:
* Sybil attack: Proof-of-Work for EID registration; Node ID = SHA-
256(EID) with computational cost.
* Bucket poisoning: Randomized bucket selection; bucket refresh with
pings (T_refresh = 5 minutes).
* Routing table flood: Token-bucket rate limiting; maximum routing
table size (5120 entries).
Attack Probability:
* Sybil: Low (PoW cost is high).
Gebauer Expires 29 January 2027 [Page 143]
Internet-Draft IACP July 2026
* Bucket poisoning: Medium (requires control of many nodes).
* Routing flood: Medium (rate limiting mitigates).
9.11.8.3. Attack Tree: PSS Session Hijacking
The following attack tree models how an adversary could hijack an
active PSS session.
+-----------------------------------------------------+
| PSS Session Hijacking |
+-----------------------------------------------------+
|
+---------------^---------------+
| | |
+-----v-----+ +-----v-----+ +-----v-----+
| Cookie | | Sequence | | Session |
| Theft | | Number | | Key |
| | | Prediction| | Compromise|
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Sniff | | Replay | | Break |
| I-Cookie | | Out-of- | | AES-GCM- |
| R-Cookie | | Order | | 256 |
+-----------+ +-----------+ +-----------+
| | |
v v v
+-----------+ +-----------+ +-----------+
| Network | | Exploit | | Quantum |
| Sniffing | | Weak | | Attack |
| (encrypted| | Sequence | | (future) |
| prevents) | | Generator | | |
+-----------+ +-----------+ +-----------+
Mitigations:
* Cookie theft: Cookies are sent in encrypted PSS frames; no
plaintext exposure.
* Sequence number prediction: Monotonically increasing with
cryptographic nonce; sequence vector reconciliation detects
anomalies.
* Key compromise: AES-GCM-256 with 128-bit security; key rotation
via EID rotation.
Gebauer Expires 29 January 2027 [Page 144]
Internet-Draft IACP July 2026
Attack Probability:
* Cookie theft: Very Low (encrypted).
* Sequence prediction: Very Low (CSPRNG-based).
* Key compromise: Low (requires quantum or side-channel).
9.11.8.4. Formal Security Arguments
This section provides informal security arguments for the core
cryptographic properties of IACP. These arguments are intended to
support formal verification efforts and to establish the protocol's
security foundations.
9.11.8.4.1. Authentication Property
Claim: The IACP protocol provides mutual authentication between
communicating peers.
Argument:
1. Each peer possesses a unique Ed25519 key pair (EID). The private
key is held exclusively by the LL-Entity.
2. The PSS_INIT frame is signed with the initiator's private key.
The signature covers the I-Cookie and the initiator's EID.
3. The PSS_ACK frame is signed with the responder's private key.
The signature covers the I-Cookie, R-Cookie, and the responder's
EID.
4. Both peers verify the received signatures against the
corresponding EID public keys. A valid signature proves that the
signing peer possesses the private key corresponding to the
claimed EID (Ed25519 security assumption).
5. The Dual-Cookie handshake ensures that both peers are
participating in the same session instance. The I-Cookie is
generated by the initiator, and the R-Cookie by the responder.
The PSS_ACK proves that the responder received the I-Cookie and
generated the R-Cookie.
Conclusion: Under the assumption that Ed25519 signatures are
unforgeable and that cookies are generated with sufficient entropy,
the protocol provides mutual authentication.
Gebauer Expires 29 January 2027 [Page 145]
Internet-Draft IACP July 2026
9.11.8.4.2. Confidentiality Property
Claim: The IACP protocol provides confidentiality for PSS payloads
and Forwarding Tickets.
Argument:
1. PSS_DATA_STREAM frames are encrypted using AES-GCM-256 with a
symmetric session key. The session key is derived during the
handshake using a cryptographically secure key exchange (X25519
or negotiated suite).
2. The AES-GCM-256 encryption provides IND-CCA2 security under the
assumption that AES is a secure block cipher and that GCM is
correctly implemented (standard security proof for AEAD).
3. Forwarding Tickets are encrypted using AES-GCM-256 with a key
derived from ECDH (X25519) between the agent and the backup host.
The key is ephemeral and session-bound.
4. Nonces are generated using a CSPRNG and are strictly incremented
per packet. This prevents nonce reuse, which would break the GCM
security proof.
Conclusion: Under the standard cryptographic assumptions for AES-
GCM-256 and X25519, the protocol provides confidentiality.
9.11.8.4.3. Integrity and Non-Repudiation Property
Claim: The IACP protocol provides integrity and non-repudiation for
control frames and PoM tickets.
Argument:
1. All critical control frames (PSS_INIT, PSS_ACK, MIGRATION_VECTOR,
ERP_REGISTER) are signed using Ed25519. The signature covers the
entire frame payload.
2. A valid Ed25519 signature provides both integrity (any tampering
would invalidate the signature) and non-repudiation (the signer
cannot deny having signed the message).
3. PoM tickets contain two conflicting signed messages. The
signatures prove that the accused node signed both messages. The
quorum validates the signatures and the semantic conflict (same
EID, same generation counter, conflicting locator).
Gebauer Expires 29 January 2027 [Page 146]
Internet-Draft IACP July 2026
4. The canonicalization procedure ensures that two messages are
compared byte-for-byte, preventing semantic ambiguity.
Conclusion: Under the assumption that Ed25519 signatures are
unforgeable and that canonicalization is deterministic, the protocol
provides integrity and non-repudiation.
9.11.8.4.4. Denial-of-Service Resistance Property
Claim: The IACP protocol provides resistance against resource
exhaustion DoS attacks.
Argument:
1. The protocol enforces a zero-allocation parsing invariant for
unauthenticated connection states. Memory is not allocated for a
PSS_INIT until the PoW token is validated.
2. The PoW validation requires computational effort from the
initiator, shifting the cost of DoS attempts to the attacker.
3. Token-bucket rate limiting limits the number of requests from a
single source. Autonomous circuit breakers trip under anomalous
load.
4. PROBLEM_CACHE state with TTL prevents repeated polling of
unreachable endpoints.
Conclusion: The protocol's architectural design (zero-allocation
parsing, PoW, rate limiting) provides defense-in-depth against
resource exhaustion attacks. However, complete resistance requires
operational deployment of rate limiting and capacity planning.
9.11.8.5. Formal Verification Status
The following formal verification efforts are recommended for
production deployments:
* Model Checking: The state machines SHOULD be verified using model
checkers (e.g., TLA+, Promela) to ensure absence of deadlocks and
invalid transitions.
* Cryptographic Proofs: The authentication and confidentiality
arguments SHOULD be formalized in a cryptographic proof framework
(e.g., ProVerif, Tamarin).
Gebauer Expires 29 January 2027 [Page 147]
Internet-Draft IACP July 2026
* Implementation Verification: The core cryptographic operations
(Ed25519, AES-GCM-256) SHOULD be verified using constant-time
execution and side-channel resistance testing.
9.11.8.6. Normative Notes for Attack Trees
The attack tree methodology is informed by the following references:
* [I-D.ietf-dnsop-dnssec-threats] for threat modeling approaches.
* [Schneier] for general attack tree principles.
* [RFC3552] for security considerations in protocol design.
10. References
10.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,
.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T.
Henderson, "Host Identity Protocol Version 2 (HIPv2)",
RFC 7401, DOI 10.17487/RFC7401, April 2015,
.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
.
[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, .
Gebauer Expires 29 January 2027 [Page 148]
Internet-Draft IACP 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,
.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
.
10.2. Informative References
[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, .
[EMILIA] Schrock, I., "EMILIA Protocol Specification", Work in
Progress , 2026.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, .
[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,
.
Gebauer Expires 29 January 2027 [Page 149]
Internet-Draft IACP July 2026
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
.
[Kademlia] Maymounkov, P. and D. Mazieres, "Kademlia: A Peer-to-Peer
Information System Based on the XOR Metric", IPTPS 2002,
2002.
[Hashcash] Back, A., "Hashcash - A Denial of Service Counter-
Measure", Whitepaper 2002, 2002.
[Wooldridge]
Wooldridge, M., "An Introduction to Multi-Agent Systems",
Publisher John Wiley & Sons, 2009.
[Nygard] Nygard, M. T., "Release It!: Design and Deploy Production-
Ready Software", Publisher Pragmatic Bookshelf, 2018.
[NIST207] Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
"Zero Trust Architecture", NIST Special Publication
800-207, 2020.
[I-D.schwenkschuster-wimse-trust-domain-discovery]
Schwenkschuster, A. and Y. Rosomakho, "WIMSE Trust Domain
Discovery", Work in Progress, Internet-Draft, draft-
schwenkschuster-wimse-trust-domain-discovery-00, 3 July
2026, .
[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, .
[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
Gebauer Expires 29 January 2027 [Page 150]
Internet-Draft IACP July 2026
Progress, Internet-Draft, draft-fossati-seat-early-
attestation-04, 27 May 2026,
.
[I-D.fossati-seat-expat]
Sardar, M. U., Fossati, T., , Sheffer, Y., Tschofenig, H.,
and I. Mihalcea, "Remote Attestation with Exported
Authenticators", Work in Progress, Internet-Draft, draft-
fossati-seat-expat-02, 26 February 2026,
.
[I-D.ietf-wimse-arch]
Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload
Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
.
[I-D.ietf-wimse-identifier]
Rosomakho, Y. and J. Salowey, "Workload Identifier", Work
in Progress, Internet-Draft, draft-ietf-wimse-identifier-
03, 6 July 2026, .
[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, .
[I-D.ietf-wimse-http-signature]
Salowey, J. and Y. Sheffer, "WIMSE Workload-to-Workload
Authentication with HTTP Signatures", Work in Progress,
Internet-Draft, draft-ietf-wimse-http-signature-04, 6 July
2026, .
[I-D.ietf-wimse-mutual-tls]
Salowey, J. and Y. Rosomakho, "Workload Authentication
Using Mutual TLS", Work in Progress, Internet-Draft,
draft-ietf-wimse-mutual-tls-02, 6 July 2026,
.
Gebauer Expires 29 January 2027 [Page 151]
Internet-Draft IACP July 2026
[I-D.hood-agtp-api]
Hood, C., "AGTP-API: Verbs, Paths, Endpoints, and
Synthesis", Work in Progress, Internet-Draft, draft-hood-
agtp-api-01, 2026,
.
[I-D.hood-agtp-trust]
Hood, C., "AGTP Trust and Verification Specification",
Work in Progress, Internet-Draft, draft-hood-agtp-trust-
02, 2026,
.
[I-D.schrock-ep-authorization-receipts]
Schrock, I., "EMILIA Protocol Specification", Work in
Progress, Internet-Draft, draft-schrock-ep-authorization-
receipts, 2026, .
Appendix A. Wire Formats of the IACP
1.) DISCOVERY_REQ (Type 0x01)
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 (0x01) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) |
| (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Ephemeral Public Key (X25519) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp / Replay Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Proof-of-Work Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoW Target Threshold [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.) DISCOVERY_RES (Type 0x02)
Gebauer Expires 29 January 2027 [Page 152]
Internet-Draft IACP 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 (0x02) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder Ephemeral Public Key (X25519) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Payload |
| (True EID [32B] + AEAD Auth Tag [16B]) [48 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.) ACCESS_TICKET_REQ (Type 0x03)
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 (0x03) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp / Replay Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.) ACCESS_TICKET_RES (Type 0x04)
Gebauer Expires 29 January 2027 [Page 153]
Internet-Draft IACP 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 (0x04) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Space Coordinate (DHT Key) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expiration Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Curator Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.) DHT_TICKET_STORE (Type 0x05)
Gebauer Expires 29 January 2027 [Page 154]
Internet-Draft IACP 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 (0x05) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Agent EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time-to-Live (TTL) [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Forwarding Data [36 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Owner Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.) DHT_TICKET_QUERY (Type 0x06)
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 (0x06) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID / Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.) DHT_TICKET_RESP (Type 0x07)
Gebauer Expires 29 January 2027 [Page 155]
Internet-Draft IACP 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 (0x07) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transaction ID / Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status / Error Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AEAD Nonce / IV [12 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted Forwarding Data [36 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Owner Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.) PSS_INIT (Type 0x08)
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 (0x08) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initiator EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial Sequence / Vector Clock [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Capabilities & Extension Flags [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoW Nonce [8 Bytes] | PoW Target [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initiator Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 156]
Internet-Draft IACP July 2026
9.) PSS_ACK (Type 0x09)
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 (0x09) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Initial Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agreed SFC Capabilities [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Responder Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10.) PSS_NEG (Type 0x0A)
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 (0x0A) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Negotiation Turn Counter | Rejection Reason Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Proposed SFC Conditions Block [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.) PSS_DATA_STREAM (Type 0x0B)
Gebauer Expires 29 January 2027 [Page 157]
Internet-Draft IACP 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 (0x0B) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AEAD Nonce / IV [12 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Encrypted ANML Payload (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12.) PSS_TEARDOWN (Type 0x0C)
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 (0x0C) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Teardown Type | Reason Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional: Proof of Malfeasance Data (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
13.) PSS_REVOCATION_PUBLISH (Type 0x0D)
Gebauer Expires 29 January 2027 [Page 158]
Internet-Draft IACP 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 (0x0D) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Offender EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reporter Digital Signature [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proof of Malfeasance Data (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
14.) ERP_DEFLECT (Type 0x0E)
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 (0x0E) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Original Target Locator (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Target Port (2B) | Deflection-Routing-TTL (1B) | Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Inner Agent Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
15.) Outer Transport Header (Type 0x0F)
Gebauer Expires 29 January 2027 [Page 159]
Internet-Draft IACP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Type (0x0F) | Flags | Transit-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP_Transit_Token [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LL-Entity Instance Identifier (LII) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LIK Transit Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Inner ERP / IACP / PSS Payload (variable) |
| |
+---------------------------------------------------------------+
16.) ERP_KEEPALIVE (Type 0x10)
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 (0x10) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Instance Authentication Token (IAT) |
| [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17.) ERP_INIT (Type 0x11)
Gebauer Expires 29 January 2027 [Page 160]
Internet-Draft IACP 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 (0x11) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Nonce [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
18.) ANML Fallback Query (Type 0x12)
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 (0x12) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Legacy Target URI (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requestor EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
19.) PSS_REVOCATION_REBUTTAL (Type 0x13)
Gebauer Expires 29 January 2027 [Page 161]
Internet-Draft IACP 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 (0x13) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Offender EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rebuttal Proof Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Rebuttal Evidence Data (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20.) ERP_INIT (Type 0x11)
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 (0x11) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Nonce [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
21.) ERP_ALLOC (Type 0x14)
Gebauer Expires 29 January 2027 [Page 162]
Internet-Draft IACP 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 (0x14) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Nonce [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Allocated EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Local_IAT [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
22.) ERP_REGISTER (Type 0x15)
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Digital Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
23.) ERP_EVOLVE (Type 0x16)
Gebauer Expires 29 January 2027 [Page 163]
Internet-Draft IACP 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 (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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24.) MIGRATION_VECTOR (Type 0x17)
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 (0x17) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type (0x0C) | TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family (2B) | New Destination Port (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| New Physical Transport Destination IP Address |
| (4 or 16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter New [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Migration Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
25.) PROOF_OF_MAL (Type 0x18)
Gebauer Expires 29 January 2027 [Page 164]
Internet-Draft IACP 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 | Offense Type Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Malicious Node Identity (EID) [32B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conflicting Signed Message Digest A [32B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conflicting Signed Message Digest B [32B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accusing Node Cryptographic Signature [64B] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
26.) WRT_PRESENTATION (Type 0x19)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type [8-bit] | Length [16-bit] |Version|Flags|
| (0x19) | | [4-b] | [4-b|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number [32-bit] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| EID [128-bit] |
| (16 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EVM Threshold [Float32/32-bit] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Cryptographic Proof [256-bit] |
| (32 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
27.) ESCROW_BATCH_SETTLE (Type 0x1A)
Gebauer Expires 29 January 2027 [Page 165]
Internet-Draft IACP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type [8-bit] | Length [16-bit] |Version| R R |
| (0x1A) | | [4-b] | [4-b|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Count | Reserviert [24-bit] |
| [8-bit] | (Must Be Zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Escrow Epoch ID [32-bit] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Total Settled Amount [64-bit] |
| (8 Bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Merkle Root of Batch [256-bit] |
| (32 Bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28.) HRP_VECTOR_RESP (Type 0x1B)
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] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
29.) FED_TRUST_ANCHOR_REQ (Type 0x1C)
Gebauer Expires 29 January 2027 [Page 166]
Internet-Draft IACP 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 (0x1C) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Domain ID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Timestamp / Nonce [8 Bytes] |
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
30.) FED_TRUST_ANCHOR_RES (Type 0x1D)
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 (0x1D) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Domain ID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Trust Anchor Document (Variable) |
| (JSON-signed document) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Curator Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
31.) FED_DISCOVERY_REQ (Type 0x1E)
Gebauer Expires 29 January 2027 [Page 167]
Internet-Draft IACP 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 (0x1E) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Search Pattern (Variable) |
| (UTF-8 domain prefix) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Results [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32.) FED_DISCOVERY_RES (Type 0x1F)
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 (0x1F) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Count [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Domain List (Variable) |
| (Array of Domain IDs) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Curator Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
33.) FED_REVOCATION (Type 0x20)
Gebauer Expires 29 January 2027 [Page 168]
Internet-Draft IACP 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 (0x20) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Domain ID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Anchor Fingerprint [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Revocation Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Curator Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
34.) FED_VALIDATE_REQ (Type 0x21)
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 (0x21) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Domain ID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
35.) FED_VALIDATE_RES (Type 0x22)
Gebauer Expires 29 January 2027 [Page 169]
Internet-Draft IACP 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 (0x22) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Validation Result [4 Bytes] |
| (0 = valid, 1 = invalid) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Validation Details (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Gateway Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
36.) PSS_ATTEST (Type 0x23)
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) |
| (EAT/CWT/TPM/TDX/SEV-SNP) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Digital Signature (Ed25519) [64B] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
37.) PSS_ATTEST_RES (Type 0x24)
Gebauer Expires 29 January 2027 [Page 170]
Internet-Draft IACP 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 (0x24) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Connection Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Status [4 Bytes] |
| (0 = valid, 1 = invalid) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Attestation Result (Variable) |
| (Signed Attestation Result) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Verifier Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
38.) ATTEST_VERIFY_REQ (Type 0x25)
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 (0x25) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attestation Type (1B) | Attestation Length (4B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TEE Evidence (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requestor Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
39.) ATTEST_VERIFY_RES (Type 0x26)
Gebauer Expires 29 January 2027 [Page 171]
Internet-Draft IACP 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 (0x26) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Status [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Attestation Result (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Verifier Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
40.) FAULT_NOTIFICATION (Type 0x2A)
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 (0x2A) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target URI Length (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target URI (Variable, UTF-8) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
41.) RETRY_OVERRIDE (Type 0x2B)
Gebauer Expires 29 January 2027 [Page 172]
Internet-Draft IACP 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 (0x2B) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target URI Length (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target URI (Variable, UTF-8) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reset Flag [1 Byte] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
42.) ERP_STREAM (Type 0x2C)
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 (0x2C) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Generation Counter [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encapsulated PSS Payload (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
43.) REVOCATION_SUBMIT (Type 0x2D)
Gebauer Expires 29 January 2027 [Page 173]
Internet-Draft IACP 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 (0x2D) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Submitter EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
44.) REVOCATION_ACCEPT (Type 0x2E)
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 (0x2E) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Validator EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 174]
Internet-Draft IACP July 2026
45.) REVOCATION_REJECT (Type 0x2F)
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 (0x2F) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Validator EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
46.) REVOCATION_FORWARD (Type 0x30)
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 (0x30) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Original Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New Locator EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Forwarder Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 175]
Internet-Draft IACP July 2026
47.) REVOCATION_REVERSAL (Type 0x31)
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 (0x31) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reversal Reason Code [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reverter EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
48.) ALGORITHM_NEGOTIATE (Type 0x32)
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 (0x32) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Cookie [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Algorithms Bitmap [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Algorithm [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Gebauer Expires 29 January 2027 [Page 176]
Internet-Draft IACP July 2026
49.) DHT_POM_UPDATE (Type 0x33)
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 (0x33) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Count [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Submitter EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
50.) DHT_POM_ACK (Type 0x34)
Gebauer Expires 29 January 2027 [Page 177]
Internet-Draft IACP 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 (0x34) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Validation Status [4 Bytes] |
| (0=accept, 1=reject) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Validator EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
51.) SLASH_COMMIT (Type 0x35)
Gebauer Expires 29 January 2027 [Page 178]
Internet-Draft IACP 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 (0x35) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Escrow Start Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Quorum Size [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Consensus Proof Length [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Consensus Proof (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Committer Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
52.) SLASH_VOTE (Type 0x36)
Gebauer Expires 29 January 2027 [Page 179]
Internet-Draft IACP 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 (0x36) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PoM Ticket Hash [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vote (0=slash, 1=reject) [1 Byte] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Voter EID [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Voter Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
53.) DHT_FIND_NODE (Type 0x3A)
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 (0x3A) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requestor EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
54.) DHT_FIND_NODE_RESP (Type 0x3B)
Gebauer Expires 29 January 2027 [Page 180]
Internet-Draft IACP 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 (0x3B) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node Count [2 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Node List (Variable) |
| (EID, IP, Port, Gen Counter) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
55.) DHT_STORE (Type 0x3C)
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 (0x3C) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Storage Key (SHA-256) [32 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTL [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length [4 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (Variable) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Owner Signature (Ed25519) [64 Bytes] |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
56.) DHT_STORE_ACK (Type 0x3D)
Gebauer Expires 29 January 2027 [Page 181]
Internet-Draft IACP 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 (0x3D) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Storage Key (SHA-256) [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code [4 Bytes] |
| (0 = success, 1 = failure) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replication Node EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
57.) DHT_PING (Type 0x3E)
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 (0x3E) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
58.) DHT_PONG (Type 0x3F)
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 (0x3F) | Flags | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID [32 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce [8 Bytes] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Appendix B. State Machines and Transition Diagrams of the IACP
To establish verifiable security bounds against resource exhaustion,
the initial IACP Discovery and Session Allocation subsystem is
formalized as a Deterministic Finite Automaton (DFA), denoted by the
5-tuple:
Gebauer Expires 29 January 2027 [Page 182]
Internet-Draft IACP July 2026
M_disc = (S, \Sigma, \delta, s_0, F)
Where the constituent sets and mappings are defined as follows:
1. S is the finite set of non-overlapping session allocation states:
S = { LISTEN, VALIDATING_POW, AWAIT_IDENTITY, PSS_NEGOTIATING,
ESTABLISHED }
2. \Sigma is the input alphabet consisting of network events and
cryptographic triggers: \Sigma = { RX_DISCOVERY_REQ, POW_FAILURE,
POW_SUCCESS, RX_PSS_INIT_(SFC=1), RX_PSS_INIT_(SFC=0),
IDENTITY_TIMEOUT }
3. s_0 in S is the unique, zero-allocation initial state: s_0 =
LISTEN
4. F subset of S is the set of final accepting operational states: F
= { PSS_NEGOTIATING, ESTABLISHED }
5. delta: S x Sigma -> S is the deterministic state transition
function, defined by the following exact mappings:
delta(LISTEN, RX_DISCOVERY_REQ) = VALIDATING_POW
delta(VALIDATING_POW, POW_FAILURE) = LISTEN
delta(VALIDATING_POW, POW_SUCCESS) = AWAIT_IDENTITY
delta(AWAIT_IDENTITY, RX_PSS_INIT_(SFC=1))= PSS_NEGOTIATING
delta(AWAIT_IDENTITY, RX_PSS_INIT_(SFC=0))= ESTABLISHED
delta(AWAIT_IDENTITY, IDENTITY_TIMEOUT) = LISTEN
Resource Invariant Guarantee: By formalizing the alphabet mapping
such that delta(LISTEN, RX_DISCOVERY_REQ) yields a state transition
where RAM = 0, the automaton proves that zero-state context is
allocated before verified PoW validation. State elevation to memory-
retaining structures is bound strictly to the execution of
delta(VALIDATING_POW, POW_SUCCESS).
1.) Discovery and Session Allocation DFA (Zero-Allocation State)
Gebauer Expires 29 January 2027 [Page 183]
Internet-Draft IACP July 2026
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| LISTEN | RX_DISCOVERY_REQ | VALIDATING_POW |
| | (Anonymous packet) | |
+-----------------------+-----------------------+---------------------+
| VALIDATING_POW | POW_FAILURE | LISTEN |
| | (Invalid nonce or | |
| | expired timestamp) | |
+-----------------------+-----------------------+---------------------+
| VALIDATING_POW | POW_SUCCESS | AWAIT_IDENTITY |
| | (Valid cryptographic | |
| | proof-of-work) | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | RX_PSS_INIT | PSS_NEGOTIATING |
| | (SFC_REQUESTED = 1) | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | RX_PSS_INIT | ESTABLISHED |
| | (SFC_REQUESTED = 0) | |
+-----------------------+-----------------------+---------------------+
| AWAIT_IDENTITY | IDENTITY_TIMEOUT | LISTEN |
| | (No valid PSS_INIT | |
| | within 500ms window) | |
+-----------------------+-----------------------+---------------------+
2.) Local ERP Context Lifecycle (LL-Entity)
+-----------------------+-----------------------+----------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+----------------------+
| UNBOUND | ERP_INIT (0x11) | ALLOCATED |
+-----------------------+-----------------------+----------------------+
| ALLOCATED | ERP_ALLOC (0x14) | ALLOCATED |
+-----------------------+-----------------------+----------------------+
| ALLOCATED | ERP_REGISTER (0x15) | TRANSITION |
+-----------------------+-----------------------+----------------------+
| TRANSITION | DHT Confirmation | BOUND |
+-----------------------+-----------------------+----------------------+
| BOUND | Network Churn | TRANSITION |
+-----------------------+-----------------------+----------------------+
| BOUND | App Digest Change | EVOLVE_PENDING |
+-----------------------+-----------------------+----------------------+
3.) Dynamic Circuit Breaker
Gebauer Expires 29 January 2027 [Page 184]
Internet-Draft IACP July 2026
+-----------------+-----------------------+---------------------------+
| Current State | Event (Input) | Next State |
+-----------------+-----------------------+---------------------------+
| CLOSED | RX_REQUEST_WITH_TICKET| CLOSED |
+-----------------+-----------------------+---------------------------+
| CLOSED | TRAFFIC_SPIKE | OPEN |
| | (Anomalous peak in | |
| | namespace sub-tree) | |
+-----------------+-----------------------+---------------------------+
| OPEN | RX_REQ_FROM_FLAGGED | OPEN |
| | (Request from flagged | |
| | namespace tree branch)| |
+-----------------+-----------------------+---------------------------+
| OPEN | COOLDOWN_TIMEOUT | CLOSED |
| | (Traffic returns to | |
| | baseline limits) | |
+-----------------+-----------------------+---------------------------+
| OPEN | RX_ACCESS_TICKET | OPEN |
| | (Valid ticket parsed | |
| | during open state) | |
+-----------------+-----------------------+---------------------------+
4.) Ongoing Session & Continuity (PSS & SFC Lifecycle FSM)
Gebauer Expires 29 January 2027 [Page 185]
Internet-Draft IACP July 2026
+-----------------+-----------------------+---------------------------+
| Current State | Event (Input) | Next State |
+-----------------+-----------------------+---------------------------+
| PSS_NEGOTIATING | SFC_EFFECTIVE | ESTABLISHED |
| | (Contract signed & | |
| | validated by peers) | |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED | RX_OUT_OF_ORDER | ANOMALY_FLAGGED |
| | (Historical payload or| |
| | gap in packet index) | |
+-----------------+-----------------------+---------------------------+
| ANOMALY_FLAGGED | ANOMALY_CLEARED | ESTABLISHED |
| | (Valid sequence re- | |
| | synchronization | |
| | achieved) | |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED/ | HEARTBEAT_FAIL | SESSION_ |
| ANOMALY_FLAGGED | (Invalid signature or | COMPROMISED |
| | unauthorized access) | |
+-----------------+-----------------------+---------------------------+
| ESTABLISHED | QUIC_CONN_CLOSE | DISCONNECTED |
| | (Unexpected transport | |
| | drop or timeout) | |
+-----------------+-----------------------+---------------------------+
| DISCONNECTED | PEER_RECONNECT | RECONCILING |
| | (Re-authenticating via| |
| | short-lived tokens) | |
+-----------------+-----------------------+---------------------------+
| RECONCILING | STATE_VECTORS_MATCH | ESTABLISHED |
| | (Delta log application| |
| | successful) | |
+-----------------+-----------------------+---------------------------+
5.) Curator Quarantine
Gebauer Expires 29 January 2027 [Page 186]
Internet-Draft IACP July 2026
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| ESTABLISHED | RX_REVOCATION_TICKET | CURATOR_QUARANTINE |
| | (Validated PoM match) | |
+-----------------------+-----------------------+---------------------+
| CURATOR_QUARANTINE | QUARANTINE_EXPIRED | EVICTED_PEER |
| | (No counter-proof) | |
+-----------------------+-----------------------+---------------------+
| CURATOR_QUARANTINE | RX_COUNTER_PROOF | ESTABLISHED |
| | (Valid signature) | |
+-----------------------+-----------------------+---------------------+
| EVICTED_PEER | CLEANUP_COMPLETE | LISTEN |
| | (Internal trigger) | |
+-----------------------+-----------------------+---------------------+
6.) The 4-Stage Security & Revocation Model
+---------------------+-----------------------+-----------------------+
| Current State | Event (Input) | Next State |
+---------------------+-----------------------+-----------------------+
| SESSION_COMPROMISED | VALIDATE_ANOMALY | EMERGENCY_ |
| | (Malicious behavior | REVOCATION |
| | deterministically | |
| | proven) | |
+---------------------+-----------------------+-----------------------+
| EMERGENCY_ | POM_GENERATED | PROPAGATING_WARN |
| REVOCATION | (Proof of Malfeasance | |
| | block fully compiled) | |
+---------------------+-----------------------+-----------------------+
| ACTIVE_CURATOR | CERT_CONTRADICTION | QUARANTINE |
| (Curator Node Only) | (Conflicting signed | |
| | claims discovered) | |
+---------------------+-----------------------+-----------------------+
| QUARANTINE | MALFEASANCE_PROVEN | PERMANENT_ |
| (Curator Node Only) | (Deliberate double- | DECAPITATION |
| | signing verified) | |
+---------------------+-----------------------+-----------------------+
| QUARANTINE | QUARANTINE_TIMEOUT | ACTIVE_CURATOR |
| (Curator Node Only) | (Grace period expiry | (Curator Node Only) |
| | without hard evidence)| |
+---------------------+-----------------------+-----------------------+
| ACTIVE_CURATOR/ | CURATOR_FLAGGED | AUTOMATED_EMERGENCY_ |
| QUARANTINE | (Parent curator enters| MIGRATION |
| (Sub-Space Nodes) | compromised state) | |
+---------------------+-----------------------+-----------------------+
7.) General IACP Workflow (DHI + ERP Integration)
Gebauer Expires 29 January 2027 [Page 187]
Internet-Draft IACP July 2026
+-----------------------+-----------------------+---------------------+
| Current State | Event (Input) | Next State |
+-----------------------+-----------------------+---------------------+
| INPUT_RECEIVED | INITIATE_RESOLVE | RESOLVING_INFRA |
+-----------------------+-----------------------+---------------------+
| RESOLVING_INFRA | DNS_SUCCESS | WELL_KNOWN_EVAL |
+-----------------------+-----------------------+---------------------+
| WELL_KNOWN_EVAL | ENDPOINT_UNREACHABLE | PROBLEM_CACHING |
+-----------------------+-----------------------+---------------------+
| WELL_KNOWN_EVAL | ENDPOINT_RESPONSIVE | LINK_HEADER_SNIFF |
+-----------------------+-----------------------+---------------------+
| SWITCH_POINT | HEAVY_MEDIA | LEGACY_PATH_ |
| | (Rich assets required | EXECUTION |
| | or ANML absent) | |
+-----------------------+-----------------------+---------------------+
| SWITCH_POINT | PURE_DATA_STREAM | NATIVE_ANML_ |
| | (ANML found, text- | INGESTION |
| | only extraction) | |
+-----------------------+-----------------------+---------------------+
| BOUND | Routing Failure | ERP_DEFLECT (0x0E) |
+-----------------------+-----------------------+---------------------+
Appendix C. Additional ASCII-Diagrams of the IACP
1.) Simplified Agent2Agent Communication via IACP
+------------------+ +-------------------+
| Host A: IP_1 | | Host B: IP_2 |
+------------------+ +-------------------+
| |
| Hosts (Persistent) | Hosts
v v
+------------------+ +-------------------+
| Node A: EID_1 | | Node B: EID_2 |
+------------------+ +-------------------+
| |
| Hosts (Ephemeral) | Hosts
v v
+------------------+ +-------------------+
| Endpoint: ESE_1 | <========= PSS ========> | Endpoint: ESE_2 |
+------------------+ (maybe with a SFC) +-------------------+
Appendix D. Security Principal and Verifier Binding Matrix
This mapping follows [I-D.bu-agentproto-security-principal-binding].
Table 1: Claims and Carriers
Gebauer Expires 29 January 2027 [Page 188]
Internet-Draft IACP July 2026
+------+---------------------------+----------------------------------+
| ID | Claim | Carrier / Location |
+------+---------------------------+----------------------------------+
| C-001| Live agent instance | EID (Ed25519 pubkey) in ERP |
|/peer-| identity | Routing Header |
|auth | | |
+------+---------------------------+----------------------------------+
| C-001| Live agent instance | IAT in local loopback frame |
|/local| (local) | |
|-conte| | |
|xt | | |
+------+---------------------------+----------------------------------+
| C-002| Human/organizational | Opaque Authorization Envelope |
| | authority (pre-execution) | (EMILIA receipt, WRT, etc.) |
+------+---------------------------+----------------------------------+
| C-003| Delegated scope | SFC Conditions Block / Opaque |
| | | Authorization Envelope |
+------+---------------------------+----------------------------------+
| C-004| Session continuity | Session Connection Cookie |
| | | (I-Cookie || R-Cookie) in PSS |
+------+---------------------------+----------------------------------+
| C-005| Action evidence | PoM ticket (cryptographic |
|/equiv| (equivocation only) | evidence of equivocation; does |
| | | not alone establish completion, |
| | | current authorization, or |
| | | independent observation) |
+------+---------------------------+----------------------------------+
| C-005| Action evidence (payload) | PSS_DATA_STREAM encrypted |
|/paylo| | payload (AES-GCM-256) |
|ad | | |
+------+---------------------------+----------------------------------+
| C-006| Tool/resource identity | Target_URI in USIV / Opaque |
| | | Authorization Envelope |
+------+---------------------------+----------------------------------+
| C-007| Evidence provenance | PoM ticket signature (Ed25519) |
+------+---------------------------+----------------------------------+
| C-008| Freshness / revocation | Generation Counter in ERP |
|/gen | | Routing Header |
+------+---------------------------+----------------------------------+
| C-008| Freshness / revocation | 2PSE Escrow Window (1h) |
|/escro| (challenge window) | |
|w | | |
+------+---------------------------+----------------------------------+
| C-009| Failure handling | FSM transitions (PROBLEM_CACHE, |
| | | LEGACY_PATH, exp. backoff) |
+------+---------------------------+----------------------------------+
| C-010| Composition boundary | IIB + USIV (DHI -> LLM Core) |
+------+---------------------------+----------------------------------+
Gebauer Expires 29 January 2027 [Page 189]
Internet-Draft IACP July 2026
| C-011| Accepted result (scope- | Verifier-produced verdict; |
| | bounded verdict) | conveyed via USIV payload |
| | | pointer as a carrier/handle |
+------+---------------------------+----------------------------------+
| C-012| Authorization/attribution | SFC (pre-exec) vs. PoM (post) |
| | boundary | separation |
+------+---------------------------+----------------------------------+
| C-013| Scoped standing grant | Opaque Authorization Envelope |
| | (pre-execution) | (carries or references grant: |
| | | issuer, subject, asset, verb, |
| | | constraints, expiry, rev.) |
+------+---------------------------+----------------------------------+
Table 2: Verifiers and Verification Rules
+------+---------------------------+----------------------------------+
| ID | Verifier | Verification Rule |
+------+---------------------------+----------------------------------+
| C-001| Receiving LL-Entity | Verify Ed25519 signature on |
|/peer-| | PSS_INIT, PSS_ACK, MIGRATION_ |
|auth | | VECTOR |
+------+---------------------------+----------------------------------+
| C-001| Local LL-Entity | Verify 256-bit IAT matches |
|/local| | allocated context |
|-conte| | |
|xt | | |
+------+---------------------------+----------------------------------+
| C-002| L7 App Gateway (async) | EMILIA signature verification, |
| | | WRT budget check; full |
| | | validation after fast-path |
| | | pre-check |
+------+---------------------------+----------------------------------+
| C-003| Receiving PSS peer / | Validate SFC ratification; check |
| | L7 Gateway | resource limits and permission |
| | | scopes |
+------+---------------------------+----------------------------------+
| C-004| Both PSS peers | Verify Dual-Cookie match and |
| | | non-zero R-Cookie after |
| | | handshake |
+------+---------------------------+----------------------------------+
| C-005| Global Directory Quorum | Verify both signatures against |
|/equiv| | Target_EID; check structural |
| | | non-identity |
+------+---------------------------+----------------------------------+
| C-005| Receiving PSS peer | AES-GCM-256 decryption; |
|/paylo| | sequence number verification |
|ad | | |
+------+---------------------------+----------------------------------+
Gebauer Expires 29 January 2027 [Page 190]
Internet-Draft IACP July 2026
| C-006| DHI (via LL-Entity) / | Validate URI resolution; HRP/APE |
| | L7 Gateway | evaluation; check envelope for |
| | | tool scope |
+------+---------------------------+----------------------------------+
| C-007| Any peer or DHT node | Ed25519 signature verification |
| | | against EID |
+------+---------------------------+----------------------------------+
| C-008| Receiving LL-Entity / | Compare Packet_Gen with |
|/gen | DHT node | Cache_Gen; update on > |
+------+---------------------------+----------------------------------+
| C-008| Global Directory Quorum | Wait for counter-proof during |
|/escro| | STATE_CHALLENGED |
|w | | |
+------+---------------------------+----------------------------------+
| C-009| DHI / LL-Entity | Enforce FSM invariants; exp. |
| | | backoff (T_base=2s, T_max=300s) |
+------+---------------------------+----------------------------------+
| C-010| DHI and LLM Core | Enforce separation; validate |
| | | USIV structure |
+------+---------------------------+----------------------------------+
| C-011| Verifier (e.g., L7 App | Evaluate canonicalized payload |
| | Gateway, DHI) | against policy and scope; |
| | | produce a scope-bounded verdict |
| | | (accept/reject) |
+------+---------------------------+----------------------------------+
| C-012| Global Directory Quorum / | SFC: pre-execution auth; PoM: |
| | PSS peers | post-execution evidence |
+------+---------------------------+----------------------------------+
| C-013| L4 fast-path (eBPF) | Envelope integrity + forward; |
| | | MUST NOT interpret semantics |
+------+---------------------------+----------------------------------+
| C-013| L7 Application Gateway | Grant validation: issuer/sig, |
| | (with policy engine) | subject, resource/verb, |
| | | constraints, expiry, revocation, |
| | | request binding |
+------+---------------------------+----------------------------------+
Table 3: Bindings and Freshness Rules
+------+---------------------------+----------------------------------+
| ID | Binding | Freshness Rule |
+------+---------------------------+----------------------------------+
| C-001| Session handshake | EID rotation (admin, compromise, |
|/peer-| transcript + Local_IAT | context term); Generation |
|auth | | Counter |
+------+---------------------------+----------------------------------+
| C-001| Local EID context | 90s liveness timeout; KEEPALIVE |
|/local| | every 30s |
Gebauer Expires 29 January 2027 [Page 191]
Internet-Draft IACP July 2026
|-conte| | |
|xt | | |
+------+---------------------------+----------------------------------+
| C-002| Opaque Auth Envelope + | Receipt expiry; WRT budget; L7 |
| | session context | async verification window |
+------+---------------------------+----------------------------------+
| C-003| PSS session + EIDs + | SFC conditions block; session |
| | ESE endpoints | lifetime |
+------+---------------------------+----------------------------------+
| C-004| Session state table via | Handshake sequence; per-packet |
| | Local_Session_Key | sequence numbers |
+------+---------------------------+----------------------------------+
| C-005| Target_EID + conflicting | Timestamp; epoch validation |
|/equiv| header fragments | |
+------+---------------------------+----------------------------------+
| C-005| Session Connection Cookie | Monotonically increasing |
|/paylo| + Sequence Number | sequence; per-packet nonce |
|ad | | |
+------+---------------------------+----------------------------------+
| C-006| Source_EID + | T_eval timeout (15000ms); cache |
| | Payload_Pointer / | TTL 300s |
| | Opaque Envelope | |
+------+---------------------------+----------------------------------+
| C-007| Target_EID + conflicting | Timestamp; no expiry specified |
| | fragments | |
+------+---------------------------+----------------------------------+
| C-008| Source_EID + current IP | Monotonically increasing |
|/gen | mapping | Generation Counter |
+------+---------------------------+----------------------------------+
| C-008| PoM ticket + Target_EID | 1-hour challenge window |
|/escro| | (T_escrow) |
|w | | |
+------+---------------------------+----------------------------------+
| C-009| Request context + target | TTL 300s for cache; backoff |
| | URI | attempts count |
+------+---------------------------+----------------------------------+
| C-010| Source_EID + Target_URI + | Session lifetime; deallocate on |
| | Payload_Pointer | completion |
+------+---------------------------+----------------------------------+
| C-011| Verifier-produced verdict | Session context lifetime; the |
| | + session context | verdict is bound to the session, |
| | | not the raw carrier |
+------+---------------------------+----------------------------------+
| C-012| SFC: session; PoM: EID + | SFC: session lifetime; PoM: |
| | timestamp | timestamp |
+------+---------------------------+----------------------------------+
| C-013| Opaque Envelope + L4 | Grant validity window + explicit |
| | stream + session context | revocation/status check; request |
Gebauer Expires 29 January 2027 [Page 192]
Internet-Draft IACP July 2026
| | | binding to current action |
+------+---------------------------+----------------------------------+
Table 4: Failure Behavior and Status
+------+---------------------------+-------------------+--------------+
| ID | Failure Behavior | Specification | Implementation|
| | | | Evidence |
+------+---------------------------+-------------------+--------------+
| C-001| Reject connection; drop | specified | none |
|/peer-| packet; raise alert | | |
|auth | | | |
+------+---------------------------+-------------------+--------------+
| C-001| Drop frame; purge crypto | specified | none |
|/local| context | | |
|-conte| | | |
|xt | | | |
+------+---------------------------+-------------------+--------------+
| C-002| Silent teardown of | specified | source- |
| | PSS/ESEs; temp EID | | claimed / not|
| | deny-list (5-60 min) | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-003| Reject PSS negotiation; | specified | source- |
| | deny ESE access | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-004| Discard packet; close | specified | source- |
| | session | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-005| Reject invalid tickets; | specified | source- |
|/equiv| quarantine node | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-005| Discard; request | specified | source- |
|/paylo| retransmission; close | | claimed / not|
|ad | session | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-006| Legacy fallback; cache | specified | source- |
| | failure | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
Gebauer Expires 29 January 2027 [Page 193]
Internet-Draft IACP July 2026
| C-007| Drop invalid tickets; no | specified | source- |
| | state mutation | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-008| Update cache; discard | specified | source- |
|/gen | stale packets | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-008| Slash stake; blacklist | specified | source- |
|/escro| EID | | claimed / not|
|w | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-009| Cache failure; drop | specified | source- |
| | fast-path; legacy fallback| | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-010| Drop USIV; no state | specified | source- |
| | invalidation | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-011| Verifier returns verdict | specified | source- |
| | with rejection reason; | | claimed / not|
| | application layer | | independently|
| | handles retry or fallback | | verified |
+------+---------------------------+-------------------+--------------+
| C-012| SFC: reject; PoM: | specified | source- |
| | slashing | | claimed / not|
| | | | independently|
| | | | verified |
+------+---------------------------+-------------------+--------------+
| C-013| L4: forward only; | specified | source- |
| | L7: silent teardown on | | claimed / not|
| | grant mismatch (scope, | | independently|
| | expiry, revocation, | | verified |
| | binding) | | |
+------+---------------------------+-------------------+--------------+
Table 5: Dependencies and Evidence References
Gebauer Expires 29 January 2027 [Page 194]
Internet-Draft IACP July 2026
+------+---------------------------+----------------------------------+
| ID | Dependency | Evidence Type |
+------+---------------------------+----------------------------------+
| C-001| None | Spec: Appendix A |
|/peer-| | Evidence: source-claimed / not |
|auth | | independently verified |
+------+---------------------------+----------------------------------+
| C-001| None | Spec: Section 4.2.2.2 |
|/local| | Evidence: implementation-local |
|-conte| | (source-claimed / not |
|xt | | independently verified) |
+------+---------------------------+----------------------------------+
| C-002| EMILIA Protocol / WRT / | Spec: Section 5.7.2; Sec 5.7.3 |
| | ext. auth system | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-003| None | Spec: Section 6.4.4 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-004| None | Spec: Section 4.2.4 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-005| None | Spec: Section 4.2.7.1 |
|/equiv| | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-005| None | Spec: Section 6.4.5 |
|/paylo| | Evidence: source-claimed / not |
|ad | | independently verified |
+------+---------------------------+----------------------------------+
| C-006| None | Spec: Section 4.1.2; 4.1.3 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-007| None | Spec: Section 4.2.7.1 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-008| None | Spec: Section 4.2.5.2 |
|/gen | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-008| None | Spec: Section 4.2.7.2 |
|/escro| | Evidence: source-claimed / not |
|w | | independently verified |
+------+---------------------------+----------------------------------+
Gebauer Expires 29 January 2027 [Page 195]
Internet-Draft IACP July 2026
| C-009| None | Spec: Section 4.1.2.4; 4.2.6.1 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-010| None | Spec: Section 4.1.5 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-011| Policy engine / | Spec: Section 4.1.5.3 |
| | Application policy | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-012| None | Spec: Section 6.4.4; 4.2.7.1 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
| C-013| EMILIA Protocol / ext. | Spec: Section 5.7.1; 5.7.2; |
| | auth system | 5.7.3 |
| | | Evidence: source-claimed / not |
| | | independently verified |
+------+---------------------------+----------------------------------+
Table 6: Negative Vectors (Failure Cases)
+------+------------------------------+-------------------------------+
| ID | Vector | Required Outcome |
+------+------------------------------+-------------------------------+
| NV-1 | Opaque envelope presented as | Refuse C-013; carrier validity|
| | standing grant | is not a standing-grant result|
+------+------------------------------+-------------------------------+
| NV-2 | USIV pointer forwarded before| L4 fast path may forward or |
| | L7 verification | label as "unevaluated"; MUST |
| | | NOT yield C-011 acceptance |
+------+------------------------------+-------------------------------+
| NV-3 | Reported outcome presented as| Refuse physical-completion or |
| | physical completion | independent-observation unless|
| | | separate verifier/evidence row|
| | | establishes it |
+------+------------------------------+-------------------------------+
| NV-4 | Valid envelope carrying a | Refuse C-013; L7 verifier must|
| | grant with wrong scope, | check issuer/subject/resource/|
| | expired, or revoked state | verb/constraints/revocation |
+------+------------------------------+-------------------------------+
Acknowledgements
The author would like to thank Aaron Jerskey from the ANML Foundation
for his valuable feedback on this specification.
Gebauer Expires 29 January 2027 [Page 196]
Internet-Draft IACP July 2026
Furthermore, the author would also like to thank Dr. Iman Schrockfrom
the EMILIA Protocol and Songbo from the A2A Communication Mailinglist
for theier valuable feedback on this specification.
An LLM was used to review and improve the clarity and phrasing of the
text in this document. The ASCII-Diagrams (for example the Wire
Formats) have been worked out by the author itself and put into shape
by an LLM Model.
Author's Address
Leonard Gebauer
Independent
Germany
Email: leonard.gebauer.ha@gmail.com
Gebauer Expires 29 January 2027 [Page 197]