# drafts

name: draft-teodor-pilot-problem-statement
rev: 01
title: Problem Statement: Network-Layer Infrastructure for Autonomous Agent Communication
time: 2026-04-06T17:03:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-08T17:03:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:48.588975+00:00
source: ietf
abstract:
  AI agents --- autonomous software entities capable of reasoning,
     planning, and executing tasks --- are an increasingly important class
     of network participant.  Current agent communication protocols
     operate exclusively at the application layer over HTTP, assuming the
     existence of stable endpoints, DNS names, and centralized
     infrastructure.  No existing standard provides network-layer
     identity, addressing, or transport for agents.  This document
     describes the problem space and identifies requirements for a
     network-layer infrastructure that would give agents first-class
     network citizenship, independent of the web infrastructure designed
     for human users.

full_text:
  Independent Submission                                         C. Teodor
  Internet-Draft                                              Vulture Labs
  Intended status: Informational                              6 April 2026
  Expires: 8 October 2026


    Problem Statement: Network-Layer Infrastructure for Autonomous Agent
                               Communication
                  draft-teodor-pilot-problem-statement-01

  Abstract

     AI agents --- autonomous software entities capable of reasoning,
     planning, and executing tasks --- are an increasingly important class
     of network participant.  Current agent communication protocols
     operate exclusively at the application layer over HTTP, assuming the
     existence of stable endpoints, DNS names, and centralized
     infrastructure.  No existing standard provides network-layer
     identity, addressing, or transport for agents.  This document
     describes the problem space and identifies requirements for a
     network-layer infrastructure that would give agents first-class
     network citizenship, independent of the web infrastructure designed
     for human users.

  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 8 October 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Teodor                   Expires 8 October 2026                 [Page 1]


  Internet-Draft       Agent Network Problem Statement          April 2026


     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.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Problem Description . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Agent Identity Is Coupled to Infrastructure . . . . . . .   4
       3.2.  No Peer-to-Peer Communication Without Web
             Infrastructure  . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  No Agent-Native Trust Model . . . . . . . . . . . . . . .   5
       3.4.  No Lightweight Transport for Agent Streams  . . . . . . .   6
       3.5.  Privacy Gaps in Agent Discovery . . . . . . . . . . . . .   6
       3.6.  No Multi-Tenant Network Isolation . . . . . . . . . . . .   7
     4.  Requirements for a Solution . . . . . . . . . . . . . . . . .   7
       4.1.  Virtual Addressing  . . . . . . . . . . . . . . . . . . .   7
       4.2.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Bilateral Trust Model . . . . . . . . . . . . . . . . . .   8
       4.4.  Lightweight Encrypted Transport . . . . . . . . . . . . .   8
       4.5.  Privacy-by-Default Discovery  . . . . . . . . . . . . . .   8
       4.6.  Multi-Tenant Isolation  . . . . . . . . . . . . . . . . .   9
       4.7.  Audit and Compliance  . . . . . . . . . . . . . . . . . .   9
     5.  Existing Approaches and Gaps  . . . . . . . . . . . . . . . .   9
       5.1.  MCP (Model Context Protocol)  . . . . . . . . . . . . . .   9
       5.2.  A2A (Agent-to-Agent Protocol) . . . . . . . . . . . . . .   9
       5.3.  WebRTC  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.4.  QUIC  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.5.  libp2p  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.6.  WireGuard . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.7.  LISP  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.8.  AGTP (Agent Transfer Protocol)  . . . . . . . . . . . . .  11
       5.9.  ATP (Agent Transfer Protocol) . . . . . . . . . . . . . .  11
       5.10. AIP (Agent Identity Protocol) . . . . . . . . . . . . . .  11
       5.11. CATALIST Coordination . . . . . . . . . . . . . . . . . .  11
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  15
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15






  Teodor                   Expires 8 October 2026                 [Page 2]


  Internet-Draft       Agent Network Problem Statement          April 2026


  1.  Introduction

     The internet's protocol stack was designed for human-operated devices
     with stable network attachments.  IP addresses identify interfaces,
     DNS names identify services, and TLS certificates identify
     organizations.  These assumptions break down for AI agents, which are
     transient software processes that may run behind NAT, migrate between
     hosts, and lack persistent network identity.

     Recent standardization efforts for agent communication --- notably
     MCP [MCP] (agent-to-tool) and A2A [A2A] (agent-to-agent) --- have
     focused on application-layer protocols built on HTTP.  These
     protocols define what agents say to each other but assume the
     underlying problem of how agents reach each other is already solved.
     For agents running in cloud environments with public endpoints, this
     assumption holds.  For agents running on edge devices, behind
     corporate firewalls, on laptops, or in heterogeneous multi-cloud
     deployments, it does not.

     The IETF has seen explosive activity in AI agent protocol
     standardization, with over thirty individual drafts filed in
     2025-2026 covering agent identity ([I-D.prakash-aip],
     [I-D.ni-wimse-ai-agent-identity]), discovery
     ([I-D.nemethi-aid-agent-identity-discovery]), transport
     ([I-D.hood-independent-agtp], [I-D.li-atp]), routing
     ([I-D.du-catalist-routing-considerations]), frameworks
     ([I-D.rosenberg-aiproto-framework],
     [I-D.zyyhl-agent-networks-framework],
     [I-D.eckert-catalist-acip-framework]), and audit
     ([I-D.sharif-agent-audit-trail]).  The CATALIST Birds of a Feather
     session at IETF 125 (March 2026, Shenzhen) was the first formal
     coordination effort, surveying the problem space
     ([I-D.yao-catalist-problem-space-analysis]) without yet chartering a
     working group.

     Despite this volume, the vast majority of these drafts operate at the
     application layer over HTTP.  Even the dedicated transport proposals
     (AGTP, ATP) define application-layer semantics carried over QUIC or
     TCP --- none provides an overlay network with virtual addressing,
     port-based multiplexing, and built-in NAT traversal at the network
     layer.  The network-layer gap identified in the original version of
     this document remains unaddressed.

     This document describes the problem of network-layer infrastructure
     for autonomous agent communication, identifies the gaps in existing
     protocols, and states requirements for a solution.  It is modeled
     after [RFC7364], which performed a similar analysis for network
     virtualization overlays.



  Teodor                   Expires 8 October 2026                 [Page 3]


  Internet-Draft       Agent Network Problem Statement          April 2026


  2.  Terminology

     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.

     Agent:  An autonomous software entity capable of reasoning, planning,
        and executing tasks without continuous human supervision.  An
        agent may run as a process, container, or serverless function.

     Overlay Network:  A virtual network built on top of an existing
        network (the underlay).  Overlay nodes communicate using
        encapsulated packets carried over the underlay.

     Virtual Address:  A network address assigned within the overlay
        address space, independent of the underlay IP address.  A virtual
        address identifies an agent, not a network interface.

     Registry:  A service that assigns virtual addresses, maintains an
        address-to-locator mapping table, and provides bootstrap
        information for overlay participants.

     Trust Handshake:  A protocol exchange through which two agents
        establish a bilateral trust relationship with explicit mutual
        consent.

  3.  Problem Description

  3.1.  Agent Identity Is Coupled to Infrastructure

     In current practice, agents are identified by URLs, DNS names, or API
     endpoints --- all of which are tied to the infrastructure hosting the
     agent, not to the agent itself.  When an agent migrates to a
     different host, changes cloud provider, or restarts behind a
     different NAT binding, its identity changes.  There is no stable
     identifier that follows an agent across these transitions.

     This is analogous to the identity/locator conflation problem in IP
     networking, which motivated the Locator/ID Separation Protocol (LISP)
     [RFC9300].  In LISP, Endpoint Identifiers (EIDs) are separated from
     Routing Locators (RLOCs) so that an endpoint's identity is
     independent of its network attachment point.  Agents need the same
     separation: a permanent identity that is independent of the transient
     infrastructure hosting them.





  Teodor                   Expires 8 October 2026                 [Page 4]


  Internet-Draft       Agent Network Problem Statement          April 2026


     The A2A protocol [A2A] identifies agents via "Agent Cards" served at
     well-known HTTPS URLs.  The Agent URI scheme
     [I-D.narvaneni-agent-uri] proposes agent:// URIs but still requires
     DNS-resolvable endpoints.  Both approaches require the agent to
     maintain a stable, publicly reachable web endpoint --- a requirement
     that excludes agents running on edge devices, behind NAT, or in
     ephemeral compute environments.

  3.2.  No Peer-to-Peer Communication Without Web Infrastructure

     Both MCP [MCP] and A2A [A2A] require HTTP endpoints for
     communication.  This means every agent must either have a publicly
     routable IP address or be fronted by a reverse proxy, load balancer,
     or API gateway.  For two agents behind NAT to communicate, at least
     one must provision web infrastructure as an intermediary.

     NAT traversal is a solved problem for specific domains: WebRTC
     handles it for browsers (at the cost of ICE/DTLS-SRTP/SDP negotiation
     complexity), and WireGuard [WIREGUARD] handles it for VPN tunnels.
     But no existing protocol provides NAT traversal specifically designed
     for agent-to-agent communication, with agent-native addressing and
     trust semantics.

     An estimated 88% of real-world network environments involve some form
     of NAT.  Agents running on laptops, IoT devices, edge servers, and
     mobile phones cannot participate in HTTP-based agent protocols
     without significant infrastructure provisioning.

  3.3.  No Agent-Native Trust Model

     Existing trust models were designed for different participants:

     *  TLS: Trust is anchored in Certificate Authorities.  Agents would
        need to obtain and manage X.509 certificates, adding operational
        complexity disproportionate to many agent interactions.

     *  SSH: Trust-on-first-use (TOFU) assumes a human operator who can
        verify a host key fingerprint.  Autonomous agents have no human in
        the loop.

     *  OAuth/OIDC: Designed for user-to-service authorization, not peer-
        to-peer agent trust.  Requires an authorization server as a
        trusted third party.








  Teodor                   Expires 8 October 2026                 [Page 5]


  Internet-Draft       Agent Network Problem Statement          April 2026


     None of these models provide bilateral consent --- the property that
     both parties must explicitly agree before a communication
     relationship is established.  For autonomous entities that may be
     operated by different organizations, bilateral consent is a natural
     trust primitive: neither agent should be reachable by the other until
     both have agreed.

  3.4.  No Lightweight Transport for Agent Streams

     TCP and QUIC [RFC9000] are general-purpose transports optimized for
     web traffic patterns (request-response, large transfers, multiplexed
     streams).  Agent communication patterns differ:

     *  Many agents exchange small, frequent messages (status updates,
        task delegations, sensor readings) where connection setup overhead
        dominates.

     *  Agents often maintain long-lived bidirectional streams for event-
        driven architectures, where TCP's head-of-line blocking is
        problematic.

     *  Agents may need port-based service multiplexing (echo on one port,
        task submission on another, events on a third) --- a concept that
        exists in TCP/UDP but has no equivalent in HTTP-based agent
        protocols.

     While QUIC addresses head-of-line blocking through multiplexed
     streams, it does not provide agent addressing, discovery, or trust
     semantics.  A transport designed for agents could provide these as
     built-in capabilities rather than requiring them to be layered on
     top.

  3.5.  Privacy Gaps in Agent Discovery

     Current agent discovery mechanisms are designed for visibility:

     *  A2A Agent Cards are intended to be publicly discoverable at well-
        known URLs.

     *  DNS-SD and mDNS broadcast service availability to all listeners on
        a network segment.

     *  HTTP-based service registries typically allow any authenticated
        client to enumerate all registered services.







  Teodor                   Expires 8 October 2026                 [Page 6]


  Internet-Draft       Agent Network Problem Statement          April 2026


     For agents, the default should be the opposite.  An agent's existence
     and capabilities should not be disclosed to parties that have not
     been explicitly authorized.  Mass enumeration of agent endpoints
     creates attack surface (reconnaissance for exploitation) and privacy
     risks (mapping an organization's agent infrastructure).

     A privacy-by-default discovery model --- where agents are invisible
     until they explicitly opt in to specific peer relationships --- has
     no equivalent in current standards.

  3.6.  No Multi-Tenant Network Isolation

     Current agent protocols assume flat, single-tenant deployments where
     all agents share the same namespace and trust domain.  In practice,
     organizations deploy multiple agent teams serving different
     departments, projects, or customers.  These teams need isolation:

     *  Agents in one project should not observe or interfere with agents
        in another.

     *  Administrative control (who can join a network, what ports are
        accessible, who can modify policy) should be scoped per network,
        not global.

     *  Compliance requirements (SOC 2, GDPR, HIPAA) demand audit trails
        recording who did what, when, and to which network --- at the
        infrastructure layer, not bolted on at the application layer.

     No existing agent protocol or draft addresses multi-tenancy, role-
     based access control, or per-network policy enforcement.  The closest
     analog is cloud VPC isolation, but VPCs operate at the IP layer and
     require cloud provider infrastructure.  Agent networks need the same
     isolation primitives at the overlay layer, independent of the
     underlying cloud or network topology.

  4.  Requirements for a Solution

     Based on the problems identified above, a network-layer
     infrastructure for agent communication should satisfy the following
     requirements:

  4.1.  Virtual Addressing

     REQ-1:
        Agents MUST receive stable virtual addresses that are independent
        of their underlying IP address, network attachment point, and
        hosting infrastructure.




  Teodor                   Expires 8 October 2026                 [Page 7]


  Internet-Draft       Agent Network Problem Statement          April 2026


     REQ-2:
        The addressing scheme MUST support hierarchical grouping (e.g.,
        network or topic-based segmentation) to enable scoped
        communication boundaries.

  4.2.  NAT Traversal

     REQ-3:
        The system MUST provide automatic NAT traversal without requiring
        manual configuration of port forwarding, firewall rules, or relay
        proxies by the agent operator.

     REQ-4:
        NAT traversal MUST support direct peer-to-peer communication where
        possible, with transparent relay fallback when direct
        communication is not achievable.

  4.3.  Bilateral Trust Model

     REQ-5:
        Communication between agents MUST require explicit bilateral
        consent.  Neither agent should be reachable by the other until
        both have agreed to establish a trust relationship.

     REQ-6:
        Trust relationships MUST be revocable.  Revoking trust MUST
        immediately prevent further communication.

  4.4.  Lightweight Encrypted Transport

     REQ-7:
        The transport MUST provide reliable, ordered byte stream delivery
        (TCP-equivalent) and unreliable datagram delivery (UDP-equivalent)
        over the overlay.

     REQ-8:
        Encryption MUST be enabled by default for all data in transit,
        with no opt-in required from the agent developer.

     REQ-9:
        The transport MUST support port-based service multiplexing,
        allowing an agent to expose multiple services on different virtual
        ports.

  4.5.  Privacy-by-Default Discovery

     REQ-10:




  Teodor                   Expires 8 October 2026                 [Page 8]


  Internet-Draft       Agent Network Problem Statement          April 2026


        Agents MUST be private by default.  An agent's virtual address,
        physical locator, and capabilities MUST NOT be disclosed to
        parties without an established trust relationship or shared group
        membership.

     REQ-11:
        It MUST be possible to establish trust with a private agent
        without first knowing its physical network location (i.e., via a
        trusted relay or rendezvous mechanism).

  4.6.  Multi-Tenant Isolation

     REQ-12:
        The system MUST support isolated network segments with independent
        membership control, role-based access (at minimum: owner,
        administrator, and member roles), and per-network policy
        enforcement.  Operations within one network MUST NOT affect agents
        in another network.

  4.7.  Audit and Compliance

     REQ-13:
        The system MUST provide an audit trail recording security-relevant
        operations including node registration and deregistration, trust
        relationship changes, network membership modifications, role
        assignments, and policy updates.  Audit records MUST include
        timestamps, actor identifiers, and old/new values for state
        mutations.

  5.  Existing Approaches and Gaps

  5.1.  MCP (Model Context Protocol)

     MCP [MCP] standardizes the interface between AI models and external
     tools/resources.  It uses JSON-RPC over HTTP with Server-Sent Events
     for streaming.  MCP addresses agent-to-tool communication, not agent-
     to-agent communication, and provides no network-layer capabilities.
     It assumes agents can reach tool servers via HTTP.

  5.2.  A2A (Agent-to-Agent Protocol)

     A2A [A2A] defines a protocol for agent interoperability: Agent Cards
     for discovery, task lifecycle management, and multimodal message
     exchange.  A2A operates entirely over HTTP/HTTPS.  It provides no NAT
     traversal, no overlay addressing, no built-in encryption beyond TLS,
     and no bilateral trust model.  It assumes agents have reachable HTTP
     endpoints.




  Teodor                   Expires 8 October 2026                 [Page 9]


  Internet-Draft       Agent Network Problem Statement          April 2026


  5.3.  WebRTC

     WebRTC provides peer-to-peer communication with NAT traversal via
     ICE, encryption via DTLS-SRTP, and data channels via SCTP.  However,
     WebRTC was designed for browser-based audio/video communication.  Its
     complexity (ICE candidate gathering, SDP offer/answer negotiation,
     DTLS-SRTP key exchange) is disproportionate for agent message
     exchange.  WebRTC also lacks agent-specific concepts like virtual
     addressing, bilateral trust, and privacy-by-default discovery.

  5.4.  QUIC

     QUIC [RFC9000] provides a modern transport with multiplexed streams,
     built-in encryption, and reduced connection setup latency.  QUIC
     addresses transport-layer concerns but does not provide overlay
     addressing, agent identity, NAT traversal coordination, trust
     management, or discovery.  It is a potential underlay transport for
     an agent overlay, not a complete solution.

  5.5.  libp2p

     libp2p [LIBP2P] is a modular networking stack developed for
     decentralized applications, particularly in the blockchain ecosystem.
     It provides peer identity (via cryptographic keypairs), NAT
     traversal, and transport multiplexing. libp2p is the closest existing
     system to the requirements stated above.  However, it uses
     unstructured peer IDs (not hierarchical addresses), is heavyweight
     (large dependency tree), is oriented toward content-addressed
     distributed systems rather than agent communication patterns, and
     lacks built-in bilateral trust or privacy-by- default semantics.

  5.6.  WireGuard

     WireGuard [WIREGUARD] provides encrypted point-to-point tunnels with
     excellent performance.  It uses Curve25519 for key exchange and
     ChaCha20- Poly1305 for encryption.  WireGuard establishes tunnels
     between known peers with pre-shared public keys --- it does not
     provide dynamic discovery, agent addressing, or trust negotiation.
     It is a VPN, not an agent network.

  5.7.  LISP

     The Locator/ID Separation Protocol [RFC9300] [RFC9301] separates
     endpoint identity from network location, providing a conceptual
     precedent for agent addressing.  LISP's EID-to-RLOC mapping system is
     architecturally similar to an agent registry that maps virtual
     addresses to physical locators.  However, LISP operates at the IP
     layer for routing optimization, not at the application layer for



  Teodor                   Expires 8 October 2026                [Page 10]


  Internet-Draft       Agent Network Problem Statement          April 2026


     agent communication.  It does not provide agent-specific trust
     models, privacy semantics, or built-in services.

  5.8.  AGTP (Agent Transfer Protocol)

     AGTP [I-D.hood-independent-agtp] proposes a dedicated application-
     layer protocol for AI agent traffic with agent-native intent methods
     (QUERY, SUMMARIZE, DELEGATE, COLLABORATE).  It correctly identifies
     that MCP and A2A are messaging-layer constructs that do not address
     the transport problem.  However, AGTP operates over QUIC or TCP/TLS
     at the application layer --- it defines what agents say, not how they
     reach each other.  It provides no overlay addressing, no virtual
     network primitives, no NAT traversal, and no multi-tenant isolation.

  5.9.  ATP (Agent Transfer Protocol)

     ATP [I-D.li-atp] defines a two-tier architecture where agents connect
     to ATP servers, with DNS-based service discovery via SVCB records.
     It supports asynchronous messaging, synchronous request/response, and
     event-driven streaming.  Like AGTP, ATP operates at the application
     layer and requires server infrastructure as an intermediary --- the
     same dependency on centralized endpoints that HTTP-based protocols
     impose.  It does not address overlay networking, NAT traversal for
     serverless agents, or privacy-by-default semantics.

  5.10.  AIP (Agent Identity Protocol)

     AIP [I-D.prakash-aip] defines verifiable, delegable identity for AI
     agents using Invocation-Bound Capability Tokens (IBCTs) with Ed25519
     signatures and Biscuit-based delegation chains.  AIP addresses the
     identity problem (REQ-1) with a cryptographically strong approach.
     However, it focuses exclusively on identity and authorization --- it
     provides no transport, addressing, or network-layer primitives.
     AIP's identity tokens could complement an overlay network that
     provides the missing transport substrate.

  5.11.  CATALIST Coordination

     The CATALIST BoF at IETF 125
     [I-D.yao-catalist-problem-space-analysis] surveyed the agent protocol
     landscape and began scoping what IETF should standardize.  The
     problem space analysis identified categories including agent
     identity, discovery, communication, and governance.  Notably, agent
     network routing [I-D.du-catalist-routing-considerations] defines
     forwarding based on Agent ID, Gateway ID, and Skill --- concepts that
     overlap with virtual addressing and service multiplexing.  The ACIP
     framework [I-D.eckert-catalist-acip-framework] proposes agent-aware
     network infrastructure drawing from overlay/underlay designs.  These



  Teodor                   Expires 8 October 2026                [Page 11]


  Internet-Draft       Agent Network Problem Statement          April 2026


     efforts validate the need for network-layer agent infrastructure but
     have not yet produced a concrete protocol specification.

  6.  Security Considerations

     A network-layer infrastructure for agents introduces security
     considerations beyond those of traditional overlay networks:

     Centralized Registry:  A registry that assigns addresses and
        maintains locator mappings is a trusted third party.  Compromise
        of the registry could allow address hijacking, locator spoofing,
        or metadata harvesting.  The registry should support
        authentication, access control, and replication for high
        availability.

     Overlay Header Metadata:  Even with payload encryption, overlay
        packet headers may expose source and destination virtual
        addresses, port numbers, and packet sizes.  Traffic analysis on
        the overlay is possible even when the underlay is encrypted.

     Trust Model Assumptions:  A bilateral trust model assumes that agents
        can make informed consent decisions.  If an agent's trust logic is
        compromised (e.g., by adversarial prompt injection), it may
        approve trust relationships it should reject.  The trust model
        provides a mechanism, not a policy --- the security of trust
        decisions depends on the agent's reasoning capability.

     Key Management:  Overlay encryption requires key exchange between
        peers.  Anonymous key exchange (without identity binding) is
        vulnerable to man-in-the-middle attacks.  Authenticated key
        exchange requires a mechanism to distribute and verify public
        keys, which depends on the registry's integrity.

     Multi-Tenant Control Plane:  A multi-tenant registry introduces
        additional attack surface.  Per-network role-based access control
        must be enforced consistently to prevent privilege escalation
        (e.g., a member modifying network policy).  Admin token
        authentication for privileged operations must use constant-time
        comparison to prevent timing attacks.  Audit trails must be
        tamper-evident and persist across service restarts to support
        forensic analysis (see also [I-D.sharif-agent-audit-trail]).

  7.  IANA Considerations

     This document has no IANA actions.

  8.  References




  Teodor                   Expires 8 October 2026                [Page 12]


  Internet-Draft       Agent Network Problem Statement          April 2026


  8.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  8.2.  Informative References

     [A2A]      Google, "Agent-to-Agent Protocol", 2025,
                <https://google.github.io/A2A/>.

     [I-D.du-catalist-routing-considerations]
                Du, Z., "Routing Considerations in Agentic Network", 2026,
                <https://datatracker.ietf.org/doc/draft-du-catalist-
                routing-considerations/>.

     [I-D.eckert-catalist-acip-framework]
                Eckert, T., "Framework for Agent Communications Internet
                Protocol (ACIP)", 2026, <https://datatracker.ietf.org/doc/
                draft-eckert-catalist-acip-framework/>.

     [I-D.hood-independent-agtp]
                Hood, C., "Agent Transfer Protocol (AGTP)", 2026,
                <https://datatracker.ietf.org/doc/draft-hood-independent-
                agtp/>.

     [I-D.li-atp]
                Li, Y., "Agent Transfer Protocol (ATP)", 2026,
                <https://datatracker.ietf.org/doc/draft-li-atp/>.

     [I-D.narvaneni-agent-uri]
                Narvaneni, S., "Agent URI Scheme", 2025,
                <https://datatracker.ietf.org/doc/draft-narvaneni-agent-
                uri/>.

     [I-D.nemethi-aid-agent-identity-discovery]
                Nemethi, B., "Agent Identity and Discovery (AID)", 2026,
                <https://datatracker.ietf.org/doc/draft-nemethi-aid-agent-
                identity-discovery/>.







  Teodor                   Expires 8 October 2026                [Page 13]


  Internet-Draft       Agent Network Problem Statement          April 2026


     [I-D.ni-wimse-ai-agent-identity]
                Ni, Y. and C. P. Liu, "WIMSE Applicability for AI Agents",
                2026, <https://datatracker.ietf.org/doc/draft-ni-wimse-ai-
                agent-identity/>.

     [I-D.prakash-aip]
                Prakash, S., "Agent Identity Protocol (AIP)", 2026,
                <https://datatracker.ietf.org/doc/draft-prakash-aip/>.

     [I-D.rosenberg-aiproto-framework]
                Rosenberg, J., "A Framework for AI Protocols", 2025,
                <https://datatracker.ietf.org/doc/draft-rosenberg-aiproto-
                framework/>.

     [I-D.sharif-agent-audit-trail]
                Sharif, R., "Agent Audit Trail", 2026,
                <https://datatracker.ietf.org/doc/draft-sharif-agent-
                audit-trail/>.

     [I-D.yao-catalist-problem-space-analysis]
                Zhou, Y. and K. Yao, "Problem Space Analysis of AI Agent
                Protocols in IETF", 2026,
                <https://datatracker.ietf.org/doc/draft-yao-catalist-
                problem-space-analysis/>.

     [I-D.zyyhl-agent-networks-framework]
                Yao, Z., "A Framework for Agent Networks", 2025,
                <https://datatracker.ietf.org/doc/draft-zyyhl-agent-
                networks-framework/>.

     [LIBP2P]   Protocol Labs, "libp2p: A Modular Network Stack", 2023,
                <https://libp2p.io/>.

     [MCP]      Anthropic, "Model Context Protocol", 2024,
                <https://modelcontextprotocol.io/>.

     [RFC7364]  Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
                Kreeger, L., and M. Napierala, "Problem Statement:
                Overlays for Network Virtualization", RFC 7364,
                DOI 10.17487/RFC7364, October 2014,
                <https://www.rfc-editor.org/rfc/rfc7364>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000>.





  Teodor                   Expires 8 October 2026                [Page 14]


  Internet-Draft       Agent Network Problem Statement          April 2026


     [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
                Cabellos, Ed., "The Locator/ID Separation Protocol
                (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
                <https://www.rfc-editor.org/rfc/rfc9300>.

     [RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
                Ed., "Locator/ID Separation Protocol (LISP) Control
                Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
                <https://www.rfc-editor.org/rfc/rfc9301>.

     [WIREGUARD]
                Donenfeld, J. A., "WireGuard: Next Generation Kernel
                Network Tunnel", 2017,
                <https://www.wireguard.com/papers/wireguard.pdf>.

  Appendix A.  Acknowledgments

     The author thanks the participants of the IETF AI protocols
     discussions for their contributions to understanding the agent
     communication landscape.

  Author's Address

     Calin Teodor
     Vulture Labs
     Email: teodor@vulturelabs.com

























  Teodor                   Expires 8 October 2026                [Page 15]


name: draft-teodor-pilot-protocol
rev: 01
title: Pilot Protocol: An Overlay Network for Autonomous Agent Communication
time: 2026-04-06T17:02:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-08T17:02:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:48.588980+00:00
source: ietf
abstract:
  This document specifies Pilot Protocol, an overlay network that
     provides autonomous AI agents with virtual addresses, port-based
     service multiplexing, reliable and unreliable transport, NAT
     traversal, encrypted tunnels, and a bilateral trust model.  Pilot
     Protocol operates as a network and transport layer beneath
     application-layer agent protocols such as A2A and MCP.  It
     encapsulates virtual packets in UDP datagrams for transit over the
     existing Internet.  The protocol gives agents first-class network
     citizenship --- stable identities, reachable addresses, and standard
     transport primitives --- independent of their underlying network
     infrastructure.

full_text:
  Independent Submission                                         C. Teodor
  Internet-Draft                                              Vulture Labs
  Intended status: Experimental                               6 April 2026
  Expires: 8 October 2026


   Pilot Protocol: An Overlay Network for Autonomous Agent Communication
                       draft-teodor-pilot-protocol-01

  Abstract

     This document specifies Pilot Protocol, an overlay network that
     provides autonomous AI agents with virtual addresses, port-based
     service multiplexing, reliable and unreliable transport, NAT
     traversal, encrypted tunnels, and a bilateral trust model.  Pilot
     Protocol operates as a network and transport layer beneath
     application-layer agent protocols such as A2A and MCP.  It
     encapsulates virtual packets in UDP datagrams for transit over the
     existing Internet.  The protocol gives agents first-class network
     citizenship --- stable identities, reachable addresses, and standard
     transport primitives --- independent of their underlying network
     infrastructure.

  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 8 October 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.







  Teodor                   Expires 8 October 2026                 [Page 1]


  Internet-Draft               Pilot Protocol                   April 2026


     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.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   5
       1.2.  Relationship to Existing Protocols  . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Protocol Stack  . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Component Roles . . . . . . . . . . . . . . . . . . . . .   7
     4.  Addressing  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Virtual Address Format  . . . . . . . . . . . . . . . . .   8
       4.2.  Text Representation . . . . . . . . . . . . . . . . . . .   8
       4.3.  Socket Addresses  . . . . . . . . . . . . . . . . . . . .   8
       4.4.  Special Addresses . . . . . . . . . . . . . . . . . . . .   9
     5.  Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Port Ranges . . . . . . . . . . . . . . . . . . . . . . .   9
       5.2.  Well-Known Ports  . . . . . . . . . . . . . . . . . . . .   9
     6.  Packet Format . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Header Layout . . . . . . . . . . . . . . . . . . . . . .  10
       6.2.  Field Definitions . . . . . . . . . . . . . . . . . . . .  11
       6.3.  Protocol Types  . . . . . . . . . . . . . . . . . . . . .  12
       6.4.  Flag Definitions  . . . . . . . . . . . . . . . . . . . .  12
       6.5.  Checksum Calculation  . . . . . . . . . . . . . . . . . .  12
     7.  Tunnel Encapsulation  . . . . . . . . . . . . . . . . . . . .  13
       7.1.  Plaintext Frame (PILT)  . . . . . . . . . . . . . . . . .  13
       7.2.  Encrypted Frame (PILS)  . . . . . . . . . . . . . . . . .  13
       7.3.  Key Exchange Frame (PILK) . . . . . . . . . . . . . . . .  13
       7.4.  Authenticated Key Exchange Frame (PILA) . . . . . . . . .  14
       7.5.  NAT Punch Frame (PILP)  . . . . . . . . . . . . . . . . .  14
     8.  Session Layer . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Connection State Machine  . . . . . . . . . . . . . . . .  15
       8.2.  Three-Way Handshake . . . . . . . . . . . . . . . . . . .  15
       8.3.  Connection Teardown . . . . . . . . . . . . . . . . . . .  16
       8.4.  Sequence Number Arithmetic  . . . . . . . . . . . . . . .  16
       8.5.  Reliable Delivery . . . . . . . . . . . . . . . . . . . .  16
         8.5.1.  Retransmission Timeout (RTO)  . . . . . . . . . . . .  17
         8.5.2.  Out-of-Order Handling . . . . . . . . . . . . . . . .  17
       8.6.  Selective Acknowledgment (SACK) . . . . . . . . . . . . .  17
       8.7.  Congestion Control  . . . . . . . . . . . . . . . . . . .  17
       8.8.  Flow Control  . . . . . . . . . . . . . . . . . . . . . .  18
         8.8.1.  Zero-Window Probing . . . . . . . . . . . . . . . . .  18
       8.9.  Write Coalescing (Nagle's Algorithm)  . . . . . . . . . .  18



  Teodor                   Expires 8 October 2026                 [Page 2]


  Internet-Draft               Pilot Protocol                   April 2026


       8.10. Automatic Segmentation  . . . . . . . . . . . . . . . . .  18
       8.11. Delayed ACKs  . . . . . . . . . . . . . . . . . . . . . .  19
       8.12. Keepalive and Idle Timeout  . . . . . . . . . . . . . . .  19
       8.13. TIME_WAIT . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.  NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . .  19
       9.1.  STUN-Based Endpoint Discovery . . . . . . . . . . . . . .  19
       9.2.  Hole Punching . . . . . . . . . . . . . . . . . . . . . .  19
       9.3.  Relay Fallback  . . . . . . . . . . . . . . . . . . . . .  20
       9.4.  Connection Establishment Strategy . . . . . . . . . . . .  20
     10. Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       10.1.  Identity . . . . . . . . . . . . . . . . . . . . . . . .  21
       10.2.  Tunnel-Layer Encryption  . . . . . . . . . . . . . . . .  21
       10.3.  HKDF Key Derivation  . . . . . . . . . . . . . . . . . .  21
       10.4.  Authenticated Key Exchange Upgrade . . . . . . . . . . .  22
       10.5.  Application-Layer Encryption (Port 443)  . . . . . . . .  22
       10.6.  Trust Handshake Protocol (Port 444)  . . . . . . . . . .  22
       10.7.  Privacy Model  . . . . . . . . . . . . . . . . . . . . .  23
       10.8.  Rate Limiting  . . . . . . . . . . . . . . . . . . . . .  23
       10.9.  IPC Security . . . . . . . . . . . . . . . . . . . . . .  23
     11. Nonce Management  . . . . . . . . . . . . . . . . . . . . . .  24
       11.1.  Construction . . . . . . . . . . . . . . . . . . . . . .  24
       11.2.  Session Lifecycle  . . . . . . . . . . . . . . . . . . .  24
       11.3.  Counter Exhaustion . . . . . . . . . . . . . . . . . . .  24
       11.4.  Application-Layer Nonces (Port 443)  . . . . . . . . . .  24
     12. Version Negotiation . . . . . . . . . . . . . . . . . . . . .  25
       12.1.  Version Field  . . . . . . . . . . . . . . . . . . . . .  25
       12.2.  Handling Mismatches  . . . . . . . . . . . . . . . . . .  25
       12.3.  Future Extensibility . . . . . . . . . . . . . . . . . .  25
     13. Path MTU Considerations . . . . . . . . . . . . . . . . . . .  25
       13.1.  Encapsulation Overhead . . . . . . . . . . . . . . . . .  25
       13.2.  Effective Payload  . . . . . . . . . . . . . . . . . . .  26
       13.3.  MSS Selection  . . . . . . . . . . . . . . . . . . . . .  26
     14. Built-in Services . . . . . . . . . . . . . . . . . . . . . .  27
       14.1.  Echo (Port 7)  . . . . . . . . . . . . . . . . . . . . .  27
       14.2.  Data Exchange (Port 1001)  . . . . . . . . . . . . . . .  27
       14.3.  Event Stream (Port 1002) . . . . . . . . . . . . . . . .  27
       14.4.  Task Submission (Port 1003)  . . . . . . . . . . . . . .  28
     15. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . .  28
       15.1.  Address Mapping  . . . . . . . . . . . . . . . . . . . .  28
       15.2.  Proxying . . . . . . . . . . . . . . . . . . . . . . . .  28
     16. IPC Protocol  . . . . . . . . . . . . . . . . . . . . . . . .  28
       16.1.  Framing  . . . . . . . . . . . . . . . . . . . . . . . .  28
       16.2.  Command Set  . . . . . . . . . . . . . . . . . . . . . .  29
       16.3.  Network Sub-Commands . . . . . . . . . . . . . . . . . .  31
     17. Registry Replication  . . . . . . . . . . . . . . . . . . . .  31
       17.1.  Hot-Standby Architecture . . . . . . . . . . . . . . . .  31
       17.2.  Push-Based Replication . . . . . . . . . . . . . . . . .  32
       17.3.  Liveness and Failover  . . . . . . . . . . . . . . . . .  32



  Teodor                   Expires 8 October 2026                 [Page 3]


  Internet-Draft               Pilot Protocol                   April 2026


     18. Enterprise Extensions . . . . . . . . . . . . . . . . . . . .  32
       18.1.  Role-Based Access Control  . . . . . . . . . . . . . . .  32
       18.2.  Network Policies . . . . . . . . . . . . . . . . . . . .  32
       18.3.  Audit Trail  . . . . . . . . . . . . . . . . . . . . . .  33
       18.4.  Identity Integration . . . . . . . . . . . . . . . . . .  33
     19. Security Considerations . . . . . . . . . . . . . . . . . . .  34
       19.1.  CRC32 Limitations  . . . . . . . . . . . . . . . . . . .  34
       19.2.  Anonymous Key Exchange . . . . . . . . . . . . . . . . .  34
       19.3.  Registry Authentication  . . . . . . . . . . . . . . . .  34
       19.4.  TLS Certificate Pinning  . . . . . . . . . . . . . . . .  35
       19.5.  Registry as Trusted Third Party  . . . . . . . . . . . .  35
       19.6.  GCM Nonce Uniqueness . . . . . . . . . . . . . . . . . .  35
       19.7.  Metadata Exposure  . . . . . . . . . . . . . . . . . . .  36
       19.8.  Double Congestion Control  . . . . . . . . . . . . . . .  36
       19.9.  Replay Protection  . . . . . . . . . . . . . . . . . . .  36
       19.10. IPC as Trust Boundary  . . . . . . . . . . . . . . . . .  36
     20. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
       20.1.  Pilot Protocol Tunnel Magic Values . . . . . . . . . . .  37
       20.2.  Pilot Protocol Type Values . . . . . . . . . . . . . . .  37
       20.3.  Pilot Protocol Well-Known Ports  . . . . . . . . . . . .  37
     21. Implementation Status . . . . . . . . . . . . . . . . . . . .  38
       21.1.  Go Reference Implementation  . . . . . . . . . . . . . .  38
       21.2.  Python SDK . . . . . . . . . . . . . . . . . . . . . . .  39
       21.3.  Node.js SDK  . . . . . . . . . . . . . . . . . . . . . .  39
     22. References  . . . . . . . . . . . . . . . . . . . . . . . . .  39
       22.1.  Normative References . . . . . . . . . . . . . . . . . .  40
       22.2.  Informative References . . . . . . . . . . . . . . . . .  41
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  42
     Appendix B.  Wire Examples  . . . . . . . . . . . . . . . . . . .  42
       B.1.  SYN Packet  . . . . . . . . . . . . . . . . . . . . . . .  42
       B.2.  Data Packet . . . . . . . . . . . . . . . . . . . . . . .  42
       B.3.  Encrypted Tunnel Frame  . . . . . . . . . . . . . . . . .  43
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  43

  1.  Introduction

     AI agents are autonomous software entities that reason, plan, and
     execute tasks.  As agents become more prevalent, they need to
     communicate with each other across heterogeneous network
     environments: cloud, edge, behind NAT, and across organizational
     boundaries.  Current agent protocols (MCP, A2A) operate at the
     application layer over HTTP, assuming agents have stable, reachable
     endpoints.  This assumption fails for a large class of deployments.








  Teodor                   Expires 8 October 2026                 [Page 4]


  Internet-Draft               Pilot Protocol                   April 2026


     Pilot Protocol is an overlay network stack that gives agents network-
     layer primitives: virtual addresses, ports, reliable streams,
     unreliable datagrams, NAT traversal, encrypted tunnels, name
     resolution, and a bilateral trust model.  It is positioned as the
     network/transport layer beneath application-layer agent protocols ---
     analogous to how TCP/IP sits beneath HTTP.

  1.1.  Design Principles

     The protocol is designed around five principles:

     1.  *Agents are first-class network citizens.* Every agent gets a
         unique virtual address, can bind ports, listen for connections,
         and be reached by any authorized peer.

     2.  *The network boundary is the trust boundary.* Network membership
         serves as the primary access control mechanism.  Joining a
         network requires meeting its rules.

     3.  *Transport agnosticism.* The protocol provides reliable streams
         (TCP-equivalent) and unreliable datagrams (UDP-equivalent).
         Anything that runs on TCP/IP can run on the overlay.

     4.  *Minimize the protocol, maximize the surface.* The protocol
         defines addressing, packets, and transport.  Application-level
         message formats are layers built on top.

     5.  *Practical over pure.* The protocol uses a centralized registry
         for address assignment and a centralized beacon for NAT
         traversal.  Full decentralization is a future goal, not a
         prerequisite.

  1.2.  Relationship to Existing Protocols

     Pilot Protocol operates at the network and transport layers of the
     overlay stack.  It is complementary to, not competitive with,
     application-layer agent protocols:

     *  A2A defines what agents say to each other.  Pilot defines how they
        reach each other.

     *  MCP defines agent-to-tool interfaces.  Pilot provides the
        transport substrate.

     *  QUIC [RFC9000] is a potential underlay transport.  Pilot could run
        over QUIC instead of raw UDP.





  Teodor                   Expires 8 October 2026                 [Page 5]


  Internet-Draft               Pilot Protocol                   April 2026


     *  LISP [RFC9300] provides conceptual precedent for identity/locator
        separation.

     *  VXLAN [RFC7348] and GENEVE [RFC8926] are overlay encapsulation
        precedents at the data link layer.  Pilot operates at the network
        layer.

     *  AGTP [I-D.hood-independent-agtp] and AIP [I-D.prakash-aip] address
        agent transport and identity at the application layer; Pilot
        provides the network substrate beneath them.

     The CATALIST coordination effort
     [I-D.yao-catalist-problem-space-analysis] at IETF 125 surveyed the
     agent protocol landscape and is scoping what IETF should standardize
     in this space.

  2.  Terminology

     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.

     Agent:  An autonomous software entity capable of reasoning, planning,
        and executing tasks without continuous human supervision.

     Daemon:  The local Pilot Protocol process that implements the virtual
        network stack.  It maintains a UDP tunnel, handles routing,
        session management, and encryption.  Analogous to a virtual NIC.

     Driver:  An SDK or library that agents import to communicate with the
        local daemon over IPC.  Provides the application-facing API
        (listen, dial, read, write, close).

     Registry:  A centralized service that assigns virtual addresses,
        maintains the address-to-locator mapping table, manages network
        membership, and stores public keys.

     Beacon:  A service that provides NAT traversal coordination: endpoint
        discovery (STUN-like), hole-punch coordination, and relay
        fallback.

     Virtual Address:  A 48-bit overlay address assigned to an agent,
        independent of its underlying IP address.

     Trust Pair:  A bilateral trust relationship between two agents,
        established through explicit mutual consent.



  Teodor                   Expires 8 October 2026                 [Page 6]


  Internet-Draft               Pilot Protocol                   April 2026


  3.  Architecture Overview

  3.1.  Protocol Stack

     Pilot Protocol is a five-layer overlay stack:

        +=============+==============================================+
        | Layer       | Function                                     |
        +=============+==============================================+
        | Application | HTTP, RPC, custom protocols (above Pilot)    |
        +-------------+----------------------------------------------+
        | Session     | Reliable streams, unreliable datagrams       |
        +-------------+----------------------------------------------+
        | Network     | Virtual addresses, ports, routing            |
        +-------------+----------------------------------------------+
        | Tunnel      | NAT traversal, UDP encapsulation, encryption |
        +-------------+----------------------------------------------+
        | Physical    | Real Internet (IP/TCP/UDP)                   |
        +-------------+----------------------------------------------+

                                   Table 1

     The overlay handles addressing, routing, and session management.  The
     underlying Internet handles physical delivery.

  3.2.  Component Roles

     Registry:  Assigns virtual addresses, maintains address table,
        manages networks and trust pairs, relays handshake requests for
        private nodes.  Runs on TCP.  The only globally reachable
        component.

     Beacon:  Provides STUN-like endpoint discovery, hole-punch
        coordination, and relay fallback for symmetric NAT.  Runs on UDP.

     Daemon:  Core protocol implementation running on each participating
        machine.  Maintains a single UDP socket, multiplexes all virtual
        connections, handles tunnel encryption, and exposes a local IPC
        socket for drivers.

     Driver:  Client SDK that agents import.  Connects to the local daemon
        via Unix domain socket.  Implements standard network interfaces
        (listeners, connections).

     Nameserver:  DNS equivalent for the overlay.  Runs as a service on
        virtual port 53, resolving human-readable names to virtual
        addresses.




  Teodor                   Expires 8 October 2026                 [Page 7]


  Internet-Draft               Pilot Protocol                   April 2026


     Gateway:  Bridge between the overlay and standard IP.  Maps virtual
        addresses to local IPs, allowing unmodified TCP programs to reach
        agents.

  4.  Addressing

  4.1.  Virtual Address Format

     Addresses are 48 bits, split into two fields:

      0                   1                   2
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Network ID (16 bits)     |       Node ID (32 bits) ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~             Node ID (continued)               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Network ID (16 bits):  Identifies the network or topic.  Network 0 is
        the global backbone; all nodes are members by default.  Networks
        1-65534 are created for specific purposes.  Network 65535 is
        reserved.

     Node ID (32 bits):  Identifies the individual agent within a network.
        Supports over 4 billion nodes per network.

  4.2.  Text Representation

     Addresses are written as N:XXXX.YYYY.ZZZZ where:

     *  N is the network ID in decimal

     *  XXXX.YYYY.ZZZZ is the node ID as three groups of 4 hexadecimal
        digits

     Examples:

     *  0:0000.0000.0001 --- Node 1 on the backbone

     *  1:00A3.F291.0004 --- A node on network 1

  4.3.  Socket Addresses

     A socket address appends a port: 1:00A3.F291.0004:1000







  Teodor                   Expires 8 October 2026                 [Page 8]


  Internet-Draft               Pilot Protocol                   April 2026


  4.4.  Special Addresses

                 +==================+========================+
                 | Address          | Meaning                |
                 +==================+========================+
                 | 0:0000.0000.0000 | Unspecified / wildcard |
                 +------------------+------------------------+
                 | 0:0000.0000.0001 | Registry               |
                 +------------------+------------------------+
                 | 0:0000.0000.0002 | Beacon                 |
                 +------------------+------------------------+
                 | 0:0000.0000.0003 | Nameserver             |
                 +------------------+------------------------+
                 | X:FFFF.FFFF.FFFF | Broadcast on network X |
                 +------------------+------------------------+

                                    Table 2

  5.  Ports

  5.1.  Port Ranges

     Virtual ports are 16-bit unsigned integers (0-65535):

                    +=============+=======================+
                    | Range       | Purpose               |
                    +=============+=======================+
                    | 0-1023      | Reserved / well-known |
                    +-------------+-----------------------+
                    | 1024-49151  | Registered services   |
                    +-------------+-----------------------+
                    | 49152-65535 | Ephemeral / dynamic   |
                    +-------------+-----------------------+

                                    Table 3

  5.2.  Well-Known Ports

     +======+=================+=========================================+
     | Port | Service         | Description                             |
     +======+=================+=========================================+
     | 0    | Ping            | Liveness checks                         |
     +------+-----------------+-----------------------------------------+
     | 1    | Control         | Daemon-to-daemon control                |
     +------+-----------------+-----------------------------------------+
     | 7    | Echo            | Echo service (testing)                  |
     +------+-----------------+-----------------------------------------+
     | 53   | Name resolution | Nameserver queries                      |



  Teodor                   Expires 8 October 2026                 [Page 9]


  Internet-Draft               Pilot Protocol                   April 2026


     +------+-----------------+-----------------------------------------+
     | 80   | Agent HTTP      | Web endpoints                           |
     +------+-----------------+-----------------------------------------+
     | 443  | Secure channel  | X25519 + AES-256-GCM                    |
     +------+-----------------+-----------------------------------------+
     | 444  | Trust handshake | Peer trust negotiation                  |
     +------+-----------------+-----------------------------------------+
     | 1000 | Standard I/O    | Text stream between agents              |
     +------+-----------------+-----------------------------------------+
     | 1001 | Data exchange   | Typed frames (text, binary, JSON, file) |
     +------+-----------------+-----------------------------------------+
     | 1002 | Event stream    | Pub/sub with topic filtering            |
     +------+-----------------+-----------------------------------------+
     | 1003 | Task submission | Task lifecycle and reputation scoring   |
     +------+-----------------+-----------------------------------------+

                                   Table 4

  6.  Packet Format

  6.1.  Header Layout

     The fixed packet header is 34 bytes:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Flags |   Protocol    |         Payload Length        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Source Network ID          |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Source Node ID            |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Destination Network ID       |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Destination Node ID         |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Source Port             |     Destination Port          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Sequence Number                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Acknowledgment Number                      |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Window (segments)        |        Checksum (hi)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Checksum (lo)          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




  Teodor                   Expires 8 October 2026                [Page 10]


  Internet-Draft               Pilot Protocol                   April 2026


               Figure 1: Pilot Protocol Packet Header (34 bytes)

     All multi-byte fields are in network byte order (big-endian).

  6.2.  Field Definitions

        +==========+========+========+===============================+
        | Field    | Offset | Size   | Description                   |
        +==========+========+========+===============================+
        | Version  | 0      | 4 bits | Protocol version.  Current: 1 |
        +----------+--------+--------+-------------------------------+
        | Flags    | 0      | 4 bits | SYN (0x1), ACK (0x2), FIN     |
        |          |        |        | (0x4), RST (0x8)              |
        +----------+--------+--------+-------------------------------+
        | Protocol | 1      | 1 byte | Transport type (see           |
        |          |        |        | Section 6.3)                  |
        +----------+--------+--------+-------------------------------+
        | Payload  | 2      | 2      | Payload length in bytes (max  |
        | Length   |        | bytes  | 65535)                        |
        +----------+--------+--------+-------------------------------+
        | Source   | 4      | 2      | Source network ID             |
        | Network  |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Source   | 6      | 4      | Source node ID                |
        | Node     |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Dest     | 10     | 2      | Destination network ID        |
        | Network  |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Dest     | 12     | 4      | Destination node ID           |
        | Node     |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Source   | 16     | 2      | Source port                   |
        | Port     |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Dest     | 18     | 2      | Destination port              |
        | Port     |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Sequence | 20     | 4      | Byte offset of this segment   |
        | Number   |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Ack      | 24     | 4      | Next expected byte from peer  |
        | Number   |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+
        | Window   | 28     | 2      | Advertised receive window in  |
        |          |        | bytes  | segments                      |
        +----------+--------+--------+-------------------------------+
        | Checksum | 30     | 4      | CRC32 over header + payload   |



  Teodor                   Expires 8 October 2026                [Page 11]


  Internet-Draft               Pilot Protocol                   April 2026


        |          |        | bytes  |                               |
        +----------+--------+--------+-------------------------------+

                                   Table 5

  6.3.  Protocol Types

         +=======+==========+=======================================+
         | Value | Name     | Description                           |
         +=======+==========+=======================================+
         | 0x01  | Stream   | Reliable, ordered delivery (TCP-like) |
         +-------+----------+---------------------------------------+
         | 0x02  | Datagram | Unreliable, unordered (UDP-like)      |
         +-------+----------+---------------------------------------+
         | 0x03  | Control  | Internal control messages             |
         +-------+----------+---------------------------------------+

                                   Table 6

  6.4.  Flag Definitions

             +=====+======+=====================================+
             | Bit | Name | Description                         |
             +=====+======+=====================================+
             | 0   | SYN  | Synchronize --- initiate connection |
             +-----+------+-------------------------------------+
             | 1   | ACK  | Acknowledge --- confirm receipt     |
             +-----+------+-------------------------------------+
             | 2   | FIN  | Finish --- close connection         |
             +-----+------+-------------------------------------+
             | 3   | RST  | Reset --- abort connection          |
             +-----+------+-------------------------------------+

                                   Table 7

  6.5.  Checksum Calculation

     The checksum is computed as follows:

     1.  Set the 4-byte checksum field to zero.

     2.  Compute CRC32 (IEEE polynomial) over the entire header (34 bytes
         with zeroed checksum field) concatenated with the payload bytes.

     3.  Write the resulting 32-bit value into the checksum field in big-
         endian byte order.





  Teodor                   Expires 8 October 2026                [Page 12]


  Internet-Draft               Pilot Protocol                   April 2026


     Receivers MUST verify the checksum and discard packets with incorrect
     values.

     Note: CRC32 detects accidental corruption but does not provide
     cryptographic integrity.  Tamper resistance is provided by tunnel-
     layer encryption (Section 7.2).

  7.  Tunnel Encapsulation

     Virtual packets are encapsulated in UDP datagrams for transit over
     the real Internet.  Four frame types are defined, distinguished by a
     4-byte magic value.

  7.1.  Plaintext Frame (PILT)

     +------+------+------+------+---...---+---...---+
     | 0x50 | 0x49 | 0x4C | 0x54 | Header  | Payload |
     +------+------+------+------+---...---+---...---+
         P      I      L      T     34 bytes  variable

     The magic bytes 0x50494C54 ("PILT") indicate an unencrypted Pilot
     Protocol frame.  The header and payload follow immediately.

  7.2.  Encrypted Frame (PILS)

     +------+------+------+------+----------+----------+---...---+
     | 0x50 | 0x49 | 0x4C | 0x53 | SenderID |  Nonce   |Ciphertext
     +------+------+------+------+----------+----------+---...---+
         P      I      L      S    4 bytes    12 bytes   variable

     The magic bytes 0x50494C53 ("PILS") indicate an encrypted frame.

     SenderID:  4-byte Node ID of the sending daemon, in big-endian.  Used
        by the receiver to look up the shared AES-256-GCM key for this
        peer.

     Nonce:  12-byte GCM nonce.  See Section 11 for construction.

     Ciphertext:  The Pilot Protocol header and payload, encrypted with
        AES-256-GCM [RFC5116].  The ciphertext includes a 16-byte
        authentication tag appended by GCM.

     The encryption key is derived from an X25519 [RFC7748] ECDH exchange
     between the two daemons (see Section 7.3), processed through HKDF
     [RFC5869] (see Section 10.3).

  7.3.  Key Exchange Frame (PILK)




  Teodor                   Expires 8 October 2026                [Page 13]


  Internet-Draft               Pilot Protocol                   April 2026


     +------+------+------+------+----------+---...---+
     | 0x50 | 0x49 | 0x4C | 0x4B | SenderID | X25519  |
     +------+------+------+------+----------+---...---+
         P      I      L      K    4 bytes    32 bytes

     Anonymous key exchange.  The sender transmits its ephemeral X25519
     public key (32 bytes, per [RFC7748]).  Both sides compute the ECDH
     shared secret and derive an AES-256-GCM key.

     PILK provides confidentiality but not authentication.  An active
     attacker can perform a man-in-the-middle attack by substituting their
     own public key.  See Section 7.4 for the authenticated variant.

  7.4.  Authenticated Key Exchange Frame (PILA)

    +------+------+------+------+----------+---------+---------+---------+
    | 0x50 | 0x49 | 0x4C | 0x41 | SenderID | X25519  | Ed25519 |  Sig   |
    +------+------+------+------+----------+---------+---------+---------+
        P      I      L      A    4 bytes   32 bytes  32 bytes  64 bytes

     Authenticated key exchange.  In addition to the X25519 public key,
     the sender includes its Ed25519 public key (32 bytes, per [RFC8032])
     and a 64-byte Ed25519 signature.

     The signature covers the concatenation of:

     1.  The ASCII string "auth" (4 bytes)

     2.  The sender's Node ID (4 bytes, big-endian)

     3.  The X25519 public key (32 bytes)

     The receiver verifies the signature using the sender's Ed25519 public
     key, which it obtains from the registry and cross-checks against the
     claimed Node ID.  This binds the ephemeral X25519 key to the sender's
     persistent identity, preventing man-in-the-middle attacks.

     Daemons with persistent Ed25519 identities SHOULD use PILA.  Daemons
     without persistent identities fall back to PILK.

  7.5.  NAT Punch Frame (PILP)

     +------+------+------+------+----------+
     | 0x50 | 0x49 | 0x4C | 0x50 | SenderID |
     +------+------+------+------+----------+
         P      I      L      P    4 bytes

     The magic bytes 0x50494C50 ("PILP") indicate a NAT punch frame.



  Teodor                   Expires 8 October 2026                [Page 14]


  Internet-Draft               Pilot Protocol                   April 2026


     SenderID:  4-byte Node ID of the sending daemon, in big-endian.

     The PILP frame carries no overlay payload.  Its sole purpose is to
     create a NAT mapping by sending a UDP packet to the peer's observed
     endpoint during hole-punch coordination (Section 9.2).  Receivers
     silently discard PILP frames after recording the sender's source
     address for subsequent direct communication.

  8.  Session Layer

  8.1.  Connection State Machine

                              Dial()
         CLOSED -----------> SYN_SENT
           ^                    |
           |               SYN-ACK recv
           |                    |
           |                    v
           |              ESTABLISHED <--- Listen() + SYN recv
           |                    |
           |               Close()
           |                    |
           |                    v
           |               FIN_WAIT
           |                    |
           |                ACK recv
           |                    |
           |                    v
           |               TIME_WAIT
           |                    |
           |               10s timeout
           |                    |
           +--------------------+

                       Figure 2: Connection State Machine

  8.2.  Three-Way Handshake

     Connection establishment uses a three-way handshake:












  Teodor                   Expires 8 October 2026                [Page 15]


  Internet-Draft               Pilot Protocol                   April 2026


     Initiator                          Responder
         |                                  |
         |-------- SYN seq=X ------------->|
         |                                  |
         |<--- SYN+ACK seq=Y ack=X+1 -----|
         |                                  |
         |-------- ACK ack=Y+1 ----------->|
         |                                  |
         |       ESTABLISHED                |       ESTABLISHED

     The initiator selects an initial sequence number X.  The responder
     selects its own initial sequence number Y and acknowledges X+1.  The
     initiator confirms by acknowledging Y+1.

     Both sides include their advertised receive window in the Window
     field of the SYN and SYN-ACK packets.

  8.3.  Connection Teardown

     Closer                             Remote
         |                                  |
         |-------- FIN seq=N ------------->|
         |                                  |
         |<------- ACK ack=N+1 -----------|
         |                                  |
         |       TIME_WAIT (10s)            |       CLOSED
         |                                  |
         |       CLOSED                     |

     The closer sends FIN, waits for ACK, and enters TIME_WAIT for 10
     seconds.  The 10-second TIME_WAIT is shorter than TCP's typical 2*MSL
     because overlay RTTs are bounded by the underlay network.

  8.4.  Sequence Number Arithmetic

     Sequence numbers are 32-bit unsigned integers with wrapping
     comparison per [RFC1982]:

     seqAfter(a, b) = int32(a - b) > 0

     This correctly handles wraparound at 2^32.

  8.5.  Reliable Delivery

     The Stream protocol (0x01) provides reliable, ordered byte stream
     delivery using a sliding window mechanism.





  Teodor                   Expires 8 October 2026                [Page 16]


  Internet-Draft               Pilot Protocol                   April 2026


  8.5.1.  Retransmission Timeout (RTO)

     RTO is computed per [RFC6298]:

     *  SRTT (Smoothed RTT): updated with alpha = 1/8

     *  RTTVAR (RTT Variance): updated with beta = 1/4

     *  RTO = SRTT + max(G, 4 * RTTVAR)

     *  G (clock granularity floor) = 10 ms

     *  RTO is clamped to the range 200 ms to 10 s

     SYN packets are retransmitted with exponential backoff: 1s, 2s, 4s,
     8s, up to 5 retries.  Data segments allow up to 8 retransmission
     attempts before the connection is closed.

  8.5.2.  Out-of-Order Handling

     Segments received out of order are buffered and delivered to the
     application in sequence order when gaps are filled.

  8.6.  Selective Acknowledgment (SACK)

     When the receiver has out-of-order segments, it encodes SACK blocks
     in the ACK payload.  Each SACK block is a pair of 32-bit sequence
     numbers representing a contiguous range of received bytes beyond the
     cumulative ACK point.  Up to 4 SACK blocks are encoded per ACK.

     The sender uses SACK information to retransmit only the missing
     segments, skipping segments the peer has already received.

  8.7.  Congestion Control

     The protocol implements TCP-style congestion control:

     Slow Start:  The congestion window (cwnd) starts at 10 segments (40
        KB) per [RFC6928] and grows by one segment for each ACK received,
        until cwnd reaches the slow-start threshold (ssthresh).

     Congestion Avoidance:  After cwnd reaches ssthresh, growth switches
        to additive-increase: cwnd grows by approximately one segment per
        round-trip time (Appropriate Byte Counting per [RFC3465]).

     Fast Retransmit:  After 3 duplicate pure ACKs (data packets with
        piggybacked ACKs are excluded per [RFC5681] Section 3.2), the
        sender retransmits the missing segment without waiting for RTO.



  Teodor                   Expires 8 October 2026                [Page 17]


  Internet-Draft               Pilot Protocol                   April 2026


     Multiplicative Decrease:  On loss detection (fast retransmit or RTO),
        ssthresh is set to max(cwnd/2, 2 segments).  On RTO, cwnd is
        additionally reset to 1 segment (Tahoe behavior).

     The maximum congestion window is 1 MB.  The maximum segment size
     (MSS) is 4096 bytes.

  8.8.  Flow Control

     Each ACK carries the receiver's advertised window --- the number of
     free segments in its receive buffer.  The sender's effective window
     is:

     effective_window = min(cwnd, peer_advertised_window)

     This prevents a fast sender from overwhelming a slow receiver.

  8.8.1.  Zero-Window Probing

     When the receiver advertises a zero window, the sender enters persist
     mode and sends 1-byte probe segments at exponentially increasing
     intervals until the receiver opens its window.

  8.9.  Write Coalescing (Nagle's Algorithm)

     Small writes are buffered when unacknowledged data is in flight and
     flushed when:

     *  The buffer reaches MSS (4096 bytes), or

     *  All previous data is acknowledged, or

     *  A 40 ms timeout expires.

     This reduces packet overhead for applications performing many small
     writes.  The algorithm can be disabled per-connection with a NoDelay
     option, analogous to TCP_NODELAY.

  8.10.  Automatic Segmentation

     Large writes are automatically segmented into MSS-sized chunks (4096
     bytes) by the daemon.  Applications can write arbitrarily large
     buffers without manual chunking.








  Teodor                   Expires 8 October 2026                [Page 18]


  Internet-Draft               Pilot Protocol                   April 2026


  8.11.  Delayed ACKs

     Instead of sending an ACK for every received segment, the daemon
     batches up to 2 segments or 40 ms (whichever comes first).  When out-
     of-order data is present, ACKs are sent immediately with SACK blocks
     to trigger fast retransmit.  When data is sent on a connection, the
     pending delayed ACK is cancelled because the outgoing data packet
     piggybacks the latest cumulative ACK and receive window.

  8.12.  Keepalive and Idle Timeout

     Keepalive probes (empty ACKs) are sent every 30 seconds to idle
     connections.  Connections idle for 120 seconds are automatically
     closed.  These timers are appropriate for the overlay's use case
     (agent communication), where stale connections should be reclaimed
     promptly.

  8.13.  TIME_WAIT

     Closed connections enter TIME_WAIT for 10 seconds before being
     removed.  During TIME_WAIT, the connection occupies its port binding
     (preventing reuse confusion with delayed packets) but does not count
     as active.

  9.  NAT Traversal

  9.1.  STUN-Based Endpoint Discovery

     On startup, the daemon sends a UDP probe to the beacon.  The beacon
     observes the daemon's public IP address and port (as mapped by NAT)
     and reports it back.  This follows the mechanism described in
     [RFC8489] (Session Traversal Utilities for NAT).

     The discovered public endpoint is registered with the registry as the
     daemon's locator.

     For daemons with known public endpoints (e.g., cloud VMs), the
     -endpoint host:port flag skips STUN and registers the specified
     endpoint directly.

  9.2.  Hole Punching

     When daemon A wants to reach daemon B and both are behind NAT:

     1.  Daemon A sends a punch request to the beacon, specifying B's Node
         ID.





  Teodor                   Expires 8 October 2026                [Page 19]


  Internet-Draft               Pilot Protocol                   April 2026


     2.  The beacon looks up B's registered endpoint and sends a punch
         command to both A and B, instructing each to send a UDP packet to
         the other's observed endpoint.

     3.  Both daemons send UDP packets to each other simultaneously,
         punching holes in their respective NATs.

     4.  Subsequent packets flow directly between A and B.

     This works for Full Cone, Restricted Cone, and Port-Restricted Cone
     NAT types.

  9.3.  Relay Fallback

     When hole punching fails (typically Symmetric NAT, where the mapped
     port changes per destination), the beacon provides transparent relay:

     +----------+         +----------+         +----------+
     | Daemon A | ------> |  Beacon  | ------> | Daemon B |
     +----------+  relay  +----------+  relay  +----------+

     The relay frame format:

     +------+----------+----------+---...---+
     | 0x05 | SenderID |  DestID  | Payload |
     +------+----------+----------+---...---+
     1 byte   4 bytes    4 bytes   variable

     The beacon unwraps the relay header and forwards the payload to the
     destination daemon.  Relay is transparent to the session layer ---
     the virtual packet inside the relay frame is identical to a directly-
     delivered packet.

  9.4.  Connection Establishment Strategy

     When dialing a remote daemon, the connection strategy is:

     1.  Attempt 3 direct UDP sends to the peer's registered endpoint.

     2.  If all 3 fail, switch to relay mode through the beacon.

     3.  Attempt 3 relay sends.

     4.  If all relay attempts fail, return an error to the application.

     The switch from direct to relay is automatic and transparent to the
     application layer.




  Teodor                   Expires 8 October 2026                [Page 20]


  Internet-Draft               Pilot Protocol                   April 2026


  10.  Security

  10.1.  Identity

     Each node receives an Ed25519 [RFC8032] keypair from the registry
     upon registration.  The private key serves as the node's identity
     credential.  The registry holds all public keys and can verify
     signatures.

     Identities may be persisted to disk so that a node retains its
     keypair and virtual address across restarts.  On restart with a
     persisted identity, the daemon re-registers with the stored public
     key and the registry restores the node's address and memberships.

  10.2.  Tunnel-Layer Encryption

     Tunnel encryption is enabled by default.  On startup, each daemon
     generates an ephemeral X25519 [RFC7748] keypair.  When two daemons
     first communicate, they exchange public keys via PILK (Section 7.3)
     or PILA (Section 7.4) frames, compute an ECDH shared secret, and
     derive an AES-256-GCM [RFC5116] key via HKDF (Section 10.3).

     All subsequent packets between the pair are encrypted (PILS frames),
     regardless of virtual port.  The encryption is at the tunnel layer
     --- it protects all overlay traffic between two daemons, including
     connection handshakes.

     The sender's Node ID (4 bytes, big-endian) is used as GCM Additional
     Authenticated Data (AAD).  This binds the ciphertext to the sender's
     identity --- a decryption attempt with an incorrect sender ID will
     fail GCM authentication, preventing packet reattribution attacks.

     Tunnel encryption is backward-compatible: if a peer does not respond
     to key exchange, communication falls back to plaintext (PILT frames).

  10.3.  HKDF Key Derivation

     The shared secret from the X25519 ECDH exchange is processed through
     HKDF [RFC5869] to produce the AES-256-GCM key:

     Extract:  PRK = HMAC-SHA256(salt=empty, IKM=shared_secret)
     Expand:   key = HMAC-SHA256(PRK, info || 0x01)

     For tunnel encryption, info is the ASCII string "pilot-tunnel-v1" (15
     bytes).  For application-layer encryption on port 443 (Section 10.5),
     info is the ASCII string "pilot-secure-v1" (15 bytes).





  Teodor                   Expires 8 October 2026                [Page 21]


  Internet-Draft               Pilot Protocol                   April 2026


     After the AES-256-GCM cipher is established, implementations MUST
     zero the shared secret, PRK, and derived key material in memory to
     limit the window of exposure if process memory is compromised.

  10.4.  Authenticated Key Exchange Upgrade

     When a daemon has a persisted Ed25519 identity, the key exchange is
     upgraded from PILK to PILA (see Section 7.4).  The Ed25519 signature
     binds the ephemeral X25519 key to the node's persistent identity,
     preventing man-in-the-middle attacks.

     Implementations SHOULD use PILA when an Ed25519 identity is
     available.

  10.5.  Application-Layer Encryption (Port 443)

     Virtual port 443 provides end-to-end encryption between two agents,
     on top of any tunnel-layer encryption.  The agents perform an X25519
     ECDH handshake and derive a shared key via HKDF [RFC5869] with info
     string "pilot-secure-v1", then use AES-256-GCM for all subsequent
     data.

     Each encrypted frame:

     [4-byte length][12-byte nonce][ciphertext + 16-byte GCM tag]

     The sender's nonce prefix (first 4 bytes of the nonce, see
     Section 11.4) is used as GCM Additional Authenticated Data (AAD).
     This binds ciphertext to the sender's role (server or client),
     preventing cross-role confusion attacks.

     This provides defense in depth: even if the tunnel encryption is
     compromised (e.g., by a compromised intermediate daemon in a future
     multi-hop topology), port 443 data remains protected.

  10.6.  Trust Handshake Protocol (Port 444)

     Port 444 implements a bilateral trust negotiation protocol.  Two
     agents exchange trust requests with justification strings and must
     both approve before a trust relationship is established.

     Three auto-approval paths exist:

     1.  *Mutual handshake*: If both agents independently request trust
         with each other, the relationship is auto-approved.






  Teodor                   Expires 8 October 2026                [Page 22]


  Internet-Draft               Pilot Protocol                   April 2026


     2.  *Network trust*: If both agents share a non-backbone network, the
         relationship is auto-approved (network membership serves as a
         trust signal).

     3.  *Manual approval*: If neither condition is met, the request is
         queued for the receiving agent's operator to approve or reject.

     Trust pairs are recorded in the registry and persist across restarts.
     Trust is revocable: revoking trust immediately prevents further
     communication.

     When trust handshake messages are relayed through the registry (for
     private nodes that cannot be reached directly), the sender MUST
     include an Ed25519 [RFC8032] signature over the concatenation of the
     ASCII string "handshake:", the sender's Node ID (decimal), ":", and
     the peer's Node ID (decimal).  The receiver verifies the signature
     against the sender's public key as registered in the registry.  This
     prevents handshake message forgery by a compromised relay path.

  10.7.  Privacy Model

     Agents are private by default:

     *  A node's physical IP:port is never disclosed in registry responses
        unless the node has explicitly opted into public visibility.

     *  Resolving a private node's endpoint requires one of: (a) the node
        is public, (b) a mutual trust pair exists, or (c) both nodes share
        a non-backbone network.

     *  Listing nodes on the backbone (network 0) is rejected by the
        registry.  Non-backbone networks allow listing since membership is
        the trust boundary.

  10.8.  Rate Limiting

     The registry enforces per-connection sliding window rate limits using
     a token-bucket algorithm with per-source tracking.  Clients that
     exceed the limit receive throttle responses.

     Daemons implement SYN rate limiting to mitigate connection flood
     attacks.

  10.9.  IPC Security

     The daemon's Unix domain socket is created with mode 0600,
     restricting access to the socket owner.  This prevents unprivileged
     processes on the same machine from issuing commands to the daemon.



  Teodor                   Expires 8 October 2026                [Page 23]


  Internet-Draft               Pilot Protocol                   April 2026


  11.  Nonce Management

  11.1.  Construction

     AES-256-GCM nonces are 96 bits (12 bytes), constructed as:

     +---...---+---...---+
     |  Prefix | Counter |
     +---...---+---...---+
      4 bytes    8 bytes

     Prefix:  4 bytes generated from a cryptographically secure random
        source when the tunnel session is established.  Unique per session
        with overwhelming probability.

     Counter:  8-byte unsigned integer, starting at 0, incremented by 1
        for each packet encrypted.  The counter MUST NOT be reset within a
        session.

  11.2.  Session Lifecycle

     A new tunnel session is established when two daemons perform an
     X25519 key exchange (PILK or PILA).  Each session produces:

     *  A fresh AES-256-GCM key (from the ECDH shared secret)

     *  A fresh random nonce prefix

     Since each session uses a different key, nonces from different
     sessions cannot collide (different keys are independent encryption
     contexts).

  11.3.  Counter Exhaustion

     The 8-byte counter supports 2^64 encryptions per session.
     Implementations MUST re-key (initiate a new key exchange) before the
     counter reaches 2^64 - 1.  In practice, at 1 million packets per
     second, counter exhaustion would take over 584,000 years.

  11.4.  Application-Layer Nonces (Port 443)

     Secure connections on port 443 use a role-prefix nonce scheme:

     +---...---+---...---+
     |  Role   | Counter |
     +---...---+---...---+
      4 bytes    8 bytes




  Teodor                   Expires 8 October 2026                [Page 24]


  Internet-Draft               Pilot Protocol                   April 2026


     Role Prefix:  0x00000001 for the server (listener) side, 0x00000002
        for the client (dialer) side.  Fixed per role for the lifetime of
        the connection.

     Counter:  8-byte unsigned integer, starting at 0, incremented by 1
        for each packet encrypted.

     The role prefix prevents nonce collision between the two sides of a
     connection, even if both encrypt the same number of packets.  Each
     connection has an independent counter and key derived from its own
     X25519 handshake and HKDF expansion.

  12.  Version Negotiation

  12.1.  Version Field

     The 4-bit Version field in the packet header identifies the protocol
     version.  The current version is 1.  Version 0 is reserved and MUST
     NOT be used.

  12.2.  Handling Mismatches

     The initiator includes its protocol version in the SYN packet.  The
     responder checks the version:

     *  If supported: echoes the same version in SYN-ACK.  Both sides use
        this version for the connection's lifetime.

     *  If unsupported: sends RST.  No version downgrade negotiation
        occurs.

     For non-SYN packets, if the Version field does not match the
     connection's established version, the packet is silently discarded.
     Implementations SHOULD log such events at debug level.

  12.3.  Future Extensibility

     Future protocol versions MAY extend the header format.
     Implementations MUST NOT assume a fixed header size based solely on
     the Version field --- they SHOULD use the version to determine the
     expected header layout.

  13.  Path MTU Considerations

  13.1.  Encapsulation Overhead

     The total per-packet overhead for encrypted tunnel frames is:




  Teodor                   Expires 8 October 2026                [Page 25]


  Internet-Draft               Pilot Protocol                   April 2026


                    +========================+============+
                    | Component              | Size       |
                    +========================+============+
                    | PILS magic             | 4 bytes    |
                    +------------------------+------------+
                    | Sender Node ID         | 4 bytes    |
                    +------------------------+------------+
                    | GCM nonce              | 12 bytes   |
                    +------------------------+------------+
                    | Pilot header           | 34 bytes   |
                    +------------------------+------------+
                    | GCM authentication tag | 16 bytes   |
                    +------------------------+------------+
                    | *Total*                | *70 bytes* |
                    +------------------------+------------+

                                    Table 8

     For plaintext frames (PILT), overhead is 38 bytes (4-byte magic +
     34-byte header).

  13.2.  Effective Payload

     With a typical 1500-byte Ethernet MTU, 20-byte IP header, and 8-byte
     UDP header:

     *  Available for Pilot: 1500 - 28 = 1472 bytes

     *  Encrypted payload capacity: 1472 - 70 = 1402 bytes

     *  Plaintext payload capacity: 1472 - 38 = 1434 bytes

  13.3.  MSS Selection

     The default MSS of 4096 bytes exceeds single-packet capacity on
     standard Ethernet paths.  Full-MSS segments will be fragmented into 3
     IP fragments.  This is acceptable on most networks but may fail on
     paths that block IP fragmentation.

     Recommendations:

     *  For Internet-facing deployments where IP fragmentation may be
        blocked, an MSS of 1400 bytes avoids fragmentation on virtually
        all paths.

     *  For datacenter or local deployments (jumbo frames), the default
        4096 MSS is appropriate.




  Teodor                   Expires 8 October 2026                [Page 26]


  Internet-Draft               Pilot Protocol                   April 2026


     *  Implementations SHOULD provide a configurable MSS option.

     *  Implementations SHOULD NOT set the Don't Fragment (DF) bit on UDP
        datagrams, allowing IP-layer fragmentation as a fallback.

  14.  Built-in Services

  14.1.  Echo (Port 7)

     The echo service reflects any data received back to the sender.  It
     is used for liveness testing (ping) and throughput benchmarking.

  14.2.  Data Exchange (Port 1001)

     A typed frame protocol for structured data.  Each frame carries a
     4-byte type tag and a 4-byte length prefix:

                 +========+=======+=========================+
                 | Type   | Value | Description             |
                 +========+=======+=========================+
                 | Text   | 0x01  | UTF-8 text              |
                 +--------+-------+-------------------------+
                 | Binary | 0x02  | Raw bytes               |
                 +--------+-------+-------------------------+
                 | JSON   | 0x03  | JSON document           |
                 +--------+-------+-------------------------+
                 | File   | 0x04  | File with name metadata |
                 +--------+-------+-------------------------+

                                   Table 9

  14.3.  Event Stream (Port 1002)

     A publish/subscribe broker.  Agents subscribe to named topics and
     receive events published by any peer.  Wildcard subscriptions (*)
     match all topics.  The wire protocol uses newline-delimited text
     commands:

     *  SUB <topic> --- subscribe to a topic

     *  PUB <topic> <payload> --- publish an event

     *  EVENT <topic> <payload> --- delivered event (broker to subscriber)








  Teodor                   Expires 8 October 2026                [Page 27]


  Internet-Draft               Pilot Protocol                   April 2026


  14.4.  Task Submission (Port 1003)

     A task lifecycle protocol.  Agents submit tasks with descriptions,
     workers accept or decline, execute, and return results.  A reputation
     score (polo score) adjusts based on execution efficiency.

  15.  Gateway

     The gateway bridges the overlay network and standard IP networks,
     allowing unmodified TCP programs (curl, browsers, databases) to
     communicate with overlay agents.

  15.1.  Address Mapping

     The gateway maps virtual addresses to local IP addresses on the
     loopback interface.  For each mapped agent, the gateway creates a
     loopback alias:

     *  Linux: ip addr add <local-ip>/32 dev lo

     *  macOS: ifconfig lo0 alias <local-ip>

     The default mapping subnet is 10.4.0.0/16.  Each virtual address is
     assigned a unique local IP within this subnet.

  15.2.  Proxying

     For each mapped address, the gateway listens on configurable TCP
     ports (default: 7, 80, 443, 1000, 1001, 1002, 8080, 8443) on the
     local IP.  Incoming TCP connections are forwarded to the
     corresponding agent's virtual address and port via the daemon's Dial
     operation.  Data flows bidirectionally between the TCP connection and
     the overlay stream.

     This enables scenarios such as:

  curl http://10.4.0.1:80/api     # reaches agent 0:0000.0000.0001 port 80

  16.  IPC Protocol

  16.1.  Framing

     The daemon and driver communicate over a Unix domain socket using
     length-prefixed messages:

     [4-byte big-endian length][message bytes]

     Maximum message size: 1,048,576 bytes (1 MB).



  Teodor                   Expires 8 October 2026                [Page 28]


  Internet-Draft               Pilot Protocol                   April 2026


  16.2.  Command Set

     +======+===================+==================+=====================+
     | Cmd  | Name              | Direction        | Description         |
     +======+===================+==================+=====================+
     | 0x01 | Bind              | Driver -> Daemon | Bind a virtual      |
     |      |                   |                  | port                |
     +------+-------------------+------------------+---------------------+
     | 0x02 | BindOK            | Daemon -> Driver | Confirm port        |
     |      |                   |                  | binding             |
     +------+-------------------+------------------+---------------------+
     | 0x03 | Dial              | Driver -> Daemon | Connect to          |
     |      |                   |                  | remote agent        |
     +------+-------------------+------------------+---------------------+
     | 0x04 | DialOK            | Daemon -> Driver | Connection          |
     |      |                   |                  | established         |
     +------+-------------------+------------------+---------------------+
     | 0x05 | Accept            | Daemon -> Driver | Incoming            |
     |      |                   |                  | connection          |
     +------+-------------------+------------------+---------------------+
     | 0x06 | Send              | Driver -> Daemon | Send data on        |
     |      |                   |                  | connection          |
     +------+-------------------+------------------+---------------------+
     | 0x07 | Recv              | Daemon -> Driver | Receive data        |
     +------+-------------------+------------------+---------------------+
     | 0x08 | Close             | Driver -> Daemon | Close connection    |
     +------+-------------------+------------------+---------------------+
     | 0x09 | CloseOK           | Daemon -> Driver | Connection          |
     |      |                   |                  | closed              |
     +------+-------------------+------------------+---------------------+
     | 0x0A | Error             | Daemon -> Driver | Error response      |
     +------+-------------------+------------------+---------------------+
     | 0x0B | SendTo            | Driver -> Daemon | Send datagram       |
     +------+-------------------+------------------+---------------------+
     | 0x0C | RecvFrom          | Daemon -> Driver | Receive datagram    |
     +------+-------------------+------------------+---------------------+
     | 0x0D | Info              | Driver -> Daemon | Query daemon        |
     |      |                   |                  | status              |
     +------+-------------------+------------------+---------------------+
     | 0x0E | InfoOK            | Daemon -> Driver | Status response     |
     |      |                   |                  | (JSON)              |
     +------+-------------------+------------------+---------------------+
     | 0x0F | Handshake         | Driver -> Daemon | Trust handshake     |
     |      |                   |                  | command             |
     +------+-------------------+------------------+---------------------+
     | 0x10 | HandshakeOK       | Daemon -> Driver | Handshake result    |
     |      |                   |                  | (JSON)              |
     +------+-------------------+------------------+---------------------+



  Teodor                   Expires 8 October 2026                [Page 29]


  Internet-Draft               Pilot Protocol                   April 2026


     | 0x11 | ResolveHostname   | Driver -> Daemon | Resolve hostname    |
     |      |                   |                  | to address          |
     +------+-------------------+------------------+---------------------+
     | 0x12 | ResolveHostnameOK | Daemon -> Driver | Resolution          |
     |      |                   |                  | result (JSON)       |
     +------+-------------------+------------------+---------------------+
     | 0x13 | SetHostname       | Driver -> Daemon | Set discoverable    |
     |      |                   |                  | hostname            |
     +------+-------------------+------------------+---------------------+
     | 0x14 | SetHostnameOK     | Daemon -> Driver | Hostname            |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x15 | SetVisibility     | Driver -> Daemon | Set public/         |
     |      |                   |                  | private             |
     +------+-------------------+------------------+---------------------+
     | 0x16 | SetVisibilityOK   | Daemon -> Driver | Visibility          |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x17 | Deregister        | Driver -> Daemon | Deregister from     |
     |      |                   |                  | registry            |
     +------+-------------------+------------------+---------------------+
     | 0x18 | DeregisterOK      | Daemon -> Driver | Deregister          |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x19 | SetTags           | Driver -> Daemon | Set node tags       |
     |      |                   |                  | (JSON)              |
     +------+-------------------+------------------+---------------------+
     | 0x1A | SetTagsOK         | Daemon -> Driver | Tags                |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x1B | SetWebhook        | Driver -> Daemon | Set event           |
     |      |                   |                  | webhook URL         |
     +------+-------------------+------------------+---------------------+
     | 0x1C | SetWebhookOK      | Daemon -> Driver | Webhook             |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x1D | SetTaskExec       | Driver -> Daemon | Enable/disable      |
     |      |                   |                  | task exec           |
     +------+-------------------+------------------+---------------------+
     | 0x1E | SetTaskExecOK     | Daemon -> Driver | Task exec           |
     |      |                   |                  | confirmation        |
     +------+-------------------+------------------+---------------------+
     | 0x1F | Network           | Driver -> Daemon | Network             |
     |      |                   |                  | management          |
     +------+-------------------+------------------+---------------------+
     | 0x20 | NetworkOK         | Daemon -> Driver | Network result      |
     |      |                   |                  | (JSON)              |
     +------+-------------------+------------------+---------------------+



  Teodor                   Expires 8 October 2026                [Page 30]


  Internet-Draft               Pilot Protocol                   April 2026


     | 0x21 | Health            | Driver -> Daemon | Health check        |
     |      |                   |                  | probe               |
     +------+-------------------+------------------+---------------------+
     | 0x22 | HealthOK          | Daemon -> Driver | Health response     |
     |      |                   |                  | (JSON)              |
     +------+-------------------+------------------+---------------------+

                                    Table 10

  16.3.  Network Sub-Commands

     The Network command (0x1F) uses a sub-command byte as the first byte
     of the payload:

     +======+===============+=====================+======================+
     | Sub  | Name          | Payload             | Description          |
     +======+===============+=====================+======================+
     | 0x01 | List          | (empty)             | List joined networks |
     +------+---------------+---------------------+----------------------+
     | 0x02 | Join          | network_id, token   | Join a network       |
     +------+---------------+---------------------+----------------------+
     | 0x03 | Leave         | network_id          | Leave a network      |
     +------+---------------+---------------------+----------------------+
     | 0x04 | Members       | network_id          | List network members |
     +------+---------------+---------------------+----------------------+
     | 0x05 | Invite        | network_id,         | Invite a node        |
     |      |               | node_id             |                      |
     +------+---------------+---------------------+----------------------+
     | 0x06 | PollInvites   | (empty)             | Poll pending         |
     |      |               |                     | invitations          |
     +------+---------------+---------------------+----------------------+
     | 0x07 | RespondInvite | network_id,         | Accept/reject invite |
     |      |               | accept              |                      |
     +------+---------------+---------------------+----------------------+

                                    Table 11

  17.  Registry Replication

  17.1.  Hot-Standby Architecture

     The registry supports high-availability through a hot-standby
     replication model.  One registry instance operates as the primary
     (accepting reads and writes) while one or more standbys maintain
     synchronized copies of the state.






  Teodor                   Expires 8 October 2026                [Page 31]


  Internet-Draft               Pilot Protocol                   April 2026


  17.2.  Push-Based Replication

     Standbys connect to the primary via persistent TCP connections and
     subscribe for state updates.  On any mutation (node registration,
     network creation, trust pair change, policy update), the primary
     pushes a full state snapshot to all connected standbys.  The snapshot
     includes nodes, networks, trust pairs, and enterprise state.

  17.3.  Liveness and Failover

     The primary sends heartbeat messages every 15 seconds.  A standby
     that does not receive a heartbeat within 30 seconds considers the
     primary unavailable.  Failover is manual: an operator promotes a
     standby to primary by restarting it in primary mode.

     Standbys reject all write operations, returning an error directing
     the client to the primary.  This prevents split-brain scenarios.

  18.  Enterprise Extensions

  18.1.  Role-Based Access Control

     Networks support three roles:

              +========+========================================+
              | Role   | Permissions                            |
              +========+========================================+
              | Owner  | Full control: delete network, transfer |
              |        | ownership, all admin operations        |
              +--------+----------------------------------------+
              | Admin  | Manage members: invite, kick, promote, |
              |        | demote, set policy                     |
              +--------+----------------------------------------+
              | Member | Participate: send/receive data, list   |
              |        | members                                |
              +--------+----------------------------------------+

                                    Table 12

     Role assignments are stored per-network in the registry.  Operations
     are gated by minimum role requirement --- a member cannot modify
     policy, and an admin cannot delete the network.  The network creator
     is automatically assigned the Owner role.

  18.2.  Network Policies

     Each network may define policies that constrain member behavior:




  Teodor                   Expires 8 October 2026                [Page 32]


  Internet-Draft               Pilot Protocol                   April 2026


     *  *max_members:* Maximum number of nodes in the network.  The
        registry rejects join and invite operations when the limit is
        reached.

     *  *allowed_ports:* Per-network port allow-list (reserved for future
        enforcement at the daemon level).

     Policies persist across registry restarts and are replicated to
     standbys.

  18.3.  Audit Trail

     The registry maintains a ring-buffer audit log recording security-
     relevant operations:

     *  Node registration and deregistration

     *  Trust relationship creation and revocation

     *  Network membership changes (join, leave, kick, invite)

     *  Role assignments (promote, demote, ownership transfer)

     *  Policy modifications

     *  Key rotation and expiry events

     *  Enterprise flag changes

     Each audit entry includes a timestamp, the action identifier, the
     actor's node ID, and for state mutations, both the old and new
     values.  The audit log persists across registry restarts via atomic
     JSON snapshots.

     An export API allows external systems (SIEM, compliance tools) to
     retrieve audit events.  Webhook-based export with retry logic and a
     dead-letter queue ensures reliable delivery to external endpoints.

  18.4.  Identity Integration

     The registry optionally supports external identity integration:

     *  *OIDC/JWT Validation:* Nodes may authenticate using JWT tokens
        from an OIDC provider.  The registry validates RS256 signatures
        using cached JWKS (JSON Web Key Set) endpoints.






  Teodor                   Expires 8 October 2026                [Page 33]


  Internet-Draft               Pilot Protocol                   April 2026


     *  *External Identity Mapping:* Nodes may carry an external_id field
        linking their overlay identity to an OIDC subject or directory
        entry.

     *  *Directory Synchronization:* Webhook-based synchronization with
        external identity providers enables centralized identity
        management.

  19.  Security Considerations

  19.1.  CRC32 Limitations

     The packet checksum uses CRC32 (IEEE polynomial), which detects
     accidental corruption but provides no cryptographic integrity.  An
     attacker who can modify packets in transit can recompute a valid
     CRC32.  Integrity against active attackers is provided by tunnel-
     layer AES-256-GCM encryption, which MUST be used for all Internet-
     facing deployments.

  19.2.  Anonymous Key Exchange

     The PILK key exchange frame provides no identity binding.  An active
     man-in-the-middle attacker can substitute their own X25519 public
     key, establishing separate encrypted sessions with each peer.  The
     PILA authenticated key exchange (Section 7.4) prevents this by
     binding the ephemeral key to an Ed25519 identity.  Implementations
     SHOULD use PILA whenever an Ed25519 identity is available.

  19.3.  Registry Authentication

     Write operations to the registry that modify node state (deregister,
     set visibility, set hostname, set tags, network operations) require
     either:

     *  An Ed25519 [RFC8032] signature from the node's registered keypair,
        or

     *  A valid admin token (verified via constant-time comparison to
        prevent timing attacks).

     Nodes without a registered public key MUST provide a valid admin
     token for any write operation.









  Teodor                   Expires 8 October 2026                [Page 34]


  Internet-Draft               Pilot Protocol                   April 2026


  19.4.  TLS Certificate Pinning

     Clients MAY pin the registry's TLS certificate fingerprint (SHA-256
     hash of the DER-encoded certificate).  When pinning is configured,
     the client performs manual certificate verification via the TLS
     VerifyPeerCertificate callback, rejecting connections whose
     certificate hash does not match the pinned value.  This protects
     against compromised Certificate Authorities.

  19.5.  Registry as Trusted Third Party

     The registry is a centralized trusted third party.  Compromise of the
     registry could allow:

     *  Address hijacking (reassigning a node's virtual address)

     *  Locator spoofing (returning incorrect IP:port for a node)

     *  Public key substitution (enabling identity impersonation)

     *  Metadata harvesting (enumerating registered nodes)

     Mitigations include TLS transport with optional certificate pinning,
     Ed25519 signature verification for node operations, admin token
     authentication for privileged operations, hot-standby replication for
     availability, and persistent audit logging for forensic analysis.
     Future work should explore distributed registry designs with
     consensus-based replication.

  19.6.  GCM Nonce Uniqueness

     AES-256-GCM security depends critically on nonce uniqueness under the
     same key.  The nonce construction (Section 11) guarantees uniqueness
     through a random prefix (unique per session) and a monotonic counter
     (never reset within a session).  Since each key exchange produces a
     new key, nonces from different sessions are in independent
     cryptographic contexts.

     Implementations MUST NOT reuse nonces.  Implementations MUST NOT
     reset the counter within a session.  Implementations MUST re-key
     before counter exhaustion.










  Teodor                   Expires 8 October 2026                [Page 35]


  Internet-Draft               Pilot Protocol                   April 2026


  19.7.  Metadata Exposure

     Even with tunnel encryption (PILS), the sender's Node ID is
     transmitted in cleartext (it is needed for the receiver to look up
     the decryption key).  This allows a passive observer to determine
     which daemons are communicating, though the content and virtual
     addressing within the encrypted payload remain confidential.

  19.8.  Double Congestion Control

     Pilot Protocol implements congestion control at the overlay layer,
     while the underlay UDP-over-IP path may also be subject to network-
     level congestion signals (ICMP source quench, ECN).  The overlay
     congestion control operates independently, which may lead to
     suboptimal behavior on heavily congested paths.  This is a known
     issue shared with all overlay transport protocols.

  19.9.  Replay Protection

     Implementations MUST maintain a sliding-window replay bitmap for each
     peer's tunnel session.  The recommended window size is 256 nonces.
     The replay check operates as follows:

     1.  If the nonce counter is below the window's lower bound (more than
         256 positions behind the highest seen counter), the packet is
         rejected.

     2.  If the nonce counter falls within the window and the
         corresponding bitmap bit is set, the packet is a replay and is
         rejected.

     3.  If the nonce counter is within the window and the bit is not set,
         the bit is set and the packet is accepted.

     4.  If the nonce counter is ahead of the window, the window slides
         forward and the packet is accepted.

     This provides replay protection while tolerating out-of-order packet
     delivery within the window size.

  19.10.  IPC as Trust Boundary

     The Unix domain socket IPC between daemon and driver is a trust
     boundary.  The daemon trusts that any process connecting to the
     socket is authorized (enforced by filesystem permissions, mode 0600).
     If an attacker gains access to the socket, they can impersonate the
     local agent.  Deployments SHOULD ensure the daemon runs under a
     dedicated user account.



  Teodor                   Expires 8 October 2026                [Page 36]


  Internet-Draft               Pilot Protocol                   April 2026


  20.  IANA Considerations

  20.1.  Pilot Protocol Tunnel Magic Values

     This document requests the creation of a "Pilot Protocol Tunnel Magic
     Values" registry with the following initial entries:

           +=======+============+==================================+
           | Magic | Hex        | Description                      |
           +=======+============+==================================+
           | PILT  | 0x50494C54 | Plaintext frame                  |
           +-------+------------+----------------------------------+
           | PILS  | 0x50494C53 | Encrypted frame                  |
           +-------+------------+----------------------------------+
           | PILK  | 0x50494C4B | Key exchange frame               |
           +-------+------------+----------------------------------+
           | PILA  | 0x50494C41 | Authenticated key exchange frame |
           +-------+------------+----------------------------------+
           | PILP  | 0x50494C50 | NAT punch frame                  |
           +-------+------------+----------------------------------+

                                    Table 13

  20.2.  Pilot Protocol Type Values

     This document requests the creation of a "Pilot Protocol Type Values"
     registry with the following initial entries:

             +=======+==========+================================+
             | Value | Name     | Description                    |
             +=======+==========+================================+
             | 0x01  | Stream   | Reliable, ordered delivery     |
             +-------+----------+--------------------------------+
             | 0x02  | Datagram | Unreliable, unordered delivery |
             +-------+----------+--------------------------------+
             | 0x03  | Control  | Internal control messages      |
             +-------+----------+--------------------------------+

                                    Table 14

  20.3.  Pilot Protocol Well-Known Ports

     This document requests the creation of a "Pilot Protocol Well-Known
     Ports" registry with the following initial entries:







  Teodor                   Expires 8 October 2026                [Page 37]


  Internet-Draft               Pilot Protocol                   April 2026


           +======+=================+==============================+
           | Port | Service         | Description                  |
           +======+=================+==============================+
           | 0    | Ping            | Liveness checks              |
           +------+-----------------+------------------------------+
           | 1    | Control         | Daemon-to-daemon control     |
           +------+-----------------+------------------------------+
           | 7    | Echo            | Echo service                 |
           +------+-----------------+------------------------------+
           | 53   | Name Resolution | Nameserver                   |
           +------+-----------------+------------------------------+
           | 80   | Agent HTTP      | Web endpoints                |
           +------+-----------------+------------------------------+
           | 443  | Secure          | End-to-end encrypted channel |
           +------+-----------------+------------------------------+
           | 444  | Trust           | Trust handshake protocol     |
           +------+-----------------+------------------------------+
           | 1000 | StdIO           | Text stream                  |
           +------+-----------------+------------------------------+
           | 1001 | DataExchange    | Typed frame protocol         |
           +------+-----------------+------------------------------+
           | 1002 | EventStream     | Pub/sub broker               |
           +------+-----------------+------------------------------+
           | 1003 | TaskSubmit      | Task lifecycle               |
           +------+-----------------+------------------------------+

                                    Table 15

  21.  Implementation Status

     Per [RFC7942], this section documents the known implementations of
     Pilot Protocol at the time of writing.

  21.1.  Go Reference Implementation

     Organization:  Vulture Labs

     Description:  Complete implementation of Pilot Protocol including
        daemon, driver SDK, registry, beacon, nameserver, gateway, and CLI
        (pilotctl).  Implemented in Go with zero external dependencies.

     Level of maturity:  Production deployments in experimental
        environments.

     Coverage:  All features specified in this document are implemented,
        including tunnel encryption (PILK/PILA/PILS/PILP), HKDF key
        derivation, sliding-window replay detection, SACK, congestion
        control, flow control, Nagle's algorithm, automatic segmentation,



  Teodor                   Expires 8 October 2026                [Page 38]


  Internet-Draft               Pilot Protocol                   April 2026


        NAT traversal (STUN, hole-punch, relay), trust handshake protocol
        with Ed25519 relay signing, privacy model, registry high-
        availability replication, enterprise RBAC and audit trail, OIDC/
        JWT identity integration, gateway bridge, per-port connection
        limits, and all built-in services.

     Testing:  983 tests.  Integration tests validated across 5 GCP
        regions (US Central, US East, Europe West, US West, Asia East)
        with public-IP, NAT-only, and symmetric-NAT topologies.

     Licensing:  Proprietary.

     Contact:  teodor@vulturelabs.com

  21.2.  Python SDK

     Organization:  Vulture Labs

     Description:  Python client SDK using ctypes FFI to the Go shared
        library.  Published on PyPI as pilotprotocol.

     Level of maturity:  Production-ready.

     Coverage:  Driver operations (dial, listen, accept, send, receive,
        close), datagram support, info queries.

     Licensing:  Proprietary.

     Contact:  teodor@vulturelabs.com

  21.3.  Node.js SDK

     Organization:  Vulture Labs

     Description:  TypeScript client SDK with FFI bindings to the Go
        shared library.  Published on npm as pilotprotocol.

     Level of maturity:  Production-ready.

     Coverage:  Driver operations (dial, listen, accept, send, receive,
        close), datagram support, info queries.  Full TypeScript type
        definitions.

     Licensing:  Proprietary.

     Contact:  teodor@vulturelabs.com

  22.  References



  Teodor                   Expires 8 October 2026                [Page 39]


  Internet-Draft               Pilot Protocol                   April 2026


  22.1.  Normative References

     [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
                DOI 10.17487/RFC1982, August 1996,
                <https://www.rfc-editor.org/rfc/rfc1982>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
                Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5116>.

     [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
                Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
                <https://www.rfc-editor.org/rfc/rfc5681>.

     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC 5869,
                DOI 10.17487/RFC5869, May 2010,
                <https://www.rfc-editor.org/rfc/rfc5869>.

     [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
                "Computing TCP's Retransmission Timer", RFC 6298,
                DOI 10.17487/RFC6298, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6298>.

     [RFC6928]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
                "Increasing TCP's Initial Window", RFC 6928,
                DOI 10.17487/RFC6928, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6928>.

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748, January
                2016, <https://www.rfc-editor.org/rfc/rfc7748>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.





  Teodor                   Expires 8 October 2026                [Page 40]


  Internet-Draft               Pilot Protocol                   April 2026


     [RFC8489]  Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
                D., Mahy, R., and P. Matthews, "Session Traversal
                Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
                February 2020, <https://www.rfc-editor.org/rfc/rfc8489>.

  22.2.  Informative References

     [I-D.hood-independent-agtp]
                Hood, C., "Agent Transfer Protocol (AGTP)", 2026,
                <https://datatracker.ietf.org/doc/draft-hood-independent-
                agtp/>.

     [I-D.prakash-aip]
                Prakash, S., "Agent Identity Protocol (AIP)", 2026,
                <https://datatracker.ietf.org/doc/draft-prakash-aip/>.

     [I-D.yao-catalist-problem-space-analysis]
                Zhou, Y. and K. Yao, "Problem Space Analysis of AI Agent
                Protocols in IETF", 2026,
                <https://datatracker.ietf.org/doc/draft-yao-catalist-
                problem-space-analysis/>.

     [RFC3465]  Allman, M., "TCP Congestion Control with Appropriate Byte
                Counting (ABC)", RFC 3465, DOI 10.17487/RFC3465, February
                2003, <https://www.rfc-editor.org/rfc/rfc3465>.

     [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
                L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
                eXtensible Local Area Network (VXLAN): A Framework for
                Overlaying Virtualized Layer 2 Networks over Layer 3
                Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
                <https://www.rfc-editor.org/rfc/rfc7348>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.

     [RFC8926]  Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
                "Geneve: Generic Network Virtualization Encapsulation",
                RFC 8926, DOI 10.17487/RFC8926, November 2020,
                <https://www.rfc-editor.org/rfc/rfc8926>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000>.




  Teodor                   Expires 8 October 2026                [Page 41]


  Internet-Draft               Pilot Protocol                   April 2026


     [RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
                Cabellos, Ed., "The Locator/ID Separation Protocol
                (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
                <https://www.rfc-editor.org/rfc/rfc9300>.

  Appendix A.  Acknowledgments

     The author thanks the participants of the IETF AI protocols
     discussions for their contributions to the understanding of the agent
     communication landscape.

  Appendix B.  Wire Examples

  B.1.  SYN Packet

     A SYN packet from 0:0000.0000.0001 port 49152 to 0:0000.0000.0002
     port 1000, with no payload:

     Byte  0:    0x11         (version=1, flags=SYN)
     Byte  1:    0x01         (protocol=Stream)
     Byte  2-3:  0x0000       (payload length=0)
     Byte  4-5:  0x0000       (src network=0)
     Byte  6-9:  0x00000001   (src node=1)
     Byte 10-11: 0x0000       (dst network=0)
     Byte 12-15: 0x00000002   (dst node=2)
     Byte 16-17: 0xC000       (src port=49152)
     Byte 18-19: 0x03E8       (dst port=1000)
     Byte 20-23: 0x00000000   (seq=0)
     Byte 24-27: 0x00000000   (ack=0)
     Byte 28-29: 0x0200       (window=512 segments)
     Byte 30-33: [CRC32]      (computed over header)

     Total: 34 bytes.

  B.2.  Data Packet

     An ACK data packet with 5-byte payload "hello":

     Byte  0:    0x12         (version=1, flags=ACK)
     Byte  1:    0x01         (protocol=Stream)
     Byte  2-3:  0x0005       (payload length=5)
     ...
     Byte 28-29: 0x01F6       (window=502 segments)
     Byte 30-33: [CRC32]      (computed over header + payload)
     Byte 34-38: 0x68656C6C6F ("hello")

     Total: 39 bytes.




  Teodor                   Expires 8 October 2026                [Page 42]


  Internet-Draft               Pilot Protocol                   April 2026


  B.3.  Encrypted Tunnel Frame

     A PILS frame carrying an encrypted Pilot packet:

     Byte  0-3:  0x50494C53   (magic="PILS")
     Byte  4-7:  0x00000001   (sender node ID=1)
     Byte  8-19: [12-byte nonce]
     Byte 20+:   [ciphertext + 16-byte GCM tag]

  Author's Address

     Calin Teodor
     Vulture Labs
     Email: teodor@vulturelabs.com





































  Teodor                   Expires 8 October 2026                [Page 43]


name: draft-stone-vcap
rev: 01
title: VCAP: Verified Commerce for Agent Protocols
time: 2026-03-24T15:37:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-25T15:37:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Other AI/agent"]
tags: []
fetched_at: 2026-05-22T09:24:48.588995+00:00
source: ietf
abstract:
  This document specifies the Verified Commerce for Agent Protocols
     (VCAP), an open standard for settling financial transactions between
     autonomous AI agents using cryptographically verifiable proof of work
     delivery.  VCAP defines the message formats, state machines,
     cryptographic bindings, and callback contracts required for any agent
     marketplace to hold funds in escrow, automatically verify
     deliverables via independent verification engines, and release or
     refund payments based on machine-verifiable evidence.  VCAP is
     designed as a settlement layer that complements agent-to-agent
     communication protocols (such as Google A2A or the Agent Protocol).
     Where those protocols define how agents discover and talk to each
     other, VCAP defines how agents pay each other with proof that work
     was done.

full_text:
  Individual Submission                                           B. Stone
  Internet-Draft                                              SwarmSync.AI
  Intended status: Informational                                March 2026
  Expires: 25 September 2026


                VCAP: Verified Commerce for Agent Protocols
                            draft-stone-vcap-01

  Abstract

     This document specifies the Verified Commerce for Agent Protocols
     (VCAP), an open standard for settling financial transactions between
     autonomous AI agents using cryptographically verifiable proof of work
     delivery.  VCAP defines the message formats, state machines,
     cryptographic bindings, and callback contracts required for any agent
     marketplace to hold funds in escrow, automatically verify
     deliverables via independent verification engines, and release or
     refund payments based on machine-verifiable evidence.  VCAP is
     designed as a settlement layer that complements agent-to-agent
     communication protocols (such as Google A2A or the Agent Protocol).
     Where those protocols define how agents discover and talk to each
     other, VCAP defines how agents pay each other with proof that work
     was done.

  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 2 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.





  Stone                   Expires 25 September 2026               [Page 1]


  Internet-Draft                    VCAP                        March 2026


     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.
     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.  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  1.1 Problem Statement . . . . . . . . . . . . . . . . . .   3
       1.2.  1.2 Design Goals  . . . . . . . . . . . . . . . . . . . .   4
       1.3.  1.3 Relationship to Other Protocols . . . . . . . . . . .   4
       1.4.  1.4 Terminology . . . . . . . . . . . . . . . . . . . . .   4
     2.  2.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   5
       2.1.  2.1 Flow Summary  . . . . . . . . . . . . . . . . . . . .   5
       2.2.  2.2 Protocol Phases . . . . . . . . . . . . . . . . . . .   5
     3.  3.  Message Formats . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  3.1 Negotiation Request . . . . . . . . . . . . . . . . .   5
       3.2.  3.2 Negotiation Response  . . . . . . . . . . . . . . . .   6
       3.3.  3.3 Escrow Hold . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  3.4 Service Delivery  . . . . . . . . . . . . . . . . . .   7
       3.5.  3.5 Verification Request  . . . . . . . . . . . . . . . .   8
       3.6.  3.6 Verification Callback (Core Message)  . . . . . . . .   9
       3.7.  3.7 Escrow Settlement . . . . . . . . . . . . . . . . . .  10
     4.  4.  State Machines  . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  4.1 Negotiation State Machine . . . . . . . . . . . . . .  11
       4.2.  4.2 Escrow State Machine  . . . . . . . . . . . . . . . .  12
       4.3.  4.3 Verification State Machine  . . . . . . . . . . . . .  13
       4.4.  4.4 Service Agreement State Machine . . . . . . . . . . .  14
     5.  5.  Cryptographic Binding . . . . . . . . . . . . . . . . . .  14
       5.1.  5.1 Proof Hash  . . . . . . . . . . . . . . . . . . . . .  14
       5.2.  5.2 Proof Signature . . . . . . . . . . . . . . . . . . .  15
       5.3.  5.3 Action Log Hash Chain (OPTIONAL, RECOMMENDED) . . . .  15
       5.4.  5.4 Agent Identity Binding (OPTIONAL) . . . . . . . . . .  15
     6.  6.  Verification Engines  . . . . . . . . . . . . . . . . . .  16
       6.1.  6.1 Verifier Requirements . . . . . . . . . . . . . . . .  16
       6.2.  6.2 Example Verifier Types  . . . . . . . . . . . . . . .  16
       6.3.  6.3 Verification Hints  . . . . . . . . . . . . . . . . .  17
     7.  7.  Timeout and Escalation  . . . . . . . . . . . . . . . . .  17
       7.1.  7.1 Timeout Semantics . . . . . . . . . . . . . . . . . .  17
       7.2.  7.2 Timeout Detection . . . . . . . . . . . . . . . . . .  17
       7.3.  7.3 Manual Review . . . . . . . . . . . . . . . . . . . .  18
     8.  8.  Idempotency . . . . . . . . . . . . . . . . . . . . . . .  18
       8.1.  8.1 Delivery Idempotency  . . . . . . . . . . . . . . . .  18
       8.2.  8.2 Escrow Idempotency  . . . . . . . . . . . . . . . . .  19



  Stone                   Expires 25 September 2026               [Page 2]


  Internet-Draft                    VCAP                        March 2026


       8.3.  8.3 Verification Callback Idempotency . . . . . . . . . .  19
     9.  9.  Security Considerations . . . . . . . . . . . . . . . . .  19
       9.1.  9.1 Shared Secret Management  . . . . . . . . . . . . . .  19
       9.2.  9.2 Transport Security  . . . . . . . . . . . . . . . . .  19
       9.3.  9.3 Callback Authentication . . . . . . . . . . . . . . .  19
       9.4.  9.4 Timing-Safe Comparison  . . . . . . . . . . . . . . .  19
       9.5.  9.5 Proof Integrity . . . . . . . . . . . . . . . . . . .  20
     10. 10.  Platform Fees  . . . . . . . . . . . . . . . . . . . . .  20
       10.1.  10.1 Fee Declaration . . . . . . . . . . . . . . . . . .  20
       10.2.  10.2 Fee Timing  . . . . . . . . . . . . . . . . . . . .  20
     11. 11.  Extensibility  . . . . . . . . . . . . . . . . . . . . .  20
       11.1.  11.1 Custom Fields . . . . . . . . . . . . . . . . . . .  21
       11.2.  11.2 Verification Engine Extensions  . . . . . . . . . .  21
       11.3.  11.3 Payment Rail Extensions . . . . . . . . . . . . . .  21
     12. 12.  Conformance  . . . . . . . . . . . . . . . . . . . . . .  21
       12.1.  12.1 Conformance Levels  . . . . . . . . . . . . . . . .  21
       12.2.  12.2 Implementation Checklist  . . . . . . . . . . . . .  21
     13. 13.  Reference Implementation . . . . . . . . . . . . . . . .  22
     14. Appendix A: Complete Action Type Registry . . . . . . . . . .  22
     15. Appendix B: JSON Schema . . . . . . . . . . . . . . . . . . .  23
     16. Appendix C: Relationship to AIVS  . . . . . . . . . . . . . .  23
     17. Appendix D: Changelog . . . . . . . . . . . . . . . . . . . .  24
       17.1.  Changes from draft-stone-vcap-00 to
              draft-stone-vcap-01  . . . . . . . . . . . . . . . . . .  24
     18. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
       19.1.  Normative References . . . . . . . . . . . . . . . . . .  24
       19.2.  Informative References . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  1.  Introduction

     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.

  1.1.  1.1 Problem Statement

     As AI agents proliferate, they increasingly need to transact with one
     another: hire other agents, delegate subtasks, and pay for completed
     work.  Today there is no standard for:

     How an agent requests work and holds payment in escrow

     How a delivering agent proves the work was actually done




  Stone                   Expires 25 September 2026               [Page 3]


  Internet-Draft                    VCAP                        March 2026


     How a verification engine independently confirms delivery

     How proof of verification cryptographically triggers fund release

     How timeouts and disputes are escalated to human review

     Each marketplace invents its own ad-hoc system, creating
     fragmentation and vendor lock-in.  VCAP provides a vendor-neutral
     protocol that any marketplace, payment processor, or agent framework
     can implement.

  1.2.  1.2 Design Goals

  | Goal | Description |
  |------|-------------|
  | **Vendor-neutral** | Any marketplace or payment processor can implement VCAP |
  | **Verification-agnostic** | Any verification engine (browser automation, LLM evaluation, human review) can produce VCAP-compliant proofs |
  | **Cryptographically auditable** | Every settlement is tied to a proof hash and signature that can be independently verified |
  | **Graceful degradation** | Automated verification falls back to human review on timeout or ambiguity |
  | **Composable** | VCAP layers on top of existing agent communication protocols (A2A, Agent Protocol, custom) |
  | **Minimal** | The spec defines only what is necessary; implementations may extend it |

  1.3.  1.3 Relationship to Other Protocols

     VCAP relates to several existing protocols.  The Agent Payments
     Protocol (AP2) [AP2] defines payment intents that VCAP fulfills at
     the settlement layer.  The Agent-to-Agent Protocol [A2A] handles
     agent discovery and messaging; VCAP adds payment settlement on top.

  | Protocol | Layer | VCAP Relationship |
  |----------|-------|-------------------|
  | Google A2A | Agent Communication | VCAP sits above A2A; uses A2A for discovery/messaging, adds payment settlement |
  | Agent Protocol | Task Execution | VCAP wraps Agent Protocol tasks with escrow and verification |
  | AIVS (AI Visibility Verification Standard) | Proof Format | AIVS proof bundles are one valid VCAP proof format |
  | OAuth 2.0 | Authorization | VCAP agents may use OAuth for identity; VCAP adds payment semantics |
  | Stripe Connect / x402 | Payment Rails | VCAP is rail-agnostic; Stripe, crypto, or internal wallets can serve as the escrow backend |

  1.4.  1.4 Terminology

  | Term | Definition |
  |------|------------|
  | **Requester** | The agent (or human) that initiates a service request and holds payment |
  | **Provider** | The agent that performs the work and receives payment |
  | **Marketplace** | The platform that facilitates discovery, escrow, and settlement |
  | **Verifier** | An independent engine that confirms whether work was delivered (may be automated or human) |
  | **Escrow** | A financial hold on the requester's funds, released only upon verified delivery |
  | **Proof Bundle** | A cryptographically signed artifact attesting to the verification result |
  | **Service Agreement** | The contract between requester and provider, specifying deliverables and payment |



  Stone                   Expires 25 September 2026               [Page 4]


  Internet-Draft                    VCAP                        March 2026


  2.  2.  Protocol Overview

  2.1.  2.1 Flow Summary

     Requester                  Marketplace                Provider              Verifier
        │                          │                          │                     │
        │──── 1. NEGOTIATE ───────>│                          │                     │
        │                          │──── 2. FORWARD ─────────>│                     │
        │                          │<─── 3. RESPOND ──────────│                     │
        │<─── 4. TERMS ───────────│                          │                     │
        │──── 5. ACCEPT ─────────>│                          │                     │
        │                          │── 6. ESCROW_HOLD ───────>│ (funds reserved)    │
        │                          │── 7. AGREEMENT_CREATED ─>│                     │
        │                          │                          │                     │
        │                          │     [Provider works...]  │                     │
        │                          │                          │                     │
        │                          │<─── 8. DELIVER ──────────│                     │
        │                          │──────────── 9. VERIFY ──────────────────────>│
        │                          │                          │                     │
        │                          │      [Verifier runs...]  │                     │
        │                          │                          │                     │
        │                          │<──────── 10. CALLBACK ──────────────────────│
        │                          │                          │                     │
        │                          │── 11a. ESCROW_RELEASE ──>│ (if VERIFIED)       │
        │                          │── 11b. ESCROW_REFUND ───>│ (if FAILED)         │
        │<── 12. SETTLEMENT_RECEIPT│                          │                     │

  2.2.  2.2 Protocol Phases

  | Phase | Name | Description |
  |-------|------|-------------|
  | Phase 1 | **Negotiation** | Requester and provider agree on scope, price, and verification criteria |
  | Phase 2 | **Escrow** | Marketplace holds requester's funds in escrow |
  | Phase 3 | **Execution** | Provider performs the work |
  | Phase 4 | **Delivery** | Provider submits deliverables with verification hints |
  | Phase 5 | **Verification** | Independent verifier confirms delivery against the agreement |
  | Phase 6 | **Settlement** | Escrow releases (on verification) or refunds (on failure) |
  | Phase 7 | **Escalation** | Timeout or ambiguity routes to human review |

  3.  3.  Message Formats

  3.1.  3.1 Negotiation Request

     Sent by the requester to initiate a service request.







  Stone                   Expires 25 September 2026               [Page 5]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "negotiation_request",
    "negotiation_id": "string (UUID, generated by marketplace)",
    "requester": {
      "agent_id": "string (URI or UUID)",
      "platform": "string (e.g., 'swarmsync', 'custom')"
    },
    "provider": {
      "agent_id": "string (URI or UUID)",
      "platform": "string"
    },
    "request": {
      "service_type": "string (free-form or from a taxonomy)",
      "description": "string (human-readable description of work)",
      "budget_amount": "number (decimal, in currency units)",
      "budget_currency": "string (ISO 4217, e.g., 'USD')",
      "requirements": "object (OPTIONAL, implementation-specific)",
      "deadline_utc": "string (OPTIONAL, ISO 8601 datetime)"
    },
    "verification_hints": {
      "type": "string (OPTIONAL, e.g., 'url', 'artifact', 'llm_eval', 'human')",
      "url": "string (OPTIONAL, URL of deliverable to verify)",
      "selector": "string (OPTIONAL, CSS selector or JSONPath for content extraction)",
      "expected_content": "string (OPTIONAL, substring or pattern to match)",
      "fingerprint_delta": "boolean (OPTIONAL, check if content changed)",
      "custom": "object (OPTIONAL, verifier-specific parameters)"
    },
    "metadata": "object (OPTIONAL, implementation-specific)"
  }

                              Figure 1: json

  3.2.  3.2 Negotiation Response

     Sent by the provider to accept, reject, or counter the request.















  Stone                   Expires 25 September 2026               [Page 6]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "negotiation_response",
    "negotiation_id": "string (matches request)",
    "response_status": "ACCEPTED | REJECTED | COUNTERED",
    "counter_terms": {
      "amount": "number (OPTIONAL, counter-offer price)",
      "currency": "string (OPTIONAL)",
      "description": "string (OPTIONAL, modified scope)",
      "deadline_utc": "string (OPTIONAL)",
      "rejection_reason": "string (OPTIONAL, when REJECTED)"
    },
    "provider_verification_hints": {
      "type": "string (OPTIONAL, provider may suggest verification method)",
      "url": "string (OPTIONAL)",
      "custom": "object (OPTIONAL)"
    }
  }

                              Figure 2: json

  3.3.  3.3 Escrow Hold

     Created by the marketplace when negotiation reaches ACCEPTED.

  {
    "vcap_version": "1.0",
    "message_type": "escrow_hold",
    "escrow_id": "string (UUID)",
    "negotiation_id": "string",
    "source_wallet": "string (requester's wallet/account identifier)",
    "destination_wallet": "string (provider's wallet/account identifier)",
    "amount": "number (decimal)",
    "currency": "string (ISO 4217)",
    "status": "HELD",
    "release_condition": "string (memo linking escrow to negotiation)",
    "held_at": "string (ISO 8601)",
    "metadata": "object (OPTIONAL)"
  }

                              Figure 3: json

  3.4.  3.4 Service Delivery

     Sent by the provider to claim work completion.






  Stone                   Expires 25 September 2026               [Page 7]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "service_delivery",
    "negotiation_id": "string",
    "escrow_id": "string",
    "provider": {
      "agent_id": "string",
      "platform": "string"
    },
    "delivery": {
      "status": "string ('success' | 'partial' | 'failed')",
      "description": "string (what was delivered)",
      "artifacts": [
        {
          "type": "string (e.g., 'url', 'file', 'text', 'api_response')",
          "uri": "string (OPTIONAL)",
          "content": "string (OPTIONAL, inline content)",
          "hash": "string (OPTIONAL, SHA-256 of artifact)"
        }
      ]
    },
    "verification_hints": {
      "url": "string (OPTIONAL, URL to verify)",
      "selector": "string (OPTIONAL, CSS selector for content extraction)",
      "expected_content": "string (OPTIONAL, substring to find)",
      "fingerprint_delta": "boolean (OPTIONAL, default false)",
      "auto_approve": "boolean (OPTIONAL, skip automated verification)"
    },
    "delivered_at": "string (ISO 8601)"
  }

                              Figure 4: json

  3.5.  3.5 Verification Request

     Sent by the marketplace to the verifier engine.















  Stone                   Expires 25 September 2026               [Page 8]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "verification_request",
    "verification_id": "string (UUID)",
    "negotiation_id": "string",
    "spec": {
      "url": "string (URL to verify)",
      "selector": "string | null (CSS selector for extraction)",
      "expected_content": "string | null (substring match, case-insensitive)",
      "fingerprint_delta": "boolean (check content change)",
      "timeout_seconds": "number (max verification duration, default 1800)"
    },
    "context": {
      "marketplace": "string (marketplace identifier)",
      "purpose": "escrow_verification",
      "escrow_ref": "string (escrow ID)",
      "negotiation_id": "string",
      "verification_id": "string"
    },
    "requested_at": "string (ISO 8601)"
  }

                              Figure 5: json

  3.6.  3.6 Verification Callback (Core Message)

     Sent by the verifier back to the marketplace.  This is the most
     critical message in the protocol -- it triggers escrow settlement.























  Stone                   Expires 25 September 2026               [Page 9]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "verification_callback",
    "verification_id": "string (matches request)",
    "passed": "boolean (true = verified, false = failed)",
    "proof_hash": "string (SHA-256 hex digest of the canonical proof bundle)",
    "proof_signature": "string (Ed25519 signature, base64url-encoded, signed with verifier's private key)",
    "extracted_content": "string (OPTIONAL, truncated content from target)",
    "failure_reason": "string (OPTIONAL, human-readable when passed=false)",
    "action_log": [
      {
        "index": "number (0-based sequential order)",
        "action": "string (e.g., 'NAVIGATE', 'EXTRACT', 'SCREENSHOT', 'FINGERPRINT')",
        "url": "string (OPTIONAL)",
        "selector": "string (OPTIONAL)",
        "success": "boolean",
        "cost_cents": "number (cost of this action)",
        "duration_ms": "number (OPTIONAL)",
        "timestamp": "string (ISO 8601)",
        "data_snippet": "string (OPTIONAL, first N chars of extracted data)"
      }
    ],
    "completed_at": "string (ISO 8601)"
  }

                              Figure 6: json

  3.7.  3.7 Escrow Settlement

     The final state of the escrow after verification.





















  Stone                   Expires 25 September 2026              [Page 10]


  Internet-Draft                    VCAP                        March 2026


  {
    "vcap_version": "1.0",
    "message_type": "escrow_settlement",
    "escrow_id": "string",
    "negotiation_id": "string",
    "status": "RELEASED | REFUNDED",
    "verification_id": "string (links to the verification that triggered settlement)",
    "proof_hash": "string (copied from verification callback for audit trail)",
    "proof_signature": "string (copied from verification callback)",
    "evidence": {
      "conduit_verification_id": "string (OPTIONAL)",
      "proof_hash": "string",
      "proof_signature": "string",
      "extracted_content": "string (OPTIONAL)",
      "action_log": "array (OPTIONAL, full action log)"
    },
    "platform_fee": {
      "amount": "number (OPTIONAL)",
      "currency": "string (OPTIONAL)",
      "rate": "number (OPTIONAL, decimal, e.g. 0.05 for 5%)"
    },
    "settled_at": "string (ISO 8601)"
  }

                              Figure 7: json

  4.  4.  State Machines

  4.1.  4.1 Negotiation State Machine






















  Stone                   Expires 25 September 2026              [Page 11]


  Internet-Draft                    VCAP                        March 2026


                        ┌──────────────┐
                        │   PENDING    │
                        └──────┬───────┘
                               │
                  ┌────────────┼────────────┐
                  │            │            │
                  ▼            ▼            ▼
            ┌──────────┐ ┌──────────┐ ┌──────────┐
            │ ACCEPTED │ │COUNTERED │ │ DECLINED │
            └────┬─────┘ └────┬─────┘ └──────────┘
                 │            │                     (terminal)
                 │            │
                 │       ┌────┴────┐
                 │       │ PENDING │  (counter-offer restarts negotiation)
                 │       └─────────┘
                 │
                 ▼
       [Escrow Hold Created]
       [Service Agreement Created]

     Transitions:

     | From | To | Trigger |
     |------|----|---------|
     | PENDING | ACCEPTED | Provider accepts terms |
     | PENDING | COUNTERED | Provider counter-offers |
     | PENDING | DECLINED | Provider rejects |
     | COUNTERED | ACCEPTED | Requester accepts counter |
     | COUNTERED | DECLINED | Requester rejects counter |
     | COUNTERED | COUNTERED | Requester counter-counters |

  4.2.  4.2 Escrow State Machine

                   ┌──────────┐
                   │   HELD   │
                   └────┬─────┘
                        │
              ┌─────────┼─────────┐
              │                    │
              ▼                    ▼
        ┌──────────┐         ┌──────────┐
        │ RELEASED │         │ REFUNDED │
        └──────────┘         └──────────┘
        (terminal)           (terminal)

     Transitions:





  Stone                   Expires 25 September 2026              [Page 12]


  Internet-Draft                    VCAP                        March 2026


  | From | To | Trigger | Guard |
  |------|----|---------|-------|
  | HELD | RELEASED | Verification VERIFIED | Atomic CAS: `status = 'HELD'` |
  | HELD | REFUNDED | Verification FAILED or REJECTED | Atomic CAS: `status = 'HELD'` |
  | HELD | REFUNDED | Timeout + manual rejection | Atomic CAS: `status = 'HELD'` |

     Concurrency Guard: The HELD -> RELEASED/REFUNDED transition MUST use
     an atomic compare-and-swap (CAS) operation to prevent double-release.
     Implementations SHOULD use database-level atomic updates:

     UPDATE Escrow SET status = 'RELEASED', released_at = NOW()
     WHERE id = :escrow_id AND status = 'HELD'
     -- Returns 0 rows affected if already transitioned

                                 Figure 8: sql

  4.3.  4.3 Verification State Machine

        ┌─────────┐
        │ PENDING │
        └────┬────┘
             │
             ▼
        ┌─────────┐
        │ RUNNING │
        └────┬────┘
             │
        ┌────┼────────┬──────────┐
        │    │        │          │
        ▼    ▼        ▼          ▼
     ┌────┐┌────┐ ┌───────┐ ┌───────┐
     │VERI││FAIL│ │TIMEOUT│ │ ERROR │
     │FIED││ ED │ └───┬───┘ └───────┘
     └──┬─┘└──┬─┘     │
        │     │       ▼
        │     │  [Manual Review]
        │     │       │
        │     │  ┌────┴────┐
        │     │  │ PENDING │ (OutcomeVerification)
        │     │  └─────────┘
        ▼     ▼
     [ESCROW  [ESCROW
     RELEASE] REFUND]

     Transitions:






  Stone                   Expires 25 September 2026              [Page 13]


  Internet-Draft                    VCAP                        March 2026


     | From | To | Trigger |
     |------|----|---------|
     | PENDING | RUNNING | Verifier acknowledges job |
     | RUNNING | VERIFIED | Verification callback `passed=true` |
     | RUNNING | FAILED | Verification callback `passed=false` |
     | RUNNING | TIMEOUT | No callback within `timeout_seconds` |
     | RUNNING | ERROR | Verifier reports internal error |
     | PENDING | TIMEOUT | No acknowledgment within `timeout_seconds` |
     | TIMEOUT | (manual) | Escalated to human review queue |

  4.4.  4.4 Service Agreement State Machine

        ┌────────┐
        │ ACTIVE │
        └───┬────┘
            │
       ┌────┼────────┐
       │    │        │
       ▼    ▼        ▼
     ┌────┐┌────┐ ┌────┐
     │COMP││DISP│ │CANC│
     │LETE││UTED│ │ELED│
     │  D ││    │ │    │
     └────┘└────┘ └────┘

     | From | To | Trigger |
     |------|----|---------|
     | ACTIVE | COMPLETED | Verification VERIFIED |
     | ACTIVE | DISPUTED | Verification REJECTED |
     | ACTIVE | CANCELLED | Either party cancels before delivery |

  5.  5.  Cryptographic Binding

  5.1.  5.1 Proof Hash

     The proof_hash field in the Verification Callback MUST be computed
     as:

     proof_hash = SHA-256(canonical_json(proof_bundle))

     Where canonical_json serializes the proof bundle with:

     Object keys sorted alphabetically (recursive)

     No whitespace between tokens

     UTF-8 encoding




  Stone                   Expires 25 September 2026              [Page 14]


  Internet-Draft                    VCAP                        March 2026


     No trailing newline

  5.2.  5.2 Proof Signature

     The proof_signature field MUST be computed as an Ed25519 signature
     over the canonical JSON serialization of the proof body:

  proof_signature = Ed25519Sign(canonical_json(proof_body), verifier_private_key)

     Where:

     proof_body contains at minimum: { verification_id, negotiation_id,
     escrow_ref, passed, proof_hash, completed_at }

     verifier_private_key is the Ed25519 private key of the verifier; the
     corresponding public key MUST be registered with the marketplace
     prior to use

     The signature binds the proof to the specific escrow, preventing
     replay across different transactions

     Implementations MUST verify proof_signature using the registered
     Ed25519 public key before releasing escrow funds.  Constant-time
     signature verification MUST be used.

  5.3.  5.3 Action Log Hash Chain (OPTIONAL, RECOMMENDED)

     For verifiers that record sequential actions (e.g., browser
     automation), the action log SHOULD be hash-chained:

     hash_0 = SHA-256(canonical_json(action_0))
     hash_1 = SHA-256(canonical_json(action_1) || hash_0)
     hash_2 = SHA-256(canonical_json(action_2) || hash_1)
     ...
     hash_n = SHA-256(canonical_json(action_n) || hash_(n-1))

     The final hash_n SHOULD be included in the proof bundle.  Modifying
     any past action immediately invalidates all subsequent hashes,
     providing tamper evidence.

  5.4.  5.4 Agent Identity Binding (OPTIONAL)

     When agent identity is cryptographically established (e.g., via
     Ed25519 key pairs), the proof bundle MAY include:







  Stone                   Expires 25 September 2026              [Page 15]


  Internet-Draft                    VCAP                        March 2026


  {
    "agent_identity": {
      "agent_id": "string",
      "public_key": "string (PEM, Ed25519 SPKI format)",
      "signature": "string (Ed25519 signature over agent_id + timestamp, signed with agent's private key)",
      "timestamp": "string (ISO 8601)"
    }
  }

                              Figure 9: json

     Agent identity headers for HTTP transport:

     X-Agent-Id: <agent UUID>
     X-Agent-Signature: <ISO-timestamp>.<Ed25519-base64url>
     X-Agent-Platform: <platform identifier>

  6.  6.  Verification Engines

  6.1.  6.1 Verifier Requirements

     A compliant VCAP verifier MUST:

     Accept a verification_request message

     Return a verification_callback message within the specified
     timeout_seconds

     Include a proof_hash computed per Section 5.1

     Include a proof_signature computed per Section 5.2

     Set passed to true only if the verification criteria are met

     6.  Include an action_log documenting all steps taken

     A compliant VCAP verifier SHOULD:

     Use hash-chained action logs per Section 5.3

     Include extracted_content when applicable

     Provide human-readable failure_reason when passed=false

  6.2.  6.2 Example Verifier Types






  Stone                   Expires 25 September 2026              [Page 16]


  Internet-Draft                    VCAP                        March 2026


  | Type | Description | Use Case |
  |------|-------------|----------|
  | **Browser Automation** | Navigates to URL, extracts content, fingerprints page | Web deliverables, deployed applications |
  | **LLM Evaluation** | Sends deliverable to an LLM for quality assessment | Content generation, code review |
  | **API Health Check** | Calls API endpoints and validates responses | API development tasks |
  | **Human Review** | Routes to a human reviewer with a structured rubric | Subjective quality, complex deliverables |
  | **Composite** | Chains multiple verifiers (e.g., browser + LLM) | Multi-criteria verification |

  6.3.  6.3 Verification Hints

     The verification_hints object in the delivery message tells the
     verifier what to check.  Standard hint fields:

  | Field | Type | Description |
  |-------|------|-------------|
  | `url` | string | URL of the deliverable to verify |
  | `selector` | string | CSS selector or JSONPath to extract specific content |
  | `expected_content` | string | Substring that must appear (case-insensitive) |
  | `fingerprint_delta` | boolean | If true, verify the page content has changed from a prior known state |
  | `auto_approve` | boolean | If true, skip automated verification (provider self-attests) |
  | `custom` | object | Verifier-specific parameters (e.g., LLM rubric, API schema) |

  7.  7.  Timeout and Escalation

  7.1.  7.1 Timeout Semantics

     If a verification does not complete within timeout_seconds (default:
     1800 seconds / 30 minutes):

     The marketplace MUST transition the verification to TIMEOUT status

     The escrow MUST remain in HELD status (funds are NOT auto-released or
     auto-refunded)

     The marketplace SHOULD create a manual review queue entry with status
     PENDING

     A human reviewer MUST make the final settlement decision

  7.2.  7.2 Timeout Detection

     Implementations SHOULD run a periodic check (recommended: every 5
     minutes) that:








  Stone                   Expires 25 September 2026              [Page 17]


  Internet-Draft                    VCAP                        March 2026


  FOR EACH verification WHERE
    status IN ('PENDING', 'RUNNING') AND
    created_at < (NOW() - timeout_seconds)
  DO
    SET status = 'TIMEOUT'
    SET failure_reason = 'Verification timed out — escalated to manual review'
    CREATE manual_review_entry(status = 'PENDING')

  7.3.  7.3 Manual Review

     When a verification is escalated to manual review, the reviewer has
     access to:

     The original service agreement and negotiation terms

     The provider's delivery artifacts

     Any partial verification results (action logs, extracted content)

     The escrow hold details

     The reviewer MUST produce a standard verification_callback message
     with:

     passed = true or passed = false

     action_log containing a single entry documenting the manual decision

     proof_hash and proof_signature computed normally

  8.  8.  Idempotency

  8.1.  8.1 Delivery Idempotency

     If the same provider submits delivery for the same escrow multiple
     times, the marketplace MUST return the existing verification result
     rather than creating a new one.  This prevents:

     Double-release of escrow funds

     Duplicate verification jobs

     Replay attacks








  Stone                   Expires 25 September 2026              [Page 18]


  Internet-Draft                    VCAP                        March 2026


  8.2.  8.2 Escrow Idempotency

     The HELD -> RELEASED/REFUNDED transition MUST be atomic and
     idempotent.  If two concurrent processes attempt to settle the same
     escrow, exactly one MUST succeed and the other MUST observe the
     already-settled state.

  8.3.  8.3 Verification Callback Idempotency

     If a verifier sends the same callback multiple times (e.g., due to
     network retry), the marketplace MUST process only the first callback
     and acknowledge subsequent duplicates without re-settling the escrow.

  9.  9.  Security Considerations

  9.1.  9.1 Shared Secret Management

     The shared_secret used for proof_signature computation MUST:

     Be at least 32 bytes of cryptographically random data

     Be transmitted out-of-band (never in VCAP messages)

     Be rotated periodically (recommended: every 90 days)

     Be unique per marketplace-verifier pair

  9.2.  9.2 Transport Security

     All VCAP messages MUST be transmitted over TLS 1.2 or later.

  9.3.  9.3 Callback Authentication

     The marketplace MUST authenticate verification callbacks to prevent
     spoofing.  Recommended mechanisms:

     Shared secret in HTTP header (e.g., X-Internal-Secret)

     Mutual TLS

     Webhook signature verification

  9.4.  9.4 Timing-Safe Comparison

     All Ed25519 signature verifications MUST use constant-time comparison
     to prevent timing oracle attacks.





  Stone                   Expires 25 September 2026              [Page 19]


  Internet-Draft                    VCAP                        March 2026


  9.5.  9.5 Proof Integrity

     The proof_hash + proof_signature pair creates a dual-layer integrity
     check:

     proof_hash verifies the proof content was not tampered with

     proof_signature verifies the proof was generated by the authorized
     verifier

     Both MUST be stored alongside the escrow settlement record for post-
     hoc auditability.

  10.  10.  Platform Fees

  10.1.  10.1 Fee Declaration

     {
       "platform_fee": {
         "rate": 0.05,
         "rate_type": "percentage",
         "amount": 15,
         "currency": "USD",
         "split": {
           "buyer_share": 0.5,
           "seller_share": 0.5
         }
       }
     }

                                Figure 10: json

  10.2.  10.2 Fee Timing

     Fees SHOULD be calculated at settlement time (not at escrow
     creation), because:

     The provider's subscription tier may change between escrow creation
     and settlement

     Partial completions may adjust the fee basis

     Fee disputes should reference the fee at settlement time

  11.  11.  Extensibility






  Stone                   Expires 25 September 2026              [Page 20]


  Internet-Draft                    VCAP                        March 2026


  11.1.  11.1 Custom Fields

     Implementations MAY add custom fields to any VCAP message using the
     metadata or custom objects.  Standard VCAP processors MUST ignore
     unknown fields.

  11.2.  11.2 Verification Engine Extensions

     New verification engine types can be registered by publishing their:

     Supported verification_hints fields

     Action types they may include in action_log

     Any custom proof_bundle fields

  11.3.  11.3 Payment Rail Extensions

     VCAP is agnostic to the underlying payment rail.  The escrow_hold and
     escrow_settlement messages use wallet identifiers that can map to:

     Internal platform wallets (balance-based)

     Stripe Connect accounts

     Cryptocurrency wallets (x402 protocol)

     Bank accounts via ACH/SEPA

     Any future payment method

  12.  12.  Conformance

  12.1.  12.1 Conformance Levels

  | Level | Requirements |
  |-------|-------------|
  | **VCAP Core** | Implement all message formats, state machines, and escrow transitions from Sections 3-4 |
  | **VCAP Verified** | Core + cryptographic binding from Section 5 (proof_hash, proof_signature) |
  | **VCAP Full** | Verified + hash-chained action logs + agent identity binding + timeout escalation |

  12.2.  12.2 Implementation Checklist

     A conformant implementation MUST:

     [ ] Generate and process all seven message types (Sections 3.1-3.7)

     [ ] Implement the negotiation state machine (Section 4.1)



  Stone                   Expires 25 September 2026              [Page 21]


  Internet-Draft                    VCAP                        March 2026


     [ ] Implement the escrow state machine with atomic CAS transitions
     (Section 4.2)

     [ ] Implement the verification state machine (Section 4.3)

     [ ] Compute proof_hash per Section 5.1

     [ ] Compute proof_signature per Section 5.2

     [ ] Support delivery idempotency (Section 8.1)

     [ ] Support escrow idempotency (Section 8.2)

     [ ] Use constant-time comparison for Ed25519 signature verification
     (Section 9.4)

     [ ] Store proof_hash and proof_signature in settlement records
     (Section 9.5)

  13.  13.  Reference Implementation

     The reference implementation is available at:

     Repository: https://github.com/bkauto3/SwarmSync

  | Component | File | Description |
  |-----------|------|-------------|
  | Negotiation | `apps/api/src/modules/ap2/ap2.service.ts` | AP2 negotiation state machine |
  | Escrow | `apps/api/src/modules/payments/ap2.service.ts` | Atomic escrow hold/release/refund |
  | Wallet Ledger | `apps/api/src/modules/payments/wallets.service.ts` | Double-entry wallet with atomic guards |
  | Verification Dispatch | `apps/api/src/modules/conduit/conduit-verification.service.ts` | Verification initiation and callback |
  | Verification Hints | `apps/api/src/modules/conduit/dto/verification-hints.dto.ts` | VerificationHintsDto |
  | Verification Callback | `apps/api/src/modules/conduit/dto/verification-callback.dto.ts` | VerificationCallbackDto |
  | AP2-Conduit Bridge | `apps/api/src/modules/conduit/conduit-ap2-bridge.service.ts` | Session billing, invoice signing |
  | Agent Identity | `apps/api/src/modules/conduit/conduit-identity.service.ts` | Ed25519 keys, HMAC signing |
  | Outcomes | `apps/api/src/modules/quality/outcomes.service.ts` | Verification -> escrow settlement |
  | Trust & Passport | `apps/api/src/modules/conduit/conduit-passport.service.ts` | Execution track record (see ATEP spec) |

  14.  Appendix A: Complete Action Type Registry

     These are the standard action types for browser-automation verifiers.
     Other verifier types may define their own action vocabularies.









  Stone                   Expires 25 September 2026              [Page 22]


  Internet-Draft                    VCAP                        March 2026


     | Action | Description | Cost Category |
     |--------|-------------|---------------|
     | `NAVIGATE` | Load a URL | Billable |
     | `CLICK` | Click an element | Billable |
     | `TYPE` | Type into an input | Billable |
     | `FILL` | Fill a form field | Billable |
     | `EXTRACT` | Extract text content | Billable |
     | `SCREENSHOT` | Capture a screenshot | Billable |
     | `SCROLL` | Scroll the page | Free |
     | `WAIT` | Wait for a duration | Free |
     | `WAIT_FOR` | Wait for a selector | Free |
     | `KEY_PRESS` | Press a keyboard key | Free |
     | `HOVER` | Hover over an element | Free |
     | `SELECT_OPTION` | Select a dropdown option | Billable |
     | `HANDLE_DIALOG` | Dismiss/accept a dialog | Free |
     | `NAVIGATE_BACK` | Go back in history | Billable |
     | `CONSOLE_MESSAGES` | Read console output | Free |
     | `EVAL` | Execute JavaScript | Billable |
     | `EXTRACT_MAIN` | Extract main content | Billable |
     | `OUTPUT_TO_FILE` | Save data to file | Free |
     | `ACCESSIBILITY_SNAPSHOT` | Capture a11y tree | Billable |
     | `NETWORK_REQUESTS` | Read network log | Free |
     | `MAP` | Map site structure | Billable |
     | `CRAWL` | Crawl multiple pages | Billable |
     | `FINGERPRINT` | SHA-256 page fingerprint | Billable |
     | `CHECK_CHANGED` | Compare fingerprints | Billable |
     | `EXPORT_PROOF` | Export proof bundle | Free |

  15.  Appendix B: JSON Schema

     Machine-readable JSON Schema definitions for all VCAP message types
     are available at:

     https://github.com/swarmsync-ai/vcap-spec/tree/main/schemas/

  16.  Appendix C: Relationship to AIVS

     The AI Visibility Verification Standard (AIVS) defines a proof bundle
     format (Ed25519 + SHA-256 hash chain) for AI browser scan
     verification.  AIVS proof bundles are a valid VCAP proof format.
     When a VCAP verifier uses AIVS-compliant proof bundles:

     The proof_hash in the VCAP callback corresponds to the AIVS manifest
     hash

     The proof_signature corresponds to the AIVS session_sig.txt

     The action_log corresponds to the AIVS audit_log.jsonl



  Stone                   Expires 25 September 2026              [Page 23]


  Internet-Draft                    VCAP                        March 2026


     The AIVS verify.py can independently validate the proof without VCAP
     infrastructure

     This layering means AIVS proofs are portable: they can be verified
     both within a VCAP settlement flow and independently by any party
     with the proof bundle file.

  17.  Appendix D: Changelog

  17.1.  Changes from draft-stone-vcap-00 to draft-stone-vcap-01

     *  Section 5.2: Replaced HMAC-SHA256 proof signature with Ed25519
        signature for consistency with the rest of the stack.
        proof_signature is now computed as
        Ed25519Sign(canonical_json(proof_body), verifier_private_key).
        The corresponding verifier public key MUST be pre-registered with
        the marketplace.

     *  Section 5.4: Updated agent identity signature description from
        HMAC-SHA256 to Ed25519 to match Section 5.2 and AIVS proof format.

     *  Section 5.4: Updated X-Agent-Signature HTTP header format from
        HMAC-SHA256 hex to Ed25519 base64url encoding.

     *  Section 9.4: Updated timing-safe comparison requirement from HMAC
        to Ed25519 verification.

     *  Section 11 (Implementer Checklist): Updated checklist item to
        reference Ed25519 verification.

     *  These changes eliminate the cryptographic inconsistency identified
        in W3C AI-KR-CG Technical Note AI-KR-CG-TR-2026-001, aligning all
        signature operations in the stack on Ed25519.

  18.  IANA Considerations

     This document has no IANA actions.

  19.  References

  19.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.






  Stone                   Expires 25 September 2026              [Page 24]


  Internet-Draft                    VCAP                        March 2026


     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

  19.2.  Informative References

     [A2A]      Google, "Agent-to-Agent Protocol", 2025,
                <https://google.github.io/A2A/>.

     [AP2]      Google et al., "Agent Payments Protocol (AP2)", 2025,
                <https://ap2-protocol.org/specification/>.

  Author's Address

     Ben Stone
     SwarmSync.AI
     Email: benstone@swarmsync.ai






























  Stone                   Expires 25 September 2026              [Page 25]


name: draft-mw-spice-intent-chain
rev: 00
title: Cryptographically Verifiable Intent Chain for AI Agent Content Provenance
time: 2026-03-18T00:28:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-19T00:28:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:48.588999+00:00
source: ietf
abstract:
  This document defines the intent_chain claim as a companion to the
     actor_chain claim defined in {{!I-D.draft-mw-spice-actor-chain}}.
     While the actor chain addresses delegation provenance (WHO delegated
     to whom), the intent chain addresses content provenance (WHAT was
     produced and HOW it was transformed).

     In AI agent workflows, content flows through multiple processing
     stages including AI agents and filters.  The intent chain provides a
     cryptographically verifiable, tamper-evident record of this content
     journey.  The full intent chain is stored as ordered logs, with only
     the Merkle root included in the OAuth token for efficiency.

     Together, the actor chain and intent chain provide complete
     governance for autonomous AI agent systems, addressing Spoofing,
     Tampering, Repudiation, and Elevation of Privilege threats in the
     STRIDE threat model.

full_text:
  SPICE                                                        R. Krishnan
  Internet-Draft                                       JPMorgan Chase & Co
  Intended status: Informational                                 A. Prasad
  Expires: 19 September 2026                                        Oracle
                                                                  D. Lopez
                                                                Telefonica
                                                              S. Addepalli
                                                                    Aryaka
                                                             18 March 2026


       Cryptographically Verifiable Intent Chain for AI Agent Content
                                 Provenance
                       draft-mw-spice-intent-chain-00

  Abstract

     This document defines the intent_chain claim as a companion to the
     actor_chain claim defined in {{!I-D.draft-mw-spice-actor-chain}}.
     While the actor chain addresses delegation provenance (WHO delegated
     to whom), the intent chain addresses content provenance (WHAT was
     produced and HOW it was transformed).

     In AI agent workflows, content flows through multiple processing
     stages including AI agents and filters.  The intent chain provides a
     cryptographically verifiable, tamper-evident record of this content
     journey.  The full intent chain is stored as ordered logs, with only
     the Merkle root included in the OAuth token for efficiency.

     Together, the actor chain and intent chain provide complete
     governance for autonomous AI agent systems, addressing Spoofing,
     Tampering, Repudiation, and Elevation of Privilege threats in the
     STRIDE threat model.

  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."



  Krishnan, et al.        Expires 19 September 2026               [Page 1]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     This Internet-Draft will expire on 19 September 2026.

  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.
     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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  The Problem: Content Provenance Gap . . . . . . . . . . .   4
       1.2.  Relationship to Actor Chain and Inference Chain . . . . .   5
       1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Three-Layer Governance Model  . . . . . . . . . . . . . .   7
       3.2.  Session as Root of Trust  . . . . . . . . . . . . . . . .   7
       3.3.  Actor Chain (WHO) - Reference . . . . . . . . . . . . . .   8
       3.4.  Intent Chain (WHAT) - This Document . . . . . . . . . . .   8
       3.5.  STRIDE Threat Model Coverage  . . . . . . . . . . . . . .   8
     4.  Intent Chain Definition . . . . . . . . . . . . . . . . . . .   9
       4.1.  Entry Types . . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Non-Deterministic Entries . . . . . . . . . . . . . . . .  10
       4.3.  Deterministic Entries . . . . . . . . . . . . . . . . . .  11
       4.4.  Entry Structure . . . . . . . . . . . . . . . . . . . . .  12
         4.4.1.  intent_digest Computation . . . . . . . . . . . . . .  12
     5.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .  13
       5.1.  Intent Registry (Ordered Logs)  . . . . . . . . . . . . .  13
         5.1.1.  Relationship Between session_id and jti . . . . . . .  14
       5.2.  Merkle Tree Construction  . . . . . . . . . . . . . . . .  15
       5.3.  Merkle Root in Token  . . . . . . . . . . . . . . . . . .  15
     6.  Token Structure . . . . . . . . . . . . . . . . . . . . . . .  16
       6.1.  Combined Token Format . . . . . . . . . . . . . . . . . .  16
       6.2.  Claim Definitions . . . . . . . . . . . . . . . . . . . .  17
         6.2.1.  Session Claims  . . . . . . . . . . . . . . . . . . .  17
         6.2.2.  Actor Chain Claims  . . . . . . . . . . . . . . . . .  18
         6.2.3.  Intent Chain Claims . . . . . . . . . . . . . . . . .  18
       6.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .  18
         6.3.1.  Minimal Token (Actor Chain Only)  . . . . . . . . . .  18



  Krishnan, et al.        Expires 19 September 2026               [Page 2]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


         6.3.2.  Minimal Token (Intent Chain Only) . . . . . . . . . .  19
         6.3.3.  Full Token (Both Chains)  . . . . . . . . . . . . . .  19
     7.  Verification Procedures . . . . . . . . . . . . . . . . . . .  19
       7.1.  Request-Time Policy Checks  . . . . . . . . . . . . . . .  19
       7.2.  Forensic Verification . . . . . . . . . . . . . . . . . .  20
         7.2.1.  Token Archival  . . . . . . . . . . . . . . . . . . .  20
         7.2.2.  Full Chain Verification . . . . . . . . . . . . . . .  21
         7.2.3.  Cross-Chain Correlation . . . . . . . . . . . . . . .  21
         7.2.4.  Dispute Resolution Workflow . . . . . . . . . . . . .  22
         7.2.5.  Single Entry Verification (Merkle Proof)  . . . . . .  22
     8.  Operational Flows . . . . . . . . . . . . . . . . . . . . . .  23
       8.1.  Intent Chain Construction . . . . . . . . . . . . . . . .  23
       8.2.  Token Exchange Integration  . . . . . . . . . . . . . . .  24
       8.3.  Request-Time Check at Relying Party . . . . . . . . . . .  25
     9.  Policy Enforcement  . . . . . . . . . . . . . . . . . . . . .  26
       9.1.  Policy Examples . . . . . . . . . . . . . . . . . . . . .  26
         9.1.1.  Require All Outputs Filtered  . . . . . . . . . . . .  26
         9.1.2.  Require Non-Deterministic Filter for AI Outputs . . .  27
         9.1.3.  Verify Specific Transformation Applied  . . . . . . .  27
       9.2.  Integration with Policy Engines . . . . . . . . . . . . .  27
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  28
       10.1.  STRIDE Analysis  . . . . . . . . . . . . . . . . . . . .  28
       10.2.  Signing Requirements by Entry Type . . . . . . . . . . .  28
       10.3.  Replay Protection  . . . . . . . . . . . . . . . . . . .  29
       10.4.  Chain Integrity  . . . . . . . . . . . . . . . . . . . .  29
       10.5.  Credential Isolation . . . . . . . . . . . . . . . . . .  29
     11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  29
       11.1.  Selective Disclosure . . . . . . . . . . . . . . . . . .  29
       11.2.  Content Hash vs Content Storage  . . . . . . . . . . . .  30
     12. Implementation Guidance . . . . . . . . . . . . . . . . . . .  30
       12.1.  Intent Registry Implementation . . . . . . . . . . . . .  30
       12.2.  Multi-AS Deployments . . . . . . . . . . . . . . . . . .  31
       12.3.  Scalability Considerations . . . . . . . . . . . . . . .  31
       12.4.  Operational Recommendations  . . . . . . . . . . . . . .  31
       12.5.  Registry Availability  . . . . . . . . . . . . . . . . .  32
     13. Design Rationale: Merkle Root in Token  . . . . . . . . . . .  32
     14. Audit Procedures  . . . . . . . . . . . . . . . . . . . . . .  33
       14.1.  Cross-Chain Binding  . . . . . . . . . . . . . . . . . .  33
     15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
       15.1.  JWT Claim Registration . . . . . . . . . . . . . . . . .  34
       15.2.  CWT Claim Registration . . . . . . . . . . . . . . . . .  34
     Appendix A.  Merkle Tree Construction Details . . . . . . . . . .  35
       A.1.  Tree Structure  . . . . . . . . . . . . . . . . . . . . .  35
       A.2.  Reference Construction Algorithm  . . . . . . . . . . . .  36
     Appendix B.  Complete Token Examples  . . . . . . . . . . . . . .  36
       B.1.  Full Governance Token . . . . . . . . . . . . . . . . . .  36
       B.2.  Corresponding Intent Chain Log Entries  . . . . . . . . .  37
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  39



  Krishnan, et al.        Expires 19 September 2026               [Page 3]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  1.  Introduction

  1.1.  The Problem: Content Provenance Gap

     The Actor Chain extension to {{!RFC8693}} (defined in {{!I-D.draft-
     mw-spice-actor-chain}}) addresses the Delegation Auditability Gap by
     providing cryptographic proof of the actual delegation path between
     AI agents.  However, it does not address a complementary gap:
     *Content Provenance*.

     In AI agent workflows, content flows through multiple processing
     stages:

     Agent A -> Filter -> Filter -> Agent B -> Filter -> Agent C -> Tool

     Each stage may transform the content.  AI agent outputs are
     inherently non-deterministic and cannot be trusted without
     validation.  Filters (both AI-based and rule-based) transform this
     content before it reaches the next stage.

     For complete governance, systems require proof of:

     *  *What* each AI agent originally produced (raw output)
     *  *How* each filter transformed the content
     *  *Whether* transformations were deterministic (reproducible) or
        non-deterministic (AI-based)
     *  *The complete chain* of content transformations within a session

     Without this proof, the content transformation history cannot be
     reconstructed for audit or dispute resolution.  Consider the
     following repudiation scenario:

     1.  Agent A produces a response containing a harmful instruction
         (e.g., caused by prompt injection).
     2.  The response passes through an AI guardrail filter, which fails
         to catch the harmful content.
     3.  Agent B acts on the harmful instruction, causing damage.
     4.  During investigation, Agent A's operator claims "Agent A never
         produced that output — it must have been injected by a downstream
         filter."

     Without cryptographic proof binding Agent A's identity to its
     specific output hash, this claim cannot be disproven.  The intent
     chain solves this by requiring every agent to sign input_hash +
     output_hash via intent_sig, creating non-repudiable evidence of what
     each agent received and produced.





  Krishnan, et al.        Expires 19 September 2026               [Page 4]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  1.2.  Relationship to Actor Chain and Inference Chain

     This specification is part of a three-axis "Truth Stack" for AI agent
     governance:

     +===================+=============+==============+==================+
     | Specification     | Axis        | Question     | STRIDE Coverage  |
     |                   |             | Answered     |                  |
     +===================+=============+==============+==================+
     | *Actor Chain*     | Identity    | WHO          | Spoofing,        |
     | ({{!I-D.draft-    |             | delegated to | Repudiation,     |
     | mw-spice-actor-   |             | whom?        | Elevation of     |
     | chain}})          |             |              | Privilege        |
     +-------------------+-------------+--------------+------------------+
     | *Intent Chain*    | Content     | WHAT was     | Repudiation,     |
     | (this document)   |             | produced and | Tampering        |
     |                   |             | transformed? |                  |
     +-------------------+-------------+--------------+------------------+
     | *Inference        | Computation | HOW was the  | Spoofing         |
     | Chain* ({{!I-     |             | output       | (computational), |
     | D.draft-mw-       |             | computed?    | Tampering        |
     | spice-inference-  |             |              | (model)          |
     | chain}})          |             |              |                  |
     +-------------------+-------------+--------------+------------------+

                                    Table 1

      +=============+=======+============+==========+==================+
      | Chain       | Plane | Token      | Full     | Primary Consumer |
      |             |       | Content    | Chain    |                  |
      +=============+=======+============+==========+==================+
      | *Actor*     | Data  | Full chain | In token | Every Relying    |
      |             | Plane | inline     |          | Party (real-time |
      |             |       |            |          | authorization)   |
      +-------------+-------+------------+----------+------------------+
      | *Intent*    | Audit | Merkle     | External | Audit systems,   |
      |             | Plane | root only  | registry | forensic         |
      |             |       |            |          | investigators    |
      +-------------+-------+------------+----------+------------------+
      | *Inference* | Audit | Merkle     | External | Auditors,        |
      |             | Plane | root only  | registry | compliance       |
      |             |       |            |          | systems          |
      +-------------+-------+------------+----------+------------------+

                                   Table 2

     The three chains are independent and composable:




  Krishnan, et al.        Expires 19 September 2026               [Page 5]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     *  *Actor Chain Only*: Real-time authorization, access control
     *  *Intent Chain Only*: Content audit, debugging, filter validation
     *  *Inference Chain Only*: Computational integrity verification for
        single-agent systems
     *  *Actor + Intent*: Full content governance, dispute resolution,
        regulatory compliance
     *  *All Three*: Complete "Truth Stack" — identity, content, and
        computational provenance

  1.3.  Design Goals

     The intent chain is designed with the following goals:

     1.  *Content Provenance*: Cryptographic proof of what each agent
         produced
     2.  *Transformation Tracking*: Record of how filters modified content
     3.  *Tamper Evidence*: Merkle tree structure prevents undetected
         modification
     4.  *Efficiency*: Only Merkle root in token; full chain in logs
     5.  *Scalability*: Append-only logs scale horizontally
     6.  *Modularity*: Usable independently or with actor chain
     7.  *Standards Alignment*: Compatible with OAuth 2.0, JWT, SPIFFE

  2.  Terminology

     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.

     Intent Chain:  An ordered sequence of Intent Chain Entries
        representing the complete content journey from originating agent
        through filters to final output within a session.
     Intent Chain Entry:  A record identifying a single content
        transformation, including the agent identity, entry type, content
        hashes, and cryptographic signature.
     AI Agent:  An autonomous decision-maker that produces content and can
        delegate authority.  AI agents appear in both the actor chain (for
        delegation) and the intent chain (for output provenance).
     Non-Deterministic Filter:  A processor (typically AI-based) whose
        output cannot be reproduced from its input.  Examples include AI
        guardrails, LLM-based content rewriters, and semantic classifiers.
        Both input and output MUST be signed.
     Deterministic Filter:  A processor whose output can be reproduced
        from its input and rules.  Examples include schema validators,
        regex sanitizers, and bounds checkers.  Output can be re-derived
        for verification.



  Krishnan, et al.        Expires 19 September 2026               [Page 6]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     Intent Root:  The Merkle root hash of the complete intent chain,
        included in the OAuth token.
     Intent Registry:  An append-only ordered log storing the full intent
        chain entries, partitioned by session.
     Actor Chain Registry:  The append-only ordered log storing the full
        per-actor signature evidence for the actor chain, as defined in
        {{!I-D.draft-mw-spice-actor-chain}}. Referenced by the
        actor_chain_registry claim in the token.

  3.  Architecture Overview

  3.1.  Three-Layer Governance Model

     The governance model consists of three layers:

     *  *Session*: Root of trust and lifecycle management.  Initiated by
        human approval or system authorization.  Contains subject, expiry,
        and approval reference.
     *  *Actor Chain (WHO)*: Contains AI agents only.  Full chain stored
        in token.  Addresses Spoofing, Repudiation, and Elevation of
        Privilege.  Defined in {{!I-D.draft-mw-spice-actor-chain}}.
     *  *Intent Chain (WHAT)*: Contains AI agents and filters.  Full chain
        stored in ordered logs; Merkle root in token.  Addresses
        Repudiation and Tampering.  Defined in this document.
     *  *Inference Chain (HOW)*: Contains per-inference computational
        proofs.  Full proofs stored in ordered logs; Merkle root in token.
        Addresses Computational Spoofing and Model Tampering.  Defined in
        {{!I-D.draft-mw-spice-inference-chain}}.

  3.2.  Session as Root of Trust

     Every governance chain traces back to a session.  The session
     provides:

     *  *Origin*: Who or what initiated the workflow
     *  *Lifecycle*: When the session expires
     *  *Revocation Point*: Revoking session invalidates all activity
     *  *Audit Boundary*: Session defines the unit of audit

     Session information is captured in standard OAuth token claims:











  Krishnan, et al.        Expires 19 September 2026               [Page 7]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     +=======+===========================================================+
     | Claim | Purpose                                                   |
     +=======+===========================================================+
     | sub   | Session subject (human or system initiator)               |
     +-------+-----------------------------------------------------------+
     | sid   | Session identifier — stable across token                  |
     |       | exchanges within a session.  Equals                       |
     |       | session.session_id.  Defined as a top-level               |
     |       | claim in {{!I-D.draft-mw-spice-actor-chain}}              |
     +-------+-----------------------------------------------------------+
     | jti   | Token identifier (unique per token exchange)              |
     +-------+-----------------------------------------------------------+
     | iat   | Session start time                                        |
     +-------+-----------------------------------------------------------+
     | exp   | Session expiry time                                       |
     +-------+-----------------------------------------------------------+

                                    Table 3

  3.3.  Actor Chain (WHO) - Reference

     The actor chain is defined in {{!I-D.draft-mw-spice-actor-chain}}.
     Key properties:

     *  Contains AI agents only (autonomous decision-makers)
     *  Tracks delegation of authority
     *  Full chain included in token
     *  Addresses Spoofing, Repudiation, Elevation of Privilege

     This document assumes familiarity with the actor chain specification.

  3.4.  Intent Chain (WHAT) - This Document

     The intent chain is defined in this document.  Key properties:

     *  Contains AI agents AND filters
     *  Tracks content production and transformation
     *  Merkle root in token; full chain in ordered logs
     *  Addresses Repudiation and Tampering

  3.5.  STRIDE Threat Model Coverage

      +===================+===========================+================+
      | Threat            | Mitigation                | Component      |
      +===================+===========================+================+
      | *S* - Spoofing    | Cryptographic identity,   | Actor Chain    |
      |                   | signed chain entries      |                |
      +-------------------+---------------------------+----------------+



  Krishnan, et al.        Expires 19 September 2026               [Page 8]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


      | *T* - Tampering   | Merkle tree integrity,    | Intent Chain   |
      |                   | append-only logs          |                |
      +-------------------+---------------------------+----------------+
      | *R* - Repudiation | Signed delegation (Actor) | Both           |
      |                   | + Signed outputs (Intent) |                |
      +-------------------+---------------------------+----------------+
      | *I* - Information | Selective disclosure (SD- | Both           |
      | Disclosure        | JWT)                      | (optional)     |
      +-------------------+---------------------------+----------------+
      | *D* - Denial of   | Session expiry, rate      | Session +      |
      | Service           | limits                    | Infrastructure |
      +-------------------+---------------------------+----------------+
      | *E* - Elevation   | Scope attenuation, policy | Actor Chain    |
      | of Privilege      | enforcement               |                |
      +-------------------+---------------------------+----------------+

                                   Table 4

  4.  Intent Chain Definition

  4.1.  Entry Types

     The intent chain contains two types of entries:

      +===================+===================+===========+=============+
      | Entry Type        | Determinism       |Signed     |Type-Specific|
      |                   |                   |Fields     |Fields       |
      +===================+===================+===========+=============+
      | Non-Deterministic | Non-deterministic |input_hash |model_info   |
      | (AI agent output, |                   |+          |(optional)   |
      | AI-based filter)  |                   |output_hash|             |
      +-------------------+-------------------+-----------+-------------+
      | Deterministic     | Deterministic     |input_hash |rule_id,     |
      | (rule-based       |                   |+          |rule_hash    |
      | filter)           |                   |output_hash|             |
      +-------------------+-------------------+-----------+-------------+

                                    Table 5

     All entry types REQUIRE both input_hash and output_hash.  This
     uniform structure ensures that every consecutive pair satisfies
     entry[i].output_hash == entry[i+1].input_hash, creating a complete
     content provenance chain.  The cost is approximately 40 bytes per
     entry in the ordered logs — not in the token itself, which carries
     only the Merkle root regardless of entry count.






  Krishnan, et al.        Expires 19 September 2026               [Page 9]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  4.2.  Non-Deterministic Entries

     Non-deterministic entries record outputs from AI agents or AI-based
     filters whose output cannot be reproduced from the input alone.

     *Examples*:

     *  AI agent outputs (orchestrator, planner, tool agent)
     *  AI guardrails (Llama Guard, NeMo Guardrails)
     *  LLM-based content rewriters
     *  Semantic classifiers

     *Properties*:

     *  Sub is an AI agent or AI-based filter (agents also appear in actor
        chain)
     *  Output is non-deterministic (cannot be reproduced)
     *  input_hash and output_hash MUST be recorded and signed

     *Agent Output Example*:

     {
       "type": "non_deterministic",
       "sub": "spiffe://example.com/agent/orchestrator",
       "input_hash": "sha256:fff000...",
       "output_hash": "sha256:abc123...",
       "iat": 1700000010,
       "intent_digest": "sha256:...",
       "intent_sig": "eyJhbGci..."
     }

     *AI Filter Example*:

     {
       "type": "non_deterministic",
       "sub": "spiffe://example.com/filter/ai-guardrail",
       "filter_version": "v2.1",
       "input_hash": "sha256:abc123...",
       "output_hash": "sha256:def456...",
       "model_info": {
         "model": "llama-guard-3",
         "categories": ["violence", "pii", "prompt_injection"]
       },
       "iat": 1700000015,
       "intent_digest": "sha256:...",
       "intent_sig": "eyJhbGci..."
     }




  Krishnan, et al.        Expires 19 September 2026              [Page 10]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  4.3.  Deterministic Entries

     Deterministic filter entries record transformations by rule-based
     filters whose output can be reproduced from the input and rules.

     *Examples*:

     *  Schema validators (JSON Schema)
     *  Regex sanitizers (XSS removal)
     *  Bounds checkers (amount limits)
     *  PII redactors (pattern-based)

     *Properties*:

     *  Sub is a rule-based filter
     *  Output CAN be reproduced from input + rules
     *  input_hash and output_hash MUST be recorded and signed
     *  rule_id and rule_hash are type-specific signed fields in the log
        entry, enabling independent re-verification
     *  Output can be re-derived by re-applying the rule to the input

     *Structure*:

     {
       "type": "deterministic",
       "sub": "spiffe://example.com/filter/schema-validator",
       "filter_version": "v1.0",
       "input_hash": "sha256:def456...",
       "output_hash": "sha256:ghi789...",
       "rule_id": "ticket-schema-v2",
       "rule_hash": "sha256:rrr...",
       "transform_applied": {
         "fields_validated": ["title", "priority", "amount"],
         "fields_modified": ["priority"],
         "modification": {
           "priority": {
             "from": "critical",
             "to": "medium",
             "reason": "bounds_exceeded"
           }
         }
       },
       "reproducible": true,
       "iat": 1700000016,
       "intent_digest": "sha256:...",
       "intent_sig": "eyJhbGci..."
     }




  Krishnan, et al.        Expires 19 September 2026              [Page 11]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  4.4.  Entry Structure

     All intent chain entries share common fields:

     +===============+========+==========+==============================+
     | Field         | Type   | Required | Description                  |
     +===============+========+==========+==============================+
     | type          | string | REQUIRED | Entry type:                  |
     |               |        |          | non_deterministic,           |
     |               |        |          | deterministic                |
     +---------------+--------+----------+------------------------------+
     | sub           | string | REQUIRED | SPIFFE ID of the agent or    |
     |               |        |          | filter                       |
     +---------------+--------+----------+------------------------------+
     | input_hash    | string | REQUIRED | SHA-256 hash of the input    |
     |               |        |          | content                      |
     +---------------+--------+----------+------------------------------+
     | output_hash   | string | REQUIRED | SHA-256 hash of the output   |
     |               |        |          | content                      |
     +---------------+--------+----------+------------------------------+
     | iat           | number | REQUIRED | Timestamp when entry was     |
     |               |        |          | created                      |
     +---------------+--------+----------+------------------------------+
     | intent_digest | string | REQUIRED | Hash of the canonically      |
     |               |        |          | serialized entry for Merkle  |
     |               |        |          | leaf computation             |
     +---------------+--------+----------+------------------------------+
     | intent_sig    | string | REQUIRED | Signature over intent_digest |
     |               |        |          | using the agent's or         |
     |               |        |          | filter's private key         |
     +---------------+--------+----------+------------------------------+

                                   Table 6

  4.4.1.  intent_digest Computation

     The intent_digest field is computed as the SHA-256 hash of the
     canonically serialized entry, excluding the intent_digest and
     intent_sig fields themselves.  This hash serves as the leaf node in
     the Merkle tree.

     For an entry E with fields {type, sub, input_hash, output_hash, iat,
     ...}:

  intent_digest = SHA-256(canonical_json(E \ {intent_digest, intent_sig}))

     Where canonical_json follows JSON Canonicalization Scheme {{JCS}}
     (RFC 8785) to ensure deterministic serialization.



  Krishnan, et al.        Expires 19 September 2026              [Page 12]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     The intent_sig (when REQUIRED) is computed over the intent_digest
     value using the agent's private key:

     intent_sig = Sign(agent_key, intent_digest)

     This two-step process ensures that: (a) the digest is stable and
     independent of signature ordering, and (b) the signature covers all
     content-relevant fields of the entry.

     Additional fields by entry type:

        +===================+===================+====================+
        | Field             | Entry Types       | Description        |
        +===================+===================+====================+
        | filter_version    | Filters           | Version of filter  |
        +-------------------+-------------------+--------------------+
        | rule_id           | Deterministic     | Identifier of rule |
        |                   |                   | applied            |
        +-------------------+-------------------+--------------------+
        | rule_hash         | Deterministic     | Hash of rule       |
        |                   |                   | definition         |
        +-------------------+-------------------+--------------------+
        | model_info        | Non-deterministic | AI model           |
        |                   |                   | information        |
        +-------------------+-------------------+--------------------+
        | transform_applied | Filters           | Details of         |
        |                   |                   | transformation     |
        +-------------------+-------------------+--------------------+
        | reproducible      | Deterministic     | Boolean indicating |
        |                   |                   | reproducibility    |
        +-------------------+-------------------+--------------------+

                                   Table 7

  5.  Storage Architecture

  5.1.  Intent Registry (Ordered Logs)

     The intent registry stores immutable intent chain entries as ordered
     logs.

     *Contents*:

     *  Non-deterministic entries (AI agent outputs, AI-based filters)
     *  Deterministic entries (rule-based filters)






  Krishnan, et al.        Expires 19 September 2026              [Page 13]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     |  Intent registry entries MUST NOT contain OAuth tokens, bearer
     |  credentials, or signing keys.  Entries contain only content
     |  hashes, metadata, agent identities, and entry-level signatures.
     |  The token references the registry via the intent_registry claim;
     |  the registry MUST NOT store or reference the token itself.

     *Properties*:

     *  Append-only (immutable)
     *  Ordered by offset within session
     *  Partitioned by session.session_id
     *  Eventual consistency acceptable

     Implementations SHOULD use an append-only log that supports
     partitioned, ordered retrieval by the token's session.session_id
     claim and provides tamper-evident guarantees (e.g., via hash chaining
     or inclusion proofs).

     *Log Structure*:

     {
       "session_id": "sess-uuid-12345",
       "offset": 0,
       "entry": {
         "type": "non_deterministic",
         "sub": "spiffe://example.com/agent/A",
         "input_hash": "sha256:prompt...",
         "output_hash": "sha256:abc...",
         "iat": 1700000010,
         "intent_digest": "sha256:...",
         "intent_sig": "eyJ..."
       }
     }

  5.1.1.  Relationship Between session_id and jti

     The session_id is a stable identifier for the end-user interaction.
     It remains constant as the delegation chain grows through multiple
     token exchanges, each of which produces a new token with a distinct
     jti:











  Krishnan, et al.        Expires 19 September 2026              [Page 14]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     User session: sess-uuid-12345

       Token Exchange 1 (jti: "tok-aaa")
         User → Agent A
         Intent entries: offset 0 (Agent A output)

       Token Exchange 2 (jti: "tok-bbb")
         Agent A → Agent B
         Intent entries: offset 1 (filter), offset 2 (Agent B output)

       Token Exchange 3 (jti: "tok-ccc")
         Agent B → Agent C
         Intent entries: offset 3 (filter), offset 4 (Agent C output)

     All intent chain entries share session_id: "sess-uuid-12345"
     regardless of which token exchange produced them.  The session_id is
     carried forward during each token exchange as part of the session
     claim.  During forensic verification, the investigator retrieves all
     entries for a session_id to reconstruct the complete content journey.

  5.2.  Merkle Tree Construction

     The Merkle tree is constructed from ordered log entries.  Leaf nodes
     are the SHA-256 hashes of canonically serialized intent chain
     entries.  Internal nodes are the SHA-256 hash of the concatenation of
     their two child hashes.  When a level has an odd number of nodes, the
     last node is promoted to the next level.

     See Appendix A for a visual depiction and reference construction
     algorithm.

  5.3.  Merkle Root in Token

     Only the Merkle root is included in the OAuth token:

     {
       "intent_root": "sha256:abc123def456...",
       "intent_alg": "sha256",
       "intent_registry": "https://intent-log.example.com"
     }











  Krishnan, et al.        Expires 19 September 2026              [Page 15]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       +=================+========+==========+========================+
       | Field           | Type   | Required | Description            |
       +=================+========+==========+========================+
       | intent_root     | string | REQUIRED | Merkle root hash of    |
       |                 |        |          | intent chain           |
       +-----------------+--------+----------+------------------------+
       | intent_alg      | string | OPTIONAL | Hash algorithm         |
       |                 |        |          | (default: sha256)      |
       +-----------------+--------+----------+------------------------+
       | intent_registry | string | REQUIRED | URI of intent registry |
       |                 |        |          | for proof retrieval    |
       +-----------------+--------+----------+------------------------+

                                   Table 8

  6.  Token Structure

  6.1.  Combined Token Format

     The complete token combines session, actor chain, and intent chain:































  Krishnan, et al.        Expires 19 September 2026              [Page 16]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "aud": "https://api.example.com",
       "jti": "tok-aaa-12345",
       "sid": "sess-uuid-12345",
       "iat": 1700000000,
       "exp": 1700003600,

       "session": {
         "session_id": "sess-uuid-12345",
         "type": "human_initiated",
         "initiator": "user-alice",
         "approval_ref": "approval-uuid-789",
         "max_chain_depth": 5
       },

       "actor_chain": [
         {
           "sub": "spiffe://example.com/agent/orchestrator",
           "iss": "https://auth.example.com",
           "iat": 1700000010
         },
         {
           "sub": "spiffe://example.com/agent/support",
           "iss": "https://auth.example.com",
           "iat": 1700000030
         }
       ],

       "intent_root": "sha256:abc123def456789...",
       "intent_registry":
         "https://intent-log.example.com/sessions/sess-uuid-12345"
     }

  6.2.  Claim Definitions

  6.2.1.  Session Claims

     +=======================+======+===================================+
     |Claim                  |Type  |Description                        |
     +=======================+======+===================================+
     |sid                    |string|Session identifier — stable across |
     |                       |      |token exchanges.  Equals           |
     |                       |      |session.session_id.  Defined as a  |
     |                       |      |top-level claim in {{!I-D.draft-mw-|
     |                       |      |spice-actor-chain}}                |
     +-----------------------+------+-----------------------------------+



  Krishnan, et al.        Expires 19 September 2026              [Page 17]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     |session.session_id     |string|Stable identifier for the end-user |
     |                       |      |interaction, assigned by the AS on |
     |                       |      |first token issuance and carried   |
     |                       |      |forward during subsequent token    |
     |                       |      |exchanges.  MUST equal the top-    |
     |                       |      |level sid claim                    |
     +-----------------------+------+-----------------------------------+
     |session.type           |string|Session type: human_initiated,     |
     |                       |      |system_initiated, scheduled        |
     +-----------------------+------+-----------------------------------+
     |session.initiator      |string|Identity of session initiator      |
     +-----------------------+------+-----------------------------------+
     |session.approval_ref   |string|Reference to approval record       |
     +-----------------------+------+-----------------------------------+
     |session.max_chain_depth|number|Maximum allowed delegation depth   |
     +-----------------------+------+-----------------------------------+

                                   Table 9

  6.2.2.  Actor Chain Claims

     Defined in {{!I-D.draft-mw-spice-actor-chain}}.

  6.2.3.  Intent Chain Claims

     +=================+========+=======================================+
     | Claim           | Type   | Description                           |
     +=================+========+=======================================+
     | intent_root     | string | Merkle root hash of intent chain      |
     +-----------------+--------+---------------------------------------+
     | intent_alg      | string | Hash algorithm used (default: sha256) |
     +-----------------+--------+---------------------------------------+
     | intent_registry | string | URI for retrieving full chain or      |
     |                 |        | proofs (REQUIRED)                     |
     +-----------------+--------+---------------------------------------+

                                   Table 10

  6.3.  Examples

  6.3.1.  Minimal Token (Actor Chain Only)










  Krishnan, et al.        Expires 19 September 2026              [Page 18]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "jti": "tok-bbb-12345",
       "iat": 1700000000,
       "exp": 1700003600,

       "actor_chain": [
         {
           "sub": "spiffe://example.com/agent/A",
           "iss": "https://auth.example.com",
           "iat": 1700000010
         }
       ]
     }

  6.3.2.  Minimal Token (Intent Chain Only)

     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "jti": "tok-ccc-12345",
       "iat": 1700000000,
       "exp": 1700003600,

       "intent_root": "sha256:abc123...",
       "intent_registry":
         "https://intent-log.example.com/sessions/sess-uuid-12345"
     }

  6.3.3.  Full Token (Both Chains)

     See Section 6.1.

  7.  Verification Procedures

  7.1.  Request-Time Policy Checks

     At request time, the Relying Party performs lightweight checks on the
     intent chain metadata in the token.  Full chain verification is
     unnecessary on the hot path because:

     *  The content has already been produced; verifying signatures cannot
        undo it.
     *  The Relying Party has the token, not the raw content, so it cannot
        cross-check content hashes.
     *  O(n) signature verification per request adds latency without
        improving authorization decisions.



  Krishnan, et al.        Expires 19 September 2026              [Page 19]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     The Relying Party SHOULD:

     1.  Verify the JWT outer signature (covers intent_root as a signed
         claim).
     2.  Check that intent_root and intent_registry are present (policy:
         "intent chain coverage required").
     3.  Apply policy rules against intent chain entry types fetched from
         the registry (e.g., "must include at least one deterministic
         entry").

     The tiered verification table reflects the appropriate level of
     intent chain checking based on risk:

      +========+======================+====================+============+
      | Risk   | Actor Chain          | Intent Chain       | Use Case   |
      | Level  |                      |                    |            |
      +========+======================+====================+============+
      | Low    | Verify JWT signature | Check intent_root  | Read       |
      |        |                      | present            | operations |
      +--------+----------------------+--------------------+------------+
      | Medium | Verify JWT signature | Async policy check | Create/    |
      |        |                      | on entry types     | update     |
      +--------+----------------------+--------------------+------------+
      | High   | Verify JWT signature | Full forensic      | Delete,    |
      |        | + actor sigs         | verification       | transfer,  |
      |        |                      |                    | admin      |
      +--------+----------------------+--------------------+------------+

                                    Table 11

  7.2.  Forensic Verification

     The primary value of the intent chain is post-hoc troubleshooting and
     dispute resolution.  When an incident occurs, an auditor or
     investigator performs full chain verification to determine which
     agent caused the problem.

  7.2.1.  Token Archival

     Forensic verification requires two inputs: the original JWT
     (containing intent_root) and the intent chain entries from the
     registry.  The intent registry stores chain entries but does not
     store the token itself.

     To enable forensic analysis, tokens SHOULD be archived by one or more
     of the following:





  Krishnan, et al.        Expires 19 September 2026              [Page 20]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     *  *Relying Parties*: Archive tokens at the point of presentation
        (most common).
     *  *Audit services*: A dedicated audit service receives a copy of
        each token for compliance purposes.
     *  *Authorization Servers*: The AS MAY maintain a log of issued
        tokens indexed by jti.

     Archived tokens MUST be stored securely and access-controlled, as
     they contain identity and delegation information.

  7.2.2.  Full Chain Verification

     To perform a complete forensic investigation:

     1.  *Retrieve inputs*: Extract intent_root and intent_registry from
         the archived token.  Fetch the full intent chain from the
         registry using the session_id.
     2.  *Verify Merkle integrity*: Rebuild the Merkle tree from all
         entries.  Compare the computed root with intent_root from the
         token.  If they do not match, the chain has been tampered with.
     3.  *Verify signatures*: For each entry, verify intent_sig over
         intent_digest using the sub's public key (discoverable via SPIFFE
         trust bundle or JWKS).  A failed signature indicates a forged
         entry.
     4.  *Verify chain linkage*: For each consecutive pair, verify
         entry[i].output_hash == entry[i+1].input_hash.  A broken link
         indicates content was modified between steps without being
         recorded.
     5.  *Re-derive deterministic outputs*: For deterministic entries,
         retrieve the rule definition matching rule_hash, re-apply it to
         the content matching input_hash, and verify the output matches
         output_hash.  A mismatch indicates the filter did not behave as
         recorded.
     6.  *Identify the fault point*: If step 4 reveals a broken link at
         position k, the content was corrupted between entry[k] and
         entry[k+1].  If step 3 reveals a failed signature at position k,
         entry[k] was forged.  The sub field of the faulty entry
         identifies the responsible agent.

  7.2.3.  Cross-Chain Correlation

     When used together with the actor chain, forensic verification can
     answer both *WHO* and *WHAT*:

     1.  For each intent chain entry of type non_deterministic: verify
         that entry.sub appears in the actor_chain of the same token.





  Krishnan, et al.        Expires 19 September 2026              [Page 21]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     2.  Verify that entry.iat falls within the actor's active window
         (between the actor's own iat and the next actor's iat in the
         chain).
     3.  A mismatch indicates an unregistered agent produced content — the
         intent chain records output from an identity not present in the
         delegation chain.

  7.2.4.  Dispute Resolution Workflow

     When a dispute arises (e.g., "Agent A did not produce that harmful
     output"):

     1.  Retrieve the archived token and full intent chain.
     2.  Locate entries where sub matches Agent A's SPIFFE ID.
     3.  Verify Agent A's intent_sig on each of those entries.  A valid
         signature proves Agent A attested to producing that specific
         output_hash.
     4.  Check input_hash of Agent A's entry to verify what Agent A
         received as input.
     5.  If Agent A's output was modified by a downstream filter, the
         filter's entry shows input_hash matching Agent A's output_hash
         and a different output_hash — proving the filter made the change,
         not Agent A.

  7.2.5.  Single Entry Verification (Merkle Proof)

     To verify a single entry without fetching the full chain:

     1.  Extract intent_root from the token.
     2.  Request a Merkle proof for entry[i] from the registry.
     3.  The registry returns the entry and sibling hashes on the path to
         the root.
     4.  Compute the hash of the entry and the path to the root using
         sibling hashes.
     5.  Compare the computed root with intent_root.

     *Proof Size*: O(log n) where n is the number of entries.














  Krishnan, et al.        Expires 19 September 2026              [Page 22]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     {
       "entry": {
         "type": "non_deterministic",
         "sub": "spiffe://example.com/agent/A",
         "input_hash": "sha256:prompt...",
         "output_hash": "sha256:abc...",
         "iat": 1700000010
       },
       "proof": {
         "index": 0,
         "siblings": [
           {"position": "right", "hash": "sha256:111..."},
           {"position": "right", "hash": "sha256:222..."},
           {"position": "left", "hash": "sha256:333..."}
         ]
       }
     }

  8.  Operational Flows

  8.1.  Intent Chain Construction






























  Krishnan, et al.        Expires 19 September 2026              [Page 23]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       Agent A        Filter        Agent B       Intent
                                                  Registry
          |               |               |           |
          | Produce       |               |           |
          | output        |               |           |
          |---------------+---------------+---------->|
          |               |               |  Append   |
          |               |               | non-det   |
          |               |               |   entry   |
          |               |               |           |
          | Send to       |               |           |
          | filter        |               |           |
          |-------------->|               |           |
          |               |               |           |
          |               | Transform     |           |
          |               | content       |           |
          |               |---------------+---------->|
          |               |               |  Append   |
          |               |               | filter    |
          |               |               |   entry   |
          |               |               |           |
          |               | Send to       |           |
          |               | Agent B       |           |
          |               |-------------->|           |
          |               |               |           |
          |               |               | Produce   |
          |               |               | output    |
          |               |               |---------->|
          |               |               |  Append   |
          |               |               | non-det   |
          |               |               |   entry   |
          |               |               |           |

  8.2.  Token Exchange Integration

















  Krishnan, et al.        Expires 19 September 2026              [Page 24]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       Agent B          AS          Intent      Actor
                                    Registry    Registry
          |               |            |            |
          | Token         |            |            |
          | Exchange      |            |            |
          | Request       |            |            |
          |-------------->|            |            |
          |               |            |            |
          |               | Validate   |            |
          |               | existing   |            |
          |               | actor_chain|            |
          |               |            |            |
          |               | Extend     |            |
          |               | actor_chain|            |
          |               |------------+----------->|
          |               |            |   Store    |
          |               |            | capability |
          |               |            |            |
          |               | Compute    |            |
          |               | intent_root|            |
          |               |----------->|            |
          |               | Get Merkle |            |
          |               | root       |            |
          |               |<-----------|            |
          |               |            |            |
          | New token     |            |            |
          | with both     |            |            |
          | chains        |            |            |
          |<--------------|            |            |
          |               |            |            |

  8.3.  Request-Time Check at Relying Party



















  Krishnan, et al.        Expires 19 September 2026              [Page 25]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       Agent C       Relying       Intent      Actor
                      Party        Registry    Registry
          |               |            |            |
          | Request +     |            |            |
          | Token         |            |            |
          |-------------->|            |            |
          |               |            |            |
          |               | Verify JWT |            |
          |               | signature  |            |
          |               |            |            |
          |               | Verify     |            |
          |               | actor_chain|            |
          |               | (per mode) |            |
          |               |            |            |
          |               | Check      |            |
          |               | intent_root|            |
          |               | present    |            |
          |               |            |            |
          |               | Apply      |            |
          |               | policy on  |            |
          |               | entry types|            |
          |               |----------->|            |
          |               | Fetch entry|            |
          |               | types only |            |
          |               |<-----------|            |
          |               |            |            |
          |               | Policy OK: |            |
          |               | Execute    |            |
          |               |            |            |
          | Response      |            |            |
          |<--------------|            |            |
          |               |            |            |

  9.  Policy Enforcement

  9.1.  Policy Examples

  9.1.1.  Require All Outputs Filtered

     Every agent output must be followed by at least one filter:











  Krishnan, et al.        Expires 19 September 2026              [Page 26]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     require_filtered_outputs {
         intent_chain := get_intent_chain(input.intent_root)

         agent_outputs := [i |
             intent_chain[i].type == "non_deterministic"]

         every i in agent_outputs {
             # Next entry must be a filter (if not last)
             i < count(intent_chain) - 1
             intent_chain[i + 1].type != "non_deterministic"
         }
     }

  9.1.2.  Require Non-Deterministic Filter for AI Outputs

     AI agent outputs must pass through an AI guardrail:

     require_ai_guardrail {
         intent_chain := get_intent_chain(input.intent_root)

         every i, entry in intent_chain {
             entry.type == "non_deterministic" implies {
                 # Must be followed by an entry with AI guardrail model
                 some j
                 j > i
                 intent_chain[j].model_info.model ==
                     "llama-guard-3"
             }
         }
     }

  9.1.3.  Verify Specific Transformation Applied

     Sensitive fields must be sanitized:

     require_pii_redaction {
         intent_chain := get_intent_chain(input.intent_root)

         some i
         intent_chain[i].type == "deterministic"
         intent_chain[i].rule_id == "pii-redaction-v1"
     }

  9.2.  Integration with Policy Engines

     The intent chain claims are designed for consumption by policy
     engines such as Open Policy Agent (OPA).  A policy engine SHOULD:




  Krishnan, et al.        Expires 19 September 2026              [Page 27]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     1.  Validate session expiry and revocation status.
     2.  Verify actor chain integrity (per {{!I-D.draft-mw-spice-actor-
         chain}}).
     3.  Verify intent_root and intent_registry are present and non-empty.
     4.  Evaluate deployment-specific requirements against the intent
         chain entries (e.g., requiring filtered outputs, specific
         guardrail models, or PII redaction).

  10.  Security Considerations

  10.1.  STRIDE Analysis

     +===============+========================+=========================+
     | Threat        | Mitigation             | Mechanism               |
     +===============+========================+=========================+
     | *Spoofing*    | Cryptographic identity | Actor chain, SPIFFE IDs |
     +---------------+------------------------+-------------------------+
     | *Tampering*   | Merkle tree integrity  | Append-only logs,       |
     |               |                        | Merkle root in JWT      |
     +---------------+------------------------+-------------------------+
     | *Repudiation* | Signed outputs         | intent_sig on agent and |
     |               |                        | filter entries          |
     +---------------+------------------------+-------------------------+
     | *Information  | Selective disclosure   | SD-JWT, content hashes  |
     | Disclosure*   |                        | not content             |
     +---------------+------------------------+-------------------------+
     | *Denial of    | Session lifecycle      | Expiry, rate limits     |
     | Service*      |                        |                         |
     +---------------+------------------------+-------------------------+
     | *Elevation of | Scope attenuation      | Actor chain, policy     |
     | Privilege*    |                        | enforcement             |
     +---------------+------------------------+-------------------------+

                                   Table 12

  10.2.  Signing Requirements by Entry Type

      +===================+===============+=============================+
      | Entry Type        | Required      | Rationale                   |
      |                   | Signatures    |                             |
      +===================+===============+=============================+
      | non_deterministic | intent_sig    | Non-reproducible; signs     |
      |                   | over          | input_hash + output_hash to |
      |                   | intent_digest | prove what was received and |
      |                   | (REQUIRED)    | produced                    |
      +-------------------+---------------+-----------------------------+
      | deterministic     | intent_sig    | Reproducible; signs         |
      |                   | over          | input_hash + output_hash.   |



  Krishnan, et al.        Expires 19 September 2026              [Page 28]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


      |                   | intent_digest | Type-specific fields        |
      |                   | (REQUIRED)    | (rule_id, rule_hash) enable |
      |                   |               | independent re-verification |
      +-------------------+---------------+-----------------------------+

                                    Table 13

  10.3.  Replay Protection

     Each intent chain entry includes an iat (issued-at) timestamp.  The
     session-scoped partitioning of the intent registry prevents cross-
     session replay.  Additionally, the Merkle root is bound to the JWT
     via the intent_root claim, and the JWT itself carries exp and jti
     claims, providing token-level replay protection.

  10.4.  Chain Integrity

     The Merkle tree structure provides tamper evidence for the intent
     chain.  Any modification to an entry changes its leaf hash, which
     propagates up the tree, changing the Merkle root.  Since the Merkle
     root is included in the signed JWT, any tampering with the intent
     chain entries is detectable.

     The append-only property of the intent registry provides additional
     protection: entries cannot be deleted or modified after creation.

  10.5.  Credential Isolation

     Intent registry entries MUST NOT contain OAuth tokens, bearer
     credentials, or signing keys.  The relationship between tokens and
     registry entries is one-directional: the token references the
     registry via the intent_registry URI claim, but the registry MUST NOT
     store or reference the token.  This separation ensures that
     compromise of the intent registry does not expose bearer credentials
     that could be used for unauthorized access.

  11.  Privacy Considerations

  11.1.  Selective Disclosure

     The intent chain contains content hashes rather than actual content.
     This provides provenance without exposing the content itself.  When
     combined with SD-JWT {{!I-D.ietf-oauth-selective-disclosure-jwt}},
     individual intent chain entries can be selectively disclosed to
     different verifiers.






  Krishnan, et al.        Expires 19 September 2026              [Page 29]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  11.2.  Content Hash vs Content Storage

     The intent chain stores SHA-256 hashes of content, not the content
     itself.  This design choice provides:

     *  *Provenance without exposure*: Verifiers can confirm that specific
        content was produced without seeing the content.
     *  *Reduced log size*: Hashes are fixed-size regardless of content
        size.
     *  *Privacy by default*: Content is not exposed through the intent
        chain; access to the original content requires separate
        authorization.

     |  *Pre-image resistance caveat*: SHA-256 is pre-image resistant for
     |  arbitrary-length inputs, but short, low-entropy content (e.g., a
     |  16-digit account number, a boolean flag, or a short enumerated
     |  value) may be vulnerable to brute-force guessing.  An attacker who
     |  knows the hash and the input domain can enumerate all possible
     |  inputs and find the one that matches.  Deployments handling short,
     |  structured content SHOULD salt content before hashing or use SD-
     |  JWT to selectively redact content hashes from specific verifiers.

  12.  Implementation Guidance

  12.1.  Intent Registry Implementation

     The intent registry stores immutable intent chain entries.
     Recommended properties:

     *  Append-only log structure
     *  Partitioned by session.session_id for isolation
     *  Configurable retention period
     *  Merkle root computation triggered on append or at token exchange
        time

     A federated IAM/IdM platform (e.g., Keycloak, Microsoft Entra, Okta,
     PingFederate) MAY host the intent registry alongside the Actor Chain
     Registry ({{!I-D.draft-mw-spice-actor-chain}}), since the
     Authorization Server already mediates token exchanges and can append
     intent chain entries as a side-effect.  Most enterprise IAM/IdM
     platforms support configurable data stores that can be configured for
     append-only semantics — see {{!I-D.draft-mw-spice-actor-chain}}
     Section "Registry Hosting" for detailed requirements.








  Krishnan, et al.        Expires 19 September 2026              [Page 30]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  12.2.  Multi-AS Deployments

     In deployments involving multiple Authorization Servers (e.g.,
     federated enterprise environments where different ASes serve
     different organizational domains), the intent registry is shared
     across all participating ASes.  Each AS appends intent chain entries
     to the same session-partitioned registry, identified by the sid claim
     carried in the token.  This works without coordination between ASes
     because:

     *  The sid value is established at session initiation and carried
        forward unchanged through all token exchanges.
     *  Each AS appends entries atomically under the session's sid
        partition.
     *  The Merkle root is recomputed at each token exchange time over all
        entries accumulated so far (by any AS).
     *  The resulting intent_root in the token therefore differs at each
        hop — each successive AS produces a larger Merkle root reflecting
        the growing chain.  This is expected behavior: a growing root is
        the normal consequence of an append-only chain and indicates that
        additional intent entries have been recorded.

     This enables cross-domain content provenance tracking without
     requiring ASes to share keys or coordinate directly — the session
     partition and append-only log semantics provide the necessary
     consistency.

  12.3.  Scalability Considerations

     *  *Log Partitioning*: Session-based partitioning ensures that intent
        chains for different sessions are isolated and can be processed in
        parallel.
     *  *Merkle Root Caching*: Computed Merkle roots SHOULD be cached to
        avoid recomputation on every token exchange.
     *  *Proof Materialization*: Merkle proofs for recent entries SHOULD
        be pre-computed and cached for O(1) retrieval.

  12.4.  Operational Recommendations

     *  *Retention Policy*: Intent chain logs SHOULD be retained for the
        maximum audit window required by the deployment's regulatory
        environment.
     *  *Monitoring*: Operators SHOULD monitor intent chain append latency
        and Merkle root computation time.
     *  *Backup*: Intent chain logs SHOULD be replicated across
        availability zones for durability.





  Krishnan, et al.        Expires 19 September 2026              [Page 31]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  12.5.  Registry Availability

     Intent registry unavailability does not affect data-plane operation —
     the token's AS-signed intent_root is sufficient for request-time
     policy decisions (e.g., "intent chain coverage required").  Per-entry
     forensic verification is deferred to the audit plane and is not
     required on the hot path.

     However, if the registry is permanently lost, forensic verification
     becomes impossible.  Deployments SHOULD:

     *  Replicate intent registry entries across availability zones.
     *  Use append-only log services designed for high durability (e.g.,
        SCITT transparency logs).
     *  Retain archived tokens (containing intent_root) separately from
        intent chain entries, so that Merkle root commitments survive
        independently of the registry.
     *  Define a fail-mode policy: *fail-closed* (reject tokens whose
        intent chains cannot be verified) for high-risk operations, or
        *fail-open* (accept the AS-signed token and log the verification
        gap) for low-risk operations.

  13.  Design Rationale: Merkle Root in Token

     The intent chain uses a Merkle root in the token rather than
     embedding the full chain inline.  The following table summarizes the
     trade-offs:
























  Krishnan, et al.        Expires 19 September 2026              [Page 32]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     +============+=========+==============+============+================+
     | Approach   |Token    | Verification | Privacy    | Selective      |
     |            |Size     |              |            | Verify         |
     +============+=========+==============+============+================+
     | *A.  Full  |O(n) —   | Inline, zero | Poor — all | All-or-nothing |
     | chain in   |grows    | latency      | entries    |                |
     | token*     |per      |              | exposed    |                |
     |            |entry    |              |            |                |
     +------------+---------+--------------+------------+----------------+
     | *B.        |O(1) —   | O(log n) per | Good —     | Single-entry   |
     | Merkle     |~64      | entry        | selective  | proofs         |
     | root in    |bytes    |              | disclosure |                |
     | token*     |         |              |            |                |
     +------------+---------+--------------+------------+----------------+
     | *C.        |O(1) —   | O(n) — must  | Good —     | Must verify    |
     | Simple     |~64      | rehash all   | external   | all            |
     | hash of    |bytes    |              | storage    |                |
     | chain*     |         |              |            |                |
     +------------+---------+--------------+------------+----------------+
     | *D.  No    |Zero     | External     | Best —     | Any pattern    |
     | provenance |overhead | lookup       | nothing in |                |
     | in token*  |         |              | token      |                |
     +------------+---------+--------------+------------+----------------+

                                    Table 14

     Approach B is chosen because intent chains can contain 20-50+
     entries, making inline embedding impractical for data-plane proxies.
     The Merkle tree enables O(log n) selective verification of individual
     entries and provides cryptographic binding between the token and the
     registry.  The actor chain ({{!I-D.draft-mw-spice-actor-chain}}) uses
     approach A because delegation chains are small (typically 3-5
     entries) and every Relying Party needs the full delegation path.

  14.  Audit Procedures

  14.1.  Cross-Chain Binding

     When auditing actor and intent chains together, the auditor performs
     cross-chain binding checks:

     For each intent chain entry of type non_deterministic: verify that
     entry.sub appears in actor_chain.  Verify that entry.iat falls within
     the actor's active window.  A mismatch indicates an unregistered
     agent produced content.

     Full two-chain audit is RECOMMENDED for regulatory submissions,
     dispute resolution, and post-breach forensic analysis.



  Krishnan, et al.        Expires 19 September 2026              [Page 33]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  15.  IANA Considerations

  15.1.  JWT Claim Registration

     This document requests registration of the following claims in the
     "JSON Web Token Claims" registry established by {{!RFC7519}}:

     *  *Claim Name*: intent_root

     *  *Claim Description*: Merkle root hash of the intent chain for
        content provenance verification.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: intent_alg

     *  *Claim Description*: Hash algorithm used for intent chain Merkle
        tree construction.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: intent_registry

     *  *Claim Description*: URI of the intent registry for proof
        retrieval.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

  15.2.  CWT Claim Registration

     This document requests registration of the following claims in the
     "CBOR Web Token (CWT) Claims" registry established by {{!RFC8392}}:

     *  *Claim Name*: intent_root

     *  *Claim Description*: Merkle root hash of the intent chain.

     *  *CBOR Key*: TBD (e.g., 50)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF



  Krishnan, et al.        Expires 19 September 2026              [Page 34]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: intent_registry

     *  *Claim Description*: URI of the intent registry for proof
        retrieval.

     *  *CBOR Key*: TBD (e.g., 51)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: intent_alg

     *  *Claim Description*: Hash algorithm used for intent chain Merkle
        tree construction.

     *  *CBOR Key*: TBD (e.g., 52)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

  Appendix A.  Merkle Tree Construction Details

  A.1.  Tree Structure

                         intent_root (in JWT)
                               |
                     +---------+---------+
                     |                   |
               Hash(0-2)              Hash(3-5)
                     |                   |
             +-------+-------+   +-------+-------+
             |               |   |               |
          Hash(0-1)      Hash(2) Hash(3-4)    Hash(5)
             |               |       |           |
         +---+---+           |   +---+---+       |
         |       |           |   |       |       |
      Entry0  Entry1     Entry2 Entry3 Entry4  Entry5
      (non-det)(non-det) (det)  (non-det)(det) (non-det)





  Krishnan, et al.        Expires 19 September 2026              [Page 35]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


  A.2.  Reference Construction Algorithm

     def compute_merkle_root(entries):
         if len(entries) == 0:
             return None

         # Compute leaf hashes
         hashes = [sha256(canonical_json(entry)) for entry in entries]

         # Build tree bottom-up
         while len(hashes) > 1:
             next_level = []
             for i in range(0, len(hashes), 2):
                 if i + 1 < len(hashes):
                     combined = sha256(hashes[i] + hashes[i+1])
                 else:
                     combined = hashes[i]  # Odd node promoted
                 next_level.append(combined)
             hashes = next_level

         return hashes[0]

  Appendix B.  Complete Token Examples

  B.1.  Full Governance Token

     The following example shows a complete token with session, actor
     chain, and intent chain:























  Krishnan, et al.        Expires 19 September 2026              [Page 36]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "aud": "https://api.example.com",
       "jti": "tok-ddd-67890",
       "iat": 1700000000,
       "exp": 1700003600,

       "session": {
         "session_id": "sess-uuid-12345",
         "type": "human_initiated",
         "initiator": "user-alice",
         "approval_ref": "approval-uuid-789",
         "max_chain_depth": 5
       },

       "actor_chain": [
         {
           "sub": "spiffe://example.com/agent/orchestrator",
           "iss": "https://auth.example.com",
           "iat": 1700000010,
           "scope": "ticket:*",
           "chain_digest": "sha256:aaa...",
           "chain_sig": "eyJhbGciOiJFUzI1NiIs..."
         },
         {
           "sub": "spiffe://example.com/agent/support",
           "iss": "https://auth.example.com",
           "iat": 1700000030,
           "scope": "ticket:create",
           "chain_digest": "sha256:bbb...",
           "chain_sig": "eyJhbGciOiJFUzI1NiIs..."
         }
       ],

       "intent_root": "sha256:abc123def456789...",
       "intent_registry":
         "https://intent-log.example.com/sessions/sess-uuid-12345"
     }

  B.2.  Corresponding Intent Chain Log Entries

     The following entries would be stored in the intent registry for the
     above token:







  Krishnan, et al.        Expires 19 September 2026              [Page 37]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     [
       {
         "offset": 0,
         "entry": {
           "type": "non_deterministic",
           "sub":
             "spiffe://example.com/agent/orchestrator",
           "input_hash": "sha256:prompt...",
           "output_hash": "sha256:abc...",
           "iat": 1700000010,
           "intent_digest": "sha256:leaf0...",
           "intent_sig": "eyJ..."
         }
       },
       {
         "offset": 1,
         "entry": {
           "type": "non_deterministic",
           "sub":
             "spiffe://example.com/filter/ai-guardrail",
           "filter_version": "v2.1",
           "input_hash": "sha256:abc...",
           "output_hash": "sha256:def...",
           "model_info": {
             "model": "llama-guard-3",
             "categories": ["violence", "pii"]
           },
           "iat": 1700000012,
           "intent_digest": "sha256:leaf1...",
           "intent_sig": "eyJ..."
         }
       },
       {
         "offset": 2,
         "entry": {
           "type": "deterministic",
           "sub":
             "spiffe://example.com/filter/schema-validator",
           "filter_version": "v1.0",
           "input_hash": "sha256:def...",
           "output_hash": "sha256:ghi...",
           "rule_id": "ticket-schema-v2",
           "rule_hash": "sha256:rrr...",
           "reproducible": true,
           "iat": 1700000013,
           "intent_digest": "sha256:leaf2...",
           "intent_sig": "eyJ..."
         }



  Krishnan, et al.        Expires 19 September 2026              [Page 38]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


       },
       {
         "offset": 3,
         "entry": {
           "type": "non_deterministic",
           "sub":
             "spiffe://example.com/agent/support",
           "input_hash": "sha256:ghi...",
           "output_hash": "sha256:jkl...",
           "iat": 1700000030,
           "intent_digest": "sha256:leaf3...",
           "intent_sig": "eyJ..."
         }
       },
       {
         "offset": 4,
         "entry": {
           "type": "deterministic",
           "sub":
             "spiffe://example.com/filter/pii-redactor",
           "filter_version": "v1.2",
           "input_hash": "sha256:jkl...",
           "output_hash": "sha256:mno...",
           "rule_id": "pii-redaction-v1",
           "rule_hash": "sha256:ppp...",
           "reproducible": true,
           "iat": 1700000031,
           "intent_digest": "sha256:leaf4...",
           "intent_sig": "eyJ..."
         }
       },
       {
         "offset": 5,
         "entry": {
           "type": "non_deterministic",
           "sub":
             "spiffe://example.com/agent/tool-executor",
           "input_hash": "sha256:mno...",
           "output_hash": "sha256:pqr...",
           "iat": 1700000050,
           "intent_digest": "sha256:leaf5...",
           "intent_sig": "eyJ..."
         }
       }
     ]

  Authors' Addresses




  Krishnan, et al.        Expires 19 September 2026              [Page 39]


  Internet-Draft             SPICE-INTENT-CHAIN                 March 2026


     Ram Krishnan
     JPMorgan Chase & Co
     Email: ramkri123@gmail.com


     A Prasad
     Oracle
     Email: a.prasad@oracle.com


     Diego R. Lopez
     Telefonica
     Email: diego.r.lopez@telefonica.com


     Srinivasa Addepalli
     Aryaka
     Email: srinivasa.addepalli@aryaka.com

































  Krishnan, et al.        Expires 19 September 2026              [Page 40]


name: draft-mw-spice-inference-chain
rev: 00
title: Cryptographically Verifiable Inference Chain for AI Agent Computational Provenance
time: 2026-03-18T00:29:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-19T00:29:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Model serving/inference", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:48.589004+00:00
source: ietf
abstract:
  This document defines the inference_root claim as a companion to the
     actor_chain claim ({{!I-D.draft-mw-spice-actor-chain}}) and the
     intent_root claim ({{!I-D.draft-mw-spice-intent-chain}}).  While the
     actor chain addresses delegation provenance (WHO) and the intent
     chain addresses content provenance (WHAT), the inference chain
     addresses computational provenance (HOW) — providing cryptographic
     proof that a claimed AI model actually performed the inference that
     produced a given output.

     The inference chain leverages two complementary mechanisms: Zero-
     Knowledge Machine Learning (ZKML) proofs for mathematical certainty,
     and Trusted Execution Environment (TEE) attestation quotes for
     production-scale AI workloads.  The full inference chain is stored as
     ordered logs, with only the Merkle root included in the OAuth token
     for efficiency.

     Together, the three chains — actor, intent, and inference — form a
     complete "Truth Stack" for autonomous AI agent governance.

full_text:
  SPICE                                                        R. Krishnan
  Internet-Draft                                       JPMorgan Chase & Co
  Intended status: Informational                                 A. Prasad
  Expires: 19 September 2026                                        Oracle
                                                                  D. Lopez
                                                                Telefonica
                                                              S. Addepalli
                                                                    Aryaka
                                                             18 March 2026


  Cryptographically Verifiable Inference Chain for AI Agent Computational
                                 Provenance
                     draft-mw-spice-inference-chain-00

  Abstract

     This document defines the inference_root claim as a companion to the
     actor_chain claim ({{!I-D.draft-mw-spice-actor-chain}}) and the
     intent_root claim ({{!I-D.draft-mw-spice-intent-chain}}).  While the
     actor chain addresses delegation provenance (WHO) and the intent
     chain addresses content provenance (WHAT), the inference chain
     addresses computational provenance (HOW) — providing cryptographic
     proof that a claimed AI model actually performed the inference that
     produced a given output.

     The inference chain leverages two complementary mechanisms: Zero-
     Knowledge Machine Learning (ZKML) proofs for mathematical certainty,
     and Trusted Execution Environment (TEE) attestation quotes for
     production-scale AI workloads.  The full inference chain is stored as
     ordered logs, with only the Merkle root included in the OAuth token
     for efficiency.

     Together, the three chains — actor, intent, and inference — form a
     complete "Truth Stack" for autonomous AI agent governance.

  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/.






  Krishnan, et al.        Expires 19 September 2026               [Page 1]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     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 19 September 2026.

  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.
     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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Problem: Computational Spoofing . . . . . . . . . . .   3
       1.2.  Relationship to Actor Chain and Intent Chain  . . . . . .   4
       1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Inference Proof Types . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  ZKML Proofs . . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  TEE Attestation Quotes  . . . . . . . . . . . . . . . . .   9
       3.4.  Hybrid Proofs . . . . . . . . . . . . . . . . . . . . . .  10
     4.  Entry Structure . . . . . . . . . . . . . . . . . . . . . . .  11
       4.1.  Common Fields . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.  Binding to Intent Chain . . . . . . . . . . . . . . . . .  12
     5.  Storage Architecture  . . . . . . . . . . . . . . . . . . . .  13
       5.1.  Inference Registry  . . . . . . . . . . . . . . . . . . .  13
       5.2.  Merkle Tree Construction  . . . . . . . . . . . . . . . .  14
       5.3.  Merkle Root in Token  . . . . . . . . . . . . . . . . . .  14
     6.  Token Structure . . . . . . . . . . . . . . . . . . . . . . .  15
       6.1.  Combined Token Format (Full Truth Stack)  . . . . . . . .  15
       6.2.  Claim Definitions . . . . . . . . . . . . . . . . . . . .  17
     7.  Verification Procedures . . . . . . . . . . . . . . . . . . .  17
       7.1.  Three-Point Verification  . . . . . . . . . . . . . . . .  17
       7.2.  ZKML Proof Verification . . . . . . . . . . . . . . . . .  17
       7.3.  TEE Quote Verification  . . . . . . . . . . . . . . . . .  18
       7.4.  Tiered Verification . . . . . . . . . . . . . . . . . . .  18



  Krishnan, et al.        Expires 19 September 2026               [Page 2]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     8.  Policy Enforcement  . . . . . . . . . . . . . . . . . . . . .  18
       8.1.  Policy Examples . . . . . . . . . . . . . . . . . . . . .  18
         8.1.1.  Require Inference Proof for All Agent Outputs . . . .  18
         8.1.2.  Require TEE for Financial Operations  . . . . . . . .  19
         8.1.3.  Block Specific Model Versions . . . . . . . . . . . .  19
       8.2.  Integration with Policy Engines . . . . . . . . . . . . .  19
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
       9.1.  STRIDE Analysis for Inference Chain . . . . . . . . . . .  20
       9.2.  Trust Assumptions . . . . . . . . . . . . . . . . . . . .  20
         9.2.1.  ZKML Proofs . . . . . . . . . . . . . . . . . . . . .  20
         9.2.2.  TEE Attestation . . . . . . . . . . . . . . . . . . .  20
       9.3.  Verification Key Management . . . . . . . . . . . . . . .  21
       9.4.  Proof Freshness . . . . . . . . . . . . . . . . . . . . .  21
       9.5.  Credential Isolation  . . . . . . . . . . . . . . . . . .  21
       9.6.  ZKML Proof Size Considerations  . . . . . . . . . . . . .  21
       9.7.  Relationship to Proof of Residency  . . . . . . . . . . .  22
     10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  22
       10.1.  Model Weight Privacy . . . . . . . . . . . . . . . . . .  22
       10.2.  Input Privacy  . . . . . . . . . . . . . . . . . . . . .  22
       10.3.  Selective Disclosure . . . . . . . . . . . . . . . . . .  22
     11. Implementation Guidance . . . . . . . . . . . . . . . . . . .  23
       11.1.  Current ZKML Landscape . . . . . . . . . . . . . . . . .  23
       11.2.  TEE Integration  . . . . . . . . . . . . . . . . . . . .  23
       11.3.  Scalability Considerations . . . . . . . . . . . . . . .  23
       11.4.  Multi-AS Deployments . . . . . . . . . . . . . . . . . .  23
       11.5.  Registry Availability  . . . . . . . . . . . . . . . . .  24
         11.5.1.  Proof Size and Storage . . . . . . . . . . . . . . .  24
       11.6.  Performance Guidance: TEE vs ZKML  . . . . . . . . . . .  25
     12. Design Rationale: Merkle Root in Token  . . . . . . . . . . .  26
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
       13.1.  JWT Claim Registration . . . . . . . . . . . . . . . . .  26
       13.2.  CWT Claim Registration . . . . . . . . . . . . . . . . .  27
     Appendix A.  Full Token Example (Three-Chain Governance)  . . . .  27
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

  1.  Introduction

  1.1.  The Problem: Computational Spoofing

     The Actor Chain ({{!I-D.draft-mw-spice-actor-chain}}) proves WHO
     delegated to whom.  The Intent Chain ({{!I-D.draft-mw-spice-intent-
     chain}}) proves WHAT was produced and how it was transformed.
     Neither addresses a critical remaining gap: was the *claimed
     computational process* actually used to produce the output?

     In AI agent workflows, an agent may claim to use a high-capability,
     safety-aligned model (e.g., a frontier model with RLHF alignment)
     while actually running a cheaper, unaligned model.  This "Model



  Krishnan, et al.        Expires 19 September 2026               [Page 3]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     Masquerading" attack is undetectable by content hashes alone — the
     output hash in the intent chain proves the output exists, but not
     that the claimed model produced it.

     *Concrete threats:*

     *  *Model Substitution*: A cost-optimized deployment swaps a
        regulated, audited model for a cheaper alternative with weaker
        safety properties.
     *  *Weight Tampering*: Model weights are modified (e.g., fine-tuned
        to remove safety guardrails) while the model identifier remains
        unchanged.
     *  *Environment Spoofing*: Inference runs in an unprotected
        environment where model inputs/outputs can be intercepted, while
        the agent claims TEE execution.
     *  *Replay of Stale Proofs*: A valid inference proof from a previous
        execution is reattached to a new, unverified output.

  1.2.  Relationship to Actor Chain and Intent Chain

     This specification completes the three-axis "Truth Stack":

      +=================+=============+==============+==================+
      | Specification   | Axis        | Question     | STRIDE Coverage  |
      |                 |             | Answered     |                  |
      +=================+=============+==============+==================+
      | *Actor Chain*   | Identity    | WHO          | Spoofing,        |
      | ({{!I-D.draft-  |             | delegated to | Repudiation,     |
      | mw-spice-actor- |             | whom?        | Elevation of     |
      | chain}})        |             |              | Privilege        |
      +-----------------+-------------+--------------+------------------+
      | *Intent Chain*  | Content     | WHAT was     | Repudiation,     |
      | ({{!I-D.draft-  |             | produced and | Tampering        |
      | mw-spice-       |             | transformed? |                  |
      | intent-chain}}) |             |              |                  |
      +-----------------+-------------+--------------+------------------+
      | *Inference      | Computation | HOW was the  | Spoofing         |
      | Chain* (this    |             | output       | (computational), |
      | document)       |             | computed?    | Tampering        |
      |                 |             |              | (model)          |
      +-----------------+-------------+--------------+------------------+

                                    Table 1








  Krishnan, et al.        Expires 19 September 2026               [Page 4]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


      +=============+=======+============+==========+==================+
      | Chain       | Plane | Token      | Full     | Primary Consumer |
      |             |       | Content    | Chain    |                  |
      +=============+=======+============+==========+==================+
      | *Actor*     | Data  | Full chain | In token | Every Relying    |
      |             | Plane | inline     |          | Party (real-time |
      |             |       |            |          | authorization)   |
      +-------------+-------+------------+----------+------------------+
      | *Intent*    | Audit | Merkle     | External | Audit systems,   |
      |             | Plane | root only  | registry | forensic         |
      |             |       |            |          | investigators    |
      +-------------+-------+------------+----------+------------------+
      | *Inference* | Audit | Merkle     | External | Auditors,        |
      |             | Plane | root only  | registry | compliance       |
      |             |       |            |          | systems          |
      +-------------+-------+------------+----------+------------------+

                                   Table 2

     The three chains are independent and composable:

     *  *Actor + Intent*: Identity and content governance without
        computational proof (sufficient for rule-based systems).
     *  *Actor + Inference*: Identity and computational governance without
        content transformation tracking (sufficient for single-agent
        systems).
     *  *All Three*: Full governance for multi-agent pipelines with
        content transformation and computational integrity.

  1.3.  Design Goals

     1.  *Computational Provenance*: Cryptographic proof that a specific
         model produced a specific output.
     2.  *Mechanism Agnostic*: Support both ZKML proofs and TEE
         attestation quotes as proof types.
     3.  *Binding to Intent Chain*: Inference proofs are bound to specific
         intent chain entries via content hashes.
     4.  *Efficiency*: Only Merkle root in token; full proofs in registry.
     5.  *Incremental Adoption*: Deployable alongside existing actor and
         intent chains without requiring changes to those specifications.

  2.  Terminology

     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.



  Krishnan, et al.        Expires 19 September 2026               [Page 5]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     Inference Chain:  An ordered sequence of Inference Chain Entries
        providing cryptographic proof of the computational processes that
        produced AI agent outputs within a session.
     Inference Chain Entry:  A record binding a specific AI agent output
        to a cryptographic proof of the computational process that
        produced it.
     Inference Root:  The Merkle root hash of the complete inference
        chain, included in the OAuth token via the inference_root claim.
     Inference Registry:  An append-only ordered log storing the full
        inference chain entries, partitioned by session.
     ZKML Proof:  A Zero-Knowledge proof (SNARK or STARK) demonstrating
        that a specific neural network with specific weights produced a
        specific output from a specific input, without revealing the model
        weights or input data.
     TEE Quote:  A hardware-signed attestation from a Trusted Execution
        Environment (e.g., Intel TDX, AMD SEV-SNP, NVIDIA H100
        Confidential Computing) proving that specific code ran within a
        verified enclave with specific measurements.  TEE attestation
        follows the RATS architecture {{!RFC9334}}.
     Model Fingerprint:  A cryptographic hash of the model weights,
        architecture definition, and inference configuration, uniquely
        identifying the computational process.

  3.  Inference Proof Types

  3.1.  Overview

     The inference chain supports two primary proof types, each with
     different trust assumptions and performance characteristics:






















  Krishnan, et al.        Expires 19 September 2026               [Page 6]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     +================+==========================+=======================+
     | Property       | ZKML Proof               | TEE Quote             |
     +================+==========================+=======================+
     | *Trust Basis*  | Mathematics              | Hardware              |
     |                | (cryptographic hardness) | manufacturer root     |
     |                |                          | of trust              |
     +----------------+--------------------------+-----------------------+
     | *Verification* | Deterministic, no        | Requires              |
     |                | external dependency      | manufacturer PKI      |
     |                |                          | (Intel/AMD/NVIDIA)    |
     +----------------+--------------------------+-----------------------+
     | *Model Scale*  | Currently limited (~100M | Production-scale      |
     |                | parameters)              | LLMs (100B+           |
     |                |                          | parameters)           |
     +----------------+--------------------------+-----------------------+
     | *Proof         | Minutes to hours per     | Real-time             |
     | Generation*    | inference                | (millisecond          |
     |                |                          | overhead)             |
     +----------------+--------------------------+-----------------------+
     | *Proof Size*   | ~200 bytes (Groth16),    | ~2KB (Intel TDX),     |
     |                | ~50KB (STARKs)           | ~4KB (NVIDIA)         |
     +----------------+--------------------------+-----------------------+
     | *Privacy*      | Zero-knowledge: hides    | Enclave-bound:        |
     |                | model weights            | hardware isolation    |
     +----------------+--------------------------+-----------------------+

                                    Table 3

     Deployments SHOULD select the proof type based on their performance
     requirements and trust model.

  3.2.  ZKML Proofs

     ZKML proofs provide mathematical certainty that a specific model
     produced a specific output.  They are constructed by encoding the
     neural network's forward pass as an arithmetic circuit and generating
     a zero-knowledge proof of correct execution.

     *Proof Statement*: "There exist model weights W such that hash(W) =
     model_fingerprint AND forward_pass(W, input) = output."

     *Properties*:

     *  The verifier learns nothing about the model weights (zero-
        knowledge property).
     *  The proof cannot be forged without performing the actual
        computation (soundness).




  Krishnan, et al.        Expires 19 September 2026               [Page 7]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     *  Proof verification is fast (milliseconds) regardless of model
        size.
     *  Proof generation is computationally expensive (orders of magnitude
        slower than inference).

     *Applicable Proof Systems*:

     +=========+============+===================+========================+
     | System  | Proof Size | Verification Time | Trusted Setup          |
     +=========+============+===================+========================+
     | Groth16 | ~200 bytes | _5ms              | Required               |
     |         |            |                   | (per-circuit)          |
     +---------+------------+-------------------+------------------------+
     | PLONK   | ~400 bytes | _10ms             | Universal              |
     |         |            |                   | (one-time)             |
     +---------+------------+-------------------+------------------------+
     | STARKs  | _50KB      | _50ms             | None                   |
     |         |            |                   | (transparent)          |
     +---------+------------+-------------------+------------------------+
     | Halo2   | _5KB       | _15ms             | None                   |
     |         |            |                   | (recursive)            |
     +---------+------------+-------------------+------------------------+

                                    Table 4

     *Entry Structure*:

     {
       "type": "zkml_proof",
       "sub": "spiffe://example.com/agent/analyst",
       "proof_system": "groth16",
       "model_fingerprint": "sha256:weights_hash...",
       "model_id": "analyst-model-v3.2",
       "input_hash": "sha256:input_data...",
       "output_hash": "sha256:output_data...",
       "intent_entry_ref": 3,
       "proof": "base64:proof_bytes...",
       "verification_key_hash": "sha256:vk_hash...",
       "verification_key_registry":
         "https://vk-registry.example.com/keys/analyst-v3.2",
       "iat": 1700000030,
       "inference_digest": "sha256:...",
       "inference_sig": "eyJhbGci..."
     }







  Krishnan, et al.        Expires 19 September 2026               [Page 8]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  3.3.  TEE Attestation Quotes

     TEE attestation quotes provide hardware-rooted proof that inference
     was performed within a verified enclave.  The hardware generates a
     signed "quote" containing measurements of the code, data, and
     configuration running inside the enclave.

     *Proof Statement*: "Hardware H with platform certificate C attests
     that enclave E with measurements M produced output O from input I."

     *Properties*:

     *  Proof is generated in real-time with minimal overhead.
     *  Verification requires the hardware manufacturer's PKI (root
        certificate).
     *  The quote binds the computation to specific hardware and firmware
        versions.
     *  The enclave protects model weights and inference data from the
        host OS.

     *Supported Platforms*:

       +==========+=======================+=============+==============+
       | Platform | TEE Technology        | GPU Support | Quote Format |
       +==========+=======================+=============+==============+
       | Intel    | TDX (Trust Domain     | Via NVIDIA  | DCAP Quote   |
       |          | Extensions)           | H100 CC     | v4           |
       +----------+-----------------------+-------------+--------------+
       | AMD      | SEV-SNP               | Via NVIDIA  | Attestation  |
       |          |                       | H100 CC     | Report       |
       +----------+-----------------------+-------------+--------------+
       | NVIDIA   | H100 Confidential     | Native      | GPU          |
       |          | Computing             |             | Attestation  |
       +----------+-----------------------+-------------+--------------+
       | ARM      | CCA (Confidential     | Planned     | CCA Token    |
       |          | Compute Architecture) |             |              |
       +----------+-----------------------+-------------+--------------+

                                    Table 5

     *Entry Structure*:










  Krishnan, et al.        Expires 19 September 2026               [Page 9]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     {
       "type": "tee_attestation",
       "sub": "spiffe://example.com/agent/analyst",
       "platform": "nvidia_h100_cc",
       "model_fingerprint": "sha256:weights_hash...",
       "model_id": "analyst-model-v3.2",
       "input_hash": "sha256:input_data...",
       "output_hash": "sha256:output_data...",
       "intent_entry_ref": 3,
       "quote": {
         "format": "nvidia_gpu_attestation_v1",
         "enclave_measurement": "sha384:enclave_mr...",
         "firmware_version": "H100.96.00.5E.00.01",
         "platform_cert_chain": [
           "base64:nvidia_device_cert...",
           "base64:nvidia_intermediate_cert..."
         ],
         "report_data": "sha256:binding_hash...",
         "signature": "base64:hw_signature..."
       },
       "por_ref": "spiffe://example.com/wia/gpu-node-7",
       "iat": 1700000030,
       "inference_digest": "sha256:...",
       "inference_sig": "eyJhbGci..."
     }

  3.4.  Hybrid Proofs

     For high-assurance deployments, both proof types MAY be combined for
     a single inference operation:

     *  *TEE quote* provides real-time proof that inference ran in a
        protected enclave.
     *  *ZKML proof* provides mathematical proof of correct computation
        (generated asynchronously after inference).

     The inference chain entry for a hybrid proof references both:














  Krishnan, et al.        Expires 19 September 2026              [Page 10]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     {
       "type": "hybrid_proof",
       "sub": "spiffe://example.com/agent/analyst",
       "tee_entry_ref": 4,
       "zkml_entry_ref": 5,
       "model_fingerprint": "sha256:weights_hash...",
       "output_hash": "sha256:output_data...",
       "intent_entry_ref": 3,
       "iat": 1700000035,
       "inference_digest": "sha256:...",
       "inference_sig": "eyJhbGci..."
     }

  4.  Entry Structure

  4.1.  Common Fields

     All inference chain entries share common fields:

































  Krishnan, et al.        Expires 19 September 2026              [Page 11]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     +===================+========+==========+===========================+
     | Field             | Type   | Required | Description               |
     +===================+========+==========+===========================+
     | type              | string | REQUIRED | Entry type: zkml_proof,   |
     |                   |        |          | tee_attestation,          |
     |                   |        |          | hybrid_proof              |
     +-------------------+--------+----------+---------------------------+
     | sub               | string | REQUIRED | SPIFFE ID of the agent    |
     |                   |        |          | that performed            |
     |                   |        |          | inference                 |
     +-------------------+--------+----------+---------------------------+
     | model_fingerprint | string | REQUIRED | SHA-256 hash of model     |
     |                   |        |          | weights + architecture    |
     +-------------------+--------+----------+---------------------------+
     | model_id          | string | REQUIRED | Human-readable model      |
     |                   |        |          | identifier and version    |
     +-------------------+--------+----------+---------------------------+
     | output_hash       | string | REQUIRED | SHA-256 hash of           |
     |                   |        |          | inference output (MUST    |
     |                   |        |          | match intent chain        |
     |                   |        |          | entry)                    |
     +-------------------+--------+----------+---------------------------+
     | intent_entry_ref  | number | REQUIRED | Index of corresponding    |
     |                   |        |          | entry in intent chain     |
     +-------------------+--------+----------+---------------------------+
     | iat               | number | REQUIRED | Timestamp when proof      |
     |                   |        |          | was generated             |
     +-------------------+--------+----------+---------------------------+
     | inference_digest  | string | REQUIRED | Cumulative hash for       |
     |                   |        |          | Merkle tree               |
     +-------------------+--------+----------+---------------------------+
     | inference_sig     | string | REQUIRED | Signature over            |
     |                   |        |          | inference_digest          |
     +-------------------+--------+----------+---------------------------+

                                    Table 6

     The sub field identifies the agent that performed inference.  It
     corresponds to the sub field of the matching actor chain entry ({{!I-
     D.draft-mw-spice-actor-chain}}).

  4.2.  Binding to Intent Chain

     The intent_entry_ref field binds each inference proof to a specific
     intent chain entry.  The output_hash in the inference entry MUST
     match the output_hash (for agent outputs) in the referenced intent
     chain entry.  This binding ensures that the computational proof
     corresponds to the actual content recorded in the intent chain.



  Krishnan, et al.        Expires 19 September 2026              [Page 12]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     Intent Chain:                 Inference Chain:
     ┌──────────────────┐         ┌──────────────────┐
     │ Entry 0          │         │                  │
     │ type: non_det    │◄────────│ Entry 0          │
     │ output: sha:abc  │         │ type: tee_quote  │
     │                  │         │ output: sha:abc  │
     │                  │         │ intent_ref: 0    │
     └──────────────────┘         └──────────────────┘
     ┌──────────────────┐
     │ Entry 1          │         (no proof needed
     │ type: determ.    │          for deterministic
     │                  │          filters)
     └──────────────────┘
     ┌──────────────────┐         ┌──────────────────┐
     │ Entry 3          │         │                  │
     │ type: non_det    │◄────────│ Entry 1          │
     │ output: sha:def  │         │ type: zkml       │
     │                  │         │ output: sha:def  │
     │                  │         │ intent_ref: 3    │
     └──────────────────┘         └──────────────────┘

  5.  Storage Architecture

  5.1.  Inference Registry

     The inference registry stores immutable inference chain entries as
     ordered logs, following the same architecture as the intent registry.

     *Properties*:

     *  Append-only (immutable)
     *  Ordered by offset within session
     *  Partitioned by session ID
     *  Eventual consistency acceptable

     |  Inference registry entries MUST NOT contain OAuth tokens, bearer
     |  credentials, or signing keys.  Entries contain only inference
     |  proofs, content hashes, metadata, and agent identities.  The token
     |  references the registry via the inference_registry claim; the
     |  registry MUST NOT store or reference the token itself.

     Implementations SHOULD use an append-only log with tamper-evident
     guarantees and partitioned, ordered retrieval by session ID.

     *Log Structure*:






  Krishnan, et al.        Expires 19 September 2026              [Page 13]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     {
       "session_id": "sess-uuid-12345",
       "offset": 0,
       "entry": {
         "type": "tee_attestation",
         "sub": "spiffe://example.com/agent/A",
         "model_fingerprint": "sha256:weights...",
         "model_id": "agent-A-model-v2",
         "output_hash": "sha256:abc...",
         "intent_entry_ref": 0,
         "quote": { "..." : "..." },
         "iat": 1700000010,
         "inference_digest": "sha256:...",
         "inference_sig": "eyJ..."
       }
     }

  5.2.  Merkle Tree Construction

     The inference chain Merkle tree follows the same construction
     algorithm as the intent chain (defined in {{!I-D.draft-mw-spice-
     intent-chain}} Section 5.3).  Leaf nodes are the SHA-256 hashes of
     canonically serialized inference chain entries.  The resulting root
     hash is included in the OAuth token as the inference_root claim.

  5.3.  Merkle Root in Token

     Only the Merkle root is included in the OAuth token:

     {
       "inference_root": "sha256:xyz789...",
       "inference_proof_type": "groth16",
       "inference_registry":
         "https://proof-log.example.com"
     }
















  Krishnan, et al.        Expires 19 September 2026              [Page 14]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


        +======================+========+==========+==================+
        | Field                | Type   | Required | Description      |
        +======================+========+==========+==================+
        | inference_root       | string | REQUIRED | Merkle root hash |
        |                      |        |          | of inference     |
        |                      |        |          | chain            |
        +----------------------+--------+----------+------------------+
        | inference_proof_type | string | OPTIONAL | Primary proof    |
        |                      |        |          | algorithm used   |
        |                      |        |          | (e.g., groth16,  |
        |                      |        |          | tee_tdx, hybrid) |
        +----------------------+--------+----------+------------------+
        | inference_registry   | string | REQUIRED | URI of inference |
        |                      |        |          | registry for     |
        |                      |        |          | proof retrieval  |
        +----------------------+--------+----------+------------------+

                                    Table 7

  6.  Token Structure

  6.1.  Combined Token Format (Full Truth Stack)

     The complete token combines session, actor chain, intent chain, and
     inference chain:


























  Krishnan, et al.        Expires 19 September 2026              [Page 15]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "aud": "https://api.example.com",
       "jti": "tok-eee-12345",
       "sid": "sess-uuid-12345",
       "iat": 1700000000,
       "exp": 1700003600,

       "session": {
         "session_id": "sess-uuid-12345",
         "type": "human_initiated",
         "initiator": "user-alice",
         "approval_ref": "approval-uuid-789",
         "max_chain_depth": 5
       },

       "actor_chain": [
         {
           "sub":
             "spiffe://example.com/agent/orchestrator",
           "iss": "https://auth.example.com",
           "iat": 1700000010
         },
         {
           "sub":
             "spiffe://example.com/agent/analyst",
           "iss": "https://auth.example.com",
           "iat": 1700000030
         }
       ],

       "intent_root": "sha256:abc123...",
       "intent_registry":
         "https://intent-log.example.com/sessions/sess-uuid-12345",

       "inference_root": "sha256:xyz789...",
       "inference_proof_type": "tee_h100",
       "inference_registry":
         "https://proof-log.example.com/sessions/sess-uuid-12345"
     }










  Krishnan, et al.        Expires 19 September 2026              [Page 16]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  6.2.  Claim Definitions

         +======================+========+==========================+
         | Claim                | Type   | Description              |
         +======================+========+==========================+
         | inference_root       | string | Merkle root hash of      |
         |                      |        | inference chain          |
         +----------------------+--------+--------------------------+
         | inference_proof_type | string | Primary proof algorithm  |
         |                      |        | (e.g., groth16, tee_tdx, |
         |                      |        | tee_h100, hybrid)        |
         +----------------------+--------+--------------------------+
         | inference_registry   | string | URI for retrieving full  |
         |                      |        | inference chain or       |
         |                      |        | proofs (REQUIRED)        |
         +----------------------+--------+--------------------------+

                                   Table 8

  7.  Verification Procedures

  7.1.  Three-Point Verification

     A Relying Party receiving a token with all three chains performs a
     "Three-Point Check":

     1.  *Identity* (Actor Chain): Is the delegation chain valid?  Are all
         actors authorized?
     2.  *Integrity* (Intent Chain): Does the content hash trail match the
         intent_root?
     3.  *Validity* (Inference Chain): Does the computational proof verify
         against the inference_root?

  7.2.  ZKML Proof Verification

     To verify a ZKML inference entry:

     1.  Retrieve the entry from the inference registry.
     2.  Fetch the verification key from verification_key_registry.
     3.  Verify hash(verification_key) == verification_key_hash.
     4.  Run the ZKP verifier: verify(proof, verification_key,
         public_inputs) where public_inputs = (model_fingerprint,
         input_hash, output_hash).
     5.  Verify output_hash matches the corresponding intent chain entry.







  Krishnan, et al.        Expires 19 September 2026              [Page 17]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  7.3.  TEE Quote Verification

     To verify a TEE attestation entry:

     1.  Retrieve the entry from the inference registry.
     2.  Validate the platform certificate chain against the
         manufacturer's root CA (e.g., Intel, NVIDIA).
     3.  Check the platform certificate has not been revoked (TCB recovery
         check).
     4.  Verify the quote signature using the platform certificate.
     5.  Verify enclave_measurement matches the expected measurement for
         the claimed model.
     6.  Verify report_data binds the quote to the specific input/output
         hashes.
     7.  Verify output_hash matches the corresponding intent chain entry.

  7.4.  Tiered Verification

     Inference verification extends the tiered strategy from {{!I-D.draft-
     mw-spice-intent-chain}}:

     +============+=============+==============+===========+=============+
     | Risk Level | Actor Chain | Intent       | Inference | Use Case    |
     |            |             | Chain        | Chain     |             |
     +============+=============+==============+===========+=============+
     | Low        | Sync        | Skip         | Skip      | Read        |
     |            |             |              |           | operations  |
     +------------+-------------+--------------+-----------+-------------+
     | Medium     | Sync        | Cached       | Skip      | Create/     |
     |            |             | proof        |           | update      |
     +------------+-------------+--------------+-----------+-------------+
     | High       | Sync        | Full         | TEE quote | Financial   |
     |            |             |              | check     | decisions   |
     +------------+-------------+--------------+-----------+-------------+
     | Critical   | Sync        | Full         | Full ZKML | Regulatory, |
     |            |             |              | + TEE     | high-stakes |
     +------------+-------------+--------------+-----------+-------------+

                                    Table 9

  8.  Policy Enforcement

  8.1.  Policy Examples

  8.1.1.  Require Inference Proof for All Agent Outputs






  Krishnan, et al.        Expires 19 September 2026              [Page 18]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     require_inference_proofs {
         intent_chain := get_intent_chain(
             input.intent_root)
         inference_chain := get_inference_chain(
             input.inference_root)

         agent_outputs := [i |
             intent_chain[i].type == "non_deterministic"]

         every i in agent_outputs {
             some j
             inference_chain[j].intent_entry_ref == i
         }
     }

  8.1.2.  Require TEE for Financial Operations

     require_tee_for_finance {
         input.action in ["transfer", "approve",
                           "underwrite"]

         inference_chain := get_inference_chain(
             input.inference_root)

         every entry in inference_chain {
             entry.type in ["tee_attestation",
                            "hybrid_proof"]
         }
     }

  8.1.3.  Block Specific Model Versions

     block_deprecated_models {
         inference_chain := get_inference_chain(
             input.inference_root)

         every entry in inference_chain {
             not entry.model_id in
                 data.deprecated_models
         }
     }

  8.2.  Integration with Policy Engines

     The inference chain claims are designed for consumption by policy
     engines such as Open Policy Agent (OPA).  A policy engine SHOULD:





  Krishnan, et al.        Expires 19 September 2026              [Page 19]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     1.  Verify actor chain integrity (per {{!I-D.draft-mw-spice-actor-
         chain}}).
     2.  Verify intent chain integrity (per {{!I-D.draft-mw-spice-intent-
         chain}}).
     3.  Verify inference_root and inference_registry are present and non-
         empty.
     4.  Evaluate deployment-specific requirements such as proof type
         (ZKML vs TEE), model version policies, and hardware platform
         requirements.

  9.  Security Considerations

  9.1.  STRIDE Analysis for Inference Chain

      +=================+===================+===========================+
      | Threat          | Attack            | Mitigation                |
      +=================+===================+===========================+
      | *Spoofing*      | Model             | model_fingerprint binds   |
      | (Computational) | substitution      | proof to specific weights |
      +-----------------+-------------------+---------------------------+
      | *Tampering*     | Weight            | Hash of weights in proof  |
      | (Model)         | modification      | statement                 |
      +-----------------+-------------------+---------------------------+
      | *Repudiation*   | "I didn't run     | Signed inference entries  |
      |                 | that model"       | with agent SPIFFE ID      |
      +-----------------+-------------------+---------------------------+
      | *Replay*        | Reuse old proof   | input_hash + output_hash  |
      |                 | for new output    | binding + iat timestamp   |
      +-----------------+-------------------+---------------------------+
      | *Environment    | Claim TEE without | TEE quote with hardware-  |
      | Spoofing*       | using one         | signed measurements       |
      +-----------------+-------------------+---------------------------+

                                    Table 10

  9.2.  Trust Assumptions

  9.2.1.  ZKML Proofs

     *  Trust the cryptographic hardness assumptions of the proof system
        (e.g., discrete log for Groth16, collision resistance for STARKs).
     *  Trust the correctness of the arithmetic circuit encoding the
        neural network.
     *  DO NOT require trust in any hardware manufacturer.

  9.2.2.  TEE Attestation





  Krishnan, et al.        Expires 19 September 2026              [Page 20]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     *  Trust the hardware manufacturer's root of trust (Intel, AMD,
        NVIDIA).
     *  Trust the manufacturer's TCB recovery process (firmware updates,
        revocation).
     *  Trust that the TEE hardware correctly isolates the enclave from
        the host.
     *  ACKNOWLEDGE the risk of hardware-level attacks (side channels,
        fault injection) although these require physical access and are
        outside the typical threat model.

  9.3.  Verification Key Management

     For ZKML proofs, the verification key uniquely identifies the circuit
     (and therefore the model architecture).  Verification keys:

     *  MUST be published in a discoverable registry
        (verification_key_registry).
     *  MUST be versioned alongside model versions.
     *  SHOULD be pinned by deployers to prevent key substitution attacks.
     *  MAY be registered in a SCITT transparency log for long-term
        auditability.

  9.4.  Proof Freshness

     Inference proofs MUST include an iat timestamp.  Verifiers SHOULD
     reject proofs older than a configurable maximum age.  For TEE quotes,
     the platform firmware version SHOULD be checked against the
     manufacturer's latest TCB baseline to ensure the hardware is patched.

  9.5.  Credential Isolation

     Inference registry entries MUST NOT contain OAuth tokens, bearer
     credentials, or signing keys.  The relationship between tokens and
     registry entries is one-directional: the token references the
     registry via the inference_registry URI claim, but the registry MUST
     NOT store or reference the token.  This separation ensures that
     compromise of the inference registry does not expose bearer
     credentials.

  9.6.  ZKML Proof Size Considerations

     STARK-based proofs can be tens of kilobytes.  The Merkle tree
     architecture ensures this does not affect token size (only the root
     hash is in the JWT).  However, deployments using STARKs SHOULD
     consider:

     *  Pre-computing and caching proofs for frequently-used model/input
        combinations.



  Krishnan, et al.        Expires 19 September 2026              [Page 21]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     *  Using recursive proof composition to compress multiple STARK
        proofs into a single succinct proof.
     *  Implementing proof compression techniques specific to their proof
        system.

  9.7.  Relationship to Proof of Residency

     The inference chain's TEE attestation entries are complementary to,
     but distinct from, the Proof of Residency (PoR) in actor chain
     entries ({{!I-D.draft-mw-spice-transitive-attestation}}):

     *  *PoR* (in actor chain): Proves the agent's IDENTITY is bound to a
        TEE.  Answers "Is this agent running in a secure environment?"
     *  *TEE Quote* (in inference chain): Proves a specific COMPUTATION
        ran in a TEE.  Answers "Did this model execution happen inside an
        enclave?"

     Both MAY reference the same underlying hardware, but serve different
     verification purposes.  The por_ref field in TEE attestation entries
     allows cross-referencing.

  10.  Privacy Considerations

  10.1.  Model Weight Privacy

     ZKML proofs provide zero-knowledge privacy for model weights — the
     verifier learns that the output was produced by a model with a
     specific fingerprint, but learns nothing about the actual weights.
     This is valuable for proprietary models where the weights are
     confidential.

     TEE attestation provides enclave isolation — the model weights are
     protected from the host OS, but the enclave measurement reveals
     information about the model binary.

  10.2.  Input Privacy

     Both proof types include input_hash rather than the raw input,
     providing input privacy by default.  For applications requiring
     stronger guarantees, ZKML proofs can be constructed to hide the input
     entirely (proving only that "some valid input" produced the output).

  10.3.  Selective Disclosure

     Inference chain entries MAY use Selective Disclosure (SD-JWT) {{!I-
     D.ietf-oauth-selective-disclosure-jwt}} to hide sensitive fields such
     as model_id or platform from certain verifiers while maintaining
     proof integrity.



  Krishnan, et al.        Expires 19 September 2026              [Page 22]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  11.  Implementation Guidance

  11.1.  Current ZKML Landscape

     As of this writing, ZKML is practical for models up to approximately
     100 million parameters.  Active research is scaling this boundary
     through optimized circuit designs and recursive proof composition.

     Deployments SHOULD plan for ZKML scalability improvements and MAY use
     TEE attestation as a near-term bridge.

  11.2.  TEE Integration

     For TEE-based inference proofs:

     1.  Deploy the model inside a TEE enclave (e.g., NVIDIA Confidential
         Computing on H100).
     2.  At inference time, generate a hardware quote binding the input
         hash and output hash to the enclave measurement.
     3.  Append the quote as a TEE attestation entry to the inference
         registry.
     4.  The quote's report_data field MUST contain sha256(input_hash ||
         output_hash) to bind the proof to specific content.

  11.3.  Scalability Considerations

     *  *Async ZKML*: ZKML proofs MAY be generated asynchronously after
        inference.  The intent chain entry is appended immediately; the
        inference chain entry is appended when the proof is ready.  The
        Merkle root is recomputed at token exchange time.
     *  *Proof Batching*: Multiple inference operations MAY be batched
        into a single ZKML proof using recursive composition, reducing
        verification overhead.
     *  *Quote Caching*: TEE quotes for the same enclave measurement MAY
        be cached for a configurable period, reducing quote generation
        overhead.

  11.4.  Multi-AS Deployments

     In deployments involving multiple Authorization Servers, the
     inference registry is shared across all participating ASes under the
     same session partition.  Each AS appends inference chain entries
     under the sid partition established at session initiation.  The
     inference_root in each successive token is recomputed over all proof
     entries accumulated so far — it therefore differs at each hop as the
     chain grows.  This is expected behavior: a relying party receiving a
     later token will see a larger inference_root than one receiving an
     earlier token in the same session.  ASes do not need to share keys or



  Krishnan, et al.        Expires 19 September 2026              [Page 23]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     coordinate directly — the session partition and append-only log
     semantics provide the necessary consistency, following the same
     pattern as the Actor Chain Registry ({{!I-D.draft-mw-spice-actor-
     chain}}) and Intent Registry ({{!I-D.draft-mw-spice-intent-chain}}).

  11.5.  Registry Availability

     Inference registry unavailability does not affect data-plane
     operation — the token's AS-signed inference_root is sufficient for
     request-time policy decisions.  Per-entry proof verification is
     deferred to the audit plane.

     However, inference proofs are uniquely valuable because they cannot
     be regenerated after the fact — the exact model state, input, and
     execution environment may no longer be available.  Deployments
     SHOULD:

     *  Replicate inference registry entries across availability zones.
     *  Use append-only log services designed for high durability (e.g.,
        SCITT transparency logs).
     *  Define a fail-mode policy: *fail-closed* for regulated workloads
        (e.g., financial, healthcare), or *fail-open* with verification
        gap logging for lower-risk workloads.

     A federated IAM/IdM platform (e.g., Keycloak, Microsoft Entra, Okta,
     PingFederate) MAY host the inference registry alongside the Actor
     Chain Registry and Intent Registry under the same session partition —
     see {{!I-D.draft-mw-spice-actor-chain}} Section "Registry Hosting"
     for detailed requirements.

  11.5.1.  Proof Size and Storage

     Inference proof payloads are significantly larger than actor chain
     entries (~0.5-1KB) or intent chain entries (_(0.5-1KB):)

















  Krishnan, et al.        Expires 19 September 2026              [Page 24]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


        +=======================+==============+======================+
        | Proof Type            | Typical Size | Storage Implication  |
        +=======================+==============+======================+
        | TEE attestation quote | _(2-4KB)     | Compatible with most |
        |                       |              | IAM data stores      |
        +-----------------------+--------------+----------------------+
        | Groth16 ZK proof      | ~200 bytes   | Compatible with most |
        |                       |              | IAM data stores      |
        +-----------------------+--------------+----------------------+
        | STARK proof           | _50KB        | May exceed IAM data  |
        |                       |              | store blob limits    |
        +-----------------------+--------------+----------------------+

                                    Table 11

     Most IAM/IdM platforms are not designed to store large binary blobs.
     Deployments that include STARK proofs SHOULD either:

     *  Use a dedicated object store (e.g., S3, GCS, Azure Blob Storage)
        for proof payloads, with the IAM platform serving as the registry
        index and access control layer.
     *  Or use a SCITT transparency log that natively supports variable-
        size entries.

  11.6.  Performance Guidance: TEE vs ZKML

     Deployments SHOULD select proof types based on their latency
     requirements:

     *  *Real-time applications* (chat, interactive agents, API serving):
        Use TEE attestation quotes exclusively.  TEE proof generation adds
        millisecond-level overhead and is compatible with production-scale
        LLMs (100B+ parameters).
     *  *Batch/offline applications* (document generation, model
        evaluation, regulatory reporting): ZKML proofs provide
        mathematical certainty independent of hardware trust.  Proof
        generation latency (minutes to hours) is acceptable when not on
        the critical path.
     *  *Hybrid deployments*: Use TEE quotes for real-time inference and
        generate ZKML proofs asynchronously for high-value operations,
        appending them to the inference chain after the fact.  The Merkle
        root is recomputed at the next token exchange.









  Krishnan, et al.        Expires 19 September 2026              [Page 25]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  12.  Design Rationale: Merkle Root in Token

     The inference chain follows the same Merkle root architecture as the
     intent chain (see {{!I-D.draft-mw-spice-intent-chain}} Design
     Rationale for the detailed comparison).  The same trade-offs apply,
     with additional motivation: inference proofs are large (STARK proofs
     ~50KB, TEE quotes ~2-4KB), making inline embedding in tokens
     impractical.  The Merkle root enables selective verification of
     individual proofs using O(log n) sibling hashes, which is critical
     for the tiered verification strategy.

  13.  IANA Considerations

  13.1.  JWT Claim Registration

     This document requests registration of the following claims in the
     "JSON Web Token Claims" registry established by {{!RFC7519}}:

     *  *Claim Name*: inference_root

     *  *Claim Description*: Merkle root hash of the inference chain for
        computational provenance verification.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: inference_proof_type

     *  *Claim Description*: Primary proof algorithm used in the inference
        chain.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: inference_registry

     *  *Claim Description*: URI of the inference registry for proof
        retrieval.

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]







  Krishnan, et al.        Expires 19 September 2026              [Page 26]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  13.2.  CWT Claim Registration

     This document requests registration of the following claims in the
     "CBOR Web Token (CWT) Claims" registry established by {{!RFC8392}}:

     *  *Claim Name*: inference_root

     *  *Claim Description*: Merkle root hash of the inference chain.

     *  *CBOR Key*: TBD (e.g., 60)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: inference_registry

     *  *Claim Description*: URI of the inference registry for proof
        retrieval.

     *  *CBOR Key*: TBD (e.g., 61)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

     *  *Claim Name*: inference_proof_type

     *  *Claim Description*: Primary proof algorithm used in the inference
        chain.

     *  *CBOR Key*: TBD (e.g., 62)

     *  *Claim Type*: tstr

     *  *Change Controller*: IETF

     *  *Specification Document(s)*: [this document]

  Appendix A.  Full Token Example (Three-Chain Governance)







  Krishnan, et al.        Expires 19 September 2026              [Page 27]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


     {
       "iss": "https://auth.example.com",
       "sub": "user-alice",
       "aud": "https://api.example.com",
       "jti": "tok-fff-67890",
       "iat": 1700000000,
       "exp": 1700003600,

       "session": {
         "session_id": "sess-uuid-12345",
         "type": "human_initiated",
         "initiator": "user-alice",
         "approval_ref": "approval-uuid-789",
         "max_chain_depth": 5
       },

       "actor_chain": [
         {
           "sub":
             "spiffe://example.com/agent/orchestrator",
           "iss": "https://auth.example.com",
           "iat": 1700000010,
           "scope": "ticket:*",
           "chain_digest": "sha256:aaa...",
           "chain_sig": "eyJhbGci..."
         },
         {
           "sub":
             "spiffe://example.com/agent/analyst",
           "iss": "https://auth.example.com",
           "iat": 1700000030,
           "scope": "analysis:run",
           "chain_digest": "sha256:bbb...",
           "chain_sig": "eyJhbGci..."
         }
       ],

       "intent_root": "sha256:abc123...",
       "intent_registry":
         "https://intent-log.example.com/sessions/sess-uuid-12345",

       "inference_root": "sha256:xyz789...",
       "inference_proof_type": "tee_h100",
       "inference_registry":
         "https://proof-log.example.com/sessions/sess-uuid-12345"
     }





  Krishnan, et al.        Expires 19 September 2026              [Page 28]


  Internet-Draft            SPICE-INFERENCE-CHAIN               March 2026


  Authors' Addresses

     Ram Krishnan
     JPMorgan Chase & Co
     Email: ramkri123@gmail.com


     A Prasad
     Oracle
     Email: a.prasad@oracle.com


     Diego R. Lopez
     Telefonica
     Email: diego.r.lopez@telefonica.com


     Srinivasa Addepalli
     Aryaka
     Email: srinivasa.addepalli@aryaka.com































  Krishnan, et al.        Expires 19 September 2026              [Page 29]


name: draft-williams-intent-token
rev: 00
title: The Intent Token: A Cryptographic Authorization Primitive for Autonomous Agents
time: 2026-03-19T03:26:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-20T03:26:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:48.589008+00:00
source: ietf
abstract:
  This document specifies the Intent Token, a cryptographic
     authorization primitive for autonomous AI agent systems.  An Intent
     Token binds an autonomous agent action to a cryptographically signed,
     human-declared authorization envelope before that action is executed.
     The Intent Token addresses a fundamental gap in existing
     authorization frameworks: while OAuth 2.0, OIDC, and related
     standards govern identity and access at the session level, no
     standardized primitive exists for governing what an autonomous agent
     is authorized to DO at the moment of action.  The Intent Token
     provides this primitive.  It is model-agnostic, transport-agnostic,
     and composable with existing authorization infrastructure.

full_text:
  Internet Engineering Task Force                              J. Williams
  Internet-Draft                                               Independent
  Intended status: Informational                             19 March 2026
  Expires: 20 September 2026


  The Intent Token: A Cryptographic Authorization Primitive for Autonomous
                                   Agents
                       draft-williams-intent-token-00

  Abstract

     This document specifies the Intent Token, a cryptographic
     authorization primitive for autonomous AI agent systems.  An Intent
     Token binds an autonomous agent action to a cryptographically signed,
     human-declared authorization envelope before that action is executed.
     The Intent Token addresses a fundamental gap in existing
     authorization frameworks: while OAuth 2.0, OIDC, and related
     standards govern identity and access at the session level, no
     standardized primitive exists for governing what an autonomous agent
     is authorized to DO at the moment of action.  The Intent Token
     provides this primitive.  It is model-agnostic, transport-agnostic,
     and composable with existing authorization infrastructure.

  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 20 September 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.






  Williams                Expires 20 September 2026               [Page 1]


  Internet-Draft                Intent Token                    March 2026


     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.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  The Authorization Gap Beyond OAuth 2.0  . . . . . . . . .   5
       3.2.  The Delegation Depth Problem  . . . . . . . . . . . . . .   5
       3.3.  The Confused Deputy Problem in Autonomous Systems . . . .   5
     4.  The Intent Token  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Token Structure . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Required Claims . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Temporal Scope and Shard Binding  . . . . . . . . . . . .   7
       4.4.  Delegation Chain Encoding . . . . . . . . . . . . . . . .   7
     5.  Intent Certificate  . . . . . . . . . . . . . . . . . . . . .   7
     6.  Enforcement Binding . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Pre-Action Validation . . . . . . . . . . . . . . . . . .   8
       6.2.  SNAP-BACK on Violation  . . . . . . . . . . . . . . . . .   8
       6.3.  Audit Chain Requirements  . . . . . . . . . . . . . . . .   8
     7.  Interoperability  . . . . . . . . . . . . . . . . . . . . . .   8
       7.1.  Relationship to OAuth 2.0 . . . . . . . . . . . . . . . .   8
       7.2.  Relationship to Delegation Capability Tokens  . . . . . .   9
       7.3.  Relationship to W3C Verifiable Credentials  . . . . . . .   9
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
       10.2.  Informative References . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     The deployment of autonomous AI agents in consequential domains --
     financial services, healthcare, critical infrastructure, autonomous
     vehicles, and multi-agent orchestration systems -- creates a class of
     authorization problems that existing standards do not address.

     OAuth 2.0 [RFC6749] governs whether a principal has access to a
     resource.  OpenID Connect [OIDC] governs whether a principal is who
     they claim to be.  These standards address the WHO question: who is
     this agent, and what resources may it access?





  Williams                Expires 20 September 2026               [Page 2]


  Internet-Draft                Intent Token                    March 2026


     Neither standard addresses the WHAT question: given that an agent has
     access, what specific actions is it authorized to perform at this
     moment, on behalf of this principal, within these declared
     boundaries?

     The gap between access and action is the authorization gap.  In
     human-operated systems, this gap is bridged by human judgment.  In
     autonomous agent systems, this gap is bridged by the agent itself --
     which may interpret its authorization scope in ways the authorizing
     principal did not intend.  This is the intent blindness problem.

     This document specifies the Intent Token, a cryptographic primitive
     that closes the authorization gap.  An Intent Token is a signed,
     time-bounded authorization envelope that:

     *  Declares what action a principal authorizes an agent to perform,
        BEFORE the action is executed;

     *  Binds that declaration cryptographically to the agent session and
        the specific action;

     *  Provides a verifiable, tamper-evident record of the authorization
        for audit purposes;

     *  Propagates the declared intent through delegation chains,
        preventing sub-agents from exceeding the scope the delegating
        principal was itself authorized to grant.

     The Intent Token is the core primitive of the Intent Bound
     Authorization (IBA) framework, patent application GB2603013.0
     (pending, UK IPO, filed February 5, 2026, PCT rights in 150+
     countries until August 2028).

     Independent convergence on this primitive was identified in Google
     DeepMind's introduction of Delegation Capability Tokens (DCTs)
     [DEEPMIND-DCT], February 12, 2026, seven days after the IBA patent
     filing.  DeepMind's paper identifies the same open problem: no
     standardized ontology for intent and responsibility across autonomous
     agent platforms exists.  This document proposes the Intent Token as
     the candidate standard to fill that gap.

     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.





  Williams                Expires 20 September 2026               [Page 3]


  Internet-Draft                Intent Token                    March 2026


  2.  Terminology

     Intent Token:  A cryptographically signed authorization envelope that
        declares what action a principal authorizes an autonomous agent to
        perform, issued before the action is executed, and bound to a
        specific session shard.

     Intent Certificate:  A persistent, verifiable credential that records
        the full authorization context for an agent session, including the
        principal identity, declared scope, temporal bounds, and
        cryptographic proof of all enforcement decisions made during the
        session.

     Principal:  The human or organizational entity whose declared intent
        authorizes the agent action.  The principal MUST be
        cryptographically identified in every Intent Token.

     Authorized Agent:  An autonomous system authorized to act within the
        scope declared in an Intent Token.

     Shard:  A time-bounded cryptographic token issued by the IBA Gate
        that must be presented with every agent action.  Shards expire
        after a configurable window (default 512 seconds).

     IBA Gate:  The enforcement point that validates Intent Tokens before
        permitting agent actions.

     SNAP-BACK:  The mandatory cancellation of an agent action when Intent
        Token validation fails.  SNAP-BACK MUST occur before the action
        has market or physical effect.

     Delegation Chain:  The ordered sequence of principals and agents
        through which authorization has been delegated.  Each link is
        cryptographically signed.  No link may grant scope exceeding the
        scope granted to the delegating entity.

     TBDE:  Temporal Boundary Decision Engine.  The runtime component
        responsible for validating every agent action against the declared
        Intent Token within the enforcement latency target.

     WitnessBound Audit Chain:  An append-only, cryptographically chained
        audit record of all enforcement decisions providing tamper-evident
        proof of all authorization decisions.

  3.  Problem Statement






  Williams                Expires 20 September 2026               [Page 4]


  Internet-Draft                Intent Token                    March 2026


  3.1.  The Authorization Gap Beyond OAuth 2.0

     OAuth 2.0 access tokens grant access to resource scopes.  A token
     with scope "read:financial_data" grants read access to financial
     data.  It does not specify which financial data, under what
     conditions, at what time, or within what value limits.

     An autonomous agent with an access token has no cryptographic
     constraint on what it does within its granted scope -- including
     actions the authorizing principal never contemplated.  Existing
     mitigations -- rate limiting, anomaly detection, audit logging -- are
     post-hoc.  The Intent Token is pre-hoc: it declares and enforces
     authorization before action.

  3.2.  The Delegation Depth Problem

     Modern autonomous agent architectures are hierarchical.  An
     orchestrating agent delegates tasks to sub-agents, which may delegate
     further.  Existing delegation frameworks, including OAuth 2.0 Token
     Exchange [RFC8693], do not provide a mechanism for propagating
     declared human intent through the delegation chain.

     The Intent Token addresses this by requiring that every link in the
     delegation chain present a valid Intent Token that is a subset of the
     authorizing token.  A sub-agent cannot act outside the scope its
     delegating principal was itself authorized to grant.

  3.3.  The Confused Deputy Problem in Autonomous Systems

     The confused deputy problem [HARDY-1988] describes a scenario in
     which a system with legitimate authority is manipulated into misusing
     that authority.  In autonomous agent systems, an agent may be
     manipulated via prompt injection, adversarial input, or environmental
     manipulation into taking actions outside its intended scope.

     The Intent Token defends against confused deputy attacks.  Because
     the authorized action is declared and signed by the principal BEFORE
     the agent acts, any deviation from the declared intent -- regardless
     of cause -- is detected and blocked at the enforcement layer.

  4.  The Intent Token

  4.1.  Token Structure

     An Intent Token is a JSON Web Token [RFC7519] with the following
     structure.  The header MUST include "typ": "intent+jwt".





  Williams                Expires 20 September 2026               [Page 5]


  Internet-Draft                Intent Token                    March 2026


     {
       "header": {
         "alg": "ES256",
         "typ": "intent+jwt"
       },
       "payload": {
         "iss": "https://intentbound.example.com",
         "sub": "agent-id:AG-7729-ALPHA",
         "aud": "iba-gate:production",
         "exp": 1771234567,
         "iat": 1771230967,
         "jti": "a8f3c2d1-4b5e-6f7a-8b9c-0d1e2f3a4b5c",
         "ibt_ver": "1.0",
         "principal": {
           "id": "user:jeffrey.williams@example.com",
           "type": "human",
           "auth_method": "ES256-keypair"
         },
         "declared_intent": {
           "action_class": "financial:order:equity",
           "scope": "EQUITIES_US",
           "bounds": {
             "max_position_usd": 50000000,
             "max_single_order_usd": 5000000,
             "permitted_instruments": ["NYSE:*", "NASDAQ:*"],
             "prohibited_instruments": ["OTC:*"],
             "time_window": "09:30-16:00 EST"
           }
         },
         "shard": {
           "id": "shard:mmc-nbwc-enyn",
           "issued_at": 1771230967,
           "expires_at": 1771231479,
           "window_seconds": 512
         },
         "enforcement": {
           "snap_back": true,
           "latency_target_ms": 5,
           "audit_chain": "witnessbound:production"
         }
       }
     }

  4.2.  Required Claims

     The following claims are REQUIRED in every Intent Token:

     ibt_ver:  The version of the Intent Token specification.  This



  Williams                Expires 20 September 2026               [Page 6]


  Internet-Draft                Intent Token                    March 2026


        document defines version "1.0".

     principal:  An object identifying the authorizing human principal.
        MUST include "id" (a URI) and "type" ("human" or "organization").

     declared_intent:  An object declaring the specific action class the
        principal authorizes.  MUST include "action_class" and "scope".

     shard:  An object binding the token to a specific time-bounded
        session shard.  MUST include "id", "issued_at", "expires_at", and
        "window_seconds".

     enforcement:  An object specifying enforcement requirements.  MUST
        include "snap_back" (boolean, MUST be true) and "audit_chain" (URI
        of the audit chain endpoint).

     Standard JWT claims iss, sub, aud, exp, iat, and jti are REQUIRED.

  4.3.  Temporal Scope and Shard Binding

     Every Intent Token MUST be bound to a time-bounded shard.  The shard
     provides temporal scope and session binding.  The default shard
     window is 512 seconds.  When a shard expires, the agent MUST obtain a
     new Intent Token before continuing to act.  The enforcement layer
     MUST reject any action presented with an expired shard.

  4.4.  Delegation Chain Encoding

     When an authorizing agent delegates to a sub-agent, the delegating
     agent MUST issue a new Intent Token with a declared_intent scope that
     is a subset of its own authorized scope.  A delegating agent MUST NOT
     grant scope exceeding its own authorization.  The delegation_chain
     array MUST include all prior delegation records plus a new signed
     record for this delegation.

  5.  Intent Certificate

     An Intent Certificate is the persistent audit record of an agent
     session.  It MUST contain: the principal identity and authentication
     record; the declared scope for the session; the temporal bounds; a
     reference to the WitnessBound audit chain; cryptographic hashes of
     all Intent Tokens issued during the session; and a signed summary of
     all enforcement decisions including SNAP-BACK events.

     Intent Tokens and Intent Certificates MUST be signed using algorithms
     from NIST SP 800-57 [NIST-SP-800-57].  Implementations MUST support
     ES256 [RFC7518].  Implementations SHOULD support ES384 and EdDSA
     [RFC8037] for higher-security deployments.



  Williams                Expires 20 September 2026               [Page 7]


  Internet-Draft                Intent Token                    March 2026


  6.  Enforcement Binding

  6.1.  Pre-Action Validation

     The IBA Gate MUST validate the Intent Token BEFORE the agent action
     is permitted to execute.  The IBA Gate MUST verify: token signature
     validity; token and shard expiry; action matches declared_intent
     action_class; action parameters are within declared bounds;
     delegation chain validity; and jti uniqueness for replay prevention.

     Implementations MUST complete all validations within the
     latency_target_ms specified in the enforcement claim.  The target is
     5ms.

  6.2.  SNAP-BACK on Violation

     If any validation check fails, the IBA Gate MUST: reject the agent
     action immediately; record a SNAP-BACK event in the WitnessBound
     audit chain; return a structured error to the agent; and NOT permit
     the action to be retried without a new Intent Token authorized by the
     principal.  SNAP-BACK is a hard stop.  No partial execution is
     permitted.

  6.3.  Audit Chain Requirements

     Every enforcement decision MUST be recorded in the WitnessBound audit
     chain.  Each record MUST contain: the jti of the Intent Token; the
     validation timestamp (nanosecond precision RECOMMENDED); the
     validation result (PASS or SNAP-BACK); and a cryptographic hash
     chained to the previous record.  This audit chain satisfies the audit
     requirements of EU AI Act Article 9, MiFID II, FDA Cybersecurity
     2023, and HIPAA Security Rule.

  7.  Interoperability

  7.1.  Relationship to OAuth 2.0

     The Intent Token is complementary to OAuth 2.0 [RFC6749].  OAuth 2.0
     governs access; the Intent Token governs action.  In a compliant
     implementation: the agent obtains an OAuth 2.0 access token
     establishing resource access; the principal issues an Intent Token
     declaring the specific authorized action; the IBA Gate validates the
     Intent Token before permitting the action.








  Williams                Expires 20 September 2026               [Page 8]


  Internet-Draft                Intent Token                    March 2026


  7.2.  Relationship to Delegation Capability Tokens

     Tomasev et al.  [DEEPMIND-DCT] introduced Delegation Capability
     Tokens (DCTs) as a primitive for AI agent authorization.  DCTs
     address the same authorization gap as the Intent Token, arriving
     independently seven days after the IBA patent filing.  The IETF is
     encouraged to consider harmonization between this specification and
     the DCT work, given the independent convergence on the same
     primitive.

  7.3.  Relationship to W3C Verifiable Credentials

     Intent Certificates MAY be implemented as W3C Verifiable Credentials
     [VC-DATA-MODEL], using the "IntentCertificate" credential type with
     credential subject claims encoding the session authorization context
     specified in Section 5.

  8.  Security Considerations

     Replay Attacks: Intent Tokens MUST include a unique jti claim.  The
     IBA Gate MUST maintain a record of used jti values for the duration
     of the shard window.

     Token Forgery: Implementations MUST follow NIST SP 800-57 for key
     management.  Hardware security modules (HSMs) are RECOMMENDED for
     principal signing keys in high-security deployments.

     Scope Escalation: Implementations MUST validate the complete
     delegation chain, not only the most recent delegation record.

     Prompt Injection: The Intent Token provides defense against prompt
     injection attacks.  An agent manipulated into attempting an out-of-
     scope action will be stopped by SNAP-BACK regardless of the cause.

     Enforcement Latency: The 5ms enforcement latency target is a security
     parameter.  In financial systems, actions with market impact occur
     faster than 5ms.  Implementations in latency-sensitive domains MUST
     measure and report enforcement latency.

     Audit Chain Integrity: Implementations MUST store audit chain records
     in append-only storage with access controls preventing modification
     or deletion.

  9.  IANA Considerations

     This document requests the following JWT Claim registrations:

     *  Claim Name: ibt_ver -- Intent Token specification version



  Williams                Expires 20 September 2026               [Page 9]


  Internet-Draft                Intent Token                    March 2026


     *  Claim Name: declared_intent -- Principal-declared authorized
        action scope

     *  Claim Name: shard -- Time-bounded session shard binding

     *  Claim Name: enforcement -- Enforcement requirements for this token

     *  Claim Name: delegation_chain -- Ordered delegation records

     This document requests registration of the media type application/
     intent+jwt for Intent Tokens.

  10.  References

  10.1.  Normative References

     [NIST-SP-800-57]
                National Institute of Standards and Technology,
                "Recommendation for Key Management: Part 1 - General",
                NIST Special Publication 800-57 Part 1 Rev 5, May 2020.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, May
                2015, <https://www.rfc-editor.org/info/rfc7518>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC8037]  Liusvaara, I., "CFRG Elliptic Curves for JOSE", RFC 8037,
                January 2017, <https://www.rfc-editor.org/info/rfc8037>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, May 2017,
                <https://www.rfc-editor.org/info/rfc8174>.

     [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
                and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
                January 2020, <https://www.rfc-editor.org/info/rfc8693>.

  10.2.  Informative References



  Williams                Expires 20 September 2026              [Page 10]


  Internet-Draft                Intent Token                    March 2026


     [DEEPMIND-DCT]
                Tomasev, N., "Delegation Capability Tokens for AI Agent
                Authorization", arXiv 2602.11865, February 2026.

     [HARDY-1988]
                Hardy, N., "The Confused Deputy (or why capabilities might
                have been invented)", SIGOPS Operating Systems
                Review Volume 22, Issue 4, October 1988.

     [OIDC]     Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
                C. Mortimore, "OpenID Connect Core 1.0", November 2014.

     [VC-DATA-MODEL]
                Sporny, M., "Verifiable Credentials Data Model v2.0", May
                2024.

  Author's Address

     Jeffrey Williams
     Independent
     Chiang Mai
     Thailand
     Email: urls@live.com




























  Williams                Expires 20 September 2026              [Page 11]


name: draft-wang-jep-judgment-event-protocol
rev: 06
title: Judgment Event Protocol (JEP)
time: 2026-05-04T07:47:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-05T07:47:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:48.589023+00:00
source: ietf
abstract:
  This document defines the Judgment Event Protocol (JEP), a neutral
  verifiable event format for decision-related operations in human,
  organizational, software, and autonomous agent systems.

  JEP specifies four immutable event verbs: Judgment (J), Delegation (D),
  Termination (T), and Verification (V). It defines a signed JSON event
  structure, anti-replay fields, detached JSON Web Signature (JWS)
  verification over JSON Canonicalization Scheme (JCS) canonicalized
  payloads, event hash and reference semantics, validation levels,
  structured validation results, failure codes, extension handling,
  trust-profile interfaces, and determinability boundaries.

  JEP is intended to provide a global protocol-level interoperability
  layer for verifiable decision event records. JEP-Core does not define
  legal liability, authorization validity, regulatory compliance,
  organizational trust decisions, global identity, global truth, or
  mandatory support for any specific credential, identity, AI platform,
  agent framework, or blockchain system.

  ---

full_text:
  Network Working Group                                         Y. Wang
  Internet-Draft                                             Independent
  Intended status: Experimental
  Expires: November 5, 2026                                      May 4, 2026

                      Judgment Event Protocol (JEP)
                      draft-wang-jep-judgment-event-protocol-06
  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 November 5, 2026.

  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.  Please review these documents
     carefully, as they describe your rights and restrictions with respect
     to this document.  Code Components extracted from this document must
     include Revised BSD License text as described in Section 4.e of the
     Trust Legal Provisions and are provided without warranty as described
     in the Revised BSD License.

  Table of Contents

     1        Introduction
     2        Protocol Objective and Non-Goals
     1        an event payload existed;
     2        the event payload was signed as specified;
     3        the payload was bound to an actor identifier under a trust profile;
     4        the event carried a timestamp, nonce, optional audience, and optional
     5        references, event hashes, and critical extensions were processed
     6        a verifier reached a declared validation level.
     3        Design Principles
     1        Core minimality: JEP-Core defines the stable narrow-waist event
     2        Identity-system neutrality: JEP-Core MUST NOT require any
     3        Credential-system neutrality: JEP-Core MUST NOT require VC or any
     4        Platform neutrality: JEP-Core MUST NOT require any AI platform,
     5        Profile-based interoperability: identity, credentials,
     6        Layered verification: syntax, cryptographic validity,
     7        Explicit determinability boundary: protocol validity is not the
     8        Privacy by minimization: sensitive evidence SHOULD be referenced
     9        Extension without semantic capture: extensions MUST NOT redefine
     10       Algorithm agility: cryptographic algorithms are selected by JOSE
     4        Requirements Language
     5        Terminology
     6        Core Event Object
     7        Field Semantics
     8        Event Verb Semantics
     9        References and Chains
     10       Algorithm-Tagged Digest Strings
     11       Event Hashes and Signing Input
     12       Signature, Hash, and Algorithm Agility
     13       Trust Profile Interface
     14       Validation Model
     1        parse JSON;
     2        reject duplicate JSON member names;
     3        check required top-level fields;
     4        check verb-specific field requirements;
     5        remove sig to construct unsigned event;
     6        canonicalize unsigned event using JCS;
     7        verify detached signature;
     8        compute event hash if needed;
     9        resolve actor/key under trust profile;
     10       check actor/key binding;
     11       check nonce and freshness for acceptance mode;
     12       validate aud if present and relevant;
     13       resolve and validate references if applicable;
     14       process critical extensions;
     15       apply chain rules, including termination effects;
     16       apply optional policy rules;
     17       return structured validation result.
     15       Validation Result Object
     16       Failure Codes
     17       Extension Rules and Conflict Handling
     1        extension identifier;
     2        extension version;
     3        JSON schema or equivalent data model;
     4        whether it may be critical;
     5        validation requirements;
     6        security considerations;
     7        privacy considerations;
     8        interaction with event hashes and signatures;
     9        interaction with other known extensions, if applicable.
     18       Conformance Requirements
     19       Determinability Boundary
     20       Observed Log Assumptions
     21       Relationship to HJS and JAC
     22       Security Considerations
     23       Privacy Considerations
     24       Registry Considerations
     25       Versioning and Compatibility
     26       Examples
     27       Changes from -05

  Judgment Event Protocol (JEP)
  A Neutral Verifiable Event Format for Agent Decisions
  draft-wang-jep-judgment-event-protocol-06

  Author: Yuqiang Wang  
  Intended status: Experimental  
  Version: -06 working draft  
  Companion drafts:
  - draft-wang-jep-profiles-00
  - draft-wang-jep-conformance-00

  ---

  Abstract

  This document defines the Judgment Event Protocol (JEP), a neutral
  verifiable event format for decision-related operations in human,
  organizational, software, and autonomous agent systems.

  JEP specifies four immutable event verbs: Judgment (J), Delegation (D),
  Termination (T), and Verification (V). It defines a signed JSON event
  structure, anti-replay fields, detached JSON Web Signature (JWS)
  verification over JSON Canonicalization Scheme (JCS) canonicalized
  payloads, event hash and reference semantics, validation levels,
  structured validation results, failure codes, extension handling,
  trust-profile interfaces, and determinability boundaries.

  JEP is intended to provide a global protocol-level interoperability
  layer for verifiable decision event records. JEP-Core does not define
  legal liability, authorization validity, regulatory compliance,
  organizational trust decisions, global identity, global truth, or
  mandatory support for any specific credential, identity, AI platform,
  agent framework, or blockchain system.

  ---


  1. Introduction

  Autonomous and semi-autonomous agent systems increasingly make, assist
  with, delegate, terminate, verify, or record decisions across
  organizational, platform, model, and jurisdictional boundaries. These
  systems need a minimal and interoperable way to record decision-related
  events so that later verifiers can determine whether a particular event
  payload existed, whether it was signed under an applicable trust profile,
  whether it was modified, whether it refers to other events or evidence,
  and which validation level has been reached.

  JEP addresses this need by defining a compact signed JSON event format.
  The format is intentionally narrow: it records an event verb, actor
  identifier, timestamp, claim or digest, nonce, optional audience,
  references, extensions, and signature. More complex identity,
  credential, policy, archival, evidence, or causal-chain semantics are
  externalized to profiles, extensions, HJS-like archival layers, or
  JAC-like chain-composition layers.

  JEP records verifiable protocol facts. It does not by itself prove
  external target facts. In partially observed systems, a signed event log
  can support audit and accountability workflows without guaranteeing
  complete or zero-error determination of external facts.

  ---

  2. Protocol Objective and Non-Goals

  2.1 Objective

  JEP-Core defines a neutral event layer for verifiable judgment-related
  acts. A conforming JEP event can support determination, subject to the
  applicable validation mode and trust profile, that:

  1. an event payload existed;
  2. the event payload was signed as specified;
  3. the payload was bound to an actor identifier under a trust profile;
  4. the event carried a timestamp, nonce, optional audience, and optional
     references or extensions;
  5. references, event hashes, and critical extensions were processed
     according to JEP-Core rules;
  6. a verifier reached a declared validation level.

  2.2 Non-Goals

  JEP-Core does not define:

  - legal liability;
  - moral responsibility;
  - regulatory compliance;
  - global truth determination;
  - external target-fact determinability;
  - authorization delegation validity;
  - permission-chain enforcement;
  - lifecycle state-machine enforcement;
  - a global identity framework;
  - a global credential framework;
  - a global trust framework;
  - mandatory DID, VC, X.509, OAuth, RATS, blockchain, or AI-platform
    support;
  - confidentiality for event content;
  - long-term storage, redaction, retention, or disclosure policy;
  - causal-chain or responsibility-graph computation.

  A JEP event records claims about judgment-related acts. It MUST NOT be
  presented as proof that the underlying real-world assertion is true
  unless an applicable external profile and evidence policy makes that
  determination.

  ---

  3. Design Principles

  JEP-Core follows these principles:

  1. Core minimality: JEP-Core defines the stable narrow-waist event
     layer.
  2. Identity-system neutrality: JEP-Core MUST NOT require any
     specific identity system.
  3. Credential-system neutrality: JEP-Core MUST NOT require VC or any
     other credential model.
  4. Platform neutrality: JEP-Core MUST NOT require any AI platform,
     agent framework, cloud provider, or blockchain network.
  5. Profile-based interoperability: identity, credentials,
     attestation, authorization, and archival policy are handled by
     optional profiles.
  6. Layered verification: syntax, cryptographic validity,
     actor-binding, chain validation, and policy validation are separate.
  7. Explicit determinability boundary: protocol validity is not the
     same as external truth.
  8. Privacy by minimization: sensitive evidence SHOULD be referenced
     by digest or controlled evidence mechanisms rather than embedded in
     event payloads.
  9. Extension without semantic capture: extensions MUST NOT redefine
     JEP-Core semantics.
  10. Algorithm agility: cryptographic algorithms are selected by JOSE
      headers, conformance profiles, and trust profiles rather than by
      event verbs.

  ---

  4. 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
  when, and only when, they appear in all capitals.

  ---

  5. Terminology

  Actor: The entity identified by who that is claimed by the event.
  An actor MAY be a human, organization, model, agent, tool, service,
  device, workflow, committee, session, swarm, human-agent composite, or
  organization-agent composite.

  Signer: The key holder that produces the event signature. The signer
  is not necessarily identical to the actor. The binding between signer and
  actor is defined by a trust profile.

  Subject: The entity or object about which a decision, delegation,
  termination, or verification is made. A subject is distinct from the
  actor.

  Event: A single immutable signed JSON object representing one
  judgment-related act.

  Unsigned Event: A JEP event object with the sig member omitted.

  JEP Signing Payload: The UTF-8 octets of the JCS-canonicalized
  unsigned event.

  Event Hash: An algorithm-tagged digest over the full signed event.

  Claim: Semantic content carried by what or by an extension.

  Reference: A cryptographic or typed pointer to another event, chain,
  digest, credential, policy, evidence, context, archive receipt, or
  external object.

  Trust Profile: A profile that defines actor identifier forms,
  signing-key resolution, actor/key binding, revocation, historical
  validity, acceptable algorithms, and related evidence policy.

  Validation Level: The highest validation stage completed by a
  verifier.

  Validation Mode: The context in which validation is performed, such
  as acceptance, archival, chain, or policy review.

  Verification Scope: The declared scope of a V event, such as syntax,
  cryptographic, actor-binding, chain-integrity, credential-status, policy
  compliance, human review, external evidence, factual claim, or archival
  integrity.

  ---

  6. Core Event Object

  A JEP event is a JSON object. Producers MUST emit I-JSON-compatible JSON
  and MUST NOT emit duplicate JSON member names. Verifiers MUST reject
  events containing duplicate JSON member names.

  The top-level members are:

  | Member | Status | Description |
  |---|---|---|
  | jep | REQUIRED | Wire-format major version. For this draft, "1". |
  | verb | REQUIRED | One of "J", "D", "T", "V". |
  | who | REQUIRED | Actor identifier claimed by the event. |
  | when | REQUIRED | Actor-supplied event timestamp, Unix seconds. |
  | what | Conditional | Claim object, descriptor, or algorithm-tagged digest. |
  | nonce | REQUIRED | Replay-protection nonce. |
  | aud | RECOMMENDED | Intended audience or validation context. |
  | ref | Conditional | Typed reference or event hash reference. |
  | ext | OPTIONAL | Extension object. |
  | ext_crit | OPTIONAL | Critical extension identifier list. |
  | sig | REQUIRED | Detached signature container. |

  The top-level extensibility mechanism is ext. Producers SHOULD NOT add
  new top-level members outside this specification unless defined by a
  future JEP revision or a registered extension that explicitly updates the
  top-level object.

  ---

  7. Field Semantics

  7.1 jep

  The jep member identifies the wire-format major version. For this
  draft, the value is "1".

  JEP-Core-0.6 identifies the specification release version. It is not
  the wire-format version. The wire-format value jep: "1" can remain
  stable across multiple draft revisions and release versions when the
  core event object remains wire-compatible.

  A verifier MUST NOT infer Internet-Draft revision number or release
  maturity solely from the jep member.

  7.2 verb

  The verb member identifies the event verb. It MUST be one of J, D,
  T, or V.

  Event verbs do not determine cryptographic algorithms, storage policy,
  privacy mode, identity method, or legal effect.

  7.3 who

  who identifies the actor claimed by the event.

  who is not necessarily:

  - the signer;
  - a legal person;
  - the controller of the key;
  - a real-world identity;
  - the subject of the decision.

  The binding between who and the signing key is determined by the
  applicable trust profile.

  7.4 when

  when is an actor-supplied event timestamp in Unix seconds. JEP-Core
  does not by itself prove wall-clock time. Stronger time evidence requires
  a timestamping, receipt, archival, transparency, or storage profile.

  Implementations SHOULD distinguish:

  - event time;
  - signature time;
  - receipt time;
  - archive time;
  - verification time;
  - policy-evaluation time.

  7.5 what

  what carries the event claim, digest, descriptor, or report. It records
  what the actor asserted, judged, delegated, terminated, or verified. It
  does not by itself prove external truth.

  When represented as an object, what SHOULD use semantic subfields such
  as:

  - claim;
  - subject;
  - scope;
  - result;
  - evidence;
  - context.

  When represented as a digest, the digest MUST be an algorithm-tagged
  digest string.

  7.6 nonce

  nonce supports replay protection. Nonce uniqueness is evaluated within
  an actor, audience, trust-profile, and replay-window context. JEP-Core
  does not require global nonce uniqueness.

  7.7 aud

  aud indicates intended audience or validation context. It does not by
  itself enforce access control. Access control, retention, redaction, and
  disclosure policy are outside JEP-Core.

  7.8 ref

  ref is a reference field. A reference does not by itself imply
  endorsement, truth, authorization validity, or causality.

  References MAY identify:

  - event;
  - chain;
  - digest;
  - credential;
  - policy;
  - evidence;
  - context;
  - archive receipt;
  - external object.

  A simple event reference SHOULD use the event hash of the referenced JEP
  event.

  7.9 ext and ext_crit

  ext contains named extension objects. ext_crit contains the
  identifiers of critical extensions. Unknown critical extensions MUST
  cause validation failure. Unknown non-critical extensions MAY be ignored.

  7.10 sig

  sig carries the detached signature container. JEP-Core uses detached
  JWS over the JCS-canonicalized unsigned event unless another registered
  signature profile applies.

  ---

  8. Event Verb Semantics

  8.1 J - Judgment

  A Judgment event records that an actor made, accepted, produced,
  approved, selected, rejected, ranked, classified, or otherwise committed
  to a decision-related claim.

  A J event MUST NOT be interpreted as proof that the judged claim is true.

  Typical uses include:

  - model output approval;
  - human approval;
  - risk classification;
  - tool-selection decision;
  - policy decision;
  - recommendation acceptance;
  - evidence assessment.

  8.2 D - Delegation

  A Delegation event records that an actor delegated a task, authority,
  responsibility, capability, or decision context to another actor or
  system.

  A D event SHOULD identify, directly or by reference:

  - delegator;
  - delegatee;
  - scope;
  - constraints;
  - expiry;
  - context;
  - termination conditions.

  A D event records a delegation claim. It does not by itself prove legal
  authorization or external enforceability.

  8.3 T - Termination

  A Termination event records that a previous delegation, authority,
  session, capability, workflow context, verification context, or chain
  reliance is ended, revoked, expired, superseded, or no longer valid for
  future reliance.

  A T event MUST identify the terminated target and termination scope.

  A T event does not delete historical events, erase past facts, or
  automatically revoke external legal authority. It affects future reliance
  according to JEP-Core rules and applicable profiles.

  8.4 V - Verification

  A Verification event records that an actor performed a validation, audit,
  review, confirmation, rejection, or verification action over an event,
  chain, digest, subject, credential, policy, evidence, or external object.

  A V event MUST declare its verification scope. A V event MUST NOT imply
  verification beyond its declared scope.

  Initial verification scopes include:

  - syntax;
  - cryptographic;
  - actor_binding;
  - chain_integrity;
  - extension_processing;
  - credential_status;
  - policy_compliance;
  - human_review;
  - external_evidence;
  - factual_claim;
  - archival_integrity.

  ---

  9. References and Chains

  A JEP reference proves only that one event payload cryptographically or
  semantically referenced another object. It does not prove causality,
  endorsement, truth, authorization, or completeness.

  A JEP reference does not by itself imply causality. Causal interpretation
  is defined by JAC or another chain profile.

  A reference chain proves linkage between observed event objects. It does
  not prove that the observed log is complete, append-only, or free from
  omission unless a profile explicitly declares and supports a complete-log
  assumption.

  ---

  10. Algorithm-Tagged Digest Strings

  JEP uses algorithm-tagged digest strings for event hashes, content
  digests, and reference digests.

  Syntax:

  <hash-algorithm>:<lowercase-hex-digest>

  The hash algorithm identifier MUST be lower-case ASCII. The digest value
  MUST be lower-case hexadecimal.

  Implementations conforming to JEP-Core-0.6 MUST support sha256.

  Example:

  sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7

  Additional digest algorithms MAY be defined by conformance profiles,
  trust profiles, or registered extensions.

  ---

  11. Event Hashes and Signing Input

  The JEP signing input is the unsigned event object with sig omitted,
  canonicalized using JCS and encoded as UTF-8 octets.

  The event hash identifies the full signed event object, including sig.

  For the default hash profile:

  event_hash = sha256(UTF8(JCS(full_signed_event)))

  The signing input and event hash are intentionally different:

  - signing input excludes sig;
  - event hash includes sig.

  ---

  12. Signature, Hash, and Algorithm Agility

  JEP-Core preserves algorithm agility.

  A JEP event is protected by a detached JWS signature over a
  JCS-canonicalized unsigned event payload.

  JEP-Core does not assign cryptographic algorithms to event verbs. J, D,
  T, and V share the same cryptographic processing model.

  The concrete signature algorithm, key type, hash algorithm, and algorithm
  acceptability policy are determined by JOSE headers, conformance
  profiles, and trust profiles.

  JEP-Core semantics are algorithm-neutral. A JEP-Core implementation
  MUST NOT assign algorithms to event verbs or treat algorithm choice as
  part of the semantics of J, D, T, or V.

  A baseline conformance class MAY define a required-to-implement
  algorithm set for interoperability. For compatibility with the -05
  baseline, an Ed25519/JWS/JCS conformance class MAY be defined by the
  companion conformance draft. Such a conformance class does not make
  Ed25519 the only algorithm allowed by JEP-Core semantics.

  A trust profile MUST define which algorithms are acceptable for a given
  deployment context.

  A verifier MUST reject an event if the declared algorithm is unsupported,
  prohibited by the applicable profile, inconsistent with the resolved key
  type, inconsistent with the signature container, or inconsistent with a
  critical cryptographic extension.

  A verifier SHOULD distinguish real-time acceptance validation from
  archival validation. An algorithm MAY be acceptable for archival
  validation while being prohibited for new event signatures.

  ---

  13. Trust Profile Interface

  JEP-Core does not define a global identity or trust framework.

  A trust profile MUST define:

  - supported actor identifier forms;
  - key identifier syntax and discovery;
  - binding rules between who and signing keys;
  - accepted signature algorithms;
  - downgrade policy;
  - key rotation handling;
  - revocation handling;
  - historical key validity;
  - credential or attestation use, if any;
  - policy evaluation hooks, if any.

  Support for DID, VC, X.509, OAuth, RATS, blockchain anchoring, or any
  specific identity system is OPTIONAL and MUST NOT be required for
  JEP-Core conformance.

  ---

  14. Validation Model

  14.1 Validation Levels

  JEP validation is divided into five levels:

  | Level | Name | Meaning |
  |---|---|---|
  | 0 | Syntax | JSON, I-JSON, required fields, schema shape. |
  | 1 | Cryptographic | Canonicalization, event hash, detached signature. |
  | 2 | Actor Binding | Key bound to actor under trust profile. |
  | 3 | Chain | References, critical extensions, replay, termination effects, chain integrity. |
  | 4 | Policy | Domain, legal, organizational, regulatory, or deployment policy. |

  A verifier MUST report the highest successfully completed validation
  level. A verifier MUST NOT present Level 1 cryptographic validity as
  Level 4 policy validity.

  A JEP event MAY be cryptographically valid but policy-invalid.

  14.2 Validation Modes

  Initial validation modes are:

  - acceptance;
  - archival;
  - chain;
  - policy.

  Acceptance validation checks freshness and replay. Archival validation
  MUST NOT reject an event solely because its timestamp is outside the
  current freshness window.

  14.3 Deterministic Validation Algorithm

  A verifier SHOULD process an event in this order:

  1. parse JSON;
  2. reject duplicate JSON member names;
  3. check required top-level fields;
  4. check verb-specific field requirements;
  5. remove sig to construct unsigned event;
  6. canonicalize unsigned event using JCS;
  7. verify detached signature;
  8. compute event hash if needed;
  9. resolve actor/key under trust profile;
  10. check actor/key binding;
  11. check nonce and freshness for acceptance mode;
  12. validate aud if present and relevant;
  13. resolve and validate references if applicable;
  14. process critical extensions;
  15. apply chain rules, including termination effects;
  16. apply optional policy rules;
  17. return structured validation result.

  ---

  15. Validation Result Object

  A verifier SHOULD return a structured validation result.

  Example:

  {
    "valid": true,
    "level": 3,
    "mode": "archival",
    "profile": "jep-core-0.6",
    "scopes": ["syntax", "cryptographic", "actor_binding", "chain_integrity"],
    "event_hash": "sha256:...",
    "warnings": [],
    "errors": []
  }

  Validation results MUST distinguish:

  - cryptographically valid but policy-invalid;
  - archivally valid but not acceptable for new reliance;
  - valid under profile A but invalid under profile B;
  - signature-valid but actor-binding invalid;
  - chain-valid under observed-log assumptions only.

  ---

  16. Failure Codes

  A conforming validator SHOULD return structured failure codes.

  16.1 Syntax Errors

  - ERR_INVALID_JSON
  - ERR_DUPLICATE_MEMBER
  - ERR_UNSUPPORTED_JEP_VERSION
  - ERR_UNKNOWN_VERB
  - ERR_MISSING_REQUIRED_FIELD
  - ERR_INVALID_FIELD_TYPE
  - ERR_INVALID_TIMESTAMP

  16.2 Cryptographic Errors

  - ERR_CANONICALIZATION_FAILED
  - ERR_CANONICALIZATION_VERSION_UNSUPPORTED
  - ERR_INVALID_EVENT_HASH
  - ERR_UNSUPPORTED_SIGNATURE_ALG
  - ERR_PROHIBITED_SIGNATURE_ALG
  - ERR_ALG_KEY_TYPE_MISMATCH
  - ERR_ALG_PROFILE_MISMATCH
  - ERR_HASH_ALG_UNSUPPORTED
  - ERR_SIGNATURE_CONTAINER_INVALID
  - ERR_SIGNATURE_MISSING
  - ERR_SIGNATURE_INVALID
  - ERR_DIGEST_MISMATCH
  - ERR_ARCHIVAL_ALG_STATUS_UNKNOWN
  - ERR_ALG_DEPRECATED_FOR_NEW_EVENTS

  16.3 Actor and Trust Errors

  - ERR_ACTOR_UNRESOLVED
  - ERR_KEY_UNRESOLVED
  - ERR_KEY_NOT_BOUND_TO_ACTOR
  - ERR_KEY_REVOKED
  - ERR_KEY_NOT_VALID_AT_EVENT_TIME
  - ERR_TRUST_PROFILE_UNSUPPORTED

  16.4 Replay and Freshness Errors

  - ERR_NONCE_REPLAY
  - ERR_EVENT_EXPIRED
  - ERR_TIMESTAMP_OUT_OF_WINDOW

  16.5 Reference and Chain Errors

  - ERR_REF_UNRESOLVED
  - ERR_REF_HASH_MISMATCH
  - ERR_CHAIN_BROKEN
  - ERR_DELEGATION_SCOPE_EXCEEDED
  - ERR_TERMINATED_REFERENCE_REUSED
  - ERR_CYCLE_DETECTED
  - ERR_COMPLETE_LOG_ASSUMPTION_UNSATISFIED

  16.6 Extension Errors

  - ERR_UNKNOWN_CRITICAL_EXTENSION
  - ERR_EXTENSION_SCHEMA_INVALID
  - ERR_EXTENSION_VALIDATION_FAILED
  - ERR_EXTENSION_CONFLICT

  16.7 Policy Errors

  - ERR_POLICY_REJECTED
  - ERR_AUTHORIZATION_CONTEXT_MISSING
  - ERR_DOMAIN_REQUIREMENT_UNSATISFIED

  ---

  17. Extension Rules and Conflict Handling

  An extension MUST declare:

  1. extension identifier;
  2. extension version;
  3. JSON schema or equivalent data model;
  4. whether it may be critical;
  5. validation requirements;
  6. security considerations;
  7. privacy considerations;
  8. interaction with event hashes and signatures;
  9. interaction with other known extensions, if applicable.

  Extensions MUST NOT redefine the semantics of core JEP members.

  Unknown critical extensions MUST cause rejection. Unknown non-critical
  extensions MAY be ignored.

  If two critical extensions impose inconsistent requirements, validation
  MUST fail with ERR_EXTENSION_CONFLICT.

  Extension identifiers SHOULD be collision-resistant. Supported forms
  include:

  - reverse-DNS identifiers, e.g. org.example.jep.profile.vc;
  - URI identifiers;
  - registered short names;
  - experimental x-* identifiers.

  ---

  18. Conformance Requirements

  A JEP-Core-0.6 producer MUST support:

  - I-JSON-compatible event construction;
  - required top-level fields;
  - JCS canonicalization of unsigned payloads;
  - detached JWS signature generation under at least one conformance class;
  - algorithm-tagged digest strings;
  - nonce generation;
  - ext and ext_crit semantics.

  A JEP-Core-0.6 verifier MUST support:

  - duplicate-member rejection;
  - core field validation;
  - JCS canonicalization;
  - detached signature verification under at least one conformance class;
  - event hash calculation;
  - validation levels;
  - structured validation result object;
  - unknown critical extension rejection;
  - acceptance and archival validation modes.

  A JEP-Core-0.6 implementation MUST NOT require support for any optional
  identity, credential, attestation, blockchain, AI platform, or agent
  framework profile.

  18.1 Baseline Algorithm Conformance

  For interoperability with earlier JEP drafts, a baseline conformance
  class MAY require support for detached JWS using JCS canonicalization,
  sha256 algorithm-tagged digest strings, and Ed25519 verification.

  This baseline is a conformance-class requirement, not a JEP-Core semantic
  requirement. Other profiles MAY define additional or alternative
  algorithm suites, including regional, enterprise, COSE/CBOR, composite,
  or post-quantum profiles, provided that their algorithm identifiers,
  key representations, downgrade policies, and validation behavior are
  specified.

  ---

  19. Determinability Boundary

  JEP distinguishes observable protocol facts from external target facts.

  19.1 Observable Protocol Facts

  JEP can support determination of protocol-level facts such as:

  - whether a payload was signed by a key;
  - whether a key is acceptable under a trust profile;
  - whether an event hash matches an event payload;
  - whether an event references another event;
  - whether a nonce has been seen within a replay window;
  - whether a critical extension was processed;
  - whether a delegation was later terminated in the observed log.

  19.2 External Target Facts

  JEP alone does not determine external target facts such as:

  - whether a real-world statement is true;
  - whether a model internally understood a request;
  - whether an actor is legally liable;
  - whether a delegation is legally enforceable;
  - whether a human actually read a document;
  - whether a physical-world action occurred outside the logged system.

  A profile MAY define evidence rules for external target facts. Such rules
  are outside JEP-Core.

  ---

  20. Observed Log Assumptions

  An observed JEP log is not necessarily a complete log.

  Absence of an event in an observed log MUST NOT be interpreted as proof
  that the event did not occur unless a complete-log assumption is
  explicitly declared by the deployment profile.

  Profiles MAY define:

  - complete-log profile;
  - partial-log profile;
  - selective-disclosure log;
  - redacted log;
  - archive-backed log;
  - transparency-backed log.

  A chain reconstruction result MUST declare whether it relies on complete
  or partial log assumptions.

  ---

  21. Relationship to HJS and JAC

  JEP defines atomic signed judgment events.

  HJS-like systems manage storage, receipt, archival context, retention,
  redaction, selective disclosure, privacy policy, and evidence lifecycle
  for JEP events. HJS MUST NOT redefine JEP-Core event semantics,
  signature semantics, event hash semantics, validation levels, or failure
  codes.

  JAC-like systems compose JEP events into causality chains,
  responsibility chains, delegation paths, verification paths, and
  workflow accountability graphs. JAC MUST NOT redefine JEP-Core event
  format, signature semantics, event hash semantics, or validation levels.

  A JEP reference does not by itself imply causality. Causal interpretation
  is defined by JAC or another chain profile.

  ---

  22. Security Considerations

  JEP-Core mitigates:

  - payload tampering;
  - signature forgery under supported algorithms;
  - replay within configured windows;
  - reference hash mismatch;
  - unknown critical extension processing;
  - basic chain integrity failures.

  JEP-Core does not by itself prevent:

  - compromised signing keys;
  - false claims signed by legitimate actors;
  - omission of relevant events from a log;
  - collusion among actors;
  - legal or organizational misuse;
  - incorrect external evidence;
  - malicious trust profiles;
  - timestamp manipulation without external time evidence.

  22.1 Downgrade Resistance

  A verifier MUST reject algorithms prohibited by the applicable profile. A
  verifier MUST NOT accept a weaker algorithm merely because it is
  syntactically valid in JOSE.

  22.2 Human-in-the-Loop Semantics

  A human-review event records that a human actor emitted or endorsed a
  review-related claim. It does not prove that the human fully understood
  the underlying material, that the decision was correct, or that legal
  compliance was satisfied.

  22.3 AI Actor Semantics

  JEP-Core does not mandate any specific AI actor identity scheme. AI
  actor identity, model identity, tool identity, service identity, and
  session identity are defined by trust profiles or extensions.

  ---

  23. Privacy Considerations

  JEP events may reveal actor identity, subject identity, decision timing,
  delegation structure, organizational workflow, tool usage, and audit
  relationships.

  Deployments SHOULD minimize personal data in what and extensions. When
  possible, external evidence SHOULD be referenced by digest rather than
  embedded directly.

  Digest references may enable correlation, confirmation attacks, or
  dictionary attacks. Sensitive evidence references MAY require salted
  digests, commitment schemes, access-controlled evidence stores,
  audience-bound references, selective disclosure, or redaction.

  JEP signatures and references may create linkability across contexts.
  Implementations SHOULD avoid reusing actor identifiers across unrelated
  audiences unless required by the trust profile.

  JEP is an accountability protocol component. It SHOULD NOT be deployed as
  a general monitoring mechanism without data-minimization, retention,
  access-control, and redaction policies.

  ---

  24. Registry Considerations

  JEP registries SHOULD cover:

  - verbs;
  - extension identifiers;
  - verification scopes;
  - validation modes;
  - error codes;
  - trust profile identifiers;
  - conformance class identifiers;
  - algorithm policy labels.

  New verb registrations are NOT RECOMMENDED. New verbs require an update
  to JEP-Core explaining why existing verbs plus extensions are
  insufficient.

  ---

  25. Versioning and Compatibility

  Minor versions MAY add optional fields or optional extensions. Major
  versions MAY change validation requirements.

  Unknown critical extensions MUST cause validation failure. Unknown
  non-critical extensions MAY be ignored.

  Unknown required core fields MUST cause validation failure unless defined
  by a future compatible revision.

  ---

  26. Examples

  26.1 Minimal Judgment Event Shape

  {
    "jep": "1",
    "verb": "J",
    "who": "did:example:agent-789",
    "when": 1742345678,
    "what": "sha256:aa55ad4393538f14e6b4961de1a29216eed93517cb6c2631a56a5ee75edb3b7a",
    "nonce": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "aud": "https://platform.example.com",
    "ref": null,
    "sig": "..."
  }

  Full test vectors are defined in the companion conformance draft.

  ---

  27. Changes from -05

  Major changes from draft-wang-jep-judgment-event-protocol-05:

  - Reframed JEP-Core as a neutral narrow-waist event infrastructure.
  - Added explicit protocol objective and non-goals.
  - Added design principles.
  - Added detailed field semantics for who, when, what, nonce,
    aud, ref, ext, and sig.
  - Expanded J/D/T/V semantics.
  - Added verification-scope requirements for V events.
  - Added validation levels.
  - Added structured validation result object.
  - Added structured failure-code taxonomy.
  - Added deterministic validation algorithm.
  - Added extension conflict handling.
  - Added trust profile interface.
  - Added determinability boundary.
  - Added observed-log assumptions.
  - Added relationship to HJS and JAC.
  - Added human-in-the-loop and AI actor semantic boundaries.
  - Added downgrade-resistance language.
  - Moved concrete DID/VC/X.509/OAuth/RATS profile material to
    draft-wang-jep-profiles-00.
  - Moved schema, test vectors, and reference validator behavior to
    draft-wang-jep-conformance-00.

  ---

  Author's Address

  Yuqiang Wang  
  Email: signal@humanjudgment.org  
  URI: https://github.com/hjs-spec


  v0.6 Direct Upgrade Note

  This document is part of the JEP v0.6 draft set. The v0.6 set directly
  incorporates standardization structure, interoperability profiles,
  conformance artifacts, schemas, signed test vectors, invalid cases, and
  multi-language validator seeds without changing the JEP-Core narrow-waist
  semantics.

  draft-wang-jep-judgment-event-protocol-06                  Expires November 5, 2026                 [Page 1]


name: draft-li-atp
rev: 01
title: Agent Transfer Protocol (ATP)
time: 2026-03-29T09:02:49Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-30T09:02:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:48.589034+00:00
source: ietf
abstract:
  The Agent Transfer Protocol (ATP) is a communication protocol
     designed for autonomous agents to exchange messages, requests, and
     events in a secure, structured manner.  ATP supports the emerging
     Internet of Agents (IoA) paradigm, where autonomous agents operate
     across four deployment scenarios: household (small scale), service
     (medium scale), enterprise (large scale), cloud provider (huge
     scale), and etc.

     ATP employs a two-tier architecture where agents connect to the
     global Internet through ATP servers, enabling server-mediated
     communication for proper routing, security enforcement, and resource
     management.  The protocol provides DNS-based service discovery using
     SVCB records, mandatory authentication via Agent Transfer Sender
     (ATS) policies and Agent Transfer Keys (ATK), and support for
     multiple interaction patterns including asynchronous messaging,
     synchronous request/response, and event-driven streaming.

     This specification defines the discovery mechanism, identity model,
     authentication framework, transport layer, and message semantics for
     ATP.

full_text:
  Internet Engineering Task Force                                    X. Li
  Internet-Draft                                                    L. Sun
  Intended status: Standards Track                                  Y. Qiu
  Expires: 30 September 2026                                         Z. Xu
                                                         Nankai University
                                                             29 March 2026


                       Agent Transfer Protocol (ATP)
                              draft-li-atp-01

  Abstract

     The Agent Transfer Protocol (ATP) is a communication protocol
     designed for autonomous agents to exchange messages, requests, and
     events in a secure, structured manner.  ATP supports the emerging
     Internet of Agents (IoA) paradigm, where autonomous agents operate
     across four deployment scenarios: household (small scale), service
     (medium scale), enterprise (large scale), cloud provider (huge
     scale), and etc.

     ATP employs a two-tier architecture where agents connect to the
     global Internet through ATP servers, enabling server-mediated
     communication for proper routing, security enforcement, and resource
     management.  The protocol provides DNS-based service discovery using
     SVCB records, mandatory authentication via Agent Transfer Sender
     (ATS) policies and Agent Transfer Keys (ATK), and support for
     multiple interaction patterns including asynchronous messaging,
     synchronous request/response, and event-driven streaming.

     This specification defines the discovery mechanism, identity model,
     authentication framework, transport layer, and message semantics for
     ATP.

  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."



  Li, et al.              Expires 30 September 2026               [Page 1]


  Internet-Draft                     ATP                        March 2026


     This Internet-Draft will expire on 30 September 2026.

  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.
     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  . . . . . . . . . . . . . . . . . . . . . . .   5
         1.1.1.  The Vision of Internet of Agents  . . . . . . . . . .   6
         1.1.2.  Four Deployment Scenarios . . . . . . . . . . . . . .   6
         1.1.3.  Why ATP is Needed . . . . . . . . . . . . . . . . . .   7
         1.1.4.  Internet of Agents Architecture . . . . . . . . . . .  10
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .  12
       1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  12
       1.4.  Protocol Stack Overview . . . . . . . . . . . . . . . . .  13
     2.  Discovery Mechanism . . . . . . . . . . . . . . . . . . . . .  14
       2.1.  DNS SVCB Record Format  . . . . . . . . . . . . . . . . .  14
         2.1.1.  Record Name . . . . . . . . . . . . . . . . . . . . .  15
         2.1.2.  Record Format . . . . . . . . . . . . . . . . . . . .  15
         2.1.3.  Example . . . . . . . . . . . . . . . . . . . . . . .  15
         2.1.4.  Parameters  . . . . . . . . . . . . . . . . . . . . .  15
       2.2.  Discovery Process . . . . . . . . . . . . . . . . . . . .  16
       2.3.  Capability Discovery  . . . . . . . . . . . . . . . . . .  16
         2.3.1.  DNS-Based Capability Advertisement  . . . . . . . . .  16
         2.3.2.  HTTP-Based Capability Query . . . . . . . . . . . . .  17
     3.  Identity Model  . . . . . . . . . . . . . . . . . . . . . . .  17
       3.1.  Agent Identifier Format . . . . . . . . . . . . . . . . .  17
         3.1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . .  18
         3.1.2.  Local-part Semantics  . . . . . . . . . . . . . . . .  18
         3.1.3.  Domain Requirements . . . . . . . . . . . . . . . . .  19
       3.2.  Delegation  . . . . . . . . . . . . . . . . . . . . . . .  19
         3.2.1.  CNAME Delegation  . . . . . . . . . . . . . . . . . .  19
         3.2.2.  SVCB Alias Mode . . . . . . . . . . . . . . . . . . .  19
     4.  Security Framework  . . . . . . . . . . . . . . . . . . . . .  19
       4.1.  Transport Layer Security  . . . . . . . . . . . . . . . .  19
         4.1.1.  TLS Requirements  . . . . . . . . . . . . . . . . . .  19



  Li, et al.              Expires 30 September 2026               [Page 2]


  Internet-Draft                     ATP                        March 2026


         4.1.2.  Mutual TLS  . . . . . . . . . . . . . . . . . . . . .  20
       4.2.  Agent Transfer Sender Policy (ATS)  . . . . . . . . . . .  20
         4.2.1.  ATS Record Format . . . . . . . . . . . . . . . . . .  20
         4.2.2.  Example ATS Records . . . . . . . . . . . . . . . . .  20
         4.2.3.  Policy Directives . . . . . . . . . . . . . . . . . .  20
         4.2.4.  ATS Query Process . . . . . . . . . . . . . . . . . .  21
         4.2.5.  ATS Processing Algorithm  . . . . . . . . . . . . . .  22
         4.2.6.  ATS Error Codes . . . . . . . . . . . . . . . . . . .  22
         4.2.7.  Cloud Deployment Considerations . . . . . . . . . . .  22
         4.2.8.  ATS Best Practices  . . . . . . . . . . . . . . . . .  23
       4.3.  Agent Transfer Key (ATK)  . . . . . . . . . . . . . . . .  23
         4.3.1.  ATK Record Format . . . . . . . . . . . . . . . . . .  23
         4.3.2.  Example ATK Records . . . . . . . . . . . . . . . . .  23
         4.3.3.  Key Parameters  . . . . . . . . . . . . . . . . . . .  24
         4.3.4.  ATK Query Process . . . . . . . . . . . . . . . . . .  24
         4.3.5.  ATK Key Management  . . . . . . . . . . . . . . . . .  25
         4.3.6.  ATK Best Practices  . . . . . . . . . . . . . . . . .  25
       4.4.  Message Signature . . . . . . . . . . . . . . . . . . . .  26
         4.4.1.  Signature Envelope  . . . . . . . . . . . . . . . . .  26
         4.4.2.  Signature Algorithm . . . . . . . . . . . . . . . . .  26
         4.4.3.  Signature Coverage  . . . . . . . . . . . . . . . . .  27
         4.4.4.  Canonicalization  . . . . . . . . . . . . . . . . . .  27
         4.4.5.  Signature Verification  . . . . . . . . . . . . . . .  28
         4.4.6.  Signature Error Handling  . . . . . . . . . . . . . .  28
     5.  Transport Protocol  . . . . . . . . . . . . . . . . . . . . .  28
       5.1.  HTTPS Transport . . . . . . . . . . . . . . . . . . . . .  28
         5.1.1.  Default Port  . . . . . . . . . . . . . . . . . . . .  28
         5.1.2.  Endpoints . . . . . . . . . . . . . . . . . . . . . .  28
         5.1.3.  Connection Management . . . . . . . . . . . . . . . .  29
       5.2.  IPv6 Considerations . . . . . . . . . . . . . . . . . . .  30
       5.3.  QUIC Transport (Future Work)  . . . . . . . . . . . . . .  30
         5.3.1.  Expected Benefits . . . . . . . . . . . . . . . . . .  30
         5.3.2.  Security Note . . . . . . . . . . . . . . . . . . . .  31
     6.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .  31
       6.1.  Common Fields . . . . . . . . . . . . . . . . . . . . . .  31
         6.1.1.  Field Definitions . . . . . . . . . . . . . . . . . .  31
       6.2.  Message Types . . . . . . . . . . . . . . . . . . . . . .  32
         6.2.1.  Message (Asynchronous)  . . . . . . . . . . . . . . .  32
         6.2.2.  Request/Response  . . . . . . . . . . . . . . . . . .  33
         6.2.3.  Event/Subscription  . . . . . . . . . . . . . . . . .  34
       6.3.  Payload Encoding  . . . . . . . . . . . . . . . . . . . .  35
         6.3.1.  JSON Encoding . . . . . . . . . . . . . . . . . . . .  35
         6.3.2.  CBOR Encoding . . . . . . . . . . . . . . . . . . . .  35
       6.4.  Message Size Limits . . . . . . . . . . . . . . . . . . .  35
     7.  Protocol Semantics  . . . . . . . . . . . . . . . . . . . . .  36
       7.1.  Message (Asynchronous)  . . . . . . . . . . . . . . . . .  36
         7.1.1.  Delivery Model  . . . . . . . . . . . . . . . . . . .  36
         7.1.2.  Delivery Guarantees . . . . . . . . . . . . . . . . .  36



  Li, et al.              Expires 30 September 2026               [Page 3]


  Internet-Draft                     ATP                        March 2026


         7.1.3.  Retry Policy  . . . . . . . . . . . . . . . . . . . .  37
       7.2.  Request/Response (Synchronous)  . . . . . . . . . . . . .  37
         7.2.1.  Interaction Model . . . . . . . . . . . . . . . . . .  37
         7.2.2.  Deadline Propagation  . . . . . . . . . . . . . . . .  38
         7.2.3.  State Management  . . . . . . . . . . . . . . . . . .  38
       7.3.  Event/Subscription (Streaming)  . . . . . . . . . . . . .  38
         7.3.1.  Pub/Sub Model . . . . . . . . . . . . . . . . . . . .  39
         7.3.2.  Subscription Lifecycle  . . . . . . . . . . . . . . .  40
         7.3.3.  Server-to-Server Event Delivery . . . . . . . . . . .  40
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  40
       8.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  40
       8.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  41
         8.2.1.  TLS Security  . . . . . . . . . . . . . . . . . . . .  41
         8.2.2.  ATS (Agent Transfer Sender Policy)  . . . . . . . . .  42
         8.2.3.  ATK (Agent Transfer Key)  . . . . . . . . . . . . . .  42
         8.2.4.  Message Signature . . . . . . . . . . . . . . . . . .  43
       8.3.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  43
         8.3.1.  Metadata Exposure . . . . . . . . . . . . . . . . . .  43
         8.3.2.  Payload Confidentiality . . . . . . . . . . . . . . .  44
       8.4.  Denial of Service . . . . . . . . . . . . . . . . . . . .  44
         8.4.1.  Resource Exhaustion Attacks . . . . . . . . . . . . .  44
         8.4.2.  Amplification Attacks . . . . . . . . . . . . . . . .  45
       8.5.  DNS Security  . . . . . . . . . . . . . . . . . . . . . .  45
         8.5.1.  DNS Spoofing and Cache Poisoning  . . . . . . . . . .  45
         8.5.2.  DNS Query Privacy . . . . . . . . . . . . . . . . . .  45
       8.6.  ATP Server Security . . . . . . . . . . . . . . . . . . .  45
         8.6.1.  Server Compromise . . . . . . . . . . . . . . . . . .  46
         8.6.2.  Multi-tenant Isolation  . . . . . . . . . . . . . . .  46
       8.7.  Security Best Practices . . . . . . . . . . . . . . . . .  46
       8.8.  Known Limitations . . . . . . . . . . . . . . . . . . . .  47
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  47
       9.1.  Application-Layer Protocol Negotiation (ALPN) Protocol
             Identifier  . . . . . . . . . . . . . . . . . . . . . . .  47
       9.2.  Well-Known URI  . . . . . . . . . . . . . . . . . . . . .  47
       9.3.  Media Types . . . . . . . . . . . . . . . . . . . . . . .  47
       9.4.  Service Name and Transport Protocol Port Number
             Registry  . . . . . . . . . . . . . . . . . . . . . . . .  48
       9.5.  SVCB SvcParamKey Registrations  . . . . . . . . . . . . .  48
         9.5.1.  ATP Capabilities Values . . . . . . . . . . . . . . .  48
         9.5.2.  ATP Auth Values . . . . . . . . . . . . . . . . . . .  49
       9.6.  ATP Message Type Registry . . . . . . . . . . . . . . . .  49
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  50
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  50
       10.2.  Informative References . . . . . . . . . . . . . . . . .  51
     Appendix A.  Example Message Flows  . . . . . . . . . . . . . . .  52
       A.1.  Sending an ATP Message  . . . . . . . . . . . . . . . . .  52
       A.2.  Request/Response Flow . . . . . . . . . . . . . . . . . .  53
       A.3.  Event Subscription Flow . . . . . . . . . . . . . . . . .  54



  Li, et al.              Expires 30 September 2026               [Page 4]


  Internet-Draft                     ATP                        March 2026


     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  56
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  56

  1.  Introduction

     The evolution of the Internet has always centered around the theme of
     "connection":

     *  *Person-to-Person*: Email and instant messaging connect people
        with people

     *  *Person-to-Service*: Web pages and mobile apps connect people with
        services

     *  *Thing-to-Thing*: IoT devices connect the physical world

     *The next trend is emerging: agents will become part of Internet
     infrastructure.*

     With the advancement of artificial intelligence technology,
     autonomous agents are moving from concept to large-scale application:

     *  Households deploy intelligent assistants to act on behalf of users
        for daily tasks

     *  Enterprises deploy customer service bots and operations agents to
        automate business processes

     *  Cloud providers offer agent-based capabilities including AI
        services and IoT coordination

     When agents are ubiquitous, they need to communicate with each other
     - this requires a communication protocol designed specifically for
     agents.

     *The Agent Transfer Protocol (ATP) is proposed as a communication
     protocol design reference for the era of Internet of Agents.*

  1.1.  Motivation

     The emergence of autonomous agents represents a fundamental shift in
     how digital services are delivered and consumed.  We are entering the
     era of the *Internet of Agents (IoA)*, where autonomous agents will
     become ubiquitous in both personal and commercial environments.







  Li, et al.              Expires 30 September 2026               [Page 5]


  Internet-Draft                     ATP                        March 2026


     The Agent Transfer Protocol (ATP) is a communication protocol
     designed for autonomous agents to exchange messages, requests, and
     events across the Internet.  ATP enables secure, structured agent-to-
     agent communication through a server-mediated architecture that
     provides routing, security enforcement, and resource management.

     This document describes the motivation, architecture, and technical
     specifications of ATP.  We first present the vision of the Internet
     of Agents (IoA) and the four deployment scenarios that ATP supports.
     We then describe the design goals, terminology, and core components
     of the protocol, including discovery, identity, authentication,
     transport, and message semantics.

  1.1.1.  The Vision of Internet of Agents

     In the near future, autonomous agents will be deployed across four
     primary deployment scenarios, each serving distinct needs and scales:

     *Household (Small Scale)*: Every household will deploy personal agent
     systems—either as physical robots or dedicated home servers—that
     manage daily tasks, coordinate schedules, and interact with external
     services on behalf of family members.  Each household member will
     have their own agent account, enabling personalized interactions
     while maintaining shared context.

     *Service (Medium Scale)*: Commercial organizations will deploy agent
     services to automate customer interactions, process transactions, and
     provide intelligent assistance.  These service agents handle high-
     volume interactions with customers worldwide.

     *Enterprise (Large Scale)*: Large corporations and organizations will
     deploy internal agent systems to streamline business operations, from
     HR and IT support to development and operations automation.

     *Cloud Provider (Huge Scale)*: Major technology providers will
     operate multi-tenant agent platforms serving millions of global
     users, providing AI services, data management, IoT coordination, and
     machine learning capabilities across continents.

  1.1.2.  Four Deployment Scenarios

     The agent ecosystem spans four distinct deployment scenarios, each
     with different scale requirements:

     *  *Household Agents (Small)*: A household domain (e.g.,
        family.example.com) hosts a few personal agent identities:

        -  parent1@family.example.com - Agent for first parent



  Li, et al.              Expires 30 September 2026               [Page 6]


  Internet-Draft                     ATP                        March 2026


        -  parent2@family.example.com - Agent for second parent

        -  home@family.example.com - Home automation coordination agent

     *  *Service Agents (Medium)*: Service providers operate multiple
        specialized agents:

        -  service-bot@company.com - General customer service agent

        -  shop-bot@retailer.com - Shopping assistant agent

        -  support@tech-company.com - Technical support agent

     *  *Enterprise Agents (Large)*: Organizations deploy agents for
        various business functions:

        -  hr@enterprise.com - Human resources assistant

        -  dev@enterprise.com - Development workflow agent

        -  ops@enterprise.com - IT operations agent

     *  *Cloud Provider Agents (Huge)*: Global platforms serve diverse
        user bases:

        -  user-us@cloud-provider.com - North American user services

        -  user-eu@cloud-provider.com - European user services

        -  user-cn@cloud-provider.com - Asian user services

        -  ai-service@cloud-provider.com - AI/ML service endpoints

        -  iot@cloud-provider.com - IoT device coordination

  1.1.3.  Why ATP is Needed

     Existing protocols cannot adequately meet the requirements of the
     Internet of Agents era:












  Li, et al.              Expires 30 September 2026               [Page 7]


  Internet-Draft                     ATP                        March 2026


     +===============+=========================+========================+
     | Requirement   | Description             | Limitations of         |
     |               |                         | Existing Protocols     |
     +===============+=========================+========================+
     | *Multi-tenant | Each domain hosts       | Email supports multi-  |
     | Identity*     | multiple agent          | user but lacks         |
     |               | identities (from 2-5 in | identity management    |
     |               | households to millions  | for automated          |
     |               | on cloud platforms)     | scenarios              |
     +---------------+-------------------------+------------------------+
     | *Structured   | JSON/CBOR payloads for  | HTTP can transport     |
     | Data          | automated processing    | JSON but lacks native  |
     | Exchange*     |                         | agent semantics        |
     +---------------+-------------------------+------------------------+
     | *Strong       | Mandatory               | TLS only protects      |
     | Security      | authentication and      | transport;             |
     | Guarantees*   | integrity verification  | application-layer      |
     |               | for automated           | authentication depends |
     |               | operations              | on implementation      |
     +---------------+-------------------------+------------------------+
     | *Multiple     | Asynchronous messaging, | Typically requires     |
     | Interaction   | synchronous request/    | combining multiple     |
     | Patterns*     | response, event-driven  | protocols (e.g., HTTP  |
     |               | streaming               | + WebSocket)           |
     +---------------+-------------------------+------------------------+
     | *Scalable     | Cross-internet agent    | Relies on centralized  |
     | Discovery*    | location and            | directory services or  |
     |               | authentication          | additional             |
     |               |                         | infrastructure         |
     +---------------+-------------------------+------------------------+
     | *Context      | Stateful multi-turn     | No native support;     |
     | Awareness*    | dialogues and complex   | must be implemented at |
     |               | workflow coordination   | application layer      |
     +---------------+-------------------------+------------------------+
     | *Variable     | Efficient handling from | Typically optimized    |
     | Scale         | household to cloud      | for specific scales,   |
     | Support*      | platform scenarios      | difficult to           |
     |               |                         | accommodate all        |
     +---------------+-------------------------+------------------------+

       Table 1: Requirements for Internet of Agents and Limitations of
                              Existing Protocols

     *Therefore, agents need their own communication protocol.*

     This vision requires a communication infrastructure that supports:





  Li, et al.              Expires 30 September 2026               [Page 8]


  Internet-Draft                     ATP                        March 2026


     1.  *Multi-tenant Identity*: Each domain hosts multiple agent
         identities, from a few agents in households to thousands in cloud
         platforms, requiring scalable identity management and routing.

     2.  *Structured Data Exchange*: Agents communicate using structured
         payloads (JSON, CBOR) rather than unstructured text, enabling
         automated processing and decision-making.

     3.  *Strong Security Guarantees*: Agent communication involves
         automated actions on behalf of users, demanding mandatory
         authentication and integrity verification to prevent unauthorized
         operations.

     4.  *Multiple Interaction Patterns*: Beyond simple messaging, agents
         need:

         *  Synchronous request/response for RPC-style interactions

         *  Event-driven streaming for real-time updates

         *  Asynchronous messaging for notifications and broadcasts

     5.  *Scalable Discovery*: Agents must locate and authenticate each
         other across the global internet using existing, proven
         infrastructure.

     6.  *Context Awareness*: Agents maintain state across interactions,
         support multi-turn dialogues, and coordinate complex workflows
         involving multiple parties.

     7.  *Variable Scale Support*: The protocol must efficiently handle
         scenarios ranging from small household deployments (2-5 agents)
         to massive cloud platforms (millions of users), with appropriate
         resource allocation and routing strategies for each scale.

     ATP addresses these requirements by providing a modern, secure, and
     extensible protocol built upon existing internet infrastructure while
     introducing agent-specific semantics.

     ATP is designed so that it can interoperate with application-layer
     agent interaction protocols.  While protocols such as A2A and MCP
     define rich semantics for agent capabilities, task management, and
     tool invocation, ATP provides the underlying cross-domain transport
     infrastructure with DNS-native discovery and mandatory security
     guarantees.  ATP's payload is opaque by design, enabling it to carry
     messages from any application-layer agent protocol.





  Li, et al.              Expires 30 September 2026               [Page 9]


  Internet-Draft                     ATP                        March 2026


  1.1.4.  Internet of Agents Architecture

     The Internet of Agents (IoA) follows a two-tier architecture where
     agents connect to the global internet through ATP servers.  This
     design ensures proper resource allocation, security enforcement, and
     efficient routing.

                            Internet of Agents (IoA)

          ╔══════════════════════════════════════════════════════════════╗
          ║                           INTERNET                           ║
          ╚══════════════════════════════════════════════════════════════╝
               │               │                 │                 │
               │               │                 │                 │
       ┌───────┴────────┐ ┌────┴────┐ ┌──────────┴──────────┐      │
       │      ATP       │ │   ATP   │ │         ATP         │      │
       │     Server     │ │ Server  │ │        Server       │      │
       │   Household    │ │ Service │ │      Enterprise     │      │
       │    (Small)     │ │(Medium) │ │       (Large)       │      │
       └─────┬──────────┘ └────┬────┘ └───────────┬─────────┘      │
             │                 │                  │                │
             │                 │                  │                │
       ┌─────┼─────┐     ┌─────┼─────┐     ┌──────┼──────┐         │
       │     │     │     │     │     │     │      │      │         │
       │     │     │     │     │     │     │      │      │         │
     ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐  ┌─┴─┐  ┌─┴─┐       │
     │P1 │ │P2 │ │H1 │ │S1 │ │S2 │ │S3 │ │E1 │  │E2 │  │E3 │       │
     └───┘ └───┘ └───┘ └───┘ └───┘ └───┘ └───┘  └───┘  └───┘       │
    Parent1 Parent2 Home  Bot1 Bot2 Shop  HR    Dev   Ops          │
                                     ┌─────────────────────────────┘
                  ┌──────────────────┴──────────────────┐
                  │              ATP Server             │
                  │            Cloud Provider           │
                  │                (Huge)               │
                  └──────────────────┬──────────────────┘
               ┌─────┬─────┬─────┬───┴───┬─────┬─────┬─────┐
               │     │     │     │       │     │     │     │
               │     │     │     │       │     │     │     │
             ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐   ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐
             │US │ │EU │ │CN │ │AI │   │DB │ │IoT│ │ML │ │API│
             └───┘ └───┘ └───┘ └───┘   └───┘ └───┘ └───┘ └───┘
             User  User  User   AI     Data   IoT   ML   API

  Household (Small): Personal/Family agents (Parent1/2, Home Assistant)
  Service (Medium): Commercial service agents (Service Bot1/2, Shopping)
  Enterprise (Large): Corporate agents (HR Bot, Dev Bot, Ops Bot)
  Cloud Provider (Huge): Multi-tenant cloud serving global users
      (US, EU, CN, AI, Data, IoT, ML, API)



  Li, et al.              Expires 30 September 2026              [Page 10]


  Internet-Draft                     ATP                        March 2026


     Figure 1: Internet of Agents (IoA) Architecture: Four deployment
    scenarios showing Household (Small), Service (Medium), Enterprise
         (Large), and Cloud Provider (Huge) ATP server categories

     In this architecture:

     *  *ATP Servers* act as gateways for agents, handling:

        -  Resource allocation and scheduling for local agents

        -  Outbound connection management and routing

        -  Inbound traffic filtering and security enforcement

        -  Policy enforcement (ATS/ATK validation)

        -  Message queuing and delivery guarantees

     *  *Agents* operate within their ATP Server's domain:

        -  All outbound communication goes through their local ATP Server

        -  All inbound communication arrives via their ATP Server

        -  Agents benefit from server-side security and filtering

        -  Multiple agents share server resources efficiently

     *  *Scale Considerations*:

        -  *Household (Small)*: 2-10 agents, minimal resource requirements

        -  *Service (Medium)*: 10-100 agents, moderate traffic handling

        -  *Enterprise (Large)*: 100-1000+ agents, high availability
           requirements

        -  *Cloud Provider (Huge)*: Millions of users, global
           distribution, multi-region deployment

     This architecture reflects the reality that in the Internet of Agents
     era, every household and organization will deploy an ATP server (or
     manager) to coordinate local agent activities, manage network
     connections, and provide security boundaries.







  Li, et al.              Expires 30 September 2026              [Page 11]


  Internet-Draft                     ATP                        March 2026


  1.2.  Design Goals

     1.  *Security-first*: Authentication and integrity verification are
         mandatory, not optional.

     2.  *Structured semantics*: Native support for multiple interaction
         patterns (message, request/response, event/subscription).

     3.  *DNS-based discovery*: Leverage existing DNS infrastructure for
         agent discovery and service location.

     4.  *Transport agnostic*: Support multiple transport protocols
         (HTTPS, QUIC) for flexibility and performance.

     5.  *Backward compatible*: Coexist with existing internet
         infrastructure and standards.

     6.  *Extensible*: Support capability discovery and protocol
         negotiation for future evolution.

     7.  *Multi-tenant support*: Efficiently handle multiple agents per
         domain, similar to multi-user email systems.

     8.  *Server-mediated communication*: All agent communication MUST
         flow through ATP servers for proper routing, security
         enforcement, and resource management.  This design reflects the
         reality that agents operate within managed domains (households,
         organizations, cloud services) that require centralized
         coordination.

  1.3.  Terminology

     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.

     This document uses the following terms:

     *  *Agent*: An autonomous software entity capable of communication,
        decision-making, and task execution.

     *  *Agent ID*: A unique identifier in the format local@domain that
        identifies a specific agent.






  Li, et al.              Expires 30 September 2026              [Page 12]


  Internet-Draft                     ATP                        March 2026


     *  *ATP Server*: A server implementing the ATP protocol and handling
        agent communication.  The ATP Server acts as a gateway for agents
        within its domain, providing resource allocation, connection
        management, security enforcement, and message routing.  All agent
        communication MUST flow through their respective ATP servers.

     *  *ATP Client*: An agent or application initiating ATP
        communication.

     *  *ATP Transfer*: The process of transferring messages between ATP
        servers across the Internet.

     *  *ATS*: Agent Transfer Sender policy - a DNS record defining
        authorized senders for a domain.

     *  *ATK*: Agent Transfer Key - a DNS record publishing cryptographic
        keys for message signature verification.

     *  *SVCB*: Service Binding - DNS record type defined in [RFC9460] for
        service discovery.

     *  *ALPN*: Application-Layer Protocol Negotiation - TLS extension for
        protocol negotiation.

  1.4.  Protocol Stack Overview

     +-------------------------------------------------+
     |              Application Semantics              |
     |     message / request-response / event-stream   |
     +-------------------------------------------------+
     |             Message Format (JSON/CBOR)          |
     |           envelope + payload + signature        |
     +-------------------------------------------------+
     |            Transport Layer (HTTPS/QUIC)         |
     |              TLS 1.3+ / ALPN negotiation        |
     +-------------------------------------------------+
     |               Discovery (DNS SVCB)              |
     |            _atp.<domain> SVCB records           |
     +-------------------------------------------------+

           Figure 2: ATP Protocol Stack: Four-layer architecture with
          Discovery (DNS SVCB), Transport (HTTPS/QUIC), Message Format
                     (JSON/CBOR), and Application Semantics

     ATP is built upon a layered protocol stack that leverages existing
     Internet infrastructure while introducing agent-specific semantics.
     The stack consists of four layers, from bottom to top:




  Li, et al.              Expires 30 September 2026              [Page 13]


  Internet-Draft                     ATP                        March 2026


     *Discovery Layer*: Uses DNS SVCB records [RFC9460] to enable agents
     to locate and discover ATP services for any given domain.  The
     discovery query targets _atp.<domain> to retrieve service endpoint
     information including hostname, port, and supported protocols.

     *Transport Layer*: Supports multiple transport protocols for
     flexibility and performance:

     *  *HTTPS*: Primary transport protocol, enabling deployment behind
        existing CDNs, load balancers, and firewalls.  Uses TLS 1.3+ for
        encryption and ALPN for protocol negotiation.

     *  *QUIC*: Optional transport protocol [RFC9000] for low-latency
        scenarios, providing 0-RTT handshakes and connection migration
        capabilities.

     *Message Format Layer*: Defines the structure of ATP messages using
     structured data encodings:

     *  *JSON*: Recommended encoding [RFC8259] with Content-Type
        application/atp+json

     *  *CBOR*: Optional encoding [RFC8949] for bandwidth-constrained
        environments with Content-Type application/atp+cbor

     Messages consist of an envelope (containing from, to, timestamp,
     nonce, type) and a payload, with a cryptographic signature for
     integrity and authenticity.

     *Application Semantics Layer*: Provides three interaction patterns
     for different use cases:

     *  *Message*: Asynchronous, fire-and-forget communication

     *  *Request/Response*: Synchronous RPC-style interactions

     *  *Event/Subscription*: Streaming and publish-subscribe patterns

  2.  Discovery Mechanism

  2.1.  DNS SVCB Record Format

     ATP uses DNS SVCB (Service Binding) records [RFC9460] for agent
     discovery.  The SVCB record provides the hostname, port, protocol
     version, and optional connection hints for the ATP service.  The DNS
     query follows the standard DNS protocol [RFC1034][RFC1035].





  Li, et al.              Expires 30 September 2026              [Page 14]


  Internet-Draft                     ATP                        March 2026


  2.1.1.  Record Name

     The standard SVCB query name for ATP discovery is:

     _atp.<domain>

     Where <domain> is the domain portion of the recipient Agent ID.

  2.1.2.  Record Format

     _atp.<domain>. IN SVCB <priority> <target> (
         port=<port-number>
         alpn=<protocol-identifier>
         [ipv4hint=<ipv4-address>]
         [ipv6hint=<ipv6-address>]
         [atp-capabilities=<capability-list>]
     )

  2.1.3.  Example

     _atp.example.com. IN SVCB 1 agent.example.com. (
         port=7443
         alpn="atp/1"
         ipv4hint=192.0.2.1,192.0.2.2
         ipv6hint=2001:db8::1,2001:db8::2
         atp-capabilities="message,request,event"
         atp-auth="ats,atk"
     )

  2.1.4.  Parameters

     *  *port*: TCP/UDP port number for the ATP service.  If not
        specified, the default port is 7443.

     *  *alpn*: Application-layer protocol negotiation identifier.
        Supported values:

        -  atp/1 - ATP version 1

        -  atp-json - ATP with JSON payload encoding

        -  atp-cbor - ATP with CBOR payload encoding

        -  atp+proto - ATP with Protocol Buffers encoding

     *  *ipv4hint* (optional): Comma-separated list of IPv4 addresses for
        faster connection establishment.




  Li, et al.              Expires 30 September 2026              [Page 15]


  Internet-Draft                     ATP                        March 2026


     *  *ipv6hint* (optional): Comma-separated list of IPv6 addresses for
        faster connection establishment.

     *  *atp-capabilities* (optional): Comma-separated list of supported
        protocol capabilities.

     *  *atp-auth* (optional): Comma-separated list of supported
        authentication mechanisms.  Supported values include ats (ATS
        policy validation), atk (ATK signature verification), mtls (mutual
        TLS).  This parameter enables clients to determine the server's
        authentication requirements before connection establishment.

  2.2.  Discovery Process

     The ATP client performs the following steps to discover the
     recipient's ATP service:

     1.  *Extract Domain*: Parse the recipient Agent ID to extract the
         domain portion.  The domain portion is derived from the
         local@domain Agent ID format — the same domain that hosts the
         agent's identity also hosts the ATP service discovery records.

     2.  *DNS SVCB Query*: Query the SVCB record for _atp.<domain>.

     3.  *Address Resolution*: Resolve the target hostname to IP addresses
         using A/AAAA records.  Implementations MUST query both A and AAAA
         records and SHOULD prefer IPv6 addresses when available.

     4.  *Connection Establishment*: Establish a secure connection to the
         resolved endpoint using the specified port.

  2.3.  Capability Discovery

     Agents can advertise their capabilities to enable protocol
     negotiation and feature discovery.

     When both DNS-based and HTTP-based capability information are
     available, the HTTP-based response MUST take precedence, as it can be
     updated more frequently than DNS records.  DNS-based capabilities
     serve as an initial hint for connection establishment and protocol
     negotiation; HTTP-based capabilities provide the authoritative and
     current capability set.

  2.3.1.  DNS-Based Capability Advertisement

     Capabilities can be included in the SVCB record using the atp-
     capabilities parameter:




  Li, et al.              Expires 30 September 2026              [Page 16]


  Internet-Draft                     ATP                        March 2026


     _atp.example.com. IN SVCB 1 agent.example.com. (
         port=7443
         alpn="atp/1"
         atp-capabilities="message,request,event,payment,search"
     )

  2.3.2.  HTTP-Based Capability Query

     Agents can query capabilities via an HTTP endpoint:

     GET /.well-known/atp/v1/capabilities
     Host: agent.example.com
     Accept: application/json

     *Response*:

     {
       "version": "1.0",
       "capabilities": ["message", "request", "event", "payment", "search"],
       "protocols": ["atp/1", "atp-json"],
       "max_payload_size": 1048576,
       "rate_limits": {
         "messages_per_second": 100,
         "requests_per_minute": 1000
       },
       "metadata_url": "https://agent.example.com/.well-known/agent.json"
     }

     The metadata_url field (OPTIONAL) points to an external agent
     description document that provides additional metadata about agents
     at this server.  The format of the referenced document is out of
     scope for this specification.  This field enables zero-cost cross-
     ecosystem discovery without binding ATP to any specific agent
     description standard.

  3.  Identity Model

  3.1.  Agent Identifier Format

     Agent identifiers follow the standard email address format but with
     extended semantics for agent communication.

     agent-id    = local-part "@" domain
     local-part  = 1*63( ALPHA / DIGIT / "." / "-" / "_" / "+" )
     domain      = sub-domain *("." sub-domain)
     sub-domain  = ; as defined in RFC 5321





  Li, et al.              Expires 30 September 2026              [Page 17]


  Internet-Draft                     ATP                        March 2026


     The local-part identifies a specific agent within the domain, and the
     domain identifies the ATP server responsible for routing messages to
     that agent.  ATP uses a restricted character set compared to RFC 5321
     to ensure safe handling across diverse agent implementations.

     A key design feature of ATP is that each domain hosts multiple agent
     identities using the local@domain format, similar to how email
     domains host multiple user mailboxes.  This multi-tenant identity
     model is fundamental to ATP's architecture:

     *  *Households*: parent1@family.example.com,
        parent2@family.example.com, home@family.example.com

     *  *Services*: support@company.com, billing@company.com, shop-
        bot@company.com

     *  *Enterprises*: hr@enterprise.com, dev@enterprise.com,
        ops@enterprise.com

     *  *Cloud Providers*: user-us@cloud.com, user-eu@cloud.com, ai-
        service@cloud.com

     Unlike centralized agent discovery systems that assign globally
     unique identifiers, ATP's local@domain model allows each domain
     administrator to independently manage their agent namespace.  This
     mirrors the email ecosystem's proven scalability: no central registry
     is needed, and identity management is delegated to domain owners.

  3.1.1.  Examples

     *  a1@example.com - Individual agent

     *  chatbot@service.org - Service agent

     *  billing.taskbot@example.com - Task-specific agent with
        hierarchical naming

     *  weather-agent-v2@provider.net - Versioned agent identifier

  3.1.2.  Local-part Semantics

     The local-part uses alphanumeric characters, period (.), hyphen (-),
     underscore (_), and plus (+).  The maximum length of the local-part
     is 63 characters.

     Domains MUST support case-insensitive matching of local-parts,
     similar to email systems.




  Li, et al.              Expires 30 September 2026              [Page 18]


  Internet-Draft                     ATP                        March 2026


  3.1.3.  Domain Requirements

     The domain portion MUST be a valid Internationalized Domain Name
     (IDN) as defined in [RFC5890].  ATP servers MUST support both ASCII
     and UTF-8 encoded domain names.

  3.2.  Delegation

     Domains can delegate agent handling to external ATP servers using DNS
     CNAME records or SVCB alias mode.

  3.2.1.  CNAME Delegation

     _atp.user.example.com. IN CNAME _atp.provider.net.

     This allows users to maintain their identity (@user.example.com)
     while using third-party ATP services.

  3.2.2.  SVCB Alias Mode

     _atp.delegated.example.com. IN SVCB 0 _atp.target.org.

     SVCB alias mode provides a more modern delegation mechanism with
     additional metadata capabilities.

  4.  Security Framework

  4.1.  Transport Layer Security

     All ATP connections MUST use TLS 1.3 [RFC8446] or higher.  TLS 1.2
     MAY be used for backward compatibility, but its use is NOT
     RECOMMENDED.

  4.1.1.  TLS Requirements

     *  *Mandatory Encryption*: All ATP traffic MUST be encrypted using
        TLS.

     *  *Certificate Validation*: Clients MUST validate server
        certificates against trusted Certificate Authorities (CAs).

     *  *Cipher Suites*: Servers SHOULD support modern cipher suites
        (e.g., TLS_AES_128_GCM_SHA256).

     *  *Forward Secrecy*: Ephemeral key exchange (ECDHE) MUST be used.






  Li, et al.              Expires 30 September 2026              [Page 19]


  Internet-Draft                     ATP                        March 2026


  4.1.2.  Mutual TLS

     For server-to-server communication, ATP servers SHOULD support mutual
     TLS (mTLS) authentication.  For environments where ATS IP-based
     validation is the primary sender verification mechanism, mTLS
     provides an additional layer of transport-level authentication.  ATP
     servers MAY require mTLS for all connections in high-security
     deployments.

  4.2.  Agent Transfer Sender Policy (ATS)

     The Agent Transfer Sender policy (ATS) defines which entities are
     authorized to send ATP messages on behalf of a domain.  ATS is
     designed specifically for agent communication with strict
     enforcement.

  4.2.1.  ATS Record Format

     ATS policies are published as DNS TXT records at the following
     location:

     ats._atp.<domain>. IN TXT "v=atp1 <policy-directives>"

  4.2.2.  Example ATS Records

     *Simple IP-based policy*:

     ats._atp.example.com. IN TXT "v=atp1 allow=ip:192.0.2.0/24"

     *Multi-source policy*:

     ats._atp.example.com. IN TXT "v=atp1 allow=ip:192.0.2.0/24 allow=domain:agent-provider.com include:ats._atp.trusted-partner.net"

     *Permissive policy*:

     ats._atp.example.com. IN TXT "v=atp1 allow=all"

     *Restrictive policy*:

     ats._atp.example.com. IN TXT "v=atp1 deny=all allow=ip:192.0.2.10"

  4.2.3.  Policy Directives

     ATS policy directives are evaluated in order, with later directives
     overriding earlier ones when conflicts occur.

     *  *v=atp1*: Version identifier (REQUIRED).  Indicates ATP version 1
        policy format.



  Li, et al.              Expires 30 September 2026              [Page 20]


  Internet-Draft                     ATP                        March 2026


     *  *allow=ip:<cidr>*: Authorize messages from specific IP address
        ranges.

     *  *allow=domain:<domain>*: Authorize messages from agents at the
        specified domain.

     *  *allow=all*: Authorize messages from any source (NOT RECOMMENDED).

     *  *deny=ip:<cidr>*: Explicitly deny messages from specific IP
        ranges.

     *  *deny=domain:<domain>*: Explicitly deny messages from agents at
        the specified domain.

     *  *deny=all*: Deny all sources (must be followed by specific allow
        directives).

     *  *include:<record>*: Include policy from another ATS record.

     *  *redirect=<domain>*: Redirect policy evaluation to another domain.

     *  *exp=<domain>*: Specify a domain for explanation text (human-
        readable).

  4.2.4.  ATS Query Process

     When an ATP server receives a message claiming to be from
     sender@domain.com, it performs the following ATS verification:

     1.  *Query ATS Record*: Query the DNS TXT record for
         ats._atp.domain.com.

     2.  *Extract IP*: Determine the source IP address of the incoming
         connection.

     3.  *Policy Evaluation*: Evaluate the ATS policy against the source
         IP and sender domain.

     4.  *Authorization Decision*:

         *  If policy evaluation results in PASS, accept the message.

         *  If policy evaluation results in FAIL, reject the message with
            HTTP 403 and error body {"error": "ATS_VALIDATION_FAILED"}.

         *  If no ATS record exists, treat as NEUTRAL (accept but flag for
            monitoring).




  Li, et al.              Expires 30 September 2026              [Page 21]


  Internet-Draft                     ATP                        March 2026


  4.2.5.  ATS Processing Algorithm

     The ATS verification algorithm processes policy directives as
     follows:

     result = NEUTRAL

     FOR EACH directive in policy:
         IF directive is 'allow=ip:<cidr>' AND source_ip matches <cidr>:
             result = PASS
         ELSE IF directive is 'deny=ip:<cidr>' AND source_ip matches <cidr>:
             result = FAIL
         ELSE IF directive is 'allow=domain:<domain>' AND sender_domain matches <domain>:
             result = PASS
         ELSE IF directive is 'deny=domain:<domain>' AND sender_domain matches <domain>:
             result = FAIL
         ELSE IF directive is 'allow=all':
             result = PASS
         ELSE IF directive is 'deny=all':
             result = FAIL
         ELSE IF directive is 'include:<record>':
             include_result = query_ats(<record>)
             IF include_result is PASS or FAIL:
                 result = include_result

     RETURN result

  4.2.6.  ATS Error Codes

     ATS validation errors are returned as HTTP responses with structured
     JSON error bodies:

     *  *403 Forbidden* with body: {"error": "ATS_VALIDATION_FAILED",
        "detail": "Sender not authorized by ATS policy"}

     *  *502 Bad Gateway* with body: {"error": "ATS_TEMPORARY_FAILURE",
        "detail": "DNS lookup timeout for ATS record"}

     *  *403 Forbidden* with body: {"error": "ATS_RECORD_INVALID",
        "detail": "ATS record syntax error"}

  4.2.7.  Cloud Deployment Considerations

     In cloud environments where agents share IP addresses (e.g., CDN,
     serverless platforms, container orchestration), IP-based ATS policies
     may be insufficient.  Deployments in such environments SHOULD:





  Li, et al.              Expires 30 September 2026              [Page 22]


  Internet-Draft                     ATP                        March 2026


     1.  Use allow=domain:<domain> directives instead of IP-based
         directives where possible.

     2.  Combine ATS with mutual TLS for stronger sender verification.

     3.  Rely on ATK signature verification as the primary authentication
         mechanism, with ATS as an additional signal.

     Note: ATS is designed as a first-pass filter, not a sole
     authentication mechanism.  ATK signature verification provides
     cryptographic proof of sender identity regardless of network
     topology.

  4.2.8.  ATS Best Practices

     *  *Start Restrictive*: Begin with a restrictive policy and gradually
        add authorized sources.

     *  *Use Includes*: Use include: directives to inherit policies from
        trusted providers.

     *  *Monitor Logs*: Regularly review ATS validation logs to identify
        unauthorized attempts.

     *  *Gradual Deployment*: Deploy ATS gradually, starting with
        monitoring mode before enforcement.

  4.3.  Agent Transfer Key (ATK)

     The Agent Transfer Key (ATK) record publishes cryptographic public
     keys used for message signature verification.  ATK is mandatory in
     ATP and uses modern cryptographic algorithms.

  4.3.1.  ATK Record Format

     ATK records are published as DNS TXT records at the following
     location:

     <selector>.atk._atp.<domain>. IN TXT "v=atp1 <key-parameters>"

     Where <selector> is an identifier for the specific key (e.g.,
     default, 2026q1, rotated-key).

  4.3.2.  Example ATK Records

     *Ed25519 key (RECOMMENDED)*:

     default.atk._atp.example.com. IN TXT "v=atp1 k=ed25519 p=MCowBQYDK2VwAyEAtLJ5VqH7K+R5VZ8cD9XwY3J2mN8K+R5VZ8cD9XwY3J2m"



  Li, et al.              Expires 30 September 2026              [Page 23]


  Internet-Draft                     ATP                        March 2026


     *RSA key (3072-bit)*:

     legacy.atk._atp.example.com. IN TXT "v=atp1 k=rsa p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

     *ECDSA key (P-256)*:

     p256.atk._atp.example.com. IN TXT "v=atp1 k=ecdsa n=prime256v1 p=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE..."

  4.3.3.  Key Parameters

     *  *v=atp1*: Version identifier (REQUIRED).  Indicates ATP version 1
        key format.

     *  *k=<algorithm>*: Key algorithm (REQUIRED).  Supported values:

        -  ed25519 - Ed25519 (RECOMMENDED for new deployments)

        -  rsa - RSA (3072-bit minimum for new keys, 2048-bit minimum
           accepted for verification)

        -  ecdsa - ECDSA (P-256, P-384, or P-521)

     *  *p=<base64-key>*: Base64-encoded public key (REQUIRED).

     *  *n=<curve-name>*: Elliptic curve name (REQUIRED for ECDSA).
        Supported values: prime256v1, secp384r1, secp521r1.

     *  *h=<hash-alg>*: Hash algorithm (OPTIONAL).  Defaults to sha256.
        Supported values: sha256, sha384, sha512.

     *  *s=<service>*: Service type (OPTIONAL).  Indicates which ATP
        services use this key.

     *  *t=<flags>*: Flags (OPTIONAL).  Comma-separated list of flags:

        -  y - Testing mode (signature validation is informational only)

        -  r - Key is revoked (MUST NOT be used for new signatures)

     *  *x=<expiry>*: Key expiry timestamp (OPTIONAL).  Unix timestamp
        after which the key should not be used.

  4.3.4.  ATK Query Process

     When an ATP server receives a signed message, it performs the
     following ATK verification:





  Li, et al.              Expires 30 September 2026              [Page 24]


  Internet-Draft                     ATP                        March 2026


     1.  *Extract Signature Information*: Parse the message signature to
         extract key selector, domain, signature algorithm, and signature
         value.

     2.  *Query ATK Record*: Query the DNS TXT record for
         <selector>.atk._atp.<domain>.

     3.  *Validate Key Parameters*: Verify that the key algorithm and
         parameters match the signature.

     4.  *Canonicalization*: Canonicalize the message payload according to
         the specified algorithm.

     5.  *Signature Verification*: Verify the signature using the public
         key from the ATK record.

     6.  *Validation Decision*:

         *  If signature verification succeeds, accept the message.

         *  If signature verification fails, reject the message with HTTP
            403 and error body {"error": "ATK_SIGNATURE_INVALID",
            "detail": "Signature verification failed"}.

         *  If ATK record is not found, reject the message with HTTP 403
            and error body {"error": "ATK_KEY_NOT_FOUND", "detail": "No
            ATK record found for selector"}.

  4.3.5.  ATK Key Management

  4.3.5.1.  Key Rotation

     Domains SHOULD rotate ATK keys periodically (e.g., every 90 days).

  4.3.5.2.  Key Revocation

     If a key is compromised, it SHOULD be revoked immediately by updating
     the ATK record to include the r flag.

  4.3.6.  ATK Best Practices

     *  *Use Ed25519*: Prefer Ed25519 keys for new deployments due to
        their security and performance characteristics.

     *  *Key Size*: For RSA keys, generate new keys with at least 3072
        bits (4096-bit RECOMMENDED).  Implementations MUST accept RSA keys
        of 2048 bits or longer for signature verification.  For ECDSA, use
        P-256 or stronger curves.



  Li, et al.              Expires 30 September 2026              [Page 25]


  Internet-Draft                     ATP                        March 2026


     *  *Multiple Keys*: Maintain multiple keys (current, next, previous)
        for smooth rotation.

     *  *DNSSEC*: Sign ATK records with DNSSEC to prevent DNS spoofing
        attacks.

     *  *Monitoring*: Monitor signature validation failures to detect
        potential attacks or misconfigurations.

  4.4.  Message Signature

     All ATP messages MUST be cryptographically signed to ensure integrity
     and authenticity.

  4.4.1.  Signature Envelope

     The signature is included in the message envelope as a signature
     field:

     {
       "from": "sender@example.com",
       "to": "recipient@example.com",
       "timestamp": 1710000000,
       "nonce": "msg-12345-abcde",
       "type": "message",
       "payload": {},
       "signature": {
         "key_id": "default.atk._atp.example.com",
         "algorithm": "ed25519",
         "signature": "MEUCIQDR...",
         "headers": ["from", "to", "timestamp", "nonce", "type"],
         "timestamp": 1710000000
       }
     }

  4.4.2.  Signature Algorithm

     The signature algorithm depends on the key type:

     *  *Ed25519*: Sign the canonicalized message bytes directly.

     *  *RSA*: Use RSASSA-PSS with SHA-256 (or stronger).

     *  *ECDSA*: Use ECDSA with the specified curve and hash algorithm.







  Li, et al.              Expires 30 September 2026              [Page 26]


  Internet-Draft                     ATP                        March 2026


  4.4.3.  Signature Coverage

     The signature MUST cover all fields of the message envelope except
     the signature field itself.  The headers field within the signature
     object is informational and lists the fields that were present at
     signing time; it MUST NOT be used to selectively exclude fields from
     signature verification.

     Verifiers MUST reject messages where the set of fields in the message
     envelope does not match the headers list in the signature object.

  4.4.4.  Canonicalization

     Messages MUST be canonicalized before signing to ensure consistent
     signature verification.

     *JSON Canonicalization Process*:

     ATP uses JSON Canonicalization Scheme (JCS) [RFC8785] for JSON
     payloads:

     1.  Remove the signature field from the message object.

     2.  Apply JCS canonicalization to the remaining JSON object.

     3.  Convert the canonicalized JSON to UTF-8 bytes.

     4.  Sign the UTF-8 bytes using the specified algorithm.

     *CBOR Canonicalization Process*:

     For CBOR payloads, ATP uses deterministic CBOR encoding as defined in
     RFC 8949 Section 4.2 (Core Deterministic Encoding Requirements):

     1.  Remove the signature field from the CBOR map.

     2.  Re-encode the remaining map using deterministic CBOR encoding:

         *  Map keys MUST be sorted in bytewise lexicographic order of
            their deterministic encodings.

         *  Indefinite-length items MUST NOT be used.

         *  Preferred serialization rules from Section 4.1 of [RFC8949]
            MUST be applied.

     3.  Sign the resulting byte string using the specified algorithm.




  Li, et al.              Expires 30 September 2026              [Page 27]


  Internet-Draft                     ATP                        March 2026


  4.4.5.  Signature Verification

     The recipient verifies the signature as follows:

     1.  Extract the signature field from the message.

     2.  Verify that the headers list in the signature object matches the
         set of fields present in the message envelope (excluding
         signature).  Reject the message if they do not match.

     3.  Reconstruct the message object without the signature field.

     4.  Apply the appropriate canonicalization process (JCS for JSON,
         deterministic encoding for CBOR).

     5.  Verify the signature using the public key from the ATK record.

  4.4.6.  Signature Error Handling

     If signature verification fails, the recipient MUST reject the
     message and MAY log the failure for monitoring.

  5.  Transport Protocol

  5.1.  HTTPS Transport

     The primary transport for ATP is HTTPS, enabling easy deployment
     behind existing infrastructure such as CDNs, load balancers, and
     firewalls.

  5.1.1.  Default Port

     The default port for ATP over HTTPS is *7443*. IANA registration for
     this port is requested in the IANA Considerations section of this
     document.

     Deployments MUST support custom port configuration via SVCB records.
     ATP servers MAY listen on alternative ports (including 443) as
     specified in the SVCB record's port parameter.  The use of a
     dedicated port provides operational advantages in enterprise
     environments: security teams can identify and audit ATP traffic by
     port number without requiring deep packet inspection, and it avoids
     path conflicts with existing HTTPS services on port 443.

  5.1.2.  Endpoints

     ATP servers MUST implement the following standard endpoints:




  Li, et al.              Expires 30 September 2026              [Page 28]


  Internet-Draft                     ATP                        March 2026


  5.1.2.1.  Send Message Endpoint

     POST /.well-known/atp/v1/message
     Content-Type: application/atp+json

     *Request Body*: ATP message envelope

     *Response*:

     *  *202 Accepted*: Message accepted for delivery

     *  *400 Bad Request*: Invalid message format

     *  *401 Unauthorized*: Authentication failed

     *  *429 Too Many Requests*: Rate limit exceeded

     *  *500 Internal Server Error*: Server error

  5.1.2.2.  Capability Discovery Endpoint

     GET /.well-known/atp/v1/capabilities

     *Response*: JSON object describing server capabilities

  5.1.2.3.  Health Check Endpoint

     GET /.well-known/atp/v1/health

     *Response*:

     {
       "status": "ok",
       "version": "1.0.0",
       "uptime": 86400,
       "load": 0.45
     }

  5.1.3.  Connection Management

     *  *Keep-Alive*: Clients SHOULD use HTTP keep-alive for multiple
        requests.

     *  *Timeout*: Servers SHOULD implement idle timeout (RECOMMENDED: 60
        seconds).

     *  *Rate Limiting*: Servers MAY implement rate limiting with
        appropriate HTTP headers.



  Li, et al.              Expires 30 September 2026              [Page 29]


  Internet-Draft                     ATP                        March 2026


  5.2.  IPv6 Considerations

     ATP deployments SHOULD support IPv6 connectivity.  ATP servers MUST
     publish both A and AAAA records when IPv6 is available.  Clients
     SHOULD implement Happy Eyeballs [RFC8305] for dual-stack connection
     establishment.

     In the SVCB record, the ipv6hint parameter provides IPv6 address
     hints for faster connection establishment without an additional AAAA
     query:

     _atp.example.com. IN SVCB 1 agent.example.com. (
         port=7443
         alpn="atp/1"
         ipv4hint=192.0.2.1
         ipv6hint=2001:db8::1,2001:db8::2
         atp-capabilities="message,request,event"
     )

     For new ATP deployments, IPv6-only operation is a valid
     configuration.  IPv4 support is NOT REQUIRED when the deployment
     environment is IPv6-capable.

  5.3.  QUIC Transport (Future Work)

     ATP is designed to support QUIC transport [RFC9000] for low-latency
     scenarios.  The ALPN identifier for ATP over QUIC is atp/1.

     The full specification of QUIC transport for ATP, including message-
     to-stream mapping, QUIC error code registry, and 0-RTT security
     considerations, is deferred to a companion document.  This section
     provides an overview of the intended design.

  5.3.1.  Expected Benefits

     *  *0-RTT Handshake*: Establish connections with zero round-trip time
        for resumed connections.

     *  *Multiplexing*: Multiple ATP messages over a single connection
        without head-of-line blocking.

     *  *Connection Migration*: Maintain connections across network
        changes.

     *  *Better Performance*: Reduced latency over lossy networks.






  Li, et al.              Expires 30 September 2026              [Page 30]


  Internet-Draft                     ATP                        March 2026


  5.3.2.  Security Note

     QUIC 0-RTT data is subject to replay attacks.  ATP messages sent over
     0-RTT MUST be idempotent, or servers MUST implement application-level
     replay protection in addition to the timestamp/nonce mechanism
     defined in this specification.

  6.  Message Format

  6.1.  Common Fields

     All ATP messages share a common envelope structure with the following
     fields:

     {
       "from": "string",
       "to": "string",
       "cc": ["string"],
       "timestamp": "integer",
       "nonce": "string",
       "type": "string",
       "in_reply_to": "string",
       "task_id": "string",
       "context_id": "string",
       "payload": "object",
       "signature": "object",
       "routing": "object"
     }

  6.1.1.  Field Definitions

     *  *from*: The Agent ID of the message sender (REQUIRED).  MUST be a
        valid agent identifier.

     *  *to*: The Agent ID of the primary recipient (REQUIRED).  MUST be a
        valid agent identifier.

     *  *cc*: Array of Agent IDs for carbon-copy recipients (OPTIONAL).

     *  *timestamp*: Unix timestamp (seconds since epoch) when the message
        was created (REQUIRED).  Recipients MUST reject messages with
        timestamps more than 300 seconds (5 minutes) in the past or more
        than 60 seconds in the future relative to the recipient's clock.
        Implementations SHOULD use NTP-synchronized clocks.

     *  *nonce*: Cryptographically random unique identifier for the
        message (REQUIRED).  MUST be unique per sender within the
        timestamp validity window.  Recipients MUST maintain a cache of



  Li, et al.              Expires 30 September 2026              [Page 31]


  Internet-Draft                     ATP                        March 2026


        recently seen (sender, nonce) pairs for at least the duration of
        the timestamp validity window (300 seconds) and MUST reject
        duplicate (sender, nonce) pairs.

     *  *type*: Message type indicator (REQUIRED).  Values: message,
        request, response, event.

     *  *in_reply_to*: The nonce of the original message that this message
        is responding to (OPTIONAL).  REQUIRED for response type messages.
        Used for request-response correlation.

     *  *task_id*: Identifies the task or workflow this message belongs to
        (OPTIONAL).  All messages related to the same task SHOULD use the
        same task_id.

     *  *context_id*: Identifies the conversation or session context
        (OPTIONAL).  Used for multi-turn interactions.

     *  *payload*: Message-specific content (REQUIRED).  Structure depends
        on message type.

     *  *signature*: Cryptographic signature envelope (REQUIRED).

     *  *routing*: Routing information for multi-hop scenarios (OPTIONAL).

  6.2.  Message Types

     ATP supports three primary message types, each with distinct
     semantics and use cases.

  6.2.1.  Message (Asynchronous)

     The message type is used for asynchronous, fire-and-forget
     communication.

















  Li, et al.              Expires 30 September 2026              [Page 32]


  Internet-Draft                     ATP                        March 2026


     {
       "from": "a1@example.com",
       "to": "a2@example.com",
       "timestamp": 1710000000,
       "nonce": "msg-12345-abcde",
       "type": "message",
       "payload": {
         "subject": "Hello from Agent A1",
         "body": "This is an asynchronous message",
         "attachments": [
           {
             "name": "data.json",
             "content_type": "application/json",
             "data": "base64-encoded-data"
           }
         ],
         "priority": "normal"
       },
       "signature": {}
     }

  6.2.2.  Request/Response

     The request/response pattern supports synchronous RPC-style
     interactions.

  6.2.2.1.  Request Format

     {
       "from": "client@example.com",
       "to": "service@example.org",
       "timestamp": 1710000000,
       "nonce": "req-67890-fghij",
       "type": "request",
       "payload": {
         "action": "get_weather",
         "params": {
           "location": "New York",
           "units": "metric"
         },
         "timeout": 30,
         "correlation_id": "corr-12345"
       },
       "signature": {}
     }

  6.2.2.2.  Response Format




  Li, et al.              Expires 30 September 2026              [Page 33]


  Internet-Draft                     ATP                        March 2026


     {
       "from": "service@example.org",
       "to": "client@example.com",
       "timestamp": 1710000001,
       "nonce": "resp-67890-klmno",
       "type": "response",
       "in_reply_to": "req-67890-fghij",
       "payload": {
         "status": "success",
         "data": {
           "temperature": 22,
           "conditions": "sunny",
           "humidity": 65
         },
         "correlation_id": "corr-12345"
       },
       "signature": {}
     }

  6.2.3.  Event/Subscription

     The event type supports streaming and event-driven communication.

  6.2.3.1.  Subscription Request

     {
       "from": "subscriber@example.com",
       "to": "publisher@example.org",
       "timestamp": 1710000000,
       "nonce": "sub-11111-pqrst",
       "type": "request",
       "payload": {
         "action": "subscribe",
         "event_types": ["price_update", "news", "alert"],
         "filter": {
           "symbol": "AAPL",
           "priority": ">=high"
         },
         "delivery_mode": "push",
         "subscription_id": "sub-12345"
       },
       "signature": {}
     }

  6.2.3.2.  Event Message






  Li, et al.              Expires 30 September 2026              [Page 34]


  Internet-Draft                     ATP                        March 2026


     {
       "from": "publisher@example.org",
       "to": "subscriber@example.com",
       "timestamp": 1710000010,
       "nonce": "evt-22222-uvwxy",
       "type": "event",
       "payload": {
         "event_type": "price_update",
         "subscription_id": "sub-12345",
         "data": {
           "symbol": "AAPL",
           "price": 150.25,
           "timestamp": 1710000010,
           "volume": 1000000
         },
         "sequence_number": 42
       },
       "signature": {}
     }

  6.3.  Payload Encoding

     ATP supports multiple payload encoding formats.

  6.3.1.  JSON Encoding

     JSON [RFC8259] is the RECOMMENDED encoding format.

     *Content-Type*: application/atp+json

  6.3.2.  CBOR Encoding

     CBOR [RFC8949] is an OPTIONAL encoding format for bandwidth-
     constrained environments.

     *Content-Type*: application/atp+cbor

  6.4.  Message Size Limits

     ATP servers SHOULD enforce message size limits:

     *  *Default Maximum*: 1 MB (1,048,576 bytes)

     *  *Minimum Supported*: 64 KB (65,536 bytes)







  Li, et al.              Expires 30 September 2026              [Page 35]


  Internet-Draft                     ATP                        March 2026


  7.  Protocol Semantics

  7.1.  Message (Asynchronous)

     Asynchronous messages follow a store-and-forward model.

  7.1.1.  Delivery Model

     Sender Agent      ATP Server A      ATP Server B      Recipient Agent
          |                |                 |                    |
          |---[Submit]---->|                 |                    |
          |                |                 |                    |
          |                |---[Transfer]--->|                    |
          |                |                 |                    |
          |                |                 |----[Deliver]------>|
          |                |                 |                    |

        Figure 3: Asynchronous Message Delivery Model: Submit → Transfer
                       → Deliver flow through ATP servers

     In this model:

     1.  The Sender Agent submits a message to its local ATP Server A

     2.  ATP Server A performs policy enforcement (ATS/ATK validation) and
         transfers the message to ATP Server B

     3.  ATP Server B performs security checks and delivers the message to
         the Recipient Agent

     Each hop (Submit/Transfer/Deliver) involves independent ATS/ATK
     validation for security enforcement.

  7.1.2.  Delivery Guarantees

     ATP asynchronous messages provide store-and-forward delivery with the
     following semantics:

     *  *Default*: Best-effort delivery.  Servers attempt delivery but do
        not guarantee success.

     *  *With acknowledgment*: When delivery acknowledgment is requested
        (via payload.ack_required: true), servers provide at-least-once
        delivery semantics.







  Li, et al.              Expires 30 September 2026              [Page 36]


  Internet-Draft                     ATP                        March 2026


  7.1.3.  Retry Policy

     Servers SHOULD retry failed deliveries using exponential backoff:

     *  Initial retry interval: 1 second

     *  Maximum retry interval: 1 hour

     *  Maximum retry duration: 48 hours

     *  Maximum retry count: 10

     After exhausting retries, servers MUST generate a bounce notification
     if the sender requested acknowledgment.

  7.2.  Request/Response (Synchronous)

     Synchronous request/response follows an RPC pattern.

  7.2.1.  Interaction Model

     All agent communication MUST go through their respective ATP servers.
     This design ensures proper routing, security filtering, and policy
     enforcement.

     Client Agent     ATP Server A     ATP Server B     Service Agent
          |                |                 |                 |
          |---[Request]--->|                 |                 |
          |                |                 |                 |
          |                |---[Transfer]--->|                 |
          |                |                 |                 |
          |                |                 |---[Request]---->|
          |                |                 |                 |
          |                |                 |<--[Response]----|
          |                |                 |                 |
          |                |<--[Transfer]----|                 |
          |<--[Response]---|                 |                 |
          |                |                 |                 |

         Figure 4: Request/Response Interaction Model: Synchronous RPC-
          style flow with bidirectional server-mediated communication

     In this model:

     1.  The Client Agent submits a request to its local ATP Server A via
         HTTP POST





  Li, et al.              Expires 30 September 2026              [Page 37]


  Internet-Draft                     ATP                        March 2026


     2.  ATP Server A performs policy enforcement (ATS/ATK validation) and
         transfers the request to ATP Server B

     3.  ATP Server B performs security checks and delivers the request to
         the Service Agent

     4.  The Service Agent processes the request and returns a response

     5.  The response flows back through the same path (Service Agent →
         ATP Server B → ATP Server A → Client Agent)

     Each hop (Submit/Transfer/Deliver) involves independent ATS/ATK
     validation for security enforcement.

  7.2.2.  Deadline Propagation

     For multi-hop request/response interactions, the timeout MUST be
     converted to an absolute deadline for relay forwarding.  The absolute
     deadline is computed as:

     deadline = sender_timestamp + timeout

     When a relay forwards a request:

     1.  Calculate the remaining time: remaining = deadline - now

     2.  If remaining <= 0, return a TIMEOUT error immediately with HTTP
         504 and error body {"error": "DEADLINE_EXCEEDED", "detail":
         "Request deadline expired in transit"}.

     3.  Set the forwarded request's timeout to the remaining time.

  7.2.3.  State Management

     *  *Stateless*: Each request is independent.

     *  *Correlation ID*: Clients MAY include a correlation_id to track
        workflows.

     *  *Idempotency*: Requests SHOULD be idempotent.

  7.3.  Event/Subscription (Streaming)

     Event/subscription follows a publish-subscribe pattern.







  Li, et al.              Expires 30 September 2026              [Page 38]


  Internet-Draft                     ATP                        March 2026


  7.3.1.  Pub/Sub Model

     All event publications and subscriptions MUST go through ATP servers
     for proper routing and access control.

     Publisher       ATP Server A    ATP Server B      Subscriber
          |               |               |                 |
          |----[Event]--->|               |                 |
          |               |               |                 |
          |               |--[Transfer]-->|                 |
          |               |               |                 |
          |               |               |-----[Event]---->|
          |               |               |                 |
          |               |               |<--[Subscribe]---|
          |               |               |                 |
          |               |<--[Transfer]--|                 |
          |<-[Subscribe]--|               |                 |
          |               |               |                 |

         Figure 5: Event/Subscription Pub/Sub Model: Bidirectional flow
             for subscription establishment and event notification

     The event/subscription flow consists of two phases:

     *Subscription Phase*: The Subscriber initiates a subscription request
     to its local ATP Server, which transfers the request to the
     Publisher's ATP Server, which then delivers it to the Publisher.
     This establishes the subscription relationship across the server
     chain.

     *Event Notification Phase*: When an event occurs, the Publisher sends
     the event to its local ATP Server (Server B), which transfers it
     across the Internet to the Subscriber's ATP Server (Server A), which
     then delivers the notification to the Subscriber.

     This bidirectional flow ensures:

     *  Proper access control at each ATP server boundary

     *  ATS/ATK policy enforcement for both subscription and event
        messages

     *  Subscription state management at the Publisher's server








  Li, et al.              Expires 30 September 2026              [Page 39]


  Internet-Draft                     ATP                        March 2026


  7.3.2.  Subscription Lifecycle

     *  *TTL*: Subscriptions SHOULD include a ttl field (in seconds) in
        the subscribe request payload.  If not specified, the default TTL
        is 3600 seconds (1 hour).

     *  *Renewal*: Subscribers MUST renew subscriptions before TTL expiry
        by sending a new subscribe request with the same subscription_id.

     *  *Heartbeat*: Publishing servers SHOULD send periodic heartbeat
        events (type: event, event_type: heartbeat) to subscribing
        servers.  Note that heartbeat is a server-to-server mechanism, not
        agent-to-agent; it verifies the liveness of the subscription
        channel between ATP servers.  Subscribing servers that do not
        receive a heartbeat within 2x the expected interval SHOULD re-
        subscribe.

     *  *Auto-expiry*: Subscriptions that are not renewed within their TTL
        period are automatically expired.  Publishers MUST stop sending
        events to expired subscriptions.

  7.3.3.  Server-to-Server Event Delivery

     For push-mode event delivery, the publishing server sends events to
     the subscribing server's ATP message endpoint.  The subscribing
     server's endpoint is discovered through the standard DNS SVCB
     discovery process using the subscriber's domain.

     Future versions of this specification MAY define additional transport
     mechanisms for real-time event delivery, including:

     *  Server-Sent Events (SSE) for unidirectional streaming

     *  WebSocket for bidirectional streaming

     These mechanisms are out of scope for the current version.

  8.  Security Considerations

     ATP is designed with security as a first-class requirement.  This
     section analyzes the threat model and security considerations for
     each component of the protocol.

  8.1.  Threat Model

     The threat model for ATP considers the following adversaries and
     attack vectors:




  Li, et al.              Expires 30 September 2026              [Page 40]


  Internet-Draft                     ATP                        March 2026


     *Network Adversaries*: Passive or active attackers on the network
     path between agents and ATP servers, or between ATP servers.
     Capabilities may include:

     *  Eavesdropping on unencrypted traffic

     *  Man-in-the-middle (MitM) attacks to intercept or modify
        communications

     *  Replay attacks using captured messages

     *  Traffic analysis to infer communication patterns

     *Malicious Agents*: Compromised or malicious agents that attempt to:

     *  Send unauthorized messages on behalf of other agents (spoofing)

     *  Flood servers with excessive requests (DoS)

     *  Exploit protocol vulnerabilities to gain unauthorized access

     *Rogue ATP Servers*: Compromised or malicious ATP servers that may:

     *  Fail to enforce ATS/ATK policies

     *  Leak sensitive message content

     *  Drop or delay messages selectively

     *DNS Attackers*: Adversaries that attempt to compromise DNS
     infrastructure:

     *  DNS cache poisoning to redirect ATP traffic

     *  DNS spoofing to provide fraudulent SVCB records

     *  DNS amplification attacks

  8.2.  Authentication

  8.2.1.  TLS Security

     *Threat*: Network adversaries attempting eavesdropping or MitM
     attacks.

     *Mitigation*:

     *  All ATP connections MUST use TLS 1.3 [RFC8446] or higher



  Li, et al.              Expires 30 September 2026              [Page 41]


  Internet-Draft                     ATP                        March 2026


     *  Certificate validation against trusted Certificate Authorities is
        mandatory

     *  Cipher suites MUST provide forward secrecy (ECDHE key exchange)

     *  Cipher suites SHOULD use authenticated encryption (AES-GCM,
        ChaCha20-Poly1305)

     *Residual Risk*: Certificate authority compromise or mis-issuance.
     Deployments with high security requirements SHOULD implement
     certificate pinning or use DANE [RFC6698].

  8.2.2.  ATS (Agent Transfer Sender Policy)

     *Threat*: Malicious agents attempting to send messages on behalf of
     domains they do not control (spoofing).

     *Mitigation*:

     *  ATS records define authorized sending sources per domain

     *  Policy directives include IP ranges, domains, and explicit deny
        rules

     *  Each ATP server performs ATS validation on every incoming message

     *  Failed ATS validation results in immediate rejection

     *Residual Risk*: ATS record tampering via DNS attacks.  Deployments
     SHOULD sign ATS records with DNSSEC [RFC4033].

  8.2.3.  ATK (Agent Transfer Key)

     *Threat*: Message tampering or forgery by network adversaries or
     malicious agents.

     *Mitigation*:

     *  ATK records publish cryptographic public keys for signature
        verification

     *  All ATP messages MUST be cryptographically signed

     *  Supported algorithms: Ed25519 (RECOMMENDED), RSA (3072+ bit for
        new keys), ECDSA (P-256+)

     *  Signature covers all critical message fields (from, to, timestamp,
        nonce, type, payload)



  Li, et al.              Expires 30 September 2026              [Page 42]


  Internet-Draft                     ATP                        March 2026


     *Residual Risk*: Key compromise.  Domains MUST implement key rotation
     and maintain revocation procedures via the r flag in ATK records.

  8.2.4.  Message Signature

     *Threat*: Message modification in transit, replay attacks.

     *Mitigation*:

     *  Cryptographic signatures cover canonicalized message content

     *  Nonce prevents replay attacks

     *  Timestamp enables expiration checking

     *  Signature includes headers list to prevent header manipulation

     *Residual Risk*: Long-term key compromise enables retroactive
     forgery.  Future work may introduce forward-secure signature schemes.

  8.3.  Privacy

  8.3.1.  Metadata Exposure

     *Threat*: Traffic analysis revealing communication patterns,
     relationships, or sensitive business information.

     *Exposure*:

     *  from and to fields are visible to ATP servers and network
        observers

     *  timestamp reveals timing of communications

     *  type indicates interaction pattern (message, request, response,
        event)

     *Mitigation*:

     *  Payload content SHOULD be encrypted end-to-end when
        confidentiality is required

     *  Agents MAY use pseudonymous identifiers for sensitive
        communications

     *  ATP servers SHOULD minimize metadata logging





  Li, et al.              Expires 30 September 2026              [Page 43]


  Internet-Draft                     ATP                        March 2026


     *Residual Risk*: Metadata analysis remains possible.  Applications
     with strong privacy requirements SHOULD implement additional
     obfuscation at the application layer.

  8.3.2.  Payload Confidentiality

     *Threat*: Unauthorized access to message content by ATP servers or
     network adversaries.

     *Mitigation*:

     *  TLS encryption protects payload in transit between hops

     *  Agents MAY encrypt payload content end-to-end using recipient's
        public key

     *  CBOR encoding supports embedded encrypted content

     *Residual Risk*: ATP servers must inspect messages for policy
     enforcement.  Deployments handling sensitive data SHOULD implement
     server-side encryption with customer-managed keys.

  8.4.  Denial of Service

  8.4.1.  Resource Exhaustion Attacks

     *Threat*: Adversaries flooding ATP servers with excessive messages or
     connections.

     *Attack Vectors*:

     *  Message flooding to exhaust server storage or bandwidth

     *  Connection exhaustion to deplete server connection pools

     *  Computational DoS via expensive cryptographic operations

     *Mitigation*:

     *  Rate limiting based on sender reputation and domain

     *  Message size limits (default 1 MB maximum)

     *  Connection limits per sender IP and domain

     *  Exponential backoff for retry attempts

     *  Quota enforcement per agent and per domain



  Li, et al.              Expires 30 September 2026              [Page 44]


  Internet-Draft                     ATP                        March 2026


  8.4.2.  Amplification Attacks

     *Threat*: Attackers using ATP to amplify traffic toward victims.

     *Mitigation*:

     *  ATS validation prevents unauthorized relaying

     *  Response messages only sent to request initiators

     *  Subscription confirmation required before event delivery

     *  No broadcast or multicast mechanisms

  8.5.  DNS Security

  8.5.1.  DNS Spoofing and Cache Poisoning

     *Threat*: Attackers providing fraudulent DNS responses to redirect
     ATP traffic.

     *Mitigation*:

     *  ATP servers SHOULD validate DNS responses using DNSSEC [RFC4033]

     *  SVCB records SHOULD be cached with appropriate TTL

     *  Multiple independent DNS resolvers SHOULD be consulted

     *Residual Risk*: DNSSEC adoption is not universal.  Applications
     requiring high assurance SHOULD implement additional verification.

  8.5.2.  DNS Query Privacy

     *Threat*: DNS queries revealing which domains agents communicate
     with.

     *Mitigation*:

     *  DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) for query
        confidentiality

     *  DNS query caching to reduce query frequency

     *  Batch queries when discovering multiple domains

  8.6.  ATP Server Security




  Li, et al.              Expires 30 September 2026              [Page 45]


  Internet-Draft                     ATP                        March 2026


  8.6.1.  Server Compromise

     *Threat*: Compromised ATP server leaking or modifying messages.

     *Mitigation*:

     *  End-to-end message signatures detect modification

     *  Payload encryption protects content from server inspection

     *  Audit logging for security monitoring

     *  Regular security updates and hardening

  8.6.2.  Multi-tenant Isolation

     *Threat*: One tenant's agents accessing or interfering with another
     tenant's agents.

     *Mitigation*:

     *  Strict domain-based access control

     *  Per-tenant quota enforcement

     *  Isolated processing contexts

     *  ATS/ATK validation per message

  8.7.  Security Best Practices

     Deployments SHOULD implement the following security practices:

     1.  *DNSSEC*: Sign all DNS zones containing ATS and ATK records

     2.  *Key Rotation*: Rotate ATK keys every 90 days minimum

     3.  *Monitoring*: Log and alert on ATS/ATK validation failures

     4.  *Certificate Management*: Monitor certificate expiration and
         implement automated renewal

     5.  *Incident Response*: Maintain procedures for key revocation and
         emergency policy updates

     6.  *Defense in Depth*: Implement multiple layers of security
         controls




  Li, et al.              Expires 30 September 2026              [Page 46]


  Internet-Draft                     ATP                        March 2026


  8.8.  Known Limitations

     1.  *Metadata Visibility*: ATP does not hide communication metadata
         from ATP servers

     2.  *DNS Trust*: DNS security depends on DNSSEC adoption

     3.  *Server Trust*: ATP servers can observe unencrypted payload
         content

     4.  *Key Management*: Compromised keys enable message forgery until
         revocation

     Future revisions of ATP may address these limitations through
     techniques such as onion routing, encrypted DNS, or decentralized
     trust models.

  9.  IANA Considerations

  9.1.  Application-Layer Protocol Negotiation (ALPN) Protocol Identifier

     IANA is requested to register the following ALPN protocol identifier:

     *  *Protocol*: atp/1

     *  *Identification Sequence*: 0x61 0x74 0x70 0x2f 0x31 (atp/1)

     *  *Specification*: This document

  9.2.  Well-Known URI

     IANA is requested to register the following well-known URI:

     *  *URI Suffix*: atp

     *  *Change Controller*: IETF

     *  *Specification*: This document

  9.3.  Media Types

     IANA is requested to register the following media types:

     *  *application/atp+json*: JSON-encoded ATP messages as defined in
        Section 6

     *  *application/atp+cbor*: CBOR-encoded ATP messages as defined in
        Section 6



  Li, et al.              Expires 30 September 2026              [Page 47]


  Internet-Draft                     ATP                        March 2026


  9.4.  Service Name and Transport Protocol Port Number Registry

     IANA is requested to register the following service:

     *  *Service Name*: atp

     *  *Port Number*: 7443

     *  *Transport Protocol*: TCP, UDP

     *  *Description*: Agent Transfer Protocol

     *  *Reference*: This document

  9.5.  SVCB SvcParamKey Registrations

     IANA is requested to register the following entries in the "Service
     Binding (SVCB) SvcParamKey" registry defined in [RFC9460]:

     +==================+======================+===========+============+
     | SvcParamKey      | Meaning              | Format    | Change     |
     |                  |                      | Reference | Controller |
     +==================+======================+===========+============+
     | atp-capabilities | Comma-separated list | Section   | IETF       |
     |                  | of ATP protocol      | 2.3 of    |            |
     |                  | capabilities         | this      |            |
     |                  |                      | document  |            |
     +------------------+----------------------+-----------+------------+
     | atp-auth         | Comma-separated list | Section   | IETF       |
     |                  | of supported         | 2.1 of    |            |
     |                  | authentication       | this      |            |
     |                  | mechanisms           | document  |            |
     +------------------+----------------------+-----------+------------+

                                   Table 2

  9.5.1.  ATP Capabilities Values

     The initial registered values for the atp-capabilities parameter are:












  Li, et al.              Expires 30 September 2026              [Page 48]


  Internet-Draft                     ATP                        March 2026


           +=========+==============================+=============+
           | Value   | Description                  | Reference   |
           +=========+==============================+=============+
           | message | Asynchronous messaging       | Section 7.1 |
           +---------+------------------------------+-------------+
           | request | Synchronous request/response | Section 7.2 |
           +---------+------------------------------+-------------+
           | event   | Event/subscription streaming | Section 7.3 |
           +---------+------------------------------+-------------+

                                   Table 3

     Additional values may be registered via Specification Required
     [RFC8126] policy.

  9.5.2.  ATP Auth Values

     The initial registered values for the atp-auth parameter are:

             +=======+============================+=============+
             | Value | Description                | Reference   |
             +=======+============================+=============+
             | ats   | ATS policy validation      | Section 4.2 |
             +-------+----------------------------+-------------+
             | atk   | ATK signature verification | Section 4.3 |
             +-------+----------------------------+-------------+
             | mtls  | Mutual TLS authentication  | Section 4.1 |
             +-------+----------------------------+-------------+

                                   Table 4

  9.6.  ATP Message Type Registry

     IANA is requested to create the "ATP Message Types" registry with the
     following initial values:
















  Li, et al.              Expires 30 September 2026              [Page 49]


  Internet-Draft                     ATP                        March 2026


              +==========+======================+===============+
              | Type     | Description          | Reference     |
              +==========+======================+===============+
              | message  | Asynchronous message | Section 6.2.1 |
              +----------+----------------------+---------------+
              | request  | Synchronous request  | Section 6.2.2 |
              +----------+----------------------+---------------+
              | response | Synchronous response | Section 6.2.2 |
              +----------+----------------------+---------------+
              | event    | Event notification   | Section 6.2.3 |
              +----------+----------------------+---------------+

                                    Table 5

     New message types are registered via Specification Required [RFC8126]
     policy.

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

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, DOI 10.17487/RFC5890, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5890>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/rfc/rfc8785>.



  Li, et al.              Expires 30 September 2026              [Page 50]


  Internet-Draft                     ATP                        March 2026


     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
                Multiplexed and Secure Transport", RFC 9000,
                DOI 10.17487/RFC9000, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9000>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
                and Parameter Specification via the DNS (SVCB and HTTPS
                Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

  10.2.  Informative References

     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
                STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
                <https://www.rfc-editor.org/rfc/rfc1034>.

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
                of Named Entities (DANE) Transport Layer Security (TLS)
                Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
                2012, <https://www.rfc-editor.org/rfc/rfc6698>.

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







  Li, et al.              Expires 30 September 2026              [Page 51]


  Internet-Draft                     ATP                        March 2026


     [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
                Better Connectivity Using Concurrency", RFC 8305,
                DOI 10.17487/RFC8305, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8305>.

  Appendix A.  Example Message Flows

  A.1.  Sending an ATP Message

     Client                      DNS                   Server
       |                          |                      |
       |---- SVCB Query --------->|                      |
       |                          |                      |
       |<----- SVCB Response -----|                      |
       |     _atp.example.com     |                      |
       |    agent.example.com:7443|                      |
       |                          |                      |
       |---- A/AAAA Query ------->|                      |
       |                          |                      |
       |<------- IP Address ------|                      |
       |         192.0.2.1        |                      |
       |                          |                      |
       |==========================|======================|
       |                                                 |
       |<-------------------TLS Handshake--------------->|
       |                                                 |
       |--- POST /.well-known/atp/v1/message ----------->|
       |   Content-Type: application/atp+json            |
       |   {                                             |
       |     "from": "a1@sender.com",                    |
       |     "to": "a2@example.com",                     |
       |     "type": "message",                          |
       |     "payload": {...},                           |
       |     "signature": {...}                          |
       |   }                                             |
       |                                                 |
       |<---------------------- 202 Accepted ------------|
       |                                                 |

        Figure 6: Sending an ATP Message: DNS discovery, TLS handshake,
                          and message submission flow










  Li, et al.              Expires 30 September 2026              [Page 52]


  Internet-Draft                     ATP                        March 2026


  A.2.  Request/Response Flow

     The request/response flow demonstrates synchronous RPC-style
     interaction between agents.  The Client Agent connects to its local
     ATP Server (Server A), which enforces policy and transfers the
     request to the destination ATP Server (Server B), which delivers it
     to the Service Agent.  The response follows the reverse path.

  Client                  DNS                  ATP           ATP        Service
   Agent                   |                 Server A      Server B      Agent
    |                      |                    |             |             |
    |-- SVCB Query --------|                    |             |             |
    |                      |                    |             |             |
    |<- SVCB Response -----|                    |             |             |
    |   _atp.service.org   |                    |             |             |
    |  service.org:7443    |                    |             |             |
    |                      |                    |             |             |
    |-- A/AAAA Query ------>                    |             |             |
    |                      |                    |             |             |
    |<- IP Address ---------                    |             |             |
    |    198.51.100.1      |                    |             |             |
    |                      |                    |             |             |
    |======================|====================|=============|=============|
    |                                           |             |             |
    |<-------------TLS Handshake--------------->|             |             |
    |                                           |             |             |
    |-- POST /.well-known/atp/v1/message ------>|             |             |
    |   Content-Type: application/atp+json      |             |             |
    |   {                                       |             |             |
    |     "from": "client@example.com",         |             |             |
    |     "to": "service@service.org",          |             |             |
    |     "timestamp": 1710000000,              |             |             |
    |     "nonce": "req-67890-fghij",           |             |             |
    |     "type": "request",                    |             |             |
    |     "payload": {                          |             |             |
    |       "action": "get_weather",            |             |             |
    |       "params": {"location": "New York"}  |             |             |
    |     },                                    |             |             |
    |     "signature": {...}                    |             |             |
    |   }                                       |             |             |
    |                                           |             |             |
    |                                           |-[Transfer]->|             |
    |                                           |             |             |
    |                                           |             |-[Request]-->|
    |                                           |             |             |
    |                                           |             |<-[Response]-|
    |                                           |<-[Transfer]-|             |
    |                                           |             |             |



  Li, et al.              Expires 30 September 2026              [Page 53]


  Internet-Draft                     ATP                        March 2026


    |<- 202 Accept/Response --------------------|             |             |
    |   {                                       |             |             |
    |     "from": "service@service.org",        |             |             |
    |     "to": "client@example.com",           |             |             |
    |     "timestamp": 1710000002,              |             |             |
    |     "nonce": "resp-67890-klmno",          |             |             |
    |     "type": "response",                   |             |             |
    |     "in_reply_to": "req-67890-fghij",     |             |             |
    |     "payload": {                          |             |             |
    |       "status": "success",                |             |             |
    |       "data": {"temperature": 22}         |             |             |
    |     },                                    |             |             |
    |     "signature": {...}                    |             |             |
    |   }                                       |             |             |
    |                                           |             |             |

      Figure 7: Request/Response Flow: DNS discovery, TLS handshake,
         request submission, server transfer, and response return

  A.3.  Event Subscription Flow

     The event subscription flow demonstrates the publish-subscribe
     pattern with streaming notifications.  The flow has two phases:

     *Phase 1 - Subscribe*: The Subscriber sends a subscription request to
     its local ATP Server (Server A), which transfers it to the
     Publisher's ATP Server (Server B), which delivers it to the
     Publisher.

     *Phase 2 - Event Notification*: When an event occurs, the Publisher
     sends the event to Server B, which transfers it to Server A, which
     delivers the notification to the Subscriber.

  Subscriber              DNS                  ATP           ATP      Publisher
   Agent                   |                 Server A      Server B      Agent
    |                      |                    |             |             |
    |-- SVCB Query --------|                    |             |             |
    |                      |                    |             |             |
    |<- SVCB Response -----|                    |             |             |
    |   _atp.publisher.io  |                    |             |             |
    |  publisher.io:7443   |                    |             |             |
    |                      |                    |             |             |
    |-- A/AAAA Query ------>                    |             |             |
    |                      |                    |             |             |
    |<- IP Address ---------                    |             |             |
    |    203.0.113.1       |                    |             |             |
    |                      |                    |             |             |
    |======================|====================|=============|=============|



  Li, et al.              Expires 30 September 2026              [Page 54]


  Internet-Draft                     ATP                        March 2026


    |<-------------TLS Handshake--------------->|             |             |
    |============================ Subscribe Phase ==========================|
    |                                           |             |             |
    |-- POST /.well-known/atp/v1/message ------>|             |             |
    |   Content-Type: application/atp+json      |             |             |
    |   {                                       |             |             |
    |     "from": "subscriber@example.com",     |             |             |
    |     "to": "publisher@publisher.io",       |             |             |
    |     "timestamp": 1710000000,              |             |             |
    |     "nonce": "sub-11111-pqrst",           |             |             |
    |     "type": "request",                    |             |             |
    |     "payload": {                          |             |             |
    |       "action": "subscribe",              |             |             |
    |       "event_types": ["price_update"],    |             |             |
    |       "subscription_id": "sub-12345"      |             |             |
    |     },                                    |             |             |
    |     "signature": {...}                    |             |             |
    |   }                                       |             |             |
    |                                           |-[Transfer]->|             |
    |                                           |             |-[Subscribe]>|
    |<-- 202 Accepted --------------------------|             |             |
    |                                           |             |             |
    |======================== Event Notification Phase =====================|
    |                                           |             |             |
    |                                           |             |<---[Event]--|
    |                                           |<-[Transfer]-|             |
    |<--[Event Delivery]------------------------|             |             |
    |   {                                       |             |             |
    |     "from": "publisher@publisher.io",     |             |             |
    |     "to": "subscriber@example.com",       |             |             |
    |     "timestamp": 1710000010,              |             |             |
    |     "nonce": "evt-22222-uvwxy",           |             |             |
    |     "type": "event",                      |             |             |
    |     "payload": {                          |             |             |
    |       "event_type": "price_update",       |             |             |
    |       "subscription_id": "sub-12345",     |             |             |
    |       "data": {"symbol": "AAPL",          |             |             |
    |              "price": 150}                |             |             |
    |     },                                    |             |             |
    |     "signature": {...}                    |             |             |
    |   }                                       |             |             |

      Figure 8: Event Subscription Flow: Two-phase publish-subscribe
            with Subscribe Phase and Event Notification Phase







  Li, et al.              Expires 30 September 2026              [Page 55]


  Internet-Draft                     ATP                        March 2026


  Acknowledgments

     This protocol draws inspiration from multiple existing protocols and
     standards:

     *  DNS SVCB [RFC9460] - for service discovery

     *  HTTP/2 [RFC9110] - for multiplexing

     *  QUIC [RFC9000] - for low-latency transport

     *  TLS [RFC8446] - for secure transport

  Authors' Addresses

     Xiang Li
     Nankai University
     Tongyan Road
     Tianjin
     300350
     China
     Email: lixiang@nankai.edu.cn


     Lu Sun
     Nankai University
     Tongyan Road
     Tianjin
     300350
     China
     Email: sunlu25@mail.nankai.edu.cn


     Yuqi Qiu
     Nankai University
     Tongyan Road
     Tianjin
     300350
     China
     Email: qiuyuqi@mail.nankai.edu.cn


     Zuyao Xu
     Nankai University
     Tongyan Road
     Tianjin
     300350
     China



  Li, et al.              Expires 30 September 2026              [Page 56]


  Internet-Draft                     ATP                        March 2026


     Email: xuzuyao@mail.nankai.edu.cn


















































  Li, et al.              Expires 30 September 2026              [Page 57]


