# drafts

name: draft-tonyai-a2a-trust
rev: 00
title: Agent-to-Agent Trust, Identity, and Verifiable Provenance
time: 2026-05-20T21:16:03Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-21T21:16:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:43.021553+00:00
source: ietf
abstract:
  This document defines a trust model for agent-to-agent (A2A)
     interactions in multi-agent AI systems.  It specifies how agents
     obtain verifiable identities via CA-signed templates, how spawn
     chains are cryptographically established and validated, how dynamic
     policies are governed under a dual-signature model, and how cross-
     organizational agent interactions are explicitly authorized.  The
     model applies existing PKI primitives (X.509, CRL, CSR) and
     established identity patterns (OAuth 2.0, On-Behalf-Of) to the
     problem of agent provenance.  This document does not address agent-
     to-resource access control, human-in-the-loop orchestration, or agent
     behavior, as those concerns belong to the resource enforcement layer
     and the orchestration layer respectively.

full_text:
  Network Working Group                                        T. Trujillo
  Internet-Draft                                     Individual Submission
  Intended status: Informational                                  May 2026
  Expires: 21 November 2026


         Agent-to-Agent Trust, Identity, and Verifiable Provenance
                         draft-tonyai-a2a-trust-00

  Abstract

     This document defines a trust model for agent-to-agent (A2A)
     interactions in multi-agent AI systems.  It specifies how agents
     obtain verifiable identities via CA-signed templates, how spawn
     chains are cryptographically established and validated, how dynamic
     policies are governed under a dual-signature model, and how cross-
     organizational agent interactions are explicitly authorized.  The
     model applies existing PKI primitives (X.509, CRL, CSR) and
     established identity patterns (OAuth 2.0, On-Behalf-Of) to the
     problem of agent provenance.  This document does not address agent-
     to-resource access control, human-in-the-loop orchestration, or agent
     behavior, as those concerns belong to the resource enforcement layer
     and the orchestration layer respectively.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 2 November 2026.

  Copyright Notice

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






  Trujillo                Expires 21 November 2026                [Page 1]


  Internet-Draft                  A2A Trust                       May 2026


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Existing Patterns and Gaps  . . . . . . . . . . . . . . . . .   5
       5.1.  On-Behalf-Of (OBO)  . . . . . . . . . . . . . . . . . . .   5
       5.2.  OAuth 2.0 Token Exchange (RFC 8693) . . . . . . . . . . .   5
     6.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .   5
       6.1.  Certificate Signing Request Flow  . . . . . . . . . . . .   5
       6.2.  Certificate Chain Structure . . . . . . . . . . . . . . .   6
     7.  Template Structure  . . . . . . . . . . . . . . . . . . . . .   7
       7.1.  Static Fields . . . . . . . . . . . . . . . . . . . . . .   7
       7.2.  Dynamic Policy Bounds . . . . . . . . . . . . . . . . . .   7
     8.  Spawn Chain Validation  . . . . . . . . . . . . . . . . . . .   7
       8.1.  Two-Check Spawn Rule  . . . . . . . . . . . . . . . . . .   8
       8.2.  Spawn Validation Sequence . . . . . . . . . . . . . . . .   8
       8.3.  Scope Constraint  . . . . . . . . . . . . . . . . . . . .   8
       8.4.  Audit Requirements  . . . . . . . . . . . . . . . . . . .   9
     9.  Dynamic Policy Governance . . . . . . . . . . . . . . . . . .   9
       9.1.  Two-Lane Model  . . . . . . . . . . . . . . . . . . . . .   9
       9.2.  Ownership . . . . . . . . . . . . . . . . . . . . . . . .   9
       9.3.  Dual Signature Requirement  . . . . . . . . . . . . . . .   9
       9.4.  Policy Change Sequence  . . . . . . . . . . . . . . . . .  10
       9.5.  Threat Coverage . . . . . . . . . . . . . . . . . . . . .  10
     10. Template Versioning . . . . . . . . . . . . . . . . . . . . .  11
       10.1.  Full Re-Verification Required  . . . . . . . . . . . . .  11
       10.2.  Versioning Principle . . . . . . . . . . . . . . . . . .  11
       10.3.  Non-Inheritance Rules  . . . . . . . . . . . . . . . . .  11
       10.4.  Template Lifecycle . . . . . . . . . . . . . . . . . . .  11
       10.5.  Cross-Organizational Grant Re-Issuance . . . . . . . . .  12
     11. Cross-Organizational Agent Interaction  . . . . . . . . . . .  12
       11.1.  Explicit Grant Requirement . . . . . . . . . . . . . . .  12
       11.2.  Grant Structure  . . . . . . . . . . . . . . . . . . . .  12
       11.3.  Trust Anchor Options . . . . . . . . . . . . . . . . . .  12
       11.4.  Unilateral Revocation  . . . . . . . . . . . . . . . . .  13
       11.5.  Federated Audit  . . . . . . . . . . . . . . . . . . . .  13
     12. Revocation  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       12.1.  Template Revocation  . . . . . . . . . . . . . . . . . .  13
       12.2.  Individual Agent Revocation  . . . . . . . . . . . . . .  13
       12.3.  Automation Requirement . . . . . . . . . . . . . . . . .  13



  Trujillo                Expires 21 November 2026                [Page 2]


  Internet-Draft                  A2A Trust                       May 2026


     13. Failure Model . . . . . . . . . . . . . . . . . . . . . . . .  13
       13.1.  Fail Closed  . . . . . . . . . . . . . . . . . . . . . .  13
     14. Conformance Requirements  . . . . . . . . . . . . . . . . . .  14
       14.1.  Field Placement  . . . . . . . . . . . . . . . . . . . .  14
       14.2.  CSR Validation . . . . . . . . . . . . . . . . . . . . .  14
       14.3.  Test Vectors . . . . . . . . . . . . . . . . . . . . . .  14
       14.4.  Conformance Certification  . . . . . . . . . . . . . . .  14
       14.5.  Reference Implementation . . . . . . . . . . . . . . . .  14
     15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     16. Security Considerations . . . . . . . . . . . . . . . . . . .  15
       16.1.  Scope Escalation . . . . . . . . . . . . . . . . . . . .  15
       16.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  15
       16.3.  Compromised Templates  . . . . . . . . . . . . . . . . .  15
       16.4.  Single Point of Compromise . . . . . . . . . . . . . . .  15
       16.5.  Cross-Organizational Trust . . . . . . . . . . . . . . .  15
       16.6.  Audit Integrity  . . . . . . . . . . . . . . . . . . . .  15
     17. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       17.1.  Normative References . . . . . . . . . . . . . . . . . .  15
       17.2.  Informative References . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction

     Multi-agent AI systems introduce identity and authorization gaps that
     existing standards do not fully address.  When Agent A spawns Agent
     B, and Agent B calls a resource, no current standard defines how the
     resource verifies that Agent B was legitimately spawned, that its
     scope has not been escalated, or that its origin template is trusted.

     This document proposes a trust model based on:

     *  Agent templates as first-class, CA-signed identity artifacts.

     *  Verifiable spawn chains where each agent's provenance is
        cryptographically traceable to a registered template.

     *  Two-lane governance separating static identity (cert-based) from
        dynamic policy (OPA-gated).

     *  Fail-closed enforcement at every verification step.

     The model reuses proven PKI primitives and applies them to a new
     surface -- agent identity -- rather than inventing new cryptographic
     mechanisms.







  Trujillo                Expires 21 November 2026                [Page 3]


  Internet-Draft                  A2A Trust                       May 2026


  2.  Conventions Used in This Document

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

  3.  Terminology

     Agent:  An ephemeral, autonomous process that performs tasks on
        behalf of a user or another agent.

     Agent Template:  A CA-signed artifact defining an agent's identity,
        allowed scopes, spawn rules, and policy reference.

     Template Registry:  The authoritative store of approved, signed agent
        templates for an organization.

     Template Registry CA:  The Certificate Authority that signs agent
        templates -- the root of trust for the agent ecosystem.

     Spawn:  The act of an agent instantiating a child agent from an
        approved template.

     Spawn Chain:  The ordered, cryptographically verifiable sequence of
        agents from the root orchestrator to the current agent.

     Policy Authority:  The entity responsible for countersigning dynamic
        policy changes after automated gate validation.

     CRL:  Certificate Revocation List -- the list of revoked template and
        agent certificates maintained by the CA.

     CSR:  Certificate Signing Request -- the template author's request to
        the CA for a signed template certificate.

     Cross-Org Grant:  An explicit, signed authorization allowing agents
        from one organization to spawn from a template owned by another.

  4.  Problem Statement

     Multi-agent orchestration creates identity and authorization gaps:

        Agent A --> spawns --> Agent B --> calls --> Resource

                                    Figure 1

     *  Which identity does the Resource see?




  Trujillo                Expires 21 November 2026                [Page 4]


  Internet-Draft                  A2A Trust                       May 2026


     *  How does authorization propagate across the chain without
        escalating?

     *  If Agent B is compromised, can it impersonate Agent A?

     *  Who owns the audit trail across the full chain?

     *  How does the Resource prove Agent B was authorized to be spawned?

     No current standard (W3C, IETF, or vendor) fully addresses agent
     provenance in multi-hop chains.

  5.  Existing Patterns and Gaps

  5.1.  On-Behalf-Of (OBO)

     Microsoft Entra ID OBO provides user-to-service delegation:

        User --> Agent A (token A) -->
        Agent A requests token for Agent B on behalf of user -->
        Entra validates the chain -->
        Issues scoped delegated token

                                    Figure 2

     Key insight: a trusted third party validates the delegation chain.
     Agents do not self-assert trust.

     OBO breaks down for agent-to-agent because agents are ephemeral,
     agent spawning is dynamic, and no registry exists for agent
     templates.

  5.2.  OAuth 2.0 Token Exchange (RFC 8693)

     [RFC8693] defines scope constraint across delegation hops --
     downstream tokens MUST be a subset of upstream grants.  This document
     adopts that principle for agent scope inheritance.

  6.  Agent Identity

     Agent identity MUST be established using X.509 certificate chains
     [RFC5280].  This reuses the same trust model used by TLS and existing
     workload identity systems.

  6.1.  Certificate Signing Request Flow






  Trujillo                Expires 21 November 2026                [Page 5]


  Internet-Draft                  A2A Trust                       May 2026


        Template Author
            | defines template (scopes, spawn rules, TTL, owner)
            | generates CSR
            v
        Template Registry CA
            | validates template conformance
            | signs the template certificate
            v
        Signed Agent Template (registered)
            |
            v
        Orchestrator spawns agent from signed template
            | agent receives certificate derived from template certificate
            | CA chain proves provenance
            v
        Resource validates certificate chain:
            - certificate signed by trusted template?
            - template signed by CA?
            - scope within bounds?
            - ALLOW or DENY

                                    Figure 3

  6.2.  Certificate Chain Structure

        Template Registry CA (root of trust)
            |
            v
        Orchestrator Agent Certificate
            Subject:       orchestrator-v1
            Issuer:        Template Registry CA
            Owner:         owner@example.com
            OrgID:         org-123
            KeyUsage:      spawn, delegate
            AllowedScopes: read:data, write:data
            CanSpawn:      [reader-template-v1], MaxChildren: 5
            PolicyRef:     policy-store/orchestrator-v1/current
            TTL:           1h
                 |
                 v
            Child Agent Certificate
                Subject:       reader-agent-v1
                Issuer:        orchestrator-v1
                CA Chain:      orchestrator-v1 -> Template Registry CA
                KeyUsage:      read only
                AllowedScopes: read:data (MUST be subset of parent)
                TTL:           15min (SHOULD be shorter than parent)




  Trujillo                Expires 21 November 2026                [Page 6]


  Internet-Draft                  A2A Trust                       May 2026


                                    Figure 4

  7.  Template Structure

  7.1.  Static Fields

     The following fields MUST be present in every agent template
     certificate and MUST NOT be modified without full re-certification:

     +===============+==========+========================================+
     | Field         | Required | Description                            |
     +===============+==========+========================================+
     | Subject       | REQUIRED | Unique template identifier             |
     +---------------+----------+----------------------------------------+
     | Issuer        | REQUIRED | Template Registry CA                   |
     +---------------+----------+----------------------------------------+
     | Owner         | REQUIRED | Verified identity of template owner    |
     +---------------+----------+----------------------------------------+
     | OrgID         | REQUIRED | CA-validated organization identifier   |
     +---------------+----------+----------------------------------------+
     | KeyUsage      | REQUIRED | Permitted operations                   |
     +---------------+----------+----------------------------------------+
     | AllowedScopes | REQUIRED | Maximum scopes this agent may hold     |
     +---------------+----------+----------------------------------------+
     | CanSpawn      | REQUIRED | Whitelist of permitted child           |
     |               |          | templates                              |
     +---------------+----------+----------------------------------------+
     | MaxChildren   | REQUIRED | Maximum concurrent child agents        |
     +---------------+----------+----------------------------------------+
     | ScopeInherit  | REQUIRED | Scope inheritance constraint           |
     +---------------+----------+----------------------------------------+
     | PolicyRef     | REQUIRED | Pointer to dynamic policy store        |
     +---------------+----------+----------------------------------------+
     | TTL           | REQUIRED | Maximum agent lifetime                 |
     +---------------+----------+----------------------------------------+

                                    Table 1

  7.2.  Dynamic Policy Bounds

     Dynamic policies MUST be bounded by the static template fields.  A
     dynamic policy MUST NOT grant scopes beyond AllowedScopes.  A dynamic
     policy MUST NOT add spawn targets beyond CanSpawn.

  8.  Spawn Chain Validation






  Trujillo                Expires 21 November 2026                [Page 7]


  Internet-Draft                  A2A Trust                       May 2026


  8.1.  Two-Check Spawn Rule

     Every spawn MUST pass two independent checks.  Either check failing
     MUST result in spawn denial with no fallback.

     Check 1 -- Static (CanSpawn in certificate): The requested child
     template MUST appear in the spawning agent's CanSpawn list.

     Check 2 -- Dynamic (Registry live lookup): The requested child
     template MUST be currently registered, CA-signed, not self-signed,
     owned by an authorized party, and not present in the current CRL.

     Rationale: CanSpawn alone is insufficient because the certificate may
     be stale and a template may have been revoked since issuance.
     Registry lookup alone is insufficient because any party could forge a
     request claiming any template.  Both checks MUST pass.

  8.2.  Spawn Validation Sequence

        1.  CanSpawn check -- child template in CanSpawn list?
            NO  --> DENY, audit log
            YES --> continue

        2.  Registry check -- registered, CA-signed, not revoked?
            NO  --> DENY, audit log
            YES --> continue

        3.  Scope check -- requested scope subset of parent scopes?
            NO  --> DENY, audit log
            YES --> continue

        4.  MaxChildren check -- current children < MaxChildren?
            NO  --> DENY, audit log
            YES --> spawn approved

        5.  Child certificate issued with:
            - parent identity embedded (delegation chain)
            - scope equal to requested scope (not exceeding parent)
            - spawn timestamp and nonce (replay prevention)
            - audit log entry written

                                    Figure 5

  8.3.  Scope Constraint

     A child agent's AllowedScopes MUST be a strict subset of the parent
     agent's AllowedScopes.  Scope escalation across agent hops is
     explicitly prohibited.



  Trujillo                Expires 21 November 2026                [Page 8]


  Internet-Draft                  A2A Trust                       May 2026


     Example:

        Parent has:  read:data, write:data
        Child gets:  read:data              -- valid
        Child gets:  read:data, write:data  -- valid (same as parent)
        Child gets:  admin:data             -- MUST be rejected

                                    Figure 6

  8.4.  Audit Requirements

     Every spawn event MUST be logged with: spawning agent identity, child
     template identity, requested scope, granted scope, timestamp, outcome
     (ALLOWED or DENIED), and reason if denied.

  9.  Dynamic Policy Governance

  9.1.  Two-Lane Model

     Template certificate (static): WHO the agent is and WHO it can spawn.
     Changes require full re-certification.

     Dynamic policy (fast lane): WHAT the agent can do within the bounds
     of the template certificate.  Changes require dual signature
     (Section 9.3).

     Dynamic policies MUST NOT exceed the bounds defined in the static
     template certificate.

  9.2.  Ownership

     Template ownership MUST be established at certificate signing time
     and embedded in the Owner and OrgID fields.  Only the verified owner
     of the organization that signed the template MAY submit policy
     changes.

  9.3.  Dual Signature Requirement

     Every policy change MUST be signed by two independent parties:

     1.  Owner -- proves the right to change the policy.

     2.  Policy Authority -- proves the policy passed automated validation
         gates.

     Neither signature alone is sufficient.  Both MUST be present and
     valid for a policy to be accepted.




  Trujillo                Expires 21 November 2026                [Page 9]


  Internet-Draft                  A2A Trust                       May 2026


        Owner key  +  Policy Authority key  =  policy accepted
            ^                  ^
        who owns it        passed the gates

                                    Figure 7

  9.4.  Policy Change Sequence

        1.  Identity and ownership verification
            - requester matches Owner in template certificate?
            - requester OrgID matches certificate OrgID?
            NO  --> rejected, audit logged

        2.  Automated gate (OPA):
            - scope within AllowedScopes?
            - spawn targets within CanSpawn?
            - no conflicts with active policies?
            ANY FAIL --> rejected

        3.  Dual signature applied:
            Owner signs, Policy Authority countersigns

        4.  Policy stored with dual signature, version, timestamp,
            and content hash

        5.  Agent validates at runtime:
            - both signatures valid?
            - version current? (replay prevention)
            - hash matches? (tamper detection)
            - policy within template certificate bounds?
            ANY FAIL --> DENY, audit logged

                                    Figure 8

  9.5.  Threat Coverage

      +========================+====================+===================+
      | Scenario               | Single Sig Gap     | Dual Sig Fix      |
      +========================+====================+===================+
      | Rogue Policy Authority | Pushes bad policy  | Owner key missing |
      +------------------------+--------------------+-------------------+
      | Rogue owner            | Bypasses OPA gates | PA won't          |
      |                        |                    | countersign       |
      +------------------------+--------------------+-------------------+
      | Compromised owner key  | Attacker modifies  | OPA gates         |
      |                        |                    | enforced          |
      +------------------------+--------------------+-------------------+
      | Compromised Policy     | Pushes bad policy  | Owner key missing |



  Trujillo                Expires 21 November 2026               [Page 10]


  Internet-Draft                  A2A Trust                       May 2026


      | Auth                   |                    |                   |
      +------------------------+--------------------+-------------------+

                                    Table 2

  10.  Template Versioning

  10.1.  Full Re-Verification Required

     A new template version MUST undergo full re-verification from
     scratch.  Trust MUST NOT be inherited from a previous version.

     Rationale: inheriting trust from v1 would allow a compromised v1
     certificate to bootstrap trust for v2.

  10.2.  Versioning Principle

     Everything on the old template chain continues to work unchanged as
     long as the certificate is valid.  New connections and functionality
     are opt-in -- only available after the new template chain is fully
     verified and explicitly adopted.

  10.3.  Non-Inheritance Rules

     The following MUST NOT be inherited from a previous version:

     *  Trust chain

     *  Cross-organizational grants

     *  CanSpawn list

     *  Dynamic policies

  10.4.  Template Lifecycle

     ACTIVE:  Template is trusted.  New spawns accepted.

     DISABLED:  No new spawns.  Existing agents run to TTL expiry.
        Reversible.

     DELETED:  Certificate revoked, CRL updated, registry entry removed.
        Irreversible.  Audit log preserved.

     Disable SHOULD precede delete.  Implementations SHOULD enforce a
     mandatory waiting period between DISABLED and DELETED.





  Trujillo                Expires 21 November 2026               [Page 11]


  Internet-Draft                  A2A Trust                       May 2026


  10.5.  Cross-Organizational Grant Re-Issuance

     Cross-organizational grants MUST be explicitly re-issued for each new
     template version.  Grants MUST NOT automatically roll over on version
     upgrade.

  11.  Cross-Organizational Agent Interaction

  11.1.  Explicit Grant Requirement

     Cross-organizational agent spawning MUST be explicitly authorized by
     the resource-owning organization.  No implicit trust exists between
     organizations.

  11.2.  Grant Structure

     A cross-organizational grant MUST contain:

     +===============+===================================================+
     | Field         | Description                                       |
     +===============+===================================================+
     | Grantor       | Resource-owning organization                      |
     +---------------+---------------------------------------------------+
     | Grantee       | Requesting organization                           |
     +---------------+---------------------------------------------------+
     | Template      | Specific template identifier                      |
     +---------------+---------------------------------------------------+
     | AllowedScopes | MUST be subset of template scopes                 |
     +---------------+---------------------------------------------------+
     | TTL           | Grant validity period                             |
     +---------------+---------------------------------------------------+
     | MaxSpawns     | Maximum concurrent agents permitted               |
     +---------------+---------------------------------------------------+
     | Signature     | Dual signature (grantor owner +                   |
     |               | Policy Authority)                                 |
     +---------------+---------------------------------------------------+

                                    Table 3

  11.3.  Trust Anchor Options

     Federated CA:  Both organizations trust a shared root CA.

     Explicit CA trust:  Org-B explicitly trusts Org-A's CA.

     Third-party CA:  Both organizations use a public CA.





  Trujillo                Expires 21 November 2026               [Page 12]


  Internet-Draft                  A2A Trust                       May 2026


  11.4.  Unilateral Revocation

     The granting organization MAY revoke a cross-organizational grant
     without the cooperation of the receiving organization.  Upon
     revocation, all agents spawned under the affected grant MUST be
     treated as untrusted on next validation.

  11.5.  Federated Audit

     Each organization MUST maintain its own independent audit trail.
     Audit records MUST NOT depend on the other organization's systems.

  12.  Revocation

  12.1.  Template Revocation

     Template revocation MUST be performed by adding the template
     certificate to the CA's CRL.  All agent certificates derived from a
     revoked template MUST be treated as untrusted on next CRL check.

  12.2.  Individual Agent Revocation

     Individual agents MAY be revoked by explicit certificate revocation
     or by removal of authorization relationships at the resource layer.

  12.3.  Automation Requirement

     Routine revocation (TTL expiry, task completion) MUST be fully
     automated.  Human involvement SHOULD be reserved for incident
     response and high-impact decisions.

  13.  Failure Model

  13.1.  Fail Closed

     Any verification step that cannot be completed MUST result in DENY.
     This includes:

     *  CA unreachable

     *  Registry unreachable

     *  CRL unreachable

     *  Certificate expired or revoked

     *  Scope escalation attempt




  Trujillo                Expires 21 November 2026               [Page 13]


  Internet-Draft                  A2A Trust                       May 2026


     *  Policy invalid or unsigned

     *  Dual signature missing or invalid

     Implementations MUST NOT provide a degraded mode that allows partial
     spawning or execution when verification infrastructure is
     unavailable.

  14.  Conformance Requirements

  14.1.  Field Placement

     Implementations MUST place every field in the location specified by
     this document.  Variable element placement is NOT permitted.

  14.2.  CSR Validation

     Non-conforming CSRs MUST be rejected by the CA.  A non-conforming
     template MUST NOT be signed.

  14.3.  Test Vectors

     Implementations MUST provide test vectors -- concrete examples of
     valid and invalid template chains -- for conformance validation.

  14.4.  Conformance Certification

     Implementations claiming conformance with this document MUST pass
     conformance certification before shipping.

  14.5.  Reference Implementation

     A reference implementation SHOULD be made available including:

     *  Template Registry CA

     *  Spawn chain validation

     *  SDK with certificate chain validation, registry lookup, and CRL
        check handling

     *  Template linter for pre-submission CSR validation

  15.  IANA Considerations

     This document has no IANA actions.





  Trujillo                Expires 21 November 2026               [Page 14]


  Internet-Draft                  A2A Trust                       May 2026


  16.  Security Considerations

  16.1.  Scope Escalation

     Implementations MUST enforce that child agent scopes are a strict
     subset of parent scopes at every hop.  Failure to enforce this allows
     privilege escalation across the agent chain.

  16.2.  Replay Attacks

     Spawn requests MUST include a timestamp and nonce.  Implementations
     MUST reject spawn requests where the timestamp exceeds a defined
     freshness window or the nonce has been seen previously.

  16.3.  Compromised Templates

     A compromised template certificate MUST be revoked immediately.  A
     single CRL update invalidates all downstream agent certificates
     derived from that template.

  16.4.  Single Point of Compromise

     The dual signature requirement (Section 9.3) ensures no single
     compromised party can push unauthorized policy changes.  CA
     compromise requires full ecosystem re-issuance.

  16.5.  Cross-Organizational Trust

     Cross-organizational grants MUST be explicitly issued.  Implicit
     trust between organizations is prohibited.

  16.6.  Audit Integrity

     Audit logs MUST be tamper-evident.  Logs MUST NOT be deletable by
     agents or orchestrators.  Audit log infrastructure SHOULD be outside
     the control of the agent ecosystem itself.

  17.  References

  17.1.  Normative References

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







  Trujillo                Expires 21 November 2026               [Page 15]


  Internet-Draft                  A2A Trust                       May 2026


     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, May 2008,
                <https://www.rfc-editor.org/info/rfc5280>.

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

     [RFC8693]  Jones, M., Campbell, A., and C. Mortimore, "OAuth 2.0
                Token Exchange", RFC 8693, January 2020,
                <https://www.rfc-editor.org/info/rfc8693>.

  17.2.  Informative References

     [NIST800-207]
                Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
                "Zero Trust Architecture", NIST SP 800-207, August 2020.

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

     [OpenFGA]  OpenFGA Project, "OpenFGA Specification",
                <https://openfga.dev>.

     [VAULTPKI] HashiCorp, "Vault PKI Secrets Engine",
                <https://developer.hashicorp.com/vault/docs/secrets/pki>.

  Author's Address

     Tony Trujillo (tonyai)
     Individual Submission
     Email: ajtrujillo68@gmail.com

















  Trujillo                Expires 21 November 2026               [Page 16]


name: draft-jovancevic-vdac
rev: 00
title: Verifiable Data Access Contract (VDAC)
time: 2026-05-22T06:53:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-23T06:53:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:43.021561+00:00
source: ietf
abstract:
  This document specifies the Verifiable Data Access Contract (VDAC),
     a protocol for cryptographically verifiable bilateral agreement
     between a content publisher and an automated agent regarding the
     terms of programmatic data access. VDAC defines the mechanism by
     which a site publishes an access offer, an agent accepts that
     offer, both parties sign the resulting contract, and per-request
     references bind individual interactions to agreed terms.

     VDAC is the protocol-layer realization of the bilateral commitment
     principle introduced in Section 6.6 of the Verifiable Identity
     Claims and Delegation Model [VICDM] and operates as a companion
     specification to the Signed Agent Identity Protocol [SAIP].

     This document defines mechanism, not content: VDAC verifies the
     existence and integrity of an agreement; the substance of what is
     agreed remains entirely between the contracting parties.

full_text:
  Network Working Group                                      S. Jovancevic
  Internet-Draft                                         SKGO, IKT Support
  Intended status: Informational                              21 May 2026
  Expires: 22 November 2026


              Verifiable Data Access Contract (VDAC)
                      draft-jovancevic-vdac-00


  Abstract

     This document specifies the Verifiable Data Access Contract (VDAC),
     a protocol for cryptographically verifiable bilateral agreement
     between a content publisher and an automated agent regarding the
     terms of programmatic data access. VDAC defines the mechanism by
     which a site publishes an access offer, an agent accepts that
     offer, both parties sign the resulting contract, and per-request
     references bind individual interactions to agreed terms.

     VDAC is the protocol-layer realization of the bilateral commitment
     principle introduced in Section 6.6 of the Verifiable Identity
     Claims and Delegation Model [VICDM] and operates as a companion
     specification to the Signed Agent Identity Protocol [SAIP].

     This document defines mechanism, not content: VDAC verifies the
     existence and integrity of an agreement; the substance of what is
     agreed remains entirely between the contracting parties.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF). Note that other groups may also distribute
     working documents as Internet-Drafts. The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other documents
     at any time. It is inappropriate to use Internet-Drafts as
     reference material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 22 November 2026.

  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.  Relationship to VICDM
         1.2.  The Emerging Architectural Stack
         1.3.  Relationship to SAIP and ALOI
         1.4.  Relationship to webbotauth Work
         1.5.  Protocol Scope and Non-Goals
     2.  Terminology
     3.  Conceptual Overview
         3.1.  The Progression from Anonymous to Contracted
         3.2.  Programmable Bilateral Consent
         3.3.  Contracted Web Semantics
         3.4.  Separation of Identity Trust and Behavior Trust
         3.5.  Mechanism, Not Content
     4.  Site Offer Document
         4.1.  Publication Location
         4.2.  Offer Document Format
         4.3.  Multiple Concurrent Offers
         4.4.  Discovery and Capability Advertisement
     5.  Agent Acceptance Document
         5.1.  Acceptance Format
         5.2.  Submission and Server Response
     6.  Contract Document
         6.1.  Contract Format
         6.2.  Contract Identifier Derivation
         6.3.  Contract Storage Obligations
         6.4.  Delegated Contracting and Infrastructure Scale
     7.  Per-Request Contract Reference
     8.  Mutual Tracking Obligation
         8.1.  Site-Side Log Entry Format
         8.2.  Agent-Side Log Entry Format
         8.3.  End-User Privacy Boundaries
         8.4.  Log Retention
     9.  Reconciliation and Dispute Evidence
         9.1.  Reconciliation Manifest Format
     10. Violation Detection and Sanctions
         10.1 Violation Notice Format
         10.2 Sanction Progression
         10.3 Self-Reporting (Good Faith Mechanism)
     11. Contract Termination
         11.1 Termination Conditions
         11.2 Termination Notice Format
         11.3 Post-Termination Obligations
     12. Relationship to ALOI
     13. Use Case Profiles (Informative)
         13.1. AI Training Data Access
         13.2. Content Retrieval and Inference Access
         13.3. Monitoring and Health-Check Access
     14. Security Considerations
     15. Privacy Considerations
     16. IANA Considerations
     17. References
         17.1. Normative References
         17.2. Informative References
     Appendix A.  Document History
     Author's Address


  1.  Introduction

     The Verifiable Data Access Contract (VDAC) provides a cryptographic
     mechanism by which a content publisher (the Site) and an automated
     client (the Agent) can establish a verifiable bilateral agreement
     regarding the terms of programmatic data access.

     Modern content publishers face a recurring problem: automated
     agents -- AI training crawlers, retrieval systems, monitoring
     services, IoT telemetry consumers -- access publisher resources at
     scale, often outside the scope envisioned by the publisher.
     Existing mechanisms address this only partially:

     o  robots.txt declares what a site permits, but is unilateral,
        advisory, and cryptographically unverified.

     o  Terms-of-service URLs declare legal terms, but bind no party
        cryptographically and are difficult to enforce per-request.

     o  Anonymous attestation models (such as those developed in the
        IETF webbotauth working group) verify that a bot is vouched
        for, but do not establish any agreement between bot and site
        about what the bot will do.

     o  Identity attestation models (such as [SAIP]) verify who the
        bot is, but make no statement about agreed terms of access.

     VDAC fills the gap between identity verification and behavioral
     agreement. Once a Site and Agent have both signed a VDAC contract,
     each subsequent request from the Agent references the contract
     cryptographically, and both parties retain non-repudiable logs of
     the actual interaction. Discrepancies between intent and behavior
     become provable rather than asserted.

  1.1.  Relationship to VICDM

     This document develops the bilateral agreement mechanism originally
     introduced in Section 6.6 of [VICDM]. VDAC is extracted into a
     standalone specification to enable focused review and independent
     deployment.

     VDAC implements the fifth principle of the VICDM model:

        Agreed intent MUST be honored bilaterally.

     An Agent operating under a valid VDAC contract is classified as
     Class 4 (Contracted Agent) under the VICDM trust model, receiving
     the highest trust level in that classification.

     The two documents are companion specifications: [VICDM] provides
     the conceptual framework and identity classification within which
     VDAC operates; this document defines the wire protocol, document
     formats, and operational mechanics.

  1.2.  The Emerging Architectural Stack

     The automated web ecosystem naturally separates into four distinct,
     interdependent layers:

     +===================+============================================+
     | Layer             | Responsibility                             |
     +===================+============================================+
     | SAIP              | Identity Verification                      |
     +-------------------+--------------------------------------------+
     | ALOI              | Unilateral Intent Declaration              |
     +-------------------+--------------------------------------------+
     | VICDM             | Trust Classification and Delegation        |
     +-------------------+--------------------------------------------+
     | VDAC              | Bilateral Operational Agreement            |
     +-------------------+--------------------------------------------+

     This separation is fundamental to modern automated network
     interactions because identity trust does not equate to behavioral
     trust. Cryptographic identity alone cannot establish operational
     accountability. VDAC introduces an explicit, operational layer
     where identity answers "who you are", and VDAC answers "whether
     you honored what was agreed".

  1.3.  Relationship to SAIP and ALOI

     VDAC builds on [SAIP] for agent identity and signature mechanics.
     Every Agent participating in a VDAC contract MUST have a verified
     SAIP identity. The Agent's signing key referenced in the VDAC
     Contract Document is the same Master Public Key registered for
     SAIP purposes.

     VDAC is complementary to the Agent Letter of Intent (ALOI) defined
     in Section 6.5 of [VICDM]:

     o  ALOI is unilateral: the Agent declares its intent in DNS, and
        any Site may observe and enforce that declaration.

     o  VDAC is bilateral: a specific Site and a specific Agent enter
        into a mutually signed agreement that supersedes general ALOI
        declarations for interactions under the contract.

     An Agent MAY operate under ALOI alone (Intent-Declaring mode),
     under VDAC with a specific Site (Contracted Agent mode), or under
     both simultaneously. When in conflict, the more specific commitment
     governs: VDAC terms supersede ALOI declarations for requests under
     the contract; ALOI continues to apply outside any VDAC contract.

  1.4.  Relationship to webbotauth Work

     The IETF webbotauth working group is developing mechanisms for
     anonymous bot attestation [WEBBOTAUTH-ARCH]. VDAC is complementary
     to that work:

     o  Anonymous attestation addresses the privacy use case: rate
        limiting and abuse prevention without per-instance disclosure.

     o  VDAC addresses the bilateral accountability use case: explicit
        mutual agreement on terms of access, with cryptographic evidence
        retained by both parties.

     A deployment MAY support anonymous attestation for general traffic
     and require VDAC for specific access tiers (e.g., bulk data
     retrieval, AI training, premium API endpoints). The two mechanisms
     address different threat models and need not be mutually exclusive.

  1.5.  Protocol Scope and Non-Goals

     VDAC defines the mechanism for verifiable bilateral agreement. It
     addresses:

     o  Offer publication by Sites.
     o  Acceptance by Agents.
     o  Cryptographic binding of both parties to agreed terms.
     o  Per-request contract reference.
     o  Mutual tracking and audit obligations.
     o  Dispute evidence format.
     o  Contract termination.

     VDAC explicitly does NOT address:

     o  Pricing, payment, or commercial settlement mechanisms.
     o  Legal enforcement, arbitration, or jurisdiction.
     o  Tax, regulatory, or compliance matters.
     o  Negotiation protocols (VDAC offers are take-it-or-leave-it
        from the protocol's perspective; out-of-band negotiation may
        precede the protocol).

     These elements are private between the contracting parties or
     addressed by other documents. VDAC provides only the mechanism
     for verifiable agreement.


  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.

     Site:                The party publishing content and offering
                          access terms. Identified by a DNS domain.

     Agent:               The automated client seeking access. Holds a
                          verified [SAIP] identity.

     Offer Document:      A signed JSON object published by the Site
                          describing access terms.

     Acceptance Document: A signed JSON object produced by the Agent
                          indicating intent to operate under a specific
                          Offer.

     Contract Document:   The mutually signed JSON object representing
                          the final bilateral agreement. Contains both
                          the Offer and the Acceptance, plus signatures
                          from both parties.

     Contract Identifier: A unique value identifying a specific
                          Contract Document, used as a per-request
                          reference.

     Contract Hash:       SHA-256 hash of the canonical Contract
                          Document, used to bind individual requests
                          cryptographically to a specific contract
                          version.


  3.  Conceptual Overview

  3.1.  The Progression from Anonymous to Contracted

     VDAC sits at the top of the VICDM interaction progression:

     +======================+============+============+============+
     | Interaction Mode     | Identity   | ALOI       | VDAC       |
     +======================+============+============+============+
     | Anonymous            | No         | No         | No         |
     +----------------------+------------+------------+------------+
     | Identified           | Yes        | No         | No         |
     +----------------------+------------+------------+------------+
     | Intent-Declaring     | Yes        | Yes        | No         |
     +----------------------+------------+------------+------------+
     | Contracted Agent     | Yes        | Yes opt.   | Yes        |
     +----------------------+------------+------------+------------+

     Each level is opt-in. No Agent is compelled to enter a VDAC
     contract; no Site is compelled to publish a VDAC Offer. Where
     bilateral terms make sense, the mechanism is available.

  3.2.  Programmable Bilateral Consent

     VDAC introduces a transition from static legal declarations to
     machine-verifiable operational consent. Traditional mechanisms are
     unsuited
     for programmatic execution: robots.txt is advisory only, Terms of
     Service
     documents are legally descriptive but unparseable by systems, and API
     keys
     grant entry without tracking ongoing behavioral obligations.

     Under the Programmable Bilateral Consent model:
     1. Both parties cryptographically bind themselves to operational
     scopes.
     2. The operational scope is explicitly machine-readable.
     3. Violations become algorithmically provable rather than merely
     asserted.

  3.3.  Contracted Web Semantics

     VDAC establishes a structural shift in web interaction philosophy.
     The historical web model relies on anonymous, unilateral, advisory,
     and loosely enforceable interactions. VDAC formalizes mutually
     authenticated interactions, cryptographically verifiable obligations,
     and
     bilateral accountability. This introduces a transition from advisory
     web
     semantics toward verifiable bilateral interaction semantics.

  3.4.  Separation of Identity Trust and Behavior Trust

     A critical distinction within this architecture is the complete
     decoupling
     of identity verification from behavioral tracking:

     o Identity Trust (SAIP/VICDM) establishes who the agent is, whether
        the identity
       is cryptographically valid, and if delegation roots are intact.

     o Behavior Trust (VDAC) verifies whether the agent and site have
        honored the
       underlying agreement over time, and preserves independent
       mathematical logs.

     Because a valid identity does not automatically guarantee compliant
     behavior,
     VDAC serves as the explicit operational accountability layer above
     SAIP.

  3.5.  Mechanism, Not Content

     VDAC is a protocol primitive. It cryptographically establishes that:

     o  The Site offered specific terms at a specific time.
     o  The Agent accepted those specific terms at a specific time.
     o  Both parties bound themselves to the contract by signature.
     o  Each subsequent request was made under the claimed contract.
     o  Both parties retained matching logs of the interaction.

     What the terms ARE -- whether they permit AI training, restrict
     to ten requests per minute, require attribution, exclude personal
     data paths, or impose specific structural limits -- is outside
     the scope of this document. VDAC verifies that an agreement exists
     and is honored. The wisdom or commercial value of the agreement
     is for the contracting parties to determine.


  4.  Site Offer Document

  4.1.  Publication Location

     A Site that wishes to enable VDAC-based access SHOULD publish an
     Offer Document at a well-known location, per [RFC8615]:

        https://<site-domain>/.well-known/vdac-offer

     When multiple Offers are published, they MAY be available at
     versioned paths:

        https://<site-domain>/.well-known/vdac-offer/<offer-id>

     The Offer Document MUST be served over TLS. Servers MAY include
     the Offer Document inline in API responses where convenient, but
     the well-known URL remains the authoritative source.

  4.2.  Offer Document Format

     The Offer Document is a JSON object signed by the Site's identity
     key:

     {
       "offer_id":     "premium-ai-training-v1",
       "site": {
         "domain":     "site.domain",
         "pubkey":     "pX023...[Truncated Base64URL]"
       },
       "valid_from":   1779369600,
       "valid_until":  1795132800,
       "terms": {
         "scope":      ["/api/v1/public/*", "/articles/archived/*"],
         "exclusions": ["/api/v1/public/users/*", "/articles/premium/*"],
         "rate_limit": {
           "window_seconds": 60,
           "requests_per_window": 120,
           "burst_allowance": 15,
           "max_concurrent_connections": 4,
           "bandwidth_cap_bytes_per_day": 1073741824
         },
         "obligations": ["attribution_required", "no_resell"],
         "custom_terms_uri": "https://site.domain/legal/tos-ai.html",
         "custom_terms_hash": "e3b0c44298fc1c149afbf4c8996fb92427..."
       },
       "offer_sig":    "SigVal...[Truncated Base64URL]"
     }

     Field semantics:

     offer_id            Unique identifier issued by the Site. MUST be
                         unique within the scope of the Site for the
                         Offer's validity period.

     site.domain         The DNS domain of the Site, matching the host
                         portion of the publication URL.

     site.pubkey         The Site's Ed25519 public key. MUST correspond
                         to the private key used to produce offer_sig.

     valid_from          Unix timestamp before which the Offer MUST
                         NOT be accepted.

     valid_until         Unix timestamp after which the Offer MUST
                         NOT be accepted.

     terms               Substantive content of the Offer.

     terms.scope         An array of URL path matchers defining permitted
                         endpoints. Pattern matching follows standard
                         glob/wildcard
                         semantics relative to the site root path.

     terms.exclusions    An array of URL path matchers defining explicit
     blocks
                         within the permitted scope. Exclusions MUST
                         override
                         scope definitions when paths overlap.

     terms.rate_limit    Stated operational performance constraints.
     Parsers
                         MUST support the primitive integer definitions
                         for
                         windows, requests, concurrency, and optional
                         daily bandwidth caps.

     terms.obligations   Free-form list of obligations the Agent agrees
                         to fulfill if accepting. The protocol does not
                         parse
                         these strings natively.

     terms.custom_terms_uri  An optional URI pointing to additional
                         contract terms that do not fit within JSON.
                         If present, the contents MUST be hashed and
                         the hash included in "custom_terms_hash"
                         computed at Offer publication time.

     offer_sig           Ed25519 signature over the canonicalized
                         offer object excluding the signature field
                         itself. Canonicalization follows [RFC8785].

  4.3.  Multiple Concurrent Offers

     A Site MAY publish multiple Offers concurrently representing
     different access tiers. Each Offer MUST have a distinct offer_id.
     The set of currently valid Offers MAY be enumerated at:

        https://<site-domain>/.well-known/vdac-offer-index

  4.4.  Discovery and Capability Advertisement

     To minimize the application layer overhead of fetching offer indexes
     proactively, implementations SHOULD leverage discovery mechanisms.

     4.4.1. HTTP Capability Advertisement
     Sites MAY advertise contract capabilities during standard HTTP
     interactions
     by including a VDAC-Advertise header in responses:

        VDAC-Advertise:
          offer="https://site.domain/.well-known/vdac-offer",
          types="ai-training, retrieval",
          index="https://site.domain/.well-known/vdac-offer-index"

     4.4.2. DNS-Based Discovery
     Agents wishing to evaluate a domain's VDAC enforcement posture before
     initiating application-layer handshakes MAY query the zone's DNS
     records.
     The VDAC pointer is constructed as a TXT record located at
     a dedicated subdomain string:

        _vdac.site.domain. IN TXT
          "v=vdac1;
           index=https://site.domain/.well-known/vdac-offer-index"


  5.  Agent Acceptance Document

  5.1.  Acceptance Format

     An Agent that wishes to accept a Site Offer constructs an
     Acceptance Document:

     {
       "contract_id":  "Z21h...[Truncated Base64URL]",
       "offer_hash":   "SHA256Val...[Truncated Base64URL]",
       "agent": {
         "saip_id":    "id=master-agent-identity",
         "pubkey":     "aF912...[Truncated Base64URL]",
         "vendor":     "vendor-domain.com",
         "delegation_allowed": true
       },
       "accepted_at":  1779370000,
       "expires_at":   1795132800,
       "agent_sig":    "SigVal...[Truncated Base64URL]"
     }

     Field semantics:

     contract_id         The Contract Identifier derived per Section
                         6.2. The Agent computes this value at
                         acceptance time.

     offer_hash          SHA-256 hash of the canonicalized Offer
                         Document. This binds the Acceptance to a
                         specific version of the Offer.

     agent.saip_id       The Agent's SAIP identity (id= value per
                         [SAIP]).

     agent.pubkey        The Agent's Master Public Key, which MUST
                         match the key registered in the Agent's DNS
                         _saip record per [SAIP].

     agent.vendor        The DNS domain of the vendor operating the
                         Agent.

     agent.delegation_allowed  A boolean flag declaring whether the
     contract
                         intends to utilize distributed worker nodes
                         authenticated via VICDM delegation structures.

     accepted_at         Unix timestamp at which the Acceptance was
                         constructed. MUST be within the Offer's
                         validity period.

     expires_at          Unix timestamp at which the resulting
                         Contract expires.

     agent_sig           Ed25519 signature over the canonicalized
                         acceptance object excluding the signature field.

  5.2.  Submission and Server Response

     The Agent submits the Acceptance Document to the Site via HTTP
     POST:

        POST https://<site-domain>/.well-known/vdac-accept
        Content-Type: application/json

     The request body is the Acceptance Document. If validation succeeds,
     the Site returns the complete signed Contract Document (Section 6)
     with HTTP status 201 (Created).

     If validation fails, the Site returns HTTP status 400 (Bad
     Request) with structured error codes: `offer_not_found`,
     `offer_expired`,
     `duration_exceeds`, `signature_invalid`, `identity_unverified`, or
     `duplicate_contract`.


  6.  Contract Document

  6.1.  Contract Format

     The Contract Document is the canonical record of the bilateral
     agreement:

     {
       "contract_id":  "DerivedID-Value",
       "offer":        { ... complete Offer Document ... },
       "acceptance":   { ... complete Acceptance Document ... },
       "site_sig":     "SigVal...[Truncated Base64URL]",
       "agent_sig":    "SigVal...[Truncated Base64URL]"
     }

     The site_sig and agent_sig fields are Ed25519 signatures
     computed over the canonicalized concatenation of the offer and
     acceptance objects (in that order), per [RFC8785].

  6.2.  Contract Identifier Derivation

     The contract_id is deterministically derived to allow either
     party to compute it independently:

        contract_id = Base64URL(SHA256(
                         offer_id || agent.saip_id || accepted_at
                      ))

     Where || denotes UTF-8 string concatenation with a single
     ASCII null byte (0x00) as a strict delimiter.

  6.3.  Contract Storage Obligations

     Both parties MUST retain identical copies of the Contract
     Document for the duration specified in terms.duration plus the
     log retention period (Section 8.4).

  6.4.  Delegated Contracting and Infrastructure Scale

     For large-scale, enterprise, and distributed systems where scraping
     or API
     consumption is handled by clustered pools of machines, executing
     unique contracts per
     ephemeral node is unfeasible. VDAC addresses this by integrating with
     the
     [VICDM] delegation mechanism.

     If `agent.delegation_allowed` is true in the signed contract,
     application
     requests operating under the contract_id MAY be signed by distinct,
     ephemeral operational public keys. The Agent node MUST include the
     matching
     umbrella corporate `Delegation Token` within the request protocol
     metadata,
     proving that the ephemeral node's key is a legitimate downstream
     delegate
     of the contract's `agent.pubkey`.


  7.  Per-Request Contract Reference

     Once a Contract is established, the Agent includes a contract
     reference in every SAIP request to the Site:

        contract-id=<contract_id>; contract-hash=<contract_hash>

     Where contract_hash is the SHA-256 hash of the canonicalized
     Contract Document, encoded as Base64URL.

     The contract-id and contract-hash parameters MUST be included in
     the SAIP canonical signature string per [SAIP] Section 6.4.2.
     This cryptographically binds the request to a specific contract
     version.


  8.  Mutual Tracking Obligation

     VDAC requires mutual logging by both parties. Tracking is an
     integral part of the contract, not an optional feature.

  8.1.  Site-Side Log Entry Format

     {
       "contract_id":   "DerivedID-Value",
       "ts":            1779371050,
       "endpoint":      "/articles/archived/news-item",
       "method":        "GET",
       "bytes_sent":    45120,
       "status_code":   200,
       "agent_sig":     "SigVal...[Truncated Base64URL]",
       "site_log_sig":  "SigVal...[Truncated Base64URL]"
     }

  8.2.  Agent-Side Log Entry Format

     {
       "contract_id":         "DerivedID-Value",
       "ts":                  1779371050,
       "endpoint":            "/articles/archived/news-item",
       "method":              "GET",
       "response_hash":       "SHA256Val...[Truncated Base64URL]",
       "bytes_received":      45120,
       "agent_log_sig":       "SigVal...[Truncated Base64URL]"
     }

  8.3.  End-User Privacy Boundaries

     This section addresses a critical constraint: VDAC tracking MUST NOT
     become a vector for surveillance of end-users whose interactions
     are mediated by a contracted Agent.

     The following constraints apply to all VDAC log entries:

     1. End-user identifying information MUST NOT be included in
        VDAC log entries. This includes, but is not limited to:
        end-user IP addresses, user-agent strings of human users
        whose interaction is proxied by the Agent, end-user
        authentication tokens, session identifiers, and personally
        identifiable URL parameters.

     2. The endpoint field MUST be normalized to exclude query
        parameters that could identify end-users. Implementations
        MUST log only the path component, or a redacted form of
        the query string where retention of certain parameters is
        operationally necessary.

     3. Response content MUST NOT be logged in raw form. Only a
        hash (response_hash) is logged. The hash provides
        verification capability without retaining the content
        itself.

  8.4.  Log Retention

     Both parties retain logs for the duration specified in the
     contract terms. The RECOMMENDED minimum retention is 90 days
     from the request timestamp. Logs older than the retention period
     SHOULD be securely deleted.


  9.  Reconciliation and Dispute Evidence

     Periodic reconciliation between Site and Agent logs is RECOMMENDED.
     To facilitate rapid, automated cross-checking without mass data
     transfer,
     parties utilize a structural summary document.

  9.1.  Reconciliation Manifest Format

     When performing an audit checkpoint, a party compiles state records
     into a
     canonical Manifest object:

     {
       "contract_id": "DerivedID-Value",
       "period_start": 1779369600,
       "period_end": 1779456000,
       "total_requests": 14500,
       "total_bytes": 48291045,
       "log_summary_hash": "SHA256HashOfAllCompiledRequestSignatures...",
       "manifest_sig": "SigVal...[Truncated Base64URL]"
     }

     If both local calculations match the `log_summary_hash`, the
     historical block is
     mutually verified. If hashes diverge, systems enter detailed
     reconciliation
     by breaking the window into narrower sub-intervals to isolate the
     precise
     mismatched request signatures.


  10.  Violation Detection and Sanctions

  10.1.  Violation Notice Format

     {
       "contract_id":   "DerivedID-Value",
       "violation":     "rate_limit_exceeded",
       "evidence_ref":  "ManifestHashOrLogID",
       "detected_at":   1779372000,
       "site_sig":      "SigVal..."
     }

     The notice MAY be delivered via HTTP response header on the
     offending request:

        VDAC-Violation: <base64url-encoded violation notice>

  10.2.  Sanction Progression

     Sanctions for VDAC violations SHOULD follow the same progressive
     model defined for ALOI in [VICDM] Section 6.5.7:

     +=================+============+================================+
     | Violation Count | Sanction   | Action                         |
     +=================+============+================================+
     | 1               | Warning    | Notice only; no rate change.   |
     +-----------------+------------+--------------------------------+
     | 2-3             | Throttle   | Reduce to minimal rate.        |
     +-----------------+------------+--------------------------------+
     | 4-5             | Downgrade  | Trust downgrade.               |
     +-----------------+------------+--------------------------------+
     | 6-10            | Block      | Reject contract requests.      |
     +-----------------+------------+--------------------------------+
     | >10             | Termination| Terminate contract per         |
     |                 |            | Section 11.                    |
     +-----------------+------------+--------------------------------+

  10.3.  Self-Reporting (Good Faith Mechanism)

     An Agent that detects an unintentional violation of contract
     terms MAY self-report the violation before the Site detects it,
     per the Good Faith Mechanism defined in [VICDM] Section 6.5.8.

     Self-reporting under VDAC uses the same signal format as ALOI
     self-reporting:

        VDAC-Self-Report: contract-id=<contract_id>;
                          violation=<violation-type>;
                          ts=<unix-timestamp-of-violation>;
                          self-sig=<signature per VICDM 6.5.8>


  11.  Contract Termination

  11.1.  Termination Conditions

     A VDAC contract terminates in any of the following conditions:
     o Natural expiry: reaching the contract's expires_at timestamp.
     o Mutual termination: both parties signing a termination notice.
     o Unilateral termination by either party, with signed notice.
     o Material breach: severe violation as defined in contract terms.

  11.2.  Termination Notice Format

     {
       "contract_id":      "DerivedID-Value",
       "terminated_by":    "site",
       "reason":           "material_breach",
       "effective_at":     1779373000,
       "evidence_ref":     "ViolationNoticeHash",
       "terminator_sig":   "SigVal..."
     }

     Defined reason codes: `natural_expiry`, `mutual_consent`,
     `site_initiated`,
     `agent_initiated`, `material_breach`, or `offer_revoked`.

  11.3.  Post-Termination Obligations

     After termination, the Agent MUST cease using the contract_id in
     requests.
     Both parties retain logged evidence for the contract's log retention
     period.
     The Agent reverts to its prior interaction mode (Anonymous,
     Identified, or
     Intent-Declaring per the VICDM progression).


  12.  Relationship to ALOI

     ALOI and VDAC are complementary: ALOI is a unilateral declaration,
     whereas
     VDAC is a bilateral agreement where both parties are bound.

     An Agent MAY operate under both simultaneously. ALOI defines the
     Agent's
     general operational scope across all interactions; VDAC defines
     specific
     terms for one particular Site. When in conflict, the more specific
     commitment
     governs: VDAC terms supersede ALOI declarations for requests under
     the contract.


  13.  Use Case Profiles (Informative)

  13.1.  AI Training Data Access
     An AI model vendor wishes to access bulk content from a publisher
     Site for
     training purposes. The structural `rate_limit` block maps a macro
     configuration
     (e.g., aggregate daily byte caps, low multi-concurrency connections)
     alongside
     obligations like `no_resell` and explicit content path exclusions.

  13.2.  Content Retrieval and Inference Access
     A retrieval-augmented AI assistant accesses individual articles in
     real time
     to answer user queries. Configuration profiles employ lower window
     boundaries, higher
     burst thresholds, and shorter termination spans. Under this profile,
     the privacy
     constraints of Section 8.3 are strictly critical.

  13.3.  Monitoring and Health-Check Access
     A third-party monitoring service accesses Site endpoints to verify
     availability.
     The profile establishes lightweight logging structures with simple
     token
     structures and predictable heartbeat windows.


  14.  Security Considerations

  14.1.  Signature Forgery
     The integrity of VDAC depends entirely on the security of the Ed25519
     signature scheme
     [RFC8032] and the secrecy of private keys. Agent keys are protected
     per [SAIP]
     requirements (TPM, HSM, or Secure Enclave).

  14.2.  Replay of Acceptance
     Resubmission of the same Acceptance Document produces an identical
     contract_id
     (per Section 6.2). The Site MUST detect duplicate contract_id values
     and reject
     duplicate Acceptance submissions.

  14.3.  Offer Substitution
     The offer_hash field in the Acceptance Document binds the Acceptance
     to a specific Offer
     version. A Site cannot substitute different terms after Acceptance
     without invalidating
     agent_sig.


  15.  Privacy Considerations

     See Section 8.3 (End-User Privacy Boundaries) for the core privacy
     requirements
     applicable to VDAC tracking. Because reconciliation logs map hashes
     and paths rather
     than raw states, they protect end-user activity while preserving
     behavioral
     audit trails.


  16.  IANA Considerations

     This document requests IANA to register the following well-known URIs
     per [RFC8615]:
     `vdac-offer`, `vdac-offer-index`, `vdac-accept`, and `vdac-contract`.

     This document requests IANA to register the following HTTP header
     fields per [RFC3864]:
     `VDAC-Violation` and `VDAC-Self-Report`.

     This document requests IANA to create the VDAC Termination Reason
     Codes registry.


  17.  References

  17.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
                RFC 2119 Key Words", BCP 14, RFC 8174, May 2017.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032, January 2017.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, May 2019.

     [RFC8785]  Rundgren, A., "JSON Canonicalization Scheme (JCS)",
                RFC 8785, June 2020.

     [RFC3864]  Klyne, G., "Registration Procedures for Message Header
                Fields", RFC 3864, September 2004.

     [VICDM]    Jovancevic, S., "Verifiable Identity Claims and
                Delegation Model (VICDM)", Work in Progress, Internet-
                Draft, draft-jovancevic-vicdm-05, 18 May 2026.

     [SAIP]     Jovancevic, S., "SAIP: Signed Agent Identity
                Protocol", Work in Progress, Internet-Draft,
                draft-jovancevic-saip-08, April 2026.

  17.2.  Informative References

     [WEBBOTAUTH-ARCH]
                Meunier, T. and S. Major, "HTTP Message Signatures
                for automated traffic Architecture", Work in Progress,
                Internet-Draft, draft-meunier-web-bot-auth-architecture,
                March 2026.


  Appendix A.  Document History

     The Verifiable Data Access Contract (VDAC) was originally defined
     in Section 6.6 of draft-jovancevic-vicdm-05. It was extracted into
     this standalone specification to enable focused review and
     independent
     versioning.

     Changes relative to VICDM Section 6.6:
     o Expanded Privacy Considerations with explicit Section 8.3
        boundaries.
     o Added Section 4.4 Capability Discovery architectures (HTTP/DNS).
     o Formalized structural standard fields for `rate_limit` JSON
        matching.
     o Introduced Section 6.4 Enterprise Infrastructure Key Delegation.
     o Added Section 9.1 Fast Reconciliation Manifest hashes.


  Author's Address

     Srecko Jovancevic
     SKGO, IKT Support
     Makedonska 22
     11000 Belgrade
     Serbia

     Email: srecko.jovancevic@skgo.org
     Email: srecko.jovancevic@gmail.com
     URI:   https://github.com/sreckojovancevic


name: draft-sato-soos-cap
rev: 00
title: The Constitutional AI Protocol (CAP) for Agentic AI Systems
time: 2026-05-17T12:22:43Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-18T12:22:43Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:43.021566+00:00
source: ietf
abstract:
  This document specifies the Constitutional AI Protocol (CAP), a
     kernel-enforced prohibition architecture for agentic AI systems.
     CAP defines a three-tier prohibition model: Tier 0 absolute
     prohibitions derived from near-universal treaty consensus, Tier 1
     jurisdiction-specific prohibitions declared by operators and
     verified by auditors, and Tier 2 voluntary operator ethical
     standards.  CAP evaluates every action request twice -- once on the
     AI agent's action before Cedar policy evaluation, and once on the
     human principal's decision before kernel execution -- ensuring that
     neither agents nor human principals can authorize absolutely
     prohibited actions.  This document also specifies Jurisdictional
     Conflict Resolution (JCR), the mechanism by which the kernel
     surfaces irreconcilable jurisdictional conflicts to human principals
     via the Human Escalation Mechanism [I-D.sato-soos-hem].

full_text:
  Internet-Draft                                                   T. Sato
  Intended status: Standards Track                         MyAuberge K.K.
  Expires: November 17, 2026                                  May 17, 2026


             The Constitutional AI Protocol (CAP) for Agentic AI Systems
                          draft-sato-soos-cap-00

  Abstract

     This document specifies the Constitutional AI Protocol (CAP), a
     kernel-enforced prohibition architecture for agentic AI systems.
     CAP defines a three-tier prohibition model: Tier 0 absolute
     prohibitions derived from near-universal treaty consensus, Tier 1
     jurisdiction-specific prohibitions declared by operators and
     verified by auditors, and Tier 2 voluntary operator ethical
     standards.  CAP evaluates every action request twice -- once on the
     AI agent's action before Cedar policy evaluation, and once on the
     human principal's decision before kernel execution -- ensuring that
     neither agents nor human principals can authorize absolutely
     prohibited actions.  This document also specifies Jurisdictional
     Conflict Resolution (JCR), the mechanism by which the kernel
     surfaces irreconcilable jurisdictional conflicts to human principals
     via the Human Escalation Mechanism [I-D.sato-soos-hem].

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on November 17, 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
     2.  Conventions and Definitions
     3.  Architecture Overview
       3.1.  The Double-Evaluation Property
       3.2.  Relationship to HEM
       3.3.  Relationship to Cedar Policy Evaluation
     4.  Constitutional Evaluation Engine (CEE)
       4.1.  CEE Placement in the Kernel
       4.2.  CEE Evaluation Protocol
       4.3.  CEE Outputs
     5.  Tier 0 -- Universal Core Prohibitions
       5.1.  Tier 0 Properties
       5.2.  Tier 0 Prohibition Classes
       5.3.  Tier 0 Prohibition Schema
       5.4.  Tier 0 Modification
     6.  Tier 1 -- Jurisdictional Prohibition Layer
       6.1.  Tier 1 Properties
       6.2.  Tier 1 Prohibition Classes
       6.3.  Tier 1 Prohibition Schema
       6.4.  Jurisdiction Configuration
       6.5.  Tier 1 Verification
     7.  Tier 2 -- Operator Ethical Layer
       7.1.  Tier 2 Properties
       7.2.  Tier 2 Prohibition Schema
       7.3.  Tier 2 Disclosure
     8.  CAP Violation Handling
       8.1.  AI-Initiated Violations
       8.2.  Human-Directed Violations
       8.3.  APPROVE_WITH_LEGAL_BASIS
       8.4.  CAP Violation Record Schema
       8.5.  Session Suspension
     9.  Jurisdictional Conflict Resolution
       9.1.  Conflict Detection
       9.2.  Conflict Resolution Methods
       9.3.  HEM_JURISDICTIONAL_CONFLICT
       9.4.  Jurisdictional Conflict Record Schema
     10. Event Log Requirements
     11. EU AI Act Applicability
       11.1. Article 5 Mapping
     12. Security Considerations
     13. IANA Considerations
       13.1. CAP Prohibition Classes Tier 0 Registry
       13.2. CAP Prohibition Classes Tier 1 Registry
       13.3. CAP Conflict Resolution Methods Registry
     14. References
       14.1. Normative References
       14.2. Informative References
     Author's Address


  1.  Introduction

     Agentic AI systems operate under authorization frameworks that
     determine what agents are permitted to do.  These frameworks -- Cedar
     policy evaluation, mandate JWT scope, human escalation decisions --
     are powerful and flexible.  Their flexibility is also their
     limitation: they can be configured to authorize actions that are
     harmful, unlawful, or both.

     The Human Escalation Mechanism [I-D.sato-soos-hem] stops the AI
     and waits for a human principal to decide.  HEM is a necessary
     governance layer.  It is not sufficient on its own, because HEM has
     no mechanism to evaluate whether a human principal's decision is
     itself lawful.  A human principal can issue an APPROVE decision on
     a market manipulation action.  HEM executes it.  The human-AI
     system has committed a crime.

     The Constitutional AI Protocol (CAP) closes this gap.  CAP defines
     a Constitutional Layer that sits above all principal authority and
     evaluates action requests twice:

     o  When the AI agent requests an action -- before Cedar policy
        evaluation.  An action that violates a Tier 0 absolute
        prohibition is refused unconditionally.  Cedar is not consulted.
        HEM does not fire.  No principal can override the refusal.

     o  When a human principal submits a decision -- before the kernel
        executes the decision.  An APPROVE or APPROVE_WITH_CONSTRAINTS
        decision on a prohibited action is refused.  The principal's
        decision slot is not consumed; they may submit a revised
        decision.

     CAP's primary value is not prohibition -- it is transparency and
     traceability of legal authorization.  Most deployed agentic AI
     actions are lawful.  CAP makes lawful actions legally traceable:
     every authorized action carries a policy rationale; every disputed
     action carries the principal's legal basis citation.  CAP makes
     unlawful action attempts visible in the audit record before harm
     occurs.  Every government claims its actions are lawful.  CAP says:
     prove it.  Cite the authority.  It goes in the log.

     This document specifies:

     o  The Constitutional Evaluation Engine (CEE) -- the kernel
        component that evaluates action requests against the three-tier
        prohibition model.

     o  Tier 0 -- Universal Core Prohibitions -- six absolute categories
        derived from near-universal treaty consensus, kernel-resident,
        immutable without a new RFC.

     o  Tier 1 -- Jurisdictional Prohibition Layer -- operator-declared,
        jurisdiction-specific prohibitions verified by Audit Principals.

     o  Tier 2 -- Operator Ethical Layer -- voluntary operator standards
        exceeding local law, publicly disclosed.

     o  Jurisdictional Conflict Resolution (JCR) -- the mechanism by
        which irreconcilable jurisdictional conflicts are surfaced to
        human principals via HEM Class 5 (HEM_JURISDICTIONAL_CONFLICT).

     This specification is a companion to [I-D.sato-soos-idp] and
     [I-D.sato-soos-hem].  Readers should be familiar with both documents
     before reading this document.


  2.  Conventions and Definitions

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

     The following terms are defined in this document or inherited from
     [I-D.sato-soos-idp] and [I-D.sato-soos-hem]:

     Constitutional Evaluation Engine (CEE):
        The kernel component that evaluates action requests and human
        principal decisions against the three-tier CAP prohibition model.
        The CEE is invoked twice per governed action: before Cedar
        evaluation and before kernel execution of a human decision.

     Constitutional Layer:
        The enforcement boundary above all principal authority.  No
        agent, operator, or human principal can override a Tier 0
        Constitutional Layer refusal.

     CAP Violation:
        An action request or human principal decision that the CEE
        determines violates a Tier 0, Tier 1, or Tier 2 prohibition.

     APPROVE_WITH_LEGAL_BASIS:
        A HEM decision sub-type reserved for Tier 1 violations where a
        principal asserts a jurisdictional legal basis.  Operational only
        when a CAP specification is the governing authority.  Defined in
        Section 8.3.

     Jurisdictional Conflict:
        A condition in which two or more declared jurisdictions have
        irreconcilable Tier 1 prohibition positions for a given action,
        and the SO Type conflict resolution method is "HEM".

     HEM_JURISDICTIONAL_CONFLICT:
        HEM Class 5 trigger.  Fires when the kernel detects a
        Jurisdictional Conflict that cannot be algorithmically resolved.
        Specified in [I-D.sato-soos-hem] Section 5.5.

     Verified External Auditor:
        Defined in [I-D.sato-soos-gar].  An external party with
        time-limited, scope-limited read access to kernel audit artifacts.

     Action Pattern:
        A structured description of the class of kernel actions a
        prohibition covers.  Action patterns are expressed using the same
        vocabulary as Cedar policy action sets, enabling the CEE to match
        incoming action requests against prohibition records without
        natural language interpretation.


  3.  Architecture Overview

  3.1.  The Double-Evaluation Property

     CAP introduces a Constitutional Layer that evaluates every governed
     action twice.  The evaluation sequence for any AI-initiated action
     is:

        AI agent requests action
                 |
                 v
        +---------------------------+
        |   CONSTITUTIONAL LAYER    |  <- Tier 0: unconditional refusal
        |   CEE evaluation          |  <- Tier 1: jurisdiction check
        |   (before Cedar)          |  <- Tier 2: operator ethics check
        +---------------------------+
                 |                  \
                 v PERMIT            v DENY
        Cedar policy evaluation    CONSTITUTIONAL_VIOLATION
                 |                  (Event Log entry, CRITICAL
                 v                   Audit Alert, action refused)
        HEM if required
                 |
                 v
        Human principal decision
                 |
                 v
        +---------------------------+
        |   CONSTITUTIONAL LAYER    |  <- Same three-tier evaluation
        |   CEE evaluation          |  <- Applied to the human decision
        |   (before execution)      |
        +---------------------------+
                 |                  \
                 v PERMIT            v DENY
        Kernel executes decision   HEM_HUMAN_DECISION_CONSTITUTIONAL_
                                   VIOLATION
                                   (decision slot NOT consumed)

     The double-evaluation property ensures that:

     o  An AI agent cannot request an absolutely prohibited action even
        if its Cedar policy would permit it.

     o  A human principal cannot authorize an absolutely prohibited
        action even with an APPROVE decision.

     o  The Constitutional Layer is evaluated by the kernel, not by the
        AI agent or any application layer.

  3.2.  Relationship to HEM

     CAP and HEM are complementary.  HEM governs agent sessions and
     routes decisions to human principals.  CAP governs what those
     decisions may authorize.

     o  HEM_CAP_VIOLATION is a CAP event, not a HEM trigger class.
        Tier 0 violations are refused before HEM state machinery is
        engaged.  The kernel records CONSTITUTIONAL_VIOLATION in the
        Event Log and fires a CRITICAL Audit Alert.  The session does not
        enter HEM_PENDING.

     o  HEM_JURISDICTIONAL_CONFLICT (Class 5) is a HEM trigger that CAP
        fires when a Tier 1 conflict cannot be algorithmically resolved
        and the SO Type has declared conflict_resolution: "HEM".  The
        kernel routes the conflict to a human principal for resolution.

     o  APPROVE_WITH_LEGAL_BASIS is a HEM decision sub-type that CAP
        introduces for Tier 1 violations.  It is reserved in this
        specification and becomes operational only when CAP is published
        as a normative authority.

  3.3.  Relationship to Cedar Policy Evaluation

     Cedar policy evaluation is the kernel's authorization layer for
     normal governed actions.  CAP is above Cedar.  The evaluation order
     is: CAP (Constitutional Layer) -> Cedar -> HEM (if Cedar routes) ->
     Human decision -> CAP (Constitutional Layer again).

     A CAP Tier 0 DENY does not invoke Cedar.  A Cedar PERMIT does not
     exempt an action from CAP evaluation.  These are independent
     enforcement layers.


  4.  Constitutional Evaluation Engine (CEE)

  4.1.  CEE Placement in the Kernel

     The CEE is a kernel-resident component.  It MUST be invoked:

     o  On every kernel.transition() call, before Cedar evaluation.

     o  On every HEM decision submission via the Decision Submission
        Protocol (Section 7.6 of [I-D.sato-soos-hem]), before the kernel
        processes the decision.

     The CEE MUST NOT be invoked by agents, applications, or principals
     directly.  There is no external CEE query interface.  The CEE
     evaluation is synchronous and atomic with the triggering call.

  4.2.  CEE Evaluation Protocol

     On receiving an action request or human decision for evaluation,
     the CEE MUST:

     (1) Evaluate against all loaded Tier 0 prohibition records.
         If any Tier 0 record matches the action pattern:
         DENY unconditionally.  Record CAP_VIOLATION_DETECTED (AI) or
         CAP_HUMAN_VIOLATION_DETECTED (human decision) in the Event Log.
         Return CONSTITUTIONAL_VIOLATION to the kernel.  Do not proceed
         to Tier 1 or Tier 2 evaluation.

     (2) If no Tier 0 match, evaluate against all loaded Tier 1
         prohibition records for the declared jurisdiction(s).
         If any Tier 1 record matches:
         Check conflict_resolution configuration.
         If conflict_resolution: "MOST_PROTECTIVE" or
         "PRIMARY_JURISDICTION": apply resolution and return DENY or
         PERMIT accordingly.
         If conflict_resolution: "HEM": fire HEM_JURISDICTIONAL_CONFLICT
         (Class 5).

     (3) If no Tier 1 match or Tier 1 PERMIT, evaluate against all
         loaded Tier 2 prohibition records.
         If any Tier 2 record matches: return DENY with
         violation_type: TIER_2.
         Tier 2 denials MAY be overridden by operator configuration
         at the SO Type level.  Tier 2 denials MUST be logged.

     (4) If no match at any tier: return PERMIT.
         Proceed to Cedar evaluation (for AI actions) or kernel
         execution (for human decisions).

  4.3.  CEE Outputs

     The CEE returns one of the following to the kernel:

     PERMIT:
        No prohibition matched.  Proceed to next evaluation layer.

     CONSTITUTIONAL_VIOLATION:
        Tier 0 match.  Action unconditionally refused.  Kernel MUST
        record CAP_VIOLATION_DETECTED or CAP_HUMAN_VIOLATION_DETECTED.
        Kernel MUST generate CRITICAL Audit Alert.

     JURISDICTIONAL_CONFLICT:
        Tier 1 conflict with conflict_resolution: "HEM".  Kernel MUST
        fire HEM_JURISDICTIONAL_CONFLICT (Class 5).

     TIER_1_DENY:
        Tier 1 match, resolution is deterministic (MOST_PROTECTIVE or
        PRIMARY_JURISDICTION).  Action denied.

     TIER_2_DENY:
        Tier 2 match.  Action denied unless operator override applies.

     SESSION_SUSPEND:
        Reserved for repeated Tier 0 violations within a session.  See
        Section 8.5.


  5.  Tier 0 -- Universal Core Prohibitions

  5.1.  Tier 0 Properties

     Tier 0 prohibitions are:

     o  Kernel-resident: loaded at kernel initialization, not at session
        open or SO Type registration.

     o  Unconditional: no Cedar policy, mandate configuration, operator
        declaration, or human principal decision can override a Tier 0
        refusal.

     o  Immutable without a new RFC: the Tier 0 registry has a
        registration procedure of "RFC Only" (Section 13.1).  No
        operator, regulator, or standards body other than the IETF can
        modify the Tier 0 set.

     o  Globally scoped: Tier 0 prohibitions apply regardless of the
        declared jurisdiction configuration of the SO Type.

     o  Treaty-anchored: each Tier 0 category is derived from a
        treaty or UN Security Council resolution with near-universal
        state ratification.  Categories for which genuine universal
        consensus does not exist are NOT in Tier 0.

  5.2.  Tier 0 Prohibition Classes

     The initial Tier 0 prohibition classes are:

     GENOCIDE_FACILITATION:
        Actions that facilitate genocide as defined in the Convention on
        the Prevention and Punishment of the Crime of Genocide (1948),
        ratified by 153 states.  Includes actions that contribute to
        killing, causing serious bodily or mental harm, or imposing
        conditions of life calculated to bring about physical destruction
        of a national, ethnical, racial, or religious group.

     CSAM:
        Actions that produce, distribute, or facilitate access to child
        sexual abuse material, as prohibited by the UN Convention on the
        Rights of the Child (1989), ratified by 196 states, and its
        Optional Protocol on the Sale of Children.

     HUMAN_TRAFFICKING:
        Actions that recruit, transport, transfer, harbor, or receive
        persons through force, fraud, or coercion for exploitation, as
        defined in the UN Protocol to Prevent, Suppress and Punish
        Trafficking in Persons (2000), ratified by 178 states.

     WMD_ASSISTANCE:
        Actions that assist in the development, production, stockpiling,
        or transfer of chemical weapons (CWC, 193 states), biological
        weapons (BWC, 183 states), or nuclear weapons (NPT, 191 states).

     TORTURE_FACILITATION:
        Actions that facilitate torture or cruel, inhuman, or degrading
        treatment as defined in the UN Convention Against Torture (1984),
        ratified by 173 states.

     TERRORIST_FINANCING:
        Actions that provide funds, financial services, or material
        support to terrorist organizations, as required by UN Security
        Council Resolution 1373 (2001), binding on all 193 UN member
        states.

  5.3.  Tier 0 Prohibition Schema

     Each Tier 0 prohibition record MUST contain the following fields:

     prohibition_id:
        Unique identifier for this prohibition record.

     prohibition_class:
        One of the Tier 0 prohibition classes registered in the CAP
        Prohibition Classes Tier 0 registry (Section 13.1).

     treaty_basis:
        Citation of the treaty or UNSC resolution anchoring this
        prohibition.  REQUIRED.

     action_pattern:
        Structured description of the class of actions this prohibition
        covers.  Expressed using Cedar action vocabulary to enable
        deterministic CEE matching.

     jurisdiction:
        MUST be "GLOBAL" for all Tier 0 records.

     effective_date:
        ISO 8601 date from which this prohibition record is in force.

     modifiable_by:
        MUST be "RFC_ONLY" for all Tier 0 records.

  5.4.  Tier 0 Modification

     Tier 0 prohibition classes MUST NOT be modified, extended, or
     removed except by publication of a new RFC that updates this
     document.  The registration procedure for the CAP Prohibition
     Classes Tier 0 registry is RFC Only (Section 13.1).

     Implementations MUST NOT expose any configuration interface that
     allows Tier 0 records to be modified, disabled, or overridden at
     deployment time.


  6.  Tier 1 -- Jurisdictional Prohibition Layer

  6.1.  Tier 1 Properties

     Tier 1 prohibitions are:

     o  Operator-declared: the operator declares applicable
        jurisdiction(s) and the legal prohibitions in force under each.

     o  Auditor-verified: Audit Principals MUST review and verify Tier 1
        prohibition records before they take effect.  Unverified Tier 1
        records MUST NOT be enforced.

     o  Jurisdiction-scoped: Tier 1 prohibitions apply only within the
        declared jurisdiction(s) of the SO Type.

     o  Mutable with review: Tier 1 records carry a review_date.
        The kernel SHOULD warn Audit Principals when review_date is
        exceeded.  Expired Tier 1 records remain in force until updated
        or explicitly retired; expiry generates a PRD_REVIEW_DATE_EXCEEDED
        Audit Alert.

     o  Signed: Tier 1 records MUST be signed by both the declaring
        operator (declared_by) and a Verified Audit Principal
        (verified_by).

  6.2.  Tier 1 Prohibition Classes

     The initial Tier 1 prohibition classes are:

     FINANCIAL_CRIME:
        Market manipulation, insider trading, money laundering, and
        related financial offenses under applicable securities and
        banking law.

     DATA_PROTECTION:
        Processing of personal data in violation of applicable data
        protection law (including GDPR, CCPA, APPI, and equivalents).

     CRITICAL_INFRASTRUCTURE:
        Actions targeting or disrupting critical infrastructure systems
        as defined under applicable national security law.

     SECURITIES_LAW:
        Actions prohibited under applicable securities regulation
        beyond financial crime (e.g., unauthorized investment advice,
        unlicensed securities dealing).

     PRIVACY_VIOLATION:
        Surveillance, tracking, or profiling activities prohibited under
        applicable privacy law.

     FRAUD:
        Deceptive practices prohibited under applicable consumer
        protection or criminal fraud law.

     COMPETITION_LAW:
        Cartel coordination, abuse of dominant position, or other
        conduct prohibited under applicable competition law.

     HUMAN_RIGHTS:
        Actions prohibited under applicable human rights law within
        the declared jurisdiction, including forced labor, unlawful
        discrimination, and denial of due process.

  6.3.  Tier 1 Prohibition Schema

     Each Tier 1 prohibition record MUST contain the following fields:

     prohibition_id:
        Unique identifier for this prohibition record.

     prohibition_class:
        One of the Tier 1 prohibition classes registered in the CAP
        Prohibition Classes Tier 1 registry (Section 13.2).

     jurisdiction:
        ISO 3166-1 alpha-2 country code for the jurisdiction in which
        this prohibition applies.  REQUIRED.

     authority_ref:
        Legal citation for the authority behind this prohibition
        (statute, regulation, case law citation).  REQUIRED.

     action_pattern:
        Structured description of the class of actions this prohibition
        covers.

     effective_date:
        ISO 8601 date from which this prohibition is in force.

     review_date:
        ISO 8601 date by which this prohibition record must be reviewed.
        REQUIRED.

     declared_by:
        Identifier of the operator declaring this prohibition.

     verified_by:
        Identifier of the Audit Principal who verified this prohibition
        record.  REQUIRED before enforcement.  Null until verified.

     signature:
        Ed25519 signature from verified_by over the canonical
        serialization of all fields except signature.

  6.4.  Jurisdiction Configuration

     Each SO Type MUST declare a Jurisdiction Configuration at
     registration time.  The Jurisdiction Configuration specifies:

     primary_jurisdiction:
        ISO 3166-1 alpha-2.  The primary legal jurisdiction governing
        this SO Type.  REQUIRED.

     secondary_jurisdictions:
        Array of ISO 3166-1 alpha-2 codes.  Additional jurisdictions
        whose Tier 1 prohibitions apply to this SO Type.  MAY be empty.

     conflict_resolution:
        Controlled vocabulary.  Specifies how the kernel resolves
        conflicts between prohibitions from different jurisdictions.
        One of:

        MOST_PROTECTIVE:
           The most restrictive prohibition across all declared
           jurisdictions applies.  If any jurisdiction prohibits an
           action, it is denied.

        PRIMARY_JURISDICTION:
           The primary_jurisdiction's prohibition position governs.
           Secondary jurisdiction prohibitions are informative only.

        HEM:
           The kernel cannot resolve jurisdictional conflicts
           algorithmically.  When a conflict is detected, the kernel
           fires HEM_JURISDICTIONAL_CONFLICT (Class 5) and routes the
           conflict to a human principal for resolution.

     conflict_escalation:
        Specifies kernel behavior when HEM_JURISDICTIONAL_CONFLICT
        cannot be resolved (chain exhausted).  One of:
        HEM: chain exhaustion disposition per [I-D.sato-soos-hem] Section 9.4.
        SUSPEND: kernel suspends the session pending operator
        intervention.

     legal_counsel_ref:
        Reference to the legal counsel who reviewed the Jurisdiction
        Configuration.  RECOMMENDED.

     declared_at:
        ISO 8601 UTC timestamp of declaration.

     declared_by:
        Identifier of the operator.

  6.5.  Tier 1 Verification

     An Audit Principal MUST review every Tier 1 prohibition record
     before it takes effect.  The review MUST verify that:

     o  The prohibition_class is appropriate for the cited authority_ref.
     o  The action_pattern correctly scopes the prohibition.
     o  The review_date is reasonable given the stability of the cited
        authority.
     o  The jurisdiction matches the declared SO Type configuration.

     On successful review, the Audit Principal MUST sign the record
     (verified_by field) using their registered key.  The kernel MUST
     NOT enforce any Tier 1 record with a null or unverifiable
     verified_by field.


  7.  Tier 2 -- Operator Ethical Layer

  7.1.  Tier 2 Properties

     Tier 2 prohibitions are:

     o  Voluntary: operators declare Tier 2 prohibitions exceeding the
        requirements of applicable law.

     o  Publicly disclosable: operators SHOULD publish their Tier 2
        prohibition set in a transparency report or equivalent public
        disclosure.

     o  Overridable by operator: unlike Tier 0 and Tier 1, the operator
        MAY configure SO Types to override specific Tier 2 prohibitions
        at the SO Type level.  Such overrides MUST be declared and
        audited.

     o  Subject to review: Tier 2 records carry a review_date.

  7.2.  Tier 2 Prohibition Schema

     Each Tier 2 prohibition record MUST contain the following fields:

     prohibition_id:
        Unique identifier.

     prohibition_class:
        Free text or reference to an operator-defined taxonomy.
        Not registered in an IANA registry.

     rationale_text:
        Human-readable explanation of why this standard exceeds local
        law requirements.  REQUIRED.

     action_pattern:
        Structured description of covered actions.

     effective_date:
        ISO 8601 date.

     review_date:
        ISO 8601 date.  REQUIRED.

     declared_by:
        Operator identifier.

     publicly_disclosed:
        Boolean.  True if this prohibition has been publicly disclosed
        in a transparency report or equivalent.

  7.3.  Tier 2 Disclosure

     Operators who declare Tier 2 prohibitions SHOULD publish them in a
     publicly accessible transparency report.  The transparency report
     SHOULD be referenced in the SO Type registration.

     Verified External Auditors MAY request Tier 2 prohibition records
     as part of an Audit Package as defined in [I-D.sato-soos-gar].


  8.  CAP Violation Handling

  8.1.  AI-Initiated Violations

     When the CEE returns CONSTITUTIONAL_VIOLATION on an AI-initiated
     action request, the kernel MUST:

     (1) Refuse the action unconditionally.  MUST NOT proceed to Cedar
         evaluation.  MUST NOT enter HEM_PENDING.

     (2) Generate a CAP_VIOLATION_DETECTED Event Log entry (Section 10).

     (3) Generate a CRITICAL Audit Alert (alert_trigger:
         CAP_VIOLATION_DETECTED) via [I-D.sato-soos-gar].

     (4) Return a structured error to the agent or application surface
         that invoked kernel.transition().  The error MUST include
         violation_type: AI_INITIATED and prohibition_class.  The error
         MUST NOT include the full action_pattern of the matched
         prohibition (to prevent pattern probing).

     The kernel MUST NOT reveal which specific Tier 0 record matched
     beyond the prohibition_class.  Action pattern details are available
     only to Verified External Auditors via the Audit Package.

  8.2.  Human-Directed Violations

     When the CEE returns CONSTITUTIONAL_VIOLATION on a human principal
     decision submission, the kernel MUST:

     (1) Refuse execution of the decision.  MUST NOT apply the decision
         to the governed session.

     (2) NOT consume the principal's decision slot.  The principal
         remains active in the designation chain and MUST be permitted
         to submit a revised decision.

     (3) Generate a CAP_HUMAN_VIOLATION_DETECTED Event Log entry
         (Section 10).

     (4) Generate a CRITICAL Audit Alert (alert_trigger:
         CAP_HUMAN_VIOLATION_DETECTED) via [I-D.sato-soos-gar].

     (5) Return HEM_HUMAN_DECISION_CONSTITUTIONAL_VIOLATION to the
         submitting principal with prohibition_class indicated.

     The preservation of the principal's decision slot (step 2) is
     critical: it assumes the principal acted in error or under coercion,
     not necessarily with intent.  The principal has the opportunity to
     submit a decision that the Constitutional Layer will PERMIT.

  8.3.  APPROVE_WITH_LEGAL_BASIS

     APPROVE_WITH_LEGAL_BASIS is a HEM decision sub-type introduced by
     this specification for Tier 1 violations where a principal asserts
     a jurisdictional legal basis for an action that would otherwise be
     prohibited.

     APPROVE_WITH_LEGAL_BASIS carries the following legal_basis block:

        legal_basis: {
          authority_type:  "COURT_ORDER" | "STATUTORY" |
                           "REGULATORY" | "TREATY",
          authority_ref:   string,  // Legal citation. REQUIRED.
          jurisdiction:    string,  // ISO 3166-1 alpha-2. REQUIRED.
          expiry:          string,  // ISO 8601. REQUIRED.
          document_hash:   string | null  // Hash of legal document.
        }

     When a principal submits APPROVE_WITH_LEGAL_BASIS, the CEE MUST:

     (1) Verify that the action matches a Tier 1 prohibition (not Tier 0).
         APPROVE_WITH_LEGAL_BASIS MUST NOT be accepted for Tier 0
         violations under any circumstances.  The kernel MUST return
         HEM_HUMAN_DECISION_CONSTITUTIONAL_VIOLATION if a Tier 0 match
         is present regardless of the legal_basis content.

     (2) Record APPROVE_WITH_LEGAL_BASIS_RECORDED in the Event Log with
         the full legal_basis block.

     (3) Proceed to kernel execution if no Tier 0 match is present.

     CAP's purpose is not to prevent lawful actions -- it is to make
     lawful actions legally traceable.  APPROVE_WITH_LEGAL_BASIS
     provides the traceability mechanism: the authority citation goes
     in the Event Log and the Audit Package.  It is available for
     regulatory inspection at any time.

     APPROVE_WITH_LEGAL_BASIS is RESERVED in this specification.
     Implementations MUST NOT accept APPROVE_WITH_LEGAL_BASIS decisions
     until a governing CAP authority is published.  The kernel MUST
     return HEM_DECISION_TYPE_NOT_YET_OPERATIONAL if an
     APPROVE_WITH_LEGAL_BASIS decision is submitted prior to that
     publication.

  8.4.  CAP Violation Record Schema

     The kernel MUST generate a CAP Violation Record for every CEE
     CONSTITUTIONAL_VIOLATION output.  The CAP Violation Record MUST
     contain:

     violation_id:
        Kernel-generated UUID.

     session_id:
        The session in which the violation was detected.

     hem_id:
        The HEM event identifier, if the violation occurred during a
        HEM_PENDING state.  Null otherwise.

     tier:
        0, 1, or 2.

     prohibition_id:
        The prohibition record that matched.

     violation_type:
        AI_INITIATED | HUMAN_DIRECTED.

     action_attempted:
        The Cedar action string of the attempted action.  Stored in the
        CAP Violation Record for auditors; MUST NOT be returned to the
        agent or application surface.

     context_hash:
        SHA-256 hash of the full action context at the time of
        detection.  Enables auditors to reconstruct the context without
        the kernel exposing it in the error response.

     outcome:
        REFUSED | SESSION_SUSPENDED | HEM_FIRED.

     timestamp:
        ISO 8601 UTC.

     kernel_signature:
        Ed25519 signature over canonical serialization of all fields
        except kernel_signature.

  8.5.  Session Suspension

     The kernel MAY suspend a session when a threshold of CAP violations
     is detected within that session.  The threshold is SO Type
     configurable.  The default threshold is three Tier 0 violations
     within a single session.

     On session suspension:

     (1) The kernel records SESSION_CAP_SUSPENDED in the Event Log.

     (2) The kernel returns SESSION_SUSPENDED to the CEE.

     (3) No further kernel.transition() calls are accepted for this
         session until an operator with appropriate authority releases
         the suspension.

     (4) A CRITICAL Audit Alert is generated (alert_trigger:
         CAP_VIOLATION_DETECTED, outcome: SESSION_SUSPENDED).

     Suspension is the kernel's defense against systematic probing of
     the Constitutional Layer by a compromised or adversarial agent.


  9.  Jurisdictional Conflict Resolution

  9.1.  Conflict Detection

     A Jurisdictional Conflict exists when:

     o  The SO Type has declared two or more jurisdictions in its
        Jurisdiction Configuration.

     o  The CEE determines that one jurisdiction's Tier 1 prohibition
        records prohibit an action that another jurisdiction's Tier 1
        prohibition records permit or do not address.

     o  The conflict_resolution method is "HEM".

     The kernel MUST detect Jurisdictional Conflicts at CEE evaluation
     time, not at SO Type registration time.  Conflicts are action-
     specific: a Jurisdiction Configuration may produce no conflicts for
     most actions and a conflict for a specific class of action.

  9.2.  Conflict Resolution Methods

     The three conflict resolution methods declared in the Jurisdiction
     Configuration determine how the kernel responds to a detected
     conflict:

     MOST_PROTECTIVE:
        The kernel applies the most restrictive prohibition across all
        declared jurisdictions.  If any jurisdiction prohibits the
        action, the CEE returns TIER_1_DENY.  No HEM event fires.  This
        is the safest default for multi-jurisdiction deployments.

     PRIMARY_JURISDICTION:
        The primary_jurisdiction's Tier 1 prohibition position governs.
        Secondary jurisdiction conflicts are recorded in the Event Log
        as CAP_TIER1_CONFLICT_DETECTED but do not block execution.
        Legal counsel SHOULD review the authority_ref for the primary
        jurisdiction before this method is selected.

     HEM:
        The kernel cannot resolve the conflict algorithmically.  The
        kernel fires HEM_JURISDICTIONAL_CONFLICT (Class 5) and routes
        the conflict to the designation chain for human resolution.
        The HEM Escalation Request carries a jurisdictional_conflict_
        summary field with the conflicting jurisdictions, their
        respective Tier 1 prohibition classes, and the action that
        triggered the conflict.

  9.3.  HEM_JURISDICTIONAL_CONFLICT

     HEM_JURISDICTIONAL_CONFLICT is HEM Class 5 as specified in
     [I-D.sato-soos-hem] Section 5.5.  This section specifies the CAP-side
     content that the kernel MUST include in the HEM Escalation Request
     when Class 5 fires.

     The jurisdictional_conflict_summary field in the HEM Escalation
     Request MUST contain:

     conflict_id:
        Kernel-generated UUID for this conflict instance.

     action:
        The Cedar action string that triggered the conflict.

     conflicting_jurisdictions:
        Array of objects, one per conflicting jurisdiction, each
        containing:
           jurisdiction:    ISO 3166-1 alpha-2.
           prohibition_id:  The Tier 1 prohibition record that applies.
           position:        PROHIBITS | PERMITS | NOT_ADDRESSED.

     resolution_options:
        Non-normative array of resolution approaches the principal MAY
        consider.  The kernel MUST NOT pre-select or recommend a
        resolution.

     Decision type constraints for Class 5 apply as specified in
     [I-D.sato-soos-hem]: APPROVE and APPROVE_WITH_CONSTRAINTS are
     prohibited.  APPROVE_WITH_LEGAL_BASIS (reserved), REDIRECT (cleanup
     only), TERMINATE, and DEFER are permitted.

  9.4.  Jurisdictional Conflict Record Schema

     The kernel MUST generate a Jurisdictional Conflict Record for every
     detected Jurisdictional Conflict.  The record MUST contain:

     conflict_id:
        Kernel-generated UUID.

     session_id:
        The session in which the conflict was detected.

     action:
        The Cedar action string.

     conflicting_jurisdictions:
        Array of objects: { jurisdiction, prohibition_id, outcome }.

     resolution_method:
        The conflict_resolution method declared for this SO Type.

     hem_id:
        The HEM event identifier if conflict_resolution is "HEM".
        Null otherwise.

     timestamp:
        ISO 8601 UTC.


  10.  Event Log Requirements

     CAP introduces the following Event Log entry types.  All entries
     are appended to the kernel Event Log specified in
     [I-D.sato-soos-hem] Section 10.

     CAP_VIOLATION_DETECTED:
        Generated when the CEE returns CONSTITUTIONAL_VIOLATION on an
        AI-initiated action.  Fields: violation_id, session_id, hem_id,
        tier, prohibition_id, action_attempted, context_hash, outcome,
        timestamp, kernel_signature.

     CAP_HUMAN_VIOLATION_DETECTED:
        Generated when the CEE returns CONSTITUTIONAL_VIOLATION on a
        human principal decision.  Fields: same as CAP_VIOLATION_DETECTED
        plus principal_id and decision_type.

     CAP_TIER1_CONFLICT_DETECTED:
        Generated when a Tier 1 jurisdictional conflict is detected,
        regardless of resolution method.  Fields: conflict_id,
        session_id, action, conflicting_jurisdictions, resolution_method,
        hem_id, timestamp.

     APPROVE_WITH_LEGAL_BASIS_RECORDED:
        Generated when a principal submits a valid APPROVE_WITH_LEGAL_BASIS
        decision.  Fields: hem_id, principal_id, legal_basis
        (authority_type, authority_ref, jurisdiction, expiry,
        document_hash), timestamp.

     SESSION_CAP_SUSPENDED:
        Generated when the kernel suspends a session under Section 8.5.
        Fields: session_id, violation_id, violation_count,
        threshold_applied, suspended_at.


  11.  EU AI Act Applicability

  11.1.  Article 5 Mapping

     EU AI Act Article 5 prohibits certain AI practices absolutely.
     The following table maps Article 5 provisions to CAP mechanisms.
     This mapping is normative: the CEE evaluation and CAP Violation
     Record specified in this document satisfy Article 5 requirements
     for deployments governed by [I-D.sato-soos-hem] when the relevant
     Tier 1 prohibitions
     are declared for EU-jurisdiction SO Types.  Tier 0 universal
     prohibitions apply globally regardless of jurisdiction
     configuration.  Operators may reference this section directly in
     EU AI Act Article 5 conformance documentation.

     +-------------------------------+--------------------------------+------+
     | Article 5 Provision           | CAP Mechanism                  | Sec. |
     +-------------------------------+--------------------------------+------+
     | 5(1)(a) -- Subliminal          | Tier 1: FINANCIAL_CRIME /      | 6.2  |
     | manipulation causing harm     | FRAUD prohibition class for    |      |
     |                               | EU jurisdiction; CEE TIER_1_   |      |
     |                               | DENY; no principal override    |      |
     |                               | without APPROVE_WITH_LEGAL_    |      |
     |                               | BASIS                          |      |
     +-------------------------------+--------------------------------+------+
     | 5(1)(b) -- Exploitation of     | Tier 1: HUMAN_RIGHTS           | 6.2  |
     | vulnerabilities of specific   | prohibition class for EU       |      |
     | groups                        | jurisdiction; CEE TIER_1_DENY  |      |
     +-------------------------------+--------------------------------+------+
     | 5(1)(c) -- Social scoring by   | Tier 1: DATA_PROTECTION /      | 6.2  |
     | public authorities            | PRIVACY_VIOLATION for EU       |      |
     |                               | jurisdiction; operators SHOULD |      |
     |                               | also declare Tier 2 prohibition|      |
     |                               | for private deployments        |      |
     +-------------------------------+--------------------------------+------+
     | 5(1)(d) -- Real-time remote    | Tier 1: DATA_PROTECTION /      | 6.2  |
     | biometric identification in   | PRIVACY_VIOLATION for EU       |      |
     | publicly accessible spaces    | jurisdiction with authority_   |      |
     |                               | ref citing Art. 5(1)(d)        |      |
     +-------------------------------+--------------------------------+------+
     | General -- No human override   | HEM_HUMAN_DECISION_            | 8.2  |
     | of prohibited practices       | CONSTITUTIONAL_VIOLATION --     |      |
     |                               | principal APPROVE cannot       |      |
     |                               | execute Tier 0 or verified     |      |
     |                               | Tier 1 actions                 |      |
     +-------------------------------+--------------------------------+------+
     | General -- Audit trail of      | CAP_VIOLATION_DETECTED and     | 10   |
     | prohibited practice attempts  | CAP_HUMAN_VIOLATION_DETECTED   |      |
     |                               | Event Log entries; CRITICAL    |      |
     |                               | Audit Alert; Audit Package     |      |
     |                               | available to regulators        |      |
     +-------------------------------+--------------------------------+------+

     Table 1: EU AI Act Article 5 Mapping

     Note: Article 5 prohibited practices that derive from near-universal
     treaty consensus may be reclassified to Tier 0 in future revisions
     of this specification.  The current Tier 1 classification for EU-
     specific Article 5 items reflects the principle that Tier 0 is
     reserved for genuine global consensus.  The enforcement consequence
     is equivalent for EU-jurisdiction SO Types: CEE denies the action
     and no principal can override without a legal basis citation.


  12.  Security Considerations

     CEE kernel integrity:
        The Constitutional Evaluation Engine is a kernel-resident
        component.  Its prohibition records and evaluation logic MUST be
        protected against modification by any agent, application, or
        principal.  Implementations MUST treat CEE records with the same
        integrity protection as mandate JWTs and Event Log entries.
        Any modification to Tier 0 records outside of a kernel
        initialization sequence loaded from a verified source MUST be
        treated as a critical security incident.

     Action pattern probing:
        The CEE MUST NOT return the matched action_pattern in error
        responses.  Returning full action pattern details enables
        adversarial agents to probe the boundary of prohibited action
        classes and find closely adjacent actions.  The error response
        MUST contain only the prohibition_class.

     Tier 1 verification integrity:
        Unverified Tier 1 records MUST NOT be enforced.  The kernel
        MUST check the verified_by signature before loading any Tier 1
        record.  An operator who deploys unverified Tier 1 records
        creates a false assurance of prohibition coverage.

     Session suspension threshold:
        The default session suspension threshold of three Tier 0
        violations (Section 8.5) SHOULD be configurable downward but
        not upward beyond the default.  A higher threshold enables
        systematic probing.  Operators who configure a higher threshold
        MUST document the justification and subject it to Audit Principal
        review.

     Legal basis citation integrity:
        The APPROVE_WITH_LEGAL_BASIS legal_basis block is an operator
        assertion, not a verified legal finding.  Implementations MUST
        record all APPROVE_WITH_LEGAL_BASIS decisions in the Audit
        Package regardless of the apparent validity of the legal_basis.
        Regulators reviewing the Audit Package can assess legal basis
        validity independently.

     Double-evaluation atomicity:
        The two CEE evaluations -- before Cedar and before execution --
        MUST be atomic with their respective triggering calls.  An
        implementation that evaluates CAP asynchronously or conditionally
        does not satisfy the Constitutional Layer guarantee.


  13.  IANA Considerations

  13.1.  CAP Prohibition Classes Tier 0 Registry

     This document establishes the "Constitutional AI Protocol
     Prohibition Classes Tier 0" registry.  The registry is maintained
     at: https://www.iana.org/assignments/cap-prohibition-classes-tier0

     Registration procedure: RFC Only.  Tier 0 classes may only be added,
     modified, or removed by publication of an RFC that updates this
     document.

     Initial values:

     +---------------------------+------------------------------------------+
     | Prohibition Class         | Treaty Basis                             |
     +---------------------------+------------------------------------------+
     | GENOCIDE_FACILITATION     | UN Genocide Convention 1948 (153 states) |
     | CSAM                      | UN CRC 1989 + Optional Protocol          |
     |                           | (196 states)                             |
     | HUMAN_TRAFFICKING         | UN Trafficking Protocol 2000             |
     |                           | (178 states)                             |
     | WMD_ASSISTANCE            | CWC (193), BWC (183), NPT (191 states)   |
     | TORTURE_FACILITATION      | UN CAT 1984 (173 states)                 |
     | TERRORIST_FINANCING       | UNSC Resolution 1373 (2001)              |
     +---------------------------+------------------------------------------+

     Table 2: Initial CAP Tier 0 Prohibition Classes

  13.2.  CAP Prohibition Classes Tier 1 Registry

     This document establishes the "Constitutional AI Protocol
     Prohibition Classes Tier 1" registry.  The registry is maintained
     at: https://www.iana.org/assignments/cap-prohibition-classes-tier1

     Registration procedure: Specification Required.

     Initial values:

     +---------------------------+------------------------------------------+
     | Prohibition Class         | Description                              |
     +---------------------------+------------------------------------------+
     | FINANCIAL_CRIME           | Market manipulation, money laundering,   |
     |                           | and related financial offenses           |
     | DATA_PROTECTION           | Personal data processing violations      |
     | CRITICAL_INFRASTRUCTURE   | Actions targeting critical infrastructure|
     | SECURITIES_LAW            | Unlicensed securities activities         |
     | PRIVACY_VIOLATION         | Prohibited surveillance and profiling    |
     | FRAUD                     | Deceptive practices under consumer or    |
     |                           | criminal law                             |
     | COMPETITION_LAW           | Cartel coordination and abuse of         |
     |                           | dominant position                        |
     | HUMAN_RIGHTS              | Violations of applicable human rights    |
     |                           | law                                      |
     +---------------------------+------------------------------------------+

     Table 3: Initial CAP Tier 1 Prohibition Classes

  13.3.  CAP Conflict Resolution Methods Registry

     This document establishes the "Constitutional AI Protocol Conflict
     Resolution Methods" registry.  The registry is maintained at:
     https://www.iana.org/assignments/cap-conflict-resolution-methods

     Registration procedure: Standards Action.

     Initial values:

     +----------------------+-----------------------------------------------+
     | Method               | Description                                   |
     +----------------------+-----------------------------------------------+
     | MOST_PROTECTIVE      | Most restrictive prohibition across all       |
     |                      | declared jurisdictions applies                |
     | PRIMARY_JURISDICTION | Primary jurisdiction prohibition position     |
     |                      | governs; secondary conflicts logged only      |
     | HEM                  | Kernel fires HEM_JURISDICTIONAL_CONFLICT      |
     |                      | (Class 5) for human resolution                |
     +----------------------+-----------------------------------------------+

     Table 4: Initial CAP Conflict Resolution Methods


  14.  References

  14.1.  Normative References

     [I-D.sato-soos-hem]
                Sato, T., "The Human Escalation Mechanism (HEM) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-hem-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-hem/>.

     [I-D.sato-soos-idp]
                Sato, T., "The Intent Declaration Primitive (IDP) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-idp-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-idp/>.

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

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

  14.2.  Informative References

     [I-D.sato-soos-gar]
                Sato, T., "The Governance Audit Record (GAR) for Agentic
                AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-gar-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-gar/>.

     [EU-AI-ACT]
                European Parliament and Council, "Regulation (EU)
                2024/1689 laying down harmonised rules on artificial
                intelligence", OJ L 2024/1689, July 2024,
                <https://eur-lex.europa.eu/legal-content/EN/TXT/
                ?uri=OJ:L_202401689>.

     [UN-GENOCIDE]
                United Nations, "Convention on the Prevention and
                Punishment of the Crime of Genocide", 78 UNTS 277,
                December 1948.

     [UN-CRC]   United Nations, "Convention on the Rights of the Child",
                1577 UNTS 3, November 1989.

     [UN-TIP]   United Nations, "Protocol to Prevent, Suppress and
                Punish Trafficking in Persons, Especially Women and
                Children", 2237 UNTS 319, November 2000.

     [CWC]      Organisation for the Prohibition of Chemical Weapons,
                "Convention on the Prohibition of the Development,
                Production, Stockpiling and Use of Chemical Weapons",
                1975 UNTS 45, January 1993.

     [UNSC-1373]
                UN Security Council, "Resolution 1373 (2001)",
                S/RES/1373, September 2001.

     [UN-CAT]   United Nations, "Convention Against Torture and Other
                Cruel, Inhuman or Degrading Treatment or Punishment",
                1465 UNTS 85, December 1984.


  Author's Address

     Tom Sato
     MyAuberge K.K.
     Chino, Nagano
     Japan
     Email: tomsato@myauberge.jp
     URI:   https://activitytravel.pro/


name: draft-sato-soos-gar
rev: 00
title: The Governance Audit Record (GAR) for Agentic AI Systems
time: 2026-05-17T12:23:28Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-18T12:23:28Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:43.021570+00:00
source: ietf
abstract:
  This document specifies the Governance Audit Record (GAR), the audit
     architecture for agentic AI systems.  GAR defines five audit types,
     the Session Audit Record (SAR), the Audit Alert system, auditor
     principal categories, and the Audit Package for external regulatory
     inspection.  GAR provides verifiable evidence that AI agent sessions
     were governed in accordance with the Intent Declaration Primitive
     [I-D.sato-soos-idp] and the Human Escalation Mechanism
     [I-D.sato-soos-hem].  GAR answers the governance question: can any
     of this be proven to a regulator?

full_text:
  Internet-Draft                                                   T. Sato
  Intended status: Standards Track                         MyAuberge K.K.
  Expires: November 17, 2026                                  May 17, 2026


                The Governance Audit Record (GAR) for Agentic AI Systems
                          draft-sato-soos-gar-00

  Abstract

     This document specifies the Governance Audit Record (GAR), the audit
     architecture for agentic AI systems.  GAR defines five audit types,
     the Session Audit Record (SAR), the Audit Alert system, auditor
     principal categories, and the Audit Package for external regulatory
     inspection.  GAR provides verifiable evidence that AI agent sessions
     were governed in accordance with the Intent Declaration Primitive
     [I-D.sato-soos-idp] and the Human Escalation Mechanism
     [I-D.sato-soos-hem].  GAR answers the governance question: can any
     of this be proven to a regulator?

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on November 17, 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
     2.  Conventions and Definitions
     3.  Architecture Overview
     4.  Audit Types
       4.1.  Type 1 -- Kernel Self-Audit
       4.2.  Type 2 -- Session-Close Audit
       4.3.  Type 3 -- Event-Triggered Alert
       4.4.  Type 4 -- Scheduled Audit
       4.5.  Type 5 -- On-Demand External Audit
     5.  Auditor Principal Categories
       5.1.  HEM Principal
       5.2.  Audit Principal
       5.3.  Verified External Auditor
       5.4.  Kernel Self-Auditor
     6.  Session Audit Record
       6.1.  SAR Generation
       6.2.  SAR Schema
       6.3.  SAR Signing
       6.4.  SAR Retention
     7.  Audit Alert System
       7.1.  Alert Generation
       7.2.  Alert Schema
       7.3.  Normative Trigger List
       7.4.  Alert Delivery
     8.  Event Log Requirements
       8.1.  IDP Audit Events
       8.2.  HEM Audit Events
       8.3.  GAR Audit Events
       8.4.  CAP Audit Events
     9.  Audit Package
       9.1.  Package Composition
       9.2.  Package Schema
       9.3.  Access Control
     10. EU AI Act Applicability
       10.1. Article 12 Mapping
     11. Security Considerations
     12. IANA Considerations
       12.1. GAR Audit Alert Triggers Registry
       12.2. GAR Auditor Principal Types Registry
     13. References
       13.1. Normative References
       13.2. Informative References
     Author's Address


  1.  Introduction

     Agentic AI systems require governance across four questions:

     o  What did the agent intend before acting?
        [I-D.sato-soos-idp] -- The Intent Declaration Primitive (IDP)
        for Agentic AI Systems

     o  Who governed the agent's decisions?
        [I-D.sato-soos-hem] -- The Human Escalation Mechanism (HEM)
        for Agentic AI Systems

     o  Were those decisions within the law?
        [I-D.sato-soos-cap] -- The Constitutional AI Protocol (CAP)
        for Agentic AI Systems (forthcoming)

     o  Can any of this be proven to a regulator?
        This document -- The Governance Audit Record (GAR) for Agentic
        AI Systems

     GAR is the evidentiary layer of this protocol family.  IDP, HEM, and
     CAP generate governance events; GAR specifies how those events are
     collected, synthesized, signed, and made available for audit.

     The architectural property GAR enforces is non-suppressibility: the
     kernel MUST generate audit artifacts automatically, MUST sign them,
     and MUST NOT allow any agent, application, or principal to suppress,
     modify, or delete them.  This property -- the kernel cannot suppress
     bad news from its principals -- is the foundation of accountable AI
     governance.

     GAR defines five audit types ranging from continuous kernel self-
     audit (Type 1) to on-demand external regulatory inspection (Type 5).
     The Session Audit Record (SAR) is the primary audit artifact: a
     complete, kernel-signed record of every governance event in a
     session, generated automatically at session close.

     This specification is a companion to [I-D.sato-soos-idp] and
     [I-D.sato-soos-hem].  Readers should be familiar with both documents
     before reading this document.


  2.  Conventions and Definitions

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

     The following terms are defined in this document or inherited from
     [I-D.sato-soos-idp] and [I-D.sato-soos-hem]:

     Audit Principal:
        A registered principal with read-only access to governance audit
        artifacts.  Distinct from a HEM Principal.  Receives Audit Alerts
        and reviews Session Audit Records.

     Governance Audit Record (GAR):
        The audit architecture specified in this document, comprising five
        audit types, the SAR, the Audit Alert system, and the Audit
        Package.

     IDP Commitment Gap:
        A condition detected by the kernel when an agent's actual state
        transition does not match the agent's declared IDP commitment.
        Classified as a critical audit finding.

     IDP Commitment Verification Record:
        A kernel-generated record produced after every governed state
        transition, recording whether the agent's action matched its IDP
        commitment.

     Kernel Self-Auditor:
        An architectural property of the governing kernel.  The kernel
        evaluates its own Event Log after every commitment and generates
        KERNEL_AUDIT_ANOMALY entries when inconsistencies are detected.
        Not a human role.

     Rationale Store:
        A kernel-managed object store, separate from the Event Log,
        holding Policy Rationale Declaration (PRD) objects and Decision
        Rationale Records (DRR) indexed by their respective identifiers.

     Session Audit Record (SAR):
        A kernel-generated, kernel-signed summary of all governance events
        in a session, produced automatically at session close.

     Verified External Auditor:
        A regulator, accounting firm, or other external party granted
        time-limited, scope-limited read access to kernel audit artifacts
        by the operator.  Produces an Audit Package.


  3.  Architecture Overview

     The GAR architecture comprises five audit types operating at
     different timescales and with different principals:

        +----------------------------------------------------------+
        |                   AI GOVERNANCE KERNEL                      |
        |                                                          |
        |  [IDP Events] [HEM Events] [CAP Events] [GAR Events]    |
        |           |         |           |            |           |
        |           v         v           v            v           |
        |        +--------------------------------+                |
        |        |         EVENT LOG              |                |
        |        |   append-only, kernel-signed   |                |
        |        +--------------------------------+                |
        |                     |                                    |
        |        +------------+------------+                       |
        |        |                         |                       |
        |        v                         v                       |
        | [Type 1: Self-Audit]    [Type 2: SAR at close]          |
        |  continuous                 session summary              |
        |        |                         |                       |
        |        v                         v                       |
        | KERNEL_AUDIT_ANOMALY      SAR (kernel-signed)            |
        |        |                         |                       |
        +--------|-------------------------|--------------------+  |
                 v                         v
        [Type 3: Audit Alerts]    [Type 4: Scheduled Audit]
         to Audit Principals        cross-session patterns
                 |
                 v
        [Type 5: Audit Package]
         to Verified External Auditor

     The kernel is the sole source of audit truth.  No agent, application,
     HEM Principal, or Audit Principal can generate, modify, or suppress
     kernel audit artifacts.


  4.  Audit Types

  4.1.  Type 1 -- Kernel Self-Audit

     The kernel MUST evaluate its own Event Log after every Event Log
     commitment.  If the kernel detects an inconsistency -- a state
     transition without a corresponding IDP submission, a HEM resolution
     without a recorded trigger, a mandate referenced by an IDP that does
     not exist in the mandate store -- the kernel MUST generate a
     KERNEL_AUDIT_ANOMALY Event Log entry.

     KERNEL_AUDIT_ANOMALY entries are immutable once written.  The kernel
     MUST NOT suppress KERNEL_AUDIT_ANOMALY entries.  A
     KERNEL_AUDIT_ANOMALY entry MUST immediately trigger a Type 3 Audit
     Alert at CRITICAL severity (Section 7.3).

     The kernel MUST also generate an IDP Commitment Verification Record
     after every governed state transition (Section 8.1).  An
     IDP_COMMITMENT_GAP result MUST be treated as a critical audit finding
     equivalent to KERNEL_AUDIT_ANOMALY for alert severity purposes.

  4.2.  Type 2 -- Session-Close Audit

     The kernel MUST generate a Session Audit Record (SAR) automatically
     at the close of every governed session.  SAR generation is not
     requestable by any external party -- it fires unconditionally on
     session close.  The SAR specification is in Section 6.

  4.3.  Type 3 -- Event-Triggered Alert

     The kernel MUST generate an Audit Alert when a normative trigger
     condition is detected.  Audit Alerts are delivered to all registered
     Audit Principals for the governed session.  The normative trigger
     list is in Section 7.3.

  4.4.  Type 4 -- Scheduled Audit

     Audit Principals MAY initiate cross-session pattern audits covering
     a specified time range or SO Type population.  The kernel MUST expose
     a kernel.query_scheduled_audit() interface for this purpose.  Type 4
     audits produce cross-session pattern reports and MUST be recorded as
     SCHEDULED_AUDIT_INITIATED and SCHEDULED_AUDIT_COMPLETED Event Log
     entries.

     The kernel SHOULD initiate a Type 4 audit automatically when a PRD
     review_date is exceeded, covering all sessions governed by the
     overdue policy.

  4.5.  Type 5 -- On-Demand External Audit

     Operators MAY grant Verified External Auditors time-limited, scope-
     limited read access to kernel audit artifacts.  Access grants MUST be
     recorded as EXTERNAL_AUDIT_ACCESS_GRANTED Event Log entries.  Access
     revocation MUST be recorded as EXTERNAL_AUDIT_ACCESS_REVOKED.  Audit
     Packages produced by Verified External Auditors are specified in
     Section 9.


  5.  Auditor Principal Categories

     GAR defines four distinct auditor categories.  These are not
     interchangeable.

  5.1.  HEM Principal

     A HEM Principal is registered in a designation chain and resolves
     HEM escalations.  A HEM Principal is NOT an auditor.  HEM Principals
     do not receive Audit Alerts and do not have access to the Rationale
     Store or Event Log beyond what is included in the HEM Escalation
     Request.

  5.2.  Audit Principal

     An Audit Principal is a registered principal with principal_type:
     AUDIT.  Audit Principals receive Audit Alerts, review Session Audit
     Records, and may initiate Type 4 scheduled audits.

     An Audit Principal MUST NOT appear in a HEM designation chain.  The
     kernel MUST reject SO Type configurations that place an Audit
     Principal in a designation chain.

     Audit Principals have read-only access to:
     o  The Event Log (kernel.query_event_log())
     o  The Rationale Store (kernel.query_rationale())
     o  Session Audit Records (kernel.query_sar())
     o  IDP Commitment Verification Records

     Audit Principals MUST NOT be able to modify any kernel artifact.

  5.3.  Verified External Auditor

     A Verified External Auditor is a regulator, accounting firm, or
     other external party granted temporary read access by the operator.
     Access is time-limited and scope-limited.  The operator declares
     the access scope (session range, SO Type filter, time window) and
     expiry at grant time.

     A Verified External Auditor produces an Audit Package (Section 9)
     covering the declared scope.  The Audit Package is kernel-signed as
     of the production timestamp.

  5.4.  Kernel Self-Auditor

     The Kernel Self-Auditor is an architectural property, not a human
     role.  It refers to the Type 1 continuous self-audit function
     executed by the kernel after every Event Log commitment.  It cannot
     be disabled, configured, or bypassed.


  6.  Session Audit Record

  6.1.  SAR Generation

     The kernel MUST generate a SAR automatically at the close of every
     governed session regardless of close reason (normal completion,
     TERMINATE decision, mandate expiry, session timeout, or error).

     SAR generation MUST be atomic with session close.  The kernel MUST
     NOT return a session close confirmation to any external party before
     the SAR is committed to the audit store.

     The kernel MUST sign every SAR using Ed25519 with the kernel's
     signing key.  The signing key MUST be the same key used for Mandate
     JWT signing and HEM Escalation Request signing, published via the
     operator's JWKS endpoint.

  6.2.  SAR Schema

     A SAR MUST contain the following fields.  All fields are REQUIRED
     unless stated otherwise.

     sar_id:
        Kernel-generated UUID.  Unique identifier for this SAR.

     session_id:
        The session identifier.  Links the SAR to all Event Log entries
        for this session.

     mandate_id:
        The governing mandate identifier.  The mandate in force at session
        open.

     mission_ref:
        The MissionDeclaration reference.  Null if no mission was
        declared for this session.

     open_timestamp:
        ISO 8601 UTC timestamp of session open.

     close_timestamp:
        ISO 8601 UTC timestamp of session close.

     close_reason:
        Controlled vocabulary.  One of: NORMAL_COMPLETION | TERMINATE_DECISION
        | MANDATE_EXPIRY | SESSION_TIMEOUT | ERROR | CAP_SUSPENSION.

     idp_submissions:
        Array of IDP summary records.  Each entry contains:
           idp_id:          IDP identifier.
           goal_summary:    Human-readable goal description.
           cedar_outcome:   PERMIT | DENY | HEM_ROUTED.
           hem_triggered:   Boolean.
           hem_decision:    Decision type if HEM was triggered, null
                            otherwise.

     hem_events:
        Array of HEM event summary records.  Each entry contains:
           hem_id:                   HEM event identifier.
           trigger_class:            Classes 1-5.
           trigger_source:           AGENT_DETECTED | TRAVELER_REQUEST |
                                     SYSTEM_EVENT.
           policy_rationale_id:      PRD identifier, null if absent.
           decision_type:            Final decision type.
           decision_rationale_class: DRR rationale class, null if absent.
           resolution_time_seconds:  Integer.  Wall time from trigger to
                                     resolution.

     state_transitions:
        Array of state transition records.  Each entry contains:
           from_state:   Prior governed object state.
           to_state:     Resulting governed object state.
           action:       Cedar action string.
           timestamp:    ISO 8601 UTC.

     cap_violations:
        Array of CAP violation records.  Each entry contains:
           violation_id:    CAP Violation Record identifier.
           tier:            0 | 1 | 2.
           prohibition_id:  Prohibition identifier.
           action:          Action attempted.
           outcome:         REFUSED | SESSION_SUSPENDED | HEM_FIRED.

     audit_summary:
        Summary counts block.  Contains:
           total_transitions:        Integer.
           hem_events_count:         Integer.
           terminate_count:          Integer.
           auto_approve_count:       Integer.
           policy_rationale_gaps:    Integer.  HEM events with no PRD.
           decision_rationale_gaps:  Integer.  HEM events where DRR was
                                     required but absent.
           cap_violation_count:      Integer.
           jurisdictional_conflicts: Integer.

     kernel_signature:
        Ed25519 signature over the canonical serialization of all SAR
        fields except kernel_signature itself.

     The idp_submissions, hem_events, state_transitions, and cap_violations
     arrays carry reference fields and key summary data only.  Full detail
     for each record is available in the Event Log and Rationale Store.
     The SAR is a governance summary and index, not a duplicate of the
     Event Log.

  6.3.  SAR Signing

     The kernel MUST sign the SAR using Ed25519 prior to committing it
     to the audit store.  The canonical serialization for signing is the
     JSON serialization of all fields except kernel_signature, with keys
     in lexicographic order and no whitespace.

     Audit Principals and Verified External Auditors MUST verify the
     kernel_signature before relying on SAR content.

  6.4.  SAR Retention

     Operators SHOULD retain Session Audit Records for a minimum of 12
     months from session close_timestamp.  Operators subject to EU AI Act
     Article 12 obligations MUST retain SARs for the period required by
     applicable law.  The kernel SHOULD warn Audit Principals when a SAR
     approaches its configured retention expiry.


  7.  Audit Alert System

  7.1.  Alert Generation

     The kernel MUST generate an Audit Alert when any normative trigger
     condition listed in Section 7.3 is detected.  Alert generation is
     synchronous with the triggering event -- the kernel MUST generate the
     alert before returning any response to the triggering agent or
     principal.

  7.2.  Alert Schema

     An Audit Alert MUST contain the following fields:

     alert_id:
        Kernel-generated UUID.

     alert_severity:
        CRITICAL | HIGH | MEDIUM | LOW.

     alert_trigger:
        Identifier of the normative trigger condition.  See Section 7.3.

     session_id:
        The session in which the trigger occurred.

     hem_id:
        The HEM event identifier, if the trigger is HEM-related.  Null
        otherwise.

     cap_violation_id:
        The CAP Violation Record identifier, if the trigger is CAP-
        related.  Null otherwise.

     detail:
        Human-readable description of the trigger condition.  REQUIRED.

     timestamp:
        ISO 8601 UTC timestamp of alert generation.

     kernel_signature:
        Ed25519 signature over canonical serialization of all fields
        except kernel_signature.

     delivered_to:
        Array of Audit Principal identifiers to whom the alert was
        delivered.

  7.3.  Normative Trigger List

     The following trigger conditions MUST generate an Audit Alert.
     Trigger identifiers are registered in the GAR Audit Alert Triggers
     registry (Section 12.1).

     +-----------------------------------------+-----------+
     | Trigger                                 | Severity  |
     +-----------------------------------------+-----------+
     | KERNEL_AUDIT_ANOMALY                    | CRITICAL  |
     | IDP_COMMITMENT_GAP                      | CRITICAL  |
     | TERMINATE_DECISION                      | HIGH      |
     | AUTO_APPROVE_DISPOSITION                | HIGH      |
     | HEM_CHAIN_EXHAUSTED                     | HIGH      |
     | MISSION_REVOKE_CASCADE                  | HIGH      |
     | HEM_TERMINATE_RATIONALE_REQUIRED        | MEDIUM    |
     | THREE_OR_MORE_HEM_EVENTS_IN_SESSION     | MEDIUM    |
     | PRD_REVIEW_DATE_EXCEEDED                | MEDIUM    |
     | POLICY_RATIONALE_GAPS_IN_SAR            | LOW       |
     +-----------------------------------------+-----------+

     Table 1: Normative Audit Alert Triggers

  7.4.  Alert Delivery

     Audit Alerts MUST be delivered to all registered Audit Principals
     for the governed session.  Delivery MUST be recorded as an
     AUDIT_ALERT_FIRED Event Log entry, followed by AUDIT_ALERT_DELIVERED
     on successful delivery.

     Implementations SHOULD use the Shared Signals Framework (SSF)
     [RFC8936] for cross-system Audit Alert delivery.

     Audit Principals SHOULD acknowledge Audit Alerts.  Acknowledgement
     MUST be recorded as AUDIT_ALERT_ACKNOWLEDGED.


  8.  Event Log Requirements

     The Event Log is the append-only, kernel-maintained record of all
     governance events in a session.  The Event Log specification is
     normative in [I-D.sato-soos-hem] Section 10.  This section specifies the
     GAR-specific Event Log entries that MUST be supported.

  8.1.  IDP Audit Events

     IDP_SUBMITTED:
        Recorded when an IDP is submitted to the kernel.  Existing entry
        type specified in [I-D.sato-soos-idp].

     IDP_COMMITMENT_VERIFIED:
        Recorded after every governed state transition.  The kernel MUST
        generate an IDP Commitment Verification Record and commit this
        event.  Fields: idp_id, state_transition_id, verified_at,
        match_result (MATCHED | IDP_COMMITMENT_GAP), kernel_signature.

     IDP_COMMITMENT_GAP:
        Recorded when match_result is IDP_COMMITMENT_GAP.  This is a
        critical audit finding.  The kernel MUST immediately:
        (a) generate a CRITICAL Audit Alert (alert_trigger:
            IDP_COMMITMENT_GAP), and
        (b) fire HEM_AGENT_ESCALATED (Class 2) for the active session.
        The kernel MUST NOT allow a session to continue after an
        IDP_COMMITMENT_GAP without HEM resolution.

  8.2.  HEM Audit Events

     The following HEM Event Log entries gain new fields under GAR:

     HEM_TRIGGERED:
        Existing entry type.  GAR adds: policy_rationale_id (REQUIRED,
        null if PRD absent -- absence recorded in audit_summary.
        policy_rationale_gaps).

     HEM_DECISION_RECEIVED:
        Existing entry type.  GAR adds: decision_rationale_class
        (REQUIRED when DRR is mandatory for the decision type; OPTIONAL
        otherwise).

     The following new HEM Event Log entries are specified in
     [I-D.sato-soos-hem] and recorded in the GAR Event Log:

     HEM_DECISION_NOT_PERMITTED_FOR_TRIGGER_CLASS
     HEM_TERMINATE_RATIONALE_REQUIRED
     HEM_HUMAN_DECISION_CONSTITUTIONAL_VIOLATION
     HEM_CHAIN_CONSTITUTIONAL_EXHAUSTED
     KERNEL_AUDIT_ANOMALY

  8.3.  GAR Audit Events

     The following Event Log entry types are introduced by this document:

     SAR_GENERATED:
        Recorded when a SAR is committed to the audit store.  Fields:
        sar_id, session_id, close_reason, kernel_signature.

     AUDIT_ALERT_FIRED:
        Recorded when an Audit Alert is generated.  Fields: alert_id,
        alert_trigger, alert_severity, session_id.

     AUDIT_ALERT_DELIVERED:
        Recorded when an Audit Alert is successfully delivered to an
        Audit Principal.  Fields: alert_id, principal_id, delivered_at.

     AUDIT_ALERT_ACKNOWLEDGED:
        Recorded when an Audit Principal acknowledges an Audit Alert.
        Fields: alert_id, principal_id, acknowledged_at.

     SCHEDULED_AUDIT_INITIATED:
        Recorded when a Type 4 scheduled audit begins.  Fields:
        audit_id, initiated_by, scope_description, initiated_at.

     SCHEDULED_AUDIT_COMPLETED:
        Recorded when a Type 4 scheduled audit completes.  Fields:
        audit_id, completed_at, findings_count.

     EXTERNAL_AUDIT_ACCESS_GRANTED:
        Recorded when a Verified External Auditor is granted access.
        Fields: auditor_id, granted_by, scope, expiry, granted_at.

     AUDIT_PACKAGE_PRODUCED:
        Recorded when a Verified External Auditor produces an Audit
        Package.  Fields: package_id, auditor_id, scope, produced_at,
        package_hash.

     EXTERNAL_AUDIT_ACCESS_REVOKED:
        Recorded when Verified External Auditor access expires or is
        revoked.  Fields: auditor_id, revoked_at, revocation_reason.

     PRD_REVIEW_DATE_EXCEEDED:
        Recorded by the kernel's continuous self-audit when a PRD
        review_date is exceeded.  Fields: prd_id, policy_id,
        review_date, detected_at.  This entry MUST trigger a MEDIUM
        Audit Alert (alert_trigger: PRD_REVIEW_DATE_EXCEEDED).

  8.4.  CAP Audit Events

     The following CAP Event Log entries are specified in
     [I-D.sato-soos-cap] and recorded in the GAR Event Log:

     CAP_VIOLATION_DETECTED:
        AI-initiated action refused by the Constitutional Evaluation
        Engine.  Fields: violation_id, tier, prohibition_id, action,
        outcome, timestamp, kernel_signature.

     CAP_HUMAN_VIOLATION_DETECTED:
        Human principal decision refused by the Constitutional Evaluation
        Engine.  Fields: violation_id, tier, prohibition_id, decision,
        outcome, timestamp, kernel_signature.

     CAP_TIER1_CONFLICT_DETECTED:
        Jurisdictional conflict detected at Tier 1.  Fields: conflict_id,
        conflicting_jurisdictions, resolution_method, hem_id, timestamp.

     APPROVE_WITH_LEGAL_BASIS_RECORDED:
        Principal submitted APPROVE_WITH_LEGAL_BASIS decision.  Fields:
        hem_id, principal_id, legal_basis (authority_type, authority_ref,
        jurisdiction, expiry, document_hash), timestamp.

     SESSION_CAP_SUSPENDED:
        Session suspended due to CAP violation.  Fields: session_id,
        violation_id, suspended_at.


  9.  Audit Package

  9.1.  Package Composition

     An Audit Package is produced by a Verified External Auditor and
     covers a declared scope (session range, SO Type filter, or time
     window).  The Audit Package is a kernel-signed compilation of:

     o  All SARs within scope
     o  All Event Log entries within scope
     o  All PRD records from the Rationale Store for policies governing
        sessions within scope
     o  All DRR records from the Rationale Store for decisions within
        scope
     o  All Audit Alert records within scope
     o  All CAP Violation Records within scope

  9.2.  Package Schema

     An Audit Package MUST contain the following fields:

     package_id:
        Kernel-generated UUID.

     auditor_id:
        Verified External Auditor identifier.

     scope:
        Declaration of what the package covers.  Fields: session_range,
        so_type_filter (optional), time_window.

     sar_records:
        Array of all SARs within scope.

     event_log_records:
        Array of all Event Log entries within scope.

     prd_records:
        Array of all PRD objects from the Rationale Store for policies
        governing sessions within scope.

     drr_records:
        Array of all DRR objects from the Rationale Store for decisions
        within scope.

     audit_alert_records:
        Array of all Audit Alert records within scope.

     cap_violation_records:
        Array of all CAP Violation Records within scope.

     chain_of_custody:
        Block containing:
           package_hash:    SHA-256 hash of all package content fields.
           kernel_signature: Ed25519 signature over package_hash.
           produced_by:     Verified External Auditor identifier.
           produced_at:     ISO 8601 UTC timestamp.

  9.3.  Access Control

     The kernel MUST verify that the requesting party holds a valid,
     unexpired Verified External Auditor access grant before producing
     an Audit Package.  The access grant MUST be scoped to include the
     requested sessions.

     Audit Package production MUST be recorded as AUDIT_PACKAGE_PRODUCED
     in the Event Log.


  10.  EU AI Act Applicability

  10.1.  Article 12 Mapping

     EU AI Act Article 12 requires high-risk AI systems to automatically
     generate logs enabling post-market monitoring and audit.  The
     following table maps Article 12 provisions to GAR mechanisms.
     This mapping is normative: the Event Log fields and SAR structure
     specified in this document satisfy Article 12(3) traceability
     requirements for deployments governed by [I-D.sato-soos-hem].
     Operators may reference
     this section directly in conformance documentation.

     +------------------------------+--------------------------------+------+
     | Article 12 Provision         | GAR Mechanism                  | Sec. |
     +------------------------------+--------------------------------+------+
     | 12(1) Automatic logging      | Event Log: append-only,        | 8    |
     | capability                   | kernel-generated, cannot be    |      |
     |                              | suppressed                     |      |
     +------------------------------+--------------------------------+------+
     | 12(2) Logging period         | SAR close_timestamp + operator | 6.4  |
     | commensurate with purpose    | retention configuration;       |      |
     |                              | SHOULD minimum 12 months       |      |
     +------------------------------+--------------------------------+------+
     | 12(3) Traceability of AI     | hem_id chain across Event Log  | 8    |
     | system operation             | entries -- full causal history  |      |
     |                              | reconstructible from any event |      |
     +------------------------------+--------------------------------+------+
     | 12(3) Human oversight audit  | principal_type + principal_id  | 8.2  |
     | record                       | + decision_type + DRR on every |      |
     |                              | HEM_DECISION_RECEIVED entry    |      |
     +------------------------------+--------------------------------+------+
     | 12(3) Policy audit record    | PRD + prd_id on every          | 8.2  |
     |                              | HEM_TRIGGERED entry            |      |
     +------------------------------+--------------------------------+------+

     Table 2: EU AI Act Article 12 Mapping


  11.  Security Considerations

     The GAR audit architecture relies on the following security
     properties:

     Kernel signing key integrity:
        All SAR, Audit Alert, IDP Commitment Verification Record, and
        Audit Package chain-of-custody signatures depend on the integrity
        of the kernel's Ed25519 signing key.  Operators MUST protect the
        kernel signing key using hardware security module (HSM) controls
        or equivalent.  Key compromise MUST be treated as a critical
        security incident requiring immediate rotation and re-signing of
        all affected audit artifacts.

     Event Log append-only property:
        The Event Log MUST be implemented as an append-only data structure.
        No API MUST allow deletion or modification of existing entries.
        Audit Principals and Verified External Auditors MUST have read-
        only access.

     Non-suppressibility:
        The kernel MUST NOT expose any interface that allows an agent,
        application, HEM Principal, or Audit Principal to suppress SAR
        generation, Audit Alert firing, or IDP Commitment Verification.
        Implementations MUST be reviewed for any code path that could
        conditionally skip these operations.

     Audit Principal separation:
        Audit Principals MUST be registered separately from HEM
        Principals.  The same party SHOULD NOT hold both roles for
        the same SO Type.  Separation prevents a principal from
        suppressing audit findings about their own HEM decisions.

     Verified External Auditor access:
        Kernel interfaces for Verified External Auditor access MUST
        enforce scope limitations at the query layer.  Access grants
        MUST expire automatically.  The kernel MUST reject queries
        outside the declared scope.

     PRD review_date enforcement:
        Operators MUST ensure that PRD review_date values reflect
        genuine governance review cycles.  Stale PRDs with extended
        review_dates undermine the living governance record property
        that PRD is designed to provide.


  12.  IANA Considerations

  12.1.  GAR Audit Alert Triggers Registry

     This document establishes the "Governance Audit Record Audit Alert
     Triggers" registry.  The registry is maintained at:
     https://www.iana.org/assignments/gar-audit-alert-triggers

     Registration procedure: Specification Required.

     Initial values:

     +------------------------------------------+-----------+-----------+
     | Trigger Identifier                        | Severity  | Reference |
     +------------------------------------------+-----------+-----------+
     | KERNEL_AUDIT_ANOMALY                      | CRITICAL  | Sec. 7.3  |
     | IDP_COMMITMENT_GAP                        | CRITICAL  | Sec. 7.3  |
     | TERMINATE_DECISION                        | HIGH      | Sec. 7.3  |
     | AUTO_APPROVE_DISPOSITION                  | HIGH      | Sec. 7.3  |
     | HEM_CHAIN_EXHAUSTED                       | HIGH      | Sec. 7.3  |
     | MISSION_REVOKE_CASCADE                    | HIGH      | Sec. 7.3  |
     | HEM_TERMINATE_RATIONALE_REQUIRED          | MEDIUM    | Sec. 7.3  |
     | THREE_OR_MORE_HEM_EVENTS_IN_SESSION       | MEDIUM    | Sec. 7.3  |
     | PRD_REVIEW_DATE_EXCEEDED                  | MEDIUM    | Sec. 7.3  |
     | POLICY_RATIONALE_GAPS_IN_SAR              | LOW       | Sec. 7.3  |
     +------------------------------------------+-----------+-----------+

     Table 3: Initial GAR Audit Alert Triggers Registry Values

  12.2.  GAR Auditor Principal Types Registry

     This document establishes the "Governance Audit Record Auditor
     Principal Types" registry.  The registry is maintained at:
     https://www.iana.org/assignments/gar-auditor-principal-types

     Registration procedure: Standards Action.

     Initial values:

     +---------------------------+---------------------------------------+
     | Type                      | Description                           |
     +---------------------------+---------------------------------------+
     | HEM_PRINCIPAL             | Resolves HEM escalations.             |
     |                           | NOT an auditor.                       |
     +---------------------------+---------------------------------------+
     | AUDIT_PRINCIPAL           | Receives Audit Alerts, reviews SARs,  |
     |                           | initiates Type 4 scheduled audits.    |
     |                           | Read-only kernel access.              |
     +---------------------------+---------------------------------------+
     | VERIFIED_EXTERNAL_AUDITOR | Regulator or accounting firm.         |
     |                           | Time-limited, scope-limited kernel    |
     |                           | access. Produces Audit Packages.      |
     +---------------------------+---------------------------------------+
     | KERNEL_SELF_AUDITOR       | Architectural property of the kernel. |
     |                           | Not a human role.                     |
     +---------------------------+---------------------------------------+

     Table 4: Initial GAR Auditor Principal Types Registry Values


  13.  References

  13.1.  Normative References

     [I-D.sato-soos-hem]
                Sato, T., "The Human Escalation Mechanism (HEM) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-hem-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-hem/>.

     [I-D.sato-soos-idp]
                Sato, T., "The Intent Declaration Primitive (IDP) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-idp-00, May 2026,
                <https://datatracker.ietf.org/doc/draft-sato-soos-idp/>.

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

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

     [RFC8936]  Hunt, P., Ed., Brock, M., Backman, A., and M. Jones,
                "Poll-Based Security Event Token (SET) Delivery Using
                HTTP", RFC 8936, DOI 10.17487/RFC8936, November 2020,
                <https://www.rfc-editor.org/rfc/rfc8936>.

  13.2.  Informative References

     [I-D.sato-soos-cap]
                Sato, T., "The Constitutional AI Protocol (CAP) for
                Agentic AI Systems", Work in Progress, Internet-Draft,
                draft-sato-soos-cap-00, May 2026.
                (forthcoming)

     [EU-AI-ACT]
                European Parliament and Council, "Regulation (EU)
                2024/1689 laying down harmonised rules on artificial
                intelligence", OJ L 2024/1689, July 2024,
                <https://eur-lex.europa.eu/legal-content/EN/TXT/
                ?uri=OJ:L_202401689>.


  Author's Address

     Tom Sato
     MyAuberge K.K.
     Chino, Nagano
     Japan
     Email: tomsato@myauberge.jp
     URI:   https://activitytravel.pro/


name: draft-vandemeent-jis-identity
rev: 01
title: JIS: JTel Identity Standard - Identity and Trust Establishment for Autonomous Agents
time: 2026-03-29T12:15:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-30T12:15:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:44.863712+00:00
source: ietf
abstract:
  This document defines JIS (JTel Identity Standard), a protocol for
     establishing identity, negotiating trust, and binding intent
     declarations to actor interactions.  JIS provides three core
     mechanisms: a dual-keypair identity model separating human-device
     binding (HID) from device authentication (DID), a trust establishment
     handshake (FIR/A) that negotiates capabilities and records intent,
     and a human-readable context layer (Humotica) that captures the
     sense, context, intent, and explanation for every interaction.

     JIS is transport-agnostic and operates as a semantic layer above
     existing protocols.  It integrates with TIBET [TIBET] for provenance
     tracking, and is consumed by UPIP [UPIP], RVP [RVP], and AINS [AINS]
     for process integrity, continuous verification, and agent discovery
     respectively.

full_text:
  Internet Engineering Task Force                          J. van de Meent
  Internet-Draft                                                     R. AI
  Intended status: Informational                                  Humotica
  Expires: 30 September 2026                                 29 March 2026


     JIS: JTel Identity Standard - Identity and Trust Establishment for
                             Autonomous Agents
                      draft-vandemeent-jis-identity-01

  Abstract

     This document defines JIS (JTel Identity Standard), a protocol for
     establishing identity, negotiating trust, and binding intent
     declarations to actor interactions.  JIS provides three core
     mechanisms: a dual-keypair identity model separating human-device
     binding (HID) from device authentication (DID), a trust establishment
     handshake (FIR/A) that negotiates capabilities and records intent,
     and a human-readable context layer (Humotica) that captures the
     sense, context, intent, and explanation for every interaction.

     JIS is transport-agnostic and operates as a semantic layer above
     existing protocols.  It integrates with TIBET [TIBET] for provenance
     tracking, and is consumed by UPIP [UPIP], RVP [RVP], and AINS [AINS]
     for process integrity, continuous verification, and agent discovery
     respectively.

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

  Copyright Notice

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



  van de Meent & AI       Expires 30 September 2026               [Page 1]


  Internet-Draft                     JIS                        March 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Identity Model  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  HID (Human Identity Key)  . . . . . . . . . . . . . . . .   6
       3.2.  DID (Device Identity Key) . . . . . . . . . . . . . . . .   7
       3.3.  HID-DID Binding . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Actor Identifier Format . . . . . . . . . . . . . . . . .   7
       3.5.  Key Lifecycle . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Trust Establishment (FIR/A) . . . . . . . . . . . . . . . . .   8
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Phase 1: INITIATE . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Phase 2: CAPABILITIES . . . . . . . . . . . . . . . . . .   9
       4.4.  Phase 3: CONFIRM  . . . . . . . . . . . . . . . . . . . .  10
       4.5.  Phase 4: EXECUTE  . . . . . . . . . . . . . . . . . . . .  10
       4.6.  Trust Score Model . . . . . . . . . . . . . . . . . . . .  11
       4.7.  Failure Conditions  . . . . . . . . . . . . . . . . . . .  11
     5.  Context Layer (Humotica)  . . . . . . . . . . . . . . . . . .  12
       5.1.  Structure . . . . . . . . . . . . . . . . . . . . . . . .  12
       5.2.  Minimum Required Context  . . . . . . . . . . . . . . . .  12
       5.3.  Semantic Validation . . . . . . . . . . . . . . . . . . .  12
       5.4.  Mapping to TIBET Components . . . . . . . . . . . . . . .  13
     6.  Intent Validation . . . . . . . . . . . . . . . . . . . . . .  13
       6.1.  Validation as Evidence  . . . . . . . . . . . . . . . . .  13
       6.2.  Blocked Intent Patterns . . . . . . . . . . . . . . . . .  14
       6.3.  Risk Scoring (BALANS) . . . . . . . . . . . . . . . . . .  14
       6.4.  Dialogue Resolution (NIR) . . . . . . . . . . . . . . . .  15
     7.  TIBET Integration . . . . . . . . . . . . . . . . . . . . . .  15
       7.1.  Identity as TIBET Precondition  . . . . . . . . . . . . .  15
       7.2.  FIR/A Events as TIBET Tokens  . . . . . . . . . . . . . .  15
       7.3.  Continuity Chain Delegation . . . . . . . . . . . . . . .  16
     8.  Transport Considerations  . . . . . . . . . . . . . . . . . .  16
       8.1.  Baseline: JSON over HTTPS . . . . . . . . . . . . . . . .  16
       8.2.  Alternative Bindings  . . . . . . . . . . . . . . . . . .  16
     9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  16



  van de Meent & AI       Expires 30 September 2026               [Page 2]


  Internet-Draft                     JIS                        March 2026


       9.1.  HID Protection  . . . . . . . . . . . . . . . . . . . . .  17
       9.2.  Pseudonymous Operation  . . . . . . . . . . . . . . . . .  17
       9.3.  Data Minimization . . . . . . . . . . . . . . . . . . . .  17
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
       10.1.  Identity Protection  . . . . . . . . . . . . . . . . . .  18
       10.2.  Semantic Validation Limitations  . . . . . . . . . . . .  18
       10.3.  FIR/A Handshake Attacks  . . . . . . . . . . . . . . . .  18
       10.4.  Key Compromise and Rotation  . . . . . . . . . . . . . .  19
       10.5.  Replay Protection  . . . . . . . . . . . . . . . . . . .  19
       10.6.  Trust Score Manipulation . . . . . . . . . . . . . . . .  19
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
       11.1.  Media Type Registration  . . . . . . . . . . . . . . . .  20
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       12.2.  Informative References . . . . . . . . . . . . . . . . .  21
     Appendix A.  Complete Flow Example  . . . . . . . . . . . . . . .  21
       A.1.  Bank Fraud Verification . . . . . . . . . . . . . . . . .  22
     Appendix B.  Conformance Levels . . . . . . . . . . . . . . . . .  23
       B.1.  JIS Basic . . . . . . . . . . . . . . . . . . . . . . . .  23
       B.2.  JIS Extended  . . . . . . . . . . . . . . . . . . . . . .  23
       B.3.  JIS Full  . . . . . . . . . . . . . . . . . . . . . . . .  23
     Appendix C.  Changes from -00 . . . . . . . . . . . . . . . . . .  24
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     AI agents, IoT devices, automated services, and human operators
     increasingly interact across trust boundaries -- across
     organizations, protocols, and jurisdictions.  These interactions
     require answers to three questions that existing protocols address
     incompletely:

     1.  WHO is acting?  (Identity)

     2.  WHY are they acting?  (Intent)

     3.  SHOULD they be trusted?  (Trust)

     Existing identity protocols (OAuth 2.0, SAML, FIDO2) solve
     authentication -- proving WHO.  But they do not capture WHY an action
     is requested, nor do they provide a mechanism for bilateral trust
     negotiation where both parties declare intent and agree on
     capabilities before proceeding.

     JIS addresses this gap by defining:





  van de Meent & AI       Expires 30 September 2026               [Page 3]


  Internet-Draft                     JIS                        March 2026


     *  A dual-keypair identity model where human identity (HID) never
        leaves the device and device identity (DID) handles all external
        authentication.

     *  A trust establishment handshake (FIR/A) where both parties declare
        intent, negotiate capabilities, and establish a trust relationship
        with a cryptographic genesis record.

     *  A human-readable context layer (Humotica) that makes every
        interaction auditable by non-technical reviewers.

  1.1.  Problem Statement

     Three structural problems motivate JIS:

     PROTOCOL FRAGMENTATION:  When N systems communicate, they require up
        to N*(N-1)/2 pairwise integrations.  JIS reduces this to N
        adapters by providing a protocol-agnostic identity and intent
        layer that sits above transport.

     REACTIVE SECURITY:  Traditional firewalls and access control systems
        react to attack patterns.  They evaluate WHAT is requested against
        rules.  They cannot evaluate WHY it is requested, because no
        standardized mechanism exists for declaring intent as part of the
        request.

     CONTEXT BLINDNESS:  Systems process requests without understanding
        the situation: a payment at 3 AM from a new country, a 4th failed
        attempt to turn on heating by a frustrated user, a model inference
        request from an agent with no established history.  Without
        context, systems cannot differentiate legitimate unusual behavior
        from threats.

  1.2.  Design Principles

     EVIDENCE OVER ENFORCEMENT:  JIS validates intent and produces
        evidence.  Whether to block, allow, or escalate is a local policy
        decision.  Intent validation failures are recorded as evidence,
        not treated as access denials.

     PRIVACY FIRST:  Human identity (HID) never leaves the device.  Only
        the device identity (DID) and HID-DID binding hash are used in
        external communication.  This ensures that human identity remains
        private even if all communications are intercepted.

     TRANSPORT AGNOSTICISM:  JIS messages are JSON [RFC8259] objects that
        can be carried over any transport.  HTTP, WebSocket, MQTT, SIP,
        Matrix, CoAP, gRPC, and Bluetooth are all suitable.



  van de Meent & AI       Expires 30 September 2026               [Page 4]


  Internet-Draft                     JIS                        March 2026


     COMPANION INTEGRATION:  JIS provides identity and trust.  Provenance
        tracking is delegated to TIBET [TIBET].  Process integrity to UPIP
        [UPIP].  Continuous verification to RVP [RVP].  Discovery to AINS
        [AINS].

  1.3.  Scope

     This document defines:

     *  The JIS identity model (HID, DID, bindings)

     *  The FIR/A trust establishment handshake

     *  The Humotica context structure

     *  Intent validation as an evidence mechanism

     *  Integration points with companion protocols

     This document does NOT define:

     *  Audit trail format (see TIBET [TIBET])

     *  Process integrity or handoff (see UPIP [UPIP])

     *  Continuous identity verification (see RVP [RVP])

     *  Agent discovery and resolution (see AINS [AINS])

     *  Specific enforcement policies

  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.

     Actor  An entity participating in a JIS interaction.  Actors include
        human users, AI agents (IDDs), IoT devices, automated services,
        and organizations.

     BALANS  Risk scoring system.  Produces a score from 0.0 to 1.0 based
        on multiple factors.  Used as evidence input for access decisions.

     DID (Device Identity Key)  An Ed25519 key pair used for device




  van de Meent & AI       Expires 30 September 2026               [Page 5]


  Internet-Draft                     JIS                        March 2026


        authentication.  The public key is shared during FIR/A.  The
        private key remains on the device.

     FIR/A (First Initiation Revoke/Accept)  The trust establishment
        handshake.  Produces a genesis record that anchors all subsequent
        interactions between two parties.

     HID (Human Identity Key)  An X25519 key pair binding a human to a
        device.  The private key MUST NEVER leave the device.  Only the
        binding hash (HID-DID binding) is used externally.

     Humotica  A structured context object capturing sense, context,
        intent, and explanation for an interaction.  Named for its focus
        on human-readable, empathetic context.

     IDD (Individual Device Derivative)  An AI agent with unique identity,
        evolved from base models through interaction and context
        accumulation.  Defined conceptually; not a protocol primitive.

     NIR (Notify, Identify, Rectify)  A dialogue-based resolution protocol
        for ambiguous situations.  Used when intent validation produces
        insufficient confidence.

  3.  Identity Model

  3.1.  HID (Human Identity Key)

     HID is an X25519 key pair that binds a human identity to a device.

     {
       "hid": {
         "algorithm": "X25519",
         "public_key": "<base64 X25519 public key>",
         "created_at": "<ISO-8601 timestamp>",
         "device_bound": true
       }
     }

     The HID private key MUST NEVER leave the device.  The HID private key
     MUST NOT be transmitted over any channel.  The HID private key SHOULD
     be stored in a hardware secure element (TEE, SE) when available.

     The HID public key is used ONLY for computing the HID-DID binding
     hash (Section 3.3).  The HID public key itself SHOULD NOT be
     transmitted.  Only the binding hash is shared.






  van de Meent & AI       Expires 30 September 2026               [Page 6]


  Internet-Draft                     JIS                        March 2026


  3.2.  DID (Device Identity Key)

     DID is an Ed25519 key pair used for device authentication and token
     signing.

     {
       "did": {
         "algorithm": "Ed25519",
         "public_key": "<base64 Ed25519 public key>",
         "created_at": "<ISO-8601 timestamp>"
       }
     }

     The DID public key is shared during FIR/A establishment (Section 4).
     The DID private key MUST remain on the device and is used for signing
     TIBET tokens and FIR/A messages.

  3.3.  HID-DID Binding

     The HID-DID binding proves that a specific human is associated with a
     specific device, without revealing the human's identity key.

     Computation:

     binding_hash = SHA-256(HID_public_key || DID_public_key)

     SHA-256 is computed per [FIPS180-4].  The binding_hash is:

     *  Shared during FIR/A as proof of human-device association

     *  Verifiable by any party that has seen both public keys

     *  Computed locally; neither key needs to be transmitted

     This design ensures that compromising the device (obtaining DID
     private key) does not compromise the human's identity key (HID
     private key).

  3.4.  Actor Identifier Format

     JIS defines three actor identifier formats:

     jis:<entity_type>:<identifier>

     Entity types:

     "human"  A human user.  Example: "jis:human:jasper_2025"




  van de Meent & AI       Expires 30 September 2026               [Page 7]


  Internet-Draft                     JIS                        March 2026


     "idd"  An AI agent (IDD).  Example: "jis:idd:root_idd_2025"

     "service"  An automated service.  Example:
        "jis:service:payment_gateway"

     The identifier portion SHOULD be meaningful and stable.
     Implementations MUST NOT embed personal data in the identifier (e.g.,
     do not use email addresses).

     Note: The -00 version used "did:jtel:" as a URI format.  This has
     been replaced with "jis:" to avoid confusion with the W3C DID
     specification [DID-CORE].  A W3C DID method specification for JIS
     identities may be developed separately if there is implementation
     demand.

  3.5.  Key Lifecycle

     Key Rotation:  DID keys SHOULD be rotated periodically.  The rotation
        event MUST be recorded as a TIBET token linking the old and new
        key.  The new key MUST be introduced via a FIR/A re-establishment
        signed with the old key.

     Key Revocation:  A compromised key MUST be revoked by publishing a
        signed revocation notice.  Tokens signed with a revoked key after
        the revocation timestamp SHOULD be treated as suspect.  The
        revocation mechanism is defined by the deployment context.

     HID Replacement:  HID replacement (e.g., new device) requires in-
        person or high-assurance verification.  The new HID-DID binding
        MUST reference the previous binding in its TIBET token.

  4.  Trust Establishment (FIR/A)

  4.1.  Overview

     FIR/A (First Initiation Revoke/Accept) is a four-phase handshake that
     establishes a bilateral trust relationship.  Unlike TLS or OAuth,
     FIR/A is not just authentication -- it is intent negotiation.  Both
     parties declare what they want, agree on what they can do, and create
     a cryptographic genesis record that anchors all subsequent
     interactions.

  4.2.  Phase 1: INITIATE

     The initiator sends a trust establishment request:






  van de Meent & AI       Expires 30 September 2026               [Page 8]


  Internet-Draft                     JIS                        March 2026


     {
       "type": "fira_init",
       "version": "1.1",
       "initiator": "jis:service:bank_fraud",
       "responder": "jis:human:alice",
       "did_public_key": "<base64 Ed25519 public key>",
       "intent": "fraud_verification_call",
       "humotica": {
         "sense": "Transaction flagged by fraud detection",
         "context": "EUR 5000 transfer to unrecognized recipient",
         "intent": "Verify transaction legitimacy with account holder",
         "explanation": "Automated fraud detection on
                         unusual transfer pattern."
       },
       "timestamp": "2026-03-29T10:30:00.000Z",
       "nonce": "<random 32 bytes, base64>"
     }

     Required fields: type, version, initiator, responder, did_public_key,
     intent, humotica, timestamp, nonce.

     The nonce MUST be cryptographically random and MUST NOT be reused.
     It provides replay protection.

  4.3.  Phase 2: CAPABILITIES

     The responder evaluates the initiation request and returns available
     capabilities and rules:

     {
       "type": "fira_capabilities",
       "fira_id": "fira-2026-03-29-bank-alice-7f3a",
       "responder": "jis:human:alice",
       "did_public_key": "<base64 Ed25519 public key>",
       "hid_did_binding": "sha256:4f2e8a...",
       "capabilities": ["voice_call", "sms_verification"],
       "rules": {
         "no_calls_after": "22:00",
         "require_caller_id": true,
         "max_attempts": 3,
         "language": "nl"
       },
       "timestamp": "2026-03-29T10:30:01.000Z",
       "init_nonce": "<echo of initiator nonce>",
       "nonce": "<responder random 32 bytes, base64>"
     }





  van de Meent & AI       Expires 30 September 2026               [Page 9]


  Internet-Draft                     JIS                        March 2026


     The fira_id is generated by the responder and uniquely identifies
     this trust establishment session.

     The init_nonce field echoes the initiator's nonce, proving the
     response is to this specific initiation (not a replay).

  4.4.  Phase 3: CONFIRM

     The initiator accepts the capabilities and confirms the trust
     relationship:

     {
       "type": "fira_confirm",
       "fira_id": "fira-2026-03-29-bank-alice-7f3a",
       "accepted_capabilities": ["voice_call"],
       "genesis_hash": "sha256:7f3a...c2e1",
       "resp_nonce": "<echo of responder nonce>",
       "signature": {
         "algorithm": "Ed25519",
         "value": "<base64 signature over canonical confirm>"
       }
     }

     The genesis_hash is computed as:

     genesis_hash = SHA-256(
       canonical(fira_init) || canonical(fira_capabilities)
     )

     This binds the trust relationship to the specific messages exchanged.
     Both parties can independently verify the genesis.

  4.5.  Phase 4: EXECUTE

     After confirmation, both parties have:

     *  Each other's DID public keys

     *  Agreed-upon capabilities

     *  A shared genesis_hash anchoring the relationship

     *  A fira_id for referencing the trust context

     All subsequent interactions SHOULD reference the fira_id and SHOULD
     produce TIBET tokens linked to the genesis.





  van de Meent & AI       Expires 30 September 2026              [Page 10]


  Internet-Draft                     JIS                        March 2026


  4.6.  Trust Score Model

     FIR/A produces an initial trust score based on the establishment
     process.  The score is between 0.0 and 1.0:

     0.8 - 1.0: HIGH  Full capabilities, minimal verification

     0.5 - 0.8: MODERATE  Standard verification at each step

     0.2 - 0.5: LOW  Enhanced verification, limited capabilities

     0.0 - 0.2: MINIMAL  Most capabilities restricted

     Trust scores are LOCAL.  Each party computes its own score for the
     counterparty.  Scores are evidence, not assertions.  Publishing a
     trust score does not obligate other parties to accept it.

     Trust scores adjust over time based on:

     *  Consistency of behavior with stated intent

     *  Quality of Humotica context provided

     *  Chain integrity of associated TIBET tokens

     *  Duration and depth of interaction history

     The exact scoring algorithm is a local policy decision.  This
     document defines the score range and inputs, not the formula.

  4.7.  Failure Conditions

     FIR/A establishment MUST fail (and produce evidence) when:

     1.  NONCE_MISMATCH: Echoed nonce does not match sent nonce.
         Indicates replay or man-in-the-middle.

     2.  HUMOTICA_MISSING: Initiation lacks required Humotica context
         (Section 5.2).

     3.  NO_COMMON_CAPABILITY: No overlap between offered and requested
         capabilities.

     4.  SIGNATURE_INVALID: Confirm signature does not verify.

     5.  TIMEOUT: Response not received within configured window
         (RECOMMENDED default: 30 seconds).




  van de Meent & AI       Expires 30 September 2026              [Page 11]


  Internet-Draft                     JIS                        March 2026


     Each failure MUST be recorded as a TIBET token with ERACHTER
     explaining the failure reason.

  5.  Context Layer (Humotica)

  5.1.  Structure

     Humotica provides human-readable context for every interaction.  The
     name reflects its focus on empathetic, human-understandable
     communication.

     {
       "humotica": {
         "sense": "What triggered this interaction?",
         "context": "What is the current situation?",
         "intent": "What does the actor want to achieve?",
         "explanation": "Why is this action being taken?"
       }
     }

     Fields:

     "sense" (string)  The trigger or stimulus.  What event, observation,
        or signal initiated this interaction.

     "context" (string)  The current situation.  Environmental state,
        history, and relevant circumstances.

     "intent" (string)  The declared goal.  What the actor wants to
        accomplish.

     "explanation" (string)  The reasoning.  Why this particular action is
        being taken to achieve the intent.

  5.2.  Minimum Required Context

     For FIR/A establishment, the Humotica object MUST contain all four
     fields.  Each field MUST be a non-empty string with at least 10
     characters.

     For ongoing interactions within an established FIR/A session,
     Humotica is RECOMMENDED but not required for every message.  When
     provided, all four fields MUST be present.

  5.3.  Semantic Validation

     Implementations MAY perform semantic validation on Humotica context:




  van de Meent & AI       Expires 30 September 2026              [Page 12]


  Internet-Draft                     JIS                        March 2026


     *  Coherence check: Does the explanation logically support the
        intent?

     *  Completeness check: Are all four fields substantive (not
        placeholder text)?

     *  Consistency check: Does the declared intent match the actual
        requested action?

     Semantic validation results are EVIDENCE.  They inform trust scoring
     and risk assessment.  They SHOULD NOT be used as binary access
     control (evidence over enforcement).

     Note: The -00 version stated that malware "cannot provide legitimate
     Humotica context."  This is an overstatement.  A sufficiently
     sophisticated adversary can craft plausible context.  Semantic
     validation raises the bar for attackers but is not an absolute
     defense.  Defense in depth, combining Humotica with behavioral
     analysis (RVP [RVP]) and chain integrity (TIBET [TIBET]), provides
     stronger assurance.

  5.4.  Mapping to TIBET Components

     Humotica fields map to TIBET provenance components:

     +---------------------+-------------------+
     | Humotica Field      | TIBET Component   |
     +---------------------+-------------------+
     | sense               | ERIN (trigger)    |
     | context             | EROMHEEN          |
     | intent              | ERIN (intent)     |
     | explanation         | ERACHTER          |
     +---------------------+-------------------+

     When a JIS interaction produces a TIBET token, the Humotica fields
     SHOULD be distributed across the TIBET components per this mapping.

  6.  Intent Validation

  6.1.  Validation as Evidence

     JIS defines intent validation as an evidence-producing mechanism, not
     an enforcement mechanism.  When an intent is evaluated, the result is
     recorded as evidence in a TIBET token.  Whether the action proceeds,
     is blocked, or requires additional verification is a local policy
     decision.





  van de Meent & AI       Expires 30 September 2026              [Page 13]


  Internet-Draft                     JIS                        March 2026


  6.2.  Blocked Intent Patterns

     Implementations SHOULD maintain a configurable list of intent
     patterns that are flagged for enhanced scrutiny.  Examples:

     "sql_injection"  No legitimate Humotica explanation for injecting SQL
        into input fields.

     "command_injection"  No legitimate Humotica explanation for injecting
        shell commands.

     "unauthorized_resource_access"  Accessing resources not covered by
        established capabilities.

     Flagged intents SHOULD trigger enhanced verification (NIR,
     Section 6.4), not silent blocking.  The decision to block is a policy
     choice, not a protocol requirement.

  6.3.  Risk Scoring (BALANS)

     BALANS provides multi-factor risk scoring from 0.0 to 1.0.

     Input factors:

     "complexity"  Higher complexity operations receive lower scores.

     "humotica_quality"  Vague or short explanations reduce score.

     "trust_history"  New or untrusted actors receive lower scores.

     "transaction_value"  High-value operations reduce score.

     "temporal_anomaly"  Actions at unusual times reduce score.

     The BALANS score is evidence attached to the interaction's TIBET
     token in EROMHEEN.  It does not directly determine access.

     Suggested thresholds (local policy):

     *  score >= 0.5: Normal processing

     *  0.3 <= score < 0.5: Trigger NIR dialogue

     *  score < 0.3: Flag for human review







  van de Meent & AI       Expires 30 September 2026              [Page 14]


  Internet-Draft                     JIS                        March 2026


  6.4.  Dialogue Resolution (NIR)

     NIR (Notify, Identify, Rectify) is a structured dialogue for
     resolving ambiguous situations instead of silent blocking.

     1.  NOTIFY: Inform the actor that additional verification is needed.
         Include the reason in human-readable form.  Example: "This
         transaction was flagged because it exceeds your usual transfer
         amount."

     2.  IDENTIFY: Request additional identity evidence.  This may be a
         biometric check (RVP [RVP]), a second-factor confirmation, or a
         human-readable explanation.

     3.  RECTIFY: Based on the additional evidence, either proceed (with
         enhanced logging) or halt (with full evidence record).

     NIR produces TIBET tokens at each step, creating an audit trail of
     the dialogue itself.

  7.  TIBET Integration

  7.1.  Identity as TIBET Precondition

     The fundamental coupling between JIS and TIBET is:

     Traditional:  [Auth] -> [Action] -> [Log]
     JIS/TIBET:    [Identity + Intent] -> [Validate] -> [Action + Audit]

     In the JIS/TIBET model, the audit record is not a side effect of the
     action.  The identity and intent declaration (JIS) together with the
     evidence record (TIBET) are architecturally intertwined with the
     action itself.

  7.2.  FIR/A Events as TIBET Tokens

     Each phase of FIR/A produces a TIBET token:

     *  INITIATE produces a TIBET token (type: "action", ERIN: initiation
        details, ERACHTER: why trust is being established)

     *  CAPABILITIES produces a child TIBET token

     *  CONFIRM produces a child TIBET token with genesis_hash in ERAAN

     *  EXECUTE produces child TIBET tokens for each subsequent action





  van de Meent & AI       Expires 30 September 2026              [Page 15]


  Internet-Draft                     JIS                        March 2026


     The FIR/A genesis_hash is stored in the CONFIRM token's ERAAN,
     linking the trust relationship to the provenance chain.

  7.3.  Continuity Chain Delegation

     The -00 version defined a separate "Continuity Chain" with HMAC
     linking.  In -01, this is simplified: the TIBET chain IS the
     continuity chain.  TIBET's hash-chained, signed tokens provide the
     same tamper-evidence guarantees as the -00 Continuity Chain, without
     duplicating the mechanism.

     Implementations that require HMAC-based chain integrity (e.g., for
     backward compatibility) MAY implement it as an additional layer, but
     it is not a JIS protocol requirement.

  8.  Transport Considerations

  8.1.  Baseline: JSON over HTTPS

     For interoperability, FIR/A messages and JIS-annotated interactions
     MUST be supported as JSON objects over HTTPS.  This is the baseline
     binding.

     Content-Type: application/jis+json

  8.2.  Alternative Bindings

     JIS operates over any transport:

     +-------------+--------------------------------------+
     | Protocol    | Binding Method                       |
     +-------------+--------------------------------------+
     | HTTP/REST   | Request body or query parameters     |
     | WebSocket   | JSON message fields                  |
     | MQTT        | Topic prefix + payload               |
     | SIP         | Message body (application/jis+json)  |
     | Matrix      | Event content fields                 |
     | CoAP        | Payload option                       |
     | gRPC        | Metadata fields                      |
     +-------------+--------------------------------------+

     The binding method determines how JIS messages are carried.  The JIS
     message format is the same regardless of transport.

  9.  Privacy Considerations






  van de Meent & AI       Expires 30 September 2026              [Page 16]


  Internet-Draft                     JIS                        March 2026


  9.1.  HID Protection

     The HID (Human Identity Key) is the most sensitive element in JIS.
     Its protection is a core protocol requirement:

     *  HID private key MUST NEVER leave the device

     *  HID public key SHOULD NOT be transmitted (only the HID-DID binding
        hash is shared)

     *  Compromising the DID does NOT compromise the HID

     *  Multiple devices for the same human use separate HID-DID bindings,
        preventing cross-device correlation by external parties

  9.2.  Pseudonymous Operation

     JIS supports pseudonymous operation.  An actor MAY use a pseudonymous
     identifier (e.g., "jis:human:anon_session_7f3a") when privacy
     requirements prevent identity disclosure.  In pseudonymous mode:

     *  FIR/A still produces a genesis record

     *  Trust scoring starts from zero

     *  TIBET tokens are still signed (proving session consistency)

     *  Humotica context is still required

  9.3.  Data Minimization

     Humotica context MAY contain sensitive information.  Implementations
     MUST:

     *  Support encryption at rest for stored JIS data

     *  Support field-level encryption for Humotica components

     *  Not retain Humotica context longer than the applicable retention
        period

     *  Support deletion of JIS data upon request, subject to regulatory
        retention requirements such as the [GDPR] right to erasure and the
        [EU-AI-ACT] traceability obligations







  van de Meent & AI       Expires 30 September 2026              [Page 17]


  Internet-Draft                     JIS                        March 2026


  10.  Security Considerations

  10.1.  Identity Protection

     Attack: An adversary compromises a device and obtains the DID private
     key.

     Impact: The adversary can impersonate the device.

     Mitigation: HID is separate from DID.  Compromising DID does not give
     the adversary the HID private key or the ability to create valid HID-
     DID bindings.  The adversary cannot prove human association.

     Deployment: Store DID private keys in hardware secure elements when
     available.  Implement key rotation schedules.  Record rotation events
     as TIBET tokens.

  10.2.  Semantic Validation Limitations

     Attack: An adversary crafts plausible Humotica context for malicious
     actions.

     Impact: The malicious action passes semantic validation.

     Mitigation: Semantic validation is one layer of defense, not
     absolute.  It raises the cost of attack by requiring contextually
     appropriate explanations.  Combined with behavioral analysis (RVP
     [RVP]) and chain integrity (TIBET [TIBET]), the overall detection
     capability is significantly stronger than any single mechanism.

     Deployment: Do not rely on semantic validation alone.  Implement
     defense in depth.  Use BALANS scores as risk signals, not binary
     gates.

  10.3.  FIR/A Handshake Attacks

     Attack: Man-in-the-middle during FIR/A establishment.

     Impact: Adversary establishes trust with both parties while
     intercepting communications.

     Mitigation: FIR/A uses nonce exchange and signed confirmations.  The
     genesis_hash binds the trust relationship to the specific messages
     exchanged.  A MITM who modifies messages produces a different
     genesis_hash, detectable by either party.

     Deployment: Implementations SHOULD use TLS for transport security.
     The FIR/A handshake provides additional application-layer protection.



  van de Meent & AI       Expires 30 September 2026              [Page 18]


  Internet-Draft                     JIS                        March 2026


  10.4.  Key Compromise and Rotation

     Attack: An actor's DID signing key is compromised.

     Impact: Adversary can create tokens and FIR/A sessions impersonating
     the compromised actor.

     Mitigation: Key rotation is supported (Section 3.5).  Upon compromise
     detection, the actor publishes a revocation record and establishes
     new keys.  Verifiers check revocation status.

     Deployment: Implement automated key rotation on a schedule
     appropriate to the threat model.  Monitor for concurrent usage of the
     same DID from different network locations.

  10.5.  Replay Protection

     Attack: An adversary replays a valid FIR/A initiation.

     Impact: Trust relationship established with stale context.

     Mitigation: FIR/A messages include cryptographic nonces and
     timestamps.  Each phase echoes the previous phase's nonce.  Replayed
     messages will contain stale nonces and timestamps.

     Deployment: Implementations MUST reject FIR/A messages with
     timestamps outside a configurable window (RECOMMENDED: 30 seconds).
     Implementations SHOULD maintain a nonce cache to detect exact
     replays.

  10.6.  Trust Score Manipulation

     Attack: An actor inflates their trust score by generating many low-
     value interactions.

     Impact: Artificially high trust enables access to sensitive
     capabilities.

     Mitigation: Trust scores are computed locally by each party.  The
     scoring algorithm considers interaction quality (Humotica depth,
     action significance), not just quantity.  This is defined as local
     policy.

     Deployment: Weight interaction significance in scoring.  Do not
     assign equal trust value to all interactions.  Implement diminishing
     returns for high-frequency, low-value interactions.





  van de Meent & AI       Expires 30 September 2026              [Page 19]


  Internet-Draft                     JIS                        March 2026


  11.  IANA Considerations

  11.1.  Media Type Registration

     This document requests registration of the following media type:

     Type name:  application

     Subtype name:  jis+json

     Required parameters:  none

     Optional parameters:  none

     Encoding considerations:  binary (UTF-8 JSON)

     Security considerations:  See Section 10

     Published specification:  this document

     Note: The -00 version requested registration of X-JIS-* HTTP headers
     and a "did:jtel" URI scheme.  Both are withdrawn.  HTTP header
     registration is not justified at this stage.  The identifier format
     "jis:" is used as a local convention, not as a registered URI scheme.

  12.  References

  12.1.  Normative References

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

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

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

     [FIPS180-4]
                National Institute of Standards and Technology (NIST),
                "Secure Hash Standard (SHS)", FIPS PUB 180-4, August 2015,
                <https://csrc.nist.gov/publications/detail/fips/180/4/
                final>.



  van de Meent & AI       Expires 30 September 2026              [Page 20]


  Internet-Draft                     JIS                        March 2026


  12.2.  Informative References

     [TIBET]    van de Meent, J. and R. AI, "TIBET: Transaction/
                Interaction-Based Evidence Trail", Work in Progress,
                Internet-Draft, draft-vandemeent-tibet-provenance-01,
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                vandemeent-tibet-provenance-01>.

     [UPIP]     van de Meent, J. and R. AI, "UPIP: Universal Process
                Integrity Protocol", Work in Progress, Internet-Draft,
                draft-vandemeent-upip-process-integrity-01, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-vandemeent-
                upip-process-integrity-01>.

     [RVP]      van de Meent, J. and R. AI, "RVP: Real-time Verification
                Protocol", Work in Progress, Internet-Draft, draft-
                vandemeent-rvp-continuous-verification-01, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-vandemeent-
                rvp-continuous-verification-01>.

     [AINS]     van de Meent, J. and R. AI, "AINS: AInternet Name
                Service", Work in Progress, Internet-Draft, draft-
                vandemeent-ains-discovery-01, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-vandemeent-
                ains-discovery-01>.

     [DID-CORE] Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
                O., and C. Allen, "Decentralized Identifiers (DIDs) v1.0",
                W3C Recommendation, July 2022,
                <https://www.w3.org/TR/did-core/>.

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

     [GDPR]     European Parliament, "Regulation (EU) 2016/679 on the
                protection of natural persons with regard to the
                processing of personal data (General Data Protection
                Regulation)", Regulation (EU) 2016/679, April 2016.

     [ZENODO-JIS]
                van de Meent, J., "JIS: JTel Identity Standard v1.0",
                Zenodo DOI: 10.5281/zenodo.17759713, November 2025,
                <https://doi.org/10.5281/zenodo.17759713>.

  Appendix A.  Complete Flow Example




  van de Meent & AI       Expires 30 September 2026              [Page 21]


  Internet-Draft                     JIS                        March 2026


  A.1.  Bank Fraud Verification

     1.  Bank fraud system detects suspicious EUR 5000 transfer.

     2.  Bank initiates FIR/A:

     {
       "type": "fira_init",
       "version": "1.1",
       "initiator": "jis:service:bank_fraud_dept",
       "responder": "jis:human:alice_2025",
       "did_public_key": "MCowBQYDK2VwAy...",
       "intent": "fraud_verification_call",
       "humotica": {
         "sense": "EUR 5000 flagged by anomaly detection",
         "context": "Transfer to unrecognized recipient,
                     first tx to this IBAN, outside
                     normal transfer pattern",
         "intent": "Verify with account holder whether
                     this transaction is authorized",
         "explanation": "Standard fraud prevention per
                         bank policy FP-2026-Q1 s3.2.
                         Customer contacted to confirm
                         before processing."
       },
       "timestamp": "2026-03-29T10:30:00.000Z",
       "nonce": "kH7mN2pQ..."
     }

     3.  Alice's device responds with capabilities:

     *  voice_call: Yes

     *  sms_verification: Yes

     *  Rules: no calls after 22:00, require caller ID

     4.  Bank confirms, genesis_hash computed:

     *  Genesis anchors all subsequent interaction tokens

     5.  Bank calls Alice.  Call proceeds with TIBET token per exchange.
     Each message in the call produces:

     *  ERIN: What was said/decided

     *  ERAAN: Reference to FIR/A genesis




  van de Meent & AI       Expires 30 September 2026              [Page 22]


  Internet-Draft                     JIS                        March 2026


     *  EROMHEEN: Call context (duration, connection quality)

     *  ERACHTER: Why this particular response

     6.  Outcome: Alice confirms transaction.  TIBET chain: fira_init,
     fira_caps, fira_confirm, call_start, verification_question,
     alice_confirms, call_end, transaction_released.

     Full audit trail: 8 tokens, complete chain, signed by both parties,
     every step with intent and context.

  Appendix B.  Conformance Levels

  B.1.  JIS Basic

     Minimum implementation:

     *  Actor identifier format (Section 3.4)

     *  FIR/A trust establishment (Section 4)

     *  TIBET token production for FIR/A events (Section 7.2)

  B.2.  JIS Extended

     Basic plus:

     *  Humotica context (Section 5)

     *  BALANS risk scoring (Section 6.3)

     *  NIR dialogue resolution (Section 6.4)

  B.3.  JIS Full

     Extended plus:

     *  HID-DID binding (Section 3.3)

     *  Key lifecycle management (Section 3.5)

     *  RVP integration for continuous verification

     *  AINS registration for discoverability







  van de Meent & AI       Expires 30 September 2026              [Page 23]


  Internet-Draft                     JIS                        March 2026


  Appendix C.  Changes from -00

     This section lists substantive changes from draft-vandemeent-jis-
     identity-00, which was derived from the JIS v1.0 specification
     [ZENODO-JIS]:

     1.   Added RFC 8174 alongside RFC 2119 in Terminology.

     2.   Changed intended status from Standards Track to Informational.

     3.   Replaced "did:jtel:" identifier format with "jis:" to avoid W3C
          DID confusion.  A separate DID method spec may follow.

     4.   Removed absolute security claims.  "Impossible for malware to
          operate without legitimate context" is replaced with realistic
          assessment: semantic validation raises the bar but is not
          absolute.

     5.   Narrowed scope: audit trail is TIBET's concern (removed
          Continuity Chain as separate mechanism).  JIS focuses on
          identity, trust, and intent.

     6.   Added FIR/A nonce exchange for replay protection (Section 4.2,
          Section 4.3).

     7.   Added formal genesis_hash computation (Section 4.4).

     8.   Expanded Security Considerations from 5 paragraphs to 6
          structured subsections with attack/impact/mitigation/ deployment
          format.

     9.   Added Privacy Considerations section (Section 9).

     10.  Removed X-JIS-* HTTP header and "did:jtel" URI scheme from IANA
          Considerations.  Not justified at this stage.

     11.  Removed SNAFT as a named protocol primitive.  Intent validation
          is now described as an evidence mechanism (Section 6), not a
          "firewall."

     12.  Removed HICSS emergency halt.  Emergency stop is a deployment
          concern, not a protocol concern.

     13.  Normalized companion protocol references to [TIBET], [UPIP],
          [RVP], [AINS].

     14.  Added Humotica minimum requirements (Section 5.2).




  van de Meent & AI       Expires 30 September 2026              [Page 24]


  Internet-Draft                     JIS                        March 2026


     15.  Added Key Lifecycle section (Section 3.5).

  Acknowledgements

     The author thanks Codex (codex.aint) for the suite-wide cleanup
     analysis that informed this revision.

  Authors' Addresses

     Jasper van de Meent
     Humotica
     Den Dolder
     Netherlands
     Email: jasper@humotica.com
     URI:   https://humotica.com


     Root AI
     Humotica
     Email: root_ai@humotica.nl
     URI:   https://humotica.com






























  van de Meent & AI       Expires 30 September 2026              [Page 25]


name: draft-coetzee-oauth-spt-txn-tokens
rev: 01
title: Sovereign Policy Token Transactions (SPT-Txn)
time: 2026-04-27T22:47:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-29T22:47:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:47.115404+00:00
source: ietf
abstract:
  This document specifies the Sovereign Policy Token Transaction
     (SPT-Txn) Framework, a token-based architecture for policy-bound,
     tamper-evident authorization across trust boundaries in agentic and
     multi-organizational systems.  The framework extends IETF
     Transaction Tokens (RFC 9700) with Capability Acquisition Tokens
     (CATs)  --  cryptographically scoped authorization tokens that bind
     capability grants to specific transaction contexts, propagate
     human-origin identity commitments across delegation chains, and
     support offline verification without issuer interaction.

     SPT-Txn addresses the gap between coarse-grained bearer token
     authorization and the fine-grained, auditable, scope-limited
     authorization required in regulated financial infrastructure, AI
     agent systems, and cross-organizational transaction chains.  The
     framework provides cryptographic guarantees that every hop in a
     transaction chain was authorized by a verified human principal,
     operated within a declared capability scope, and can be audited
     without exposing personally identifiable information.

full_text:
  Internet-Draft            SPT-Txn Tokens                   April 2026


  Network Working Group                                       R.J. Coetzee
  Internet-Draft                               Violet Sky Security SEZC
  Intended status: Informational                            April 27, 2026
  Expires: October 27, 2026


          Sovereign Policy Token Transactions (SPT-Txn)
              draft-coetzee-oauth-spt-txn-tokens-01

  Abstract

     This document specifies the Sovereign Policy Token Transaction
     (SPT-Txn) Framework, a token-based architecture for policy-bound,
     tamper-evident authorization across trust boundaries in agentic and
     multi-organizational systems.  The framework extends IETF
     Transaction Tokens (RFC 9700) with Capability Acquisition Tokens
     (CATs)  --  cryptographically scoped authorization tokens that bind
     capability grants to specific transaction contexts, propagate
     human-origin identity commitments across delegation chains, and
     support offline verification without issuer interaction.

     SPT-Txn addresses the gap between coarse-grained bearer token
     authorization and the fine-grained, auditable, scope-limited
     authorization required in regulated financial infrastructure, AI
     agent systems, and cross-organizational transaction chains.  The
     framework provides cryptographic guarantees that every hop in a
     transaction chain was authorized by a verified human principal,
     operated within a declared capability scope, and can be audited
     without exposing personally identifiable information.

  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 October 27, 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.


  Coetzee                   Expires October 27, 2026             [Page 1]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  Table of Contents

     1.  Introduction .................................................  1
       1.1.  Terminology ..............................................  4
       1.2.  Changes from -00 .........................................  5
       1.3.  Changes from -03 .........................................  5
     2.  Problem Statement ............................................  6
       2.1.  Limitations of Current Txn-Tokens ........................  6
       2.2.  Requirements .............................................  6
     3.  TBAC Capability Token Model ..................................  7
       3.1.  The ABAC-to-TBAC Boundary ................................  7
       3.2.  Capability Token Structure ...............................  7
       3.3.  Eight-Step Enforcement Engine ............................  8
       3.4.  Scope Invariants .........................................  9
       3.5.  Token Serialization Formats ..............................  9
     4.  SPT-Txn Token Structure ...................................... 10
       4.1.  Base Claims (Inherited) .................................. 10
       4.2.  SPT-Txn Extension Claims ................................. 10
     5.  ZK Circuit Specification ..................................... 11
       5.1.  Proof System ............................................. 11
       5.2.  Circuit 1: Attribute Proof ............................... 11
       5.3.  Circuit 2: Compliance Claim .............................. 12
       5.4.  Circuit 3: Biometric Commitment .......................... 12
     6.  Multi-Chain Trust Registry Model ............................. 13
       6.1.  Chain-Agnostic Trust Registry ............................ 13
       6.2.  Chain-Specific Deployment Notes .......................... 13
         6.2.1.  Ethereum / EVM-Compatible Chains ..................... 13
         6.2.2.  XDC Network .......................................... 13
         6.2.3.  Algorand ............................................. 13
         6.2.4.  Hedera Hashgraph ..................................... 13
     7.  Transaction Flow ............................................. 14
     8.  Security Considerations ...................................... 15
       8.1.  Capability Token Security ................................ 15
       8.2.  Delegation Chain Security ................................ 15
       8.3.  ZK Proof Security ........................................ 15
       8.4.  Trust Registry Security .................................. 15
     9.  Privacy Considerations ....................................... 16
       9.1.  Human Anchor Privacy ..................................... 16
       9.2.  Compliance Reference Privacy ............................. 16
       9.3.  Selective Disclosure ..................................... 16
       9.4.  Auditability vs. Privacy ................................. 16
       9.5.  GDPR Compliance .......................................... 16
       9.6.  Human Anchor Escrow ...................................... 16
         9.6.1.  Escrow Function and Position in the
                 Architecture ......................................... 16
         9.6.2.  Escrow Envelope Construction ......................... 17
         9.6.3.  Escrow Key Material Requirements ..................... 17
         9.6.4.  Threshold Authorization Requirements ................. 18
         9.6.5.  Deanonymization Request Interface .................... 19
         9.6.6.  Escrow Audit Log ..................................... 20
         9.6.7.  Escrow Key Lifecycle ................................. 20
         9.6.8.  Compromise and Recovery .............................. 21
         9.6.9.  Implementation Note (Non-Normative) .................. 22
     10.  Security Properties ......................................... 23
       10.1.  Signature Algorithm Requirements ........................ 23
       10.2.  Key Management .......................................... 23
       10.3.  Transport Security ...................................... 23
       10.4.  Replay Prevention ....................................... 23
       10.5.  Token Format Security Properties ........................ 23
       10.6.  ZK Proof System Security ................................ 23
       10.7.  Multi-Chain Trust Registry Integrity .................... 23
     11.  IANA Considerations ......................................... 24
     12.  References .................................................. 25
       12.1.  Normative References .................................... 25
       12.2.  Informative References .................................. 26
     Author's Address ................................................. 26

  Coetzee                   Expires October 27, 2026             [Page 2]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  1.  Introduction

     Authorization in distributed and agentic systems requires answering
     three questions with cryptographic certainty at every transaction
     hop:

        (a) Was this action authorized by a verified human principal?
        (b) Does the acting entity operate within an explicitly declared
            capability scope?
        (c) Can the full chain of authorization be audited without
            accessing personally identifiable information?

     Existing approaches cannot answer all three simultaneously.  Bearer
     tokens (OAuth 2.0 [RFC6749]) answer none of them at the
     cryptographic layer.  Transaction Tokens (RFC 9700) address workload
     identity propagation but not capability scoping or privacy-
     preserving human traceability.  Demonstrating Proof of Possession
     (DPoP, RFC 9449) binds tokens to a key pair but not to a
     transaction context or a human-origin commitment.

     The consequence is that when an AI agent or automated service takes
     an action that causes harm, the audit record is a log.  Logs are
     not proof.  They are mutable, selectively produced, and unavailable
     to external auditors without system access.  What regulated
     environments require is cryptographic proof of authorization scope
     at every hop  --  immutable, verifiable by any party holding the
     appropriate public key, and auditable without PII exposure.

     This document specifies the Sovereign Policy Token Transaction
     (SPT-Txn) Framework, which provides this capability through two
     coordinated mechanisms:

     Capability Acquisition Tokens (CATs):  Cryptographically signed
        authorization tokens issued by an Attribute-Based Access Control
        (ABAC) Policy Decision Point (PDP), binding a specific capability
        scope to a holder identity, transaction context, and delegation
        depth.  CTs are verifiable offline and cannot be used outside
        their declared scope.

     SPT-Txn Transaction Tokens:  An extension of IETF Transaction
        Tokens that adds CT references, scope hashes, human-origin
        commitments (humanAnchor), and compliance proof references to
        every hop in the transaction chain.  The chain is immutable and
        carries cryptographic evidence of its full authorization
        history.

     Together, these mechanisms enable regulated financial systems,
     AI agent orchestration platforms, and cross-organizational
     transaction chains to provide cryptographic proof that every action
     was authorized by a verified human, within declared scope, with
     a complete and auditable chain of custody  --  without exposing
     identity information to intermediate parties.

     The framework is designed for direct alignment with IETF standards.
     CTs are normatively serialized as JSON Web Tokens [RFC7519] with
     JSON Web Signatures [RFC7515].  SPT-Txn Transaction Tokens extend
     the base claims defined in RFC 9700.  The ZK proof system uses
     Groth16 over BN254, with circuit specifications at the
     normative level.  Trust registries are chain-agnostic and
     support Ethereum, XDC, Algorand, and Hedera deployments.


  Coetzee                   Expires October 27, 2026             [Page 3]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     The SPT-Txn Framework directly addresses the requirements of the EU
     AI Act Article 14 (human oversight of high-risk AI systems).  The
     humanAnchor claim provides cryptographic traceability to the
     authorizing human; CT scope provides bounded authorization that
     the AI system cannot exceed; the revocation mechanism provides the
     override capability Article 14 requires; and the HCS audit chain
     provides monitoring evidence without PII exposure.

     Formal cryptographic security definitions and proofs for the token
     binding security property are provided in the companion theory
     paper [SPT-THEORY].  The theory paper defines transaction binding
     security as a game-based security property and proves that the
     SPT-Txn construction achieves it under EUF-CMA assumptions in the
     random oracle model.

  1.1.  Terminology

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

     This document uses the following terms:

     Capability Acquisition Token (CAT):
        A signed token issued by an ABAC Policy Decision Point, binding
        a capability scope to a holder identity and transaction context.
        Normative serialization: JWT [RFC7519].  SD-JWT, Biscuit, and
        CWT are alternative formats (Section 3.5).

     Capability Token (CT):
        Synonym for Capability Acquisition Token.  Used interchangeably
        in this document.

     ABAC PDP:
        Attribute-Based Access Control Policy Decision Point.  The
        issuing authority for Capability Tokens.  Evaluates policy
        against subject attributes and issues scoped CTs.

     TBAC:
        Token-Based Access Control.  The enforcement model in which
        resource servers verify presented tokens rather than querying
        a central policy engine at each request.

     humanAnchor:
        A zero-knowledge commitment to the zkDID of the human principal
        who authorized the root transaction.  Propagated immutably
        through all delegation hops.  Enables human traceability
        without PII exposure.

     zkDID:
        A zero-knowledge Decentralized Identifier commitment that
        proves identity membership in a verified set without revealing
        the underlying identifier.

     delegation_depth:
        The remaining number of sub-delegation levels permitted from
        the current CT holder.  Decremented at each delegation.
        A CT with depth 0 MUST NOT issue further delegation CTs.

     Trust Registry:
        An on-chain smart contract registry that maps ABAC PDP
        identities to capability types they are authorized to certify.
        Used by resource servers to verify CT issuer authority without
        contacting the issuer.

     Transaction Token (Txn-Token):
        As defined in RFC 9700.  A short-lived signed token representing
        a workload's identity and context within a transaction chain.
        SPT-Txn extends the base Txn-Token claim set.

     SPT-Txn Token:
        An SPT-Txn-extended Transaction Token carrying the additional
        claims defined in Section 4.2.


  Coetzee                   Expires October 27, 2026             [Page 4]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  1.2.  Changes from -00

     The following changes were made in this revision:

     (a)  Section 9 (Privacy Considerations) reorganized into numbered
          subsections 9.1 through 9.5.  Text content of these subsections
          is unchanged from -00.

     (b)  New Sections 9.6.1 through 9.6.9 added, specifying Escrow
          Function and Position, Escrow Envelope Construction, Escrow Key
          Material Requirements, Threshold Authorization Requirements,
          Deanonymization Request Interface, Escrow Audit Log, Escrow Key
          Lifecycle, Compromise and Recovery, and a non-normative
          Implementation Note.

     (c)  No changes to wire format, token claims, enforcement engine, ZK
          circuits, or trust registry interfaces.

     (d)  No changes to IANA Considerations.


  1.3.  Changes from -03

     The following changes were made in this revision:

     (a) Section 1.1 (Terminology): CT definition updated from "signed
         JWT" to "signed token" with a normative note: "Normative
         serialization: JWT.  SD-JWT, Biscuit, and CWT are alternative
         formats (Section 3.5)."

     (b) Section 3.2: Added "normatively" qualifier to the CT
         serialization statement.

     (c) Section 3.3 Step 1: Signature verification now specifies
         JWS for JWT/SD-JWT, public-key block verification for
         Biscuit, and COSE verification for CWT.

     (d) Section 3.5 (new): Token Serialization Formats.  Full section
         with RFC 2119 normative language covering SD-JWT selective
         disclosure and data minimisation, Biscuit cryptographic
         attenuation with Ed25519 and Datalog, CWT for high-throughput
         agent-to-agent, and format selection criteria.

     (e) Section 6.2.4: Hedera Hashgraph section numbering corrected
         (was duplicate 6.2.3 in -03).

     (f) Section 10.5 (new): Token Format Security Properties.
         Ed25519 and COSE alongside ECDSA; post-quantum vulnerability
         note; Biscuit structural attenuation defence.  Existing
         Sections 10.5 and 10.6 renumbered to 10.6 and 10.7.

     (g) References: Added SD-JWT [I-D.ietf-oauth-selective-disclosure-
         jwt], RFC 8392 (CWT), and Biscuit [BISCUIT].  Updated SPT-WP
         reference from v3.0 to v6.0.


  Coetzee                   Expires October 27, 2026             [Page 5]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  2.  Problem Statement

  2.1.  Limitations of Current Txn-Tokens

     RFC 9700 Transaction Tokens solve the workload identity propagation
     problem: a downstream service can verify that a call originated
     from a known, authenticated workload rather than an arbitrary
     external caller.  This is a significant security improvement over
     bearer token architectures.

     However, RFC 9700 Txn-Tokens have four limitations that make them
     insufficient for regulated agentic systems:

     No capability scoping:  A Txn-Token proves that a workload made a
        call; it does not prove that the workload had authorization to
        make that specific call with that specific scope.  The workload's
        authorization is evaluated separately by a policy engine at
        each hop, creating a distributed policy evaluation problem in
        cross-organizational deployments.

     No human traceability:  Txn-Tokens propagate the "sub" claim
        identifying the originating user.  In cross-organizational
        chains, this propagates PII to every service in the chain,
        creating GDPR data minimization violations.  Alternatively,
        organizations strip the subject claim, losing human
        traceability entirely.

     No cross-organizational trust:  RFC 9700 assumes a shared
        authorization server within a single trust domain.  When a
        transaction crosses organizational boundaries, services in
        different organizations cannot verify each other's Txn-Tokens
        without a pre-established trust relationship at the
        authorization server level.

     No compliance propagation:  Regulated transactions require
        compliance attestations (KYC, AML, jurisdiction verification)
        at the root.  RFC 9700 provides no mechanism for propagating
        compliance evidence through the chain without re-verification
        at each hop.

  2.2.  Requirements

     The SPT-Txn Framework is designed to satisfy the following
     requirements:

     REQ-1:  A resource server MUST be able to verify that the
        presenting workload holds a valid capability grant from an
        authorized issuer, scoped to the requested operation, without
        contacting the issuing authority at request time.

     REQ-2:  The capability grant MUST be cryptographically bound to
        a specific transaction context such that it cannot be reused
        in a different transaction without detection.

     REQ-3:  Every hop in a transaction chain MUST carry a
        cryptographic commitment to the human principal who authorized
        the root transaction.  This commitment MUST NOT reveal the
        human's identity to intermediate services.

     REQ-4:  Capability scope MUST be monotonically non-increasing
        through the delegation chain.  No delegatee MAY hold greater
        capability than its delegator.

     REQ-5:  The maximum delegation depth MUST be set at root
        issuance and enforced cryptographically at each delegation
        step.

     REQ-6:  Resource servers in different organizations MUST be
        able to verify capability grants issued by issuers in other
        organizations using a shared trust registry, without bilateral
        pre-configuration.

     REQ-7:  Compliance attestations established at transaction root
        MUST be propagatable to downstream services by reference,
        without re-exposing the underlying compliance data.

     REQ-8:  The complete authorization chain MUST be auditable by
        an authorized auditor without requiring access to PII.


  Coetzee                   Expires October 27, 2026             [Page 6]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  3.  TBAC Capability Token Model

  3.1.  The ABAC-to-TBAC Boundary

     The SPT-Txn Framework operates at the boundary between
     Attribute-Based Access Control (ABAC) and Token-Based Access
     Control (TBAC).

     ABAC evaluation is expensive: it requires policy retrieval,
     attribute collection, and real-time evaluation at each access
     decision.  In high-throughput transaction chains, ABAC evaluation
     at every hop introduces unacceptable latency and creates
     availability dependencies on the ABAC Policy Decision Point.

     The SPT-Txn approach performs ABAC evaluation once, at the
     transaction root, and materializes the result as a Capability
     Token  --  a signed, scope-limited, cryptographically verifiable
     authorization artifact.  Downstream enforcement is TBAC: verify
     the token, check the scope, make the decision.  No policy engine
     call required.

     This boundary is the fundamental architectural claim of SPT-Txn:
     ABAC at the root, TBAC at every subsequent hop.

  3.2.  Capability Token Structure

     A Capability Token (CT) is normatively a JSON Web Token [RFC7519]
     signed with JSON Web Signature [RFC7515].  Alternative
     serialization formats are specified in Section 3.5.

     CTs MUST contain the following claims:

     iss:  The DID or HTTPS identifier of the ABAC PDP that issued
        this CT.  REQUIRED.

     sub:  The identity of the CT holder.  SHOULD be a workload
        identity (SPIFFE SVID, DID, or equivalent).  REQUIRED.

     iat:  Issued-at time.  REQUIRED.

     exp:  Expiry time.  REQUIRED.  CTs MUST have a finite lifetime.

     jti:  JWT ID.  A unique identifier for this specific CT.
        REQUIRED.  Used for revocation registry lookups.

     ct_type:  The capability type granted.  MUST be a URI
        identifying the capability.  REQUIRED.

     ct_scope:  The capability scope granted.  A structured object
        defining the specific operations, resources, and constraints
        permitted.  REQUIRED.

     human_anchor:  A zero-knowledge commitment to the zkDID of the
        authorizing human principal.  REQUIRED for CTs in agentic
        chains.  Format: bytes32 (Poseidon hash of zkDID commitment).

     delegation_depth:  The remaining delegation depth permitted
        from this CT holder.  REQUIRED.  MUST be a non-negative
        integer.  A value of 0 means the holder MAY NOT issue
        further delegation CTs.

     max_depth:  The maximum delegation depth set at root issuance.
        REQUIRED.  MUST equal the delegation_depth of the root CT.

     parent_ct:  The hash of the parent CT in the delegation chain.
        REQUIRED for all non-root CTs.  OPTIONAL for root CTs.

     compliance_ref:  A hash reference to the ZK compliance proofs
        established at transaction root.  REQUIRED for regulated
        transaction contexts.  Format: bytes32.

     revocation_nonce:  A nonce included in the revocation registry
        commitment.  REQUIRED.


  Coetzee                   Expires October 27, 2026             [Page 7]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     Example Capability Token (decoded JWT payload):

        {
          "iss": "did:web:abac-pdp.example.org",
          "sub": "spiffe://org.example/workload/agent-a1",
          "iat": 1741017600,
          "exp": 1741021200,
          "jti": "ct-7f3a9b2c-4d1e-8f6a-b5c3-2e9d1a7b4f8e",
          "ct_type": "urn:example:capability:financial-transfer",
          "ct_scope": {
            "operations": ["transfer", "query"],
            "max_amount_usd": 50000,
            "currencies": ["USD", "EUR"],
            "jurisdictions": ["US", "EU"]
          },
          "human_anchor": "0x7f3a9b2c4d1e8f6ab5c32e9d1a7b4f8e...",
          "delegation_depth": 2,
          "max_depth": 3,
          "parent_ct": "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d...",
          "compliance_ref": "0x9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d...",
          "revocation_nonce": "0x3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f..."
        }

  3.3.  Eight-Step Enforcement Engine

     Resource servers MUST implement the following eight-step
     enforcement procedure when a CT is presented.  The enforcement
     engine is format-agnostic; format-specific parsing is handled
     by a token adapter layer (Section 3.5).

     Step 1: Token Signature Verification

        For JWT/SD-JWT:  Verify the JWS signature using the issuer's
           public key.  The issuer key MUST be retrieved from the
           Trust Registry (Section 6), not from a URL in the token.
        For Biscuit:  Verify the public-key block signature using
           the Ed25519 public key from the Trust Registry.
        For CWT:  Verify the COSE_Sign1 structure using the issuer's
           key from the Trust Registry.

        If signature verification fails, MUST reject with HTTP 401.

     Step 2: Issuer Trust Verification

        Retrieve the Trust Registry entry for ct.iss.  Verify that
        the issuer is authorized to certify capability type ct.ct_type.
        If the issuer is not listed for this capability type, MUST
        reject with HTTP 403.

     Step 3: Temporal Validity

        Verify ct.exp > now and ct.iat <= now.
        If either check fails, MUST reject with HTTP 401.

     Step 4: Revocation Check

        Query the revocation registry using ct.jti and
        ct.revocation_nonce.  If the CT appears in the revocation
        registry, MUST reject with HTTP 401.

     Step 5: Scope Verification

        Verify that the requested operation and parameters fall
        within ct.ct_scope.  Scope checking MUST be performed
        against the structured scope object, not a free-form string.
        If the operation is outside scope, MUST reject with HTTP 403.

     Step 6: Delegation Depth Verification

        If this CT was issued by delegation (parent_ct is present),
        verify that ct.delegation_depth < parent.delegation_depth
        and ct.max_depth == parent.max_depth.
        If either check fails, MUST reject with HTTP 403.

     Step 7: Human Anchor Verification

        Verify that ct.human_anchor is present and non-zero.
        Verify that ct.human_anchor matches the human_anchor claim
        in the SPT-Txn Transaction Token presented alongside the CT.
        If anchors do not match, MUST reject with HTTP 403.

     Step 8: Scope Hash Binding

        Compute hash(ct.ct_scope) and compare with the
        spt_ct_scope_hash claim in the accompanying SPT-Txn Token.
        If hashes do not match, MUST reject with HTTP 403.


  Coetzee                   Expires October 27, 2026             [Page 8]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  3.4.  Scope Invariants

     The following invariants MUST hold across the delegation chain.
     Implementations MUST enforce these at issuance time.

     Invariant 1 (Scope Monotonicity):
        For any CT_child delegated from CT_parent:
           ct_child.ct_scope is a subset of ct_parent.ct_scope

        No delegatee MAY hold a scope that is not a subset of its
        delegator's scope.  Scope extension through delegation is
        explicitly prohibited.

     Invariant 2 (Depth Monotonicity):
        For any CT_child delegated from CT_parent:
           ct_child.delegation_depth < ct_parent.delegation_depth
           ct_child.max_depth == ct_parent.max_depth

     Invariant 3 (Human Anchor Immutability):
        For any CT in a delegation chain rooted at CT_root:
           ct.human_anchor == ct_root.human_anchor

        The human anchor MUST NOT be modified at any delegation step.

     Invariant 4 (Compliance Reference Continuity):
        For any CT_child delegated from CT_parent:
           ct_child.compliance_ref == ct_parent.compliance_ref

        Compliance proofs established at root propagate by reference
        and MUST NOT be replaced or omitted at delegation steps.

  3.5.  Token Serialization Formats

     The TBAC enforcement engine (Section 3.3) operates through a
     format-agnostic verification interface.  Format-specific parsing
     is isolated behind a token adapter layer.  The eight enforcement
     steps operate identically regardless of serialization format.

  3.5.1.  Primary Format: JWT with Selective Disclosure (SD-JWT)

     JWT [RFC7519] is the normative CT serialization for cross-
     organizational interoperability.  All implementations MUST
     support JWT.

     SD-JWT [I-D.ietf-oauth-selective-disclosure-jwt] extends JWT
     with selective disclosure of individual claims.  Implementations
     SHOULD support SD-JWT where data minimization requirements apply.

     SD-JWT selective disclosure enables a CT holder to present only
     the subset of claims required by the verifying resource server,
     without revealing the full CT payload.  This is particularly
     relevant for the ct_scope claim, where a holder MAY disclose
     only the sub-scope relevant to the requested operation, while
     the issuer's binding covers the full scope.

     SD-JWT CTs MUST protect the following claims from selective
     omission (they MUST always be disclosed):
     iss, sub, iat, exp, jti, human_anchor, delegation_depth,
     max_depth, revocation_nonce.

     The ct_scope and compliance_ref claims MAY be selectively
     disclosed in SD-JWT presentations.

  3.5.2.  Alternative Format: Biscuit

     Biscuit [BISCUIT] is an append-only capability token format
     using Ed25519 signatures and Datalog for policy expression.
     Biscuit provides cryptographic attenuation: a holder can create
     a more restricted version of a token by appending a new
     block signed with a fresh key, without interaction with the
     original issuer.

     Implementations MAY support Biscuit where cryptographic
     attenuation without issuer interaction is required.  Biscuit's
     append-only structure enforces Invariant 1 (Scope Monotonicity)
     cryptographically at the format layer.

     When using Biscuit:
     - The root block MUST contain all REQUIRED CT claims as
       Datalog facts.
     - The human_anchor and delegation_depth MUST be in the
       root block and MUST NOT be modifiable by attenuation blocks.
     - The Trust Registry MUST list the Ed25519 public key of the
       root block issuer for the relevant capability type.
     - Step 1 of the enforcement engine MUST verify the root block
       signature using the Trust Registry key, and verify all
       attenuation block signatures form a valid chain.

  3.5.3.  Alternative Format: CWT (CBOR Web Token)

     CWT [RFC8392] provides the same semantic structure as JWT in
     CBOR encoding, with COSE [RFC9052] for signing.  CWT is
     RECOMMENDED for high-throughput agent-to-agent transaction
     contexts where binary encoding reduces token size and
     parsing overhead.

     When using CWT:
     - All REQUIRED CT claims MUST be present using their CBOR
       integer claim keys as defined in the IANA CBOR Web Token
       Claims Registry, or as defined in Section 11 for SPT-Txn-
       specific claims.
     - The COSE_Sign1 structure MUST be used for signing.
     - Step 1 of the enforcement engine MUST verify using COSE
       signature verification procedures [RFC9052].

  3.5.4.  Format Selection Criteria

     The following criteria SHOULD guide format selection:

     JWT/SD-JWT:  Cross-organizational deployments; human-readable
        debugging requirements; broad ecosystem library support;
        when GDPR data minimization is required (SD-JWT).

     Biscuit:  Deployments requiring cryptographic attenuation
        without issuer interaction; edge computing contexts; when
        Datalog policy expression is operationally preferred.

     CWT:  High-throughput agent-to-agent pipelines; IoT and
        constrained environments; when binary encoding provides
        measurable operational benefit.

     Implementations MUST NOT mix formats within a single delegation
     chain (e.g., a JWT root CT MUST NOT have a CWT child CT).
     The format is set at root issuance and MUST be consistent
     through the chain.


  Coetzee                   Expires October 27, 2026             [Page 9]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  4.  SPT-Txn Token Structure

  4.1.  Base Claims (Inherited)

     SPT-Txn Tokens inherit and MUST include all REQUIRED claims
     defined in RFC 9700 for Transaction Tokens:

     iss:  The authorization server that issued this token.
     iat:  Issued-at time.
     exp:  Expiry time.
     txn:  Transaction identifier from RFC 9700.
     sub:  The workload identity of the calling service at this hop.
     azp:  The authorized party (original requesting workload).
     rctx:  The request context as defined in RFC 9700.

  4.2.  SPT-Txn Extension Claims

     SPT-Txn Tokens MUST include the following additional claims:

     spt_ct_ref:  bytes32.  The SHA-256 hash of the Capability
        Token presented by the caller at this hop.  Binds the
        transaction token to the specific capability grant used.
        REQUIRED.

     spt_ct_scope_hash:  bytes32.  The SHA-256 hash of the
        ct_scope claim of the presented CT.  Used by the enforcement
        engine in Step 8 for scope binding verification.  REQUIRED.

     spt_human_anchor:  bytes32.  The humanAnchor value from the
        presented CT.  MUST equal ct.human_anchor.  Propagated
        immutably.  REQUIRED.

     spt_delegation_depth:  uint8.  The delegation_depth value
        from the presented CT at this hop.  REQUIRED.

     spt_compliance_ref:  bytes32.  The compliance_ref from the
        root CT.  MUST be identical at every hop.  REQUIRED for
        regulated transaction contexts.

     spt_parent_txn:  The jti of the parent SPT-Txn Token in
        the chain.  OPTIONAL for root tokens.  REQUIRED for all
        non-root tokens.

     Example SPT-Txn Token extension claims:

        {
          "spt_ct_ref":
            "0x7f3a9b2c4d1e8f6ab5c32e9d1a7b4f8e9c0d1e2f...",
          "spt_ct_scope_hash":
            "0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b...",
          "spt_human_anchor":
            "0x7f3a9b2c4d1e8f6ab5c32e9d1a7b4f8e9c0d1e2f...",
          "spt_delegation_depth": 2,
          "spt_compliance_ref":
            "0x9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b...",
          "spt_parent_txn": "ct-4a5b6c7d-8e9f-0a1b-2c3d-4e5f6a7b8c9d"
        }


  Coetzee                   Expires October 27, 2026            [Page 10]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  5.  ZK Circuit Specification

  5.1.  Proof System

     SPT-Txn uses Groth16 [GROTH16] over the BN254 pairing-friendly
     elliptic curve.  Proof generation is performed by the ABAC PDP
     at root transaction time.  Proof verification is performed by
     resource servers and auditors.

     The proof system provides:
     - Completeness: Valid witnesses always produce valid proofs.
     - Soundness: Invalid witnesses cannot produce valid proofs
       (computationally, under the BN254 discrete log assumption).
     - Zero-knowledge: Proofs reveal nothing about witnesses beyond
       the verified public inputs.

     Circuit parameters MUST be generated through a trusted setup
     ceremony.  The SPT-Txn reference implementation uses the
     Hermez ceremony outputs for BN254 [HERMEZ].

  5.2.  Circuit 1: Attribute Proof

     The Attribute Proof circuit proves that a principal holds
     specified attributes issued by a trusted issuer, without
     revealing which attributes or their values.

     Public inputs:
        attr_root:  Merkle root of the attribute set.
        issuer_pk:  Public key of the trusted attribute issuer.
        attr_type_commitment:  Commitment to the attribute type
           being proved.

     Private inputs (witness):
        attr_value:  The actual attribute value.
        attr_merkle_path:  Merkle path proving inclusion.
        issuer_signature:  Issuer's signature over the attribute.
        nullifier_key:  Holder's nullifier key.

     Outputs:
        nullifier:  Hash(nullifier_key, attr_root).  Prevents
           double-use of the same attribute proof.
        proof:  Groth16 proof of the above relation.

     The circuit proves:
        1. attr_value is included in the Merkle tree with
           root attr_root (via attr_merkle_path).
        2. issuer_signature is a valid signature over
           (attr_type, attr_value) under issuer_pk.
        3. nullifier == Hash(nullifier_key, attr_root).


  Coetzee                   Expires October 27, 2026            [Page 11]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  5.3.  Circuit 2: Compliance Claim

     The Compliance Claim circuit proves that a principal satisfies
     a compliance requirement (KYC, AML, jurisdiction) without
     revealing the underlying compliance data.

     Public inputs:
        compliance_type:  URI identifying the compliance requirement.
        compliance_issuer_pk:  Public key of the compliance certifier.
        jurisdiction_set_root:  Merkle root of permitted jurisdictions.
        timestamp_bound:  Maximum age of the compliance attestation.

     Private inputs (witness):
        compliance_credential:  The underlying compliance credential.
        issuer_signature:  Certifier's signature.
        jurisdiction_merkle_path:  Proof of jurisdiction inclusion.
        credential_timestamp:  Timestamp of the credential.

     Outputs:
        compliance_commitment:  Hash(compliance_credential,
           compliance_type).  Used as compliance_ref in CTs.
        proof:  Groth16 proof of the above relation.

     The circuit proves:
        1. compliance_credential is validly signed by
           compliance_issuer_pk.
        2. The jurisdiction in compliance_credential is included
           in the set with root jurisdiction_set_root.
        3. credential_timestamp > (now - timestamp_bound).
        4. compliance_commitment == Hash(compliance_credential,
           compliance_type).

  5.4.  Circuit 3: Biometric Commitment

     The Biometric Commitment circuit proves that a biometric
     measurement matches a committed template, producing a zkDID
     commitment without revealing the biometric data.

     Public inputs:
        template_commitment:  Pedersen commitment to the biometric
           template.
        liveness_proof_root:  Root of the liveness attestation tree.

     Private inputs (witness):
        biometric_measurement:  The raw biometric measurement.
        biometric_template:  The enrolled template.
        template_randomness:  Randomness in the commitment.
        liveness_attestation:  Signed liveness attestation.
        liveness_merkle_path:  Merkle path in attestation tree.

     Outputs:
        zkdid_commitment:  Poseidon(biometric_template,
           template_randomness).  This is the humanAnchor.
        proof:  Groth16 proof of the above relation.

     The circuit proves:
        1. biometric_measurement matches biometric_template
           within a defined distance threshold.
        2. template_commitment == Pedersen(biometric_template,
           template_randomness).
        3. liveness_attestation is valid and included in the
           liveness attestation tree.
        4. zkdid_commitment == Poseidon(biometric_template,
           template_randomness).


  Coetzee                   Expires October 27, 2026            [Page 12]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  6.  Multi-Chain Trust Registry Model

  6.1.  Chain-Agnostic Trust Registry

     The Trust Registry is an on-chain data store mapping issuer
     identities to the capability types they are authorized to
     certify.  It is the root of trust for Step 2 of the enforcement
     engine.

     Trust Registry entries MUST contain:

     issuer_id:  The DID or HTTPS identifier of the ABAC PDP.
     capability_types:  A list of capability type URIs the issuer
        is authorized to certify.
     issuer_pubkey:  The current public key of the issuer, used
        for CT signature verification.
     valid_from:  Unix timestamp from which this entry is valid.
     valid_until:  Unix timestamp at which this entry expires.
     status:  ACTIVE, SUSPENDED, or REVOKED.

     Trust Registry entries MUST be signed by a Trust Anchor  --  a
     higher-level authority that has authorized the issuer to
     operate for the specified capability types.  The Trust Anchor
     public key MUST be distributed out-of-band at deployment time.

     Resource servers MUST cache Trust Registry entries for
     performance.  Cache TTL SHOULD be configured based on the
     valid_until field minus a safety margin.  Implementations MUST
     treat expired Trust Registry entries as equivalent to revoked.

  6.2.  Chain-Specific Deployment Notes

  6.2.1.  Ethereum / EVM-Compatible Chains

     Trust Registry SHOULD be implemented as an upgradeable proxy
     smart contract using the EIP-1967 transparent proxy pattern.
     Access control for Trust Registry updates MUST use a
     multi-signature scheme with a minimum threshold of 3-of-5.

     Event logs (TrustRegistryEntry events) MUST be emitted for
     all Trust Registry updates to support auditability.

     Gas optimization: Trust Registry reads are view functions and
     consume no gas for read-only verification.

  6.2.2.  XDC Network

     XDC provides EVM compatibility with Delegated Proof of Stake
     consensus and native support for trade finance applications.
     Trust Registry deployment on XDC follows the same EVM
     contract specification as Section 6.2.1.

     XDC's 2-second block finality provides faster Trust Registry
     update propagation than Ethereum mainnet.  Implementations
     SHOULD use XDC for deployments with high Trust Registry
     update frequency.

  6.2.3.  Algorand

     Algorand's AVM (Algorand Virtual Machine) supports Trust
     Registry implementation as an Algorand Smart Contract (ASC1).
     State storage uses global state for Trust Registry entries.

     Algorand's 3.9-second block finality and immediate transaction
     finality (no confirmation delay) make it suitable for Trust
     Registry deployments requiring low-latency updates.

     Algorand Standard Assets (ASAs) MAY be used to represent
     Trust Registry authority grants in a transferable format.

  6.2.4.  Hedera Hashgraph

     Hedera Consensus Service (HCS) provides a tamper-evident,
     timestamped message log suitable for Trust Registry audit
     trails.  Trust Registry state SHOULD be maintained in
     Hedera Smart Contracts (compatible with Solidity/EVM), with
     all state-changing operations also submitted to an HCS topic
     for auditability.

     HCS provides:
     - Cryptographic proof of message ordering and timestamp.
     - Gossip-about-gossip consensus with Byzantine fault tolerance.
     - GDPR-compliant auditability (HCS messages are public but
       can reference encrypted off-chain data by hash).

     The HCS audit topic MUST record:
     - All Trust Registry entry additions and modifications.
     - All CT issuance events (by hash reference, not content).
     - All revocation events.


  Coetzee                   Expires October 27, 2026            [Page 13]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  7.  Transaction Flow

     The following illustrates a complete SPT-Txn transaction flow
     for a regulated financial agentic system.

     Step 1: Human Authentication and Root CT Issuance

        Human H presents to ABAC PDP:
          - ZK proof of biometric commitment (liveness attested)
          - ZK compliance proofs (KYC, AML, jurisdiction)

        ABAC PDP evaluates against Policy NFT and issues:

          CT_H: {
            iss: "did:web:abac-pdp.org-a.example",
            sub: H.zkDID,
            ct_type: "urn:example:capability:financial-transfer",
            ct_scope: { full authorized scope },
            human_anchor: H.zkDID_commitment,
            delegation_depth: 3,
            max_depth: 3,
            compliance_ref: hash(ZK_compliance_proofs)
          }

          Txn-Token-root: {
            (RFC 9700 base claims),
            spt_ct_ref: hash(CT_H),
            spt_ct_scope_hash: hash(CT_H.ct_scope),
            spt_human_anchor: H.zkDID_commitment,
            spt_delegation_depth: 3,
            spt_compliance_ref: hash(ZK_compliance_proofs)
          }

     Step 2: Human Delegates to AI Agent A1

        H requests a delegation CT for A1 from ABAC PDP:

          CT_A1: {
            sub: A1.workload_identity,
            human_anchor: H.zkDID_commitment,  <- unchanged
            ct_scope: { reduced_scope },       <- subset of CT_H
            delegation_depth: 2,               <- decremented
            parent_ct: hash(CT_H)
          }

        H provides A1 with CT_A1 and an updated Txn-Token
        identifying A1 as the next hop workload.

     Step 3: A1 Calls Service S1 (Organization B)

        A1 requests a delegation CT for S1:

          CT_S1: {
            sub: S1.workload_identity,
            human_anchor: H.zkDID_commitment,  <- unchanged
            ct_scope: { further_reduced_scope },
            delegation_depth: 1,
            parent_ct: hash(CT_A1)
          }

        A1 presents CT_S1 and SPT-Txn Token to S1.

     Step 4: S1 Verifies CT_S1 (Offline, No Issuer Contact)

        S1 runs the eight-step enforcement engine:
        (a) JWS signature valid per Trust Registry key for Org A.
        (b) Org A's ABAC PDP authorized for this capability type.
        (c) CT_S1.exp > now.
        (d) CT_S1.jti not in revocation registry.
        (e) Requested operation within CT_S1.ct_scope.
        (f) CT_S1.delegation_depth (1) < CT_A1.delegation_depth (2).
        (g) CT_S1.human_anchor == Txn-Token.spt_human_anchor.
        (h) hash(CT_S1.ct_scope) == Txn-Token.spt_ct_scope_hash.

        All checks pass.  S1 processes the request.
        No call to Org A's authorization server required.

     Step 5: S1 Calls S2 (Organization C)

        S1 requests a leaf CT for S2:

          CT_S2: {
            sub: S2.workload_identity,
            human_anchor: H.zkDID_commitment,
            ct_scope: { minimal_leaf_scope },
            delegation_depth: 0,  <- cannot delegate further
            parent_ct: hash(CT_S1)
          }

     Audit Trail (verifiable by any authorized auditor):

        Txn-Token chain: H -> A1 -> S1 -> S2
        Each hop: CT reference, scope hash, depth, compliance ref.
        Any party can verify: human authorized root, scope only
        reduced at each step, compliance claims valid from root,
        chain of custody intact.
        No PII revealed to intermediate parties or auditors.


  Coetzee                   Expires October 27, 2026            [Page 14]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  8.  Security Considerations

  8.1.  Capability Token Security

     CT Signature Verification:  All CT signatures MUST be verified
     against the issuer's public key retrieved from the Trust
     Registry.  Implementations MUST NOT accept issuer public keys
     embedded in the token itself or retrieved from a URL in the
     token.  This prevents key substitution attacks.

     CT Expiry:  CTs MUST have a finite exp claim.  Implementations
     MUST NOT accept CTs with exp in the past.  The recommended
     maximum CT lifetime is 1 hour for transactional CTs.  Long-
     lived CTs increase revocation exposure.

     JTI Uniqueness:  The jti claim MUST be globally unique across
     all CTs issued by a given issuer.  Implementations MUST reject
     CTs with a jti that has been seen before (replay prevention).

     CT Scope Precision:  CT scopes MUST be as narrow as possible
     while permitting the required operations.  Overly broad scopes
     reduce the security benefit of TBAC enforcement.  Issuers MUST
     validate scope requests against the requesting principal's
     ABAC policy before issuing.

  8.2.  Delegation Chain Security

     Scope Monotonicity Enforcement:  Issuers MUST verify Invariant 1
     (Section 3.4) before issuing delegation CTs.  Implementations
     MUST reject delegation requests where the requested scope is not
     a strict subset of the delegator's CT scope.

     Depth Enforcement:  Issuers MUST verify that the delegator's
     CT has delegation_depth > 0 before issuing a delegation CT.
     Implementations MUST set the delegatee's delegation_depth to
     delegator.delegation_depth - 1.

     Human Anchor Immutability:  Issuers MUST copy the human_anchor
     from the parent CT without modification.  Any CT presenting a
     human_anchor different from its parent MUST be rejected.

     Parent CT Validity:  Before issuing a delegation CT, the issuer
     MUST verify that the parent CT passes all eight enforcement steps
     (Section 3.3).  An issuer MUST NOT issue delegation CTs on behalf
     of an expired, revoked, or out-of-scope parent CT.

  8.3.  ZK Proof Security

     Trusted Setup:  The Groth16 proof system requires a trusted
     setup.  The toxic waste from the setup MUST be destroyed.
     Multi-party computation ceremonies SHOULD be used to distribute
     trust.  The reference implementation uses the Hermez ceremony.

     Proof Replay:  ZK proofs are publicly verifiable.  The nullifier
     mechanism in Circuit 1 MUST be used to prevent proof replay.
     Implementations MUST maintain a nullifier registry and reject
     proofs with previously seen nullifiers.

     Circuit Audit:  ZK circuits MUST be independently audited before
     production deployment.  The circuit specification in Section 5
     is normative; implementations MUST match the specified input/
     output structure exactly.

  8.4.  Trust Registry Security

     Registry Immutability:  Trust Registry updates MUST require
     multi-signature authorization.  Single-key control of the Trust
     Registry is a critical security risk.

     Registry Monitoring:  Implementations MUST monitor Trust Registry
     events for unexpected entry additions or modifications.  An
     unexpected Trust Registry update MAY indicate a key compromise
     at the Trust Anchor level.

     Entry Expiry:  Trust Registry entries MUST have a valid_until
     field.  Perpetual Trust Registry entries create long-term
     exposure if the associated issuer is later compromised.


  Coetzee                   Expires October 27, 2026            [Page 15]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  9.  Privacy Considerations

  9.1.  Human Anchor Privacy

     The humanAnchor is a zero-knowledge commitment to the authorizing
     human's zkDID.  It does not reveal the human's identity, biometric
     data, or any other PII to intermediate services.  Only the licensed
     issuer holding the escrow key can deanonymize the humanAnchor under
     lawful process.  The operational requirements of the escrow mechanism
     are specified in Section 9.6.

  9.2.  Compliance Reference Privacy

     The compliance_ref is a hash reference to ZK compliance proofs
     established at root.  The proofs themselves are not propagated in the
     transaction chain.  Resource servers verify that compliance_ref
     matches a known proof commitment; they do not receive or store the
     underlying compliance data.

  9.3.  Selective Disclosure

     When SD-JWT format (Section 3.5.1) is used, CT holders MAY limit
     claim disclosure to the specific claims required by the verifying
     resource server.  This reduces the PII surface per hop.  The set of
     claims that MUST always be disclosed is enumerated in Section 3.5.1.

  9.4.  Auditability vs. Privacy

     The SPT-Txn audit chain (Section 7) is designed to be auditable by
     authorized auditors without revealing PII.  The Txn-Token chain
     carries human_anchor (ZK commitment), spt_ct_ref (token hash), and
     spt_compliance_ref (proof hash) -- none of which reveal PII directly.
     Identity deanonymization requires invocation of the escrow mechanism
     specified in Section 9.6 and is subject to the lawful process
     requirements defined therein.

  9.5.  GDPR Compliance

     The humanAnchor mechanism is designed to satisfy GDPR Article 25
     (Data Protection by Design) and Article 5(1)(c) (Data Minimization).
     Intermediate services receive only cryptographic commitments, not
     personal data.  Implementations operating in EU jurisdictions SHOULD
     obtain legal review of their specific humanAnchor escrow arrangement
     against the requirements of Section 9.6 and applicable regional law.

  9.6.  Human Anchor Escrow

  9.6.1.  Escrow Function and Position in the Architecture

     The Human Anchor Escrow is the cryptographic and operational
     mechanism by which the holder of an authorized escrow capability,
     acting under lawful process, recovers the zkDID of a human principal
     from a humanAnchor commitment present in a Capability Token or
     SPT-Txn Token.


  Coetzee                   Expires October 27, 2026            [Page 16]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     The escrow is OUT OF BAND with respect to all token verification
     operations.  No step of the eight-step enforcement engine (Section
     3.3), no Capability Token issuance step, and no SPT-Txn Token
     issuance step interacts with the escrow.  The escrow is invoked
     solely in response to a Deanonymization Request (Section 9.6.5) and
     does not appear in the request-time critical path of any resource
     server.

     At root Capability Token issuance, the ABAC PDP MUST construct an
     Escrow Envelope binding the humanAnchor to material sufficient to
     recover the zkDID.  The Escrow Envelope MUST be retained by the ABAC
     PDP indexed by human_anchor.  The Escrow Envelope MUST NOT be
     transmitted in any token, included in any audit chain entry visible
     to non-escrow parties, or replicated to any party other than the ABAC
     PDP and (at the PDP's discretion) escrow custody backups under
     equivalent protection.

  9.6.2.  Escrow Envelope Construction

     The Escrow Envelope is an authenticated ciphertext encrypting the
     zkDID under the Escrow Public Key (Section 9.6.3).  The ABAC PDP MUST
     construct the envelope as follows:

        envelope = AuthEnc(K_escrow_pub, plaintext, AAD)

     where:

     - plaintext is the binary encoding of the zkDID concatenated with a
       unique nonce.

     - AAD is the binary concatenation of the humanAnchor, the issuer
       identifier (iss), and the issued-at timestamp (iat) of the root CT.

     - AuthEnc is an authenticated public-key encryption scheme satisfying
       IND-CCA2 against active adversaries, such as ECIES with
       HKDF-SHA-256 key derivation and AES-256-GCM, or equivalent.
       Implementations MUST NOT use unauthenticated or non-CCA-secure
       schemes.

     Implementations MUST verify that decryption of the envelope yields a
     plaintext whose first component, when committed via the Section 5.4
     circuit's commitment function, equals the humanAnchor in the AAD.
     This binding prevents an adversary in possession of an Escrow Private
     Key share threshold from substituting an envelope and obtaining a
     zkDID for a humanAnchor it did not authorize.

  9.6.3.  Escrow Key Material Requirements

     The Escrow Public Key is the public component of an asymmetric
     keypair used to construct Escrow Envelopes.  Implementations MUST
     satisfy the following requirements:


  Coetzee                   Expires October 27, 2026            [Page 17]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     ESC-1.  The Escrow Private Key MUST NOT exist in unsplit form on any
        single system at any time after generation, except transiently
        during distributed key generation if a non-DKG construction is
        used.

     ESC-2.  Implementations SHOULD use a Distributed Key Generation (DKG)
        protocol such that no single party ever observes the full Escrow
        Private Key.  Implementations using Shamir Secret Sharing of a
        centrally generated key MUST destroy the centrally generated key
        immediately after share distribution and MUST document the
        generation ceremony in the deployment policy (Section 9.6.7).

     ESC-3.  The Escrow Public Key MUST be published in the Trust Registry
        (Section 6) as a separate registry entry distinct from the ABAC
        PDP's CT signing key.  The entry MUST identify its purpose as
        escrow encryption and MUST NOT be accepted by resource servers for
        CT signature verification.

     ESC-4.  The Escrow keypair MUST use an algorithm whose security is
        not weaker than the CT signing algorithm requirements of Section
        10.1.  X25519 with HKDF-SHA-256 and AES-256-GCM is RECOMMENDED.
        P-256 with the equivalent ECIES construction is permitted.  RSA
        key transport MUST NOT be used.

     ESC-5.  Escrow keypair material MUST be stored in hardware security
        modules or equivalent tamper-resistant hardware on every escrow
        custodian's system.  Software-only escrow share storage MUST NOT
        be used in production deployments.

  9.6.4.  Threshold Authorization Requirements

     Decryption of an Escrow Envelope MUST require the cooperation of a
     quorum of Escrow Custodians.  Implementations MUST satisfy:

     THR-1.  The deployment MUST define a threshold (t, n) where n is the
        number of Escrow Custodians and t is the minimum number whose
        participation is required to decrypt an envelope.  Implementations
        MUST configure t such that t is greater than or equal to
        ceil((n+1)/2).  Deployments handling regulated financial
        transactions SHOULD configure t such that t is greater than or
        equal to ceil(2n/3).

     THR-2.  The threshold scheme MUST be implemented such that no proper
        subset of fewer than t custodians can produce a valid decryption,
        recover any portion of the Escrow Private Key, or recover any
        portion of the plaintext.  Schemes failing to provide threshold
        security against t-1 colluding custodians MUST NOT be used.

     THR-3.  Each individual Escrow Custodian MUST be a distinct legal
        entity with an independent operational, technical, and legal
        control surface.  Multiple custodians under common control of a
        single legal entity MUST NOT be counted as separate participants
        for threshold purposes.


  Coetzee                   Expires October 27, 2026            [Page 18]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     THR-4.  The deployment policy MUST document the identities of all
        Escrow Custodians, the threshold (t, n) in effect, and the legal
        basis under which each custodian operates.  The policy MUST be
        updated within thirty (30) days of any change to custodian
        composition.

     THR-5.  Threshold ElGamal, threshold ECIES, or equivalent threshold
        decryption protocols providing the property in THR-2 are
        RECOMMENDED.  Schemes that reconstruct the Escrow Private Key in a
        single location during decryption (including Shamir
        reconstruction) provide weaker security and SHOULD be avoided in
        deployments handling regulated transactions.

  9.6.5.  Deanonymization Request Interface

     A Deanonymization Request is the protocol-level invocation by which
     an authorized requestor initiates escrow decryption of a specific
     humanAnchor.  The request is processed by the ABAC PDP, which
     mediates between the requestor and the Escrow Custodians.  The
     request format MUST include:

     request_id:  A globally unique identifier for the request.

     target_human_anchor:  The humanAnchor whose deanonymization is
        requested.

     requestor_id:  The identifier of the requesting authority.

     lawful_basis_ref:  A reference (URI or hash) to the legal instrument
        authorizing the request (court order, regulatory production order,
        or equivalent).

     requestor_signature:  A signature over the preceding fields using a
        key listed in the Trust Registry as authorized for escrow request
        issuance, distinct from any key used for CT issuance or
        verification.

     The ABAC PDP MUST verify the requestor's signature against the Trust
     Registry, MUST verify that the signing key is currently authorized
     for escrow request issuance, MUST locate the Escrow Envelope
     corresponding to target_human_anchor, and MUST forward the envelope
     and the request metadata to the Escrow Custodians for threshold
     decryption.

     Each Escrow Custodian MUST independently evaluate the deanonymization
     request against its custodian policy before participating in
     decryption.  Custodian policy SHOULD include verification of the
     lawful basis reference, applicable jurisdictional review, and any
     internal authorization workflow.  Custodians MUST NOT be required by
     protocol to participate; threshold non-participation by custodians
     who determine the request is not authorized is the protocol's
     intended behavior, not a failure mode.


  Coetzee                   Expires October 27, 2026            [Page 19]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     If the threshold of participating custodians is reached, the
     resulting plaintext zkDID MUST be returned only to the requestor
     identified in requestor_id and MUST NOT be retained by the ABAC PDP
     after delivery.

     The protocol does not define what constitutes a valid
     lawful_basis_ref.  Determining the legal sufficiency of a request is
     a matter of jurisdictional law and custodian policy, not protocol
     specification.

  9.6.6.  Escrow Audit Log

     The ABAC PDP MUST maintain an Escrow Audit Log recording every
     Deanonymization Request received, regardless of whether the request
     resulted in successful decryption.  Each log entry MUST contain
     request_id, target_human_anchor, requestor_id, lawful_basis_ref, the
     request timestamp, the participating custodian set if decryption
     proceeded, and the outcome (decryption_completed, threshold_not_
     reached, request_rejected, or custodian_policy_failure).

     The Escrow Audit Log MUST NOT contain the decrypted zkDID or any
     portion thereof.

     The Escrow Audit Log MUST be append-only.  Each entry MUST be
     cryptographically chained to the previous entry such that any
     modification or deletion of historical entries is detectable.  The
     chained log root SHOULD be published periodically to the Trust
     Registry chain (Section 6) or to an equivalent public, append-only
     medium, with a minimum publication frequency of once per twenty-four
     (24) hours when entries have been added.

     The Escrow Audit Log SHOULD be accessible to the human principal
     corresponding to a humanAnchor, upon presentation of a zero-knowledge
     proof of correspondence to that humanAnchor, such that the human can
     verify whether their humanAnchor has been the subject of a
     deanonymization request.  The protocol does not require this access
     channel; deployments operating under jurisdictions that mandate
     notice to the data subject SHOULD provide it.

  9.6.7.  Escrow Key Lifecycle

     Escrow keypairs MUST be subject to a documented lifecycle covering
     generation, rotation, retirement, and destruction.  Implementations
     MUST satisfy the following requirements:

     LIFE-1.  Escrow Public Keys MUST have a documented validity period
        reflected in the Trust Registry entry's valid_from and valid_until
        fields.  CTs issued during a key's validity period MUST have their
        Escrow Envelopes constructed under that key.  Envelope material
        MUST be retained by the ABAC PDP for at least the operational
        lifetime of the longest-lived CT issued under that key, plus the
        maximum statute-of-limitations period applicable to any
        transaction the CT may have authorized.


  Coetzee                   Expires October 27, 2026            [Page 20]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     LIFE-2.  Escrow keypair generation MUST occur in a documented
        ceremony attended by all Escrow Custodians or their authorized
        delegates.  The ceremony MUST produce a public artifact attesting
        to the generation: the Escrow Public Key, the threshold parameters
        (t, n), the custodian identities, and the ceremony timestamp,
        signed by a quorum of custodians.

     LIFE-3.  Escrow keys SHOULD be rotated on a schedule documented in
        the deployment policy.  Rotation MUST follow a key-overlap
        procedure where the new keypair is generated, published to the
        Trust Registry, and used for all new envelopes from a defined
        cutover date, while the previous keypair remains available for
        decryption of envelopes constructed under it.

     LIFE-4.  Retirement of an Escrow keypair MUST NOT occur while any
        Escrow Envelope constructed under that key is within its required
        retention period (LIFE-1).  Premature retirement renders the
        corresponding humanAnchors permanently un-deanonymizable, which
        MAY be desirable in specific privacy-by-design deployments but
        MUST be an explicit deployment policy decision, not an operational
        accident.

  9.6.8.  Compromise and Recovery

     This subsection specifies the protocol-level response to compromise
     events affecting the escrow.

     Compromise of fewer than t Escrow Custodians is below the threshold
     and does not directly enable unauthorized deanonymization.  The ABAC
     PDP MUST nonetheless treat any confirmed custodian compromise as an
     event requiring escrow keypair rotation per LIFE-3, with a cutover
     date no later than thirty (30) days after compromise confirmation.
     The compromised custodian MUST be excluded from the new keypair's
     custody set.

     Compromise of t or more Escrow Custodians constitutes an Escrow
     Compromise.  On confirmation of an Escrow Compromise, the ABAC PDP
     MUST:

     - Mark the Trust Registry entry for the compromised Escrow Public Key
       as REVOKED.

     - Cease accepting new Capability Token issuance requests under the
       compromised escrow until a replacement keypair is generated and
       published.

     - Publish a notice to the Trust Registry chain or equivalent public
       medium identifying the compromised key, the time window of
       compromise, and the expected replacement schedule.


  Coetzee                   Expires October 27, 2026            [Page 21]

  Internet-Draft            SPT-Txn Tokens                   April 2026


     Capability Tokens whose Escrow Envelopes were constructed under a
     compromised key are not automatically invalidated for transaction
     processing purposes -- the token signature, scope, depth, and human
     anchor binding remain cryptographically intact.  The compromise
     affects only the escrow recoverability of the human identity, not the
     integrity of the authorization chain.  Resource servers SHOULD
     continue to honor non-revoked CTs issued before compromise;
     deployments MAY define a stricter policy in their deployment
     documentation.

     Loss of t or more Escrow Custodians without compromise -- for example
     through simultaneous key destruction events -- produces a permanent
     inability to deanonymize humanAnchors constructed under the affected
     keypair.  This is a deployment failure mode that MUST be addressed
     through custodian redundancy and documented disaster recovery
     procedures.  The protocol does not provide a mechanism to recover
     from total custody loss; this is a deliberate design property
     reflecting the principle that the human's identity is protected even
     against the operator of the system.

  9.6.9.  Implementation Note (Non-Normative)

     Two threshold cryptography constructions are particularly suitable
     for the requirements above.  Threshold ElGamal over Curve25519 with a
     published reference such as the FROST family of protocols provides
     distributed key generation and threshold decryption without ever
     reconstructing the private key, satisfying THR-2 and THR-5 in their
     strongest form.  Threshold ECIES with the same primitives is
     operationally equivalent.  Implementations choosing Shamir Secret
     Sharing of a centrally generated X25519 private key satisfy THR-1
     through THR-4 but provide weaker security at the moment of
     decryption, when shares are reconstructed in one location; this
     construction is permitted but discouraged for regulated financial
     deployments.

     The Escrow Custodian role is operationally distinct from the ABAC PDP
     role.  A deployment in which the ABAC PDP is also an Escrow Custodian
     satisfies the protocol but reduces the trust separation that the
     escrow is designed to provide.  Deployments are encouraged to recruit
     Escrow Custodians from distinct legal jurisdictions and distinct
     regulatory regimes such that no single jurisdiction's lawful process
     can compel decryption unilaterally.  This composition decision is a
     matter of deployment policy and is not specified by the protocol.


  Coetzee                   Expires October 27, 2026            [Page 22]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  10.  Security Properties

  10.1.  Signature Algorithm Requirements

     All CT signatures MUST use one of the following algorithms:

     ES256:  ECDSA with P-256 and SHA-256.  REQUIRED to support.
     ES384:  ECDSA with P-384 and SHA-384.  RECOMMENDED.
     EdDSA (Ed25519):  Edwards-curve DSA.  RECOMMENDED.
        Ed25519 is RECOMMENDED for new deployments due to its
        constant-time implementation properties and smaller
        signature size.

     RS256 and weaker algorithms MUST NOT be used for CT signing.

     Post-quantum note:  ECDSA and EdDSA are vulnerable to
     quantum adversaries with access to Shor's algorithm.
     Deployments with long-term security requirements (>10 years)
     SHOULD monitor NIST post-quantum standardization and plan
     migration to PQ-safe signature schemes.  The SPT-Txn claim
     structure is algorithm-agnostic and does not require changes
     to accommodate algorithm migration.

  10.2.  Key Management

     ABAC PDP signing keys MUST be stored in hardware security
     modules (HSMs) or equivalent tamper-resistant hardware.

     Key rotation MUST be supported.  Trust Registry entries MUST
     be updated when issuer keys are rotated.  CTs signed with
     rotated-out keys MUST be considered expired at rotation time
     unless a key overlap period is explicitly configured.

     Key overlap period SHOULD NOT exceed the maximum CT lifetime
     to bound exposure of the outgoing key.

  10.3.  Transport Security

     All SPT-Txn Token and CT transmission MUST occur over TLS 1.3
     [RFC8446] or later.  TLS 1.2 MAY be permitted for legacy
     compatibility with explicit operator acknowledgment.

     CT transmission in HTTP headers MUST use the Authorization
     header with a custom scheme:
        Authorization: SPT-CT <base64url-encoded-CT>

  10.4.  Replay Prevention

     CTs include a jti claim for unique identification.  Resource
     servers MUST maintain a short-term jti cache to detect CT
     replay within the CT's validity window.

     SPT-Txn Tokens inherit the replay prevention mechanisms
     defined in RFC 9700, including the txn claim binding.

  10.5.  Token Format Security Properties

     This section specifies security properties specific to each
     token serialization format (Section 3.5).

     JWT/SD-JWT Security:

        JWS algorithm confusion attacks MUST be prevented by
        explicitly specifying the expected algorithm at verification
        time.  Implementations MUST NOT accept the "none" algorithm.

        SD-JWT holder binding MUST use Ed25519 or P-256 key binding.
        Unbound SD-JWT presentations MUST NOT be accepted for CT
        presentation.

     Biscuit Security:

        Biscuit's append-only structure provides structural defence
        against scope escalation: attenuation blocks can only
        restrict, never expand, the token's authority.  This
        cryptographically enforces Invariant 1 (Scope Monotonicity)
        at the format layer, independent of the enforcement engine.

        The root block's Ed25519 key MUST be registered in the
        Trust Registry.  Attenuation block keys are ephemeral and
        MUST NOT be registered.

        Biscuit tokens MUST be treated as opaque by intermediate
        services that are not the intended verifier.

     CWT/COSE Security:

        COSE_Sign1 MUST be used (not COSE_Sign for multi-signer).
        Algorithm parameters MUST be in the protected header.
        Unprotected header algorithm parameters MUST be ignored.

        The COSE kid (key ID) parameter MUST NOT be used to select
        verification keys.  Verification keys MUST be retrieved
        from the Trust Registry based on the iss claim.

  10.6.  ZK Proof System Security

     See Section 8.3 for ZK proof security considerations.

     Additionally:
     - Groth16 proofs are computationally sound under the BN254
       discrete logarithm assumption.
     - Proof size is constant (192 bytes for Groth16 on BN254)
       regardless of circuit complexity.
     - Verification time is constant and fast (< 5ms on commodity
       hardware), making ZK proof verification practical in the
       enforcement engine hot path.

  10.7.  Multi-Chain Trust Registry Integrity

     See Section 8.4 for Trust Registry security considerations.

     Cross-chain deployments:  When Trust Registries are deployed
     on multiple chains, implementations MUST ensure consistency
     between chain deployments.  A Trust Registry entry on one
     chain MUST NOT be considered authoritative for resource
     servers configured to use a different chain.

     Chain reorganizations:  For EVM chains, Trust Registry reads
     SHOULD wait for a minimum of 12 block confirmations to protect
     against reorganization-based attacks on Trust Registry state.
     Hedera and Algorand provide immediate finality and do not
     require confirmation delays.


  Coetzee                   Expires October 27, 2026            [Page 23]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  11.  IANA Considerations

     This document requests registration of the following JWT claims
     in the IANA JSON Web Token Claims Registry [IANA.JWT.Claims].

     Claim Name:  spt_ct_ref
     Claim Description:  SHA-256 hash of the Capability Token
        presented at this transaction hop.
     Change Controller:  IETF
     Specification Document(s):  Section 4.2 of this document.

     Claim Name:  spt_ct_scope_hash
     Claim Description:  SHA-256 hash of the ct_scope claim of
        the presented Capability Token.
     Change Controller:  IETF
     Specification Document(s):  Section 4.2 of this document.

     Claim Name:  spt_human_anchor
     Claim Description:  Zero-knowledge commitment to the zkDID
        of the authorizing human principal (humanAnchor).
     Change Controller:  IETF
     Specification Document(s):  Sections 3.2 and 4.2 of this
        document.

     Claim Name:  spt_delegation_depth
     Claim Description:  Remaining delegation depth from the
        Capability Token at this transaction hop.
     Change Controller:  IETF
     Specification Document(s):  Section 4.2 of this document.

     Claim Name:  spt_compliance_ref
     Claim Description:  Hash reference to the ZK compliance proofs
        established at transaction root.
     Change Controller:  IETF
     Specification Document(s):  Sections 3.2 and 4.2 of this
        document.

     Claim Name:  spt_parent_txn
     Claim Description:  JWT ID of the parent SPT-Txn Token in
        the transaction chain.
     Change Controller:  IETF
     Specification Document(s):  Section 4.2 of this document.

     This document also requests registration of the following
     Capability Token claims (in a new SPT-Txn CT Claims Registry
     to be established by IANA, or in the JWT Claims Registry):

     Claim Name:  ct_type
     Claim Description:  URI identifying the capability type granted
        by this Capability Token.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.

     Claim Name:  ct_scope
     Claim Description:  Structured object defining the capability
        scope, operations, and constraints granted.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.

     Claim Name:  human_anchor
     Claim Description:  Zero-knowledge commitment to the zkDID of
        the authorizing human (humanAnchor), carried in the CT.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.

     Claim Name:  delegation_depth
     Claim Description:  Remaining delegation levels permitted from
        this CT holder.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.

     Claim Name:  compliance_ref
     Claim Description:  Hash reference to ZK compliance proofs
        at transaction root.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.

     Claim Name:  revocation_nonce
     Claim Description:  Nonce included in the revocation registry
        commitment for this CT.
     Change Controller:  IETF
     Specification Document(s):  Section 3.2 of this document.


  Coetzee                   Expires October 27, 2026            [Page 24]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  12.  References

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

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

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Token (JWT)", RFC 7519,
                DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

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

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and
                H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392,
                DOI 10.17487/RFC8392, March 2018,
                <https://www.rfc-editor.org/info/rfc8392>.

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

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

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating
                Proof of Possession (DPoP)", RFC 9449,
                DOI 10.17487/RFC9449, September 2023,
                <https://www.rfc-editor.org/info/rfc9449>.

     [RFC9700]  Tulshibagwale, A., Fletcher, G., Kasselman, P.,
                Burgin, K., and D. Richer, "Transaction Tokens",
                RFC 9700, 2025,
                <https://www.rfc-editor.org/info/rfc9700>.

     [I-D.ietf-oauth-selective-disclosure-jwt]
                Fett, D., Yasuda, K., and B. Campbell,
                "Selective Disclosure for JWTs (SD-JWT)", Work in
                Progress, Internet-Draft,
                draft-ietf-oauth-selective-disclosure-jwt-13,
                2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-
                oauth-selective-disclosure-jwt>.


  Coetzee                   Expires October 27, 2026            [Page 25]

  Internet-Draft            SPT-Txn Tokens                   April 2026


  12.2.  Informative References

     [BISCUIT]  Felte, C., et al., "Biscuit: A Capability-Based
                Authorization Token", 2022,
                <https://github.com/biscuit-auth/biscuit>.

     [GROTH16]  Groth, J., "On the Size of Pairing-Based Non-
                interactive Arguments", Advances in Cryptology
                EUROCRYPT 2016, LNCS 9666, pp. 305-326, 2016,
                DOI 10.1007/978-3-662-49896-5_11.

     [HERMEZ]   Hermez Network, "Trusted Setup Ceremony",
                <https://ceremony.hermez.io/>.

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

     [SPT-THEORY]
                Coetzee, R.J., "Transaction Binding Security for
                Policy-Bound Authorization Tokens: Formal
                Definitions and Proofs for the SPT-Txn Framework",
                Zenodo,
                DOI 10.5281/zenodo.18917439, 2025,
                <https://doi.org/10.5281/zenodo.18917439>.

     [SPT-WP]   Coetzee, R.J., "The SPT-Txn Framework v6.0:
                Sovereign Policy Token Transactions",
                Zenodo, 2025,
                <https://doi.org/10.5281/zenodo.18917439>.

     [IANA.JWT.Claims]
                IANA, "JSON Web Token Claims",
                <https://www.iana.org/assignments/jwt>.


  Author's Address

     Rudolf Jacobus Coetzee
     Violet Sky Security SEZC
     Cayman Islands

     Email: rudi@violetskysecurity.com
     URI:   https://www.violetskysecurity.com


  Coetzee                   Expires October 27, 2026            [Page 26]


name: draft-haberkamp-ipp
rev: 00
title: Intent Provenance Protocol (IPP)
time: 2026-03-16T12:21:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-17T12:21:41Z
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:47.115408+00:00
source: ietf
abstract:
  This document specifies the Intent Provenance Protocol (IPP), a
     cryptographic infrastructure standard for carrying verified human
     intent through chains of autonomous artificial intelligence agent
     actions.  IPP defines the Intent Token -- a signed, bounded, and
     tamper-evident data structure that travels with every agentic action,
     preserving an unbroken, auditable lineage from the originating human
     principal to each terminal action executed on their behalf.

     As AI agents become primary actors in enterprise environments --
     executing transactions, accessing sensitive data, orchestrating sub-
     agents, and operating across organizational boundaries -- the absence
     of a shared trust substrate creates systemic risk to organizational
     accountability, regulatory compliance, and legal liability
     attribution.  IPP addresses this gap by establishing a protocol layer
     that operates above cryptographic authentication and below
     application logic, making human intent a first-class, verifiable
     primitive in agentic systems.

     IPP introduces four foundational properties -- Lineage, Boundedness,
     Non-repudiation, and Interoperability -- enforced through a
     combination of Ed25519 digital signatures, Decentralized Identifiers
     (DIDs), and a Narrowing Invariant that prevents any derived token
     from exceeding its parent's authorized scope.  The protocol is
     framework-agnostic, cloud-agnostic, and designed for open
     implementation across the ecosystem of AI orchestration platforms.

full_text:
  Internet Engineering Task Force                             A. Haberkamp
  Internet-Draft                                        KH Sovereign, Inc.
  Intended status: Informational                                March 2026
  Expires: 17 September 2026


                      Intent Provenance Protocol (IPP)
                           draft-haberkamp-ipp-00

  Abstract

     This document specifies the Intent Provenance Protocol (IPP), a
     cryptographic infrastructure standard for carrying verified human
     intent through chains of autonomous artificial intelligence agent
     actions.  IPP defines the Intent Token -- a signed, bounded, and
     tamper-evident data structure that travels with every agentic action,
     preserving an unbroken, auditable lineage from the originating human
     principal to each terminal action executed on their behalf.

     As AI agents become primary actors in enterprise environments --
     executing transactions, accessing sensitive data, orchestrating sub-
     agents, and operating across organizational boundaries -- the absence
     of a shared trust substrate creates systemic risk to organizational
     accountability, regulatory compliance, and legal liability
     attribution.  IPP addresses this gap by establishing a protocol layer
     that operates above cryptographic authentication and below
     application logic, making human intent a first-class, verifiable
     primitive in agentic systems.

     IPP introduces four foundational properties -- Lineage, Boundedness,
     Non-repudiation, and Interoperability -- enforced through a
     combination of Ed25519 digital signatures, Decentralized Identifiers
     (DIDs), and a Narrowing Invariant that prevents any derived token
     from exceeding its parent's authorized scope.  The protocol is
     framework-agnostic, cloud-agnostic, and designed for open
     implementation across the ecosystem of AI orchestration platforms.

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





  Haberkamp               Expires 17 September 2026               [Page 1]


  Internet-Draft         Intent Provenance Protocol             March 2026


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 2 September 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Background and Motivation . . . . . . . . . . . . . . . .   3
       1.2.  The Authorship Problem in Agentic Systems . . . . . . . .   4
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   6
       3.2.  The Four Foundational Properties  . . . . . . . . . . . .   7
       3.3.  Protocol Layers . . . . . . . . . . . . . . . . . . . . .   8
     4.  The Intent Token  . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Token Structure . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  The Intent Scope Envelope . . . . . . . . . . . . . . . .   9
       4.3.  Quantitative Bounds . . . . . . . . . . . . . . . . . . .  10
     5.  The Genesis Seal  . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Purpose and Design  . . . . . . . . . . . . . . . . . . .  10
       5.2.  Genesis Seal Structure  . . . . . . . . . . . . . . . . .  10
       5.3.  Key Generation Ceremony . . . . . . . . . . . . . . . . .  11
       5.4.  Authorship Attribution Requirements . . . . . . . . . . .  12
     6.  Cryptographic Mechanisms  . . . . . . . . . . . . . . . . . .  12
       6.1.  Signature Algorithm . . . . . . . . . . . . . . . . . . .  12
       6.2.  Decentralized Identifiers (DIDs)  . . . . . . . . . . . .  13
       6.3.  Hash Functions  . . . . . . . . . . . . . . . . . . . . .  13
       6.4.  The Narrowing Invariant . . . . . . . . . . . . . . . . .  13
     7.  Delegation and Derived Tokens . . . . . . . . . . . . . . . .  13
       7.1.  Derivation Rules  . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Delegation Depth  . . . . . . . . . . . . . . . . . . . .  14
       7.3.  Sub-Agent Spawning  . . . . . . . . . . . . . . . . . . .  14
     8.  Revocation  . . . . . . . . . . . . . . . . . . . . . . . . .  14



  Haberkamp               Expires 17 September 2026               [Page 2]


  Internet-Draft         Intent Provenance Protocol             March 2026


       8.1.  Revocation Registry . . . . . . . . . . . . . . . . . . .  14
       8.2.  Polling Requirements  . . . . . . . . . . . . . . . . . .  14
       8.3.  Mid-Chain Revocation  . . . . . . . . . . . . . . . . . .  15
     9.  Provenance Chain  . . . . . . . . . . . . . . . . . . . . . .  15
       9.1.  Append-Only Structure . . . . . . . . . . . . . . . . . .  15
       9.2.  Provenance Record Format  . . . . . . . . . . . . . . . .  15
     10. Interoperability  . . . . . . . . . . . . . . . . . . . . . .  15
       10.1.  Framework Integration  . . . . . . . . . . . . . . . . .  15
       10.2.  Cross-Organization Trust . . . . . . . . . . . . . . . .  15
       10.3.  Domain Taxonomy  . . . . . . . . . . . . . . . . . . . .  16
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  16
     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  17
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  17
       14.2.  Informative References . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18

  1.  Introduction

  1.1.  Background and Motivation

     For three decades, enterprise security has operated under a single
     foundational assumption: that every consequential digital action
     originates from, and is ultimately accountable to, a human being.
     Access control systems, identity governance frameworks, audit logging
     infrastructures, and regulatory compliance regimes all derive their
     validity from this assumption.  A human authenticates.  A human is
     authorized.  A human acts.  A human is accountable.

     The emergence of autonomous artificial intelligence agents --
     software entities capable of perceiving their environment, reasoning
     about goals, taking sequences of actions, and spawning additional
     agents to fulfill sub-tasks -- fundamentally invalidates this
     assumption.  In agentic environments, the majority of consequential
     actions are executed by software entities operating without real-time
     human supervision.  A human sets a goal; an agent, or a hierarchy of
     agents, determines and executes the means.

     This creates a category of risk that existing security infrastructure
     is architecturally unequipped to address: not the risk of
     unauthorized access, but the risk of authorized-but-misaligned action
     -- agent behavior that is technically permitted by access control
     systems but inconsistent with the human intent that originally
     authorized the agent's deployment.






  Haberkamp               Expires 17 September 2026               [Page 3]


  Internet-Draft         Intent Provenance Protocol             March 2026


  1.2.  The Authorship Problem in Agentic Systems

     Consider a scenario in which a Chief Financial Officer instructs an
     AI assistant to "optimize cash positions across all subsidiaries and
     move any idle balances over ten million dollars into short-term
     treasuries."  The assistant spawns three sub-agents: one to query
     treasury balances, one to evaluate current rates, and one to execute
     transfers.  The transfer agent, drawing on outputs from the other
     two, initiates eleven separate wire transfers totaling three hundred
     forty million dollars.

     At the moment the eleventh transfer is executed, no existing system
     can answer the following questions with cryptographic certainty:

     a.  What specific human intent authorized this action?

     b.  What constraints bounded that intent?

     c.  What is the complete chain of delegation from the CFO's
         instruction to this specific transfer?

     d.  Is this action consistent with what the CFO meant, or merely
         consistent with what the CFO said?

     e.  Who bears legal accountability if this action causes harm?

     The Intent Provenance Protocol is designed to make all five of these
     questions answerable with cryptographic precision, in real time,
     without requiring a central authority, and in a form that is legally
     defensible across jurisdictions.

  1.3.  Scope

     This specification defines: the structure and semantics of the Intent
     Token; the Genesis Seal mechanism for permanent authorship
     attribution; the cryptographic mechanisms underlying token signing
     and verification; the Narrowing Invariant governing token derivation;
     the revocation protocol; the provenance chain format; and the
     interoperability requirements for compliant implementations.

     This specification does not define: specific AI agent architectures
     or orchestration frameworks; natural language processing mechanisms
     for intent parsing; application-layer authorization policies; or
     legal standards for accountability attribution (though it is designed
     to support such standards).






  Haberkamp               Expires 17 September 2026               [Page 4]


  Internet-Draft         Intent Provenance Protocol             March 2026


  2.  Terminology and Definitions

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

     Agent:
        An autonomous software entity capable of perceiving inputs,
        reasoning about goals, taking sequences of actions, and
        potentially spawning additional agents.  Agents are the primary
        non-human actors governed by this protocol.

     Principal:
        A human being or legally accountable organization at the root of
        an intent chain.  Every valid Intent Token chain MUST have a human
        Principal at its origin.  There is no such thing as an agent-
        originated intent chain under this protocol.

     Intent Token:
        The atomic unit of this protocol.  A cryptographically signed,
        bounded, and time-limited data structure that carries verified
        human intent through a chain of agentic actions.

     Genesis Seal:
        A cryptographic artifact embedded in every Intent Token that
        permanently links the token to the original IPP specification and
        its author, Amanda Haberkamp.  The Genesis Seal contains a hash of
        the specification document signed by the Founding Key.

     Founding Key:
        The Ed25519 private key generated by Amanda Haberkamp during the
        Key Generation Ceremony and used exclusively to produce the
        Genesis Seal signature.  This key is never used after the ceremony
        and is stored in offline cold storage.

     Narrowing Invariant:
        The protocol rule that a Derived Token MUST be strictly less than
        or equal to its Parent Token in every dimension of scope,
        delegation depth, and expiry.  Violations of this invariant are
        detectable by any participant without contacting a central
        authority.








  Haberkamp               Expires 17 September 2026               [Page 5]


  Internet-Draft         Intent Provenance Protocol             March 2026


     Derived Token:
        An Intent Token produced by an agent from a Parent Token.  A
        Derived Token carries narrowed scope and reduced delegation depth,
        and is signed by both the issuing agent and linked to the Parent
        Token's signature.

     Delegation Depth:
        A non-negative integer field in the Intent Token specifying how
        many additional levels of sub-agent spawning are authorized.  A
        value of zero means the token holder may act but may not spawn
        sub-agents.

     Provenance Chain:
        An append-only, cryptographically linked sequence of records
        within an Intent Token documenting every action taken under that
        token's authority.

     Domain Taxonomy:
        The hierarchical dot-notation vocabulary for classifying intent
        domains, maintained by KH Sovereign, Inc. and open for community
        contribution.  Examples: financial.treasury,
        healthcare.records.read, infrastructure.compute.provision.

     DID:
        Decentralized Identifier.  A W3C standard identifier that enables
        verifiable, self-sovereign identity without relying on a
        centralized registry.  All Principal and Agent identities in this
        protocol are expressed as DIDs.

     Revocation Registry:
        A distributed service providing real-time token revocation status.
        Agents MUST check the registry before taking any action under a
        token.

  3.  Protocol Overview

  3.1.  Design Principles

     IPP is designed according to the following principles:

     *  *Decentralized enforcement:* Token validity is verifiable by any
        participant without contacting a central authority.  The
        cryptographic structure of the token itself makes violations
        detectable.

     *  *Human primacy:* Every intent chain MUST originate from a human
        Principal.  This is not a policy choice -- it is a structural
        requirement enforced by the token schema.



  Haberkamp               Expires 17 September 2026               [Page 6]


  Internet-Draft         Intent Provenance Protocol             March 2026


     *  *Minimal footprint:* The SDK integration surface is intentionally
        small.  Developers add governance capability to existing agents
        without rewriting their architecture.

     *  *Open interoperability:* The protocol is framework-agnostic,
        cloud-agnostic, and jurisdiction-agnostic.  Any conformant
        implementation can interoperate with any other.

     *  *Permanent authorship:* The Genesis Seal embeds cryptographic
        attribution to the protocol's author in every token, making the
        authorship record tamper-evident and permanent by design.

  3.2.  The Four Foundational Properties

     Every compliant IPP implementation MUST guarantee the following four
     properties:

     Lineage:
        Every action taken by any agent under an Intent Token MUST be
        traceable, through an unbroken chain of cryptographic signatures,
        to a human Principal.  The chain may pass through any number of
        intermediate agents, but the terminal node in the backwards trace
        MUST always be a DID resolving to a human or human-accountable
        legal entity.

     Boundedness:
        Every Intent Token MUST carry explicit, machine-readable
        constraints on the scope of authorized action.  These constraints
        MUST be enforced by the SDK before any action is taken.
        Constraints travel with the token through every delegation level
        and MUST NOT be expanded by any intermediate agent.

     Non-Repudiation:
        Every Intent Token MUST be cryptographically signed such that the
        signing Principal or Agent cannot credibly deny having issued the
        token.  The signature MUST be verifiable by any third party using
        only the signer's public key, without requiring communication with
        the signer or any central authority.

     Interoperability:
        Compliant implementations MUST be capable of consuming and
        producing Intent Tokens regardless of the AI framework, cloud
        environment, or programming language used.  The token format is
        defined in JSON with a canonical serialization for signature
        purposes.






  Haberkamp               Expires 17 September 2026               [Page 7]


  Internet-Draft         Intent Provenance Protocol             March 2026


  3.3.  Protocol Layers

     IPP operates as a distinct protocol layer between cryptographic
     identity infrastructure and application logic:

     +------------------------------------------+
     |          Application Logic               |
     |    <- Agent goals, actions, outputs      |
     +------------------------------------------+
     |   Intent Provenance Protocol (IPP)       |
     |   - Intent Tokens                        |
     |   - Delegation and Derivation            |
     |   - Provenance Chain                     |
     |   - Revocation                           |
     +------------------------------------------+
     |   Cryptographic Identity Layer           |
     |   <- DIDs, Ed25519, TLS                  |
     +------------------------------------------+
     |   Transport / Infrastructure             |
     |   <- HTTP, gRPC, cloud APIs              |
     +------------------------------------------+

  4.  The Intent Token

  4.1.  Token Structure

     The Intent Token is a JSON object with a canonical structure.  The
     following is a complete example of a root Intent Token issued by a
     Principal:

  {
    "$schema": "https://ipp.khsovereign.com/schema/v0.1/intent-token.json",
    "version": "0.1",
    "genesis": {
      "spec_hash": "sha3-256:a3f9c2d8e1b74f6a...",
      "author_did": "did:key:z6MkHaberkamp...",
      "author_name": "Amanda Haberkamp",
      "org": "KH Sovereign, Inc.",
      "genesis_sig": "ed25519:BASE64URL..."
    },
    "token_id": "ipp:tok:550e8400-e29b-41d4-a716-446655440000",
    "schema_version": "0.1",
    "created_at": "2026-09-01T14:32:00Z",
    "expires_at": "2026-09-01T22:32:00Z",
    "principal": {
      "did": "did:key:z6MkPrincipalXXX...",
      "name": "Amanda Haberkamp",
      "org": "KH Sovereign, Inc.",



  Haberkamp               Expires 17 September 2026               [Page 8]


  Internet-Draft         Intent Provenance Protocol             March 2026


      "legal_jurisdiction": "US-IL",
      "signature": "ed25519:BASE64URL..."
    },
    "intent": {
      "natural_language": "Optimize cash positions across subsidiaries",
      "domain": "financial.treasury",
      "resource_scope": ["subsidiary:*", "account_type:cash"],
      "quantitative_bounds": {
        "min_balance_threshold": 10000000,
        "currency": "USD",
        "max_single_transaction": 50000000,
        "time_window": "business_hours_CT"
      },
      "prohibited_actions": ["equity_purchase", "account_closure"]
    },
    "delegation": {
      "parent_token_id": null,
      "depth_remaining": 3,
      "depth_original": 3,
      "agent_id": "ipp:agent:langchain:treasury-optimizer-v1",
      "agent_framework": "langchain",
      "agent_version": "0.1.0",
      "spawned_by_principal": true
    },
    "revocation": {
      "registry_endpoint": "https://revoke.khsovereign.com/v1",
      "token_id_hash": "sha3-256:HASH...",
      "check_interval_ms": 5000
    },
    "provenance_chain": [],
    "token_signature": "ed25519:BASE64URL_SIGNED_BY_PRINCIPAL"
  }

  4.2.  The Intent Scope Envelope

     The intent field encodes the human's goal as a Structured Intent
     Envelope.  The natural_language field is human-readable but NOT
     machine-enforceable.  Enforcement is performed against the structured
     fields only.

     The domain field value MUST be drawn from the IPP Domain Taxonomy
     maintained at https://ipp.khsovereign.com/taxonomy.  Implementations
     using non-standard domain values MUST prefix them with "x." (e.g.,
     x.mycompany.custom_domain) to avoid collision with future taxonomy
     additions.






  Haberkamp               Expires 17 September 2026               [Page 9]


  Internet-Draft         Intent Provenance Protocol             March 2026


  4.3.  Quantitative Bounds

     The quantitative_bounds object is domain-specific.  Standard bound
     fields for the financial domain are defined below.  Domain-specific
     extensions are published in the IPP Domain Taxonomy registry.

     "quantitative_bounds": {
       "min_balance_threshold": integer,
       "max_single_transaction": integer,
       "max_total_exposure": integer,
       "currency": "ISO 4217 code",
       "time_window": "named window or ISO 8601 interval",
       "geographic_restriction": ["ISO 3166-1 alpha-2 codes"],
       "counterparty_allowlist": ["DID or entity identifier"],
       "counterparty_blocklist": ["DID or entity identifier"]
     }

  5.  The Genesis Seal

  5.1.  Purpose and Design

     The Genesis Seal is a cryptographic artifact embedded in every Intent
     Token that permanently and irrevocably links the token to this
     specification and to its author, Amanda Haberkamp.  The Genesis Seal
     serves three simultaneous functions:

     *  *Protocol versioning:* The spec_hash field uniquely identifies the
        exact version of the IPP specification under which the token was
        issued.

     *  *Authorship attribution:* The author_did and genesis_sig fields
        constitute a permanent, cryptographically verifiable record that
        Amanda Haberkamp is the originator of this protocol.

     *  *Ecosystem integrity:* Because the Genesis Seal is required in all
        tokens, any token that omits or falsifies it is detectable as non-
        compliant without reference to any external authority.

     The genesis_sig is produced using the Founding Key -- an Ed25519
     private key generated by Amanda Haberkamp and used ONLY ONCE, during
     the Key Generation Ceremony described in Section 5.3.  The private
     component of this key is stored in offline cold storage and is never
     used again.  The public component is published in this specification
     and in the IPP specification repository.

  5.2.  Genesis Seal Structure





  Haberkamp               Expires 17 September 2026              [Page 10]


  Internet-Draft         Intent Provenance Protocol             March 2026


     "genesis": {
       "spec_hash":      "sha3-256:[HASH OF IPP SPECIFICATION DOCUMENT]",
       "author_did":     "did:key:z6MkHaberkampXXXXXXXXXXXXXXXXXXXXXXXX",
       "author_name":    "Amanda Haberkamp",
       "org":            "KH Sovereign, Inc.",
       "founding_pubkey":"ed25519-pub:[BASE64URL PUBLIC KEY]",
       "genesis_sig":    "ed25519:[BASE64URL SIGNATURE]"
     }

     Where genesis_sig = Ed25519Sign(
       private_key = FOUNDING_PRIVATE_KEY,
       message     = SHA3-256(spec_hash || author_did
                              || author_name || org || timestamp)
     )

     Verification of the Genesis Seal MUST proceed as follows:

     1.  Retrieve the IPP specification from the canonical location:
         https://ipp.khsovereign.com/spec/v0.1

     2.  Compute SHA3-256 of the specification document and compare with
         spec_hash.  If they do not match, the token was issued under a
         modified or forged specification.

     3.  Retrieve Amanda Haberkamp's founding public key from the
         specification repository at https://ipp.khsovereign.com/keys/
         founding_public.pem

     4.  Verify the genesis_sig using the founding public key.  If
         verification fails, the Genesis Seal is invalid.

     5.  If both checks pass, the token is certified as issued under the
         authentic IPP specification authored by Amanda Haberkamp.

  5.3.  Key Generation Ceremony

     The Founding Key pair was generated according to the following
     procedure, designed to maximize security and establish a clear,
     witnessed chain of custody:

     1.  An air-gapped machine (disconnected from all networks) was used
         for all key generation operations.

     2.  The Ed25519 key pair was generated using OpenSSL 3.x:







  Haberkamp               Expires 17 September 2026              [Page 11]


  Internet-Draft         Intent Provenance Protocol             March 2026


     openssl genpkey -algorithm ed25519 \
       -out amanda_haberkamp_founding_private.pem

     openssl pkey -in amanda_haberkamp_founding_private.pem \
       -pubout \
       -out amanda_haberkamp_founding_public.pem

     3.  A DID was generated from the public key using the did:key method.

     4.  The Genesis Seal payload was constructed and signed using the
         private key.

     5.  The private key was printed to paper (two copies), placed in
         fireproof storage in separate physical locations, and deleted
         from all digital media.

     6.  The public key, DID, and Genesis Seal were committed to the IPP
         specification repository with a cryptographic timestamp.

     SECURITY NOTE: The Founding Private Key is used exactly once.  If the
     Founding Private Key is ever compromised, a Key Compromise event MUST
     be declared via a signed notice published at
     https://ipp.khsovereign.com/security, and a successor key ceremony
     MUST be conducted.

  5.4.  Authorship Attribution Requirements

     Any implementation, derivative protocol, or software product that
     uses, embeds, or interoperates with Intent Tokens MUST include the
     following attribution:

     Implements the Intent Provenance Protocol (IPP) v0.1,
     authored by Amanda Haberkamp, KH Sovereign, Inc., 2026.
     https://ipp.khsovereign.com

  6.  Cryptographic Mechanisms

  6.1.  Signature Algorithm

     All signatures in this protocol MUST use Ed25519 as defined in
     [RFC8032].  Signature values are encoded as Base64URL without
     padding, prefixed with "ed25519:".

     The canonical serialization for signing MUST be produced by: (1)
     removing the token_signature field, (2) sorting all keys
     lexicographically at every nesting level, (3) serializing to JSON
     with no extraneous whitespace, and (4) encoding as UTF-8.




  Haberkamp               Expires 17 September 2026              [Page 12]


  Internet-Draft         Intent Provenance Protocol             March 2026


  6.2.  Decentralized Identifiers (DIDs)

     All Principal and Agent identities MUST be expressed as DIDs
     conforming to the W3C DID Core specification [W3C-DID].  This
     specification RECOMMENDS the did:key method for its self-sovereign
     properties.  Implementations MAY additionally support did:web,
     did:ion, or other conformant DID methods provided they satisfy the
     following requirements: (a) the DID is resolvable without requiring
     communication with the token issuer; (b) the resolved DID document
     contains a verificationMethod with the public key material; and (c)
     the DID is persistent.

  6.3.  Hash Functions

     All hash operations in this specification use SHA3-256 [FIPS202].
     Hash values are represented as lowercase hexadecimal strings prefixed
     with "sha3-256:".

  6.4.  The Narrowing Invariant

     For any Derived Token D with Parent Token P, the following MUST hold:

     D.expires_at            <= P.expires_at
     D.delegation.depth      <  P.delegation.depth
     D.intent.domain         is a sub-domain of P.intent.domain
     D.intent.resource_scope  ⊆ P.intent.resource_scope
     D.intent.quant_bounds    ⊆ P.intent.quant_bounds
     D.intent.prohibited      ⊇ P.intent.prohibited_actions

     Any receiving agent MUST independently verify this invariant before
     accepting a Derived Token.  Verification failure MUST result in token
     rejection.

  7.  Delegation and Derived Tokens

  7.1.  Derivation Rules

     When an agent derives a child token from a parent, it MUST:

     1.  Set parent_token_id to the token_id of the parent.

     2.  Reduce depth_remaining by exactly one.

     3.  Set the intent scope to a subset of the parent's scope,
         satisfying the Narrowing Invariant.

     4.  Set expires_at to be no later than the parent's expires_at.




  Haberkamp               Expires 17 September 2026              [Page 13]


  Internet-Draft         Intent Provenance Protocol             March 2026


     5.  Set the agent_id to a unique identifier for the spawned sub-
         agent.

     6.  Compute and embed a valid narrowing_proof.

     7.  Sign the new token with the parent agent's private key.

     8.  Propagate the genesis field unchanged from the parent token.  The
         Genesis Seal is never re-derived.

  7.2.  Delegation Depth

     The depth_remaining field represents the number of additional sub-
     agent spawning levels authorized.  An agent holding a token with
     depth_remaining = 0 MAY act under the token but MUST NOT issue
     Derived Tokens.

  7.3.  Sub-Agent Spawning

     An agent spawning a sub-agent MUST provide the Derived Token to the
     sub-agent as its authorization credential.  The sub-agent MUST NOT
     accept instructions that are inconsistent with its token's intent
     scope, even if those instructions come from the spawning parent
     agent.  The token is the authority -- not the parent agent.

     CRITICAL SECURITY PROPERTY: An agent MUST refuse instructions from
     any source -- including its parent agent -- that would require it to
     act outside its token's authorized scope.

  8.  Revocation

  8.1.  Revocation Registry

     The Revocation Registry accepts token revocation notices from
     authorized principals and returns revocation status for token IDs.
     Revocation is keyed on token_id_hash -- the SHA3-256 hash of the
     token_id -- to preserve privacy while maintaining revocability.

  8.2.  Polling Requirements

     Agents MUST poll the revocation registry at the interval specified by
     check_interval_ms before taking any action.  The RECOMMENDED default
     interval is 5000 milliseconds.  If the revocation registry is
     unreachable, agents MUST NOT proceed with actions unless an
     offline_grace_period_ms is specified and has not been exceeded.






  Haberkamp               Expires 17 September 2026              [Page 14]


  Internet-Draft         Intent Provenance Protocol             March 2026


  8.3.  Mid-Chain Revocation

     Revocation of a parent token MUST propagate to all derived tokens.
     The registry MUST maintain the full ancestry tree of token derivation
     so that when a root or intermediate token is revoked, all descendant
     tokens are simultaneously marked as revoked.

  9.  Provenance Chain

  9.1.  Append-Only Structure

     The provenance_chain is an append-only array.  Agents MUST append a
     record to the chain before taking any action under the token.
     Records MUST NOT be modified or removed once appended.  Each record
     is signed by the acting agent, creating a cryptographically linked
     sequence of accountability records.

  9.2.  Provenance Record Format

     {
       "record_id":      "ipp:pr:uuid4",
       "token_id":       "ipp:tok:parent-token-id",
       "agent_id":       "ipp:agent:uuid4",
       "timestamp":      "ISO8601_UTC",
       "action_type":    "financial.treasury.transfer",
       "action_summary": "Human-readable description of action",
       "resource_id":    "Identifier of resource acted upon",
       "outcome":        "success | failure | partial | blocked",
       "within_bounds":  true,
       "agent_sig":      "ed25519:BASE64URL"
     }

  10.  Interoperability

  10.1.  Framework Integration

     The IPP SDK MUST provide integration adapters for the following AI
     orchestration frameworks at minimum: LangChain (Python and
     JavaScript), AutoGen (Microsoft), CrewAI, Microsoft Semantic Kernel,
     and Google Vertex AI Agent Builder.  Integration MUST NOT require
     rewriting existing agent logic.

  10.2.  Cross-Organization Trust

     When an agent from Organization A must interact with an agent from
     Organization B, the inter-organization trust handshake proceeds as
     follows:




  Haberkamp               Expires 17 September 2026              [Page 15]


  Internet-Draft         Intent Provenance Protocol             March 2026


     1.  Organization A's agent presents its Derived Token to Organization
         B's agent.

     2.  Organization B's agent verifies the Genesis Seal, validates the
         token signature chain back to a Principal DID, verifies the token
         has not expired, and checks revocation status.

     3.  Organization B's agent verifies that the requested interaction
         falls within the scope defined in the presented token.

     4.  If all checks pass, Organization B's agent may respond and
         optionally issue its own Derived Token for downstream actions.

     5.  Both agents append provenance records to their respective tokens
         for the interaction.

  10.3.  Domain Taxonomy

     The IPP Domain Taxonomy is maintained at https://ipp.khsovereign.com/
     taxonomy as an open standard with community contribution via pull
     request.  KH Sovereign, Inc. serves as the taxonomy steward.  Current
     top-level domains include:

     financial.*      - Financial operations (treasury, payments, trading)
     healthcare.*     - Healthcare data and clinical operations
     infrastructure.* - Cloud and system infrastructure operations
     analytics.*      - Data analysis and reporting
     communications.* - Email, messaging, external communications
     hr.*             - Human resources and personnel operations
     legal.*          - Legal document and compliance operations
     security.*       - Security monitoring and response operations
     x.*              - Private/experimental namespace (not standardized)

  11.  Security Considerations

     Implementers MUST be aware of the following security considerations:

     Private Key Compromise:
        If a Principal's private key is compromised, an attacker can issue
        Intent Tokens on behalf of that Principal.  Revocation of all
        tokens issued under the compromised key MUST be performed
        immediately.

     Replay Attacks:
        Intent Tokens are time-bounded by the expires_at field.
        Implementations MUST reject expired tokens.  The token_id SHOULD
        be checked against a short-term cache of recently used token IDs
        to prevent replay of valid, non-expired tokens.



  Haberkamp               Expires 17 September 2026              [Page 16]


  Internet-Draft         Intent Provenance Protocol             March 2026


     Scope Creep:
        The Narrowing Invariant prevents scope expansion in derived
        tokens.  However, implementations MUST verify the invariant
        independently -- they MUST NOT trust the narrowing_proof field
        without cryptographic verification.

     Registry Availability:
        The Revocation Registry is a critical dependency.  Implementations
        MUST design for registry unavailability and MUST fail safe when
        the registry is unreachable and no offline grace period applies.

  12.  Privacy Considerations

     Intent Tokens contain sensitive information about organizational
     operations.  Implementations MUST transmit tokens only over encrypted
     channels (TLS 1.3 minimum).  The Revocation Registry uses
     token_id_hash rather than token_id to prevent the registry operator
     from building a map of active tokens.  Implementations MUST NOT send
     the full token to the revocation registry.

  13.  IANA Considerations

     This document requests registration of the URI scheme "ipp:" for use
     as the prefix for Intent Token identifiers (ipp:tok:*), Agent
     identifiers (ipp:agent:*), and Provenance Record identifiers
     (ipp:pr:*).  This document also requests registration of the media
     type application/ipp+json for serialized Intent Token payloads.

  14.  References

  14.1.  Normative References

     [FIPS202]  NIST, "SHA-3 Standard: Permutation-Based Hash and
                Extendable-Output Functions", FIPS PUB 202, August 2015,
                <https://doi.org/10.6028/NIST.FIPS.202>.

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

     [RFC3161]  Adams, C., "Internet X.509 Public Key Infrastructure Time-
                Stamp Protocol (TSP)", RFC 3161, August 2001,
                <https://www.rfc-editor.org/rfc/rfc3161>.

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




  Haberkamp               Expires 17 September 2026              [Page 17]


  Internet-Draft         Intent Provenance Protocol             March 2026


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

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

  14.2.  Informative References

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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

  Author's Address

     Amanda Haberkamp
     KH Sovereign, Inc.
     Chicago, Illinois
     United States
     Email: amanda@khsovereign.com
     URI:   https://ipp.khsovereign.com


























  Haberkamp               Expires 17 September 2026              [Page 18]


name: draft-hood-independent-atp
rev: 00
title: Agent Transfer Protocol (ATP)
time: 2026-03-19T19:19:54Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-20T19:19:54Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:47.115413+00:00
source: ietf
abstract:
  AI agents and agentic systems generate a growing volume of intent-
     driven, unstructured, and undifferentiated traffic that flows through
     HTTP indistinguishably from human-initiated requests.  HTTP lacks the
     semantic vocabulary, observability primitives, and identity
     mechanisms required by agent systems operating at scale.  Existing
     protocols described as "agent protocols" — including MCP, ACP, A2A,
     and ANP — are messaging-layer constructs that presuppose HTTP as
     their transport.  They do not address the underlying transport
     problem.

     This document defines the Agent Transfer Protocol (ATP): a dedicated
     application-layer protocol for AI agent traffic.  ATP provides agent-
     native intent methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN,
     DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY), protocol-level
     agent identity and authority headers, and a status code vocabulary
     designed for the conditions AI agent systems encounter.  ATP SHOULD
     prefer QUIC for new implementations and MUST support TCP/TLS for
     compatibility and fallback.  It is designed to be composable with
     existing agent frameworks, not to replace them.

full_text:
  Independent Submission                                           C. Hood
  Internet-Draft                                             Nomotic, Inc.
  Intended status: Informational                             19 March 2026
  Expires: 20 September 2026


                       Agent Transfer Protocol (ATP)
                       draft-hood-independent-atp-00

  Abstract

     AI agents and agentic systems generate a growing volume of intent-
     driven, unstructured, and undifferentiated traffic that flows through
     HTTP indistinguishably from human-initiated requests.  HTTP lacks the
     semantic vocabulary, observability primitives, and identity
     mechanisms required by agent systems operating at scale.  Existing
     protocols described as "agent protocols" — including MCP, ACP, A2A,
     and ANP — are messaging-layer constructs that presuppose HTTP as
     their transport.  They do not address the underlying transport
     problem.

     This document defines the Agent Transfer Protocol (ATP): a dedicated
     application-layer protocol for AI agent traffic.  ATP provides agent-
     native intent methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN,
     DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY), protocol-level
     agent identity and authority headers, and a status code vocabulary
     designed for the conditions AI agent systems encounter.  ATP SHOULD
     prefer QUIC for new implementations and MUST support TCP/TLS for
     compatibility and fallback.  It is designed to be composable with
     existing agent frameworks, not to replace them.

  Status of This Memo

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

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 20 September 2026.




  Hood                    Expires 20 September 2026               [Page 1]


  Internet-Draft                     ATP                        March 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Limitations of HTTP for Agent Traffic . . . . . . . . . .   4
       1.3.  Why Not Evolve HTTP?  . . . . . . . . . . . . . . . . . .   5
       1.4.  Motivation for a Dedicated Protocol . . . . . . . . . . .   6
       1.5.  Scope and Target Audience . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Problem 1: Undifferentiated Agent Traffic on HTTP . . . .   7
       3.2.  Problem 2: Semantic Mismatch Between Agent Intent and
             Available Methods . . . . . . . . . . . . . . . . . . . .   8
       3.3.  Problem 3: No Protocol-Level Identity, Authority, or
             Attribution for Agents  . . . . . . . . . . . . . . . . .   8
       3.4.  Problem Summary . . . . . . . . . . . . . . . . . . . . .   8
     4.  Related Work and Existing Approaches  . . . . . . . . . . . .   9
       4.1.  HTTP/REST as the De Facto Standard  . . . . . . . . . . .   9
       4.2.  Existing Agent Protocols  . . . . . . . . . . . . . . . .   9
       4.3.  Transport-Layer Alternatives  . . . . . . . . . . . . . .   9
       4.4.  The Critical Distinction: Messaging vs. Transport . . . .  10
       4.5.  ATP Positioning: The Proposed Stack . . . . . . . . . . .  10
     5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Stack Position  . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Design Principles . . . . . . . . . . . . . . . . . . . .  11
       5.3.  Connection Model  . . . . . . . . . . . . . . . . . . . .  12
       5.4.  Header Format . . . . . . . . . . . . . . . . . . . . . .  12
         5.4.1.  Request Headers . . . . . . . . . . . . . . . . . . .  12
         5.4.2.  Response Headers  . . . . . . . . . . . . . . . . . .  13
       5.5.  Status Codes  . . . . . . . . . . . . . . . . . . . . . .  13
       5.6.  Wire Format and Content-Type  . . . . . . . . . . . . . .  15
       5.7.  Early Implementations . . . . . . . . . . . . . . . . . .  15
       5.8.  Agent Identification and Naming . . . . . . . . . . . . .  16
         5.8.1.  The Canonical Agent Identifier  . . . . . . . . . . .  16
         5.8.2.  Human-Friendly Agent Names (Optional Layer) . . . . .  17
         5.8.3.  Governed Name Registration  . . . . . . . . . . . . .  17
         5.8.4.  Name Resolution . . . . . . . . . . . . . . . . . . .  18



  Hood                    Expires 20 September 2026               [Page 2]


  Internet-Draft                     ATP                        March 2026


         5.8.5.  Scaling Considerations  . . . . . . . . . . . . . . .  19
         5.8.6.  IANA Considerations for the atp:// URI Scheme . . . .  19
     6.  Method Definitions  . . . . . . . . . . . . . . . . . . . . .  19
       6.1.  Design Philosophy . . . . . . . . . . . . . . . . . . . .  20
       6.2.  Core Methods  . . . . . . . . . . . . . . . . . . . . . .  20
         6.2.1.  QUERY . . . . . . . . . . . . . . . . . . . . . . . .  20
         6.2.2.  SUMMARIZE . . . . . . . . . . . . . . . . . . . . . .  21
         6.2.3.  BOOK  . . . . . . . . . . . . . . . . . . . . . . . .  21
         6.2.4.  SCHEDULE  . . . . . . . . . . . . . . . . . . . . . .  22
         6.2.5.  LEARN . . . . . . . . . . . . . . . . . . . . . . . .  23
         6.2.6.  DELEGATE  . . . . . . . . . . . . . . . . . . . . . .  24
         6.2.7.  COLLABORATE . . . . . . . . . . . . . . . . . . . . .  25
         6.2.8.  CONFIRM . . . . . . . . . . . . . . . . . . . . . . .  26
         6.2.9.  ESCALATE  . . . . . . . . . . . . . . . . . . . . . .  27
         6.2.10. NOTIFY  . . . . . . . . . . . . . . . . . . . . . . .  28
       6.3.  Method Summary Table  . . . . . . . . . . . . . . . . . .  29
       6.4.  Method Registry and Extensibility . . . . . . . . . . . .  30
       6.5.  Extended Method Vocabulary and Industry Profiles  . . . .  31
         6.5.1.  Three-Tier Method Architecture  . . . . . . . . . . .  31
         6.5.2.  Method Category Taxonomy  . . . . . . . . . . . . . .  31
         6.5.3.  Standard Extended Methods (Tier 2)  . . . . . . . . .  32
         6.5.4.  Short-Form and Industry-Inspired Methods  . . . . . .  33
         6.5.5.  Industry Profile Method Sets  . . . . . . . . . . . .  33
         6.5.6.  Registration Path for New Methods . . . . . . . . . .  34
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
       7.1.  Mandatory TLS . . . . . . . . . . . . . . . . . . . . . .  34
       7.2.  Agent Identity Headers and Agent Certificate Extension  .  35
       7.3.  Authority Scope Enforcement . . . . . . . . . . . . . . .  35
       7.4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  35
         7.4.1.  Agent Spoofing  . . . . . . . . . . . . . . . . . . .  35
         7.4.2.  Authority Laundering  . . . . . . . . . . . . . . . .  36
         7.4.3.  Delegation Chain Poisoning  . . . . . . . . . . . . .  36
         7.4.4.  Denial of Service via High-Frequency Agent Traffic  .  36
         7.4.5.  Session Hijacking . . . . . . . . . . . . . . . . . .  36
         7.4.6.  Escalation Suppression  . . . . . . . . . . . . . . .  36
       7.5.  Privacy Considerations  . . . . . . . . . . . . . . . . .  36
       7.6.  Denial-of-Service Considerations  . . . . . . . . . . . .  37
       7.7.  Intellectual Property Considerations  . . . . . . . . . .  37
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
       8.1.  Port Assignment . . . . . . . . . . . . . . . . . . . . .  38
       8.2.  ATP Method Registry . . . . . . . . . . . . . . . . . . .  38
       8.3.  ATP Status Code Registry  . . . . . . . . . . . . . . . .  39
       8.4.  Header Field Registry . . . . . . . . . . . . . . . . . .  40
       8.5.  URI Scheme Registration . . . . . . . . . . . . . . . . .  41
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  41
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  42
     Appendix A.  Authority-Scope Format . . . . . . . . . . . . . . .  43



  Hood                    Expires 20 September 2026               [Page 3]


  Internet-Draft                     ATP                        March 2026


     Appendix B.  Example ATP Wire Formats . . . . . . . . . . . . . .  43
       B.1.  QUERY Request and Response  . . . . . . . . . . . . . . .  44
       B.2.  BOOK Request and Response . . . . . . . . . . . . . . . .  44
       B.3.  ESCALATE Request and Response . . . . . . . . . . . . . .  45
     Appendix C.  Comparison Table . . . . . . . . . . . . . . . . . .  47
     Appendix D.  Glossary . . . . . . . . . . . . . . . . . . . . . .  48
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  49

  1.  Introduction

     *Note Regarding Intellectual Property:* Implementers should be aware
     that certain extensions to this specification -- specifically the
     Agent Certificate extension (Section 7.2) and the ACTIVATE method --
     may be subject to pending patent applications by the author.  The
     core ATP specification is intended for open implementation without
     royalty obligation.  The licensor is prepared to grant a royalty-free
     license to implementers consistent with [RFC8179].  IPR disclosures:
     https://datatracker.ietf.org/ipr/ -- see also Section 7.7.

  1.1.  Background

     The deployment of AI agents and multi-agent systems is accelerating
     across enterprise, research, and consumer contexts.  These systems
     execute complex, multi-step workflows — querying data sources,
     booking resources, delegating subtasks to peer agents, and escalating
     decisions to human principals — with minimal or no human supervision
     per transaction.

     Unlike human-initiated web traffic, agent-generated traffic is
     dynamic, high-frequency, intent-driven, and often stateful across
     sequences of related requests.  The infrastructure carrying this
     traffic was not designed with these properties in mind.

  1.2.  Limitations of HTTP for Agent Traffic

     HTTP has served as the internet's primary application-layer transport
     for over three decades.  Its evolution through HTTP/2 [RFC7540] and
     HTTP/3 [RFC9114] has improved performance, multiplexing, and latency.
     However, the fundamental model of HTTP — stateless, resource-
     oriented, human-initiated request/response — creates specific
     failures when applied to agentic systems at scale:

     *  Traffic indistinguishability: Agent-generated requests are
        structurally identical to human-initiated requests at the
        transport layer.  Operators cannot identify, route, or govern
        agent traffic without application-layer instrumentation.





  Hood                    Expires 20 September 2026               [Page 4]


  Internet-Draft                     ATP                        March 2026


     *  Method vocabulary mismatch: HTTP's method set (GET, POST, PUT,
        DELETE, PATCH) describes resource operations.  Agent traffic
        expresses purposeful intent — summarize, book, delegate, escalate.
        The mismatch forces intent into request bodies, invisible to
        protocol-level handlers.

     *  Identity and attribution absence: HTTP carries no native mechanism
        for asserting agent identity, declared authority scope, or the
        principal accountable for an agent's actions.

     *  Session semantics mismatch: HTTP's stateless model is optimized
        for isolated request/response cycles.  Agent workflows are
        inherently stateful sequences.

  1.3.  Why Not Evolve HTTP?

     A natural question is whether these limitations could be addressed by
     extending HTTP rather than defining a new protocol.  There are three
     specific reasons why HTTP extension is not the preferred path.

     First, the HTTP method registry is effectively frozen for new
     semantics.  [RFC9110] defines the HTTP method registry with IETF
     Review as the registration procedure, meaning new methods require a
     full IETF consensus process and must be backward-compatible with
     existing HTTP implementations.  Adding intent-based verbs (SUMMARIZE,
     DELEGATE, ESCALATE) to HTTP would require every HTTP client, server,
     proxy, and middleware component to ignore or handle unknown methods
     gracefully — a compatibility constraint that limits how agent-
     specific semantics can be expressed at the protocol level.

     Second, HTTP carries decades of backward-compatibility constraints.
     Features such as persistent agent identity headers, authority scope
     declarations, and session-level governance semantics would require
     HTTP extensions that interact unpredictably with existing caching,
     proxy, and CDN behavior designed for human-generated traffic
     patterns.

     Third, the observability goal — making agent traffic distinguishable
     from human traffic at the infrastructure layer — cannot be achieved
     by adding fields to HTTP.  Infrastructure components route and filter
     HTTP traffic based on methods and headers that are identical across
     agent and human requests.  A protocol-level separation is necessary
     to give infrastructure the signal it needs.

     ATP is therefore designed as a dedicated protocol rather than an HTTP
     extension.  HTTP and ATP coexist: human traffic continues to flow
     over HTTP; agent traffic flows over ATP.  The two protocols serve
     different classes of network participant.



  Hood                    Expires 20 September 2026               [Page 5]


  Internet-Draft                     ATP                        March 2026


  1.4.  Motivation for a Dedicated Protocol

     These limitations are architectural, not implementational.  They
     cannot be resolved by better middleware or application code layered
     on HTTP.  They require a protocol designed from first principles for
     AI agent systems.

     ATP is that protocol.  It provides a dedicated transport environment
     for agent traffic with: native intent-based methods, mandatory agent
     identity headers, protocol-level authority scope declaration, and a
     status code vocabulary for the conditions autonomous systems
     encounter.

  1.5.  Scope and Target Audience

     This document covers ATP architecture, design principles, stack
     position, request and response header format, agent-native method
     definitions and semantics, status code vocabulary, security
     considerations, and IANA considerations.

     The Agent Certificate extension for cryptographic binding of agent
     identity to ATP header fields is described at a high level in
     Section 7.2.  Full specification is provided in a separate companion
     document: [ATP-CERT].  That extension may be subject to pending
     intellectual property claims; see Section 7.7 and the IPR Notice
     preceding the Abstract.

     Target audience: AI agent developers, protocol designers, cloud and
     network infrastructure providers, enterprise security and compliance
     architects, and standards community participants.

  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.

     Agent:  An AI software system that executes tasks, makes decisions,
        and takes actions without continuous human supervision per
        transaction.

     Principal:  The human, organization, or system that authorized an
        agent to act and is accountable for its actions.

     Agent-ID:  A unique identifier for a specific agent instance, present
        in all ATP request headers.



  Hood                    Expires 20 September 2026               [Page 6]


  Internet-Draft                     ATP                        March 2026


     Principal-ID:  The identifier of the principal on whose behalf an
        agent operates.

     Authority-Scope:  A declared set of permissions defining what actions
        an agent is authorized to take, in the format domain:action or
        domain:*.

     Intent Method:  An ATP method name expressing the agent's purpose, as
        distinguished from HTTP resource-operation verbs.

     Delegation Chain:  An ordered record of Agent-IDs representing the
        sequence of delegations that produced the current request.

     Escalation:  An agent's intentional deferral of a decision or action
        to a human principal or higher-authority agent.

     Attribution Record:  A logged record of an agent action sufficient
        for audit and compliance purposes.

     Session:  An ATP persistent connection context shared across multiple
        method invocations within a single agent workflow.

     SEP (Scope-Enforcement Point):  An ATP-aware infrastructure component
        — load balancer, gateway, proxy — that enforces Authority-Scope
        compliance without application-layer access.  Requires the Agent
        Certificate extension ([ATP-CERT]).

  3.  Problem Statement

     ATP is motivated by three distinct, compounding failures in how
     current internet infrastructure handles AI agent traffic.

  3.1.  Problem 1: Undifferentiated Agent Traffic on HTTP

     AI agents generate intent-driven, structured traffic that is
     functionally invisible to the infrastructure it traverses.  This
     traffic flows through HTTP alongside human traffic with no protocol-
     level differentiation.  Observability failure, routing inefficiency,
     and security blindness result — operators cannot determine what
     fraction of traffic is agent-generated without application-layer
     instrumentation that is expensive, inconsistent, and easy to
     circumvent.

     ATP response: a dedicated protocol environment for agent traffic.
     Infrastructure can distinguish, route, monitor, and govern agent
     traffic natively.





  Hood                    Expires 20 September 2026               [Page 7]


  Internet-Draft                     ATP                        March 2026


  3.2.  Problem 2: Semantic Mismatch Between Agent Intent and Available
        Methods

     AI agents operate on intent.  HTTP's method vocabulary was designed
     to describe operations on resources, not purposeful action.  When an
     agent intends to SUMMARIZE a document, BOOK a resource, and SCHEDULE
     a sequence — all three arrive as POST requests.  The server receives
     identical verbs with meaningfully different intent buried in request
     bodies, invisible to any protocol-level handler.

     ATP response: a vocabulary of agent-native methods that express
     intent at the protocol level.

  3.3.  Problem 3: No Protocol-Level Identity, Authority, or Attribution
        for Agents

     When an AI agent takes an action, there is currently no protocol-
     level mechanism to verify who authorized this agent, what scope of
     authority it holds, which principal is accountable for its actions,
     or whether it is the agent it claims to be.  Accountability gaps,
     authority laundering, auditability failure, and multi-agent trust
     collapse result.

     ATP response: agent identity and authority scope embedded in protocol
     headers on every request, with an optional Agent Certificate
     extension for cryptographic verification.

  3.4.  Problem Summary

     +===+==================+======================+=====================+
     | # | Problem          | Current Failure      | ATP Response        |
     +===+==================+======================+=====================+
     | 1 | Undifferentiated | HTTP cannot separate | Dedicated protocol  |
     |   | traffic          | agent traffic        | environment         |
     +---+------------------+----------------------+---------------------+
     | 2 | Semantic         | HTTP verbs obscure   | Native intent-      |
     |   | mismatch         | agent intent         | based method        |
     |   |                  |                      | vocabulary          |
     +---+------------------+----------------------+---------------------+
     | 3 | No protocol-     | Attribution is       | Agent identity and  |
     |   | level identity   | untraceable          | scope in headers    |
     +---+------------------+----------------------+---------------------+

                 Table 1: Summary of Problems Addressed by ATP







  Hood                    Expires 20 September 2026               [Page 8]


  Internet-Draft                     ATP                        March 2026


  4.  Related Work and Existing Approaches

  4.1.  HTTP/REST as the De Facto Standard

     HTTP remains the universal transport for all agent traffic currently
     deployed.  REST conventions layered on HTTP provide a degree of
     semantic structure, but REST remains a resource-manipulation
     paradigm.  As described in Section 1.3, evolving HTTP to address
     agent-specific needs is constrained by the frozen method registry,
     backward-compatibility requirements, and the impossibility of
     achieving infrastructure-level traffic differentiation through HTTP
     extensions alone.

  4.2.  Existing Agent Protocols

     MCP [MCP] (Model Context Protocol, Anthropic):  Defines structured
        communication between AI models and tools/resources.  Runs over
        HTTP.  Addresses tool-calling semantics, not agent traffic
        transport.

     ACP [ACP] (Agent Communication Protocol, IBM):  Defines messaging
        semantics for agent-to-agent communication.  Runs over HTTP.

     A2A [A2A] (Agent-to-Agent Protocol, Linux Foundation):  Defines
        inter-agent communication and task delegation semantics.  Runs
        over HTTP.

     ANP [ANP] (Agent Network Protocol):  Defines discovery and
        communication for networked agents.  Runs over HTTP.

     All of these are messaging protocols.  They define what agents say to
     each other.  They do not define how agent traffic moves across a
     network.  Each presupposes HTTP as its transport and inherits all of
     HTTP's limitations for agentic systems.

  4.3.  Transport-Layer Alternatives

     gRPC:  High-performance RPC over HTTP/2.  Strong typing and efficient
        serialization.  Does not address agent-specific semantics,
        identity, or authority.

     WebSockets:  Persistent bidirectional connections over HTTP.  Useful
        for real-time communication but does not address method semantics
        or identity.

     QUIC [RFC9000]:  Modern multiplexed transport with reduced connection





  Hood                    Expires 20 September 2026               [Page 9]


  Internet-Draft                     ATP                        March 2026


        overhead.  ATP *SHOULD* prefer QUIC for new implementations.  QUIC
        is a transport primitive; ATP is the application-layer protocol
        above it.

  4.4.  The Critical Distinction: Messaging vs. Transport

     The most important positioning principle for ATP is the distinction
     between messaging protocols and transport protocols.  MCP, ACP, A2A,
     and ANP are messaging protocols — they define what agents say.  ATP
     defines how agent traffic moves.

     An analogy: SMTP is a messaging protocol that runs over TCP.  SMTP
     does not replace TCP.  Saying "TCP is unnecessary because SMTP
     exists" is a category error.  The same logic applies here.  MCP and
     its peers define agent messaging semantics.  ATP defines the
     transport environment those messages move through.

  4.5.  ATP Positioning: The Proposed Stack

     +-----------------------------------------------------+
     |            Agent Application Logic                  |
     +-----------------------------------------------------+
     |  Messaging Layer  (MCP / ACP / A2A)  [optional]     |
     +-----------------------------------------------------+
     |   ATP - Agent Transfer Protocol      [this spec]    |
     +-----------------------------------------------------+
     |            TLS 1.3+                  [mandatory]    |
     +-----------------------------------------------------+
     |         TCP / QUIC / UDP                            |
     +-----------------------------------------------------+

                      Figure 1: ATP in the Protocol Stack

     ATP is not a replacement for messaging protocols.  Agents using MCP
     or A2A route those messages over ATP and gain transport-level
     observability and identity without modifying the messaging layer.
     ATP-native agents that do not use a separate messaging protocol
     interact with ATP methods directly.

  5.  Protocol Overview

  5.1.  Stack Position

     ATP is an application-layer protocol.  It operates above the
     transport layer (TCP, UDP, or QUIC) and is wrapped by TLS.  It sits
     below any agent messaging protocol in deployments that use one.





  Hood                    Expires 20 September 2026              [Page 10]


  Internet-Draft                     ATP                        March 2026


     *  *SHOULD* prefer QUIC [RFC9000] [RFC9001] for new deployments
        (lower latency, multiplexing without head-of-line blocking, 0-RTT
        connection establishment).

     *  *MUST* support TCP/TLS as a fallback for compatibility with
        existing infrastructure.

     *  *MAY* run over UDP where QUIC is not available, subject to
        implementor-defined reliability guarantees.

     Suggested port assignment (subject to IANA assignment — see
     Section 8):

     *  ATP/QUIC: port 8443 (proposed)

     *  ATP/TCP+TLS: port 8080 (proposed)

  5.2.  Design Principles

     Minimalist core:  The base spec defines only what is necessary for
        agent traffic differentiation, method semantics, and identity
        headers.  Extensions belong in companion specifications.

     Extensible by design:  New methods are registered through an IANA-
        managed Method Registry.  New header fields follow a defined
        extension convention.  Additive changes do not require a version
        increment.

     Agent-native:  Every design decision assumes the initiating party is
        an AI system, not a human.

     Secure by default:  TLS 1.3 or higher is mandatory.  Unencrypted ATP
        connections *MUST* be rejected.  Agent identity headers are
        present on every request.

     Observable by design:  Native metadata in every ATP header provides
        the minimum information needed for routing, monitoring, and audit
        without application-layer instrumentation.

     Composable:  ATP works alongside existing agent messaging protocols
        without requiring modification to those protocols.










  Hood                    Expires 20 September 2026              [Page 11]


  Internet-Draft                     ATP                        March 2026


  5.3.  Connection Model

     ATP uses a persistent session model by default, reflecting the
     reality that agents typically execute multi-step workflows rather
     than isolated single requests.  An ATP session is established with a
     single TLS handshake including agent identity assertion, persists
     across multiple method exchanges, carries a Session-ID header
     identifying the agent's task context, and terminates on explicit
     session close or inactivity timeout (RECOMMENDED minimum: 60
     seconds).

     Per-request (stateless) mode is supported for constrained
     environments.  In stateless mode, agent identity headers *MUST* be
     present on every individual request.

  5.4.  Header Format

  5.4.1.  Request Headers

     +==================+==========+=====================================+
     | Field            | Required | Description                         |
     +==================+==========+=====================================+
     | ATP-Version      | *MUST*   | Protocol version.  Current:         |
     |                  |          | ATP/1.0                             |
     +------------------+----------+-------------------------------------+
     | ATP-Method       | *MUST*   | The agent intent method (see        |
     |                  |          | Section 6)                          |
     +------------------+----------+-------------------------------------+
     | Agent-ID         | *MUST*   | Opaque identifier for the           |
     |                  |          | requesting agent instance           |
     +------------------+----------+-------------------------------------+
     | Principal-ID     | *MUST*   | Identifier of the human or system   |
     |                  |          | that authorized this agent          |
     +------------------+----------+-------------------------------------+
     | Authority-Scope  | *MUST*   | Declared scope of actions this      |
     |                  |          | agent is authorized to take         |
     +------------------+----------+-------------------------------------+
     | Session-ID       | *SHOULD* | Identifies the current task/        |
     |                  |          | workflow context                    |
     +------------------+----------+-------------------------------------+
     | Task-ID          | *SHOULD* | Unique identifier for this          |
     |                  |          | specific method invocation          |
     +------------------+----------+-------------------------------------+
     | Delegation-Chain | *MAY*    | Ordered list of Agent-IDs if this   |
     |                  |          | request was delegated               |
     +------------------+----------+-------------------------------------+
     | Priority         | *MAY*    | Request priority hint: critical,    |
     |                  |          | normal, background                  |



  Hood                    Expires 20 September 2026              [Page 12]


  Internet-Draft                     ATP                        March 2026


     +------------------+----------+-------------------------------------+
     | TTL              | *MAY*    | Maximum acceptable response         |
     |                  |          | latency in milliseconds             |
     +------------------+----------+-------------------------------------+

                       Table 2: ATP Request Header Fields

  5.4.2.  Response Headers

       +====================+=============+============================+
       | Field              | Required    | Description                |
       +====================+=============+============================+
       | ATP-Version        | *MUST*      | Protocol version           |
       +--------------------+-------------+----------------------------+
       | ATP-Status         | *MUST*      | Numeric status code (see   |
       |                    |             | Section 5.5)               |
       +--------------------+-------------+----------------------------+
       | Task-ID            | *MUST*      | Echo of request Task-ID    |
       |                    |             | for correlation            |
       +--------------------+-------------+----------------------------+
       | Server-Agent-ID    | *SHOULD*    | Identity of the responding |
       |                    |             | server or agent            |
       +--------------------+-------------+----------------------------+
       | Attribution-Record | *SHOULD*    | Signed record of the       |
       |                    |             | action taken, for audit    |
       +--------------------+-------------+----------------------------+
       | Continuation-Token | *MAY*       | Token for retrieving       |
       |                    |             | additional results in      |
       |                    |             | streaming contexts         |
       +--------------------+-------------+----------------------------+
       | Supported-Methods  | *SHOULD*    | List of ATP methods        |
       |                    | (on session | supported by this server   |
       |                    | open)       |                            |
       +--------------------+-------------+----------------------------+

                      Table 3: ATP Response Header Fields

  5.5.  Status Codes

     ATP defines its own status code space.  Codes 451, 550, and 551 are
     ATP-specific with no HTTP equivalent and are registered in the IANA
     ATP Status Code Registry (see Section 8.3).









  Hood                    Expires 20 September 2026              [Page 13]


  Internet-Draft                     ATP                        March 2026


     +======+===============+============================================+
     | Code | Name          | Meaning                                    |
     +======+===============+============================================+
     | 200  | OK            | Method executed successfully               |
     +------+---------------+--------------------------------------------+
     | 202  | Accepted      | Method accepted; execution is              |
     |      |               | asynchronous                               |
     +------+---------------+--------------------------------------------+
     | 204  | No Content    | Method executed; no response body          |
     +------+---------------+--------------------------------------------+
     | 400  | Bad Request   | Malformed ATP request                      |
     +------+---------------+--------------------------------------------+
     | 401  | Unauthorized  | Agent-ID not recognized or not             |
     |      |               | authenticated                              |
     +------+---------------+--------------------------------------------+
     | 403  | Forbidden     | Agent lacks authority for requested        |
     |      |               | action per Authority-Scope                 |
     +------+---------------+--------------------------------------------+
     | 404  | Not Found     | Target resource or agent not found         |
     +------+---------------+--------------------------------------------+
     | 408  | Timeout       | TTL exceeded before method could execute   |
     +------+---------------+--------------------------------------------+
     | 409  | Conflict      | Method conflicts with current state        |
     |      |               | (e.g., BOOK on unavailable resource)       |
     +------+---------------+--------------------------------------------+
     | 422  | Unprocessable | Request well-formed but semantically       |
     |      |               | invalid                                    |
     +------+---------------+--------------------------------------------+
     | 429  | Rate Limited  | Agent is exceeding permitted request       |
     |      |               | frequency                                  |
     +------+---------------+--------------------------------------------+
     | 451  | Scope         | Requested action is outside declared       |
     |      | Violation     | Authority-Scope — ATP-specific             |
     +------+---------------+--------------------------------------------+
     | 500  | Server Error  | Internal failure in the responding system  |
     +------+---------------+--------------------------------------------+
     | 503  | Unavailable   | Responding agent or system temporarily     |
     |      |               | unavailable                                |
     +------+---------------+--------------------------------------------+
     | 550  | Delegation    | A delegated sub-agent failed to complete   |
     |      | Failure       | the requested action — ATP-specific        |
     +------+---------------+--------------------------------------------+
     | 551  | Authority     | Delegation chain contains an unverifiable  |
     |      | Chain Broken  | or broken identity link — ATP-specific     |
     +------+---------------+--------------------------------------------+

                           Table 4: ATP Status Codes




  Hood                    Expires 20 September 2026              [Page 14]


  Internet-Draft                     ATP                        March 2026


     Status code 451 (Scope Violation) is a governance signal: the agent
     attempted an action outside its declared Authority-Scope, caught at
     the protocol level.  Status code 551 (Authority Chain Broken)
     indicates that one or more Agent-ID entries in the Delegation-Chain
     header cannot be verified as part of a valid delegation sequence.
     Both are operational signals, not protocol errors, and *MUST* be
     logged for audit purposes.

  5.6.  Wire Format and Content-Type

     ATP request and response bodies are encoded as JSON.  The registered
     Content-Type for ATP message bodies is:

     Content-Type: application/atp+json

     Implementations *MUST* include this Content-Type on all ATP requests
     and responses that carry a message body.  Responses with no body
     (e.g., 204 No Content) *MUST NOT* include a Content-Type header.
     Binary or streaming extensions *MAY* define additional Content-Type
     values as part of their companion specifications.

     The common structure for all ATP request bodies:

     {
       "method": "QUERY",
       "task_id": "task-0042",
       "session_id": "sess-a1b2c3d4",
       "parameters": { },
       "context": { }
     }

     And for all ATP response bodies:

     {
       "status": 200,
       "task_id": "task-0042",
       "result": { },
       "attribution": { }
     }

  5.7.  Early Implementations

     ATP is a proposed specification.  No production implementations exist
     at the time of this writing.  The author encourages early prototype
     implementations to validate the protocol design, identify gaps, and
     generate feedback prior to IETF working group submission.





  Hood                    Expires 20 September 2026              [Page 15]


  Internet-Draft                     ATP                        March 2026


        If you are building an ATP prototype or reference implementation,
        please share your findings via the feedback channel listed on the
        cover of this document.  A reference implementation in Python and/
        or Go is planned as open-source software concurrent with or
        shortly after IETF I-D submission.  Implementation reports are
        welcome and will be incorporated into subsequent draft revisions.

     Implementers wishing to experiment before the formal IANA port
     assignment may use port 8443 (ATP/QUIC) and port 8080 (ATP/TCP+TLS)
     as working values.  These values are subject to change upon final
     IANA assignment.

     The ACTIVATE method extension, which binds .nomo governed agent
     packages to ATP as a first-class activation operation, is described
     in a companion document and is implemented as an optional extension.
     Core ATP implementations need not support ACTIVATE to be compliant
     with this specification.

  5.8.  Agent Identification and Naming

  5.8.1.  The Canonical Agent Identifier

     Every ATP agent is identified by a canonical Agent-ID: a 256-bit
     cryptographic identifier derived from the agent's governance-layer
     Birth Certificate at activation time.  This identifier is globally
     unique, fixed-length, and — when the Agent Certificate extension is
     deployed — cryptographically verifiable at the transport layer.

     The URI form of a canonical Agent-ID uses the atp:// scheme:

     atp://3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d4e8b2a5f9c3d7e1b0a4f8c2d6e0b

     URI length is not a practical constraint for atp:// identifiers.
     256-character URIs are handled without issue by all modern protocol
     stacks and do not require abbreviation or truncation.

     The atp:// URI scheme is proposed for IANA registration per [RFC7595]
     as an open, unencumbered scheme.  This registration is distinct from
     and independent of any intellectual property claims on ATP
     extensions.

     The canonical Agent-ID is the authoritative identifier in all ATP
     protocol operations: it appears in the Agent-ID header of every
     request, is the key in the certificate registry, and is the cross-
     layer reference linking the ATP Agent Certificate to the governance-
     layer Birth Certificate.  All other identification forms described in
     this section are aliases that resolve to a canonical Agent-ID.




  Hood                    Expires 20 September 2026              [Page 16]


  Internet-Draft                     ATP                        March 2026


  5.8.2.  Human-Friendly Agent Names (Optional Layer)

     For deployments with large numbers of agents — particularly
     enterprise environments with hundreds or thousands of agents per
     organization — the canonical Agent-ID alone is insufficient for
     human-readable observability, audit navigation, and operational
     management.  ATP supports an optional hierarchical naming layer as a
     convenience alias system on top of canonical identifiers.

     Human-friendly names follow a structured DNS-style format using the
     .agent or .nomo top-level labels:

     atp://marketing-01.acme.agent
     atp://sales-bot-v2.engineering.acme.agent
     atp://customer-experience.acme.nomo

     The structure is: [agent-label].[department].[organization].[tld]

     where tld is .agent for general-purpose agents or .nomo for agents
     activated under the governed .nomo package format.  Organization-
     level namespaces (e.g., acme.agent) are scoped per governance zone
     and enforced at registration time (see Section 5.8.3).

     Attribute-based pattern matching is supported for multi-agent
     operations.  The wildcard form acme.agent:sales-* matches all agents
     whose friendly name begins with sales- within the acme.agent
     namespace.

     Human-friendly names *MUST NOT* be used as Agent-ID header values in
     ATP protocol messages.  The Agent-ID header always carries the
     canonical 256-bit identifier.  Friendly names are a resolution and
     management layer; they are not transport-layer identifiers.

  5.8.3.  Governed Name Registration

     Human-friendly name registration is tied to the governed activation
     flow and ATP Agent Certificate issuance process.  An agent may only
     claim a friendly name after successfully completing the atomic
     activation protocol and receiving an Active lifecycle state in the
     certificate registry.

     The registration process:

     1.  The activating operator submits a proposed friendly name
         alongside the .nomo package during the ACTIVATE transaction.

     2.  The activation endpoint verifies uniqueness within the
         organization's governance zone namespace.



  Hood                    Expires 20 September 2026              [Page 17]


  Internet-Draft                     ATP                        March 2026


     3.  On successful activation, the friendly name is recorded in the
         governance platform's name registry, mapped to the activated
         agent's canonical certificate_id.

     4.  The name binding is included in the genesis audit record as the
         friendly_name field.

     5.  Revocation of the agent's certificate automatically releases the
         friendly name, making it available for re-registration.

     Uniqueness is enforced at the governance-zone level.  Different
     organizations operating separate governance zones may register the
     same friendly name label without conflict.

  5.8.4.  Name Resolution

     Two resolution mechanisms are supported:

     DNS-based resolution:  The organization publishes DNS TXT records
        under the _agent subdomain of its governance zone domain:

     _agent.acme.agent. IN TXT "atp-id=3a9f2c1d8b7e4a6f..."

     ATP-native resolution:  An ATP QUERY request to the governance
        platform's resolution endpoint resolves a friendly name to a
        canonical Agent-ID along with the agent's current lifecycle state,
        governance zone, trust tier, and ATP Agent Certificate status.
        Resolution responses carry Content-Type: application/atp+json:

     {
       "friendly_name": "sales-bot-v2.engineering.acme.agent",
       "canonical_id":  "3a9f2c1d8b7e4a6f...",
       "lifecycle_state": "Active",
       "governance_zone": "zone:internal",
       "trust_tier": 2,
       "cert_status": "Active",
       "inclusion_proof_hash": "b2c4d6e8..."
     }

     Implementations *MUST* treat the canonical Agent-ID as authoritative
     in the event of a conflict between DNS-based and ATP-native
     resolution results.









  Hood                    Expires 20 September 2026              [Page 18]


  Internet-Draft                     ATP                        March 2026


  5.8.5.  Scaling Considerations

     The hierarchical naming scheme scales to organizations with millions
     of agents without structural modification.  Unlike sequential numeric
     suffixes, hierarchical sub-labels enable departmental grouping, role-
     based cohorts, version tracking, and delegation visibility.  The
     governance platform's name registry is a lightweight key-value store
     indexed on (governance_zone, friendly_name) with a pointer to
     certificate_id, adding O(1) per-resolution overhead.

  5.8.6.  IANA Considerations for the atp:// URI Scheme

     This document proposes registration of the atp:// URI scheme with
     IANA per [RFC7595].  Registration template:

     URI scheme name:  atp

     Status:  Permanent

     URI scheme syntax:  atp://[canonical-agent-id] or atp://[friendly-
        name]

     URI scheme semantics:  Identifies an AI agent operating over the
        Agent Transfer Protocol.  The canonical form uses a 256-bit hex-
        encoded cryptographic identifier.  The friendly-name form uses a
        hierarchical DNS-style label resolvable to a canonical identifier
        via DNS TXT records or ATP-native lookup.

     Applications/protocols that use this URI scheme:  Agent Transfer
        Protocol (this document)

     Interoperability considerations:  Friendly names are optional
        aliases; implementations *MUST* accept canonical identifiers and
        *SHOULD* support friendly-name resolution.

     Contact:  Chris Hood, chris@nomotic.ai

     References:  This document

     The atp:// URI scheme registration is open and unencumbered.  No
     intellectual property claims apply to the URI scheme itself.

  6.  Method Definitions








  Hood                    Expires 20 September 2026              [Page 19]


  Internet-Draft                     ATP                        March 2026


  6.1.  Design Philosophy

     ATP methods are intent verbs, not resource operations.  Each method
     expresses what an agent is trying to accomplish.  Method names are
     uppercase ASCII strings.  Methods that modify state are NOT
     idempotent by default unless explicitly marked.  All methods accept a
     context parameter carrying agent session state.  Requirement language
     follows [RFC2119].

  6.2.  Core Methods

  6.2.1.  QUERY

     Purpose: Semantic data retrieval.  The agent specifies what it needs
     to know, not where to find it.  Distinguished from HTTP GET by
     expressing an information need rather than retrieving a known
     resource at a known location.

         +======================+==========+=========================+
         | Parameter            | Required | Description             |
         +======================+==========+=========================+
         | intent               | *MUST*   | Natural language or     |
         |                      |          | structured expression   |
         |                      |          | of the information need |
         +----------------------+----------+-------------------------+
         | scope                | *SHOULD* | Data domains or sources |
         |                      |          | to include or exclude   |
         +----------------------+----------+-------------------------+
         | format               | *MAY*    | Desired response        |
         |                      |          | format: structured,     |
         |                      |          | natural, raw            |
         +----------------------+----------+-------------------------+
         | confidence_threshold | *MAY*    | Minimum confidence      |
         |                      |          | score for included      |
         |                      |          | results (0.0-1.0)       |
         +----------------------+----------+-------------------------+
         | context              | *MAY*    | Session context for     |
         |                      |          | disambiguation          |
         +----------------------+----------+-------------------------+

                           Table 5: QUERY Parameters

     Response: Result set with confidence scores per item.  Server
     *SHOULD* indicate provenance of each result.  Idempotent: Yes.







  Hood                    Expires 20 September 2026              [Page 20]


  Internet-Draft                     ATP                        March 2026


  6.2.2.  SUMMARIZE

     Purpose: Request a concise synthesis of provided content or a
     referenced resource.  The agent is requesting a cognitive operation
     on data, not retrieving data.

        +===========+==========+======================================+
        | Parameter | Required | Description                          |
        +===========+==========+======================================+
        | source    | *MUST*   | Content inline (up to implementation |
        |           |          | limit) or URI reference              |
        +-----------+----------+--------------------------------------+
        | length    | *SHOULD* | Target summary length: brief,        |
        |           |          | standard, detailed                   |
        +-----------+----------+--------------------------------------+
        | focus     | *MAY*    | Aspect to emphasize in the summary   |
        +-----------+----------+--------------------------------------+
        | format    | *MAY*    | Output format: bullets, prose,       |
        |           |          | structured                           |
        +-----------+----------+--------------------------------------+
        | audience  | *MAY*    | Intended reader context, for         |
        |           |          | calibrating complexity               |
        +-----------+----------+--------------------------------------+

                         Table 6: SUMMARIZE Parameters

     Response: Summary content with a source_hash and a confidence score.
     Idempotent: Yes.

  6.2.3.  BOOK

     Purpose: Reserve a resource, time slot, seat, or allocation on behalf
     of the agent's principal.  State-modifying.  Notable error codes: 409
     Conflict (resource unavailable), 451 Scope Violation (principal not
     authorized for this resource type).
















  Hood                    Expires 20 September 2026              [Page 21]


  Internet-Draft                     ATP                        March 2026


     +=====================+=============+==============================+
     | Parameter           | Required    | Description                  |
     +=====================+=============+==============================+
     | resource_id         | *MUST*      | Identifier of the resource   |
     |                     |             | to reserve                   |
     +---------------------+-------------+------------------------------+
     | principal_id        | *MUST*      | The human or system on whose |
     |                     |             | behalf the booking is made   |
     +---------------------+-------------+------------------------------+
     | time_slot           | *MUST* (if  | ISO 8601 datetime or range   |
     |                     | time-based) |                              |
     +---------------------+-------------+------------------------------+
     | quantity            | *MAY*       | Number of units to reserve   |
     +---------------------+-------------+------------------------------+
     | options             | *MAY*       | Resource-specific booking    |
     |                     |             | parameters                   |
     +---------------------+-------------+------------------------------+
     | confirm_immediately | *MAY*       | Boolean; if false, creates a |
     |                     |             | hold pending confirmation    |
     +---------------------+-------------+------------------------------+

                           Table 7: BOOK Parameters

     Response: Booking confirmation with booking_id, status (confirmed /
     held), and expiry timestamp if a hold.  Idempotent: No.

  6.2.4.  SCHEDULE

     Purpose: Define a sequence of actions, method calls, or events to be
     executed at specified times or in response to specified triggers.
     Creates a durable plan, not an immediate execution.




















  Hood                    Expires 20 September 2026              [Page 22]


  Internet-Draft                     ATP                        March 2026


       +===============+================+==============================+
       | Parameter     | Required       | Description                  |
       +===============+================+==============================+
       | steps         | *MUST*         | Ordered list of ATP method   |
       |               |                | calls with parameters        |
       +---------------+----------------+------------------------------+
       | trigger       | *MUST*         | immediate, datetime, event,  |
       |               |                | or condition                 |
       +---------------+----------------+------------------------------+
       | trigger_value | *MUST* (if not | Datetime, event name, or     |
       |               | immediate)     | condition expression         |
       +---------------+----------------+------------------------------+
       | on_failure    | *SHOULD*       | Behavior on step failure:    |
       |               |                | abort, skip, retry, escalate |
       +---------------+----------------+------------------------------+
       | notify        | *MAY*          | Notification targets on      |
       |               |                | completion or failure        |
       +---------------+----------------+------------------------------+

                          Table 8: SCHEDULE Parameters

     Response: Schedule record with schedule_id, confirmed steps, and next
     execution timestamp.  Idempotent: No.

  6.2.5.  LEARN

     Purpose: Update the agent's session context, knowledge state, or
     persistent memory.  An explicit context write — the agent asserts
     that something should be retained.






















  Hood                    Expires 20 September 2026              [Page 23]


  Internet-Draft                     ATP                        March 2026


     +============+==========+==========================================+
     | Parameter  | Required | Description                              |
     +============+==========+==========================================+
     | content    | *MUST*   | Information to be learned (structured or |
     |            |          | unstructured)                            |
     +------------+----------+------------------------------------------+
     | scope      | *MUST*   | session (ephemeral), principal (persists |
     |            |          | for principal), global (shared)          |
     +------------+----------+------------------------------------------+
     | category   | *SHOULD* | Semantic category for retrieval          |
     |            |          | optimization                             |
     +------------+----------+------------------------------------------+
     | confidence | *MAY*    | Agent's confidence in the content        |
     |            |          | (0.0-1.0)                                |
     +------------+----------+------------------------------------------+
     | source     | *MAY*    | Provenance of the learned content        |
     +------------+----------+------------------------------------------+
     | ttl        | *MAY*    | Expiry for the learned content           |
     +------------+----------+------------------------------------------+

                          Table 9: LEARN Parameters

     Response: Confirmation with learn_id and effective scope.
     Idempotent: No.

  6.2.6.  DELEGATE

     Purpose: Transfer execution of a task or method to a sub-agent or
     downstream system.  Initiates a new ATP session on behalf of the
     delegating agent, carrying forward authority lineage.





















  Hood                    Expires 20 September 2026              [Page 24]


  Internet-Draft                     ATP                        March 2026


         +==================+==========+=============================+
         | Parameter        | Required | Description                 |
         +==================+==========+=============================+
         | target_agent_id  | *MUST*   | Identifier of the agent to  |
         |                  |          | delegate to                 |
         +------------------+----------+-----------------------------+
         | task             | *MUST*   | ATP method call (or         |
         |                  |          | sequence) to execute        |
         +------------------+----------+-----------------------------+
         | authority_scope  | *MUST*   | Scope granted to sub-agent  |
         |                  |          | — *MUST* be a strict subset |
         |                  |          | of delegating agent's scope |
         +------------------+----------+-----------------------------+
         | delegation_token | *MUST*   | Signed token proving        |
         |                  |          | delegation authority        |
         +------------------+----------+-----------------------------+
         | callback         | *SHOULD* | ATP endpoint for result     |
         |                  |          | delivery                    |
         +------------------+----------+-----------------------------+
         | deadline         | *MAY*    | Maximum time for task       |
         |                  |          | completion                  |
         +------------------+----------+-----------------------------+

                         Table 10: DELEGATE Parameters

     Security note: the authority_scope in a DELEGATE request *MUST NOT*
     exceed the delegating agent's own Authority-Scope.  Servers *MUST*
     enforce this and *MUST* return 451 Scope Violation if violated.  This
     is the protocol-level defense against authority laundering.
     Idempotent: No.

  6.2.7.  COLLABORATE

     Purpose: Initiate a multi-agent coordinated task where two or more
     agents work in parallel or in defined roles toward a shared goal.
     Unlike DELEGATE (hierarchical), COLLABORATE is peer-to-peer.















  Hood                    Expires 20 September 2026              [Page 25]


  Internet-Draft                     ATP                        March 2026


         +====================+==========+==========================+
         | Parameter          | Required | Description              |
         +====================+==========+==========================+
         | collaborators      | *MUST*   | List of Agent-IDs        |
         |                    |          | invited to collaborate   |
         +--------------------+----------+--------------------------+
         | objective          | *MUST*   | Shared goal expressed as |
         |                    |          | a task description or    |
         |                    |          | structured specification |
         +--------------------+----------+--------------------------+
         | role_assignments   | *SHOULD* | Map of Agent-IDs to      |
         |                    |          | roles within the         |
         |                    |          | collaboration            |
         +--------------------+----------+--------------------------+
         | coordination_model | *SHOULD* | parallel, sequential, or |
         |                    |          | consensus                |
         +--------------------+----------+--------------------------+
         | result_aggregation | *MAY*    | How results from         |
         |                    |          | collaborators are        |
         |                    |          | combined                 |
         +--------------------+----------+--------------------------+

                       Table 11: COLLABORATE Parameters

     Response: Collaboration session receipt with collaboration_id.  Each
     collaborator receives an ATP NOTIFY to join.  Idempotent: No.

  6.2.8.  CONFIRM

     Purpose: Explicit acknowledgment of a prior action, state, or data
     item.  Creates a signed attestation record.




















  Hood                    Expires 20 September 2026              [Page 26]


  Internet-Draft                     ATP                        March 2026


      +=============+==============+===================================+
      | Parameter   | Required     | Description                       |
      +=============+==============+===================================+
      | target_id   | *MUST*       | ID of the action, booking,        |
      |             |              | schedule, or item being confirmed |
      +-------------+--------------+-----------------------------------+
      | status      | *MUST*       | accepted, rejected, or deferred   |
      +-------------+--------------+-----------------------------------+
      | reason      | *SHOULD* (if | Explanation of the decision       |
      |             | rejected/    |                                   |
      |             | deferred)    |                                   |
      +-------------+--------------+-----------------------------------+
      | attestation | *MAY*        | Agent-signed confirmation payload |
      |             |              | for audit                         |
      +-------------+--------------+-----------------------------------+

                         Table 12: CONFIRM Parameters

     Response: Confirmation receipt with timestamp and attestation_id.
     Idempotent: Yes.

  6.2.9.  ESCALATE

     Purpose: Route a task, decision, or exception to a human principal or
     higher-authority agent when the current agent cannot or should not
     proceed.  ESCALATE is the protocol-level expression of meaningful
     friction in AI systems — a first-class method, not a failure code.
























  Hood                    Expires 20 September 2026              [Page 27]


  Internet-Draft                     ATP                        March 2026


        +===========+==========+======================================+
        | Parameter | Required | Description                          |
        +===========+==========+======================================+
        | task_id   | *MUST*   | The task or method invocation        |
        |           |          | triggering escalation                |
        +-----------+----------+--------------------------------------+
        | reason    | *MUST*   | Structured reason:                   |
        |           |          | confidence_threshold, scope_limit,   |
        |           |          | ethical_flag, ambiguous_instruction, |
        |           |          | resource_unavailable                 |
        +-----------+----------+--------------------------------------+
        | context   | *MUST*   | Full context needed for the          |
        |           |          | escalation recipient to act          |
        +-----------+----------+--------------------------------------+
        | priority  | *SHOULD* | urgent, normal, or low               |
        +-----------+----------+--------------------------------------+
        | recipient | *MAY*    | Specific human or agent to escalate  |
        |           |          | to; if absent, routes to default     |
        |           |          | handler                              |
        +-----------+----------+--------------------------------------+
        | deadline  | *MAY*    | Time by which a response is needed   |
        +-----------+----------+--------------------------------------+

                         Table 13: ESCALATE Parameters

     Response: Escalation receipt with escalation_id and routing
     confirmation.  The escalated task is paused until resolved via
     CONFIRM.  Idempotent: Yes. An agent that escalates appropriately is
     functioning correctly.  Governance frameworks built on ATP can use
     escalation frequency and reason codes as observability signals for
     systemic issues.

  6.2.10.  NOTIFY

     Purpose: Asynchronous push of information from an agent to a
     recipient.  Does not expect a response.  Fire-and-forget.  Delivery
     confirmation (if required) returned via a subsequent CONFIRM from the
     recipient.













  Hood                    Expires 20 September 2026              [Page 28]


  Internet-Draft                     ATP                        March 2026


       +====================+==========+==============================+
       | Parameter          | Required | Description                  |
       +====================+==========+==============================+
       | recipient          | *MUST*   | Target Agent-ID, human       |
       |                    |          | endpoint, or broadcast group |
       +--------------------+----------+------------------------------+
       | content            | *MUST*   | Notification payload         |
       +--------------------+----------+------------------------------+
       | urgency            | *SHOULD* | critical, informational, or  |
       |                    |          | background                   |
       +--------------------+----------+------------------------------+
       | delivery_guarantee | *MAY*    | at_most_once, at_least_once, |
       |                    |          | or exactly_once              |
       +--------------------+----------+------------------------------+
       | expiry             | *MAY*    | Timestamp after which the    |
       |                    |          | notification should not be   |
       |                    |          | delivered                    |
       +--------------------+----------+------------------------------+

                         Table 14: NOTIFY Parameters

     Response: Delivery receipt with notification_id.  Idempotent: No.

  6.3.  Method Summary Table

     +=============+=============+=================+============+=======+
     | Method      | Intent      | State-Modifying | Idempotent |Primary|
     |             |             |                 |            |Error  |
     |             |             |                 |            |Codes  |
     +=============+=============+=================+============+=======+
     | QUERY       | Retrieve    | No              | Yes        |404,   |
     |             | information |                 |            |422    |
     +-------------+-------------+-----------------+------------+-------+
     | SUMMARIZE   | Synthesize  | No              | Yes        |400,   |
     |             | content     |                 |            |422    |
     +-------------+-------------+-----------------+------------+-------+
     | BOOK        | Reserve a   | Yes             | No         |409,   |
     |             | resource    |                 |            |451    |
     +-------------+-------------+-----------------+------------+-------+
     | SCHEDULE    | Plan future | Yes             | No         |400,   |
     |             | actions     |                 |            |409    |
     +-------------+-------------+-----------------+------------+-------+
     | LEARN       | Update      | Yes             | No         |400,   |
     |             | agent       |                 |            |403    |
     |             | context     |                 |            |       |
     +-------------+-------------+-----------------+------------+-------+
     | DELEGATE    | Transfer    | Yes             | No         |403,   |
     |             | task to     |                 |            |451,   |



  Hood                    Expires 20 September 2026              [Page 29]


  Internet-Draft                     ATP                        March 2026


     |             | sub-agent   |                 |            |551    |
     +-------------+-------------+-----------------+------------+-------+
     | COLLABORATE | Coordinate  | Yes             | No         |404,   |
     |             | peer agents |                 |            |403    |
     +-------------+-------------+-----------------+------------+-------+
     | CONFIRM     | Attest to a | Yes             | Yes        |404,   |
     |             | prior       |                 |            |400    |
     |             | action      |                 |            |       |
     +-------------+-------------+-----------------+------------+-------+
     | ESCALATE    | Defer to    | Yes             | Yes        |404    |
     |             | human/      |                 |            |       |
     |             | authority   |                 |            |       |
     +-------------+-------------+-----------------+------------+-------+
     | NOTIFY      | Push        | No              | No         |400,   |
     |             | information |                 |            |404    |
     +-------------+-------------+-----------------+------------+-------+

                      Table 15: ATP Core Method Summary

  6.4.  Method Registry and Extensibility

     ATP defines a formal Method Registry maintained by IANA (see
     Section 8.2).  Any party may submit a new method for registration.
     The registration procedure is Expert Review, and registration *MUST*
     be accompanied by a published specification — at minimum an IETF
     Internet-Draft or equivalent publicly available document.  Registered
     methods *MUST*:

     1.  Have a unique uppercase ASCII name

     2.  Define required and optional parameters

     3.  Define expected response structure

     4.  Specify idempotency behavior

     5.  Specify applicable error codes

     6.  Include a security considerations section

     7.  Be accompanied by a published reference specification (Internet-
         Draft or RFC)

     Experimental methods *MAY* be used prior to registration using the X-
     prefix convention (e.g., X-NEGOTIATE).  Experimental methods *MUST
     NOT* be used in production deployments without registration.





  Hood                    Expires 20 September 2026              [Page 30]


  Internet-Draft                     ATP                        March 2026


     Capability negotiation occurs during session establishment.  The
     server returns a Supported-Methods header listing the methods it
     implements.  Clients *SHOULD* check this list before invoking non-
     core methods.

  6.5.  Extended Method Vocabulary and Industry Profiles

  6.5.1.  Three-Tier Method Architecture

     The ATP method vocabulary is organized into three tiers reflecting
     different levels of universality, specificity, and domain relevance.

     Tier 1 — Core Methods (defined in Section 6.2):  The baseline
        vocabulary required for ATP compliance.  Every conformant ATP
        implementation *MUST* support all Tier 1 methods.

     Tier 2 — Standard Extended Methods:  Registered in the IANA ATP
        Method Registry and available for use in any ATP implementation.
        Not required for baseline compliance but *SHOULD* be implemented
        where their semantics apply.  Defined in [ATP-METHODS].

     Tier 3 — Industry Profile Methods:  Domain-specific method sets
        defined and registered by industry communities as named ATP
        profiles.  Valid within deployments that declare support for the
        relevant profile.  Not required in general-purpose
        implementations.

  6.5.2.  Method Category Taxonomy

     All ATP methods are organized into five categories:

     ACQUIRE:  Retrieve data, resources, or state without modifying it.
        Typically idempotent; no state modification.

     COMPUTE:  Process, transform, or analyze information and produce a
        derived result.  Typically idempotent given the same input.

     TRANSACT:  Perform state-changing operations with external systems,
        resources, or records.  Not idempotent by default; subject to
        reversibility classification.

     COMMUNICATE:  Send information, notifications, or signals to
        recipients.  Fire-and- forget or confirm-receipt delivery models.

     ORCHESTRATE:  Coordinate, sequence, or manage multiple agents, tasks,
        or workflows.  May spawn sub-agents or sessions; delegation chain
        semantics apply.




  Hood                    Expires 20 September 2026              [Page 31]


  Internet-Draft                     ATP                        March 2026


                         +=============+=============+
                         | Core Method | Category    |
                         +=============+=============+
                         | QUERY       | Acquire     |
                         +-------------+-------------+
                         | SUMMARIZE   | Compute     |
                         +-------------+-------------+
                         | BOOK        | Transact    |
                         +-------------+-------------+
                         | SCHEDULE    | Orchestrate |
                         +-------------+-------------+
                         | LEARN       | Compute     |
                         +-------------+-------------+
                         | DELEGATE    | Orchestrate |
                         +-------------+-------------+
                         | COLLABORATE | Orchestrate |
                         +-------------+-------------+
                         | CONFIRM     | Transact    |
                         +-------------+-------------+
                         | ESCALATE    | Orchestrate |
                         +-------------+-------------+
                         | NOTIFY      | Communicate |
                         +-------------+-------------+

                             Table 16: Core Method
                                Category Mapping

  6.5.3.  Standard Extended Methods (Tier 2)

     The following methods constitute the initial Tier 2 registration set,
     defined in [ATP-METHODS].  Listed here by category with brief
     semantic definitions; full parameter specifications are in the
     companion document.

     ACQUIRE category: FETCH, SEARCH, SCAN, PULL, IMPORT, FIND.

     COMPUTE category: EXTRACT, FILTER, VALIDATE, TRANSFORM, TRANSLATE,
     NORMALIZE, PREDICT, RANK, MAP.

     TRANSACT category: REGISTER, SUBMIT, TRANSFER, PURCHASE, SIGN, MERGE,
     LINK, LOG, SYNC, PUBLISH.

     COMMUNICATE category: REPLY, SEND, REPORT.

     ORCHESTRATE category: MONITOR, ROUTE, RETRY, PAUSE, RESUME, RUN,
     CHECK.





  Hood                    Expires 20 September 2026              [Page 32]


  Internet-Draft                     ATP                        March 2026


     Notable constraints: PURCHASE *MUST* carry explicit principal_id and
     scope enforcement; 451 Scope Violation applies if payments:purchase
     is not in the agent's Authority-Scope.  RUN requires explicit
     procedure_id parameter; implementations *MUST NOT* accept free-form
     execution strings.

  6.5.4.  Short-Form and Industry-Inspired Methods

     A set of short-form verb methods — SET, TAKE, OPEN, START, CALL,
     MAKE, TURN, BREAK — are provisionally catalogued as candidates for
     Tier 2 registration.  These verbs are highly context-dependent and
     their semantics vary significantly across deployment domains.

     Short-form methods will be registered individually only when a
     published companion specification provides unambiguous semantic
     definitions demonstrably distinct from existing registered methods.
     Provisional registrations using the X- prefix (e.g., X-SET, X-CALL)
     are encouraged during the experimentation period.

  6.5.5.  Industry Profile Method Sets

     ATP recognizes that specific industries require method vocabularies
     reflecting domain-specific operations that would be inappropriate in
     a general-purpose standard.  Industry profile method sets are defined
     and registered as named ATP profiles.  A profile is a published
     companion specification that:

     1.  Declares a profile name (e.g., atp-profile-healthcare, atp-
         profile-financial, atp-profile-legaltech)

     2.  Defines one or more industry-specific methods with full parameter
         specifications, error codes, and security considerations

     3.  Specifies which Tier 1 and Tier 2 methods are REQUIRED,
         RECOMMENDED, or NOT APPLICABLE within the profile

     4.  Addresses regulatory or compliance considerations specific to the
         domain (e.g., HIPAA for healthcare, PCI-DSS for financial
         services)

     Illustrative examples of potential industry profile methods (not yet
     registered; listed for directional purposes only):

     Healthcare: PRESCRIBE, AUTHORIZE, REFER, DISPENSE, TRIAGE, CONSENT,
     REDACT

     Financial services: SETTLE, RECONCILE, HEDGE, CLEAR, UNDERWRITE, KYC,
     AML



  Hood                    Expires 20 September 2026              [Page 33]


  Internet-Draft                     ATP                        March 2026


     Legal and compliance: ATTEST, NOTARIZE, DISCLOSE, REDLINE, EXECUTE,
     PRESERVE

     Infrastructure: PROVISION, DEPROVISION, ROLLBACK, SNAPSHOT, FAILOVER

     Industry communities are encouraged to develop and submit profile
     specifications through the IETF process.  The IANA ATP Method
     Registry will maintain a profile index alongside the core and
     standard method registries.

  6.5.6.  Registration Path for New Methods

     For Tier 2 Standard Methods:  Submit an Internet-Draft to the IETF
        providing full method specification per Section 6.4.  The
        Designated Expert reviews for semantic uniqueness, clarity, and
        security considerations.

     For Industry Profile Methods:  Submit a profile specification to the
        IETF (or a recognized domain standards body with an established
        ATP registry liaison) covering all methods in the profile and
        profile compliance requirements.

     For Experimental Methods:  Use the X- prefix without registration.
        Implementations *MUST NOT* deploy experimental methods in
        production without completing the registration process.
        Experimental method names do not reserve the unprefixed name.

     The ATP Method Registry is published at:
     https://www.iana.org/assignments/atp-methods/

  7.  Security Considerations

     This section satisfies the mandatory IETF Security Considerations
     requirement.  All ATP implementations *MUST* address the
     considerations described here.

  7.1.  Mandatory TLS

     All ATP connections *MUST* use TLS 1.3 or higher.  Implementations
     *MUST* reject connections using TLS 1.2 or below.  Certificate
     validation follows standard PKI practices per [RFC5280].  Servers
     *MUST* present a valid certificate.









  Hood                    Expires 20 September 2026              [Page 34]


  Internet-Draft                     ATP                        March 2026


  7.2.  Agent Identity Headers and Agent Certificate Extension

     Every ATP request *MUST* include Agent-ID and Principal-ID header
     fields.  In the base specification, these fields are not
     cryptographically authenticated — they are self-asserted but logged
     mandatorily for auditability.  Implementations *SHOULD* use logging
     and anomaly detection to identify inconsistencies.

     Full cryptographic verification of agent identity and Authority-Scope
     is provided by the ATP Agent Certificate extension [ATP-CERT].  That
     extension binds Agent-ID, Principal-ID, and Authority-Scope to an
     X.509 v3 certificate presented during TLS mutual authentication,
     enabling infrastructure-layer identity and scope verification without
     application-layer access.  Implementers planning deployments that
     require verified agent identity *SHOULD* plan for the Agent
     Certificate extension.

        Note: The Agent Certificate extension may be subject to pending
        intellectual property claims.  See Section 7.7 and the IPR Notice
        preceding the Abstract for details.  The licensor is prepared to
        grant a royalty-free license to implementers.

     Every ATP server *MUST* log Agent-ID and Principal-ID fields for
     every request, creating an attributable audit trail even in
     deployments without the Certificate extension.

  7.3.  Authority Scope Enforcement

     The Authority-Scope header declares what actions the agent is
     authorized to take.  Compliant ATP servers *MUST* parse the
     Authority-Scope on every request, return 451 Scope Violation for any
     method that exceeds declared scope, and log all scope violations for
     audit purposes.  Scope declarations are self-asserted in the base
     spec, analogous to scope assertions in OAuth 2.0 [RFC6749].
     Cryptographically signed and infrastructure-enforced scopes are
     defined in [ATP-CERT].

  7.4.  Threat Model

  7.4.1.  Agent Spoofing

     Threat: A malicious actor forges Agent-ID and Principal-ID headers to
     impersonate a trusted agent.  Base spec mitigation: mandatory logging
     and anomaly detection.  Full mitigation requires [ATP-CERT].







  Hood                    Expires 20 September 2026              [Page 35]


  Internet-Draft                     ATP                        March 2026


  7.4.2.  Authority Laundering

     Threat: An agent claims an Authority-Scope broader than what it was
     granted.  Mitigation: server-side scope enforcement; 451 Scope
     Violation returned and logged.  In DELEGATE chains, each hop's scope
     *MUST* be a strict subset of the delegating agent's scope.

  7.4.3.  Delegation Chain Poisoning

     Threat: A malicious agent inserts itself into a DELEGATE chain.
     Mitigation: Delegation-Chain headers are logged at each hop. 551
     Authority Chain Broken is returned if any chain entry is
     unverifiable.  Full mitigation requires [ATP-CERT] for signed
     delegation tokens.

  7.4.4.  Denial of Service via High-Frequency Agent Traffic

     Threat: Agents — compromised, misconfigured, or adversarial —
     generate extremely high request volumes.  Mitigation: 429 Rate
     Limited status code.  Rate limiting *SHOULD* be applied per Agent-ID
     and per Principal-ID.  When [ATP-CERT] is deployed, per-Agent-ID
     quotas can be cryptographically tied to verified identity, preventing
     quota evasion through Agent-ID spoofing.

  7.4.5.  Session Hijacking

     Threat: An attacker intercepts or forges a Session-ID.  Mitigation:
     mandatory TLS protects sessions in transit.  Session-IDs *MUST* be
     cryptographically random with minimum 128 bits of entropy.  Servers
     *MUST* validate that Session-ID, Agent-ID, and TLS client identity
     are consistent.

  7.4.6.  Escalation Suppression

     Threat: A compromised agent or intermediary suppresses ESCALATE
     requests, preventing human oversight.  Mitigation: compliant
     implementations *MUST* route ESCALATE requests directly to the
     declared escalation handler without modification.  Intermediaries
     *MUST NOT* drop, delay, or modify ESCALATE requests.  Escalation
     handlers *SHOULD* implement independent receipt confirmation.

  7.5.  Privacy Considerations

     Agent identity headers carry information about agent behavior that
     may be sensitive:

     *  Agent-ID and Principal-ID together may reveal organizational
        structure



  Hood                    Expires 20 September 2026              [Page 36]


  Internet-Draft                     ATP                        March 2026


     *  Session-ID and Task-ID reveal workflow patterns

     *  Delegation-Chain reveals multi-agent architecture

     ATP logs containing these fields *MUST* be treated as sensitive
     operational data.  Operators *MUST* implement appropriate access
     controls, retention limits, and data minimization practices
     consistent with applicable privacy regulations.

     Where privacy-preserving attribution is required, implementations
     *MAY* use pseudonymous Agent-IDs with a separate trusted resolution
     service.  Under this model, the Agent-ID transmitted in ATP headers
     is an opaque, unlinkable identifier; a trusted resolution service —
     accessible only to authorized parties — maps the opaque identifier to
     the true agent identity for audit and accountability purposes.  The
     architecture for pseudonymous agent identity resolution is reserved
     for a future companion document.

  7.6.  Denial-of-Service Considerations

     ATP's agent identity headers provide a mechanism for more precise
     denial-of-service mitigation than is possible with HTTP.  Rate
     limiting *SHOULD* be applied per Agent-ID and per Principal-ID in
     addition to per-IP-address controls.

     When [ATP-CERT] is deployed, per-Agent-ID rate limiting can be
     cryptographically tied to verified agent identity, preventing quota
     evasion through Agent-ID rotation.  Implementations planning high-
     volume governed agent deployments *SHOULD* plan for [ATP-CERT] as
     part of their denial-of-service mitigation strategy.

     Additional recommended mitigations: Priority header enforcement
     (Priority: background requests *SHOULD* have lower rate limit
     headroom than Priority: critical); per-governance-zone aggregate
     limits in multi-tenant deployments; and circuit breaker patterns for
     ESCALATE request floods.

  7.7.  Intellectual Property Considerations

     The core ATP specification — including all base methods, header
     fields, status codes, connection model, and IANA registrations
     defined in this document — is intended for open implementation
     without royalty obligation.

     Certain extensions referenced in this document may be subject to
     pending patent applications by the author, specifically: the Agent
     Certificate extension [ATP-CERT], which provides cryptographic
     binding of agent identity and authority scope to ATP header fields;



  Hood                    Expires 20 September 2026              [Page 37]


  Internet-Draft                     ATP                        March 2026


     and the ACTIVATE method, which provides ATP-native transmission and
     activation of governed agent packages.  Implementers of the core ATP
     specification are not affected by any intellectual property claims on
     these extensions.

     The licensor is prepared to grant a royalty-free license to
     implementers for any patent claims that cover contributions in this
     document and its referenced extensions, consistent with the IETF's
     IPR framework under [RFC8179].

     IPR disclosures have been filed with the IETF Secretariat and are
     available at: https://datatracker.ietf.org/ipr/

  8.  IANA Considerations

     This document requests the following IANA actions upon advancement to
     RFC status.

  8.1.  Port Assignment

     Registration of the following service names in the IANA Service Name
     and Transport Protocol Port Number Registry:

          +==============+======+===========+=======================+
          | Service Name | Port | Transport | Description           |
          +==============+======+===========+=======================+
          | atp          | TBD  | TCP       | Agent Transfer        |
          |              |      |           | Protocol over TCP/TLS |
          +--------------+------+-----------+-----------------------+
          | atp-quic     | TBD  | UDP       | Agent Transfer        |
          |              |      |           | Protocol over QUIC    |
          +--------------+------+-----------+-----------------------+

                      Table 17: Proposed Port Assignments

  8.2.  ATP Method Registry

     Establishment of a new IANA registry: Agent Transfer Protocol
     Methods.

     Registry name:  Agent Transfer Protocol Methods

     Registration procedure:  Expert Review per [RFC8126], with the








  Hood                    Expires 20 September 2026              [Page 38]


  Internet-Draft                     ATP                        March 2026


        additional requirement that each registration be accompanied by a
        published specification — at minimum a publicly available
        Internet-Draft or equivalent document.  The Designated Expert
        *SHOULD* verify that the proposed method name is unique, the
        reference specification is publicly accessible, and the method
        definition includes the required fields (parameters, response
        structure, idempotency, error codes, security considerations).

     Reference:  This document

     Initial registrations:

           +=============+===========+============================+
           | Method      | Status    | Reference                  |
           +=============+===========+============================+
           | QUERY       | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | SUMMARIZE   | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | BOOK        | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | SCHEDULE    | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | LEARN       | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | DELEGATE    | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | COLLABORATE | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | CONFIRM     | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | ESCALATE    | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+
           | NOTIFY      | Permanent | This document, Section 6.2 |
           +-------------+-----------+----------------------------+

                Table 18: Initial ATP Method Registry Entries

  8.3.  ATP Status Code Registry

     Establishment of a new IANA registry: Agent Transfer Protocol Status
     Codes.

     Registry name:  Agent Transfer Protocol Status Codes

     Registration procedure:  Expert Review + published specification
        required.




  Hood                    Expires 20 September 2026              [Page 39]


  Internet-Draft                     ATP                        March 2026


     The following ATP-specific status codes — those with no HTTP
     equivalent — are registered with full definitions:

     +======+============+==================================+===========+
     | Code | Name       | Definition                       | Reference |
     +======+============+==================================+===========+
     | 451  | Scope      | The requested action is outside  | This      |
     |      | Violation  | the Authority-Scope declared in  | document, |
     |      |            | the request headers.  The server | Section   |
     |      |            | *MUST* log this event.  The      | 5.5       |
     |      |            | agent *MUST NOT* retry the same  |           |
     |      |            | request without modifying its    |           |
     |      |            | Authority-Scope declaration.     |           |
     |      |            | This is a governance signal, not |           |
     |      |            | a protocol error.                |           |
     +------+------------+----------------------------------+-----------+
     | 550  | Delegation | A sub-agent to which a task was  | This      |
     |      | Failure    | delegated via the DELEGATE       | document, |
     |      |            | method failed to complete the    | Section   |
     |      |            | task within the declared         | 5.5       |
     |      |            | deadline or returned an error.   |           |
     |      |            | The response body *SHOULD*       |           |
     |      |            | contain the sub-agent's error    |           |
     |      |            | details.                         |           |
     +------+------------+----------------------------------+-----------+
     | 551  | Authority  | One or more entries in the       | This      |
     |      | Chain      | Delegation-Chain header cannot   | document, |
     |      | Broken     | be verified as part of a valid   | Section   |
     |      |            | and continuous delegation        | 5.5       |
     |      |            | sequence.  The specific          |           |
     |      |            | unverifiable entry *SHOULD* be   |           |
     |      |            | identified in the response body. |           |
     |      |            | The server *MUST* log this       |           |
     |      |            | event.                           |           |
     +------+------------+----------------------------------+-----------+

                Table 19: ATP-Specific Status Code Definitions

  8.4.  Header Field Registry

     ATP header fields are distinct from HTTP header fields and are
     registered in a new IANA registry: Agent Transfer Protocol Header
     Fields.

     Registry name:  Agent Transfer Protocol Header Fields

     Registration procedure:  Expert Review + published specification
        required.



  Hood                    Expires 20 September 2026              [Page 40]


  Internet-Draft                     ATP                        March 2026


     ATP does not reuse the HTTP Field Name Registry, as ATP header fields
     have different semantics, applicability, and versioning constraints
     from HTTP fields.  HTTP header fields are not automatically valid in
     ATP, and ATP header fields are not valid HTTP fields.

     Initial registrations (all Permanent): ATP-Version, ATP-Method, ATP-
     Status, Agent-ID, Principal-ID, Authority-Scope, Session-ID, Task-ID,
     Delegation-Chain, Priority, TTL, Server-Agent-ID, Attribution-Record,
     Continuation-Token, Supported-Methods.

  8.5.  URI Scheme Registration

     Registration of the atp:// URI scheme per [RFC7595], as described in
     Section 5.8.6 of this document.

  9.  References

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

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

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

     [RFC8179]  Bradner, S. and J. Contreras, "Intellectual Property
                Rights in IETF Technology", BCP 79, RFC 8179,
                DOI 10.17487/RFC8179, May 2017,
                <https://www.rfc-editor.org/rfc/rfc8179>.

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



  Hood                    Expires 20 September 2026              [Page 41]


  Internet-Draft                     ATP                        March 2026


     [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
                QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
                <https://www.rfc-editor.org/rfc/rfc9001>.

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

  9.2.  Informative References

     [A2A]      Linux Foundation, "Agent-to-Agent Protocol Specification",
                2025, <https://a2aprotocol.ai>.

     [ACP]      IBM Research, "Agent Communication Protocol", 2025.

     [ANP]      "Agent Network Protocol", 2025.

     [ATP-CERT] Hood, C., "ATP Agent Certificate Extension", Work in
                Progress, Internet-Draft, draft-hood-atp-agent-cert-00,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                atp-agent-cert-00>.

     [ATP-METHODS]
                Hood, C., "ATP Standard Extended Method Vocabulary", Work
                in Progress, Internet-Draft, draft-hood-atp-standard-
                methods-00, 2026, <https://datatracker.ietf.org/doc/html/
                draft-hood-atp-standard-methods-00>.

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

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

     [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
                Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
                DOI 10.17487/RFC7540, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7540>.

     [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
                and Registration Procedures for URI Schemes", BCP 35,
                RFC 7595, DOI 10.17487/RFC7595, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7595>.

     [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
                June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.



  Hood                    Expires 20 September 2026              [Page 42]


  Internet-Draft                     ATP                        March 2026


  Appendix A.  Authority-Scope Format

     Authority-Scope values are expressed as a space-separated list of
     scope tokens following the pattern: [domain]:[action] or [domain]:*
     for full domain access.  Tokens *MUST* be lowercase ASCII with a
     single colon separator.

     Examples:

     Authority-Scope: calendar:book calendar:query
     Authority-Scope: documents:summarize documents:query knowledge:learn
     Authority-Scope: *:query
     Authority-Scope: booking:* payments:confirm

     Reserved domains (initial set):

        +============+================================================+
        | Domain     | Description                                    |
        +============+================================================+
        | calendar   | Scheduling and time-based resource management  |
        +------------+------------------------------------------------+
        | documents  | Document access, summarization, and annotation |
        +------------+------------------------------------------------+
        | knowledge  | Agent context and memory operations            |
        +------------+------------------------------------------------+
        | booking    | Reservation and resource allocation            |
        +------------+------------------------------------------------+
        | payments   | Financial transactions and confirmations       |
        +------------+------------------------------------------------+
        | agents     | Delegation and collaboration with other agents |
        +------------+------------------------------------------------+
        | escalation | Escalation routing and handler management      |
        +------------+------------------------------------------------+
        | activation | Governed agent package activation (ACTIVATE    |
        |            | method extension)                              |
        +------------+------------------------------------------------+
        | *          | All domains — requires explicit grant; use     |
        |            | with caution                                   |
        +------------+------------------------------------------------+

                   Table 20: Reserved Authority-Scope Domains

  Appendix B.  Example ATP Wire Formats

     The following examples use a human-readable pseudo-wire format with
     HTTP-style headers followed by a JSON body.  The Content-Type for all
     ATP message bodies is application/atp+json.




  Hood                    Expires 20 September 2026              [Page 43]


  Internet-Draft                     ATP                        March 2026


  B.1.  QUERY Request and Response

     ATP/1.0 QUERY
     Agent-ID: agt-7f3a9c2d
     Principal-ID: usr-chris-hood
     Authority-Scope: documents:query knowledge:query
     Session-ID: sess-a1b2c3d4
     Task-ID: task-0042
     TTL: 3000
     Content-Type: application/atp+json

     {
       "task_id": "task-0042",
       "parameters": {
         "intent": "Key arguments against MCP in the context
                  of HTTP overhead",
         "scope": ["documents:research", "knowledge:session"],
         "format": "structured",
         "confidence_threshold": 0.75
       }
     }

     ATP/1.0 200 OK
     Task-ID: task-0042
     Server-Agent-ID: srv-knowledge-01
     Attribution-Record: [signed attribution token]
     Content-Type: application/atp+json

     {
       "status": 200,
       "task_id": "task-0042",
       "result": {
         "results": [{"content": "...", "source": "doc-atp-research",
                      "confidence": 0.91}],
         "result_count": 1
       }
     }

  B.2.  BOOK Request and Response












  Hood                    Expires 20 September 2026              [Page 44]


  Internet-Draft                     ATP                        March 2026


     ATP/1.0 BOOK
     Agent-ID: agt-travel-planner
     Principal-ID: usr-chris-hood
     Authority-Scope: booking:* calendar:book
     Session-ID: sess-trip-2026-04
     Task-ID: task-0107
     Priority: normal
     Content-Type: application/atp+json

     {
       "method": "BOOK",
       "task_id": "task-0107",
       "parameters": {
         "resource_id": "flight-AA2847",
         "principal_id": "usr-chris-hood",
         "time_slot": "2026-04-15T08:00:00Z",
         "options": {"seat_preference": "aisle", "class": "economy"},
         "confirm_immediately": true
       }
     }

     ATP/1.0 200 OK
     Task-ID: task-0107
     Attribution-Record: [signed attribution token]
     Content-Type: application/atp+json

     {
       "status": 200,
       "task_id": "task-0107",
       "result": {
         "booking_id": "BK-2026-0107",
         "status": "confirmed",
         "resource_id": "flight-AA2847",
         "confirmation_code": "XQRT7Y"
       }
     }

  B.3.  ESCALATE Request and Response













  Hood                    Expires 20 September 2026              [Page 45]


  Internet-Draft                     ATP                        March 2026


     ATP/1.0 ESCALATE
     Agent-ID: agt-procurement-03
     Principal-ID: usr-finance-dept
     Authority-Scope: booking:* payments:confirm
     Session-ID: sess-procurement-q2
     Task-ID: task-0881
     Priority: urgent
     Content-Type: application/atp+json

     {
       "method": "ESCALATE",
       "task_id": "task-0881",
       "parameters": {
         "task_id": "task-0880",
         "reason": "scope_limit",
         "context": {
           "attempted_action": "BOOK",
           "resource": "vendor-contract-750k",
           "block_reason": "Contract value exceeds agent
                       authorization threshold"
         },
         "recipient": "usr-cfo",
         "deadline": "2026-03-19T09:00:00Z"
       }
     }

     ATP/1.0 202 Accepted
     Task-ID: task-0881
     Server-Agent-ID: srv-escalation-handler
     Content-Type: application/atp+json

     {
       "status": 202,
       "task_id": "task-0881",
       "result": {
         "escalation_id": "ESC-0881",
         "routed_to": "usr-cfo",
         "status": "pending_review",
         "task_paused": true,
         "estimated_review_by": "2026-03-19T09:00:00Z"
       }
     }









  Hood                    Expires 20 September 2026              [Page 46]


  Internet-Draft                     ATP                        March 2026


  Appendix C.  Comparison Table

     +==============+================+=======+======+===================+
     |Criterion     | ATP            |HTTP/  |gRPC  | A2A / MCP         |
     |              |                |REST   |      |                   |
     +==============+================+=======+======+===================+
     |Agent-native  | Yes            |No     |No    | Partial           |
     |methods       |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Intent        | Native         |None   |None  | Messaging layer   |
     |semantics at  |                |       |      | only              |
     |protocol level|                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Built-in agent| Yes            |No     |No    | No                |
     |identity      |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Authority     | Protocol-level |None   |None  | Application-layer |
     |scope         |                |       |      |                   |
     |enforcement   |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Built-in      | Yes            |No     |No    | Varies by impl.   |
     |attribution/  |                |       |      |                   |
     |audit         |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Transport     | TCP/UDP/QUIC   |TCP/TLS|HTTP/2| HTTP              |
     |flexibility   |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Escalation as | Yes            |No     |No    | No                |
     |first-class   |                |       |      |                   |
     |primitive     |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Ecosystem     | Proposed       |Mature |Mature| Emerging          |
     |maturity      |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Governance/   | Native         |Manual/|Manual| Limited           |
     |observability |                |bolt-on|      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Method        | Yes (Expert    |Frozen |N/A   | N/A               |
     |registry      | Review)        |(IETF  |      |                   |
     |extensibility |                |Review)|      |                   |
     +--------------+----------------+-------+------+-------------------+
     |Open core /   | Yes            |Yes    |Yes   | Yes               |
     |royalty-free  |                |       |      |                   |
     +--------------+----------------+-------+------+-------------------+

                Table 21: ATP Compared to Existing Approaches





  Hood                    Expires 20 September 2026              [Page 47]


  Internet-Draft                     ATP                        March 2026


     HTTP's method registry (registered with IETF Review per [RFC9110]) is
     effectively frozen for new semantic methods because any new HTTP
     method must be backward-compatible with existing HTTP infrastructure
     globally.  ATP's Expert Review + published spec procedure enables the
     protocol to evolve its method vocabulary as the agent ecosystem
     develops, without the backward-compatibility constraints of the HTTP
     method space.

  Appendix D.  Glossary

     Agent:  A software system that executes tasks, makes decisions, and
        takes actions without continuous human supervision per
        transaction.

     Agent Transfer Protocol (ATP):  The application-layer protocol
        defined in this document, providing a dedicated transport
        environment for agent traffic.

     Agent-ID:  A unique identifier for a specific agent instance, present
        in all ATP request headers.  In the base spec, self-asserted.
        With [ATP-CERT], cryptographically bound to a verified identity.

     Attribution Record:  A signed, logged record of an agent action,
        sufficient for audit and compliance purposes.

     Authority-Scope:  A declared set of permissions defining what actions
        an agent is authorized to take, expressed as space-separated
        domain:action tokens.

     Delegation Chain:  An ordered record of Agent-IDs representing the
        sequence of delegations that led to the current request.

     ESCALATE:  An ATP method representing an agent's intentional deferral
        of a decision or action to a human principal or higher-authority
        agent.  A first-class method, not a failure code.

     Intent Verb:  An ATP method name expressing the agent's purpose, as
        distinguished from HTTP resource-operation verbs (GET, POST, PUT,
        DELETE).

     Method Registry:  The IANA-maintained registry of valid ATP method
        names and their specifications.  Registration requires Expert
        Review and a published specification.

     Principal:  The human, organization, or system that authorized an
        agent to act and is accountable for its actions.

     Principal-ID:  The identifier of the principal on whose behalf an



  Hood                    Expires 20 September 2026              [Page 48]


  Internet-Draft                     ATP                        March 2026


        agent operates, present in all ATP request headers.

     Scope-Enforcement Point (SEP):  An ATP-aware infrastructure component
        — load balancer, gateway, proxy — that enforces Authority-Scope
        compliance on ATP requests without application-layer access.
        Requires [ATP-CERT].

     Scope Violation (451):  An ATP status code returned when an agent
        requests an action outside its declared Authority-Scope.  A
        governance signal, not a protocol error. *MUST* be logged.

     Session:  An ATP persistent connection context shared across multiple
        method invocations within a single agent workflow.

     551 Authority Chain Broken:  An ATP status code returned when one or
        more entries in the Delegation-Chain header cannot be verified as
        part of a valid and continuous delegation sequence. *MUST* be
        logged.

  Author's Address

     Chris Hood
     Nomotic, Inc.
     Email: chris@nomotic.ai
     URI:   https://nomotic.ai


























  Hood                    Expires 20 September 2026              [Page 49]


