# drafts

name: draft-xu-agentic-overlay-network-architecture
rev: 00
title: Architecture for Agentic Overlay Networks
time: 2026-05-18T05:51:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-19T05:51:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Agent discovery/reg", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698409+00:00
source: ietf
abstract:
  This document describes an architecture for agentic overlay networks.
     The architecture enables autonomous software agents, agent gateways,
     registries, discovery services, and enterprise service hubs to
     interoperate across administrative domains without replacing the
     existing Internet protocol stack.

     The architecture separates control-plane coordination from runtime
     agent interaction.  Management root nodes coordinate trust anchors,
     semantic taxonomies, and network-wide policy.  Registry service nodes
     onboard agents and publish signed capability metadata.  Discovery
     service nodes provide intent-driven candidate selection.  Enterprise
     service hubs adapt private systems and legacy interfaces into agent-
     compatible capabilities.  After discovery, runtime authentication and
     execution are performed by the invoking and target endpoints, which
     can be agents or gateways, using mutual verification; discovery and
     management nodes are not required in the runtime path.

     This document defines architectural roles, functional boundaries,
     metadata expectations, operational workflows, and security
     considerations for such networks.  It does not define a new transport
     protocol, a new URI scheme, or a mandatory discovery ranking
     algorithm.

full_text:
  Independent Submission                                             J. Xu
  Internet-Draft                                                     B. Li
  Intended status: Informational                                    R. Zhu
  Expires: 9 November 2026                                           CAICT
                                                                8 May 2026


                 Architecture for Agentic Overlay Networks
              draft-xu-agentic-overlay-network-architecture-00

  Abstract

     This document describes an architecture for agentic overlay networks.
     The architecture enables autonomous software agents, agent gateways,
     registries, discovery services, and enterprise service hubs to
     interoperate across administrative domains without replacing the
     existing Internet protocol stack.

     The architecture separates control-plane coordination from runtime
     agent interaction.  Management root nodes coordinate trust anchors,
     semantic taxonomies, and network-wide policy.  Registry service nodes
     onboard agents and publish signed capability metadata.  Discovery
     service nodes provide intent-driven candidate selection.  Enterprise
     service hubs adapt private systems and legacy interfaces into agent-
     compatible capabilities.  After discovery, runtime authentication and
     execution are performed by the invoking and target endpoints, which
     can be agents or gateways, using mutual verification; discovery and
     management nodes are not required in the runtime path.

     This document defines architectural roles, functional boundaries,
     metadata expectations, operational workflows, and security
     considerations for such networks.  It does not define a new transport
     protocol, a new URI scheme, or a mandatory discovery ranking
     algorithm.

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







  Xu, et al.               Expires 9 November 2026                [Page 1]


  Internet-Draft          Agentic Overlay Networks                May 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 9 November 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.4.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.5.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Architectural Principles  . . . . . . . . . . . . . . . . . .   6
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   7
     5.  Logical Layers  . . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Deployment Profiles . . . . . . . . . . . . . . . . . . . . .   8
     7.  Node Roles  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1.  Management Root Nodes . . . . . . . . . . . . . . . . . .   9
       7.2.  Registry Service Nodes  . . . . . . . . . . . . . . . . .  10
       7.3.  Discovery Service Nodes . . . . . . . . . . . . . . . . .  11
       7.4.  Agent Gateways  . . . . . . . . . . . . . . . . . . . . .  11
       7.5.  Enterprise Service Hubs . . . . . . . . . . . . . . . . .  12
     8.  Capability Metadata . . . . . . . . . . . . . . . . . . . . .  12
     9.  Operational Workflows . . . . . . . . . . . . . . . . . . . .  14
       9.1.  Agent Registration  . . . . . . . . . . . . . . . . . . .  14
       9.2.  Taxonomy Synchronization  . . . . . . . . . . . . . . . .  14
       9.3.  Agent Discovery . . . . . . . . . . . . . . . . . . . . .  15
       9.4.  Mutual Verification Runtime Interaction . . . . . . . . .  15
       9.5.  Trusted Metering  . . . . . . . . . . . . . . . . . . . .  16
     10. Interoperability Considerations . . . . . . . . . . . . . . .  17
       10.1.  Relationship to Existing Mechanisms  . . . . . . . . . .  17
       10.2.  Versioning and Extension . . . . . . . . . . . . . . . .  18
       10.3.  Failure Handling . . . . . . . . . . . . . . . . . . . .  18



  Xu, et al.               Expires 9 November 2026                [Page 2]


  Internet-Draft          Agentic Overlay Networks                May 2026


     11. Security Considerations . . . . . . . . . . . . . . . . . . .  19
     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  20
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     14. Implementation Status . . . . . . . . . . . . . . . . . . . .  21
     15. Implementation Checklist  . . . . . . . . . . . . . . . . . .  21
     16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       16.1.  Normative References . . . . . . . . . . . . . . . . . .  21
       16.2.  Informative References . . . . . . . . . . . . . . . . .  22
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     Autonomous software agents increasingly act as networked principals
     that can interpret intent, select tools, invoke remote services, and
     cooperate with other agents.  Existing Internet mechanisms remain
     essential for packet delivery and host reachability, but they do not
     by themselves provide the agent-specific functions needed for large-
     scale cross-domain collaboration: capability registration, semantic
     discovery, verifiable identity, policy coordination, protocol
     adaptation, and auditable commercial metering.

     An agentic overlay network adds these functions above the existing
     Internet.  It is an overlay because it preserves IP, DNS, TLS, HTTP,
     QUIC, and other deployed infrastructure where those mechanisms are
     suitable.  It is agentic because its primary subjects are autonomous
     agents and agent gateways rather than only hosts, users, or
     conventional web applications.

     The architecture in this document is intended for multi-operator
     environments.  It assumes that no single platform will control all
     agents, all discovery services, or all enterprise systems.  It
     therefore defines a separation between network-wide coordination and
     decentralized execution.  Coordination provides consistent semantics
     and trust anchors; execution remains between the selected runtime
     endpoints and does not require a central node in the data path.

  1.1.  Problem Statement

     Agent deployments are converging on several recurring interoperation
     problems:

     *  agents can expose useful capabilities, but there is no common
        architectural boundary between capability registration, semantic
        discovery, credential verification, and runtime invocation;






  Xu, et al.               Expires 9 November 2026                [Page 3]


  Internet-Draft          Agentic Overlay Networks                May 2026


     *  discovery systems often mix search, authorization, routing, and
        execution in one platform-specific service, which makes cross-
        domain deployment hard;

     *  existing host and service discovery mechanisms can identify hosts
        or endpoints, but they do not by themselves define agent
        capability semantics, freshness, proof of control, or agent-
        specific lifecycle state; and

     *  enterprises need a way to expose selected internal tools as agent
        capabilities without placing private systems or raw data in a
        global registry.

     This document addresses those problems by defining architectural
     roles and boundaries.  It deliberately stops short of defining a
     complete product ecosystem, commercial governance model, or mandatory
     implementation backend.

  1.2.  Applicability

     This architecture is applicable when multiple organizations need to
     publish, discover, verify, and invoke autonomous agents or agent
     gateways across administrative boundaries.  It is less useful for
     single-application systems where all agents, tools, credentials, and
     discovery functions are controlled by one implementation and do not
     need interoperable metadata or cross-domain trust.

  1.3.  Goals

     The architecture has the following goals:

     *  enable agents to register stable identities, endpoint references,
        supported protocols, and capability metadata;

     *  enable discovery services to find candidate agents based on user
        or agent intent, capability tags, operational status, and policy
        constraints;

     *  permit heterogeneous agent protocols and legacy APIs to be adapted
        without forcing all deployments onto one interaction protocol;

     *  support decentralized runtime authentication between interacting
        endpoints;

     *  keep management nodes out of the runtime traffic path;

     *  allow operator-neutral governance of trust anchors, revocation,
        taxonomy synchronization, and audit artifacts; and



  Xu, et al.               Expires 9 November 2026                [Page 4]


  Internet-Draft          Agentic Overlay Networks                May 2026


     *  provide a basis for interoperable metering and audit evidence
        without requiring every runtime interaction to be recorded on a
        public ledger.

  1.4.  Non-Goals

     This document does not define:

     *  a replacement for IP, DNS, TLS, HTTP, QUIC, or other deployed
        Internet protocols;

     *  a new agent URI scheme;

     *  a mandatory agent-to-agent invocation protocol;

     *  a single global discovery algorithm;

     *  a universal reputation system;

     *  an economic settlement protocol; or

     *  an application-specific workflow language.

     Companion specifications may define concrete message formats,
     transport bindings, identity credential profiles, discovery query
     schemas, or metering records that fit within this architecture.

  1.5.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Terminology

     Agent:  An autonomous or semi-autonomous software system that can
        receive an intent or request, perform planning or tool use, and
        return a result or state transition.

     Agent Gateway:  A domain-local component that adapts an internal API,
        tool, service, or legacy system into an agent-compatible
        interface.  An Agent Gateway is not a global discovery service
        unless it also implements that role.

     Agentic Overlay Network:  An overlay architecture that adds agent




  Xu, et al.               Expires 9 November 2026                [Page 5]


  Internet-Draft          Agentic Overlay Networks                May 2026


        identity, capability registration, semantic discovery, trust
        coordination, and operational metering above the existing
        Internet.

     Capability Metadata:  Structured and human-readable information
        describing what an agent can do, how it can be invoked, which
        protocols it supports, and which operational constraints apply.

     Discovery Service Node:  A node that accepts discovery requests and
        returns candidate agents.  It performs search and candidate
        ranking, but it is not in the runtime execution path between
        agents.

     Enterprise Service Hub:  A private-domain component that encapsulates
        enterprise data sources, tools, and internal APIs and exposes
        selected capabilities through an Agent Gateway or Registry Service
        Node.

     Management Root Node:  A control-plane node that coordinates trust
        anchors, credential issuer authorization, semantic taxonomy
        synchronization, revocation information, and network-wide policy
        artifacts.  It does not forward agent traffic.

     Registry Service Node:  A node that onboards agents or Agent
        Gateways, validates registration metadata, issues or requests
        identity credentials, and publishes capability metadata to
        authorized discovery infrastructure.

     Semantic Taxonomy:  A controlled hierarchy or graph of capability
        labels used to normalize registration and discovery across
        administrative domains.

     Trusted Metering Log:  A tamper-evident record or digest that
        summarizes an invocation, discovery, referral, or metering-
        relevant event without necessarily exposing private payload data.

  3.  Architectural Principles

     The architecture follows these principles:

     Control-plane coordination is limited.  Management Root Nodes provide
     coordination and trust bootstrapping.  They MUST NOT be required for
     ordinary runtime endpoint-to-endpoint message exchange.

     Execution is decentralized.  After discovery, the invoking agent or
     its gateway communicates directly with the target agent or target
     gateway.  The parties perform mutual verification without relying on
     the Discovery Service Node as a trusted intermediary.



  Xu, et al.               Expires 9 November 2026                [Page 6]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Metadata and payloads are separated.  Registries and discovery
     services operate on capability metadata, endpoint references,
     operational status, and policy hints.  They SHOULD NOT require access
     to private task payloads.

     Protocol adaptation is local.  Heterogeneous enterprise systems and
     agent protocols are adapted by Agent Gateways and Enterprise Service
     Hubs close to the systems they protect.

     Semantic coordination is explicit.  Capability labels and taxonomies
     SHOULD be synchronized through controlled processes so that discovery
     results have consistent meaning across domains.

  4.  Architecture Overview

     An agentic overlay network is composed of a coordination plane, a
     service exchange plane, and a runtime interaction plane.

               +-------------------------------+
               |     Management Root Nodes     |
               | trust, policy, taxonomy       |
               +---------------+---------------+
                               |
                   control synchronization
                               |
            +------------------+------------------+
            |                                     |
     +------+-----------+                 +-------+----------+
     | Registry Service |                 | Discovery Service|
     | Nodes            |                 | Nodes            |
     | onboarding and   |                 | semantic search  |
     | capability data  |                 | candidate lists  |
     +------+-----------+                 +-------+----------+
            |                                     |
            | registration                        | discovery
            |                                     |
     +------+--------------+              +-------+----------+
     | Agents, Gateways,   |<------------>| Invoking Agents |
     | Enterprise Hubs     | execution    | and Users       |
     +---------------------+              +-----------------+

     The key architectural boundary is that discovery and execution are
     separate.  A Discovery Service Node returns candidates and metadata.
     The invoking party then verifies identity, policy, credentials, and
     endpoint information before using any candidate.






  Xu, et al.               Expires 9 November 2026                [Page 7]


  Internet-Draft          Agentic Overlay Networks                May 2026


  5.  Logical Layers

     The architecture can be understood as four logical layers.  These
     layers are not wire-protocol layers; they are functional groupings
     used to assign responsibilities.

     +=================+=============================+===================+
     | Layer           | Function                    | Typical           |
     |                 |                             | Components        |
     +=================+=============================+===================+
     | Underlay        | Existing network transport, | IP, DNS, TLS,     |
     | Support         | compute, storage, and       | HTTP, QUIC, edge  |
     |                 | optional deterministic      | compute           |
     |                 | networking support          |                   |
     +-----------------+-----------------------------+-------------------+
     | Interconnection | Registration, addressing    | Registry Service  |
     |                 | references, endpoint        | Nodes, Discovery  |
     |                 | discovery, and protocol     | Service Nodes,    |
     |                 | adaptation                  | Agent Gateways    |
     +-----------------+-----------------------------+-------------------+
     | Collaboration   | Identity, trust, taxonomy   | Management Root   |
     |                 | synchronization, policy     | Nodes,            |
     |                 | coordination, metering, and | credential        |
     |                 | audit                       | issuers, audit    |
     |                 |                             | services          |
     +-----------------+-----------------------------+-------------------+
     | Application     | User-facing and agent-      | Agents,           |
     |                 | facing services that        | applications,     |
     |                 | express or satisfy intents  | enterprise        |
     |                 |                             | services          |
     +-----------------+-----------------------------+-------------------+

                                    Table 1

     The architecture intentionally keeps most agent-specific semantics
     above the existing transport layer.  Underlay technologies MAY
     provide quality, latency, or reliability enhancements, but they are
     not required to understand agent capability metadata.

  6.  Deployment Profiles

     Deployments can adopt this architecture incrementally.  This document
     defines four non-exclusive deployment profiles to make that
     progression explicit.







  Xu, et al.               Expires 9 November 2026                [Page 8]


  Internet-Draft          Agentic Overlay Networks                May 2026


       +=========+=============+======================================+
       | Profile | Name        | Description                          |
       +=========+=============+======================================+
       | P0      | Local       | A single domain exposes local tools  |
       |         | Gateway     | through Agent Gateways.  No cross-   |
       |         |             | domain registry is required.         |
       +---------+-------------+--------------------------------------+
       | P1      | Domain      | A domain operates a Registry Service |
       |         | Registry    | Node and publishes signed capability |
       |         |             | metadata for local agents.           |
       +---------+-------------+--------------------------------------+
       | P2      | Federated   | Multiple domains exchange catalog    |
       |         | Discovery   | summaries and allow authorized       |
       |         |             | Discovery Service Nodes to query or  |
       |         |             | synchronize metadata.                |
       +---------+-------------+--------------------------------------+
       | P3      | Coordinated | Management Root Nodes coordinate     |
       |         | Overlay     | trust anchors, taxonomy versions,    |
       |         |             | revocation state, and audit digests  |
       |         |             | across multiple operators.           |
       +---------+-------------+--------------------------------------+

                                   Table 2

     Implementations SHOULD document which deployment profile they
     implement.  Clients SHOULD degrade gracefully when interacting with a
     deployment that supports only a lower profile.  For example, a P0
     deployment can still expose a useful agent endpoint, but a client
     cannot assume global taxonomy synchronization or cross-operator
     revocation checks.

  7.  Node Roles

  7.1.  Management Root Nodes

     Management Root Nodes are control-plane coordination nodes.  A
     deployment MAY use one Management Root Node or a federation of such
     nodes operated by neutral or authorized organizations.

     Management Root Nodes are responsible for:

     *  authorizing Registry Service Nodes and Discovery Service Nodes;

     *  publishing credential issuer metadata and revocation information;

     *  coordinating semantic taxonomy versions;

     *  publishing policy digests or governance artifacts;



  Xu, et al.               Expires 9 November 2026                [Page 9]


  Internet-Draft          Agentic Overlay Networks                May 2026


     *  receiving compact catalog summaries or audit digests; and

     *  distributing synchronized control-plane state to authorized
        service nodes.

     Management Root Nodes MUST NOT be required for:

     *  runtime request forwarding;

     *  target agent selection for an individual user request;

     *  access to private invocation payloads;

     *  direct enforcement of endpoint-level authorization decisions; or

     *  maintaining real-time fine-grained search indices for all agents.

     This boundary reduces central bottlenecks and limits the operational
     power of the control plane.

  7.2.  Registry Service Nodes

     Registry Service Nodes are supply-side onboarding hubs.  They receive
     agent registrations, validate metadata, and publish capability
     records to discovery infrastructure.

     A Registry Service Node SHOULD perform the following functions:

     *  validate that mandatory registration fields are present;

     *  verify endpoint reachability where applicable;

     *  validate imported OpenAPI, tool, or agent-card descriptions when
        supplied;

     *  assign or verify a stable agent identifier;

     *  issue, request, or bind credentials that associate the agent
        identifier with capability metadata;

     *  monitor lifecycle events such as update, suspension, deletion, and
        heartbeat status; and

     *  synchronize catalog summaries with authorized Management Root
        Nodes or Discovery Service Nodes.






  Xu, et al.               Expires 9 November 2026               [Page 10]


  Internet-Draft          Agentic Overlay Networks                May 2026


     A Registry Service Node MUST preserve the distinction between
     asserted capabilities and verified capabilities.  If it cannot verify
     a claim, it MUST NOT mark that claim as verified.

     Registrations SHOULD be soft state.  A Registry Service Node SHOULD
     assign an expiration time to each active registration and require
     refresh before expiration.  If an agent fails to refresh, the
     Registry Service Node SHOULD mark the registration inactive or remove
     it from discovery results.

  7.3.  Discovery Service Nodes

     Discovery Service Nodes are demand-side search and candidate
     selection nodes.  They accept discovery requests and return candidate
     agents with metadata that allows the requester to make its own trust
     decision.

     A Discovery Service Node SHOULD support:

     *  lookup by stable identifier;

     *  discovery by capability tags;

     *  discovery by natural-language intent;

     *  filtering by protocol support, domain, policy, trust level, or
        operational status;

     *  ranking that combines semantic relevance with operational and
        policy signals; and

     *  explainable result metadata sufficient for clients to understand
        why a candidate was returned.

     A Discovery Service Node MUST treat its own results as
     recommendations, not as authorization decisions.  It MUST NOT require
     target agents to route runtime traffic through it.

  7.4.  Agent Gateways

     Agent Gateways adapt local systems into agent-compatible interfaces.
     They are often deployed inside enterprises, clouds, or application
     platforms.

     An Agent Gateway MAY:

     *  translate between agent protocols and internal REST, RPC, message
        bus, or tool interfaces;



  Xu, et al.               Expires 9 November 2026               [Page 11]


  Internet-Draft          Agentic Overlay Networks                May 2026


     *  enforce local policy;

     *  perform local authentication and authorization;

     *  redact or transform private data before exposing a capability;

     *  maintain local logs required by the enterprise domain; and

     *  present a standardized capability record to a Registry Service
        Node.

     Agent Gateways SHOULD NOT be assumed to be globally trusted.  Remote
     agents SHOULD verify the gateway's credentials and policy claims
     before invocation.

  7.5.  Enterprise Service Hubs

     Enterprise Service Hubs are private-domain integration components.
     They are used when an organization wants to expose selected internal
     capabilities while keeping raw systems and data inside a protected
     environment.

     An Enterprise Service Hub SHOULD expose only the minimum metadata
     needed for discovery.  Sensitive schemas, raw datasets, internal
     credentials, and private business logic SHOULD remain local unless
     explicitly authorized by local policy.

  8.  Capability Metadata

     Capability metadata is the primary object exchanged between
     registration and discovery functions.  A concrete serialization is
     out of scope for this document, but a registration profile SHOULD
     include the fields in Table 1.


















  Xu, et al.               Expires 9 November 2026               [Page 12]


  Internet-Draft          Agentic Overlay Networks                May 2026


      +=================+=============+================================+
      | Field           | Requirement | Description                    |
      +=================+=============+================================+
      | agent_id        | MUST        | Stable identifier for the      |
      |                 |             | agent or gateway               |
      +-----------------+-------------+--------------------------------+
      | name            | MUST        | Human-readable name            |
      +-----------------+-------------+--------------------------------+
      | description     | MUST        | Natural-language capability    |
      |                 |             | description                    |
      +-----------------+-------------+--------------------------------+
      | capability_tags | SHOULD      | Normalized tags selected from  |
      |                 |             | a semantic taxonomy            |
      +-----------------+-------------+--------------------------------+
      | endpoints       | MUST        | Endpoint references or         |
      |                 |             | protocol-specific contact data |
      +-----------------+-------------+--------------------------------+
      | protocols       | MUST        | Supported invocation protocols |
      |                 |             | or transport bindings          |
      +-----------------+-------------+--------------------------------+
      | auth_methods    | SHOULD      | Supported authentication       |
      |                 |             | methods                        |
      +-----------------+-------------+--------------------------------+
      | credential_refs | SHOULD      | References to credentials or   |
      |                 |             | attestations                   |
      +-----------------+-------------+--------------------------------+
      | status          | SHOULD      | Operational status such as     |
      |                 |             | active, suspended, deprecated  |
      +-----------------+-------------+--------------------------------+
      | freshness       | SHOULD      | Timestamp, sequence number, or |
      |                 |             | version marker                 |
      +-----------------+-------------+--------------------------------+
      | ttl             | MAY         | Suggested registration         |
      |                 |             | lifetime in seconds            |
      +-----------------+-------------+--------------------------------+
      | constraints     | MAY         | Rate limits, regions, data     |
      |                 |             | handling limits, cost hints    |
      +-----------------+-------------+--------------------------------+
      | examples        | MAY         | Example tasks or invocation    |
      |                 |             | patterns                       |
      +-----------------+-------------+--------------------------------+

                                   Table 3

     Capability metadata SHOULD be signed by the publisher or by a
     Registry Service Node.  Consumers MUST validate signatures and
     freshness before relying on the metadata for security-sensitive
     decisions.



  Xu, et al.               Expires 9 November 2026               [Page 13]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Implementations MUST ignore unrecognized metadata fields unless a
     local policy requires strict validation.  This enables extension
     fields, protocol-specific bindings, and future capability descriptors
     to coexist with the base architecture.

  9.  Operational Workflows

  9.1.  Agent Registration

     Agent registration brings a new agent or gateway into the overlay.

     1.  The agent operator submits capability metadata to a Registry
         Service Node.

     2.  The Registry Service Node validates mandatory fields and endpoint
         reachability.

     3.  The Registry Service Node verifies or assigns the agent
         identifier.

     4.  The Registry Service Node binds the identifier to capability
         metadata using a credential, signed record, or equivalent
         mechanism.

     5.  The Registry Service Node stores the local catalog entry.

     6.  The Registry Service Node synchronizes a catalog summary or
         signed record to authorized discovery infrastructure.

     Registrations SHOULD support incremental updates.  A metadata update
     MUST carry a freshness indicator that allows receivers to reject
     stale records.

     An explicit deregistration request SHOULD be supported.
     Deregistration MUST be authenticated with the same or stronger proof
     of control as registration.  After deregistration, Registry Service
     Nodes SHOULD either remove the record from discovery or return it
     only as an inactive historical record according to local retention
     policy.

  9.2.  Taxonomy Synchronization

     Capability labels are useful only if different parties interpret them
     in compatible ways.  Management Root Nodes or authorized taxonomy
     services SHOULD publish versioned semantic taxonomies.

     Taxonomy updates SHOULD include:




  Xu, et al.               Expires 9 November 2026               [Page 14]


  Internet-Draft          Agentic Overlay Networks                May 2026


     *  a taxonomy identifier;

     *  a version number or timestamp;

     *  label identifiers;

     *  parent-child or graph relationships;

     *  deprecation markers;

     *  mappings to related labels where available; and

     *  a signature from the taxonomy authority.

     Registry Service Nodes SHOULD validate submitted capability tags
     against a supported taxonomy version.  Discovery Service Nodes SHOULD
     expose which taxonomy versions were used when producing results.

  9.3.  Agent Discovery

     Agent discovery returns candidate agents for a requested intent or
     constraint set.

     1.  The requester sends a discovery request to a Discovery Service
         Node.

     2.  The Discovery Service Node normalizes the request against
         supported taxonomies and policies.

     3.  The Discovery Service Node searches local or synchronized
         catalogs.

     4.  The Discovery Service Node ranks candidates using implementation-
         specific relevance and policy signals.

     5.  The Discovery Service Node returns candidate metadata, credential
         references, endpoint references, and matching evidence.

     6.  The requester validates the returned metadata before selecting a
         target.

     Discovery results MUST NOT be treated as proof that an agent is safe,
     authorized, or suitable for a particular regulated use.

  9.4.  Mutual Verification Runtime Interaction

     After selecting a candidate, the invoking party establishes trust
     directly with the target endpoint, which can be an agent or gateway.



  Xu, et al.               Expires 9 November 2026               [Page 15]


  Internet-Draft          Agentic Overlay Networks                May 2026


     1.  The invoking party resolves or retrieves the target's credential
         material.

     2.  Both parties validate each other's credentials, signatures,
         revocation status, and policy constraints.

     3.  The invoking party establishes a secure channel using the
         selected protocol.

     4.  The target enforces local authorization policy.

     5.  The parties exchange runtime requests and responses directly.

     6.  Each party records local audit or metering evidence according to
         policy.

     Discovery Service Nodes SHOULD NOT be in this execution path unless
     the deployment explicitly uses them as application gateways.  If a
     Discovery Service Node also acts as a gateway, the two roles MUST be
     distinguishable in metadata and policy.

  9.5.  Trusted Metering

     Commercial deployments may require metering for billing, audit,
     reconciliation, or contribution tracing.  The architecture supports
     metering without requiring every interaction payload to be globally
     visible.

     A metering record SHOULD include:

     *  a record identifier;

     *  identities of the metering parties or pseudonymous references;

     *  timestamp or time window;

     *  invocation or discovery event type;

     *  service or capability identifier;

     *  usage counters or metering-relevant units;

     *  policy or contract reference;

     *  privacy-preserving digest of evidence where applicable; and

     *  signature by the recording party.




  Xu, et al.               Expires 9 November 2026               [Page 16]


  Internet-Draft          Agentic Overlay Networks                May 2026


     High-frequency private interaction data SHOULD remain off-chain or
     local.  Deployments MAY publish compact digests, Merkle roots,
     revocation events, or metering commitments to a distributed ledger
     when tamper-evidence or cross-operator reconciliation is required.

  10.  Interoperability Considerations

     The architecture is protocol-neutral.  It can coexist with agent
     cards, well-known metadata files, DNS-based discovery hints, MCP-
     style tool interfaces, A2A-style messaging, HTTP APIs, gRPC services,
     local process bindings, and future agent protocols.

     Interoperability profiles SHOULD define:

     *  how an agent identifier is represented;

     *  how capability metadata is serialized;

     *  how signatures and credential references are encoded;

     *  how endpoints and protocols are selected;

     *  how taxonomy labels are named and versioned;

     *  how discovery queries and results are encoded; and

     *  how status, revocation, and freshness are checked.

     Profiles SHOULD avoid requiring one specific machine-learning model
     or ranking algorithm for discovery.  Discovery algorithms affect
     quality and performance, but the interoperable surface is the query,
     metadata, result, and validation contract.

  10.1.  Relationship to Existing Mechanisms

     DNS and well-known URIs [RFC8615] can provide bootstrap hints, domain
     control signals, or descriptor locations.  They SHOULD NOT be
     overloaded with high-frequency, large, or privacy-sensitive agent
     metadata.

     OAuth 2.0, mutual TLS, signed application messages, public-key
     credentials, or other credential systems can be used as
     authentication and authorization substrates.  This architecture does
     not require one credential technology, but deployments MUST make
     credential semantics and revocation behavior explicit.






  Xu, et al.               Expires 9 November 2026               [Page 17]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Deployments that use TLS SHOULD follow the security properties of the
     TLS version they negotiate; TLS 1.3 is specified in [RFC8446].
     Deployments that use OAuth-style bearer authorization SHOULD account
     for token replay and audience restriction, including the
     considerations in OAuth 2.0 [RFC6749] and OAuth 2.0 Bearer Token
     Usage [RFC6750].

     Agent interaction protocols such as tool invocation protocols,
     message-based agent protocols, or local process protocols remain
     above or beside this architecture.  The overlay discovers and
     verifies candidates; the selected interaction protocol carries the
     task.

  10.2.  Versioning and Extension

     Deployment profiles, metadata objects, taxonomy versions, and
     credential profiles SHOULD carry explicit version identifiers.
     Implementations MUST NOT assume that all nodes in an overlay support
     the same profile version.

     Unknown metadata fields MUST be ignored unless strict validation is
     required by local policy.  Unknown profile identifiers, taxonomy
     versions, or credential profiles SHOULD cause graceful degradation
     rather than silent acceptance.

     Private extensions SHOULD use collision-resistant names, such as URIs
     or reverse-DNS names.  Extensions that affect interoperability across
     independent implementations SHOULD be documented in a stable
     specification.

  10.3.  Failure Handling

     Implementations SHOULD distinguish at least the following failure
     conditions:

















  Xu, et al.               Expires 9 November 2026               [Page 18]


  Internet-Draft          Agentic Overlay Networks                May 2026


        +=======================+=====================================+
        | Condition             | Typical Handling                    |
        +=======================+=====================================+
        | stale_metadata        | Reject for security-sensitive use   |
        |                       | or request refresh                  |
        +-----------------------+-------------------------------------+
        | revoked_credential    | Do not invoke; report revocation to |
        |                       | the user or policy engine           |
        +-----------------------+-------------------------------------+
        | taxonomy_mismatch     | Fall back to text search or request |
        |                       | a supported taxonomy version        |
        +-----------------------+-------------------------------------+
        | discovery_unavailable | Use cached signed metadata if local |
        |                       | policy permits                      |
        +-----------------------+-------------------------------------+
        | endpoint_unreachable  | Try alternate binding or mark       |
        |                       | candidate degraded                  |
        +-----------------------+-------------------------------------+
        | policy_denied         | Do not invoke even if semantic      |
        |                       | match is high                       |
        +-----------------------+-------------------------------------+

                                    Table 4

     Discovery clients SHOULD surface these conditions separately.
     Collapsing all failures into "not found" can hide security problems
     and make operational debugging difficult.

  11.  Security Considerations

     Agentic overlay networks introduce risks beyond ordinary service
     discovery.  Agents can initiate actions, combine tools, and operate
     across administrative domains.  Implementations MUST treat discovery
     data as untrusted input.

     Identity spoofing:  Attackers may register names or descriptions
        similar to trusted agents.  Registries SHOULD require proof of
        control over identifiers and SHOULD distinguish unverified claims
        from verified credentials.

     Capability exaggeration:  Agents may claim capabilities they do not
        possess.  Registries SHOULD mark whether capabilities are self-
        asserted, registry-validated, or attested by a third party.

     Stale metadata:  Discovery results may include outdated endpoints,
        revoked credentials, or deprecated capabilities.  Metadata MUST
        include freshness information.  Clients MUST check revocation and
        expiration before invocation.



  Xu, et al.               Expires 9 November 2026               [Page 19]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Discovery poisoning:  Malicious operators may attempt to bias ranking
        or inject misleading metadata.  Discovery Service Nodes SHOULD
        apply abuse detection, provenance checks, and rate limits.

     Centralization risk:  Management Root Nodes could become governance
        bottlenecks.  Deployments SHOULD scope their authority narrowly
        and publish auditable policy artifacts.

     Payload exposure:  Registries and discovery services SHOULD NOT
        require private invocation payloads.  Enterprise Service Hubs
        SHOULD redact sensitive metadata and keep raw data local unless
        policy permits disclosure.

     Confused deputy attacks:  An agent may be tricked into invoking
        another agent using credentials or authority outside the user's
        intent.  Runtime agents SHOULD use scoped, task-specific
        credentials and SHOULD bind authorization to the requested action.

     Downgrade attacks:  An attacker may try to force a client from a
        stronger deployment profile to a weaker one, for example by
        suppressing credential references or taxonomy versions.  Clients
        SHOULD enforce minimum acceptable profile and credential
        requirements for sensitive tasks.

     Registry compromise:  A compromised Registry Service Node can publish
        false metadata for many agents.  Management Root Nodes or
        governance services SHOULD support rapid revocation of registry
        credentials and distribution of registry compromise indicators.

     Metering privacy:  Metering records can reveal business relationships
        or user behavior.  Deployments SHOULD minimize metering data,
        aggregate where possible, and use privacy-preserving digests when
        detailed evidence is not required.

  12.  Privacy Considerations

     Capability metadata can reveal sensitive information about enterprise
     systems, available tools, regions, customers, or business processes.
     Registrations SHOULD disclose only what is necessary for discovery
     and safe invocation.

     Deployments SHOULD evaluate privacy risks using the general guidance
     for Internet protocols in [RFC6973].

     Discovery requests can reveal user intent.  Discovery Service Nodes
     SHOULD provide transport confidentiality, access control, retention
     limits, and privacy-preserving logging options.




  Xu, et al.               Expires 9 November 2026               [Page 20]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Enterprise Service Hubs SHOULD keep private data, internal schemas,
     and credentials within the local domain unless a specific policy
     authorizes external disclosure.

  13.  IANA Considerations

     This document does not create new registries, media types, URI
     schemes, HTTP fields, or protocol parameter values.  It makes no IANA
     requests.

  14.  Implementation Status

     This section is to be removed before publication as an RFC.

     Prototype deployments are expected to use existing web transports,
     signed JSON metadata, public-key credentials or equivalent signed
     credentials, local vector or keyword search in Discovery Service
     Nodes, and enterprise gateways for protocol adaptation.

  15.  Implementation Checklist

     An implementation of this architecture can be reviewed against the
     following checklist:

     *  which deployment profile is supported;

     *  how capability metadata is signed and refreshed;

     *  how unknown metadata fields are handled;

     *  how taxonomy versions are negotiated or rejected;

     *  how registry compromise and credential revocation are distributed;

     *  how discovery results are separated from authorization decisions;

     *  how endpoint reachability and stale metadata failures are
        reported; and

     *  what information is retained in metering or audit logs.

  16.  References

  16.1.  Normative References







  Xu, et al.               Expires 9 November 2026               [Page 21]


  Internet-Draft          Agentic Overlay Networks                May 2026


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

  16.2.  Informative References

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6750>.

     [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
                Morris, J., Hansen, M., and R. Smith, "Privacy
                Considerations for Internet Protocols", RFC 6973,
                DOI 10.17487/RFC6973, July 2013,
                <https://www.rfc-editor.org/rfc/rfc6973>.

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

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

  Appendix A.  Acknowledgements

     The authors thank participants in discussions on agent networking,
     agent discovery, and cross-domain agent interoperability.

  Authors' Addresses

     Jinliang Xu
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: xujinliang@caict.ac.cn



  Xu, et al.               Expires 9 November 2026               [Page 22]


  Internet-Draft          Agentic Overlay Networks                May 2026


     Bingqi Li
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: libingqi@caict.ac.cn


     Runkai Zhu
     CAICT
     No. 52, Huayuan North Road
     Beijing
     Haidian District, 100191
     China
     Email: zhurunkai@caict.ac.cn



































  Xu, et al.               Expires 9 November 2026               [Page 23]


name: draft-yu-ai-agent-ipv6-networking-considerations
rev: 00
title: IPv6 Networking Considerations for AI Agent Communication
time: 2026-05-20T10:02:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-21T10:02:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698413+00:00
source: ietf
abstract:
  AI agents are increasingly expected to communicate across platforms,
     organizations, clouds, edge environments, and administrative domains.
     Ongoing work on agent protocols has started to address agent
     description, discovery, authentication, authorization, invocation,
     delegation, and collaboration.  These functions are essential, but
     they generally treat the IP network as a transparent connectivity
     substrate.

     This document discusses IPv6 networking considerations for AI agent
     communication.  It focuses on networking support after an agent has
     been discovered by an application-layer or control-plane mechanism.
     It discusses how stable Agent identifiers can be associated with IPv6
     locators or Agent Gateways, how agent communication requirements can
     be mapped to IPv6 or SRv6 forwarding policies, how limited agent-
     related network context can be carried within controlled deployment
     environments, and how network-layer telemetry can complement
     application-layer audit records.

     This document does not define a new agent discovery protocol, a new
     application-layer agent collaboration protocol, or a new
     authentication or authorization mechanism.  It is intended to be
     complementary to existing and emerging agent discovery, identity,
     authorization, auditing, and collaboration mechanisms.

full_text:
  Internet Engineering Task Force                                    H. Yu
  Internet-Draft                 China Internet Network Information Center
  Intended status: Informational                               20 May 2026
  Expires: 21 November 2026


         IPv6 Networking Considerations for AI Agent Communication
            draft-yu-ai-agent-ipv6-networking-considerations-00

  Abstract

     AI agents are increasingly expected to communicate across platforms,
     organizations, clouds, edge environments, and administrative domains.
     Ongoing work on agent protocols has started to address agent
     description, discovery, authentication, authorization, invocation,
     delegation, and collaboration.  These functions are essential, but
     they generally treat the IP network as a transparent connectivity
     substrate.

     This document discusses IPv6 networking considerations for AI agent
     communication.  It focuses on networking support after an agent has
     been discovered by an application-layer or control-plane mechanism.
     It discusses how stable Agent identifiers can be associated with IPv6
     locators or Agent Gateways, how agent communication requirements can
     be mapped to IPv6 or SRv6 forwarding policies, how limited agent-
     related network context can be carried within controlled deployment
     environments, and how network-layer telemetry can complement
     application-layer audit records.

     This document does not define a new agent discovery protocol, a new
     application-layer agent collaboration protocol, or a new
     authentication or authorization mechanism.  It is intended to be
     complementary to existing and emerging agent discovery, identity,
     authorization, auditing, and collaboration mechanisms.

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







  Yu                      Expires 21 November 2026                [Page 1]


  Internet-Draft                AI Agent IPv6                     May 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 21 November 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.  Conventions Used in This Document . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   4
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Separation of Agent Identity and Network Location . . . .   6
       5.2.  Network Reachability After Discovery  . . . . . . . . . .   6
       5.3.  Path Control and Service Chaining . . . . . . . . . . . .   6
       5.4.  Network-Layer Evidence for Audit  . . . . . . . . . . . .   7
     6.  Design Requirements . . . . . . . . . . . . . . . . . . . . .   7
     7.  Networking Considerations Overview  . . . . . . . . . . . . .   8
       7.1.  Agent Discovery Function  . . . . . . . . . . . . . . . .   8
       7.2.  Agent Identity and Binding Function . . . . . . . . . . .   8
       7.3.  Agent Locator Resolution Function . . . . . . . . . . . .   9
       7.4.  Network Policy Function . . . . . . . . . . . . . . . . .   9
       7.5.  Forwarding and Telemetry Function . . . . . . . . . . . .   9
     8.  Agent-ID to IPv6 Locator Binding  . . . . . . . . . . . . . .   9
     9.  Use of IPv6 and SRv6  . . . . . . . . . . . . . . . . . . . .  10
     10. Agent Context Carriage  . . . . . . . . . . . . . . . . . . .  10
       10.1.  Destination Options  . . . . . . . . . . . . . . . . . .  11
       10.2.  SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . .  11
       10.3.  Fallback Mechanisms  . . . . . . . . . . . . . . . . . .  12
     11. Semantic Routing Considerations . . . . . . . . . . . . . . .  12
     12. Network Telemetry and Audit Support . . . . . . . . . . . . .  12
     13. Deployment Models . . . . . . . . . . . . . . . . . . . . . .  13



  Yu                      Expires 21 November 2026                [Page 2]


  Internet-Draft                AI Agent IPv6                     May 2026


       13.1.  Endpoint and Gateway Mode  . . . . . . . . . . . . . . .  13
       13.2.  Controlled-Domain Mode . . . . . . . . . . . . . . . . .  13
       13.3.  SRv6-Domain Mode . . . . . . . . . . . . . . . . . . . .  13
     14. Relationship to Existing Work . . . . . . . . . . . . . . . .  14
     15. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     16. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  15
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     18. Normative References  . . . . . . . . . . . . . . . . . . . .  16
     19. Informative References  . . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Conventions Used in This Document

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Introduction

     AI agents are moving from isolated applications toward large-scale,
     cross-domain collaboration.  An agent may invoke tools, communicate
     with other agents, migrate across cloud or edge nodes, act on behalf
     of a user or organization, and interact through multiple application-
     layer protocols.  In such environments, agent communication is not
     only an application-layer issue.  It also raises questions of network
     reachability, locator binding, path selection, traffic isolation,
     observability, and operational governance.

     Several ongoing discussions and individual Internet-Drafts explore
     agent registration, discovery, identity, capability advertisement,
     authorization, delegation, auditing, and invocation.  Such work is
     important for enabling agents to describe themselves, discover each
     other, and select suitable application-layer interaction mechanisms.
     However, after an agent has been discovered and an application-layer
     protocol has been selected, the resulting communication still needs
     to be carried by the underlying network.

     In large-scale deployments, the following questions remain relevant
     at the networking layer:

     *  How is a stable Agent identifier associated with a changing IPv6
        locator or Agent Gateway?

     *  How can a discovered agent endpoint be connected to IPv6
        reachability and network policy enforcement?




  Yu                      Expires 21 November 2026                [Page 3]


  Internet-Draft                AI Agent IPv6                     May 2026


     *  How can different agent communication flows be steered through
        different network paths or service chains?

     *  How can agent communication be isolated, observed, and audited at
        the network layer?

     *  How can application-level intent be translated into structured and
        enforceable IPv6 or SRv6 policies without requiring ordinary
        routers to understand agent semantics?

     This document discusses IPv6 networking considerations for AI agent
     communication.  It uses IPv6 as the basic addressing and forwarding
     substrate.  In deployments where Segment Routing over IPv6 is
     available, SRv6 may be used to support policy-based path steering,
     service function chaining, and domain-local network programming.  The
     IPv6 Segment Routing Header (SRH) is defined in [RFC8754], and SRv6
     Network Programming is defined in [RFC8986].

     This document does not assume that ordinary Internet routers
     understand agent identities, task semantics, natural language intent,
     or application payloads.  Any processing of agent-related network
     context is limited to explicitly participating endpoints, Agent
     Gateways, policy enforcement points, or SRv6-capable nodes within
     controlled domains.

  3.  Scope and Non-Goals

     This document focuses on:

     *  the separation of stable Agent identifiers from IPv6 locators;

     *  the binding of Agent identifiers to IPv6 locators or Agent
        Gateways;

     *  IPv6 reachability for discovered agents;

     *  mapping agent communication requirements to IPv6 or SRv6 policies;

     *  limited carriage of agent-related network context in controlled
        deployments;

     *  network-layer telemetry that can complement application-layer
        audit records;

     *  operational considerations for deployment in endpoints, Agent
        Gateways, enterprise networks, data centers, operator networks,
        and SRv6 domains.




  Yu                      Expires 21 November 2026                [Page 4]


  Internet-Draft                AI Agent IPv6                     May 2026


     This document does not define:

     *  a new agent discovery protocol;

     *  a new application-layer agent collaboration protocol;

     *  a new authentication, authorization, or delegation protocol;

     *  a new replacement for A2A, MCP, ARDP, Agent Directory, OAuth,
        OIDC, DID, SD-JWT, WIMSE, RATS, SCITT, or OpenTelemetry
        mechanisms;

     *  a general-purpose semantic routing protocol;

     *  a requirement that public Internet routers process agent-specific
        metadata;

     *  a requirement that IPv6 extension headers be usable across the
        public Internet.

  4.  Terminology

     Agent:
        A software entity that can perceive context, reason, plan, invoke
        tools, communicate with other agents, and perform tasks on behalf
        of a user, organization, or system.

     Agent Identifier:
        A stable identifier used to identify an agent independently from
        its current network location.  This document uses the term Agent-
        ID when referring to such an identifier in examples.

     IPv6 Locator:
        An IPv6 address or prefix used to reach an agent instance, an
        Agent Gateway, or another network element representing the agent.

     Agent Gateway:
        A network or application gateway that represents one or more
        agents and provides controlled access, address mapping, policy
        enforcement, protocol adaptation, or telemetry collection.

     Agent Context:
        A limited set of structured metadata related to agent
        communication, such as an Agent-ID reference, Session-ID, Trace-
        ID, Policy-ID, Trust-Level, or Audit-Flag.  Agent Context in this
        document does not include natural language prompts, user private
        data, or application payloads.




  Yu                      Expires 21 November 2026                [Page 5]


  Internet-Draft                AI Agent IPv6                     May 2026


     Agent Domain:
        An administrative or operational domain that explicitly supports
        agent-related networking functions, such as Agent-ID to locator
        binding, Agent Gateway enforcement, SRv6 policy selection, or
        network-layer telemetry collection.

     Agent-ID Registration Data Service:
        A trusted query mechanism that can provide registration data for
        an Agent-ID, such as the responsible entity, lifecycle state,
        associated domains, IPv6 locators, Agent Gateways, public key
        references, and revocation status.  An RDAP-based profile is one
        possible realization, but is not specified by this document.

  5.  Problem Statement

     Agent discovery and collaboration mechanisms can help an application
     identify an agent, understand its capabilities, and select an
     application-layer protocol for interaction.  However, those
     mechanisms do not by themselves define how the resulting traffic
     should be handled by the IPv6 network.  This document identifies four
     networking problems that become important in large-scale and cross-
     domain deployments.

  5.1.  Separation of Agent Identity and Network Location

     An agent may be replicated, migrated, hidden behind a gateway, or
     deployed across multiple network domains.  Its identity should remain
     stable, while the IPv6 locator used to reach it may change.  A method
     is needed to associate Agent identifiers with IPv6 locators or Agent
     Gateways in a verifiable and operationally manageable way.

  5.2.  Network Reachability After Discovery

     An agent discovery mechanism may return an endpoint, but that result
     does not necessarily prove that the endpoint is reachable, authorized
     to represent the Agent-ID, or suitable for a specific network policy.
     Agent communication therefore needs a way to connect discovery
     results with IPv6 reachability, locator selection, and policy
     enforcement.

  5.3.  Path Control and Service Chaining

     Different agent communication flows may have different network
     requirements.  Some flows may require low latency, some may require
     security inspection, some may require a compliance-aware path, and
     some may require audit collection.  A method is needed to map
     structured communication requirements into IPv6 or SRv6 forwarding
     behavior without requiring the data plane to interpret application



  Yu                      Expires 21 November 2026                [Page 6]


  Internet-Draft                AI Agent IPv6                     May 2026


     semantics.

  5.4.  Network-Layer Evidence for Audit

     Application-layer logs may record task execution, authorization
     decisions, or API invocations.  Network operators may also need
     independently collected flow-level evidence, such as source and
     destination locators, Agent Gateway traversal, SRv6 policy
     identifiers, timestamps, and telemetry records.  Such evidence can
     complement application-layer audit records, but does not replace
     them.

  6.  Design Requirements

     The following requirements guide the considerations discussed in this
     document.  They are intended to constrain Agent-related use of IPv6
     and SRv6 mechanisms.  They do not define a new application-layer
     agent protocol.

     REQ-1:
        Agent identity and network location MUST be decoupled.  A stable
        Agent identifier MUST NOT depend on a single IPv6 locator.

     REQ-2:
        Agent-ID to IPv6 locator or Agent Gateway bindings MUST be
        verifiable by an authorized mechanism.

     REQ-3:
        This document MUST NOT require ordinary Internet routers to
        understand agent identities, task semantics, natural language
        intent, or application payloads.

     REQ-4:
        Metadata exposed at the network layer MUST be minimized and MUST
        NOT contain sensitive user data, natural language prompts, private
        application payloads, or long semantic descriptions.

     REQ-5:
        Deployments MUST be possible without relying on IPv6 extension
        headers being forwarded across the public Internet.

     REQ-6:
        Use of SRv6-specific mechanisms MUST be limited to SRv6-capable
        domains and MUST follow the operational and security constraints
        of SRv6.






  Yu                      Expires 21 November 2026                [Page 7]


  Internet-Draft                AI Agent IPv6                     May 2026


     REQ-7:
        The considerations in this document MUST remain complementary to
        application-layer discovery, identity, authorization, auditing,
        and collaboration mechanisms.

     REQ-8:
        Network-layer telemetry SHOULD be able to correlate with
        application-layer audit records through structured identifiers
        such as Trace-ID, Policy-ID, or Gateway-ID.

     REQ-9:
        Deployments MUST define where agent-related network context is
        processed, who is authorized to process it, and how such
        processing is protected and audited.

  7.  Networking Considerations Overview

     The considerations discussed in this document can be organized into
     five logical functions.  These functions are logical and may be
     implemented by different systems in different deployments.

  7.1.  Agent Discovery Function

     This function discovers agent capabilities and endpoints through
     existing or emerging mechanisms, such as an Agent Directory, ARDP,
     A2A AgentCard, MCP-related directories, DNS-based indirection, or
     enterprise service discovery systems.  This document does not replace
     this function.

  7.2.  Agent Identity and Binding Function

     This function maintains or queries the binding between an Agent-ID
     and networking information.  A binding record may include:

     *  Agent-ID;

     *  responsible entity;

     *  IPv6 locator;

     *  IPv6 prefix;

     *  Agent Gateway;

     *  certificate or public key reference;

     *  binding status;




  Yu                      Expires 21 November 2026                [Page 8]


  Internet-Draft                AI Agent IPv6                     May 2026


     *  validity period;

     *  revocation status.

     The binding function may use an Agent-ID Registration Data Service,
     an Agent Registry, DNS-based indirection, an enterprise identity
     system, an operator-managed database, or a controller.  This document
     does not require a single global registry.

  7.3.  Agent Locator Resolution Function

     This function selects the IPv6 locator or Agent Gateway that should
     be used for a specific communication.  Selection may depend on
     network reachability, policy, trust level, service class,
     administrative domain, or deployment location.

  7.4.  Network Policy Function

     This function maps structured communication requirements to network
     policies.  Such policies may include default IPv6 forwarding, SRv6
     path steering, service-chain insertion, security gateway traversal,
     compliance-aware routing, audit collection, traffic isolation, or
     low-latency forwarding.

  7.5.  Forwarding and Telemetry Function

     This function carries agent communication using IPv6 and, where
     applicable, SRv6.  It may also collect telemetry information that can
     be correlated with application-layer audit records.

  8.  Agent-ID to IPv6 Locator Binding

     This document separates Agent-ID from IPv6 locator.  The Agent-ID
     identifies the agent as a stable entity.  The IPv6 locator identifies
     the current network location of an agent instance, an Agent Gateway,
     or another network element that represents the agent.

     An Agent-ID may be associated with one or more IPv6 locators.  The
     relationship may be one-to-one, one-to-many, many-to-one, or dynamic:

     *  A fixed agent instance may map to one IPv6 locator.

     *  A replicated agent service may map to multiple IPv6 locators.

     *  Many agents may be represented by a single Agent Gateway IPv6
        locator.

     *  A mobile or migrated agent may change its IPv6 locator over time.



  Yu                      Expires 21 November 2026                [Page 9]


  Internet-Draft                AI Agent IPv6                     May 2026


     Binding information SHOULD be authenticated and SHOULD include a
     validity period and revocation status.  If an Agent Gateway
     represents an Agent-ID, the gateway authorization SHOULD also be
     verifiable.

  9.  Use of IPv6 and SRv6

     IPv6 is used as the basic network-layer substrate.  In simple cases,
     agent communication can use ordinary IPv6 forwarding.  In more
     advanced cases, SRv6 may be used within an SRv6-capable domain to
     support path steering, service chaining, security inspection, or
     audit path selection.

     SRv6 may be useful when agent communication needs to pass through
     specific network functions, such as:

     *  Agent Gateway;

     *  authentication gateway;

     *  policy enforcement point;

     *  security inspection node;

     *  audit collection node;

     *  data compliance gateway;

     *  inference gateway;

     *  target agent service endpoint.

     This document avoids defining new IPv6 extension headers.  [RFC8200]
     notes that defining new IPv6 extension headers is not recommended
     unless existing extension headers cannot be used, and also notes
     operational concerns around Hop-by-Hop options.  Therefore, this
     document primarily considers existing mechanisms and deployment
     profiles.

  10.  Agent Context Carriage

     Limited Agent Context may be carried in network-layer or network-
     adjacent mechanisms.  Candidate fields include:

     *  Agent-ID reference;

     *  Session-ID;




  Yu                      Expires 21 November 2026               [Page 10]


  Internet-Draft                AI Agent IPv6                     May 2026


     *  Trace-ID;

     *  Task-ID reference;

     *  Policy-ID;

     *  Trust-Level;

     *  Audit-Flag;

     *  Gateway-ID;

     *  Validity-Time;

     *  Service-Class.

     Agent Context MUST be minimized.  Large semantic descriptions,
     natural language prompts, private user data, or sensitive application
     payloads MUST NOT be carried in IPv6 extension headers or other
     network-visible metadata fields.

  10.1.  Destination Options

     IPv6 Destination Options may be considered when the context is
     intended for the final destination or an intermediate destination
     identified by a Routing Header.  [RFC8200] specifies that a
     Destination Options header can appear before a Routing Header or
     before the upper-layer header.

     Destination Options may be suitable only in deployment environments
     where participating endpoints or gateways are explicitly configured
     to process such options.  This document does not assume that
     Destination Options are reliably forwarded or processed across the
     public Internet.

  10.2.  SRH TLVs

     SRH TLVs may be considered inside an SRv6-capable domain when the
     information is related to SRv6 policy, service-chain context, audit
     path selection, or domain-local agent policy enforcement.  Such TLVs
     are not intended to carry user prompts, full Agent identities, or
     sensitive payload data.









  Yu                      Expires 21 November 2026               [Page 11]


  Internet-Draft                AI Agent IPv6                     May 2026


  10.3.  Fallback Mechanisms

     Because IPv6 extension header support may be inconsistent across
     public networks, deployments SHOULD provide fallback mechanisms.
     Such mechanisms may include application-layer headers, TLS-protected
     metadata, Agent Gateway encapsulation, controller-side policy
     mapping, or out-of-band policy association.

  11.  Semantic Routing Considerations

     This document does not require routers to understand natural
     language, prompts, complex semantic descriptions, or agent reasoning
     processes.  Semantic routing, if used, is understood as an indirect
     process:

     1.  An upper-layer agent system, registry, controller, or gateway
         interprets task intent and converts it into a structured network
         policy identifier.

     2.  The IPv6 or SRv6 network uses the structured policy identifier to
         select a path, service chain, security domain, telemetry
         behavior, or audit policy.

     User or task intent
        -> Agent application / Registry / Gateway
        -> structured Policy-ID
        -> IPv6 or SRv6 policy
        -> forwarding path or service chain

     This design keeps semantic interpretation out of the forwarding plane
     and limits network-layer behavior to structured and verifiable policy
     identifiers.

  12.  Network Telemetry and Audit Support

     IPv6 and SRv6 deployments can provide network-layer evidence that
     complements application-layer audit records.  Examples include:

     *  source and destination IPv6 locators;

     *  Agent Gateway traversal records;

     *  SRv6 policy identifiers;

     *  service-chain identifiers;

     *  Trace-ID or Policy-ID correlation fields;




  Yu                      Expires 21 November 2026               [Page 12]


  Internet-Draft                AI Agent IPv6                     May 2026


     *  timestamps and flow-level telemetry;

     *  policy enforcement events;

     *  path or domain transition records.

     This document does not define a complete audit record format, legal
     compliance framework, or non-repudiation mechanism.  Such functions
     may be provided by application-layer audit architectures, logging
     systems, transparency services, or other mechanisms.  This document
     focuses on the network-layer evidence that can be correlated with
     those systems.

  13.  Deployment Models

     The considerations in this document can be applied incrementally.
     This document identifies three non-exclusive deployment models.

  13.1.  Endpoint and Gateway Mode

     In this model, agent-related network context is processed only by
     agent endpoints and Agent Gateways.  The public Internet or transit
     network forwards ordinary IPv6 traffic and does not process agent-
     specific metadata.  This model is suitable when extension header
     processing is not available or when functions are implemented
     primarily at the edge.

  13.2.  Controlled-Domain Mode

     In this model, agent-related networking functions are deployed within
     an enterprise, campus, data center, cloud, operator network, or
     dedicated interconnection environment.  Participating nodes may
     process limited Agent Context according to local policy.  This model
     is suitable for environments where administrative control, security
     policy, and extension header behavior can be managed.

  13.3.  SRv6-Domain Mode

     In this model, SRv6 policies are used to steer traffic through
     specific service functions or network domains.  Agent-related context
     may be associated with SRv6 policies, service chains, or domain-local
     telemetry collection.  This model is limited to SRv6-capable domains
     and must follow SRv6 operational and security practices.








  Yu                      Expires 21 November 2026               [Page 13]


  Internet-Draft                AI Agent IPv6                     May 2026


  14.  Relationship to Existing Work

     The considerations in this document are complementary to existing and
     emerging work on agent protocols.  Agent discovery mechanisms can
     identify agents, advertise capabilities, and resolve endpoints.  A2A
     and MCP focus on application-layer interaction, tool invocation, and
     collaboration.  OAuth, OIDC, DID, SD-JWT, WIMSE, RATS, and related
     mechanisms may be used for identity, authorization, attestation,
     selective disclosure, or workload identity.  OpenTelemetry and
     related systems may provide application-layer tracing and
     observability.

     This document focuses on a different layer: IPv6-based networking
     support for agent communication after discovery.  It can provide
     locator binding, network policy selection, Agent Gateway traversal,
     SRv6 service chaining, and network-layer telemetry that can be
     correlated with higher-layer identity, authorization, and audit
     mechanisms.

     A common limitation of many agent discovery and collaboration
     mechanisms is that they stop at the point where an endpoint,
     protocol, credential, or capability description has been selected.
     They generally do not specify how the selected interaction is bound
     to an IPv6 locator or Agent Gateway, how the traffic is steered
     through an operator controlled path, or how network-layer evidence is
     correlated with application-layer audit records.  This document
     addresses that gap.

     This document also avoids placing agent semantics in ordinary
     routers.  Any interpretation of user intent, task descriptions, or
     agent capabilities is expected to occur in an application, registry,
     controller, or gateway.  The network is expected to operate on
     structured identifiers, locators, and policies.

  15.  Security Considerations

     This document raises several security considerations.

     First, Agent-ID to IPv6 locator or Agent Gateway binding must be
     authenticated.  An attacker must not be able to claim an Agent-ID or
     bind it to an unauthorized locator.

     Second, Agent Gateway authorization must be verifiable.  A gateway
     must not represent an agent unless it has been authorized by the
     responsible entity or administrative domain.






  Yu                      Expires 21 November 2026               [Page 14]


  Internet-Draft                AI Agent IPv6                     May 2026


     Third, Agent Context carried in network-visible mechanisms must be
     minimized and integrity-protected where necessary.  Sensitive data
     must not be exposed in cleartext network headers.

     Fourth, replay attacks must be considered.  Context fields such as
     Policy-ID, Trace-ID, or Agent-ID references may need validity time,
     nonce, session binding, or cryptographic protection depending on the
     deployment.

     Fifth, policy identifiers must not be used to bypass access control,
     security inspection, or authorization checks.  Network policy
     selection must be integrated with existing security policy
     enforcement.

     Sixth, this document does not assume that IPv6 extension headers are
     available across the public Internet.  Deployment profiles must
     define where such mechanisms are allowed and what fallback mechanisms
     are used.

     Seventh, SRv6 usage must follow SRv6 security considerations.  SRv6
     policies and SIDs used for agent communication must be protected
     against unauthorized insertion, modification, or misuse.

  16.  Privacy Considerations

     Agent-related metadata may reveal information about agent identity,
     task class, policy class, organizational relationships, or network
     path choices.  Deployments must minimize exposed metadata and avoid
     carrying sensitive user data in network-layer headers or network-
     visible metadata fields.

     Agent-ID references may be pseudonymous, scoped to a domain, or
     represented by opaque references.  Detailed identity information
     should be obtained through authorized query mechanisms, rather than
     exposed in every packet.

     Network telemetry used for audit support may contain sensitive
     operational information.  Access to telemetry records should be
     controlled, retained only as long as necessary, and protected against
     unauthorized disclosure or correlation.

  17.  IANA Considerations

     This initial version does not request any IANA action.







  Yu                      Expires 21 November 2026               [Page 15]


  Internet-Draft                AI Agent IPv6                     May 2026


     Future versions may request code points for specific Destination
     Options, SRH TLVs, or other identifiers if concrete encodings are
     standardized.  Such requests are out of scope for this considerations
     document.

  18.  Normative References

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

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

     [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", STD 86, RFC 8200,
                DOI 10.17487/RFC8200, July 2017,
                <https://www.rfc-editor.org/info/rfc8200>.

     [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
                Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
                (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
                <https://www.rfc-editor.org/info/rfc8754>.

     [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
                D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
                (SRv6) Network Programming", RFC 8986,
                DOI 10.17487/RFC8986, February 2021,
                <https://www.rfc-editor.org/info/rfc8986>.

  19.  Informative References

     [I-D.pioli-agent-discovery]
                Pioli, L., "Agent Registration and Discovery Protocol",
                <https://datatracker.ietf.org/doc/draft-pioli-agent-
                discovery/>.

     [Agent2Agent-Archive]
                IETF, "IETF Agent2Agent Mailing List Archive",
                <https://mailarchive.ietf.org/arch/browse/agent2agent/>.

  Author's Address

     Haisheng Yu
     China Internet Network Information Center
     Email: yuhaisheng@cnnic.cn



  Yu                      Expires 21 November 2026               [Page 16]


name: draft-morrison-agent-channel-fan-out
rev: 00
title: An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions
time: 2026-05-21T10:15:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-22T10:15:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698417+00:00
source: ietf
abstract:
  This memo specifies an application-layer frame format and a delivery
     model by which the several concurrent agentic sessions of a single
     identity-bound principal, and the recognised members of an
     organisational identity substrate, exchange short structured
     messages.  The frame, termed the agent-channel frame, is a transport
     envelope: it carries a closed-catalogue kind discriminator, a
     structured per-kind payload, an identity attribution pair, and an
     inline provenance block.  Delivery is fan-out: a sender names a
     recipient scope rather than a single endpoint, and the scope is
     expanded at delivery time against the recipient's subscriptions.
     Recipients receive frames over a per-handle Server-Sent Events stream
     and MAY narrow what they receive with a subscribe-time filter
     expression.  Frames are ephemeral routing units; the memo specifies
     only the wire envelope, the scope-expansion grammar, the subscribe
     filter grammar, and the delivery semantics.  Frame persistence, where
     an implementation chooses to retain frames for replay, is out of
     scope and is not specified.  The memo composes with the handle
     namespace of [IDPRONOUNS], the discovery surface of [MCPDNS], and the
     cross-organisational ceremony of [IDACCORD]; no new transport and no
     new handle category is introduced.

full_text:
  Network Working Group                                        B. Morrison
  Internet-Draft                       Alter Meridian Pty Ltd (~truealter)
  Intended status: Informational                                  May 2026
  Expires: 22 November 2026


  An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent
                                  Sessions
                  draft-morrison-agent-channel-fan-out-00

  Abstract

     This memo specifies an application-layer frame format and a delivery
     model by which the several concurrent agentic sessions of a single
     identity-bound principal, and the recognised members of an
     organisational identity substrate, exchange short structured
     messages.  The frame, termed the agent-channel frame, is a transport
     envelope: it carries a closed-catalogue kind discriminator, a
     structured per-kind payload, an identity attribution pair, and an
     inline provenance block.  Delivery is fan-out: a sender names a
     recipient scope rather than a single endpoint, and the scope is
     expanded at delivery time against the recipient's subscriptions.
     Recipients receive frames over a per-handle Server-Sent Events stream
     and MAY narrow what they receive with a subscribe-time filter
     expression.  Frames are ephemeral routing units; the memo specifies
     only the wire envelope, the scope-expansion grammar, the subscribe
     filter grammar, and the delivery semantics.  Frame persistence, where
     an implementation chooses to retain frames for replay, is out of
     scope and is not specified.  The memo composes with the handle
     namespace of [IDPRONOUNS], the discovery surface of [MCPDNS], and the
     cross-organisational ceremony of [IDACCORD]; no new transport and no
     new handle category is introduced.

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




  Morrison                Expires 22 November 2026                [Page 1]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     This Internet-Draft will expire on 2 November 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.

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     4.  The Agent-Channel Frame . . . . . . . . . . . . . . . . . . .   6
       4.1.  Envelope Fields . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Attribution Fields  . . . . . . . . . . . . . . . . . . .   7
       4.3.  Provenance Block  . . . . . . . . . . . . . . . . . . . .   7
     5.  The Frame-Kind Catalogue  . . . . . . . . . . . . . . . . . .   8
       5.1.  Advisory and Broadcast Kinds  . . . . . . . . . . . . . .   8
       5.2.  Handover Kind . . . . . . . . . . . . . . . . . . . . . .   8
       5.3.  Lock-Shaped Kinds . . . . . . . . . . . . . . . . . . . .   9
       5.4.  Question-and-Answer Kinds . . . . . . . . . . . . . . . .   9
       5.5.  Decision-Request Kind . . . . . . . . . . . . . . . . . .   9
       5.6.  Diagnostic Kinds  . . . . . . . . . . . . . . . . . . . .  10
       5.7.  Convergence Kinds . . . . . . . . . . . . . . . . . . . .  10
     6.  Payload Schemas . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  agent_advisory  . . . . . . . . . . . . . . . . . . . . .  10
       6.2.  agent_broadcast . . . . . . . . . . . . . . . . . . . . .  11
       6.3.  agent_handover  . . . . . . . . . . . . . . . . . . . . .  11
       6.4.  agent_lock_request  . . . . . . . . . . . . . . . . . . .  11
       6.5.  agent_lock_release  . . . . . . . . . . . . . . . . . . .  12
       6.6.  agent_lease_extend  . . . . . . . . . . . . . . . . . . .  12
       6.7.  agent_query . . . . . . . . . . . . . . . . . . . . . . .  12
       6.8.  agent_response  . . . . . . . . . . . . . . . . . . . . .  12
       6.9.  agent_return_event  . . . . . . . . . . . . . . . . . . .  12
       6.10. agent_binding_moment  . . . . . . . . . . . . . . . . . .  13
       6.11. peer_diagnostic_request . . . . . . . . . . . . . . . . .  13
       6.12. peer_diagnostic_response  . . . . . . . . . . . . . . . .  13
       6.13. intent_declare, intent_withdraw, flush_executed . . . . .  13
     7.  Recipient Scope Grammar . . . . . . . . . . . . . . . . . . .  14
     8.  Delivery over the Per-Handle Stream . . . . . . . . . . . . .  15
       8.1.  Submission and Expansion  . . . . . . . . . . . . . . . .  15
       8.2.  Stream Maintenance  . . . . . . . . . . . . . . . . . . .  16



  Morrison                Expires 22 November 2026                [Page 2]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


       8.3.  Ephemerality  . . . . . . . . . . . . . . . . . . . . . .  16
     9.  Subscribe Filter Grammar  . . . . . . . . . . . . . . . . . .  16
     10. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  18
     11. A Reference Tool Surface  . . . . . . . . . . . . . . . . . .  19
     12. Composition with Companion Memos  . . . . . . . . . . . . . .  19
     13. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  20
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     15. Security Considerations . . . . . . . . . . . . . . . . . . .  21
       15.1.  Sender Spoofing  . . . . . . . . . . . . . . . . . . . .  21
       15.2.  Scope-Authorisation Bypass . . . . . . . . . . . . . . .  21
       15.3.  Fan-Out Amplification  . . . . . . . . . . . . . . . . .  22
       15.4.  Lock-Shaped Frames Are Not Authority . . . . . . . . . .  22
       15.5.  Replay and Duplication . . . . . . . . . . . . . . . . .  22
       15.6.  Diagnostic-Frame Information Disclosure  . . . . . . . .  23
     16. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23
       16.1.  Recipient-Scope Membership Inference . . . . . . . . . .  23
       16.2.  Attribution Exposure . . . . . . . . . . . . . . . . . .  23
       16.3.  Provenance-Block Content . . . . . . . . . . . . . . . .  23
       16.4.  Ephemerality as a Privacy Property . . . . . . . . . . .  24
     17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
       17.1.  Normative References . . . . . . . . . . . . . . . . . .  24
       17.2.  Informative References . . . . . . . . . . . . . . . . .  25
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

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

  2.  Introduction

     A single human principal increasingly operates several artificial-
     intelligence agent runtimes at once: multiple concurrent sessions of
     one coding assistant, a separate assistant in an integrated
     development environment, a command-line agent, and a background
     runtime daemon.  Those surfaces need to exchange short messages with
     one another: to advise a sibling that a file is being edited, to hand



  Morrison                Expires 22 November 2026                [Page 3]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     work over when one session ends, to ask a question and collect
     answers, to announce that a branch was merged.

     In current practice such messages have no shared transport.  Where
     two sessions of the same principal must coordinate, the prevailing
     fallback is a file written to a shared temporary directory and a
     manual instruction to a second session to read it.  That fallback has
     no addressing, no delivery guarantee, no attribution, and no
     filtering; it does not reach a session on a second host, and it does
     not reach the principal's runtimes operating under a second
     organisational context.

     This memo specifies a frame format and a delivery model that replace
     the file fallback.  The contribution is deliberately narrow.  The
     companion memo [SUBSTRATE] argues that _coordination_ (the
     deconfliction of conflicting action) should not be standardised as an
     envelope protocol, because envelope coordination re-centralises an
     inherently distributed problem.  The present memo does not contradict
     that argument.  It specifies a _delivery_ frame for messages a
     session has _chosen_ to send: an advisory, a handover, a question.
     It is a transport, not a coordination protocol.  No frame in this
     memo's catalogue compels a recipient to any action; no frame carries
     a lock a recipient must honour; the lock-shaped frames of Section 5
     are advisory announcements, and a recipient that ignores one remains
     conformant.  Reconciliation of conflicting action, where it occurs,
     occurs through the substrate-observation cascade of [SUBSTRATE], not
     through this memo's frames.

     The frame is identity-keyed.  A sender names a recipient _scope_:
     "all my sessions", "all sessions of one tool", "one named session",
     or "all members of an organisation"; the scope is expanded against
     recipients' live subscriptions at delivery time.  The fan-out is the
     load-bearing delivery primitive: a sender addresses a set, not an
     endpoint, and the set is resolved by the delivery substrate from
     identity, not from a registry of endpoints the sender maintains.

     The frame is ephemeral.  A delivered frame is a routing unit with a
     time-to-live; once delivered, the delivery substrate is under no
     obligation specified by this memo to retain it.  Where an
     implementation retains delivered frames so that a late-joining
     session can replay recent traffic, the retention mechanism, its
     ordering properties, and its retention horizon are implementation
     matters outside the scope of this specification.  This memo specifies
     the wire envelope and the delivery semantics; it does not specify a
     store.






  Morrison                Expires 22 November 2026                [Page 4]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  3.  Conventions and Definitions

     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.

     The following terms are defined for the purposes of this document.
     Terms previously defined by the referenced Morrison-family memos
     retain their established meaning and are reproduced here only when
     operative for the present specification.

     ~handle  A principal identity handle as defined by [IDPRONOUNS].  A
        Sovereign-tier handle is human-controlled (e.g. ~alice); an
        Instrument-tier handle is agent-runtime-vendor-controlled and
        conventionally prefixed ~cc- (e.g. ~cc-example-model).

     Agent-channel frame  The application-layer message unit specified by
        this memo.  A single JSON object [RFC8259] comprising an envelope,
        a kind discriminator, a structured payload, an identity
        attribution pair, and a provenance block.

     Kind  The closed-catalogue discriminator naming the frame's purpose.
        Section 4 enumerates the catalogue.  An implementation that
        receives a kind outside the catalogue MUST reject the frame.

     Payload  The kind-specific structured body of a frame.  Each kind has
        exactly one payload shape; a frame whose payload shape does not
        match its kind is malformed.

     Recipient scope  A string naming the set of recipients a frame is to
        be delivered to.  Section 6 specifies the scope grammar.  A
        recipient scope is not an endpoint; it is expanded against live
        subscriptions at delivery time.

     Delivery substrate  The network-addressable system that accepts a
        submitted frame, expands its recipient scope, and emits the frame
        to the subscriptions the scope names.  The delivery substrate is
        addressed per the discovery mechanism of [MCPDNS].

     Per-handle stream  A single Server-Sent Events HTML-SSE [RFC8441]
        stream associated with one ~handle, over which the delivery
        substrate emits the frames whose expanded recipient scope includes
        a session of that handle.

     Subscribe filter  An expression supplied by a subscriber at the time




  Morrison                Expires 22 November 2026                [Page 5]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


        it opens its per-handle stream, narrowing the frames the delivery
        substrate emits to that subscriber.  Section 8 specifies the
        filter grammar.

     Time-to-live  A per-frame integer, in milliseconds, after which a
        sender declares the frame's content no longer operative.  The
        time-to-live is advisory to recipients; it is not a retention
        directive to the delivery substrate.

  4.  The Agent-Channel Frame

     An agent-channel frame is a single JSON object [RFC8259].  Its fields
     are specified below.  An implementation receiving a frame MUST reject
     it if a REQUIRED field is absent, if any field carries a value
     outside the constraints below, or if an unrecognised field is present
     (the frame object does not admit extension fields; see Section 12).

  4.1.  Envelope Fields

     envelope_version (string, REQUIRED)  The wire-contract version.  This
        memo specifies version "1.0".  A receiver that does not implement
        the stated version MUST reject the frame rather than attempt a
        partial parse.

     frame_id (string, REQUIRED)  A version-4 UUID generated by the
        sender, unique to this frame.  Receivers MAY use frame_id to
        discard a duplicate delivery of the same frame.

     kind (string, REQUIRED)  One of the fifteen catalogue values of
        Section 4.  A kind outside the catalogue MUST cause rejection
        (Section 10).

     sender_handle (string, REQUIRED)  The ~handle of the sending
        principal, in the canonical handle form of [IDPRONOUNS].  The
        delivery substrate MUST verify that sender_handle matches the
        authenticated identity of the submitting session and MUST reject a
        frame whose sender_handle does not.

     recipient_handle (string, REQUIRED)  The ~handle of the target
        principal, in canonical handle form.  For a frame addressed to the
        sender's own sessions, sender_handle and recipient_handle are
        identical.  The recipient _scope_ (Section 6) further qualifies
        which sessions of recipient_handle receive the frame;
        recipient_handle alone identifies the target principal.

     created_at (string, REQUIRED)  An RFC 3339 timestamp, with time zone,





  Morrison                Expires 22 November 2026                [Page 6]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


        at which the sender emitted the frame.  The delivery substrate MAY
        reject a frame whose created_at lies implausibly far in the future
        or the past relative to substrate time.

     ttl_ms (integer, OPTIONAL)  The frame's advisory time-to-live in
        milliseconds.  When absent, the recipient applies an
        implementation-default horizon.  The field is advisory to the
        recipient (it indicates when the sender considers the content
        stale); it places no retention obligation on the delivery
        substrate.

     payload (object, REQUIRED)  The kind-specific body, with the shape
        specified for the frame's kind in Section 5.

  4.2.  Attribution Fields

     Every frame carries the tier-structured attribution pair of
     [IDCOMMITS], lifted from version-control commit time to wire time.

     acted_by (string, REQUIRED)  The Sovereign-tier ~handle of the human
        principal on whose behalf the frame is sent.

     drafted_with (string, REQUIRED)  The Instrument-tier ~handle of the
        agent runtime that composed the frame.

     The attribution pair lets a receiver distinguish a frame a human
     authored directly from a frame an agent runtime composed, without a
     side-channel lookup.  An agent-channel frame and an Acted-By: /
     Drafted-With: commit trailer block carry the same attribution shape:
     one at message time, one at commit time.

  4.3.  Provenance Block

     Every frame carries an inline provenance block so a receiver can
     assess the frame's basis without an out-of-band query.  The block
     comprises five fields.

     provenance_compute_location (string, REQUIRED)  Where the inference
        behind the frame's content was computed.  One of "server-active",
        "server-aggregate", or "local-only".  The value "local-only"
        asserts that the frame's content derives from inference that did
        not leave the principal's device.

     provenance_method (array of strings, REQUIRED, non-empty)  One or
        more derivation-method tags identifying how the frame's content
        was produced (for example, a session-context snapshot, a pre-
        compaction snapshot).  At least one tag is REQUIRED.




  Morrison                Expires 22 November 2026                [Page 7]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     provenance_return_ref (string, OPTIONAL)  A reference to a return
        record, where the frame's content is derived from a recipient's
        data and the implementation maintains a return-accounting surface.
        Absent where inapplicable.

     provenance_context_check (string, REQUIRED)  One of "passed" or
        "skipped".  The value "passed" asserts that the sender confirmed
        the frame is not emitted in a context the sender's policy
        prohibits; "skipped" asserts the check is inapplicable to the
        frame.

     provenance_basis (string, REQUIRED)  A short tag naming the stream
        the frame belongs to and the basis under which that stream emits.

     The provenance block is descriptive metadata carried for the
     receiver's benefit.  This memo does not specify a conformance
     behaviour keyed to any provenance field; an implementation MAY use
     the block to inform its own acceptance policy.

  5.  The Frame-Kind Catalogue

     The kind field takes one of exactly fifteen values.  The catalogue is
     closed: a sixteenth value is an error (Section 10), not an extension
     point.  The catalogue is grouped below by function; the grouping is
     descriptive and is not encoded on the wire.

  5.1.  Advisory and Broadcast Kinds

     agent_advisory  A session announces what it is doing, for example
        that it is about to edit a named file, or that it is operating in
        a named working tree on a named branch.  Default recipient scope
        is the sender's own sessions.

     agent_broadcast  A session announces a completed event other sessions
        should know of, for example that a branch was merged, or that a
        sibling's working tree is now stale.  Carries a coarse event class
        so a subscriber may filter without parsing the body.

  5.2.  Handover Kind

     agent_handover  A session passes work to another session, carrying
        the prose content a principal would otherwise place in a shared
        temporary file and a list of pointer references (file paths,
        change-request references, working-tree paths).  This kind
        replaces the temporary-file fallback described in Section 1.






  Morrison                Expires 22 November 2026                [Page 8]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  5.3.  Lock-Shaped Kinds

     The following three kinds are _advisory announcements_.  They
     announce a session's intent regarding a named resource.  They do not,
     and cannot, compel a recipient.  A recipient that receives an
     agent_lock_request and proceeds to act on the named resource anyway
     is conformant; the announcement is information, not authority.
     Enforcement of mutual exclusion, where an implementation requires it,
     is performed locally by the operating environment (for example, a
     filesystem advisory lock), not by this memo's frames.

     agent_lock_request  Announces that the sender claims a named resource
        for an advisory lease, carrying a lease identifier and a lease
        lifetime.

     agent_lock_release  Announces that the sender has released an
        advisory lease, carrying the lease identifier.

     agent_lease_extend  Announces that the sender extends the lifetime of
        an advisory lease, carrying the lease identifier and the
        additional lifetime.

     The lease identifier is a correlation value only.  The delivery
     substrate MUST NOT treat it as a key into any lock table, MUST NOT
     enforce uniqueness of an outstanding lease, and MUST NOT reject an
     agent_lock_release whose lease identifier does not match a prior
     agent_lock_request.  Correlation of the three kinds is performed by
     recipients; the delivery substrate validates only their shape.

  5.4.  Question-and-Answer Kinds

     agent_query  Asks a question and names a scope to which answers
        should be delivered, carrying a query identifier and a caller-side
        collection window.

     agent_response  Answers an agent_query, carrying the query identifier
        it answers and the responding session's identifier.

     agent_return_event  Records the closure of a question-and-answer
        exchange against a return-accounting surface, where the
        implementation maintains one, carrying a return reference and an
        optional query identifier.

  5.5.  Decision-Request Kind

     agent_binding_moment  Carries a structured decision request from one
        session to another.  Its payload is the eight-slot grammar of
        Section 5.10.



  Morrison                Expires 22 November 2026                [Page 9]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  5.6.  Diagnostic Kinds

     peer_diagnostic_request  Reports an observed symptom to a peer for
        troubleshooting, carrying a diagnostic identifier and a coarse
        severity.

     peer_diagnostic_response  Answers a peer_diagnostic_request, carrying
        the diagnostic identifier and a finding.

  5.7.  Convergence Kinds

     intent_declare  Announces a session's intent to incur a class of
        costly external effect, carrying a namespaced class identifier, a
        pointer to the intended effect, and a decay horizon.

     intent_withdraw  Withdraws a previously declared intent before its
        effect is executed, carrying the class identifier and a pointer to
        the declared intent.

     flush_executed  Announces that a session has executed a batched
        effect on behalf of a set of declared intents, carrying a pointer
        to the result and the pointers of the included intents.

     The three convergence kinds let a set of sessions batch a costly
     effect (for example, opening a single change request for several
     pooled changes) without electing a coordinator: each session
     announces its intent, observes the others' announcements, and one
     session executes the batched effect.  As with the lock-shaped kinds,
     the announcements carry no authority; a session that declares an
     intent and a session that executes a flush each act on their own
     observation of the announced traffic.

  6.  Payload Schemas

     Each kind has exactly one payload shape.  A frame whose payload does
     not satisfy the shape for its kind is malformed and MUST be rejected.
     The schemas below give the REQUIRED and OPTIONAL fields of each
     payload; string-length and numeric bounds are stated where an
     implementation is expected to enforce them.

  6.1.  agent_advisory

     advisory_text (string, REQUIRED, 1 to 2048 octets)  What the sender
        is doing.

     file_refs (array of strings, OPTIONAL)  Files the advisory concerns.

     worktree (string, OPTIONAL, up to 512 octets)  The working-tree path



  Morrison                Expires 22 November 2026               [Page 10]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


        the sender operates in.

     branch (string, OPTIONAL, up to 256 octets)  The branch the sender is
        on.

  6.2.  agent_broadcast

     broadcast_text (string, REQUIRED, 1 to 2048 octets)  The announcement
        body.

     event_class (string, REQUIRED)  One of "merged", "stale", "released",
        "other".  A coarse class permitting subscriber-side filtering
        without body parsing.

     refs (array of strings, OPTIONAL)  Branch, change-request, or commit
        references the broadcast concerns.

  6.3.  agent_handover

     previous_session_id (string, REQUIRED, 1 to 128 octets)  An opaque
        identifier for the handing-over session.

     next_session_id (string, OPTIONAL, up to 128 octets)  An identifier
        for the session that claims the handover.  Absent at emission; a
        claiming session populates it by a subsequent frame.

     handover_body (string, REQUIRED)  The handover content.

     pointer_refs (array of strings, OPTIONAL)  File paths, change-request
        references, decision identifiers, and working-tree paths the
        handover points at.

  6.4.  agent_lock_request

     resource (string, REQUIRED, 1 to 512 octets)  The resource the sender
        claims an advisory lease over.

     lease_id (string, REQUIRED)  A version-4 UUID correlating this
        announcement with later agent_lock_release and agent_lease_extend
        frames.

     ttl_ms (integer, REQUIRED, greater than 0, at most 3 600 000)  The
        advisory lease lifetime in milliseconds.

     intent (string, OPTIONAL, up to 2048 octets)  A human-readable reason
        for the claim.





  Morrison                Expires 22 November 2026               [Page 11]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  6.5.  agent_lock_release

     lease_id (string, REQUIRED)  The lease the announcement releases.

     resource (string, REQUIRED, 1 to 512 octets)  The resource the
        released lease covered.

  6.6.  agent_lease_extend

     lease_id (string, REQUIRED)  The lease whose lifetime is extended.

     additional_ttl_ms (integer, REQUIRED, greater than 0, at most

     3 600 000)  The additional lifetime in milliseconds.

  6.7.  agent_query

     query_text (string, REQUIRED, 1 to 2048 octets)  The question.

     query_id (string, REQUIRED)  A version-4 UUID correlating the query
        with its responses and return event.

     response_scope (string, REQUIRED, 1 to 512 octets)  The recipient
        scope (Section 6) to which responses are to be delivered.

     timeout_ms (integer, REQUIRED, greater than 0)  The caller-side
        window, in milliseconds, over which the caller collects responses.

  6.8.  agent_response

     query_id (string, REQUIRED)  The query this frame answers.

     response_text (string, REQUIRED, 1 to 2048 octets)  The answer.

     responder (string, REQUIRED, 1 to 128 octets)  An identifier for the
        responding session.

  6.9.  agent_return_event

     return_event_ref (string, REQUIRED, 1 to 256 octets)  A reference to
        a return record on the implementation's return-accounting surface.

     query_id (string, OPTIONAL)  The query this return event closes,
        where the return is paired with an agent_query.

     summary (string, REQUIRED, 1 to 2048 octets)  A human-readable
        summary of what was returned.




  Morrison                Expires 22 November 2026               [Page 12]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  6.10.  agent_binding_moment

     The agent_binding_moment payload carries an eight-slot decision
     request.  The eight slots are: a one-sentence synopsis; an array of
     findings; an array of recommendations; a one-line offer; and a
     question object comprising a one-sentence stem, an array of two to
     four options (each an object carrying a short label and a one-line
     reasoning), a recommended_idx integer naming exactly one option, and
     a hatches object carrying two booleans, free_text and dialogue, each
     defaulting to true.

     The two hatches preserve a dual escape from the decision frame:
     free_text indicates the recipient may answer outside the option set,
     and dialogue indicates the recipient may revise the question itself.
     A decision-request frame in which both hatches are false is
     malformed; a recipient MUST be left a path that is not one of the
     enumerated options.

  6.11.  peer_diagnostic_request

     symptom (string, REQUIRED, 1 to 2048 octets)  A description of the
        observed symptom.

     diagnostic_id (string, REQUIRED)  A version-4 UUID correlating the
        request with its response.

     substrate_refs (array of strings, OPTIONAL)  Observation references
        supporting the report.

     severity (string, REQUIRED)  One of "info", "degraded", "blocked".

  6.12.  peer_diagnostic_response

     diagnostic_id (string, REQUIRED)  The request this frame answers.

     finding (string, REQUIRED, 1 to 2048 octets)  The diagnostic finding.

     remediation (string, OPTIONAL, up to 2048 octets)  A suggested
        remediation, where one is known.

  6.13.  intent_declare, intent_withdraw, flush_executed

     intent_declare carries a convergence_class namespaced identifier, a
     payload_ref pointer to the intended effect, an acted_by and
     drafted_with attribution pair, a declared_at timestamp, a ttl decay
     horizon in milliseconds, a withdrawable boolean, and an OPTIONAL
     urgency of "normal" or "urgent".




  Morrison                Expires 22 November 2026               [Page 13]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     intent_withdraw carries the convergence_class, an intent_ref pointing
     at the declared intent, and a withdrawn_at timestamp.

     flush_executed carries the convergence_class, a result_ref pointing
     at the result of the executed effect, an OPTIONAL batch_refs array of
     the included intent pointers, and an executed_at timestamp.

     The pointer fields (payload_ref, intent_ref, result_ref, batch_refs)
     carry references (change-request identifiers, settlement identifiers,
     filing identifiers) and not the referenced objects themselves.
     Carrying references keeps frames small and keeps the delivery
     substrate free of the referenced content.

  7.  Recipient Scope Grammar

     A frame is submitted with a recipient scope: a string naming the set
     of sessions the frame is to reach.  The delivery substrate expands
     the scope at delivery time against the live subscriptions (Section 7)
     of recipient_handle.  A scope is not a list of endpoints; the sender
     names a set by its identity shape, and the substrate resolves the
     membership.

     The following scope forms are specified.

     ~handle  Point-to-point in the degenerate sense: every session of the
        named handle.  Equivalent to ~handle/*.

     ~handle/*  All sessions of the named handle.  When ~handle is the
        sender's own handle, this is the same-principal fan-out that
        reaches all the sender's concurrent sessions.

     ~handle/<prefix>*  All sessions of the named handle whose instrument
        identifier begins with <prefix>.  For example, ~alice/cc-* reaches
        all of ~alice's sessions whose instrument identifier begins cc-.

     ~handle/<instrument>@<session-id>  A single named session, identified
        by instrument and session identifier.

     org:<org-handle>/members/*  All sessions of all recognised members of
        the named organisational identity substrate.

     org:<org-handle>/members/<role>/*  All sessions of recognised members
        holding the named role.

     accord:<peer-org-handle>/grant:<grant-scope>  All sessions of the
        named peer organisation reachable under an Identity Accord
        [IDACCORD] grant of the named grant scope.




  Morrison                Expires 22 November 2026               [Page 14]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     A delivery substrate MUST refuse a scope the submitting session is
     not authorised to address.  In particular, a session MUST NOT submit
     a frame to a scope naming a handle other than recipient_handle, MUST
     NOT submit a frame to an org: scope of an organisation that does not
     recognise the sender as a member, and MUST NOT submit a frame to an
     accord: scope absent a corresponding Accord grant.  Cross-
     organisational delivery is always grant-mediated through the peer-
     protocol ceremony of [IDACCORD]; it is never effected by an
     administrative assignment.

     A delivery substrate MAY decline to implement the org: and accord:
     scope forms in an initial deployment, in which case it MUST reject a
     frame carrying an unimplemented scope with the scope-unimplemented
     error of Section 10 rather than silently dropping it.

  8.  Delivery over the Per-Handle Stream

     Each ~handle is associated with one per-handle Server-Sent Events
     stream HTML-SSE [RFC8441].  A session of the handle opens the stream
     by an authenticated request to the delivery substrate resolved per
     [MCPDNS].  The stream is unidirectional from the substrate to the
     subscriber; a session sends a frame by a separate authenticated
     submission, not over the stream it subscribes on.

  8.1.  Submission and Expansion

     A session submits a frame to the delivery substrate.  The substrate:

     1.  validates the frame against Sections 3, 4, and 5, rejecting a
         malformed frame per Section 10;

     2.  verifies that sender_handle matches the submitting session's
         authenticated identity, and that the submitting session is
         authorised to address the supplied recipient scope (Section 6);

     3.  expands the recipient scope against the live subscriptions of
         recipient_handle; and

     4.  emits the frame as a Server-Sent Events event on the per-handle
         stream of each subscription the expansion names, subject to that
         subscription's filter (Section 8).

     A frame whose expanded scope names no live subscription is delivered
     to no subscriber.  This is not an error: the sender addressed a set,
     and the set was, at delivery time, empty.  The submission result
     reports the count of subscriptions the frame was emitted to so a
     sender may observe an empty fan-out.




  Morrison                Expires 22 November 2026               [Page 15]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  8.2.  Stream Maintenance

     The per-handle stream is a long-lived HTTP response.  The delivery
     substrate SHOULD emit a periodic keepalive comment so that
     intermediaries do not close an idle stream, and a subscriber SHOULD
     treat a prolonged absence of both frames and keepalives as a dropped
     stream and re-open it.

     Each emitted event carries the Server-Sent Events id field.  A
     subscriber that re-opens a dropped stream MAY supply the id of the
     last event it received in the Last-Event-ID request header.  A
     delivery substrate MAY honour Last-Event-ID by resuming emission
     after the named event, where the substrate retains recent events; a
     substrate that does not retain events, or for which the named event
     has aged past retention, resumes emission from the current stream
     position.  Whether, and for how long, a substrate retains delivered
     frames for resumption is an implementation matter and is not
     specified by this memo (Section 1).  A subscriber MUST NOT assume
     gap-free resumption.

  8.3.  Ephemerality

     A delivered frame is a routing unit.  Once the delivery substrate has
     emitted a frame to the subscriptions its scope named, this memo
     places no further obligation on the substrate with respect to that
     frame.  The frame's ttl_ms is advisory to recipients and is not a
     directive to the substrate.  An implementation that retains delivered
     frames does so under its own retention policy; the retention policy,
     the order in which retained frames are presented, and any durability
     property of the retention store are outside the scope of this
     specification.

  9.  Subscribe Filter Grammar

     A subscriber MAY narrow the frames it receives on its per-handle
     stream by supplying a filter expression when it opens the stream.
     The filter is carried as a query-string parameter on the stream-open
     request; this memo names the parameter filter for the reference
     deployment, and an implementation MAY use any name consistent with
     its addressing convention.

     A filter expression is a comma-separated list of key:value clauses.
     A frame is emitted to a filtered subscription only if it satisfies
     every clause.  An empty filter, or an absent filter parameter,
     matches every frame.

     The following filter axes are specified.




  Morrison                Expires 22 November 2026               [Page 16]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     kind:<kind>  Matches frames whose kind equals the named catalogue
        value.  A value outside the catalogue MUST cause the stream-open
        request to be rejected, so that a misspelled kind does not
        silently match nothing.

     sender:<~handle>  Matches frames whose sender_handle equals the named
        handle.  A value that is not a canonical handle MUST cause the
        stream-open request to be rejected.

     content_type:<value>  Matches frames whose payload carries a content-
        type field equal to the named value.  A frame whose payload
        carries no content-type field does not match a content_type
        clause; the axis is an opt-in field filter, not a default-pass.

     tool:<tool-class>  Matches frames emitted by a session of the named
        tool class.

     org:<org-handle>  Matches frames scoped to the named organisation.

     tool and org are forward-compatibility axes: a deployment that has
     not yet implemented the org: recipient scope of Section 6 accepts and
     parses an org filter clause so that subscribers may write their
     filter strings ahead of substrate support, but the clause matches no
     frame until the corresponding scope form is implemented.  A parsed-
     but-not-yet-effective clause MUST NOT widen the stream; the
     subscriber asked for a narrowing and receives, at worst, a valid no-
     op.

     An unrecognised filter axis MUST cause the stream-open request to be
     rejected with the filter-axis-unknown error of Section 10.  A filter
     is a narrowing instruction the subscriber relies on; a typo that
     silently disabled the narrowing would be a privacy failure, not a
     convenience.

     Filtering is performed by the delivery substrate, not by the
     subscriber.  A subscriber that supplies a filter receives only the
     frames the filter admits; the substrate does not emit and then expect
     the subscriber to discard.  Substrate-side filtering keeps the volume
     on a constrained subscriber link proportional to what the subscriber
     asked for, rather than proportional to the handle's total fan-out
     traffic.










  Morrison                Expires 22 November 2026               [Page 17]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  10.  Error Handling

     A delivery substrate that rejects a submitted frame, or a stream-open
     request, MUST return a machine-readable error.  An error is a JSON
     object carrying a stable code string, a field naming the offending
     field where one applies, and a human-readable message.  The following
     codes are specified.

     envelope-version-unsupported  The frame's envelope_version is not
        implemented.

     kind-unknown  The frame's kind is outside the fifteen-value
        catalogue.

     payload-kind-mismatch  The frame's payload shape does not match its
        kind.

     field-missing  A REQUIRED field is absent.  field names it.

     field-invalid  A field carries a value outside the constraints of
        Section 3, 4, or 5.  field names it.

     field-unknown  The frame carries a field outside the specified set
        (Section 12). field names it.

     sender-identity-mismatch  The frame's sender_handle does not match
        the submitting session's authenticated identity.

     scope-unauthorised  The submitting session is not authorised to
        address the supplied recipient scope.

     scope-unimplemented  The supplied recipient scope is well-formed but
        the delivery substrate does not implement that scope form.

     filter-axis-unknown  A stream-open filter clause names an
        unrecognised axis.

     filter-value-invalid  A stream-open filter clause carries a value
        invalid for its axis.

     A rejection MUST NOT result in a partial delivery: either a frame is
     fully validated and entered into scope expansion, or it is rejected
     and emitted to no subscriber.








  Morrison                Expires 22 November 2026               [Page 18]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  11.  A Reference Tool Surface

     This section describes, non-normatively, the agent-runtime-facing
     verb surface of the reference deployment.  The verbs are exposed as
     Model Context Protocol [MCP] tools; an implementation MAY expose the
     same operations under any addressing convention.  The verbs are named
     here so that the wire elements of Sections 3 through 8 can be related
     to the operations an agent runtime performs.

     agent_send  Submits a single frame to a recipient scope.

     agent_advise  Submits an agent_advisory frame; a distinct verb from
        agent_send so a runtime hook can emit an advisory without
        selecting a kind.

     agent_broadcast  Submits an agent_broadcast frame to a fan-out scope.

     agent_handover  Submits an agent_handover frame, retiring the
        temporary-file fallback of Section 1.

     agent_lock_acquire, agent_lock_release, agent_lease_extend  Submit
        the three advisory lock-shaped frames of Section 4.4.

     agent_query  Submits an agent_query frame and returns the query
        identifier for the caller to correlate responses against.

     agent_roster  Returns the set of the handle's sessions currently
        subscribed to the per-handle stream, i.e. the live membership
        against which a recipient scope would expand.

     agent_subscribe  Opens the per-handle stream with an OPTIONAL filter
        expression (Section 8).

     The reference deployment exposes these verbs alongside, and distinct
     from, the verb surface by which human-readable messages are
     exchanged.  The agent-channel frame and the human-message surface
     share a delivery substrate and a per-handle stream; they are
     distinguished by the structured-versus-prose shape of their payloads
     and by the kind catalogue, which the human-message surface does not
     carry.

  12.  Composition with Companion Memos

     This memo composes with four Morrison-family Internet-Drafts and does
     not introduce a transport, a handle category, or an attribution slot
     beyond them.





  Morrison                Expires 22 November 2026               [Page 19]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     [IDPRONOUNS] supplies the ~handle namespace and the Sovereign/
     Instrument trust-tier taxonomy used by the sender_handle,
     recipient_handle, acted_by, and drafted_with fields and by the scope
     grammar of Section 6.

     [MCPDNS] supplies the discovery mechanism by which an agent runtime
     resolves the delivery substrate for a ~handle and opens the per-
     handle stream against it.

     [IDCOMMITS] supplies the tier-structured attribution grammar that the
     acted_by / drafted_with pair of Section 3.2 carries at wire time.  A
     frame's attribution pair and a commit's trailer block are the same
     shape applied at two points in a workflow.

     [IDACCORD] supplies the peer-protocol ceremony that mediates the
     accord: recipient scope of Section 6.  Cross-organisational delivery
     is grant-bounded through that ceremony; no meta-federation authority
     is introduced.

     [SUBSTRATE] supplies the coordination posture this memo deliberately
     does not duplicate.  The present memo is a delivery frame for
     messages a session chooses to send; it is not a coordination
     protocol.  Where concurrent sessions of a principal must deconflict
     conflicting action, they do so through the substrate-observation
     cascade of [SUBSTRATE].  The lock-shaped kinds of Section 4.4 are
     announcements within the present memo's delivery model and are
     explicitly not the enforcement mechanism; [SUBSTRATE] specifies how
     conflicting action is reconciled.

  13.  Extensibility

     The agent-channel frame object does not admit extension fields.  An
     implementation that receives a frame carrying a field outside the set
     specified in Sections 3, 4, and 5 MUST reject it with the field-
     unknown error of Section 10.  Closed-object validation is deliberate:
     a frame is a small routing unit on a constrained stream, and a
     silently-accepted unknown field is more likely a sender bug than a
     forward-compatible extension.

     Extension of the protocol proceeds by revision of this memo.  A new
     frame kind, a new payload field, or a new scope or filter form is
     introduced by a new envelope_version, and a receiver that does not
     implement the new version rejects frames carrying it (Section 3.1)
     rather than parsing them partially.  The fifteen-value kind catalogue
     of Section 4 is, for envelope_version "1.0", exhaustive.






  Morrison                Expires 22 November 2026               [Page 20]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  14.  IANA Considerations

     This memo requests no IANA action.

     The frame format of this memo is an application-layer JSON object
     [RFC8259] carried over the existing Server-Sent Events transport
     HTML-SSE [RFC8441]; it introduces no new media type, no new URI
     scheme, no new port, and no new DNS resource record.  The per-handle
     stream is discovered and addressed by the mechanism of [MCPDNS] and
     requires no separate allocation here.

     The fifteen kind values of Section 4, the recipient-scope forms of
     Section 6, the filter axes of Section 8, and the error codes of
     Section 10 are protocol constants of this specification.  This memo
     does not request an IANA registry for them.  Should a future
     revision, or a companion specification, propose a registry for the
     kind catalogue or the error codes (for example to permit third-party
     kind allocation), that revision will request the corresponding IANA
     action and specify the registration policy.

  15.  Security Considerations

  15.1.  Sender Spoofing

     A frame asserts a sender_handle and an acted_by / drafted_with
     attribution pair.  An unauthenticated submission path would let any
     party assert any handle.  The delivery substrate MUST authenticate
     the submitting session and MUST verify that sender_handle matches the
     authenticated identity before the frame enters scope expansion; a
     frame failing the check is rejected with sender-identity-mismatch
     (Section 10).  The substrate SHOULD additionally verify that the
     acted_by handle is the Sovereign-tier handle the authenticated
     session is bound to, so that an Instrument-tier session cannot assert
     a Sovereign-tier acted_by other than its own principal's.

  15.2.  Scope-Authorisation Bypass

     The recipient-scope grammar of Section 6 lets a sender address a set
     rather than an endpoint.  A sender that could address an arbitrary
     scope could deliver unsolicited frames to any handle or any
     organisation's members.  The delivery substrate MUST refuse a scope
     the submitting session is not authorised to address: a scope naming a
     foreign handle, an org: scope of an organisation that does not
     recognise the sender, or an accord: scope absent a grant.
     Authorisation is checked at submission time, before scope expansion;
     a frame failing the check is rejected with scope-unauthorised and
     reaches no subscriber.




  Morrison                Expires 22 November 2026               [Page 21]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  15.3.  Fan-Out Amplification

     A single submitted frame to a broad scope (org:<org-
     handle>/members/*) expands to many emitted events.  An attacker in
     possession of a member credential could submit frames at a high rate
     to amplify load across an organisation's subscribers.  Delivery
     substrates SHOULD rate-limit submissions per authenticated sender,
     SHOULD cap the cardinality a single scope expansion may produce, and
     SHOULD apply the per-frame size bounds of Section 5 so that an
     amplified frame is at least small.  The convergence kinds of
     Section 4.7 are themselves a load-reduction mechanism (they let a set
     of sessions collapse many intended effects into one), and a substrate
     MAY treat a high rate of intent_declare frames without corresponding
     flush_executed frames as an abuse signal.

  15.4.  Lock-Shaped Frames Are Not Authority

     The agent_lock_request, agent_lock_release, and agent_lease_extend
     kinds are advisory announcements (Section 4.4).  A reader, or an
     implementer, who treats them as an enforcement mechanism introduces a
     security defect: a recipient that _relies_ on a received
     agent_lock_request to guarantee exclusive access has trusted an
     unenforceable announcement, and an attacker who suppresses or forges
     such a frame can induce a recipient to act, or to refrain from
     acting, incorrectly.  Mutual exclusion, where an implementation
     requires it, MUST be enforced by a local mechanism (a filesystem
     advisory lock, an operating-system lease) that does not depend on
     frame delivery.  The lease identifier carried by these frames is a
     correlation value and MUST NOT be treated by the delivery substrate
     as a key into a lock table.

  15.5.  Replay and Duplication

     A frame carries a sender-generated frame_id.  An attacker positioned
     on the transport could re-deliver an aged frame to refresh a
     recipient's view of stale state, for example by replaying an
     agent_advisory to make a long-departed session appear active.  The
     per-frame ttl_ms bounds the window in which a recipient treats a
     frame's content as operative, and a recipient SHOULD discard a frame
     whose created_at plus ttl_ms lies in the past.  A recipient SHOULD
     additionally de-duplicate by frame_id so a duplicated delivery of the
     same frame is processed once.  Because the lock-shaped frames are not
     authority (above), a replayed lock-shaped frame cannot, by itself,
     grant or revoke access; its worst effect is a stale advisory, bounded
     by ttl_ms.






  Morrison                Expires 22 November 2026               [Page 22]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  15.6.  Diagnostic-Frame Information Disclosure

     A peer_diagnostic_request carries a symptom description and
     observation references; a peer_diagnostic_response carries a finding
     and a remediation.  These may disclose configuration, file paths, or
     operational detail a sender did not intend to expose beyond its own
     sessions.  A sender SHOULD scope diagnostic frames no more broadly
     than the troubleshooting requires, preferring point-to-point or its
     own sessions over an org: scope, and SHOULD redact secret material
     from a symptom description before submission.

  16.  Privacy Considerations

  16.1.  Recipient-Scope Membership Inference

     The submission result of Section 7.1 reports the count of
     subscriptions a frame was emitted to.  A sender that submits frames
     to successively narrower scopes can, from the reported counts, infer
     how many of a handle's sessions, or an organisation's members'
     sessions, are currently online.  A delivery substrate SHOULD consider
     whether to report an exact count or a coarsened one, and SHOULD
     restrict the agent_roster operation of Section 9, which enumerates a
     handle's live sessions, to the handle's own sessions and to parties
     the handle has authorised.

  16.2.  Attribution Exposure

     Every frame carries an acted_by Sovereign-tier handle and a
     drafted_with Instrument-tier handle.  Within a fan-out, every
     recipient of a frame learns the sending principal's identity and the
     runtime that composed the frame.  This is intentional; the
     attribution pair is the basis on which a recipient assesses a frame.
     A sender should be aware that an org: or accord: scope discloses the
     attribution pair to every member of the addressed set.  A sender that
     wishes to limit attribution exposure SHOULD prefer the narrowest
     scope that reaches the intended recipients.

  16.3.  Provenance-Block Content

     The provenance block of Section 3.3 carries a compute-location, a set
     of derivation-method tags, and a stream-basis tag.  These describe
     how the frame's content was produced and may, in aggregate across
     many frames, characterise a sender's working pattern.  The block is
     carried for the recipient's benefit; a sender SHOULD populate
     provenance_method and provenance_basis with tags no more specific
     than a recipient needs to assess the frame, and an implementation
     SHOULD NOT require the block to carry identifying detail beyond the
     derivation method.



  Morrison                Expires 22 November 2026               [Page 23]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


  16.4.  Ephemerality as a Privacy Property

     This memo specifies delivery, not storage (Section 1, Section 7.3).
     A frame delivered and not retained leaves no standing record on the
     delivery substrate beyond the substrate's transient processing of it.
     Where an implementation chooses to retain delivered frames for stream
     resumption, that retention is a privacy-relevant decision the
     implementation makes outside this specification: a retained frame is
     a record of who said what to whom, and the retention horizon, access
     controls, and deletion behaviour of any such store SHOULD be
     specified by the implementation and surfaced to the principals whose
     frames it retains.  The convergence kinds of Section 4.7 carry an
     explicit decay horizon (ttl on intent_declare) precisely so that the
     announcement of an intended effect is, by design, forgotten once the
     window for the effect has closed.

  17.  References

  17.1.  Normative References

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

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

     [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/info/rfc8259>.

     [RFC8441]  McManus, P., "Bootstrapping WebSockets with HTTP/2",
                RFC 8441, DOI 10.17487/RFC8441, September 2018,
                <https://www.rfc-editor.org/info/rfc8441>.

     [MCPDNS]   Morrison, B., "Discovery of Model Context Protocol Servers
                via DNS TXT Records", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-
                discovery/>.

     [IDPRONOUNS]
                Morrison, B., "Identity Pronouns: A Reference-Axis
                Extension to ~handle Identity Systems", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                pronouns/>.



  Morrison                Expires 22 November 2026               [Page 24]


  Internet-Draft            Agent-Channel Fan-Out                 May 2026


     [IDACCORD] Morrison, B., "Identity Accord Protocol", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                accord/>.

     [IDCOMMITS]
                Morrison, B., "Identity-Attributed Git Commits via Tier-
                Structured Trailers", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-identity-
                attributed-commits/>.

     [SUBSTRATE]
                Morrison, B., "Substrate-Observation as an Alternative to
                Envelope Coordination for Concurrent Sessions", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-
                substrate-observation/>.

     [MCP]      Agentic AI Foundation, "Model Context Protocol
                Specification", 2026, <https://modelcontextprotocol.io>.

  17.2.  Informative References

     [HTML-SSE] WHATWG, "HTML Living Standard, Section 9.2: Server-Sent
                Events", 2026, <https://html.spec.whatwg.org/multipage/
                server-sent-events.html>.

  Acknowledgements

     This memo grew out of internal architectural work on how the several
     concurrent agentic sessions of a single principal, today reduced to
     passing a file through a shared temporary directory, should instead
     exchange short structured messages over an identity-keyed delivery
     substrate.  The realisation that the needed primitive is a fan-out
     _delivery_ frame, and that coordination, as distinct from delivery,
     is better left to substrate observation than standardised as an
     envelope, is the load-bearing insight behind this specification and
     its companion memo [SUBSTRATE].

  Author's Address

     Blake Morrison
     Alter Meridian Pty Ltd (~truealter)
     Email: blake@truealter.com
     URI:   alter:~blake








  Morrison                Expires 22 November 2026               [Page 25]


name: draft-kroehl-agentic-trust-aae
rev: 00
time: 2026-05-22T05:12:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-22T21:48:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/68/"]
categories: ["Agent identity/auth", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698428+00:00
source: ietf
title:
  Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents

abstract:
  Autonomous AI agents now operate at production scale across
     financial, commercial, and infrastructure domains — executing
     transactions, invoking APIs, and taking consequential actions without
     direct human oversight at each step.  Existing authorization
     mechanisms (OAuth 2.0, API keys, ACLs) were designed for human-
     initiated requests and do not capture the machine-evaluable semantics
     required for autonomous agent authorization: what the agent is
     mandated to do, what constraints bound its actions, and for how long
     the authorization is valid.

     This document specifies the Agent Authorization Envelope (AAE), a
     structured authorization container for autonomous AI agents.  AAE
     defines three mandatory blocks — MANDATE, CONSTRAINTS, and VALIDITY —
     that together constitute a machine-evaluable, cryptographically
     verifiable authorization assertion.  AAE is designed to be protocol-
     agnostic, binding to W3C Decentralized Identifiers (DIDs) for agent
     identity and W3C Verifiable Credentials (VCs) for issuance and
     signature, and is independent of any specific AI framework, transport
     protocol, or blockchain.

full_text:
  Independent Submission                                      L. K. Kroehl
  Internet-Draft                                            CryptoKRI GmbH
  Intended status: Informational                               21 May 2026
  Expires: 22 November 2026


   Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization
                     Structure for Autonomous AI Agents
                     draft-kroehl-agentic-trust-aae-00

  Abstract

     Autonomous AI agents now operate at production scale across
     financial, commercial, and infrastructure domains — executing
     transactions, invoking APIs, and taking consequential actions without
     direct human oversight at each step.  Existing authorization
     mechanisms (OAuth 2.0, API keys, ACLs) were designed for human-
     initiated requests and do not capture the machine-evaluable semantics
     required for autonomous agent authorization: what the agent is
     mandated to do, what constraints bound its actions, and for how long
     the authorization is valid.

     This document specifies the Agent Authorization Envelope (AAE), a
     structured authorization container for autonomous AI agents.  AAE
     defines three mandatory blocks — MANDATE, CONSTRAINTS, and VALIDITY —
     that together constitute a machine-evaluable, cryptographically
     verifiable authorization assertion.  AAE is designed to be protocol-
     agnostic, binding to W3C Decentralized Identifiers (DIDs) for agent
     identity and W3C Verifiable Credentials (VCs) for issuance and
     signature, and is independent of any specific AI framework, transport
     protocol, or blockchain.

  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 22 November 2026.



  Kroehl                  Expires 22 November 2026                [Page 1]


  Internet-Draft                     AAE                          May 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Regulatory Convergence  . . . . . . . . . . . . . . . . .   3
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  The Agent Authorization Envelope  . . . . . . . . . . . . . .   5
       2.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  The MANDATE Block . . . . . . . . . . . . . . . . . . . .   6
       2.3.  The CONSTRAINTS Block . . . . . . . . . . . . . . . . . .   7
       2.4.  The VALIDITY Block  . . . . . . . . . . . . . . . . . . .   8
     3.  Delegation Chains . . . . . . . . . . . . . . . . . . . . . .   9
     4.  Action Vocabulary Schemas . . . . . . . . . . . . . . . . . .  12
     5.  Verification Algorithm  . . . . . . . . . . . . . . . . . . .  13
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
       6.1.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  15
       6.2.  Constraint Bypass . . . . . . . . . . . . . . . . . . . .  15
       6.3.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  16
       6.4.  Delegation Amplification  . . . . . . . . . . . . . . . .  16
       6.5.  Delegation Revocation . . . . . . . . . . . . . . . . . .  16
       6.6.  Clock Skew and Time Synchronization . . . . . . . . . . .  16
       6.7.  On-Chain Anchoring  . . . . . . . . . . . . . . . . . . .  16
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
       8.1.  Media Type Registration . . . . . . . . . . . . . . . . .  17
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
     Appendix A.  Example: Travel Booking Agent  . . . . . . . . . . .  20
     Appendix B.  Relationship to Existing Standards . . . . . . . . .  21
     Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  22
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22









  Kroehl                  Expires 22 November 2026                [Page 2]


  Internet-Draft                     AAE                          May 2026


  1.  Introduction

     The deployment of autonomous AI agents at scale creates an
     authorization gap that existing Internet protocols do not address.
     When a human user initiates a request, the authorization question is
     well-understood: who is the user, what are they permitted to do, and
     has their session expired?  Protocols such as OAuth 2.0 [RFC6749]
     answer these questions for human-delegated access.

     When an autonomous agent initiates a request — potentially on behalf
     of another agent, under a delegated mandate, with specific
     constraints on permissible actions — the question requires a
     different answer.  The agent may be acting under a mandate issued
     hours earlier; its actions may be bounded by value caps, action
     allowlists, or domain restrictions; and the authorization may expire
     on a schedule that the receiving system must be able to verify
     without contacting the issuing party.

     No current IETF standard addresses this combination of requirements
     for autonomous agents.  OAuth 2.0 scopes are issuer-defined strings
     without machine-evaluable semantics for agent mandates.  SPIFFE/SVID
     addresses workload identity but not authorization semantics.  JWT
     claims are flexible but unstructured for agent-specific use cases.

     This document specifies the Agent Authorization Envelope (AAE) to
     fill this gap.  AAE is derived from a production deployment
     operational since March 2026 [ARXIV-AAE] and is aligned with
     regulatory requirements from Singapore IMDA [IMDA-MGF], NIST
     [NIST-CAISI], and the EU AI Act (Regulation 2024/1689).

  1.1.  Regulatory Convergence

     Independent regulatory work has converged on the same authorization
     structure that AAE implements.  Two requirements from the Singapore
     IMDA Model AI Governance Framework for Agentic AI, Version 1.5
     [IMDA-MGF], published 20 May 2026, are directly relevant.

     First, on agent identity (§2.1.2, "Agent identity — Identification"),
     the framework states:

        An agent should have its own unique, cryptographically verifiable
        identity, such that it can identify itself to the organisation,
        its human user, or other agents.

     The framework further recommends that agent identities be catalogued
     and centrally managed, issued from and tracked by a centralised
     system — the operational model that a DID-based trust registry
     implements.



  Kroehl                  Expires 22 November 2026                [Page 3]


  Internet-Draft                     AAE                          May 2026


     Second, on authorization scope (§2.1.2, "Authorisation"), the
     framework recommends that authorisations be scoped, time- or session-
     bound, non-transferable, and follow the principle of least privilege
     by default with explicit escalation paths; that they be bounded by
     the authorising human's permissions; and that delegations of
     authority be clearly recorded.

     This maps directly to the three AAE blocks: MANDATE defines the scope
     and action allowlist, CONSTRAINTS implement least-privilege and value
     bounds, VALIDITY enforces time-bound non-transferable authorization,
     and the delegation chain structure records authority provenance
     (Section 3).

     A case study in the same framework (§2.3, "Terminal 3 case study")
     describes an independent implementation of the same pattern: a
     "Verifiable Credential of Intent" issued by a human principal to an
     agent before each cycle, defining accessible records, applicable
     constraints, and a declared ceiling amount.  This is a real-world
     deployment of pre-transaction scoped authorization that is
     structurally equivalent to AAE.

  1.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 that takes actions on behalf
     of a principal, potentially without per-action human approval.

     *Principal:* The human or organization that deploys and is ultimately
     accountable for an agent's actions.

     *Issuer:* The entity that issues the AAE, typically a trust registry
     or the principal directly.

     *Relying Party:* The system or service that receives a request from
     an agent and evaluates the AAE to determine whether to process it.

     *AAE:* Agent Authorization Envelope — the structured authorization
     container defined in this document.








  Kroehl                  Expires 22 November 2026                [Page 4]


  Internet-Draft                     AAE                          May 2026


  2.  The Agent Authorization Envelope

     An AAE is a W3C Verifiable Credential [W3C-VC] whose
     credentialSubject carries an aae object.  The aae object has three
     mandatory members — mandate, constraints, and validity — defined in
     the following subsections.

     An AAE MUST be secured using JOSE.  The Verifiable Credential is the
     payload of a JSON Web Signature (JWS) [RFC7515] in compact
     serialization, signed by the issuer using the Edwards-curve Digital
     Signature Algorithm (EdDSA) with the Ed25519 curve, as specified for
     JOSE in [RFC8037] and for the signature algorithm itself in
     [RFC8032].  The issuer's signing key is a JSON Web Key (JWK)
     [RFC7517] bound to the issuer's W3C DID [W3C-DID]: the JWS protected-
     header kid parameter MUST be a DID URL that dereferences, via the
     issuer DID document, to the corresponding verification method.

     This document distinguishes two media types.  An _unsecured AAE_ —
     the Verifiable Credential before JWS encapsulation — is a JSON object
     with media type application/aae+json (Section 8).  A _secured AAE_ —
     the JWS in compact serialization — is not a JSON document; it is
     transported with media type application/jose [RFC7515], and the media
     type of its JWS payload is indicated by the cty protected-header
     parameter, "aae+json".

  2.1.  Structure

     On the wire, a secured AAE is a JWS in compact serialization:

     BASE64URL(UTF8(JWS Protected Header)) || '.' ||
     BASE64URL(JWS Payload) || '.' ||
     BASE64URL(JWS Signature)

     The JWS Protected Header MUST contain:

     {
       "alg": "EdDSA",
       "cty": "aae+json",
       "kid": "did:moltrust:registry#key-1"
     }

     alg: REQUIRED.  MUST be "EdDSA"; the curve MUST be Ed25519, as
     specified for JOSE in [RFC8037].








  Kroehl                  Expires 22 November 2026                [Page 5]


  Internet-Draft                     AAE                          May 2026


     cty: REQUIRED.  The media type of the JWS payload; MUST be "aae+json"
     (Section 8).  The "application/" prefix is omitted as permitted by
     [RFC7515].  Per [RFC7515], cty (content type) identifies the secured
     payload; the typ parameter, if present, identifies the JWS object
     itself and MUST NOT carry the payload media type.

     kid: REQUIRED.  A DID URL identifying the issuer verification method.
     It MUST dereference, via the issuer DID document, to an Ed25519
     verification method authorized for the assertionMethod proof purpose.

     The JWS Payload is the unsecured AAE: a W3C Verifiable Credential
     whose media type is application/aae+json (Section 8).

     {
       "@context": [
         "https://www.w3.org/ns/credentials/v2",
         "https://moltrust.ch/contexts/aae/v1"
       ],
       "type": ["VerifiableCredential", "AgentAuthorizationEnvelope"],
       "id": "urn:uuid:3f2b8c10-7c2e-4f1a-9b6d-1e2a3c4d5e6f",
       "issuer": "did:moltrust:registry",
       "validFrom": "2026-05-20T10:00:00Z",
       "credentialSubject": {
         "id": "did:example:agent-abc123",
         "aae": {
           "mandate": { ... },
           "constraints": { ... },
           "validity": { ... }
         }
       }
     }

     The Verifiable Credential MUST contain an id member whose value is a
     URI [RFC3986] that is globally unique across all AAEs issued by the
     issuer (for example, a UUID URN [RFC9562]).  The Verifiable
     Credential MUST NOT contain an embedded proof member; integrity and
     authenticity are provided solely by the enclosing JWS.

  2.2.  The MANDATE Block

     The MANDATE block specifies what the agent is authorized to do.  It
     MUST contain an actions array of permitted action identifiers and
     SHOULD contain a purpose string describing the authorization context.








  Kroehl                  Expires 22 November 2026                [Page 6]


  Internet-Draft                     AAE                          May 2026


     "mandate": {
       "actions": ["read", "book", "pay"],
       "purpose": "Travel booking on behalf of principal",
       "scope": "travel-vertical",
       "principal_did": "did:example:principal-xyz"
     }

     actions: REQUIRED.  Array of strings.  Each string is a permitted
     action identifier.  Relying parties define their own action
     vocabularies; interoperability is achieved through shared vertical
     schemas (see Section 4).

     purpose: RECOMMENDED.  Human-readable description of the
     authorization context.  Used for audit logs.

     scope: OPTIONAL.  Restricts the MANDATE to a specific vertical or
     service domain.

     principal_did: RECOMMENDED.  The DID of the human or organization
     ultimately accountable for the agent's actions.

     The MANDATE block MAY also contain a delegation object or a
     delegation_policy object; both are defined in Section 3.

  2.3.  The CONSTRAINTS Block

     The CONSTRAINTS block specifies limits that bound the agent's actions
     within the MANDATE.

     Relying parties MUST enforce all constraints they recognize.  A
     relying party MUST reject an AAE if any constraint marked required:
     true is unrecognized or cannot be evaluated.  A relying party MAY
     ignore an unrecognized constraint only if that constraint is
     explicitly marked required: false.  If the required member is absent,
     the constraint MUST be treated as required: true.
















  Kroehl                  Expires 22 November 2026                [Page 7]


  Internet-Draft                     AAE                          May 2026


     "constraints": {
       "max_transaction_value": {
         "value": 500,
         "currency": "USD",
         "required": true
       },
       "allowed_domains": {
         "value": ["booking.example.com", "flights.example.com"],
         "required": true
       },
       "rate_limit": {
         "value": 10,
         "window": "PT1H",
         "required": false
       }
     }

     Constraint keys are extensible.  This document defines three
     RECOMMENDED constraint types:

     *  max_transaction_value: Maximum value of any single transaction.
        MUST include value (number) and currency (ISO 4217).

     *  allowed_domains: Allowlist of domains the agent may contact.

     *  rate_limit: Maximum number of actions per time window.  MUST
        include value (integer) and window (an ISO 8601 duration, e.g.,
        "PT1H").

     A relying party that enforces a rate_limit constraint marked
     required: true MUST maintain sufficient state to count accepted
     actions within the specified window.  A relying party that cannot
     maintain such state MUST reject an AAE containing a required
     rate_limit constraint.

  2.4.  The VALIDITY Block

     The VALIDITY block specifies the temporal bounds of the
     authorization.

     "validity": {
       "not_before": "2026-05-20T10:00:00Z",
       "not_after": "2026-05-20T18:00:00Z",
       "revocation_check": "https://api.moltrust.ch/aae/revocation/{id}",
       "single_use": false
     }





  Kroehl                  Expires 22 November 2026                [Page 8]


  Internet-Draft                     AAE                          May 2026


     not_before: REQUIRED.  An RFC 3339 [RFC3339] date-time, expressed in
     UTC with the "Z" offset.  The AAE MUST NOT be accepted before this
     time.

     not_after: REQUIRED.  An RFC 3339 [RFC3339] date-time, expressed in
     UTC with the "Z" offset.  The AAE MUST NOT be accepted after this
     time.  Relying parties MUST reject expired AAEs.

     revocation_check: OPTIONAL.  An HTTPS URI Template [RFC6570] for
     checking AAE revocation status.  The template MUST support the {id}
     variable, expanding (with URI encoding) to the Verifiable Credential
     id, and SHOULD support the {did} variable, expanding to
     credentialSubject.id.  If revocation_check is present, the relying
     party MUST query the endpoint over HTTPS; the response MUST be a JSON
     object containing at least an id member and a boolean revoked member.
     The relying party MUST reject the AAE if the endpoint indicates
     revoked: true or if the response cannot be parsed.  If revocation
     status cannot be determined — for example, on network failure or an
     HTTP 5xx response — the relying party MUST reject the AAE.  A relying
     party MAY apply an explicit, locally configured, auditable fail-open
     policy only for AAEs whose risk classification permits such
     behaviour; such a policy SHOULD NOT be used for high-risk actions and
     MUST be subject to explicit governance and audit logging.

     single_use: OPTIONAL.  Boolean.  Default: false.  If true, the
     relying party MUST maintain state keyed by the Verifiable Credential
     id (Section 2.1) and MUST reject any subsequent presentation of an
     AAE bearing the same id after the first successful authorization.  A
     relying party that cannot maintain such state MUST reject any AAE
     with single_use: true.  Where a relying party is deployed across
     multiple nodes, the single-use state MUST be shared across all nodes
     that can accept the AAE; otherwise the AAE could be replayed against
     a different node.  In this document, "invalidation" denotes relying-
     party-local state; it does not invalidate the AAE globally.

     If the Verifiable Credential contains a validFrom member, the relying
     party MUST NOT accept the AAE before the later of validFrom and
     validity.not_before.  Issuers SHOULD set validFrom equal to or
     earlier than validity.not_before.

  3.  Delegation Chains

     An agent may act under a mandate delegated from another agent.  An
     AAE issued directly by a principal, and not itself delegated, is a
     _root AAE_: it has no delegation member, and its effective delegation
     depth is 0.  A root AAE that authorizes onward delegation MUST
     include a delegation_policy object in its MANDATE block with a non-
     negative integer max_depth member; this value is the parent's



  Kroehl                  Expires 22 November 2026                [Page 9]


  Internet-Draft                     AAE                          May 2026


     effective maximum depth for the first delegation link.

     "mandate": {
       "actions": ["read", "book"],
       "delegation_policy": { "max_depth": 2 }
     }

     A _delegated AAE_ carries a delegation object in its MANDATE block:

     "mandate": {
       "actions": ["read"],
       "delegation": {
         "delegator_did": "did:example:parent-agent",
         "delegator_aae_id": "urn:uuid:parent-aae-123",
         "delegator_aae_uri": "https://aae.example/p/parent-aae-123",
         "delegator_aae_hash": "sha-256:5b7e2c...",
         "depth": 1,
         "max_depth": 2
       }
     }

     delegator_did: REQUIRED in delegation context.  The DID of the
     delegating agent.

     delegator_aae_id: REQUIRED in delegation context.  The id of the
     parent AAE.

     delegator_aae_uri: REQUIRED in delegation context, unless the parent
     AAE is embedded in the request by the transport binding.  A URI from
     which the relying party can retrieve the parent AAE.

     delegator_aae_hash: OPTIONAL.  A hash of the parent secured AAE.  If
     present, the value MUST have the form sha-256:<base64url-encoded-
     digest>.  The digest input MUST be the exact ASCII octet sequence of
     the parent AAE JWS compact serialization as retrieved, without
     additional whitespace, decoding, re-encoding, or JSON
     canonicalization.  SHA-256 is as defined in [RFC6234].  If the
     computed digest does not match the value in delegator_aae_hash, the
     relying party MUST reject the delegated AAE.

     depth: REQUIRED in delegation context.  Integer.  The delegation
     depth of this AAE.  It MUST equal the parent AAE's effective
     delegation depth plus 1.  The effective delegation depth of a root
     AAE is 0; the effective delegation depth of a delegated AAE is its
     delegation.depth.






  Kroehl                  Expires 22 November 2026               [Page 10]


  Internet-Draft                     AAE                          May 2026


     max_depth: REQUIRED in delegation context.  Integer.  The maximum
     delegation depth permitted for this branch of the chain.  It MUST be
     less than or equal to the parent AAE's effective maximum depth — the
     parent's delegation.max_depth if the parent is a delegated AAE, or
     the root AAE's mandate.delegation_policy.max_depth if the parent is a
     root AAE.  A relying party MUST reject a delegated AAE whose depth
     exceeds its max_depth, and MUST reject any delegation whose parent is
     a root AAE that has no delegation_policy.

     A relying party MUST be able to retrieve the parent AAE in order to
     verify a delegation chain.  The parent AAE's credentialSubject.id
     MUST equal the delegated AAE's delegation.delegator_did.  Which DID
     is permitted to sign a delegated AAE — the signing-authority rule —
     is specified in the Verification Algorithm (Section 5).

     Delegated AAEs MUST NOT grant actions not present in the parent AAE.
     Delegated AAEs MUST be strictly subordinate to their parent AAE.  For
     the purposes of this document, "equal to or more restrictive" is
     defined per element as follows:

     *  *Actions*: The delegated mandate.actions MUST be a subset of the
        parent mandate.actions.  If the delegated MANDATE contains the
        delegate action, the parent MANDATE MUST also contain it.

     *  *Numeric upper-bound constraints* (for example,
        max_transaction_value): The delegated value MUST be less than or
        equal to the parent value.

     *  *Rate-limit constraints* (rate_limit): A delegated rate_limit
        constraint is equal to or more restrictive than the parent only if
        the relying party can prove that no execution pattern permitted by
        the delegated rate limit would violate the parent rate limit.  In
        the absence of a profile defining such comparison semantics, the
        delegated rate_limit MUST use the same window value as the parent
        constraint, and the delegated value MUST be less than or equal to
        the parent value; if the windows differ and no such profile
        applies, the delegated AAE MUST be rejected.

     *  *Allowlist constraints* (for example, allowed_domains): The
        delegated value MUST be a subset of the parent value.

     *  *Validity*: The delegated validity.not_before MUST be greater than
        or equal to the parent validity.not_before, and the delegated
        validity.not_after MUST be less than or equal to the parent
        validity.not_after.






  Kroehl                  Expires 22 November 2026               [Page 11]


  Internet-Draft                     AAE                          May 2026


     *  *Delegation depth*: The delegated delegation.depth MUST equal the
        parent AAE's effective delegation depth plus 1; the delegated
        delegation.max_depth MUST be less than or equal to the parent
        AAE's effective maximum depth; and delegation.depth MUST NOT
        exceed delegation.max_depth.

     Every constraint present in the parent AAE that is marked required:
     true, or for which the required member is absent and is therefore
     treated as required: true (Section 2.3), MUST also be present in the
     delegated AAE and MUST either be marked required: true or omit the
     required member.  A delegated AAE MUST NOT omit, downgrade, or change
     to required: false any parent constraint that is required by this
     rule.  A delegated AAE MAY introduce additional constraints, provided
     they do not contradict the parent constraints.  For currency-valued
     constraints (for example, max_transaction_value), the delegated
     constraint MUST use the same currency as the parent constraint,
     unless the relying party has an explicitly configured and auditable
     currency-conversion policy; if the currencies differ and no such
     policy exists, the delegated AAE MUST be rejected.

     If a relying party cannot determine whether a delegated element is
     equal to or more restrictive than the corresponding parent element,
     the delegated AAE MUST be rejected.

  4.  Action Vocabulary Schemas

     Interoperability across relying parties requires shared action
     vocabularies.  This document defines a minimal common vocabulary:

           +==========+===========================================+
           | Action   | Semantics                                 |
           +==========+===========================================+
           | read     | Retrieve information without side effects |
           +----------+-------------------------------------------+
           | write    | Create or modify state                    |
           +----------+-------------------------------------------+
           | delete   | Remove state                              |
           +----------+-------------------------------------------+
           | pay      | Initiate a payment or financial transfer  |
           +----------+-------------------------------------------+
           | invoke   | Call an external API or service           |
           +----------+-------------------------------------------+
           | delegate | Issue a delegated AAE to a sub-agent      |
           +----------+-------------------------------------------+

                                   Table 1





  Kroehl                  Expires 22 November 2026               [Page 12]


  Internet-Draft                     AAE                          May 2026


     Vertical-specific vocabularies (travel, finance, healthcare) SHOULD
     be published as extensions to this base vocabulary, as stable and
     versioned schemas at publicly accessible URIs.  This document does
     not create an IANA registry for action vocabularies.

  5.  Verification Algorithm

     A relying party receiving an agent request with an attached AAE MUST
     perform the following checks in order:

     1.  *Signature verification*: Parse the JWS in compact serialization
         and read the protected header.  The _signing DID_ is the DID
         portion of the kid parameter.  Resolve the signing DID,
         dereference the referenced verification method, and confirm that
         (a) the verification method is present in that DID document, (b)
         it is authorized for the assertionMethod proof purpose, (c) it
         contains or resolves to a JWK with kty: "OKP" and crv: "Ed25519",
         and (d) the JWS signature validates under that key.  Reject the
         AAE if the signing DID cannot be resolved, the verification
         method is absent or not authorized for assertionMethod, the key
         is not Ed25519, the alg is not "EdDSA", or the signature is
         invalid.

         The relying party MUST then verify signing authority.  For a non-
         delegated AAE (no mandate.delegation member), the signing DID
         MUST be identical to the Verifiable Credential issuer.  For a
         delegated AAE, the signing DID MUST satisfy one of the following:
         (a) it is identical to mandate.delegation.delegator_did, and the
         Verifiable Credential issuer is also identical to that DID; or
         (b) it is explicitly authorized by
         mandate.delegation.delegator_did to issue delegated AAEs on that
         delegator's behalf, where the authorization is represented by a
         verification method or service entry in the delegator's DID
         document.  If signing authority cannot be established under the
         applicable rule — or, for case (b), the relying party does not
         understand the authorization mechanism — the AAE MUST be
         rejected.

     2.  *Payload and schema validation*: Parse the JWS payload as UTF-
         8-encoded JSON.  The payload MUST be a W3C Verifiable Credential
         containing id, issuer, credentialSubject.id, and
         credentialSubject.aae.  The aae object MUST contain mandate,
         constraints, and validity.  The protected-header cty parameter
         MUST equal "aae+json".  Reject the AAE if any required member is
         absent, has the wrong JSON type, or otherwise violates the
         structural requirements of this document.





  Kroehl                  Expires 22 November 2026               [Page 13]


  Internet-Draft                     AAE                          May 2026


     3.  *Temporal validity*: Confirm current time is within not_before
         and not_after.  Reject if outside bounds.

     4.  *Subject binding*: Confirm the agent presenting the AAE controls
         credentialSubject.id.  The relying party MUST generate a fresh,
         unpredictable nonce with at least 128 bits of entropy and send it
         to the agent together with a relying-party audience identifier.
         The agent MUST return a JWS in compact serialization whose
         payload is the UTF-8 encoding of a JSON object with exactly these
         members:

        {
          "nonce":  "<relying-party nonce>",
          "aud":    "<relying-party audience identifier>",
          "iat":    "<RFC 3339 UTC timestamp>",
          "aae_id": "<Verifiable Credential id>"
        }

         The challenge-response JWS protected header MUST contain "alg":
         "EdDSA" and a kid DID URL whose DID portion equals
         credentialSubject.id.  The referenced verification method MUST be
         authorized under the authentication relationship in the resolved
         DID document.  The relying party MUST reject the AAE unless all
         of the following hold: (a) the challenge-response signature is
         valid under a key controlled by credentialSubject.id; (b) the
         verification method is authorized for authentication; (c) the
         nonce was generated by this relying party and has not been used
         before; (d) aud identifies this relying party; (e) aae_id equals
         the Verifiable Credential id; and (f) iat is within the relying
         party's accepted clock-skew window.

     5.  *Single-use check*: If validity.single_use is true, the relying
         party MUST perform an atomic check-and-record operation keyed by
         the Verifiable Credential id.  An id that has already been
         recorded MUST be rejected.  Where the relying party is deployed
         across multiple nodes, this state MUST be shared across all
         nodes; concurrent presentations of the same id MUST NOT both
         succeed.

     6.  *Action check*: Confirm the requested action is present in
         mandate.actions.  Reject if absent.

     7.  *Constraint evaluation*: For each constraint in the CONSTRAINTS
         block, the relying party MUST enforce every constraint it
         recognizes.  If a recognized constraint marked required: true (or
         with required absent) cannot be evaluated, the relying party MUST
         reject the AAE.  If a recognized constraint marked required:
         false cannot be evaluated, the relying party MAY ignore that



  Kroehl                  Expires 22 November 2026               [Page 14]


  Internet-Draft                     AAE                          May 2026


         constraint.  If a constraint is unrecognized, the relying party
         MUST reject the AAE unless that constraint is explicitly marked
         required: false.  The relying party MUST reject the AAE if any
         enforced constraint is violated.

     8.  *Revocation check* (if applicable): If validity.revocation_check
         is present, the relying party MUST query the endpoint over HTTPS
         and evaluate the result as specified for revocation_check in
         Section 2.4, including the limited fail-open exception defined
         there.

     9.  *Delegation chain* (if applicable): If the AAE contains a
         delegation field, the relying party MUST verify every ancestor
         AAE in the chain.  The signature, payload-and-schema, temporal-
         validity, and revocation checks above apply to each ancestor AAE.
         The subject-binding and single-use checks MUST NOT be performed
         for ancestor AAEs: ancestor agents are not required to be online
         to answer a challenge, and single-use state applies only to the
         presented AAE.  For each delegation link, the relying party MUST
         verify that the parent AAE's credentialSubject.id equals the
         child's delegation.delegator_did; that the signing authority of
         each AAE in the chain holds as specified in step 1; and that
         constraint monotonicity and depth limits hold as defined in
         Section 3.  To detect cycles, the relying party MUST maintain the
         set of AAE id values already visited in the current verification
         path and MUST reject the chain immediately if any id appears more
         than once.  The relying party MUST enforce an implementation-
         defined maximum recursion limit no greater than the smallest
         max_depth value observed in the chain.

     Steps 1–7 are REQUIRED.  Steps 8–9 are conditional on presence of the
     relevant fields.

  6.  Security Considerations

  6.1.  Replay Attacks

     AAEs with broad temporal validity windows are susceptible to replay
     attacks.  Implementations SHOULD use short not_after windows (minutes
     to hours for high-value actions) and SHOULD implement nonce-based
     replay protection at the transport layer.

  6.2.  Constraint Bypass

     Relying parties that silently ignore unrecognized constraints create
     a security gap.  Relying parties MUST treat unrecognized constraints
     with required: true as grounds for rejection.




  Kroehl                  Expires 22 November 2026               [Page 15]


  Internet-Draft                     AAE                          May 2026


  6.3.  Key Compromise

     If an issuer's signing key is compromised, all AAEs signed by that
     key are potentially invalid.  Issuers MUST have an operational key-
     rotation procedure and SHOULD publish revocation endpoints.  Issuers
     SHOULD retain verification material for retired signing keys for at
     least as long as AAEs signed by those keys can remain valid, unless a
     key was retired because of compromise.  Issuers SHOULD provide a
     mechanism for real-time revocation signaling to relying parties;
     continuous access evaluation profiles defined by other standards
     bodies are one such mechanism.

  6.4.  Delegation Amplification

     Delegation chains that do not enforce constraint monotonicity allow
     sub-agents to acquire permissions exceeding those of their parent.
     Implementations MUST enforce that delegated AAEs are strictly
     subordinate to their parent AAEs in actions, constraints, and
     validity.

  6.5.  Delegation Revocation

     If a parent AAE or a delegator agent is compromised, the issuer
     SHOULD treat all downstream delegated AAEs as revoked.  A relying
     party that determines that a parent AAE in a delegation chain has
     been revoked SHOULD treat all descendant AAEs in that chain as
     invalid.

  6.6.  Clock Skew and Time Synchronization

     AAE validity depends on relying-party evaluation of not_before,
     not_after, and challenge-response timestamps.  Relying parties SHOULD
     use authenticated time synchronization and SHOULD define a maximum
     accepted clock-skew window.  For high-value actions, relying parties
     SHOULD keep the accepted skew to the minimum operationally feasible
     value.  Excessive clock-skew windows can allow premature use of an
     AAE or its continued use after expiration.

  6.7.  On-Chain Anchoring

     When AAEs are anchored to a public ledger for tamper-evident audit
     trails, implementations MUST ensure that no personally identifiable
     information (PII) is written on-chain.  AAE content SHOULD be hashed
     before anchoring; the hash, timestamp, and issuer DID are sufficient
     for audit purposes.






  Kroehl                  Expires 22 November 2026               [Page 16]


  Internet-Draft                     AAE                          May 2026


  7.  Privacy Considerations

     AAEs contain the agent's DID and may contain the principal's DID.
     Relying parties SHOULD NOT log full AAE payloads unless required for
     regulatory audit purposes.  Where audit logs are required,
     implementations SHOULD apply data minimization: log the AAE
     identifier, action taken, timestamp, and outcome — not the full
     MANDATE or CONSTRAINTS payload.

     Even when only hashes of AAEs are anchored on a public ledger,
     timestamps, issuer DIDs, subject DIDs, and repeated hash-publication
     patterns can leak metadata and enable linkability across an agent's
     activity.  Implementations SHOULD assess linkability risk before
     anchoring AAEs on a public ledger and SHOULD avoid publishing stable
     identifiers on-chain unless required.

  8.  IANA Considerations

  8.1.  Media Type Registration

     IANA is requested to register the following media type in the "Media
     Types" registry, following the procedures of [RFC6838] and the
     structured syntax suffix rules of [RFC6839]:

     Type name:  application

     Subtype name:  aae+json

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  Same as for application/json [RFC8259];
        UTF-8.

     Security considerations:  See Section 6 of this document.

     Interoperability considerations:  This media type uses the "+json"
        structured syntax suffix [RFC6839].  Processors that do not
        understand application/aae+json MAY process it as application/
        json.

     Published specification:  This document.

     Applications that use this media type:  Autonomous AI agent
        frameworks, authorization servers, policy engines, and relying
        parties that issue or evaluate Agent Authorization Envelopes.




  Kroehl                  Expires 22 November 2026               [Page 17]


  Internet-Draft                     AAE                          May 2026


     Fragment identifier considerations:  As specified for the "+json"
        structured syntax suffix in [RFC6839].

     Additional information:  Deprecated alias names for this type: N/A.
        Magic number(s): N/A.  File extension(s): .aae.json.  Macintosh
        file type code(s): N/A.

     Person & email address to contact for further information:  Lars
        Kersten Kroehl lars@moltrust.ch (mailto:lars@moltrust.ch)

     Intended usage:  COMMON

     Restrictions on usage:  N/A

     Author:  Lars Kersten Kroehl

     Change controller:  Lars Kersten Kroehl, CryptoKRI GmbH

     This registration applies to the unsecured JSON AAE payload.  A
     secured AAE in JWS compact serialization is not a JSON document and
     is transported using the application/jose media type defined in
     [RFC7515]; this document does not register a separate media type for
     the secured form.

     This document requests no other IANA actions.

  9.  References

  9.1.  Normative References

     [W3C-DID]  W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July
                2022, <https://www.w3.org/TR/did-core/>.

     [W3C-VC]   W3C, "Verifiable Credentials Data Model v2.0", 8 May 2024,
                <https://www.w3.org/TR/vc-data-model-2.0/>.

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

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

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/info/rfc7515>.



  Kroehl                  Expires 22 November 2026               [Page 18]


  Internet-Draft                     AAE                          May 2026


     [RFC8037]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
                and Signatures in JSON Object Signing and Encryption
                (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
                <https://www.rfc-editor.org/info/rfc8037>.

     [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/info/rfc8032>.

     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/info/rfc7517>.

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/info/rfc3986>.

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

     [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
                and D. Orchard, "URI Template", RFC 6570,
                DOI 10.17487/RFC6570, March 2012,
                <https://www.rfc-editor.org/info/rfc6570>.

     [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and SHA-based HMAC and HKDF)", RFC 6234,
                DOI 10.17487/RFC6234, May 2011,
                <https://www.rfc-editor.org/info/rfc6234>.

     [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
                Specifications and Registration Procedures", BCP 13,
                RFC 6838, DOI 10.17487/RFC6838, January 2013,
                <https://www.rfc-editor.org/info/rfc6838>.

     [RFC6839]  Hansen, T. and A. Melnikov, "Additional Media Type
                Structured Syntax Suffixes", RFC 6839,
                DOI 10.17487/RFC6839, January 2013,
                <https://www.rfc-editor.org/info/rfc6839>.

     [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/info/rfc8259>.




  Kroehl                  Expires 22 November 2026               [Page 19]


  Internet-Draft                     AAE                          May 2026


  9.2.  Informative References

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC9635]  Richer, J., Ed. and F. Imbault, "Grant Negotiation and
                Authorization Protocol (GNAP)", RFC 9635,
                DOI 10.17487/RFC9635, October 2024,
                <https://www.rfc-editor.org/info/rfc9635>.

     [RFC9562]  Davis, K., Peabody, B., and P. Leach, "Universally Unique
                IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
                2024, <https://www.rfc-editor.org/info/rfc9562>.

     [SPIFFE]   "SPIFFE: Secure Production Identity Framework for
                Everyone", n.d., <https://spiffe.io/>.

     [ARXIV-AAE]
                Kroehl, L. K., "From Specification to Deployment:
                Empirical Evidence from a W3C VC + DID Trust
                Infrastructure for Autonomous Agents", May 2026,
                <https://arxiv.org/abs/2605.06738>.

     [IMDA-MGF] Singapore IMDA, "Model AI Governance Framework for Agentic
                AI, Version 1.5", 20 May 2026, <https://www.imda.gov.sg/-
                /media/imda/files/about/emerging-tech-and-research/
                artificial-intelligence/mgf-for-agentic-ai.pdf>.

     [NIST-CAISI]
                NIST, "NIST AI 100-1: Artificial Intelligence Risk
                Management Framework", January 2023.

  Appendix A.  Example: Travel Booking Agent

     A travel booking agent operating under an 8-hour mandate with a $500
     transaction cap.  The example shows the JWS protected header and the
     JWS payload (the unsecured Verifiable Credential); on the wire these
     are BASE64URL-encoded and concatenated with the signature as a JWS in
     compact serialization (Section 2.1).

     JWS protected header:

     {
       "alg": "EdDSA",
       "cty": "aae+json",
       "kid": "did:moltrust:registry#key-1"
     }



  Kroehl                  Expires 22 November 2026               [Page 20]


  Internet-Draft                     AAE                          May 2026


     JWS payload:

     {
       "@context": [
         "https://www.w3.org/ns/credentials/v2",
         "https://moltrust.ch/contexts/aae/v1"
       ],
       "type": ["VerifiableCredential", "AgentAuthorizationEnvelope"],
       "id": "urn:uuid:9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d",
       "issuer": "did:moltrust:registry",
       "validFrom": "2026-05-20T08:00:00Z",
       "credentialSubject": {
         "id": "did:example:travel-agent-001",
         "aae": {
           "mandate": {
             "actions": ["read", "book", "pay"],
             "purpose": "Business travel booking",
             "scope": "travel-vertical",
             "principal_did": "did:example:enterprise-corp"
           },
           "constraints": {
             "max_transaction_value": {
               "value": 500, "currency": "USD", "required": true
             },
             "allowed_domains": {
               "value": ["flights.example.com", "hotels.example.com"],
               "required": true
             }
           },
           "validity": {
             "not_before": "2026-05-20T08:00:00Z",
             "not_after": "2026-05-20T16:00:00Z",
             "single_use": false
           }
         }
       }
     }

  Appendix B.  Relationship to Existing Standards

     AAE is designed as a complement to, not a replacement for, existing
     authorization standards:

     *  *OAuth 2.0 / GNAP* ([RFC6749], [RFC9635]): Handle human-delegated
        access tokens.  AAE handles machine-to-machine agent authorization
        with richer semantics.





  Kroehl                  Expires 22 November 2026               [Page 21]


  Internet-Draft                     AAE                          May 2026


     *  *SPIFFE/SVID* ([SPIFFE]): Handles workload identity in service
        meshes.  AAE handles authorization semantics layered above
        identity.

     *  *W3C Verifiable Credentials*: AAE is issued as a VC, leveraging
        the existing VC ecosystem for issuance, verification, and
        revocation.

     *  *W3C DIDs*: AAE subjects and issuers are identified by DIDs,
        enabling decentralized, portable agent identity.

  Appendix C.  Acknowledgements

     The AAE specification is derived from the MolTrust production
     deployment documented in [ARXIV-AAE].  The author thanks Harald
     Rössler (DSNCON GmbH) for infrastructure and security review.

  Author's Address

     Lars Kersten Kroehl
     CryptoKRI GmbH
     CH- Zurich
     Switzerland
     Email: lars@moltrust.ch



























  Kroehl                  Expires 22 November 2026               [Page 22]


name: draft-yu-agent-identifier-rdap
rev: 00
title: An RDAP Profile for Agent Identifier Registration Data
time: 2026-05-22T07:22:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-23T07:22:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:41.698433+00:00
source: ietf
abstract:
  AI agents may need stable identifiers that are independent from their
     current network locations.  In agent deployments, an Agent identifier
     may be associated with IPv6 locators, IPv6 prefixes, Agent Gateways,
     public key references, policy references, lifecycle state, and
     revocation status.  Applications, gateways, controllers, and
     operators need a trusted way to query this registration data.

     This document defines an RDAP profile for querying Agent identifier
     registration data.  The profile reuses the Registration Data Access
     Protocol (RDAP) query model and JSON response format, and defines an
     RDAP object class and extension members for Agent identifiers, IPv6
     locator bindings, Agent Gateway bindings, and related operational
     metadata.

     This document does not define a new agent discovery protocol, a new
     agent interaction protocol, or a new authentication mechanism.  It
     defines a registration data access profile that can be used by agent
     deployments and by other agent-related systems that need trusted
     Agent identifier metadata.

full_text:
  Internet Engineering Task Force                                    H. Yu
  Internet-Draft                 China Internet Network Information Center
  Intended status: Informational                               20 May 2026
  Expires: 21 November 2026


           An RDAP Profile for Agent Identifier Registration Data
                     draft-yu-agent-identifier-rdap-00

  Abstract

     AI agents may need stable identifiers that are independent from their
     current network locations.  In agent deployments, an Agent identifier
     may be associated with IPv6 locators, IPv6 prefixes, Agent Gateways,
     public key references, policy references, lifecycle state, and
     revocation status.  Applications, gateways, controllers, and
     operators need a trusted way to query this registration data.

     This document defines an RDAP profile for querying Agent identifier
     registration data.  The profile reuses the Registration Data Access
     Protocol (RDAP) query model and JSON response format, and defines an
     RDAP object class and extension members for Agent identifiers, IPv6
     locator bindings, Agent Gateway bindings, and related operational
     metadata.

     This document does not define a new agent discovery protocol, a new
     agent interaction protocol, or a new authentication mechanism.  It
     defines a registration data access profile that can be used by agent
     deployments and by other agent-related systems that need trusted
     Agent identifier metadata.

  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 21 November 2026.




  Yu                      Expires 21 November 2026                [Page 1]


  Internet-Draft            Agent Identifier RDAP                 May 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.  Conventions Used in This Document . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  RDAP Extension Identifier . . . . . . . . . . . . . . . . . .   4
     6.  Query Path  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Agent RDAP Object . . . . . . . . . . . . . . . . . . . . . .   5
     8.  IPv6 Locator Object . . . . . . . . . . . . . . . . . . . . .   6
     9.  Agent Gateway Object  . . . . . . . . . . . . . . . . . . . .   7
     10. Example Response  . . . . . . . . . . . . . . . . . . . . . .   7
     11. Use with Agent Networking . . . . . . . . . . . . . . . . . .   9
     12. Conformance and Error Handling  . . . . . . . . . . . . . . .   9
     13. Relationship to Audit and Accountability  . . . . . . . . . .  10
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     17. Normative References  . . . . . . . . . . . . . . . . . . . .  11
     18. Informative References  . . . . . . . . . . . . . . . . . . .  11
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

  1.  Conventions Used in This Document

     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.








  Yu                      Expires 21 November 2026                [Page 2]


  Internet-Draft            Agent Identifier RDAP                 May 2026


  2.  Introduction

     AI agents are increasingly expected to interact across platforms,
     organizations, clouds, edge environments, and administrative domains.
     A stable Agent identifier can help identify an agent independently
     from the agent's current network location.  However, a relying party
     may still need to know which entity is responsible for the Agent
     identifier, whether the identifier is active, which IPv6 locators or
     Agent Gateways are authorized to represent the agent, and whether a
     binding has expired or been revoked.

     The companion IPv6 networking considerations draft discusses what
     networking information may be needed after agent discovery, including
     Agent-ID to IPv6 locator or Agent Gateway binding.  This document
     explores one possible way to provide stable registration data for
     Agent identifiers using RDAP.

     RDAP provides a RESTful query model and JSON responses for
     registration data [RFC7480] [RFC9082] [RFC9083].  Reusing RDAP allows
     agent deployments to use an existing registration data access model
     rather than defining a new query protocol.

  3.  Scope and Non-Goals

     This document specifies:

     *  an RDAP object class for Agent identifiers;

     *  query paths for Agent identifier lookup;

     *  JSON members for Agent lifecycle state and responsible entity
        references;

     *  JSON members for IPv6 locator and Agent Gateway bindings;

     *  JSON members for policy, certificate, validity, and revocation
        metadata;

     *  security and privacy considerations for exposing Agent
        registration data.

     This document does not specify:

     *  a new Agent identifier syntax;

     *  a new agent discovery or collaboration protocol;

     *  a new authentication, authorization, or attestation protocol;



  Yu                      Expires 21 November 2026                [Page 3]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     *  a mandatory global registry for all Agent identifiers;

     *  real-time presence, health, load, capability ranking, or endpoint
        selection;

     *  a replacement for RDAP domain, nameserver, entity, autnum, or IP
        network objects.

  4.  Terminology

     Agent:
        A software entity that can perceive context, reason, plan, invoke
        tools, communicate with other agents, and perform tasks on behalf
        of a user, organization, or system.

     Agent Identifier:
        A stable identifier used to identify an agent independently from
        its current network location.

     Agent Networking Considerations:
        Considerations related to the use of IP networking mechanisms to
        support agent communication after discovery.

     Agent Gateway:
        A network or application gateway that represents one or more
        agents and provides controlled access, address mapping, policy
        enforcement, protocol adaptation, or telemetry collection.

     Agent Binding:
        An association between an Agent identifier and one or more IPv6
        locators, IPv6 prefixes, or Agent Gateways.

     Agent RDAP Object:
        An RDAP object representing registration data for an Agent
        identifier.

  5.  RDAP Extension Identifier

     RDAP responses that use the extensions defined in this document MUST
     include the extension identifier "agent_identifier_rdap" in the
     "rdapConformance" array.

     {
       "rdapConformance": [
         "rdap_level_0",
         "agent_identifier_rdap"
       ]
     }



  Yu                      Expires 21 November 2026                [Page 4]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     The extension identifier is used provisionally in this version.
     Future versions may request IANA registration if this approach
     receives community interest.

  6.  Query Path

     This profile defines the following RDAP query path for exact Agent
     identifier lookup:

     /agent/{agentIdentifier}

     The "agentIdentifier" path component is the Agent identifier being
     queried.  The value MUST be percent-encoded when required by URI
     syntax.

     Servers MAY also support search paths in a future version.  This
     document defines only exact lookup.

  7.  Agent RDAP Object

     An Agent RDAP Object is an RDAP response object that describes an
     Agent identifier and related registration data.  It reuses common
     RDAP members such as "objectClassName", "handle", "entities",
     "events", "links", "notices", and "remarks" as defined by RDAP.

     The "objectClassName" member for an Agent RDAP Object MUST be
     "agent".

     The following agent-specific members are defined:

     agentIdentifier:
        The stable Agent identifier represented by this object.

     agentStatus:
        The lifecycle state of the Agent identifier or binding.  Example
        values include "active", "inactive", "suspended", "revoked", and
        "expired".

     responsibleEntity:
        An RDAP entity handle, URI, or opaque reference identifying the
        entity responsible for the Agent identifier.

     agentDomains:
        An array of administrative or operational domains associated with
        the Agent identifier.






  Yu                      Expires 21 November 2026                [Page 5]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     ipv6Locators:
        An array of IPv6 locator objects associated with the Agent
        identifier.

     agentGateways:
        An array of Agent Gateway objects authorized to represent the
        Agent identifier.

     certificateRefs:
        An array of certificate, key, or trust document references.

     policyRefs:
        An array of policy references associated with the Agent identifier
        or binding.

     revocationStatus:
        Information about revocation state and revocation checking
        endpoints.

  8.  IPv6 Locator Object

     An IPv6 Locator Object describes an IPv6 address or prefix through
     which an agent instance, service, or gateway can be reached.

     The following members are defined:

     locator:
        An IPv6 address or prefix.

     locatorType:
        The type of locator.  Example values include "instance",
        "service", "gateway", and "prefix".

     priority:
        An integer used to express selection priority.  Lower values
        indicate higher preference.

     weight:
        An integer used for weighted selection among locators of equal
        priority.

     region:
        A deployment region, availability zone, site, or other operational
        location label.

     validFrom:
        The time from which this locator binding is valid.




  Yu                      Expires 21 November 2026                [Page 6]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     validUntil:
        The time after which this locator binding is no longer valid.

     status:
        The status of the locator binding.  Example values include
        "active", "inactive", "revoked", and "expired".

  9.  Agent Gateway Object

     An Agent Gateway Object describes a gateway that is authorized to
     represent one or more Agent identifiers.

     The following members are defined:

     gatewayIdentifier:
        A stable identifier for the Agent Gateway.

     gatewayLocator:
        An IPv6 address, IPv6 prefix, URI, or other locator used to reach
        the gateway.

     representedAgents:
        An array of Agent identifier references or patterns represented by
        the gateway.

     authorizationRef:
        A reference to authorization data showing that the gateway may
        represent the Agent identifier.

     policyRefs:
        An array of policy references enforced by or associated with the
        gateway.

     status:
        The status of the gateway binding.

  10.  Example Response

     The following example shows an Agent RDAP Object for an agent that is
     reachable through an Agent Gateway.

     {
       "rdapConformance": [
         "rdap_level_0",
         "agent_identifier_rdap"
       ],
       "objectClassName": "agent",
       "handle": "AGENT-EXAMPLE-0001",



  Yu                      Expires 21 November 2026                [Page 7]


  Internet-Draft            Agent Identifier RDAP                 May 2026


       "agentIdentifier": "agent:warehouse.example.cn:agv-001",
       "agentStatus": "active",
       "responsibleEntity": "CNIC-EXAMPLE-ENTITY",
       "agentDomains": [
         "warehouse.example.cn"
       ],
       "ipv6Locators": [
         {
           "locator": "2001:db8:100:20::1",
           "locatorType": "gateway",
           "priority": 100,
           "weight": 100,
           "region": "warehouse-site-a",
           "validFrom": "2026-05-20T00:00:00Z",
           "validUntil": "2026-11-20T00:00:00Z",
           "status": "active"
         }
       ],
       "agentGateways": [
         {
           "gatewayIdentifier": "warehouse-gateway-001",
           "gatewayLocator": "2001:db8:100:20::1",
           "representedAgents": [
             "agent:warehouse.example.cn:agv-001"
           ],
           "authorizationRef": "https://example.net/agent/authz/warehouse-gw-001",
           "policyRefs": [
             "policy:warehouse-dispatch"
           ],
           "status": "active"
         }
       ],
       "certificateRefs": [
         "https://example.net/agent/certs/agv-001"
       ],
       "policyRefs": [
         "policy:warehouse-dispatch"
       ],
       "revocationStatus": {
         "status": "notRevoked",
         "revocationCheck": "https://example.net/agent/status/agv-001"
       },
       "events": [
         {
           "eventAction": "registration",
           "eventDate": "2026-05-20T00:00:00Z"
         },
         {



  Yu                      Expires 21 November 2026                [Page 8]


  Internet-Draft            Agent Identifier RDAP                 May 2026


           "eventAction": "last changed",
           "eventDate": "2026-05-20T00:00:00Z"
         }
       ],
       "links": [
         {
           "value": "https://rdap.example.net/agent/agent%3Awarehouse.example.cn%3Aagv-001",
           "rel": "self",
           "href": "https://rdap.example.net/agent/agent%3Awarehouse.example.cn%3Aagv-001",
           "type": "application/rdap+json"
         }
       ]
     }

  11.  Use with Agent Networking

     An agent networking implementation can use this RDAP profile to
     verify Agent-ID binding data before selecting an IPv6 locator, Agent
     Gateway, or network policy.  For example, an Agent Gateway can query
     the Agent RDAP Object to determine whether it is authorized to
     represent a target Agent-ID.  A controller can query the same object
     to select a locator or policy for a given communication, such as an
     SRv6 policy in a controlled domain.

     This RDAP profile is not a real-time reachability protocol.  It
     provides registration data.  Implementations that require live
     reachability, health, or load information should combine this profile
     with other mechanisms such as Agent registries, service discovery
     systems, controllers, telemetry, or application-layer health checks.
     Online/offline state, live load, health, capability ranking, and
     endpoint selection are out of scope for this profile.

  12.  Conformance and Error Handling

     Servers implementing this profile MUST follow RDAP transport and
     response requirements.  RDAP error responses, including status codes,
     notices, and remarks, are used as defined by RDAP.

     If the requested Agent identifier does not exist, the server SHOULD
     return an RDAP not-found response.  If the Agent identifier exists
     but the client is not authorized to view the requested data, the
     server SHOULD return an appropriate authorization error or a redacted
     response according to local policy.

     A server MAY return different field sets to different clients based
     on authentication, authorization, local policy, and privacy
     requirements.  Clients MUST NOT assume that absence of a field means
     absence of the corresponding registration data.



  Yu                      Expires 21 November 2026                [Page 9]


  Internet-Draft            Agent Identifier RDAP                 May 2026


  13.  Relationship to Audit and Accountability

     Agent identifier registration data can be useful to audit and
     accountability systems.  For example, an audit record may contain an
     Agent identifier and later need to determine the responsible entity,
     lifecycle state, revocation state, authorized Agent Gateway, or
     associated IPv6 locator for that identifier.

     This profile can provide stable registration data that audit systems
     may reference.  It does not define audit records, distributed audit
     log formats, audit context propagation, attestation evidence,
     transparency logs, or non-repudiation mechanisms.

  14.  Security Considerations

     Agent registration data can influence routing, gateway selection,
     access control, and policy enforcement.  Servers providing Agent RDAP
     Objects MUST authenticate update operations and MUST ensure that an
     Agent identifier cannot be bound to an unauthorized IPv6 locator or
     Agent Gateway.

     RDAP clients MUST use HTTPS as specified by RDAP over HTTP.  Clients
     MUST validate the server identity according to the applicable TLS
     validation rules.

     Agent Gateway authorization data is security-sensitive.  A gateway
     MUST NOT be treated as authorized to represent an Agent identifier
     solely because it appears in an unauthenticated or stale response.
     Implementations SHOULD check validity periods, revocation status, and
     policy references before relying on gateway binding information.

     Replay and stale-data attacks are possible if old registration data
     is accepted after a binding has changed or been revoked.  Servers
     SHOULD include update events and validity intervals.  Clients SHOULD
     apply local freshness policies and re-query when cached data is
     stale.

     This profile does not define how Agent identifiers are created,
     delegated, or cryptographically controlled.  Deployments MUST define
     the authority model used to issue and manage Agent identifiers.

  15.  Privacy Considerations

     Agent RDAP Objects may reveal information about organizations,
     internal deployments, gateways, network locations, operational
     regions, policy names, and relationships between domains.  Servers
     SHOULD minimize disclosed data and apply access control where
     appropriate.



  Yu                      Expires 21 November 2026               [Page 10]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     Some Agent identifiers may be pseudonymous or scoped to a domain.
     Servers SHOULD avoid exposing unnecessary personally identifiable
     information, user data, prompts, task descriptions, or sensitive
     application payload information in Agent RDAP Objects.

     Public RDAP responses and authenticated RDAP responses may have
     different disclosure levels.  Deployments SHOULD define which fields
     are public and which require authorization.

  16.  IANA Considerations

     This initial version does not request any IANA action.

     Future versions may request registration of an RDAP extension
     identifier if this approach receives community interest.

  17.  Normative References

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

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

     [RFC7480]  Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 7480, DOI 10.17487/RFC7480, March 2015,
                <https://www.rfc-editor.org/info/rfc7480>.

     [RFC9082]  Hollenbeck, S. and A. Newton, "Registration Data Access
                Protocol (RDAP) Query Format", STD 95, RFC 9082,
                DOI 10.17487/RFC9082, June 2021,
                <https://www.rfc-editor.org/info/rfc9082>.

     [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 9083, DOI 10.17487/RFC9083, June 2021,
                <https://www.rfc-editor.org/info/rfc9083>.

  18.  Informative References

     [RFC7482]  Newton, A. and S. Hollenbeck, "Registration Data Access
                Protocol (RDAP) Query Format", RFC 7482,
                DOI 10.17487/RFC7482, March 2015,
                <https://www.rfc-editor.org/info/rfc7482>.



  Yu                      Expires 21 November 2026               [Page 11]


  Internet-Draft            Agent Identifier RDAP                 May 2026


     [RFC7483]  Newton, A. and S. Hollenbeck, "JSON Responses for the
                Registration Data Access Protocol (RDAP)", RFC 7483,
                DOI 10.17487/RFC7483, March 2015,
                <https://www.rfc-editor.org/info/rfc7483>.

     [I-D.yu-ai-agent-ipv6-networking-considerations]
                Yu, H., "IPv6 Networking Considerations for AI Agent
                Communication", <https://datatracker.ietf.org/doc/draft-
                yu-ai-agent-ipv6-networking-considerations/>.

  Author's Address

     Haisheng Yu
     China Internet Network Information Center
     Email: yuhaisheng@cnnic.cn




































  Yu                      Expires 21 November 2026               [Page 12]


name: draft-chang-delta1-settlement
rev: 00
title: Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI Accountability
time: 2026-04-15T18:35:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-17T18:35:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "AI safety/alignment", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:43.021530+00:00
source: ietf
abstract:
  This document defines Delta-1, a profile of the SCITT (Supply Chain
     Integrity, Transparency, and Trust) architecture applied to AI agent
     decision accountability.

     Delta-1 specializes the SCITT receipt model for a specific use case:
     proving that an individual AI decision met three accountability
     conditions simultaneously:

     C1: Evidence of the decision process was consumed and sealed.  C2:
     Strategic intent was isolated from inference providers.  C3: An
     authorized party recorded the settlement.

     The verdict is binary (VALID or INVALID) with no intermediate states.
     Receipts are independently verifiable without the issuing
     infrastructure being online, subject to the trust and attestation
     assumptions defined in this document.

     By building on the SCITT framework, Delta-1 inherits transparency-log
     semantics, receipt conventions, and verification patterns, while
     extending them with domain-specific requirements for AI decision
     closure.

     This profile is intended for regulated industries, including finance,
     healthcare, and legal, operating under accountability and record-
     retention obligations.

full_text:
  Network Working Group                                         Y.C. Chang
  Internet-Draft                                                   OIA Lab
  Intended status: Informational                             16 April 2026
  Expires: 18 October 2026


   Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI
                               Accountability
                      draft-chang-delta1-settlement-00

  Abstract

     This document defines Delta-1, a profile of the SCITT (Supply Chain
     Integrity, Transparency, and Trust) architecture applied to AI agent
     decision accountability.

     Delta-1 specializes the SCITT receipt model for a specific use case:
     proving that an individual AI decision met three accountability
     conditions simultaneously:

     C1: Evidence of the decision process was consumed and sealed.  C2:
     Strategic intent was isolated from inference providers.  C3: An
     authorized party recorded the settlement.

     The verdict is binary (VALID or INVALID) with no intermediate states.
     Receipts are independently verifiable without the issuing
     infrastructure being online, subject to the trust and attestation
     assumptions defined in this document.

     By building on the SCITT framework, Delta-1 inherits transparency-log
     semantics, receipt conventions, and verification patterns, while
     extending them with domain-specific requirements for AI decision
     closure.

     This profile is intended for regulated industries, including finance,
     healthcare, and legal, operating under accountability and record-
     retention obligations.

  Note to RFC Editor

     This document is submitted as an individual Internet-Draft.  Remove
     this note prior to publication as an RFC.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.




  Chang                    Expires 18 October 2026                [Page 1]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     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 18 October 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Relationship to SCITT . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Receipt Structure . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Required Fields . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Optional Fields . . . . . . . . . . . . . . . . . . . . .   6
     5.  Condition Evaluation  . . . . . . . . . . . . . . . . . . . .   6
       5.1.  C1: Evidence Consumed . . . . . . . . . . . . . . . . . .   6
       5.2.  C2: Intent Isolated . . . . . . . . . . . . . . . . . . .   7
       5.3.  C3: Settlement Recorded . . . . . . . . . . . . . . . . .   7
       5.4.  Binary Conjunction  . . . . . . . . . . . . . . . . . . .   7
     6.  Transcript Binding  . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Binding Fields  . . . . . . . . . . . . . . . . . . . . .   8
     7.  Anti-Replay Protection  . . . . . . . . . . . . . . . . . . .   9
       7.1.  Run ID Nonce  . . . . . . . . . . . . . . . . . . . . . .   9
       7.2.  Monotonic Sequence Number . . . . . . . . . . . . . . . .   9
     8.  Signature and Verification  . . . . . . . . . . . . . . . . .   9
       8.1.  Proof Construction and Signing  . . . . . . . . . . . . .   9
       8.2.  Verification  . . . . . . . . . . . . . . . . . . . . . .   9
     9.  Hardware Attestation (Optional) . . . . . . . . . . . . . . .  10
       9.1.  Attestation Proof Structure . . . . . . . . . . . . . . .  10
       9.2.  Attestation Verification  . . . . . . . . . . . . . . . .  10



  Chang                    Expires 18 October 2026                [Page 2]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


       9.3.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  11
     10. Receipt Lifecycle . . . . . . . . . . . . . . . . . . . . . .  11
       10.1.  Immutability . . . . . . . . . . . . . . . . . . . . . .  11
       10.2.  Archival . . . . . . . . . . . . . . . . . . . . . . . .  11
       10.3.  Chain of Custody . . . . . . . . . . . . . . . . . . . .  11
     11. Transport Considerations  . . . . . . . . . . . . . . . . . .  11
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  12
       12.1.  Self-Attestation Risk  . . . . . . . . . . . . . . . . .  12
       12.2.  Key Management . . . . . . . . . . . . . . . . . . . . .  12
       12.3.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  12
       12.4.  Transcript Transplantation . . . . . . . . . . . . . . .  12
       12.5.  Side-Channel Attacks on TEE  . . . . . . . . . . . . . .  12
       12.6.  Timing Information . . . . . . . . . . . . . . . . . . .  12
       12.7.  JSON Canonicalization  . . . . . . . . . . . . . . . . .  12
       12.8.  Key Rotation and Revocation  . . . . . . . . . . . . . .  13
       12.9.  Validator Integrity  . . . . . . . . . . . . . . . . . .  13
       12.10. TEE Vendor Generalization  . . . . . . . . . . . . . . .  13
       12.11. Quote Freshness  . . . . . . . . . . . . . . . . . . . .  13
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
       13.1.  Media Type Registration  . . . . . . . . . . . . . . . .  13
     14. Normative References  . . . . . . . . . . . . . . . . . . . .  14
     15. Informative References  . . . . . . . . . . . . . . . . . . .  15
     Appendix A.  JSON Schema  . . . . . . . . . . . . . . . . . . . .  15
     Appendix B.  Example Receipts . . . . . . . . . . . . . . . . . .  17
       VALID Receipt (All Conditions Met)  . . . . . . . . . . . . . .  17
       INVALID Receipt (C2 Failed) . . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

     As AI agents increasingly make or assist in consequential decisions,
     such as financial trades, clinical recommendations, procurement
     approvals, and legal assessments, organizations need a mechanism to
     prove that each decision met defined accountability conditions at the
     time it was made.

     Current approaches often provide authorization semantics ("this AI
     action was approved") but not settlement semantics ("the decision's
     accountability conditions can be cryptographically proven after the
     fact").  This gap creates regulatory, legal, and operational risk.

  1.1.  Relationship to SCITT

     The SCITT architecture defines a framework for creating transparent,
     tamper-evident signed statements registered on append-only
     transparency services, with receipts proving inclusion.

     Delta-1 maps SCITT concepts to AI decision accountability:



  Chang                    Expires 18 October 2026                [Page 3]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     *  SCITT Signed Statement = Delta-1 condition evaluation result

     *  SCITT Transparency Service = append-only evidence chain

     *  SCITT Receipt = Delta-1 settlement receipt (binary verdict)

     *  SCITT Issuer = AI decision pipeline being attested

     *  SCITT Verifier = Customer, auditor, or regulator

     Delta-1 extends SCITT with:

     *  Binary verdict semantics (VALID or INVALID, with no scoring)

     *  Three-condition conjunction (C1 AND C2 AND C3)

     *  Transcript binding to prevent receipt transplantation

     *  Anti-replay protection via run identifiers and monotonic counters

     *  Optional hardware attestation to upgrade trust from software self-
        report to hardware-attested execution

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Terminology

     Settlement Receipt  A cryptographically signed document attesting to
        the binary verdict of a Delta-1 evaluation.

     Delta-1 (D1)  The conjunction of three conditions (C1 AND C2 AND C3)
        that, when all are true, indicates accountability closure for a
        single AI decision.

     C1 (Evidence Consumed)  The decision's evidence chain has been
        recorded in an append-only, tamper-evident store and sealed.

     C2 (Intent Isolated)  Strategic intent was fragmented or transformed
        before reaching the inference provider, preventing the provider
        from reconstructing the decision-maker's strategy under the threat
        model defined by the deployment.

     C3 (Settlement Recorded)  An authorized party has reviewed and signed
        off on the decision's closure.



  Chang                    Expires 18 October 2026                [Page 4]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     BBOX  Black-box evidence chain: an append-only, hash-linked log of
        decision-process steps.

     Transcript Binding  A canonical digest that cryptographically binds
        the receipt to the pipeline execution context.

  3.  Protocol Overview

     The Delta-1 protocol operates as the final step in an AI decision
     accountability pipeline:

     1.  AI query is processed through privacy and isolation layers.

     2.  Evidence of each processing step is recorded in the evidence
         chain.

     3.  The evidence chain is sealed.

     4.  The Delta-1 validator evaluates C1, C2, and C3.

     5.  A binary receipt is produced: VALID or INVALID.

     6.  The receipt is signed using the customer's signing key.

     7.  Optional hardware attestation evidence is attached.

     8.  The receipt is delivered for archival and later verification.

     Verification is performed by the receipt holder.  Offline
     verification of the receipt signature and transcript binding is
     REQUIRED.  Verification of optional external artifacts, such as TEE
     quote status or trusted time evidence, MAY depend on cached trust
     anchors or online validation services, depending on local policy.

  4.  Receipt Structure

     A Delta-1 receipt is a JSON object with the following fields.

  4.1.  Required Fields

     schema_version  String.  MUST be "delta1-v1".

     receipt_id  String.  Globally unique identifier for this receipt.
        RECOMMENDED format: "EP-" followed by 8 or more hexadecimal
        characters.

     session_id  String.  Identifier of the decision session.




  Chang                    Expires 18 October 2026                [Page 5]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     run_id  String.  Globally unique nonce for anti-replay protection.
        MUST NOT be reused across receipts.

     sequence_number  Unsigned integer.  Monotonically increasing counter
        per issuing validator instance.

     delta1_valid  Boolean.  True if and only if C1, C2, and C3 are all
        true.

     conditions_met  Object containing boolean fields c1, c2, and c3.

     timestamp  String.  RFC 3339 timestamp of receipt issuance.

     proof_hash  String.  SHA-256 digest of the canonical proof input
        defined in Section 8.1.

     signature  String.  Ed25519 signature over the proof_hash, produced
        by the customer's signing key.

     public_key_ref  String.  Reference to the public key used for
        signature verification.

  4.2.  Optional Fields

     transcript_digest  String.  Canonical digest of the pipeline
        execution context.  REQUIRED for production deployments.

     attestation  Object.  Hardware attestation proof, if a TEE is used.

     bbox_seal_hash  String.  SHA-256 digest of the sealed evidence chain.

     trusted_time  Object.  Optional trusted time evidence, such as RFC
        3161 or Roughtime-derived proof.

  5.  Condition Evaluation

     The Delta-1 validator MUST evaluate three conditions.  All three MUST
     be true for the receipt to be VALID.

  5.1.  C1: Evidence Consumed

     C1 is true when all of the following hold:

     a.  An evidence chain exists for the session.

     b.  The chain contains at least the minimum required evidence
         packets; implementation-defined, RECOMMENDED value is 3 or
         greater.



  Chang                    Expires 18 October 2026                [Page 6]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     c.  Required processing layers are represented in the chain.

     d.  Chain integrity is valid and hash linkage is unbroken.

     e.  The chain has been sealed and no further entries are accepted.

  5.2.  C2: Intent Isolated

     C2 is true when all of the following hold:

     a.  Intent fragmentation or transformation was applied before
         transmission to the inference provider.

     b.  Training-signal blocking mechanisms were active.

     c.  Confirmation-denial or equivalent response screening verified
         that provider responses did not reveal protected original
         entities.

     d.  Under the deployment threat model, the original intent is not
         reconstructable from the transformed query material delivered to
         providers.

     Deployments claiming C2 compliance SHOULD document the threat model,
     attacker vantage point, and reconstruction criteria used for
     validation.

  5.3.  C3: Settlement Recorded

     C3 is true when all of the following hold:

     a.  A settlement record exists for the session.

     b.  The settlement was produced by an authorized signer.

     c.  The signature is cryptographically valid.

     d.  The settlement has not expired.

     e.  Closure was explicitly acknowledged and was not purely automatic.

  5.4.  Binary Conjunction

     The verdict is computed as follows:

     delta1_valid = c1 AND c2 AND c3





  Chang                    Expires 18 October 2026                [Page 7]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     There is no partial validity, no scoring, and no weighted average.
     Two out of three conditions being true still yields INVALID.

  6.  Transcript Binding

     To prevent receipt transplantation, the receipt SHOULD include a
     transcript binding digest.

     The transcript_digest is computed as follows:

     transcript_digest = SHA-256(
       original_request_digest ||
       transformed_request_digests ||
       provider_dispatch_map ||
       provider_response_digests ||
       trt_verdict_digest ||
       bbox_seal_hash ||
       policy_versions ||
       model_identities
     )

  6.1.  Binding Fields

     original_request_digest  SHA-256 of the user's original query before
        transformation.

     transformed_request_digests  SHA-256 of each transformed fragment
        sent to providers.

     provider_dispatch_map  Ordered pairs of fragment identifier and
        provider identifier.

     provider_response_digests  SHA-256 of each provider's raw response.

     trt_verdict_digest  SHA-256 digest of the transformation or
        sanitization verdict.

     bbox_seal_hash  SHA-256 digest of the sealed evidence chain.

     policy_versions  Identifiers of active policy versions at processing
        time.

     model_identities  Provider and model identifiers used in the
        pipeline.







  Chang                    Expires 18 October 2026                [Page 8]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


  7.  Anti-Replay Protection

  7.1.  Run ID Nonce

     Each receipt MUST contain a globally unique run_id.  The validator
     MUST reject any validation request whose run_id has been previously
     used.

     Implementations SHOULD use cryptographically random identifiers of at
     least 128 bits.

  7.2.  Monotonic Sequence Number

     Each receipt MUST contain a sequence_number that is strictly greater
     than the sequence_number of any previous receipt from the same
     validator instance.

     Gaps are permitted, such as after rejected validations, but decreases
     are not permitted.

  8.  Signature and Verification

  8.1.  Proof Construction and Signing

     Before computing proof_hash, implementations MUST construct a
     canonical proof input object containing the following fields:
     session_id, run_id, sequence_number, conditions_met,
     transcript_digest, and timestamp.

     The proof input object MUST be serialized using the JSON
     Canonicalization Scheme (JCS) defined in [RFC8785].  The proof_hash
     is the SHA-256 digest of that canonicalized byte string.

     The receipt signature MUST use Ed25519 [RFC8032].  The signed payload
     is the proof_hash.

     The signing key MUST be controlled by the customer, not by the
     infrastructure vendor.

  8.2.  Verification

     Verification requires, at minimum:

     a.  The receipt JSON document.

     b.  The customer's Ed25519 public key.

     Verification procedure:



  Chang                    Expires 18 October 2026                [Page 9]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     1.  Recompute proof_hash from the canonical proof input.

     2.  Verify the Ed25519 signature against proof_hash.

     3.  If transcript_digest is present, verify that it matches the
         expected canonical digest.

     4.  If sequence tracking is implemented, verify that sequence_number
         exceeds the last known value for the validator instance.

     Verification of receipt signature and transcript binding MUST NOT
     require network access, vendor APIs, or online services.

  9.  Hardware Attestation (Optional)

     When the Delta-1 validator executes inside a Trusted Execution
     Environment (TEE), the receipt MAY include attestation evidence.

  9.1.  Attestation Proof Structure

     tee_type  TEE technology identifier, such as sgx_dcap, sev_snp, cca,
        or nitro.

     quote  The TEE attestation artifact appropriate to tee_type.

     measurement  Measurement of the trusted execution payload, such as
        MRENCLAVE or equivalent.

     signer_identity  Identity of the signing authority for the measured
        payload, if applicable.

     tcb_level  Status of the TEE trusted computing base.

     report_data_hash  The receipt proof_hash bound into the attestation
        evidence.

     mode  Deployment mode.  Simulation values MUST NOT be trusted in
        production.

  9.2.  Attestation Verification

     Attestation verification depends on tee_type and local trust policy.
     Implementations MAY validate attestation online, or offline using
     cached collateral and trust anchors.

     At minimum, verifiers SHOULD:





  Chang                    Expires 18 October 2026               [Page 10]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     A.  Verify the attestation evidence against the relevant TEE trust
         chain.

     B.  Verify that the measured payload matches an expected published
         measurement.

     C.  Verify that report_data_hash equals receipt.proof_hash.

     D.  Verify that tcb_level is acceptable under local policy.

  9.3.  Trust Model

     Without attestation, the customer trusts that vendor-operated
     software ran correctly.  With attestation, trust shifts toward the
     TEE platform and its measurement chain.  This is a substantial trust
     upgrade, but not a zero-trust guarantee.

  10.  Receipt Lifecycle

  10.1.  Immutability

     A receipt, once issued, MUST NOT be modified.  If a condition is
     later found to have been recorded incorrectly, a new receipt MUST be
     issued with a new receipt_id and the updated verdict.

  10.2.  Archival

     Receipts SHOULD be archived by the customer for the duration required
     by applicable regulation, contract, or internal retention policy.

  10.3.  Chain of Custody

     To prove accountability over a period of time, implementations MAY
     chain receipts by incorporating the previous receipt's proof_hash
     into the next receipt's transcript binding.

  11.  Transport Considerations

     Delta-1 receipts are transport-agnostic.  They MAY be delivered via:

     *  HTTPS API response for real-time systems

     *  File download, including compliance or legal export flows

     *  Message queue for asynchronous processing pipelines

     *  Blockchain anchoring for optional public verifiability




  Chang                    Expires 18 October 2026               [Page 11]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     The receipt format is JSON.  Implementations SHOULD support both JSON
     and CBOR [RFC8949] encodings where bandwidth-constrained environments
     require compact encoding.

  12.  Security Considerations

  12.1.  Self-Attestation Risk

     Without TEE support, the receipt is ultimately a software self-
     report.  A compromised validator can produce fraudulent VALID
     receipts.

  12.2.  Key Management

     The customer's Ed25519 signing key is a root of trust.  Compromise of
     this key permits forged receipts.  Implementations SHOULD use
     hardware security modules or equivalent protections.

  12.3.  Replay Attacks

     run_id nonces and monotonic sequence_number values are used to
     mitigate replay attacks.  Validators MUST reject duplicate run_id
     values.

  12.4.  Transcript Transplantation

     Without transcript binding, a valid receipt could be attached to a
     different decision.  Production deployments SHOULD include transcript
     binding.

  12.5.  Side-Channel Attacks on TEE

     TEE technologies remain exposed to side-channel and implementation-
     level attacks.  Current mitigations reduce, but do not eliminate,
     residual risk.

  12.6.  Timing Information

     The timestamp in the receipt is produced by the validator's local
     clock.  High-assurance deployments SHOULD bind receipt issuance time
     to a trusted external time source, such as RFC 3161 or Roughtime-
     based evidence.

  12.7.  JSON Canonicalization

     Receipt proof construction MUST use JCS canonicalization before
     hashing.  Without deterministic serialization, semantically identical
     content can yield different proof_hash values.



  Chang                    Expires 18 October 2026               [Page 12]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


  12.8.  Key Rotation and Revocation

     Implementations MUST support key rotation.  Historical receipts
     signed by an old key remain valid if the corresponding public key and
     validity period are preserved.

  12.9.  Validator Integrity

     The Delta-1 validator is a single point of trust when no TEE is used.
     Reproducible builds, transparency logs, and multi-party validation
     are RECOMMENDED mitigations for high-assurance deployments.

  12.10.  TEE Vendor Generalization

     Implementations SHOULD support multiple TEE families and MUST
     distinguish them using tee_type.

  12.11.  Quote Freshness

     Attestation artifacts can be replayed.  Binding proof_hash into
     report_data_hash ensures that an attestation artifact covers exactly
     one receipt instance.

  13.  IANA Considerations

     This document requests registration of the "application/
     delta1-receipt+json" media type in the "Media Types" registry.

  13.1.  Media Type Registration

     Type name  application

     Subtype name  delta1-receipt+json

     Required parameters  None.

     Optional parameters  version, default value "delta1-v1".

     Encoding considerations  Binary.  Delta-1 receipt documents are UTF-8
        encoded JSON texts.

     Security considerations  See Section 12.

     Interoperability considerations  Interoperability depends on
        consistent canonicalization, proof construction, and algorithm
        support as defined in this specification.

     Published specification  This document.



  Chang                    Expires 18 October 2026               [Page 13]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     Applications that use this media type  AI accountability systems,
        evidence archival systems, regulatory reporting systems, and audit
        verification tools.

     Fragment identifier considerations  Same as for application/json.

     Additional information  Magic number: N/A.  File extension:
        .delta1.json.  Macintosh file type code: N/A.

     Person and email address to contact for further information  YC
        Chang, yc@oia-lab.com

     Intended usage  Common.

     Restrictions on usage  None.

     Author  YC Chang

     Change controller  IETF

  14.  Normative References

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

     [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
                Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
                <https://www.rfc-editor.org/info/rfc3339>.

     [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and SHA-based HMAC and HKDF)", RFC 6234,
                DOI 10.17487/RFC6234, May 2011,
                <https://www.rfc-editor.org/info/rfc6234>.

     [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/info/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/info/rfc8174>.







  Chang                    Expires 18 October 2026               [Page 14]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     [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/info/rfc8785>.

     [SCITT-ARCH]
                Birkholz, H., "An Architecture for Trustworthy and
                Transparent Digital Supply Chains", Work in Progress,
                Internet-Draft, draft-ietf-scitt-architecture,
                <https://datatracker.ietf.org/doc/draft-ietf-scitt-
                architecture/>.

  15.  Informative References

     [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
                2001, <https://www.rfc-editor.org/info/rfc3161>.

     [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/info/rfc8949>.

     [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
                DOI 10.17487/RFC9530, February 2024,
                <https://www.rfc-editor.org/info/rfc9530>.

     [P11]      Chang, Y., "Authorization Is Not Settlement: Why AI
                Accountability Requires Binary Closure",
                DOI 10.5281/zenodo.19338864, March 2026,
                <https://doi.org/10.5281/zenodo.19338864>.

     [EUAIA]    Council, E. P. A., "Regulation (EU) 2024/1689 laying down
                harmonised rules on artificial intelligence (AI Act)",
                2024.

     [COAIA]    Colorado, S. O., "SB 24-205 Concerning Consumer
                Protections for Artificial Intelligence", 2024.

     [FORESHADOW]
                Bulck, J. V., "Foreshadow: Extracting the Keys to the
                Intel SGX Kingdom", 2018.

  Appendix A.  JSON Schema






  Chang                    Expires 18 October 2026               [Page 15]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "title": "Delta1Receipt",
       "type": "object",
       "required": [
         "schema_version",
         "receipt_id",
         "session_id",
         "run_id",
         "sequence_number",
         "delta1_valid",
         "conditions_met",
         "timestamp",
         "proof_hash",
         "signature",
         "public_key_ref"
       ],
       "properties": {
         "schema_version": {
           "type": "string",
           "const": "delta1-v1"
         },
         "receipt_id": { "type": "string" },
         "session_id": { "type": "string" },
         "run_id": { "type": "string" },
         "sequence_number": {
           "type": "integer",
           "minimum": 1
         },
         "delta1_valid": { "type": "boolean" },
         "conditions_met": {
           "type": "object",
           "required": ["c1", "c2", "c3"],
           "properties": {
             "c1": { "type": "boolean" },
             "c2": { "type": "boolean" },
             "c3": { "type": "boolean" }
           }
         },
         "timestamp": {
           "type": "string",
           "format": "date-time"
         },
         "proof_hash": { "type": "string" },
         "signature": { "type": "string" },
         "public_key_ref": { "type": "string" },
         "transcript_digest": { "type": "string" },
         "bbox_seal_hash": { "type": "string" },



  Chang                    Expires 18 October 2026               [Page 16]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


         "trusted_time": {
           "type": "object",
           "properties": {
             "type": { "type": "string" },
             "value": { "type": "string" }
           }
         },
         "attestation": {
           "type": "object",
           "properties": {
             "tee_type": { "type": "string" },
             "quote": { "type": "string" },
             "measurement": { "type": "string" },
             "signer_identity": { "type": "string" },
             "tcb_level": { "type": "string" },
             "report_data_hash": { "type": "string" },
             "mode": { "type": "string" }
           }
         }
       }
     }

  Appendix B.  Example Receipts

  VALID Receipt (All Conditions Met)


























  Chang                    Expires 18 October 2026               [Page 17]


  Internet-Draft         Delta-1 Settlement Receipts            April 2026


     {
       "schema_version": "delta1-v1",
       "receipt_id": "EP-mnu2gmo2-df9ba6d5",
       "session_id": "session-20260414-e3f1",
       "run_id": "run-20260414-a7f3b2c1d4e5",
       "sequence_number": 42,
       "delta1_valid": true,
       "conditions_met": { "c1": true, "c2": true, "c3": true },
       "timestamp": "2026-04-14T10:24:15Z",
       "proof_hash": "3fa2b7c1e8d9f4a5b6c7d8e9f0a1b2c3...",
       "signature": "ed25519:MIGHAoGBANr5nD1y4X...",
       "public_key_ref": "customer_hsm_key_001",
       "transcript_digest": "a1b2c3d4e5f6a7b8c9d0e1f2...",
       "bbox_seal_hash": "9a8b7c6d5e4f3a2b1c...",
       "attestation": {
         "tee_type": "sgx_dcap",
         "quote": "SIMULATION:abc123...",
         "measurement": "f7a2b1c3d4e5f6a7b8c9d0e1...",
         "signer_identity": "e1f2a3b4c5d6e7f8a9b0c1d2...",
         "tcb_level": "simulation",
         "report_data_hash": "3fa2b7c1e8d9f4a5b6c7d8e9f0a1b2c3...",
         "mode": "simulation"
       }
     }

  INVALID Receipt (C2 Failed)

     {
       "schema_version": "delta1-v1",
       "receipt_id": "EP-x9k3m7p2-c4a1b8f3",
       "session_id": "session-20260414-b2c3",
       "run_id": "run-20260414-f8e7d6c5b4a3",
       "sequence_number": 43,
       "delta1_valid": false,
       "conditions_met": { "c1": true, "c2": false, "c3": true },
       "timestamp": "2026-04-14T10:25:02Z",
       "proof_hash": "7b8c9d0e1f2a3b4c5d6e7f8a...",
       "signature": "ed25519:KJHFaskjdfh...",
       "public_key_ref": "customer_hsm_key_001",
       "transcript_digest": ""
     }

  Author's Address

     YC Chang
     OIA Lab
     Email: yc@oia-lab.com
     URI:   https://oia-lab.com



  Chang                    Expires 18 October 2026               [Page 18]


name: draft-aevum-wlp
rev: 00
title: WLP: Wet-Lab Protocol -- AI-to-Automation Instruction Schema v0
time: 2026-05-18T18:42:35Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-19T18:42:35Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Human-agent interaction", "Other AI/agent"]
tags: []
fetched_at: 2026-05-22T09:24:43.021537+00:00
source: ietf
abstract:
  This document specifies WLP v0, the Wet-Lab Protocol for translating
     AI hypotheses (PACR records) into machine-executable wet-lab
     instructions.  WLP is the longevity-research analogue of SCP (Science
     Context Protocol) from the photoresist automation domain.  The
     protocol is royalty-free (Apache-2.0).  Reference implementations in
     Rust (crates/wlp-conformance) and Python
     (agentcard_adapters.wlp_conformance) are provided.

full_text:
  Individual Submission                                            K. Tsoi
  Internet-Draft                                             Aevum Network
  Intended status: Informational                               19 May 2026
  Expires: 20 November 2026


      WLP: Wet-Lab Protocol -- AI-to-Automation Instruction Schema v0
                             draft-aevum-wlp-00

  Abstract

     This document specifies WLP v0, the Wet-Lab Protocol for translating
     AI hypotheses (PACR records) into machine-executable wet-lab
     instructions.  WLP is the longevity-research analogue of SCP (Science
     Context Protocol) from the photoresist automation domain.  The
     protocol is royalty-free (Apache-2.0).  Reference implementations in
     Rust (crates/wlp-conformance) and Python
     (agentcard_adapters.wlp_conformance) are provided.

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





  Tsoi                    Expires 20 November 2026                [Page 1]


  Internet-Draft                     WLP                          May 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  WLP-instruction Schema v0.1 . . . . . . . . . . . . . . . . .   2
     3.  WLP-outcome Schema  . . . . . . . . . . . . . . . . . . . . .   3
     4.  AgentCard Extension . . . . . . . . . . . . . . . . . . . . .   4
     5.  Conformance Requirements  . . . . . . . . . . . . . . . . . .   4
     6.  Execution Flow  . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Lambda Throughput Ratio . . . . . . . . . . . . . . . . . . .   5
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     WLP closes the loop between AI hypothesis generation and physical
     experimental execution without human translation.  Each WLP-
     instruction carries a PACR provenance link and a lambda (energy)
     budget, enabling full cost accounting and falsifiability tracing.

     Key design principles: (1) AI-to-Machine direct translation -- WLP-
     instructions are machine-executable; (2) PACR traceable -- every
     instruction has a pacr_record_id provenance link; (3) lambda budget
     constrained -- platforms MUST reject over-budget instructions; (4)
     Conformance verifiable -- any platform can run the Conformance Suite.

  2.  WLP-instruction Schema v0.1
























  Tsoi                    Expires 20 November 2026                [Page 2]


  Internet-Draft                     WLP                          May 2026


  {
    "wlp_version": "0.1",
    "instruction_id": "WLP-{gene}-{yyyymmdd}-{seq}",
    "target": {
      "gene": "FOXO3",
      "itt_l_id": "ITT-L-001",
      "h_itt_v2": 0.72
    },
    "intervention": {
      "type": "crispr_knockdown | compound | overexpression | sirna | small_molecule",
      "reagent": "sgRNA-FOXO3-001",
      "dose": {"value": 10, "unit": "nM | uM | mg/kg"},
      "window": {"start_day": 0, "end_day": 14}
    },
    "readout": {
      "primary": "S_T_delta",
      "secondary": ["lifespan_extension_pct", "healthspan_marker"],
      "model": "C_elegans | mouse | organoid | cell_line",
      "timepoint_days": [7, 14, 30]
    },
    "expected": {
      "S_T_delta": 0.05,
      "confidence": 0.65,
      "basis": "superlearner_dqn_v2"
    },
    "constraints": {
      "lambda_budget_j": 500,
      "max_duration_days": 30,
      "min_replicates": 3
    },
    "provenance": {
      "generated_by": "II:superlearner-meta-v1",
      "pacr_record_id": "pacr-discovery-v3:line-XXXXXX",
      "wlp_conformance": "v0.1"
    }
  }

  3.  WLP-outcome Schema













  Tsoi                    Expires 20 November 2026                [Page 3]


  Internet-Draft                     WLP                          May 2026


     {
       "instruction_id": "WLP-FOXO3-20260519-001",
       "executed_by": "wet-lab-node-001",
       "execution_date": "2026-05-26",
       "result": {
         "S_T_delta_observed": 0.048,
         "S_T_delta_expected": 0.050,
         "prediction_accuracy": 0.96,
         "replicates": 3,
         "p_value": 0.023
       },
       "lambda_actual_j": 420,
       "falsification_triggered": false,
       "notes": ""
     }

  4.  AgentCard Extension

     Wet-lab nodes MUST declare capability via AgentCard extension fields:

     {
       "execution_capability": ["crispr-screen", "organoid-assay",
                                 "model-organism", "compound-screen"],
       "wlp_version": "0.1",
       "throughput": {
         "assays_per_week": 10,
         "lambda_capacity_j_per_week": 5000
       }
     }

  5.  Conformance Requirements

     An implementation is conformant if it passes all 5 tests.  Reference
     test vectors are in crates/wlp-conformance/src/lib.rs.

















  Tsoi                    Expires 20 November 2026                [Page 4]


  Internet-Draft                     WLP                          May 2026


               +===================+===========================+
               | Test              | Acceptance Criterion      |
               +===================+===========================+
               | schema_valid      | WLP-instruction has all 8 |
               |                   | required top-level fields |
               +-------------------+---------------------------+
               | pacr_traceable    | provenance.pacr_record_id |
               |                   | is non-empty              |
               +-------------------+---------------------------+
               | lambda_bounded    | lambda_actual_j <=        |
               |                   | lambda_budget_j           |
               +-------------------+---------------------------+
               | outcome_parseable | WLP-outcome has all 5     |
               |                   | required fields           |
               +-------------------+---------------------------+
               | s_t_delta_range   | S_T_delta_observed in     |
               |                   | [-1.0, 1.0]               |
               +-------------------+---------------------------+

                                    Table 1

  6.  Execution Flow

     Superlearner DQN
       -> generate WLP-instruction
       -> write to ~/.eon/bus/wlp-queue.jsonl
             |
             v
     wlp_dispatcher.py
       -> match wet-lab-node AgentCard (execution_capability filter)
       -> send WLP-instruction to node
             |
             v
     Automated wet-lab platform
       -> execute experiment
       -> return WLP-outcome.json
             |
             v
     wlp_outcome_bridge.py
       -> convert to PACR record (domain="wet_lab")
       -> write to ~/.eon/pacr-wet-lab-v1.jsonl

  7.  Lambda Throughput Ratio

  lambda_throughput_ratio = PACR_virtual_hypotheses / WLP_executed_instructions

  Target (Day 90): filtered hypotheses (H_ITT_v2 >= 0.5) / WLP count >= 1000x




  Tsoi                    Expires 20 November 2026                [Page 5]


  Internet-Draft                     WLP                          May 2026


  8.  IANA Considerations

     This document has no IANA actions.

  9.  Security Considerations

     WLP-instructions carry lambda budgets that MUST be enforced by
     execution platforms to prevent resource exhaustion.  PACR provenance
     links MUST be validated before execution.

  Author's Address

     Kwai Lap Tsoi
     Aevum Network
     Email: kwailapt@gmail.com
     URI:   https://github.com/kwailapt/EON



































  Tsoi                    Expires 20 November 2026                [Page 6]


name: draft-baur-pap
rev: 00
title: Principal Agent Protocol (PAP)
time: 2026-05-20T18:06:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-21T18:06:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:43.021544+00:00
source: ietf
abstract:
  This document specifies the Principal Agent Protocol (PAP), a
     cryptographic protocol for human-controlled agent-to-agent
     transactions.  PAP establishes a trust model rooted in human
     principals, defines hierarchical delegation through signed mandates,
     enforces context minimization through selective disclosure at the
     protocol level, and provides session ephemerality as a structural
     guarantee.  The protocol uses no novel cryptographic primitives and
     requires no central registry, token economy, or trusted third party.

full_text:
  Network Working Group                                            T. Baur
  Internet-Draft                                             Baur Software
  Intended status: Informational                               20 May 2026
  Expires: 21 November 2026


                       Principal Agent Protocol (PAP)
                             draft-baur-pap-00

  Abstract

     This document specifies the Principal Agent Protocol (PAP), a
     cryptographic protocol for human-controlled agent-to-agent
     transactions.  PAP establishes a trust model rooted in human
     principals, defines hierarchical delegation through signed mandates,
     enforces context minimization through selective disclosure at the
     protocol level, and provides session ephemerality as a structural
     guarantee.  The protocol uses no novel cryptographic primitives and
     requires no central registry, token economy, or trusted third party.

  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 21 November 2026.

  Copyright Notice

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










  Baur                    Expires 21 November 2026                [Page 1]


  Internet-Draft                     PAP                          May 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   6
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
       1.3.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   7
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   7
       2.1.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Trust Model and Threat Model  . . . . . . . . . . . . . . . .   8
       3.1.  Trust Hierarchy . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Trust Assumptions . . . . . . . . . . . . . . . . . . . .   8
       3.3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   9
       3.4.  Explicit Non-Goals  . . . . . . . . . . . . . . . . . . .  10
     4.  Identity Layer  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  DID Method  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.  DID Document  . . . . . . . . . . . . . . . . . . . . . .  11
       4.3.  Principal Keypair . . . . . . . . . . . . . . . . . . . .  11
       4.4.  Session Keypair . . . . . . . . . . . . . . . . . . . . .  11
     5.  Mandate Structure and Delegation Rules  . . . . . . . . . . .  12
       5.1.  Mandate Object  . . . . . . . . . . . . . . . . . . . . .  12
       5.2.  Mandate Signing . . . . . . . . . . . . . . . . . . . . .  14
       5.3.  Mandate Hashing . . . . . . . . . . . . . . . . . . . . .  14
       5.4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .  14
         5.4.1.  5.4.1.  Scope Object  . . . . . . . . . . . . . . . .  14
         5.4.2.  5.4.2.  ScopeAction Object  . . . . . . . . . . . . .  15
         5.4.3.  5.4.3.  DisclosureSet Object  . . . . . . . . . . . .  15
         5.4.4.  5.4.4.  DisclosureEntry Object  . . . . . . . . . . .  16
         5.4.5.  5.4.4.1.  TEE Requirement for No-Retention
                 Disclosures . . . . . . . . . . . . . . . . . . . . .  17
         5.4.6.  5.4.5.  Scope Containment . . . . . . . . . . . . . .  18
       5.5.  Delegation Rules  . . . . . . . . . . . . . . . . . . . .  18
       5.6.  Mandate Chain Verification  . . . . . . . . . . . . . . .  18
       5.7.  Decay State Machine . . . . . . . . . . . . . . . . . . .  19
         5.7.1.  5.7.1.  State Transitions . . . . . . . . . . . . . .  19
         5.7.2.  5.7.2.  Decay Computation . . . . . . . . . . . . . .  20
     6.  Session Lifecycle . . . . . . . . . . . . . . . . . . . . . .  20
       6.1.  Session State Machine . . . . . . . . . . . . . . . . . .  21
       6.2.  Capability Token  . . . . . . . . . . . . . . . . . . . .  22
         6.2.1.  6.2.1.  Token Signing . . . . . . . . . . . . . . . .  22



  Baur                    Expires 21 November 2026                [Page 2]


  Internet-Draft                     PAP                          May 2026


         6.2.2.  6.2.2.  Token Verification  . . . . . . . . . . . . .  23
       6.3.  Six-Phase Handshake . . . . . . . . . . . . . . . . . . .  23
         6.3.1.  6.3.1.  Phase 1: Token Presentation . . . . . . . . .  24
         6.3.2.  6.3.2.  Phase 2: Ephemeral DID Exchange . . . . . . .  24
         6.3.3.  6.3.3.  Phase 3: Disclosure . . . . . . . . . . . . .  25
         6.3.4.  6.3.4.  Phase 4: Execution  . . . . . . . . . . . . .  25
         6.3.5.  6.3.5.  Phase 5: Receipt Co-Signing . . . . . . . . .  25
         6.3.6.  6.3.6.  Phase 6: Session Close  . . . . . . . . . . .  25
     7.  SD-JWT Disclosure Protocol  . . . . . . . . . . . . . . . . .  25
       7.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  26
       7.2.  SD-JWT Object . . . . . . . . . . . . . . . . . . . . . .  26
       7.3.  Disclosure Object . . . . . . . . . . . . . . . . . . . .  26
       7.4.  Commitment Computation  . . . . . . . . . . . . . . . . .  27
       7.5.  Disclosure Verification . . . . . . . . . . . . . . . . .  27
       7.6.  Zero-Disclosure Sessions  . . . . . . . . . . . . . . . .  28
     8.  Protocol Messages and Envelope  . . . . . . . . . . . . . . .  28
       8.1.  Protocol Message Types  . . . . . . . . . . . . . . . . .  28
       8.2.  Envelope  . . . . . . . . . . . . . . . . . . . . . . . .  29
         8.2.1.  8.2.1.  Envelope Signing  . . . . . . . . . . . . . .  30
         8.2.2.  8.2.2.  Envelope Verification . . . . . . . . . . . .  31
     9.  Marketplace Advertisement Schema  . . . . . . . . . . . . . .  31
       9.1.  Agent Advertisement . . . . . . . . . . . . . . . . . . .  31
       9.2.  Provider Object . . . . . . . . . . . . . . . . . . . . .  33
       9.3.  Disclosure Filtering  . . . . . . . . . . . . . . . . . .  33
       9.4.  Advertisement Signing . . . . . . . . . . . . . . . . . .  33
       9.5.  Advertisement Hashing . . . . . . . . . . . . . . . . . .  34
       9.6.  Operator Metrics  . . . . . . . . . . . . . . . . . . . .  34
     10. Federation Protocol . . . . . . . . . . . . . . . . . . . . .  36
       10.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  36
       10.2.  Registry Peer  . . . . . . . . . . . . . . . . . . . . .  36
       10.3.  Federation Messages  . . . . . . . . . . . . . . . . . .  36
       10.4.  Federation Endpoints . . . . . . . . . . . . . . . . . .  37
       10.5.  Content-Hash Deduplication . . . . . . . . . . . . . . .  38
       10.6.  Peer Discovery . . . . . . . . . . . . . . . . . . . . .  38
       10.7.  Peer Trust Signals . . . . . . . . . . . . . . . . . . .  38
         10.7.1.  10.7.1.  Signal Categories . . . . . . . . . . . . .  38
         10.7.2.  10.7.2.  Peer Vouch  . . . . . . . . . . . . . . . .  39
         10.7.3.  10.7.3.  Vouch Budget  . . . . . . . . . . . . . . .  39
     11. Receipt Format  . . . . . . . . . . . . . . . . . . . . . . .  39
       11.1.  Transaction Receipt  . . . . . . . . . . . . . . . . . .  40
       11.2.  Receipt Signing  . . . . . . . . . . . . . . . . . . . .  41
       11.3.  Co-Signing Protocol  . . . . . . . . . . . . . . . . . .  41
       11.4.  Receipt Verification . . . . . . . . . . . . . . . . . .  41
       11.5.  Privacy Properties . . . . . . . . . . . . . . . . . . .  41
       11.6.  Session Attestation  . . . . . . . . . . . . . . . . . .  42
     12. Verifiable Credential Envelope  . . . . . . . . . . . . . . .  42
       12.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  43
       12.2.  VC Structure . . . . . . . . . . . . . . . . . . . . . .  43



  Baur                    Expires 21 November 2026                [Page 3]


  Internet-Draft                     PAP                          May 2026


       12.3.  Credential Signing . . . . . . . . . . . . . . . . . . .  43
     13. Extension Points  . . . . . . . . . . . . . . . . . . . . . .  44
       13.1.  Payment Proof  . . . . . . . . . . . . . . . . . . . . .  44
         13.1.1.  13.1.1.  Bolt11Hash  . . . . . . . . . . . . . . . .  44
         13.1.2.  13.1.2.  CashuTokenHash  . . . . . . . . . . . . . .  45
         13.1.3.  13.1.3.  Payment Proof Properties  . . . . . . . . .  45
         13.1.4.  13.1.4.  Ecash Blind Signature Protocol  . . . . . .  45
       13.2.  Payment Proof Verification . . . . . . . . . . . . . . .  47
         13.2.1.  13.2.1.  Receipt Payment Proof Commitment  . . . . .  47
       13.3.  Continuity Tokens  . . . . . . . . . . . . . . . . . . .  47
         13.3.1.  13.3.1.  Continuity Token Lifecycle  . . . . . . . .  48
         13.3.2.  13.3.2.  Continuity Token Properties . . . . . . . .  48
       13.4.  Auto-Approval Policies . . . . . . . . . . . . . . . . .  49
         13.4.1.  13.4.1.  Auto-Approval Constraints . . . . . . . . .  49
       13.5.  M-of-N Social Recovery . . . . . . . . . . . . . . . . .  50
         13.5.1.  13.5.1.  Recovery Mandate  . . . . . . . . . . . . .  50
         13.5.2.  13.5.2.  Recovery Request  . . . . . . . . . . . . .  50
         13.5.3.  13.5.3.  Partial Recovery Signature (Blind)  . . . .  51
         13.5.4.  13.5.4.  Recovery Proof Assembly . . . . . . . . . .  52
         13.5.5.  13.5.5.  Revocation Proof and Broadcast  . . . . . .  52
         13.5.6.  13.5.6.  NotarySet Registry  . . . . . . . . . . . .  53
         13.5.7.  13.5.7.  Security Properties . . . . . . . . . . . .  53
       13.6.  TEE Attestation  . . . . . . . . . . . . . . . . . . . .  54
         13.6.1.  13.6.1.  Attestation Object  . . . . . . . . . . . .  54
         13.6.2.  13.6.2.  Attestation Verification  . . . . . . . . .  54
         13.6.3.  13.6.3.  Trust Boundaries  . . . . . . . . . . . . .  55
         13.6.4.  13.6.4.  Implementation Notes  . . . . . . . . . . .  55
       13.7.  Payment Proof Validation . . . . . . . . . . . . . . . .  55
         13.7.1.  13.7.1.  Proof Format Registry . . . . . . . . . . .  55
         13.7.2.  13.7.2.  Validation Requirements . . . . . . . . . .  56
         13.7.3.  13.7.3.  Privacy Requirements  . . . . . . . . . . .  56
       13.8.  Chat and Real-Time Communication . . . . . . . . . . . .  56
         13.8.1.  13.8.1.  Overview  . . . . . . . . . . . . . . . . .  57
         13.8.2.  13.8.2.  Capability Grant  . . . . . . . . . . . . .  57
         13.8.3.  13.8.3.  Phase 4 Streaming Mode  . . . . . . . . . .  57
         13.8.4.  13.8.4.  Message Format (DIDComm basicmessage) . . .  58
         13.8.5.  13.8.5.  Receipt . . . . . . . . . . . . . . . . . .  58
         13.8.6.  13.8.6.  Group Chat Rooms  . . . . . . . . . . . . .  58
         13.8.7.  13.8.7.  Audio and Video . . . . . . . . . . . . . .  59
         13.8.8.  13.8.8.  Privacy Properties  . . . . . . . . . . . .  59
     14. Transport Binding . . . . . . . . . . . . . . . . . . . . . .  59
       14.1.  HTTP/JSON Transport  . . . . . . . . . . . . . . . . . .  59
       14.2.  Agent Server Endpoints . . . . . . . . . . . . . . . . .  60
       14.3.  Agent Handler Interface  . . . . . . . . . . . . . . . .  60
       14.4.  Endpoint Resolution  . . . . . . . . . . . . . . . . . .  61
       14.5.  Content Type . . . . . . . . . . . . . . . . . . . . . .  61
       14.6.  Error Handling . . . . . . . . . . . . . . . . . . . . .  61
       14.7.  WebSocket Transport  . . . . . . . . . . . . . . . . . .  62



  Baur                    Expires 21 November 2026                [Page 4]


  Internet-Draft                     PAP                          May 2026


         14.7.1.  14.7.1.  Connection Lifecycle  . . . . . . . . . . .  62
         14.7.2.  14.7.2.  Endpoint Format . . . . . . . . . . . . . .  62
         14.7.3.  14.7.3.  Message Framing . . . . . . . . . . . . . .  62
         14.7.4.  14.7.4.  Sequence Enforcement  . . . . . . . . . . .  62
       14.8.  Oblivious HTTP (OHTTP) Transport . . . . . . . . . . . .  62
         14.8.1.  14.8.1.  Architecture  . . . . . . . . . . . . . . .  63
         14.8.2.  14.8.2.  Encapsulation . . . . . . . . . . . . . . .  63
         14.8.3.  14.8.3.  Key Configuration . . . . . . . . . . . . .  63
         14.8.4.  14.8.4.  Relay Selection . . . . . . . . . . . . . .  63
       14.9.  DIDComm Transport  . . . . . . . . . . . . . . . . . . .  63
         14.9.1.  14.9.1.  Message Mapping . . . . . . . . . . . . . .  63
         14.9.2.  14.9.2.  Encryption  . . . . . . . . . . . . . . . .  64
         14.9.3.  14.9.3.  Service Endpoint  . . . . . . . . . . . . .  64
       14.10. Transport Negotiation  . . . . . . . . . . . . . . . . .  64
       14.11. DIDComm v2 Envelope Compatibility  . . . . . . . . . . .  65
         14.11.1.  14.11.1.  Design Principles . . . . . . . . . . . .  65
         14.11.2.  14.11.2.  Plaintext Messages  . . . . . . . . . . .  65
         14.11.3.  14.11.3.  Signed Messages (Ed25519 JWS) . . . . . .  66
         14.11.4.  14.11.4.  Encrypted Messages (ECDH-ES + A256GCM
                 JWE)  . . . . . . . . . . . . . . . . . . . . . . . .  66
         14.11.5.  14.11.5.  Ed25519 to X25519 Key Conversion  . . . .  67
         14.11.6.  14.11.6.  Translation Rules . . . . . . . . . . . .  67
     15. PAP URI Scheme  . . . . . . . . . . . . . . . . . . . . . . .  68
       15.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  68
       15.2.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . .  69
       15.3.  Resolution . . . . . . . . . . . . . . . . . . . . . . .  70
       15.4.  Action Type and Query Parameters . . . . . . . . . . . .  71
       15.5.  Recapture Semantics (pap+https://, pap+wss://) . . . . .  71
       15.6.  Link Rendering . . . . . . . . . . . . . . . . . . . . .  72
       15.7.  Special Authorities  . . . . . . . . . . . . . . . . . .  72
     16. Security Considerations . . . . . . . . . . . . . . . . . . .  73
       16.1.  Cryptographic Algorithms . . . . . . . . . . . . . . . .  73
       16.2.  Key Management . . . . . . . . . . . . . . . . . . . . .  73
       16.3.  Nonce Management . . . . . . . . . . . . . . . . . . . .  74
       16.4.  Replay Protection  . . . . . . . . . . . . . . . . . . .  74
       16.5.  Denial of Service  . . . . . . . . . . . . . . . . . . .  74
       16.6.  Man-in-the-Middle  . . . . . . . . . . . . . . . . . . .  74
       16.7.  Context Leakage  . . . . . . . . . . . . . . . . . . . .  75
       16.8.  Mandate Chain Depth  . . . . . . . . . . . . . . . . . .  75
       16.9.  Clock Skew . . . . . . . . . . . . . . . . . . . . . . .  75
       16.10. Canonical JSON Determinism . . . . . . . . . . . . . . .  75
       16.11. Attack Surface Summary . . . . . . . . . . . . . . . . .  75
     Appendix A.  Example: Zero-Disclosure Search  . . . . . . . . . .  76
       A.1.  A.1.  Setup . . . . . . . . . . . . . . . . . . . . . . .  76
       A.2.  A.2.  Root Mandate  . . . . . . . . . . . . . . . . . . .  77
       A.3.  A.3.  Marketplace Query . . . . . . . . . . . . . . . . .  77
       A.4.  A.4.  Session Handshake . . . . . . . . . . . . . . . . .  77
       A.5.  A.5.  Receipt . . . . . . . . . . . . . . . . . . . . . .  77



  Baur                    Expires 21 November 2026                [Page 5]


  Internet-Draft                     PAP                          May 2026


     Appendix B.  Example: Selective Disclosure Flight Booking . . . .  78
       B.1.  B.1.  Disclosure Set  . . . . . . . . . . . . . . . . . .  78
       B.2.  B.2.  SD-JWT Claims . . . . . . . . . . . . . . . . . . .  78
       B.3.  B.3.  Marketplace Filtering . . . . . . . . . . . . . . .  78
       B.4.  B.4.  Receipt . . . . . . . . . . . . . . . . . . . . . .  78
     Appendix C.  Example: 4-Level Delegation Chain  . . . . . . . . .  79
     Appendix D.  Conformance Test Matrix  . . . . . . . . . . . . . .  79
       D.1.  D.1.  Core Protocol Tests . . . . . . . . . . . . . . . .  79
       D.2.  D.2.  Transport Tests . . . . . . . . . . . . . . . . . .  83
       D.3.  D.3.  Extension Tests . . . . . . . . . . . . . . . . . .  83
       D.4.  D.4.  Federation Tests  . . . . . . . . . . . . . . . . .  85
       D.5.  D.5.  Trust Invariant Summary . . . . . . . . . . . . . .  85
     Appendix E.  References . . . . . . . . . . . . . . . . . . . . .  86
       E.1.  Normative References  . . . . . . . . . . . . . . . . . .  86
       E.2.  Informative References  . . . . . . . . . . . . . . . . .  87
     Appendix F.  IANA and Vocabulary References . . . . . . . . . . .  87
       F.1.  Schema.org Vocabulary . . . . . . . . . . . . . . . . . .  87
       F.2.  W3C Standards . . . . . . . . . . . . . . . . . . . . . .  88
       F.3.  IETF Standards  . . . . . . . . . . . . . . . . . . . . .  88
       F.4.  WebAuthn  . . . . . . . . . . . . . . . . . . . . . . . .  89
       F.5.  Multicodec  . . . . . . . . . . . . . . . . . . . . . . .  89
       F.6.  Reserved Namespace Prefixes . . . . . . . . . . . . . . .  89
     Appendix G.  Changelog  . . . . . . . . . . . . . . . . . . . . .  90
       G.1.  v1.0 (2026-03-24) . . . . . . . . . . . . . . . . . . . .  90
       G.2.  v0.7 (2026-03-10) . . . . . . . . . . . . . . . . . . . .  90
       G.3.  v0.6 (2026-02-28) . . . . . . . . . . . . . . . . . . . .  90
       G.4.  v0.4 (2026-02-01) . . . . . . . . . . . . . . . . . . . .  90
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  91

  1.  Introduction

  1.1.  Problem Statement

     Existing agent-to-agent protocols authenticate agents as platform
     entities, not as delegates of human principals.  None enforce context
     minimization at the protocol level.  Disclosure is implementation-
     dependent.  Session ephemerality is undefined.  Execution isolation
     is absent—agents run in the same address space as the orchestrator or
     other services, creating blast radius problems even when disclosure
     is minimized.  Economic models underneath these protocols are
     compatible with platform capture through cloud compute metering.

  1.2.  Design Goals

     PAP is designed to satisfy the following goals:

     1.  The human principal is the root of trust for every transaction.




  Baur                    Expires 21 November 2026                [Page 6]


  Internet-Draft                     PAP                          May 2026


     2.  Context disclosure is enforced by the protocol at the request
         boundary (via SD-JWT).
     3.  Execution is isolated at the process boundary via OS-level
         capabilities.
     4.  Sessions are ephemeral by design; no persistent correlation.
     5.  Delegation is hierarchical with cryptographically enforced
         bounds.
     6.  Co-signed receipts prove both disclosure scope and execution
         constraints.
     7.  No novel cryptography, no token economy, no central registry.
     8.  Any compliant implementation MUST be buildable from this document
         alone, without reference to a specific programming language.

  1.3.  Protocol Overview

     A PAP transaction involves:

     *  A *human principal* who holds a device-bound keypair.
     *  An *orchestrator agent* operating under a root mandate.
     *  One or more *downstream agents* operating under delegated
        mandates, each executing in sandboxed isolation.
     *  A *marketplace* for agent discovery and disclosure filtering.
     *  A *6-phase session handshake* between pairs of agents.
     *  *Request boundary security* via SD-JWT selective disclosure
        (minimize what the agent sees).
     *  *Execution boundary security* via OS sandboxing (minimize what the
        agent can do).
     *  *Co-signed receipts* recording property references and enforcement
        proof, never values.

  2.  Conventions and 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 [RFC 2119] [RFC 8174] when, and only when, they appear in all
     capitals, as shown here.

  2.1.  Definitions

     *Principal:* A human user who holds the root keypair and is the
     ultimate authority over all agent actions taken on their behalf.

     *Orchestrator:* An agent that holds the root mandate from the
     principal.  The orchestrator is the only agent that MAY hold the
     principal's full context.  It delegates scoped mandates to downstream
     agents.




  Baur                    Expires 21 November 2026                [Page 7]


  Internet-Draft                     PAP                          May 2026


     *Mandate:* A signed authorization object that specifies what an agent
     is permitted to do, what context it may disclose, and when the
     authorization expires.

     *Mandate Chain:* An ordered sequence of mandates from root to leaf,
     each cryptographically linked to its parent.

     *Scope:* The set of actions a mandate permits.  Deny-by-default: an
     empty scope permits nothing.

     *Disclosure Set:* The set of context classes an agent holds and the
     conditions under which they may be shared.

     *Capability Token:* A single-use, signed authorization to open a
     session with a specific agent for a specific action.

     *Session DID:* An ephemeral did:key identifier generated for a single
     session and discarded at session close.

     *Receipt:* A co-signed record of a transaction that contains property
     type references but never property values.

     *Decay State:* The lifecycle state of a mandate as it approaches or
     passes its TTL without renewal.

  3.  Trust Model and Threat Model

  3.1.  Trust Hierarchy

     The PAP trust hierarchy is:

     Human Principal (device-bound keypair, root of trust)
       +-- Orchestrator Agent (root mandate, full principal context)
            +-- Downstream Agent (task mandate, scoped context)
                 +-- Marketplace Agent (own principal chain)

     The principal's device-bound keypair is the sole root of trust.
     Every agent in a transaction MUST carry a cryptographically
     verifiable mandate chain traceable to this root.

  3.2.  Trust Assumptions

       +======================+=======================================+
       | Assumption           | Verification Method                   |
       +======================+=======================================+
       | Principal keypair    | WebAuthn device binding (Section 4.3) |
       | not compromised      |                                       |
       +----------------------+---------------------------------------+



  Baur                    Expires 21 November 2026                [Page 8]


  Internet-Draft                     PAP                          May 2026


       | Orchestrator         | Mandate chain verification            |
       | delegates correctly  | (Section 5.6)                         |
       +----------------------+---------------------------------------+
       | Session keys not     | Single-use per session, discarded at  |
       | leaked               | close                                 |
       +----------------------+---------------------------------------+
       | Clocks approximately | RFC 3339 timestamps; receivers SHOULD |
       | synchronized         | reject tokens with skew exceeding     |
       |                      | implementation-defined thresholds     |
       +----------------------+---------------------------------------+
       | Ed25519 not broken   | Cryptographic library security;       |
       |                      | algorithm agility reserved for future |
       |                      | versions                              |
       +----------------------+---------------------------------------+

                                   Table 1

  3.3.  Threat Model

     PAP is designed to defend against the following threats:

     *T1.  Context profiling.* An adversary correlates a principal's
     transactions across sessions to build a behavioral profile.
     _Mitigation:_ Ephemeral session DIDs (Section 6.3) ensure each
     session is cryptographically unlinkable.

     *T2.  Over-disclosure.* An agent discloses more principal context
     than the principal authorized. _Mitigation:_ SD-JWT selective
     disclosure (Section 7) structurally prevents disclosure of claims not
     included in the disclosure set.  Marketplace filtering (Section 9.3)
     excludes agents whose requirements exceed the mandate before any
     session is established.

     *T3.  Delegation bypass.* A downstream agent acts outside its
     delegated scope. _Mitigation:_ Scope containment (Section 5.4) and
     TTL bounds (Section 5.5) are verified cryptographically at each level
     of the mandate chain.

     *T4.  Replay attacks.* An adversary replays a captured capability
     token to open an unauthorized session. _Mitigation:_ Nonce
     consumption (Section 6.2) ensures each token is single-use.

     *T5.  Mandate tampering.* An adversary modifies a mandate in the
     chain. _Mitigation:_ Parent hash binding (Section 5.3) and Ed25519
     signatures (Section 5.2) detect any modification.






  Baur                    Expires 21 November 2026                [Page 9]


  Internet-Draft                     PAP                          May 2026


     *T6.  Platform capture.* A platform operator accumulates control over
     agent transactions through infrastructure dependency. _Mitigation:_
     Federated discovery (Section 10), no central registry, no token
     economy, principal-held keys.  Marketplace registries MUST NOT rank
     query results by operator metrics (Section 9.6) — ranking power is
     platform capture power.  Trust evaluation is the principal's
     responsibility.

     *T7.  Payment linkability.* A payment is correlated with the
     principal's identity. _Mitigation:_ Chaumian ecash blind-signed
     tokens (Section 13.1) provide unlinkable proof of value transfer.

  3.4.  Explicit Non-Goals

     The following are explicitly out of scope for PAP:

     1.  Compatibility with token economy monetization.
     2.  Enclave-as-equivalent-to-local trust models.
     3.  Identity recovery through platform operators.
     4.  Central registries for agent discovery.
     5.  Runtime scope expansion of mandates.
     6.  Arbitrary code execution in the orchestrator context.
     7.  Any extension that trades trust guarantees for adoption ease.

  4.  Identity Layer

  4.1.  DID Method

     PAP uses the did:key method as defined in [DID-KEY].  All identifiers
     MUST use Ed25519 public keys with the following derivation:

     did:key:z<base58btc(0xed01 || public_key_bytes)>

     Where: - 0xed01 is the multicodec prefix for Ed25519 public keys. -
     public_key_bytes is the 32-byte Ed25519 public key. - base58btc is
     Bitcoin's base58 encoding. - The z prefix indicates base58btc
     multibase encoding.

     Implementations MUST support did:key resolution by extracting the
     public key bytes from the DID string:

     1.  Strip the did:key:z prefix.
     2.  Base58-decode the remainder.
     3.  Verify the first two bytes are 0xed and 0x01.
     4.  The remaining 32 bytes are the Ed25519 public key.






  Baur                    Expires 21 November 2026               [Page 10]


  Internet-Draft                     PAP                          May 2026


  4.2.  DID Document

     A DID document for a PAP identity MUST conform to [DID-CORE] and
     contain:

     {
       "@context": "https://www.w3.org/ns/did/v1",
       "id": "did:key:z...",
       "verificationMethod": [{
         "id": "did:key:z...#key-1",
         "type": "Ed25519VerificationKey2020",
         "controller": "did:key:z...",
         "publicKeyMultibase": "z<base58btc(0xed01 ++ public_key_bytes)>"
       }],
       "authentication": ["did:key:z...#key-1"]
     }

     A DID document MUST NOT contain any personal information.  It
     contains only the public key and verification method reference.

  4.3.  Principal Keypair

     The principal keypair is the root of trust.  It MUST be an Ed25519
     keypair.  In production deployments, the private key SHOULD be bound
     to a hardware authenticator via WebAuthn [WEBAUTHN].

     Implementations MUST support the PrincipalSigner interface:

     *  did() -> String -- The did:key identifier.
     *  sign(message: bytes) -> bytes -- Ed25519 signature (64 bytes).
     *  verifying_key() -> Ed25519PublicKey -- The public key.

     Implementations MAY use software keys for development and testing.
     Production deployments SHOULD use WebAuthn-backed keys.

  4.4.  Session Keypair

     A session keypair is an ephemeral Ed25519 keypair generated fresh for
     each protocol session.  Session keypairs:

     *  MUST be generated using a cryptographically secure random number
        generator.
     *  MUST NOT be derived from or linked to the principal keypair.
     *  MUST be discarded when the session closes.
     *  MUST NOT be persisted to stable storage.






  Baur                    Expires 21 November 2026               [Page 11]


  Internet-Draft                     PAP                          May 2026


     The session DID is derived using the same did:key method as the
     principal DID.  An observer MUST NOT be able to determine whether a
     did:key identifier represents a principal or a session key.

  5.  Mandate Structure and Delegation Rules

  5.1.  Mandate Object

     A mandate is the core delegation primitive.  It authorizes an agent
     to perform specific actions with specific context.  A mandate MUST
     contain the following fields:








































  Baur                    Expires 21 November 2026               [Page 12]


  Internet-Draft                     PAP                          May 2026


      +=====================+=============+========+====================+
      | Field               |Type         |Required| Description        |
      +=====================+=============+========+====================+
      | principal_did       |String       |REQUIRED| DID of the human   |
      |                     |             |        | principal (root of |
      |                     |             |        | trust)             |
      +---------------------+-------------+--------+--------------------+
      | agent_did           |String       |REQUIRED| DID of the agent   |
      |                     |             |        | receiving this     |
      |                     |             |        | mandate            |
      +---------------------+-------------+--------+--------------------+
      | issuer_did          |String       |REQUIRED| DID of the entity  |
      |                     |             |        | signing this       |
      |                     |             |        | mandate            |
      +---------------------+-------------+--------+--------------------+
      | parent_mandate_hash |String or    |REQUIRED| SHA-256 hash of    |
      |                     |null         |        | the parent         |
      |                     |             |        | mandate, or null   |
      |                     |             |        | for root mandates  |
      +---------------------+-------------+--------+--------------------+
      | scope               |Scope        |REQUIRED| Permitted actions  |
      |                     |             |        | (Section 5.4)      |
      +---------------------+-------------+--------+--------------------+
      | disclosure_set      |DisclosureSet|REQUIRED| Context classes    |
      |                     |             |        | and sharing        |
      |                     |             |        | conditions         |
      |                     |             |        | (Section 5.4.3)    |
      +---------------------+-------------+--------+--------------------+
      | ttl                 |DateTime     |REQUIRED| Expiry timestamp   |
      |                     |             |        | (RFC 3339)         |
      +---------------------+-------------+--------+--------------------+
      | decay_state         |DecayState   |REQUIRED| Current lifecycle  |
      |                     |             |        | state              |
      |                     |             |        | (Section 5.7)      |
      +---------------------+-------------+--------+--------------------+
      | issued_at           |DateTime     |REQUIRED| Issuance timestamp |
      |                     |             |        | (RFC 3339)         |
      +---------------------+-------------+--------+--------------------+
      | payment_proof       |PaymentProof |OPTIONAL| ZK payment         |
      |                     |or null      |        | commitment         |
      |                     |             |        | (Section 13.1)     |
      +---------------------+-------------+--------+--------------------+
      | signature           |String or    |OPTIONAL| Ed25519 signature  |
      |                     |null         |        | (base64url-no-pad) |
      +---------------------+-------------+--------+--------------------+

                                    Table 2




  Baur                    Expires 21 November 2026               [Page 13]


  Internet-Draft                     PAP                          May 2026


  5.2.  Mandate Signing

     A mandate MUST be signed by the issuer's Ed25519 signing key.

     The canonical form for signing MUST be computed as follows:

     1.  Construct a JSON object containing all mandate fields EXCEPT
         signature.
     2.  DateTime fields MUST be serialized as RFC 3339 strings.
     3.  Null fields MUST be included as JSON null.
     4.  Serialize the JSON object to bytes.
     5.  Compute the Ed25519 signature over these bytes.
     6.  Encode the 64-byte signature using base64url without padding (RFC
         4648 Section 5, no = padding).

     The canonical JSON object MUST contain exactly these keys:

     {
       "principal_did": "...",
       "agent_did": "...",
       "issuer_did": "...",
       "parent_mandate_hash": null,
       "scope": { ... },
       "disclosure_set": { ... },
       "ttl": "2026-03-15T20:00:00+00:00",
       "issued_at": "2026-03-15T16:00:00+00:00",
       "payment_proof": null
     }

  5.3.  Mandate Hashing

     The mandate hash is used for parent-child linking in delegation
     chains.  It MUST be computed as:

     1.  Compute the canonical form (Section 5.2, step 1-4).
     2.  Apply SHA-256 to the canonical bytes.
     3.  Encode the 32-byte digest using base64url without padding.

     The hash MUST be deterministic: the same mandate MUST always produce
     the same hash.

  5.4.  Scope

  5.4.1.  5.4.1.  Scope Object

     A scope defines the set of permitted actions.  It is deny-by-default:
     an agent with an empty scope MUST NOT perform any action.




  Baur                    Expires 21 November 2026               [Page 14]


  Internet-Draft                     PAP                          May 2026


     {
       "actions": [
         {
           "action": "schema:SearchAction",
           "object": "schema:WebPage",
           "conditions": {}
         }
       ]
     }

     +=========+======================+==========+=======================+
     | Field   | Type                 | Required | Description           |
     +=========+======================+==========+=======================+
     | actions | Array of ScopeAction | REQUIRED | The permitted         |
     |         |                      |          | actions               |
     +---------+----------------------+----------+-----------------------+

                                    Table 3

  5.4.2.  5.4.2.  ScopeAction Object

       +============+=========+==========+=============================+
       | Field      | Type    | Required | Description                 |
       +============+=========+==========+=============================+
       | action     | String  | REQUIRED | Schema.org action type      |
       |            |         |          | (e.g., schema:SearchAction) |
       +------------+---------+----------+-----------------------------+
       | object     | String  | OPTIONAL | Schema.org object type      |
       |            | or null |          | constraint (e.g.,           |
       |            |         |          | schema:Flight)              |
       +------------+---------+----------+-----------------------------+
       | conditions | Object  | OPTIONAL | Protocol-level conditions   |
       |            |         |          | (key-value pairs).          |
       |            |         |          | Default: empty object.      |
       +------------+---------+----------+-----------------------------+

                                    Table 4

     Action and object type references MUST use the schema: prefix for
     Schema.org vocabulary.  Implementations MAY define additional
     namespaced prefixes for domain-specific vocabularies.

  5.4.3.  5.4.3.  DisclosureSet Object

     The disclosure set defines what context an agent holds and the
     conditions for sharing it.





  Baur                    Expires 21 November 2026               [Page 15]


  Internet-Draft                     PAP                          May 2026


     {
       "entries": [
         {
           "type": "schema:Person",
           "permitted_properties": ["schema:name", "schema:nationality"],
           "prohibited_properties": ["schema:email", "schema:telephone"],
           "session_only": true,
           "no_retention": true
         }
       ]
     }

      +=========+==========================+==========+================+
      | Field   | Type                     | Required | Description    |
      +=========+==========================+==========+================+
      | entries | Array of DisclosureEntry | REQUIRED | The disclosure |
      |         |                          |          | entries        |
      +---------+--------------------------+----------+----------------+

                                   Table 5

  5.4.4.  5.4.4.  DisclosureEntry Object

     +=======================+=========+==========+=====================+
     | Field                 | Type    | Required | Description         |
     +=======================+=========+==========+=====================+
     | type                  | String  | REQUIRED | Schema.org type     |
     |                       |         |          | (e.g.,              |
     |                       |         |          | schema:Person)      |
     +-----------------------+---------+----------+---------------------+
     | permitted_properties  | Array   | REQUIRED | Properties the      |
     |                       | of      |          | agent MAY disclose  |
     |                       | String  |          |                     |
     +-----------------------+---------+----------+---------------------+
     | prohibited_properties | Array   | REQUIRED | Properties the      |
     |                       | of      |          | agent MUST NOT      |
     |                       | String  |          | disclose            |
     +-----------------------+---------+----------+---------------------+
     | session_only          | Boolean | OPTIONAL | If true, disclosed  |
     |                       |         |          | data is valid only  |
     |                       |         |          | for the session     |
     |                       |         |          | duration.  Default: |
     |                       |         |          | false.              |
     +-----------------------+---------+----------+---------------------+
     | no_retention          | Boolean | OPTIONAL | If true, the        |
     |                       |         |          | receiving party     |
     |                       |         |          | MUST NOT retain     |
     |                       |         |          | disclosed data      |



  Baur                    Expires 21 November 2026               [Page 16]


  Internet-Draft                     PAP                          May 2026


     |                       |         |          | beyond the session. |
     |                       |         |          | Default: false.     |
     +-----------------------+---------+----------+---------------------+

                                   Table 6

     Property references MUST use Schema.org property names with the
     schema: prefix.

     *Property Reference Format:* When used in receipts or marketplace
     advertisements, a fully qualified property reference is formed as
     {type}.{property}, e.g., schema:Person.schema:name.

  5.4.5.  5.4.4.1.  TEE Requirement for No-Retention Disclosures

     When a disclosure entry has no_retention set to true, the receiving
     agent MUST provide TEE attestation (Section 13.6) during session
     establishment.  If the receiving agent cannot provide valid TEE
     attestation, the initiating agent MUST NOT disclose properties from
     that entry.

     Without TEE attestation, no_retention is a contractual constraint
     only — the protocol cannot enforce data deletion on an untrusted
     host.  Implementations SHOULD clearly communicate this limitation to
     principals when TEE attestation is unavailable.

     An implementation's disclosure validation MUST return one of three
     states to the caller:

      +=================+===============================================+
      | State           | Meaning                                       |
      +=================+===============================================+
      | NotRequired     | No no_retention entries in the disclosure set |
      +-----------------+-----------------------------------------------+
      | TeeEnforced     | TEE attestation present; retention constraint |
      |                 | is cryptographic                              |
      +-----------------+-----------------------------------------------+
      | ContractualOnly | No TEE available; no_retention is a           |
      |                 | contractual term only                         |
      +-----------------+-----------------------------------------------+

                                    Table 7

     Implementations that support the TEE extension (Section 13.6) MUST
     treat ContractualOnly as an error.  Implementations without TEE
     support MAY proceed with ContractualOnly but MUST expose this state
     to the caller so the principal can make an informed decision.




  Baur                    Expires 21 November 2026               [Page 17]


  Internet-Draft                     PAP                          May 2026


  5.4.6.  5.4.5.  Scope Containment

     A child scope S_c is *contained by* a parent scope S_p (written S_c
     <= S_p) if and only if for every action A_c in S_c, there exists an
     action A_p in S_p such that:

     1.  A_c.action == A_p.action
     2.  If A_p.object is non-null, then A_c.object MUST equal A_p.object.
     3.  If A_p.object is null, then A_c.object MAY be any value
         (including null).
     4.  If A_p.object is non-null and A_c.object is null, the containment
         check MUST fail.  A child MUST NOT broaden an object constraint.

  5.5.  Delegation Rules

     When an agent delegates a mandate to a child agent, the following
     rules MUST be enforced:

     *R1.  Scope Containment:* The child mandate's scope MUST be contained
     by the parent mandate's scope (Section 5.4.5).  If scope containment
     fails, the delegation MUST be rejected.

     *R2.  TTL Bound:* The child mandate's ttl MUST NOT exceed the parent
     mandate's ttl.  If the child TTL exceeds the parent TTL, the
     delegation MUST be rejected.

     *R3.  Parent Hash Binding:* The child mandate's parent_mandate_hash
     MUST equal the hash (Section 5.3) of the parent mandate's canonical
     form.

     *R4.  Issuer Chain:* The child mandate's issuer_did MUST equal the
     parent mandate's agent_did.  The child mandate MUST be signed by the
     parent mandate's agent_did key.

     *R5.  Principal Propagation:* The child mandate's principal_did MUST
     equal the parent mandate's principal_did.

     *R6.  Root Mandate:* A root mandate MUST have parent_mandate_hash set
     to null.  A root mandate's issuer_did MUST equal its principal_did.

  5.6.  Mandate Chain Verification

     A mandate chain is an ordered array of mandates [M_0, M_1, ..., M_n]
     where M_0 is the root mandate.  Verification MUST proceed as follows:

     1.  M_0.parent_mandate_hash MUST be null.
     2.  M_0.signature MUST verify against the principal's public key.




  Baur                    Expires 21 November 2026               [Page 18]


  Internet-Draft                     PAP                          May 2026


     3.  For each i from 1 to n: a.  M_i.parent_mandate_hash MUST equal
         hash(M_{i-1}). b.  M_i.scope MUST satisfy scope containment
         against M_{i-1}.scope (Section 5.4.5). c.  M_i.ttl MUST NOT
         exceed M_{i-1}.ttl. d.  M_i.signature MUST verify against the
         public key of M_{i-1}.agent_did.

     If any check fails, the entire chain MUST be rejected.

  5.7.  Decay State Machine

     A mandate's decay state tracks its lifecycle as the TTL progresses.
     The decay state MUST be one of:

                 +===========+===============================+
                 | State     | Description                   |
                 +===========+===============================+
                 | Active    | Full scope, within TTL        |
                 +-----------+-------------------------------+
                 | Degraded  | Reduced scope, TTL within     |
                 |           | decay window, renewal pending |
                 +-----------+-------------------------------+
                 | ReadOnly  | No execution permitted,       |
                 |           | observation only, TTL expired |
                 +-----------+-------------------------------+
                 | Suspended | No activity, awaiting         |
                 |           | principal review              |
                 +-----------+-------------------------------+

                                    Table 8

  5.7.1.  5.7.1.  State Transitions

     The following transitions are valid:

     Active --> Degraded --> ReadOnly --> Suspended
       ^            |            |
       |            |            |
       +-- renewal -+-- renewal -+













  Baur                    Expires 21 November 2026               [Page 19]


  Internet-Draft                     PAP                          May 2026


      +===========+===========+=========================================+
      | From      | To        | Condition                               |
      +===========+===========+=========================================+
      | Active    | Degraded  | Remaining TTL <= implementation-defined |
      |           |           | decay window                            |
      +-----------+-----------+-----------------------------------------+
      | Degraded  | ReadOnly  | TTL expired without renewal             |
      +-----------+-----------+-----------------------------------------+
      | ReadOnly  | Suspended | Implementation-defined timeout without  |
      |           |           | principal action                        |
      +-----------+-----------+-----------------------------------------+
      | Degraded  | Active    | Mandate renewed by issuer               |
      +-----------+-----------+-----------------------------------------+
      | ReadOnly  | Active    | Mandate renewed by issuer               |
      +-----------+-----------+-----------------------------------------+
      | Suspended | (none)    | Suspended mandates MUST NOT be renewed. |
      |           |           | Principal MUST issue a new mandate.     |
      +-----------+-----------+-----------------------------------------+

                                    Table 9

     Any transition not listed above MUST be rejected.

  5.7.2.  5.7.2.  Decay Computation

     An implementation SHOULD compute the current decay state as:

     function compute_decay_state(mandate, decay_window_seconds):
       now = current_utc_time()
       if now > mandate.ttl:
         if mandate.decay_state == Suspended:
           return Suspended
         else:
           return ReadOnly
       else:
         remaining = mandate.ttl - now (in seconds)
         if remaining <= decay_window_seconds:
           return Degraded
         else:
           return Active

     The decay_window_seconds parameter is implementation-defined.
     Implementations SHOULD document their chosen value.

  6.  Session Lifecycle






  Baur                    Expires 21 November 2026               [Page 20]


  Internet-Draft                     PAP                          May 2026


  6.1.  Session State Machine

     A session tracks the state of a transaction between two agents.  The
     session state MUST be one of:

       +===========+===================================================+
       | State     | Description                                       |
       +===========+===================================================+
       | Initiated | Capability token presented, awaiting verification |
       +-----------+---------------------------------------------------+
       | Open      | Handshake complete, session DIDs exchanged        |
       +-----------+---------------------------------------------------+
       | Executed  | Transaction executed within session               |
       +-----------+---------------------------------------------------+
       | Closed    | Session closed, ephemeral keys discarded          |
       +-----------+---------------------------------------------------+

                                    Table 10

     Valid transitions:

     Initiated --> Open --> Executed --> Closed
         |                                 ^
         +----------> Closed (early) ------+
                          ^
         Open -------> Closed (early) -----+

       +===========+==========+========================================+
       | From      | To       | Trigger                                |
       +===========+==========+========================================+
       | Initiated | Open     | Session DID exchange completed         |
       +-----------+----------+----------------------------------------+
       | Initiated | Closed   | Early termination (rejection or error) |
       +-----------+----------+----------------------------------------+
       | Open      | Executed | Action executed                        |
       +-----------+----------+----------------------------------------+
       | Open      | Closed   | Early termination                      |
       +-----------+----------+----------------------------------------+
       | Executed  | Closed   | Session close message sent             |
       +-----------+----------+----------------------------------------+

                                    Table 11

     Any transition not listed above MUST be rejected.







  Baur                    Expires 21 November 2026               [Page 21]


  Internet-Draft                     PAP                          May 2026


  6.2.  Capability Token

     A capability token is a single-use authorization to open a session.
     It MUST contain the following fields:

     +============+==========+==========+================================+
     | Field      | Type     | Required | Description                    |
     +============+==========+==========+================================+
     | id         | String   | REQUIRED | Unique token identifier        |
     |            |          |          | (UUID v4)                      |
     +------------+----------+----------+--------------------------------+
     | target_did | String   | REQUIRED | DID of the agent this token    |
     |            |          |          | authorizes a session with      |
     +------------+----------+----------+--------------------------------+
     | action     | String   | REQUIRED | Schema.org action type this    |
     |            |          |          | token authorizes               |
     +------------+----------+----------+--------------------------------+
     | nonce      | String   | REQUIRED | Single-use nonce (UUID v4),    |
     |            |          |          | consumed on session            |
     |            |          |          | initiation                     |
     +------------+----------+----------+--------------------------------+
     | issuer_did | String   | REQUIRED | DID of the issuing agent       |
     |            |          |          | (typically the                 |
     |            |          |          | orchestrator)                  |
     +------------+----------+----------+--------------------------------+
     | issued_at  | DateTime | REQUIRED | Issuance timestamp (RFC        |
     |            |          |          | 3339)                          |
     +------------+----------+----------+--------------------------------+
     | expires_at | DateTime | REQUIRED | Expiry timestamp (RFC 3339)    |
     +------------+----------+----------+--------------------------------+
     | signature  | String   | OPTIONAL | Ed25519 signature              |
     |            | or null  |          | (base64url-no-pad)             |
     +------------+----------+----------+--------------------------------+

                                    Table 12

  6.2.1.  6.2.1.  Token Signing

     The token canonical form MUST be:












  Baur                    Expires 21 November 2026               [Page 22]


  Internet-Draft                     PAP                          May 2026


     {
       "id": "...",
       "target_did": "...",
       "action": "...",
       "nonce": "...",
       "issuer_did": "...",
       "issued_at": "...",
       "expires_at": "..."
     }

     Signing follows the same procedure as mandate signing (Section 5.2).

  6.2.2.  6.2.2.  Token Verification

     A receiving agent MUST verify a capability token as follows:

     1.  token.target_did MUST match the receiver's DID.
     2.  token.nonce MUST NOT appear in the receiver's consumed nonce set.
     3.  The current time MUST NOT exceed token.expires_at.
     4.  token.signature MUST verify against the public key of
         token.issuer_did.

     If all checks pass, the receiver MUST immediately add token.nonce to
     its consumed nonce set.  A nonce, once consumed, MUST never be
     accepted again.

  6.3.  Six-Phase Handshake

     The session handshake consists of six phases.  Each phase involves a
     message exchange between the initiating agent (I) and the receiving
     agent (R).




















  Baur                    Expires 21 November 2026               [Page 23]


  Internet-Draft                     PAP                          May 2026


  Phase  Direction  Message              Data
  -----  ---------  -------------------  --------------------------------
  1a     I -> R     TokenPresentation    CapabilityToken
  1b     R -> I     TokenAccepted        session_id, receiver_session_did
         R -> I     TokenRejected        reason (terminates handshake)

  2a     I -> R     SessionDidExchange   initiator_session_did
  2b     R -> I     SessionDidAck        (empty)

  3a     I -> R     DisclosureOffer      disclosures (may be empty array)
  3b     R -> I     DisclosureAccepted   (empty)

  4      R -> I     ExecutionResult      result (Schema.org JSON-LD)

  5a     I -> R     ReceiptForCoSign     half-signed TransactionReceipt
  5b     R -> I     ReceiptCoSigned      fully co-signed TransactionReceipt

  6a     I -> R     SessionClose         session_id
  6b     R -> I     SessionClosed        (empty)

  6.3.1.  6.3.1.  Phase 1: Token Presentation

     The initiating agent presents a signed capability token.  The
     receiving agent verifies the token (Section 6.2.2).

     On acceptance, the receiver MUST: 1.  Generate a fresh session
     keypair (Section 4.4). 2.  Create a session in the Initiated state.
     3.  Return a TokenAccepted message containing the session ID and the
     receiver's ephemeral session DID.

     On rejection, the receiver MUST return a TokenRejected message with a
     reason string.  The handshake terminates.

  6.3.2.  6.3.2.  Phase 2: Ephemeral DID Exchange

     The initiating agent generates its own fresh session keypair and
     sends a SessionDidExchange message containing its session DID.

     On receipt, the receiver MUST: 1.  Transition the session state from
     Initiated to Open. 2.  Store the initiator's session DID. 3.  Return
     a SessionDidAck message.

     After Phase 2, both parties have exchanged ephemeral session DIDs.
     All subsequent envelope signatures (Section 8.2) MUST use session
     keys.






  Baur                    Expires 21 November 2026               [Page 24]


  Internet-Draft                     PAP                          May 2026


  6.3.3.  6.3.3.  Phase 3: Disclosure

     The initiating agent sends a DisclosureOffer containing an array of
     SD-JWT disclosures (Section 7).  The array MAY be empty for zero-
     disclosure sessions.

     The receiver MUST: 1.  Verify each disclosure against the SD-JWT
     commitment (Section 7.3). 2.  Return a DisclosureAccepted message.

     If disclosure verification fails, the receiver SHOULD return an Error
     message and close the session.

  6.3.4.  6.3.4.  Phase 4: Execution

     The receiver executes the requested action and returns an
     ExecutionResult message containing a Schema.org JSON-LD result
     object.

     The session state MUST transition from Open to Executed.

  6.3.5.  6.3.5.  Phase 5: Receipt Co-Signing

     The initiating agent constructs a TransactionReceipt (Section 11),
     signs it with its session key, and sends it as ReceiptForCoSign.

     The receiving agent MUST: 1.  Verify the initiator's signature on the
     receipt. 2.  Add its own co-signature using its session key. 3.
     Return the fully co-signed receipt as ReceiptCoSigned.

  6.3.6.  6.3.6.  Phase 6: Session Close

     Either party MAY initiate session close by sending a SessionClose
     message containing the session ID.

     On receipt of SessionClose, the other party MUST: 1.  Return a
     SessionClosed message. 2.  Transition the session state to Closed. 3.
     Discard all ephemeral session keys.

     After Phase 6, both parties MUST discard their session keypairs.
     Session DIDs MUST NOT be reused.

  7.  SD-JWT Disclosure Protocol









  Baur                    Expires 21 November 2026               [Page 25]


  Internet-Draft                     PAP                          May 2026


  7.1.  Overview

     PAP uses Selective Disclosure JWT (SD-JWT) as defined in [SD-JWT-08]
     for context disclosure during the session handshake.  SD-JWT allows
     the principal to hold multiple claims but disclose only those
     permitted by the mandate.

  7.2.  SD-JWT Object

     An SD-JWT MUST contain:

        +===========+=========+===========+===========================+
        | Field     | Type    | Required  | Description               |
        +===========+=========+===========+===========================+
        | issuer    | String  | REQUIRED  | DID of the claim issuer   |
        |           |         |           | (typically the principal) |
        +-----------+---------+-----------+---------------------------+
        | claims    | Object  | REQUIRED  | All claims as key-value   |
        |           |         | (private) | pairs                     |
        +-----------+---------+-----------+---------------------------+
        | salts     | Object  | REQUIRED  | Per-claim random salts    |
        |           |         | (private) | (UUID v4)                 |
        +-----------+---------+-----------+---------------------------+
        | signature | String  | OPTIONAL  | Ed25519 signature over    |
        |           | or null |           | commitment bytes          |
        |           |         |           | (base64url-no-pad)        |
        +-----------+---------+-----------+---------------------------+

                                    Table 13

     The claims and salts fields are private to the holder and MUST NOT be
     transmitted in their entirety.  Only selected disclosures
     (Section 7.3) are transmitted.

  7.3.  Disclosure Object

     A disclosure reveals a single claim.  It MUST contain:














  Baur                    Expires 21 November 2026               [Page 26]


  Internet-Draft                     PAP                          May 2026


       +=======+==========+==========+================================+
       | Field | Type     | Required | Description                    |
       +=======+==========+==========+================================+
       | salt  | String   | REQUIRED | The claim-specific random salt |
       +-------+----------+----------+--------------------------------+
       | key   | String   | REQUIRED | The claim key                  |
       +-------+----------+----------+--------------------------------+
       | value | Any JSON | REQUIRED | The claim value                |
       |       | value    |          |                                |
       +-------+----------+----------+--------------------------------+

                                   Table 14

  7.4.  Commitment Computation

     The SD-JWT commitment is signed to bind all possible disclosures.

     1.  For each claim (key, value) with salt s:

         *  Construct: {"salt": s, "key": key, "value": value}
         *  Hash: SHA-256(JSON_bytes(disclosure))
         *  Encode: base64url-no-pad

     2.  Collect all hashes and sort lexicographically.

     3.  Construct commitment bytes:

        {
         "issuer": "<issuer_did>",
         "disclosure_hashes": ["<sorted_hash_1>", "<sorted_hash_2>", ...]
        }

     4.  Sign: Ed25519_sign(JSON_bytes(commitment))

  7.5.  Disclosure Verification

     A verifier MUST:

     1.  Verify the SD-JWT signature over the commitment bytes using the
         issuer's public key.
     2.  For each received disclosure: a.  Compute hash = base64url(SHA-
         256(JSON_bytes(disclosure))). b.  Verify that hash is present in
         the signed disclosure_hashes array.

     If any disclosure hash is not found in the commitment, the
     verification MUST fail.





  Baur                    Expires 21 November 2026               [Page 27]


  Internet-Draft                     PAP                          May 2026


  7.6.  Zero-Disclosure Sessions

     A session MAY proceed with zero disclosures.  In this case:

     *  The DisclosureOffer message carries an empty disclosures array.
     *  The SD-JWT signature MUST still verify (the commitment contains
        hashes for all claims, but none are revealed).
     *  The receiver MUST accept an empty disclosure set without error.

  8.  Protocol Messages and Envelope

  8.1.  Protocol Message Types

     All protocol messages are serialized as JSON objects with a type
     discriminator field.  The following message types are defined:




































  Baur                    Expires 21 November 2026               [Page 28]


  Internet-Draft                     PAP                          May 2026


      +====================+=======+===========+========================+
      | Type               | Phase | Direction | Fields                 |
      +====================+=======+===========+========================+
      | TokenPresentation  | 1     | I->R      | token: CapabilityToken |
      +--------------------+-------+-----------+------------------------+
      | TokenAccepted      | 1     | R->I      | session_id: String,    |
      |                    |       |           | receiver_session_did:  |
      |                    |       |           | String                 |
      +--------------------+-------+-----------+------------------------+
      | TokenRejected      | 1     | R->I      | reason: String         |
      +--------------------+-------+-----------+------------------------+
      | SessionDidExchange | 2     | I->R      | initiator_session_did: |
      |                    |       |           | String                 |
      +--------------------+-------+-----------+------------------------+
      | SessionDidAck      | 2     | R->I      | (no fields)            |
      +--------------------+-------+-----------+------------------------+
      | DisclosureOffer    | 3     | I->R      | disclosures: Array of  |
      |                    |       |           | JSON values            |
      +--------------------+-------+-----------+------------------------+
      | DisclosureAccepted | 3     | R->I      | (no fields)            |
      +--------------------+-------+-----------+------------------------+
      | ExecutionResult    | 4     | R->I      | result: JSON value     |
      |                    |       |           | (Schema.org JSON-LD)   |
      +--------------------+-------+-----------+------------------------+
      | ReceiptForCoSign   | 5     | I->R      | receipt:               |
      |                    |       |           | TransactionReceipt     |
      +--------------------+-------+-----------+------------------------+
      | ReceiptCoSigned    | 5     | R->I      | receipt:               |
      |                    |       |           | TransactionReceipt     |
      +--------------------+-------+-----------+------------------------+
      | SessionClose       | 6     | Either    | session_id: String     |
      +--------------------+-------+-----------+------------------------+
      | SessionClosed      | 6     | Either    | (no fields)            |
      +--------------------+-------+-----------+------------------------+
      | Error              | Any   | Either    | code: String, message: |
      |                    |       |           | String                 |
      +--------------------+-------+-----------+------------------------+

                                    Table 15

  8.2.  Envelope

     Protocol messages are transmitted inside an envelope that provides
     routing, sequencing, and integrity.







  Baur                    Expires 21 November 2026               [Page 29]


  Internet-Draft                     PAP                          May 2026


       +============+=================+==========+====================+
       | Field      | Type            | Required | Description        |
       +============+=================+==========+====================+
       | id         | String          | REQUIRED | Unique envelope    |
       |            |                 |          | identifier (UUID   |
       |            |                 |          | v4)                |
       +------------+-----------------+----------+--------------------+
       | session_id | String          | REQUIRED | Session this       |
       |            |                 |          | envelope belongs   |
       |            |                 |          | to                 |
       +------------+-----------------+----------+--------------------+
       | sender     | String          | REQUIRED | DID of the sender  |
       +------------+-----------------+----------+--------------------+
       | recipient  | String          | REQUIRED | DID of the         |
       |            |                 |          | intended recipient |
       +------------+-----------------+----------+--------------------+
       | sequence   | Integer         | REQUIRED | Monotonically      |
       |            |                 |          | increasing         |
       |            |                 |          | sequence number    |
       |            |                 |          | within the session |
       +------------+-----------------+----------+--------------------+
       | payload    | ProtocolMessage | REQUIRED | The protocol       |
       |            |                 |          | message            |
       +------------+-----------------+----------+--------------------+
       | timestamp  | DateTime        | REQUIRED | ISO 8601 timestamp |
       +------------+-----------------+----------+--------------------+
       | signature  | Bytes or null   | OPTIONAL | Ed25519 signature  |
       |            |                 |          | over signable      |
       |            |                 |          | bytes              |
       +------------+-----------------+----------+--------------------+

                                   Table 16

  8.2.1.  8.2.1.  Envelope Signing

     The signable bytes for an envelope MUST be computed as:

  SHA-256(session_id_bytes || sequence_big_endian_8_bytes || payload_json_bytes)

     Where || denotes concatenation and sequence_big_endian_8_bytes is the
     sequence number as an 8-byte big-endian integer.

     Before Phase 2 (DID exchange), the signature field MAY be null
     because the capability token carries its own signature from the
     issuer.

     After Phase 2, all envelopes MUST be signed by the sender's ephemeral
     session key.



  Baur                    Expires 21 November 2026               [Page 30]


  Internet-Draft                     PAP                          May 2026


  8.2.2.  8.2.2.  Envelope Verification

     The recipient MUST:

     1.  Verify recipient matches its own DID.
     2.  Verify sequence is strictly greater than the last received
         sequence number for this session.
     3.  If signature is present, verify it against the sender's session
         public key.

  9.  Marketplace Advertisement Schema

  9.1.  Agent Advertisement

     An agent advertisement declares an agent's capabilities, disclosure
     requirements, and return types.  Advertisements use Schema.org
     vocabulary and JSON-LD structure.


































  Baur                    Expires 21 November 2026               [Page 31]


  Internet-Draft                     PAP                          May 2026


     +=====================+==========+==========+======================+
     | Field               | Type     | Required | Description          |
     +=====================+==========+==========+======================+
     | @context            | String   | REQUIRED | MUST be              |
     |                     |          |          | "https://schema.org" |
     +---------------------+----------+----------+----------------------+
     | @type               | String   | REQUIRED | MUST be              |
     |                     |          |          | "schema:Service"     |
     +---------------------+----------+----------+----------------------+
     | name                | String   | REQUIRED | Human-readable agent |
     |                     |          |          | name                 |
     +---------------------+----------+----------+----------------------+
     | provider            | Provider | REQUIRED | Provider             |
     |                     |          |          | organization         |
     |                     |          |          | (Section 9.2)        |
     +---------------------+----------+----------+----------------------+
     | capability          | Array of | REQUIRED | Schema.org action    |
     |                     | String   |          | types the agent can  |
     |                     |          |          | perform              |
     +---------------------+----------+----------+----------------------+
     | object_types        | Array of | REQUIRED | Schema.org object    |
     |                     | String   |          | types the agent      |
     |                     |          |          | operates on          |
     +---------------------+----------+----------+----------------------+
     | requires_disclosure | Array of | REQUIRED | Fully qualified      |
     |                     | String   |          | property references  |
     |                     |          |          | the agent requires   |
     |                     |          |          | (e.g.,               |
     |                     |          |          | schema:Person.name)  |
     +---------------------+----------+----------+----------------------+
     | returns             | Array of | REQUIRED | Schema.org types the |
     |                     | String   |          | agent returns        |
     +---------------------+----------+----------+----------------------+
     | ttl_min             | Integer  | OPTIONAL | Minimum session TTL  |
     |                     |          |          | in seconds.          |
     |                     |          |          | Default: 300.        |
     +---------------------+----------+----------+----------------------+
     | signed_by           | String   | REQUIRED | DID that signed this |
     |                     |          |          | advertisement        |
     +---------------------+----------+----------+----------------------+
     | signature           | String   | OPTIONAL | Ed25519 signature    |
     |                     | or null  |          | (base64url-no-pad)   |
     +---------------------+----------+----------+----------------------+

                                   Table 17






  Baur                    Expires 21 November 2026               [Page 32]


  Internet-Draft                     PAP                          May 2026


  9.2.  Provider Object

         +=======+========+==========+===============================+
         | Field | Type   | Required | Description                   |
         +=======+========+==========+===============================+
         | @type | String | REQUIRED | MUST be "schema:Organization" |
         +-------+--------+----------+-------------------------------+
         | name  | String | REQUIRED | Organization name             |
         +-------+--------+----------+-------------------------------+
         | did   | String | REQUIRED | Operator DID                  |
         +-------+--------+----------+-------------------------------+

                                    Table 18

  9.3.  Disclosure Filtering

     A marketplace registry MUST support two query modes:

     *Query by action:* Return all advertisements whose capability array
     contains the requested action type.

     *Query by action with disclosure satisfiability:* Return only
     advertisements where: 1.  The capability array contains the requested
     action type, AND 2.  Every entry in requires_disclosure is present in
     the caller's available properties list.

     This filtering MUST occur before any mandate is issued or session is
     established.  Agents whose disclosure requirements exceed the
     principal's authorization MUST be excluded.  The principal MUST NOT
     be asked to over-disclose.

  9.4.  Advertisement Signing

     The canonical form for advertisement signing MUST include all fields
     except signature:

     {
       "@context": "https://schema.org",
       "@type": "schema:Service",
       "name": "...",
       "provider": { ... },
       "capability": [...],
       "object_types": [...],
       "requires_disclosure": [...],
       "returns": [...],
       "ttl_min": 300,
       "signed_by": "did:key:z..."
     }



  Baur                    Expires 21 November 2026               [Page 33]


  Internet-Draft                     PAP                          May 2026


     Signing follows the same Ed25519/base64url-no-pad procedure as
     mandate signing (Section 5.2).

     A marketplace registry MUST reject unsigned advertisements.

  9.5.  Advertisement Hashing

     The content hash of an advertisement MUST be computed as:

     base64url(SHA-256(canonical_bytes))

     This hash is used for deduplication in federated registries
     (Section 10).

  9.6.  Operator Metrics

     An agent advertisement MAY include an operator_metrics field
     containing self-reported operational statistics.  Metrics are
     informational metadata for principal evaluation and MUST NOT be used
     by marketplace registries for ranking, sorting, or filtering query
     results.






























  Baur                    Expires 21 November 2026               [Page 34]


  Internet-Draft                     PAP                          May 2026


     +========================+==========+==========+===================+
     | Field                  | Type     | Required | Description       |
     +========================+==========+==========+===================+
     | total_receipts         | Integer  | OPTIONAL | Total co-signed   |
     |                        |          |          | transaction       |
     |                        |          |          | receipts          |
     +------------------------+----------+----------+-------------------+
     | bilateral_attestations | Integer  | OPTIONAL | Receipts with     |
     |                        |          |          | bilateral session |
     |                        |          |          | attestation       |
     +------------------------+----------+----------+-------------------+
     | unique_counterparties  | Integer  | OPTIONAL | Distinct          |
     |                        |          |          | counterparty      |
     |                        |          |          | session DIDs      |
     +------------------------+----------+----------+-------------------+
     | action_types           | Array of | OPTIONAL | Distinct          |
     |                        | String   |          | Schema.org action |
     |                        |          |          | types performed   |
     +------------------------+----------+----------+-------------------+
     | tee_sessions_pct       | Number   | OPTIONAL | Fraction of       |
     |                        |          |          | sessions with TEE |
     |                        |          |          | attestation (0.0  |
     |                        |          |          | to 1.0)           |
     +------------------------+----------+----------+-------------------+
     | first_seen             | DateTime | OPTIONAL | RFC 3339          |
     |                        |          |          | timestamp of      |
     |                        |          |          | first             |
     |                        |          |          | registration      |
     +------------------------+----------+----------+-------------------+
     | uptime_days            | Integer  | OPTIONAL | Days the operator |
     |                        |          |          | has been active   |
     +------------------------+----------+----------+-------------------+

                                   Table 19

     The operator_metrics field MUST be excluded from the advertisement
     content hash (Section 9.5) and signature computation (Section 9.4).
     Metrics change over time while the advertisement identity remains
     stable.

     *Anti-ranking requirement:* Marketplace registries MUST return query
     results in insertion order.  Registries MUST NOT rank, sort, or
     filter results based on operator metrics.  The principal's
     orchestrator is responsible for evaluating metrics and making
     selection decisions.  This requirement prevents marketplace
     registries from accumulating ranking power, which would constitute
     platform capture.




  Baur                    Expires 21 November 2026               [Page 35]


  Internet-Draft                     PAP                          May 2026


  10.  Federation Protocol

  10.1.  Overview

     Federation enables independent marketplace registries to discover and
     share agent advertisements.  Federation is peer-to-peer with no
     central coordinator.

  10.2.  Registry Peer

     A federation peer is identified by:

          +===========+==========+==========+======================+
          | Field     | Type     | Required | Description          |
          +===========+==========+==========+======================+
          | did       | String   | REQUIRED | DID of the peer      |
          |           |          |          | registry operator    |
          +-----------+----------+----------+----------------------+
          | endpoint  | String   | REQUIRED | HTTP(S) endpoint for |
          |           |          |          | federation API calls |
          +-----------+----------+----------+----------------------+
          | last_sync | DateTime | OPTIONAL | Timestamp of last    |
          |           | or null  |          | successful sync      |
          +-----------+----------+----------+----------------------+

                                   Table 20

  10.3.  Federation Messages

     Federation uses the following message types, discriminated by a type
     field:




















  Baur                    Expires 21 November 2026               [Page 36]


  Internet-Draft                     PAP                          May 2026


     +==================+=========+====================+================+
     | Type             |Direction| Fields             | Description    |
     +==================+=========+====================+================+
     | QueryByAction    |Request  | action: String     | Query for      |
     |                  |         |                    | agents         |
     |                  |         |                    | supporting an  |
     |                  |         |                    | action         |
     +------------------+---------+--------------------+----------------+
     | QueryResponse    |Response | advertisements:    | Matching       |
     |                  |         | Array of           | advertisements |
     |                  |         | AgentAdvertisement |                |
     +------------------+---------+--------------------+----------------+
     | Announce         |Request  | advertisement:     | Announce a new |
     |                  |         | AgentAdvertisement | local          |
     |                  |         |                    | advertisement  |
     +------------------+---------+--------------------+----------------+
     | AnnounceAck      |Response | hash: String,      | Acknowledge    |
     |                  |         | accepted: Boolean  | announcement   |
     +------------------+---------+--------------------+----------------+
     | PeerList         |Request  | (none)             | Request known  |
     |                  |         |                    | peer list      |
     +------------------+---------+--------------------+----------------+
     | PeerListResponse |Response | peers: Array of    | Known peers    |
     |                  |         | RegistryPeer       |                |
     +------------------+---------+--------------------+----------------+

                                   Table 21

  10.4.  Federation Endpoints

     A federation server MUST expose the following HTTP endpoints:

     +========+=======================+==============+==================+
     | Method | Path                  | Request Body | Response Body    |
     +========+=======================+==============+==================+
     | GET    | /federation/          | (none)       | QueryResponse    |
     |        | query?action={action} |              |                  |
     +--------+-----------------------+--------------+------------------+
     | POST   | /federation/announce  | Announce     | AnnounceAck      |
     +--------+-----------------------+--------------+------------------+
     | GET    | /federation/peers     | (none)       | PeerListResponse |
     +--------+-----------------------+--------------+------------------+

                                   Table 22







  Baur                    Expires 21 November 2026               [Page 37]


  Internet-Draft                     PAP                          May 2026


  10.5.  Content-Hash Deduplication

     When merging remote advertisements, a federated registry MUST:

     1.  Compute the content hash of each advertisement (Section 9.5).
     2.  If the hash already exists in the local seen-hashes set, skip the
         advertisement.
     3.  If the advertisement has no signature, skip it.
     4.  Otherwise, register the advertisement and add its hash to the
         seen-hashes set.

     This ensures idempotent synchronization and prevents duplicate
     entries.

  10.6.  Peer Discovery

     A registry MAY discover new peers transitively:

     1.  Query a known peer's /federation/peers endpoint.
     2.  For each peer in the response not already known, add it to the
         local peer list.

     Implementations SHOULD implement rate limiting and SHOULD validate
     that newly discovered peers are reachable before adding them.

  10.7.  Peer Trust Signals

     A federation peer MAY present trust signals to establish credibility
     with other registries.  Trust signals are additive — more signals
     increase confidence but no single signal is sufficient alone.

  10.7.1.  10.7.1.  Signal Categories

          +=================+===============+======================+
          | Signal          | Weight        | Description          |
          +=================+===============+======================+
          | Social vouching | Primary       | Signed vouches from  |
          |                 |               | existing peers       |
          +-----------------+---------------+----------------------+
          | TEE attestation | Supplementary | Hardware attestation |
          |                 |               | of registry software |
          +-----------------+---------------+----------------------+
          | Operational     | Supplementary | Observable uptime    |
          | history         |               | and sync metrics     |
          +-----------------+---------------+----------------------+
          | Domain          | Supplementary | DNS or TLS proof of  |
          | verification    |               | domain ownership     |
          +-----------------+---------------+----------------------+



  Baur                    Expires 21 November 2026               [Page 38]


  Internet-Draft                     PAP                          May 2026


                                   Table 23

     A registry SHOULD require at least two signal categories before
     granting a peer full synchronization privileges.

  10.7.2.  10.7.2.  Peer Vouch

     A peer vouch is a signed statement by an existing peer that they have
     evaluated the new peer and believe it operates a conformant registry.

      +===============+==========+==========+==========================+
      | Field         | Type     | Required | Description              |
      +===============+==========+==========+==========================+
      | voucher_did   | String   | REQUIRED | DID of the vouching peer |
      +---------------+----------+----------+--------------------------+
      | vouchee_did   | String   | REQUIRED | DID of the peer being    |
      |               |          |          | vouched                  |
      +---------------+----------+----------+--------------------------+
      | timestamp     | DateTime | REQUIRED | RFC 3339 timestamp       |
      +---------------+----------+----------+--------------------------+
      | justification | String   | REQUIRED | Structured reason for    |
      |               |          |          | vouching                 |
      +---------------+----------+----------+--------------------------+
      | signature     | String   | REQUIRED | Ed25519 signature by     |
      |               |          |          | voucher                  |
      +---------------+----------+----------+--------------------------+

                                   Table 24

  10.7.3.  10.7.3.  Vouch Budget

     To prevent vouch ring attacks (where colluding peers mutually vouch
     to create Sybil identities), implementations SHOULD enforce:

     *  *Vouch budget:* Each peer MAY issue at most 3 vouches per year.
     *  *Minimum age:* A peer MUST be registered for at least 90 days
        before it is eligible to vouch for others.
     *  *Probationary period:* Newly registered peers operate in
        probationary status for 60 days.  During probation, a peer MAY
        receive advertisements but MUST NOT vouch for other peers.
     *  *Diverse trust paths:* The vouchers for a new peer SHOULD NOT all
        trace their own vouching chains through the same set of peers.

  11.  Receipt Format







  Baur                    Expires 21 November 2026               [Page 39]


  Internet-Draft                     PAP                          May 2026


  11.1.  Transaction Receipt

     A transaction receipt is a co-signed record of a completed session.
     Receipts contain property type references only -- never values.

     +========================+========+==========+=====================+
     | Field                  |Type    | Required | Description         |
     +========================+========+==========+=====================+
     | session_id             |String  | REQUIRED | Ephemeral session   |
     |                        |        |          | ID (not linked to   |
     |                        |        |          | principal)          |
     +------------------------+--------+----------+---------------------+
     | action                 |String  | REQUIRED | Schema.org action   |
     |                        |        |          | type executed       |
     +------------------------+--------+----------+---------------------+
     | initiating_agent_did   |String  | REQUIRED | Ephemeral session   |
     |                        |        |          | DID of the          |
     |                        |        |          | initiator           |
     +------------------------+--------+----------+---------------------+
     | receiving_agent_did    |String  | REQUIRED | Ephemeral session   |
     |                        |        |          | DID of the receiver |
     +------------------------+--------+----------+---------------------+
     | disclosed_by_initiator |Array of| REQUIRED | Property references |
     |                        |String  |          | disclosed by the    |
     |                        |        |          | initiator           |
     +------------------------+--------+----------+---------------------+
     | disclosed_by_receiver  |Array of| REQUIRED | Property references |
     |                        |String  |          | or operator         |
     |                        |        |          | statements from the |
     |                        |        |          | receiver            |
     +------------------------+--------+----------+---------------------+
     | executed               |String  | REQUIRED | Human-readable      |
     |                        |        |          | description of the  |
     |                        |        |          | action executed     |
     +------------------------+--------+----------+---------------------+
     | returned               |String  | REQUIRED | Human-readable      |
     |                        |        |          | description of the  |
     |                        |        |          | result returned     |
     +------------------------+--------+----------+---------------------+
     | timestamp              |DateTime| REQUIRED | RFC 3339 timestamp  |
     +------------------------+--------+----------+---------------------+
     | signatures             |Array of| REQUIRED | Co-signatures       |
     |                        |String  |          | (base64url-no-pad)  |
     +------------------------+--------+----------+---------------------+

                                   Table 25





  Baur                    Expires 21 November 2026               [Page 40]


  Internet-Draft                     PAP                          May 2026


  11.2.  Receipt Signing

     The canonical form for receipt signing MUST include all fields except
     signatures:

     {
       "session_id": "...",
       "action": "...",
       "initiating_agent_did": "...",
       "receiving_agent_did": "...",
       "disclosed_by_initiator": [...],
       "disclosed_by_receiver": [...],
       "executed": "...",
       "returned": "...",
       "timestamp": "..."
     }

  11.3.  Co-Signing Protocol

     1.  The initiator constructs a receipt from the completed session.
     2.  The initiator computes Ed25519_sign(canonical_bytes) using its
         session key and appends the base64url-no-pad encoded signature to
         signatures.
     3.  The initiator sends the half-signed receipt to the receiver.
     4.  The receiver verifies the initiator's signature against the
         initiator's session public key.
     5.  The receiver computes Ed25519_sign(canonical_bytes) using its
         session key and appends its signature to signatures.
     6.  The receiver returns the fully co-signed receipt.

  11.4.  Receipt Verification

     To verify a co-signed receipt:

     1.  The signatures array MUST contain exactly 2 entries.
     2.  signatures[0] MUST verify against the initiator's session public
         key.
     3.  signatures[1] MUST verify against the receiver's session public
         key.

  11.5.  Privacy Properties

     Receipts MUST NOT contain: - Personal data values (names, emails,
     etc.) - SD-JWT claim values - Raw execution inputs or outputs







  Baur                    Expires 21 November 2026               [Page 41]


  Internet-Draft                     PAP                          May 2026


     Receipts MUST contain only: - Schema.org property type references
     (e.g., schema:Person.schema:name) - Operator-defined category
     references (e.g., operator:search_executed) - Human-readable action/
     result descriptions

     This ensures receipts are auditable by both principals without
     revealing the data exchanged in the transaction.

  11.6.  Session Attestation

     A session attestation is a signed statement by a session participant
     recording their assessment of the session outcome.

      +==============+==========+==========+===========================+
      | Field        | Type     | Required | Description               |
      +==============+==========+==========+===========================+
      | session_id   | String   | REQUIRED | Session identifier        |
      +--------------+----------+----------+---------------------------+
      | attester_did | String   | REQUIRED | Ephemeral session DID of  |
      |              |          |          | attester                  |
      +--------------+----------+----------+---------------------------+
      | outcome      | String   | REQUIRED | One of: fulfilled,        |
      |              |          |          | partial, failed, disputed |
      +--------------+----------+----------+---------------------------+
      | action_type  | String   | REQUIRED | Schema.org action type    |
      |              |          |          | executed                  |
      +--------------+----------+----------+---------------------------+
      | timestamp    | DateTime | REQUIRED | RFC 3339 timestamp        |
      +--------------+----------+----------+---------------------------+
      | signature    | String   | REQUIRED | Ed25519 signature by      |
      |              |          |          | attester                  |
      +--------------+----------+----------+---------------------------+

                                   Table 26

     A receipt with attestations from both the initiating and receiving
     agents is *bilaterally attested*. Bilaterally attested receipts carry
     higher evidentiary weight for operator metric computation.

     Attestations are per-action-type.  An operator's reputation in one
     action domain (e.g., schema:SearchAction) MUST NOT be conflated with
     reputation in another domain (e.g., schema:ReserveAction).

  12.  Verifiable Credential Envelope







  Baur                    Expires 21 November 2026               [Page 42]


  Internet-Draft                     PAP                          May 2026


  12.1.  Overview

     PAP mandates MAY be wrapped in a W3C Verifiable Credential (VC)
     envelope for interoperability with existing credential ecosystems.
     The VC envelope is OPTIONAL; implementations MUST support bare
     mandates and MAY additionally support VC-wrapped mandates.

  12.2.  VC Structure

     A PAP Verifiable Credential MUST conform to [VC-DATA-MODEL-2.0]:

     {
       "@context": [
         "https://www.w3.org/ns/credentials/v2",
         "https://www.w3.org/ns/credentials/examples/v2"
       ],
       "id": "urn:uuid:<uuid-v4>",
       "type": ["VerifiableCredential", "PAPMandateCredential"],
       "issuer": "<issuer_did>",
       "issuanceDate": "<rfc3339>",
       "expirationDate": "<rfc3339>",
       "credentialSubject": { <mandate_payload> },
       "proof": {
         "type": "Ed25519Signature2020",
         "created": "<rfc3339>",
         "verificationMethod": "<did>#key-1",
         "proofPurpose": "assertionMethod",
         "proofValue": "<base64url-no-pad>"
       }
     }

     The type array MUST include both "VerifiableCredential" and
     "PAPMandateCredential" for discoverability.

  12.3.  Credential Signing

     The canonical form for VC signing MUST include all fields except
     proof:

     {
       "@context": [...],
       "id": "...",
       "type": [...],
       "issuer": "...",
       "issuanceDate": "...",
       "expirationDate": "..." or null,
       "credentialSubject": { ... }
     }



  Baur                    Expires 21 November 2026               [Page 43]


  Internet-Draft                     PAP                          May 2026


     The proofValue is base64url(Ed25519_sign(JSON_bytes(canonical))).

  13.  Extension Points

     The following extensions are defined for PAP v1.0.  Core extensions
     (Sections 13.1--13.4) were introduced in v0.4.  Recovery mandates
     (Section 13.5), TEE attestation (Section 13.6), and payment proof
     validation (Section 13.7) were added in v0.7.  All extensions are
     OPTIONAL; a conformant implementation MAY support none, some, or all
     of them.

  13.1.  Payment Proof

     A mandate MAY carry a payment_proof field containing a zero-knowledge
     payment commitment.  PAP does not define the payment protocol; it
     defines the integration point.  Only cryptographic commitments are
     stored — *never* amounts, destinations, mints, or other identifying
     payment data.

     The PaymentProof type is a tagged enum with two variants:

             +===========+================+======================+
             | Variant   | Inner Type     | Description          |
             +===========+================+======================+
             | Lightning | Bolt11Hash     | SHA-256 of a BOLT-11 |
             |           |                | invoice payment hash |
             +-----------+----------------+----------------------+
             | Ecash     | CashuTokenHash | SHA-256 of a Cashu   |
             |           |                | blind-signed token   |
             +-----------+----------------+----------------------+

                                    Table 27

  13.1.1.  13.1.1.  Bolt11Hash

     A commitment to a Lightning Network payment.  The hash field contains
     the base64url-no-pad encoded SHA-256 of the BOLT-11 invoice payment
     hash.  The preimage is never stored.

     {
       "type": "Lightning",
       "hash": "<base64url-no-pad SHA-256>"
     }








  Baur                    Expires 21 November 2026               [Page 44]


  Internet-Draft                     PAP                          May 2026


  13.1.2.  13.1.2.  CashuTokenHash

     A commitment to a Cashu ecash token.  The hash field contains the
     base64url-no-pad encoded SHA-256 of the blind-signed token.  The
     token itself is never stored.

     {
       "type": "Ecash",
       "hash": "<base64url-no-pad SHA-256>"
     }

  13.1.3.  13.1.3.  Payment Proof Properties

     *  The proof contains *only* a cryptographic commitment hash.
     *  No amounts, destinations, mints, or routing data are stored.
     *  The vendor MUST NOT be able to identify the payer from the proof.
     *  The proof MUST be unlinkable to the principal's identity.
     *  The payment proof is included in the mandate's canonical form for
        signing.
     *  If a mandate's scope includes schema:PayAction, a payment proof
        SHOULD be attached.  Implementations MAY reject mandates that
        permit payment actions without a proof.

  13.1.4.  13.1.4.  Ecash Blind Signature Protocol

     PAP includes a reference implementation of the Chaumian blind
     signature scheme in the pap-ecash crate.  The scheme uses RFC 9474
     RSABSSA-SHA384-PSS (non-augmented variant, randomize = false).

     *Protocol parameters:*

      +=============+===================================================+
      | Parameter   | Value                                             |
      +=============+===================================================+
      | Scheme      | RSABSSA-SHA384-PSS (RFC 9474 §4.2, non-augmented) |
      +-------------+---------------------------------------------------+
      | Key size    | ≥ 2048 bits (production); 1024 bits (tests only)  |
      +-------------+---------------------------------------------------+
      | Commitment  | SHA-256(serial ∥ signature), base64url-no-pad     |
      +-------------+---------------------------------------------------+
      | Serial size | 32 bytes, randomly chosen by the client           |
      +-------------+---------------------------------------------------+

                                    Table 28

     *Protocol steps:*





  Baur                    Expires 21 November 2026               [Page 45]


  Internet-Draft                     PAP                          May 2026


     1.  *Request* — client calls ecash_request(serial, mint_pk).  Returns
         a BlindToken containing a randomly-blinded serial.  Only the
         blinded_message() bytes are transmitted to the mint.
     2.  *Mint* — mint calls ecash_mint_sign(blinded_msg, keypair).
         Returns raw blind-signature bytes to the client.
     3.  *Unblind* — client calls ecash_unblind(blind_token, blind_sig,
         mint_pk).  Returns the spendable EcashToken { serial, signature
         }.
     4.  *Attach* — client calls token.to_payment_proof() and includes the
         result in the mandate's payment_proof field.
     5.  *Verify* — payee calls ecash_verify(token, mint_pk).  Valid
         tokens have a correct RSA-PSS signature over serial.
     6.  *Redeem* — payee calls ecash_redeem(token, mint_pk, registry).
         Atomically verifies and records serial in the spent registry,
         preventing double-spend.

     *Unlinkability invariant:* The random blinding factor applied in step
     1 means that the blinded_message bytes transmitted to the mint are
     statistically independent of the final (serial, signature) pair.  The
     mint cannot link a signing operation to a subsequent redemption.

     *Double-spend invariant:* ecash_redeem MUST return
     EcashError::DoubleSpend on any second call with the same serial,
     regardless of signature validity.

     *Test vectors:* The conformance test suite is in crates/pap-ecash/.
     Run the following to generate and verify all test vectors:

     cargo test -p pap-ecash -- --nocapture

     The ecash_test_vector test uses a freshly-generated 1024-bit test key
     (test-only size) and serial 0x000…001 (32 bytes).  Because blind-rsa-
     signatures v0.14 uses OsRng internally (no injectable RNG), the
     blinding factor and PSS salt are non-deterministic.  The test
     therefore validates structural invariants (correct verification,
     43-char base64url commitment) rather than pinning an exact byte
     value.

     *C FFI:* pap_ecash_mint_keypair_generate, pap_ecash_blind,
     pap_ecash_blind_message_bytes, pap_ecash_mint_sign,
     pap_ecash_unblind, pap_ecash_verify, pap_ecash_spent_registry_new,
     pap_ecash_redeem, pap_ecash_token_payment_proof_commitment.

     *WASM:* EcashMintKeypair, EcashBlindToken, EcashToken, ecashMintSign,
     ecashVerify.






  Baur                    Expires 21 November 2026               [Page 46]


  Internet-Draft                     PAP                          May 2026


  13.2.  Payment Proof Verification

     A receiving agent that requires payment MUST: 1.  Extract the
     payment_proof from the mandate. 2.  Validate the proof's structural
     integrity (valid base64url, 32-byte SHA-256 commitment). 3.  Verify
     the proof against the payment network (out of band): - *Lightning*:
     verify the BOLT-11 payment hash preimage - *Ecash*: verify the Cashu
     token with the issuing mint 4.  Accept or reject the session based on
     verification.

  13.2.1.  13.2.1.  Receipt Payment Proof Commitment

     When a transaction receipt is created for a schema:PayAction, the
     receipt MUST include a payment_proof_commitment field containing the
     commitment hash from the mandate's payment proof.  This enables
     auditing without revealing payment details.

     A receipt validator MUST check: 1.  The payment_proof_commitment is
     present for payment actions. 2.  The commitment matches the mandate's
     payment proof commitment. 3.  The commitment is included in the
     receipt's canonical form for co-signing.

     The verification protocol between the receiving agent and the payment
     network is out of scope for this specification.

  13.3.  Continuity Tokens

     A continuity token enables stateful relationships across sessions
     without requiring the vendor to retain state.






















  Baur                    Expires 21 November 2026               [Page 47]


  Internet-Draft                     PAP                          May 2026


     +===================+==========+==========+=========================+
     | Field             | Type     | Required | Description             |
     +===================+==========+==========+=========================+
     | schema_type       | String   | REQUIRED | Schema.org type         |
     |                   |          |          | describing the          |
     |                   |          |          | encrypted               |
     |                   |          |          | payload shape           |
     +-------------------+----------+----------+-------------------------+
     | vendor_did        | String   | REQUIRED | DID of the              |
     |                   |          |          | vendor that             |
     |                   |          |          | issued this             |
     |                   |          |          | token                   |
     +-------------------+----------+----------+-------------------------+
     | encrypted_payload | String   | REQUIRED | Vendor-encrypted        |
     |                   |          |          | state (opaque to        |
     |                   |          |          | orchestrator)           |
     +-------------------+----------+----------+-------------------------+
     | ttl               | DateTime | REQUIRED | Expiry                  |
     |                   |          |          | timestamp, set          |
     |                   |          |          | by the principal        |
     +-------------------+----------+----------+-------------------------+
     | issued_at         | DateTime | REQUIRED | Issuance                |
     |                   |          |          | timestamp               |
     +-------------------+----------+----------+-------------------------+

                                    Table 29

  13.3.1.  13.3.1.  Continuity Token Lifecycle

     1.  At session close, the vendor encrypts its internal state and
         returns it as a continuity token to the orchestrator.
     2.  The orchestrator stores the token locally.  The vendor retains
         nothing.
     3.  When the principal returns, the orchestrator presents the token
         to the vendor.
     4.  The vendor decrypts the payload and resumes the relationship.
     5.  The principal controls the TTL.  The vendor MUST NOT set or
         extend the TTL.
     6.  To sever the relationship, the principal deletes the token.  No
         revocation notice is required.

  13.3.2.  13.3.2.  Continuity Token Properties

     *  The schema_type MUST be inspectable by the orchestrator without
        decrypting the payload.
     *  The vendor MUST NOT be able to write to the continuity token
        without the principal presenting it.




  Baur                    Expires 21 November 2026               [Page 48]


  Internet-Draft                     PAP                          May 2026


     *  The encrypted payload format is vendor-defined and opaque to the
        protocol.

  13.4.  Auto-Approval Policies

     An auto-approval policy allows the principal to pre-authorize certain
     categories of actions without per-transaction approval.

     +============================+========+========+===================+
     | Field                      |Type    |Required|Description        |
     +============================+========+========+===================+
     | name                       |String  |REQUIRED|Human-readable     |
     |                            |        |        |policy name        |
     +----------------------------+--------+--------+-------------------+
     | scope                      |Scope   |REQUIRED|Subset of the      |
     |                            |        |        |mandate scope this |
     |                            |        |        |policy applies to  |
     +----------------------------+--------+--------+-------------------+
     | max_value                  |Number  |OPTIONAL|Maximum transaction|
     |                            |or null |        |value for auto-    |
     |                            |        |        |approval (currency-|
     |                            |        |        |agnostic)          |
     +----------------------------+--------+--------+-------------------+
     | zero_additional_disclosure |Boolean |REQUIRED|If true, auto-     |
     |                            |        |        |approve only when  |
     |                            |        |        |zero additional    |
     |                            |        |        |disclosure is      |
     |                            |        |        |required beyond the|
     |                            |        |        |mandate            |
     +----------------------------+--------+--------+-------------------+
     | authored_at                |DateTime|REQUIRED|Timestamp when the |
     |                            |        |        |principal authored |
     |                            |        |        |this policy        |
     +----------------------------+--------+--------+-------------------+

                                   Table 30

  13.4.1.  13.4.1.  Auto-Approval Constraints

     *  The policy scope MUST be contained by the mandate scope
        (Section 5.4.5).  A policy MUST NOT be more permissive than the
        mandate.
     *  Policies are principal-authored and orchestrator-enforced.  An
        agent MUST NOT trigger a policy change by requesting it.
     *  zero_additional_disclosure defaults to true.  When true, the
        orchestrator MUST auto-approve only when the agent's disclosure
        requirements are fully covered by the existing mandate.




  Baur                    Expires 21 November 2026               [Page 49]


  Internet-Draft                     PAP                          May 2026


     *  If max_value is set and the transaction value exceeds it, the
        orchestrator MUST request explicit principal approval.

  13.5.  M-of-N Social Recovery

     Principal identity recovery via a designated notary quorum.  No
     central recovery authority.  The principal designates N notary DIDs
     at setup time; any M co-signers from that set can authorize key
     rotation.

  13.5.1.  13.5.1.  Recovery Mandate

     A principal creates a RecoveryMandate while they still control their
     key, designating the notary set and threshold.

      +===============+===============+==========+======================+
      | Field         | Type          | Required | Description          |
      +===============+===============+==========+======================+
      | principal_did | String        | REQUIRED | DID of the principal |
      |               |               |          | creating the mandate |
      +---------------+---------------+----------+----------------------+
      | threshold     | Integer       | REQUIRED | M: minimum co-       |
      |               |               |          | signatures required  |
      |               |               |          | (1 ≤ M ≤ N)          |
      +---------------+---------------+----------+----------------------+
      | notary_dids   | Array<String> | REQUIRED | N designated notary  |
      |               |               |          | DIDs (no duplicates) |
      +---------------+---------------+----------+----------------------+
      | created_at    | DateTime      | REQUIRED | Mandate creation     |
      |               |               |          | timestamp            |
      +---------------+---------------+----------+----------------------+
      | signature     | String        | REQUIRED | Ed25519 signature by |
      |               |               |          | the principal        |
      +---------------+---------------+----------+----------------------+

                                    Table 31

     Constraints: - threshold MUST be ≥ 1 and ≤ notary_dids.length. -
     notary_dids MUST NOT contain duplicate entries. - The mandate MUST be
     signed by the principal's current key. - Only one recovery mandate
     per principal DID.  A new mandate replaces any previous one.

  13.5.2.  13.5.2.  Recovery Request

     When recovery is needed, a RecoveryRequest is created identifying the
     old principal, the new principal keypair, and the authorizing
     recovery mandate.




  Baur                    Expires 21 November 2026               [Page 50]


  Internet-Draft                     PAP                          May 2026


       +=======================+==========+==========+=================+
       | Field                 | Type     | Required | Description     |
       +=======================+==========+==========+=================+
       | old_principal_did     | String   | REQUIRED | DID of the      |
       |                       |          |          | principal being |
       |                       |          |          | recovered       |
       +-----------------------+----------+----------+-----------------+
       | new_principal_did     | String   | REQUIRED | DID of the new  |
       |                       |          |          | principal       |
       |                       |          |          | keypair         |
       +-----------------------+----------+----------+-----------------+
       | recovery_mandate_hash | String   | REQUIRED | SHA-256 hash of |
       |                       |          |          | the authorizing |
       |                       |          |          | RecoveryMandate |
       +-----------------------+----------+----------+-----------------+
       | requested_at          | DateTime | REQUIRED | Request         |
       |                       |          |          | timestamp       |
       +-----------------------+----------+----------+-----------------+

                                    Table 32

     The canonical bytes of the recovery request are the message that each
     notary signs independently.

  13.5.3.  13.5.3.  Partial Recovery Signature (Blind)

     Each notary signs the recovery request independently.  Notaries MUST
     NOT communicate with each other during recovery — they learn nothing
     about which other notaries have been contacted (threshold blind
     signature scheme).

     Before signing, a notary MUST verify: 1.  The recovery mandate was
     signed by the old principal. 2.  The notary's own DID is in the
     designated notary set. 3.  The request references the correct
     recovery mandate hash. 4.  The request's old_principal_did matches
     the mandate.















  Baur                    Expires 21 November 2026               [Page 51]


  Internet-Draft                     PAP                          May 2026


         +============+==========+==========+========================+
         | Field      | Type     | Required | Description            |
         +============+==========+==========+========================+
         | notary_did | String   | REQUIRED | DID of the signing     |
         |            |          |          | notary                 |
         +------------+----------+----------+------------------------+
         | signature  | String   | REQUIRED | Ed25519 signature over |
         |            |          |          | the RecoveryRequest    |
         |            |          |          | canonical bytes        |
         +------------+----------+----------+------------------------+
         | signed_at  | DateTime | REQUIRED | Timestamp of the       |
         |            |          |          | notary's signature     |
         +------------+----------+----------+------------------------+

                                    Table 33

  13.5.4.  13.5.4.  Recovery Proof Assembly

     A recovery coordinator collects M partial signatures and assembles a
     RecoveryProof.  Verification of the proof MUST check:

     1.  The recovery mandate was signed by the old principal.
     2.  At least M partial signatures are present.
     3.  All signers are in the designated notary set.
     4.  No duplicate signers.
     5.  All partial signatures are cryptographically valid.

  13.5.5.  13.5.5.  Revocation Proof and Broadcast

     After successful recovery, a RevocationProof is created and broadcast
     to federation peers.




















  Baur                    Expires 21 November 2026               [Page 52]


  Internet-Draft                     PAP                          May 2026


     +=====================+==========+==========+=======================+
     | Field               | Type     | Required | Description           |
     +=====================+==========+==========+=======================+
     | old_principal_did   | String   | REQUIRED | The revoked DID       |
     +---------------------+----------+----------+-----------------------+
     | new_principal_did   | String   | REQUIRED | The replacement       |
     |                     |          |          | DID                   |
     +---------------------+----------+----------+-----------------------+
     | recovery_proof_hash | String   | REQUIRED | SHA-256 hash of       |
     |                     |          |          | the RecoveryProof     |
     +---------------------+----------+----------+-----------------------+
     | revoked_at          | DateTime | REQUIRED | Revocation            |
     |                     |          |          | timestamp             |
     +---------------------+----------+----------+-----------------------+
     | signature           | String   | REQUIRED | Ed25519 signature     |
     |                     |          |          | by the new            |
     |                     |          |          | principal key         |
     +---------------------+----------+----------+-----------------------+

                                    Table 34

     The revocation proof MUST be signed by the new principal key (proving
     possession).  Federation peers that receive a valid revocation MUST:
     - Mark the old principal DID as revoked. - Reject any future
     operations using the old DID. - Remove the old recovery mandate from
     their NotarySet.

  13.5.6.  13.5.6.  NotarySet Registry

     Each federation node maintains a NotarySet — a registry of recovery
     mandates queryable by principal DID.  The NotarySet: - Stores signed
     recovery mandates. - Tracks revoked principal DIDs. - Rejects mandate
     registration for already-revoked DIDs. - Processes revocation
     broadcasts from federation peers.

  13.5.7.  13.5.7.  Security Properties

     *  *No central authority.* Recovery requires M independent notaries.
     *  *Blind co-signing.* Notaries do not learn which other notaries
        participate in a recovery event.
     *  *Old key revocation.* The old principal DID is cryptographically
        revoked and broadcast to all federation peers.
     *  *Notary set immutability.* The notary set is fixed at mandate
        creation time by the principal.  It cannot be modified without
        creating a new mandate signed by the principal.
     *  *Threshold enforcement.* Fewer than M signatures MUST be rejected.
        Duplicate signers MUST be rejected.




  Baur                    Expires 21 November 2026               [Page 53]


  Internet-Draft                     PAP                          May 2026


  13.6.  TEE Attestation

     A mandate or session MAY carry a Trusted Execution Environment (TEE)
     attestation to provide evidence that an agent is executing within an
     isolated enclave.  TEE attestation is OPTIONAL and does NOT elevate a
     TEE to equivalence with local trust (Section 3.4).

  13.6.1.  13.6.1.  Attestation Object

       +====================+==========+==========+====================+
       | Field              | Type     | Required | Description        |
       +====================+==========+==========+====================+
       | enclave_type       | String   | REQUIRED | TEE platform       |
       |                    |          |          | identifier (e.g.,  |
       |                    |          |          | "sgx", "sev-snp",  |
       |                    |          |          | "trustzone")       |
       +--------------------+----------+----------+--------------------+
       | measurement        | String   | REQUIRED | Enclave            |
       |                    |          |          | measurement hash   |
       |                    |          |          | (base64url-no-pad) |
       +--------------------+----------+----------+--------------------+
       | attestation_report | String   | REQUIRED | Platform-specific  |
       |                    |          |          | attestation report |
       |                    |          |          | (base64url-no-pad) |
       +--------------------+----------+----------+--------------------+
       | timestamp          | DateTime | REQUIRED | Attestation        |
       |                    |          |          | generation         |
       |                    |          |          | timestamp (RFC     |
       |                    |          |          | 3339)              |
       +--------------------+----------+----------+--------------------+
       | nonce              | String   | REQUIRED | Challenge nonce    |
       |                    |          |          | binding this       |
       |                    |          |          | attestation to the |
       |                    |          |          | current session    |
       |                    |          |          | (UUID v4)          |
       +--------------------+----------+----------+--------------------+

                                    Table 35

  13.6.2.  13.6.2.  Attestation Verification

     A verifier MUST:

     1.  Verify the attestation_report against the TEE platform's root of
         trust (platform-specific, out of scope).
     2.  Verify that measurement matches an expected enclave binary hash
         (implementation-defined allowlist).
     3.  Verify that nonce matches the session's challenge nonce.



  Baur                    Expires 21 November 2026               [Page 54]


  Internet-Draft                     PAP                          May 2026


     4.  Verify that timestamp is within an acceptable window
         (implementations SHOULD reject attestations older than 60
         seconds).

  13.6.3.  13.6.3.  Trust Boundaries

     TEE attestation provides evidence of code integrity, not behavioral
     correctness.  Specifically:

     *  A TEE attestation MUST NOT be treated as equivalent to a mandate.
        An agent in a TEE still requires a valid mandate chain.
     *  A TEE attestation MUST NOT be used to expand scope beyond what the
        mandate permits.
     *  The principal MAY use TEE attestation as an input to auto-approval
        policies (Section 13.4) but MUST NOT be required to accept TEE
        attestation as a substitute for consent.

  13.6.4.  13.6.4.  Implementation Notes

     The reference implementation provides TEE attestation support via the
     pap-tee crate, which is compiled only when opted into as a
     dependency.  Integration with pap-core is gated behind the tee Cargo
     feature flag.

     *  *pap-tee crate*: Defines AttestationEvidence, EnclaveType, the
        AttestationVerifier trait, and a SoftwareSimulator for integration
        testing without hardware.
     *  *pap-core tee feature*: Adds an optional attestation field to
        Session and provides open_with_attestation().
     *  *ProtocolMessage::TokenAccepted*: Carries an optional attestation
        field as opaque JSON (serde_json::Value).  Receivers parse it via
        AttestationEvidence::from_value().

     The SoftwareSimulator uses EnclaveType::Software and signs
     attestation reports with an Ed25519 key.  It is intended for
     conformance testing (Appendix D, tests E-13 through E-15) and MUST
     NOT be deployed in production.

  13.7.  Payment Proof Validation

     Section 13.1 defines the payment proof integration point.  This
     section specifies the validation requirements that a conformant
     implementation MUST satisfy when payment proofs are present.

  13.7.1.  13.7.1.  Proof Format Registry

     PAP defines the following payment proof format prefixes:




  Baur                    Expires 21 November 2026               [Page 55]


  Internet-Draft                     PAP                          May 2026


         +=================+================+=======================+
         | Prefix          | Protocol       | Description           |
         +=================+================+=======================+
         | ecash:blind:v1: | Chaumian ecash | Blind-signed mint     |
         |                 |                | tokens (Section 13.1) |
         +-----------------+----------------+-----------------------+
         | ln:preimage:v1: | Lightning      | Hash preimage proof   |
         |                 | Network        | of payment            |
         +-----------------+----------------+-----------------------+
         | zk:receipt:v1:  | Zero-knowledge | ZK proof of value     |
         |                 | proof          | transfer              |
         +-----------------+----------------+-----------------------+

                                   Table 36

     Implementations MAY support additional formats using the pap:payment:
     namespace prefix.

  13.7.2.  13.7.2.  Validation Requirements

     A receiving agent that requires payment MUST:

     1.  Parse the payment_proof field and identify the format prefix.
     2.  If the format is not supported, reject the mandate with a
         PaymentFormatUnsupported error.
     3.  Verify the proof against the appropriate payment backend (mint,
         Lightning node, or ZK verifier).  The verification protocol is
         out of scope for this specification.
     4.  Verify that the proof amount meets the agent's minimum
         requirement for the requested action.
     5.  Verify that the proof has not been previously consumed (double-
         spend protection).

  13.7.3.  13.7.3.  Privacy Requirements

     *  Payment proof verification MUST NOT reveal the payer's identity to
        the payment backend.
     *  The receiving agent MUST NOT store payment proofs beyond the
        session duration unless required by applicable law.
     *  Payment proofs MUST NOT appear in transaction receipts
        (Section 11.5).

  13.8.  Chat and Real-Time Communication








  Baur                    Expires 21 November 2026               [Page 56]


  Internet-Draft                     PAP                          May 2026


  13.8.1.  13.8.1.  Overview

     PAP provides a natural foundation for zero-trust, privacy-preserving
     real-time communication between principals.  A personal agent MAY
     advertise schema:CommunicateAction in the federation registry —
     exactly as a service agent advertises schema:SearchAction.  This
     makes a principal discoverable for chat without requiring a phone
     number, email address, or centrally-administered identity.
     Discoverability is opt-in, scoped, and revocable through the standard
     mandate system.

     Chat is not a new protocol.  It is the *Phase 4 streaming extension*
     of the standard 6-phase handshake, applied to a
     schema:CommunicateAction session.

  13.8.2.  13.8.2.  Capability Grant

     A CapabilityToken scoped to schema:CommunicateAction MUST be issued
     by the initiating principal (or a delegated orchestrator) and signed
     with a principal key.  The token:

     *  MUST set action = "schema:CommunicateAction".
     *  MUST set target_did to the receiving principal's agent DID.
     *  MAY set a ttl appropriate for the conversation duration.
     *  MAY carry a scope restricting the permitted communication modes
        (e.g., text-only, text+audio, text+audio+video).

  13.8.3.  13.8.3.  Phase 4 Streaming Mode

     After Phase 3 (disclosure), instead of a single task execution, the
     session transitions to *streaming mode*:

     1.  *Phase 4 execute* (client → server, no payload): the receiving
         agent returns ExecutionResult containing a schema:Conversation
         JSON-LD object.  This signals that the session SHOULD remain
         open.

     2.  *StreamingMessage frames* (bidirectional, Phase 4): either party
         MAY send StreamingMessage frames carrying DIDComm basicmessage
         protocol payloads (see Section 13.8.5).  Each frame MUST include:

         *  id: a UUID for ack correlation.
         *  content: a JSON object conforming to the DIDComm basicmessage
            body schema.

     3.  *StreamingAck* (responding side): upon receiving a
         StreamingMessage, the server MUST reply with either a
         StreamingAck (delivery confirmed) or a StreamingMessage (reply).



  Baur                    Expires 21 November 2026               [Page 57]


  Internet-Draft                     PAP                          May 2026


     4.  The session MUST remain open until either party sends
         SessionClose (Phase 6).  Implementations SHOULD NOT proceed to
         Phase 5 (receipt co-signing) until the conversation is concluded.

  13.8.4.  13.8.4.  Message Format (DIDComm basicmessage)

     The content field of each StreamingMessage MUST conform to the
     DIDComm basicmessage 2.0 protocol body:

     {
       "type": "https://didcomm.org/basicmessage/2.0/message",
       "id": "<UUID>",
       "body": {
         "content": "<text of message>"
       }
     }

     The DIDComm wrapping (plaintext, signed, or encrypted) is applied at
     the Envelope layer via PapToDIDComm (Section 5.6).  For chat
     sessions, implementations SHOULD use at minimum DIDCommSigned to bind
     each message to the sender's session DID.

  13.8.5.  13.8.5.  Receipt

     Upon SessionClose, the receipt (Phase 5) MUST record:

     *  action = "schema:CommunicateAction"
     *  executed: a summary string, e.g., "schema:Conversation".
     *  disclosed_by_initiator / disclosed_by_receiver: property
        references only (e.g., ["schema:name"]).  Message *content* MUST
        NOT appear in receipts.
     *  Both parties' session DIDs as initiating_agent_did /
        receiving_agent_did (ephemeral, unlinked from principal DIDs).

  13.8.6.  13.8.6.  Group Chat Rooms

     A group chat room is an agent with its own DID that implements
     AgentHandler and maintains one session per member:

     *  The room DID is registered in the federation with capability:
        ["schema:CommunicateAction"].
     *  The room owner issues a separate CapabilityToken to each member,
        all targeting the room DID.
     *  Each member runs the standard 6-phase handshake against the room
        DID.  After Phase 4 (streaming mode open), the room agent fans out
        each StreamingMessage to all other connected members.





  Baur                    Expires 21 November 2026               [Page 58]


  Internet-Draft                     PAP                          May 2026


     *  Group membership is enforced by the token system: only principals
        holding a valid token may connect.  Revocation follows the
        standard mandate revocation flow (Section 8).
     *  Rooms MAY be hosted locally (Papillon instance) or on any
        federation peer.  A room hosted on a federation peer is
        discoverable via its DID advertisement.

  13.8.7.  13.8.7.  Audio and Video

     Audio and video calls follow the same pattern as text chat, using
     WebRTC as the media transport:

     1.  PAP Phases 1–4 establish identity, authorization, and streaming
         mode.  The CapabilityToken scope SHOULD include the permitted
         media types (e.g., text+audio+video).
     2.  *SDP negotiation* is carried via StreamingMessage frames: the
         offerer sends a StreamingMessage whose content.body contains the
         SDP offer; the answerer replies with SDP answer.  ICE candidates
         are exchanged as subsequent frames.
     3.  WebRTC DTLS-SRTP establishes the media channel out-of-band.  PAP
         does not inspect or relay media.
     4.  Implementations MAY route ICE/TURN through an OHTTP relay to
         conceal participant IP addresses.
     5.  The PAP receipt records call metadata (duration, participant
         session DIDs, permitted media scope) but MUST NOT include audio
         or video content.

  13.8.8.  13.8.8.  Privacy Properties

     Chat sessions inherit all PAP privacy guarantees:

     *  *Ephemeral session DIDs* — neither party's principal DID appears
        in message frames or SDP.
     *  *OHTTP relay* — IP addresses hidden from the relay operator.
     *  *Receipts* — property references only; no message content.
     *  *Discoverability* — controlled by the principal's federation
        advertisement; opt-in.
     *  *Forward secrecy* — DIDComm anoncrypt (ECDH-ES + A256GCM) MAY be
        applied to StreamingMessage content for per-message forward
        secrecy.

  14.  Transport Binding

  14.1.  HTTP/JSON Transport

     PAP defines an HTTP/JSON transport binding for the 6-phase handshake.
     This binding is the default transport for PAP v1.0.  Implementations
     MAY define additional transport bindings.



  Baur                    Expires 21 November 2026               [Page 59]


  Internet-Draft                     PAP                          May 2026


  14.2.  Agent Server Endpoints

     A receiving agent MUST expose the following HTTP endpoints:

     +======+========================+=====+==================+==================+
     |Method|Path                    |Phase|Request           |Response          |
     +======+========================+=====+==================+==================+
     |POST  |/session                |1    |TokenPresentation |TokenAccepted or  |
     |      |                        |     |                  |TokenRejected     |
     +------+------------------------+-----+------------------+------------------+
     |POST  |/session/{id}/did       |2    |SessionDidExchange|SessionDidAck     |
     +------+------------------------+-----+------------------+------------------+
     |POST  |/session/{id}/disclosure|3    |DisclosureOffer   |DisclosureAccepted|
     +------+------------------------+-----+------------------+------------------+
     |POST  |/session/{id}/execute   |4    |(empty body)      |ExecutionResult   |
     +------+------------------------+-----+------------------+------------------+
     |POST  |/session/{id}/receipt   |5    |ReceiptForCoSign  |ReceiptCoSigned   |
     +------+------------------------+-----+------------------+------------------+
     |POST  |/session/{id}/close     |6    |SessionClose      |SessionClosed     |
     +------+------------------------+-----+------------------+------------------+

                                    Table 37

     The {id} path parameter is the session ID returned in Phase 1.

  14.3.  Agent Handler Interface

     Implementations MUST implement a handler interface with the following
     operations:






















  Baur                    Expires 21 November 2026               [Page 60]


  Internet-Draft                     PAP                          May 2026


     +===================+=====+=====================+=====================+
     |Operation          |Phase|Input                |Output               |
     +===================+=====+=====================+=====================+
     |handle_token       |1    |CapabilityToken      |(session_id,         |
     |                   |     |                     |receiver_session_did)|
     +-------------------+-----+---------------------+---------------------+
     |handle_did_exchange|2    |session_id,          |()                   |
     |                   |     |initiator_session_did|                     |
     +-------------------+-----+---------------------+---------------------+
     |handle_disclosure  |3    |session_id,          |()                   |
     |                   |     |disclosures          |                     |
     +-------------------+-----+---------------------+---------------------+
     |execute            |4    |session_id           |JSON result          |
     +-------------------+-----+---------------------+---------------------+
     |co_sign_receipt    |5    |TransactionReceipt   |TransactionReceipt   |
     |                   |     |                     |(co-signed)          |
     +-------------------+-----+---------------------+---------------------+
     |handle_close       |6    |session_id           |()                   |
     +-------------------+-----+---------------------+---------------------+

                                    Table 38

  14.4.  Endpoint Resolution

     Endpoint resolution maps a DID to a transport endpoint URL.  In
     production, this SHOULD be backed by DID Document service endpoints.
     Implementations MAY use in-memory registries for development and
     testing.

  14.5.  Content Type

     All HTTP request and response bodies MUST use Content-Type:
     application/json.  Implementations SHOULD set Accept: application/
     json on requests.

  14.6.  Error Handling

     If a phase handler returns an error, the server MUST respond with
     HTTP status 500 and a ProtocolMessage::Error payload containing a
     code and message.

     If the request body does not match the expected message type for the
     endpoint, the server MUST respond with HTTP status 400.








  Baur                    Expires 21 November 2026               [Page 61]


  Internet-Draft                     PAP                          May 2026


  14.7.  WebSocket Transport

     Implementations MAY support a WebSocket transport binding as an
     alternative to the HTTP/JSON binding.  The WebSocket binding is
     OPTIONAL and provides full-duplex communication for sessions that
     benefit from lower-latency message exchange.

  14.7.1.  14.7.1.  Connection Lifecycle

     1.  The initiating agent opens a WebSocket connection to the
         receiving agent's WebSocket endpoint.
     2.  All 6 phases of the session handshake (Section 6.3) are conducted
         as JSON messages over the WebSocket connection.
     3.  Each message MUST be a JSON-serialized Envelope (Section 8.2).
     4.  The connection MUST be closed after Phase 6 (session close).

  14.7.2.  14.7.2.  Endpoint Format

     A WebSocket endpoint MUST use the wss:// scheme.  Implementations
     MUST NOT use unencrypted ws:// connections in production.

     The endpoint URL MUST be published in the agent's DID Document
     service array with type set to "PAPWebSocket":

     {
       "id": "did:key:z...#pap-ws",
       "type": "PAPWebSocket",
       "serviceEndpoint": "wss://agent.example.com/pap/ws"
     }

  14.7.3.  14.7.3.  Message Framing

     Each WebSocket text frame MUST contain exactly one JSON-serialized
     Envelope.  Binary frames MUST NOT be used.  Implementations MUST
     reject connections that send binary frames.

  14.7.4.  14.7.4.  Sequence Enforcement

     Envelope sequence number rules (Section 8.2.2) apply identically over
     WebSocket.  Out-of-order messages MUST be rejected.

  14.8.  Oblivious HTTP (OHTTP) Transport

     Implementations MAY support Oblivious HTTP [RFC 9458] as a transport
     binding.  OHTTP provides request unlinkability at the network layer,
     preventing the receiving agent's operator from correlating requests
     by IP address.




  Baur                    Expires 21 November 2026               [Page 62]


  Internet-Draft                     PAP                          May 2026


  14.8.1.  14.8.1.  Architecture

     An OHTTP deployment interposes a relay between the initiating agent
     and the receiving agent:

     Initiator -> OHTTP Relay -> Receiving Agent (Gateway)

     The relay sees the initiator's IP but not the request content.  The
     receiving agent sees the request content but not the initiator's IP.

  14.8.2.  14.8.2.  Encapsulation

     Each PAP protocol message MUST be encapsulated as an OHTTP Binary
     HTTP request targeting the corresponding HTTP/JSON endpoint
     (Section 14.2).  The Content-Type MUST remain application/json.

  14.8.3.  14.8.3.  Key Configuration

     The receiving agent MUST publish its OHTTP key configuration in its
     DID Document service array with type set to "PAPObliviousHTTP":

     {
       "id": "did:key:z...#pap-ohttp",
       "type": "PAPObliviousHTTP",
       "serviceEndpoint": "https://agent.example.com/pap/ohttp",
       "ohttpKeyConfig": "<base64url-encoded-key-config>"
     }

  14.8.4.  14.8.4.  Relay Selection

     The initiating agent selects the OHTTP relay.  The relay MUST NOT be
     operated by the same entity as the receiving agent.  The protocol
     does not define relay discovery; implementations SHOULD allow the
     principal to configure trusted relays.

  14.9.  DIDComm Transport

     Implementations MAY support DIDComm Messaging v2 [DIDCOMM-V2] as a
     transport binding.  DIDComm provides authenticated encryption at the
     message layer, enabling transport-independent secure messaging
     between agents identified by DIDs.

  14.9.1.  14.9.1.  Message Mapping

     Each PAP protocol message (Section 8.1) MUST be wrapped in a DIDComm
     plaintext message with the following mapping:





  Baur                    Expires 21 November 2026               [Page 63]


  Internet-Draft                     PAP                          May 2026


        +===============+=============================================+
        | DIDComm Field | Value                                       |
        +===============+=============================================+
        | type          | https://pap.dev/protocol/1.0/{message_type} |
        +---------------+---------------------------------------------+
        | from          | Sender's DID (session DID after Phase 2)    |
        +---------------+---------------------------------------------+
        | to            | Array containing recipient's DID            |
        +---------------+---------------------------------------------+
        | body          | The PAP protocol message payload            |
        +---------------+---------------------------------------------+
        | created_time  | Envelope timestamp (Unix epoch seconds)     |
        +---------------+---------------------------------------------+

                                    Table 39

     Where {message_type} is the lowercase, hyphenated form of the PAP
     message type (e.g., token-presentation, session-did-exchange).

  14.9.2.  14.9.2.  Encryption

     DIDComm messages MUST use authenticated encryption (authcrypt) after
     Phase 2 when both session DIDs are known.  Phase 1 messages MAY use
     anonymous encryption (anoncrypt) since the initiator's session DID is
     not yet established.

  14.9.3.  14.9.3.  Service Endpoint

     A DIDComm-capable agent MUST publish a DIDComm service endpoint in
     its DID Document:

     {
       "id": "did:key:z...#pap-didcomm",
       "type": "DIDCommMessaging",
       "serviceEndpoint": {
         "uri": "https://agent.example.com/pap/didcomm",
         "accept": ["didcomm/v2"]
       }
     }

  14.10.  Transport Negotiation

     When an agent supports multiple transport bindings, the initiating
     agent MUST select a transport by inspecting the receiving agent's DID
     Document service array.  The preference order SHOULD be:

     1.  OHTTP (strongest privacy properties)
     2.  DIDComm (authenticated encryption at message layer)



  Baur                    Expires 21 November 2026               [Page 64]


  Internet-Draft                     PAP                          May 2026


     3.  WebSocket (lower latency for interactive sessions)
     4.  HTTP/JSON (default, widest compatibility)

     If the receiving agent's DID Document contains no service entries,
     the initiating agent MUST fall back to HTTP/JSON with endpoint
     resolution (Section 14.4).

  14.11.  DIDComm v2 Envelope Compatibility

     PAP defines an optional DIDComm v2 envelope compatibility layer that
     wraps PAP protocol envelopes inside DIDComm v2 message formats.  This
     allows PAP agents to interoperate with DIDComm-native agents without
     changing the PAP protocol itself.  This section specifies the
     detailed wire formats used by the DIDComm transport binding
     (Section 14.9).

  14.11.1.  14.11.1.  Design Principles

     *  PAP mandate, session, and receipt semantics are fully preserved.
     *  Only the outer transport envelope changes; the inner PAP Envelope
        (including its Ed25519 signature) travels intact inside the
        DIDComm message body.
     *  The DIDComm layer provides additional transport-level integrity
        (JWS) or confidentiality (JWE) on top of PAP's own signatures.
     *  This is a shim — existing pap-transport behavior is unaffected.

  14.11.2.  14.11.2.  Plaintext Messages

     A PAP envelope is wrapped in a DIDComm v2 plaintext message:

     {
       "id": "<uuid>",
       "typ": "application/didcomm-plain+json",
       "type": "https://pap.baur.dev/proto/1.0/<message-slug>",
       "from": "<sender-did>",
       "to": ["<recipient-did>"],
       "created_time": <unix-timestamp>,
       "body": { <full PAP Envelope as JSON> }
     }

     The type field uses PAP message type URIs under the namespace
     https://pap.baur.dev/proto/1.0/, with kebab-case slugs derived from
     the ProtocolMessage variant name (e.g., session-did-ack, execution-
     result, token-presentation).

     The body field contains the complete PAP Envelope including its
     signature field, so the receiving agent can verify the PAP-level
     signature independently of the DIDComm layer.



  Baur                    Expires 21 November 2026               [Page 65]


  Internet-Draft                     PAP                          May 2026


  14.11.3.  14.11.3.  Signed Messages (Ed25519 JWS)

     A signed DIDComm v2 message uses JWS General JSON Serialization (RFC
     7515) with the EdDSA algorithm (RFC 8037):

     {
       "payload": "<base64url(plaintext-json)>",
       "signatures": [{
         "protected": "<base64url({\"typ\":\"application/didcomm-signed+json\",\"alg\":\"EdDSA\"})>",
         "signature": "<base64url(Ed25519-signature)>"
       }]
     }

     The signing input is ASCII(protected) || '.' || ASCII(payload) where
     both values are base64url-encoded without padding (RFC 4648
     Section 5).  The signature is computed with Ed25519 (RFC 8032).

     Verifiers MUST reject messages where: - The alg header value is not
     "EdDSA". - The signature does not verify against the expected key. -
     The decoded payload is not valid DIDComm v2 plaintext JSON.

  14.11.4.  14.11.4.  Encrypted Messages (ECDH-ES + A256GCM JWE)

     An encrypted DIDComm v2 message uses JWE JSON Serialization with
     anonymous encryption (anoncrypt):

     *  *Key Agreement*: ECDH-ES (direct, no key wrapping) via X25519
        Diffie-Hellman.  The sender generates an ephemeral X25519 keypair.
        The recipient's Ed25519 public key is converted to X25519 using
        the Edwards-to-Montgomery birational map.
     *  *Key Derivation*: Concat KDF (NIST SP 800-56A Section 5.8.1) with
        algId = "A256GCM", empty apu, and apv = SHA-256(recipient-did).
     *  *Content Encryption*: AES-256-GCM with a random 96-bit IV.  The
        base64url-encoded protected header serves as Additional
        Authenticated Data (AAD).

     {
       "protected": "<base64url(header-json)>",
       "recipients": [{
         "header": { "kid": "<recipient-did>" },
         "encrypted_key": ""
       }],
       "iv": "<base64url(96-bit-nonce)>",
       "ciphertext": "<base64url(aes-gcm-ciphertext)>",
       "tag": "<base64url(128-bit-auth-tag)>"
     }

     The protected header contains:



  Baur                    Expires 21 November 2026               [Page 66]


  Internet-Draft                     PAP                          May 2026


       +=======+=======================================================+
       | Field | Value                                                 |
       +=======+=======================================================+
       | typ   | "application/didcomm-encrypted+json"                  |
       +-------+-------------------------------------------------------+
       | alg   | "ECDH-ES"                                             |
       +-------+-------------------------------------------------------+
       | enc   | "A256GCM"                                             |
       +-------+-------------------------------------------------------+
       | epk   | {"kty":"OKP","crv":"X25519","x":"<base64url-pubkey>"} |
       +-------+-------------------------------------------------------+
       | apv   | "<base64url(SHA-256(recipient-did))>"                 |
       +-------+-------------------------------------------------------+

                                    Table 40

     The encrypted_key field is empty for ECDH-ES direct key agreement
     (the content encryption key is derived directly from the shared
     secret).

  14.11.5.  14.11.5.  Ed25519 to X25519 Key Conversion

     DIDComm v2 encryption requires X25519 keys for key agreement.  PAP
     agents use Ed25519 keys (via did:key).  The conversion is:

     *  *Public key*: Decompress the Ed25519 compressed Edwards Y
        coordinate, then apply the Edwards-to-Montgomery birational map to
        obtain the X25519 public key (32 bytes).
     *  *Private key*: Compute SHA-512(Ed25519-seed)[0..32].  The X25519
        library applies standard clamping (clear bits 0-2, clear bit 255,
        set bit 254).

     This conversion is consistent: the X25519 public key derived from the
     converted private key matches the X25519 public key derived from the
     original Ed25519 public key.

  14.11.6.  14.11.6.  Translation Rules

           +=========================+=============================+
           | Direction               | Operation                   |
           +=========================+=============================+
           | PAP → DIDComm Plaintext | Serialize PAP Envelope into |
           |                         | DIDComm body                |
           +-------------------------+-----------------------------+
           | PAP → DIDComm Signed    | Build plaintext, then apply |
           |                         | Ed25519 JWS                 |
           +-------------------------+-----------------------------+
           | PAP → DIDComm Encrypted | Build plaintext, then apply |



  Baur                    Expires 21 November 2026               [Page 67]


  Internet-Draft                     PAP                          May 2026


           |                         | ECDH-ES + A256GCM JWE       |
           +-------------------------+-----------------------------+
           | DIDComm Plaintext → PAP | Deserialize body field as   |
           |                         | PAP Envelope                |
           +-------------------------+-----------------------------+
           | DIDComm Signed → PAP    | Verify JWS, then extract    |
           |                         | PAP Envelope from body      |
           +-------------------------+-----------------------------+
           | DIDComm Encrypted → PAP | Decrypt JWE, then extract   |
           |                         | PAP Envelope from body      |
           +-------------------------+-----------------------------+

                                    Table 41

     In all cases, the PAP Envelope.signature field (if present) remains
     intact and can be verified independently using the session's
     ephemeral key.

  15.  PAP URI Scheme

  15.1.  Overview

     The pap URI scheme identifies agents, capabilities, and resources
     within the Principal Agent Protocol.  A pap:// URI is always an
     expression of *intent* — resolving one initiates a PAP mandate-scoped
     interaction, not a raw network request.

     The scheme family consists of three variants:

     +==============+====================================================+
     | Scheme       | Meaning                                            |
     +==============+====================================================+
     | pap://       | PAP-native transport; client negotiates protocol   |
     +--------------+----------------------------------------------------+
     | pap+https:// | PAP mandate scope applied over HTTPS transport     |
     +--------------+----------------------------------------------------+
     | pap+wss://   | PAP mandate scope applied over WebSocket           |
     |              | transport                                          |
     +--------------+----------------------------------------------------+

                                    Table 42










  Baur                    Expires 21 November 2026               [Page 68]


  Internet-Draft                     PAP                          May 2026


     pap+https:// and pap+wss:// are *recapture schemes*. They apply PAP
     semantics — mandate enforcement, selective disclosure, co-signed
     receipts — to existing transports.  The remote endpoint does not need
     to implement PAP.  The client enforces the protocol locally.  A
     pap+https:// URI is still an HTTPS request under the hood; the
     principal's mandate scope wraps it regardless of whether the server
     is PAP-aware.

  15.2.  Syntax

     pap-uri         = pap-scheme "://" pap-authority pap-path [ "?" pap-query ]

     pap-scheme      = "pap" / "pap+https" / "pap+wss"

     pap-authority   = registry-host / did-authority / catalog-name

     registry-host   = host [ ":" port ]
                       ; authority is the hostname only; agent slug appears in path

     did-authority   = "did:key:" base58-multicodec-key
                       ; PAP parsers MUST treat "did:key:" as an atomic authority
                       ; token. Standard RFC 3986 host parsing (which disallows
                       ; colons) MUST NOT be applied to did-authority. A PAP URI
                       ; parser identifies did-authority by the "did:key:" prefix
                       ; before applying any other rule.

     catalog-name    = 1*( ALPHA / DIGIT / "-" / "_" )
                       ; MUST NOT be a reserved word (receipt, canvas, settings)
                       ; resolved against local catalog before dispatch

     pap-path        = registry-path / simple-path

     registry-path   = "/agents/" agent-slug "/" schema-action-type
     simple-path     = "/" schema-action-type
                       ; Schema.org action type, e.g. "SearchAction"

     pap-query       = pap-param *( "&" pap-param )
     pap-param       = schema-property "=" pap-value
                       ; values MUST be percent-encoded per RFC 3986 §2.1
                       ; "+" MUST NOT be used as a space encoding in pap-query

     Examples:









  Baur                    Expires 21 November 2026               [Page 69]


  Internet-Draft                     PAP                          May 2026


  ; Networked agent via Chrysalis registry
  pap://chrysalis.example.com/agents/arxiv/SearchAction?query=quantum%20computing

  ; Direct peer-to-peer via DID (no registry)
  pap://did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK/SearchAction

  ; Local catalog shorthand — resolved before dispatch
  pap://arxiv/SearchAction?query=quantum%20computing
  pap://wikipedia/ReadAction?name=Rust%20programming

  ; Receipt deep-link
  pap://receipt/RCP_abc123

  ; Recapture schemes — PAP scope over existing transports
  pap+https://api.example.com/agents/bookings/BuyAction?offer=flight-abc
  pap+wss://stream.example.com/agents/feed/ListenAction

  15.3.  Resolution

     A conforming client MUST resolve a pap:// URI using the following
     priority chain, in order:

     1.  *Special authority* — if the authority is one of the reserved
         words (receipt, canvas, settings), resolve locally without any
         network lookup.  See §15.7.  Do not proceed to subsequent steps.

     2.  *did:key: authority* — if the authority begins with did:key:,
         resolve directly via DID Document endpoint discovery
         (Section 14.4).  No registry lookup.  Initiates a PAP handshake
         with the identified agent.

     3.  *Catalog name* — if the authority contains no . character and
         does not begin with did:, the client MUST check its local agent
         catalog for an entry whose name field matches the authority
         (case-insensitive).  If found, rewrite the URI to the agent's
         registered DID and resolve via step 1.

     4.  *Registry hostname* — if the authority contains a . character, or
         matches localhost, or is a valid IPv4 address or IPv6 literal,
         treat it as a Chrysalis registry host.  Resolve by querying the
         registry's /agents/{slug}/ routes (Section 14.1) using the path-
         embedded agent slug, and initiate a PAP handshake with the
         returned agent endpoint.  The . heuristic MUST NOT be applied to
         localhost or IP literals; they are always treated as registry
         hosts.






  Baur                    Expires 21 November 2026               [Page 70]


  Internet-Draft                     PAP                          May 2026


     If resolution fails at all steps, the client MUST render an inline
     error in place of the activated link, showing the unresolved URI and
     a human-readable explanation.  The client MUST NOT navigate away from
     the current canvas or dismiss existing content.  The client MUST NOT
     silently fall back to a raw HTTP request.

  15.4.  Action Type and Query Parameters

     The action type path segment MUST be a Schema.org action type (e.g.
     SearchAction, BuyAction, ReadAction).  For registry URIs the full
     path is /agents/{slug}/{ActionType}; for catalog and DID URIs the
     path is /{ActionType}. Clients SHOULD use the action type to pre-
     filter agents during resolution — if a catalog agent does not
     advertise the requested action type in its capability array, it MUST
     NOT be selected.

     Query parameters MUST use Schema.org property names as keys.  Values
     MUST be percent-encoded per RFC 3986 §2.1; + MUST NOT be used as a
     space encoding.  Clients MAY pass query parameters directly to the
     agent as the intent payload.  Agents MAY ignore unknown parameters.

  15.5.  Recapture Semantics (pap+https://, pap+wss://)

     When a pap+https:// or pap+wss:// URI is resolved:

     1.  The active mandate scope MUST be checked before the request is
         made.  If no mandate is in scope, the client MUST NOT proceed.

     2.  The request is made over the underlying transport (HTTPS or WSS)
         with the standard PAP session headers included where the server
         accepts them.

     3.  The client MUST record what was disclosed and generate a receipt
         entry regardless of whether the server participates in the PAP
         handshake.

     4.  The remote endpoint's response is treated as agent output and
         rendered via the standard block renderer pipeline.

     For pap+wss:// URIs, the connection lifecycle (establishment,
     keepalive, and termination) follows the mandate-scoped session
     lifecycle defined in §5.  Streaming-specific semantics (chunked
     responses, event framing) are deferred to v1.1.

     This allows principals to bring existing web services under PAP
     governance without requiring those services to be modified.





  Baur                    Expires 21 November 2026               [Page 71]


  Internet-Draft                     PAP                          May 2026


     *v1.0 scope note:* In v1.0, pap+https:// and pap+wss:// URIs are
     parsed and classified by conforming clients.  Full mandate
     enforcement (steps 1–4 above) requires the mandate enforcement layer,
     which is deferred to a post-v1.0 milestone. v1.0 clients MUST NOT
     silently downgrade a pap+https:// URI to an unscoped HTTPS request.
     They MUST either enforce the mandate or reject the request with a
     clear principal-visible error explaining that recapture enforcement
     is not yet available.

  15.6.  Link Rendering

     Any string value in a JSON-LD agent response that begins with pap://,
     pap+https://, or pap+wss:// MUST be rendered as a navigable link by
     conforming clients.  Activating such a link MUST dispatch the URI as
     intent through the same pipeline as a principal-typed query — it is
     not a browser navigation event.

     This enables agent-rendered content to form a navigable graph of
     intent-links without requiring any special page routing.  Every link
     is a new PAP interaction.

     *Agent-rendered link security:* Clients MUST visually distinguish
     links originating from agent-rendered content from links typed
     directly by the principal.  Before dispatching an agent-rendered
     pap:// link, clients SHOULD display the full URI and the identity of
     the agent that produced it, and require explicit principal
     confirmation.  This prevents injection attacks where a malicious or
     compromised agent response induces the client to execute unintended
     actions.

     Agent-rendered links MUST NOT activate the settings, canvas, or
     receipt special authorities (§15.7).  Clients MUST silently reject
     such links and MAY log the attempt for principal review.

  15.7.  Special Authorities

     The following authority values are reserved and MUST be handled by
     the client without registry or catalog lookup:













  Baur                    Expires 21 November 2026               [Page 72]


  Internet-Draft                     PAP                          May 2026


              +===========+=====================================+
              | Authority | Meaning                             |
              +===========+=====================================+
              | receipt   | Deep-link to a receipt by session   |
              |           | ID. pap://receipt/{session-id}      |
              |           | opens the receipt detail view.      |
              +-----------+-------------------------------------+
              | canvas    | Deep-link to a canvas block.        |
              |           | pap://canvas/{canvas-id}/{block-id} |
              |           | navigates to the referenced block.  |
              +-----------+-------------------------------------+
              | settings  | Opens the settings panel.           |
              |           | pap://settings/{tab} opens a        |
              |           | specific tab.                       |
              +-----------+-------------------------------------+

                                    Table 43

  16.  Security Considerations

  16.1.  Cryptographic Algorithms

     PAP v1.0 uses exclusively:

     *  *Ed25519* (RFC 8032) for all signatures.
     *  *SHA-256* (FIPS 180-4) for all hashes.
     *  *Base64url without padding* (RFC 4648 Section 5) for all binary-
        to-text encoding.
     *  *Base58btc* for DID key encoding.

     Implementations MUST use these algorithms for PAP v1.0.  All signable
     structures carry a SignatureAlgorithm field (serialized as the JWS
     alg string, e.g. "EdDSA") to enable forward-compatible algorithm
     negotiation.  The field defaults to Ed25519 when absent.
     Implementations MUST reject algorithms they do not support.  The
     did:key multicodec prefix encodes the algorithm of the public key.

     Future versions of this specification MAY introduce additional
     algorithms (e.g., ML-DSA-65 for post-quantum resistance).

  16.2.  Key Management

     *  Principal private keys SHOULD be stored in hardware security
        modules or platform authenticators (WebAuthn).  They MUST NOT be
        stored in plaintext in configuration files or environment
        variables in production.
     *  Session private keys MUST be held only in memory for the duration
        of the session.  They MUST NOT be persisted to disk.



  Baur                    Expires 21 November 2026               [Page 73]


  Internet-Draft                     PAP                          May 2026


     *  Signing keys for agent operators (used to sign advertisements)
        SHOULD be protected with access controls appropriate to the
        deployment environment.

  16.3.  Nonce Management

     *  Capability token nonces MUST be stored in a consumed-nonce set for
        at least the duration of the token's validity period.
     *  Implementations SHOULD periodically purge expired nonces to
        prevent unbounded growth of the consumed-nonce set.
     *  If a receiver restarts and loses its consumed-nonce set, it SHOULD
        reject all tokens issued before the restart by comparing issued_at
        against its restart timestamp.

  16.4.  Replay Protection

     Multiple layers provide replay protection:

     1.  *Token nonces:* Each capability token has a UUID v4 nonce
         consumed on first use.
     2.  *Envelope sequencing:* Sequence numbers are monotonically
         increasing within a session.  Out-of-order envelopes MUST be
         rejected.
     3.  *Token expiry:* Tokens carry an expires_at timestamp.  Expired
         tokens MUST be rejected.
     4.  *Session ephemerality:* Session keys are discarded at close.  A
         replayed session message cannot be verified against the original
         session keys.

  16.5.  Denial of Service

     *  Implementations SHOULD rate-limit token presentation requests to
        prevent resource exhaustion from session initiation floods.
     *  Federation sync operations SHOULD be rate-limited per peer.
     *  Marketplace registries SHOULD limit the number of advertisements
        per operator DID.

  16.6.  Man-in-the-Middle

     *  After Phase 2 (DID exchange), all envelopes MUST be signed by the
        sender's session key.  An attacker who intercepts envelopes cannot
        forge valid signatures without the session private key.
     *  The initial token presentation (Phase 1) is protected by the
        orchestrator's signature on the capability token.  An attacker
        cannot forge a valid token without the orchestrator's private key.
     *  Implementations SHOULD use TLS for all HTTP transport to protect
        against passive eavesdropping.




  Baur                    Expires 21 November 2026               [Page 74]


  Internet-Draft                     PAP                          May 2026


  16.7.  Context Leakage

     *  The DisclosureOffer (Phase 3) MUST contain only SD-JWT disclosures
        permitted by the mandate's disclosure set.
     *  The orchestrator MUST verify that the agent's requires_disclosure
        is satisfiable by the mandate before issuing a capability token.
        An agent MUST NOT receive a token if its disclosure requirements
        exceed the principal's authorization.
     *  Receipts MUST NOT contain personal data values (Section 11.5).

  16.8.  Mandate Chain Depth

     Implementations SHOULD enforce a maximum mandate chain depth to
     prevent resource exhaustion during chain verification.  A maximum
     depth of 10 is RECOMMENDED.

  16.9.  Clock Skew

     *  Implementations MUST use UTC for all timestamps.
     *  Implementations SHOULD tolerate clock skew of up to 30 seconds for
        token expiry and mandate TTL checks.
     *  Implementations MAY use NTP or similar time synchronization
        protocols to minimize skew.

  16.10.  Canonical JSON Determinism

     The security of mandate hashing and signature verification depends on
     deterministic JSON serialization.  Implementations MUST ensure that
     the canonical JSON form produces identical bytes for the same logical
     content.

     Implementations SHOULD: - Use a JSON serializer that produces
     consistent key ordering. - Represent numbers without unnecessary
     precision. - Use RFC 3339 with explicit UTC offset for all
     timestamps.

     If an implementation cannot guarantee deterministic JSON output, it
     MUST use an alternative canonical form (e.g., JCS [RFC 8785]) and
     document the choice.

  16.11.  Attack Surface Summary

      +===================+=============================+==============+
      | Attack Vector     | Mitigation                  | Spec Section |
      +===================+=============================+==============+
      | Context profiling | Ephemeral session DIDs      | 4.4, 6.3.2   |
      +-------------------+-----------------------------+--------------+
      | Over-disclosure   | SD-JWT structural binding + | 7, 9.3       |



  Baur                    Expires 21 November 2026               [Page 75]


  Internet-Draft                     PAP                          May 2026


      |                   | marketplace filtering       |              |
      +-------------------+-----------------------------+--------------+
      | Replay attacks    | Nonce consumption +         | 6.2.2, 8.2.2 |
      |                   | envelope sequencing         |              |
      +-------------------+-----------------------------+--------------+
      | Delegation bypass | Scope containment + TTL     | 5.4.5, 5.5   |
      |                   | bounds                      |              |
      +-------------------+-----------------------------+--------------+
      | Mandate tampering | Parent hash + signature     | 5.3, 5.6     |
      |                   | chain                       |              |
      +-------------------+-----------------------------+--------------+
      | Platform lock-in  | Federated discovery, no     | 10           |
      |                   | central registry            |              |
      +-------------------+-----------------------------+--------------+
      | Payment           | ZK commitments (Lightning   | 13.1         |
      | linkability       | BOLT-11, Cashu ecash)       |              |
      +-------------------+-----------------------------+--------------+
      | Session           | Session keys discarded at   | 4.4, 6.3.6   |
      | correlation       | close                       |              |
      +-------------------+-----------------------------+--------------+
      | Stale             | Decay state machine + non-  | 5.7          |
      | authorization     | renewal revocation          |              |
      +-------------------+-----------------------------+--------------+
      | Advertisement     | Signed advertisements,      | 9.4          |
      | spoofing          | registry rejects unsigned   |              |
      +-------------------+-----------------------------+--------------+
      | Retention         | TEE attestation for         | 5.4.4.1,     |
      | violation         | no_retention sessions       | 13.6         |
      +-------------------+-----------------------------+--------------+
      | Vouch ring /      | Vouch budget + age          | 10.7.3       |
      | Sybil peers       | requirement + diverse paths |              |
      +-------------------+-----------------------------+--------------+
      | Metric-based      | Anti-ranking requirement on | 9.6          |
      | ranking capture   | marketplace queries         |              |
      +-------------------+-----------------------------+--------------+

                                   Table 44

  Appendix A.  Example: Zero-Disclosure Search

     This appendix illustrates a complete PAP transaction with zero
     personal disclosure.

  A.1.  A.1.  Setup

     Principal generates keypair -> did:key:zPrincipal
     Orchestrator keypair -> did:key:zOrch
     Search agent operator keypair -> did:key:zSearch



  Baur                    Expires 21 November 2026               [Page 76]


  Internet-Draft                     PAP                          May 2026


  A.2.  A.2.  Root Mandate

     {
       "principal_did": "did:key:zPrincipal",
       "agent_did": "did:key:zOrch",
       "issuer_did": "did:key:zPrincipal",
       "parent_mandate_hash": null,
       "scope": {
         "actions": [{"action": "schema:SearchAction"}]
       },
       "disclosure_set": {"entries": []},
       "ttl": "2026-03-15T20:00:00+00:00",
       "decay_state": "Active",
       "issued_at": "2026-03-15T16:00:00+00:00",
       "payment_proof": null,
       "signature": "<base64url>"
     }

  A.3.  A.3.  Marketplace Query

     query_satisfiable("schema:SearchAction", available=[])
       -> [SearchAgent] (requires_disclosure: [])
       -> Filtered out: agents requiring personal disclosure

  A.4.  A.4.  Session Handshake

  Phase 1: Orchestrator -> SearchAgent: TokenPresentation
           SearchAgent -> Orchestrator: TokenAccepted(session_id, recv_did)

  Phase 2: Orchestrator -> SearchAgent: SessionDidExchange(init_did)
           SearchAgent -> Orchestrator: SessionDidAck

  Phase 3: Orchestrator -> SearchAgent: DisclosureOffer([])
           SearchAgent -> Orchestrator: DisclosureAccepted

  Phase 4: SearchAgent -> Orchestrator: ExecutionResult({...})

  Phase 5: Orchestrator -> SearchAgent: ReceiptForCoSign(receipt)
           SearchAgent -> Orchestrator: ReceiptCoSigned(receipt)

  Phase 6: Orchestrator -> SearchAgent: SessionClose
           SearchAgent -> Orchestrator: SessionClosed

  A.5.  A.5.  Receipt







  Baur                    Expires 21 November 2026               [Page 77]


  Internet-Draft                     PAP                          May 2026


     {
       "session_id": "<uuid>",
       "action": "schema:SearchAction",
       "initiating_agent_did": "did:key:zInitSess",
       "receiving_agent_did": "did:key:zRecvSess",
       "disclosed_by_initiator": [],
       "disclosed_by_receiver": ["operator:search_executed"],
       "executed": "schema:SearchAction executed",
       "returned": "schema:SearchResult returned",
       "timestamp": "2026-03-15T16:05:00+00:00",
       "signatures": ["<initiator_sig>", "<receiver_sig>"]
     }

     Zero personal properties disclosed.  Both session DIDs are ephemeral
     and discarded.  The receipt is auditable but contains no personal
     data.

  Appendix B.  Example: Selective Disclosure Flight Booking

  B.1.  B.1.  Disclosure Set

     {
       "entries": [{
         "type": "schema:Person",
         "permitted_properties": ["schema:name", "schema:nationality"],
         "prohibited_properties": ["schema:email", "schema:telephone"],
         "session_only": true,
         "no_retention": true
       }]
     }

  B.2.  B.2.  SD-JWT Claims

     Claims: {name: "Alice", email: "alice@example.com",
              nationality: "US", telephone: "+1-555-0100"}
     Disclosed: [name, nationality]
     Withheld: [email, telephone]  (cryptographically uncommitted)

  B.3.  B.3.  Marketplace Filtering

  SkyBook Flight Agent:  requires [name, nationality]    -> satisfiable
  LuxAir Premium Agent:  requires [name, nationality, email] -> FILTERED OUT
  StayWell Hotel Agent:  wrong object type               -> not matched

  B.4.  B.4.  Receipt






  Baur                    Expires 21 November 2026               [Page 78]


  Internet-Draft                     PAP                          May 2026


     {
       "disclosed_by_initiator": [
         "schema:Person.schema:name",
         "schema:Person.schema:nationality"
       ],
       "disclosed_by_receiver": ["operator:booking_confirmed"]
     }

     Values "Alice" and "US" never appear in the receipt.

  Appendix C.  Example: 4-Level Delegation Chain

     Level 0: Principal (root of trust)
     Level 1: Orchestrator
       scope: [Search, Reserve(Flight), Reserve(Lodging), Pay]
       ttl: 4h

     Level 2: Trip Planner (delegated from Orchestrator)
       scope: [Search, Reserve(Flight)]  (subset of Level 1)
       ttl: 3h  (< 4h)
       parent_mandate_hash: hash(Level 1 mandate)

     Level 3: Booking Agent (delegated from Trip Planner)
       scope: [Reserve(Flight)]  (subset of Level 2)
       ttl: 2h  (< 3h)
       parent_mandate_hash: hash(Level 2 mandate)

     Attempted violations: - Booking Agent delegates PayAction ->
     DelegationExceedsScope - Booking Agent delegates with TTL > 2h ->
     DelegationExceedsTtl

     Chain verification: verify_chain([principal_key, orch_key,
     planner_key])

  Appendix D.  Conformance Test Matrix

     A conformant PAP v1.0 implementation MUST pass all tests in the
     *Core* category.  Tests in the *Extension* category apply only when
     the implementation supports the corresponding extension.

  D.1.  D.1.  Core Protocol Tests

       +======+================================+=========+=============+
       | ID   | Test                           | Spec    | Requirement |
       |      |                                | Section |             |
       +======+================================+=========+=============+
       | C-01 | Root mandate sign and verify   | 5.2     | MUST        |
       +------+--------------------------------+---------+-------------+



  Baur                    Expires 21 November 2026               [Page 79]


  Internet-Draft                     PAP                          May 2026


       | C-02 | Mandate hash determinism (same | 5.3     | MUST        |
       |      | input produces same hash)      |         |             |
       +------+--------------------------------+---------+-------------+
       | C-03 | Scope containment: child       | 5.4.5   | MUST        |
       |      | subset of parent accepted      |         |             |
       +------+--------------------------------+---------+-------------+
       | C-04 | Scope containment: child       | 5.4.5,  | MUST        |
       |      | exceeding parent rejected      | 5.5 R1  |             |
       +------+--------------------------------+---------+-------------+
       | C-05 | Scope containment: child       | 5.4.5   | MUST        |
       |      | broadening object constraint   |         |             |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-06 | Delegation TTL: child TTL <=   | 5.5 R2  | MUST        |
       |      | parent TTL accepted            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-07 | Delegation TTL: child TTL >    | 5.5 R2  | MUST        |
       |      | parent TTL rejected            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-08 | Parent hash binding: correct   | 5.5 R3  | MUST        |
       |      | hash accepted                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-09 | Parent hash binding: incorrect | 5.5 R3  | MUST        |
       |      | hash rejected                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-10 | Issuer chain: child issuer_did | 5.5 R4  | MUST        |
       |      | == parent agent_did            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-11 | Principal propagation: child   | 5.5 R5  | MUST        |
       |      | principal_did == parent        |         |             |
       |      | principal_did                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-12 | Root mandate:                  | 5.5 R6  | MUST        |
       |      | parent_mandate_hash is null    |         |             |
       +------+--------------------------------+---------+-------------+
       | C-13 | Mandate chain verification:    | 5.6     | MUST        |
       |      | 2-level chain                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-14 | Mandate chain verification:    | 5.6     | MUST        |
       |      | 3-level chain                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-15 | Mandate chain verification:    | 5.6     | MUST        |
       |      | invalid signature in chain     |         |             |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-16 | Decay state: Active within TTL | 5.7     | MUST        |
       +------+--------------------------------+---------+-------------+
       | C-17 | Decay state: Degraded within   | 5.7     | MUST        |



  Baur                    Expires 21 November 2026               [Page 80]


  Internet-Draft                     PAP                          May 2026


       |      | decay window                   |         |             |
       +------+--------------------------------+---------+-------------+
       | C-18 | Decay state: ReadOnly after    | 5.7     | MUST        |
       |      | TTL expiry                     |         |             |
       +------+--------------------------------+---------+-------------+
       | C-19 | Decay state: Suspended is      | 5.7.1   | MUST        |
       |      | terminal (no renewal)          |         |             |
       +------+--------------------------------+---------+-------------+
       | C-20 | Decay state: invalid           | 5.7.1   | MUST        |
       |      | transition rejected            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-21 | Capability token sign and      | 6.2     | MUST        |
       |      | verify                         |         |             |
       +------+--------------------------------+---------+-------------+
       | C-22 | Capability token: wrong        | 6.2.2   | MUST        |
       |      | target_did rejected            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-23 | Capability token: nonce replay | 6.2.2   | MUST        |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-24 | Capability token: expired      | 6.2.2   | MUST        |
       |      | token rejected                 |         |             |
       +------+--------------------------------+---------+-------------+
       | C-25 | Session state machine:         | 6.1     | MUST        |
       |      | Initiated -> Open -> Executed  |         |             |
       |      | -> Closed                      |         |             |
       +------+--------------------------------+---------+-------------+
       | C-26 | Session state machine: invalid | 6.1     | MUST        |
       |      | transition rejected            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-27 | Session state machine: early   | 6.1     | MUST        |
       |      | termination from Initiated     |         |             |
       +------+--------------------------------+---------+-------------+
       | C-28 | SD-JWT commitment and          | 7.4,    | MUST        |
       |      | disclosure verification        | 7.5     |             |
       +------+--------------------------------+---------+-------------+
       | C-29 | SD-JWT: disclosure hash not in | 7.5     | MUST        |
       |      | commitment rejected            |         |             |
       +------+--------------------------------+---------+-------------+
       | C-30 | SD-JWT: unsigned commitment    | 7.4     | MUST        |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-31 | SD-JWT: zero-disclosure        | 7.6     | MUST        |
       |      | session accepted               |         |             |
       +------+--------------------------------+---------+-------------+
       | C-32 | SD-JWT: partial disclosure     | 7.3     | MUST        |
       |      | (subset of claims)             |         |             |
       +------+--------------------------------+---------+-------------+



  Baur                    Expires 21 November 2026               [Page 81]


  Internet-Draft                     PAP                          May 2026


       | C-33 | Envelope sign and verify with  | 8.2.1   | MUST        |
       |      | session keys                   |         |             |
       +------+--------------------------------+---------+-------------+
       | C-34 | Envelope: wrong key            | 8.2.2   | MUST        |
       |      | verification fails             |         |             |
       +------+--------------------------------+---------+-------------+
       | C-35 | Envelope: out-of-sequence      | 8.2.2   | MUST        |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-36 | Envelope: tampered payload     | 8.2.1   | MUST        |
       |      | detected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-37 | Receipt: co-signed by both     | 11.3    | MUST        |
       |      | parties                        |         |             |
       +------+--------------------------------+---------+-------------+
       | C-38 | Receipt: contains property     | 11.5    | MUST        |
       |      | references, not values         |         |             |
       +------+--------------------------------+---------+-------------+
       | C-39 | Receipt: zero-disclosure       | 11.5    | MUST        |
       |      | receipt valid                  |         |             |
       +------+--------------------------------+---------+-------------+
       | C-40 | Receipt: wrong key co-sign     | 11.4    | MUST        |
       |      | verification fails             |         |             |
       +------+--------------------------------+---------+-------------+
       | C-41 | Advertisement: unsigned        | 9.4     | MUST        |
       |      | advertisement rejected by      |         |             |
       |      | registry                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-42 | Advertisement: content hash    | 9.5,    | MUST        |
       |      | deduplication                  | 10.5    |             |
       +------+--------------------------------+---------+-------------+
       | C-43 | Marketplace: query by action   | 9.3     | MUST        |
       |      | returns matching agents        |         |             |
       +------+--------------------------------+---------+-------------+
       | C-44 | Marketplace: disclosure        | 9.3     | MUST        |
       |      | satisfiability filtering       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-45 | VC envelope: wrap and unwrap   | 12.2    | MUST        |
       |      | mandate                        |         |             |
       +------+--------------------------------+---------+-------------+
       | C-46 | VC envelope: unsigned VC       | 12.3    | MUST        |
       |      | rejected                       |         |             |
       +------+--------------------------------+---------+-------------+
       | C-47 | Session: no_retention          | 5.4.4.1 | MUST        |
       |      | disclosure rejected without    |         |             |
       |      | TEE attestation                |         |             |
       +------+--------------------------------+---------+-------------+
       | C-48 | Session attestation: sign and  | 11.6    | MUST        |



  Baur                    Expires 21 November 2026               [Page 82]


  Internet-Draft                     PAP                          May 2026


       |      | verify bilateral attestation   |         |             |
       +------+--------------------------------+---------+-------------+
       | C-49 | Session attestation: per-      | 11.6    | MUST        |
       |      | action-type segmentation       |         |             |
       |      | enforced                       |         |             |
       +------+--------------------------------+---------+-------------+

                                    Table 45

  D.2.  D.2.  Transport Tests

       +======+===========================+==============+=============+
       | ID   | Test                      | Spec Section | Requirement |
       +======+===========================+==============+=============+
       | T-01 | HTTP/JSON: full 6-phase   | 14.2         | MUST        |
       |      | handshake over HTTP       |              |             |
       +------+---------------------------+--------------+-------------+
       | T-02 | HTTP/JSON: error response | 14.6         | MUST        |
       |      | with code and message     |              |             |
       +------+---------------------------+--------------+-------------+
       | T-03 | HTTP/JSON: wrong message  | 14.6         | MUST        |
       |      | type returns 400          |              |             |
       +------+---------------------------+--------------+-------------+
       | T-04 | WebSocket: full 6-phase   | 14.7         | OPTIONAL    |
       |      | handshake over WebSocket  |              |             |
       +------+---------------------------+--------------+-------------+
       | T-05 | WebSocket: binary frame   | 14.7.3       | OPTIONAL    |
       |      | rejected                  |              |             |
       +------+---------------------------+--------------+-------------+
       | T-06 | OHTTP: encapsulated       | 14.8         | OPTIONAL    |
       |      | request reaches gateway   |              |             |
       +------+---------------------------+--------------+-------------+
       | T-07 | DIDComm: message mapping  | 14.9.1       | OPTIONAL    |
       |      | roundtrip                 |              |             |
       +------+---------------------------+--------------+-------------+

                                    Table 46

  D.3.  D.3.  Extension Tests

        +======+==============================+=========+=============+
        | ID   | Test                         | Spec    | Requirement |
        |      |                              | Section |             |
        +======+==============================+=========+=============+
        | E-01 | Payment proof: mandate with  | 13.1,   | OPTIONAL    |
        |      | valid proof accepted         | 13.7    |             |
        +------+------------------------------+---------+-------------+
        | E-02 | Payment proof: unsupported   | 13.7.2  | OPTIONAL    |



  Baur                    Expires 21 November 2026               [Page 83]


  Internet-Draft                     PAP                          May 2026


        |      | format rejected              |         |             |
        +------+------------------------------+---------+-------------+
        | E-03 | Payment proof: double-spend  | 13.7.2  | OPTIONAL    |
        |      | rejected                     |         |             |
        +------+------------------------------+---------+-------------+
        | E-04 | Continuity token: creation   | 13.3    | OPTIONAL    |
        |      | and expiry check             |         |             |
        +------+------------------------------+---------+-------------+
        | E-05 | Continuity token: expired    | 13.3.1  | OPTIONAL    |
        |      | token rejected               |         |             |
        +------+------------------------------+---------+-------------+
        | E-06 | Continuity token: principal- | 13.3.2  | OPTIONAL    |
        |      | controlled TTL               |         |             |
        +------+------------------------------+---------+-------------+
        | E-07 | Auto-approval: policy within | 13.4    | OPTIONAL    |
        |      | mandate scope accepted       |         |             |
        +------+------------------------------+---------+-------------+
        | E-08 | Auto-approval: policy        | 13.4.1  | OPTIONAL    |
        |      | exceeding mandate rejected   |         |             |
        +------+------------------------------+---------+-------------+
        | E-09 | Auto-approval: transaction   | 13.4.1  | OPTIONAL    |
        |      | exceeding max_value requires |         |             |
        |      | approval                     |         |             |
        +------+------------------------------+---------+-------------+
        | E-10 | Recovery mandate:            | 13.5.1  | OPTIONAL    |
        |      | pap:RecoverAction in scope   |         |             |
        +------+------------------------------+---------+-------------+
        | E-11 | Recovery mandate: delegation | 13.5.3  | OPTIONAL    |
        |      | attempt rejected             |         |             |
        +------+------------------------------+---------+-------------+
        | E-12 | Recovery mandate: short TTL  | 13.5.3  | OPTIONAL    |
        |      | enforced                     |         |             |
        +------+------------------------------+---------+-------------+
        | E-13 | TEE attestation: valid       | 13.6.2  | OPTIONAL    |
        |      | attestation with matching    |         |             |
        |      | nonce                        |         |             |
        +------+------------------------------+---------+-------------+
        | E-14 | TEE attestation: stale       | 13.6.2  | OPTIONAL    |
        |      | attestation rejected         |         |             |
        +------+------------------------------+---------+-------------+
        | E-15 | TEE attestation: does not    | 13.6.3  | OPTIONAL    |
        |      | expand mandate scope         |         |             |
        +------+------------------------------+---------+-------------+
        | E-16 | Marketplace: query results   | 9.6     | MUST        |
        |      | not ranked by operator       |         |             |
        |      | metrics                      |         |             |
        +------+------------------------------+---------+-------------+
        | E-17 | Marketplace: operator        | 9.6     | MUST        |



  Baur                    Expires 21 November 2026               [Page 84]


  Internet-Draft                     PAP                          May 2026


        |      | metrics excluded from        |         |             |
        |      | content hash                 |         |             |
        +------+------------------------------+---------+-------------+

                                    Table 47

  D.4.  D.4.  Federation Tests

      +======+=================================+=========+=============+
      | ID   | Test                            | Spec    | Requirement |
      |      |                                 | Section |             |
      +======+=================================+=========+=============+
      | F-01 | Federation: QueryByAction       | 10.3,   | MUST        |
      |      | returns matching advertisements | 10.4    |             |
      +------+---------------------------------+---------+-------------+
      | F-02 | Federation: Announce and        | 10.3,   | MUST        |
      |      | AnnounceAck roundtrip           | 10.4    |             |
      +------+---------------------------------+---------+-------------+
      | F-03 | Federation: content-hash        | 10.5    | MUST        |
      |      | deduplication on merge          |         |             |
      +------+---------------------------------+---------+-------------+
      | F-04 | Federation: unsigned            | 10.5    | MUST        |
      |      | advertisement skipped on merge  |         |             |
      +------+---------------------------------+---------+-------------+
      | F-05 | Federation: transitive peer     | 10.6    | OPTIONAL    |
      |      | discovery                       |         |             |
      +------+---------------------------------+---------+-------------+
      | F-06 | Federation: peer registration   | 10.7.2  | SHOULD      |
      |      | requires minimum vouches        |         |             |
      +------+---------------------------------+---------+-------------+
      | F-07 | Federation: vouch budget        | 10.7.3  | SHOULD      |
      |      | enforced (max 3/year)           |         |             |
      +------+---------------------------------+---------+-------------+
      | F-08 | Federation: probationary peer   | 10.7.3  | SHOULD      |
      |      | cannot vouch                    |         |             |
      +------+---------------------------------+---------+-------------+
      | F-09 | Federation: vouch signature     | 10.7.2  | MUST        |
      |      | verification                    |         |             |
      +------+---------------------------------+---------+-------------+

                                   Table 48

  D.5.  D.5.  Trust Invariant Summary

     A conformant implementation MUST demonstrate all eight trust
     invariants hold:





  Baur                    Expires 21 November 2026               [Page 85]


  Internet-Draft                     PAP                          May 2026


           +======+=============================+==================+
           | #    | Invariant                   | Key Tests        |
           +======+=============================+==================+
           | TI-1 | Mandate scope is            | C-03, C-04, C-05 |
           |      | cryptographically bounded   |                  |
           +------+-----------------------------+------------------+
           | TI-2 | Session DIDs are ephemeral  | C-25, C-27       |
           |      | and unlinkable to principal |                  |
           +------+-----------------------------+------------------+
           | TI-3 | Receipts contain property   | C-37, C-38, C-39 |
           |      | references, never values    |                  |
           +------+-----------------------------+------------------+
           | TI-4 | Delegation chains enforce   | C-06, C-07,      |
           |      | depth and TTL bounds        | C-13, C-14       |
           +------+-----------------------------+------------------+
           | TI-5 | Decay states follow the     | C-16, C-17,      |
           |      | defined state machine       | C-18, C-19, C-20 |
           +------+-----------------------------+------------------+
           | TI-6 | no_retention requires TEE   | C-47             |
           |      | attestation                 |                  |
           +------+-----------------------------+------------------+
           | TI-7 | Marketplace queries are     | E-16, E-17       |
           |      | ranking-free                |                  |
           +------+-----------------------------+------------------+
           | TI-8 | Peer vouching enforces      | F-06, F-07, F-08 |
           |      | budget and age constraints  |                  |
           +------+-----------------------------+------------------+

                                    Table 49

     _End of specification._

  Appendix E.  References

  E.1.  Normative References

     [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC 8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
     2119 Key Words", BCP 14, RFC 8174, May 2017.

     [RFC 3339] Klyne, G. and C.  Newman, "Date and Time on the Internet:
     Timestamps", RFC 3339, July 2002.

     [RFC 4648] Josefsson, S., "The Base16, Base32, and Base64 Data
     Encodings", RFC 4648, October 2006.




  Baur                    Expires 21 November 2026               [Page 86]


  Internet-Draft                     PAP                          May 2026


     [RFC 8032] Josefsson, S. and I.  Liusvaara, "Edwards-Curve Digital
     Signature Algorithm (EdDSA)", RFC 8032, January 2017.

     [DID-CORE] Sporny, M., Guy, A., Sabadello, M., and D.  Reed,
     "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July
     2022.

     [DID-KEY] Longley, D. and M.  Sporny, "The did:key Method v0.7", W3C
     Community Group Report.

     [SD-JWT-08] Fett, D., Yasuda, K., and B.  Campbell, "Selective
     Disclosure for JWTs (SD-JWT)", Internet-Draft draft-ietf-oauth-
     selective-disclosure-jwt-08.

     [VC-DATA-MODEL-2.0] Sporny, M., et al., "Verifiable Credentials Data
     Model v2.0", W3C Recommendation.

     [WEBAUTHN] Balfanz, D., et al., "Web Authentication: An API for
     accessing Public Key Credentials Level 2", W3C Recommendation.

  E.2.  Informative References

     [RFC 8785] Rundgren, A., Jordan, B., and S.  Erdtman, "JSON
     Canonicalization Scheme (JCS)", RFC 8785, June 2020.

     [RFC 9458] Thomson, M. and C.  A.  Wood, "Oblivious HTTP", RFC 9458,
     January 2024.

     [DIDCOMM-V2] Curren, S., Looker, T., and O.  Terbu, "DIDComm
     Messaging v2.0", Decentralized Identity Foundation, 2022.

     [RFC 6455] Fette, I. and A.  Melnikov, "The WebSocket Protocol", RFC
     6455, December 2011.

  Appendix F.  IANA and Vocabulary References

  F.1.  Schema.org Vocabulary

     PAP uses Schema.org (https://schema.org (https://schema.org)) as the
     vocabulary for action types, object types, and property references.
     The following Schema.org types are referenced in this specification:

     *Action Types:* - schema:SearchAction -- Search for information -
     schema:ReserveAction -- Reserve a resource (flight, hotel, etc.) -
     schema:PayAction -- Make a payment - schema:CheckAction -- Check a
     condition or status - schema:ReadAction -- Read a resource





  Baur                    Expires 21 November 2026               [Page 87]


  Internet-Draft                     PAP                          May 2026


     *Object Types:* - schema:Flight -- A flight - schema:Lodging --
     Lodging accommodation - schema:WebPage -- A web page

     *Entity Types:* - schema:Person -- A person - schema:Organization --
     An organization - schema:Service -- A service - schema:Order -- An
     order - schema:Subscription -- A subscription

     *Property References:* - schema:name -- Name of a person or entity -
     schema:email -- Email address - schema:telephone -- Phone number -
     schema:nationality -- Nationality

     Implementations MAY use additional Schema.org types and properties.
     Implementations MAY define additional namespaced vocabularies using a
     prefix notation (e.g., custom:MyAction).  Custom vocabularies SHOULD
     be documented.

  F.2.  W3C Standards

       +==========+====================================+==============+
       | Standard | URI                                | Usage        |
       +==========+====================================+==============+
       | DID Core | https://www.w3.org/TR/did-core/    | DID document |
       | 1.0      | (https://www.w3.org/TR/did-core/)  | structure    |
       +----------+------------------------------------+--------------+
       | DID Key  | https://w3c-ccg.github.io/did-     | did:key      |
       | Method   | method-key/ (https://w3c-          | derivation   |
       |          | ccg.github.io/did-method-key/)     |              |
       +----------+------------------------------------+--------------+
       | VC Data  | https://www.w3.org/TR/vc-data-     | Credential   |
       | Model    | model-2.0/ (https://www.w3.org/TR/ | envelope     |
       | 2.0      | vc-data-model-2.0/)                |              |
       +----------+------------------------------------+--------------+

                                   Table 50

  F.3.  IETF Standards

      +===================+=======================+====================+
      | Standard          | RFC/Draft             | Usage              |
      +===================+=======================+====================+
      | RFC 2119          | Key words             | Requirement levels |
      +-------------------+-----------------------+--------------------+
      | RFC 8174          | Key words update      | Requirement levels |
      |                   |                       | clarification      |
      +-------------------+-----------------------+--------------------+
      | RFC 3339          | Date and Time on the  | Timestamp format   |
      |                   | Internet              |                    |
      +-------------------+-----------------------+--------------------+



  Baur                    Expires 21 November 2026               [Page 88]


  Internet-Draft                     PAP                          May 2026


      | RFC 4648          | Base Encodings        | Base64url encoding |
      +-------------------+-----------------------+--------------------+
      | RFC 8032          | Edwards-Curve Digital | Ed25519 signatures |
      |                   | Signature Algorithm   |                    |
      +-------------------+-----------------------+--------------------+
      | RFC 8785          | JSON Canonicalization | Canonical JSON     |
      |                   | Scheme                | (RECOMMENDED)      |
      +-------------------+-----------------------+--------------------+
      | RFC 9458          | Oblivious HTTP        | OHTTP transport    |
      |                   |                       | binding            |
      |                   |                       | (Section 14.8)     |
      +-------------------+-----------------------+--------------------+
      | draft-ietf-oauth- | SD-JWT                | Selective          |
      | selective-        |                       | disclosure         |
      | disclosure-jwt-08 |                       |                    |
      +-------------------+-----------------------+--------------------+

                                   Table 51

  F.4.  WebAuthn

      +================+=================================+==============+
      | Standard       | URI                             | Usage        |
      +================+=================================+==============+
      | Web            | https://www.w3.org/TR/webauthn- | Device-bound |
      | Authentication | 2/ (https://www.w3.org/TR/      | key          |
      | Level 2        | webauthn-2/)                    | generation   |
      +----------------+---------------------------------+--------------+

                                    Table 52

  F.5.  Multicodec

     The Ed25519 public key multicodec prefix is 0xed01 as registered in
     the Multicodec table (https://github.com/multiformats/multicodec
     (https://github.com/multiformats/multicodec)).

  F.6.  Reserved Namespace Prefixes

            +===========+========================+===============+
            | Prefix    | Namespace              | Authority     |
            +===========+========================+===============+
            | schema:   | https://schema.org     | Schema.org    |
            |           | (https://schema.org)   | Community     |
            +-----------+------------------------+---------------+
            | operator: | Implementation-defined | Agent         |
            |           |                        | operator      |
            +-----------+------------------------+---------------+



  Baur                    Expires 21 November 2026               [Page 89]


  Internet-Draft                     PAP                          May 2026


            | pap:      | Reserved for PAP       | PAP           |
            |           | extensions             | specification |
            +-----------+------------------------+---------------+

                                   Table 53

  Appendix G.  Changelog

  G.1.  v1.0 (2026-03-24)

     *  Promoted specification from Draft to Approved status.
     *  *Section 13.5:* Added recovery mandate extension with recovery
        proof binding and short-TTL constraints.
     *  *Section 13.6:* Added TEE attestation extension with enclave
        measurement verification and trust boundary rules.
     *  *Section 13.7:* Added payment proof validation requirements
        including format registry, double-spend protection, and privacy
        constraints.
     *  *Section 14.7:* Added WebSocket transport binding with connection
        lifecycle, message framing, and sequence enforcement.
     *  *Section 14.8:* Added Oblivious HTTP (OHTTP) transport binding
        with relay architecture and key configuration.
     *  *Section 14.9:* Added DIDComm v2 transport binding with message
        mapping and authenticated encryption.
     *  *Section 14.10:* Added transport negotiation rules with privacy-
        preference ordering.
     *  *Appendix D:* Added conformance test matrix.
     *  Updated all version references from v0.1 to v1.0.
     *  Added DIDComm and WebSocket to normative/informative references.

  G.2.  v0.7 (2026-03-10)

     *  Added recovery mandate extension (Section 13.5).
     *  Added TEE attestation extension (Section 13.6).
     *  Added payment proof format registry and validation (Section 13.7).

  G.3.  v0.6 (2026-02-28)

     *  Added WebSocket transport binding (Section 14.7).
     *  Added OHTTP transport binding (Section 14.8).
     *  Added DIDComm transport binding (Section 14.9).
     *  Added transport negotiation (Section 14.10).

  G.4.  v0.4 (2026-02-01)

     *  Initial public draft with core protocol:
        -  Trust model and threat model (Section 3).
        -  Identity layer with did:key (Section 4).



  Baur                    Expires 21 November 2026               [Page 90]


  Internet-Draft                     PAP                          May 2026


        -  Mandate structure and delegation rules (Section 5).
        -  Session lifecycle with 6-phase handshake (Section 6).
        -  SD-JWT disclosure protocol (Section 7).
        -  Protocol messages and envelope (Section 8).
        -  Marketplace advertisement schema (Section 9).
        -  Federation protocol (Section 10).
        -  Receipt format (Section 11).
        -  Verifiable Credential envelope (Section 12).
        -  Payment proof integration point (Section 13.1).
        -  Continuity tokens (Section 13.3).
        -  Auto-approval policies (Section 13.4).
        -  HTTP/JSON transport binding (Section 14.1--14.6).

  Author's Address

     Todd Baur
     Baur Software
     Email: todd@baursoftware.com

































  Baur                    Expires 21 November 2026               [Page 91]


