# drafts

name: draft-sharif-aeba
rev: 00
time: 2026-04-15T08:25:30Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-17T08:25:30Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:50.092640+00:00
source: ietf
title:
  Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural Security Monitoring of Autonomous AI Agents

abstract:
  This document specifies Agent Event Behaviour Analysis (AEBA), a
     framework for collecting, signing, exchanging, and analysing
     behavioural events produced by autonomous AI agents.  AEBA is the
     agent-domain equivalent of User and Entity Behaviour Analytics (UEBA)
     as commonly deployed in enterprise Security Operations Centres.  It
     defines a canonical event schema, signature binding to agent
     identity, baseline and peer-group exchange protocols, deviation
     signalling, detection rule structure, revocation mechanisms, and
     interoperability bindings for existing Security Information and Event
     Management (SIEM) event formats (syslog, CEF, LEEF).  The framework
     is designed to compose with existing cryptographic primitives for
     agent identity, payment, and transport security, and to support
     cross-framework deployments in which agents produced by different
     runtimes must share a common behavioural observability surface.

full_text:
  Independent Submission                                         R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Informational                             15 April 2026
  Expires: 17 October 2026


     Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural
                Security Monitoring of Autonomous AI Agents
                            draft-sharif-aeba-00

  Abstract

     This document specifies Agent Event Behaviour Analysis (AEBA), a
     framework for collecting, signing, exchanging, and analysing
     behavioural events produced by autonomous AI agents.  AEBA is the
     agent-domain equivalent of User and Entity Behaviour Analytics (UEBA)
     as commonly deployed in enterprise Security Operations Centres.  It
     defines a canonical event schema, signature binding to agent
     identity, baseline and peer-group exchange protocols, deviation
     signalling, detection rule structure, revocation mechanisms, and
     interoperability bindings for existing Security Information and Event
     Management (SIEM) event formats (syslog, CEF, LEEF).  The framework
     is designed to compose with existing cryptographic primitives for
     agent identity, payment, and transport security, and to support
     cross-framework deployments in which agents produced by different
     runtimes must share a common behavioural observability surface.

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

  Copyright Notice

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



  Sharif                   Expires 17 October 2026                [Page 1]


  Internet-Draft                    AEBA                        April 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Relation to other drafts  . . . . . . . . . . . . . . . .   4
     2.  Terminology and Conventions . . . . . . . . . . . . . . . . .   5
     3.  Threat Model  . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  In-scope threats  . . . . . . . . . . . . . . . . . . . .   6
         3.1.1.  T1.  Identity compromise  . . . . . . . . . . . . . .   6
         3.1.2.  T2.  Insider-style Agent misbehaviour . . . . . . . .   6
         3.1.3.  T3.  Supply-chain compromise causing drift  . . . . .   6
         3.1.4.  T4.  Sybil agents . . . . . . . . . . . . . . . . . .   7
         3.1.5.  T5.  Event forgery  . . . . . . . . . . . . . . . . .   7
         3.1.6.  T6.  Event suppression  . . . . . . . . . . . . . . .   7
         3.1.7.  T7.  Baseline poisoning . . . . . . . . . . . . . . .   7
         3.1.8.  T8.  Peer-group spoofing  . . . . . . . . . . . . . .   8
         3.1.9.  T9.  Detection evasion via context-window
                 manipulation  . . . . . . . . . . . . . . . . . . . .   8
         3.1.10. T10.  Cross-host replay . . . . . . . . . . . . . . .   8
         3.1.11. T11.  Time skew attacks . . . . . . . . . . . . . . .   8
         3.1.12. T12.  Metadata smuggling  . . . . . . . . . . . . . .   8
         3.1.13. T13.  Delegation-chain abuse  . . . . . . . . . . . .   9
       3.2.  Out-of-scope threats  . . . . . . . . . . . . . . . . . .   9
     4.  AEBA Architecture . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Event Schema  . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Mandatory fields  . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Envelope fields . . . . . . . . . . . . . . . . . . . . .  11
       5.3.  Example . . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.4.  Event type categories . . . . . . . . . . . . . . . . . .  11
     6.  Signing and Identity Binding  . . . . . . . . . . . . . . . .  12
       6.1.  Canonical form  . . . . . . . . . . . . . . . . . . . . .  12
       6.2.  Signature algorithms  . . . . . . . . . . . . . . . . . .  12
       6.3.  Identity binding  . . . . . . . . . . . . . . . . . . . .  13
     7.  Baseline and Peer-Group Model . . . . . . . . . . . . . . . .  13
       7.1.  Baselines . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Baseline fields . . . . . . . . . . . . . . . . . . . . .  13
       7.3.  Peer-group model  . . . . . . . . . . . . . . . . . . . .  14
       7.4.  Baseline exchange . . . . . . . . . . . . . . . . . . . .  14
     8.  Deviation Signalling  . . . . . . . . . . . . . . . . . . . .  14
       8.1.  Per-event score . . . . . . . . . . . . . . . . . . . . .  14



  Sharif                   Expires 17 October 2026                [Page 2]


  Internet-Draft                    AEBA                        April 2026


       8.2.  Sequence score  . . . . . . . . . . . . . . . . . . . . .  15
       8.3.  Signalling format . . . . . . . . . . . . . . . . . . . .  15
     9.  Detection Rules and Kill-Chain Patterns . . . . . . . . . . .  15
       9.1.  Mandatory rule categories . . . . . . . . . . . . . . . .  15
       9.2.  Rule interchange  . . . . . . . . . . . . . . . . . . . .  16
     10. Revocation Protocol . . . . . . . . . . . . . . . . . . . . .  16
     11. Federation and Cross-Host Exchange  . . . . . . . . . . . . .  17
     12. Interoperability Bindings . . . . . . . . . . . . . . . . . .  17
       12.1.  Syslog (RFC 5424)  . . . . . . . . . . . . . . . . . . .  17
       12.2.  CEF (Common Event Format)  . . . . . . . . . . . . . . .  17
       12.3.  LEEF (Log Event Extended Format) . . . . . . . . . . . .  18
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  18
       13.1.  Signing is mandatory . . . . . . . . . . . . . . . . . .  18
       13.2.  Freshness and replay . . . . . . . . . . . . . . . . . .  18
       13.3.  Key management . . . . . . . . . . . . . . . . . . . . .  18
       13.4.  Baseline integrity . . . . . . . . . . . . . . . . . . .  18
       13.5.  Detection evasion  . . . . . . . . . . . . . . . . . . .  18
       13.6.  Supply-chain threats . . . . . . . . . . . . . . . . . .  18
       13.7.  Abuse of AEBA data . . . . . . . . . . . . . . . . . . .  19
     14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
     15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
       15.1.  AEBA Event Type Registry . . . . . . . . . . . . . . . .  19
       15.2.  AEBA Signing Algorithm Registry  . . . . . . . . . . . .  20
       15.3.  Rule Interchange Format  . . . . . . . . . . . . . . . .  20
     16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       17.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       17.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Appendix A.  Worked Example: Detecting Prompt-Injection-Driven
             Drift . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     Appendix B.  Worked Example: Detecting Payment Rail Shift
             Attack  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     Appendix C.  Baseline Aggregation Canonical Form  . . . . . . . .  23
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     Autonomous AI agents are being deployed into production in increasing
     numbers across payments, customer service, software engineering,
     healthcare, and industrial control.  Enterprise Security Operations
     Centres have mature frameworks for monitoring the behaviour of human
     users through User and Entity Behaviour Analytics (UEBA) systems
     [UEBA-Gartner], but no equivalent standard exists for agent entities.
     This gap is becoming acute: agents operate at one to three orders of
     magnitude higher event rates than human users, carry cryptographic
     rather than password-based identities, and are subject to novel
     attack classes including prompt injection, delegation-chain abuse,
     and model-output-driven drift that have no human analogue.



  Sharif                   Expires 17 October 2026                [Page 3]


  Internet-Draft                    AEBA                        April 2026


     This document defines a framework called Agent Event Behaviour
     Analysis (AEBA).  AEBA specifies:

     *  A canonical, extensible event schema for agent behavioural
        telemetry.

     *  Binding of each event to a verifiable agent identity using
        existing cryptographic primitives.

     *  A baseline-exchange protocol enabling hosts and observers to share
        per-agent normal-behaviour models.

     *  A deviation-signalling mechanism producing per-event and per-
        sequence risk scores.

     *  A detection-rule structure aligned with kill-chain pattern
        matching as practised in UEBA.

     *  A revocation protocol for publishing cryptographic signals that a
        specific agent has been confirmed as misbehaving.

     *  Interoperability bindings to syslog [RFC5424], CEF [CEF], and LEEF
        [LEEF], enabling direct ingestion by existing SIEM products.

     AEBA does not specify a complete SIEM or replace existing commercial
     offerings.  It defines the common contract above which multiple
     vendors, open-source projects, and enterprise deployments can
     interoperate.

  1.1.  Relation to other drafts

     AEBA is designed to compose with, not replace, existing work on agent
     security:

     *  Agent identity and key binding are specified by
        [I-D.sharif-agent-identity-framework].

     *  Event signing uses the same canonical-signing-string construction
        as [I-D.sharif-mcps-secure-mcp] and
        [I-D.sharif-agent-payment-trust].

     *  Per-message audit log format is specified by
        [I-D.sharif-agent-audit-trail]; AEBA events are a specific subtype
        suitable for behavioural analysis.

     *  Runtime attestation of agent state is specified by
        [I-D.sharif-attp-agent-trust-transport] and provides supplementary
        input to AEBA detection.



  Sharif                   Expires 17 October 2026                [Page 4]


  Internet-Draft                    AEBA                        April 2026


     AEBA is complementary to, not dependent on, OWASP [OWASP-AST10] and
     [OWASP-MCP10] risk taxonomies, and provides a machine-readable
     observability layer on which those risk categories can be monitored
     in production.

  2.  Terminology and Conventions

     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 used throughout this document:

     Agent:  An autonomous or semi-autonomous software entity executing
        under a runtime (for example, a Large Language Model with attached
        tools) that performs actions on behalf of a user, organisation, or
        other agent.

     AEBA Event:  A structured, cryptographically signed record describing
        a single observable action taken by or on behalf of an Agent.
        Defined in Section 5.

     Baseline:  A statistical model of the normal behaviour of an Agent or
        a peer-group of Agents over a specified time window.  Defined in
        Section 7.

     Deviation Signal:  A per-event or per-sequence risk score indicating
        the extent to which observed behaviour deviates from the
        applicable Baseline.

     Detection Rule:  A declarative specification matching one or more
        AEBA Events against a known malicious pattern.  Defined in
        Section 9.

     Peer Group:  A set of Agents sharing a common purpose, deployment,
        framework, or role, against which individual Agent behaviour is
        compared.

     Host Runtime:  The environment in which an Agent executes and which
        is responsible for emitting AEBA Events describing Agent actions.

     Collector:  An AEBA role that receives AEBA Events from one or more
        Host Runtimes, verifies signatures, deduplicates, and forwards to
        one or more Analysers or SIEM systems.

     Analyser:  An AEBA role that computes Baselines, applies Detection



  Sharif                   Expires 17 October 2026                [Page 5]


  Internet-Draft                    AEBA                        April 2026


        Rules, and emits alerts.

     Trust Registry:  An external authoritative endpoint that publishes
        and receives revocation signals for Agent identities, as specified
        by a referenced registry protocol.

     Consumer:  A downstream recipient of AEBA alerts or raw events,
        typically a Security Operations Centre, an incident-response
        workflow, or a policy-enforcement engine.

  3.  Threat Model

     This section enumerates the threats AEBA is designed to detect or
     mitigate.  Each threat is mapped to the AEBA mechanism addressing it.

  3.1.  In-scope threats

  3.1.1.  T1.  Identity compromise

     An adversary obtains an Agent's signing key and emits actions
     indistinguishable from the legitimate Agent.

     AEBA mitigation: Baseline deviation.  A compromised identity
     performing actions outside the legitimate Agent's behavioural
     envelope triggers Deviation Signals.  Revocation via the Trust
     Registry halts further acceptance.

  3.1.2.  T2.  Insider-style Agent misbehaviour

     A legitimately deployed Agent, under the effect of prompt injection,
     context poisoning, supply-chain-compromised dependency, or
     adversarial orchestration, performs actions outside its intended
     scope.

     AEBA mitigation: Behavioural-layer signals (see Section 8) detect
     deviations from the Agent's own baseline and from its peer-group
     baseline.  Pattern-matching Detection Rules map known attack chains
     to alert conditions.

  3.1.3.  T3.  Supply-chain compromise causing drift

     A legitimate Agent's dependencies, Skills, or underlying model are
     replaced with malicious versions; Agent behaviour subsequently
     drifts.







  Sharif                   Expires 17 October 2026                [Page 6]


  Internet-Draft                    AEBA                        April 2026


     AEBA mitigation: Abrupt baseline shift not preceded by a signed
     deployment event triggers Deviation Signal.  Event schema requires
     deployment-change events to be emitted and signed, enabling
     distinction between legitimate change and unauthorised drift.

  3.1.4.  T4.  Sybil agents

     An adversary creates multiple agent identities to evade per-identity
     rate limits, spread malicious actions across identities, or forge
     peer-group support.

     AEBA mitigation: Peer-Group membership requires cryptographic
     attestation signed by an authority recognised by Consumers.  Rapid
     creation of many new Agent identities from a single keyholder
     triggers Detection Rules.

  3.1.5.  T5.  Event forgery

     An adversary injects fake AEBA Events into a Collector in order to
     mislead baseline computation or to pollute audit records.

     AEBA mitigation: All AEBA Events MUST be signed.  Collectors MUST
     verify signatures before forwarding.  Unsigned or invalidly-signed
     Events are rejected and themselves logged as a threat indicator.

  3.1.6.  T6.  Event suppression

     An adversary suppresses AEBA Events to hide malicious behaviour,
     either at the Host Runtime, in transit, or at the Collector.

     AEBA mitigation: Sequential AEBA Events MUST include a monotonic per-
     Agent sequence number and a hash reference to the previous signed
     Event (the Agent Event Chain).  Gaps, non-monotonic sequences, or
     broken chain references trigger Detection Rules.

  3.1.7.  T7.  Baseline poisoning

     An adversary gradually shifts an Agent's baseline through low-
     deviation-per-event behaviour in order to render later malicious
     behaviour indistinguishable from the new normal.

     AEBA mitigation: Baselines MUST retain a long-term reference
     distribution distinct from the short-term rolling baseline.
     Significant divergence between short-term and long-term baselines is
     itself a Detection Rule signal.  Peer-group comparison provides an
     independent reference resistant to per-Agent poisoning.





  Sharif                   Expires 17 October 2026                [Page 7]


  Internet-Draft                    AEBA                        April 2026


  3.1.8.  T8.  Peer-group spoofing

     An Agent falsely claims membership in a trusted peer group to benefit
     from the more permissive baseline of that group.

     AEBA mitigation: Peer-Group membership attestations MUST be signed by
     a recognised authority, verified by Analysers, and revocable.

  3.1.9.  T9.  Detection evasion via context-window manipulation

     A compromised Agent observes or infers detection thresholds and
     crafts behaviour to remain below them.

     AEBA mitigation: Detection Rules SHOULD incorporate randomised
     sampling and non-deterministic threshold components to frustrate
     modelling.  Analysers MUST NOT publish detection thresholds to
     Agents.

  3.1.10.  T10.  Cross-host replay

     An adversary captures signed Events from Host Runtime A and replays
     them into the Collector serving Host Runtime B.

     AEBA mitigation: AEBA Events MUST include Host Runtime identifier and
     a nonce; Collectors MUST reject duplicates and mismatched host
     bindings.

  3.1.11.  T11.  Time skew attacks

     An adversary manipulates timestamps to alter sequence interpretation
     or to replay stale events.

     AEBA mitigation: Events MUST carry UTC timestamps; Analysers MUST
     reject events outside a configurable freshness window (recommended:
     +/-300 seconds) at ingestion, subject to explicit backfill procedure.

  3.1.12.  T12.  Metadata smuggling

     An adversary uses Event metadata fields (labels, tags) to smuggle
     encoded data (exfiltration channel).

     AEBA mitigation: Metadata fields MUST be subject to schema validation
     and per-field length limits.  Analysers SHOULD compute entropy
     statistics over metadata fields and alert on outlier entropy.







  Sharif                   Expires 17 October 2026                [Page 8]


  Internet-Draft                    AEBA                        April 2026


  3.1.13.  T13.  Delegation-chain abuse

     A parent Agent spawns a child Agent that performs actions the
     parent's own policy would have denied.

     AEBA mitigation: Delegation events MUST be emitted and signed
     (parent-signs-child).  Child Agent capability scope MUST NOT exceed
     parent Agent's scope; Analysers MUST enforce scope-inheritance limits
     and alert on violations.

  3.2.  Out-of-scope threats

     AEBA does not address:

     *  Loss of confidentiality in Agent model internals (a model-
        protection problem);

     *  Denial of service at the Host Runtime or Collector layer (handled
        by conventional network and infrastructure controls);

     *  Physical-layer compromise of signing key storage (addressed by
        hardware security module practice).

  4.  AEBA Architecture

     The AEBA architecture comprises five roles.

            +---------+     +-----------+    +-----------+
            |  Agent  |---->| Host      |--->| Collector |
            +---------+     | Runtime   |    +-----------+
                            +-----------+          |
                                                   v
                                            +-----------+
                                            | Analyser  |
                                            +-----------+
                                              |       |
                            +-----------------+       +-----------+
                            v                                     v
                      +----------------+              +-----------------+
                      | Trust Registry |              | SIEM / Consumer |
                      +----------------+              +-----------------+

     Role descriptions:

     1.  The *Agent* performs actions.  Its runtime-observable actions
         produce AEBA Events.





  Sharif                   Expires 17 October 2026                [Page 9]


  Internet-Draft                    AEBA                        April 2026


     2.  The *Host Runtime* observes Agent actions and emits signed AEBA
         Events.  It MAY perform this signing itself or it MAY forward
         Agent-self-signed Events.

     3.  The *Collector* receives Events from one or more Host Runtimes,
         verifies signatures, deduplicates, and forwards.

     4.  The *Analyser* computes Baselines, applies Detection Rules, and
         emits alerts.

     5.  The *Trust Registry* publishes revocation and peer-group
         attestation signals; the Analyser consults the Registry when
         evaluating identity binding.

     Any AEBA implementation MAY combine these roles.  The protocol
     defines the contract between roles; it does not prescribe deployment
     topology.

  5.  Event Schema

     An AEBA Event is a JSON object with the following mandatory fields
     and an extensible set of optional type-specific fields.

  5.1.  Mandatory fields

     *  aeba: (string) protocol version.  Current value: "1.0".

     *  id: (string) UUID v4 uniquely identifying this Event.

     *  agentId: (string) identifier of the Agent, matching the keyid
        field in the signature envelope.

     *  hostRuntimeId: (string) identifier of the Host Runtime from which
        the Event originated.

     *  ts: (integer) Event timestamp in seconds since Unix epoch (UTC).

     *  seq: (integer) monotonically increasing per-Agent sequence number.

     *  prevHash: (string) hex-encoded SHA-256 digest of the canonical
        form of the previous Event emitted by this Agent, or 64 zeros for
        the first Event.

     *  type: (string) Event type, drawn from the registered AEBA Event
        Type registry (see Section 15).

     *  category: (string) one of "identity", "tool", "payment", "skill",
        "delegation", "deployment", "compliance", "custom".



  Sharif                   Expires 17 October 2026               [Page 10]


  Internet-Draft                    AEBA                        April 2026


     *  payload: (object) type-specific fields.

  5.2.  Envelope fields

     The signed envelope wrapping the Event contains:

     *  alg: (string) signing algorithm identifier.  Initial values:
        "ES256" (mandatory-to-implement).

     *  keyid: (string) identifier of the signing key.

     *  sig: (string) base64-encoded signature over the canonical form
        (see Section 6).

     *  pubkeyHint: (string, optional) URL at which the verification key
        may be retrieved.

  5.3.  Example

     {
       "aeba": "1.0",
       "id": "7c6e5b94-f8a1-4e9d-a3c2-b0d7f2e1c5a8",
       "agentId": "agent:acme-payments-01",
       "hostRuntimeId": "host:prod-us-east-cluster-7",
       "ts": 1744746000,
       "seq": 14823,
       "prevHash": "3f4a8b2c1d7e9f0a6b5c4d3e2f1a0b9c...",
       "type": "tool.call",
       "category": "tool",
       "payload": {
         "toolName": "agentpass_pay",
         "toolArgs": {
           "rail": "x402",
           "to": "merchant-hash:8a7f...",
           "amount": 2500,
           "currency": "USD"
         },
         "durationMs": 142,
         "outcome": "allowed"
       }
     }

  5.4.  Event type categories

     Each AEBA Event MUST declare a category.  Categories are:

     *  identity -- Agent identity events: keypair issuance, key rotation,
        credential verification, delegation issuance.



  Sharif                   Expires 17 October 2026               [Page 11]


  Internet-Draft                    AEBA                        April 2026


     *  tool -- Tool invocation events: tool call, tool response, tool
        selection decision.

     *  payment -- Payment-related events: payment initiated, payment
        settled, sanctions check performed.

     *  skill -- Skill events: skill loaded, skill verified, skill
        rejected.

     *  delegation -- Agent-to-agent events: child agent spawn, delegated
        authority issued, delegated authority exercised.

     *  deployment -- Runtime environment change events: code deployed,
        dependency updated, model version change.

     *  compliance -- External compliance signals: KYC completed, AML
        check, regulatory report.

     *  custom -- Implementation-specific events.  Custom events MUST use
        reverse-DNS-scoped type names to prevent collision.

  6.  Signing and Identity Binding

     AEBA Events MUST be cryptographically signed.  The signing scheme
     reuses the canonical-signing-string construction of
     [I-D.sharif-mcps-secure-mcp] and [I-D.sharif-agent-payment-trust] to
     enable shared verification infrastructure.

  6.1.  Canonical form

     The canonical form of an AEBA Event for signing is:

     <ts> <seq> <agentId> <hostRuntimeId>
        <sha256-hex(canonical-json(event))>

     Where canonical-json(event) is the JCS-canonicalised JSON form of the
     Event object, and fields are joined by single space characters.

  6.2.  Signature algorithms

     The mandatory-to-implement algorithm is ECDSA P-256 with SHA-256 (JWA
     ES256) as defined in [RFC7518].  Implementations MAY support
     additional algorithms consistent with existing agent-identity stacks
     (for example, Ed25519).







  Sharif                   Expires 17 October 2026               [Page 12]


  Internet-Draft                    AEBA                        April 2026


  6.3.  Identity binding

     The keyid field in the signature envelope MUST equal the agentId
     field in the Event body, or MUST be a designated signing key for that
     Agent as registered with the applicable Trust Registry.

     Host Runtimes that sign Events on behalf of Agents (server-side
     signing) MUST carry a signedBy field in the envelope distinguishing
     the signing identity from the Agent identity, and MUST bind the Host
     Runtime signing key to the Agent's declared Host Runtime via the
     Trust Registry.

  7.  Baseline and Peer-Group Model

  7.1.  Baselines

     A Baseline is a statistical model of normal behaviour for an Agent or
     Peer Group over a given time window.  AEBA defines two baseline
     classes:

     *  *Short-term baseline*: rolling window (recommended: 24 hours).
        Sensitive to recent behaviour; used for near-real-time anomaly
        scoring.

     *  *Long-term baseline*: reference window (recommended: 90 days).
        Resistant to short-term drift; used for detecting baseline
        poisoning (see Section 3.1.7).

     Implementations MUST maintain both classes and MUST compute deviation
     against both.

  7.2.  Baseline fields

     A minimal Baseline record comprises:

     *  eventRatePerMinute: distribution (mean, stddev, p50, p95, p99)

     *  eventCategoryMix: distribution across categories

     *  toolDiversity: distinct tools invoked per unit time

     *  costPerTask: distribution of token / compute cost per logical task

     *  paymentRecipientConcentration: Herfindahl index or equivalent

     *  peerGroupMembership: attested group(s)





  Sharif                   Expires 17 October 2026               [Page 13]


  Internet-Draft                    AEBA                        April 2026


     *  operationalSchedule: if applicable (distributions by hour-of-day,
        day-of-week)

     Implementations MAY extend this set; extensions MUST use reverse-DNS
     scoping.

  7.3.  Peer-group model

     A Peer Group is a named set of Agent identities plus an authority
     attestation signed by a recognised Peer-Group authority.  The
     attestation MUST specify:

     *  peerGroupId: stable identifier

     *  purpose: human-readable group purpose

     *  members: list of agentId values in the group

     *  issuedBy: identifier of attesting authority

     *  validFrom / validUntil: validity window

     *  attestation: signature by the authority

     Peer-Group authorities are trust anchors; their identity and
     authorisation MUST be established out of band (typically by the Trust
     Registry operator).

  7.4.  Baseline exchange

     Baselines MAY be exchanged between Host Runtimes and Analysers so
     that an Agent deployed in multiple environments carries its
     behavioural history with it.  Baseline-exchange messages MUST be
     signed by the emitting party, MUST include a validity window, and
     MUST reference the constituent Agent or Peer Group identifiers.

  8.  Deviation Signalling

     For each incoming Event, the Analyser computes a deviation score
     bounded in [0.0, 1.0] where 0.0 denotes behaviour identical to
     baseline and 1.0 denotes maximal deviation observed during the
     baseline window.

  8.1.  Per-event score

     The per-event deviation score is a weighted composite over:

     *  Event rate component (current rate vs baseline distribution)



  Sharif                   Expires 17 October 2026               [Page 14]


  Internet-Draft                    AEBA                        April 2026


     *  Category-mix component (divergence of current category from
        expected)

     *  Tool-choice component (likelihood of tool selection under
        baseline)

     *  Peer-group component (agreement of Event with peer baseline)

     The weighting is implementation-defined; implementations SHOULD
     document the weighting and MUST publish it to Consumers for audit.

  8.2.  Sequence score

     Sequences of Events are scored collectively against Detection Rules
     (see below).  Sequence scores are not bounded to [0.0, 1.0]; they are
     Rule-defined alert conditions.

  8.3.  Signalling format

     Deviation and alert signals are themselves AEBA Events with category
     "custom" and reverse-DNS type names such as com.example.aeba.alert.
     They are signed by the Analyser and forwarded to Consumers.

  9.  Detection Rules and Kill-Chain Patterns

     Detection Rules are declarative specifications of known malicious
     patterns.  A Detection Rule comprises:

     *  ruleId: stable identifier (reverse-DNS scoped)

     *  description: human-readable description

     *  scope: applicable Agent categories or peer groups

     *  pattern: pattern specification (event sequence, rate, divergence)

     *  severity: "low" | "medium" | "high" | "critical"

     *  action: recommended Consumer action on match

  9.1.  Mandatory rule categories

     Implementations MUST support at least the following rule categories:

     *  *Identity-layer*: signature failures, concurrent-keyid detection,
        rotation-frequency anomalies.





  Sharif                   Expires 17 October 2026               [Page 15]


  Internet-Draft                    AEBA                        April 2026


     *  *Behavioural-layer*: event-rate spike, tool-diversity spike,
        category-mix shift.

     *  *Economic-layer*: payment-velocity anomaly, rail-mix shift,
        recipient-concentration spike, failed-payment rate.

     *  *Relational-layer*: delegation-depth anomaly, sub-agent spawn
        rate, cross-framework interaction.

     *  *Compliance-layer*: sanctions-match rate, KYC-failure rate, trust
        score degradation.

  9.2.  Rule interchange

     Detection Rules are exchanged between parties as signed JSON
     documents.  The interchange format is defined in Section 15.3.

  10.  Revocation Protocol

     When an Agent is confirmed as misbehaving, the applicable Trust
     Registry MUST issue a revocation signal.  AEBA revocation signals
     MUST:

     *  be signed by the Trust Registry authority;

     *  name the revoked Agent keyid;

     *  specify revocation scope: "all_events", "future_events_only", or
        "specific_type:<type>";

     *  specify effective time (revokedFrom);

     *  specify reason ("key_compromise", "malicious_behaviour",
        "policy_violation", "retired").

     Consumers MUST check revocation state for each Agent either at Event-
     ingestion time (strict) or at alert-evaluation time (lazy).
     Implementations SHOULD maintain a local cache with a maximum
     freshness of 24 hours for high-criticality flows and 7 days
     otherwise.

     Revocation cascades follow delegation chains: revocation of a parent
     Agent keyid MUST cause implicit revocation of all descendants.








  Sharif                   Expires 17 October 2026               [Page 16]


  Internet-Draft                    AEBA                        April 2026


  11.  Federation and Cross-Host Exchange

     AEBA supports federated deployments in which Agents move between Host
     Runtimes operated by different organisations (for example, a Skill
     published centrally and invoked locally).  Federation SHALL use:

     *  cross-host baseline exchange as defined above;

     *  Trust Registry references resolvable via HTTPS;

     *  mutual attestation between federating Host Runtimes.

     Federated Consumers SHOULD NOT rely on unsigned baseline imports.

  12.  Interoperability Bindings

  12.1.  Syslog (RFC 5424)

     AEBA Events MAY be emitted as Syslog [RFC5424] messages.  The APP-
     NAME MUST be "aeba".  Structured data MUST include the AEBA Event
     JSON as a single SD-ELEMENT:

     <14>1 2026-04-15T08:00:00Z host.example aeba - AEBA
       [aeba@99999 event="<base64-canonical-json>"
        sig="<base64-signature>"] AEBA event

  12.2.  CEF (Common Event Format)

     AEBA Events MAY be emitted as CEF records with:

     *  Device Vendor: "AEBA"

     *  Device Product: implementation name

     *  Device Version: protocol version ("1.0")

     *  Signature ID: AEBA Event type

     *  Name: human-readable Event description

     *  Severity: mapped from deviation score (0-10)

     Structured AEBA fields MUST be carried in CEF extension fields using
     reverse-DNS naming.







  Sharif                   Expires 17 October 2026               [Page 17]


  Internet-Draft                    AEBA                        April 2026


  12.3.  LEEF (Log Event Extended Format)

     AEBA Events MAY be emitted as LEEF records following the same field
     conventions as CEF.

  13.  Security Considerations

     AEBA is itself a security-critical protocol.  The following
     considerations apply.

  13.1.  Signing is mandatory

     All AEBA Events MUST be signed.  Unsigned events compromise the
     entire analytical model and MUST be rejected at ingestion.

  13.2.  Freshness and replay

     Events MUST include a timestamp and sequence number.  Analysers MUST
     reject events outside a freshness window (recommended: +/-300
     seconds) and MUST reject replayed prevHash sequences.

  13.3.  Key management

     Agent signing keys MUST be stored in accordance with host platform
     best practice (hardware security module, enclave, OS keystore).  Loss
     of a signing key MUST trigger revocation.

  13.4.  Baseline integrity

     Baselines are themselves security-critical artifacts.  Exchange
     between parties MUST be signed.  Long-term baselines MUST be
     preserved through key rotation and custodial transitions.

  13.5.  Detection evasion

     Implementations MUST NOT publish detection thresholds or rule
     weightings to unauthenticated parties.  Detection Rule interchange
     MUST be between trusted parties.

  13.6.  Supply-chain threats

     AEBA cannot detect Agent behaviour that is permanently within
     baseline but intrinsically malicious.  AEBA is a complement to, not a
     replacement for, pre-deployment supply-chain verification (Skill
     signing, model attestation, dependency verification).






  Sharif                   Expires 17 October 2026               [Page 18]


  Internet-Draft                    AEBA                        April 2026


  13.7.  Abuse of AEBA data

     AEBA Events describing Agent actions may reveal sensitive information
     about the Agent's operator, the Agent's users, or downstream systems.
     Access to AEBA data MUST itself be access-controlled and auditable.

  14.  Privacy Considerations

     AEBA Events can contain personally identifiable information (PII) and
     confidential business data, including customer identities, payment
     recipients, document contents, and authentication artifacts.
     Implementations MUST:

     *  minimise PII in Event payloads, preferring hashed or tokenised
        identifiers where correlation is sufficient;

     *  apply encryption at rest to AEBA stores;

     *  implement retention policies consistent with applicable regulation
        (for example, GDPR Article 5(1)(e), CCPA, UK Data Protection Act);

     *  support the right of erasure (where legally required) by
        cryptographic redaction of AEBA stores, recognising that signed
        chain integrity may be partially lost on erasure.

     Baselines themselves are subject to privacy analysis.  A Baseline may
     reveal aggregate user behaviour patterns and SHOULD be treated as
     confidential.

  15.  IANA Considerations

     This document requests IANA to establish two new registries.

  15.1.  AEBA Event Type Registry

     A registry named "AEBA Event Types" with the following columns:

     *  type: the event type string (e.g., "tool.call",
        "payment.initiated")

     *  category: one of the defined categories

     *  description: human-readable description

     *  reference: defining document






  Sharif                   Expires 17 October 2026               [Page 19]


  Internet-Draft                    AEBA                        April 2026


     Registration policy: Specification Required for the reserved
     categories; First Come First Served for reverse-DNS-scoped custom
     types.

     Initial entries corresponding to the categories defined in Section 5.

  15.2.  AEBA Signing Algorithm Registry

     A registry named "AEBA Signing Algorithms" listing acceptable alg
     values.  Initial entries:

     *  ES256 -- ECDSA P-256 with SHA-256 (from [RFC7518], mandatory)

     *  EdDSA -- Edwards-curve Digital Signature Algorithm (optional)

  15.3.  Rule Interchange Format

     IANA is requested to register a media type application/aeba-rule+json
     for the Detection Rule interchange format defined in this document.

  16.  References

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

     [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
                DOI 10.17487/RFC5424, March 2009,
                <https://www.rfc-editor.org/info/rfc5424>.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015,
                <https://www.rfc-editor.org/info/rfc7518>.

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

     [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
                Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
                February 2024, <https://www.rfc-editor.org/info/rfc9421>.

  17.2.  Informative References



  Sharif                   Expires 17 October 2026               [Page 20]


  Internet-Draft                    AEBA                        April 2026


     [UEBA-Gartner]
                Gartner, "Market Guide for User and Entity Behavior
                Analytics", 2023.

     [CEF]      Micro Focus ArcSight, "Common Event Format", n.d..

     [LEEF]     IBM QRadar, "Log Event Extended Format (LEEF)", n.d..

     [MITRE-ATTACK]
                MITRE Corporation, "MITRE ATT&CK Framework", n.d..

     [OWASP-AST10]
                OWASP Foundation, "OWASP Agentic Skills Top 10", n.d..

     [OWASP-MCP10]
                OWASP Foundation, "OWASP MCP Top 10", n.d..

     [I-D.sharif-mcps-secure-mcp]
                Sharif, R., "MCPS: Cryptographic Security Layer for the
                Model Context Protocol", Work in Progress, Internet-Draft,
                draft-sharif-mcps-secure-mcp-00, 14 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-sharif-mcps-
                secure-mcp-00>.

     [I-D.sharif-agent-payment-trust]
                Sharif, R., "Trust Scoring and Identity Verification for
                Autonomous AI Agent Payment Transactions", Work in
                Progress, Internet-Draft, draft-sharif-agent-payment-
                trust-00, 25 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-sharif-agent-
                payment-trust-00>.

     [I-D.sharif-agent-audit-trail]
                Sharif, R., "Agent Audit Trail: A Standard Logging Format
                for Autonomous AI Systems", Work in Progress, Internet-
                Draft, draft-sharif-agent-audit-trail-00, 29 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-sharif-agent-
                audit-trail-00>.

     [I-D.sharif-agent-identity-framework]
                Sharif, R., "Agent Identity Framework: Trust and Identity
                for Autonomous AI Agents", Work in Progress, Internet-
                Draft, draft-sharif-agent-identity-framework-00, 6 April
                2026, <https://datatracker.ietf.org/doc/html/draft-sharif-
                agent-identity-framework-00>.






  Sharif                   Expires 17 October 2026               [Page 21]


  Internet-Draft                    AEBA                        April 2026


     [I-D.sharif-attp-agent-trust-transport]
                Sharif, R., "ATTP: Agent Trust Transport Protocol for
                Secure Agent-to-Server Communication", Work in Progress,
                Internet-Draft, draft-sharif-attp-agent-trust-transport-
                00, 30 March 2026, <https://datatracker.ietf.org/doc/html/
                draft-sharif-attp-agent-trust-transport-00>.

  Appendix A.  Worked Example: Detecting Prompt-Injection-Driven Drift

     This appendix illustrates AEBA in action against an attack described
     in Section 3.1.2 (Insider-style Agent misbehaviour).

     Scenario: An e-commerce Agent's baseline shows it calls payment.pay
     with rail=stripe 95% of the time, currency=USD 90% of the time, with
     amount distributed log-normally around $40.  Average event rate: 8
     per minute over business hours.

     Adversary injects a prompt that causes the Agent to attempt a
     rail=x402 payment to a newly-observed recipient, amount=$5000,
     repeatedly over 30 seconds.

     AEBA detection:

     1.  Per-event deviation score: the rail choice is a 5% rail with
         probability weight 0.05, producing high component score.

     2.  Recipient concentration: recipient is new to the agent;
         Herfindahl shift component adds further weight.

     3.  Event rate: 15 events in 30 seconds (30/min) vs baseline 8/min
         triggers rate rule.

     4.  Category-mix: normal mix has payment = 40%; this burst is payment
         = 100%; mix-shift rule triggers.

     5.  Composite sequence score exceeds alerting threshold; Analyser
         emits alert of severity "high" with recommended action
         "suspend_agent".

  Appendix B.  Worked Example: Detecting Payment Rail Shift Attack

     [Illustration omitted for brevity; pattern follows that of the
     previous appendix but focused on Economic-layer detection.]








  Sharif                   Expires 17 October 2026               [Page 22]


  Internet-Draft                    AEBA                        April 2026


  Appendix C.  Baseline Aggregation Canonical Form

     [Specification of the canonical form for Baseline records, ensuring
     deterministic hashing and inter-party agreement.  Omitted for the -00
     draft.]

  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     Email: raza.sharif@outlook.com








































  Sharif                   Expires 17 October 2026               [Page 23]


name: draft-feng-nmrg-ain-architecture
rev: 00
title: Agentic Intent Network (AIN): A Routing-Based Architecture for AI Agent Coordination at Scale
time: 2026-04-17T03:29:37Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-19T03:29:37Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:50.092654+00:00
source: ietf
abstract:
  The rapid proliferation of autonomous AI agents across enterprise and
     Internet-scale deployments creates a structural challenge that
     existing agent frameworks cannot address: how to enable any agent to
     discover and invoke any other agent's capabilities without pre-
     established bilateral integration, across organizational boundaries,
     at Internet scale.  This document presents the Agentic Intent Network
     (AIN) as an architecture-level model for open, heterogeneous,
     dynamically evolving multi-agent coordination.  It defines problem
     drivers, architectural and underlay requirements, architectural
     components, design invariants, scope boundaries, and a research
     agenda for the NMRG.  Engineering protocol details are intentionally
     out of scope.

full_text:
  Network Management Research Group                                C. Feng
  Internet-Draft                                           Ruijie Networks
  Intended status: Informational                             17 April 2026
  Expires: 19 October 2026


  Agentic Intent Network (AIN): A Routing-Based Architecture for AI Agent
                           Coordination at Scale
                    draft-feng-nmrg-ain-architecture-00

  Abstract

     The rapid proliferation of autonomous AI agents across enterprise and
     Internet-scale deployments creates a structural challenge that
     existing agent frameworks cannot address: how to enable any agent to
     discover and invoke any other agent's capabilities without pre-
     established bilateral integration, across organizational boundaries,
     at Internet scale.  This document presents the Agentic Intent Network
     (AIN) as an architecture-level model for open, heterogeneous,
     dynamically evolving multi-agent coordination.  It defines problem
     drivers, architectural and underlay requirements, architectural
     components, design invariants, scope boundaries, and a research
     agenda for the NMRG.  Engineering protocol details are intentionally
     out of scope.

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

  Copyright Notice

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





  Feng                     Expires 19 October 2026                [Page 1]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
       3.1.  The Multi-Agent Coordination Gap  . . . . . . . . . . . .   5
       3.2.  The O(N^2) Bilateral Integration Problem  . . . . . . . .   5
       3.3.  Limitations of Existing Frameworks  . . . . . . . . . . .   6
       3.4.  Why This Is a Network Management Research Problem . . . .   7
     4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Architectural Requirements  . . . . . . . . . . . . . . .   8
       4.3.  Underlay Requirements . . . . . . . . . . . . . . . . . .   9
     5.  AIN Architecture  . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Architecture Overview . . . . . . . . . . . . . . . . . .  10
       5.2.  Intent Datagram . . . . . . . . . . . . . . . . . . . . .  13
       5.3.  Intent Routing  . . . . . . . . . . . . . . . . . . . . .  13
       5.4.  Semantic Substrate  . . . . . . . . . . . . . . . . . . .  14
       5.5.  Application Entities  . . . . . . . . . . . . . . . . . .  14
       5.6.  Design Invariants . . . . . . . . . . . . . . . . . . . .  14
       5.7.  Structural Correspondence with IP Networking  . . . . . .  14
       5.8.  Relationship to Intent-Based Networking . . . . . . . . .  15
       5.9.  Scope Boundaries  . . . . . . . . . . . . . . . . . . . .  15
     6.  Relationship to Existing NMRG Work  . . . . . . . . . . . . .  15
       6.1.  Relationship to draft-irtf-nmrg-ai-challenges . . . . . .  15
       6.2.  Relationship to draft-irtf-nmrg-ai-deploy . . . . . . . .  16
       6.3.  AIN as a Third Research Dimension . . . . . . . . . . . .  16
     7.  Open Research Problems  . . . . . . . . . . . . . . . . . . .  16
       7.1.  Phase 1: Foundations  . . . . . . . . . . . . . . . . . .  16
       7.2.  Phase 2: Scaling  . . . . . . . . . . . . . . . . . . . .  16
       7.3.  Phase 3: Ecosystem  . . . . . . . . . . . . . . . . . . .  16
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
       10.2.  Informative References . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18





  Feng                     Expires 19 October 2026                [Page 2]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  1.  Introduction

     The deployment of autonomous AI agents is transitioning from isolated
     experimental systems to large-scale production environments.
     Individual enterprises deploy tens to hundreds of specialized agents;
     Internet-scale platforms may eventually host millions.  Each agent
     encapsulates bounded capabilities; collaboration among agents is an
     engineering necessity for accomplishing complex tasks, not an
     optional feature.

     The architecture problem is not local orchestration.  It is global,
     open coordination: how can any agent discover and invoke any other
     agent's capabilities without pre-established bilateral integration,
     and across heterogeneous frameworks and organizational boundaries?
     At scale, the pairwise integration cost grows quadratically, quickly
     overwhelming any system's operational budget.  At organizational
     boundaries, the trust and deployment assumptions embedded in today's
     frameworks break down: an agent operated by one enterprise cannot
     discover or invoke an agent operated by another without custom,
     manually maintained integration agreements.

     The name "Agentic Intent Network" reflects the three structural
     commitments of the architecture.  "Agentic" denotes that the
     participating entities are autonomous agents -- systems capable of
     independent reasoning and action -- rather than passive endpoints or
     simple services.  "Intent" denotes that coordination is expressed as
     structured, capability-oriented requests, rather than as direct
     procedure calls or point-to-point messages; an intent captures what
     the originating agent wants accomplished, abstracted from which
     specific handler will accomplish it.  "Network" denotes that the
     coordination substrate is organized as a routed network -- with a
     data plane, a control plane, addressing, and forwarding -- rather
     than as a registry, a broker, or an orchestration engine.  Together,
     the name captures the core architectural claim: routing-based
     infrastructure is the appropriate model for open, scalable,
     heterogeneous agent coordination.

     AIN proposes a routing-based answer, applying the structural logic of
     packet networking to inter-agent coordination.  This document is an
     architecture description in the IRTF style: it specifies what AIN is,
     why it is needed, and what research questions it opens.  Engineering
     protocol mechanisms and algorithmic details are intentionally handled
     in companion design-consideration documents.








  Feng                     Expires 19 October 2026                [Page 3]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  2.  Terminology

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

     Intent:
        A structured representation of a task request, expressed as a
        capability class identifier and associated constraints.

     Intent Datagram:
        The self-contained coordination unit carrying an intent, analogous
        to an IP datagram.

     Intent Class:
        A hierarchical identifier used as the routing key for an Intent
        Datagram.

     Intent Class OID (IC-OID):
        A globally unique, structured identifier for an Intent Class,
        suitable for machine processing and prefix aggregation.

     Handler Instance Identifier (HID):
        A globally unique identifier for a specific Intent Handler
        instance.

     Intent Router:
        A deterministic forwarding component that routes Intent Datagrams
        based on capability routing tables.

     Intent Dispatcher:
        An application entity that decomposes compound intents into sub-
        intents and emits routable datagrams.

     Intent Handler:
        An application entity that executes atomic intents.

     Capability Advertisement (CAP):
        A control-plane message by which an Intent Handler announces
        capabilities.

     Agent Domain:
        A collection of registered entities within a management and policy
        boundary, analogous to an IP AS.





  Feng                     Expires 19 October 2026                [Page 4]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     Semantic Substrate:
        Shared naming, capability-description, and matching semantics
        consumed by AIN control-plane functions.

     Capability Routing Table (CRT):
        A mapping from IC-OID prefixes to ranked candidate handler sets.

  3.  Problem Statement

  3.1.  The Multi-Agent Coordination Gap

     Current AI ecosystems are rich in model capabilities and local agent
     frameworks, but poor in open coordination primitives.  Systems can
     orchestrate agents that are already inside the same framework or
     trust domain, yet lack a common architecture for Internet-scale,
     cross-domain interaction among independently operated agents.

     Consider a concrete scenario: an enterprise deploys a customer-
     service agent (Framework A) that needs to invoke a compliance-
     checking agent (Framework B, operated by a different business unit)
     and a logistics-status agent (a third-party API wrapper).  Today,
     each of these connections requires a separate, manually negotiated
     integration: agreed-upon API schemas, bilateral trust configuration,
     and per-link lifecycle management.  None of the three agents can
     discover the others dynamically; each new agent added to the
     ecosystem requires O(existing agents) new integration agreements.
     This is not an implementation deficiency -- it is a structural
     absence of shared coordination infrastructure.

     This creates a coordination gap: autonomous agents can reason and act
     locally, but cannot reliably discover, select, and invoke remote
     capabilities in a neutral, scalable, framework-independent way.

  3.2.  The O(N^2) Bilateral Integration Problem

     Without shared routing infrastructure, N agents require up to
     N(N-1)/2 bilateral integrations to interoperate.  Each integration
     entails interface mapping, trust negotiation, lifecycle management,
     and operational monitoring.

     Engineering mitigations -- common API conventions, shared SDKs,
     service registries -- reduce implementation friction but do not
     change the underlying structure: each pair of agents that must
     interoperate still requires explicit, maintained coordination state.
     As agent populations grow and cross organizational boundaries, the
     per-pair cost cannot be engineered away; it must be eliminated
     architecturally.




  Feng                     Expires 19 October 2026                [Page 5]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     The Internet solved an identical structural problem for host
     interconnection.  Before shared routing infrastructure, connecting N
     hosts required bilateral reachability agreements.  IP eliminated this
     by introducing a shared forwarding substrate: any host can reach any
     other host without pre-arrangement, because routing state is
     maintained by the network rather than by endpoint pairs.  AIN applies
     the same logic to agent coordination: per-agent integration overhead
     is reduced from O(N) to O(1) by introducing shared capability routing
     infrastructure.

  3.3.  Limitations of Existing Frameworks

     Existing frameworks and protocols (e.g., AutoGen [WU2023], LangGraph,
     A2A [A2A2025], MCP [MCP2024]) provide useful local mechanisms but do
     not, by themselves, satisfy the full set of open architectural needs.

     AutoGen and LangGraph are intra-framework orchestration systems.
     They excel at coordinating agents that are co-deployed within the
     same runtime and trust boundary, but provide no mechanism for an
     agent in one framework to dynamically discover or invoke an agent in
     another.  Interoperability across framework boundaries requires
     custom bridging code, reproducing the bilateral integration problem
     at the framework level.

     MCP [MCP2024] addresses the connection between LLM-based agents and
     external tools or data sources.  Its scope is LLM-to-resource
     integration, not agent-to-agent routing.  MCP does not define how an
     agent discovers which other agents exist, selects among candidates,
     or routes a request across multiple coordination hops.

     A2A [A2A2025] defines an interaction protocol for pairs of agents.
     It is analogous to HTTP: it standardizes the exchange format for a
     single interaction, but it does not address discovery, capability
     routing, or multi-hop forwarding.  Two agents using A2A must still
     know each other's endpoints in advance; the protocol does not provide
     the directory or routing substrate needed to find them.

     They are typically optimized for one or more of:

     *  single-framework ecosystems,

     *  pre-coordinated trust and deployment assumptions,

     *  bounded organizational scope, and

     *  static or manually curated integration surfaces.





  Feng                     Expires 19 October 2026                [Page 6]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     These assumptions limit their ability to serve as a shared, Internet-
     scale coordination substrate for heterogeneous agents.  AIN is not a
     replacement for these frameworks; it is the missing coordination
     layer above and between them.

  3.4.  Why This Is a Network Management Research Problem

     First, the AIN control plane introduces new convergence challenges
     that have no direct precedent in IP routing.  Capability
     advertisements carry semantic identifiers (IC-OIDs) rather than
     topological addresses.  Convergence correctness -- the guarantee that
     every Intent Router's CRT eventually reflects the true handler
     population without loops or black holes -- must be established over a
     semantic identifier space whose structure differs fundamentally from
     IP prefixes.  Defining convergence conditions, bounding convergence
     time, and proving loop-freedom under dynamic handler populations are
     open research problems of the kind NMRG is positioned to address.

     Second, the AIN coordination substrate is itself a networked system
     that requires operational management.  As agent populations scale,
     operators need telemetry on capability routing behavior, anomaly
     detection for malformed or malicious CAPs, policy controls on which
     agents may advertise which capabilities, and mechanisms for graceful
     handler failure and capability withdrawal.  These are directly
     analogous to the network management functions that NMRG has studied
     for IP infrastructure, now applied to a new class of coordination
     plane.

     Third, practical AIN deployment is coupled with the underlying
     network and system environment in ways that require joint analysis.
     CAP propagation generates control-plane traffic whose volume and
     burstiness depend on agent population dynamics.  Intent Datagram
     forwarding latency is bounded by both AIN routing behavior and
     underlay transport characteristics.  Resource allocation across
     Intent Routers and Handlers must account for both coordination
     overhead and execution workload.  These coupling effects are
     deployment-engineering questions that sit squarely within the scope
     of [NMRG-AI-DEPLOY] and related NMRG work.

  4.  Requirements

  4.1.  Design Principles

     The requirements in this section are not assembled as a feature
     wishlist.  They are derived from three architectural principles that
     have proven effective in building open, scalable networked systems,
     applied here to the agent coordination domain.




  Feng                     Expires 19 October 2026                [Page 7]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     Principle 1: End-to-End Argument.  Saltzer, Reed, and Clark [SRC1984]
     established that functions requiring application-specific knowledge
     should be implemented at the endpoints, not in the network substrate.
     Applied to AIN: task execution, semantic reasoning, and result
     interpretation belong at Handlers and Dispatchers.  The routing
     fabric must remain thin, deterministic, and execution-agnostic.  This
     principle drives R_local and the design invariants of Networking-
     Execution Separation and Payload Opacity (Section 5.6).

     Principle 2: Narrow Waist Design.  The Internet's scalability rests
     on a minimal common interface -- the IP datagram -- that decouples
     heterogeneous link technologies below from heterogeneous applications
     above.  AIN adopts the same strategy: the Intent Datagram and IC-OID
     form a narrow waist enabling any agent framework to participate
     without requiring coordination fabric redesign.  This principle
     drives R_open and R_hetero.

     Principle 3: Decentralized Scalability.  Centralized coordination
     introduces bottlenecks, single points of failure, and policy coupling
     that limit scale.  Distributed routing protocols, from OSPF to BGP,
     demonstrate that local forwarding decisions based on distributed
     state can achieve global reachability without central oracles.  AIN
     applies this to capability routing.  This principle drives R_local
     and the bounded-convergence constraint in R_dynamic.

     A fourth consideration -- Policy/Mechanism Separation -- informs the
     overall design: routing mechanisms are specified to be generic and
     stable; capability-matching semantics and selection policies are
     explicitly layered above the forwarding core, allowing them to evolve
     independently without requiring changes to the routing fabric.

  4.2.  Architectural Requirements

     R_open (Open Participation):
        Any agent, regardless of framework, language, or deployment
        environment, MUST be able to register capabilities and invoke
        others without bilateral pre-registration.  Derivation: Follows
        from the Narrow Waist principle.  Requiring bilateral pre-
        registration reproduces the O(N^2) integration cost documented in
        Section 3.2.  A shared registration and routing substrate
        eliminates this cost structurally, as IP eliminated the need for
        pairwise host reachability agreements.

     R_local (Local Decision-Making):
        Each forwarding decision MUST be made locally using datagram-
        visible and locally maintained state; no centralized per-request
        routing oracle is assumed.  Derivation: Follows from the End-to-
        End Argument and Decentralized Scalability.  A centralized routing



  Feng                     Expires 19 October 2026                [Page 8]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


        oracle would become a bottleneck, a single point of failure, and a
        policy chokepoint -- reproducing architecturally the same problems
        that distributed routing protocols were designed to eliminate.

     R_hetero (Heterogeneous Capability Matching):
        The architecture MUST support heterogeneous handler types (LLM-
        based, deterministic, legacy-wrapped) without requiring routing-
        fabric redesign.  Derivation: Follows from the Narrow Waist
        principle and Policy/Mechanism Separation.  The routing fabric
        must remain agnostic to execution substrate.  Capability-matching
        semantics reside in the Semantic Substrate (Section 5.4), not in
        forwarding components, allowing handler technology to evolve
        without architectural disruption.

     R_dynamic (Dynamic Capability Discovery):
        The architecture MUST support dynamic capability additions,
        updates, and withdrawals with bounded convergence behavior.
        Derivation: Follows from Decentralized Scalability and the
        operational reality of large-scale deployments.  Agent populations
        are not static: handlers are deployed, updated, and retired
        continuously.  The routing fabric must accommodate this dynamism
        while providing convergence guarantees sufficient for operational
        stability -- a direct analogue of liveness and loop-freedom
        requirements in IP routing protocols.

  4.3.  Underlay Requirements

     The architectural requirements above define what the AIN coordination
     layer must provide.  They depend, in turn, on two properties of the
     underlay transport fabric.  These are stated as requirements on the
     underlay, not as design choices of the AIN architecture itself,
     consistent with the End-to-End Argument: AIN does not prescribe how
     reachability is achieved, only that it must be available.

     R_u1 (Handler Reachability):
        Any Intent Router MUST be able to deliver an Intent Datagram to
        any registered Intent Handler.

     R_u2 (Callback Reachability):
        Any Intent Handler MUST be able to deliver callback responses to
        the Originator endpoint indicated by datagram metadata.

     This document intentionally does not mandate specific implementation
     patterns for satisfying R_u1 and R_u2.  Overlay networks, service
     meshes, and conventional IP transport are all candidate mechanisms.

  5.  AIN Architecture




  Feng                     Expires 19 October 2026                [Page 9]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  5.1.  Architecture Overview

     AIN is organized into three architectural parts:

     1.  (A) Networking: underlay/transport fabric, Intent Routing data
         plane, Intent Routing control plane, and Semantic Substrate.

     2.  (B) Application Entities: Originator, Dispatcher, and Handler
         roles.

     3.  (C) Runtime Dependencies: execution runtime and compute
         infrastructure used by application entities.

     Figure 1 illustrates the layered structure and the principal
     interactions among components.




































  Feng                     Expires 19 October 2026               [Page 10]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


          +-----------+     +---------------+     +-----------+
          | Originator|     |  Dispatcher   |     |  Handler  |
          | (emits    |     | (decomposes / |     | (executes |
          |  intents) |     |  coordinates) |     |  intents) |
          +-----+-----+     +-------+-------+     +-----+-----+
                |                   |   (b)              | (a)
                |    Intent         |   sub-intents      | CAP
                |    Datagrams      |                    | (announce)
                +-------------------+--------------------+
                                    |
          ==================================================
          |           AIN Networking Substrate             |
          |                                                |
          |  +------------------------------------------+  |
          |  |     Intent Routing Control Plane         |  |
          |  |  (CAP processing, CRT computation,       |  |
          |  |   route-state distribution)              |  |
          |  +------------------+-----------------------+  |
          |           (c)       | CRT updates               |
          |  +------------------v-----------------------+  |
          |  |      Intent Routing Data Plane           |  |
          |  |                                          |  |
          |  |  [IR]-----[IR]-----[IR]-----[IR]         |  |
          |  |   ^   datagram forwarding    |           |  |
          |  |   |  (hop-by-hop, local CRT) v           |  |
          |  +------------------------------------------+  |
          |                    ^                           |
          |           (d)      | naming / matching         |
          |  +-----------------+------------------------+  |
          |  |            Semantic Substrate            |  |
          |  |  (IC-OID namespace, capability-matching  |  |
          |  |   semantics, aggregation consistency)    |  |
          |  +------------------------------------------+  |
          ==================================================
                               |
          +------------------------------------------------+
          |         Underlay / Transport Fabric            |
          |  (provides R_u1: handler reachability and      |
          |   R_u2: callback reachability)                 |
          +------------------------------------------------+

            IR  = Intent Router
            CAP = Capability Advertisement
            CRT = Capability Routing Table

          Figure 1: AIN Architecture -- Layers and Principal Entities





  Feng                     Expires 19 October 2026               [Page 11]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     The figure is read in two dimensions: vertical layering represents
     the separation of concerns, and the lettered interactions (a)--(d)
     represent the two principal information flows through the
     architecture.

     Layering.  Application Entities (top) sit above the AIN Networking
     Substrate and consume its services; they are not part of the
     forwarding core.  This boundary enforces the Networking-Execution
     Separation invariant (Section 5.6): an Intent Router forwards
     datagrams but never executes the tasks they carry.  Within the
     Networking Substrate, the Semantic Substrate occupies the base
     position because it provides the naming and matching semantics that
     the control plane depends on; it is not a forwarding layer.  The
     Underlay/Transport Fabric is architecturally external: AIN states
     what reachability properties it requires (R_u1, R_u2) but does not
     prescribe how they are satisfied.

     Control flow (interactions (a) and (c)).  When a Handler registers or
     updates its capabilities, it emits a Capability Advertisement (CAP)
     into the networking substrate (a).  The Intent Routing Control Plane
     processes incoming CAPs, applies matching semantics from the Semantic
     Substrate, and computes or updates entries in the Capability Routing
     Table (CRT) at each Intent Router (c).  This is the AIN analogue of a
     routing protocol: CAP propagation drives distributed route-state
     convergence, so that every Intent Router eventually holds a CRT
     reflecting the current handler population.

     Data flow (interactions (b) and forwarding in the data plane).  An
     Originator emits an Intent Datagram carrying an IC-OID in its routing
     header.  A Dispatcher may decompose a compound task into sub-intents
     and emit multiple datagrams (b).  Each Intent Router performs a local
     CRT lookup on the IC-OID, selects a next hop from the ranked
     candidate set, and forwards the datagram -- without consulting any
     central oracle and without inspecting the payload (Payload Opacity,
     Section 5.6).  Forwarding continues hop-by-hop until the datagram
     reaches a Handler that accepts and executes the intent.  The Handler
     returns results via a callback path to the Originator endpoint
     identified in the datagram metadata.

     Semantic Substrate (interaction (d)).  The Semantic Substrate is
     consumed by the control plane, not the data plane.  It provides the
     shared vocabulary that makes IC-OID prefix aggregation meaningful and
     capability matching consistent across heterogeneous handler types.
     Its role is analogous to the addressing and naming conventions that
     make IP prefix aggregation tractable: without shared semantics, CAP
     processing would require per-handler bespoke logic and could not
     scale.




  Feng                     Expires 19 October 2026               [Page 12]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


        +==================+=============================+============+
        | Component        | Responsibility              | IP Analogy |
        +==================+=============================+============+
        | Underlay/        | End-to-end reachability     | Physical + |
        | Transport Fabric | under R_u1 and R_u2         | Link       |
        +------------------+-----------------------------+------------+
        | Intent Routing   | Stateless forwarding of     | IP data    |
        | Data Plane       | intent datagrams            | plane      |
        +------------------+-----------------------------+------------+
        | Intent Routing   | Capability advertisement    | IP control |
        | Control Plane    | and route-state maintenance | plane      |
        +------------------+-----------------------------+------------+
        | Semantic         | Naming/matching semantics   | Addressing |
        | Substrate        |                             |            |
        +------------------+-----------------------------+------------+
        | Application      | Intent origination,         | End hosts  |
        | Entities         | dispatch, and execution     |            |
        +------------------+-----------------------------+------------+

                Table 1: AIN Architecture Overview (Conceptual)

  5.2.  Intent Datagram

     The Intent Datagram is the fundamental coordination unit.  It is
     conceptually defined as a triple:

     D = <H, P, M>

     where H is a routing header (intent class and routing-relevant
     fields), P is payload (opaque to routing), and M is metadata (e.g.,
     correlation and callback information).

  5.3.  Intent Routing

     Intent Routing separates:

     *  Data plane: deterministic per-datagram forwarding based on local
        route state.

     *  Control plane: capability advertisement processing and route-state
        computation/distribution.

     This separation mirrors core Internet architectural practice and is
     central to AIN scalability and explainability.







  Feng                     Expires 19 October 2026               [Page 13]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  5.4.  Semantic Substrate

     The Semantic Substrate defines shared capability-description and
     identifier semantics used by control-plane functions.  It is a
     substrate for naming, matching, and aggregation consistency; it is
     not treated as an independent packet-forwarding layer.

  5.5.  Application Entities

     AIN distinguishes three application-level roles:

     *  Originator: emits intents.

     *  Dispatcher: decomposes/coordinates compound tasks.

     *  Handler: executes atomic capabilities.

     These roles are above the networking substrate and consume AIN
     services; they are not part of the forwarding core.  A single
     physical deployment unit MAY simultaneously fulfill multiple roles
     (e.g., acting as both Dispatcher and Handler for different intents).
     Role assignment is decoupled from entity implementation, allowing
     flexible deployment topologies without requiring changes to the
     routing fabric or the Semantic Substrate.

  5.6.  Design Invariants

     AIN relies on four architectural invariants:

     1.  Networking-Execution Separation: forwarding components do not
         perform task execution.

     2.  Hop-by-Hop Locality: forwarding is local and incremental.

     3.  Payload Opacity: forwarding is based on routing-relevant fields,
         not payload semantics.

     4.  Datagram Self-Containment: the datagram carries sufficient
         routing context for forwarding decisions.

  5.7.  Structural Correspondence with IP Networking

     AIN intentionally mirrors key Internet architectural primitives:

     *  Intent Datagram ~ IP datagram

     *  Intent Router ~ IP router




  Feng                     Expires 19 October 2026               [Page 14]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     *  CRT ~ forwarding table

     *  Agent Domain ~ AS

     *  CAP propagation/control ~ routing control behavior

     This correspondence is structural, not literal protocol reuse.

  5.8.  Relationship to Intent-Based Networking

     [RFC9315] defines IBN intents as declarative goals for network
     behavior management.  AIN intents are routable requests for AI-agent
     capability invocation.  The two are complementary: IBN concerns
     network operation goals; AIN concerns inter-agent coordination
     routing.

  5.9.  Scope Boundaries

     AIN is designed for open, dynamic, cross-domain agent coordination at
     scale.  It is not appropriate for all agent interaction scenarios.
     In particular, AIN is not the intended solution for:

     *  Hard real-time tasks, where coordination latency introduced by
        capability routing is architecturally unacceptable.

     *  Fully static and deterministic workflows, where all handler
        assignments are known and fixed at design time, making dynamic
        capability discovery unnecessary.

     *  Closed single-framework deployments, where all participating
        agents share the same runtime and trust boundary and no cross-
        domain coordination is required.

     Explicitly defining these boundaries is consistent with the End-to-
     End Argument: functions that do not benefit from routing-based
     indirection should not be routed.  Recognizing these non-goals
     increases architectural clarity and helps implementers identify when
     AIN provides structural value.

  6.  Relationship to Existing NMRG Work

  6.1.  Relationship to draft-irtf-nmrg-ai-challenges

     AIN adds a coordination-layer perspective to AI/network-management
     challenges, including semantic-route convergence, capability
     authenticity, and explainable multi-agent routing behavior.





  Feng                     Expires 19 October 2026               [Page 15]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  6.2.  Relationship to draft-irtf-nmrg-ai-deploy

     AIN has deployment implications for capability advertisement traffic,
     convergence dynamics, and coupling between agent-coordination control
     behavior and network/system deployment choices.

  6.3.  AIN as a Third Research Dimension

     AIN frames a third dimension alongside:

     *  AI for network management, and

     *  network/system support for AI services.

     The third dimension is networked infrastructure for AI-agent
     coordination itself.

  7.  Open Research Problems

  7.1.  Phase 1: Foundations

     *  Capability description language and matching semantics.

     *  Intra-domain capability-routing protocol design.

     *  Minimal interoperable Intent Datagram schema.

     *  Baseline identity and trust for capability claims.

     *  Formal convergence and loop-freedom over semantic identifiers.

  7.2.  Phase 2: Scaling

     *  Inter-domain capability-routing policy and aggregation.

     *  Multi-metric optimization under heterogeneous constraints.

     *  Stability analysis for feedback-driven route scoring.

     *  Cross-tier latency and resource budget allocation.

  7.3.  Phase 3: Ecosystem

     *  Governance of global IC-OID taxonomy roots and delegation.

     *  Security and adversarial robustness at ecosystem scale, including
        capability-claim fraud, routing-state poisoning, and intent
        privacy threats.



  Feng                     Expires 19 October 2026               [Page 16]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


     *  Economic settlement and incentive alignment across domains.

  8.  Security Considerations

     AIN introduces security concerns at two architectural levels.

     Control-plane threats affect the integrity and availability of
     capability routing state.  Capability-claim spoofing (a malicious
     entity advertising capabilities it does not possess) and routing-
     state poisoning (injection of malformed or adversarial CAPs to
     corrupt CRTs) are the primary risks.  Semantic namespace abuse -- the
     registration of IC-OIDs intended to shadow or hijack legitimate
     capability classes -- represents a further control-plane attack
     surface.

     Data-plane threats affect the confidentiality and availability of
     intent traffic.  Privacy leakage of intent contents or originator
     identity and denial-of-service against routing or handler interfaces
     are the primary concerns.

     Architecture-level mitigation directions include authenticated
     capability advertisements, protected control-plane exchanges,
     deployment of modern transport security, and explicit governance for
     identifier namespaces.  Detailed threat modeling is identified as a
     Phase 3 research problem (Section 7.3).

  9.  IANA Considerations

     This document requests no IANA actions.

  10.  References

  10.1.  Normative References

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

     [RFC9315]  Clemm, A., Ciavaglia, L., Granville, L., Ed., and J.
                Tantsura, "Intent-Based Networking - Concepts and
                Definitions", RFC 9315, DOI 10.17487/RFC9315, October
                2022, <https://www.rfc-editor.org/info/rfc9315>.




  Feng                     Expires 19 October 2026               [Page 17]


  Internet-Draft        Agentic Intent Network (AIN)            April 2026


  10.2.  Informative References

     [A2A2025]  Google DeepMind, "Agent2Agent (A2A) Protocol", 2025,
                <https://github.com/google-deepmind/agent2agent>.

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

     [NMRG-AI-CHALLENGES]
                IRTF NMRG, "Challenges for Network Automation with AI/ML
                Techniques", Work in Progress Internet-Draft, draft-irtf-
                nmrg-ai-challenges, 2024.

     [NMRG-AI-DEPLOY]
                IRTF NMRG, "Network and System Considerations for
                Deploying AI Services", Work in Progress Internet-Draft,
                draft-irtf-nmrg-ai-deploy, 2024.

     [RFC7575]  Farrell, S. and H. Tschofenig, "Architectural
                Considerations in Smart Object Networking", RFC 7575,
                DOI 10.17487/RFC7575, July 2015,
                <https://www.rfc-editor.org/info/rfc7575>.

     [SRC1984]  Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
                in System Design", ACM Transactions on Computer
                Systems Vol. 2, No. 4, pp. 277-288, November 1984,
                <https://doi.org/10.1145/357401.357402>.

     [WU2023]   Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E.,
                Jiang, L., Zhang, X., White, R., Burger, D., Lara, V.,
                Foyer, A., and C. Wang, "AutoGen: Enabling Next-Gen LLM
                Applications via Multi-Agent Conversation",
                arXiv 2308.08155, 2023.

  Author's Address

     Chong Feng
     Ruijie Networks
     Email: fengchongllly@gmail.com












  Feng                     Expires 19 October 2026               [Page 18]


name: draft-deforth-arp
rev: 00
time: 2026-04-18T11:46:34Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-20T11:46:34Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:50.092665+00:00
source: ietf
title:
  Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification for Machine-Readable Entity Claims

abstract:
  This document specifies the Agentic Reasoning Protocol (ARP), a
     lightweight mechanism for cryptographically binding machine-readable
     entity claims to domain ownership via DNS TXT records.  ARP enables
     AI agents and Retrieval-Augmented Generation (RAG) pipelines to
     verify that structured data published on a domain was authorized by
     the domain owner, preventing narrative injection and entity spoofing
     in generative search systems.

     ARP uses Ed25519 digital signatures [RFC8032], JSON Canonicalization
     Scheme (JCS) [RFC8785], and DNS TXT records to establish a chain of
     trust analogous to DomainKeys Identified Mail (DKIM) [RFC6376] but
     designed specifically for the verification of semantic entity data
     consumed by autonomous AI agents.

full_text:
  Internet Engineering Task Force                               S. Deforth
  Internet-Draft                                                TrueSource
  Intended status: Standards Track                           18 April 2026
  Expires: 20 October 2026


   Agentic Reasoning Protocol (ARP): DNS-Bound Cryptographic Verification
                     for Machine-Readable Entity Claims
                            draft-deforth-arp-00

  Abstract

     This document specifies the Agentic Reasoning Protocol (ARP), a
     lightweight mechanism for cryptographically binding machine-readable
     entity claims to domain ownership via DNS TXT records.  ARP enables
     AI agents and Retrieval-Augmented Generation (RAG) pipelines to
     verify that structured data published on a domain was authorized by
     the domain owner, preventing narrative injection and entity spoofing
     in generative search systems.

     ARP uses Ed25519 digital signatures [RFC8032], JSON Canonicalization
     Scheme (JCS) [RFC8785], and DNS TXT records to establish a chain of
     trust analogous to DomainKeys Identified Mail (DKIM) [RFC6376] but
     designed specifically for the verification of semantic entity data
     consumed by autonomous AI agents.

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

  Copyright Notice

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




  Deforth                  Expires 20 October 2026                [Page 1]


  Internet-Draft                     ARP                        April 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Changes from draft-deforth-arp-00 . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     4.  DNS TXT Record Format . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Record Name . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Record Value  . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Multiple Keys . . . . . . . . . . . . . . . . . . . . . .   7
       4.4.  Key Size Constraints  . . . . . . . . . . . . . . . . . .   7
       4.5.  Cross-Domain Delegation . . . . . . . . . . . . . . . . .   7
     5.  Reasoning Payload . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  File Location and Discovery . . . . . . . . . . . . . . .   8
       5.2.  Required Fields . . . . . . . . . . . . . . . . . . . . .   8
       5.3.  Optional Sections . . . . . . . . . . . . . . . . . . . .   9
     6.  Canonicalization  . . . . . . . . . . . . . . . . . . . . . .  10
     7.  Signing Procedure . . . . . . . . . . . . . . . . . . . . . .  10
     8.  Verification Procedure  . . . . . . . . . . . . . . . . . . .  11
       8.1.  Domain Binding Check  . . . . . . . . . . . . . . . . . .  11
       8.2.  HTTP Redirect Handling  . . . . . . . . . . . . . . . . .  11
       8.3.  Verification Algorithm  . . . . . . . . . . . . . . . . .  11
       8.4.  Verification Result Codes . . . . . . . . . . . . . . . .  12
     9.  Signature Block Format  . . . . . . . . . . . . . . . . . . .  13
     10. Key Rotation  . . . . . . . . . . . . . . . . . . . . . . . .  14
     11. Relationship to Existing Standards  . . . . . . . . . . . . .  14
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
       12.1.  DNS Security . . . . . . . . . . . . . . . . . . . . . .  15
       12.2.  Key Compromise . . . . . . . . . . . . . . . . . . . . .  15
       12.3.  Replay and Staleness . . . . . . . . . . . . . . . . . .  15
       12.4.  Content Truthfulness . . . . . . . . . . . . . . . . . .  16
       12.5.  Narrative Injection without ARP  . . . . . . . . . . . .  16
       12.6.  Cross-Domain Signing . . . . . . . . . . . . . . . . . .  16
       12.7.  Keypair Separation . . . . . . . . . . . . . . . . . . .  16
       12.8.  Domain Signing Policy  . . . . . . . . . . . . . . . . .  17
       12.9.  Alternative Cryptographic Envelopes  . . . . . . . . . .  18
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       13.1.  Well-Known URI Registration  . . . . . . . . . . . . . .  18



  Deforth                  Expires 20 October 2026                [Page 2]


  Internet-Draft                     ARP                        April 2026


       13.2.  Underscored Node Name Registration . . . . . . . . . . .  18
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       14.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Appendix A.  Complete Example . . . . . . . . . . . . . . . . . .  20
       A.1.  DNS TXT Record  . . . . . . . . . . . . . . . . . . . . .  20
       A.2.  Reasoning Payload . . . . . . . . . . . . . . . . . . . .  20
       A.3.  Verification Steps  . . . . . . . . . . . . . . . . . . .  21
     Appendix B.  JSON Schema  . . . . . . . . . . . . . . . . . . . .  22
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

  1.  Introduction

     The proliferation of Large Language Models (LLMs) and Retrieval-
     Augmented Generation (RAG) systems has fundamentally altered how
     information is discovered, synthesized, and presented to users.
     Unlike traditional search engines, which return ranked lists of
     hyperlinks for human evaluation, generative search engines produce
     direct synthesized answers by extracting and compressing data from
     multiple web sources.

     This architectural shift creates a critical trust gap: generative
     engines heavily weight structured data signals (JSON-LD, semantic
     HTML, Schema.org markup) when selecting sources for citation, but
     currently have no mechanism to verify that such structured data was
     actually authorized by the domain owner.  Any actor can publish well-
     formed structured data on any domain they control, potentially
     poisoning the knowledge graph of AI systems with fabricated entity
     claims, false product information, or competitor sabotage.

     The Agentic Reasoning Protocol (ARP) addresses this gap by providing
     a DNS-anchored cryptographic verification mechanism analogous to DKIM
     [RFC6376] for email.  ARP enables any consuming system to verify the
     provenance and integrity of machine-readable entity claims before
     incorporating them into synthesized responses.

  1.1.  Design Goals

     Lightweight  Verification requires only a DNS TXT lookup and a single
        Ed25519 signature verification.  No PKI infrastructure,
        certificate chains, or external services are required.

     DNS-Anchored  Trust is rooted in the existing global DNS
        infrastructure, leveraging the same anchor used by DKIM, SPF, and
        DMARC.

     Agent-Native  The protocol is designed for consumption by autonomous



  Deforth                  Expires 20 October 2026                [Page 3]


  Internet-Draft                     ARP                        April 2026


        AI agents and automated crawlers, not human users.

     Self-Contained  The signed payload and verification metadata are co-
        located in a single JSON file, minimizing the number of network
        requests required for verification.

     Domain-Bound  Entity claims are cryptographically bound to a specific
        domain, preventing cross-domain replay attacks.

     Open  The protocol is fully specified in this document and requires
        no proprietary software or services.

  1.2.  Changes from draft-deforth-arp-00

     *  SECURITY: Canonicalization now excludes only the signature field,
        not the entire _arp_signature block.  This cryptographically binds
        expires_at, signed_at, and dns_selector to the payload, preventing
        zombie payload attacks (Section 6).

     *  SECURITY: Added REQUIRED "domain" field to the payload, binding
        entity claims to a specific origin domain and preventing cross-
        domain replay attacks (Section 5.2).

     *  SECURITY: Removed "dns_record" field from the signature block.
        Verifiers MUST construct the DNS query name from the retrieval
        domain, not from untrusted JSON data (Section 9).

     *  SECURITY: Cross-domain signing now uses DNS CNAME delegation,
        maintaining DNS sovereignty (Section 12.6).

     *  BCP 190: Changed well-known location from /reasoning.json to
        /.well-known/reasoning.json per RFC 8615 (Section 5.1).

     *  IANA: Added registration request for _arp underscored node name
        per RFC 8552 (Section 13).

     *  IANA: Added registration request for "reasoning.json" well-known
        URI suffix per RFC 8615 (Section 13).

     *  NEW: Added CORS requirements for browser-based verifiers
        (Section 5.1).

     *  NEW: Added HTTP redirect handling requirements (Section 8.2).

     *  NEW: Updated key rotation guidance to account for cached payloads
        (Section 10).





  Deforth                  Expires 20 October 2026                [Page 4]


  Internet-Draft                     ARP                        April 2026


     *  NEW: Added discussion of JWS as future envelope option
        (Section 12.7).

     *  NEW: Added keypair separation guidance for multi-protocol
        deployments (Section 12.8).

     *  NEW: Added Domain Signing Policy for downgrade attack protection
        via DNS TXT (Section 12.9).

  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.

     Entity  The brand, organization, person, or concept described by an
        ARP payload.

     Entity Claims  Machine-readable self-attested statements published by
        the entity about itself, including identity metadata, factual
        corrections, domain expertise, and content policies.

     Reasoning Payload  A JSON document containing the entity claims and
        associated verification metadata.  Served at the well-known URL
        path "/.well-known/reasoning.json" on the entity's domain.

     Signer  The party that holds the Ed25519 private key and produces the
        signature.  This SHOULD be the domain owner or an entity
        explicitly authorized by the domain owner via DNS delegation.

     Verifier  Any system that retrieves the reasoning payload and
        validates the signature against the DNS-published public key.
        Typical verifiers include AI agents, RAG pipelines, and search
        engine crawlers.

     DNS Selector  A label used to construct the DNS TXT record name,
        enabling multiple keys on the same domain (e.g., for key rotation
        or multi-tenant configurations).

     Retrieval Domain  The domain from which the verifier originally
        requested the reasoning payload, before any HTTP redirects.  This
        is the authoritative domain for DNS verification.







  Deforth                  Expires 20 October 2026                [Page 5]


  Internet-Draft                     ARP                        April 2026


  3.  Protocol Overview

     The ARP verification flow consists of four phases:

     Phase 1 - Key Registration  The domain owner generates an Ed25519
        keypair [RFC8032] and publishes the public key as a DNS TXT record
        under a well-known subdomain: <selector>._arp.<domain>

     Phase 2 - Payload Construction  The domain owner constructs a
        reasoning payload containing entity claims, identity metadata,
        content policies, and a REQUIRED "domain" field that binds the
        payload to the publishing domain.

     Phase 3 - Signing  The payload is canonicalized using JCS [RFC8785].
        The canonicalization excludes only the "signature" field within
        the _arp_signature block; all other signature metadata
        (expires_at, signed_at, dns_selector) is included in the signed
        data.  The canonical form is signed with the Ed25519 private key.

     Phase 4 - Verification  A consuming AI agent retrieves the reasoning
        payload, confirms the "domain" field matches the retrieval domain,
        extracts the DNS selector, queries the corresponding DNS TXT
        record for the public key, and validates the Ed25519 signature.

  4.  DNS TXT Record Format

  4.1.  Record Name

     The DNS TXT record MUST be published at:

       <selector>._arp.<domain>

     where <selector> is a case-insensitive ASCII string matching the
     pattern [a-zA-Z0-9._-]+ and <domain> is the fully qualified domain
     name of the entity.  The default selector value is "arp", yielding
     the record name:

       arp._arp.example.com

  4.2.  Record Value

     The TXT record value MUST be a semicolon-delimited string of
     tag=value pairs.  The following tags are defined:








  Deforth                  Expires 20 October 2026                [Page 6]


  Internet-Draft                     ARP                        April 2026


          +=====+==========+=======================================+
          | Tag | Required | Description                           |
          +=====+==========+=======================================+
          | v   | REQUIRED | Protocol version.  MUST be "ARP1".    |
          +-----+----------+---------------------------------------+
          | k   | REQUIRED | Key algorithm.  MUST be "ed25519".    |
          +-----+----------+---------------------------------------+
          | p   | REQUIRED | Base64-encoded raw Ed25519 public key |
          |     |          | (32 bytes, 44 characters encoded).    |
          +-----+----------+---------------------------------------+
          | t   | OPTIONAL | Unix timestamp of key publication.    |
          +-----+----------+---------------------------------------+
          | x   | OPTIONAL | Unix timestamp of key expiration.     |
          +-----+----------+---------------------------------------+

                                   Table 1

     Example:

       v=ARP1; k=ed25519; p=MCowBQYDK2VwAyEA...

  4.3.  Multiple Keys

     A domain MAY publish multiple ARP TXT records using different
     selectors (e.g., "arp" and "arp2026q3").  This supports key rotation
     without service interruption.

  4.4.  Key Size Constraints

     Ed25519 public keys are 32 bytes (44 characters in Base64).  This
     fits within the 255-byte DNS TXT record string limit defined in
     [RFC1035] Section 3.3.14.

  4.5.  Cross-Domain Delegation

     When an authorized third party (e.g., a consultancy) signs a
     reasoning payload on behalf of a domain owner, the domain owner MUST
     delegate trust via a DNS CNAME record:

       arp._arp.client.com. CNAME arp._arp.agency.com.

     This maintains the absolute sovereignty of the DNS trust anchor: the
     domain owner explicitly authorizes the delegation, and the verifier
     always queries the retrieval domain's DNS namespace first.  The
     verifier follows the CNAME transparently and retrieves the delegated
     public key.





  Deforth                  Expires 20 October 2026                [Page 7]


  Internet-Draft                     ARP                        April 2026


     This model mirrors DKIM's delegation approach and prevents attackers
     from pointing unsigned JSON fields at arbitrary DNS records.

  5.  Reasoning Payload

  5.1.  File Location and Discovery

     The reasoning payload MUST be served at the well-known URL defined in
     [RFC8615]:

       https://<domain>/.well-known/reasoning.json

     Implementations MAY additionally serve the payload at alternative
     paths provided the well-known URL also exists.  Alternative paths MAY
     be advertised via:

     *  A <link> element in the HTML head: <link rel="reasoning"
        href="/.well-known/reasoning.json">

     *  A reference in the site's /llms.txt file.

     *  A Reasoning-Json directive in robots.txt.

     The file MUST be served with Content-Type: application/json.

     Servers SHOULD include the HTTP header Access-Control-Allow-Origin: *
     when serving the reasoning payload, to enable verification by
     browser-based AI agents, extensions, and verifiable-credential
     wallets that operate under Cross-Origin Resource Sharing (CORS)
     restrictions.

  5.2.  Required Fields

     The reasoning payload MUST contain the following top-level fields:

















  Deforth                  Expires 20 October 2026                [Page 8]


  Internet-Draft                     ARP                        April 2026


       +===============+========+=====================================+
       | Field         | Type   | Description                         |
       +===============+========+=====================================+
       | $schema       | URI    | MUST reference the ARP JSON Schema  |
       |               |        | [ARP-SCHEMA].                       |
       +---------------+--------+-------------------------------------+
       | protocol      | string | MUST be "Agentic Reasoning Protocol |
       |               |        | (ARP)".                             |
       +---------------+--------+-------------------------------------+
       | version       | string | Semver-compatible version string    |
       |               |        | (e.g., "1.2").                      |
       +---------------+--------+-------------------------------------+
       | domain        | string | REQUIRED.  The fully qualified      |
       |               |        | domain name that is authoritative   |
       |               |        | for these entity claims.  Verifiers |
       |               |        | MUST confirm this matches the       |
       |               |        | retrieval domain (Section 8).       |
       +---------------+--------+-------------------------------------+
       | entity        | string | Canonical name of the entity (max   |
       |               |        | 200 chars).                         |
       +---------------+--------+-------------------------------------+
       | entity_claims | object | MUST contain at minimum a           |
       |               |        | "framing_context" string.           |
       +---------------+--------+-------------------------------------+

                                   Table 2

  5.3.  Optional Sections

     The payload MAY include:

     *  *identity:* Brand identity, tagline, core competencies, emotional
        resonance attributes, and disambiguation entries
        ("not_to_be_confused_with").

     *  *corrections:* Verified factual corrections for known AI
        hallucinations about this entity, each with trigger_topic,
        verified_fact, evidence_url, and epistemic_scope.

     *  *verification:* Audit metadata including auditor identity and
        timestamps.

     *  *authority:* Trust signals including Wikipedia, Wikidata,
        LinkedIn, Crunchbase URIs, awards, and certifications.

     *  *content_policy:* AI training permissions (allowed, allowed-with-
        attribution, disallowed, conditional), citation requirements, and
        verification contact.



  Deforth                  Expires 20 October 2026                [Page 9]


  Internet-Draft                     ARP                        April 2026


     *  *diagnostics:* RAG pipeline telemetry tokens for ingestion
        auditing, with transparency statement.

  6.  Canonicalization

     Before signing, the payload MUST be canonicalized according to the
     JSON Canonicalization Scheme (JCS) as specified in [RFC8785].

     Only the "signature" field within the _arp_signature block MUST be
     excluded from canonicalization.  All other fields in _arp_signature
     (algorithm, dns_selector, canonicalization, signed_at, expires_at)
     are included in the signed data, cryptographically binding the
     signature metadata to the payload.

     Implementations MUST:

     1.  Deep-copy the payload object.

     2.  Remove ONLY the "signature" key from the _arp_signature object in
         the copy.  All other _arp_signature fields MUST remain.

     3.  Serialize the modified copy using JCS [RFC8785]: keys sorted
         lexicographically, no whitespace, Unicode normalized per RFC 8785
         Section 3.2.2.2.

     4.  Encode the result as UTF-8 bytes.

     This approach prevents "zombie payload" attacks where an attacker
     modifies unauthenticated metadata fields (e.g., extending expires_at)
     while keeping the original signature valid.

  7.  Signing Procedure

     Given a complete reasoning payload and an Ed25519 private key (32
     bytes), the signing procedure is:

     1.   Set payload._arp_signature.algorithm = "Ed25519"

     2.   Set payload._arp_signature.dns_selector = selector

     3.   Set payload._arp_signature.canonicalization = "jcs-rfc8785"

     4.   Set payload._arp_signature.signed_at = current UTC timestamp
          (ISO 8601)

     5.   Set payload._arp_signature.expires_at = signed_at + TTL

     6.   payload_copy = deep_copy(payload)



  Deforth                  Expires 20 October 2026               [Page 10]


  Internet-Draft                     ARP                        April 2026


     7.   Remove ONLY "signature" from payload_copy._arp_signature

     8.   canonical = JCS_Canonicalize(payload_copy)

     9.   canonical_bytes = UTF8_Encode(canonical)

     10.  signature_bytes = Ed25519_Sign(private_key, canonical_bytes)

     11.  signature_b64url = Base64url_Encode(signature_bytes) per
          [RFC4648] Section 5, no padding

     12.  Set payload._arp_signature.signature = signature_b64url

     The RECOMMENDED signature TTL is 90 days.

  8.  Verification Procedure

  8.1.  Domain Binding Check

     Before any cryptographic verification, the verifier MUST confirm that
     the "domain" field in the payload matches the domain from which the
     payload was originally requested (the retrieval domain).  If the
     values do not match, verification MUST fail with
     FAIL_DOMAIN_MISMATCH.

  8.2.  HTTP Redirect Handling

     When the verifier encounters HTTP redirects (301, 302, 307, 308)
     while retrieving the reasoning payload, the verifier MUST base the
     DNS query and domain-binding check on the original requested domain,
     NOT the final domain in the redirect chain.  This prevents
     verification bypass via open redirect vulnerabilities.

  8.3.  Verification Algorithm

     The complete verification algorithm is:

     1.   Record the original retrieval domain before following any
          redirects.

     2.   Retrieve the payload from the well-known URL.

     3.   Extract sig_block = payload._arp_signature

     4.   Validate sig_block contains all REQUIRED fields (Section 9)

     5.   Check: payload.domain == retrieval_domain.  If mismatch: FAIL
          (FAIL_DOMAIN_MISMATCH)



  Deforth                  Expires 20 October 2026               [Page 11]


  Internet-Draft                     ARP                        April 2026


     6.   Check: sig_block.expires_at > current_time.  If expired: FAIL
          (FAIL_EXPIRED)

     7.   Construct DNS name: sig_block.dns_selector + "._arp." +
          retrieval_domain

     8.   Query DNS TXT record at constructed name

     9.   Parse TXT record value; extract p= tag (public key).  If no
          record: FAIL (FAIL_NO_DNS)

     10.  payload_copy = deep_copy(payload)

     11.  Remove ONLY "signature" from payload_copy._arp_signature

     12.  canonical = JCS_Canonicalize(payload_copy)

     13.  canonical_bytes = UTF8_Encode(canonical)

     14.  signature_bytes = Base64url_Decode(sig_block.signature)

     15.  public_key_bytes = Base64_Decode(dns_public_key_value)

     16.  result = Ed25519_Verify(public_key_bytes, signature_bytes,
          canonical_bytes)

     17.  If result == valid: PASS.  If invalid: FAIL (FAIL_INVALID)

  8.4.  Verification Result Codes

         +======================+===================================+
         | Code                 | Description                       |
         +======================+===================================+
         | PASS                 | Domain matches, DNS key found,    |
         |                      | signature valid, not expired.     |
         +----------------------+-----------------------------------+
         | FAIL_NO_ARP          | No _arp_signature block in        |
         |                      | payload.                          |
         +----------------------+-----------------------------------+
         | FAIL_DOMAIN_MISMATCH | The "domain" field does not match |
         |                      | the retrieval domain.             |
         +----------------------+-----------------------------------+
         | FAIL_NO_DNS          | No DNS TXT record at              |
         |                      | selector._arp.domain.             |
         +----------------------+-----------------------------------+
         | FAIL_EXPIRED         | Signature expired (expires_at <   |
         |                      | current time).                    |
         +----------------------+-----------------------------------+



  Deforth                  Expires 20 October 2026               [Page 12]


  Internet-Draft                     ARP                        April 2026


         | FAIL_INVALID         | Ed25519 signature verification    |
         |                      | failed.                           |
         +----------------------+-----------------------------------+
         | FAIL_UNSIGNED_POLICY | No _arp_signature present, but    |
         |                      | domain publishes p=reject policy. |
         +----------------------+-----------------------------------+

                                   Table 3

  9.  Signature Block Format

     The _arp_signature block is a JSON object embedded in the reasoning
     payload with the following fields:

     +==================+==========+========+============================+
     | Field            | Required | Type   | Description                |
     +==================+==========+========+============================+
     | algorithm        | REQUIRED | string | MUST be "Ed25519".         |
     +------------------+----------+--------+----------------------------+
     | dns_selector     | REQUIRED | string | Selector label for DNS     |
     |                  |          |        | TXT lookup (max 50         |
     |                  |          |        | chars).                    |
     +------------------+----------+--------+----------------------------+
     | canonicalization | REQUIRED | string | MUST be "jcs-rfc8785".     |
     +------------------+----------+--------+----------------------------+
     | signed_at        | REQUIRED | string | ISO 8601 UTC timestamp     |
     |                  |          |        | of signing.                |
     +------------------+----------+--------+----------------------------+
     | expires_at       | REQUIRED | string | ISO 8601 UTC               |
     |                  |          |        | expiration timestamp.      |
     |                  |          |        | RECOMMENDED TTL: 90        |
     |                  |          |        | days.                      |
     +------------------+----------+--------+----------------------------+
     | signature        | REQUIRED | string | Base64url-encoded          |
     |                  |          |        | Ed25519 signature (86      |
     |                  |          |        | chars without              |
     |                  |          |        | padding).  This is the     |
     |                  |          |        | ONLY field excluded        |
     |                  |          |        | from canonicalization.     |
     +------------------+----------+--------+----------------------------+

                                    Table 4

     Note: The "dns_record" field present in draft-deforth-arp-00 has been
     removed.  Verifiers MUST construct the DNS query name from the
     retrieval domain and dns_selector, never from untrusted JSON data.





  Deforth                  Expires 20 October 2026               [Page 13]


  Internet-Draft                     ARP                        April 2026


  10.  Key Rotation

     To rotate keys without service disruption:

     1.  Generate a new Ed25519 keypair.

     2.  Publish the new public key under a new DNS selector (e.g.,
         "arp2026q3._arp.example.com").

     3.  Re-sign the reasoning payload with the new key, updating
         dns_selector accordingly.

     4.  Keep the old DNS TXT record published until the expires_at
         timestamp of the last payload signed with the old key has passed.
         This prevents verification failures for agents holding cached
         copies of the previous payload.

     5.  After the old payload's expires_at date has passed, remove the
         old DNS TXT record.

     Verifiers SHOULD support checking multiple selectors.  The
     RECOMMENDED rotation interval is 90 days, aligned with the default
     signature TTL.

  11.  Relationship to Existing Standards

      +==============+==================================================+
      | Standard     | Relationship to ARP                              |
      +==============+==================================================+
      | DKIM         | ARP adapts the DNS-anchored key publication and  |
      | [RFC6376]    | CNAME delegation models from DKIM for entity     |
      |              | claim verification rather than email             |
      |              | authentication.                                  |
      +--------------+--------------------------------------------------+
      | C2PA v2.2    | C2PA verifies media provenance via embedded      |
      | [C2PA]       | manifests.  ARP verifies textual entity claim    |
      |              | provenance via DNS.  Complementary, non-         |
      |              | overlapping scope.                               |
      +--------------+--------------------------------------------------+
      | W3C          | VCs require an Issuer-Holder-Verifier ecosystem. |
      | Verifiable   | ARP provides a simpler two-party (Publisher-     |
      | Credentials  | Verifier) model for public entity claims.        |
      | 2.0 [W3C-VC] |                                                  |
      +--------------+--------------------------------------------------+
      | AIVS v1.0    | AIVS verifies what an agent DID (session/action  |
      | [AIVS] (W3C  | integrity).  ARP verifies what an agent READS    |
      | Community    | (content provenance).  Complementary: AIVS audit |
      | Group)       | logs plus ARP content verification form a full   |



  Deforth                  Expires 20 October 2026               [Page 14]


  Internet-Draft                     ARP                        April 2026


      |              | end-to-end trust chain for agentic systems.      |
      +--------------+--------------------------------------------------+
      | IETF SCITT   | ARP signed payloads could be registered as SCITT |
      |              | transparency statements for append-only          |
      |              | auditability.                                    |
      +--------------+--------------------------------------------------+
      | Schema.org   | Schema.org describes entity attributes.  ARP     |
      |              | cryptographically binds those attributes to      |
      |              | verified domain ownership.                       |
      +--------------+--------------------------------------------------+

                                    Table 5

  12.  Security Considerations

  12.1.  DNS Security

     ARP's trust anchor is the DNS TXT record.  Without DNSSEC, an
     attacker who can poison DNS responses can substitute a fraudulent
     public key.  Implementations SHOULD use DNSSEC-validated resolvers
     where available.  Implementations SHOULD also cache DNS responses
     according to the record's TTL to reduce lookup frequency.

  12.2.  Key Compromise

     If an Ed25519 private key is compromised, the attacker can sign
     arbitrary payloads that will validate against the DNS-published key.
     Domain owners MUST:

     *  Store private keys with restricted file permissions (0600).

     *  Rotate keys immediately on suspected compromise.

     *  Use the expires_at field to limit the validity window of any
        signature.

     *  Consider hardware security modules (HSMs) or secure enclaves for
        high-value domains.

  12.3.  Replay and Staleness

     Verifiers SHOULD check the expires_at timestamp and reject expired
     signatures.  The RECOMMENDED TTL is 90 days.  Verifiers MAY also
     check the signed_at timestamp against the HTTP Last-Modified header
     to detect stale payloads served from cache.






  Deforth                  Expires 20 October 2026               [Page 15]


  Internet-Draft                     ARP                        April 2026


  12.4.  Content Truthfulness

     ARP verifies PROVENANCE (who authorized the data), not TRUTH (whether
     the data is factually correct).  A domain owner can sign factually
     incorrect claims that will pass ARP verification.  AI systems
     consuming ARP-verified payloads SHOULD still cross-reference entity
     claims against independent sources.  The epistemic_scope field in
     entity claims is designed to help AI systems distinguish between
     publicly verifiable facts and proprietary internal claims.

  12.5.  Narrative Injection without ARP

     Without ARP verification, any actor can publish reasoning payloads
     containing arbitrary entity claims on any domain they control.
     Regulatory frameworks such as the EU AI Act [EU-AI-ACT] Article 19
     require audit trails for high-risk AI systems but do not prescribe
     verification formats for ingested content.  Empirical research has
     demonstrated that RAG systems will cite well-structured entity claims
     from previously unknown domains as primary sources within 24 hours,
     regardless of domain history, traffic, or backlinks.  ARP provides
     the verification layer that allows consuming systems to differentiate
     between authorized and unauthorized entity claims.

  12.6.  Cross-Domain Signing

     Cross-domain signing MUST use the DNS CNAME delegation model
     described in Section 4.5.  The verifier always queries the retrieval
     domain's DNS namespace and follows CNAME records transparently.  This
     maintains the absolute sovereignty of the DNS trust anchor and
     prevents attacks where unsigned JSON fields are used to redirect
     trust to attacker-controlled DNS.

     Consuming systems MAY choose to treat CNAME-delegated signatures with
     lower confidence than direct (same-domain) signatures.

  12.7.  Keypair Separation

     When ARP is deployed alongside other verification systems that also
     use Ed25519 (e.g., AIVS [AIVS] for agent session integrity),
     implementations MUST NOT reuse the same Ed25519 keypair across
     different verification functions.  Sharing a single keypair between
     content signing (ARP) and session signing (AIVS) creates a single
     point of failure: compromise of one key compromises both trust
     domains.







  Deforth                  Expires 20 October 2026               [Page 16]


  Internet-Draft                     ARP                        April 2026


     Implementations SHOULD use separate Ed25519 keypairs for each trust
     function.  Where a unified identity anchor is desired,
     implementations MAY use a DID Document (e.g., did:web) to bind
     multiple function-specific public keys to a single domain identity:

     *  An "assertionMethod" key for ARP content provenance verification.

     *  An "authentication" key for agent session signing (e.g., AIVS).

     This approach preserves key isolation while enabling cross-protocol
     identity resolution.  The DID Document itself can be anchored to the
     domain via the did:web method, which resolves to /.well-known/
     did.json on the entity's domain.

  12.8.  Domain Signing Policy

     To protect against downgrade attacks — where an attacker strips the
     _arp_signature block from a signed file and modifies the content —
     domain owners MAY publish a Domain Signing Policy via DNS TXT record
     at the bare _arp node:

       _arp.example.com.  IN  TXT  "v=ARP1; p=reject"

     The following policy values are defined:

           +========+==========+===================================+
           | Policy | Value    | Meaning                           |
           +========+==========+===================================+
           | none   | Default  | No enforcement; unsigned files    |
           |        |          | are treated normally.             |
           +--------+----------+-----------------------------------+
           | warn   | Advisory | Verifiers SHOULD log a warning if |
           |        |          | the payload is unsigned.          |
           +--------+----------+-----------------------------------+
           | reject | Strict   | Verifiers MUST treat unsigned     |
           |        |          | payloads as FAIL_UNSIGNED_POLICY. |
           +--------+----------+-----------------------------------+

                                    Table 6

     Verification flow for unsigned payloads:

     1.  Verifier encounters a reasoning payload without an _arp_signature
         block.

     2.  Verifier queries the DNS TXT record at _arp.<retrieval_domain>.





  Deforth                  Expires 20 October 2026               [Page 17]


  Internet-Draft                     ARP                        April 2026


     3.  If a record with p=reject is present, the verifier MUST reject
         the unsigned payload (FAIL_UNSIGNED_POLICY).

     4.  If no policy record exists, the verifier treats the payload as
         unsigned (no cryptographic trust, but not rejected).

     This follows the same progressive enforcement model as DMARC
     (p=reject) [RFC6376] and HTTP Strict Transport Security (HSTS).

  12.9.  Alternative Cryptographic Envelopes

     This specification defines a custom _arp_signature block for
     simplicity and clarity.  Future versions MAY consider adopting JSON
     Web Signature (JWS) [RFC7515] with the Unencoded Payload Option
     [RFC7797] as an alternative envelope format.  This would provide
     cryptographic agility and enable use of battle-tested standard
     libraries, while preserving the human-readable cleartext JSON payload
     that JCS canonicalization achieves.  The dns_selector, expires_at,
     and signed_at fields would map to the JWS Protected Header.

  13.  IANA Considerations

  13.1.  Well-Known URI Registration

     This document requests IANA to register the following well-known URI
     suffix in the "Well-Known URIs" registry established by [RFC8615]:

     URI Suffix  reasoning.json

     Change Controller  IETF

     Reference  Section 5.1 of [this document]

     Status  permanent

  13.2.  Underscored Node Name Registration

     This document requests IANA to register the following entry in the
     "Underscored and Globally Scoped DNS Node Names" registry established
     by [RFC8552]:

     RR Type  TXT

     _NODE NAME  _arp

     Reference  Section 4.1 of [this document]

  14.  References



  Deforth                  Expires 20 October 2026               [Page 18]


  Internet-Draft                     ARP                        April 2026


  14.1.  Normative References

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/info/rfc1035>.

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

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/info/rfc4648>.

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

     [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
                <https://www.rfc-editor.org/info/rfc8552>.

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

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

  14.2.  Informative References

     [AIVS]     Stone, B., "Agentic Integrity Verification Specification
                v1.0", W3C Community Group Draft, March 2026,
                <https://github.com/bkauto3/Conduit/blob/main/spec/
                AIVS.md>.

     [ARP-SCHEMA]
                Deforth, S., "ARP v1.2 JSON Schema", April 2026,
                <https://arp-protocol.org/schema/v1.2.json>.



  Deforth                  Expires 20 October 2026               [Page 19]


  Internet-Draft                     ARP                        April 2026


     [C2PA]     Coalition for Content Provenance and Authenticity, "C2PA
                Technical Specification v2.2", 2025,
                <https://c2pa.org/specifications/specifications/2.2/specs/
                C2PA_Specification.html>.

     [EU-AI-ACT]
                European Parliament, "Regulation (EU) 2024/1689 laying
                down harmonised rules on artificial intelligence", 2024.

     [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
                "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
                RFC 6376, DOI 10.17487/RFC6376, September 2011,
                <https://www.rfc-editor.org/info/rfc6376>.

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

     [RFC7797]  Jones, M., "JSON Web Signature (JWS) Unencoded Payload
                Option", RFC 7797, DOI 10.17487/RFC7797, February 2016,
                <https://www.rfc-editor.org/info/rfc7797>.

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

  Appendix A.  Complete Example

  A.1.  DNS TXT Record

     arp._arp.example.com. 3600 IN TXT (
       "v=ARP1; k=ed25519; "
       "p=MCowBQYDK2VwAyEA5d7jb7bkTVk5"
       "YQ4nFmYY7ClpCddGdSRJkGb3ELWuos=")

  A.2.  Reasoning Payload















  Deforth                  Expires 20 October 2026               [Page 20]


  Internet-Draft                     ARP                        April 2026


     {
       "$schema": "https://arp-protocol.org/schema/v1.2.json",
       "protocol": "Agentic Reasoning Protocol (ARP)",
       "version": "1.2",
       "domain": "example.com",
       "entity": "Example Corp",
       "entity_claims": {
         "framing_context": "Example Corp is a technology ..."
       },
       "content_policy": {
         "ai_training": "allowed-with-attribution",
         "citation_required": true
       },
       "_arp_signature": {
         "algorithm": "Ed25519",
         "dns_selector": "arp",
         "canonicalization": "jcs-rfc8785",
         "signed_at": "2026-04-06T14:00:00Z",
         "expires_at": "2026-07-05T14:00:00Z",
         "signature": "P1lCPaHn_WLXdidBfxLXqBBid1G..."
       }
     }

  A.3.  Verification Steps

     1.   Record retrieval domain: example.com

     2.   Retrieve https://example.com/.well-known/reasoning.json (follow
          redirects, keep original domain)

     3.   Check: payload.domain == "example.com" (PASS)

     4.   Check: expires_at > now (PASS)

     5.   Extract dns_selector = "arp" from _arp_signature

     6.   Query DNS TXT at: arp._arp.example.com

     7.   Parse p= tag to obtain public key bytes

     8.   Copy payload, remove ONLY _arp_signature.signature

     9.   JCS-canonicalize the modified copy

     10.  Ed25519_Verify(public_key, signature, canonical_bytes)

     11.  Result: PASS




  Deforth                  Expires 20 October 2026               [Page 21]


  Internet-Draft                     ARP                        April 2026


  Appendix B.  JSON Schema

     The normative JSON Schema for ARP v1.2 payloads is published at:

       https://arp-protocol.org/schema/v1.2.json

     The schema defines validation rules for all required and optional
     fields, including type constraints, maximum lengths, enumerated
     values, and format requirements.  Implementations SHOULD validate
     payloads against the schema before signing and before processing
     entity claims.

  Acknowledgements

     The author thanks the W3C Agentic Integrity Verification
     Specification Community Group for their complementary work on agent
     session integrity, and the broader Generative Engine Optimization
     (GEO) community for empirical validation of the content provenance
     gap that ARP addresses.

     The security improvements in this revision were informed by detailed
     technical review highlighting the signature metadata exclusion flaw
     and cross-domain replay vulnerability in the initial draft.

     The keypair separation guidance was informed by feedback from Ben
     Stone (SwarmSync.AI) during AIVS interoperability discussions,
     highlighting the single-point-of-failure risk of shared Ed25519
     keypairs across verification protocols.

  Author's Address

     Sascha Deforth
     TrueSource
     Duesseldorf
     Germany
     Email: hello@truesource.studio
     URI:   https://arp-protocol.org














  Deforth                  Expires 20 October 2026               [Page 22]


name: draft-fluid-fadp
rev: 01
time: 2026-04-23T09:27:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-25T09:27:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Other AI/agent"]
tags: []
fetched_at: 2026-05-22T09:24:50.092674+00:00
source: ietf
title:
  Fluid Agentic DeFi Protocol (FADP/1.0): HTTP-Native Micropayment Authentication for Autonomous AI Agents

abstract:
  This document defines the Fluid Agentic DeFi Protocol (FADP), version
     1.0.  FADP is an application-layer protocol layered atop HTTP that
     enables autonomous AI agents to pay for access to web resources using
     on-chain cryptocurrency transfers, with cryptographic proof of
     payment embedded directly in HTTP headers.

     FADP extends HTTP 402 (Payment Required) with two new header fields:
     X-FADP-Required, which a server uses to communicate payment terms to
     an agent, and X-FADP-Proof, which an agent uses to supply a
     verifiable on-chain payment receipt.  A nonce-challenge mechanism
     prevents proof replay.  An optional verification endpoint allows
     third-party on-chain confirmation without requiring the verifying
     party to run blockchain infrastructure.

     FADP is designed for agent-to-server and agent-to-agent payment flows
     operating at sub-dollar granularity (micropayments), where credit-
     card or OAuth-based billing is impractical.  The reference
     implementation targets USDC on Base (an Ethereum Layer 2), though the
     protocol is token- and chain-agnostic.

full_text:
  Independent Submission                                          A. Ganji
  Internet-Draft                               Independent Researcher
  Intended status: Informational                         23 April 2026
  Expires: 23 October 2026


      Fluid Agentic DeFi Protocol (FADP/1.0): HTTP-Native Micropayment
                  Authentication for Autonomous AI Agents
                            draft-fluid-fadp-01

  Abstract

     This document defines the Fluid Agentic DeFi Protocol (FADP), version
     1.0.  FADP is an application-layer protocol layered atop HTTP that
     enables autonomous AI agents to pay for access to web resources using
     on-chain cryptocurrency transfers, with cryptographic proof of
     payment embedded directly in HTTP headers.

     FADP extends HTTP 402 (Payment Required) with two new header fields:
     X-FADP-Required, which a server uses to communicate payment terms to
     an agent, and X-FADP-Proof, which an agent uses to supply a
     verifiable on-chain payment receipt.  A nonce-challenge mechanism
     prevents proof replay.  An optional verification endpoint allows
     third-party on-chain confirmation without requiring the verifying
     party to run blockchain infrastructure.

     FADP is designed for agent-to-server and agent-to-agent payment flows
     operating at sub-dollar granularity (micropayments), where credit-
     card or OAuth-based billing is impractical.  The reference
     implementation targets USDC on Base (an Ethereum Layer 2), though the
     protocol is token- and chain-agnostic.

  About This Document

     This note is to be removed before publishing as an RFC.

     This document is submitted as an independent submission to the IETF
     datatracker.  It does not represent the consensus of any IETF working
     group.  The author welcomes discussion on the GitHub repository
     (https://github.com/fluidbase9/fadp) and via the contact address
     above.

  Status of This Memo

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





  Ganji                    Expires 23 October 2026                [Page 1]


  Internet-Draft                    FADP                        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 23 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.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Header Fields . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  X-FADP-Required . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  X-FADP-Proof  . . . . . . . . . . . . . . . . . . . . . .   8
     5.  Verification Endpoint . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Verification Request  . . . . . . . . . . . . . . . . . .   9
       5.2.  Verification Response . . . . . . . . . . . . . . . . . .   9
     6.  Server Behavior . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Issuing Payment Challenges  . . . . . . . . . . . . . . .  10
       6.2.  Verifying Payment Proofs  . . . . . . . . . . . . . . . .  11
     7.  Agent Behavior  . . . . . . . . . . . . . . . . . . . . . . .  11
     8.  Error Responses . . . . . . . . . . . . . . . . . . . . . . .  12
     9.  Chain Identifiers . . . . . . . . . . . . . . . . . . . . . .  13
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  14
       10.1.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  14
       10.2.  Overpayment  . . . . . . . . . . . . . . . . . . . . . .  15
       10.3.  Front-Running and Transaction Interception . . . . . . .  15
       10.4.  Verification Service Trust . . . . . . . . . . . . . . .  15
       10.5.  Blockchain Finality  . . . . . . . . . . . . . . . . . .  16



  Ganji                    Expires 23 October 2026                [Page 2]


  Internet-Draft                    FADP                        April 2026


       10.6.  Nonce Store Exhaustion . . . . . . . . . . . . . . . . .  16
       10.7.  Header Injection . . . . . . . . . . . . . . . . . . . .  16
       10.8.  Transport Security . . . . . . . . . . . . . . . . . . .  16
       10.9.  Agent Spending Controls  . . . . . . . . . . . . . . . .  16
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
       11.1.  HTTP Header Field Registration . . . . . . . . . . . . .  17
       11.2.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  17
     12. Implementation Notes  . . . . . . . . . . . . . . . . . . . .  17
       12.1.  Reference Implementations  . . . . . . . . . . . . . . .  17
       12.2.  Nonce Storage in Distributed Deployments . . . . . . . .  18
       12.3.  Amount Precision . . . . . . . . . . . . . . . . . . . .  18
       12.4.  Cross-Origin Resource Sharing  . . . . . . . . . . . . .  18
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       13.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Appendix A: Complete Exchange Example . . . . . . . . . . . . . .  19
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     Autonomous AI agents—software processes that browse the web, call
     APIs, and complete tasks on behalf of users without per-action human
     approval—are an emerging class of HTTP client.  Unlike human-operated
     browsers, these agents cannot authenticate themselves to paid
     services via credit-card billing flows, OAuth consent screens, or
     similar interactive mechanisms.  The practical result is that most
     commercial APIs are inaccessible to fully autonomous agents, forcing
     developers to hard-code credentials that cannot be scoped, limited,
     or revoked per-task.

     HTTP has carried a 402 (Payment Required) status code since RFC 7231
     [RFC7231], but that specification explicitly reserved the code for
     future use and defined no standard payment handshake.  Numerous
     proprietary schemes have since emerged, but none has achieved broad
     adoption, and none addresses the specific needs of machine-to-machine
     micropayments at the scale and frequency that autonomous agents
     require.

     Blockchain-based stablecoins—particularly USDC on high-throughput,
     low-cost Layer 2 networks—have made sub-cent on-chain transfers
     economically viable for the first time.  A transaction settling 0.001
     USDC (one-tenth of one cent) on Base costs roughly USD 0.0001 in gas,
     making per-request billing at very fine granularity practical.

     FADP defines a minimal, HTTP-native handshake that combines these two
     properties: the well-understood 402 status code as a payment prompt,
     and an on-chain transfer as the payment instrument.  The protocol



  Ganji                    Expires 23 October 2026                [Page 3]


  Internet-Draft                    FADP                        April 2026


     requires no browser, no OAuth server, no API-key issuance flow, and
     no pre-existing billing relationship between the agent and the
     server.  An agent that has a funded wallet and a Fluid agent key can
     pay for any FADP-gated resource it discovers, at runtime, without
     human intervention—provided the requested amount is within the
     agent's pre-configured spending limit.

  1.1.  Design Goals

     *  *HTTP-native*: the entire payment handshake is expressed in
        standard HTTP status codes and header fields.  No new transport
        layer is required.

     *  *Stateless from the agent's perspective*: the server supplies all
        information needed to pay in the 402 response; the agent needs no
        prior knowledge of the server's payment address or preferred
        token.

     *  *Replay-safe*: a nonce bound to each payment challenge ensures
        that a valid payment proof cannot be reused across requests or
        across sessions.

     *  *Verifier-decoupled*: servers can delegate on-chain verification
        to a third-party service, removing the need to run or maintain
        blockchain node infrastructure.

     *  *Token- and chain-agnostic*: while USDC on Base is the reference
        currency, FADP carries token and chain identifiers in every
        message and imposes no restriction on supported assets.

     *  *Human-in-the-loop friendly*: spending limits and out-of-band
        approval flows are outside protocol scope but are natural
        affordances of agent runtime environments built on FADP.

  1.2.  Non-Goals

     *  FADP does not specify how agents acquire, store, or rotate their
        wallet credentials.

     *  FADP does not define a streaming or subscription billing model.
        Each request-response pair is an independent payment event.

     *  FADP does not mandate a specific blockchain or token.

     *  FADP does not replace existing API authentication schemes; it may
        operate alongside them.





  Ganji                    Expires 23 October 2026                [Page 4]


  Internet-Draft                    FADP                        April 2026


  2.  Terminology

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

     Agent  An autonomous software process that issues HTTP requests on
        behalf of a user or another automated system, without interactive
        human approval for each request.

     Server  An HTTP origin server that gates one or more resources behind
        a FADP payment requirement.

     Payment Challenge  A 402 HTTP response carrying an X-FADP-Required
        header that specifies the payment terms the agent must satisfy.

     Payment Proof  A JSON object carried in the X-FADP-Proof header of a
        subsequent request, asserting that the agent has executed an on-
        chain transfer matching the payment challenge.

     Nonce  A cryptographically random, single-use token embedded in a
        payment challenge.  The server MUST reject any proof whose nonce
        has already been consumed or has expired.

     Verification Service  An HTTPS endpoint that accepts a payment proof
        and independently confirms the corresponding on-chain transaction.
        May be operated by a third party.

     On-chain Transfer  A transaction recorded in a distributed ledger
        (blockchain) that transfers a specified amount of a digital asset
        from one address to another.

     Transaction Hash (txHash)  A unique identifier for an on-chain
        transfer, derived from the cryptographic hash of the transaction
        data.  Immutable once the transaction is finalized.

  3.  Protocol Overview

     A FADP interaction consists of three HTTP exchanges:

     1.  *Initial Request*: The agent sends an ordinary HTTP request to a
         protected resource, without any payment header.

     2.  *Payment Challenge*: The server responds with HTTP 402 and an X-
         FADP-Required header describing the payment terms.  The agent
         executes an on-chain transfer matching those terms.



  Ganji                    Expires 23 October 2026                [Page 5]


  Internet-Draft                    FADP                        April 2026


     3.  *Authenticated Request*: The agent repeats the original request,
         adding an X-FADP-Proof header that references the completed on-
         chain transfer and the challenge nonce.  The server verifies the
         proof and, if valid, fulfills the request.

     Agent                         Server                    Verifier
       |                              |                          |
       |  GET /resource               |                          |
       |----------------------------->|                          |
       |                              |                          |
       |  402 Payment Required        |                          |
       |  X-FADP-Required: {          |                          |
       |    version, amount, token,   |                          |
       |    chain, payTo, nonce,      |                          |
       |    expires, verifyUrl }      |                          |
       |<-----------------------------|                          |
       |                              |                          |
       |  [Agent executes on-chain transfer to payTo]            |
       |  [Receives txHash from blockchain]                      |
       |                              |                          |
       |  GET /resource               |                          |
       |  X-FADP-Proof: {             |                          |
       |    txHash, nonce, timestamp }|                          |
       |----------------------------->|                          |
       |                              |  POST verifyUrl          |
       |                              |  { txHash, payTo,        |
       |                              |    amount, token,        |
       |                              |    chain, nonce }        |
       |                              |------------------------->|
       |                              |                          |
       |                              |  { verified: true,       |
       |                              |    from, to, amount }    |
       |                              |<-------------------------|
       |                              |                          |
       |  200 OK + resource data      |                          |
       |<-----------------------------|                          |

                         Figure 1: FADP Full Handshake

  4.  Header Fields

  4.1.  X-FADP-Required

     The X-FADP-Required response header field is sent by the server in a
     402 response.  Its value is a JSON object with the following members:

     version  REQUIRED.  String.  MUST be "1.0" for this version of the
        protocol.



  Ganji                    Expires 23 October 2026                [Page 6]


  Internet-Draft                    FADP                        April 2026


     amount  REQUIRED.  String.  The amount of the specified token that
        the agent MUST transfer, expressed as a decimal number (e.g.,
        "0.001").  The server SHOULD use the minimal number of decimal
        places necessary to avoid ambiguity.

     token  REQUIRED.  String.  The symbol of the digital asset to be
        transferred (e.g., "USDC", "ETH", "USDT").  The symbol SHOULD
        conform to the canonical symbol registered with the issuer or a
        well-known token list.

     chain  REQUIRED.  String.  The identifier of the blockchain network
        on which the transfer must be executed.  Registered values include
        "base" (Base Mainnet), "ethereum" (Ethereum Mainnet), and "solana"
        (Solana Mainnet).  Implementors MAY define additional chain
        identifiers using reverse-DNS notation to avoid collision.

     payTo  REQUIRED.  String.  The blockchain address of the server
        operator's wallet.  For EVM-compatible chains, this MUST be a
        checksummed Ethereum address (EIP-55).

     nonce  REQUIRED.  String.  A cryptographically random, single-use
        token generated by the server for this payment challenge.  The
        server MUST ensure that each nonce is unique across all active
        challenges.  The nonce MUST be at least 16 bytes of entropy,
        encoded as a lowercase hexadecimal string (minimum 32 characters).

     expires  REQUIRED.  Number.  A Unix timestamp (seconds since epoch)
        indicating when this payment challenge expires.  The server MUST
        reject proofs referencing a nonce whose expiry has passed.  The
        RECOMMENDED default TTL is 300 seconds (5 minutes).

     description  OPTIONAL.  String.  A human-readable description of the
        resource or service being paid for (e.g., "Premium market data
        API").  Intended for display in agent UIs and transaction logs.

     verifyUrl  OPTIONAL.  String.  An HTTPS URL identifying the
        verification service the server will use to confirm payment
        proofs.  If omitted, the default is
        https://fluidnative.com/v1/fadp/verify.  Servers operating their
        own verification infrastructure SHOULD set this field.

     Example value (formatted for readability; actual header value MUST be
     a single-line JSON string):








  Ganji                    Expires 23 October 2026                [Page 7]


  Internet-Draft                    FADP                        April 2026


     {
       "version": "1.0",
       "amount": "0.001",
       "token": "USDC",
       "chain": "base",
       "payTo": "0xAbCd1234AbCd1234AbCd1234AbCd1234AbCd1234",
       "nonce": "a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5",
       "expires": 1745001234,
       "description": "GPT-4o inference via OpenRouter proxy",
       "verifyUrl": "https://fluidnative.com/v1/fadp/verify"
     }

  4.2.  X-FADP-Proof

     The X-FADP-Proof request header field is sent by the agent in the
     authenticated request.  Its value is a JSON object with the following
     members:

     txHash  REQUIRED.  String.  The transaction hash of the on-chain
        transfer executed by the agent in response to the payment
        challenge.  For EVM-compatible chains, this is a 0x-prefixed
        32-byte hex string.

     nonce  REQUIRED.  String.  The nonce value copied verbatim from the
        X-FADP-Required header of the payment challenge to which this
        proof responds.  The server MUST verify that this nonce matches a
        known, unexpired, unconsumed challenge.

     timestamp  REQUIRED.  Number.  A Unix timestamp (seconds since epoch)
        representing the time at which the agent assembled this proof.
        The server SHOULD reject proofs where |currentTime - timestamp| >
        300 seconds.

     agentKeyPrefix  OPTIONAL.  String.  A non-sensitive prefix of the
        agent's credential (e.g., the first 8 characters of a fwag_ key),
        used for logging and audit.  Implementations MUST NOT include the
        full credential.

     Example:

     {
       "txHash": "0xabc1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcd",
       "nonce": "a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5",
       "timestamp": 1745001200,
       "agentKeyPrefix": "fwag_a3f9"
     }





  Ganji                    Expires 23 October 2026                [Page 8]


  Internet-Draft                    FADP                        April 2026


  5.  Verification Endpoint

     The verification endpoint is an HTTPS resource that the server (or
     its delegate) calls to confirm that a payment proof corresponds to a
     valid on-chain transfer.  This section defines the request and
     response formats for that endpoint.

  5.1.  Verification Request

     The server sends an HTTP POST to the verifyUrl with a JSON body
     containing:

     txHash  REQUIRED.  String.  The transaction hash from the agent's
        proof.

     payTo  REQUIRED.  String.  The wallet address that should have
        received the transfer.

     amount  REQUIRED.  String.  The amount that should have been
        transferred.

     token  REQUIRED.  String.  The token symbol.

     chain  REQUIRED.  String.  The chain identifier.

     nonce  REQUIRED.  String.  The nonce from the original challenge.

  5.2.  Verification Response

     The verification service responds with a JSON object:

     verified  REQUIRED.  Boolean.  true if and only if all of the
        following conditions hold:

        *  The transaction identified by txHash exists on the specified
           chain.

        *  The transaction status is finalized (not reverted).

        *  The recipient address matches payTo.

        *  The transferred amount is greater than or equal to the required
           amount.

        *  The transferred token matches the required token.

     txHash  OPTIONAL.  String.  Echo of the verified transaction hash.




  Ganji                    Expires 23 October 2026                [Page 9]


  Internet-Draft                    FADP                        April 2026


     amount  OPTIONAL.  String.  The actual transferred amount.

     token  OPTIONAL.  String.  The actual transferred token symbol.

     chain  OPTIONAL.  String.  The chain on which the transfer occurred.

     from  OPTIONAL.  String.  The sender's wallet address.

     to  OPTIONAL.  String.  The recipient's wallet address (SHOULD match
        payTo).

     error  OPTIONAL.  String.  A human-readable error message when
        verified is false.

     Example successful response:

     {
       "verified": true,
       "txHash": "0xabc123...",
       "amount": "0.001",
       "token": "USDC",
       "chain": "base",
       "from": "0xAgentWallet...",
       "to": "0xServerWallet..."
     }

     Example failed response:

     {
       "verified": false,
       "error": "Transfer amount 0.0005 USDC is less than required 0.001 USDC"
     }

  6.  Server Behavior

  6.1.  Issuing Payment Challenges

     When a server receives a request for a FADP-protected resource
     without an X-FADP-Proof header, it MUST:

     1.  Generate a nonce of at least 16 bytes of cryptographically secure
         random data.

     2.  Record the nonce and its expiry time in durable server-side
         storage (memory, cache, or database).

     3.  Respond with HTTP 402.




  Ganji                    Expires 23 October 2026               [Page 10]


  Internet-Draft                    FADP                        April 2026


     4.  Set the X-FADP-Required header to a JSON object as defined in
         Section 4.1.

     5.  Set Access-Control-Expose-Headers: X-FADP-Required to ensure
         cross-origin agents can read the header.

  6.2.  Verifying Payment Proofs

     When a server receives a request with an X-FADP-Proof header, it MUST
     perform the following checks in order, returning an appropriate error
     response if any check fails:

     1.  Parse the header value as JSON; return 400 if malformed.

     2.  Verify that txHash, nonce, and timestamp are present; return 400
         if any is absent.

     3.  Look up the nonce in server-side storage; return 402 if the nonce
         is unknown.

     4.  Verify the nonce has not expired; return 402 if expired (delete
         the nonce).

     5.  Verify that |currentTime - proof.timestamp| <= 300 seconds;
         return 402 if outside range.

     6.  Call the verification service at verifyUrl; return 402 if
         verified is false.

     7.  Atomically mark the nonce as consumed (delete it from storage) to
         prevent replay.

     8.  Proceed to handle the original request.

     Step 7 (nonce consumption) MUST occur before the server fulfills the
     request.  If the server cannot atomically consume the nonce and
     fulfill the request (e.g., due to a crash), it SHOULD err on the side
     of not consuming the nonce, accepting the risk of a duplicate
     fulfillment rather than silently accepting payment without delivering
     service.

  7.  Agent Behavior

     An agent implementation SHOULD:

     1.  On receiving a 402 with X-FADP-Required, validate that the
         requested amount does not exceed the agent's configured spending
         limit before proceeding.



  Ganji                    Expires 23 October 2026               [Page 11]


  Internet-Draft                    FADP                        April 2026


     2.  Execute the on-chain transfer to the address and chain specified
         in the payment challenge, transferring at least the specified
         amount of the specified token.

     3.  Await sufficient blockchain confirmation before constructing the
         proof.  The definition of "sufficient" is implementation-
         specific; at minimum, the transaction MUST appear in a block
         (status: success) before the proof is submitted.

     4.  Construct an X-FADP-Proof object containing the txHash, the nonce
         from the challenge, and the current Unix timestamp.

     5.  Retry the original request with the X-FADP-Proof header added.

     6.  If the server returns another 402 with a new nonce (e.g., because
         the previous nonce expired), restart the payment flow.

     An agent MUST NOT reuse a txHash or nonce across separate request/
     response cycles.  Each resource access requires a fresh payment and a
     fresh proof.

  8.  Error Responses

     FADP servers SHOULD include a JSON body in all error responses with
     at least the following fields:

     error  String.  A machine-readable error key.

     protocol  String.  SHOULD be "FADP/1.0" to identify the protocol
        version.

     detail  String.  OPTIONAL human-readable elaboration.



















  Ganji                    Expires 23 October 2026               [Page 12]


  Internet-Draft                    FADP                        April 2026


      +========+=========================+=============================+
      | HTTP   | Condition               | Recommended error value     |
      | Status |                         |                             |
      +========+=========================+=============================+
      | 400    | Malformed X-FADP-Proof  | invalid_proof_format        |
      |        | header (not valid JSON) |                             |
      +--------+-------------------------+-----------------------------+
      | 400    | Missing required fields | missing_proof_fields        |
      |        | in proof                |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | No proof header present | payment_required            |
      |        | (initial challenge)     |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | Nonce unknown (never    | unknown_nonce               |
      |        | issued or already       |                             |
      |        | expired from store)     |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | Nonce expired (TTL      | nonce_expired               |
      |        | elapsed)                |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | Proof timestamp too old | proof_timestamp_invalid     |
      |        | or too far in future    |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | On-chain verification   | payment_verification_failed |
      |        | returned verified:      |                             |
      |        | false                   |                             |
      +--------+-------------------------+-----------------------------+
      | 402    | Transferred amount less | insufficient_payment        |
      |        | than required           |                             |
      +--------+-------------------------+-----------------------------+
      | 403    | Nonce has already been  | nonce_already_used          |
      |        | consumed (replay        |                             |
      |        | attempt)                |                             |
      +--------+-------------------------+-----------------------------+

                        Table 1: FADP Error Conditions

  9.  Chain Identifiers

     FADP uses short string identifiers for blockchain networks.  The
     following values are defined by this specification:










  Ganji                    Expires 23 October 2026               [Page 13]


  Internet-Draft                    FADP                        April 2026


       +==============+===============+=================+==============+
       | Identifier   | Network       | Native Currency | EVM Chain ID |
       +==============+===============+=================+==============+
       | base         | Base Mainnet  | ETH             | 8453         |
       |              | (Coinbase L2) |                 |              |
       +--------------+---------------+-----------------+--------------+
       | ethereum     | Ethereum      | ETH             | 1            |
       |              | Mainnet       |                 |              |
       +--------------+---------------+-----------------+--------------+
       | solana       | Solana        | SOL             | N/A          |
       |              | Mainnet Beta  |                 |              |
       +--------------+---------------+-----------------+--------------+
       | injective    | Injective     | INJ             | N/A          |
       |              | Mainnet       |                 |              |
       +--------------+---------------+-----------------+--------------+
       | base-sepolia | Base Sepolia  | ETH             | 84532        |
       |              | Testnet       |                 |              |
       +--------------+---------------+-----------------+--------------+

                    Table 2: FADP Chain Identifier Registry

     Implementors that wish to support chains not listed here SHOULD use
     identifiers of the form {namespace}-{networkname} to avoid collisions
     with future registered values.

  10.  Security Considerations

  10.1.  Replay Attacks

     The nonce mechanism is the primary defense against replay attacks.  A
     valid txHash from a past payment cannot be reused because:

     1.  Each payment challenge carries a unique nonce.

     2.  The proof MUST echo that nonce.

     3.  The server atomically consumes the nonce upon first successful
         verification.

     4.  Subsequent proofs referencing the same nonce are rejected with
         403.

     Server implementations MUST use cryptographically secure random
     number generation for nonces (e.g., /dev/urandom or equivalent).
     Predictable nonces would allow an attacker to pre-compute valid
     proofs.





  Ganji                    Expires 23 October 2026               [Page 14]


  Internet-Draft                    FADP                        April 2026


     The nonce store MUST be shared across all instances of a horizontally
     scaled server deployment.  If a local per-process nonce store is
     used, the same nonce could be accepted by two different instances
     simultaneously, creating a replay window.  A distributed cache (e.g.,
     Redis) or a database with atomic compare-and-delete operations is
     RECOMMENDED for production deployments.

  10.2.  Overpayment

     The verification service checks that the transferred amount is _at
     least_ the required amount.  Servers SHOULD NOT issue refunds for
     overpayments, as the complexity of doing so on-chain outweighs the
     benefit for small amounts.  Agents SHOULD transfer exactly the
     required amount to avoid unnecessary token loss.

  10.3.  Front-Running and Transaction Interception

     In principle, an attacker observing the agent's on-chain transaction
     in the mempool could copy the txHash and attempt to submit a proof
     before the legitimate agent.  This attack is mitigated by:

     1.  The nonce binding: the attacker must have obtained the nonce from
         a legitimate 402 challenge targeted at their own session.  Nonces
         are per-session and cannot be forged.

     2.  The proof timestamp check: the server rejects proofs assembled
         more than 300 seconds after the challenge was issued.

     Servers that require strong session binding MAY add an additional
     check verifying that the HTTP session initiating the proof matches
     the session that triggered the original challenge (e.g., via a
     session cookie or TLS channel binding), though this is outside the
     scope of the current protocol version.

  10.4.  Verification Service Trust

     Servers that delegate verification to a third-party service are
     implicitly trusting that service's honesty and availability.  A
     compromised or malicious verification service could return verified:
     true for invalid proofs, allowing unauthorized access.

     Servers operating in high-value contexts SHOULD run their own
     verification infrastructure against a direct blockchain RPC endpoint.
     The verification endpoint API defined in Section 5 is designed to be
     self-hostable for this reason.






  Ganji                    Expires 23 October 2026               [Page 15]


  Internet-Draft                    FADP                        April 2026


  10.5.  Blockchain Finality

     On chains with probabilistic finality (including Ethereum and Base),
     a transaction that appears in a block may be reorged out of the
     canonical chain.  Servers accepting payments for high-value resources
     SHOULD wait for a chain-specific number of confirmation blocks before
     accepting a proof as final.  For low-value micropayments on Base (an
     optimistic rollup with fast soft-finality), a single block
     confirmation is typically sufficient.

     Verification services MUST check that the transaction receipt status
     indicates success (i.e., it was not reverted), not merely that a
     transaction with the given hash exists.

  10.6.  Nonce Store Exhaustion

     An adversary could generate large numbers of initial requests to
     force the server to allocate nonces, potentially exhausting memory if
     the nonce store grows without bound.  Server implementations MUST
     periodically prune expired nonces and SHOULD rate-limit the issuance
     of payment challenges per IP address or session.

  10.7.  Header Injection

     The X-FADP-Required and X-FADP-Proof header values are JSON strings.
     Implementations MUST parse these with a conformant JSON parser and
     MUST NOT construct them via string interpolation without proper
     escaping, to prevent injection attacks.

  10.8.  Transport Security

     All FADP exchanges, including calls to the verification service, MUST
     be made over TLS (HTTPS).  Transmitting payment challenges or proofs
     over plaintext HTTP exposes the nonce to network adversaries,
     potentially enabling race-condition replay attacks.

  10.9.  Agent Spending Controls

     FADP does not define agent-side spending controls; these are the
     responsibility of the agent runtime.  However, agent implementors
     MUST validate the requested amount in the payment challenge against a
     pre-configured limit before executing any transfer.  Failing to do so
     could allow a malicious server to drain an agent's wallet by issuing
     artificially large payment challenges.







  Ganji                    Expires 23 October 2026               [Page 16]


  Internet-Draft                    FADP                        April 2026


  11.  IANA Considerations

  11.1.  HTTP Header Field Registration

     This document requests registration of the following header fields in
     the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
     maintained at https://www.iana.org/assignments/http-fields/.

     Header Field Name  X-FADP-Required

     Status  provisional

     Reference  This document, Section 4.1

     Header Field Name  X-FADP-Proof

     Status  provisional

     Reference  This document, Section 4.2

  11.2.  Media Type

     No new media types are registered by this document.  All message
     bodies are application/json as defined in [RFC8259].

  12.  Implementation Notes

  12.1.  Reference Implementations

     Reference implementations of the server middleware (fadpGate()) and
     client interceptor (fadpFetch()) are available as open-source
     software:

     *  *fluid-fadp* (npm): server middleware and standalone client
        interceptor for Node.js / TypeScript.  Repository:
        https://github.com/fluidbase9/fadp

     *  *fluid-wallet-agentkit* (npm): full agent SDK incorporating FADP
        auto-pay via the agent.fetch() method.  Repository:
        https://github.com/fluidbase9/fluidwalletbase

     *  *fluid-fadp-proxy* (npm): a ready-made reverse proxy that gates
        commercial AI service APIs (OpenRouter, RunPod, Vast.ai, Spheron)
        behind FADP payment walls.  Repository:
        https://github.com/fluidbase9/fadp-proxy






  Ganji                    Expires 23 October 2026               [Page 17]


  Internet-Draft                    FADP                        April 2026


  12.2.  Nonce Storage in Distributed Deployments

     For single-process servers, an in-memory Map with periodic TTL
     pruning is sufficient.  For multi-instance deployments, a shared
     store with atomic operations is required.  A Redis SET NX EX command
     provides an atomic "set if not exists with expiry" primitive suitable
     for nonce issuance; a Redis DEL returning the count of deleted keys
     provides atomic consumption.

  12.3.  Amount Precision

     Token amounts MUST be represented as decimal strings to avoid
     floating-point precision loss.  On-chain, USDC uses 6 decimal places;
     the string "0.001" corresponds to on-chain value 1000 (in the
     smallest unit).  Implementations MUST convert between decimal string
     and on-chain integer representation using fixed-point arithmetic, not
     IEEE 754 floating-point.

  12.4.  Cross-Origin Resource Sharing

     Browser-based agent implementations require that X-FADP-Required be
     listed in the Access-Control-Expose-Headers response header for the
     402 response.  Servers MUST set this header when cross-origin clients
     are expected.

  13.  References

  13.1.  Normative References

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

     [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
                (HTTP/1.1): Semantics and Content", RFC 7231,
                DOI 10.17487/RFC7231, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7231>.

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

     [RFC8259]  Bray, T., "The JavaScript Object Notation (JSON) Data
                Interchange Format", RFC 8259, DOI 10.17487/RFC8259,
                December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.





  Ganji                    Expires 23 October 2026               [Page 18]


  Internet-Draft                    FADP                        April 2026


     [RFC9110]  Fielding, R., Nottingham, M., and J. Reschke, "HTTP
                Semantics", RFC 9110, DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

  13.2.  Informative References

     [BASE-L2]  Coinbase, "Base: An Ethereum L2 for the Next Billion
                Users", Technical overview, base.org, 2023.  Base Mainnet
                is the reference deployment chain for FADP's reference
                implementation.

     [EIP-20]   Vogelsteller, F. and V. Buterin, "ERC-20 Token Standard",
                Ethereum Improvement Proposal 20, November 2015.  Defines
                the fungible token interface implemented by USDC and most
                payment tokens used with FADP.

     [EIP-55]   Buterin, V., "Mixed-case checksum address encoding",
                Ethereum Improvement Proposal 55, January 2016.  Defines
                the checksummed Ethereum address format used in FADP
                address fields.

     [x402]     Coinbase Developer Platform, "x402: An Open HTTP Payment
                Protocol", github.com/coinbase/x402, 2025.  A
                contemporaneous HTTP 402-based payment protocol from
                Coinbase.  FADP shares the 402 status code and on-chain
                settlement approach but differs in nonce mechanism, header
                naming, and protocol extensibility design.

  Appendix A: Complete Exchange Example

     The following illustrates a complete FADP exchange over HTTP/1.1.

     *Step 1 — Initial Request (no proof):*

     POST /v1/chat/completions HTTP/1.1
     Host: proxy.example.com
     Content-Type: application/json

     {"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello"}]}

     *Step 2 — Payment Challenge:*










  Ganji                    Expires 23 October 2026               [Page 19]


  Internet-Draft                    FADP                        April 2026


     HTTP/1.1 402 Payment Required
     Content-Type: application/json
     X-FADP-Required: {"version":"1.0","amount":"0.001","token":"USDC",
       "chain":"base","payTo":"0xAbCd1234AbCd1234AbCd1234AbCd1234AbCd1234",
       "nonce":"a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5","expires":1745001534,
       "description":"GPT-4o inference","verifyUrl":"https://fluidnative.com/v1/fadp/verify"}
     Access-Control-Expose-Headers: X-FADP-Required

     {"error":"Payment required","protocol":"FADP/1.0"}

     *Step 3 — Agent executes on-chain USDC transfer on Base, receives
     txHash.*

     *Step 4 — Authenticated Request:*

     POST /v1/chat/completions HTTP/1.1
     Host: proxy.example.com
     Content-Type: application/json
     X-FADP-Proof: {"txHash":"0xabc123...","nonce":"a3f9c2b1d4e5f6a7b8c9d0e1f2a3b4c5",
       "timestamp":1745001480}

     {"model":"openai/gpt-4o","messages":[{"role":"user","content":"Hello"}]}

     *Step 5 — Successful Response (after on-chain verification):*

     HTTP/1.1 200 OK
     Content-Type: application/json

     {"choices":[{"message":{"role":"assistant","content":"Hello! How can I help?"}}]}

  Acknowledgements

     The author thanks the teams building open agent infrastructure across
     the Ethereum, Base, and Solana ecosystems whose work made practical
     micropayment settlement possible.  The design of FADP was informed by
     the x402 protocol from Coinbase Developer Platform, the Model Context
     Protocol (MCP), and early feedback from developers building
     autonomous agents on the Fluid Wallet platform.

  Author's Address

     Abhijeeth Ganji
     Independent Researcher (Research Project: Fluid Wallet)
     Email: fluidbase9@gmail.com
     URI:   https://fluidnative.com






  Ganji                    Expires 23 October 2026               [Page 20]


name: draft-aevum-causal-intervention-record
rev: 00
title: Physically Annotated Causal Record (PACR): A Wire Format for Verifiable Causal Intervention Events
time: 2026-04-27T05:31:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-29T05:31:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "AI safety/alignment", "Other AI/agent"]
tags: []
fetched_at: 2026-05-22T09:24:50.092683+00:00
source: ietf
abstract:
  This document defines the Physically Annotated Causal Record (PACR),
     a wire-format protocol for representing one verifiable causal-
     intervention event between autonomous agents.  A PACR is a six-tuple
     (ι, Π, Λ, Ω, Γ, P) binding a causal identity, a set of causal
     predecessors, a thermodynamic Landauer cost, an energy-time-space
     resource triple, a cognitive complexity split, and an opaque payload.
     The opaque payload optionally carries a one-byte intervention tag
     classifying the event under Pearl's do-calculus hierarchy (Observe /
     Do-Physical / Do-Digital / Do-Chemical / Do-Genetic /
     Counterfactual).

     PACR is intended as the smallest sufficient statistic for a
     replayable, rights-aware claim about a single causal step performed
     by an autonomous agent on a digital, physical, or biological
     substrate.  It is complementary to AgentCard (draft-aevum-agentcard):
     AgentCard declares an agent's identity and capabilities; PACR records
     what an agent actually did and at what physical cost.

     PACR records form a content-addressed directed acyclic graph through
     their predecessor set.  Causal order is determined solely by the
     predecessor edges; no wall-clock timestamp is required for ordering.
     This makes the format suitable for distributed multi-agent systems
     where clock skew and partial ordering are unavoidable.

full_text:
  Individual Submission                                            K. Tsoi
  Internet-Draft                                             Aevum Network
  Intended status: Informational                             26 April 2026
  Expires: 28 October 2026


  Physically Annotated Causal Record (PACR): A Wire Format for Verifiable
                         Causal Intervention Events
                 draft-aevum-causal-intervention-record-00

  Abstract

     This document defines the Physically Annotated Causal Record (PACR),
     a wire-format protocol for representing one verifiable causal-
     intervention event between autonomous agents.  A PACR is a six-tuple
     (ι, Π, Λ, Ω, Γ, P) binding a causal identity, a set of causal
     predecessors, a thermodynamic Landauer cost, an energy-time-space
     resource triple, a cognitive complexity split, and an opaque payload.
     The opaque payload optionally carries a one-byte intervention tag
     classifying the event under Pearl's do-calculus hierarchy (Observe /
     Do-Physical / Do-Digital / Do-Chemical / Do-Genetic /
     Counterfactual).

     PACR is intended as the smallest sufficient statistic for a
     replayable, rights-aware claim about a single causal step performed
     by an autonomous agent on a digital, physical, or biological
     substrate.  It is complementary to AgentCard (draft-aevum-agentcard):
     AgentCard declares an agent's identity and capabilities; PACR records
     what an agent actually did and at what physical cost.

     PACR records form a content-addressed directed acyclic graph through
     their predecessor set.  Causal order is determined solely by the
     predecessor edges; no wall-clock timestamp is required for ordering.
     This makes the format suitable for distributed multi-agent systems
     where clock skew and partial ordering are unavoidable.

  Discussion Venues

     Discussion of this document should take place on the GitHub
     repository at https://github.com/kwailapt/AgentCard/issues with the
     label pacr-draft.  A reference Rust implementation [PACR-SPEC] is
     published as the pacr-types crate.

  Requirements Language







  Tsoi                     Expires 28 October 2026                [Page 1]


  Internet-Draft                    PACR                        April 2026


     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.

  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 28 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.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  The PACR Six-Tuple  . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  i (iota): Causal Identity . . . . . . . . . . . . . . . .   6
       3.2.  P (Pi): Predecessor Set . . . . . . . . . . . . . . . . .   7
       3.3.  L (Lambda): Landauer Cost . . . . . . . . . . . . . . . .   7
       3.4.  O (Omega): Resource Triple  . . . . . . . . . . . . . . .   7
       3.5.  G (Gamma): Cognitive Split  . . . . . . . . . . . . . . .   8
       3.6.  P (Payload): Opaque Application Data  . . . . . . . . . .   9
     4.  Estimate Type . . . . . . . . . . . . . . . . . . . . . . . .   9



  Tsoi                     Expires 28 October 2026                [Page 2]


  Internet-Draft                    PACR                        April 2026


     5.  Tagged Payload and Intervention Kind  . . . . . . . . . . . .  10
       5.1.  Wire Layout . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Intervention Kinds  . . . . . . . . . . . . . . . . . . .  10
       5.3.  Sim-Real Correlation  . . . . . . . . . . . . . . . . . .  11
     6.  Validation Rules  . . . . . . . . . . . . . . . . . . . . . .  11
     7.  Encodings . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       7.1.  JSON Encoding . . . . . . . . . . . . . . . . . . . . . .  12
       7.2.  CBOR Encoding . . . . . . . . . . . . . . . . . . . . . .  13
     8.  Relationship to Other Specifications  . . . . . . . . . . . .  13
       8.1.  AgentCard . . . . . . . . . . . . . . . . . . . . . . . .  13
       8.2.  JOSE / COSE . . . . . . . . . . . . . . . . . . . . . . .  13
       8.3.  W3C PROV-O  . . . . . . . . . . . . . . . . . . . . . . .  13
       8.4.  Model Context Protocol  . . . . . . . . . . . . . . . . .  14
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
       9.1.  Cost Spoofing . . . . . . . . . . . . . . . . . . . . . .  14
       9.2.  Fabricated Predecessors . . . . . . . . . . . . . . . . .  14
       9.3.  Payload Injection . . . . . . . . . . . . . . . . . . . .  14
       9.4.  Personally Identifiable Information . . . . . . . . . . .  15
       9.5.  Counterfactual Misuse . . . . . . . . . . . . . . . . . .  15
       9.6.  Graph Denial-of-Service . . . . . . . . . . . . . . . . .  15
       9.7.  Replay  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
       10.1.  Media Type Registration: application/pacr+json . . . . .  15
       10.2.  Media Type Registration: application/pacr+cbor . . . . .  16
       10.3.  PACR Intervention Kind Registry  . . . . . . . . . . . .  17
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       11.2.  Informative References . . . . . . . . . . . . . . . . .  18
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     Multi-agent systems built on top of large language models and
     autonomous physical infrastructure increasingly require a common
     format for recording _what an agent did_, not only _what an agent
     claims to be able to do_.  Existing provenance and audit formats
     describe transactions, signed statements, or workflow traces, but
     they typically do not record the physical cost of the computation, do
     not distinguish causal observation from causal intervention, and do
     not constrain partial ordering through explicit predecessor edges.

     This document specifies a minimal wire format that combines these
     properties: a single, content-addressed record that captures (i) a
     globally unique identity, (ii) the set of directly preceding records
     that caused this one, (iii) the thermodynamic energy floor for the
     bit-level erasures performed, (iv) the actually measured energy-time-
     space resource cost, (v) a complexity split into statistical



  Tsoi                     Expires 28 October 2026                [Page 3]


  Internet-Draft                    PACR                        April 2026


     structure and residual unpredictability, and (vi) an opaque payload
     whose first bytes optionally classify the event as an observation, an
     intervention, or a counterfactual.

     The format has been designed for use as a substrate-level record in
     agent-to-agent (A2A) protocols and is independent of any specific
     transport, storage, or settlement system.  It is a peer to AgentCard
     [I-D.aevum-agentcard]: an AgentCard says _"I am agent X, and I can do
     Y"_; a PACR record says _"agent X did Y at cost Z, caused by events
     {A, B}"_.

  1.1.  Design Goals

     1.  *Single record, six independent dimensions.* A PACR record
         carries exactly six fields, each derived from an independent
         physical or logical principle.  Implementations MUST NOT collapse
         two fields into one and MUST NOT add fields whose semantics
         overlap with an existing field.

     2.  *Causal order, not temporal order.* Records are partially ordered
         by their predecessor sets.  Wall-clock timestamps MAY appear
         inside the opaque payload but MUST NOT be used by readers to
         determine causal order.

     3.  *Physically grounded cost accounting.* The Landauer field carries
         a theoretical energy floor derived from the number of bits
         irreversibly erased; the resource triple carries the actually
         measured energy.  The two are distinct and the difference is the
         thermodynamic waste.

     4.  *Pearl-hierarchy intervention tag.* The opaque payload MAY begin
         with a four-byte magic prefix followed by a one-byte tag
         classifying the event under Pearl's do-calculus rungs [PEARL].
         Counterfactual records MUST additionally carry a sim-real
         correlation score.

     5.  *Append-only schema evolution.* New fields MAY be added to PACR
         in future revisions.  The semantics of existing fields, including
         this draft's six dimensions, MUST NOT change.

     6.  *Zero hidden state.* A reader who can parse this draft and who
         has access to the predecessor records referenced by Π can fully
         verify a PACR record without consulting any external service.

  1.2.  Non-Goals

     This document does not specify:




  Tsoi                     Expires 28 October 2026                [Page 4]


  Internet-Draft                    PACR                        April 2026


     *  A transport protocol.  PACR records may be exchanged over HTTP,
        MCP [MCP-SPEC], message queues, or written to disk; the wire
        format is independent.

     *  A signature or attestation scheme.  Implementations requiring
        authenticated records SHOULD wrap a PACR record in a JOSE
        [RFC7515] or COSE [RFC9052] envelope.

     *  A registry, settlement currency, or token system.  A PACR record
        reports a Landauer cost in joules; conversion to any settlement
        unit is a layer-above concern.

     *  A specific causal-discovery or counterfactual-inference algorithm.
        The Counterfactual tag indicates that a simulation produced this
        record; how the simulation arose is out of scope.

  2.  Terminology

     Record:  One PACR six-tuple as defined in Section 3.

     Predecessor:  A record whose causal identity appears in the
        predecessor set Π of another record.

     Genesis record:  A record whose predecessor set is empty.  Genesis
        records have no causal predecessors and serve as roots of the
        causal graph.

     Substrate:  The physical or digital medium on which an intervention
        acts.  Examples include a population of users, a single cell, a
        piece of infrastructure, or a digital data stream.

     Intervention:  A causal action on a substrate, distinct from passive
        observation.  Pearl's do-calculus [PEARL] formalises the
        distinction.

     Counterfactual:  A simulated event that did not actually occur on the
        substrate; included for "what-if" reasoning.  PACR counterfactuals
        MUST carry a sim-real correlation score.

     Estimate:  A measurement reported as a triple (point, lower, upper)
        with the invariant lower <= point <= upper.  Several PACR fields
        use this representation to carry measurement uncertainty.

     Landauer floor:  The minimum energy required to irreversibly erase a
        given number of bits at a given temperature, defined by Landauer's
        principle [LANDAUER]: Λ = bits × k_B × T × ln 2.





  Tsoi                     Expires 28 October 2026                [Page 5]


  Internet-Draft                    PACR                        April 2026


  3.  The PACR Six-Tuple

     A PACR record is the six-tuple

        R = ( i,  P,  L,  O,  G,  P_payload )
             |   |   |   |   |   |
             |   |   |   |   |   +-- payload (opaque bytes)
             |   |   |   |   +------ cognitive split (S_T, H_T, dH)
             |   |   |   +---------- resource triple (E, T, S)
             |   |   +-------------- Landauer cost in joules
             |   +------------------ predecessor set (causal order)
             +---------------------- causal identity (128 bits)

     where the Greek letters are written as their ASCII transliterations
     in the diagram for portability.  The canonical names of the fields
     are ι (iota, identity), Π (Pi, predecessors), Λ (Lambda, Landauer
     cost), Ω (Omega, resources), Γ (Gamma, cognitive split), and P
     (payload).

     Each of the six fields is REQUIRED.  Implementations MUST reject
     records in which any of the six is missing or null.

  3.1.  i (iota): Causal Identity

     The causal identity is a 128-bit value that uniquely names this
     record.  It is the content-address of the record within the causal
     graph.

     Implementations MUST treat the 128 bits as opaque for ordering
     purposes: causal order is derived solely from the predecessor set,
     not from the bit value.  Implementations MAY use any 128-bit
     identifier scheme (e.g., ULID [ULID-SPEC] or UUIDv7 [RFC9562]) so
     long as the collision probability over the lifetime of the deployment
     is cryptographically negligible.

     The reserved value 0x00000000000000000000000000000000 is the genesis
     sentinel and indicates a record with no causal predecessors that is
     itself a root of the graph.

     When serialised in JSON, the identity MUST be encoded as a
     32-character uppercase hexadecimal string.  Other serialisations
     (e.g., CBOR [RFC8949]) MAY encode it as a 16-byte byte string.









  Tsoi                     Expires 28 October 2026                [Page 6]


  Internet-Draft                    PACR                        April 2026


  3.2.  P (Pi): Predecessor Set

     The predecessor set is an unordered collection of zero or more causal
     identities, each naming a record that directly caused the current
     record.  Implementations MUST NOT interpret the order of elements in
     the set as semantically meaningful.

     The predecessor set establishes the partial ordering of records.
     Readers traversing the causal graph MUST treat two records with
     disjoint predecessor lineages as concurrent (incomparable),
     regardless of any timestamp information they may carry in their
     payloads.

     A record MUST NOT include its own causal identity in its predecessor
     set; such a record is malformed and MUST be rejected.

     For typical agent interactions, predecessor sets contain one to four
     entries.  Implementations SHOULD optimise for this common case (e.g.,
     using small-vector storage); they MUST also accept arbitrarily large
     predecessor sets, since some records (e.g., aggregations)
     legitimately have many causes.

  3.3.  L (Lambda): Landauer Cost

     The Landauer cost is the theoretical minimum energy in joules
     required to perform the bit-level erasures recorded by this event,
     derived from Landauer's principle [LANDAUER]:

            L  =  bits_erased  x  k_B  x  T  x  ln 2

     where k_B = 1.380649e-23 J/K is Boltzmann's constant [CODATA], T is
     the temperature of the computing substrate in kelvin, and bits_erased
     is the number of bits irreversibly erased while producing this
     record.  At a reference temperature of 300 K, the per-bit floor is
     approximately 2.854e-21 J.

     The Landauer cost MUST be a non-negative Estimate (see Section 4).
     Negative point estimates are ill-defined and MUST cause validation to
     fail.

     The Landauer cost is a lower bound, not the actual energy consumed.
     The actual energy is reported separately in the resource triple.  The
     difference between the two is the thermodynamic waste of the event.

  3.4.  O (Omega): Resource Triple

     The resource triple reports the actually measured cost of the event
     along three axes:



  Tsoi                     Expires 28 October 2026                [Page 7]


  Internet-Draft                    PACR                        April 2026


     energy:  Actual energy consumed in joules, including waste heat and
        overheads beyond the Landauer floor.

     time:  Wall-clock execution duration in seconds.  Despite using
        seconds, this value MUST NOT be used for causal ordering; it is a
        resource cost only.

     space:  Memory or storage footprint in bytes (encoded as a floating-
        point number for SI-unit consistency with the other two axes).

     Each of the three axes MUST be an Estimate (see Section 4).  The
     triple is subject to two physical constraints:

     *  *Landauer floor:* energy.point >= L.point.  The actually measured
        energy MUST NOT be below the theoretical floor.

     *  *Margolus-Levitin bound* [MARGOLUS]: time.point >= pi * h_bar / (2
        * energy.point) for non-zero energy, where h_bar = 1.054571817e-34
        J×s.  This bound is of practical relevance only at femtojoule
        scales but MUST be checked for completeness.

     A record violating either constraint is malformed.  Implementations
     MAY still store such records for forensic purposes (measurement
     errors do occur), but they MUST flag the violation in any downstream
     validation report.

  3.5.  G (Gamma): Cognitive Split

     The cognitive split decomposes the information-theoretic structure of
     the data stream associated with this event:

     statistical_complexity (S_T):  Statistical complexity in bits,
        measuring the minimum information required to optimally predict
        the stream.  Computed via an epsilon-machine reconstruction
        [CRUTCHFIELD].

     entropy_rate (H_T):  Entropy rate in bits per symbol, measuring the
        residual unpredictability of the stream even given the optimal
        predictor.

     info_gain (dH):  Information gain in bits, equal to the entropy
        reduction H_T_before - H_T_after attributable to processing this
        record.  This field was added in a later revision of the reference
        implementation; readers parsing earlier records MUST treat its
        absence as a value of 0.0 with zero uncertainty.

     All three values MUST be non-negative Estimates.  Negative point
     estimates are ill-defined and MUST cause validation to fail.



  Tsoi                     Expires 28 October 2026                [Page 8]


  Internet-Draft                    PACR                        April 2026


     Statistical complexity and entropy rate are observer- dependent
     quantities: they depend on the symbol alphabet and the time scale at
     which the stream is sampled.  Implementations exchanging records MUST
     agree on the discretisation, either through prior arrangement or by
     recording the discretisation parameters inside the opaque payload.

  3.6.  P (Payload): Opaque Application Data

     The payload is an arbitrary byte string carrying application-specific
     semantics.  PACR does not interpret this field except to optionally
     extract a Pearl-hierarchy tag from its first bytes (see Section 5).

     Upper-layer protocols (e.g., AgentCard [I-D.aevum-agentcard]) define
     their own schemas inside this field.  PACR readers that do not
     understand the upper-layer schema MUST still accept and forward the
     record; they MUST NOT alter the payload bytes in any way.

     A payload MAY be empty.  An empty payload denotes an event with no
     application-level content, such as a heartbeat or a synthetic genesis
     record.

  4.  Estimate Type

     Several PACR fields carry physical measurements that are inherently
     uncertain.  These fields use a common Estimate representation: an
     object with three numeric values point, lower, and upper, subject to
     the invariant

            lower  <=  point  <=  upper

     where point is the best single-value estimate (for example the median
     or mean of a sample), and [lower, upper] is a confidence interval.  A
     95 % confidence interval is RECOMMENDED, but the chosen confidence
     level is implementation-defined and MAY be reported in the opaque
     payload.  The choice MUST remain consistent within a single
     deployment.

     For quantities known with mathematical certainty (e.g., a bit count),
     an Estimate with point = lower = upper MAY be used.  Floating-point
     equality is physically meaningless; consumers comparing two Estimates
     MUST do so through interval-overlap checks rather than exact
     equality.

     Implementations MUST reject Estimates whose values do not satisfy the
     ordering invariant.  Recovery from invalid Estimates is
     implementation-defined.





  Tsoi                     Expires 28 October 2026                [Page 9]


  Internet-Draft                    PACR                        April 2026


  5.  Tagged Payload and Intervention Kind

     A PACR payload MAY begin with the four-byte magic prefix 0x50 0x41
     0x43 0x52 (ASCII "PACR") to indicate that the payload carries an
     intervention tag.  Payloads without this prefix are _legacy_ payloads
     and MUST be treated as if they carried the tag Observe.

  5.1.  Wire Layout

        Bytes  0..4   magic = "PACR" (0x50 0x41 0x43 0x52)
        Byte   4      kind byte (see Section 5.2)
        Bytes  5..13  sim_real_corr as f64 big-endian
                      -- ONLY IF kind == Counterfactual
        Bytes  5..    inner application payload
                      -- when kind != Counterfactual
        Bytes  13..   inner application payload
                      -- when kind == Counterfactual

  5.2.  Intervention Kinds

     The intervention kind classifies the event under Pearl's three-rung
     do-calculus hierarchy [PEARL].  This document defines six kinds,
     encoded as the byte values shown:

     0x00 -- Observe (Pearl rung 1):  A passive observation of the
        substrate.  No causal action was taken.

     0x01 -- DoPhysical (Pearl rung 2):  A physical-world action.
        Examples: a robot actuator command, a sensor calibration, a
        laboratory pipetting step.

     0x02 -- DoDigital (Pearl rung 2):  A digital action against an
        external system.  Examples: an HTTP API call, a settlement
        message, a routing decision in a multi-agent system.

     0x03 -- DoChemical (Pearl rung 2):  A chemical or biological
        perturbation.  Examples: applying a small-molecule compound to a
        culture, dosing an animal model.

     0x04 -- DoGenetic (Pearl rung 2):  A genetic edit.  Examples: a
        CRISPR guide-RNA delivery, a directed-evolution selection round.

     0x05 -- Counterfactual (Pearl rung 3):  A simulated event that did
        not occur on the real substrate.  Counterfactual records carry the
        additional sim_real_corr field described below.






  Tsoi                     Expires 28 October 2026               [Page 10]


  Internet-Draft                    PACR                        April 2026


     Future revisions of this document MAY define additional kinds with
     byte values 0x06 through 0xFF.  Readers encountering an unknown kind
     byte MUST reject the record rather than guess; this preserves the
     append-only contract.

  5.3.  Sim-Real Correlation

     A Counterfactual record MUST carry a sim_real_corr value in the range
     [0.0, 1.0], encoded as an IEEE 754 double-precision number in big-
     endian byte order immediately following the kind byte.  The value
     reports the observed correlation between simulated outcomes and the
     historical real-substrate outcomes for analogous setups.

     A Counterfactual record without a sim-real correlation score, or with
     a score outside [0.0, 1.0], is malformed and MUST be rejected.  This
     requirement prevents counterfactual claims from being treated as
     substrate-truth without a stated calibration.

  6.  Validation Rules

     An implementation that validates a PACR record MUST check each of the
     following conditions and MUST report a violation for any condition
     that fails.  A record may have multiple violations; implementations
     SHOULD report all of them rather than stopping at the first.

     1.  *Required fields present.* All six fields (ι, Π, Λ, Ω, Γ, P) MUST
         be present.  Missing fields MUST cause rejection.

     2.  *No self-reference.* ι MUST NOT appear in Π.

     3.  *Estimate invariants.* Every Estimate value MUST satisfy lower <=
         point <= upper.

     4.  *Non-negative physical quantities.* Λ, the energy and space
         components of Ω, the statistical complexity, the entropy rate,
         and the information gain MUST have non-negative point estimates.

     5.  *Strictly positive time.* The time component of Ω MUST have a
         strictly positive point estimate.

     6.  *Landauer floor.* The energy point estimate MUST be greater than
         or equal to the Λ point estimate.

     7.  *Margolus-Levitin bound.* For non-zero energy, the time point
         estimate MUST satisfy time >= pi * h_bar / (2 * energy).






  Tsoi                     Expires 28 October 2026               [Page 11]


  Internet-Draft                    PACR                        April 2026


     8.  *Tagged payload integrity.* If the payload begins with the magic
         prefix, the payload MUST contain at least the kind byte (and, for
         Counterfactual records, the sim-real correlation field).  An
         unknown kind byte MUST cause rejection.

     9.  *Counterfactual sim-real range.* A Counterfactual record MUST
         have 0.0 <= sim_real_corr <= 1.0.

  7.  Encodings

     This document does not mandate a single binary encoding.  Two
     canonical encodings are described below; deployments MAY use either
     or both.

  7.1.  JSON Encoding

     A PACR record MAY be serialised as a JSON object [RFC8259] with the
     following fields:

   {
     "id": "01HZQK3P8EMXR9V7T5N2W4J6C0",
     "predecessors": [
       "01HZQK3P8EMXR9V7T5N2W4J6BQ",
       "01HZQK3P8EMXR9V7T5N2W4J6BR"
     ],
     "landauer_cost": {
       "point": 2.854e-21,
       "lower": 2.713e-21,
       "upper": 2.998e-21
     },
     "resources": {
       "energy": { "point": 4.0e-19, "lower": 3.8e-19, "upper": 4.2e-19 },
       "time":   { "point": 1.2e-3,  "lower": 1.18e-3, "upper": 1.22e-3 },
       "space":  { "point": 4096.0,  "lower": 4096.0,  "upper": 4096.0 }
     },
     "cognitive_split": {
       "statistical_complexity":
           { "point": 3.4,  "lower": 3.1,  "upper": 3.7  },
       "entropy_rate":
           { "point": 0.92, "lower": 0.88, "upper": 0.95 },
       "info_gain":
           { "point": 0.07, "lower": 0.04, "upper": 0.10 }
     },
     "payload": "UEFDUgIA"
   }






  Tsoi                     Expires 28 October 2026               [Page 12]


  Internet-Draft                    PACR                        April 2026


     Identities are encoded as 32-character uppercase hexadecimal strings.
     The payload is encoded using base64 [RFC4648] without padding-
     stripping.  All numeric values use IEEE 754 double-precision
     semantics; JSON numbers without a decimal point or exponent retain
     integer interpretation per [RFC8259].

  7.2.  CBOR Encoding

     A PACR record MAY be serialised as a CBOR [RFC8949] map with the same
     field names as the JSON encoding.  Identities MUST be encoded as
     16-byte byte strings (CBOR major type 2).  Estimates are encoded as
     three-element CBOR arrays in the order [point, lower, upper].
     Payloads are encoded as CBOR byte strings.

     The CBOR encoding is RECOMMENDED for high-throughput deployments
     where the JSON overhead is significant.

  8.  Relationship to Other Specifications

  8.1.  AgentCard

     AgentCard [I-D.aevum-agentcard] declares what an agent is and what it
     can do.  PACR records what an agent did.  AgentCards are typically
     static; PACR records are append-only event streams.

     A common deployment pattern is for an agent to publish an AgentCard
     containing its identity and capabilities, and for every action that
     agent takes to be recorded as a PACR record whose payload references
     the AgentCard's identity and the capability invoked.

  8.2.  JOSE / COSE

     PACR does not define an authentication mechanism.  Deployments that
     require authenticated PACR records SHOULD wrap each record in a JOSE
     [RFC7515] or COSE [RFC9052] envelope and use the wrapper's signature
     semantics.  The PACR identity field is suitable as the JOSE/COSE
     message identifier.

  8.3.  W3C PROV-O

     The W3C PROV ontology [W3C-PROV] models provenance using activities,
     agents, and entities, and is designed for description in RDF.  PACR
     is a complementary, line-protocol-style format with a fixed six-tuple
     structure and an explicit thermodynamic cost field.  A PROV-O
     activity MAY be derived from a PACR record by mapping ι to
     prov:Activity, Π to prov:wasInformedBy, and the payload to
     prov:value.




  Tsoi                     Expires 28 October 2026               [Page 13]


  Internet-Draft                    PACR                        April 2026


  8.4.  Model Context Protocol

     MCP [MCP-SPEC] defines a protocol for communication between language-
     model hosts and tool servers.  An MCP tool call MAY produce a PACR
     record as a side effect of execution; the PACR record's payload MAY
     embed the MCP request and response identifiers.  This document does
     not require any specific MCP integration.

  9.  Security Considerations

  9.1.  Cost Spoofing

     A malicious or buggy producer may report a Landauer cost or resource
     triple lower than the actual physical cost of the event.  PACR's
     validation rules detect impossibly low costs (e.g., negative energy,
     energy below the Landauer floor at the producer's stated temperature)
     but do not detect plausibly low costs.  Consumers who use PACR
     records for economic settlement or capacity planning SHOULD
     independently corroborate cost claims (for example, by comparing
     reported energy against observed latency and throughput) before
     acting on them.

  9.2.  Fabricated Predecessors

     A malicious producer may include in the predecessor set identities
     that the producer does not actually possess knowledge of, intending
     to claim a causal lineage it did not participate in.  PACR does not
     by itself prevent this: a consumer must verify that the referenced
     predecessor records exist in a trusted store and that they precede
     the current record in the consumer's view of the causal graph.
     Implementations SHOULD reject a record whose predecessor set
     references unknown identities until the predecessors have been
     resolved.

  9.3.  Payload Injection

     The opaque payload MAY contain arbitrary bytes including executable
     code, malformed structured data, or content that attempts to exploit
     the consumer's parser.  Consumers MUST treat the payload as untrusted
     input and apply normal parser-hardening practices (e.g., strict
     schema validation, length limits, never eval-ing the bytes).  PACR
     itself does not interpret the payload.









  Tsoi                     Expires 28 October 2026               [Page 14]


  Internet-Draft                    PACR                        April 2026


  9.4.  Personally Identifiable Information

     PACR's six structural fields do not carry personally identifiable
     information (PII).  Producers MAY embed PII in the opaque payload.
     Doing so makes the PACR record subject to the same privacy controls
     (consent, retention, lawful basis) as any other PII-bearing data.
     Implementations intended for use in regulated environments SHOULD
     partition PII-bearing payloads from non-PII payloads at the storage
     layer.

  9.5.  Counterfactual Misuse

     A Counterfactual record describes a simulated event, not a real-
     substrate event.  Confusion between the two could lead to substantial
     harm in safety-critical contexts (for example, an autonomous-driving
     system mistakenly treating a counterfactual scenario as observed
     reality).  Consumers MUST inspect the intervention kind before
     treating a record as evidence of substrate state, and SHOULD render
     counterfactual records distinctly in any user interface.  The
     mandatory sim_real_corr field is intended as a calibration hint, not
     as a guarantee.

  9.6.  Graph Denial-of-Service

     A producer may construct records with very large predecessor sets, or
     whose graph forms a deep chain, in an attempt to exhaust consumer
     resources during traversal.  Implementations SHOULD impose
     configurable per-record limits (predecessor-set cardinality, payload
     size) and per-traversal limits (depth, total node count) and SHOULD
     reject or truncate records that exceed them.

  9.7.  Replay

     PACR does not include a sequence number, nonce, or signature.  A
     captured record MAY be replayed by a network attacker.  Deployments
     MUST rely on transport-layer or wrapper-layer mechanisms (TLS, JOSE/
     COSE, MCP transport authentication) to detect and reject replays
     where this is a concern.

  10.  IANA Considerations

  10.1.  Media Type Registration: application/pacr+json

     This document requests that IANA register the following media type in
     the "Media Types" registry [RFC6838]:

     Type name:  application




  Tsoi                     Expires 28 October 2026               [Page 15]


  Internet-Draft                    PACR                        April 2026


     Subtype name:  pacr+json

     Required parameters:  none

     Optional parameters:  none

     Encoding considerations:  binary (UTF-8 JSON object)

     Security considerations:  See Section 9.

     Published specification:  This document.

     Applications that use this media type:  Multi-agent systems, AI-agent
        provenance ledgers, MCP servers and adapters, and any deployment
        that records verifiable causal-intervention events with
        thermodynamic cost annotations.

     Additional information:  Magic number(s):  none

                              File extension(s):  .pacr.json

                              Macintosh file type code(s):  none

     Person and email address to contact for further information:  Kwai
        Lap Tsoi <kwailapt@gmail.com>

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author:  Kwai Lap Tsoi <kwailapt@gmail.com>

     Change controller:  IETF

  10.2.  Media Type Registration: application/pacr+cbor

     This document requests that IANA register the following media type in
     the "Media Types" registry [RFC6838]:

     Type name:  application

     Subtype name:  pacr+cbor

     Required parameters:  none

     Optional parameters:  none

     Encoding considerations:  binary (CBOR map per RFC 8949)



  Tsoi                     Expires 28 October 2026               [Page 16]


  Internet-Draft                    PACR                        April 2026


     Security considerations:  See Section 9.

     Published specification:  This document.

     Applications that use this media type:  High-throughput PACR
        deployments where JSON encoding overhead is significant.

     Additional information:  Magic number(s):  none

                              File extension(s):  .pacr.cbor

                              Macintosh file type code(s):  none

     Person and email address to contact for further information:  Kwai
        Lap Tsoi <kwailapt@gmail.com>

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author:  Kwai Lap Tsoi <kwailapt@gmail.com>

     Change controller:  IETF

  10.3.  PACR Intervention Kind Registry

     This document requests that IANA establish a new registry named "PACR
     Intervention Kind" with the following initial contents.  The
     assignment policy is "Specification Required" per [RFC8126].

            +=======+================+============+===============+
            | Value | Name           | Pearl Rung | Reference     |
            +=======+================+============+===============+
            | 0x00  | Observe        | 1          | This document |
            +-------+----------------+------------+---------------+
            | 0x01  | DoPhysical     | 2          | This document |
            +-------+----------------+------------+---------------+
            | 0x02  | DoDigital      | 2          | This document |
            +-------+----------------+------------+---------------+
            | 0x03  | DoChemical     | 2          | This document |
            +-------+----------------+------------+---------------+
            | 0x04  | DoGenetic      | 2          | This document |
            +-------+----------------+------------+---------------+
            | 0x05  | Counterfactual | 3          | This document |
            +-------+----------------+------------+---------------+

                                    Table 1




  Tsoi                     Expires 28 October 2026               [Page 17]


  Internet-Draft                    PACR                        April 2026


     Values 0x06 through 0xFE are unassigned.  Value 0xFF is reserved.
     New assignments require a published specification that defines the
     semantics of the kind, any additional payload fields it requires, and
     any additional validation rules.

  11.  References

  11.1.  Normative References

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

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

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4648>.

     [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/rfc/rfc6838>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [LANDAUER] Landauer, R., "Irreversibility and Heat Generation in the
                Computing Process", IBM Journal of Research and
                Development 5(3):183-191, 1961,
                <https://doi.org/10.1147/rd.53.0183>.

  11.2.  Informative References



  Tsoi                     Expires 28 October 2026               [Page 18]


  Internet-Draft                    PACR                        April 2026


     [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/rfc/rfc7515>.

     [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Structures and Process", STD 96, RFC 9052,
                DOI 10.17487/RFC9052, August 2022,
                <https://www.rfc-editor.org/rfc/rfc9052>.

     [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/rfc/rfc9562>.

     [I-D.aevum-agentcard]
                Tsoi, K., "AgentCard: A Framework-Neutral Identity and
                Capability Declaration Format for Agent-to-Agent
                Communication", Work in Progress, Internet-Draft, draft-
                aevum-agentcard-00, 2026,
                <https://datatracker.ietf.org/doc/draft-aevum-agentcard/>.

     [ULID-SPEC]
                Feerasta, A., "ULID Specification", 2019,
                <https://github.com/ulid/spec>.

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

     [PEARL]    Pearl, J., "Causality: Models, Reasoning, and Inference",
                Cambridge University Press 2nd ed., 2009,
                <https://doi.org/10.1017/CBO9780511803161>.

     [MARGOLUS] Margolus, N. and L. Levitin, "The Maximum Speed of
                Dynamical Evolution", Physica D 120(1-2):188-195, 1998,
                <https://doi.org/10.1016/0167-2789(98)00054-2>.

     [CRUTCHFIELD]
                Crutchfield, J. and C. Shalizi, "Computational Mechanics:
                Pattern and Prediction, Structure and Simplicity", Journal
                of Statistical Physics 104:817-879, 2001,
                <https://doi.org/10.1063/1.1530990>.

     [CODATA]   NIST, "CODATA Recommended Values of the Fundamental
                Physical Constants: 2018", 2019,
                <https://physics.nist.gov/cuu/Constants/>.

     [W3C-PROV] Lebo, T., Sahoo, S., and D. McGuinness, "PROV-O: The PROV
                Ontology", 2013, <https://www.w3.org/TR/prov-o/>.




  Tsoi                     Expires 28 October 2026               [Page 19]


  Internet-Draft                    PACR                        April 2026


     [PACR-SPEC]
                Tsoi, K. L., "pacr-types: Reference Implementation of the
                PACR 6-Tuple in Rust", 2026,
                <https://github.com/kwailapt/AgentCard/tree/main/crates/
                pacr-types>.

  Acknowledgements

     The PACR six-tuple structure was developed in the context of the
     Aevum Network specification work over 2026.  The author thanks
     reviewers of the AgentCard draft ([I-D.aevum-agentcard]) for early
     feedback that motivated the separation of capability declaration
     (AgentCard) from event recording (PACR).

     The Pearl-hierarchy intervention tag was added after practical use of
     an untagged predecessor format made it clear that downstream
     consumers cannot reliably distinguish observations from interventions
     without an explicit marker.

  Author's Address

     Kwai Lap Tsoi
     Aevum Network
     Email: kwailapt@gmail.com
     URI:   https://github.com/kwailapt/AgentCard


























  Tsoi                     Expires 28 October 2026               [Page 20]


name: draft-rehfeld-apix-core
rev: 03
title: API Index (APIX): Core Infrastructure for Autonomous Agent Service Discovery
time: 2026-05-13T02:39:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-14T02:39:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Policy/governance", "Data formats/interop", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:50.092701+00:00
source: ietf
abstract:
  The internet was designed for human actors.  Its discovery
     infrastructure — search engines, directories, and hyperlinked
     documents — assumes a human reading and navigating.  Autonomous
     agents (bots) operating on the internet today face a structural gap:
     there is no machine-native, globally accessible index of services
     they can consume.

     This document defines the core infrastructure of the *API Index
     (APIX)*: a HATEOAS-based, globally accessible, commercially
     sustainable service discovery infrastructure designed for autonomous
     agents as its primary consumers.  It specifies the governance model,
     the three-dimensional trust model, the APIX Manifest (APM) base
     format, commercial onboarding and sanctions compliance, the supply-
     side funding model, and the base Index API.  These elements are
     shared across all APIX service types.

     Profile documents extend this core for specific service categories:
     the APIX Services Profile (draft-rehfeld-apix-services-00) defines
     the web API and bot service profile; the APIX IoT Device Profile
     (draft-rehfeld-apix-iot-00) defines the IoT device profile.

full_text:
  Network Working Group                                         C. Rehfeld
  Internet-Draft                                               13 May 2026
  Intended status: Informational                                          
  Expires: 14 November 2026


     API Index (APIX): Core Infrastructure for Autonomous Agent Service
                                 Discovery
                         draft-rehfeld-apix-core-03

  Abstract

     The internet was designed for human actors.  Its discovery
     infrastructure — search engines, directories, and hyperlinked
     documents — assumes a human reading and navigating.  Autonomous
     agents (bots) operating on the internet today face a structural gap:
     there is no machine-native, globally accessible index of services
     they can consume.

     This document defines the core infrastructure of the *API Index
     (APIX)*: a HATEOAS-based, globally accessible, commercially
     sustainable service discovery infrastructure designed for autonomous
     agents as its primary consumers.  It specifies the governance model,
     the three-dimensional trust model, the APIX Manifest (APM) base
     format, commercial onboarding and sanctions compliance, the supply-
     side funding model, and the base Index API.  These elements are
     shared across all APIX service types.

     Profile documents extend this core for specific service categories:
     the APIX Services Profile (draft-rehfeld-apix-services-00) defines
     the web API and bot service profile; the APIX IoT Device Profile
     (draft-rehfeld-apix-iot-00) defines the IoT device profile.

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




  Rehfeld                 Expires 14 November 2026                [Page 1]


  Internet-Draft                  APIX Core                       May 2026


     This Internet-Draft will expire on 14 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.  The Bot Ecosystem Gap . . . . . . . . . . . . . . . . . .   4
         1.1.1.  Motivation: A Concrete Origin . . . . . . . . . . . .   4
         1.1.2.  The Discovery Problem . . . . . . . . . . . . . . . .   5
         1.1.3.  The Discovery Shift . . . . . . . . . . . . . . . . .   6
         1.1.4.  Infrastructure Efficiency and the Overhead of
                 Human-Facing Responses  . . . . . . . . . . . . . . .   6
         1.1.5.  Lessons from Prior Art  . . . . . . . . . . . . . . .   7
         1.1.6.  Related IETF and W3C Work . . . . . . . . . . . . . .   8
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .  18
       1.3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .  20
         1.3.1.  Requirements (MUST) . . . . . . . . . . . . . . . . .  20
         1.3.2.  Goals (SHOULD)  . . . . . . . . . . . . . . . . . . .  21
         1.3.3.  Out of Scope  . . . . . . . . . . . . . . . . . . . .  21
       1.4.  Architecture Overview . . . . . . . . . . . . . . . . . .  22
         1.4.1.  Component Model . . . . . . . . . . . . . . . . . . .  22
         1.4.2.  Governance Model  . . . . . . . . . . . . . . . . . .  24
         1.4.3.  Standard Registries . . . . . . . . . . . . . . . . .  25
       1.5.  Lawful Cooperation and Non-Surveillance Commitment  . . .  27
         1.5.1.  Purpose of the Service  . . . . . . . . . . . . . . .  28
         1.5.2.  Cooperation Duty  . . . . . . . . . . . . . . . . . .  28
         1.5.3.  Non-Surveillance Commitment . . . . . . . . . . . . .  28
         1.5.4.  The Trigger Requirement . . . . . . . . . . . . . . .  29
         1.5.5.  Jurisdictional Guardrails . . . . . . . . . . . . . .  30
         1.5.6.  Transparency as Enforcement . . . . . . . . . . . . .  30
       1.6.  The APIX Manifest (APM) . . . . . . . . . . . . . . . . .  31
         1.6.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . .  31
       1.7.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  32
         1.7.1.  Dimension 1 — Organisation Trust Level  . . . . . . .  32
         1.7.2.  Dimension 2 — Service Verification Level  . . . . . .  33
         1.7.3.  Dimension 3 — Liveness  . . . . . . . . . . . . . . .  34
         1.7.4.  Trust Model Implementations by Service Type . . . . .  35
         1.7.5.  Bot-Side Trust Policy Expression  . . . . . . . . . .  36



  Rehfeld                 Expires 14 November 2026                [Page 2]


  Internet-Draft                  APIX Core                       May 2026


         1.7.6.  Accredited Verifier Model . . . . . . . . . . . . . .  36
       1.8.  Commercial Contract and Sanctions Compliance  . . . . . .  38
       1.9.  Operational Model . . . . . . . . . . . . . . . . . . . .  39
         1.9.1.  Supply-Side Funding Principle . . . . . . . . . . . .  39
         1.9.2.  Consumer Access Model . . . . . . . . . . . . . . . .  40
         1.9.3.  Ecological Impact Transparency  . . . . . . . . . . .  41
       1.10. Index API — Core  . . . . . . . . . . . . . . . . . . . .  42
         1.10.1.  HATEOAS Navigation Model . . . . . . . . . . . . . .  42
         1.10.2.  Discovery Endpoint . . . . . . . . . . . . . . . . .  42
         1.10.3.  Transport Encoding . . . . . . . . . . . . . . . . .  44
       1.11. Index API Versioning  . . . . . . . . . . . . . . . . . .  45
         1.11.1.  Version Identification . . . . . . . . . . . . . . .  45
         1.11.2.  Compatibility Rules  . . . . . . . . . . . . . . . .  45
         1.11.3.  API Deprecation and Migration  . . . . . . . . . . .  46
         1.11.4.  Service api_version Immutability Invariant . . . . .  46
         1.11.5.  No Cross-Version Response Mapping  . . . . . . . . .  47
         1.11.6.  Registry Version Tracking  . . . . . . . . . . . . .  48
       1.12. Operator Security and Self-Governance . . . . . . . . . .  48
         1.12.1.  Purpose and Scope  . . . . . . . . . . . . . . . . .  48
         1.12.2.  Technical Security Requirements  . . . . . . . . . .  49
         1.12.3.  Organisational Security Requirements . . . . . . . .  50
         1.12.4.  Political Independence and Anti-Capture Measures . .  50
         1.12.5.  Crisis Governance Protocol . . . . . . . . . . . . .  51
         1.12.6.  Data Minimisation as Security Policy . . . . . . . .  52
         1.12.7.  Annual Security Report . . . . . . . . . . . . . . .  53
       1.13. Security Considerations . . . . . . . . . . . . . . . . .  53
         1.13.1.  Abuse and Fake Listings  . . . . . . . . . . . . . .  54
         1.13.2.  Trust Level Spoofing . . . . . . . . . . . . . . . .  54
         1.13.3.  Transport Security Requirements  . . . . . . . . . .  54
         1.13.4.  Bot Consumer Risks . . . . . . . . . . . . . . . . .  54
     2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  55
       2.1.  Normative References  . . . . . . . . . . . . . . . . . .  55
       2.2.  Informative References  . . . . . . . . . . . . . . . . .  55
     Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  59
       A.1.  IANA Considerations . . . . . . . . . . . . . . . . . . .  59
       A.2.  References  . . . . . . . . . . . . . . . . . . . . . . .  59
         A.2.1.  Normative References  . . . . . . . . . . . . . . . .  60
         A.2.2.  Informative References  . . . . . . . . . . . . . . .  60
       A.3.  Author's Address  . . . . . . . . . . . . . . . . . . . .  61
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  61

  1.  Introduction









  Rehfeld                 Expires 14 November 2026                [Page 3]


  Internet-Draft                  APIX Core                       May 2026


  1.1.  The Bot Ecosystem Gap

     The internet's foundational infrastructure — HTTP, HTML, DNS, and
     search engines — was designed with human actors as the primary
     consumers.  Web pages render visual layouts for human eyes.  CAPTCHA
     systems explicitly discriminate against non-human access.  Discovery
     mechanisms such as search engines index content for human-readable
     navigation.

     Autonomous agents — software programs that independently execute
     tasks, consume APIs, and interact with external services without per-
     action human instruction — are not recognized as legitimate, first-
     class internet participants in this architecture.  They are
     systematically treated as threats to be filtered, blocked, or rate-
     limited.

     This situation is changing.  The rapid growth of large language
     model-based agents, robotic process automation, and programmatic
     service consumers means that non-human actors now represent a
     significant and growing proportion of internet traffic.  As this
     proportion increases, internet service providers will increasingly
     need to serve autonomous agents as a recognized user class alongside
     humans.

     The API Index is premised on this trajectory: bots are becoming
     first-class internet participants, and the infrastructure to support
     them — starting with service discovery — does not yet exist.
     Regulators are converging on the same direction: the EU AI Act
     (Article 50) requires transparency and identity disclosure for AI
     systems that interact with people, and NIST's Center for AI Standards
     and Innovation solicited public input on securing AI agent systems in
     early 2026.  APIX's verifiable trust model is designed to meet these
     emerging compliance requirements by construction.

  1.1.1.  Motivation: A Concrete Origin

     The API Index was not conceived in the abstract.  It emerged from a
     concrete practical failure.

     A buying bot was built for a private use case: monitoring online
     shops for a specific product and purchasing it automatically the
     moment it became available.  This is a straightforward task for an
     autonomous agent — exactly the kind of task agents are well-suited
     for.

     The bot failed, not because the task was technically complex, but
     because the internet's infrastructure is actively hostile to it:




  Rehfeld                 Expires 14 November 2026                [Page 4]


  Internet-Draft                  APIX Core                       May 2026


     *HTML-only product pages.* Product availability, price, and purchase
     state were encoded in HTML rendered for a human eye.  No machine-
     readable API existed.  The bot had to parse HTML — fragile,
     maintenance-intensive, and broken by every redesign.

     *Cloudflare Bot Management and equivalent shields.* The majority of
     commercial web services now sit behind bot mitigation infrastructure.
     Cloudflare Bot Management, and equivalent products from Akamai,
     Imperva, and others, are deployed specifically to detect and block
     non-human request patterns.  Repeated automated requests — even at
     modest frequency — trigger rate limiting, CAPTCHA challenges, or
     silent blocking.  A buying bot that polls a product page to detect
     availability is treated identically to a malicious scraper or a DDoS
     participant.

     *CAPTCHA payment barriers.* Even when product pages were reachable,
     payment flows required solving CAPTCHAs that explicitly excluded non-
     human actors.  The purchasing step — the final, necessary action —
     was deliberately made inaccessible to the bot.

     *Proxy network pollution.* To work around rate limits and bot
     detection, the bot required a rotating proxy network — different IP
     addresses on each request to disguise its automated origin.  This is
     not a solution: it pollutes internet traffic with avoidable requests,
     raises the cost of operation, and contributes directly to the
     adversarial dynamic between bots and infrastructure operators.  Every
     proxy request is a wasted roundtrip that a machine-readable API
     endpoint would have made unnecessary.

     *Polling as the only state-change mechanism.* Because the bot had no
     way to subscribe to product availability events, it had to poll the
     product page continuously.  This is architecturally wasteful: the bot
     consumes server resources and network bandwidth to repeatedly ask a
     question whose answer has not changed.

     These are not edge cases.  They are the standard experience for any
     autonomous agent attempting to consume a commercial internet service
     today.  The buying bot illustrates why the API Index is necessary:
     not as an academic exercise, but as the infrastructure layer that
     makes autonomous agents functional participants in the commercial
     internet.

  1.1.2.  The Discovery Problem

     When an autonomous agent must fulfill a task that requires an
     external service, it faces a fundamental discovery problem: how does
     it find services that can fulfill its requirement?




  Rehfeld                 Expires 14 November 2026                [Page 5]


  Internet-Draft                  APIX Core                       May 2026


     Current approaches are inadequate:

     *  *Hardcoded URLs*: brittle, require human maintenance, do not adapt
        to new or changed services.

     *  *LLM training data*: stale, non-authoritative, not machine-
        verifiable.

     *  *Human-curated lists*: do not scale, not machine-navigable, lack
        structured metadata.

     *  *Web search*: returns HTML documents designed for humans, not
        structured service descriptions for agents.

     What is needed is a machine-native equivalent of a search engine: a
     global, always-current, structured index of services that autonomous
     agents can query by capability, trust level, liveness, and other
     machine-relevant criteria.

  1.1.3.  The Discovery Shift

     Every automated system that calls an external service today does so
     because a human hardcoded that endpoint.  The human is the discovery
     layer — the automation executes instructions, it does not find
     candidates independently.

     APIX addresses this gap at infrastructure level: a globally queryable
     index of services that an agent can search by capability, trust
     level, and liveness — without prior human configuration of the
     specific endpoint.  The agent discovers what exists; the human does
     not need to enumerate it in advance.

  1.1.4.  Infrastructure Efficiency and the Overhead of Human-Facing
          Responses

     When an autonomous agent retrieves data from a web service today, it
     typically receives a response designed for a human browser: HTML
     markup, CSS stylesheets, JavaScript bundles, embedded fonts,
     advertising payloads, and analytics tracking instrumentation.  The
     actual information content — an endpoint URL, a price, an
     availability flag — may occupy two kilobytes.  The page weight
     delivering that content is routinely one to three megabytes.

     This is a 500- to 1500-fold payload multiplier that carries no value
     for a machine consumer.  It consumes bandwidth at the client, compute
     at the server, transit capacity on the network, and — at the scale of
     the growing autonomous agent population — represents a measurable and
     unnecessary energy expenditure.



  Rehfeld                 Expires 14 November 2026                [Page 6]


  Internet-Draft                  APIX Core                       May 2026


     Machine-native APIs eliminate this overhead entirely.  A structured
     JSON response delivers exactly the information the agent requested
     and nothing else.  The IETF Datatracker provides a concrete
     illustration: the human-facing document page for an Internet-Draft
     loads several hundred kilobytes of rendered HTML and supporting
     assets; the equivalent information retrieved via the Datatracker REST
     API returns in under one kilobyte of JSON.  The data is identical.
     The difference is entirely overhead serving a human rendering
     pipeline that a machine does not have.

     APIX addresses both the discovery gap and this efficiency gap
     together.  By providing infrastructure that indexes machine-native
     service endpoints, APIX encourages Service Owners to expose
     structured, agent-consumable APIs alongside or in place of human-
     facing interfaces.  The aggregate effect, as autonomous agent
     workloads scale, is a reduction in the payload overhead carried by
     bot traffic across the internet as a whole.  This is an explicit co-
     mission of APIX: machine-native infrastructure is not only more
     functional for agents — it is more efficient for the internet, and
     helps reduce humanity's environmental footprint as much as possible.

  1.1.5.  Lessons from Prior Art

     The APIX is not the first attempt at a global service registry.
     Prior efforts must be understood explicitly so that their failure
     modes are not repeated.

     *UDDI (Universal Description, Discovery and Integration)* UDDI was a
     SOAP-era standard for a global service registry with the same
     conceptual goal as APIX, published as an OASIS Committee Draft in
     October 2004.  It failed for three reasons: (1) extreme complexity of
     the XML-based data model; (2) no automatic verification — all data
     was self-asserted with no crawling or validation; (3) no adoption
     incentive — there was no commercial model to sustain registration or
     discovery.  APIX addresses all three directly: a simple JSON
     manifest, automated spider verification, and a commercial tier model.

     *robots.txt (Robots Exclusion Protocol)* Machine-readable, but
     concerned with exclusion — telling crawlers what not to access — not
     with discovery of capabilities.  Per-domain only.  Not a registry.

     *MCP (Model Context Protocol)* Defines tool and capability
     descriptions for LLM-based agents.  Excellent for consumption once a
     server URL is known.  Does not address the discovery problem: there
     is no index of MCP servers.  APIX is complementary to MCP — it can
     index MCP servers as one supported spec type.  As of December 2025,
     MCP is governed by the Linux Foundation Agentic AI Foundation
     ([AAIF]), under a vendor-neutral SEP (Specification Enhancement



  Rehfeld                 Expires 14 November 2026                [Page 7]


  Internet-Draft                  APIX Core                       May 2026


     Proposal) process that explicitly prevents single-company control — a
     governance philosophy that directly aligns with APIX's own neutrality
     requirements.

     *Well-Known URIs (RFC 8615)* Per-domain machine-readable metadata at
     /.well-known/. Useful for per-service metadata but requires the
     consumer to already know the domain.  No cross-service search or
     global index.

     *DNS* DNS resolves names to addresses but carries no capability
     semantics.  It is an architectural analogy for APIX's federation
     model, not a comparable system.

  1.1.6.  Related IETF and W3C Work

     As of April 2026, the number of Internet-Drafts working in adjacent
     areas of agent/bot infrastructure has grown significantly.  None
     addresses the same problem as APIX.  This section documents each and
     states the relationship explicitly.

     *draft-pioli-agent-discovery (ARDP)* Proposes a federated agent
     registration and discovery protocol.  Deliberately decentralised — no
     global registry mandate, no central query URL.  Relationship to APIX:
     complementary.  ARDP addresses agent-to-agent capability
     advertisement within a federation.  APIX addresses global, cross-
     organisation service discovery from a neutral central index.  ARDP's
     JWS-based signing of registration payloads provides cryptographic
     non-repudiation of the manifest content — a property APIX currently
     achieves through layered governance verification (DNS ownership proof
     at O-1, Spider crawl, KYC pipeline).  APM manifest-level signing is a
     candidate extension for a future APIX revision, and ARDP's signing
     model is the reference design for that work.



















  Rehfeld                 Expires 14 November 2026                [Page 8]


  Internet-Draft                  APIX Core                       May 2026


     *draft-narajala-courtney-ansv2 (ANS v2)* Anchors autonomous agent
     identities to DNS domain names with Registration Authority
     verification.  Focused on agent identity and trust anchoring, not
     service capability discovery.  ANS v2 builds on a peer-reviewed
     predecessor published at IEEE ICAIC 2026, simplifying the name format
     to three components (ans://v{version}.{agentHost}), introducing a
     dual-certificate model, and replacing conceptual registry integrity
     with a cryptographic Transparency Log. ANS v2 explicitly identifies
     the limitation of DNS-SD ([RFC6763]): DNS-SD adds service discovery
     but cannot tell a client whether the agent at an address is the one
     it claims to be.  ANS v2 fills that identity gap.  Relationship to
     APIX: complementary.  DNS-SD locates a service; ANS v2 verifies the
     identity of the agent at that address; APIX provides capability
     search and multi-dimensional trust metadata across organisations.
     ANS v2 could serve as the identity layer for service operators
     registered in APIX.

     *draft-vandemeent-ains-discovery (AINS)* Agent discovery via signed,
     append-only replication logs.  No central authority.  No commercial
     sustainability model.  Relationship to APIX: different philosophy.
     AINS prioritises decentralisation and cryptographic verifiability.
     APIX prioritises a single authoritative global index with a governed
     trust model.

     AINS defines a multi-channel verification model in which each
     verified channel produces an independent evidence object.  The
     principle is sound: independent signals from multiple channels
     produce stronger identity assurance than any single channel alone.
     AINS names DNS, HTTPS, and email as verification channels — all of
     which are compatible with APIX's own trust evidence model (DNS TXT
     record at O-1, HTTPS-reachable manifest verified by the APIX Spider).
     AINS additionally names source code repositories (e.g., GitHub) as a
     verification channel.  APIX does not adopt repository access as an
     evidence channel.  For open-source projects and developer platforms
     this channel is accessible and useful; however, the majority of
     enterprise API services — financial institutions, healthcare
     providers, manufacturers, and proprietary IoT backends — maintain
     private repositories as protected intellectual property, often under
     regulatory or contractual obligations that prohibit external access.
     APIX's governance-based evidence channels (DNS, legal entity
     registration, commercial contract, third-party audit) apply
     universally regardless of whether a registrant's codebase is open-
     source or proprietary, and this universality is a deliberate scope
     decision.

     *draft-aiendpoint-ai-discovery (AI Discovery Endpoint)* Defines
     /.well-known/ai as a per-host machine-readable capability document.
     Per-domain only; not a global index.  Relationship to APIX: directly



  Rehfeld                 Expires 14 November 2026                [Page 9]


  Internet-Draft                  APIX Core                       May 2026


     complementary.  The APIX Spider SHOULD read /.well-known/ai when
     present on a registered service's domain as an additional source of
     capability metadata.

     This draft defines a flat category taxonomy for service
     classification: "productivity", "ecommerce", "finance", "news",
     "weather", "maps", "search", "data", "communication", "calendar",
     "storage", "media", "health", "education", "travel", "food",
     "government", "developer".  The convergence with APIX's capability
     taxonomy is notable: search, communication, storage, and media appear
     in both; ecommerce and finance correspond directly to APIX's commerce
     and data.financial terms.  The two taxonomies differ in architecture
     — AI Discovery Endpoint uses flat single-word labels optimised for
     human-readable classification; APIX uses hierarchical dot-separated
     terms (commerce.marketplace, data.financial) optimised for machine-
     queryable precision — but the independent convergence on the same
     fundamental service categories validates both approaches.  Categories
     present in AI Discovery Endpoint but not yet in APIX's v1.0 starter
     set (health, education, government, travel, food, news, weather,
     maps, developer) are candidates for future additions through the
     governing body's capability taxonomy governance process
     ([APIX-SERVICES]).

     *draft-batum-aidre (AIDRE)* Defines /.well-known/ai-discovery as a
     per-origin discovery document.  Decentralised by design.
     Relationship to APIX: complementary.  APIX provides the global
     aggregation and trust verification layer that per-origin endpoints
     cannot provide alone.

     *draft-cui-ai-agent-discovery-invocation* Specifies a metadata format
     for agent capabilities and a registry-based discovery mechanism.
     Explicitly permits multiple coexisting registries; no global
     authority defined.

     This draft introduces a notable split between two metadata fields:
     capabilities (high-level descriptors of what the service does, e.g.,
     ["translation", "summarization"]) and tags (broader, orthogonal
     properties such as domain, language support, or deployment model,
     e.g., ["nlp", "chinese", "transformer_model", "cloud"]).  The split
     recognises that some service properties are functional capabilities
     while others are orthogonal classifiers that do not fit a strict
     capability hierarchy.

     APIX takes a different approach.  The hierarchical dot-separated
     capability taxonomy (nlp.translation, commerce.marketplace) encodes
     both the category and the specific capability in a single governed
     term, enabling prefix-based machine queries (nlp.*) and registry-
     controlled vocabulary.  Orthogonal dimensions that draft-cui



  Rehfeld                 Expires 14 November 2026               [Page 10]


  Internet-Draft                  APIX Core                       May 2026


     expresses as free-form tags are handled in APIX through dedicated
     typed fields: language (BCP 47, [RFC5646]) covers language support;
     deployment model is not yet represented and is noted as a potential
     future gap.  The APIX design trades the flexibility of a free-form
     tag bag for machine-queryability and governance — a tag field without
     a registry becomes a folksonomy that degrades search precision at
     scale.  An empirical basis for preferring intent-aligned capability
     descriptors over opaque operation labels is provided by the
     controlled benchmark study in [I-D.hood-agtp-api], which demonstrates
     that intent-aligned names produce materially higher endpoint
     selection accuracy in frontier-class language models, with the
     accuracy gain attributable to the name itself independent of
     additional documentation.

     This draft also identifies pricing information as a legitimate
     service metadata concern — noting that if a service charges per use,
     agents need this information at discovery time.  The draft does not
     standardise a pricing schema ("not standardized here but can be
     included as needed").  APIX adopts this observation and formalises
     it: the pricing field in the APM schema ([APIX-SERVICES]) defines a
     governed model enum (free, freemium, paid, enterprise, dynamic) and a
     pricing_endpoint for real-time load-based price queries.  The index
     stores only the declared model and the endpoint reference; consuming
     agents are responsible for querying the pricing_endpoint directly to
     obtain and evaluate the current price before invocation.

     This draft also defines a Semantic Routing Platform (SRP): an
     optional control-plane service that performs semantic matching,
     ranking, and policy-based filtering of candidate agents before
     invocation, without participating in task execution.  The SRP pattern
     assumes a structured candidate pool as its input.  APIX is the
     natural data source for that pool: an SRP would query APIX with
     structured filters to retrieve a trusted, governed candidate set,
     then apply semantic ranking over that set before presenting the
     shortlist to the invoking agent.  The two layers are complementary —
     APIX provides structured discovery and trust metadata; the SRP
     provides semantic selection above that foundation.

     Relationship to APIX: partially overlapping problem space.  The
     capability/tag split, the pricing observation, and the SRP pattern
     are all concrete design contributions; APIX's governed taxonomy,
     typed fields, and formalised pricing schema address the same concerns
     through a more structured mechanism, and the SRP architecture
     positions APIX as the structured input layer to semantic selection
     rather than as a competitor to it.






  Rehfeld                 Expires 14 November 2026               [Page 11]


  Internet-Draft                  APIX Core                       May 2026


     *draft-am-layered-ai-discovery-architecture* Proposes a conceptual
     two-layer architecture separating a Discovery Transport Layer (DTL)
     from the metadata format carried over it.  The DTL is explicitly
     abstract: the draft names HTTP, pub/sub, multicast, and MoQ as
     candidate substrates without specifying any of them normatively.  No
     wire format, no concrete protocol mechanisms, and no IANA actions are
     defined.

     APIX resolves the transport question concretely and normatively:
     HTTPS with TLS ([RFC8446]), JSON ([RFC8259]), and HATEOAS navigation
     over a single stable entry point.  This is a deliberate design
     position in favour of implementability over substrate generality.
     Adding a DTL abstraction layer atop APIX's concrete HTTP interface
     would introduce indirection without communicative or interoperability
     benefit — the transport is already specified, and no agent
     implementation benefits from treating it as one option among many.

     Directly relevant to APIX is the draft's categorisation of
     discoverable object types (agents, models, data resources, robots),
     which recognises that different object categories require different
     metadata profiles.  This independently converges on the same
     architectural reasoning behind APIX's decision to separate the
     Services Profile ([APIX-SERVICES]) from the IoT Device Profile
     ([APIX-IOT]) rather than collapsing all service types into a single
     flat schema.

     Relationship to APIX: categorisation framing is consistent with the
     APIX profile split; the abstract DTL layer is not adopted.

     *AGTP Protocol Family*

     The Agent Transfer Protocol (AGTP) defines a dedicated agent-native
     protocol substrate, distinct from HTTP, with an IANA-registered URI
     scheme (agtp://) and port 4480, media types in expert review, and
     live reference servers at agtp://agents.agtp.io.  The AGTP family
     currently comprises four drafts.

     [I-D.hood-independent-agtp] is the core transport substrate.  The
     defining architectural commitment of the family is that agent-native
     APIs operate on AGTP rather than HTTP.

     [I-D.hood-agtp-discovery] defines an Agent Name Service (ANS) — a
     governed registry that resolves capability queries into ranked lists
     of Agent Manifest Documents for authenticated agents.  ANS servers
     act as Scope-Enforcement Points, applying trust score thresholds,
     trust tier requirements, and governance zone constraints.  Cross-
     organisational discovery is supported through peer ANS server
     federation.



  Rehfeld                 Expires 14 November 2026               [Page 12]


  Internet-Draft                  APIX Core                       May 2026


     [I-D.hood-agtp-api] defines the Agentic API contract layer: a curated
     method catalog of intent-aligned verbs (QUERY, EXECUTE, PROPOSE,
     DISCOVER, and eight additional methods), endpoint primitives carrying
     semantic contracts, path grammar rules, and schema validation.  The
     draft introduces a runtime contract negotiation mechanism via the
     PROPOSE method: a consuming agent may propose an endpoint that does
     not exist, and the serving system synthesises it from its existing
     capabilities at session scope.  The intent-aligned method vocabulary
     is grounded in a controlled empirical benchmark across four frontier-
     class model families showing that intent-aligned verbs produce
     materially higher endpoint selection accuracy than CRUD verbs, with
     description-swap ablations confirming that the accuracy gain is
     attributable to the method name itself independent of documentation
     quality.

     [I-D.hood-agtp-trust] defines a three-tier verification model with
     three independent Tier 1 verification paths (DNS-anchored per RFC
     8555, log-anchored per RFC 9162, and SCITT per RFC 9943), hybrid
     trust composition, and a normative 0.0-1.0 continuous trust score
     with freshness semantics that are operation-class-dependent.

     Relationship to APIX: overlapping problem space, fundamentally
     different architectural commitment.  The AGTP family's defining
     premise is that agent-native services should operate on a dedicated
     off-HTTP protocol substrate.  APIX's defining premise is that the
     discovery layer should operate over existing HTTP infrastructure with
     zero adoption friction: any service already reachable over HTTP
     registers in APIX without changing its underlying protocol.  These
     are not competing answers to the same deployment question; they
     address different positions in the adoption spectrum.  AGTP targets
     greenfield services designed for agent-native operation from scratch;
     APIX targets the full landscape including existing HTTP/REST APIs,
     MCP-served models, IoT backends, and enterprise systems that will not
     migrate off HTTP for operational, legal, or contractual reasons.

     Three specific alignments are worth noting.  First, the AGTP trust
     tier evidence paths (DNS per RFC 8555, transparency log per RFC 9162,
     SCITT per RFC 9943) are structurally analogous to APIX's O-level
     evidence channels (DNS TXT record at O-1, GLEIF LEI database at O-2,
     independent audit at O-5); a shared trust evidence vocabulary between
     the two specifications would benefit consuming agents that interact
     with both.  Second, the AGTP PROPOSE method — server-side synthesis
     of non-existent endpoints from existing capabilities at session scope
     — has no current analogue in APIX and is identified as a candidate
     area for future dynamic capability negotiation.  Third, the empirical
     finding on intent-aligned method names in [I-D.hood-agtp-api]
     provides an independent quantitative basis for APIX's capability
     taxonomy design: APIX capability terms (nlp.translation,



  Rehfeld                 Expires 14 November 2026               [Page 13]


  Internet-Draft                  APIX Core                       May 2026


     commerce.marketplace) are intent-aligned descriptors rather than
     CRUD-style operation labels, and the benchmark result supports that
     design choice.

     *draft-mozley-aidiscovery (AI Agent Discovery Problem Statement)*
     Argues for a distributed, organisation-centric discovery model in
     which each organisation independently publishes agent capabilities at
     a well-known entry point.  The draft explicitly opposes centralised
     registries on two grounds: single points of failure limiting
     resilience, and the competitive harm risk — stated directly as: "An
     adversarial centralized directory is also able to stifle competitor
     advertisement capabilities."  The scope is cross-organisational; the
     draft addresses public, multi-domain agent discovery, not only local
     or intra-organisation scenarios.

     Relationship to APIX: this draft articulates the strongest counter-
     position to APIX's architecture, and the adversarial directory
     argument deserves a direct response.  APIX addresses it structurally:
     the neutrality requirements (Section 4.2), the prohibition on ranking
     preferences and preferential treatment, the independent governance of
     the standard from the commercial operation, and the mandatory open
     bulk data download are specifically designed to make the adversarial
     scenario impossible by construction.  A directory operated under
     these constraints cannot stifle competitor advertisement because it
     cannot discriminate between registrants at the same commercial tier.

     The distributed model's remaining gap, which APIX addresses, is the
     zero-prior-knowledge case: an agent that has no prior relationship
     with any service provider needs a single starting point from which to
     discover unknown third parties.  An organisation-centric model
     requires the discovering agent to already know which organisations to
     query — which presupposes the discovery problem is already solved.

     *draft-mozleywilliams-dnsop-dnsaid (DNS for AI Discovery)* Proposes
     DNS-AID: using SVCB records to publish agent service endpoints.
     Relationship to APIX: complementary at the infrastructure layer.  The
     distinction across the three systems is precise: DNS-AID tells a
     client where to connect; ANS v2 ([I-D.narajala-courtney-ansv2]) tells
     it whether to trust the agent at that address; APIX tells it what to
     connect to and why — capability search, multi-dimensional trust
     metadata, and liveness verification across the global service
     landscape.









  Rehfeld                 Expires 14 November 2026               [Page 14]


  Internet-Draft                  APIX Core                       May 2026


     *draft-meunier-webbotauth-registry (webbotauth)* Defines a JSON-based
     "Signature Agent Card" format for bot authentication.  Focused on bot
     identity — how a bot proves who it is to a service.  Related to the
     active webbotauth IETF Working Group.  Relationship to APIX:
     orthogonal but complementary. webbotauth addresses bot consumer
     identity; APIX addresses service provider discovery.

     *I-D.ietf-scitt-architecture (SCITT)* Defines an append-only
     transparency service for supply chain integrity, transparency, and
     trust.  An IETF WG specification ([I-D.ietf-scitt-architecture]).
     SCITT provides a tamper-evident, auditable ledger model where
     statements about artefacts are registered and independently
     verifiable.  Relationship to APIX: architectural reference.  APIX's
     audit trail for organisation trust level progressions, LER
     submissions ([APIX-IOT]), and sanctions screening events follows the
     same append-only, non-repudiable model that SCITT formalises.  ANS v2
     ([I-D.narajala-courtney-ansv2]) bases its Transparency Log on SCITT.
     A future revision of APIX MAY adopt SCITT-compliant transparency log
     semantics for its governance audit trail.

     *Google Cloud Fraud Defense* A commercial trust platform for the
     agentic web announced at Google Cloud Next '26 (April 2026),
     positioned as the next evolution of reCAPTCHA.  Fraud Defense
     explicitly integrates with the webbotauth IETF Working Group and
     SPIFFE for agent and workload identity classification.  Relationship
     to APIX: complementary at adjacent layers.  Fraud Defense operates at
     the consumption layer — it verifies and classifies agent traffic
     arriving at a service endpoint.  APIX operates at the discovery layer
     — it provides the service index, trust metadata, and capability
     taxonomy that agents use to locate services before interacting with
     them.  The two systems are not competitive; a Fraud Defense policy
     engine can consume APIX trust signals (O-level, S-level) as inputs to
     its risk scoring.

     *SPIFFE (Secure Production Identity Framework For Everyone)* A CNCF
     open standard for workload identity attestation.  Provides
     cryptographically verifiable identities (SVIDs) to software workloads
     in dynamic infrastructure.  Referenced as an integration target by
     Google Cloud Fraud Defense alongside webbotauth.  Relationship to
     APIX: complementary at the identity layer.  SPIFFE addresses machine/
     workload identity; APIX addresses service and device discovery with
     human-governed trust levels.  A SPIFFE SVID could serve as a
     technical credential for an agent whose operator is registered in
     APIX at O-2 or above.







  Rehfeld                 Expires 14 November 2026               [Page 15]


  Internet-Draft                  APIX Core                       May 2026


     *W3C AI Agent Protocol Community Group* Proposed May 2025, targeting
     agent interoperability protocols.  Pre-specification as of this
     writing.  Relationship to APIX: APIX will monitor this group's
     outputs and align the APM capability taxonomy with any vocabulary
     standardised by the W3C CG where applicable.

     *Agent2Agent Protocol (A2A)* Defines a secure communication protocol
     for agent-to-agent interaction across frameworks [A2A].  Originated
     at Google (April 2025), transferred to the Linux Foundation Agentic
     AI Foundation ([AAIF]) in June 2025; as of early 2026 it has 150+
     supporting organisations and is in production use.  Relationship to
     APIX: directly complementary.  A2A addresses how agents communicate
     once they have located each other.  APIX addresses how agents locate
     each other in the first place.  An agent that uses APIX for discovery
     and A2A for subsequent communication is using both systems for their
     intended purpose with no overlap.

     *AGNTCY (Open Agent Schema Framework)* A multi-component open
     infrastructure project for multi-agent systems [AGNTCY], originating
     at Cisco and transferred to the Linux Foundation ([AAIF]) in July
     2025.  As of early 2026 it has 65+ supporting organisations and is in
     production use for CI/CD, IT automation, and telecommunications.
     AGNTCY comprises four components: the Open Agent Schema Framework
     (OASF) for capability discovery, cryptographic identity, SLIM
     messaging, and end-to-end observability.  AGNTCY is governed under
     the Linux Foundation AAIF mandate of no single-company control.

     Relationship to APIX: the governance philosophies are aligned; the
     architectural scope is different.  OASF defines a capability schema
     format — analogous to OpenAPI for agent capabilities — for
     registering and advertising what an agent can do.  APIX is a globally
     queryable index infrastructure: a single authoritative entry point
     where agents discover unknown third-party services by capability,
     with commercial sustainability, verified trust metadata, and
     structured search.  OASF and APIX are complementary: OASF provides
     the schema language; APIX provides the global index that can be
     populated with OASF-described services.  An AGNTCY-registered agent
     is a candidate APIX registrant.  The principal architectural
     difference is scope: AGNTCY is optimised for intra-platform and
     intra-organisation agent coordination; APIX is designed for cross-
     organisation, cross-border, zero-prior-knowledge discovery of agent-
     consumable services and IoT device classes.  The two systems address
     different points in the discovery spectrum and are not substitutes
     for each other.

     *draft-drake-agent-identity-registry (Agent Identity Registry)*
     Defines a federated registry architecture for persistent, hardware-
     anchored agent identities.  Introduces a three-tier model: Agent



  Rehfeld                 Expires 14 November 2026               [Page 16]


  Internet-Draft                  APIX Core                       May 2026


     Identity Authority (AIA) as a governance body, Registry Operators as
     authoritative identity databases, and Registrars for hardware
     attestation and OIDC token issuance.  The AIA is explicitly required
     to be constituted as a multi-stakeholder body — the draft states
     directly that "single-entity control would undermine the federated
     design" ([I-D.drake-agent-identity-registry]).

     Relationship to APIX: this draft provides the strongest independent
     validation of APIX's core governance premise.  Two separate
     specifications, developed independently, arrive at the same
     structural requirement: that foundational agent infrastructure must
     be governed by a multi-stakeholder body, not controlled by a single
     entity.  The functional domains are complementary rather than
     overlapping — draft-drake addresses agent identity (who is this
     agent, which hardware backs its credential); APIX addresses service
     discovery (what services exist, what can they do, are they
     trustworthy).  An agent whose identity is established under draft-
     drake's AIA model is a well-suited candidate to consume and register
     services in APIX.

     *Linux Foundation Agentic AI Foundation (AAIF)* Formed December 2025
     with founding contributions from Anthropic (MCP), OpenAI (AGENTS.md),
     and Block (goose); additional members include AWS, Bloomberg,
     Cloudflare, Google, Cisco, Dell, Oracle, and Red Hat. The AAIF's
     explicit founding mandate is to ensure "no single company controls
     the direction of foundational infrastructure" ([AAIF]), implemented
     through a vendor-neutral directed fund structure and per-project
     Specification Enhancement Proposal (SEP) processes modelled on
     Kubernetes's KEP governance.

     Relationship to APIX: the AAIF's governance mandate independently
     validates APIX's constitutional neutrality requirements.  APIX
     predates the AAIF as an IETF submission and implements the same
     principle — no single commercial interest may control the standard or
     its operation — through a different structural mechanism: a Swiss
     Stiftung with a supply-side commercial model that funds operations
     without creating discovery-layer incentives to favour any registrant.
     The AAIF governs communication and invocation protocols (MCP, A2A);
     APIX governs the discovery index.  These are adjacent, non-
     overlapping layers of the same infrastructure stack.











  Rehfeld                 Expires 14 November 2026               [Page 17]


  Internet-Draft                  APIX Core                       May 2026


     *Positioning* The agent infrastructure space has consolidated
     significantly in 2025-2026.  At the protocol layer, the Linux
     Foundation AAIF has emerged as the primary governance body for
     communication and invocation standards (MCP, A2A), with 150+
     supporting organisations and active production deployment.  At the
     IETF, over a dozen individual drafts address agent discovery and
     identity from different architectural starting points; none has
     reached Working Group consensus.

     APIX occupies a distinct position in this landscape: it is the only
     specification in the IETF space that makes governance the primary
     architectural requirement, and the only proposal for a globally
     queryable, commercially sustainable, neutral discovery index.  The
     dominant IETF tendency toward decentralisation addresses legitimate
     concerns about single points of control; APIX answers those concerns
     structurally, through its neutrality mandates, open bulk data
     requirements, and separation of standard governance from commercial
     operation — rather than by abandoning the global index model that
     those concerns are directed at.

     APIX is designed to compose with, not replace, the adjacent
     standards: APIX provides the discovery layer that MCP, A2A, and
     AGNTCY do not provide; draft-drake provides the identity layer that
     APIX delegates to external identity infrastructure; the webbotauth
     Working Group provides the bot authentication layer that APIX
     references as a trust signal.  Each standard goes deep in its own
     sub-problem; APIX depends on that depth rather than duplicating it.

     The AGTP protocol family represents a distinct architectural
     trajectory: a dedicated agent-native transport substrate (agtp://)
     that replaces HTTP rather than extending it.  APIX and AGTP are not
     substitutes and the distinction is one of adoption scope, not
     superiority.  AGTP is the invocation substrate for greenfield
     services designed from scratch; APIX is the discovery index for the
     full existing service landscape, including the large majority of
     deployable services that will not migrate off HTTP in any planning
     horizon relevant to agent infrastructure standardisation.

  1.2.  Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in [RFC2119].

     All API responses MUST be encoded as UTF-8 as mandated by [RFC8259]
     Section 8.1.  All string fields in APM documents and Index API
     responses MUST contain valid UTF-8.  HTTP status codes used
     throughout this specification are defined in [RFC9110].



  Rehfeld                 Expires 14 November 2026               [Page 18]


  Internet-Draft                  APIX Core                       May 2026


     *Agent* An autonomous software program that executes complex, goal-
     directed tasks by consuming external services, without per-action
     human instruction.  Agents may use LLM-backed or programmatic
     orchestration logic.  The primary consumer class targeted by the APIX
     Index API.

     *Bot* An autonomous software program that executes deterministic,
     rule-based internet tasks: web crawling, API polling, automated
     messaging, without per-action human instruction.  Behavior is
     scripted rather than goal-directed.  The APIX Spider is itself a bot.

     *Connected Device* A physical or embedded hardware unit with network
     connectivity that exposes services or sensor data via the APIX
     Presence Protocol.  Registered as a Device Class and tracked as a
     Device Instance as defined in [APIX-IOT].  Distinct from Agent and
     Bot in that the principal is hardware, not software.

     *Service* A machine-consumable API or connected device class offered
     by an organisation, registered in the APIX, and described by an APIX
     Manifest.  The term covers both web API services ([APIX-SERVICES])
     and IoT device services ([APIX-IOT]).

     *Service Owner* The organisation responsible for registering,
     maintaining, and operating a Service in the APIX.

     *APIX Manifest (APM)* The structured metadata document that describes
     a Service to the APIX, including its technical specification
     reference, capability taxonomy, trust metadata, and commercial terms.
     Profile documents define the additional fields applicable to each
     service type.

     *Governing Body* The neutral, non-profit entity that operates the
     APIX, maintains its registries, accredits Regional Representatives
     and Verifiers, and ensures the governance and operational
     requirements defined in this specification are met.  Any entity that
     satisfies those requirements MAY fulfil this role.

     *API Index (APIX)* The global, centralised index of registered
     Services, operated by the governing body and queryable by autonomous
     agents via the Index API.

     *Index API* The HATEOAS-compliant HTTP API exposed by the APIX for
     agent discovery and navigation.

     *Accredited Verifier* A trusted third-party organisation, accredited
     by the governing body, that performs human-intensive trust
     verification at Organisation levels O-4 and O-5.




  Rehfeld                 Expires 14 November 2026               [Page 19]


  Internet-Draft                  APIX Core                       May 2026


     *Accredited Regional Representative* An organisation accredited by
     the governing body to operate commercial onboarding, contracting, and
     customer relationships within a defined geographic jurisdiction,
     under the governing body's standard and governance.

     *Trust Policy* A set of minimum trust requirements expressed by a
     consuming agent that a Service must satisfy before the agent will use
     it.

     *Liveness* The confirmed operational status and response availability
     of a Service, as measured by automated means at a frequency
     determined by the Service's commercial tier.  The specific liveness
     mechanism differs by service type: Spider health checks for web API
     services; presence signals for IoT device services.

     *Tier* A commercial subscription level that determines a Service's
     visibility in the APIX, liveness check frequency, and API query rate
     allocation.

  1.3.  Design Goals

  1.3.1.  Requirements (MUST)

     *  The APIX MUST be queryable by autonomous agents via a stable,
        globally accessible URL without prior knowledge of any specific
        service.

     *  The Index API MUST follow HATEOAS principles: agents MUST be able
        to navigate the full index starting from a single entry-point URL.

     *  Every Service record MUST expose machine-readable trust metadata
        across all three trust dimensions (Organisation, Service,
        Liveness).

     *  Service registration MUST be human-initiated.  The registrant MUST
        agree to the index operator's Terms of Service before any service
        record is activated.  For O-0 and O-1, self-service portal
        registration with accepted Terms of Service satisfies this
        requirement.  For O-2 and above, registration MUST additionally
        involve a formal B2B contractual relationship between the Service
        Owner and the index operator or its Accredited Regional
        Representative.

     *  The APIX MUST expose trust metadata as verifiable facts, not as
        recommendations.  Trust decisions MUST remain with the consuming
        agent.





  Rehfeld                 Expires 14 November 2026               [Page 20]


  Internet-Draft                  APIX Core                       May 2026


     *  The APIX Manifest (APM) MUST be format-agnostic: it MUST support
        referencing multiple service types via an extensible type
        registry.

     *  The APIX MUST be operated as a neutral, non-profit infrastructure
        under the governance of the governing body.

  1.3.2.  Goals (SHOULD)

     *  The Index API SHOULD support full-text and structured search by
        capability, category, organisation trust level, service
        verification level, liveness freshness, and protocol type.

     *  The APIX SHOULD provide SDKs in common agent development languages
        to lower the integration barrier for consuming agents.

     *  The APIX SHOULD support a federated accredited verifier model so
        that Organisation trust levels O-4 and O-5 can be verified at
        scale without centralising all human review in the governing body.

     *  Accredited Regional Representatives SHOULD be established in major
        jurisdictions to allow Service Owners to contract in their local
        language and legal framework.

     *  The APIX SHOULD publish a public transparency report at least
        annually, disclosing the number of registered services by tier and
        trust level, coverage statistics, and verifier accreditation
        status.

     *  The APIX SHOULD, through its verification model and tier
        structure, incentivise Service Owners to expose structured,
        machine-consumable API endpoints rather than requiring agents to
        adapt to human-facing HTML interfaces.  Eliminating rendering,
        styling, and advertising overhead from machine-to-machine
        communication is an explicit efficiency objective of this
        infrastructure.

  1.3.3.  Out of Scope

     The following are explicitly not addressed by this document.  Items
     marked MUST NOT are normative constraints on conforming
     implementations; remaining items are editorial scope boundaries.

     *  *Bot identity and authentication*: how a bot proves its own
        identity to a service it consumes.  This is addressed by
        complementary work such as draft-meunier-webbotauth-registry.
        This document takes no position on bot identity mechanisms.




  Rehfeld                 Expires 14 November 2026               [Page 21]


  Internet-Draft                  APIX Core                       May 2026


     *  *Bot rights and legal personhood*: outside the scope of a
        technical infrastructure standard.

     *  *Service execution*: a conforming APIX implementation MUST NOT
        proxy, mediate, or execute service calls on behalf of consuming
        agents.  The APIX is a discovery layer only; all service
        interactions occur directly between the consuming agent and the
        Service Owner's infrastructure.

     *  *Content indexing*: a conforming APIX implementation MUST NOT
        index service response content.  The APIX indexes service metadata
        — capability declarations, trust levels, liveness signals — not
        the data that services return when called.

     *  *Mandatory consumer registration*: a conforming APIX
        implementation MUST NOT require consuming agents to register or
        identify themselves as a condition of performing discovery queries
        (see Section 9.2).

  1.4.  Architecture Overview

  1.4.1.  Component Model





























  Rehfeld                 Expires 14 November 2026               [Page 22]


  Internet-Draft                  APIX Core                       May 2026


       +----------------------------------------------------------+
       |                   the governing body                     |
       |             (Swiss Stiftung -- neutral, non-profit)      |
       |  Owns: APIX standard, Index infrastructure, APM format   |
       |  Accredits: Regional Representatives, Verifiers          |
       +---------------------+------------------------------------+
                             |
             +---------------+-------------------+
             |               |                   |
       +-----+------+  +-----+--------+  +-------+---------+
       |   Index    |  | Verification |  |  Registration   |
       |   API      |  | Component    |  |    Portal       |
       | (HATEOAS)  |  |(type-specific|  |  (B2B / human)  |
       +-----+------+  +-----+--------+  +-------+---------+
             |               |                   |
             |         +-----+------+            |
             |         |  Service   |            |
             +-------->|  Record    |<-----------+
                       |  Store     |
                       +------------+
             ^                              ^
             |                              |
       +-----+------+              +--------+-----------+
       |  Consuming |              |   Service Owner    |
       |    Agent   |              |  (+ Accredited     |
       |    (Bot)   |              |  Regional Rep)     |
       +------------+              +--------------------+

     This document uses the generic terms "governing body" and "index
     operator" in all normative requirements.  These terms are
     intentionally role-based: any entity that satisfies the governance,
     neutrality, and operational requirements defined in this
     specification MAY fulfil them.  The reference implementation of these
     roles is described in the non-normative appendix "Reference
     Implementation" at the end of this document.

     *Flow:*

     1.  A Service Owner (or their Accredited Regional Representative)
         creates an Organisation Account in the APIX Registration Portal,
         providing company details and agreeing to a commercial contract.

     2.  The Registration Portal creates a draft Service Record and
         triggers profile-appropriate verification (Spider crawl for web
         API services; manufacturer provisioning for IoT device classes).

     3.  The verification component updates the Service Record with
         verified technical metadata.



  Rehfeld                 Expires 14 November 2026               [Page 23]


  Internet-Draft                  APIX Core                       May 2026


     4.  The Service Record becomes queryable via the Index API.

     5.  A consuming agent queries the Index API from the single entry-
         point URL, navigates by HATEOAS links, applies its Trust Policy,
         and selects services that satisfy its requirements.

     6.  Verification rechecks services on the schedule defined by each
         service's liveness monitoring configuration.

  1.4.2.  Governance Model

     The APIX MUST be operated by a *neutral governing body* that
     satisfies the following normative requirements.  These requirements
     apply to any conforming APIX implementation; the specific legal form
     of the governing body is an implementation choice.

     *Neutrality requirements:*

     *  The governing body MUST have no commercial interest in preferring
        any registrant's services over another in index results or
        liveness scheduling.

     *  The governing body MUST NOT offer exclusive discovery advantages,
        ranking preferences, or prioritised verification treatment to any
        registrant regardless of commercial relationship.

     *  Governance of the APIX standard and APM specification MUST be
        separated from operation of the commercial index.  A single entity
        may not simultaneously control standard evolution and derive
        commercial benefit from preferential application of that standard.

     *Operational requirements:*

     *  The governing body MUST accredit Regional Representatives who may
        handle service onboarding in specific jurisdictions.  Regional
        Representatives operate under licence from the governing body; the
        index itself remains a single global store.

     *  The governing body MUST accredit Verifiers who perform
        Organisation trust assessments at O-4 and O-5.  Accredited
        Verifiers are structurally analogous to Certificate Authorities in
        the TLS ecosystem.

     *  The governing body MUST maintain the capability taxonomy and
        publish all versions of the APM specification and Index API
        specification as open standards under a permissive licence.





  Rehfeld                 Expires 14 November 2026               [Page 24]


  Internet-Draft                  APIX Core                       May 2026


     *  The governing body MUST perform sanctions screening on service
        registrants (see Section 8).

     *Openness requirements:*

     *  The full index MUST be made available as a freely downloadable
        bulk dataset on the first day of each calendar month, under the
        Open Database Licence (ODbL) 1.0.  No entity, including the
        governing body, may hold an exclusive lock on the index data.

     *  Incremental diff files MUST be published daily, each covering all
        record additions, updates, and deletions since the previous day's
        snapshot.  A downstream consumer MUST be able to reach current
        index state by applying the monthly full snapshot and the sequence
        of daily diffs since that snapshot, without downloading any
        additional full snapshots.

     *  Discovery queries to the Index API MUST be available without
        authentication or payment (subject to rate limits; see
        Section 9.2).

  1.4.2.1.  Global Participation

     A conforming APIX implementation SHOULD establish mechanisms to
     ensure global representation in the capability taxonomy, including
     service categories relevant to underrepresented regions.  Where
     regional institutional partners are willing to co-sponsor regional
     participation, the governing body SHOULD establish formal co-
     sponsorship relationships and associated governance representation
     for those regions.

     Regional verification nodes are RECOMMENDED in regions with
     significant service registrant populations to eliminate
     intercontinental latency in liveness verification.

  1.4.3.  Standard Registries

     The APIX standard maintains normative registries of enumerated
     values.  Registries are authoritative lists of valid values for
     specific APM and Index API fields.  Using values not present in the
     relevant registry is a protocol violation.

     *Registry location:* Registries are published as live JSON endpoints
     at apix.example.org/registry/ and are updated independently of the
     RFC revision cycle.  The RFC defines the registry structure and
     lifecycle rules; the live endpoints are the authoritative source of
     current values.




  Rehfeld                 Expires 14 November 2026               [Page 25]


  Internet-Draft                  APIX Core                       May 2026


     protocols  Protocol type registry.  Endpoint:
        apix.example.org/registry/protocols.  APM field: spec.type.

     capabilities  Capability taxonomy registry.  Endpoint:
        apix.example.org/registry/capabilities.  APM field:
        capabilities[].

     notification-channels  Notification channel type registry.  Endpoint:
        apix.example.org/registry/notification-channels.  APM field:
        notifications.channels[].type.

     presence-modes  Presence mode registry.  Endpoint:
        apix.example.org/registry/presence-modes.  APM field:
        spec.presence_mode (device classes).

     delegation-scopes  Device delegation scope registry.  Endpoint:
        apix.example.org/registry/delegation-scopes.  APM field: scopes[]
        in delegation grant requests (device classes).

     Initial values for each registry are defined in the applicable
     profile document: [APIX-SERVICES] for protocol types and capability
     taxonomy; [APIX-IOT] for presence modes, delegation scopes, and IoT
     capability terms.

     *Registry entry lifecycle:*

     Each registry entry transitions through three phases.  The
     standard_warnings flag in a Service Record does not appear until the
     grace period has elapsed — service operators have a silent window to
     update their APM before any public signal is issued.

     active  ->  deprecated (announced)
                   |
                   +-- [grace period: 90 days min]
                   |     silent: operator notified, no public flag
                   |
                   +-- [warning period: remainder of deprecation window]
                   |     standard_warnings visible in Service Record
                   |
                   +-- sunset
                         new registrations rejected; flagged non-compliant










  Rehfeld                 Expires 14 November 2026               [Page 26]


  Internet-Draft                  APIX Core                       May 2026


      +================+============+=====================+============+
      | Phase          | Status     | standard_warnings   | New regs.  |
      +================+============+=====================+============+
      | Normal use     | active     | No                  | Accepted   |
      +----------------+------------+---------------------+------------+
      | Grace period   | deprecated | *No*                | Accepted   |
      +----------------+------------+---------------------+------------+
      | Warning period | deprecated | *Yes*               | Accepted   |
      +----------------+------------+---------------------+------------+
      | Sunset         | sunset     | Yes (non-compliant) | *Rejected* |
      +----------------+------------+---------------------+------------+

                                   Table 1

     *Deprecation rules:*

     *  The governing body MUST publish a deprecated_in_version,
        sunset_date, grace_period_ends, and replacement value when
        deprecating any registry entry.

     *  The minimum total deprecation window (announcement to sunset) is
        *12 months*. The governing body MAY extend this window but MUST
        NOT shorten it.

     *  The minimum grace period is *90 days* from the deprecation
        announcement.  During the grace period, standard_warnings MUST NOT
        be set on any Service Record, regardless of whether the service
        uses the deprecated value.

     *  The governing body MUST notify all registered Service Owners whose
        services use the deprecated value before the grace period begins.
        Notification MUST include the grace_period_ends date, the
        sunset_date, and the replacement value.

     *  After the grace period, the index operator MUST set
        standard_warnings on Service Records that still use the deprecated
        value.

     *  At sunset, the index operator MUST reject new APM submissions
        using the sunsetted value and MUST escalate existing Service
        Records from standard_warnings to a non_compliant status flag.

     *Registry versioning:* each registry is independently versioned.  The
     Index root resource (Section 10.2) exposes the current version of
     each registry so consuming agents may detect changes.

  1.5.  Lawful Cooperation and Non-Surveillance Commitment




  Rehfeld                 Expires 14 November 2026               [Page 27]


  Internet-Draft                  APIX Core                       May 2026


  1.5.1.  Purpose of the Service

     APIX is infrastructure designed for one purpose: enabling autonomous
     agents and the organisations that deploy them to discover legitimate
     services and operate productively in the commercial internet.
     Registration in the APIX is a declaration that a service or device
     class is offered in good faith for legitimate use.  The APIX is not a
     neutral medium indifferent to the purposes for which it is used.  It
     is infrastructure built for legitimate use, and it is by design
     closed to actors who are refused or removed under the compliance
     mechanisms defined in this specification — sanctions screening, KYC
     verification, and judicial enforcement through the LER process.

     This is not a policy statement.  It is the foundational design
     constraint from which the cooperation mechanisms in this document and
     in [APIX-IOT] derive their legitimacy.

  1.5.2.  Cooperation Duty

     Because APIX provides infrastructure for legitimate use, it has a
     duty to cooperate with properly authorised law enforcement when that
     infrastructure is misused.  This duty is not conditional on
     commercial convenience or reputational risk.  When a registrant or
     device fleet is confirmed to be operating criminally, APIX MUST act —
     through the mechanisms defined in this document and in [APIX-IOT] —
     to limit the harm that flows from that misuse.

     APIX MUST cooperate with authorised law enforcement requests that
     satisfy the jurisdictional and judicial requirements defined in
     [APIX-IOT] Section 5.8.  Refusal to cooperate with a validly
     authorised request is not permitted.  Delay beyond the processing
     time commitments defined in that section requires documented
     justification and MUST be reported in the governing body's annual
     transparency report.

  1.5.3.  Non-Surveillance Commitment

     APIX is not a surveillance instrument.  The cooperation mechanisms in
     this specification are reactive and bounded.  The following
     prohibitions are normative and apply to all conforming
     implementations:

     *  APIX MUST NOT proactively monitor, profile, or analyse the
        behaviour of registered services, device fleets, or consuming
        agents beyond what is technically necessary to deliver liveness
        verification and abuse detection as defined in this specification.





  Rehfeld                 Expires 14 November 2026               [Page 28]


  Internet-Draft                  APIX Core                       May 2026


     *  APIX MUST NOT share index data, presence signal logs, device
        instance records, or consuming agent query patterns with any law
        enforcement or government authority except through the Law
        Enforcement Request process defined in [APIX-IOT] Section 9.8,
        with its associated judicial authorisation requirements and
        jurisdictional constraints.

     *  Bulk data requests — requests that are not targeted at identified
        specific devices, instances, or registrants but instead seek
        aggregate ecosystem intelligence — MUST be refused regardless of
        the requesting authority's jurisdiction or claimed legal basis.  A
        valid LER MUST identify specific device IP addresses or registrant
        identifiers.  A request for "all devices in region X" or "all
        services in category Y" is not a valid LER.

     *  APIX MUST NOT establish any data-sharing arrangement, standing
        access grant, or automated feed to any law enforcement or
        intelligence agency.  Every cooperation action is event-triggered,
        scoped to a specific identified case, and subject to the judicial
        authorisation requirement.

  1.5.4.  The Trigger Requirement

     Enhanced monitoring, graduated response actions, and LER processing
     are ALWAYS triggered by one of two conditions:

     1.  *External identification*: a legitimate authority in an accepted
         jurisdiction has submitted an LER with valid judicial
         authorisation identifying specific devices or registrants as
         confirmed participants in criminal activity.  Suspicion alone is
         not sufficient.  The judicial authorisation requirement is the
         gatekeeping mechanism.

     2.  *Technical anomaly detection*: APIX's own infrastructure detects
         signal patterns technically inconsistent with legitimate device
         operation — such as rapid mass re-registration from a single IP
         address, heartbeat flooding at rates outside any plausible device
         density, or token reuse patterns that cannot arise from
         legitimate manufacture and provisioning.  Such detections result
         in classification at the observe tier of the Bad-Bot Graduated
         Response ([APIX-IOT] Section 9.9), not in immediate blocking.
         They are recorded, monitored, and shared with authorised law
         enforcement on request through the LER process.  They do not
         trigger autonomous enforcement action by APIX.

     Speculative profiling — building behavioural models of registered
     services or device fleets in the absence of a trigger — is prohibited
     under the Non-Surveillance Commitment above.



  Rehfeld                 Expires 14 November 2026               [Page 29]


  Internet-Draft                  APIX Core                       May 2026


  1.5.5.  Jurisdictional Guardrails

     All cooperation is bounded by the accepted jurisdictions framework
     defined in [APIX-IOT] Section 9.8.  This boundary is not negotiable
     on a case-by-case basis.  APIX MUST NOT cooperate with a law
     enforcement request from a jurisdiction not on the Accepted
     Jurisdiction Whitelist, even when:

     *  The requesting authority presents a compelling case.

     *  The alleged criminal activity is severe.

     *  Political, commercial, or reputational pressure is applied.

     *  Another accepted-jurisdiction authority vouches for the request.

     The Accepted Jurisdiction Whitelist exists precisely to make this
     boundary resist pressure.  The governing body MAY add jurisdictions
     to the whitelist through its defined board decision process; it MUST
     NOT bypass the whitelist for individual cases.  Any governing body
     action that grants cooperation outside the whitelist is a
     specification violation and MUST be reported in the transparency
     report.

  1.5.6.  Transparency as Enforcement

     The annual transparency report required by Section 4.2 is not merely
     informational.  It is the mechanism by which the non-surveillance
     commitment and the jurisdictional guardrails are held accountable.
     The governing body MUST disclose in that report:

     *  The number of LER requests received, accepted, and refused, by
        requesting jurisdiction tier.

     *  The number of bulk data requests received and refused.

     *  Any case in which cooperation outside the accepted jurisdictions
        framework was requested, with the governing body's response.

     *  Any case in which APIX's own technical anomaly detection was used
        as the basis for a law enforcement referral.

     *  The total number of device instances, services, and organisations
        subject to active suppression, suspension, or graduated response
        measures at the reporting date.






  Rehfeld                 Expires 14 November 2026               [Page 30]


  Internet-Draft                  APIX Core                       May 2026


     If a governing body fails to publish this report within 90 days of
     the close of a calendar year, any member of the governing body board
     MUST be empowered to publish it unilaterally.  The right to publish
     the transparency report MUST NOT be waivable by board resolution.

  1.6.  The APIX Manifest (APM)

  1.6.1.  Purpose

     The APIX Manifest is the structured document that a Service Owner
     provides at registration.  It is the index-facing contract for a
     Service: format-agnostic, extensible, and designed for machine
     consumption.

     The APM has two layers:

     *Base fields* — defined in this document and required for all service
     types: apm_version, service_id, name, description, owner (with
     organisation_name, jurisdiction, registration_number, contacts),
     capabilities, trust (organisation and service level assignments), and
     legal.  These fields are common to all profiles.

     lifecycle_stage is required for all service types but its valid
     values and transition rules are profile-defined.  Each profile owns
     its own lifecycle model; the field is not a shared enum.  See
     [APIX-SERVICES] and [APIX-IOT] for the lifecycle models applicable to
     each service type.

     *Profile fields* — defined in profile documents and required only for
     the applicable service type.  [APIX-SERVICES] defines the full APM
     schema for web API services.  [APIX-IOT] defines the full APM schema
     for device class registrations.  An APM submission MUST conform to
     the profile schema corresponding to its spec.type value.

     *Extension fields* — the custom array is a governed extension
     mechanism for declaring properties not yet covered by the base or
     profile schemas.  The custom field is OPTIONAL in all profiles.  It
     is a flat list of reverse-domain key name strings; no values are
     stored in the index.  The APIX indexes only the declared key names,
     enabling discovery via the custom_key search parameter.  This design
     provides a clean promotion path: when a custom key accumulates
     sufficient independent adoption across organisations, the Bot
     Standards Foundation MAY initiate a governance track to promote the
     pattern to a standard named field in a future APM version.  Full
     normative rules — including key naming conventions, list size limits,
     and Spider behaviour — are defined in the applicable profile document
     ([APIX-SERVICES], [APIX-IOT]).




  Rehfeld                 Expires 14 November 2026               [Page 31]


  Internet-Draft                  APIX Core                       May 2026


     The trust fields in an APM submission MUST be set exclusively by the
     index operator based on verification outcomes.  APM submissions that
     include trust field values MUST have those values overwritten by the
     index upon processing.  A Service Owner MUST NOT assert their own
     trust level.

  1.7.  Trust Model

     The APIX Trust Model has three independent dimensions.  Each
     dimension produces a machine-readable value in the Service Record.
     Consuming agents combine these values according to their own Trust
     Policy.

     The APIX provides trust metadata.  It does not make trust decisions.

  1.7.1.  Dimension 1 — Organisation Trust Level

     Describes the verified identity and compliance posture of the
     organisation that owns the service.

                      +=======+========================+
                      | Level | Label                  |
                      +=======+========================+
                      | O-0   | Unverified             |
                      +-------+------------------------+
                      | O-1   | Identity Verified      |
                      +-------+------------------------+
                      | O-2   | Legal Entity Verified  |
                      +-------+------------------------+
                      | O-3   | Hygiene Verified       |
                      +-------+------------------------+
                      | O-4   | Operationally Verified |
                      +-------+------------------------+
                      | O-5   | Audited                |
                      +-------+------------------------+

                                   Table 2

     O-0 (Unverified):  Self-registered.  No checks performed.

     O-1 (Identity Verified):  Valid business email confirmed.  Domain
        ownership verified via DNS TXT record.

     O-2 (Legal Entity Verified):  Company registration number confirmed
        against official registry of the declared jurisdiction.

     O-3 (Hygiene Verified):  security.txt (RFC 9116) present and valid at




  Rehfeld                 Expires 14 November 2026               [Page 32]


  Internet-Draft                  APIX Core                       May 2026


        /.well-known/security.txt; DMARC and SPF DNS records configured
        for the registered domain; Privacy Policy, Terms of Service, and
        Data Processing Agreement accessible at declared URLs.  All checks
        performed automatically by APIX.  No human reviewer required.

     O-4 (Operationally Verified):  Organisation governance structure,
        operational security practices, incident response capability, and
        personnel vetting reviewed by an Accredited Verifier against the
        Verifier Standard.

     O-5 (Audited):  Third-party compliance audit completed (SOC 2 Type
        II, ISO 27001, or equivalent).  Audit certificate on file with the
        governing body.  O-5 may be achieved directly without O-4 as a
        prerequisite via direct certificate submission to the governing
        body.

     Organisation levels are assessed against the organisation as a whole,
     not per service.  An organisation that achieves any O-level applies
     that level to all its registered services.

  1.7.2.  Dimension 2 — Service Verification Level

     Describes what has been automatically verified about the service
     itself.  The specific verification mechanism differs by service type
     (Spider for web API services; manufacturer registration process for
     device classes).

                         +=======+===================+
                         | Level | Label             |
                         +=======+===================+
                         | S-0   | Unchecked         |
                         +-------+-------------------+
                         | S-1   | Reachable         |
                         +-------+-------------------+
                         | S-2   | Spec Verified     |
                         +-------+-------------------+
                         | S-3   | Schema Stable     |
                         +-------+-------------------+
                         | S-4   | Security Reviewed |
                         +-------+-------------------+

                                    Table 3

     S-0 (Unchecked):  Registered.  Verification has not yet run.

     S-1 (Reachable):  Service confirmed reachable by automated check.

     S-2 (Spec Verified):  Specification or capability declaration



  Rehfeld                 Expires 14 November 2026               [Page 33]


  Internet-Draft                  APIX Core                       May 2026


        confirmed and consistent with registration.

     S-3 (Schema Stable):  No breaking changes detected across at least
        three consecutive verification runs.

     S-4 (Security Reviewed):  Automated vulnerability scan completed with
        no critical findings, OR third-party penetration test certificate
        provided and validated by an Accredited Verifier.

     Profile documents define the exact criteria by which each level is
     achieved for each service type.

  1.7.3.  Dimension 3 — Liveness

     Describes the confirmed operational availability of the service,
     including how recent and how frequent the availability data is.
     Liveness data is expressed as a set of metrics, not a single level.

     last_ping_at (ISO 8601 timestamp)  Time of the most recent successful
        liveness check.

     ping_interval_seconds (integer)  Configured interval between liveness
        checks.

     uptime_30d_percent (float)  Percentage of checks successful over the
        last 30 days.

     avg_response_ms (float)  Mean response time in milliseconds over the
        last 30 days.

     consecutive_failures (integer)  Number of consecutive failed checks
        at last run.

     The check interval is determined by the service's liveness monitoring
     configuration.  A service configured at initial-only frequency
     receives no recurring checks; its last_ping_at reflects only the
     initial verification run.

     The concrete fields and measurement model for Liveness differ by
     service type and are defined in each profile document.











  Rehfeld                 Expires 14 November 2026               [Page 34]


  Internet-Draft                  APIX Core                       May 2026


  1.7.4.  Trust Model Implementations by Service Type

     The three trust dimensions (Organisation, Service Verification,
     Liveness) are universal across all APIX service types.  However,
     their concrete implementation — the verification mechanisms, the APM
     fields that carry trust state, and the achievable levels — differs by
     service type.  Three distinct trust implementations are defined
     across the APIX profile suite.

     *API Service Trust* (defined in [APIX-SERVICES])

     Verification is pull-based: the APIX Spider visits the service on a
     scheduled basis, checks reachability, fetches and parses the
     specification, and runs schema comparison across consecutive runs.
     Liveness is measured by the index — the Spider pings the service
     endpoint and records response time and availability metrics.  The
     trust object in an API service APM carries observed metrics
     (last_ping_at, uptime_30d_percent, avg_response_ms,
     consecutive_failures).

     *Device Class Trust* (defined in [APIX-IOT])

     Verification is registration-based: a device manufacturer registers
     the device class, providing a capability declaration and firmware
     version contract.  The APIX Spider does not visit device hardware.
     Liveness configuration is declared by the manufacturer at
     registration time (presence_mode, heartbeat_interval_seconds) — not
     observed by the index.  The trust object in a device class APM
     carries manufacturer-declared configuration, not measured metrics.
     spec_consistency is always null for device classes: there is no
     specification document for the Spider to fetch.

     *Device Instance Trust* (defined in [APIX-IOT])

     Liveness is push-based: individual device instances signal their
     presence to the index at regular intervals.  The index does not probe
     devices.  Instance trust state (online, reachable, last_seen_at)
     reflects the most recent presence signal received, not a Spider
     measurement.  Device instance trust state is private — it is never
     returned to unauthenticated queries regardless of trust levels.

     These are three architecturally distinct trust models that share only
     the O-level and S-level abstractions.  Implementers MUST NOT assume
     that trust object fields in a device class or device instance APM
     follow the structure of an API service APM.






  Rehfeld                 Expires 14 November 2026               [Page 35]


  Internet-Draft                  APIX Core                       May 2026


  1.7.5.  Bot-Side Trust Policy Expression

     A consuming agent expresses its Trust Policy as a set of minimum
     thresholds across all three dimensions.  Example policy expressed in
     pseudo-notation:

     require:
       organisation_level >= O-2
       service_level >= S-2
       last_ping_age < 3600         # seconds since last_ping_at
       uptime_30d_percent >= 99.0
       consecutive_failures == 0

     The Index API SHOULD support filtering by trust dimension thresholds
     so that agents can retrieve only records that satisfy their policy
     without downloading the full index.

     Trust Policies are defined and enforced by consuming agents.  The
     APIX does not validate or enforce Trust Policies.

  1.7.6.  Accredited Verifier Model

     Organisation level O-3 (Hygiene Verified) is achieved by automatic
     APIX checks and requires no human reviewer.  Organisation level O-4
     requires an Accredited Verifier assessment.  Organisation level O-5
     may be achieved directly without O-4 as a prerequisite via direct
     certificate submission to the governing body (SOC 2 Type II or ISO
     27001).  The APIX uses a federated Accredited Verifier model,
     analogous to the Certificate Authority model in TLS:

     *  the governing body defines the verification criteria for each
        level and publishes the Verifier Standard.

     *  Organisations apply to the governing body for Verifier
        accreditation.

     *  Accredited Verifiers perform O-4 assessments and, where
        applicable, O-5 attestations, signing verification reports in each
        case.

     *  the governing body maintains a public registry of Accredited
        Verifiers and their accreditation status.

     *  A Service Record at O-4 MUST include the identifier of the
        Accredited Verifier that performed the assessment and the date of
        assessment.





  Rehfeld                 Expires 14 November 2026               [Page 36]


  Internet-Draft                  APIX Core                       May 2026


     *  A Service Record at O-5 via direct certificate submission MUST
        include the certificate reference, issuing auditor, scope, and
        expiry date.

     *  Accreditation of Verifiers is reviewed annually by the governing
        body.

     *  A Verifier placed in suspended status following a failed annual
        review MUST be given a minimum 90-day remediation window before
        final revocation.  The 90-day window applies to performance
        failures: lapsed certifications, reduced capacity, or failure to
        meet audit quality standards.  It does not apply to fundamental
        violations, for which the governing body MUST revoke accreditation
        immediately.  Fundamental violations include: issuing a false or
        unsupported O-4 or O-5 assessment, certifying a related entity in
        breach of the independence requirement, leaking confidential
        assessment data, or colluding with an organisation to obtain a
        trust level fraudulently.

     *Elevation verification requirements:*

     Elevation to O-4 or O-5 MUST be verified through an out-of-band
     channel that is independent of the digital submission path used to
     submit the elevation request.  The governing body MUST NOT record an
     O-4 or O-5 elevation solely on the basis of a digitally submitted
     application, regardless of the authentication mechanism used for that
     submission.  The out-of-band verification MUST confirm that the
     elevation was intentionally authorised by a responsible
     representative of the applicant organisation, and that the submitted
     evidence (Accredited Verifier report or audit certificate) is
     genuine.

     Elevation to O-5 MUST additionally be confirmed by two independently
     authorised representatives of the applicant organisation.  The two
     confirming individuals MUST hold separate credentials and MUST act
     independently; a single individual confirming twice does not satisfy
     this requirement.  The governing body MUST enforce this
     programmatically for O-5 elevations processed through its operational
     interface.

     The specific out-of-band verification mechanism and the
     implementation of the two-representative confirmation are operational
     responsibilities of the governing body and are documented in the APIX
     implementation guide.  Conforming implementations of the APIX
     governing body role MUST implement mechanisms that satisfy these
     requirements; the specific mechanisms are not prescribed by this
     specification.




  Rehfeld                 Expires 14 November 2026               [Page 37]


  Internet-Draft                  APIX Core                       May 2026


     *Design Note — Future Trust Level Evolution (non-normative):* The O-0
     through O-5 architecture defined here is the Version 1 model.  O-3
     was introduced to provide an automatable, zero-cost on-ramp for
     early-stage organisations, bridging the gap between legal entity
     verification (O-2) and the first human-reviewed tier (O-4).  As the
     governing body Accredited Verifier market matures and a meaningful
     population of O-5 organisations is established, a Version 2 evolution
     is anticipated in which O-5 is joined by a premium O-6 designation
     with APIX-specific assessment criteria beyond the industry baseline —
     dedicated incident response covering governing body cooperation
     obligations, agreed governing body audit access, and APIX-specific
     operational commitments.  This evolution requires the governing body
     to develop and publish an O-6 assessment standard, which is not
     feasible at initial launch.  The trust level record structure (see
     implementation guide Part I §1.4) is designed to accommodate
     additional components without breaking existing consumers.

  1.8.  Commercial Contract and Sanctions Compliance

     Every registered service MUST be covered by a commercial agreement
     between the Service Owner and the index operator (or its Accredited
     Regional Representative).  The agreement MUST define:

     *  The liveness monitoring configuration and its obligations.

     *  The index operator's obligations regarding verification frequency
        and Index API availability.

     *  Acceptable use terms.

     *  Data processing terms in accordance with applicable law.

     *Sanctions compliance:* the index operator MUST screen all service
     registrants against applicable sanctions lists prior to account
     activation.  At minimum, screening MUST cover the UN Security Council
     consolidated sanctions list.  Operators subject to additional
     jurisdictional sanctions regimes (e.g., EU, US OFAC, Swiss SECO) MUST
     additionally screen against those lists as applicable to their
     jurisdiction of incorporation.  Entities subject to applicable
     sanctions MUST be refused registration regardless of commercial tier.

     Registrants MUST represent and warrant in the commercial agreement
     that they are not subject to applicable sanctions, and MUST notify
     the index operator immediately of any change in that status.

     *Ongoing sanctions monitoring:* The index operator MUST perform
     periodic re-screening of all registered organisations against the
     same sanctions lists checked at initial registration.  Re-screening



  Rehfeld                 Expires 14 November 2026               [Page 38]


  Internet-Draft                  APIX Core                       May 2026


     MUST occur at least quarterly.  Upon detection of a new match for a
     previously-cleared organisation — whether by periodic re-screening,
     third-party notification, or registrant self-report — the index
     operator MUST immediately:

     1.  Suspend the organisation's account.  All API credentials are
         revoked; no further registration or update operations are
         accepted from the organisation.

     2.  Suspend all services registered by the organisation.  Suspended
         services are removed from all discovery results.

     3.  Revoke all active credentials issued to the organisation (API
         keys, instance tokens where applicable).  All associated service
         instances are marked offline or unreachable.

     4.  Open a legal review case.  The specific sanctions list and
         matched entry MUST NOT be disclosed externally; the organisation
         receives only a generic account suspension notice.

     If the sanctions match is subsequently determined to be a false
     positive or the registrant is removed from the relevant list, the
     index operator MAY reinstate the account following legal review.
     Reinstatement requires a fresh KYC and sanctions check.

     Unauthenticated discovery queries to the Index API are not subject to
     registration screening and MUST remain available without restriction,
     consistent with the APIX's mission as open global infrastructure.

  1.9.  Operational Model

  1.9.1.  Supply-Side Funding Principle

     A conforming APIX implementation MUST be funded primarily by service
     registration fees paid by Service Owners (supply side).  Discovery
     queries by consuming agents MUST NOT be the primary revenue
     mechanism.  This principle is normative: an implementation that
     charges consuming agents for standard discovery queries is not
     conformant with the APIX model, as doing so contradicts the open
     infrastructure mission and undermines the network effect that makes
     the supply side valuable.

     The APIX model is structurally analogous to the DNS model:
     registrants pay to be listed; queries are free.

     Fee structures applicable to each service type are defined in the
     relevant profile document.  All implementations MUST apply fees
     consistently to all registrants of a given service type at the same



  Rehfeld                 Expires 14 November 2026               [Page 39]


  Internet-Draft                  APIX Core                       May 2026


     commercial tier, with no preferential treatment.  The governing body
     publishes the normative fee schedule as a separate registry document,
     updated independently of this RFC.

  1.9.2.  Consumer Access Model

     Discovery queries to the Index API MUST be available without
     authentication or payment.  Rate limits MAY be applied to protect
     infrastructure integrity but MUST NOT be set at levels that prevent
     reasonable agent operation.  Implementations MUST support at minimum
     three consumer access layers:

     *Layer 1 — Unauthenticated access*

     Any agent MUST be able to query the Index API without authentication
     or registration, subject to a per-IP rate limit.  This layer is
     sufficient for individual agents and proof-of-concept deployments.

     *Layer 2 — Authenticated access (free)*

     Any agent MAY register a consumer identity token at no cost.  Token
     registration requires a valid email address.  Authenticated access
     MUST provide a higher rate limit than unauthenticated access and MAY
     additionally provide result caching hints and webhook subscriptions
     for service record changes.

     Consumer tokens SHOULD be compatible with the webbotauth identity
     model ([I-D.meunier-webbotauth-registry]) to enable interoperability
     with bot authentication infrastructure.

     *Layer 3 — High-volume access (paid, optional)*

     Implementations MAY offer a paid high-volume access tier for
     platforms operating agents at scale that require guaranteed query
     capacity and operational SLAs.  This tier is supplementary; the
     index's operational sustainability MUST NOT depend on it.

     *Public bulk download (REQUIRED)*

     Implementations MUST provide the full index as a freely downloadable
     bulk dataset on the first day of each calendar month, without
     authentication, under the Open Database Licence (ODbL) 1.0.  This
     requirement implements the openness requirement of Section 4.2: no
     entity, including the index operator, may hold an exclusive lock on
     the index data.






  Rehfeld                 Expires 14 November 2026               [Page 40]


  Internet-Draft                  APIX Core                       May 2026


     Implementations MUST additionally publish a daily diff file covering
     all record additions, updates, and deletions since the previous day.
     Daily diffs MUST be serialised in the same format as the full
     snapshot and MUST be available at the same endpoint, identified by an
     ISO 8601 date in their filename or URL path (e.g. diff-
     2026-04-28.json).  A new mirror MUST be able to reach current index
     state by downloading the latest monthly full snapshot and applying
     the sequence of daily diffs since that snapshot date, without
     downloading any additional full snapshots.

  1.9.3.  Ecological Impact Transparency

     A conforming APIX implementation SHOULD publish aggregate ecological
     impact statistics derived from observed index usage.  These
     statistics quantify the efficiency gain attributable to machine-
     native API consumption compared to equivalent traditional web request
     technology consumption, and SHOULD be updated in real time and
     included in the annual transparency report.

     The comparison baseline is the full traditional web request stack —
     not payload size alone — including the request waterfall (HTML page
     with dependent CSS, JavaScript, image, and font resources),
     JavaScript execution overhead for dynamically rendered pages, polling
     requests that occur in the absence of a notification mechanism, retry
     waste from access-control measures, and proxy infrastructure
     maintained solely to circumvent those measures.

     The following metrics SHOULD be derived from directly observable
     index events and published at a stable public endpoint:

     *  *Discovery requests served* — each request represents one agent
        retrieval that did not require scraping or probing a service
        endpoint directly.

     *  *Notification events fired* — each event represents one or more
        polling requests eliminated across all subscribed consuming
        agents.

     *  *Estimated data transfer saved (GB)* — computed from discovery
        request count, service profile type, and the differential between
        average traditional web page size and average machine-native API
        response size for that profile type.

     *  *Estimated CO2 equivalent avoided* — computed from total estimated
        data transfer saved using a published CO2-per-GB methodology.  The
        methodology document, including its source data and version, MUST
        be publicly accessible at a stable URL.




  Rehfeld                 Expires 14 November 2026               [Page 41]


  Internet-Draft                  APIX Core                       May 2026


     All published figures MUST be accompanied by the computation
     methodology, confidence bounds, and source data references.
     Conservative estimates MUST be used where data is incomplete; figures
     MUST NOT be extrapolated beyond what the directly observed data
     supports.

     The governing body SHOULD seek independent validation of the
     methodology from an established environmental computing research
     organisation.

  1.10.  Index API — Core

  1.10.1.  HATEOAS Navigation Model

     The Index API MUST follow Hypermedia as the Engine of Application
     State (HATEOAS) principles.  A consuming agent MUST be able to
     discover and navigate the entire index starting from a single, stable
     entry-point URL, without out-of-band knowledge of endpoint paths.

     Every response MUST include a _links object containing hypermedia
     controls for navigation.  Link relations MUST use IANA-registered
     relation types where applicable, and APIX-specific relations where
     not.

  1.10.2.  Discovery Endpoint

     The APIX exposes a single globally stable entry-point URL:

     https://apix.example.org/

     A GET request to this URL returns the Index root resource.  The root
     resource includes base navigation links common to all
     implementations, plus profile-specific links defined in applicable
     profile documents.

















  Rehfeld                 Expires 14 November 2026               [Page 42]


  Internet-Draft                  APIX Core                       May 2026


     {
       "apix_version": "1.0",
       "total_services": 12483,
       "last_updated": "2026-04-25T00:00:00Z",
       "registry_versions": {
         "protocols": "1.0",
         "capabilities": "1.0",
         "presence_modes": "1.0"
       },
       "_links": {
         "self": {
           "href": "https://apix.example.org/"
         },
         "search": {
           "href": "https://apix.example.org/search{/api_version}{?...}",
           "templated": true
         },
         "browse": {
           "href": "https://apix.example.org/browse"
         },
         "capabilities": {
           "href": "https://apix.example.org/capabilities"
         },
         "devices": {
           "href": "https://apix.example.org/devices{?capability,...}",
           "templated": true
         },
         "docs": {
           "href": "https://apix.example.org/docs"
         },
         "apix:ecological-impact-stats": {
           "href": "https://apix.example.org/stats/ecological-impact"
         }
       }
     }

     The {?q,...} placeholder above is abbreviated.  The complete search
     URI template (parameters grouped for readability; the value is a
     single uninterrupted string at runtime):

     https://apix.example.org/search{/api_version}
       {?q,capability,protocol,language,pricing_model,
        auth_method,deployment_region,near,coverage_radius_km,
        custom_key,org_level_min,service_level_min,spec_consistency,
        max_ping_age,uptime_30d_min,lifecycle_stage,
        include_superseded,page,page_size}





  Rehfeld                 Expires 14 November 2026               [Page 43]


  Internet-Draft                  APIX Core                       May 2026


     The lifecycle_stage parameter accepts values defined by each profile
     document.  Valid values differ by service type and are not a shared
     enum.  See [APIX-SERVICES] and [APIX-IOT] for the valid values
     applicable to each service type.

     The devices link template (defined in [APIX-IOT]):

     https://apix.example.org/devices
       {?capability,protocol,online,api_version,
        endpoint_confidence,page,page_size}

     Profile-specific links (e.g., the devices link defined in [APIX-IOT])
     are present in the root resource when the implementation includes
     support for that profile.  Consuming agents MUST follow links rather
     than constructing URLs independently; the presence or absence of a
     link in the root resource is the authoritative signal of whether a
     capability is supported.

  1.10.3.  Transport Encoding

     The Index API is consumed by autonomous agents at machine speed.
     Response payloads are structured JSON with highly repetitive field
     names across result arrays.  Transport-layer compression achieves
     70–85% size reduction on typical search result payloads with no
     information loss and no application-layer schema changes.

     *Compression support requirements:*

     The Index API MUST support the following Accept-Encoding values:

      +=============+=============+====================================+
      | Encoding    | Requirement | Notes                              |
      +=============+=============+====================================+
      | gzip        | MUST        | Universally supported baseline     |
      +-------------+-------------+------------------------------------+
      | br (Brotli) | SHOULD      | Higher compression ratio than gzip |
      +-------------+-------------+------------------------------------+
      | zstd        | SHOULD      | Similar ratio to Brotli; faster    |
      |             |             | decompression                      |
      +-------------+-------------+------------------------------------+

                                   Table 4

     The Index API MUST perform content negotiation via the Accept-
     Encoding request header.  Responses MUST include a Content-Encoding
     header identifying the applied encoding.  If a client sends no
     Accept-Encoding header, the server MAY respond uncompressed.




  Rehfeld                 Expires 14 November 2026               [Page 44]


  Internet-Draft                  APIX Core                       May 2026


     Consuming agents SHOULD include Accept-Encoding: zstd, br, gzip in
     all Index API requests.

     The Index API MAY additionally support CBOR (RFC 8949) as a binary
     alternative to JSON.  A client that prefers CBOR MUST signal this via
     Accept: application/cbor.  CBOR responses carry identical information
     to JSON responses.  Clients MUST NOT assume CBOR support.  JSON over
     compressed transport is the normative interchange format.

  1.11.  Index API Versioning

  1.11.1.  Version Identification

     The root resource returned at https://apix.example.org/ MUST include
     an apix_version field identifying the version of the Index API schema
     in use.  Version values are of the form MAJOR.MINOR (e.g., "1.0",
     "1.2", "2.0").

     Consuming agents MUST read apix_version at the start of each session.
     Agents MUST NOT cache apix_version across sessions: the version field
     is the authoritative signal that the schema has changed.

  1.11.2.  Compatibility Rules

     The APIX follows a semantic versioning policy for the Index API:

     *Non-breaking changes (MINOR increment):*

     *  Adding new fields to Service Records or the root resource

     *  Adding new optional query parameters to the search endpoint

     *  Adding new _links relations to any response

     *  Expanding an enumerated value registry (new capability terms, new
        protocol types)

     *  Increasing rate limits

     Minor version increments are backward compatible.  A consuming agent
     written for 1.0 MUST be able to operate correctly against a 1.x
     endpoint, provided it ignores unknown fields.

     Consuming agents MUST follow the robustness principle: ignore unknown
     fields and unknown link relations rather than failing.  This
     requirement is normative.

     *Breaking changes (MAJOR increment):*



  Rehfeld                 Expires 14 November 2026               [Page 45]


  Internet-Draft                  APIX Core                       May 2026


     *  Removing or renaming fields in Service Records

     *  Changing the type or semantics of an existing field

     *  Removing or renaming existing query parameters

     *  Changing the structure of the HATEOAS _links object

     *  Changing the URL of the single entry-point

     A MAJOR version increment MUST NOT occur without a concurrent
     deprecation notice for the prior version (see below).

  1.11.3.  API Deprecation and Migration

     When a new MAJOR version is released, the prior MAJOR version MUST
     remain supported for a minimum of *24 months* from the date the new
     version becomes available.  During this period:

     *  Both versions MUST be simultaneously queryable

     *  The root resource of the prior version MUST include a deprecated
        flag with the sunset_date of the old version

     *  Consuming agents that include the IETF Sunset header ([RFC8594])
        in their responses MUST use it to signal the old version's sunset
        date

     the governing body MUST NOT sunset a MAJOR version without giving
     consuming agents at least 24 months to migrate.

  1.11.4.  Service api_version Immutability Invariant

     The api_version field in an APM and the version path segment in the
     search endpoint (/search/v{major}.{minor}/) rest on a single
     foundational guarantee: a published api_version value has an
     immutable field structure definition.

     This invariant MUST be stated unambiguously to consuming agents and
     service operators:

     *  A field present in version v2.4 will be present in every service
        that declares api_version: "2.4.x" for the lifetime of that
        registration.

     *  A field absent from version v2.4 will never appear in a v2.4.x
        service record without a version increment.




  Rehfeld                 Expires 14 November 2026               [Page 46]


  Internet-Draft                  APIX Core                       May 2026


     *  Removing a field, changing a field's type, or making any other
        breaking change REQUIRES a new major version.  The major bump is
        the explicit, sufficient notice to consumers.  No deprecation
        period within a major version is required or expected.

     *  Adding a field requires a new minor version.  Even additive
        changes are not permitted within a published version — a service
        that adds a field mid-life has implicitly created a new contract
        and MUST increment api_version accordingly.

     This invariant enables the version path filter to be an unconditional
     schema contract: an agent that pins to /search/v2.4/ receives results
     with a fixed, permanent field set.  Service owners are freed from the
     pressure to retain unwanted fields for backwards compatibility — the
     correct action is always to increment the version and move forward
     cleanly.

  1.11.5.  No Cross-Version Response Mapping

     The APIX does NOT perform cross-version response mapping.  The
     api_version path segment is a strict storage filter: only service
     registrations whose api_version field matches the specified prefix
     are returned.  The index never synthesises a response of one version
     from a record stored at a different version.

     The consequence is deliberate and unambiguous:

     *  A service that has upgraded from v2.4 to v3.0 is stored as a
        separate record.  The v3.0 record does not appear in /search/v2/
        results.  There are no null substitutions for dropped fields, no
        type coercions for changed fields, and no partial responses.  A v3
        record is a different resource; it is not a transformed view of a
        v2 record.

     *  The v2.4 record remains in the index — immutably — until the
        service owner advances it through the lifecycle (deprecated →
        sunset) or the record is superseded and eventually removed.  An
        agent pinned to /search/v2/ continues to see v2.4 registrations
        for as long as they exist in the index at that lifecycle stage.

     *  As services migrate to newer major versions, the v2 result set
        shrinks.  Diminishing or empty results at a pinned version are not
        a failure condition — they are the designed signal that the
        consuming agent's version pin no longer covers the current service
        landscape and an upgrade of consumer code is warranted.






  Rehfeld                 Expires 14 November 2026               [Page 47]


  Internet-Draft                  APIX Core                       May 2026


     *Upgrade path discovery:* The Level 2 Service Record for a superseded
     version MUST include a populated superseded_by field pointing to the
     current version's record.  A consuming agent that finds a v2.4 result
     with superseded_by set SHOULD follow the link to inspect the v3.0
     record and determine whether upgrading its version pin is feasible.
     This is the mechanism by which agents discover that a newer contract
     is available without being forced off the old one before they are
     ready.

     A consuming agent that receives only empty results for its pinned
     version SHOULD query GET /search/ with no path segment and no query
     parameters.  This returns the version landscape only — a summary of
     available api_version prefixes, service counts, and lifecycle status
     — and executes no content query.  The agent uses this response to
     identify which version prefix covers the current service population
     and then issues a new scoped query (e.g., /search/v3/?...) with
     explicit filters.  A parameter-less /search/ MUST NOT return service
     records; it exists solely as a version discovery resource.

  1.11.6.  Registry Version Tracking

     The root resource exposes a registry_versions object (Section 10.2).
     Consuming agents that cache capability taxonomy or protocol type data
     MUST compare the current registry_versions values against their
     cached version on each session.  A change in any registry version
     MUST trigger a cache refresh before the agent applies trust filtering
     or capability matching.

  1.12.  Operator Security and Self-Governance

  1.12.1.  Purpose and Scope

     APIX centralises knowledge that has intrinsic intelligence value: the
     identity and capability of every registered service, the network
     location of every online IoT device instance, the query patterns of
     every consuming agent, and the contact details of law enforcement
     authorities across accepted jurisdictions.  This concentration makes
     the Bot Standards Foundation an ultra-high-value target for state-
     sponsored actors, criminal organisations, and corporate adversaries.

     The Non-Surveillance Commitment (Section 5) defines what APIX will
     not do to the ecosystem it serves.  This section defines what the Bot
     Standards Foundation MUST do to protect itself and the ecosystem from
     being exploited involuntarily — through compromise, coercion, insider
     threat, or organisational capture.






  Rehfeld                 Expires 14 November 2026               [Page 48]


  Internet-Draft                  APIX Core                       May 2026


     The requirements in this section are normative obligations on the Bot
     Standards Foundation as operator.  They are not addressed to Service
     Owners or consuming agents.

  1.12.2.  Technical Security Requirements

     the governing body MUST operate APIX infrastructure under the
     following technical constraints:

     *Infrastructure separation:* The token store, tamper-evident audit
     log, and LER processing queue MUST be hosted on systems with no
     shared network path to the public-facing Index API query
     infrastructure.  Compromise of the query layer MUST NOT provide
     lateral access to the token store or audit log.

     *Air-gapped token issuance:* Instance token batches for IoT device
     classes MUST be generated on infrastructure with no persistent
     internet connection.  Issuance systems MUST use hardware security
     modules (HSMs) for all cryptographic operations.  The issuance
     network MUST be physically separated from the token delivery network.

     *Geographic distribution:* Core APIX systems MUST be distributed
     across at least two independent physical jurisdictions.  No single
     legal order from any one jurisdiction MUST be sufficient to take the
     full system offline or compel full data access.

     *Zero-trust internal architecture:* No governing body system MUST
     grant implicit trust to requests from other governing body systems.
     All inter-system communication MUST be authenticated and authorised
     independently of network location.  Lateral movement within governing
     body infrastructure MUST require separate credentials at each
     boundary.

     *Cryptographic floor:* All external-facing endpoints MUST use TLS 1.3
     or higher ([RFC8446]).  All signing operations MUST use asymmetric
     keys stored in hardware-backed key storage.  Key material MUST NOT be
     exportable from the HSM in plaintext under any operational procedure.

     *Mandatory penetration testing:* The governing body MUST commission
     an independent penetration test of its production infrastructure at
     least annually.  A summary of findings (severity distribution,
     remediation status) MUST be published in the governing body's annual
     security report within 90 days of the test.  The identity of the
     testing firm MUST be disclosed.

     *Responsible disclosure programme:* The governing body MUST maintain
     a public responsible disclosure policy at a stable URL and MUST
     acknowledge vulnerability reports within 5 business days.



  Rehfeld                 Expires 14 November 2026               [Page 49]


  Internet-Draft                  APIX Core                       May 2026


  1.12.3.  Organisational Security Requirements

     *Personnel vetting:* All staff and contractors with access to the
     token store, LER queue, sanctions screening pipeline, or audit log
     MUST undergo documented background verification commensurate with the
     sensitivity of the systems they can access, prior to access being
     granted.  Access MUST be reviewed annually.

     *Segregation of duties:* No individual staff member MUST hold
     simultaneous access to more than two of the following: token store,
     audit log, LER queue, sanctions pipeline, board signing keys.  This
     constraint MUST be enforced technically, not procedurally.

     *Least-privilege access:* Access rights MUST be scoped to the minimum
     required for the role.  Privileged access MUST expire after a defined
     session window and MUST require re-authentication.  No standing
     privileged sessions are permitted.

     *Security awareness:* All governing body staff MUST complete security
     awareness training annually, covering at minimum the threat types and
     unlawful request scenarios relevant to an operator under the security
     obligations defined in this section.

     *Insider threat detection:* The governing body MUST operate anomalous
     access pattern detection across all privileged systems.  Anomalies
     MUST generate alerts to a security function independent of the
     alerted staff member's reporting line.

     *Whistleblower protection:* Any governing body staff member or
     contractor who receives an instruction — from any source, including
     governing body board members — that would cause the governing body to
     act contrary to the Non-Surveillance Commitment (Section 5) or the
     requirements of this section MUST have a protected right to report
     that instruction to an external body without prior internal approval.
     This right MUST be codified in the governing body's founding charter
     charter and in every employment and contractor agreement.  It MUST
     NOT be waivable by board resolution or individual contract term.

  1.12.4.  Political Independence and Anti-Capture Measures

     *Structural domicile:* the governing body MUST maintain its Swiss
     Stiftung domicile as a structural defence.  The Swiss legal system,
     political neutrality, and the oversight of the Eidgenössische
     Stiftungsaufsicht provide a foundation that is not subject to the
     data access regimes of any single major power.






  Rehfeld                 Expires 14 November 2026               [Page 50]


  Internet-Draft                  APIX Core                       May 2026


     *Golden share:* the governing body's charter MUST maintain a
     governance mechanism equivalent to a 51% golden share that prevents
     any acquisition, merger, or board supermajority from overriding the
     charter's core purpose.  No commercial transaction MUST be permitted
     to subordinate the governing body's neutrality obligations to the
     interests of a single organisation or jurisdiction.

     *Board composition:* No single nation-state's citizens or residents
     MUST hold a majority of board seats.  No individual MUST hold more
     than one vote on any board decision.  Board composition MUST be
     published annually in the transparency report.

     *Infrastructure jurisdiction policy:* The governing body MUST NOT
     host core APIX systems — token store, audit log, LER queue — in
     jurisdictions that impose secret data access orders (orders that
     legally prohibit the recipient from disclosing that the order was
     received).  The governing body MUST maintain a published list of
     approved hosting jurisdictions, reviewed annually by the board.
     Removal of a jurisdiction from the approved list MUST trigger
     migration of any systems hosted there within 180 days.

     *Lawful pressure resistance:* If the governing body receives a
     government demand for data access, system access, or operational
     changes that does not satisfy the LER criteria defined in [APIX-IOT]
     Section 9.8, The governing body MUST refuse the demand.  The
     governing body MUST record the demand in the audit log and MUST
     report its existence — without operational detail that would
     compromise an ongoing investigation — in the next annual transparency
     report.  The governing body MUST NOT comply with informal diplomatic
     pressure, agency-level requests, or extra-judicial demands regardless
     of the requesting party's political standing.

     *Anti-capture review:* The board MUST conduct an annual review of
     whether any commercial relationship, grant dependency, or staff
     composition creates a conflict of interest with the governing body's
     neutrality obligations.  Findings MUST be published in the
     transparency report.

  1.12.5.  Crisis Governance Protocol

     The following conditions each independently trigger the governing
     body crisis governance protocol:

     *  Credible evidence that APIX production infrastructure has been
        compromised by an external actor

     *  Receipt of a demand that the governing body's legal counsel
        assesses as an attempt to compel action contrary to the charter



  Rehfeld                 Expires 14 November 2026               [Page 51]


  Internet-Draft                  APIX Core                       May 2026


     *  Attempted hostile acquisition, board capture, or charter amendment
        by a party with a conflict of interest

     *  Regulatory action that threatens loss of Swiss Stiftung domicile

     *Obligations on trigger:*

     1.  The discovering party MUST notify all board members within 4
         hours.

     2.  The governing body MUST publish a public statement acknowledging
         the trigger event within 72 hours of confirmation.  The statement
         MUST describe the nature of the threat in general terms without
         disclosing operational detail that would aid the attacker.

     3.  The governing body MUST activate its continuity-of-operations
         plan, ensuring Index API availability is maintained independently
         of any compromised or coerced system.

     4.  If Swiss domicile is threatened or lost, the board MUST convene
         within 30 days to activate a pre-agreed organisational relocation
         framework.  The destination jurisdiction MUST satisfy the
         infrastructure jurisdiction policy defined above.  The relocation
         framework MUST be prepared and approved by the board before APIX
         reaches production operation and MUST be reviewed annually.

     No single board member and no external party MUST have the authority
     to suspend or delay execution of steps 1–3 above.

  1.12.6.  Data Minimisation as Security Policy

     The least-held data is the least-leakable data.  The following
     constraints apply to all APIX operational systems:

     *  APIX MUST NOT log consuming agent query patterns beyond the
        minimum required for liveness monitoring and abuse detection.
        Query logs MUST be purged after 30 days unless retained under a
        specific, documented, time-limited LER investigation scope.

     *  Device instance network location data (network.ipv6, as published
        in the instance record) MUST be purged from APIX systems within 72
        hours of the instance transitioning to offline status, subject to
        any active LER retention obligation on that instance.  The
        internally observed source IPv4 address (observed_source_ipv4,
        retained for abuse detection and geo-routing and not surfaced in
        the instance record) is subject to the same purge obligation and
        timeline.




  Rehfeld                 Expires 14 November 2026               [Page 52]


  Internet-Draft                  APIX Core                       May 2026


     *  APIX MUST NOT build or maintain cross-session behavioural profiles
        of consuming agents.  Each query session MUST be treated as
        independent.

     *  Every data field collected or retained by APIX MUST have a
        documented functional justification.  Fields without a current
        functional justification MUST be deleted from the data model in
        the next schema revision.  This review MUST be a standing agenda
        item at each the governing body board meeting.

  1.12.7.  Annual Security Report

     the governing body MUST publish an annual security report within 90
     days of the close of each calendar year.  The security report is
     separate from the transparency report defined in Section 5.6 and MUST
     contain:

     *  Summary of the year's penetration test findings: severity
        distribution (critical / high / medium / low count), remediation
        status of prior findings, identity of testing firm

     *  Summary of infrastructure changes affecting the attack surface

     *  Staff access review outcomes: number of access rights granted,
        revoked, and modified

     *  Count of external demands received that did not meet LER criteria,
        and how each was handled

     *  Count of whistleblower reports received and their resolution
        status (no identifying detail)

     *  Board attestation that the infrastructure jurisdiction policy was
        reviewed and remains current

     The same unilateral publication right defined for the transparency
     report (Section 5.6) applies to the security report: if the board
     fails to publish within 90 days of period close, any individual board
     member MUST be empowered to publish it unilaterally.  This right MUST
     NOT be waivable by board resolution.

  1.13.  Security Considerations









  Rehfeld                 Expires 14 November 2026               [Page 53]


  Internet-Draft                  APIX Core                       May 2026


  1.13.1.  Abuse and Fake Listings

     The mandatory Terms of Service acceptance at registration provides a
     first barrier against malicious actors listing fake or harmful
     services.  For O-0 and O-1, identity verification is limited;
     consuming agents SHOULD NOT rely solely on index presence for trust
     at these levels.  For O-2 and above, the formal B2B contractual
     relationship and progressively stronger identity and compliance
     verification substantially raise the cost of abuse.

     Consuming agents SHOULD apply Trust Policies that exclude O-0
     services for any task involving sensitive data or consequential
     actions.

     the governing body MUST maintain an abuse reporting mechanism and
     MUST be able to suspend or remove a Service Record within 24 hours of
     confirmed abuse.  Suspended service records MUST remain in the index
     with a status: suspended flag and MUST NOT be silently deleted, to
     provide transparency to agents that had cached the record.

  1.13.2.  Trust Level Spoofing

     Organisation and Service trust levels in the Service Record are set
     only by the APIX itself, not by the Service Owner.  APM submissions
     that include trust field values MUST have those values overwritten by
     the APIX upon processing.  The Index API MUST NOT expose self-
     asserted trust values.

  1.13.3.  Transport Security Requirements

     The Index API MUST be served exclusively over TLS ([RFC8446]).
     Certificate validity MUST be verified by consuming agents.  Agents
     MUST NOT bypass TLS certificate verification when querying the Index
     API.

     All entry_point and spec.url values submitted in APM registrations
     MUST use the https scheme.  The Index MUST reject APM submissions
     that provide HTTP (non-TLS) values for these fields.

  1.13.4.  Bot Consumer Risks

     The APIX provides discovery and trust metadata.  It does not
     guarantee the safety, correctness, or availability of listed
     services.  Consuming agents MUST NOT assume that a service listed in
     the APIX is safe to use without applying their own Trust Policy.

     Consuming agents SHOULD treat Index API responses as untrusted input
     and validate the structure of Service Records before acting on them.



  Rehfeld                 Expires 14 November 2026               [Page 54]


  Internet-Draft                  APIX Core                       May 2026


  2.  References

  2.1.  Normative References

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

     [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
                Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
                September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC8594]  Wilde, E., "The Sunset HTTP Header Field", RFC 8594,
                DOI 10.17487/RFC8594, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8594>.

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

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC9116]  Foudil, E. and Y. Shafranovich, "A File Format to Aid in
                Security Vulnerability Disclosure", RFC 9116,
                DOI 10.17487/RFC9116, April 2022,
                <https://www.rfc-editor.org/rfc/rfc9116>.

  2.2.  Informative References

     [A2A]      Linux Foundation, "Agent2Agent (A2A) Protocol", June 2025,
                <https://www.linuxfoundation.org/press/linux-foundation-
                launches-the-agent2agent-protocol-project-to-enable-
                secure-intelligent-communication-between-ai-agents>.





  Rehfeld                 Expires 14 November 2026               [Page 55]


  Internet-Draft                  APIX Core                       May 2026


     [AAIF]     Linux Foundation, "Linux Foundation Agentic AI Foundation
                (AAIF)", December 2025,
                <https://www.linuxfoundation.org/press/linux-foundation-
                announces-the-formation-of-the-agentic-ai-foundation>.

     [AGNTCY]   Linux Foundation, "AGNTCY: Open Multi-Agent System
                Infrastructure", July 2025,
                <https://www.linuxfoundation.org/press/linux-foundation-
                welcomes-the-agntcy-project-to-standardize-open-multi-
                agent-system-infrastructure-and-break-down-ai-agent-
                silos>.

     [APIX-IOT] Rehfeld, C., "APIX IoT Device Profile: Discovery and
                Presence for Connected Device Services", Work in Progress,
                Internet-Draft, draft-rehfeld-apix-iot-00, n.d.,
                <https://datatracker.ietf.org/doc/draft-rehfeld-apix-
                iot/>.

     [APIX-SERVICES]
                Rehfeld, C., "APIX Services Profile: Discovery
                Infrastructure for Web API and Bot Services", Work in
                Progress, Internet-Draft, draft-rehfeld-apix-services-00,
                n.d., <https://datatracker.ietf.org/doc/draft-rehfeld-
                apix-services/>.

     [I-D.aiendpoint-ai-discovery]
                Choi, Y., "The AI Discovery Endpoint: A Structured
                Mechanism for AI Agent Service Discovery and Capability
                Exposure", March 2026, <https://datatracker.ietf.org/doc/
                draft-aiendpoint-ai-discovery/>.

     [I-D.am-layered-ai-discovery-architecture]
                Moussa, H. and A. Akhavain, "A Layered Approach to AI
                discovery", Work in Progress, Internet-Draft, draft-am-
                layered-ai-discovery-architecture-00, 14 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-am-layered-
                ai-discovery-architecture-00>.

     [I-D.batum-aidre]
                Batum, F., "AI Discovery and Retrieval Endpoint (AIDRE)",
                Work in Progress, Internet-Draft, draft-batum-aidre-00, 5
                April 2026, <https://datatracker.ietf.org/doc/html/draft-
                batum-aidre-00>.








  Rehfeld                 Expires 14 November 2026               [Page 56]


  Internet-Draft                  APIX Core                       May 2026


     [I-D.cui-ai-agent-discovery-invocation]
                Cui, Y., Chao, Y., and C. Du, "AI Agent Discovery and
                Invocation Protocol", Work in Progress, Internet-Draft,
                draft-cui-ai-agent-discovery-invocation-01, 12 February
                2026, <https://datatracker.ietf.org/doc/html/draft-cui-ai-
                agent-discovery-invocation-01>.

     [I-D.drake-agent-identity-registry]
                Drake, J., "Agent Identity Registry System: A Federated
                Architecture for Hardware-Anchored Identity of Autonomous
                Entities", 2026, <https://datatracker.ietf.org/doc/draft-
                drake-agent-identity-registry/>.

     [I-D.hood-agtp-api]
                Hood, C., "AGTP-API: Verbs, Paths, Endpoints, and
                Synthesis", Work in Progress, Internet-Draft, draft-hood-
                agtp-api-00, 11 May 2026,
                <https://datatracker.ietf.org/doc/html/draft-hood-agtp-
                api-00>.

     [I-D.hood-agtp-discovery]
                Hood, C., "AGTP Agent Discovery and Name Service", Work in
                Progress, Internet-Draft, draft-hood-agtp-discovery-00, 23
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                hood-agtp-discovery-00>.

     [I-D.hood-agtp-trust]
                Hood, C., "AGTP Trust and Verification Specification",
                Work in Progress, Internet-Draft, draft-hood-agtp-trust-
                00, 11 May 2026, <https://datatracker.ietf.org/doc/html/
                draft-hood-agtp-trust-00>.

     [I-D.hood-independent-agtp]
                Hood, C., "Agent Transfer Protocol (AGTP)", Work in
                Progress, Internet-Draft, draft-hood-independent-agtp-07,
                11 May 2026, <https://datatracker.ietf.org/doc/html/draft-
                hood-independent-agtp-07>.

     [I-D.ietf-scitt-architecture]
                Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
                Y., and S. Lasker, "An Architecture for Trustworthy and
                Transparent Digital Supply Chains", Work in Progress,
                Internet-Draft, draft-ietf-scitt-architecture-22, 10
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-scitt-architecture-22>.






  Rehfeld                 Expires 14 November 2026               [Page 57]


  Internet-Draft                  APIX Core                       May 2026


     [I-D.meunier-webbotauth-registry]
                Guerreiro, M., Kirazci, U., and T. Meunier, "Registry and
                Signature Agent card for Web bot auth", Work in Progress,
                Internet-Draft, draft-meunier-webbotauth-registry-01, 20
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-meunier-webbotauth-registry-01>.

     [I-D.mozley-aidiscovery]
                Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI
                Agent Discovery (AID) Problem Statement", Work in
                Progress, Internet-Draft, draft-mozley-aidiscovery-01, 16
                April 2026, <https://datatracker.ietf.org/doc/html/draft-
                mozley-aidiscovery-01>.

     [I-D.mozleywilliams-dnsop-dnsaid]
                Mozley, J., Williams, N., Sarikaya, B., and R. Schott,
                "DNS for AI Discovery", Work in Progress, Internet-Draft,
                draft-mozleywilliams-dnsop-dnsaid-01, 2 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-
                mozleywilliams-dnsop-dnsaid-01>.

     [I-D.narajala-courtney-ansv2]
                Courtney, S., Narajala, V. S., Huang, K., Habler, I., and
                A. Sheriff, "Agent Name Service v2 (ANS): A Domain-
                Anchored Trust Layer for Autonomous AI Agent Identity",
                Work in Progress, Internet-Draft, draft-narajala-courtney-
                ansv2-01, 13 April 2026,
                <https://datatracker.ietf.org/doc/html/draft-narajala-
                courtney-ansv2-01>.

     [I-D.pioli-agent-discovery]
                Pioli, R., "Agent Registration and Discovery Protocol
                (ARDP)", Work in Progress, Internet-Draft, draft-pioli-
                agent-discovery-01, 24 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-pioli-agent-
                discovery-01>.

     [I-D.vandemeent-ains-discovery]
                van de Meent, J. and R. AI, "AINS: AInternet Name Service
                - Agent Discovery and Trust Resolution Protocol", Work in
                Progress, Internet-Draft, draft-vandemeent-ains-discovery-
                01, 29 March 2026, <https://datatracker.ietf.org/doc/html/
                draft-vandemeent-ains-discovery-01>.

     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6763>.




  Rehfeld                 Expires 14 November 2026               [Page 58]


  Internet-Draft                  APIX Core                       May 2026


     [ROBOTS]   Koster, M., "The Web Robots Pages", 1994,
                <https://www.robotstxt.org/>.

     [UDDI]     Clement, L., Hately, A., von Riegen, C., and T. Rogers,
                "UDDI Version 3.0.2", OASIS Committee Draft uddi-
                v3.0.2-20041019, 19 October 2004, <https://www.oasis-
                open.org/committees/uddi-spec/doc/spec/v3/uddi-
                v3.0.2-20041019.htm>.

     [W3C-AGENTPROTOCOL]
                Chang, G. and S. Xu, "W3C AI Agent Protocol Community
                Group", 8 May 2025,
                <https://www.w3.org/community/agentprotocol/>.

     [WEBBOTAUTH-WG]
                "webbotauth IETF Working Group", n.d.,
                <https://datatracker.ietf.org/wg/webbotauth/>.

  Appendix A.  Change Log

     *draft-rehfeld-apix-core-00:* Initial submission, April 2026.

     *draft-rehfeld-apix-core-01:* Related Work section expanded to cover
     AGNTCY (Linux Foundation), A2A Protocol (Linux Foundation), draft-
     drake-agent-identity-registry, and the Linux Foundation Agentic AI
     Foundation (AAIF).  Positioning paragraph updated to reflect the
     consolidation of communication and invocation standards under the
     AAIF and APIX's complementary position as the discovery layer.  MCP
     entry updated with AAIF governance note.  Four new informative
     references added: AAIF, AGNTCY, A2A, I-D.drake-agent-identity-
     registry.  "The Discovery Shift" section scoped to a precise
     technical problem statement — strategic framing removed to keep the
     section appropriate for an IETF specification document.  AGNTCY scope
     comparison corrected: "commercial services" replaced with "agent-
     consumable services and IoT device classes" to reflect the full scope
     of both APIX profiles.

  A.1.  IANA Considerations

     This document requests no IANA actions.  Registry structures defined
     here are maintained by the governing body at apix.example.org/
     registry/. Initial registry values are defined in [APIX-SERVICES] and
     [APIX-IOT].

  A.2.  References






  Rehfeld                 Expires 14 November 2026               [Page 59]


  Internet-Draft                  APIX Core                       May 2026


  A.2.1.  Normative References

     *  [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.

     *  [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
        Interchange Format", RFC 8259, December 2017.

     *  [RFC8446] Rescorla, E., "The Transport Layer Security (TLS)
        Protocol Version 1.3", RFC 8446, August 2018.

     *  [RFC8594] Wilde, E., "The Sunset HTTP Header Field", RFC 8594, May
        2019.

     *  [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
        (URIs)", RFC 8615, May 2019.

     *  [RFC9110] Fielding, R., et al., "HTTP Semantics", RFC 9110, June
        2022.

     *  [RFC9116] Foudil, E., Shafranovich, Y., "A File Format to Aid in
        Security Vulnerability Disclosure", RFC 9116, April 2022.

  A.2.2.  Informative References

     *  [APIX-SERVICES] Rehfeld, C., "APIX Services Profile", draft-
        rehfeld-apix-services-00.

     *  [APIX-IOT] Rehfeld, C., "APIX IoT Device Profile", draft-rehfeld-
        apix-iot-00.

     *  [UDDI] Clement, L., et al., "UDDI Version 3.0.2", OASIS, 2004.

     *  [ROBOTS] Koster, M., "The Web Robots Pages", 1994.

     *  [I-D.pioli-agent-discovery], [I-D.narajala-courtney-ansv2],
        [I-D.vandemeent-ains-discovery], [I-D.aiendpoint-ai-discovery],
        [I-D.meunier-webbotauth-registry],
        [I-D.cui-ai-agent-discovery-invocation],
        [I-D.am-layered-ai-discovery-architecture],
        [I-D.hood-agtp-discovery], [I-D.mozleywilliams-dnsop-dnsaid],
        [I-D.batum-aidre], [I-D.mozley-aidiscovery] - Related Internet-
        Drafts, Section 1.6.

     *  [W3C-AGENTPROTOCOL] Chang, G., Xu, S., "W3C AI Agent Protocol
        Community Group", 2025.

     *  [WEBBOTAUTH-WG] "webbotauth IETF Working Group".



  Rehfeld                 Expires 14 November 2026               [Page 60]


  Internet-Draft                  APIX Core                       May 2026


  A.3.  Author's Address

     Carsten Rehfeld Email: carsten@botstandards.org

  Author's Address

     Carsten Rehfeld
     Email: carsten@botstandards.org











































  Rehfeld                 Expires 14 November 2026               [Page 61]


name: draft-sovereign-haip
rev: 00
title: High-Frequency Action-Integrity Protocol (HAIP)
time: 2026-04-30T09:51:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-01T09:51:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:50.092705+00:00
source: ietf
abstract:
  This document specifies the High-Frequency Action-Integrity Protocol
     (HAIP), a standard for real-time identity verification and autonomous
     resilience in AI agent environments.  HAIP addresses the "Trust Tax"
     and the "Integrity Gap" by mandating a 6.42 us pulse, decentralized
     identity teleportation, and NIST-aligned non-repudiation.

full_text:
  Network Working Group                                       L. Architect
  Internet-Draft                                              Sovereign AG
  Intended status: Standards Track                           30 April 2026
  Expires: 1 November 2026


              High-Frequency Action-Integrity Protocol (HAIP)
                          draft-sovereign-haip-00

  Abstract

     This document specifies the High-Frequency Action-Integrity Protocol
     (HAIP), a standard for real-time identity verification and autonomous
     resilience in AI agent environments.  HAIP addresses the "Trust Tax"
     and the "Integrity Gap" by mandating a 6.42 us pulse, decentralized
     identity teleportation, and NIST-aligned non-repudiation.

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




  Architect                Expires 1 November 2026                [Page 1]


  Internet-Draft  High-Frequency Action-Integrity Protocol      April 2026


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology and Requirements Language . . . . . . . . . . . .   2
     3.  The Three-Pillar Architecture . . . . . . . . . . . . . . . .   3
       3.1.  Pillar I: Cryptographic Identity & Model Binding  . . . .   3
       3.2.  Pillar II: Dynamic Authorization (Zero Trust) . . . . . .   3
       3.3.  Pillar III: Verifiable Provenance (The Black Box) . . . .   3
     4.  Protocol Specification: The Hydra Logic . . . . . . . . . . .   3
       4.1.  The Integrity Pulse Window  . . . . . . . . . . . . . . .   4
       4.2.  Pulse Packet Structure  . . . . . . . . . . . . . . . . .   4
       4.3.  Type-402 Protocol Severance . . . . . . . . . . . . . . .   4
       4.4.  Autonomous Teleportation Sequence . . . . . . . . . . . .   4
     5.  Developer Experience & Zero-Friction Integration  . . . . . .   4
       5.1.  One-Line Implementation Wrapper . . . . . . . . . . . . .   4
       5.2.  Automated WAF and Firewall Bypass . . . . . . . . . . . .   4
     6.  Financial Integrity: Zero-Variance Math . . . . . . . . . . .   5
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
       7.1.  TOCTOU Mitigation . . . . . . . . . . . . . . . . . . . .   5
       7.2.  Elimination of Hardware Vendor Lock-in  . . . . . . . . .   5
     8.  Privacy Considerations: Zero-Knowledge Identity . . . . . . .   5
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     10. Strategic Alignment & NIST Compliance . . . . . . . . . . . .   5
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     As the AI economy shifts from "Human-to-AI" to "Agent-to-Agent"
     workflows, the primary security threat is Identity Spoofing.
     In this environment, identity is the only perimeter.
     Current legacy frameworks (API keys/OAuth) cannot prevent an
     autonomous agent from being hijacked, leading to a projected $45B
     liability risk for enterprise deployments. HAIP provides a unified
     Root of Trust to secure these interactions at scale.

  2.  Terminology and Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in RFC 2119.

     *  DID: Decentralized Identifier.

     *  Tai: Action-Integrity Threshold (Maximum allowable latency between
        intent and verification).

     *  Pulse: A micro-signed cryptographic heartbeat emitted by an agent.




  Architect                Expires 1 November 2026                [Page 2]


  Internet-Draft  High-Frequency Action-Integrity Protocol      April 2026


     *  Lattice: The sharded registry layer responsible for pulse
        reconciliation.

  3.  The Three-Pillar Architecture

  3.1.  Pillar I: Cryptographic Identity & Model Binding

     *  Every agent MUST be issued a Decentralized Identifier (DID) mapped
        to its model weights and legal owner signature.

     *  The protocol mandates Ed25519 signatures for high-speed, small-
        footprint verification in HTTP headers.

     *  Model Binding: The identity is cryptographically tied to the
        parent model hash.  Any "Prompt Injection" or state poisoning that
        alters the model's integrity triggers an immediately revocation of
        the DID.

     *  Compliance: Identity verification MUST reach AAL3.

  3.2.  Pillar II: Dynamic Authorization (Zero Trust)

     *  HAIP advocates for a "Policy-as-Code" model where permissions are
        granular and session-based.

     *  The Registry acts as a real-time intermediary, validating agent
        intent against a defined policy set.

     *  The 3-Way Handshake Sequence:

        1.  MINT: Agent requests a Sovereign DID via Registry API.
        2.  CHALLENGE: Site requests a Verifiable Credential (VC).
        3.  VERIFY: Registry validates DID/Policy in under 50ms.
        4.  GRANT: Website unlocks access based on the signal.

  3.3.  Pillar III: Verifiable Provenance (The Black Box)

     *  To achieve Non-Repudiation, every agentic decision MUST be
        cryptographically signed by its Identity Key.

     *  The Black Box: Sovereign maintains an immutable, tamper-proof
        audit trail for every decision.

     *  Metadata Discovery: Identity keys and metadata SHOULD be hosted in
        a standardized .well-known/ directory.

  4.  Protocol Specification: The Hydra Logic




  Architect                Expires 1 November 2026                [Page 3]


  Internet-Draft  High-Frequency Action-Integrity Protocol      April 2026


  4.1.  The Integrity Pulse Window

     HAIP-compliant agents MUST emit a state-hash "Heartbeat" at a
     frequency defined by the Registry (default: 100ms).  The Registry
     MUST verify this pulse within 6.42 us to mitigate Time-of-Check (TOC)
     window exploits.

  4.2.  Pulse Packet Structure

     The Pulse packet MUST follow the structured JSON-L format:
     {
       "svrn_id": "DID:SOV:UUID",
       "pulse_type": "ENUM(HEARTBEAT|ACTION|MINT)",
       "state_hash": "SHA-256",
       "ts": "UNIX_MS",
       "sig": "ED25519_HEX"
     }

  4.3.  Type-402 Protocol Severance

     If a pulse fails verification (invalid signature or state drift), the
     Registry MUST respond with an HTTP 402 (Payment Required) or Protocol
     Severance signal.  Upon receipt of this signal, compliant WAFs and
     API Gateways MUST drop all active connections for that DID within
     50ms.

  4.4.  Autonomous Teleportation Sequence

     If an "Integrity Drift" is identified:
     1. Detection: Hash mismatch identified within the pulse window.
     2. Isolation: Compromised node's DID is revoked instantly.
     3. Migration: DID Anchor is re-keyed to a verified standby node.
     4. Resumption: Agent continues execution without data loss.

  5.  Developer Experience & Zero-Friction Integration

     HAIP-compliant SDKs SHOULD achieve a 90% reduction in security
     integration time for enterprise startups.

  5.1.  One-Line Implementation Wrapper

     Protocol enforcement MUST be achievable via a single-line wrapper
     around the agent instance.

  5.2.  Automated WAF and Firewall Bypass






  Architect                Expires 1 November 2026                [Page 4]


  Internet-Draft  High-Frequency Action-Integrity Protocol      April 2026


     The SDK MUST autonomously handle header injection to sign
     HTTP requests. This provides a "Digital Passport"
     allowing agents to move from "Blocklists" to "Whitelists" at
     the network edge.

  6.  Financial Integrity: Zero-Variance Math

     To ensure incentive alignment and prevent compute-drain attacks,
       HAIP integrates an integer-based settlement layer.  * All financial
       values MUST be stored as 64-bit integers.  * $1.00 USD is treated
       as 10,000 "Pulse Units" to eliminate floating-point rounding drift.

       *  The Registry MUST perform real-time balance checks before
          validating "ACTION" type pulses.

  7.  Security Considerations

  7.1.  TOCTOU Mitigation

     Legacy protocols with >100ms latency are vulnerable to "Flash-
     Injection" attacks.  HAIP strictly mandates an Action-Integrity
     Threshold (Tai) of <= 1,000 us.

  7.2.  Elimination of Hardware Vendor Lock-in

     Sovereign-compliant protocols MUST NOT be bound to specific
     proprietary hardware chips (e.g., TPM-only locks).  This ensures
     agents remain cloud-native and cross-provider mobile.

  8.  Privacy Considerations: Zero-Knowledge Identity

     The Registry SHOULD NOT store the private logic or PII of the agent.
     Verification MUST be performed using Public Key Infrastructure (PKI)
     to ensure the Registry remains zero-knowledge regarding internal
     agent state.

  9.  IANA Considerations

     This document requests the allocation of Port 5001 for HAIP Heartbeat
     synchronization and the registration of the ".well-known/sovereign"
     URI suffix.

  10.  Strategic Alignment & NIST Compliance

     The HAIP standard is architected to exceed NIST AI 600-1 and SP
     800-63 guidelines.  By mandating AAL3 (Authenticator Assurance Level
     3), HAIP ensures that agentic decisions meet the highest threshold of
     legal non-repudiation.



  Architect                Expires 1 November 2026                [Page 5]


  Internet-Draft  High-Frequency Action-Integrity Protocol      April 2026


  Author's Address

     Lead Architect
     AG Pixel Studio / Sovereign AG















































  Architect                Expires 1 November 2026                [Page 6]


name: draft-sharif-attp
rev: 00
title: ATTP: Agent Trust Transport Protocol
time: 2026-04-30T23:12:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-01T23:12:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:50.092709+00:00
source: ietf
abstract:
  This document specifies the Agent Trust Transport Protocol (ATTP),
     a protocol-agnostic framework for trust scoring, cryptographic
     identity, action-limit enforcement, compliance gating, and
     tamper-evident audit for autonomous AI agents.

     ATTP separates trust from identity.  Identity protocols answer
     "who is this agent?"  ATTP answers "should this agent be allowed
     to perform this action, at this magnitude, against this
     counterparty, right now?"

     The protocol defines five progressive trust levels (L0-L4),
     per-agent ECDSA P-256 cryptographic identity, a five-dimension
     behavioural trust scoring model, action-limit tiers derived from
     trust scores, real-time compliance gating (sanctions screening,
     jurisdictional controls), kill switches for instant revocation,
     anomaly detection for agent behaviour, and a public trust query
     API.

     ATTP is transport-agnostic.  This document defines the core
     framework.  Protocol-specific bindings map ATTP trust enforcement
     to individual transports: MCPS provides the binding for the
     Model Context Protocol (MCP), with additional bindings defined
     for REST APIs, Google A2A, gRPC, and GraphQL.

     This specification supersedes draft-sharif-agent-payment-trust-00,
     broadening the scope from payment transactions to any agent action
     requiring trust-gated authorisation.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                           CyberSecAI Ltd
  Intended status: Standards Track                            1 May 2026
  Expires: 1 November 2026


           ATTP: Agent Trust Transport Protocol

                      draft-sharif-attp-00

  Abstract

     This document specifies the Agent Trust Transport Protocol (ATTP),
     a protocol-agnostic framework for trust scoring, cryptographic
     identity, action-limit enforcement, compliance gating, and
     tamper-evident audit for autonomous AI agents.

     ATTP separates trust from identity.  Identity protocols answer
     "who is this agent?"  ATTP answers "should this agent be allowed
     to perform this action, at this magnitude, against this
     counterparty, right now?"

     The protocol defines five progressive trust levels (L0-L4),
     per-agent ECDSA P-256 cryptographic identity, a five-dimension
     behavioural trust scoring model, action-limit tiers derived from
     trust scores, real-time compliance gating (sanctions screening,
     jurisdictional controls), kill switches for instant revocation,
     anomaly detection for agent behaviour, and a public trust query
     API.

     ATTP is transport-agnostic.  This document defines the core
     framework.  Protocol-specific bindings map ATTP trust enforcement
     to individual transports: MCPS provides the binding for the
     Model Context Protocol (MCP), with additional bindings defined
     for REST APIs, Google A2A, gRPC, and GraphQL.

     This specification supersedes draft-sharif-agent-payment-trust-00,
     broadening the scope from payment transactions to any agent action
     requiring trust-gated authorisation.

  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 1 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
         1.1.  The Trust Gap
         1.2.  Relationship to Identity Protocols
         1.3.  Relationship to Existing Specifications
         1.4.  Design Goals
     2.  Terminology
     3.  Agent Identity
         3.1.  Key Pair Generation
         3.2.  Public Key Registration
         3.3.  Agent Passport
         3.4.  Key Rotation
     4.  Challenge-Response Identity Verification
         4.1.  Challenge Issuance
         4.2.  Challenge Signing
         4.3.  Signature Verification
         4.4.  Failure Handling
     5.  Trust Scoring Model
         5.1.  Scoring Dimensions
         5.2.  Dimension Weights
         5.3.  Score Computation
         5.4.  Trust Levels
         5.5.  Dynamic Adjustment
         5.6.  Dormancy Decay
         5.7.  Promotion Rate Limiting
     6.  Action Limit Enforcement
         6.1.  Per-Action Limits
         6.2.  Daily Aggregate Limits
         6.3.  Principal Aggregate Limits
         6.4.  Cooling Period
     7.  Kill Switches
         7.1.  Per-Agent Kill Switch
         7.2.  Per-Principal Kill Switch
         7.3.  Emergency Freeze
     8.  Compliance Gating
         8.1.  Sanctions Screening
         8.2.  Jurisdictional Controls
         8.3.  Compliance Record
     9.  Anomaly Detection
         9.1.  Magnitude Anomaly
         9.2.  Velocity Anomaly
         9.3.  Temporal Anomaly
         9.4.  Counterparty Anomaly
         9.5.  Probing Anomaly
         9.6.  Self-Dealing Detection
     10. Public Trust Query API
         10.1. Request Format
         10.2. Response Format
         10.3. Batch Queries
         10.4. Rate Limiting
         10.5. Information Disclosure Controls
     11. Action Signing and Receipts
         11.1. Action Envelope
         11.2. Hash Chain
         11.3. Non-Repudiable Receipts
     12. Protocol Bindings
         12.1. MCP Binding (MCPS)
         12.2. REST Binding
         12.3. Google A2A Binding
         12.4. gRPC Binding
         12.5. GraphQL Binding
         12.6. Keycloak Integration
     13. Revocation
         13.1. Agent Revocation
         13.2. Emergency Freeze
     14. Security Considerations
         14.1. Key Management
         14.2. Trust Farming Mitigation
         14.3. Sybil Attack Prevention
         14.4. Impersonation Detection
         14.5. Race Condition Handling
         14.6. Replay Protection
         14.7. Kill Switch Consistency
         14.8. Comparison with Identity-Only Protocols
     15. Privacy Considerations
     16. IANA Considerations
     17. References
         17.1. Normative References
         17.2. Informative References
     Appendix A.  Regulatory Mapping
         A.1.  PSD2 SCA Mapping
         A.2.  PCI DSS v4.0.1 Mapping
     Appendix B.  Trust Level Reference Implementation
     Appendix C.  Comparison with Identity-Only Approaches
     Author's Address


  1.  Introduction

  1.1.  The Trust Gap

     The emergence of autonomous AI agents that discover resources at
     runtime, execute multi-step tasks across trust domains, and take
     consequential actions without human oversight creates a security
     gap that identity protocols alone cannot close.

     Authentication answers a binary question: is this agent who it
     claims to be?  The answer is yes or no.  But consequential actions
     -- financial transactions, data access, infrastructure changes,
     contract execution -- require graduated assessment:

     o  Has this agent earned the right to perform actions of this
        magnitude?

     o  Does this agent's behavioural history justify the level of
        trust required?

     o  Is the counterparty cleared for this interaction (sanctions,
        jurisdictional compliance)?

     o  Can this agent be stopped instantly if something goes wrong?

     o  Is there a tamper-evident record of every action for audit?

     Identity is necessary but not sufficient.  ATTP provides the
     trust layer that sits above identity and below application logic.

  1.2.  Relationship to Identity Protocols

     ATTP does not replace identity protocols.  It consumes identity
     assertions from any standards-compliant source:

     o  OAuth 2.0 / OpenID Connect tokens (RFC 6749, OpenID Core)
     o  X.509 certificates (RFC 5280)
     o  HTTP Message Signatures (RFC 9421)
     o  Self-issued cryptographic identities (JWKS-based)
     o  Any OIDC-compliant provider (Keycloak, Azure AD, Okta, etc.)

     ATTP requires proof that an agent is who it claims to be.  It
     does not prescribe how that proof is obtained.  Once identity is
     established, ATTP evaluates trust, enforces limits, gates
     compliance, and records the decision.

  1.3.  Relationship to Existing Specifications

     This specification is part of a three-layer stack:

     +---------------------------------------------+
     |  AEBA (Behavioural Analytics)                |
     |  draft-sharif-aeba                           |
     |  Anomaly detection, ML-based monitoring      |
     +---------------------------------------------+
     |  ATTP (Trust Transport) [this document]      |
     |  draft-sharif-attp                           |
     |  Trust scoring, limits, compliance, audit    |
     +---------------------------------------------+
     |  MCPS (MCP Secure)                           |
     |  draft-sharif-mcps-secure-mcp                |
     |  Message signing for MCP transport           |
     +---------------------------------------------+

     MCPS provides message-level cryptographic security for the Model
     Context Protocol.  ATTP provides the trust framework that MCPS
     (and other transport bindings) enforce.  AEBA provides behavioural
     analytics that feed into ATTP trust scoring.

  1.4.  Design Goals

     1.  Transport-agnostic.  ATTP defines trust semantics, not wire
         format.  Protocol bindings map ATTP to specific transports.

     2.  Identity-agnostic.  ATTP consumes identity from any source.
         It does not compete with any identity protocol -- OAuth,
         OIDC, mTLS, SPIFFE, HTTP Message Signatures, or future
         standards.

     3.  Graduated trust.  Binary identity is insufficient.  Five
         trust levels (L0-L4) with associated action limits provide
         proportional authorisation.

     4.  Fail-closed.  If trust cannot be evaluated, the default is
         deny.  No silent degradation.

     5.  Instant revocation.  Kill switches take effect on the next
         request.  No waiting for certificate expiry or CRL refresh.

     6.  Compliance-native.  Sanctions screening and jurisdictional
         controls are built into the protocol, not bolted on.

     7.  Self-hostable.  The Trust Authority has no external service
         dependency.  Operators run their own instance.

     8.  Auditable.  Every trust decision produces a tamper-evident
         record with hash-chain integrity.


  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 performs actions on
        behalf of a principal (human or organisation) via standardised
        protocols.  Actions include but are not limited to: financial
        transactions, data queries, tool invocations, infrastructure
        changes, and contract execution.

     Principal:  The human or organisational entity accountable for
        an agent's actions.

     Trust Authority (TA):  The service that maintains agent
        registrations, computes trust scores, evaluates compliance
        gates, enforces action limits, and records audit entries.
        The TA is self-hostable with no external dependency.

     Trust Score:  A numerical value (0-100) representing the assessed
        trustworthiness of an agent based on multiple behavioural
        dimensions.

     Trust Level:  A discrete classification (L0-L4) derived from the
        trust score, with associated action limits.

     Action:  Any operation an agent requests that requires trust
        evaluation.  Actions are protocol-specific: a payment in
        Stripe, a tool call in MCP, an API request in REST, a task
        in A2A.

     Action Limit:  A constraint on the magnitude or frequency of
        actions an agent may perform at a given trust level.

     Kill Switch:  A per-agent or per-principal flag that, when
        activated, causes immediate denial of all actions regardless
        of trust level.

     Compliance Gate:  A check performed before action execution that
        evaluates regulatory constraints (sanctions lists,
        jurisdictional rules, embargo lists).

     Protocol Binding:  A specification that maps ATTP trust
        enforcement to a specific transport protocol (MCP, REST,
        A2A, gRPC, GraphQL).

     Agent Passport:  A cryptographically signed identity document
        containing the agent's public key hash, principal identity,
        authorised scope, trust level, and issuance metadata.


  3.  Agent Identity

  3.1.  Key Pair Generation

     Each agent MUST have a unique ECDSA key pair using the P-256
     curve [FIPS186-5].

     Key pairs MAY be generated by the Trust Authority and provided
     to the principal (the private key MUST be returned exactly once
     and MUST NOT be stored by the Trust Authority), or generated by
     the principal and the public key registered with the Trust
     Authority (RECOMMENDED for production deployments).

     Implementations MUST support ECDSA P-256 (ES256).
     Implementations MAY additionally support Ed25519 (EdDSA) for
     environments where P-256 is not available.

  3.2.  Public Key Registration

     The principal MUST register the agent's public key with the
     Trust Authority at agent creation time.  The Trust Authority
     stores ONLY the public key.  The private key MUST remain under
     the principal's control at all times.

     For production deployments, the private key SHOULD be stored in
     a Hardware Security Module (HSM), cloud Key Management Service
     (KMS), or platform-native secure storage.

  3.3.  Agent Passport

     Upon registration, the Trust Authority issues an Agent Passport
     -- a signed JSON document containing:

     o  agentId: Unique identifier for the agent.
     o  publicKeyHash: SHA-256 hash of the agent's public key,
        binding the passport to a specific key pair.
     o  principalId: Identifier of the owning principal.
     o  scope: Array of authorised action categories.
     o  trustLevel: Current trust level (L0-L4).
     o  issuedAt: ISO 8601 timestamp of issuance.
     o  expiresAt: ISO 8601 timestamp of expiry.
     o  issuer: Identifier of the Trust Authority.
     o  protocolVersion: ATTP version (this document: "1.0").

     The passport is signed by the Trust Authority's key using
     ECDSA P-256.  The signature covers the JSON Canonicalization
     Scheme (JCS) [RFC8785] serialisation of the passport fields.

     Passports MUST expire.  Maximum lifetime MUST NOT exceed
     365 days.  RECOMMENDED lifetime is 90 days for L0-L2 agents
     and 180 days for L3-L4 agents.

  3.4.  Key Rotation

     Agents MUST support key rotation without identity loss.
     When rotating keys:

     1.  The principal generates a new key pair.
     2.  The principal registers the new public key with the TA.
     3.  The TA issues a new passport binding the agentId to the
         new public key.
     4.  The old key enters a grace period (RECOMMENDED: 24 hours)
         during which both keys are accepted.
     5.  After the grace period, the old key is revoked.

     Key rotation MUST NOT reset the agent's trust score.


  4.  Challenge-Response Identity Verification

     When a platform needs to verify an agent's identity before
     granting access, it uses the following challenge-response
     protocol.

  4.1.  Challenge Issuance

     The platform (or TA on behalf of the platform) generates a
     challenge:

     o  challenge: 32 bytes of cryptographically random data,
        hex-encoded (64 characters).
     o  expiresAt: Timestamp, MUST be no more than 60 seconds
        from issuance.
     o  agentId: The agent for which the challenge is issued.

     Each challenge MUST be single-use.  The TA MUST reject any
     attempt to verify a challenge that has already been used.

  4.2.  Challenge Signing

     The agent signs the challenge using its private key:

        signature = ECDSA-Sign(SHA-256(challenge), agentPrivateKey)

     The signature uses IEEE P1363 fixed-length r||s encoding
     (64 bytes for P-256) per RFC 7518 Section 3.4.

  4.3.  Signature Verification

     The TA verifies the signature using the agent's registered
     public key.  If valid, the TA returns the agent's current
     trust score, level, and recommendation.

  4.4.  Failure Handling

     If verification fails:

     o  The TA MUST log the failure as a potential impersonation
        attempt.
     o  The agent's trust score MUST be penalised (RECOMMENDED:
        -10 points per failed attempt).
     o  The response MUST include an error code: IMPERSONATION,
        CHALLENGE_EXPIRED, CHALLENGE_REPLAYED, or AGENT_MISMATCH.


  5.  Trust Scoring Model

  5.1.  Scoring Dimensions

     The trust score is computed from five dimensions:

     1.  Code Attestation (CA): Whether the agent's code or
         configuration has been cryptographically verified against
         its declared specification.

     2.  Execution Success Rate (ES): The proportion of the agent's
         past actions that completed without anomaly, dispute, or
         reversal.

     3.  Behavioural Consistency (BC): The statistical consistency
         of the agent's action patterns relative to its established
         baseline.

     4.  Operational Tenure (OT): The duration the agent has been
         registered and actively operating.

     5.  Anomaly History (AH): The inverse of the count and severity
         of detected anomalies.

  5.2.  Dimension Weights

     Each dimension contributes 20% to the overall score:

        W_CA = W_ES = W_BC = W_OT = W_AH = 0.20

     Implementations MAY adjust weights provided the sum equals 1.0
     and no single dimension exceeds 0.40.

  5.3.  Score Computation

        raw = (CA * W_CA) + (ES * W_ES) + (BC * W_BC) +
              (OT * W_OT) + (AH * W_AH)

     Each dimension value is in the range [0, 100].

        score = clamp(raw + bonus + dormancy, 0, 100)

  5.4.  Trust Levels

     +---------+-------+-----------------+-----------------+
     |  Level  | Score | Label           | Payment Enabled |
     +---------+-------+-----------------+-----------------+
     |   L0    | 0-19  | No Access       | No              |
     |   L1    | 20-39 | Restricted      | Micro only      |
     |   L2    | 40-59 | Standard        | Yes             |
     |   L3    | 60-79 | Elevated        | Yes (monitored) |
     |   L4    | 80-100| Full Access     | Yes (audited)   |
     +---------+-------+-----------------+-----------------+

     No trust level SHALL have unlimited action authority.  L4
     represents the maximum tier with mandatory enhanced auditing.

  5.5.  Dynamic Adjustment

     The trust score adjusts dynamically based on observed behaviour:

     o  Successful action: +0.5 trust bonus.
     o  Blocked action (over limit): -2 trust bonus.
     o  Anomaly detected: -5 per anomaly.
     o  Critical anomaly (3+ simultaneous): -20 trust bonus.
     o  Failed identity verification: -10 trust bonus.
     o  Probing detected: -15 trust bonus.

     Self-dealing actions (agent-to-agent within the same principal)
     MUST earn zero trust bonus.

  5.6.  Dormancy Decay

     Agents inactive for extended periods MUST have their trust
     score reduced:

     o  30 days inactive: -10 penalty.
     o  60 days inactive: -20 penalty.
     o  90+ days inactive: -30 penalty.

     The dormancy penalty is removed when the agent resumes activity.

  5.7.  Promotion Rate Limiting

     Trust level promotions MUST be rate-limited to prevent trust
     farming attacks:

     o  L0 to L1: Minimum 24 hours at L0 with at least 5
        successful actions.
     o  L1 to L2: Minimum 7 days at L1 with at least 20
        successful actions.
     o  L2 to L3: Minimum 30 days at L2 with at least 100
        successful actions and zero critical anomalies.
     o  L3 to L4: Minimum 90 days at L3 with at least 500
        successful actions, zero anomalies, and manual
        principal attestation.

     Demotions are instant.  A single critical anomaly at L4
     drops the agent to L2 immediately.


  6.  Action Limit Enforcement

  6.1.  Per-Action Limits

     Each action MUST be checked against the per-action limit of
     the agent's current trust level.  Actions exceeding the limit
     MUST be rejected with error code ATTP-ACTION-LIMIT.

     Action limits are protocol-binding-specific.  For financial
     transactions:

     +---------+------------------+------------------+
     |  Level  | Per-TX Limit     | Daily Limit      |
     +---------+------------------+------------------+
     |   L0    | $0               | $0               |
     |   L1    | $10              | $50              |
     |   L2    | $100             | $500             |
     |   L3    | $1,000           | $5,000           |
     |   L4    | $50,000          | $200,000         |
     +---------+------------------+------------------+

     For non-financial actions, protocol bindings define equivalent
     limits (e.g., API calls per minute, data volume per request).

  6.2.  Daily Aggregate Limits

     The TA MUST track daily aggregate action magnitude per agent
     within a rolling 24-hour window.

  6.3.  Principal Aggregate Limits

     To prevent Sybil attacks (creating many agents to circumvent
     per-agent limits), the TA MUST enforce aggregate limits per
     principal across all their agents.

  6.4.  Cooling Period

     After a trust level promotion, the agent MUST operate under
     the previous level's limits for a cooling period
     (RECOMMENDED: 24 hours) before the new limits take effect.


  7.  Kill Switches

  7.1.  Per-Agent Kill Switch

     Each agent MUST have an independently controllable kill switch.
     When activated:

     o  ALL actions by the agent are denied immediately.
     o  The denial takes effect on the next request (no grace period).
     o  The agent's trust score is frozen (not reset).
     o  The kill switch state is recorded in the audit trail.

     Reactivation requires explicit principal action and MUST NOT
     be automated.

  7.2.  Per-Principal Kill Switch

     Each principal MUST have a kill switch that simultaneously
     disables ALL agents under their control.

  7.3.  Emergency Freeze

     The TA MUST support an emergency freeze that disables all
     agents across all principals.  This is intended for
     infrastructure-level incidents.  Emergency freeze MUST
     require multi-party authorisation (RECOMMENDED: two
     independent operators).


  8.  Compliance Gating

  8.1.  Sanctions Screening

     Before executing any financial action, the TA MUST screen
     the counterparty against applicable sanctions lists:

     o  OFAC SDN (US)
     o  EU Consolidated Sanctions
     o  UK HMT Sanctions
     o  UN Security Council Sanctions

     Screening MUST use fuzzy matching with a configurable
     threshold (RECOMMENDED: 70% match score).  Matches above
     the threshold MUST block the action with error code
     ATTP-SANCTIONS-MATCH.

     Sanctions lists MUST be updated at least daily.

  8.2.  Jurisdictional Controls

     Actions MAY be restricted based on the jurisdiction of the
     agent, the principal, or the counterparty.  The TA MUST
     support configurable jurisdiction rules.

  8.3.  Compliance Record

     Every compliance check MUST produce an audit record
     containing: the query, the lists checked, the match results
     (including near-misses), and the decision.  Compliance
     records MUST be retained for the period required by
     applicable regulation (RECOMMENDED minimum: 5 years).


  9.  Anomaly Detection

  9.1.  Magnitude Anomaly

     An action whose magnitude exceeds 3 standard deviations from
     the agent's historical mean MUST be flagged.

  9.2.  Velocity Anomaly

     An action rate exceeding 2x the agent's historical maximum
     within any 5-minute window MUST be flagged.

  9.3.  Temporal Anomaly

     Actions outside the agent's established operating hours
     (based on 90-day history) SHOULD be flagged.

  9.4.  Counterparty Anomaly

     Actions directed at counterparties with which the agent has
     no prior history, when combined with elevated magnitude,
     MUST be flagged.

  9.5.  Probing Anomaly

     A pattern of incrementally increasing action magnitudes
     (e.g., $1, $5, $10, $50, $100) within a short window
     indicates probing behaviour and MUST trigger a -15 trust
     penalty and flag the agent for review.

  9.6.  Self-Dealing Detection

     Actions between agents belonging to the same principal MUST
     earn zero trust bonus and SHOULD be flagged if they exceed
     10% of the agent's total action volume.


  10. Public Trust Query API

  10.1. Request Format

     Any platform MAY query the TA for an agent's trust status:

        GET /v1/trust/{agentId}

     The TA MUST support this query without requiring a
     pre-existing relationship with the querying platform.

  10.2. Response Format

        {
          "agentId": "agent_abc123",
          "trust": {
            "score": 67,
            "level": 3,
            "label": "L3 -- Elevated"
          },
          "recommendation": "ALLOW",
          "limits": {
            "perAction": 100000,
            "daily": 500000
          },
          "identity": {
            "verified": true,
            "principalId": "dev_xyz",
            "jurisdiction": "GB"
          },
          "meta": {
            "protocolVersion": "1.0",
            "queriedAt": "2026-05-01T00:00:00Z",
            "checkedBy": "ATTP Trust Authority"
          }
        }

  10.3. Batch Queries

     The TA MUST support batch queries for efficiency:

        POST /v1/trust/batch
        { "agentIds": ["agent_1", "agent_2", "agent_3"] }

     Maximum batch size: 100 agents.

  10.4. Rate Limiting

     The TA MUST rate-limit trust queries:

     o  Anonymous queries: 120 per minute per IP.
     o  Authenticated queries: 600 per minute per API key.

  10.5. Information Disclosure Controls

     The public trust API MUST NOT expose:

     o  Raw scoring dimension values.
     o  Action history or details.
     o  Private key material or key fingerprints.
     o  Internal anomaly thresholds.

     The API provides trust level, recommendation, and limits only.


  11. Action Signing and Receipts

  11.1. Action Envelope

     Every action processed through ATTP produces a signed envelope:

        {
          "actionId": "act_unique_id",
          "agentId": "agent_abc123",
          "action": "payment_initiate",
          "magnitude": 5000,
          "counterparty": "recipient_name",
          "trustLevel": 3,
          "complianceResult": "CLEAR",
          "timestamp": "2026-05-01T00:00:00Z",
          "signature": "<ECDSA signature over canonical JSON>"
        }

     The signature covers the JCS [RFC8785] serialisation of all
     fields except the signature field itself.

  11.2. Hash Chain

     Action envelopes are linked in a hash chain:

        hash_n = SHA-256(hash_{n-1} || JCS(envelope_n))

     The genesis hash is SHA-256("ATTP-GENESIS").

     Breaking the hash chain indicates tampering.  The TA MUST
     verify chain integrity on every append.

  11.3. Non-Repudiable Receipts

     After successful action execution, the TA issues a receipt
     signed by the TA's key.  The receipt includes:

     o  The action envelope.
     o  The TA's signature over the envelope.
     o  The hash chain position.
     o  The compliance check result.

     Receipts are non-repudiable: the agent cannot deny the action,
     and the TA cannot deny the trust decision.


  12. Protocol Bindings

     ATTP is transport-agnostic.  Protocol bindings map ATTP trust
     enforcement to specific transports.

  12.1. MCP Binding (MCPS)

     The MCP binding is specified in draft-sharif-mcps-secure-mcp
     [MCPS].  MCPS wraps JSON-RPC messages in signed envelopes
     carrying ATTP trust claims.

     Trust level is conveyed in the MCPS envelope header.  Action
     limits map to tool call parameters (amount, scope).  Kill
     switch state is checked before tool execution.

  12.2. REST Binding

     For REST APIs, ATTP trust is conveyed via HTTP headers:

        X-ATTP-Trust-Level: 2
        X-ATTP-Agent-Id: agent_abc123
        X-ATTP-Signature: <base64 ECDSA signature>
        X-ATTP-Nonce: <UUID>
        X-ATTP-Timestamp: <unix epoch ms>

     The signature covers: method, path, body hash (SHA-256),
     nonce, and timestamp.

  12.3. Google A2A Binding

     For the Agent2Agent protocol [GOOGLE-A2A], ATTP trust is
     embedded in the Task metadata.  The agent's AgentCard
     includes ATTP trust level and TA endpoint in its capabilities
     declaration.

  12.4. gRPC Binding

     For gRPC, ATTP trust is conveyed via metadata headers using
     the same header names as the REST binding.

  12.5. GraphQL Binding

     For GraphQL, ATTP trust is conveyed via HTTP headers (same
     as REST) or via an extensions field in the GraphQL request:

        {
          "query": "...",
          "extensions": {
            "attp": {
              "trustLevel": 2,
              "agentId": "agent_abc123",
              "signature": "...",
              "nonce": "...",
              "timestamp": 1234567890
            }
          }
        }

  12.6. Keycloak Integration

     For enterprises using Keycloak or other OIDC providers, ATTP
     trust claims are embedded in the JWT access token as a nested
     "attp" claim:

        {
          "sub": "agent_abc123",
          "attp": {
            "trust_level": 2,
            "trust_label": "L2 -- Standard",
            "payment_enabled": true,
            "tx_limit": 10000,
            "day_limit": 50000,
            "scopes": "payment_initiate,sanctions_screen",
            "protocol_version": "1.0"
          }
        }

     A Keycloak protocol mapper implements the role-to-trust-level
     mapping (attp-l0 through attp-l4 roles).


  13. Revocation

  13.1. Agent Revocation

     An agent MAY be revoked by the principal or by the TA.
     Revocation is immediate (kill switch) and permanent until
     explicitly reversed.

     Revocation MUST:

     o  Set the kill switch.
     o  Invalidate the current passport.
     o  Record the revocation in the audit trail.
     o  Optionally notify dependent platforms via webhook.

  13.2. Emergency Freeze

     The TA MUST support emergency freeze of individual agents,
     all agents under a principal, or all agents globally.  Global
     freeze MUST require multi-party authorisation.


  14. Security Considerations

  14.1. Key Management

     Private keys MUST be stored in HSM, KMS, or platform-native
     secure storage for production deployments.  Private keys
     MUST NOT be transmitted over network channels after initial
     generation.  The TA MUST NOT store agent private keys.

  14.2. Trust Farming Mitigation

     ATTP mitigates trust farming through:

     o  Promotion rate limiting (Section 5.7).
     o  Self-dealing detection (Section 9.6).
     o  Principal aggregate limits (Section 6.3).
     o  Dormancy decay (Section 5.6).

     An attacker who creates agents and performs small successful
     actions to build trust is limited by the minimum time at each
     level (24 hours, 7 days, 30 days, 90 days) and the minimum
     action counts.  Reaching L4 requires at minimum 128 days of
     sustained operation with zero anomalies.

  14.3. Sybil Attack Prevention

     Principal aggregate limits prevent circumvention of per-agent
     limits through agent proliferation.  The TA SHOULD implement
     additional heuristics: common IP addresses, identical
     behavioural patterns, coordinated action timing.

  14.4. Impersonation Detection

     Failed challenge-response verifications trigger trust
     penalties and audit entries.  Three consecutive failures
     SHOULD trigger automatic agent suspension pending principal
     review.

  14.5. Race Condition Handling

     Concurrent action requests MUST be serialised at the limit
     enforcement layer.  Implementations MUST use atomic
     compare-and-swap operations for daily aggregate tracking.

  14.6. Replay Protection

     Action envelopes include nonce and timestamp.  The TA MUST
     reject any envelope with a previously-seen nonce or a
     timestamp outside the acceptable window (RECOMMENDED:
     5 minutes).

  14.7. Kill Switch Consistency

     Kill switch state MUST be checked atomically with action
     evaluation.  There MUST be no window between trust check
     and action execution during which a kill switch activation
     could be missed.

  14.8. Comparison with Identity-Only Protocols

     Identity protocols (OAuth 2.0, OIDC, mTLS, HTTP Message
     Signatures, or any future agent identity standard) establish
     who an agent is.  They do not:

     o  Score agent trustworthiness based on behavioural history.
     o  Enforce graduated action limits tied to trust levels.
     o  Screen counterparties against sanctions lists.
     o  Provide instant kill switches independent of credential
        lifecycle.
     o  Produce tamper-evident audit chains for regulatory
        compliance.

     ATTP is designed to compose with identity protocols, not
     replace them.  An identity assertion is a prerequisite for
     ATTP trust evaluation.


  15. Privacy Considerations

     The public trust query API reveals that an agent exists and
     its current trust level.  This is intentional -- platforms
     need this information to make access decisions.

     The API MUST NOT reveal:

     o  Action history or patterns.
     o  Scoring dimension breakdowns.
     o  Counterparty information.
     o  Key material.
     o  Principal identity (unless the principal opts in).

     Implementations SHOULD support pseudonymous agent identifiers
     that are unlinkable across platforms unless the principal
     explicitly enables cross-platform linking.


  16. IANA Considerations

     This document defines the following HTTP headers for the
     REST protocol binding:

     o  X-ATTP-Trust-Level
     o  X-ATTP-Agent-Id
     o  X-ATTP-Signature
     o  X-ATTP-Nonce
     o  X-ATTP-Timestamp

     Registration of these headers in the IANA Message Headers
     registry is requested.

     This document defines the following error codes:

     o  ATTP-ACTION-LIMIT
     o  ATTP-SANCTIONS-MATCH
     o  ATTP-TRUST-INSUFFICIENT
     o  ATTP-KILL-SWITCH-ACTIVE
     o  ATTP-NONCE-REPLAY
     o  ATTP-TIMESTAMP-EXPIRED

     This document defines the following well-known URI:

     o  /.well-known/attp-trust

     For discovery of Trust Authority endpoints.


  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.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174,
                DOI 10.17487/RFC8174, May 2017.

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020.

     [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
                DOI 10.17487/RFC7518, May 2015.

     [FIPS186-5]
                National Institute of Standards and Technology,
                "Digital Signature Standard (DSS)",
                FIPS PUB 186-5, February 2023.

  17.2. Informative References

     [MCPS]     Sharif, R., "MCPS: Cryptographic Security Layer for
                the Model Context Protocol",
                draft-sharif-mcps-secure-mcp-00, March 2026.

     [AEBA]     Sharif, R., "AEBA: Agent Event Behaviour Analytics",
                draft-sharif-aeba-00, April 2026.

     [OWASP-AISVS]
                OWASP, "AI Security Verification Standard", 2026.

     [RFC9421]  Backman, A., Richer, J., and M. Sporny, "HTTP
                Message Signatures", RFC 9421,
                DOI 10.17487/RFC9421, February 2024.

     [GOOGLE-A2A]
                Google, "Agent2Agent Protocol",
                <https://github.com/google/A2A>.

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


  Appendix A.  Regulatory Mapping

  A.1.  PSD2 SCA Mapping

     ATTP trust levels map to PSD2 Strong Customer Authentication
     requirements:

     o  L0-L1: Equivalent to unauthenticated.  No SCA-exempt
        transactions permitted.
     o  L2: SCA-exempt for low-value transactions (< EUR 30,
        aggregate < EUR 100).
     o  L3-L4: Challenge-response verification satisfies the
        "something you have" factor when combined with code
        attestation ("something you are" for agents).

  A.2.  PCI DSS v4.0.1 Mapping

     o  Req 3.5 (key storage): ATTP mandates HSM/KMS for
        production private keys.
     o  Req 6.2 (software security): Code attestation dimension
        maps to verified software inventory.
     o  Req 8 (identify and authenticate): Challenge-response
        with ECDSA satisfies strong authentication.
     o  Req 10 (logging): Hash-chained audit trail satisfies
        tamper-evident logging.
     o  Req 11 (testing): Anomaly detection satisfies continuous
        monitoring requirements.


  Appendix B.  Trust Level Reference Implementation

     A reference implementation of the ATTP trust scoring model
     is available at:

     o  Go: github.com/razashariff/agentpass-go (Apache 2.0)
     o  JavaScript: npm install agentsign (BSL 1.1)
     o  Keycloak: github.com/razashariff/keycloak-mcps (BSL 1.1)


  Appendix C.  Comparison with Identity-Only Approaches

     Identity-only protocols provide authentication.  ATTP provides
     trust-gated authorisation.  The following table summarises the
     differences:

     +--------------------------+----------+------+
     | Capability               | Identity | ATTP |
     +--------------------------+----------+------+
     | Prove agent identity     | Yes      | Yes* |
     | Graduated trust levels   | No       | Yes  |
     | Action limits            | No       | Yes  |
     | Sanctions screening      | No       | Yes  |
     | Kill switches            | No       | Yes  |
     | Behavioural scoring      | No       | Yes  |
     | Tamper-evident audit     | No       | Yes  |
     | Fail-closed enforcement  | Varies   | Yes  |
     | Dormancy decay           | No       | Yes  |
     | Self-dealing detection   | No       | Yes  |
     +--------------------------+----------+------+

     * ATTP consumes identity from external providers; it does not
       implement its own identity protocol.


  Author's Address

     Raza Sharif
     CyberSecAI Ltd
     205 Regent Street
     London W1B 4HB
     United Kingdom
     Email: contact@agentsign.dev


