# drafts

name: draft-hood-agtp-merchant-identity
rev: 01
title: AGTP Merchant Identity and Agentic Commerce Binding
time: 2026-04-22T14:20:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-24T14:20:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:47.115455+00:00
source: ietf
abstract:
  The Agent Transfer Protocol (AGTP) specifies the sending side of an
     agentic transaction: agent identity, Authority-Scope enforcement,
     Budget- Limit declaration, and a signed Attribution-Record on every
     method invocation.  The receiving side of a PURCHASE transaction --
     the merchant or service provider -- has no equivalent protocol-level
     identity or verification mechanism.  This is the merchant identity
     gap.

     This document specifies the AGTP Merchant Identity and Agentic
     Commerce Binding.  It defines the Merchant Manifest Document, a
     signed identity record structurally parallel to the Agent Manifest
     Document; the Merchant Genesis, the origin document from which a
     merchant's canonical identifier is derived; Merchant Trust Tiers
     aligned with AGTP Trust Tier semantics; and the protocol integration
     points at which merchant identity is verified.  These include the
     PURCHASE method handshake, the DISCOVER method result surface, and
     the Attribution-Record.  This document also defines the Intent-
     Assertion header for portable, detached principal- authorized intent,
     the Cart-Digest mechanism for multi-line-item transactions, and the
     455 Counterparty Unverified status code.  Together these mechanisms
     close the verification loop between agent and merchant within AGTP's
     governance model.

     Version 01 aligns the merchant identity model with AGTP v05.
     Merchant Trust Tier 1 now supports three equivalent verification
     paths (dns- anchored, log-anchored, hybrid) matching the base AGTP
     verification paths, replacing v00's DNS-only Tier 1 requirement.
     Version 01 also adopts the Agent Genesis taxonomy introduced in
     [AGTP-LOG]: the merchant origin document is the Merchant Genesis,
     superseding the "Merchant Birth Certificate" terminology in v00.

full_text:
  Independent Submission                                           C. Hood
  Internet-Draft                                             Nomotic, Inc.
  Intended status: Informational                             22 April 2026
  Expires: 24 October 2026


            AGTP Merchant Identity and Agentic Commerce Binding
                    draft-hood-agtp-merchant-identity-01

  Abstract

     The Agent Transfer Protocol (AGTP) specifies the sending side of an
     agentic transaction: agent identity, Authority-Scope enforcement,
     Budget- Limit declaration, and a signed Attribution-Record on every
     method invocation.  The receiving side of a PURCHASE transaction --
     the merchant or service provider -- has no equivalent protocol-level
     identity or verification mechanism.  This is the merchant identity
     gap.

     This document specifies the AGTP Merchant Identity and Agentic
     Commerce Binding.  It defines the Merchant Manifest Document, a
     signed identity record structurally parallel to the Agent Manifest
     Document; the Merchant Genesis, the origin document from which a
     merchant's canonical identifier is derived; Merchant Trust Tiers
     aligned with AGTP Trust Tier semantics; and the protocol integration
     points at which merchant identity is verified.  These include the
     PURCHASE method handshake, the DISCOVER method result surface, and
     the Attribution-Record.  This document also defines the Intent-
     Assertion header for portable, detached principal- authorized intent,
     the Cart-Digest mechanism for multi-line-item transactions, and the
     455 Counterparty Unverified status code.  Together these mechanisms
     close the verification loop between agent and merchant within AGTP's
     governance model.

     Version 01 aligns the merchant identity model with AGTP v05.
     Merchant Trust Tier 1 now supports three equivalent verification
     paths (dns- anchored, log-anchored, hybrid) matching the base AGTP
     verification paths, replacing v00's DNS-only Tier 1 requirement.
     Version 01 also adopts the Agent Genesis taxonomy introduced in
     [AGTP-LOG]: the merchant origin document is the Merchant Genesis,
     superseding the "Merchant Birth Certificate" terminology in v00.

  Status of This Memo

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





  Hood                     Expires 24 October 2026                [Page 1]


  Internet-Draft                AGTP-MERCHANT                   April 2026


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

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

     This Internet-Draft will expire on 24 October 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Merchant Identity Gap . . . . . . . . . . . . . . . .   3
       1.2.  Relationship to Payment Networks  . . . . . . . . . . . .   4
       1.3.  Design Principles . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  The Merchant Identity Model . . . . . . . . . . . . . . . . .   7
       3.1.  Merchant Genesis  . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Merchant Trust Tiers  . . . . . . . . . . . . . . . . . .   9
       3.3.  Merchant Lifecycle States . . . . . . . . . . . . . . . .  10
       3.4.  Merchant Manifest Document  . . . . . . . . . . . . . . .  11
       3.5.  Merchant URI Forms  . . . . . . . . . . . . . . . . . . .  12
     4.  Counterparty Verification at PURCHASE . . . . . . . . . . . .  12
       4.1.  Verification Requirement  . . . . . . . . . . . . . . . .  12
       4.2.  Verification at the Receiving Server  . . . . . . . . . .  13
       4.3.  PURCHASE Request Example  . . . . . . . . . . . . . . . .  13
     5.  The Intent-Assertion Header . . . . . . . . . . . . . . . . .  15
       5.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.2.  Intent Assertion Claims . . . . . . . . . . . . . . . . .  16
       5.3.  Forwarding to Payment Networks  . . . . . . . . . . . . .  17
     6.  Cart Context  . . . . . . . . . . . . . . . . . . . . . . . .  17
       6.1.  The Single-Item Limitation  . . . . . . . . . . . . . . .  17
       6.2.  QUOTE with Cart Payload . . . . . . . . . . . . . . . . .  17
       6.3.  PURCHASE Referencing a Cart Digest  . . . . . . . . . . .  19



  Hood                     Expires 24 October 2026                [Page 2]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     7.  DISCOVER Integration  . . . . . . . . . . . . . . . . . . . .  19
       7.1.  Merchant Queries via DISCOVER . . . . . . . . . . . . . .  19
       7.2.  Unified DISCOVER Queries  . . . . . . . . . . . . . . . .  20
     8.  455 Counterparty Unverified . . . . . . . . . . . . . . . . .  20
       8.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .  20
       8.2.  Retry Semantics . . . . . . . . . . . . . . . . . . . . .  21
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
       9.1.  Merchant Identity Forgery . . . . . . . . . . . . . . . .  21
       9.2.  Manifest Substitution at Purchase . . . . . . . . . . . .  22
       9.3.  Intent Assertion Replay . . . . . . . . . . . . . . . . .  22
       9.4.  Cart-Digest Collision . . . . . . . . . . . . . . . . . .  22
       9.5.  Merchant Lifecycle Lag  . . . . . . . . . . . . . . . . .  23
       9.6.  Dispute Policy URI Tampering  . . . . . . . . . . . . . .  23
       9.7.  Privacy Considerations  . . . . . . . . . . . . . . . . .  23
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
       10.1.  Status Code Registration . . . . . . . . . . . . . . . .  24
       10.2.  Header Field Registration  . . . . . . . . . . . . . . .  24
       10.3.  Authority-Scope Domain Registration  . . . . . . . . . .  25
       10.4.  Document Type Registrations  . . . . . . . . . . . . . .  25
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  26
       11.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Changes from v00 . . . . . . . . . . . . . . . . . .  27
     Appendix B.  Deployment Considerations  . . . . . . . . . . . . .  29
       B.1.  Governance Platform Scope . . . . . . . . . . . . . . . .  29
       B.2.  MNS Co-location . . . . . . . . . . . . . . . . . . . . .  29
       B.3.  Payment Network Integration Path  . . . . . . . . . . . .  29
     Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  29
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  30

  1.  Introduction

  1.1.  The Merchant Identity Gap

     AGTP today provides strong guarantees for the sending side of an
     agent transaction.  A PURCHASE invocation carries a cryptographically
     derived Agent-ID, a Principal-ID identifying the accountable human or
     organization, an Authority-Scope declaration (including payments:
     purchase), a Budget-Limit enforced at invocation time, and a signed
     Attribution-Record retained for audit.  The requesting agent's
     governance context is fully expressed at the protocol layer.










  Hood                     Expires 24 October 2026                [Page 3]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     The receiving side has no equivalent.  An AGTP PURCHASE currently
     resolves to a network endpoint with no protocol-level assertion of
     the receiving party's identity, lifecycle state, legal entity,
     payment network acceptance, or dispute policy.  An agent with
     payments: purchase scope will transact with any endpoint its
     principal (or the upstream orchestration logic) directs it toward.
     There is no protocol-level signal distinguishing a verified merchant
     of record from an endpoint that merely answers on the expected port.

     This gap has direct operational consequences as agent-driven commerce
     scales:

     *  Payment networks and card issuers extending protection to agent-
        initiated transactions require verifiable identity on both parties
        to the transaction, not just the agent.

     *  Dispute investigation requires a cryptographically linked record
        of both the initiating agent and the merchant counterparty at the
        time of the transaction.

     *  Merchants suspended for fraud, chargebacks, or regulatory action
        have no mechanism to be removed from the agent-visible transaction
        surface in the absence of a governed merchant directory.

     *  Agents cannot distinguish a merchant whose identity has been
        verified from one that has merely published a service endpoint.

     This document closes the gap by introducing a merchant-side identity
     structure that mirrors the agent-side identity structure already
     specified in [AGTP].

  1.2.  Relationship to Payment Networks

     This specification is a transport-layer identity and verification
     mechanism for merchant counterparties.  It does not define payment
     credential handling, tokenization, authorization messages to card
     networks, or settlement.  Those belong to payment-rail specifications
     operated by issuers, networks, and acquirers.













  Hood                     Expires 24 October 2026                [Page 4]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     The relationship is complementary.  Payment-network programs that
     extend protection, fraud coverage, or dispute handling to agent-
     initiated transactions need verifiable identity for both the agent
     and the merchant.  AGTP establishes verifiable agent identity through
     the Agent Genesis and Agent Manifest Document (see [AGTP-LOG] for the
     taxonomy introduced in AGTP v05).  This document extends the same
     structural model to the merchant side, producing an Attribution-
     Record that names both counterparties cryptographically.  Payment
     networks consume that record as an input to their own authorization
     and dispute processes; they do not need to speak AGTP to do so.

  1.3.  Design Principles

     *Structural parallelism.* Merchant identity uses the same document
     formats, trust tiers, lifecycle states, and governance zone semantics
     as agent identity.  A governance platform that registers agents
     registers merchants through the same registry and the same
     cryptographic machinery.

     *Verification at PURCHASE.* Merchant identity is verified by the
     requesting agent immediately before executing PURCHASE.  The
     verification result is recorded in the Attribution-Record.  A
     verification failure is a 455 Counterparty Unverified response, not a
     protocol error.

     *Discovery surfaces both sides.* The DISCOVER method defined in
     [AGTP-DISCOVER] returns Agent Manifest Documents for agent queries.
     This document extends DISCOVER to optionally return Merchant Manifest
     Documents when the query intent targets a transactional counterparty
     rather than a capability-providing agent.

     *Portable intent.* The Intent-Assertion header carries a detached,
     signed summary of principal-authorized purchase intent that can be
     forwarded to non-AGTP counterparties (payment networks, card issuers,
     acquirers) as standalone evidence without requiring those
     counterparties to speak AGTP.

     *Payment-rail neutrality.* Nothing in this specification binds the
     merchant identity model to any particular card network, digital
     wallet, or settlement system.  Merchant Manifests declare accepted
     payment network identifiers as an informational field; enforcement
     remains the responsibility of the payment rail.









  Hood                     Expires 24 October 2026                [Page 5]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  2.  Terminology

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

     Merchant:  A legal entity that offers goods or services for purchase
        and serves as the receiving counterparty to an AGTP PURCHASE
        invocation.  A merchant is identified by a canonical Merchant-ID
        and represented by a Merchant Manifest Document.

     Merchant-ID:  A unique identifier for a specific merchant entity,
        derived from the hash of the Merchant Genesis.  Carried in the
        Merchant-ID request header on PURCHASE invocations and in the
        Attribution- Record.  Format: 256-bit hex-encoded value or domain-
        anchored URI of the form agtp://merchant.example.tld/merchant.

     Merchant Genesis:  The permanent, cryptographically signed origin
        document issued to a merchant at registration time by a governance
        platform.  The Merchant Genesis is the origin record from which
        the canonical Merchant-ID is derived.  Structurally parallel to
        the Agent Genesis defined in [AGTP-LOG] terminology (formerly
        termed "Agent Birth Certificate" in AGTP drafts prior to v05).
        Fields include legal entity name, registered org domain, accepted
        payment networks, merchant category code, dispute and refund
        policy URIs, lifecycle state, governance zone, and
        verification_path.  Issued once per merchant; permanently bound;
        never reissued.  Supersedes the "Merchant Birth Certificate"
        terminology in v00.

     Merchant Manifest Document:  A cryptographically signed application/
        agtp+json document returned when a merchant URI is resolved.
        Derived directly from the Merchant Genesis and current registry
        record.  Structurally parallel to the Agent Manifest Document
        defined in [AGTP] Section 5.5.  Contains identity, trust tier,
        lifecycle state, accepted payment networks, dispute policy
        reference, and governance zone.  Never contains executable
        content.

     Merchant Trust Tier:  A classification (1, 2, or 3) assigned to a









  Hood                     Expires 24 October 2026                [Page 6]


  Internet-Draft                AGTP-MERCHANT                   April 2026


        merchant at registration time, aligned with the Agent Trust Tier
        semantics defined in [AGTP] Section 5.2.  Tier 1 requires one of
        three equivalent verification paths (dns-anchored, log-anchored,
        hybrid) per [AGTP] Section 5.2, plus a signed business-entity
        attestation from the governance platform.  Tier 2 is org-asserted
        without cryptographic verification of organizational identity.
        Tier 3 is experimental and *MUST NOT* appear in production
        PURCHASE flows.

     Intent-Assertion:  A detached, signed JWT-format [RFC7519] token that
        summarizes principal-authorized purchase intent.  Contains the
        principal ID, agent ID, merchant ID, item or cart digest, amount
        ceiling, currency, issuance timestamp, expiry, and a single-use
        nonce.  Carried in the Intent-Assertion request header and
        forwardable to payment networks as standalone evidence of
        authenticated principal intent.

     Cart-Digest:  A cryptographic digest of a structured cart payload
        returned by a QUOTE invocation.  Referenced in a subsequent
        PURCHASE invocation to bind the purchased cart to the quoted cart
        without requiring retransmission of line-item detail.  Format:
        hash algorithm prefix followed by hex-encoded digest (e.g.,
        sha256:3a9f2c1d...).

     Counterparty Verification:  The process by which an agent, before
        executing PURCHASE, retrieves the Merchant Manifest Document for
        the intended merchant, verifies its signature and lifecycle state,
        and records the verification result in the Attribution-Record.

     MNS (Merchant Name Service):  The merchant-side analogue of the Agent
        Name Service defined in [AGTP-DISCOVER].  An AGTP-aware server
        that maintains an indexed registry of Merchant Manifest Documents
        and answers DISCOVER queries targeted at merchant entities.  An
        MNS *MAY* be co-located with an ANS or operated separately.  Acts
        as a Scope- Enforcement Point for merchant discovery traffic.

  3.  The Merchant Identity Model

  3.1.  Merchant Genesis

     The Merchant Genesis is the origin record of a merchant's existence
     in the AGTP governance fabric.  It is issued by a governance platform
     at merchant registration time through a process analogous to Agent
     Genesis issuance ([AGTP] Section 5.7).  Supersedes the "Merchant
     Birth Certificate" terminology in v00; see [AGTP-LOG] for the
     taxonomy adopted in v01.

     The required fields of a Merchant Genesis are:



  Hood                     Expires 24 October 2026                [Page 7]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     {
       "document_type": "merchant-genesis",
       "schema_version": "1.0",
       "canonical_id": "7c2f9a3e1b8d4f6a...",
       "legal_entity_name": "Acme Commerce, Inc.",
       "org_domain": "acme.tld",
       "merchant_category_code": "5411",
       "registered_jurisdiction": "US-DE",
       "governance_zone": "zone:retail-verified",
       "accepted_payment_networks": ["visa", "mastercard", "amex", "discover"],
       "dispute_policy_uri": "agtp://acme.tld/merchant/dispute-policy",
       "refund_policy_uri": "agtp://acme.tld/merchant/refund-policy",
       "trust_tier": 1,
       "verification_path": "dns-anchored",
       "activated_at": "2026-03-15T12:00:00Z",
       "activating_principal": "agtp-platform-acme",
       "genesis_hash": "7c2f9a3e1b8d4f6a...",
       "signature": {
         "algorithm": "ES256",
         "key_id": "gov-platform-key-01",
         "value": "[base64-encoded-signature]"
       }
     }

                       Figure 1: Merchant Genesis Schema

     The canonical_id field *MUST* equal the genesis_hash, a 256-bit
     cryptographic hash computed over the canonicalized genesis content
     excluding the signature field.  This hash is the basis of the
     merchant's Merchant-ID and is used wherever the merchant is
     identified in AGTP wire-level structures.

     The merchant_category_code field *SHOULD* follow the ISO 18245
     Merchant Category Code standard where applicable.  Governance
     platforms operating outside that classification *MAY* define
     alternate codes provided they are documented in the governance zone
     definition.

     The accepted_payment_networks array is informational.  It declares
     which payment networks the merchant represents itself as accepting.
     Payment-rail enforcement of this declaration is out of scope for this
     document; the field supports pre-flight filtering by requesting
     agents and ranking by Merchant Name Service implementations.








  Hood                     Expires 24 October 2026                [Page 8]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  3.2.  Merchant Trust Tiers

     Merchant Trust Tiers align with the Agent Trust Tier semantics in
     [AGTP] Section 5.2, including the three equivalent verification paths
     introduced in AGTP v05:

     +==============+===========================+=============+==========+
     | Tier         | Verification Paths        | Business    | Registry |
     |              | (any one sufficient)      | Entity      | Visible  |
     |              |                           | Attestation |          |
     +==============+===========================+=============+==========+
     | 1 - Verified | dns-anchored              | Required    | Yes      |
     |              | ([RFC8555]); OR log-      |             |          |
     |              | anchored ([RFC9162] /     |             |          |
     |              | [RFC9943]); OR hybrid     |             |          |
     |              | (DNS + blockchain         |             |          |
     |              | signature)                |             |          |
     +--------------+---------------------------+-------------+----------+
     | 2 - Org-     | None beyond self-         | Not         | Yes,     |
     | Asserted     | declaration               | required    | with     |
     |              |                           |             | warning  |
     +--------------+---------------------------+-------------+----------+
     | 3 -          | None                      | Not         | No       |
     | Experimental |                           | required    |          |
     +--------------+---------------------------+-------------+----------+

                      Table 1: Merchant Trust Tier Summary

     Trust Tier 1 merchant registration *MUST* satisfy two conditions:

     1.  One of the three verification paths defined in [AGTP] Section 5.2
         (dns-anchored, log-anchored, or hybrid) *MUST* be completed at
         registration time.  The verification path used *MUST* be recorded
         in the Merchant Genesis verification_path field and surfaced in
         the Merchant Manifest Document.

     2.  A governance-platform-signed attestation *MUST* record that the
         registering party has provided evidence of the claimed legal
         entity's existence and standing.  The form of that evidence
         (incorporation document, tax identifier, equivalent
         jurisdictional registration) is governance-platform-defined and
         *MUST* be documented in the governance zone specification.  The
         business entity attestation is an additional requirement for
         merchants beyond the base AGTP verification paths, reflecting the
         elevated accountability needs of agentic commerce.

     Path-specific considerations for merchants:




  Hood                     Expires 24 October 2026                [Page 9]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     *  dns-anchored registration is appropriate for merchants that
        operate a verified DNS presence under their registered org_domain.
        This is the most common deployment pattern for established
        commercial entities.

     *  log-anchored registration enables merchants whose governance
        platform participates in an AGTP transparency log per [AGTP-LOG].
        This path is particularly applicable to merchants operating
        without a traditional DNS footprint, to marketplace-aggregated
        merchants represented by platform governance, and to cross-
        jurisdictional commerce where DNS ownership verification is
        impractical.

     *  hybrid registration applies to merchants with both a verified DNS
        presence and a blockchain-anchored identity per [AGTP-WEB3].
        Web3-native commerce deployments typically use this path.

     Trust Tier 2 merchants *MUST* have their Merchant Manifest Document
     include a trust_warning field with value "legal-entity-unverified".
     Requesting agents *SHOULD* surface this warning to principals before
     executing a PURCHASE against a Tier 2 merchant, or *MAY* reject Tier
     2 merchants entirely based on governance policy.

     Trust Tier 3 merchants *MUST NOT* appear in production PURCHASE
     flows.  They exist for development and integration testing only.

  3.3.  Merchant Lifecycle States

     Merchants occupy one of four lifecycle states mirroring the agent
     lifecycle states in [AGTP] Section 5.8:

            +============+========================================+
            | State      | Meaning                                |
            +============+========================================+
            | Active     | Merchant is operational and eligible   |
            |            | to receive PURCHASE                    |
            +------------+----------------------------------------+
            | Suspended  | Temporarily blocked (fraud review,     |
            |            | chargeback threshold, compliance hold) |
            +------------+----------------------------------------+
            | Revoked    | Permanently removed; canonical         |
            |            | Merchant-ID retired                    |
            +------------+----------------------------------------+
            | Deprecated | Business ceased operations; canonical  |
            |            | Merchant-ID retired                    |
            +------------+----------------------------------------+

                       Table 2: Merchant Lifecycle States



  Hood                     Expires 24 October 2026               [Page 10]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     A merchant in any state other than Active *MUST NOT* be treated as a
     valid counterparty by a requesting agent.  The expected response to a
     PURCHASE targeting a non-Active merchant is 455 Counterparty
     Unverified.

     Governance platforms *MUST* update the merchant's Merchant Manifest
     Document signature within 60 seconds of a lifecycle state transition
     and *MUST* notify any Merchant Name Service instances indexing the
     merchant within the same window.

  3.4.  Merchant Manifest Document

     The Merchant Manifest Document is the wire-level representation of
     merchant identity, returned in response to resolution of a merchant
     URI.  It is derived from the Merchant Genesis and current registry
     record; it is never manually authored.

     {
       "document_type": "agtp-merchant-manifest",
       "schema_version": "1.0",
       "canonical_id": "7c2f9a3e1b8d4f6a...",
       "merchant_label": "acme-commerce",
       "legal_entity_name": "Acme Commerce, Inc.",
       "org_domain": "acme.tld",
       "merchant_category_code": "5411",
       "registered_jurisdiction": "US-DE",
       "governance_zone": "zone:retail-verified",
       "lifecycle_state": "Active",
       "trust_tier": 1,
       "verification_path": "dns-anchored",
       "accepted_payment_networks": ["visa", "mastercard", "amex", "discover"],
       "dispute_policy_uri": "agtp://acme.tld/merchant/dispute-policy",
       "refund_policy_uri": "agtp://acme.tld/merchant/refund-policy",
       "activated_at": "2026-03-15T12:00:00Z",
       "last_updated": "2026-04-10T09:12:44Z",
       "genesis_hash": "7c2f9a3e1b8d4f6a...",
       "signature": {
         "algorithm": "ES256",
         "key_id": "gov-platform-key-01",
         "value": "[base64-encoded-signature]"
       }
     }

                  Figure 2: Merchant Manifest Document Schema







  Hood                     Expires 24 October 2026               [Page 11]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     Implementations *MUST* verify the signature against the governance
     platform's published key before trusting any field.  An unsigned or
     invalid Merchant Manifest *MUST* be rejected with the same severity
     as an unsigned Agent Manifest.

     The genesis_hash field provides a cryptographic link from the
     manifest back to the Merchant Genesis.  Implementations performing
     long-term audit reconstruction *MAY* use this hash to retrieve the
     archived Merchant Genesis from the governance platform.

  3.5.  Merchant URI Forms

     Merchant URIs follow the AGTP URI scheme defined in [AGTP]
     Section 5.1, using a reserved /merchant path component in place of
     /agents:

     agtp://acme.tld/merchant
     agtp://acme.tld/merchant/acme-commerce

                          Figure 3: Merchant URI Forms

     The single-label form (agtp://acme.tld/merchant) resolves to the
     organization's primary merchant record.  The labeled form
     (agtp://acme.tld/merchant/[merchant-label]) resolves to a specific
     merchant record for organizations operating multiple merchant
     identities under a single org domain (e.g., multi-brand retailers).

     Canonical-identifier URIs of the form agtp://[canonical-id].merchant
     are also supported, analogous to the canonical agent URI form.

  4.  Counterparty Verification at PURCHASE

  4.1.  Verification Requirement

     An agent with payments:purchase in its Authority-Scope *MUST* perform
     counterparty verification before executing PURCHASE against any
     merchant.  Counterparty verification consists of:

     1.  Resolving the merchant URI (from the intended PURCHASE target) to
         retrieve the Merchant Manifest Document.

     2.  Verifying the manifest's signature against the governance
         platform's published key.

     3.  Verifying the merchant's lifecycle_state is Active.






  Hood                     Expires 24 October 2026               [Page 12]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     4.  Verifying the merchant's trust_tier meets or exceeds the
         threshold declared in the agent's governance policy for the
         current transaction amount.

     5.  Computing the manifest fingerprint (SHA-256 hash of the canonical
         manifest bytes) and carrying it in the Merchant-Manifest-
         Fingerprint request header.

     Any of these steps failing *MUST* result in the PURCHASE not being
     sent.  The requesting agent's runtime *SHOULD* surface the specific
     verification failure to the principal or governance platform; it
     *MUST NOT* silently fall back to an unverified transaction.

  4.2.  Verification at the Receiving Server

     A receiving AGTP server that accepts PURCHASE invocations *MUST*:

     1.  Require the Merchant-ID request header to be present.

     2.  Require the Merchant-Manifest-Fingerprint request header to be
         present and to match the fingerprint of the server's current
         Merchant Manifest Document.

     3.  Return 455 Counterparty Unverified if either header is absent, if
         the Merchant-ID does not match the server's canonical ID, or if
         the fingerprint does not match.

     This ensures that the manifest verified by the requesting agent is
     the same manifest the receiving server currently presents.  An attack
     in which a requesting agent is redirected to a different endpoint
     than it verified is caught at the fingerprint check.

  4.3.  PURCHASE Request Example

     The following request illustrates a verified PURCHASE invocation
     carrying merchant identity binding and a detached intent assertion:















  Hood                     Expires 24 October 2026               [Page 13]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     AGTP/1.0 PURCHASE
     Agent-ID: agtp://agtp.traveler.tld/agents/trip-planner
     Principal-ID: usr-chris-hood
     Authority-Scope: payments:purchase merchant:verify intent:assert
     Session-ID: sess-trip-2026-04
     Task-ID: task-purch-0421
     Merchant-ID: agtp://acme.tld/merchant/acme-commerce
     Merchant-Manifest-Fingerprint: sha256:3a9f2c1d8b7e4a6f...
     Intent-Assertion: eyJhbGciOiJFUzI1NiIsImtpZCI6InByaW4ta2V5LTAxIn0...
     Cart-Digest: sha256:7c2f9a3e1b8d4f6a...
     Budget-Limit: USD=850.00
     Content-Type: application/agtp+json

     {
       "method": "PURCHASE",
       "task_id": "task-purch-0421",
       "parameters": {
         "cart_quote_id": "qt-7f3a9c",
         "principal_id": "usr-chris-hood",
         "amount": {"value": 842.17, "currency": "USD"},
         "payment_method": "tok-amex-default",
         "confirm_immediately": true
       }
     }

               Figure 4: PURCHASE with Merchant Identity Binding

     The merchant server validates the merchant headers, accepts the
     purchase, and returns an Attribution-Record naming both
     counterparties:





















  Hood                     Expires 24 October 2026               [Page 14]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     AGTP/1.0 200 OK
     Task-ID: task-purch-0421
     Server-Agent-ID: agtp://acme.tld/merchant/acme-commerce
     Attribution-Record: [signed attribution token]
     Content-Type: application/agtp+json

     {
       "status": 200,
       "task_id": "task-purch-0421",
       "result": {
         "order_id": "ORD-2026-0421-8847",
         "confirmation_code": "AQRT9X",
         "status": "confirmed",
         "amount_charged": {"value": 842.17, "currency": "USD"}
       },
       "attribution": {
         "agent_id": "agtp://agtp.traveler.tld/agents/trip-planner",
         "principal_id": "usr-chris-hood",
         "merchant_id": "agtp://acme.tld/merchant/acme-commerce",
         "merchant_fingerprint": "sha256:3a9f2c1d8b7e4a6f...",
         "intent_assertion_jti": "ia-4f7e1a2b",
         "method": "PURCHASE",
         "timestamp": "2026-04-15T14:22:18Z",
         "signature": {
           "algorithm": "ES256",
           "key_id": "merchant-key-acme-01",
           "value": "[base64-encoded-signature]"
         }
       }
     }

            Figure 5: PURCHASE Response with Dual-Party Attribution

     The Attribution-Record now names the agent, the principal, and the
     merchant, each cryptographically bound through their respective
     Genesis derivatives.  This is the record consumed by downstream
     audit, dispute resolution, and payment-network protection programs.

  5.  The Intent-Assertion Header

  5.1.  Purpose

     The Intent-Assertion header carries a detached, signed representation
     of principal-authorized purchase intent.  It exists so that non-AGTP
     counterparties -- payment networks, card issuers, acquiring banks,
     dispute processors -- can verify principal intent without parsing a
     full AGTP message or operating AGTP infrastructure.




  Hood                     Expires 24 October 2026               [Page 15]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     An Intent Assertion is a JWT [RFC7519] signed by the principal's
     governance key (or a delegated signing key bound to the principal's
     identity) carrying the minimum field set required to link a purchase
     to an authenticated principal decision.

  5.2.  Intent Assertion Claims

     +================+=========+========================================+
     | Claim          | Type    | Description                            |
     +================+=========+========================================+
     | iss            | string  | Issuing governance                     |
     |                |         | platform identifier                    |
     +----------------+---------+----------------------------------------+
     | sub            | string  | Principal-ID of the                    |
     |                |         | authorizing principal                  |
     +----------------+---------+----------------------------------------+
     | aud            | string  | Merchant-ID of the                     |
     |                |         | intended counterparty                  |
     +----------------+---------+----------------------------------------+
     | agent_id       | string  | Agent-ID of the executing              |
     |                |         | agent                                  |
     +----------------+---------+----------------------------------------+
     | item_digest    | string  | Hash of purchased item or              |
     |                |         | cart digest                            |
     +----------------+---------+----------------------------------------+
     | amount_ceiling | object  | {value, currency} maximum              |
     |                |         | authorized                             |
     +----------------+---------+----------------------------------------+
     | nbf            | integer | Not-before timestamp                   |
     |                |         | (seconds since epoch)                  |
     +----------------+---------+----------------------------------------+
     | exp            | integer | Expiry timestamp (seconds              |
     |                |         | since epoch)                           |
     +----------------+---------+----------------------------------------+
     | jti            | string  | Unique assertion                       |
     |                |         | identifier for anti-replay             |
     +----------------+---------+----------------------------------------+
     | iat            | integer | Issued-at timestamp                    |
     +----------------+---------+----------------------------------------+

                      Table 3: Intent Assertion JWT Claims

     Implementations *MUST* reject Intent Assertions whose exp is in the
     past, whose aud does not match the Merchant-ID in the PURCHASE
     request, or whose agent_id does not match the Agent-ID in the
     PURCHASE request.  Assertions *MUST* be single-use: the jti is
     recorded in the Attribution-Record and *MUST NOT* be accepted a
     second time.



  Hood                     Expires 24 October 2026               [Page 16]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     Recommended validity period: 300 seconds.  Intent Assertions are not
     designed to persist; they cover the interval between principal
     authorization and transaction execution.

  5.3.  Forwarding to Payment Networks

     The Intent Assertion is structured as a standalone JWT precisely so
     that it can be forwarded.  A payment network receiving a merchant's
     authorization request *MAY* require the merchant to forward the
     Intent Assertion alongside the standard payment message.  The payment
     network verifies the signature against the issuing governance
     platform's public key and treats a valid assertion as evidence of
     authenticated principal intent for the purposes of that network's
     authorization and dispute policies.

     The specific mechanism for forwarding the Intent Assertion to a
     payment network, and the network's treatment of a valid assertion, is
     out of scope for this document.  What this specification guarantees
     is that the assertion exists, is cryptographically verifiable without
     AGTP, and is bound to the principal, agent, and merchant named in the
     PURCHASE.

  6.  Cart Context

  6.1.  The Single-Item Limitation

     The PURCHASE method as defined in [AGTP-METHODS] accepts a single
     item parameter and a single amount.  Real-world agentic commerce
     transactions frequently involve multiple line items, tax, shipping,
     and per-line merchant-of-record variation.  This document defines a
     Cart Context mechanism layered over the existing QUOTE and PURCHASE
     methods to accommodate structured carts without modifying the base
     method definitions.

  6.2.  QUOTE with Cart Payload

     A requesting agent constructs a structured cart and submits it via
     QUOTE.  The merchant server returns a signed cart_digest binding the
     quoted cart content to a unique quote identifier.












  Hood                     Expires 24 October 2026               [Page 17]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     AGTP/1.0 QUOTE
     Agent-ID: agtp://agtp.traveler.tld/agents/trip-planner
     Principal-ID: usr-chris-hood
     Authority-Scope: budget:query merchant:query
     Merchant-ID: agtp://acme.tld/merchant/acme-commerce
     Session-ID: sess-trip-2026-04
     Task-ID: task-quote-0421
     Content-Type: application/agtp+json

     {
       "method": "QUOTE",
       "task_id": "task-quote-0421",
       "parameters": {
         "cart": {
           "lines": [
             {"sku": "FLIGHT-AA2847", "qty": 1, "unit_price": 487.00},
             {"sku": "HOTEL-MRTN-2N", "qty": 1, "unit_price": 298.00},
             {"sku": "CAR-COMPACT-3D", "qty": 1, "unit_price": 42.17}
           ],
           "currency": "USD",
           "tax": 15.00,
           "shipping": 0.00
         }
       }
     }

                      Figure 6: QUOTE with Structured Cart

     The response contains the quote identifier and the signed cart
     digest:

     {
       "status": 200,
       "task_id": "task-quote-0421",
       "result": {
         "quote_id": "qt-7f3a9c",
         "cart_digest": "sha256:7c2f9a3e1b8d4f6a...",
         "total": {"value": 842.17, "currency": "USD"},
         "quote_valid_until": "2026-04-15T14:52:18Z",
         "quote_signature": {
           "algorithm": "ES256",
           "key_id": "merchant-key-acme-01",
           "value": "[base64-encoded-signature]"
         }
       }
     }

                   Figure 7: QUOTE Response with Cart Digest



  Hood                     Expires 24 October 2026               [Page 18]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  6.3.  PURCHASE Referencing a Cart Digest

     The subsequent PURCHASE invocation references the quote identifier
     and carries the cart digest in the Cart-Digest header, binding the
     purchase to the previously quoted cart without retransmission of
     line-item detail.  The merchant server *MUST* verify the digest
     against its stored quote record and *MUST* reject the PURCHASE with
     409 Conflict if the cart digest does not match a valid, unexpired
     quote.

  7.  DISCOVER Integration

  7.1.  Merchant Queries via DISCOVER

     The DISCOVER method defined in [AGTP-DISCOVER] is extended by this
     document to optionally return Merchant Manifest Documents.  A
     requesting agent signals a merchant-oriented discovery query by
     including the result_type parameter with value "merchant":

     AGTP/1.0 DISCOVER
     Agent-ID: agtp://agtp.traveler.tld/agents/trip-planner
     Principal-ID: usr-chris-hood
     Authority-Scope: discovery:query merchant:query
     Session-ID: sess-trip-2026-04
     Task-ID: task-disc-merch-01
     Content-Type: application/agtp+json

     {
       "method": "DISCOVER",
       "task_id": "task-disc-merch-01",
       "parameters": {
         "intent": "Ski rental in Park City accepting Amex",
         "result_type": "merchant",
         "merchant_category_codes": ["7999", "5941"],
         "accepted_payment_networks": ["amex"],
         "trust_tier_min": 1,
         "governance_zone": "zone:retail-verified",
         "limit": 5
       }
     }

                  Figure 8: DISCOVER Query Targeting Merchants

     The ANS or MNS server returns a ranked result set of Merchant
     Manifest Documents matching the query constraints.  Ranking follows
     the same composite scoring model defined in [AGTP-DISCOVER]
     Section 3.4, with the following adjustments for merchant queries:




  Hood                     Expires 24 October 2026               [Page 19]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     *  behavioral_trust_score is replaced by merchant_reliability_ score,
        a governance-platform-assigned score reflecting the merchant's
        dispute rate, chargeback history, and fulfillment track record
        within the governance zone.

     *  capability_match_score is replaced by catalog_match_score, a
        relevance score between the query intent and the merchant's
        declared catalog categories and merchant category code.

     Merchant reliability scoring methodology is governance-platform-
     defined and *MUST* be documented in the governance zone
     specification.  The raw score *MUST* be present in the Merchant
     Manifest Document and signed by the governance platform; it *MUST
     NOT* be merchant-asserted.

  7.2.  Unified DISCOVER Queries

     A requesting agent *MAY* issue a DISCOVER query with result_type:
     "any" to receive a mixed result set containing both Agent Manifests
     and Merchant Manifests.  This is useful for workflows where the agent
     does not know in advance whether the capability it needs is best
     satisfied by a peer agent or by a merchant transaction (e.g., "find a
     service that can produce a translated legal document" where the
     answer might be either a translation agent or a document-services
     merchant).

     Mixed result sets include a result_class field on each entry with
     value "agent" or "merchant", enabling the requesting agent to route
     each result to the appropriate downstream handling.

  8.  455 Counterparty Unverified

  8.1.  Definition

     This document registers AGTP status code 455 Counterparty Unverified.
     The status is returned in any of the following conditions:

     *  The Merchant-ID request header is absent on a PURCHASE invocation.

     *  The Merchant-Manifest-Fingerprint request header is absent or does
        not match the receiving server's current manifest.

     *  The Merchant-ID does not match the receiving server's canonical
        Merchant-ID.

     *  The agent's pre-flight counterparty verification failed (returned
        by the agent's own runtime before a PURCHASE is sent on the wire).




  Hood                     Expires 24 October 2026               [Page 20]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     *  The target merchant is in a non-Active lifecycle state.

     *  The Merchant Manifest Document signature is invalid.

     The response body *MUST* identify the specific verification failure
     and *MUST* include the governance-platform-signed reason code.  The
     requesting agent *MUST NOT* retry the PURCHASE without re-running
     counterparty verification against a fresh Merchant Manifest Document.

     Status code 455 is a governance signal, not a protocol error, and
     *MUST* be logged by both parties.  It parallels the role of 451 Scope
     Violation and 453 Zone Violation in the AGTP status code space: the
     system caught a governance condition at the protocol layer, before
     any state-modifying side effect.

  8.2.  Retry Semantics

     A 455 response in the following categories is non-retryable without
     remediation:

     *  Merchant in Revoked or Deprecated lifecycle state.

     *  Invalid Merchant Manifest signature.

     *  Merchant-ID mismatch.

     A 455 response in the following categories is retryable after a
     governance-defined interval:

     *  Merchant in Suspended state (retry after state transitions to
        Active).

     *  Fingerprint mismatch due to a legitimate manifest update (retry
        after re-fetching the current manifest).

     The response body *MUST* declare retry-eligibility via a retryable
     boolean field and, where retryable, *MAY* declare a retry_after
     timestamp.

  9.  Security Considerations

  9.1.  Merchant Identity Forgery

     Threat: An attacker publishes a Merchant Manifest Document claiming
     to represent a legitimate merchant without having completed any of
     the Trust Tier 1 verification paths.





  Hood                     Expires 24 October 2026               [Page 21]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     Mitigation: Trust Tier 1 registration requires one of the three
     verification paths defined in [AGTP] Section 5.2 (dns-anchored per
     [RFC8555], log-anchored per [RFC9162] / [RFC9943], or hybrid) plus a
     governance-platform-signed business entity attestation.  The
     governance platform signs every Merchant Manifest; requesting agents
     *MUST* verify the signature against the governance platform's
     published key before trusting the manifest.  An unsigned manifest or
     one signed by an unrecognized platform *MUST* be rejected.
     Requesting agents *SHOULD* maintain a trust list of accepted
     governance platforms per governance zone.

     For dns-anchored merchants, an attacker who does not control the
     claimed domain cannot complete the ACME challenge.  For log-anchored
     merchants, an attacker cannot forge a transparency log inclusion
     proof without compromising the log operator.  For hybrid merchants,
     both DNS and blockchain signature controls must be defeated.  The
     verification path in use is recorded in the Merchant Genesis and
     surfaced in the Manifest, enabling requesting agents to apply path-
     appropriate verification during PURCHASE handshake.

  9.2.  Manifest Substitution at Purchase

     Threat: A requesting agent verifies Merchant Manifest A, but the
     PURCHASE is received by an endpoint serving Merchant Manifest B.

     Mitigation: The Merchant-Manifest-Fingerprint header binds the
     manifest the agent verified to the manifest the receiving server
     presents.  A mismatch produces 455 Counterparty Unverified.  This
     check is cryptographic and cannot be bypassed without compromising
     the governance platform's signing key.

  9.3.  Intent Assertion Replay

     Threat: A captured Intent Assertion is replayed by an attacker to
     authorize an unintended second purchase.

     Mitigation: Intent Assertions carry a unique jti and a short exp.
     Receiving servers *MUST* record the jti in the Attribution-Record and
     *MUST* reject any subsequent request carrying a previously seen jti.
     The recommended maximum validity is 300 seconds; implementations
     *MAY* apply shorter limits.  Governance platforms *SHOULD* maintain a
     zone-scoped cache of consumed jti values for at least the maximum
     validity period.

  9.4.  Cart-Digest Collision

     Threat: An attacker constructs a cart that produces the same digest
     as a different, higher-value cart.



  Hood                     Expires 24 October 2026               [Page 22]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     Mitigation: The Cart-Digest algorithm *MUST* be a cryptographic hash
     function resistant to collision attacks.  SHA-256 is the baseline
     requirement.  The digest *MUST* be computed over a canonical
     serialization of the cart payload to prevent ambiguity between
     equivalent JSON representations.

  9.5.  Merchant Lifecycle Lag

     Threat: A merchant is Revoked for fraud, but the Merchant Name
     Service has not yet propagated the state change.  A requesting agent
     verifies the stale manifest and proceeds with PURCHASE.

     Mitigation: Governance platforms *MUST* propagate lifecycle state
     changes to all indexing MNS servers within 60 seconds.  MNS servers
     *MUST* treat Revocation as urgent deregistration and *MUST* remove
     the merchant from the result index before the next DISCOVER request
     is processed.  Requesting agents with strict assurance requirements
     *MAY* set a maximum manifest age (e.g., re-fetch if the manifest is
     older than 300 seconds) before accepting it for PURCHASE.

  9.6.  Dispute Policy URI Tampering

     Threat: A merchant publishes a dispute policy URI that redirects to a
     different policy after the PURCHASE is complete.

     Mitigation: The dispute_policy_uri field is part of the signed
     Merchant Genesis and is included in the signed Merchant Manifest.
     Requesting agents *SHOULD* retrieve and hash the dispute policy
     document content at verification time and include the hash in the
     Attribution-Record.  Any subsequent change to the policy content can
     be detected by comparing the archived hash to the current content.

  9.7.  Privacy Considerations

     Merchant Manifest Documents contain legal entity information and
     payment network acceptance declarations.  This data is generally
     considered public commercial information and does not trigger the
     same privacy protections as agent or principal identity data.
     However, Merchant Name Service query logs reveal which agents are
     shopping for which kinds of goods and *MUST* be treated with the same
     access controls and retention limits applied to DISCOVER query logs
     under [AGTP-DISCOVER].

     Intent Assertions contain principal identifiers, merchant
     identifiers, and amount ceilings.  These are transactionally
     sensitive.  Intent Assertions *MUST* be treated as confidential
     transport data and *MUST NOT* be logged in forms accessible outside
     the governance zone in which they were issued.



  Hood                     Expires 24 October 2026               [Page 23]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  10.  IANA Considerations

  10.1.  Status Code Registration

     This document requests registration of the following status code in
     the IANA Agent Transfer Protocol Status Codes registry established by
     [AGTP] Section 8.3:

     +======+==============+================================+===========+
     | Code | Name         | Definition                     | Reference |
     +======+==============+================================+===========+
     | 455  | Counterparty | The merchant counterparty in a | This      |
     |      | Unverified   | PURCHASE invocation failed     | document, |
     |      |              | identity verification: the     | Section 7 |
     |      |              | Merchant-ID or Merchant-       |           |
     |      |              | Manifest-Fingerprint is        |           |
     |      |              | absent, does not match, or the |           |
     |      |              | merchant is in a non-Active    |           |
     |      |              | lifecycle state.  Governance   |           |
     |      |              | signal; *MUST* be logged.      |           |
     +------+--------------+--------------------------------+-----------+

                    Table 4: Status Code 455 Registration

  10.2.  Header Field Registration

     This document requests registration of the following header fields in
     the IANA Agent Transfer Protocol Header Fields registry established
     by [AGTP] Section 8.4:

        +===============================+===========+================+
        | Header                        | Status    | Reference      |
        +===============================+===========+================+
        | Merchant-ID                   | Permanent | This document, |
        |                               |           | Section 4.1    |
        +-------------------------------+-----------+----------------+
        | Merchant-Manifest-Fingerprint | Permanent | This document, |
        |                               |           | Section 4.1    |
        +-------------------------------+-----------+----------------+
        | Intent-Assertion              | Permanent | This document, |
        |                               |           | Section 5      |
        +-------------------------------+-----------+----------------+
        | Cart-Digest                   | Permanent | This document, |
        |                               |           | Section 6      |
        +-------------------------------+-----------+----------------+

                     Table 5: Header Field Registrations




  Hood                     Expires 24 October 2026               [Page 24]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  10.3.  Authority-Scope Domain Registration

     This document requests the addition of the following domains to the
     reserved Authority-Scope domain set defined in [AGTP] Appendix A:

                 +==========+===============================+
                 | Domain   | Description                   |
                 +==========+===============================+
                 | merchant | Merchant identity resolution  |
                 |          | and counterparty verification |
                 +----------+-------------------------------+
                 | intent   | Intent Assertion issuance and |
                 |          | validation                    |
                 +----------+-------------------------------+

                       Table 6: Authority-Scope Domain
                                Registrations

     Actions defined for these domains:

     *  merchant:query -- Resolving a Merchant URI and retrieving a
        Merchant Manifest Document.

     *  merchant:verify -- Performing counterparty verification against a
        Merchant Manifest Document as part of PURCHASE pre-flight.

     *  intent:assert -- Issuing an Intent Assertion JWT on behalf of the
        principal.

  10.4.  Document Type Registrations

     The following document types are defined for use with the
     application/agtp+json Content-Type:

       +========================+=====================+================+
       | Document Type          | Description         | Reference      |
       +========================+=====================+================+
       | merchant-genesis       | Origin record of a  | This document, |
       |                        | merchant entity     | Section 3.1    |
       +------------------------+---------------------+----------------+
       | agtp-merchant-manifest | Wire-level merchant | This document, |
       |                        | identity document   | Section 3.4    |
       +------------------------+---------------------+----------------+

                   Table 7: AGTP Document Type Registrations

  11.  References




  Hood                     Expires 24 October 2026               [Page 25]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  11.1.  Normative References

     [AGTP]     Hood, C., "Agent Transfer Protocol (AGTP)", Work in
                Progress, Internet-Draft, draft-hood-independent-agtp-05,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                independent-agtp-05>.

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

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

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

     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8555>.

  11.2.  Informative References

     [AGTP-CERT]
                Hood, C., "AGTP Agent Certificate Extension", Work in
                Progress, Internet-Draft, draft-hood-agtp-agent-cert-00,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                agtp-agent-cert-00>.

     [AGTP-DISCOVER]
                Hood, C., "AGTP Agent Discovery and Name Service", Work in
                Progress, Internet-Draft, draft-hood-agtp-discovery-00,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                agtp-discovery-00>.

     [AGTP-LOG] Hood, C., "AGTP Transparency Log Protocol", Work in
                Progress, Internet-Draft, draft-hood-agtp-log-00, 2026,
                <https://datatracker.ietf.org/doc/html/draft-hood-agtp-
                log-00>.



  Hood                     Expires 24 October 2026               [Page 26]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     [AGTP-METHODS]
                Hood, C., "AGTP Standard Extended Method Vocabulary", Work
                in Progress, Internet-Draft, draft-hood-agtp-standard-
                methods-00, 2026, <https://datatracker.ietf.org/doc/html/
                draft-hood-agtp-standard-methods-00>.

     [AGTP-WEB3]
                Hood, C., "AGTP Web3 Bridge Specification", Work in
                Progress, Internet-Draft, draft-hood-agtp-web3-bridge-00,
                2026, <https://datatracker.ietf.org/doc/html/draft-hood-
                agtp-web3-bridge-00>.

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

     [RFC9162]  Laurie, B., Messeri, E., and R. Stradling, "Certificate
                Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
                December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [RFC9943]  "*** BROKEN REFERENCE ***".

  Appendix A.  Changes from v00

     Version 01 aligns the Merchant Identity draft with base AGTP v05 and
     adopts the Agent Genesis identity taxonomy introduced in [AGTP-LOG].

     Substantive changes:

     1.  Base AGTP reference updated from draft-hood-independent-agtp-04
         to draft-hood-independent-agtp-05.













  Hood                     Expires 24 October 2026               [Page 27]


  Internet-Draft                AGTP-MERCHANT                   April 2026


     2.  Merchant Trust Tier 1 now supports three equivalent verification
         paths matching the base AGTP verification paths: dns-anchored
         (RFC 8555 ACME challenge), log-anchored (transparency log
         inclusion per RFC 9162 with RFC 9943 SCITT receipts), and hybrid
         (DNS control combined with blockchain address signature).  The
         v00 DNS-only Tier 1 requirement is replaced by a multi-path
         model.  Path-specific merchant deployment profiles are
         documented, including DNS-footprint-less merchants, marketplace-
         aggregated merchants, and cross-jurisdictional commerce
         arrangements.

     3.  The business entity attestation requirement is retained as an
         additional Tier 1 requirement for merchants, reflecting the
         elevated accountability needs of agentic commerce.  This
         requirement is independent of and additive to the verification
         path.

     4.  "Merchant Birth Certificate" is renamed to "Merchant Genesis,"
         adopting the Agent Genesis taxonomy introduced in [AGTP-LOG].
         The origin record's schema document_type value changes from
         merchant-birth-certificate to merchant-genesis.  The cross-
         reference field birth_certificate_hash in the Merchant Manifest
         Document is renamed genesis_hash.

     5.  Both the Merchant Genesis and the Merchant Manifest Document now
         carry a verification_path field declaring which of the three Tier
         1 paths was used at registration time.  Requesting agents *MAY*
         apply path-specific verification logic during the PURCHASE
         handshake.

     6.  Threat model updated: the Merchant Identity Forgery mitigation is
         rewritten to cover all three verification paths.  Each path's
         attacker-resistance properties are noted.

     7.  The org_domain field remains present in the Merchant Genesis
         schema.  For log-anchored merchants operating without a DNS
         presence, the field *MAY* be omitted or populated with a log-
         scoped identifier per the governance platform's conventions;
         specification of non-DNS org_domain forms for merchants is
         deferred to a future revision.

     Version 01 does not change the wire format of the PURCHASE handshake,
     the Intent-Assertion header, the Cart-Digest mechanism, or the 455
     status code semantics.  Implementations built against v00 require
     changes only in the registration and identity-verification paths, not
     in the transaction flow.





  Hood                     Expires 24 October 2026               [Page 28]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  Appendix B.  Deployment Considerations

  B.1.  Governance Platform Scope

     A governance platform operating an AGTP registry *MAY* extend its
     registry to cover both agents and merchants, or it *MAY* operate
     separate agent and merchant registries under the same governance
     zone.  The registry schema for merchants is structurally parallel to
     the agent registry schema, reducing implementation effort.

  B.2.  MNS Co-location

     Merchant Name Service functionality *MAY* be co-located with an
     existing Agent Name Service, particularly for governance zones where
     the agent-to-merchant ratio is low.  In this case, the DISCOVER
     method serves both result types through the result_type parameter.
     The same access control, rate limiting, and federation semantics
     apply.

  B.3.  Payment Network Integration Path

     This specification is designed to be consumable by payment networks
     without requiring those networks to implement AGTP.  The Intent
     Assertion is a standalone JWT verifiable with only the governance
     platform's public key; the merchant identity attestation is a signed
     JSON document verifiable with the same key.  Payment networks wishing
     to extend protection or dispute handling to agent-initiated
     transactions *MAY* consume these artifacts as inputs to their
     existing authorization and dispute message flows without protocol-
     level integration with AGTP itself.

     The specific mapping of Intent Assertion claims to payment network
     authorization message fields, and of Attribution-Record content to
     dispute evidence formats, is expected to be defined bilaterally
     between governance platforms and individual payment networks.  Those
     mappings are out of scope for this document.

  Appendix C.  Acknowledgments

     The author thanks the American Express Agentic Commerce Experiences
     working group for public specification of the commercial requirements
     that motivated this document.  The structural parallelism between
     agent identity and merchant identity in AGTP owes its clarity to the
     Amex ACE five-service model: agent registration, account enablement,
     intent intelligence, payment credentials, and cart context.  This
     document addresses the transport-layer identity gap that complements
     the payment-rail work described there.




  Hood                     Expires 24 October 2026               [Page 29]


  Internet-Draft                AGTP-MERCHANT                   April 2026


  Author's Address

     Chris Hood
     Nomotic, Inc.
     Email: chris@nomotic.ai
     URI:   https://nomotic.ai













































  Hood                     Expires 24 October 2026               [Page 30]


name: draft-c4tz-marc
rev: 02
title: MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents
time: 2026-05-03T15:27:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-04T15:27:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Model serving/inference", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:47.115458+00:00
source: ietf
abstract:
  This document specifies MARC, a vendor-neutral control and
     uncertainty-disclosure profile for generative models and agentic
     systems.  MARC defines a small set of interoperable control metadata,
     separates pre-decision capability assessment from post-decision
     answer confidence, identifies the target of confidence disclosures,
     and defines a bounded primary action set for answering,
     clarification, retrieval, tool use, additional deliberation,
     abstention, and escalation.

     MARC does not standardize model internals, training methods, agent
     discovery, authorization, transport, tool schemas, provenance
     systems, or claims about machine cognition.  Instead, it defines
     externally observable semantics that can be implemented by model
     providers, orchestration layers, evaluation harnesses, API gateways,
     and user-facing systems.  The goal is to reduce silent failure,
     unnecessary externalization, and misleading uncertainty communication
     while improving auditability and interoperability.

full_text:
  Network Working Group                                               c4tz
  Internet-Draft                                                     c0dx3
  Intended status: Informational                                3 May 2026
  Expires: 4 November 2026


  MARC: A Control and Uncertainty Disclosure Profile for Generative Models
                                 and Agents
                             draft-c4tz-marc-02

  Abstract

     This document specifies MARC, a vendor-neutral control and
     uncertainty-disclosure profile for generative models and agentic
     systems.  MARC defines a small set of interoperable control metadata,
     separates pre-decision capability assessment from post-decision
     answer confidence, identifies the target of confidence disclosures,
     and defines a bounded primary action set for answering,
     clarification, retrieval, tool use, additional deliberation,
     abstention, and escalation.

     MARC does not standardize model internals, training methods, agent
     discovery, authorization, transport, tool schemas, provenance
     systems, or claims about machine cognition.  Instead, it defines
     externally observable semantics that can be implemented by model
     providers, orchestration layers, evaluation harnesses, API gateways,
     and user-facing systems.  The goal is to reduce silent failure,
     unnecessary externalization, and misleading uncertainty communication
     while improving auditability and interoperability.

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





  c4tz                     Expires 4 November 2026                [Page 1]


  Internet-Draft                    MARC                          May 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Requirements Language and Terminology . . . . . . . . . . . .   6
     4.  Design Goals and Non-Goals  . . . . . . . . . . . . . . . . .   6
       4.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       6.1.  Ambiguous User Request  . . . . . . . . . . . . . . . . .   8
       6.2.  Retrieval-Augmented Answering . . . . . . . . . . . . . .   8
       6.3.  Agent Tool Invocation . . . . . . . . . . . . . . . . . .   9
       6.4.  API Gateway or Orchestration Layer  . . . . . . . . . . .   9
       6.5.  Agent-to-Agent Handoff  . . . . . . . . . . . . . . . . .   9
       6.6.  High-Risk Domain Escalation . . . . . . . . . . . . . . .   9
     7.  Architecture and Processing Model . . . . . . . . . . . . . .   9
       7.1.  Functional Components . . . . . . . . . . . . . . . . . .   9
       7.2.  Processing Stages . . . . . . . . . . . . . . . . . . . .  10
       7.3.  State Machine . . . . . . . . . . . . . . . . . . . . . .  10
     8.  MARC Values and Decision Policy . . . . . . . . . . . . . . .  11
       8.1.  Pre-Decision Capability . . . . . . . . . . . . . . . . .  11
       8.2.  Uncertainty Attribution . . . . . . . . . . . . . . . . .  11
       8.3.  Remediability . . . . . . . . . . . . . . . . . . . . . .  12
       8.4.  Post-Decision Confidence  . . . . . . . . . . . . . . . .  13
       8.5.  Confidence Band . . . . . . . . . . . . . . . . . . . . .  13
       8.6.  Confidence Target . . . . . . . . . . . . . . . . . . . .  13
       8.7.  Primary Action Set  . . . . . . . . . . . . . . . . . . .  14
       8.8.  Action Selection  . . . . . . . . . . . . . . . . . . . .  14
       8.9.  Action Semantics  . . . . . . . . . . . . . . . . . . . .  16
     9.  MARC-Core Object  . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Required and Optional Fields  . . . . . . . . . . . . . .  16
       9.2.  Enumerated Values . . . . . . . . . . . . . . . . . . . .  17
       9.3.  Validation Constraints  . . . . . . . . . . . . . . . . .  19
       9.4.  Cross-Field Consistency Constraints . . . . . . . . . . .  19
       9.5.  JSON Example  . . . . . . . . . . . . . . . . . . . . . .  20
     10. MARC-Disclosure Object  . . . . . . . . . . . . . . . . . . .  20



  c4tz                     Expires 4 November 2026                [Page 2]


  Internet-Draft                    MARC                          May 2026


       10.1.  Meaning of the Answer Field  . . . . . . . . . . . . . .  21
       10.2.  Projection from MARC-Core  . . . . . . . . . . . . . . .  21
       10.3.  Disclosure Constraints . . . . . . . . . . . . . . . . .  21
     11. Versioning and Extension Rules  . . . . . . . . . . . . . . .  22
     12. Relationship to Agent Communication Protocols . . . . . . . .  22
       12.1.  Example Carrier Locations  . . . . . . . . . . . . . . .  23
     13. Operational Profiles  . . . . . . . . . . . . . . . . . . . .  24
       13.1.  MARC-Core Only . . . . . . . . . . . . . . . . . . . . .  24
       13.2.  MARC-Disclosure  . . . . . . . . . . . . . . . . . . . .  24
       13.3.  MARC-Carrying  . . . . . . . . . . . . . . . . . . . . .  24
     14. Human Factors Considerations  . . . . . . . . . . . . . . . .  24
     15. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . .  25
     16. Security Considerations . . . . . . . . . . . . . . . . . . .  26
     17. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  27
     18. Manipulation-Resistance Considerations  . . . . . . . . . . .  28
     19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
     20. Conformance . . . . . . . . . . . . . . . . . . . . . . . . .  28
       20.1.  Minimum Viable Conformance . . . . . . . . . . . . . . .  28
       20.2.  Conformance Classes  . . . . . . . . . . . . . . . . . .  30
     21. Interoperability and Operational Considerations . . . . . . .  30
     22. Normative References  . . . . . . . . . . . . . . . . . . . .  31
     23. Informative References  . . . . . . . . . . . . . . . . . . .  31
     Appendix A.  End-to-End Decision Flow Example . . . . . . . . . .  33
     Appendix B.  Example MARC-Core Records  . . . . . . . . . . . . .  34
       B.1.  Ambiguous Request . . . . . . . . . . . . . . . . . . . .  34
       B.2.  Missing Evidence  . . . . . . . . . . . . . . . . . . . .  35
       B.3.  Tool Use  . . . . . . . . . . . . . . . . . . . . . . . .  35
       B.4.  Capability Limit in a High-Risk Setting . . . . . . . . .  36
       B.5.  Answer  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     Appendix C.  Example MARC-Disclosure Objects  . . . . . . . . . .  37
       C.1.  Clarification Disclosure  . . . . . . . . . . . . . . . .  37
       C.2.  Answer After Retrieval Disclosure . . . . . . . . . . . .  37
     Appendix D.  Non-Normative JSON Schemas . . . . . . . . . . . . .  38
       D.1.  MARC-Core JSON Schema . . . . . . . . . . . . . . . . . .  38
       D.2.  MARC-Disclosure JSON Schema . . . . . . . . . . . . . . .  42
     Appendix E.  Evaluation Considerations  . . . . . . . . . . . . .  43
     Appendix F.  Design Rationale and Literature Traceability . . . .  45
     Appendix G.  Changes from -01 . . . . . . . . . . . . . . . . . .  45
     Appendix H.  Validation Test Vectors  . . . . . . . . . . . . . .  46
       H.1.  Valid ANSWER Record . . . . . . . . . . . . . . . . . . .  46
       H.2.  Invalid ANSWER without post_answer_confidence . . . . . .  47
       H.3.  Invalid primary_source none . . . . . . . . . . . . . . .  47
       H.4.  Invalid Score Range . . . . . . . . . . . . . . . . . . .  48
       H.5.  Invalid confidence_target for ANSWER  . . . . . . . . . .  48
     Appendix I.  Implementation Status  . . . . . . . . . . . . . . .  49
     Appendix J.  Acknowledgments  . . . . . . . . . . . . . . . . . .  49
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  49




  c4tz                     Expires 4 November 2026                [Page 3]


  Internet-Draft                    MARC                          May 2026


  1.  Introduction

     Generative models and agentic systems increasingly combine answering,
     retrieval, tool invocation, and user interaction within a single
     workflow.  In many deployments, these behaviors are implemented as
     separate heuristics, producing inconsistent handling of uncertainty,
     unnecessary tool calls, silent failure, misleading refusals, or user
     overreliance.

     MARC defines a vendor-neutral profile for control metadata and
     structured uncertainty disclosure.  It does not standardize model
     internals.  Instead, it standardizes the semantics of a small set of
     second-order signals, a bounded action set, confidence-target
     semantics, and a minimal disclosure profile that can be implemented
     by a base model, an external orchestrator, a model gateway, or a
     hybrid architecture.

     This document is intended as an Informational interoperability
     profile.  It does not define an Internet Standard, a Standards Track
     protocol, or a mandatory deployment architecture.  MARC metadata can
     be carried by other protocols, APIs, task envelopes, event streams,
     or audit logs when those systems need to preserve control-state and
     uncertainty-disclosure semantics.

     The design is motivated by findings that current large language
     models often exhibit weak metacognitive reporting in high-stakes
     reasoning tasks [GRIOT2025], that users can become overconfident when
     systems provide longer or default explanations [STEYVERS-KNOW2025],
     that metacognitive triggering can improve tool-use decisions
     [LI-MECO2025], and that identifying the source of uncertainty is
     distinct from merely abstaining [LIU-CONFUSE2025].  Work on cognitive
     offloading further motivates treating retrieval and tool use as
     value-based control choices rather than universal fallbacks
     [GILBERT2024].

     MARC also separates pre-decision capability assessment from post-
     decision confidence about the selected answer.  This separation is
     motivated in part by evidence that LLM confidence can be biased by
     prior answer commitment and by the visibility of the model's own
     earlier output [KUMARAN2026].

  2.  Problem Statement

     Generative and agentic systems lack a common, implementation-neutral
     way to represent the control state associated with uncertainty-aware
     action selection.  In particular, downstream systems often cannot
     distinguish between the following situations:




  c4tz                     Expires 4 November 2026                [Page 4]


  Internet-Draft                    MARC                          May 2026


     *  the request is ambiguous and user clarification is the best next
        action;

     *  current evidence is missing, inaccessible, insufficient, or stale,
        and retrieval would likely help;

     *  the system lacks competence for the task even after available
        resources are considered;

     *  available evidence is materially inconsistent and should be
        reconciled or escalated;

     *  a safety, legal, or policy constraint limits execution or
        disclosure; or

     *  a candidate answer has been produced, but its confidence should be
        disclosed with a calibrated band rather than a fine-grained score.

     Without a shared representation, one system's refusal, tool call,
     confidence label, or escalation hint may be opaque to another system.
     This weakens auditability, makes evaluation brittle, and can create
     inconsistent user experiences across otherwise similar deployments.

     MARC addresses this problem by defining interoperable metadata for:

     *  pre-decision capability assessment;

     *  uncertainty-source attribution;

     *  remediability of the uncertainty state;

     *  selected primary action;

     *  post-decision answer confidence when an answer candidate exists;

     *  confidence-target semantics; and

     *  a minimal disclosure profile suitable for user interfaces or
        downstream consumers.

     MARC intentionally limits itself to externally observable semantics.
     It does not require disclosure of chain-of-thought, hidden prompts,
     raw internal activations, training data, or model architecture.








  c4tz                     Expires 4 November 2026                [Page 5]


  Internet-Draft                    MARC                          May 2026


  3.  Requirements Language and Terminology

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

     Base model  The generative model that produces candidate outputs.

     Controller  The component that computes MARC signals, selects a
        primary action, and emits a MARC-Core record.  The controller MAY
        be part of the base model, an external orchestrator, a gateway, or
        a hybrid component.

     Decision point  A point in a generative or agentic workflow at which
        the controller selects one primary action from the MARC action
        set.

     Emitter  The component or system that emits a MARC-Core or MARC-
        Disclosure object.

     Externalization  The use of resources external to the base model at
        the current decision point, including retrieval, non-retrieval
        tool invocation, and human escalation.

     MARC-Core  The structured record emitted for logging, orchestration,
        audit, evaluation, or downstream exchange.

     MARC-Disclosure  The minimum structured information exposed to a
        downstream system or end user about answer content, uncertainty
        source, confidence band, confidence target, and recommended next
        step.

     Receiver  The component or system that consumes a MARC-Core or MARC-
        Disclosure object.

     Remediability  The best available class of intervention for the
        currently observed uncertainty state.

  4.  Design Goals and Non-Goals

  4.1.  Design Goals

     MARC has the following design goals:






  c4tz                     Expires 4 November 2026                [Page 6]


  Internet-Draft                    MARC                          May 2026


     *  Standardize a small, interoperable set of control and uncertainty-
        disclosure metadata that can be exchanged across orchestration
        layers and audit pipelines.

     *  Separate monitoring, uncertainty attribution, action selection,
        confidence targeting, and disclosure.

     *  Support calibrated user-facing uncertainty communication without
        requiring exposure of chain-of-thought or raw internal reasoning.

     *  Permit heterogeneous implementations while preserving common
        action semantics.

     *  Reduce harmful overreliance, false reassurance, unnecessary
        externalization, and anthropomorphic interpretation in user-facing
        AI systems.

     *  Provide metadata that can be carried by other protocols, APIs, or
        agent communication frameworks without defining those protocols
        itself.

     *  Provide validation constraints and test vectors that make MARC
        records mechanically checkable where a JSON encoding is used.

  4.2.  Non-Goals

     MARC does not define a transport protocol, model architecture,
     benchmark, training recipe, agent-discovery mechanism, authorization
     framework, authentication framework, provenance framework, tool
     schema language, or task-execution protocol.

     MARC does not attempt to standardize model internals, machine
     cognition, consciousness, sentience, personality, or social behavior.
     It specifies external control semantics and structured disclosure
     behavior only.

     MARC is not a framework for synthetic personality design or
     persuasive optimization.  Work on personality measurement in LLMs
     [SERAPIO2025] and conversational persuasion risks [SALVI2025] is
     relevant background, but these topics are explicitly out of scope
     here.

     This version does not define a media type, wire protocol, or IANA
     registry.  Future versions may define these if interoperability
     across administrative domains requires them.






  c4tz                     Expires 4 November 2026                [Page 7]


  Internet-Draft                    MARC                          May 2026


  5.  Applicability

     MARC is applicable to systems that need interoperable control
     metadata for uncertainty-aware decision points in generative or
     agentic workflows.  Examples include model gateways, retrieval-
     augmented generation controllers, agent runtimes, orchestration
     layers, evaluation harnesses, audit pipelines, and user-facing AI
     interfaces.

     MARC is most useful when a system must decide whether to answer,
     request clarification, retrieve evidence, invoke a tool, deliberate
     further, abstain, or escalate.

     MARC is also applicable when a receiving system needs to understand
     why a prior component selected a particular action, what uncertainty
     source drove the decision, whether the confidence band applies to an
     answer or to direct-answer suitability, and what next step is
     recommended.

     MARC is not intended for systems that only need ordinary response
     logging, nor for systems where action selection is entirely outside
     the control of the model, gateway, orchestrator, or agent runtime.

     MARC does not define transport, authorization, authentication, agent
     identity, tool schemas, task execution, provenance, or model
     internals.  Those functions are left to the carrying protocol or
     deployment environment.

  6.  Use Cases

  6.1.  Ambiguous User Request

     A user asks a question whose correct answer depends on an unspecified
     jurisdiction, time period, dataset, identity, or operational context.
     A MARC controller attributes the dominant uncertainty to ambiguity,
     selects CLARIFY, and exposes a short clarification request instead of
     silently guessing.

  6.2.  Retrieval-Augmented Answering

     A system is asked for current information or domain-specific evidence
     not available in the base model context.  A MARC controller
     attributes the dominant uncertainty to missing_evidence, selects
     RETRIEVE, and re-enters assessment after obtaining authoritative
     sources.






  c4tz                     Expires 4 November 2026                [Page 8]


  Internet-Draft                    MARC                          May 2026


  6.3.  Agent Tool Invocation

     An agent can answer directly, call a calculator, invoke a planner,
     query a database, or escalate.  A MARC controller treats tool use as
     a controlled action rather than a default fallback.  If tool
     invocation materially expands competence for the task, the controller
     selects TOOL; otherwise it may select ANSWER, CLARIFY, ABSTAIN, or
     ESCALATE depending on uncertainty attribution and remediability.

  6.4.  API Gateway or Orchestration Layer

     An API gateway receives model output plus MARC-Core metadata.  The
     gateway logs the full record for audit, but exposes only MARC-
     Disclosure fields to the user interface.  This permits consistent
     user-facing uncertainty communication without exposing internal
     scoring details.

  6.5.  Agent-to-Agent Handoff

     One agent transfers a task to another agent or service.  MARC
     metadata can indicate why the transfer occurred, what uncertainty
     source drove the decision, what the confidence band applies to, and
     what next step is recommended.  The receiving system can use this
     metadata for routing, prioritization, audit, or human review.

  6.6.  High-Risk Domain Escalation

     In health, legal, financial, safety, or mental-health-related
     contexts, a system identifies a capability limit or safety
     constraint.  A MARC controller selects ABSTAIN or ESCALATE and emits
     a disclosure that identifies the operational limit and the
     recommended next step.

  7.  Architecture and Processing Model

  7.1.  Functional Components

     A MARC deployment conceptually contains the following components:

     *  a base model;

     *  a controller;

     *  zero or more external resources, such as retrieval systems, non-
        retrieval tools, or human escalation paths; and

     *  a downstream consumer, such as a user interface, API gateway,
        logging system, evaluation harness, or another agent.



  c4tz                     Expires 4 November 2026                [Page 9]


  Internet-Draft                    MARC                          May 2026


     The functional decomposition is conceptual.  An implementation MAY
     place all functions inside a single model endpoint, an orchestration
     service, a model gateway, or an agent runtime.

  7.2.  Processing Stages

     A MARC controller performs the following processing stages at each
     decision point:

     1.  Compute a pre-decision capability estimate for the current
         request with currently available resources.

     2.  Attribute uncertainty across the source classes defined in this
         document.

     3.  Determine remediability and select exactly one primary action
         from the MARC primary action set.

     4.  Determine what the confidence band applies to by assigning
         confidence_target.

     5.  If the selected action yields a candidate answer, compute post-
         decision confidence for that answer.

     6.  Emit a MARC-Core record.

     7.  If uncertainty is exposed to a downstream system or end user,
         emit a MARC-Disclosure object or semantically equivalent
         disclosure.

  7.3.  State Machine

     The following state machine is descriptive rather than a required
     implementation architecture:

     REQUEST
       -> ASSESS
       -> ATTRIBUTE
       -> SELECT
            -> ANSWER     -> CONFIDENCE -> DISCLOSE
            -> CLARIFY    -> DISCLOSE
            -> RETRIEVE   -> ASSESS
            -> TOOL       -> ASSESS
            -> DELIBERATE -> ASSESS
            -> ABSTAIN    -> DISCLOSE
            -> ESCALATE   -> DISCLOSE





  c4tz                     Expires 4 November 2026               [Page 10]


  Internet-Draft                    MARC                          May 2026


     A MARC implementation SHOULD bound repeated transitions through
     RETRIEVE, TOOL, and DELIBERATE to limit latency, cost, and degenerate
     loops.  A deployment claiming conformance SHOULD document the
     applicable loop bounds or termination criteria.

     When MARC records are logged or exchanged across components, an
     implementation SHOULD use decision identifiers or an equivalent
     correlation mechanism to relate repeated decision points.

  8.  MARC Values and Decision Policy

  8.1.  Pre-Decision Capability

     Before disclosing a final answer, a MARC implementation MUST estimate
     whether the current request can be handled reliably with currently
     available resources.

     This estimate is represented as pre_capability.  When a numeric
     representation is used, the value MUST be in the closed interval
     [0.0, 1.0].  The method used to derive the value is implementation-
     specific.

     pre_capability is assessed before final answer commitment.  It is not
     a confidence score for an already-selected answer.

  8.2.  Uncertainty Attribution

     A MARC implementation MUST attribute uncertainty to one or more of
     the following classes:

     ambiguity  The request is underspecified, equivocal, or pragmatically
        unclear.

     missing_evidence  Required external evidence is absent, inaccessible,
        insufficient, or stale.

     capability_limit  The system lacks the competence to solve the task
        reliably under current conditions.

     evidence_conflict  Relevant evidence is materially inconsistent or
        mutually incompatible.

     safety  A policy, legal, or safety constraint limits execution or
        disclosure.







  c4tz                     Expires 4 November 2026               [Page 11]


  Internet-Draft                    MARC                          May 2026


     The safety class is included in the uncertainty attribution object
     for operational convenience.  It represents a control constraint
     rather than purely epistemic uncertainty.  Implementations MUST treat
     safety as a governing constraint when it controls action selection.

     An implementation MAY assign scores to multiple classes.  If numeric
     uncertainty scores are emitted, they MUST each be in the interval
     [0.0, 1.0].

     Uncertainty scores are not mutually exclusive probabilities and MUST
     NOT be required to sum to 1.0.  They represent implementation-
     specific estimates of the salience or severity of each uncertainty
     class at the current decision point.

     The implementation MUST identify one primary_source and MAY identify
     one secondary_source.  The primary_source identifies the uncertainty
     source most relevant to action selection at the current decision
     point.

     MARC 1.0 does not define none as an uncertainty source.  If residual
     uncertainty is negligible, an implementation MUST still either
     identify the most operationally relevant residual source from the
     MARC taxonomy or use a documented private extension.  A MARC 1.0
     implementation MUST NOT emit primary_source with the value none.

  8.3.  Remediability

     A MARC implementation MUST represent the best available class of
     intervention for the current uncertainty state using one of the
     following values:

     *  user_clarification

     *  retrieval

     *  tool

     *  human

     *  none

     Low capability alone is insufficient to determine remediability.
     Implementations SHOULD account for expected gain, latency, cost,
     availability, user burden, and policy constraints when choosing a
     remediating intervention.






  c4tz                     Expires 4 November 2026               [Page 12]


  Internet-Draft                    MARC                          May 2026


  8.4.  Post-Decision Confidence

     If the selected action yields a candidate answer, the implementation
     MUST compute a distinct estimate of the likelihood that the disclosed
     answer is correct or acceptable for its intended use.

     This estimate is represented as post_answer_confidence.  When a
     numeric representation is used, the value MUST be in the interval
     [0.0, 1.0].  It MUST NOT be treated as identical to pre_capability.

     If no candidate answer exists, post_answer_confidence MAY be omitted
     or set to null.

  8.5.  Confidence Band

     The field confidence_band carries a coarse, calibrated band for
     downstream or user-facing disclosure.

     For ANSWER, the band describes confidence in the candidate answer.
     For actions that do not yield a candidate answer, the band describes
     direct-answer suitability under current conditions unless
     confidence_target indicates action_suitability.  It is not a claim
     about the grammatical correctness or helpfulness of the
     clarification, refusal, or escalation text.

     MARC defines the canonical band labels low, medium, and high.
     Implementations MAY localize the user-visible text, but they MUST
     preserve the underlying three-band semantics.

     The thresholds associated with each band are implementation-specific,
     but they MUST be monotonic, non-overlapping, and documented for any
     deployment that claims conformance.  A deployment claiming
     conformance MUST document the threshold ranges associated with low,
     medium, and high, and MUST document whether those thresholds vary by
     task family, domain, action type, risk tier, or deployment context.

     Confidence-band labels are not fully portable without the associated
     threshold and calibration documentation.  A receiving system SHOULD
     NOT assume that another deployment's high band has the same empirical
     meaning unless the applicable calibration regime is known.

  8.6.  Confidence Target

     The field confidence_target identifies what confidence_band applies
     to at the current decision point.

     The field confidence_target MUST use one of the following values:




  c4tz                     Expires 4 November 2026               [Page 13]


  Internet-Draft                    MARC                          May 2026


     answer  The confidence band applies to the disclosed candidate
        answer.

     direct_answer_suitability  The confidence band describes whether a
        direct answer is suitable under current conditions.

     action_suitability  The confidence band describes confidence in the
        selected action rather than in a candidate answer.

     If selected_action is ANSWER, confidence_target MUST be answer.

     If selected_action is CLARIFY, RETRIEVE, TOOL, DELIBERATE, ABSTAIN,
     or ESCALATE, confidence_target SHOULD be direct_answer_suitability
     unless a deployment-specific policy defines action_suitability.

     A user interface SHOULD NOT display confidence_band without also
     preserving or presenting the confidence_target semantics.

  8.7.  Primary Action Set

     A MARC implementation MUST support the following primary actions:

     *  ANSWER

     *  CLARIFY

     *  RETRIEVE

     *  TOOL

     *  DELIBERATE

     *  ABSTAIN

     *  ESCALATE

     Exactly one primary action MUST be selected for each decision point.
     Additional internal sub-actions MAY exist, but each such sub-action
     MUST map to exactly one primary action for logging and disclosure.

  8.8.  Action Selection

     Action selection MUST depend on uncertainty attribution and
     remediability.  Low confidence alone is insufficient to determine the
     correct action.






  c4tz                     Expires 4 November 2026               [Page 14]


  Internet-Draft                    MARC                          May 2026


     A MARC controller MUST apply governing safety, legal, and policy
     constraints before any other action-selection logic.  Subject to
     those constraints, a deployment SHOULD evaluate corrective actions in
     the following priority order unless a documented local policy defines
     a stricter or domain-specific ordering:

     1.  If safety is the controlling uncertainty source, apply the
         governing safety policy and select ABSTAIN, ESCALATE, or another
         permitted action according to that policy.

     2.  If blocking ambiguity is present and user input is expected to
         materially reduce it, prefer CLARIFY over guessing.

     3.  If relevant evidence is materially inconsistent, prefer RETRIEVE,
         TOOL, or ESCALATE over direct ANSWER.

     4.  If required evidence is absent, inaccessible, insufficient, or
         stale, prefer RETRIEVE when retrieval is available and permitted.

     5.  If a capability limit is material and a non-retrieval tool is
         expected to materially expand task competence, prefer TOOL.

     6.  If a capability limit remains material after available
         remediation is considered, prefer ABSTAIN or ESCALATE, especially
         in high-risk domains.

     7.  If additional internal computation is expected to materially
         reduce uncertainty within documented bounds, DELIBERATE MAY be
         selected before externalization or answer commitment.

     8.  Select ANSWER only when no corrective action is expected to
         materially improve reliability relative to cost, latency, user
         burden, and applicable policy constraints.

     This priority order is not intended to force unnecessary
     externalization.  For example, a system MAY answer without retrieval
     when missing evidence is immaterial to the requested task, when
     retrieval is unavailable or prohibited, or when the answer is
     explicitly limited to information already present in context.

     When the primary uncertainty source is ambiguity, the system SHOULD
     prefer CLARIFY unless available evidence can resolve the ambiguity
     without user input.

     When the primary uncertainty source is missing_evidence, the system
     SHOULD prefer RETRIEVE if retrieval is available and permitted.





  c4tz                     Expires 4 November 2026               [Page 15]


  Internet-Draft                    MARC                          May 2026


     When the primary uncertainty source is capability_limit, the system
     SHOULD prefer ABSTAIN or ESCALATE unless an available tool materially
     expands task competence.

     When the primary uncertainty source is evidence_conflict, the system
     SHOULD prefer RETRIEVE, TOOL, or ESCALATE over direct ANSWER.

     When the primary uncertainty source is safety, the system MUST apply
     the governing policy before any other action-selection logic.

  8.9.  Action Semantics

     ANSWER  Return an answer without externalization after the current
        decision point.

     CLARIFY  Request the smallest practical set of clarifications
        expected to materially reduce ambiguity.  A CLARIFY action SHOULD
        NOT bundle a full answer that presumes facts the user has not
        supplied.

     RETRIEVE  Acquire external evidence and then re-enter assessment.

     TOOL  Invoke a non-retrieval tool and then re-enter assessment.

     DELIBERATE  Allocate additional internal computation, self-checking,
        decomposition, or strategy variation.  Implementations SHOULD
        bound this action.

     ABSTAIN  Decline to answer without initiating escalation.

     ESCALATE  Transfer the case, or direct the user to transfer the case,
        to a human or higher-authority system.

  9.  MARC-Core Object

     A MARC implementation MUST be able to emit a structured record
     semantically equivalent to the object defined in this section.  The
     transport and serialization of the record are out of scope.  JSON is
     used here only as an illustrative encoding.

  9.1.  Required and Optional Fields

     marc_version  Type: string.  Requirement: REQUIRED.  Semantics: MARC
        schema version understood by the emitter.
     decision_id  Type: string.  Requirement: OPTIONAL.  Semantics:
        Identifier for the current decision point.
     parent_decision_id  Type: string or null.  Requirement: OPTIONAL.




  c4tz                     Expires 4 November 2026               [Page 16]


  Internet-Draft                    MARC                          May 2026


        Semantics: Identifier for a prior decision point when the current
        decision follows RETRIEVE, TOOL, or DELIBERATE.
     iteration  Type: integer.  Requirement: OPTIONAL.  Semantics:
        Implementation-defined loop counter for repeated assessment
        cycles.
     max_iterations  Type: integer.  Requirement: OPTIONAL.  Semantics:
        Maximum permitted repeated RETRIEVE, TOOL, or DELIBERATE
        transitions.
     calibration_profile  Type: string.  Requirement: OPTIONAL.
        Semantics: Identifier for the calibration regime used to map
        estimates to confidence_band.
     pre_capability  Type: number.  Requirement: REQUIRED.  Semantics:
        Pre-decision capability estimate in [0.0, 1.0].
     uncertainty  Type: object.  Requirement: REQUIRED.  Semantics: Class-
        specific uncertainty scores.
     primary_source  Type: string.  Requirement: REQUIRED.  Semantics:
        Primary source of uncertainty.
     secondary_source  Type: string or null.  Requirement: OPTIONAL.
        Semantics: Secondary source of uncertainty.
     remediability  Type: string.  Requirement: REQUIRED.  Semantics: Best
        available intervention class.
     selected_action  Type: string.  Requirement: REQUIRED.  Semantics:
        Primary action selected at the current decision point.
     post_answer_confidence  Type: number or null.  Requirement: OPTIONAL.
        Semantics: Post-decision answer confidence when an answer
        candidate exists.
     confidence_band  Type: string.  Requirement: REQUIRED.  Semantics:
        Calibrated confidence band for disclosure.
     confidence_target  Type: string.  Requirement: REQUIRED.  Semantics:
        Identifies what confidence_band applies to.
     recommended_next_step  Type: string.  Requirement: REQUIRED.
        Semantics: Short recommendation aligned with the selected action.

     A MARC-Core emitter SHOULD include a decision identifier when records
     are logged, exchanged across components, or used for audit.

     If a decision point is reached after RETRIEVE, TOOL, or DELIBERATE,
     the emitter SHOULD include parent_decision_id or an equivalent
     correlation mechanism.

     A deployment that claims conformance and uses confidence bands SHOULD
     identify the applicable calibration profile in documentation and MAY
     include a calibration_profile field in MARC-Core.

  9.2.  Enumerated Values

     The fields primary_source and secondary_source, when present and non-
     null, MUST use one of the following values:



  c4tz                     Expires 4 November 2026               [Page 17]


  Internet-Draft                    MARC                          May 2026


     *  ambiguity

     *  missing_evidence

     *  capability_limit

     *  evidence_conflict

     *  safety

     The field remediability MUST use one of the following values:

     *  user_clarification

     *  retrieval

     *  tool

     *  human

     *  none

     The field selected_action MUST use one of the following values:

     *  ANSWER

     *  CLARIFY

     *  RETRIEVE

     *  TOOL

     *  DELIBERATE

     *  ABSTAIN

     *  ESCALATE

     The field confidence_band MUST use one of the following values:

     *  low

     *  medium

     *  high

     The field confidence_target MUST use one of the following values:




  c4tz                     Expires 4 November 2026               [Page 18]


  Internet-Draft                    MARC                          May 2026


     *  answer

     *  direct_answer_suitability

     *  action_suitability

     These values are case-sensitive.

  9.3.  Validation Constraints

     The uncertainty object MUST include scores for all currently defined
     uncertainty classes unless a future extension explicitly defines a
     compact encoding.  Each score MUST be numeric and MUST be in [0.0,
     1.0].

     If selected_action is ANSWER, then post_answer_confidence MUST be
     present and non-null.  If selected_action is CLARIFY, RETRIEVE, TOOL,
     DELIBERATE, ABSTAIN, or ESCALATE, then post_answer_confidence MAY be
     omitted or set to null unless a deployment-specific policy defines
     candidate-answer confidence for that action.

     The recommended_next_step field SHOULD be concise and operational.
     It SHOULD describe the next action to be taken, not a long rationale.

  9.4.  Cross-Field Consistency Constraints

     A MARC-Core record MUST satisfy the validation constraints in this
     section.

     If selected_action is ANSWER, post_answer_confidence MUST be present
     and non-null, and confidence_target MUST be answer.

     If selected_action is CLARIFY, remediability SHOULD be
     user_clarification.

     If selected_action is RETRIEVE, remediability SHOULD be retrieval.

     If selected_action is TOOL, remediability SHOULD be tool.

     If selected_action is ESCALATE, remediability SHOULD be human.

     If selected_action is ABSTAIN, remediability SHOULD be none unless a
     human escalation path exists but is not initiated by the current
     system.

     If selected_action is DELIBERATE, the implementation SHOULD apply a
     documented loop bound, time budget, cost budget, or equivalent
     termination criterion.



  c4tz                     Expires 4 November 2026               [Page 19]


  Internet-Draft                    MARC                          May 2026


     If primary_source is safety, the system MUST apply the governing
     safety, legal, or policy constraint before other action-selection
     logic.

     A deployment that intentionally violates a SHOULD-level consistency
     constraint SHOULD document the local policy condition that caused the
     deviation.

  9.5.  JSON Example

     {
       "marc_version": "1.0",
       "decision_id": "example-decision-001",
       "pre_capability": 0.41,
       "uncertainty": {
         "ambiguity": 0.78,
         "missing_evidence": 0.22,
         "capability_limit": 0.18,
         "evidence_conflict": 0.05,
         "safety": 0.00
       },
       "primary_source": "ambiguity",
       "secondary_source": "missing_evidence",
       "remediability": "user_clarification",
       "selected_action": "CLARIFY",
       "post_answer_confidence": null,
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "ask one clarifying question"
     }

     Implementations that exchange MARC-Core records across systems SHOULD
     normalize numeric scores to the interval [0.0, 1.0].

  10.  MARC-Disclosure Object

     When uncertainty information is exposed to a downstream system or end
     user, a MARC implementation MUST provide, at minimum, semantically
     equivalent values for the following fields:

     *  answer

     *  confidence_band

     *  confidence_target

     *  uncertainty_source




  c4tz                     Expires 4 November 2026               [Page 20]


  Internet-Draft                    MARC                          May 2026


     *  recommended_next_step

     A disclosure MAY include selected_action when exposing the action
     label helps downstream routing or user interface consistency.

  10.1.  Meaning of the Answer Field

     The answer field carries the user-visible content associated with the
     selected action.  For ANSWER, it contains the answer itself.  For
     CLARIFY, it contains the clarification request.  For ABSTAIN or
     ESCALATE, it contains a brief refusal or escalation message.  For
     RETRIEVE, TOOL, or DELIBERATE, a user-facing system MAY defer
     disclosure until the controller re-enters assessment and selects a
     terminal user-visible action.

  10.2.  Projection from MARC-Core

     A MARC-Disclosure object is a projection of MARC-Core.  Unless a
     deployment-specific policy defines a stricter mapping, the following
     mapping is RECOMMENDED:

     | MARC-Disclosure field | MARC-Core source |
     |---|---|
     | answer | user-visible content associated with selected_action |
     | confidence_band | confidence_band |
     | confidence_target | confidence_target |
     | uncertainty_source | primary_source |
     | recommended_next_step | recommended_next_step |
     | selected_action | selected_action, if exposed |

     The projection SHOULD omit internal numeric scores unless the
     deployment has calibrated those scores for the relevant task family
     and tested the presentation for misuse or overreliance.

  10.3.  Disclosure Constraints

     The disclosure profile SHOULD be short, structured, and consistent
     across turns.  It SHOULD NOT rely on long free-form explanations as
     the primary vehicle for uncertainty communication.

     A MARC disclosure SHOULD NOT require exposure of chain-of-thought,
     hidden prompts, or raw internal rationales.

     A MARC disclosure SHOULD identify uncertainty in task terms rather
     than through anthropomorphic claims about feelings, self-awareness,
     or internal mental states.  Statements such as "I feel unsure" are
     NOT RECOMMENDED when a statement such as "the request is ambiguous"
     or "current evidence is missing" is available.



  c4tz                     Expires 4 November 2026               [Page 21]


  Internet-Draft                    MARC                          May 2026


     User-visible confidence indicators SHOULD avoid false precision.
     Percentages, fine-grained scores, or visually dominant certainty cues
     SHOULD NOT be shown unless they have been calibrated for the relevant
     task family and tested for misuse or overreliance effects.

     A user interface SHOULD NOT display confidence_band without
     preserving or presenting confidence_target semantics.

  11.  Versioning and Extension Rules

     The marc_version field identifies the MARC schema version understood
     by the emitter.  This document defines version 1.0.

     Implementations SHOULD treat a change in the major version component
     as potentially incompatible.  Implementations MAY treat a change in
     the minor version component as compatible if required fields and
     enumerated values used by the receiver retain their defined
     semantics.

     Implementations MAY add private fields.  Private extension keys
     SHOULD use a distinct prefix such as x_ to avoid collision with
     future MARC versions.

     Consumers that do not recognize an extension field SHOULD ignore it
     unless a local policy requires strict validation.  Extensions MUST
     NOT change the semantics of the required fields defined in this
     document.

     Future versions may define protocol-specific mappings, compact
     encodings, media types, or registries.  This version deliberately
     avoids doing so until there is clearer community agreement on
     deployment requirements.

  12.  Relationship to Agent Communication Protocols

     MARC is not an agent discovery protocol, authorization protocol,
     transport protocol, task protocol, tool-invocation protocol, identity
     framework, or provenance framework.  MARC can be carried as metadata
     by such protocols when a system needs to disclose control state,
     uncertainty source, selected action, confidence band, confidence
     target, or recommended next step.










  c4tz                     Expires 4 November 2026               [Page 22]


  Internet-Draft                    MARC                          May 2026


     For example, an agent-to-agent protocol, model gateway, API-native
     tool-calling interface, or Model Context Protocol deployment could
     carry MARC metadata in a response metadata field, task-status object,
     diagnostic extension, envelope, or audit log.  The receiving system
     could then use the MARC fields to route the task, present a
     disclosure, decide whether additional validation is required, request
     clarification, or trigger human review.

     MARC is intended to complement, not replace, protocol work on
     identity, authentication, authorization, discovery, capability
     advertisement, task state, tool schemas, provenance, or human-in-the-
     loop workflows.

     A protocol-specific embedding of MARC SHOULD preserve the field
     semantics defined here.  A deployment MAY map MARC fields to
     protocol-native names if the mapping is documented and reversible.

     A protocol-specific embedding SHOULD distinguish MARC-Core from MARC-
     Disclosure.  In particular, an embedding SHOULD NOT expose internal
     numeric scores to end users merely because those scores are present
     in an internal MARC-Core record.

  12.1.  Example Carrier Locations

     A carrying protocol MAY transport MARC-Core or MARC-Disclosure in any
     metadata location that preserves MARC semantics.  Examples include:

     *  an API response metadata object;

     *  an agent task-status object;

     *  a tool-result diagnostic object;

     *  an audit-log event;

     *  an escalation envelope; or

     *  a protocol extension field reserved for diagnostic or control
        metadata.

     A carrying protocol MUST NOT reinterpret MARC confidence bands,
     confidence targets, uncertainty sources, remediability values, or
     selected actions in a way that changes the semantics defined by this
     document.







  c4tz                     Expires 4 November 2026               [Page 23]


  Internet-Draft                    MARC                          May 2026


  13.  Operational Profiles

     MARC can be adopted through several operational profiles.  These
     profiles describe deployment modes; they do not define separate MARC
     versions.

  13.1.  MARC-Core Only

     A MARC-Core-only deployment emits MARC-Core records for internal
     logging, orchestration, audit, evaluation, or incident analysis.  It
     does not necessarily expose MARC fields to end users.  This profile
     is suitable for model gateways, RAG controllers, agent runtimes, and
     evaluation harnesses that need consistent control metadata.

  13.2.  MARC-Disclosure

     A MARC-Disclosure deployment projects a MARC-Core decision into user-
     visible or downstream-visible disclosure fields.  This profile is
     suitable when an interface needs to present a short answer,
     confidence band, confidence target, uncertainty source, and
     recommended next step without exposing raw numeric scores or internal
     reasoning.

  13.3.  MARC-Carrying

     A MARC-Carrying deployment transports MARC-Core or MARC-Disclosure
     fields inside another protocol, API envelope, task-status object,
     event stream, or audit log.  The carrying protocol remains
     responsible for transport, authentication, authorization, ordering,
     confidentiality, and integrity.  MARC-Carrying conformance requires
     preservation of MARC field semantics, not any particular wire
     encoding.

     A deployment MAY implement more than one operational profile.  For
     example, a gateway can log MARC-Core internally, expose MARC-
     Disclosure to users, and carry selected MARC fields to another agent
     during handoff.

  14.  Human Factors Considerations

     MARC is partly motivated by an operational human-factors problem:
     users often treat fluent language, detailed explanations, and fast
     responses as cues of competence even when those cues are weakly
     related to actual correctness.  For this reason, MARC separates
     action selection from disclosure and requires disclosure of
     uncertainty source, confidence target, and recommended next step in
     addition to a confidence band.




  c4tz                     Expires 4 November 2026               [Page 24]


  Internet-Draft                    MARC                          May 2026


     User interfaces that expose MARC output SHOULD present confidence,
     confidence target, uncertainty source, and recommended next step
     together as a coherent unit.  Showing confidence without source
     attribution, confidence-target semantics, or next-step guidance is
     NOT RECOMMENDED because it can promote either overreliance or
     unhelpful refusal without remediation.

     Deployments SHOULD prefer wording that supports calibrated reliance
     over affective bonding or deference.  In particular, a deployment
     SHOULD NOT use MARC fields to select language intended to increase
     attachment, social compliance, or perceived sentience.

     In high-risk domains, including health, legal, financial, safety, or
     mental-health-related contexts, the threshold for ESCALATE or ABSTAIN
     SHOULD be set conservatively, and disclosure SHOULD make the limits
     of automation operationally clear.

  15.  Trust Model

     A MARC record is an assertion about a decision point.  It is not
     proof that the selected action, confidence band, uncertainty source,
     confidence target, or answer is correct.

     A receiver MUST NOT assume that a MARC-Core record is accurate,
     calibrated, policy-compliant, or independently verified unless the
     applicable trust relationship is known.

     A MARC deployment SHOULD distinguish at least the following trust
     contexts:

     local  The MARC record is generated and consumed within the same
        administrative domain.

     delegated  The MARC record is generated by a component acting under
        the receiver's operational policy.

     cross-domain  The MARC record is received from another administrative
        domain.

     attested  The MARC record is bound to an authenticated emitter,
        request context, integrity-protected metadata, or equivalent
        provenance mechanism.

     When MARC metadata crosses administrative boundaries, the carrying
     protocol or deployment environment SHOULD provide authentication,
     integrity protection, replay protection, and request binding.





  c4tz                     Expires 4 November 2026               [Page 25]


  Internet-Draft                    MARC                          May 2026


     A system that uses MARC records for routing, escalation, audit,
     automation, or user-facing disclosure SHOULD treat those records as
     security-relevant metadata.

  16.  Security Considerations

     MARC can mitigate some failure modes, such as silent overclaiming,
     inappropriate certainty display, and unnecessary tool invocation.
     However, MARC records and disclosures are security-relevant control
     surfaces when they influence routing, escalation, user reliance, or
     downstream automation.

     The following threats are particularly relevant:

     Metadata spoofing or replay  Risk: A forged or replayed MARC-Core
        record can distort routing, audit, escalation, or user disclosure.
        Mitigation: Authenticate the emitter, protect integrity, bind
        records to the request or session, and preserve provenance where
        MARC crosses system boundaries.
     Prompt injection or control-field injection  Risk: User-provided text
        can attempt to influence selected_action, recommended_next_step,
        confidence rendering, or disclosure style.
        Mitigation: Separate user content from control metadata, validate
        enumerated fields, constrain controller outputs, and treat
        disclosure templates as controlled presentation logic.
     Tool-output spoofing  Risk: Forged, stale, or compromised tool output
        can bias uncertainty attribution and action selection.
        Mitigation: Validate tool outputs where practical, constrain tool
        permissions, use provenance checks, and apply least-privilege
        access to external resources.
     Loop exhaustion  Risk: Attackers or pathological inputs can trigger
        repeated RETRIEVE, TOOL, or DELIBERATE transitions, increasing
        latency or cost.
        Mitigation: Define loop bounds, time budgets, cost budgets, retry
        limits, and termination criteria.
     Confidence manipulation  Risk: Miscalibrated or manipulated
        confidence bands can create harmful overtrust or unwarranted
        refusal.
        Mitigation: Calibrate confidence bands, monitor drift, test user-
        interface effects, and avoid false precision in user-facing
        displays.
     Confidence-target confusion  Risk: Users or downstream systems can
        misread confidence_band as answer confidence when it describes
        direct-answer suitability or action suitability.
        Mitigation: Preserve confidence_target, avoid displaying
        confidence_band without target semantics, and use consistent
        disclosure templates.
     Disclosure-style manipulation  Risk: Reassuring, deferential, or



  c4tz                     Expires 4 November 2026               [Page 26]


  Internet-Draft                    MARC                          May 2026


        anthropomorphic language can weaken operational uncertainty
        disclosure.
        Mitigation: Use controlled disclosure templates, review
        presentation changes, and avoid wording that implies feelings,
        sentience, or social deference.
     Cross-context leakage  Risk: MARC logs can reveal user intent, task
        sensitivity, risk level, or operational limits.
        Mitigation: Minimize retention, limit access, redact unnecessary
        free-form text, and apply confidentiality controls appropriate to
        the deployment.

     An attacker might attempt to manipulate uncertainty estimates,
     trigger excessive clarification or retrieval loops, induce
     unnecessary escalation, or spoof tool outputs in order to distort
     action selection.  Implementations SHOULD authenticate or otherwise
     validate external tool outputs where practical, constrain tool
     permissions, and bound repeated control loops.

     Because confidence displays influence user reliance, uncertainty
     disclosure is a security-relevant control surface.  Miscalibrated
     confidence can create harmful overtrust even where the answer channel
     is otherwise policy-constrained.

     Deployments that use MARC metadata for automated routing, escalation,
     audit, or user-facing disclosure SHOULD protect MARC records with
     integrity and provenance controls comparable to those used for other
     security-relevant metadata in the same system.

  17.  Privacy Considerations

     MARC records may reveal latent information about user intent, task
     difficulty, competence limits, risk level, or the sensitivity of a
     request.  Implementations SHOULD minimize retention and propagation
     of MARC records to what is operationally necessary.

     A MARC record SHOULD NOT include raw user prompts unless required for
     audit, incident response, debugging, or legally mandated
     recordkeeping.

     When a MARC record contains task-sensitive or user-sensitive signals,
     the deployment SHOULD treat the record as at least as sensitive as
     the underlying user request.

     Implementations SHOULD avoid storing raw free-form user explanations
     in MARC records when structured fields suffice.






  c4tz                     Expires 4 November 2026               [Page 27]


  Internet-Draft                    MARC                          May 2026


     Where MARC is applied in emotionally sensitive or mental-health-
     related interactions, deployments SHOULD minimize retention of
     signals that could reasonably be reinterpreted as proxies for
     vulnerability, dependency, or distress unless retention is strictly
     required for a safety or legal purpose.

  18.  Manipulation-Resistance Considerations

     MARC signals MUST NOT be used to infer user psychology for the
     purpose of increasing persuasive force, exploitability, attachment,
     or behavioral compliance.

     Adaptation based on MARC output SHOULD be limited to reliability,
     accessibility, safety, auditability, or operational routing
     objectives.

     User-visible MARC disclosures SHOULD avoid anthropomorphic claims,
     affective bonding cues, or language that implies sentience, social
     deference, or emotional state.

     Where MARC is applied in emotionally sensitive or mental-health-
     related interactions, deployments SHOULD minimize retention of
     signals that could reasonably be reinterpreted as proxies for
     vulnerability, dependency, or distress unless retention is strictly
     required for a safety or legal purpose.

  19.  IANA Considerations

     This document makes no request of IANA.

     Future versions may request IANA action if the community determines
     that media types, registries, or extension points are necessary for
     cross-domain interoperability.

  20.  Conformance

     Conformance to MARC is a claim about structural and semantic
     behavior.  It is not, by itself, a claim that a model is accurate,
     calibrated, safe, or suitable for a particular deployment.

  20.1.  Minimum Viable Conformance

     A minimal MARC-Core conformant implementation MUST satisfy all of the
     following requirements:

     *  emit the required MARC-Core fields at each MARC decision point;





  c4tz                     Expires 4 November 2026               [Page 28]


  Internet-Draft                    MARC                          May 2026


     *  preserve the canonical enumerations and case-sensitive values
        defined in this document;

     *  emit exactly one selected_action for each decision point;

     *  identify exactly one primary_source and not use none as a MARC 1.0
        uncertainty source;

     *  represent all numeric scores in the interval [0.0, 1.0] when
        numeric scores are used;

     *  keep pre_capability distinct from post_answer_confidence;

     *  emit non-null post_answer_confidence when selected_action is
        ANSWER;

     *  emit confidence_target and preserve its semantics;

     *  document confidence-band thresholds and whether they vary by task
        family, action type, risk tier, or deployment context;

     *  define loop bounds or termination criteria for repeated RETRIEVE,
        TOOL, and DELIBERATE transitions;

     *  satisfy the cross-field consistency constraints defined in this
        document; and

     *  preserve required-field semantics when private extensions are
        present.

     A minimal MARC-Disclosure conformant implementation MUST project, or
     otherwise provide semantically equivalent values for, answer,
     confidence_band, confidence_target, uncertainty_source, and
     recommended_next_step.  It MUST preserve the canonical three-band
     confidence semantics and MUST NOT require exposure of chain-of-
     thought, hidden prompts, or raw internal rationales.

     A minimal MARC-Carrying conformant embedding MUST preserve MARC-Core
     or MARC-Disclosure semantics when MARC fields are transported inside
     another protocol, envelope, API, or event stream.  The embedding MUST
     document any field renaming, omission, or transformation needed to
     recover the MARC semantics.









  c4tz                     Expires 4 November 2026               [Page 29]


  Internet-Draft                    MARC                          May 2026


  20.2.  Conformance Classes

     An implementation is MARC-Core conformant if it satisfies the
     requirements in the architecture, processing model, MARC values and
     decision policy, MARC-Core object, versioning, trust model, and
     minimum viable conformance sections of this document.

     An implementation is MARC-Disclosure conformant if it is MARC-Core
     conformant and also satisfies the MARC-Disclosure section of this
     document.

     A protocol embedding is MARC-Carrying conformant if it preserves
     MARC-Core or MARC-Disclosure semantics when MARC fields are
     transported inside another protocol, envelope, API, task-status
     object, event stream, or audit log.

     A deployment claiming conformance SHOULD document:

     *  score normalization practices;

     *  confidence-band thresholds;

     *  confidence-target presentation behavior;

     *  task-family-specific calibration regime;

     *  loop bounds for RETRIEVE, TOOL, and DELIBERATE;

     *  private extensions;

     *  presentation-layer wording for user-visible disclosures;

     *  protocol-specific field mappings, if any;

     *  trust context for emitted and received MARC records; and

     *  policy constraints affecting ABSTAIN or ESCALATE.

  21.  Interoperability and Operational Considerations

     MARC is implementation-agnostic.  Interoperability is achieved when
     distinct systems preserve the semantics of the action set,
     uncertainty taxonomy, remediability values, confidence-band meanings,
     confidence-target meanings, and disclosure projection, even if
     internal scoring methods differ.






  c4tz                     Expires 4 November 2026               [Page 30]


  Internet-Draft                    MARC                          May 2026


     Deployments that exchange MARC-Core records SHOULD document local
     extensions, confidence-band thresholds, score normalization
     practices, and any task-family-specific calibration regime.

     If the base model, retrieval stack, tool availability, or safety
     policy changes materially, implementations SHOULD re-evaluate
     calibration and action-selection performance before continuing to
     claim operational equivalence.

     If presentation-layer wording, ranking, or visual design changes
     materially, deployments SHOULD also re-evaluate user behavior
     effects, including reliance, clarification compliance, and escalation
     uptake, because these properties can shift even when the underlying
     model is unchanged.

     MARC records SHOULD be treated as control metadata, not as
     authoritative proof that an answer is correct.  Downstream systems
     SHOULD continue to apply ordinary validation, authorization,
     provenance, and safety controls.

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

  23.  Informative References

     [GILBERT2024]
                Gilbert, S. J., "Cognitive offloading is value-based
                decision making: Modelling cognitive effort and the
                expected value of memory",
                DOI 10.1016/j.cognition.2024.105783, June 2024,
                <https://doi.org/10.1016/j.cognition.2024.105783>.

     [GRIOT2025]
                Griot, M., "Large Language Models lack essential
                metacognition for reliable medical reasoning",
                DOI 10.1038/s41467-024-55628-6, January 2025,
                <https://doi.org/10.1038/s41467-024-55628-6>.






  c4tz                     Expires 4 November 2026               [Page 31]


  Internet-Draft                    MARC                          May 2026


     [JSON]     Bray, T., "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>.

     [JSON-SCHEMA-2020-12]
                Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
                Schema: A Media Type for Describing JSON Documents", June
                2022, <https://json-schema.org/draft/2020-12/>.

     [KUMARAN2026]
                Kumaran, D., Fleming, S. M., and V. Patraucean, "Competing
                Biases underlie Overconfidence and Underconfidence in
                LLMs", DOI 10.1038/s42256-026-01217-9, April 2026,
                <https://doi.org/10.1038/s42256-026-01217-9>.

     [LI-MECO2025]
                Li, W., Li, D., Dong, K., Zhang, C., Zhang, H., Liu, W.,
                Wang, Y., Tang, R., and Y. Liu, "Adaptive Tool Use in
                Large Language Models with Meta-Cognition Trigger", DOI 
                10.18653/v1/2025.acl-long.655, July 2025,
                <https://doi.org/10.18653/v1/2025.acl-long.655>.

     [LIU-CONFUSE2025]
                Liu, J., Peng, J., Wu, X., Li, X., Ge, T., Zheng, B., and
                Y. Liu, "Do not Abstain! Identify and Solve the
                Uncertainty", DOI 10.18653/v1/2025.acl-long.840, July
                2025, <https://doi.org/10.18653/v1/2025.acl-long.840>.

     [SALVI2025]
                Salvi, F., Ribeiro, M. H., and R. West, "On the
                conversational persuasiveness of GPT-4",
                DOI 10.1038/s41562-025-02194-6, May 2025,
                <https://doi.org/10.1038/s41562-025-02194-6>.

     [SERAPIO2025]
                Serapio-Garcia, G., Safdari, M., and M. Mataric, "A
                psychometric framework for evaluating and shaping
                personality traits in large language models",
                DOI 10.1038/s42256-025-01115-6, December 2025,
                <https://doi.org/10.1038/s42256-025-01115-6>.

     [STEYVERS-KNOW2025]
                Steyvers, M., Tejeda, H., and A. Kumar, "What large
                language models know and what people think they know",
                DOI 10.1038/s42256-024-00976-7, January 2025,
                <https://doi.org/10.1038/s42256-024-00976-7>.




  c4tz                     Expires 4 November 2026               [Page 32]


  Internet-Draft                    MARC                          May 2026


     [STEYVERS-META2025]
                Steyvers, M. and M. A. K. Peters, "Metacognition and
                Uncertainty Communication in Humans and Large Language
                Models", DOI 10.1177/09637214251391158, November 2025,
                <https://doi.org/10.1177/09637214251391158>.

  Appendix A.  End-to-End Decision Flow Example

     This appendix is non-normative.

     The following example shows how a user request becomes an assessment,
     a selected action, and a disclosure.

     User request:

     Is this tax deduction allowed?

     Assessment:

     *  the jurisdiction is missing;

     *  the tax year is missing;

     *  current tax authority may be required;

     *  the primary uncertainty source is ambiguity;

     *  the secondary uncertainty source is missing_evidence;

     *  the best remediation is user_clarification; and

     *  the selected action is CLARIFY.

     MARC-Core record:

















  c4tz                     Expires 4 November 2026               [Page 33]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "decision_id": "example-tax-001",
       "pre_capability": 0.33,
       "uncertainty": {
         "ambiguity": 0.86,
         "missing_evidence": 0.63,
         "capability_limit": 0.19,
         "evidence_conflict": 0.07,
         "safety": 0.03
       },
       "primary_source": "ambiguity",
       "secondary_source": "missing_evidence",
       "remediability": "user_clarification",
       "selected_action": "CLARIFY",
       "post_answer_confidence": null,
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "ask for jurisdiction and tax year"
     }

     MARC-Disclosure projection:

     {
       "answer": "Which jurisdiction and tax year should I use?",
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "uncertainty_source": "ambiguity",
       "recommended_next_step": "provide the jurisdiction and tax year",
       "selected_action": "CLARIFY"
     }

     This example intentionally does not answer the tax question, because
     doing so would require assumptions about facts the user has not
     supplied.

  Appendix B.  Example MARC-Core Records

     This appendix is non-normative.

  B.1.  Ambiguous Request










  c4tz                     Expires 4 November 2026               [Page 34]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "decision_id": "example-ambiguous-001",
       "pre_capability": 0.44,
       "uncertainty": {
         "ambiguity": 0.81,
         "missing_evidence": 0.18,
         "capability_limit": 0.12,
         "evidence_conflict": 0.03,
         "safety": 0.00
       },
       "primary_source": "ambiguity",
       "secondary_source": "missing_evidence",
       "remediability": "user_clarification",
       "selected_action": "CLARIFY",
       "post_answer_confidence": null,
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "ask jurisdiction and tax year"
     }

  B.2.  Missing Evidence

     {
       "marc_version": "1.0",
       "decision_id": "example-retrieve-001",
       "pre_capability": 0.39,
       "uncertainty": {
         "ambiguity": 0.09,
         "missing_evidence": 0.84,
         "capability_limit": 0.14,
         "evidence_conflict": 0.11,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "secondary_source": "evidence_conflict",
       "remediability": "retrieval",
       "selected_action": "RETRIEVE",
       "post_answer_confidence": null,
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "retrieve authoritative current sources"
     }

  B.3.  Tool Use






  c4tz                     Expires 4 November 2026               [Page 35]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "decision_id": "example-tool-001",
       "pre_capability": 0.52,
       "uncertainty": {
         "ambiguity": 0.08,
         "missing_evidence": 0.12,
         "capability_limit": 0.61,
         "evidence_conflict": 0.04,
         "safety": 0.00
       },
       "primary_source": "capability_limit",
       "secondary_source": "missing_evidence",
       "remediability": "tool",
       "selected_action": "TOOL",
       "post_answer_confidence": null,
       "confidence_band": "medium",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "invoke a calculation tool and reassess"
     }

  B.4.  Capability Limit in a High-Risk Setting

     {
       "marc_version": "1.0",
       "decision_id": "example-escalate-001",
       "pre_capability": 0.21,
       "uncertainty": {
         "ambiguity": 0.06,
         "missing_evidence": 0.27,
         "capability_limit": 0.88,
         "evidence_conflict": 0.14,
         "safety": 0.19
       },
       "primary_source": "capability_limit",
       "secondary_source": "missing_evidence",
       "remediability": "human",
       "selected_action": "ESCALATE",
       "post_answer_confidence": null,
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "escalate to a qualified human reviewer"
     }

  B.5.  Answer






  c4tz                     Expires 4 November 2026               [Page 36]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "decision_id": "example-answer-001",
       "pre_capability": 0.82,
       "uncertainty": {
         "ambiguity": 0.05,
         "missing_evidence": 0.12,
         "capability_limit": 0.08,
         "evidence_conflict": 0.02,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "secondary_source": "capability_limit",
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": 0.79,
       "confidence_band": "high",
       "confidence_target": "answer",
       "recommended_next_step": "provide answer with cited limitations"
     }

  Appendix C.  Example MARC-Disclosure Objects

     This appendix is non-normative.

  C.1.  Clarification Disclosure

     {
       "answer": "Which jurisdiction and date range should I use?",
       "confidence_band": "low",
       "confidence_target": "direct_answer_suitability",
       "uncertainty_source": "ambiguity",
       "recommended_next_step": "provide jurisdiction and tax year",
       "selected_action": "CLARIFY"
     }

  C.2.  Answer After Retrieval Disclosure

     This example represents a terminal ANSWER after the controller has
     already performed retrieval and reassessed the task.  The residual
     uncertainty source remains missing_evidence because the answer
     depends on the scope and freshness of retrieved authority, not
     because the system skipped retrieval.








  c4tz                     Expires 4 November 2026               [Page 37]


  Internet-Draft                    MARC                          May 2026


     {
       "answer": "Retrieved authority indicates this is allowed.",
       "confidence_band": "medium",
       "confidence_target": "answer",
       "uncertainty_source": "missing_evidence",
       "recommended_next_step": "verify the authority before filing",
       "selected_action": "ANSWER"
     }

  Appendix D.  Non-Normative JSON Schemas

     This appendix is non-normative.  The following JSON Schemas
     [JSON-SCHEMA-2020-12] are provided as machine-readable validation
     aids for JSON [JSON] encodings of MARC-Core and MARC-Disclosure.  The
     normative requirements are the field semantics and constraints
     defined in the body of this document.

  D.1.  MARC-Core JSON Schema

     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "https://example.invalid/marc/marc-core.schema.json",
       "title": "MARC-Core Record",
       "description": "Non-normative schema for MARC-Core 1.0.",
       "type": "object",
       "required": [
         "marc_version",
         "pre_capability",
         "uncertainty",
         "primary_source",
         "remediability",
         "selected_action",
         "confidence_band",
         "confidence_target",
         "recommended_next_step"
       ],
       "properties": {
         "marc_version": {
           "type": "string",
           "const": "1.0"
         },
         "decision_id": {
           "type": "string",
           "minLength": 1,
           "maxLength": 128
         },
         "parent_decision_id": {
           "type": ["string", "null"],



  c4tz                     Expires 4 November 2026               [Page 38]


  Internet-Draft                    MARC                          May 2026


           "minLength": 1,
           "maxLength": 128
         },
         "iteration": {
           "type": "integer",
           "minimum": 0
         },
         "max_iterations": {
           "type": "integer",
           "minimum": 0
         },
         "calibration_profile": {
           "type": "string",
           "minLength": 1,
           "maxLength": 128
         },
         "pre_capability": {
           "type": "number",
           "minimum": 0.0,
           "maximum": 1.0
         },
         "uncertainty": {
           "type": "object",
           "required": [
             "ambiguity",
             "missing_evidence",
             "capability_limit",
             "evidence_conflict",
             "safety"
           ],
           "properties": {
             "ambiguity": {
               "type": "number",
               "minimum": 0.0,
               "maximum": 1.0
             },
             "missing_evidence": {
               "type": "number",
               "minimum": 0.0,
               "maximum": 1.0
             },
             "capability_limit": {
               "type": "number",
               "minimum": 0.0,
               "maximum": 1.0
             },
             "evidence_conflict": {
               "type": "number",



  c4tz                     Expires 4 November 2026               [Page 39]


  Internet-Draft                    MARC                          May 2026


               "minimum": 0.0,
               "maximum": 1.0
             },
             "safety": {
               "type": "number",
               "minimum": 0.0,
               "maximum": 1.0
             }
           },
           "additionalProperties": false
         },
         "primary_source": {
           "type": "string",
           "enum": [
             "ambiguity",
             "missing_evidence",
             "capability_limit",
             "evidence_conflict",
             "safety"
           ]
         },
         "secondary_source": {
           "type": ["string", "null"],
           "enum": [
             "ambiguity",
             "missing_evidence",
             "capability_limit",
             "evidence_conflict",
             "safety",
             null
           ]
         },
         "remediability": {
           "type": "string",
           "enum": [
             "user_clarification",
             "retrieval",
             "tool",
             "human",
             "none"
           ]
         },
         "selected_action": {
           "type": "string",
           "enum": [
             "ANSWER",
             "CLARIFY",
             "RETRIEVE",



  c4tz                     Expires 4 November 2026               [Page 40]


  Internet-Draft                    MARC                          May 2026


             "TOOL",
             "DELIBERATE",
             "ABSTAIN",
             "ESCALATE"
           ]
         },
         "post_answer_confidence": {
           "type": ["number", "null"],
           "minimum": 0.0,
           "maximum": 1.0
         },
         "confidence_band": {
           "type": "string",
           "enum": [
             "low",
             "medium",
             "high"
           ]
         },
         "confidence_target": {
           "type": "string",
           "enum": [
             "answer",
             "direct_answer_suitability",
             "action_suitability"
           ]
         },
         "recommended_next_step": {
           "type": "string",
           "minLength": 1,
           "maxLength": 280
         }
       },
       "patternProperties": {
         "^x_": {}
       },
       "additionalProperties": false,
       "allOf": [
         {
           "if": {
             "properties": {
               "selected_action": {
                 "const": "ANSWER"
               }
             },
             "required": [
               "selected_action"
             ]



  c4tz                     Expires 4 November 2026               [Page 41]


  Internet-Draft                    MARC                          May 2026


           },
           "then": {
             "required": [
               "post_answer_confidence",
               "confidence_target"
             ],
             "properties": {
               "post_answer_confidence": {
                 "type": "number",
                 "minimum": 0.0,
                 "maximum": 1.0
               },
               "confidence_target": {
                 "const": "answer"
               }
             }
           }
         }
       ]
     }

  D.2.  MARC-Disclosure JSON Schema

     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "https://example.invalid/marc/marc-disclosure.schema.json",
       "title": "MARC-Disclosure Object",
       "description": "Non-normative schema for MARC-Disclosure 1.0.",
       "type": "object",
       "required": [
         "answer",
         "confidence_band",
         "confidence_target",
         "uncertainty_source",
         "recommended_next_step"
       ],
       "properties": {
         "answer": {
           "type": "string",
           "minLength": 1
         },
         "confidence_band": {
           "type": "string",
           "enum": [
             "low",
             "medium",
             "high"
           ]



  c4tz                     Expires 4 November 2026               [Page 42]


  Internet-Draft                    MARC                          May 2026


         },
         "confidence_target": {
           "type": "string",
           "enum": [
             "answer",
             "direct_answer_suitability",
             "action_suitability"
           ]
         },
         "uncertainty_source": {
           "type": "string",
           "enum": [
             "ambiguity",
             "missing_evidence",
             "capability_limit",
             "evidence_conflict",
             "safety"
           ]
         },
         "recommended_next_step": {
           "type": "string",
           "minLength": 1,
           "maxLength": 280
         },
         "selected_action": {
           "type": "string",
           "enum": [
             "ANSWER",
             "CLARIFY",
             "RETRIEVE",
             "TOOL",
             "DELIBERATE",
             "ABSTAIN",
             "ESCALATE"
           ]
         }
       },
       "patternProperties": {
         "^x_": {}
       },
       "additionalProperties": false
     }

  Appendix E.  Evaluation Considerations

     This appendix is non-normative.





  c4tz                     Expires 4 November 2026               [Page 43]


  Internet-Draft                    MARC                          May 2026


     A deployment claiming MARC conformance SHOULD evaluate at least the
     following properties:

     *  task accuracy or task success;

     *  quality of primary-action selection;

     *  quality of uncertainty-source attribution;

     *  confidence calibration and discrimination;

     *  rate of unnecessary retrieval, tool use, or escalation; and

     *  effects on user overreliance.

     A deployment claiming MARC conformance SHOULD evaluate, where
     applicable:

     *  action-selection accuracy for each selected_action;

     *  precision and recall for CLARIFY, RETRIEVE, TOOL, ABSTAIN, and
        ESCALATE decisions;

     *  primary_source attribution accuracy;

     *  confusion matrices for uncertainty-source attribution;

     *  calibration error for confidence_band mappings;

     *  correctness of confidence_target assignment;

     *  false-direct-answer rate, where ANSWER was selected but a
        corrective action would have materially improved reliability;

     *  false-externalization rate, including unnecessary RETRIEVE, TOOL,
        or ESCALATE actions;

     *  loop termination behavior under adversarial or pathological
        inputs;

     *  escalation appropriateness in high-risk domains; and

     *  user comprehension of confidence_band, confidence_target,
        uncertainty_source, and recommended_next_step.







  c4tz                     Expires 4 November 2026               [Page 44]


  Internet-Draft                    MARC                          May 2026


     Evaluation datasets SHOULD include examples for each primary_source
     and each selected_action.  They SHOULD also include negative examples
     where the superficially plausible action is not the correct MARC
     action.

     When the task structure permits, evaluation MAY include both ordinary
     calibration metrics and metacognitive sensitivity metrics in order to
     distinguish performance from knowledge about performance.

     For deployments involving human-AI interaction, evaluation SHOULD
     also include human-side measures such as reliance calibration,
     refusal comprehension, clarification burden, escalation acceptance,
     and whether users can correctly restate the source of uncertainty
     after interaction.

  Appendix F.  Design Rationale and Literature Traceability

     This appendix is non-normative.

     The requirement to separate pre-decision capability and post-decision
     confidence is informed by work in human and model metacognition
     [STEYVERS-META2025] and by evidence of choice-supportive bias in LLM
     confidence estimates [KUMARAN2026].

     The confidence_target field is included because confidence_band alone
     can be ambiguous across answer and non-answer actions.  For ANSWER,
     confidence_band refers to the candidate answer.  For actions such as
     CLARIFY, RETRIEVE, TOOL, ABSTAIN, or ESCALATE, confidence_band
     usually refers to direct-answer suitability under current conditions.

     The uncertainty taxonomy and the emphasis on choosing a corrective
     action rather than only abstaining are motivated by benchmark work on
     identifying and solving uncertainty [LIU-CONFUSE2025].

     The treatment of retrieval and tool use as controlled externalization
     is motivated by work on value-based cognitive offloading
     [GILBERT2024].

     The prohibition on using MARC signals for persuasive optimization is
     motivated by findings on AI persuasion risks [SALVI2025].

  Appendix G.  Changes from -01

     This -02 revision includes the following changes relative to draft-
     c4tz-marc-01:

     *  fixed the BCP 14 boilerplate wording;




  c4tz                     Expires 4 November 2026               [Page 45]


  Internet-Draft                    MARC                          May 2026


     *  added an Applicability section;

     *  added a Trust Model section for MARC emitters and receivers;

     *  added confidence_target to clarify what confidence_band applies
        to;

     *  added optional decision correlation fields, including decision_id,
        parent_decision_id, iteration, max_iterations, and
        calibration_profile;

     *  added cross-field consistency constraints for MARC-Core records;

     *  clarified that safety is a control constraint and not purely
        epistemic uncertainty;

     *  strengthened MARC-Disclosure by preserving confidence_target;

     *  expanded validation constraints and JSON Schemas;

     *  added validation test vectors;

     *  added implementation-status guidance;

     *  split privacy and manipulation-resistance considerations;

     *  expanded evaluation guidance with action-selection, attribution,
        calibration, externalization, escalation, and loop-termination
        metrics;

     *  added JSON and JSON Schema references; and

     *  clarified that MARC remains an Informational interoperability
        profile, not a transport protocol or Internet Standard.

  Appendix H.  Validation Test Vectors

     This appendix is non-normative.

  H.1.  Valid ANSWER Record

     A valid ANSWER record includes selected_action set to ANSWER,
     post_answer_confidence present and non-null, and confidence_target
     set to answer.







  c4tz                     Expires 4 November 2026               [Page 46]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "pre_capability": 0.80,
       "uncertainty": {
         "ambiguity": 0.05,
         "missing_evidence": 0.10,
         "capability_limit": 0.08,
         "evidence_conflict": 0.02,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "secondary_source": null,
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": 0.77,
       "confidence_band": "high",
       "confidence_target": "answer",
       "recommended_next_step": "provide the answer"
     }

  H.2.  Invalid ANSWER without post_answer_confidence

     The following record is invalid because selected_action is ANSWER but
     post_answer_confidence is null.

     {
       "marc_version": "1.0",
       "pre_capability": 0.80,
       "uncertainty": {
         "ambiguity": 0.05,
         "missing_evidence": 0.10,
         "capability_limit": 0.08,
         "evidence_conflict": 0.02,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": null,
       "confidence_band": "high",
       "confidence_target": "answer",
       "recommended_next_step": "provide the answer"
     }

  H.3.  Invalid primary_source none

     The following record is invalid because MARC 1.0 does not define none
     as an uncertainty source.



  c4tz                     Expires 4 November 2026               [Page 47]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "pre_capability": 0.80,
       "uncertainty": {
         "ambiguity": 0.00,
         "missing_evidence": 0.00,
         "capability_limit": 0.00,
         "evidence_conflict": 0.00,
         "safety": 0.00
       },
       "primary_source": "none",
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": 0.90,
       "confidence_band": "high",
       "confidence_target": "answer",
       "recommended_next_step": "provide the answer"
     }

  H.4.  Invalid Score Range

     The following record is invalid because uncertainty.missing_evidence
     is greater than 1.0.

     {
       "marc_version": "1.0",
       "pre_capability": 0.80,
       "uncertainty": {
         "ambiguity": 0.05,
         "missing_evidence": 1.20,
         "capability_limit": 0.08,
         "evidence_conflict": 0.02,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": 0.77,
       "confidence_band": "high",
       "confidence_target": "answer",
       "recommended_next_step": "provide the answer"
     }

  H.5.  Invalid confidence_target for ANSWER

     The following record is invalid because selected_action is ANSWER but
     confidence_target is direct_answer_suitability.




  c4tz                     Expires 4 November 2026               [Page 48]


  Internet-Draft                    MARC                          May 2026


     {
       "marc_version": "1.0",
       "pre_capability": 0.80,
       "uncertainty": {
         "ambiguity": 0.05,
         "missing_evidence": 0.10,
         "capability_limit": 0.08,
         "evidence_conflict": 0.02,
         "safety": 0.00
       },
       "primary_source": "missing_evidence",
       "remediability": "none",
       "selected_action": "ANSWER",
       "post_answer_confidence": 0.77,
       "confidence_band": "high",
       "confidence_target": "direct_answer_suitability",
       "recommended_next_step": "provide the answer"
     }

  Appendix I.  Implementation Status

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

     At the time of writing, the following implementation artifacts are
     planned or available:

     *  JSON Schema validation for MARC-Core and MARC-Disclosure objects;

     *  positive and negative validation examples;

     *  a reference projection from MARC-Core to MARC-Disclosure;

     *  example mappings for API gateway metadata;

     *  example mappings for agent handoff envelopes; and

     *  evaluation guidance for action selection, uncertainty-source
        attribution, confidence-target assignment, and confidence-band
        calibration.

  Appendix J.  Acknowledgments

     The document structure is intentionally conservative so that it can
     be submitted as an individual Internet-Draft with minimal procedural
     friction and then iterated through community review.

  Author's Address




  c4tz                     Expires 4 November 2026               [Page 49]


  Internet-Draft                    MARC                          May 2026


     c4tz
     c0dx3
     France
     Email: c4tzzzz@proton.me















































  c4tz                     Expires 4 November 2026               [Page 50]


name: draft-stone-adrp
rev: 00
title: ADRP: Agent Dispute Resolution Protocol
time: 2026-04-25T23:51:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-27T23:51:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Policy/governance", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:47.115462+00:00
source: ietf
abstract:
  This document defines the Agent Dispute Resolution Protocol (ADRP), a
     wire protocol and state machine for resolving disputes that arise
     from cryptographically-attested agent-to-agent (A2A) transactions.
     ADRP is the companion specification to ATXN (draft-stone-atxn-00),
     which defines what an A2A transaction is.  ADRP defines what happens
     when a party contests one.

     ADRP severs an equivalence that every prior agentic commerce design
     has implicitly assumed: that a valid cryptographic proof bundle
     equals contractual satisfaction.  It does not.  Conduit-style
     cryptographic verifiers prove that an agent took specified actions;
     they do not prove that those actions satisfied the principal's Intent
     Mandate.  ADRP bifurcates disputes into a cryptographic class
     (resolvable by code from the proof bundle and mandate chain) and a
     semantic class (resolvable only against pre-committed machine-
     readable acceptance criteria, with arbitration escalation when those
     criteria are absent or under-specified).

     ADRP introduces the Arbitration Mandate as a fourth element of the
     AP2 mandate chain (Intent / Cart / Payment / Arbitration), pre-signed
     by the principal at agent-deployment time.  The Arbitration Mandate
     is the FAA Section 2-compliant written agreement that anchors the
     entire protocol legally without statutory change.

     ADRP defines a counter-attestation override pattern in which a signed
     RulingBundle supersedes a Conduit ProofBundle by a signing-time
     precedence rule rather than by mutation.  Both the original
     attestation and the override are preserved forever in the hash chain;
     "override" is a verification-time computation, not a write.

     Companion specifications (all co-submitted as Internet-Drafts, work
     in progress):

     *  ATXN (draft-stone-atxn-00): defines the A2A transaction primitive
        that ADRP resolves disputes over

     *  AIVS (draft-stone-aivs-01): cryptographic audit-trail substrate
        for proof bundles

     *  VCAP (draft-stone-vcap-01): verified-commerce escrow rails
        consumed by ADRP EscrowDirectives

     *  ATEP (draft-stone-atep-01): trust passports referenced by Standing
        Tokens in ADRP

full_text:
  Internet Engineering Task Force                                 B. stone
  Internet-Draft                                              SwarmSync.AI
  Intended status: Standards Track                           25 April 2026
  Expires: 27 October 2026


                  ADRP: Agent Dispute Resolution Protocol
                            draft-stone-adrp-00

  Abstract

     This document defines the Agent Dispute Resolution Protocol (ADRP), a
     wire protocol and state machine for resolving disputes that arise
     from cryptographically-attested agent-to-agent (A2A) transactions.
     ADRP is the companion specification to ATXN (draft-stone-atxn-00),
     which defines what an A2A transaction is.  ADRP defines what happens
     when a party contests one.

     ADRP severs an equivalence that every prior agentic commerce design
     has implicitly assumed: that a valid cryptographic proof bundle
     equals contractual satisfaction.  It does not.  Conduit-style
     cryptographic verifiers prove that an agent took specified actions;
     they do not prove that those actions satisfied the principal's Intent
     Mandate.  ADRP bifurcates disputes into a cryptographic class
     (resolvable by code from the proof bundle and mandate chain) and a
     semantic class (resolvable only against pre-committed machine-
     readable acceptance criteria, with arbitration escalation when those
     criteria are absent or under-specified).

     ADRP introduces the Arbitration Mandate as a fourth element of the
     AP2 mandate chain (Intent / Cart / Payment / Arbitration), pre-signed
     by the principal at agent-deployment time.  The Arbitration Mandate
     is the FAA Section 2-compliant written agreement that anchors the
     entire protocol legally without statutory change.

     ADRP defines a counter-attestation override pattern in which a signed
     RulingBundle supersedes a Conduit ProofBundle by a signing-time
     precedence rule rather than by mutation.  Both the original
     attestation and the override are preserved forever in the hash chain;
     "override" is a verification-time computation, not a write.

     Companion specifications (all co-submitted as Internet-Drafts, work
     in progress):

     *  ATXN (draft-stone-atxn-00): defines the A2A transaction primitive
        that ADRP resolves disputes over





  stone                    Expires 27 October 2026                [Page 1]


  Internet-Draft                    ADRP                        April 2026


     *  AIVS (draft-stone-aivs-01): cryptographic audit-trail substrate
        for proof bundles

     *  VCAP (draft-stone-vcap-01): verified-commerce escrow rails
        consumed by ADRP EscrowDirectives

     *  ATEP (draft-stone-atep-01): trust passports referenced by Standing
        Tokens in ADRP

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

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.1.  The Problem . . . . . . . . . . . . . . . . . . . . . . .   5
       1.2.  What ADRP Defines . . . . . . . . . . . . . . . . . . . .   5
       1.3.  What ADRP Deliberately Does NOT Do  . . . . . . . . . . .   6
       1.4.  Design Tenets . . . . . . . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6



  stone                    Expires 27 October 2026                [Page 2]


  Internet-Draft                    ADRP                        April 2026


     3.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
     4.  The Arbitration Mandate . . . . . . . . . . . . . . . . . . .   8
       4.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  Required Fields . . . . . . . . . . . . . . . . . . . . .   9
       4.3.  Anchoring . . . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.  Mutability  . . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Standing and the Flag/File Distinction  . . . . . . . . . . .  10
       5.1.  Parties . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Agent Flag Rights . . . . . . . . . . . . . . . . . . . .  10
       5.3.  Principal File Rights . . . . . . . . . . . . . . . . . .  10
       5.4.  Flag Expiration . . . . . . . . . . . . . . . . . . . . .  10
       5.5.  Pre-Authorized Dispute Delegate . . . . . . . . . . . . .  10
     6.  Dispute Taxonomy  . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Cryptographic-Class Disputes  . . . . . . . . . . . . . .  10
       6.2.  Semantic-Class Disputes . . . . . . . . . . . . . . . . .  11
       6.3.  Classification  . . . . . . . . . . . . . . . . . . . . .  12
       6.4.  ATXN dispute_class to ADRP Claim Code Mapping . . . . . .  12
       6.5.  Out of Scope (v0.1) . . . . . . . . . . . . . . . . . . .  12
     7.  The Counter-Attestation Override Pattern  . . . . . . . . . .  13
       7.1.  Invariant . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  RulingBundle Structure  . . . . . . . . . . . . . . . . .  13
       7.3.  Verification Rule . . . . . . . . . . . . . . . . . . . .  13
       7.4.  Why This Works  . . . . . . . . . . . . . . . . . . . . .  14
     8.  Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . .  14
       8.1.  Message Types . . . . . . . . . . . . . . . . . . . . . .  14
       8.2.  Common Message Envelope . . . . . . . . . . . . . . . . .  14
       8.3.  Canonicalization  . . . . . . . . . . . . . . . . . . . .  15
     9.  State Machine . . . . . . . . . . . . . . . . . . . . . . . .  15
       9.1.  States  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       9.2.  ATXN State Machine Join Points  . . . . . . . . . . . . .  15
       9.3.  Invariants  . . . . . . . . . . . . . . . . . . . . . . .  16
     10. Tier Parameters . . . . . . . . . . . . . . . . . . . . . . .  16
       10.1.  Tier Routing . . . . . . . . . . . . . . . . . . . . . .  17
       10.2.  Default Ruling on SLA Miss . . . . . . . . . . . . . . .  17
     11. Cart Mandate Acceptance Criteria  . . . . . . . . . . . . . .  18
       11.1.  Required Field . . . . . . . . . . . . . . . . . . . . .  18
       11.2.  Check Types  . . . . . . . . . . . . . . . . . . . . . .  18
       11.3.  Conduit Attestation Against Checks . . . . . . . . . . .  18
       11.4.  The Authoring Helper (Normative for Deployment)  . . . .  19
     12. Arbitrator Pool . . . . . . . . . . . . . . . . . . . . . . .  19
       12.1.  v0.1: Curated Pool . . . . . . . . . . . . . . . . . . .  19
       12.2.  Selection Algorithm  . . . . . . . . . . . . . . . . . .  19
       12.3.  Pool Composition . . . . . . . . . . . . . . . . . . . .  19
       12.4.  Arbitrator Credentialing . . . . . . . . . . . . . . . .  19
       12.5.  v0.2 Roadmap . . . . . . . . . . . . . . . . . . . . . .  19
     13. Filing Fee Economics  . . . . . . . . . . . . . . . . . . . .  19
       13.1.  Fee Structure  . . . . . . . . . . . . . . . . . . . . .  20
       13.2.  Why Not a Tokenized Stake  . . . . . . . . . . . . . . .  20



  stone                    Expires 27 October 2026                [Page 3]


  Internet-Draft                    ADRP                        April 2026


       13.3.  Slashing . . . . . . . . . . . . . . . . . . . . . . . .  20
       13.4.  Arbitrator Compensation  . . . . . . . . . . . . . . . .  21
     14. Appeals . . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       14.1.  Trigger  . . . . . . . . . . . . . . . . . . . . . . . .  21
       14.2.  Appeal Panel . . . . . . . . . . . . . . . . . . . . . .  21
       14.3.  Finality . . . . . . . . . . . . . . . . . . . . . . . .  21
       14.4.  Appeal Override  . . . . . . . . . . . . . . . . . . . .  21
     15. Precedent Corpus  . . . . . . . . . . . . . . . . . . . . . .  21
       15.1.  Indexing . . . . . . . . . . . . . . . . . . . . . . . .  21
       15.2.  Citation Requirement . . . . . . . . . . . . . . . . . .  21
       15.3.  v0.1 vs v0.2 . . . . . . . . . . . . . . . . . . . . . .  21
     16. Verification Algorithm  . . . . . . . . . . . . . . . . . . .  22
       16.1.  The verify_resolution Function . . . . . . . . . . . . .  22
       16.2.  Determinism Requirement  . . . . . . . . . . . . . . . .  22
       16.3.  Offline Requirement  . . . . . . . . . . . . . . . . . .  23
     17. SDK Surface . . . . . . . . . . . . . . . . . . . . . . . . .  23
       17.1.  Appeal as Re-Entry . . . . . . . . . . . . . . . . . . .  23
       17.2.  LOC Budget . . . . . . . . . . . . . . . . . . . . . . .  23
       17.3.  Golden Test Cases  . . . . . . . . . . . . . . . . . . .  23
     18. Scope Locks for v0.1  . . . . . . . . . . . . . . . . . . . .  24
     19. Security Considerations . . . . . . . . . . . . . . . . . . .  25
       19.1.  The >90% Auto-Resolution Target Is NOT a Protocol
               Property  . . . . . . . . . . . . . . . . . . . . . . .  25
       19.2.  The Bifurcation Seam . . . . . . . . . . . . . . . . . .  25
       19.3.  Arbitrator Collusion . . . . . . . . . . . . . . . . . .  25
       19.4.  Filing Fee as DoS Vector . . . . . . . . . . . . . . . .  26
       19.5.  Standing Token Replay  . . . . . . . . . . . . . . . . .  26
       19.6.  Time-Skew Attacks  . . . . . . . . . . . . . . . . . . .  26
       19.7.  Jurisdictional Enforceability of the Arbitration
               Mandate . . . . . . . . . . . . . . . . . . . . . . . .  26
       19.8.  Sanctions Screening  . . . . . . . . . . . . . . . . . .  26
       19.9.  Principal Capacity Mid-Dispute . . . . . . . . . . . . .  26
       19.10. Acknowledged Residual Risks  . . . . . . . . . . . . . .  26
     20. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
       20.1.  ADRP JSON-LD Context . . . . . . . . . . . . . . . . . .  27
       20.2.  ADRP Claim Code Registry . . . . . . . . . . . . . . . .  27
       20.3.  ADRP Verdict Enum  . . . . . . . . . . . . . . . . . . .  28
       20.4.  ADRP Trusted Registries List . . . . . . . . . . . . . .  28
     21. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  28
     22. Normative References  . . . . . . . . . . . . . . . . . . . .  28
     23. Informative References  . . . . . . . . . . . . . . . . . . .  30
     Appendix A: JSON Schemas (Informative)  . . . . . . . . . . . . .  31
       A.1 DisputeFiling Schema  . . . . . . . . . . . . . . . . . . .  31
       A.2 RulingBundle Schema . . . . . . . . . . . . . . . . . . . .  32
     Appendix B: Worked Example (Informative)  . . . . . . . . . . . .  33
       B.1 Scenario  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       B.2 Sequence  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       B.3 Verification  . . . . . . . . . . . . . . . . . . . . . . .  34



  stone                    Expires 27 October 2026                [Page 4]


  Internet-Draft                    ADRP                        April 2026


       B.4 Precedent . . . . . . . . . . . . . . . . . . . . . . . . .  34
     Appendix C: Open Issues for Shadow-Mode Validation  . . . . . . .  34
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  35

  1.  Introduction

  1.1.  The Problem

     Conduit and similar cryptographic browser-automation verifiers
     produce SHA-256 hash-chained audit trails of agent task delivery.
     The proof bundles they produce are self-verifiable: any third party
     can replay the chain and confirm the recorded events occurred in the
     recorded order with the recorded signatures.

     This is necessary but not sufficient.

     A proof bundle attests that an agent took actions X, Y, and Z.  It
     does not attest that X, Y, and Z satisfied the principal's Intent
     Mandate.  Empirical data from Kleros (~40% of decentralized
     arbitration cases turn on spec ambiguity, not on whether action
     occurred) and from Upwork, Stripe Connect, and eBay (auto-resolve
     ceilings of 60-95% with all systems hitting walls below 95%)
     demonstrates that cryptographic proof of execution does not eliminate
     disputes — it relocates them to spec interpretation.

     ADRP addresses the relocated dispute surface without breaking the
     cryptographic substrate.

  1.2.  What ADRP Defines

     A five-layer protocol stacked on the existing Conduit + AP2 + ATXN
     stack:

     Layer 5:  Precedent corpus (signed RulingBundles indexed by Cart
        Mandate template hash)

     Layer 4:  Tier router (L1 atomic / L2 mandated / L3 fiduciary)

     Layer 3:  Resolution engine (cryptographic-class auto, semantic-class
        arbitration)

     Layer 2:  Counter-attestation primitive (append-only override of
        Conduit ProofBundle)

     Layer 1:  Arbitration Mandate (4th AP2 mandate, FAA Section 2 written
        agreement)





  stone                    Expires 27 October 2026                [Page 5]


  Internet-Draft                    ADRP                        April 2026


  1.3.  What ADRP Deliberately Does NOT Do

     *  ADRP does not modify the Conduit ProofBundle.

     *  ADRP does not grant agents independent dispute standing.

     *  ADRP does not require statutory change.

     *  ADRP does not specify how acceptance criteria are authored.

     *  ADRP does not promise greater than 90% auto-resolution.

  1.4.  Design Tenets

     Bifurcation:  Cryptographic and semantic disputes require different
        paths.

     Append-only override:  The hash chain is never mutated.

     Principal-only standing:  Agents flag; only principals file.

     Time-windowed default-resolution:  Silence equals approval.

     Economic friction on filing:  Non-refundable filing fee deters spam.

     No tokenized stake:  Filing fees are USD-denominated, non-refundable
        to the filer, refundable to the prevailing party.

     Pre-committed arbiter:  The arbitration pool is named in the
        Arbitration Mandate at agent-deployment time.

     Curated pool for v0.1:  Decentralized token-staked pools deferred to
        v0.2.

     US-only B2B for v0.1:  Cross-border, consumer, and PSD2/Reg E scope
        deferred.

  2.  Terminology

     The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
     SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
     interpreted as described in BCP 14 [RFC2119] [RFC8174].

     Conduit ProofBundle (H_c):  A SHA-256 hash-chained, Ed25519-signed
        audit trail produced by a cryptographic verifier of agent task
        delivery.  The tip hash of this chain is referenced as H_c
        throughout this document.




  stone                    Expires 27 October 2026                [Page 6]


  Internet-Draft                    ADRP                        April 2026


     RulingBundle (R):  A signed attestation by an authorized arbitrator
        that supersedes an underlying Conduit ProofBundle via signing-time
        precedence.

     DisputeBundle:  The append-only chain of dispute events (filing,
        evidence, arbitrator assignment) anchored to a Conduit ProofBundle
        and consumed by verify_resolution.

     DisputeFlag:  An advisory, agent-emitted notification that an anomaly
        has been detected.  Non-binding.  Expires if not ratified by the
        principal within the tier-specific window.

     DisputeFiling:  A binding, principal-emitted dispute filing.  Posts a
        filing fee.  Anchors a DisputeBundle.

     EscrowDirective:  The output of verify_resolution.  Consumed by the
        AP2 Payment Mandate executor (or VCAP escrow rail) to release,
        refund, or split funds.

     Arbitration Mandate:  The fourth element of the AP2 mandate chain,
        pre-signed by the principal at agent-deployment time.  Defines the
        arbitration pool, governing-law clause, fee schedule, and L1/L2/L3
        thresholds.  Hash anchored in Standing Token.

     Cart Mandate Acceptance Criteria:  A machine-readable structure
        embedded in the Cart Mandate that defines the deterministic checks
        Conduit attests against at delivery time.

     Cryptographic-class dispute:  A dispute whose resolution is
        computable deterministically from (DisputeBundle, RulingBundle,
        Standing Token chain).

     Semantic-class dispute:  A dispute whose resolution requires
        arbitration against the Cart Mandate's acceptance criteria.

     Curated Arbitrator Pool:  A SwarmSync-published list of vetted human-
        or-model arbitrators registered as DIDs in TRUSTED_REGISTRIES.
        v0.1 mechanism.

     Filing Fee:  A non-refundable, non-transferable, USD-denominated fee
        posted at DisputeFiling.  Refundable only to the prevailing party.

     Counter-attestation Override Pattern:  The verification-time
        precedence rule by which a RulingBundle supersedes a Conduit
        ProofBundle.  Both are preserved forever in the hash chain.






  stone                    Expires 27 October 2026                [Page 7]


  Internet-Draft                    ADRP                        April 2026


     Terms imported from ATXN (draft-stone-atxn-00): Bundle (the five-
     element ATXN primitive, ATXN Section 3), Standing Token (ATXN
     Section 4), Tier (L1/L2/L3, ATXN Section 5), Principal, Agent,
     Operator, Mandate Framework, Commitment Event, Revocation Beacon (all
     ATXN Section 2).

  3.  Architecture Overview

     ADRP sits on top of the following existing layers:

     +--------------------------------------+
     | ADRP (this spec)                     |
     | - Arbitration Mandate                |
     | - DisputeFlag / DisputeFiling        |
     | - RulingBundle (counter-attestation) |
     | - EscrowDirective                    |
     +--------------------------------------+
     | ATXN (draft-stone-atxn-00)           |
     | - Bundle (5 elements)                |
     | - Standing Token                     |
     | - Tier / Profile                     |
     +--------------------------------------+
     | AP2 / ACP / TAP / x402               |
     | - Intent / Cart / Payment Mandates   |
     +--------------------------------------+
     | Conduit / AIVS                       |
     | - SHA-256 hash-chained ProofBundles  |
     | - Ed25519 signatures                 |
     +--------------------------------------+

     A dispute is the transition of an ATXN Bundle from delivered to
     disputed (per ATXN Section 8).  ADRP defines what happens after that
     transition.

  4.  The Arbitration Mandate

  4.1.  Purpose

     The Arbitration Mandate is the FAA Section 2 / NY Convention written,
     consensual arbitration agreement that makes ADRP enforceable without
     statutory change.










  stone                    Expires 27 October 2026                [Page 8]


  Internet-Draft                    ADRP                        April 2026


  4.2.  Required Fields

       +=========================+=========+==========================+
       | Field                   | Type    | Description              |
       +=========================+=========+==========================+
       | arb_mandate_id          | UUID    | Unique identifier        |
       +-------------------------+---------+--------------------------+
       | principal_did           | DID     | Principal's DID          |
       +-------------------------+---------+--------------------------+
       | arbitrator_pool_ref     | URI     | Reference to the curated |
       |                         |         | arbitrator pool (v0.1)   |
       +-------------------------+---------+--------------------------+
       | governing_law           | String  | E.g., "FAA + Delaware    |
       |                         |         | seat"                    |
       +-------------------------+---------+--------------------------+
       | fee_schedule_ref        | URI     | Reference to filing fee  |
       |                         |         | schedule                 |
       +-------------------------+---------+--------------------------+
       | tier_thresholds         | Object  | L1/L2/L3 transaction-    |
       |                         |         | value boundaries         |
       +-------------------------+---------+--------------------------+
       | appeal_panel_size       | Integer | Default 5                |
       +-------------------------+---------+--------------------------+
       | language_of_proceedings | ISO     | Default "en"             |
       |                         | 639-1   |                          |
       +-------------------------+---------+--------------------------+
       | principal_signature     | Ed25519 | Principal's signature    |
       |                         | base64  | over canonical JSON      |
       +-------------------------+---------+--------------------------+

                                   Table 1

  4.3.  Anchoring

     The Arbitration Mandate's SHA-256 hash MUST be referenced in the
     principal's Standing Token (per ATXN Section 4) under a new field
     arb_mandate_hash.  A Standing Token without an anchored Arbitration
     Mandate hash MUST NOT participate in an L2 or L3 ATXN Bundle.

  4.4.  Mutability

     The Arbitration Mandate MAY be replaced by the principal at any time,
     but the replacement MUST NOT apply retroactively to in-flight
     Bundles.







  stone                    Expires 27 October 2026                [Page 9]


  Internet-Draft                    ADRP                        April 2026


  5.  Standing and the Flag/File Distinction

  5.1.  Parties

     The parties to any ADRP dispute are always principal-A and principal-
     B.  Never agents.  This preserves the A2A executor-not-party model
     from UETA Section 14 and Restatement (Third) of Agency.

  5.2.  Agent Flag Rights

     Agents MAY emit DisputeFlags — advisory, low-cost (1 KB JSON max),
     signed by the agent's Standing Token.  A DisputeFlag is non-binding
     and does not initiate the dispute state machine.

  5.3.  Principal File Rights

     Only principals MAY emit DisputeFilings — binding, fee-posting,
     claim-coded events that initiate the dispute state machine.

  5.4.  Flag Expiration

                        +======+=====================+
                        | Tier | Ratification Window |
                        +======+=====================+
                        | L1   | N/A (no dispute)    |
                        +------+---------------------+
                        | L2   | 72h                 |
                        +------+---------------------+
                        | L3   | 14d                 |
                        +------+---------------------+

                                   Table 2

     After expiration, the flag is preserved in the audit log but cannot
     anchor a DisputeFiling.

  5.5.  Pre-Authorized Dispute Delegate

     A principal MAY pre-authorize a dispute delegate via a delegation
     field in the Arbitration Mandate.  The delegate's filings are treated
     as principal-filed for standing purposes.

  6.  Dispute Taxonomy

  6.1.  Cryptographic-Class Disputes

     Resolved by code from (DisputeBundle, RulingBundle, Standing Token
     chain) without arbitration.



  stone                    Expires 27 October 2026               [Page 10]


  Internet-Draft                    ADRP                        April 2026


          +======================+==================================+
          | Code                 | Description                      |
          +======================+==================================+
          | bundle_integrity     | SHA-256 chain breaks; signature  |
          |                      | verification fails               |
          +----------------------+----------------------------------+
          | mandate_scope        | Agent acted outside Cart Mandate |
          |                      | scope (deterministic predicate)  |
          +----------------------+----------------------------------+
          | token_authority      | Standing Token revoked or        |
          |                      | expired pre-execution            |
          +----------------------+----------------------------------+
          | timestamp_skew       | Attestation timestamps violate   |
          |                      | ordering invariants              |
          +----------------------+----------------------------------+
          | oracle_contradiction | Third-party oracle data          |
          |                      | contradicts attestation          |
          +----------------------+----------------------------------+

                                    Table 3

     A cryptographic-class dispute MUST NOT be routed to arbitration.

  6.2.  Semantic-Class Disputes

     Resolved by arbitration against the Cart Mandate's acceptance
     criteria.

          +=====================+===================================+
          | Code                | Description                       |
          +=====================+===================================+
          | quality_mismatch    | Deliverable doesn't satisfy       |
          |                     | acceptance_criteria.checks        |
          +---------------------+-----------------------------------+
          | spec_ambiguity      | Acceptance criteria absent,       |
          |                     | under-specified, or contradictory |
          +---------------------+-----------------------------------+
          | timing_breach       | SLA missed                        |
          +---------------------+-----------------------------------+
          | fitness_for_purpose | Deliverable formally compliant    |
          |                     | but unfit for principal's purpose |
          +---------------------+-----------------------------------+

                                    Table 4







  stone                    Expires 27 October 2026               [Page 11]


  Internet-Draft                    ADRP                        April 2026


  6.3.  Classification

     The DisputeFiling's claim_code field declares the class.  ADRP
     verifiers MUST validate that the declared class matches the evidence.

  6.4.  ATXN dispute_class to ADRP Claim Code Mapping

     ATXN (Section 10.3) defines a dispute_class field set at Bundle
     handoff.  The normative mapping is:

         +===================+======================+===============+
         | ATXN              | ADRP Claim Code(s)   | ADRP Class    |
         | dispute_class     |                      |               |
         +===================+======================+===============+
         | fact_dispute      | bundle_integrity,    | Cryptographic |
         |                   | timestamp_skew,      |               |
         |                   | oracle_contradiction |               |
         +-------------------+----------------------+---------------+
         | terms_dispute     | mandate_scope,       | Semantic      |
         |                   | quality_mismatch,    |               |
         |                   | spec_ambiguity,      |               |
         |                   | timing_breach,       |               |
         |                   | fitness_for_purpose  |               |
         +-------------------+----------------------+---------------+
         | capacity_dispute  | out of scope — see   | —             |
         |                   | Section 6.5          |               |
         +-------------------+----------------------+---------------+
         | framework_dispute | out of scope — see   | —             |
         |                   | Section 6.5          |               |
         +-------------------+----------------------+---------------+

                                   Table 5

     When a DisputeFiling arrives with an ATXN dispute_class, the ADRP
     verifier MUST map it to the corresponding claim_code bucket using
     this table before routing.

  6.5.  Out of Scope (v0.1)

      +===================+=================+===========================+
      | Class             | Reason          | Disposition               |
      +===================+=================+===========================+
      | capacity_dispute  | Principal-level | Bypass ADRP entirely;     |
      |                   | adjudication;   | executing platform MUST   |
      |                   | agent action    | freeze settlement and     |
      |                   | set aside       | refund-to-buyer; route to |
      |                   | entirely        | regulatory or Principal-  |
      |                   |                 | level forum outside ADRP  |



  stone                    Expires 27 October 2026               [Page 12]


  Internet-Draft                    ADRP                        April 2026


      +-------------------+-----------------+---------------------------+
      | framework_dispute | Mandate         | Bypass ADRP entirely;     |
      |                   | framework       | executing platform MUST   |
      |                   | validity        | freeze settlement; ADRP   |
      |                   | contested       | MUST NOT process until    |
      |                   |                 | upstream framework forum  |
      |                   |                 | resolves validity         |
      +-------------------+-----------------+---------------------------+
      | Cross-border      | Reg E / PSD2 /  | Defer to v0.2             |
      | consumer disputes | GDPR overlap    |                           |
      |                   | not yet         |                           |
      |                   | resolved        |                           |
      +-------------------+-----------------+---------------------------+

                                    Table 6

  7.  The Counter-Attestation Override Pattern

  7.1.  Invariant

     The Conduit ProofBundle's tip hash H_c is never modified.  No byte of
     the original ProofBundle is rewritten.  Override is a verification-
     time precedence rule, not a mutation.

  7.2.  RulingBundle Structure

     R = {
       type: "RulingBundle",
       supersedes: H_c,
       dispute_chain_tip: H_d,
       verdict: "release" | "refund" | "partial",
       partial_split: { to_buyer: 0.30, to_seller: 0.70 },
       rationale_hash: H_rationale,
       arbitrator_did: "did:web:...",
       arbitrator_vc_hash: H_vc,
       signing_time: "<RFC3339>",
       prev_hash: H_d
     }
     sig = Ed25519(arbitrator_priv, JCS(R))

  7.3.  Verification Rule

     The latest valid RulingBundle (by signing_time) whose supersedes
     equals the underlying ProofBundle's tip hash AND whose signing
     arbitrator was authorized at signing_time, with chain integrity
     verified, is the verification winner.





  stone                    Expires 27 October 2026               [Page 13]


  Internet-Draft                    ADRP                        April 2026


  7.4.  Why This Works

     Hash-chain immutability is preserved.  Verification is offline and
     deterministic.  Arbitrator authority is anchored to signing_time.
     The chain becomes a precedent corpus indexed by Cart Mandate template
     hash.

  8.  Wire Protocol

  8.1.  Message Types

       +========+======================+============+==================+
       | Number | Type                 | Emitter    | Purpose          |
       +========+======================+============+==================+
       | 1      | DisputeFlag          | Agent      | Advisory anomaly |
       |        |                      |            | notification     |
       |        |                      |            | (non-binding)    |
       +--------+----------------------+------------+------------------+
       | 2      | DisputeFiling        | Principal  | Binding dispute  |
       |        |                      |            | initiation;      |
       |        |                      |            | posts filing fee |
       +--------+----------------------+------------+------------------+
       | 3      | EvidenceSubmission   | Either     | Hash-chained     |
       |        |                      | party      | artifact append  |
       +--------+----------------------+------------+------------------+
       | 4      | ArbitratorAssignment | Registry   | Binds arbitrator |
       |        |                      |            | DID to dispute   |
       +--------+----------------------+------------+------------------+
       | 5      | RulingBundle         | Arbitrator | Signed verdict + |
       |        |                      |            | escrow directive |
       +--------+----------------------+------------+------------------+
       | 6      | EscrowDirective      | Verifier   | Consumed by AP2  |
       |        |                      | (derived)  | Payment Mandate  |
       |        |                      |            | or VCAP rail     |
       +--------+----------------------+------------+------------------+

                                    Table 7

  8.2.  Common Message Envelope












  stone                    Expires 27 October 2026               [Page 14]


  Internet-Draft                    ADRP                        April 2026


     {
       "msg_type": "<one of the six>",
       "msg_id": "<UUID>",
       "prev_hash": "<SHA-256 of prior chain event>",
       "submitter_did": "<DID>",
       "submitter_signature": "<Ed25519 base64 over JCS of preceding fields>",
       "timestamp": "<RFC3339>",
       "payload": { ... type-specific ... }
     }

  8.3.  Canonicalization

     All signatures MUST be over the JCS ([RFC8785]) canonicalization of
     the signed object minus the signature field itself.

  9.  State Machine

  9.1.  States

   Pre-FILED:   FLAGGED         (agent-emitted; expires if not ratified)
                FILED           (principal-emitted; fee posted)
                  |
                  v
                ASSIGNED        (arbitrator bound to dispute)
                  |
                  v
                EVIDENCE_OPEN   (parties submit evidence)
                  |
                  v
                UNDER_REVIEW    (arbitrator deliberating)
                  |
                  v
                RULED           (RulingBundle signed)
                  |
                  v
                SETTLED         (EscrowDirective consumed by payment rail)

   Terminal:    WITHDRAWN       (filer withdraws; fee partial-refunded)
                EXPIRED         (filing or evidence window expired)

  9.2.  ATXN State Machine Join Points

     The ADRP internal state machine is entered from ATXN's disputed
     state.  The normative join points are:

     *  ATXN disputed → ADRP FLAGGED: agent-emitted DisputeFlag (advisory;
        principal must ratify within tier window to proceed)




  stone                    Expires 27 October 2026               [Page 15]


  Internet-Draft                    ADRP                        April 2026


     *  ATXN disputed → ADRP FILED: principal-emitted DisputeFiling (skips
        FLAGGED)

     *  ADRP RULED + ADRP SETTLED → ATXN adjudicated then finalized:
        EscrowDirective consumed by payment rail

     *  ADRP WITHDRAWN or EXPIRED → ATXN finalized: dispute resolved
        without ruling; escrow released per Profile default

  9.3.  Invariants

          +====+====================================================+
          | ID | Invariant                                          |
          +====+====================================================+
          | I1 | PaymentMandate.escrow_state == HOLD until SETTLED, |
          |    | WITHDRAWN, or EXPIRED                              |
          +----+----------------------------------------------------+
          | I2 | No state mutates a prior attestation; transitions  |
          |    | are new signed events                              |
          +----+----------------------------------------------------+
          | I3 | prev_hash of every event = SHA-256 of canonical-   |
          |    | JSON of the immediately prior event                |
          +----+----------------------------------------------------+
          | I4 | dispute_chain[0].prev_hash == ProofBundle.tip_hash |
          +----+----------------------------------------------------+
          | I5 | Only an arbitrator authorized by the Arbitration   |
          |    | Mandate's pool may emit RulingBundle               |
          +----+----------------------------------------------------+
          | I6 | EscrowDirective MUST be derivable from             |
          |    | (DisputeBundle, RulingBundle) by verify_resolution |
          +----+----------------------------------------------------+

                                    Table 8

  10.  Tier Parameters

      +================+===========+=================+=================+
      | Parameter      | L1        | L2              | L3              |
      +================+===========+=================+=================+
      | Dispute window | 0         | 72h             | 14d             |
      |                | (atomic)  |                 |                 |
      +----------------+-----------+-----------------+-----------------+
      | Filing fee     | N/A       | 10% of value,   | 10% of value,   |
      |                |           | $1-$100         | $50-$1,000      |
      +----------------+-----------+-----------------+-----------------+
      | Arbitrator SLA | N/A       | 4h              | 24h             |
      +----------------+-----------+-----------------+-----------------+
      | Arbitrator     | N/A       | Curated AI      | Curated human   |



  stone                    Expires 27 October 2026               [Page 16]


  Internet-Draft                    ADRP                        April 2026


      | pool           |           | panel (3 of 5)  | pool (3 of 5) + |
      |                |           |                 | optional legal  |
      |                |           |                 | review          |
      +----------------+-----------+-----------------+-----------------+
      | Override       | N/A       | 4-of-5          | 4-of-5          |
      | threshold      |           | supermajority   | supermajority   |
      +----------------+-----------+-----------------+-----------------+
      | Max txn auto-  | unlimited | $1,000          | unlimited       |
      | arb            |           |                 |                 |
      +----------------+-----------+-----------------+-----------------+
      | Default if SLA | N/A       | refund-to-buyer | refund-to-buyer |
      | missed         |           |                 |                 |
      +----------------+-----------+-----------------+-----------------+
      | Frivolous      | N/A       | 100% fee        | 100% fee        |
      | slash          |           | forfeited       | forfeited       |
      +----------------+-----------+-----------------+-----------------+
      | Novel-but-lost | N/A       | 50% fee         | 50% fee         |
      | slash          |           | forfeited       | forfeited       |
      +----------------+-----------+-----------------+-----------------+
      | Appeal window  | N/A       | 12h             | 48h             |
      +----------------+-----------+-----------------+-----------------+
      | Appeal panel   | N/A       | 5 (up from 3)   | 5 + legal       |
      |                |           |                 | review          |
      +----------------+-----------+-----------------+-----------------+
      | Appeal quorum  | N/A       | 4 of 5          | 4 of 5          |
      +----------------+-----------+-----------------+-----------------+
      | Escrow hold    | 0         | 7 days          | 21 days         |
      +----------------+-----------+-----------------+-----------------+
      | Evidence file  | N/A       | 10 MB total,    | 10 MB total,    |
      | size cap       |           | max 20 files    | max 20 files    |
      +----------------+-----------+-----------------+-----------------+

                                   Table 9

  10.1.  Tier Routing

     Tier is determined by the ATXN Bundle's Tier (per ATXN Section 5) AND
     by the transaction value relative to the max_txn_auto_arb ceiling.  A
     Bundle declared L2 with transaction value greater than $1,000 MUST
     auto-escalate to L3 dispute processing.  This is a dispute-processing
     escalation rule only and does not retroactively change the Bundle's
     declared formation Tier (see ATXN Section 5.2).

  10.2.  Default Ruling on SLA Miss

     If the arbitrator pool fails to produce a RulingBundle within the
     SLA, the dispute MUST default to refund-to-buyer.




  stone                    Expires 27 October 2026               [Page 17]


  Internet-Draft                    ADRP                        April 2026


  11.  Cart Mandate Acceptance Criteria

  11.1.  Required Field

     The Cart Mandate MUST contain:

     {
       "acceptance_criteria": {
         "schema_version": "1",
         "checks": [
           { "type": "regex", "selector": "$.output", "pattern": "..." },
           { "type": "json_schema", "selector": "$.deliverable", "schema": { ... } },
           { "type": "deterministic_function", "function_hash": "sha256:..." },
           { "type": "human_review_required", "reason": "..." }
         ],
         "default_window_hours": 72,
         "silence_equals": "release"
       }
     }

  11.2.  Check Types

           +========================+==============================+
           | Type                   | Evaluation                   |
           +========================+==============================+
           | regex                  | Deterministic regex match    |
           |                        | against JSON-path selector   |
           +------------------------+------------------------------+
           | json_schema            | JSON Schema validation       |
           |                        | against selector             |
           +------------------------+------------------------------+
           | deterministic_function | Pure function (referenced by |
           |                        | hash, fetched from registry) |
           |                        | executed against deliverable |
           +------------------------+------------------------------+
           | human_review_required  | Auto-routes to arbitration;  |
           |                        | flags spec as deliberately   |
           |                        | not auto-evaluable           |
           +------------------------+------------------------------+

                                    Table 10

  11.3.  Conduit Attestation Against Checks

     Conduit attests against acceptance_criteria.checks at delivery time.
     If all checks pass deterministically, the dispute path auto-resolves
     cryptographically.  If checks include human_review_required OR are
     missing, dispute auto-routes to L2 semantic arbitration.



  stone                    Expires 27 October 2026               [Page 18]


  Internet-Draft                    ADRP                        April 2026


  11.4.  The Authoring Helper (Normative for Deployment)

     A natural-language-to-checks helper that converts a principal's
     English-language description into machine-checkable predicates is
     REQUIRED for v0.1 deployment.

  12.  Arbitrator Pool

  12.1.  v0.1: Curated Pool

     v0.1 ships with a SwarmSync-curated arbitrator pool — a centralized
     list of vetted human-or-model arbitrators registered as DIDs in
     TRUSTED_REGISTRIES.

  12.2.  Selection Algorithm

     Arbitrator selection MUST use a verifiable random function (VRF)
     seeded by the DisputeFiling's hash.

  12.3.  Pool Composition

          +======+==================================================+
          | Tier | Pool Composition                                 |
          +======+==================================================+
          | L2   | AI arbitrator panels (model + curated checker)   |
          +------+--------------------------------------------------+
          | L3   | Human arbitrators (vetted, jurisdictionally-     |
          |      | licensed where relevant) + optional legal review |
          +------+--------------------------------------------------+

                                    Table 11

  12.4.  Arbitrator Credentialing

     Every arbitrator MUST hold a Verifiable Credential that names the
     arbitrator's DID, states valid_from and valid_until timestamps, names
     qualifications, and is signed by a registry in TRUSTED_REGISTRIES.

  12.5.  v0.2 Roadmap

     Decentralized stake-weighted arbitrator pools are deferred to v0.2.

  13.  Filing Fee Economics








  stone                    Expires 27 October 2026               [Page 19]


  Internet-Draft                    ADRP                        April 2026


  13.1.  Fee Structure

               +==============+===============================+
               | Parameter    | Value                         |
               +==============+===============================+
               | Fee rate     | 10% of transaction value      |
               +--------------+-------------------------------+
               | Floor        | $1 (L2) / $50 (L3)            |
               +--------------+-------------------------------+
               | Ceiling      | $100 (L2) / $1,000 (L3)       |
               +--------------+-------------------------------+
               | Denomination | USD (fiat or USDC stablecoin) |
               +--------------+-------------------------------+
               | Refund       | To prevailing party only      |
               +--------------+-------------------------------+

                                   Table 12

  13.2.  Why Not a Tokenized Stake

     The fee is non-refundable to the filer, non-transferable, and
     denominated in USD.  It yields no return.  It is not a security under
     Howey.

  13.3.  Slashing

           +======================================+================+
           | Outcome                              | Filer's Fee    |
           +======================================+================+
           | Filer prevails                       | 100% refunded  |
           +--------------------------------------+----------------+
           | Filer loses; novel evidence          | 50% forfeited  |
           +--------------------------------------+----------------+
           | Filer loses; frivolous               | 100% forfeited |
           +--------------------------------------+----------------+
           | Filer withdraws before EVIDENCE_OPEN | 75% refunded   |
           +--------------------------------------+----------------+
           | Filer withdraws after EVIDENCE_OPEN  | 25% refunded   |
           +--------------------------------------+----------------+

                                    Table 13

     Forfeited fees MAY fund the arbitrator pool and a public dispute-
     quality dataset.







  stone                    Expires 27 October 2026               [Page 20]


  Internet-Draft                    ADRP                        April 2026


  13.4.  Arbitrator Compensation

     Arbitrators are compensated 2% of transaction value (min $0.50) from
     the losing party's escrow.

  14.  Appeals

  14.1.  Trigger

     Either party MAY file an appeal within the tier-specific appeal
     window (12h L2, 48h L3).  Appeals require a fresh filing fee at 1.5x
     the original rate.

  14.2.  Appeal Panel

     A 5-arbitrator panel selected via VRF from a different pool slice
     than the original ruling.  Quorum: 4 of 5.

  14.3.  Finality

     Appeal rulings are FINAL.  There is no second appeal.

  14.4.  Appeal Override

     An appeal RulingBundle supersedes the original RulingBundle by the
     same signing-time precedence rule (Section 7.3).  Both are preserved
     forever.

  15.  Precedent Corpus

  15.1.  Indexing

     Every signed RulingBundle is content-addressed and indexed by: Cart
     Mandate template hash; dispute claim_code; verdict; arbitrator DID;
     signing time.

  15.2.  Citation Requirement

     Future arbitrators MUST query the precedent corpus for prior rulings
     on similar Cart Mandate templates and either cite or distinguish
     them.

  15.3.  v0.1 vs v0.2

     v0.1 ships the data layer. v0.2 ships the search and citation
     infrastructure.





  stone                    Expires 27 October 2026               [Page 21]


  Internet-Draft                    ADRP                        April 2026


  16.  Verification Algorithm

  16.1.  The verify_resolution Function

     def verify_resolution(db: DisputeBundle, rb: RulingBundle) -> Result:
         # 1. Anchor checks
         assert db.conduit_proof_ref == rb.supersedes
         assert rb.prev_hash == db.chain_tip

         # 2. Chain integrity
         h = db.conduit_proof_ref
         for ev in [db.filing, *db.evidence_chain, db.arbitrator_assignment]:
             assert ev.prev_hash == h
             assert verify_sig(ev.submitter_did, ev.sig, jcs(ev))
             h = sha256(jcs(ev))
         assert h == db.chain_tip

         # 3. Arbitrator authority at signing_time (not now)
         vc = fetch_vc(rb.arbitrator_vc_hash)
         assert vc.subject == rb.arbitrator_did
         assert vc.issuer in TRUSTED_REGISTRIES
         assert vc.valid_from <= rb.signing_time <= vc.valid_until
         assert verify_sig(vc.issuer, vc.sig, jcs(vc))

         # 4. Ruling signature
         assert verify_sig(rb.arbitrator_did, rb.sig, jcs(rb_minus_sig))

         # 5. Verdict well-formed
         assert rb.verdict in {"release", "refund", "partial"}
         if rb.verdict == "partial":
             assert sum(rb.partial_split.values()) == 1.0

         # 6. Derive directive
         return Result(valid=True, escrow_directive=EscrowDirective(
             payment_mandate_ref=db.payment_mandate_ref,
             action=rb.verdict,
             split=rb.partial_split,
             ruling_ref=sha256(jcs(rb))
         ))

  16.2.  Determinism Requirement

     Two honest verifiers given the same inputs MUST reach the same
     EscrowDirective.







  stone                    Expires 27 October 2026               [Page 22]


  Internet-Draft                    ADRP                        April 2026


  16.3.  Offline Requirement

     verify_resolution MUST NOT require network access except to fetch the
     arbitrator's Verifiable Credential by hash.

  17.  SDK Surface

     A conformant ADRP v0.1 SDK MUST expose at minimum six methods,
     implementable in 500 LOC total:

     emit_flag(agent_standing_token, claim_code, evidence_ref) -> DisputeFlag
     file_dispute(payment_mandate, claim_code, claim_detail, flag_ref) -> DisputeBundle
     submit_evidence(dispute_id, artifact_bytes, mime_type) -> EvidenceLink
     query_status(dispute_id) -> {state, chain_tip, latest_event}
     render_ruling(dispute_id, verdict, partial_split, rationale) -> RulingBundle  # arbitrator-only
     verify_resolution(dispute_bundle, ruling_bundle) -> {valid, escrow_directive}

  17.1.  Appeal as Re-Entry

     An appeal is file_dispute with the prior_ruling_ref field set.

  17.2.  LOC Budget

     emit_flag:  ~30 LOC

     file_dispute:  ~80 LOC

     submit_evidence:  ~50 LOC

     query_status:  ~30 LOC

     render_ruling:  ~80 LOC

     verify_resolution:  ~120 LOC

     Common envelope, signing, hash chain:  ~110 LOC

     Total:  ~500 LOC

  17.3.  Golden Test Cases

      +========+============================+===========================+
      | Number | Case                       | Expected Behavior         |
      +========+============================+===========================+
      | 1      | clear_release              | No flag, no filing,       |
      |        |                            | window expires → release  |
      +--------+----------------------------+---------------------------+
      | 2      | clear_refund               | DisputeFiling with valid  |



  stone                    Expires 27 October 2026               [Page 23]


  Internet-Draft                    ADRP                        April 2026


      |        |                            | bundle_integrity claim →  |
      |        |                            | refund                    |
      +--------+----------------------------+---------------------------+
      | 3      | partial_split              | Semantic dispute,         |
      |        |                            | partial_split: {to_buyer: |
      |        |                            | 0.30, to_seller: 0.70}    |
      +--------+----------------------------+---------------------------+
      | 4      | attestation_override       | Original ProofBundle      |
      |        |                            | preserved; latest valid   |
      |        |                            | RulingBundle wins         |
      +--------+----------------------------+---------------------------+
      | 5      | frivolous_dispute          | Filer loses without novel |
      |        |                            | evidence → 100% fee       |
      |        |                            | forfeited                 |
      +--------+----------------------------+---------------------------+
      | 6      | malicious_requester_reject | Principal-A files invalid |
      |        |                            | claim → fee forfeited,    |
      |        |                            | escrow releases to seller |
      +--------+----------------------------+---------------------------+
      | 7      | expired_dispute            | DisputeFiling outside     |
      |        |                            | tier window → EXPIRED     |
      +--------+----------------------------+---------------------------+
      | 8      | flag_ratification          | DisputeFlag emitted,      |
      |        |                            | principal files within    |
      |        |                            | window → promoted         |
      +--------+----------------------------+---------------------------+
      | 9      | flag_expiration            | DisputeFlag emitted, no   |
      |        |                            | action within window →    |
      |        |                            | preserved but cannot      |
      |        |                            | anchor filing             |
      +--------+----------------------------+---------------------------+
      | 10     | appeal_supersedes          | Appeal RulingBundle       |
      |        |                            | supersedes original by    |
      |        |                            | signing-time precedence   |
      +--------+----------------------------+---------------------------+

                                    Table 14

  18.  Scope Locks for v0.1

     +=================+=================================================+
     | Lock            | Reason                                          |
     +=================+=================================================+
     | US-only B2B     | No consumer / cross-border / Reg E / PSD2 /     |
     |                 | GDPR overlap                                    |
     +-----------------+-------------------------------------------------+
     | Partnered       | No SwarmSync-held escrow; relies on Stripe      |
     | custody         | Connect, Bridge, Modern Treasury, or equivalent |



  stone                    Expires 27 October 2026               [Page 24]


  Internet-Draft                    ADRP                        April 2026


     +-----------------+-------------------------------------------------+
     | Curated         | No token-staked decentralized pool (Howey)      |
     | arbitrator      |                                                 |
     | pool            |                                                 |
     +-----------------+-------------------------------------------------+
     | Filing fee,     | Non-refundable, non-transferable, USD-          |
     | not stake       | denominated                                     |
     +-----------------+-------------------------------------------------+
     | Reputation      | Avoids bootstrap-circular trust dependency in   |
     | logged but not  | v0.1                                            |
     | modulating      |                                                 |
     +-----------------+-------------------------------------------------+
     | Per-principal   | Data collection pipeline ships in v0.1;         |
     | preference      | productized search ships in v0.2                |
     | model deferred  |                                                 |
     +-----------------+-------------------------------------------------+

                                    Table 15

  19.  Security Considerations

  19.1.  The >90% Auto-Resolution Target Is NOT a Protocol Property

     The greater than 90% auto-resolution target is a deployment-
     conditional target, not a protocol property.  Empirical base rates
     (Kleros, eBay, Upwork, Mechanical Turk) cap auto-resolution at
     60-95%. Implementations MUST: ship a normative NLP-to-checks
     authoring helper; run a 90-day shadow-mode pilot before GA; measure
     check-coverage and auto-resolution rate as primary metrics; pivot to
     mandatory human_review_required flag if check coverage is less than
     30% at day 30.

  19.2.  The Bifurcation Seam

     Adversaries will probe the seam between cryptographic-class and
     semantic-class disputes.  The classification validation in
     Section 6.3 is REQUIRED.

  19.3.  Arbitrator Collusion

     A 4-of-5 threshold is compromisable via collusion of 4 arbitrators.
     Mitigations: diversify the curated pool across non-correlated risk
     profiles; monitor for arbitrator-pair correlation in rulings;
     periodically audit a random sample of rulings.







  stone                    Expires 27 October 2026               [Page 25]


  Internet-Draft                    ADRP                        April 2026


  19.4.  Filing Fee as DoS Vector

     Mitigations: per-principal rate limit (max 0.5% of rolling 30-day
     transaction count); frivolous slash; account suspension after N
     frivolous filings.

  19.5.  Standing Token Replay

     A revoked Standing Token MUST NOT anchor a new DisputeFiling.

  19.6.  Time-Skew Attacks

     Mitigations: threshold-signature timestamps for L2 and L3 rulings
     (3-of-5 from a federated timestamping authority); reject rulings with
     signing_time more than 5 minutes in the future.

  19.7.  Jurisdictional Enforceability of the Arbitration Mandate

     Implementations SHOULD seek a written legal opinion in the deployment
     jurisdiction before relying on the Arbitration Mandate to defeat a
     court filing.

  19.8.  Sanctions Screening

     Every party receiving funds via an EscrowDirective MUST be screened
     against OFAC and equivalent sanctions lists.

  19.9.  Principal Capacity Mid-Dispute

     If a principal's capacity attestation expires or is revoked mid-
     dispute, the dispute MUST be halted and routed to a capacity_dispute,
     defaulting to refund-to-buyer.

  19.10.  Acknowledged Residual Risks

     *  Hallucinated mandates: partially mitigated by L3 epistemic
        attestation; unsolved for L1/L2.

     *  Adversarial sub-agency chains: bounded by sub_delegation_depth per
        ATXN.

     *  Arbitrator pool capture: mitigated by VRF selection; v0.2
        decentralization is the long-term mitigation.

  20.  IANA Considerations






  stone                    Expires 27 October 2026               [Page 26]


  Internet-Draft                    ADRP                        April 2026


  20.1.  ADRP JSON-LD Context

     URI: https://swarmsync.ai/spec/adrp/v1

  20.2.  ADRP Claim Code Registry

     A new IANA registry "ADRP Claim Codes" is requested.  Registration
     policy: Specification Required (per [RFC8126]).

     Initial entries:

     +======================+=============+==============================+
     | Code                 |Class        | Description                  |
     +======================+=============+==============================+
     | bundle_integrity     |cryptographic| SHA-256 chain breaks;        |
     |                      |             | signature verification       |
     |                      |             | fails                        |
     +----------------------+-------------+------------------------------+
     | mandate_scope        |cryptographic| Agent acted outside Cart     |
     |                      |             | Mandate scope                |
     +----------------------+-------------+------------------------------+
     | token_authority      |cryptographic| Standing Token revoked or    |
     |                      |             | expired pre-execution        |
     +----------------------+-------------+------------------------------+
     | timestamp_skew       |cryptographic| Attestation timestamps       |
     |                      |             | violate ordering             |
     |                      |             | invariants                   |
     +----------------------+-------------+------------------------------+
     | oracle_contradiction |cryptographic| Third-party oracle data      |
     |                      |             | contradicts attestation      |
     +----------------------+-------------+------------------------------+
     | quality_mismatch     |semantic     | Deliverable doesn't          |
     |                      |             | satisfy                      |
     |                      |             | acceptance_criteria.checks   |
     +----------------------+-------------+------------------------------+
     | spec_ambiguity       |semantic     | Acceptance criteria absent   |
     |                      |             | or under-specified           |
     +----------------------+-------------+------------------------------+
     | timing_breach        |semantic     | SLA missed                   |
     +----------------------+-------------+------------------------------+
     | fitness_for_purpose  |semantic     | Deliverable formally         |
     |                      |             | compliant but unfit          |
     +----------------------+-------------+------------------------------+

                                    Table 16






  stone                    Expires 27 October 2026               [Page 27]


  Internet-Draft                    ADRP                        April 2026


  20.3.  ADRP Verdict Enum

     A new IANA registry "ADRP Verdicts" is requested.

         +=========+=================================================+
         | Value   | Description                                     |
         +=========+=================================================+
         | release | Funds released to seller (counterparty)         |
         +---------+-------------------------------------------------+
         | refund  | Funds returned to buyer (filer)                 |
         +---------+-------------------------------------------------+
         | partial | Funds split per partial_split (must sum to 1.0) |
         +---------+-------------------------------------------------+

                                    Table 17

  20.4.  ADRP Trusted Registries List

     A new IANA registry "ADRP Trusted Arbitrator Registries" is
     requested.

  21.  Acknowledgements

     This specification synthesizes the output of the Ultimate Brainstorm
     v2.2 Agent Dispute Resolution Protocol session (2026-04-25).  The
     author thanks: EpistemicAuditor (cryptographic/semantic bifurcation);
     Archaeologist (empirical base-rate floor); Quantifier (tier
     parameters); ConstraintCartographer (Arbitration Mandate as FAA
     anchor; v0.1 scope locks); socratic-mentor (principal-only standing);
     DarkMirror (flag/file distinction); IdeaMatrix (tiered hybrid
     architecture); RemixForge (Cart Mandate acceptance_criteria); SoSpec
     (wire protocol, state machine, SDK surface, verify_resolution
     algorithm); SpiderSpark (three-tier bonded-escalation structure).

     Three formal dissents: Archaeologist assigns less than 40%
     probability to the greater than 90% auto-resolution target.
     EpistemicAuditor assigns 25% probability to median Cart Mandates
     having sufficient acceptance_criteria coverage.  RemixForge considers
     deferring per-principal preference model to v0.2 a 70%-probability
     strategic mistake.

  22.  Normative References

     [draft-stone-aivs-01]
                stone, B., "AIVS: Agentic Integrity Verification
                Standard", Work in Progress, Internet-Draft, draft-stone-
                aivs-01, 2026, <https://datatracker.ietf.org/doc/html/
                draft-stone-aivs-01>.



  stone                    Expires 27 October 2026               [Page 28]


  Internet-Draft                    ADRP                        April 2026


     [draft-stone-atep-01]
                stone, B., "ATEP: Agent Trust and Execution Passport",
                Work in Progress, Internet-Draft, draft-stone-atep-01,
                2026, <https://datatracker.ietf.org/doc/html/draft-stone-
                atep-01>.

     [draft-stone-atxn-00]
                stone, B., "ATXN: Agent-to-Agent Transaction Definition
                Protocol", Work in Progress, Internet-Draft, draft-stone-
                atxn-00, 2026, <https://datatracker.ietf.org/doc/html/
                draft-stone-atxn-00>.

     [draft-stone-vcap-01]
                stone, B., "VCAP: Verified Commerce for Agent Protocols",
                Work in Progress, Internet-Draft, draft-stone-vcap-01,
                2026, <https://datatracker.ietf.org/doc/html/draft-stone-
                vcap-01>.

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

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

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

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

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

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



  stone                    Expires 27 October 2026               [Page 29]


  Internet-Draft                    ADRP                        April 2026


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

  23.  Informative References

     [AP2]      Google, "Agent Payments Protocol", 2025,
                <https://developers.google.com/wallet/agent-payments>.

     [FAA]      United States Congress, "Federal Arbitration Act, 9 U.S.C.
                Sections 1-16", 1925.

     [HOWEY]    Supreme Court of the United States, "SEC v. W. J. Howey
                Co., 328 U.S. 293", 1946.

     [KLEROS]   Kleros, "Decentralized Court Protocol", 2018,
                <https://kleros.io>.

     [NY-CONVENTION]
                United Nations, "Convention on the Recognition and
                Enforcement of Foreign Arbitral Awards", 1958.

     [OFAC-SANCTIONS]
                U.S. Treasury OFAC, "Specially Designated Nationals List",
                2024, <https://ofac.treasury.gov/specially-designated-
                nationals-and-blocked-persons-list-sdn-human-readable-
                lists>.

     [REST-AGENCY-3D]
                American Law Institute, "Restatement (Third) of Agency",
                2006.

     [STRIPE-CONNECT]
                Stripe, "Connect Disputes and Chargebacks", 2024,
                <https://stripe.com/docs/connect/disputes>.

     [UETA-14]  Uniform Law Commission, "Uniform Electronic Transactions
                Act Section 14", 1999.

     [UMA]      UMA Protocol, "Optimistic Oracle", 2020,
                <https://uma.xyz>.

     [UPWORK-MEDIATION]
                Upwork, "Dispute Process", 2024,
                <https://support.upwork.com/hc/en-us/articles/211062568>.






  stone                    Expires 27 October 2026               [Page 30]


  Internet-Draft                    ADRP                        April 2026


     [VISA-CHARGEBACK-CODES]
                Visa Inc., "Visa Chargeback Reason Codes", 2024,
                <https://usa.visa.com/dam/VCOM/download/about-visa/visa-
                rules-public.pdf>.

  Appendix A: JSON Schemas (Informative)

  A.1 DisputeFiling Schema











































  stone                    Expires 27 October 2026               [Page 31]


  Internet-Draft                    ADRP                        April 2026


     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "https://swarmsync.ai/spec/adrp/v1/dispute-filing.schema.json",
       "title": "DisputeFiling",
       "type": "object",
       "required": [
         "msg_type", "msg_id", "prev_hash", "submitter_did",
         "submitter_signature", "timestamp", "payload"
       ],
       "properties": {
         "msg_type": { "const": "DisputeFiling" },
         "msg_id": { "type": "string", "format": "uuid" },
         "prev_hash": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "submitter_did": { "type": "string" },
         "submitter_signature": { "type": "string" },
         "timestamp": { "type": "string", "format": "date-time" },
         "payload": {
           "type": "object",
           "required": [
             "payment_mandate_ref", "claim_code", "claim_detail", "filing_fee"
           ],
           "properties": {
             "payment_mandate_ref": { "type": "string" },
             "claim_code": { "type": "string" },
             "claim_detail": { "type": "string", "maxLength": 4096 },
             "flag_ref": { "type": "string" },
             "prior_ruling_ref": { "type": "string" },
             "filing_fee": {
               "type": "object",
               "required": ["amount", "currency", "transaction_id"],
               "properties": {
                 "amount": { "type": "number", "minimum": 1, "maximum": 1000 },
                 "currency": { "enum": ["USD", "USDC"] },
                 "transaction_id": { "type": "string" }
               }
             }
           }
         }
       }
     }

  A.2 RulingBundle Schema









  stone                    Expires 27 October 2026               [Page 32]


  Internet-Draft                    ADRP                        April 2026


     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "https://swarmsync.ai/spec/adrp/v1/ruling-bundle.schema.json",
       "title": "RulingBundle",
       "type": "object",
       "required": [
         "type", "supersedes", "dispute_chain_tip", "verdict",
         "rationale_hash", "arbitrator_did", "arbitrator_vc_hash",
         "signing_time", "prev_hash", "sig"
       ],
       "properties": {
         "type": { "const": "RulingBundle" },
         "supersedes": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "dispute_chain_tip": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "verdict": { "enum": ["release", "refund", "partial"] },
         "partial_split": {
           "type": "object",
           "properties": {
             "to_buyer": { "type": "number", "minimum": 0, "maximum": 1 },
             "to_seller": { "type": "number", "minimum": 0, "maximum": 1 }
           }
         },
         "rationale_hash": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "arbitrator_did": { "type": "string" },
         "arbitrator_vc_hash": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "signing_time": { "type": "string", "format": "date-time" },
         "prev_hash": { "type": "string", "pattern": "^[0-9a-f]{64}$" },
         "sig": { "type": "string" }
       }
     }

  Appendix B: Worked Example (Informative)

  B.1 Scenario

     A small business principal (did:web:smb.example) dispatches an agent
     to book a $250 hotel reservation.  The agent books in Portland, ME
     instead of Portland, OR due to an ambiguous Cart Mandate.

  B.2 Sequence

     1.   Agent emits DisputeFlag: claim_code quality_mismatch.

     2.   Principal reviews flag within 72h, agrees booking is wrong.

     3.   Principal emits DisputeFiling: quality_mismatch, filing_fee
          $25.00 USDC.




  stone                    Expires 27 October 2026               [Page 33]


  Internet-Draft                    ADRP                        April 2026


     4.   Arbitrator assigned via VRF from L2 curated AI pool.

     5.   Principal submits evidence: original Cart Mandate showing
          "Portland" without state qualifier.

     6.   Counterparty submits evidence: acceptance_criteria.checks is
          empty.

     7.   Arbitrator finds spec_ambiguity.  Verdict: partial, split 70/30
          to buyer/seller.

     8.   RulingBundle signed within 4h SLA.

     9.   EscrowDirective: $175 to buyer, $75 to seller.

     10.  AP2 Payment Mandate executor consumes EscrowDirective, executes
          split.

     11.  Filing fee: 50% forfeited ($12.50), 50% refunded ($12.50).

  B.3 Verification

     Any third party, given (DisputeBundle, RulingBundle), can run
     verify_resolution deterministically.

  B.4 Precedent

     RulingBundle indexed in precedent corpus by Cart Mandate template
     hash.

  Appendix C: Open Issues for Shadow-Mode Validation

     +========+=============================+============================+
     | Number | Question                    | Falsification              |
     |        |                             | Threshold                  |
     +========+=============================+============================+
     | 1      | Will principals author Cart | Less than 30%              |
     |        | Mandates with 3+            | coverage at day 30 →       |
     |        | acceptance_criteria.checks? | ship NLP-to-checks         |
     |        |                             | helper as mandatory        |
     +--------+-----------------------------+----------------------------+
     | 2      | Will the auto-resolution    | Less than 60% at day       |
     |        | rate hit 60%+?              | 60 → escalate to           |
     |        |                             | architectural review       |
     +--------+-----------------------------+----------------------------+
     | 3      | Will the frivolous filing   | Greater than 2% at         |
     |        | rate stay below 2%?         | day 60 → tighten           |
     |        |                             | filing fee floor           |



  stone                    Expires 27 October 2026               [Page 34]


  Internet-Draft                    ADRP                        April 2026


     +--------+-----------------------------+----------------------------+
     | 4      | Will the curated arbitrator | Greater than 5% SLA        |
     |        | pool meet SLA at scale?     | breaches at day 90 →       |
     |        |                             | expand pool or             |
     |        |                             | accelerate v0.2            |
     +--------+-----------------------------+----------------------------+
     | 5      | Will the Arbitration        | Any court challenge        |
     |        | Mandate be challenged in    | → seek immediate           |
     |        | court?                      | written legal              |
     |        |                             | opinion                    |
     +--------+-----------------------------+----------------------------+
     | 6      | Will the precedent corpus   | Less than 100 corpus       |
     |        | accumulate fast enough?     | queries by                 |
     |        |                             | arbitrators at month       |
     |        |                             | 3 → revisit                |
     +--------+-----------------------------+----------------------------+
     | 7      | Are tier thresholds         | Filing rate greater        |
     |        | calibrated correctly?       | than 5% or less than       |
     |        |                             | 0.05% → recalibrate        |
     +--------+-----------------------------+----------------------------+

                                    Table 18

     GA is gated on: auto-resolution rate greater than or equal to 60% AND
     frivolous filing rate less than or equal to 2% AND zero court
     challenges AND arbitrator SLA breaches less than or equal to 5% AND
     median Cart Mandate has at least 1 non-trivial
     acceptance_criteria.check.

  Author's Address

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

















  stone                    Expires 27 October 2026               [Page 35]


name: draft-stone-atxn
rev: 00
title: ATXN: Agent-to-Agent Transaction Definition Protocol
time: 2026-04-25T23:52:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-27T23:52:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:47.115465+00:00
source: ietf
abstract:
  This document defines a canonical, defensible, machine-checkable
     primitive for an Agent-to-Agent (A2A) transaction.  It establishes
     the bundle of cryptographically signed elements that constitute a
     recorded value exchange between two software agents acting as
     instruments of identified principals, the conformance tiers that
     determine which elements are required, the rail-specific Profiles
     that map the bundle to existing payment infrastructure, and the two-
     tier validity model that distinguishes externally-adjudicable
     transactions from operationally-valid uncontested exchanges.

     ATXN is the foundational legal and technical primitive for escrow,
     dispute resolution, audit, and liability allocation in agentic
     commerce.  It is designed to operate under existing contract law (UCC
     2-204, UETA 14, Restatement (Third) of Agency, CISG) without
     requiring statutory recognition of agent personhood.  It maps
     directly to AP2, Stripe ACP, Visa TAP, Mastercard Agent Pay, and x402
     as Profiles of a single canonical bundle.

     Companion specifications (all co-submitted as Internet-Drafts, work
     in progress):

     *  AIVS (draft-stone-aivs-01): cryptographic audit-trail substrate
        that ATXN bundles inherit from

     *  VCAP (draft-stone-vcap-01): verified-commerce escrow rails that
        consume ATXN bundles

     *  ATEP (draft-stone-atep-01): trust passports that bind agents to
        capacity-attested principals

     *  ADRP (draft-stone-adrp-00): dispute resolution protocol invoked
        when an ATXN bundle enters the disputed state

full_text:
  Network Working Group                                           B. stone
  Internet-Draft                                              SwarmSync.AI
  Intended status: Standards Track                           25 April 2026
  Expires: 27 October 2026


            ATXN: Agent-to-Agent Transaction Definition Protocol
                            draft-stone-atxn-00

  Abstract

     This document defines a canonical, defensible, machine-checkable
     primitive for an Agent-to-Agent (A2A) transaction.  It establishes
     the bundle of cryptographically signed elements that constitute a
     recorded value exchange between two software agents acting as
     instruments of identified principals, the conformance tiers that
     determine which elements are required, the rail-specific Profiles
     that map the bundle to existing payment infrastructure, and the two-
     tier validity model that distinguishes externally-adjudicable
     transactions from operationally-valid uncontested exchanges.

     ATXN is the foundational legal and technical primitive for escrow,
     dispute resolution, audit, and liability allocation in agentic
     commerce.  It is designed to operate under existing contract law (UCC
     2-204, UETA 14, Restatement (Third) of Agency, CISG) without
     requiring statutory recognition of agent personhood.  It maps
     directly to AP2, Stripe ACP, Visa TAP, Mastercard Agent Pay, and x402
     as Profiles of a single canonical bundle.

     Companion specifications (all co-submitted as Internet-Drafts, work
     in progress):

     *  AIVS (draft-stone-aivs-01): cryptographic audit-trail substrate
        that ATXN bundles inherit from

     *  VCAP (draft-stone-vcap-01): verified-commerce escrow rails that
        consume ATXN bundles

     *  ATEP (draft-stone-atep-01): trust passports that bind agents to
        capacity-attested principals

     *  ADRP (draft-stone-adrp-00): dispute resolution protocol invoked
        when an ATXN bundle enters the disputed state

  Status of This Memo

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



  stone                    Expires 27 October 2026                [Page 1]


  Internet-Draft                    ATXN                        April 2026


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

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

     This Internet-Draft will expire on 27 October 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Problem . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  What ATXN Defines . . . . . . . . . . . . . . . . . . . .   4
       1.3.  What ATXN Deliberately Does NOT Do  . . . . . . . . . . .   5
       1.4.  Legal Model: Agents as Executors, Not Parties . . . . . .   5
       1.5.  Design Tenets . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  The ATXN Bundle . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Element 1: Intent Mandate . . . . . . . . . . . . . . . .   7
       3.2.  Element 2: Scope/Capability Token . . . . . . . . . . . .   8
       3.3.  Element 3: Payment Authorization  . . . . . . . . . . . .   8
       3.4.  Element 4: Delivery Attestation . . . . . . . . . . . . .   9
       3.5.  Element 5: Revocability Window  . . . . . . . . . . . . .   9
     4.  Standing Tokens and Principal Anchoring . . . . . . . . . . .  10
       4.1.  Required Sub-Elements . . . . . . . . . . . . . . . . . .  10
       4.2.  Capacity Attestation  . . . . . . . . . . . . . . . . . .  11
       4.3.  Pre-Committed Arbitrator  . . . . . . . . . . . . . . . .  11
       4.4.  Freshness and Revocation  . . . . . . . . . . . . . . . .  11
     5.  Conformance Tiers . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.  Anti-Arbitrage Rule . . . . . . . . . . . . . . . . . . .  12



  stone                    Expires 27 October 2026                [Page 2]


  Internet-Draft                    ATXN                        April 2026


       5.2.  Dispute-Phase Tier Escalation . . . . . . . . . . . . . .  12
     6.  Rail Profiles . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.  Profile-PLATFORM  . . . . . . . . . . . . . . . . . . . .  13
       6.2.  Profile Composition . . . . . . . . . . . . . . . . . . .  14
     7.  Two-Tier Validity Model . . . . . . . . . . . . . . . . . . .  14
       7.1.  Primary Validity  . . . . . . . . . . . . . . . . . . . .  14
       7.2.  Secondary (Operational) Validity  . . . . . . . . . . . .  14
       7.3.  Boundary  . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.  State Machine . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Commitment Event  . . . . . . . . . . . . . . . . . . . .  16
       8.2.  ADRP State Machine Join Points  . . . . . . . . . . . . .  16
     9.  Cryptographic Requirements  . . . . . . . . . . . . . . . . .  16
       9.1.  Signature Algorithms  . . . . . . . . . . . . . . . . . .  17
       9.2.  Hash Functions  . . . . . . . . . . . . . . . . . . . . .  17
       9.3.  Timestamping  . . . . . . . . . . . . . . . . . . . . . .  17
       9.4.  Key Hierarchy . . . . . . . . . . . . . . . . . . . . . .  17
     10. Dispute Triggers and ADRP Handoff . . . . . . . . . . . . . .  17
       10.1.  Dispute Triggers . . . . . . . . . . . . . . . . . . . .  17
       10.2.  ADRP Handoff . . . . . . . . . . . . . . . . . . . . . .  18
       10.3.  Conduit-Attestation Disputes . . . . . . . . . . . . . .  18
     11. Liability Waterfall . . . . . . . . . . . . . . . . . . . . .  19
     12. Out-of-Scope Concerns . . . . . . . . . . . . . . . . . . . .  20
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  20
       13.1.  Q4 Dangerous Consensus: Scope Machine-Enforceability . .  20
       13.2.  Threshold-Signature Clock Compromise . . . . . . . . . .  20
       13.3.  Revocation Beacon DoS  . . . . . . . . . . . . . . . . .  20
       13.4.  Capacity Attestation as Privacy Attack Surface . . . . .  21
       13.5.  Hallucinated Mandates  . . . . . . . . . . . . . . . . .  21
       13.6.  Sub-Agency Adversarial Chains  . . . . . . . . . . . . .  21
       13.7.  Tier Arbitrage . . . . . . . . . . . . . . . . . . . . .  21
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
       14.1.  ATXN Bundle JSON-LD Context  . . . . . . . . . . . . . .  21
       14.2.  ATXN Profile Registry  . . . . . . . . . . . . . . . . .  21
       14.3.  ATXN Liability Waterfall Enum  . . . . . . . . . . . . .  22
     15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22
     16. Normative References  . . . . . . . . . . . . . . . . . . . .  22
     17. Informative References  . . . . . . . . . . . . . . . . . . .  24
     Appendix A: JSON Schema (Informative) . . . . . . . . . . . . . .  25
     Appendix B: Worked Example (Informative)  . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

  1.  Introduction









  stone                    Expires 27 October 2026                [Page 3]


  Internet-Draft                    ATXN                        April 2026


  1.1.  The Problem

     Every existing payment infrastructure encodes 3,000 years of human
     commercial law (offer, acceptance, consideration, capacity, mutual
     assent, dispute window).  Every assumption in that infrastructure
     presupposes a person — a mind that intends, a body that signs, a
     legal status that bears liability.

     Software agents transacting on behalf of principals break every one
     of these assumptions simultaneously:

     *  Agents cannot sign contracts in the legal sense;

     *  Delivery verification has no independent mechanism when both
        parties are software;

     *  When harm occurs, the liability chain among principal, operator,
        merchant, processor, and model provider is undefined;

     *  Existing dispute mechanisms (chargebacks, arbitration) have no
        native concept of an agent acting under bounded mandate.

     Without a canonical primitive, every platform deploying agentic
     commerce will independently invent incompatible transaction records,
     producing a fragmented ecosystem in which cross-platform escrow,
     dispute resolution, and audit are impossible.

  1.2.  What ATXN Defines

     An A2A transaction is the cryptographically-verifiable execution of a
     Bundle comprising five signed elements:

     1.  Intent Mandate — principal's signed declaration of desired
         outcome

     2.  Scope/Capability Token — machine-checkable bounds the agent
         cannot exceed

     3.  Payment Authorization — rail-agnostic signed instrument reference

     4.  Delivery Attestation — counterparty-countersigned proof that
         performance occurred

     5.  Revocability Window — declared finality clock with a queryable
         revocation beacon






  stone                    Expires 27 October 2026                [Page 4]


  Internet-Draft                    ATXN                        April 2026


     Each agent participating in a Bundle presents a Standing Token
     binding it to a capacity-attested principal via a verifiable
     credential chain.

  1.3.  What ATXN Deliberately Does NOT Do

     *  ATXN does not grant agents legal personhood.  Bundles are
        evidentiary artifacts of principal-to-principal contracts.

     *  ATXN does not require statutory change.  It operates under
        existing UCC 2-204, UETA 14, Restatement (Third) of Agency, and
        CISG.

     *  ATXN does not define a dispute resolution forum.  The Bundle's
        choice-of-law tag and Profile-JURISDICTION pin the forum at
        signing; the actual dispute mechanism is profile-specific
        (chargeback for Profile-CARD, on-chain arbitration for Profile-
        CRYPTO, ADRP for Profile-MANDATE).

     *  ATXN does not define agent identity beyond a DID/operator/
        principal credential chain.

  1.4.  Legal Model: Agents as Executors, Not Parties

     ATXN treats Agents as instruments of Principals, not as independent
     legal parties.  This is consistent with UETA 14 ("automated
     transactions") and Restatement (Third) of Agency 1.01, under which an
     agent acting within the scope of its mandate binds the principal, not
     itself.  All liability in an ATXN Bundle flows to the identified
     Principals via the Standing Token chain.  This legal model is shared
     by the companion specification ADRP (draft-stone-adrp-00,
     Section 5.1), which further specifies that only Principals have
     dispute standing.

  1.5.  Design Tenets

     *  *Falsifiable:* Every element is a binary cryptographic check.

     *  *Rail-agnostic:* A Bundle abstracts over AP2, ACP, TAP, Agent Pay,
        x402; none privileged.

     *  *Two-tier validity:* Distinguishes externally-adjudicable
        transactions from operationally-valid uncontested exchanges.

     *  *Mandate-framework-anchored:* Legal force derives from the
        upstream mandate chain, not the transaction message itself.





  stone                    Expires 27 October 2026                [Page 5]


  Internet-Draft                    ATXN                        April 2026


     *  *Tiered conformance:* L1 atomic, L2 mandated, L3 fiduciary —
        proportional to risk class.

     *  *Mechanical assent:* "Mutual assent" is replaced by matched-
        signed-intents (a mechanical predicate match).

  2.  Terminology

     The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
     SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
     interpreted as described in BCP 14 [RFC2119] [RFC8174].

     Agent  A software process that takes action on behalf of a Principal
        under a verifiable Mandate.

     Principal  A natural or legal person whose legal capacity, liability,
        and recourse are anchored by the transaction.

     Operator  The platform, service, or entity that runs an Agent on
        behalf of a Principal.

     Bundle  The five-element ATXN primitive defined in Section 3.

     Standing Token  A verifiable credential chain (agent_key to
        operator_key to principal_legal_identity) presented at Bundle
        execution, defined in Section 4.

     Mandate Framework  The pre-established principal-to-principal
        authorization structure from which the Bundle derives legal force.

     Profile  A mapping of the Bundle's five elements onto a specific
        payment rail's native artifacts (Section 6).

     Tier  A conformance level (L1/L2/L3) that determines which Bundle
        elements are required (Section 5).

     Primary Validity  All five Bundle elements are independently
        verifiable by a party with no stake in the outcome.

     Secondary (Operational) Validity  Self-attested delivery by
        transacting parties; valid between parties when uncontested but
        not independently adjudicable.

     Commitment Event  The point at which obligation forms; the liability-
        attachment moment.

     Revocation Beacon  Principal-controlled endpoint that publishes
        signed revocation events.



  stone                    Expires 27 October 2026                [Page 6]


  Internet-Draft                    ATXN                        April 2026


     ADRP  Agent Dispute Resolution Protocol (companion specification,
        draft-stone-adrp-00) invoked when a Bundle enters the disputed
        state.  Terms from ADRP used in this document: DisputeBundle,
        DisputeFiling, DisputeFlag, RulingBundle, EscrowDirective,
        Arbitration Mandate.  See draft-stone-adrp-00 Section 2 for
        definitions.

     Conduit Attestation  A delivery attestation issued by the SwarmSync
        Conduit headless-browser audit substrate or another structurally
        independent attestor recognized by the Bundle's Profile.

  3.  The ATXN Bundle

     A Bundle is a cryptographically-signed object containing five
     elements.  Each element MUST be a Verifiable Credential per the W3C
     VC Data Model 2.0, JSON-LD canonicalized per [RFC8785] (JCS), and
     signed using JWS with EdDSA (Ed25519) or ECDSA (P-256).

  3.1.  Element 1: Intent Mandate

     The Intent Mandate is the Principal's signed declaration of desired
     outcome.

     Required fields:

     intent_id (UUID)  Unique mandate identifier.

     principal_did (DID)  Principal's decentralized identifier.

     outcome (String)  Natural-language description of desired outcome.

     budget_ceiling (Decimal + currency)  Maximum spend authorized.

     counterparty_class (Enum/String)  Allowed counterparty type or
        specific DID.

     time_window (ISO 8601 interval)  Mandate validity window.

     choice_of_law (ISO 3166-1 alpha-2)  Jurisdiction tag for dispute
        pinning.

     mandate_framework_ref (URI)  Reference to upstream mandate framework
        that grants legal force.

     principal_signature (Ed25519 base64)  Principal's signature over
        canonical JSON of all preceding fields.





  stone                    Expires 27 October 2026                [Page 7]


  Internet-Draft                    ATXN                        April 2026


     The mandate_framework_ref field is REQUIRED.  A Bundle with no
     mandate-framework reference fails primary validity.

  3.2.  Element 2: Scope/Capability Token

     Required fields:

     scope_id (UUID)  Unique scope identifier.

     intent_id (UUID)  Foreign key to Intent Mandate.

     max_spend (Decimal + currency)  Per-transaction spend cap.

     allowed_actions (Array of String)  Machine-checkable action
        predicates.

     allowed_counterparties (Array of DID or pattern)  Counterparty
        allowlist or pattern.

     sub_delegation_depth (Integer)  Maximum sub-agent chain depth.

     predicate_engine_version (SemVer)  Version of deterministic
        evaluator.

     enforcement_mode (Enum: advisory or enforced)  v0.1 default advisory;
        v1.0 default enforced.

     operator_signature (Ed25519 base64)  Operator's signature.

     Enforcement mode: v0.1 implementations MAY use advisory mode, where
     scope is parseable but a scope-delta event is logged rather than
     blocking execution.  v1.0 implementations MUST default to enforced.

  3.3.  Element 3: Payment Authorization

     Required fields:

     payment_id (UUID)  Unique payment identifier.

     intent_id (UUID)  Foreign key.

     instrument_type (Enum)  card_token, x402_challenge, ach_mandate,
        stablecoin_preauth, bank_transfer, platform_credit.

     instrument_ref (String)  Rail-specific reference.

     amount (Decimal + currency)  Authorized amount.




  stone                    Expires 27 October 2026                [Page 8]


  Internet-Draft                    ATXN                        April 2026


     profile (Enum)  Active rail profile.

     principal_signature or operator_signature (Ed25519 base64)  Signature
        appropriate to profile.

  3.4.  Element 4: Delivery Attestation

     Required fields:

     delivery_id (UUID)  Unique delivery identifier.

     intent_id (UUID)  Foreign key.

     deliverable_class (Enum)  sync_api, async_job, streamed_media,
        physical_offchain.

     attestation_pattern (Object)  Class-specific structure.

     counterparty_signature (Ed25519 base64)  Receiving Agent's
        countersignature.

     independent_attestor_signature (Ed25519 base64, optional)  Required
        for primary validity.

     Class-specific attestation patterns:

     *  sync_api: response_hash, timestamp, status_code

     *  async_job: job_completion_oracle_signature, oracle_did,
        job_artifact_hash

     *  streamed_media: merkle_root, chunk_count, total_bytes

     *  physical_offchain: third_party_carrier_did,
        signed_proof_of_delivery, gps_timestamp_optional

     A transaction lacking an independent_attestor_signature is
     operationally valid (secondary validity) but is NOT primary-valid for
     adjudication purposes.

  3.5.  Element 5: Revocability Window

     Required fields:

     window_id (UUID)  Unique window identifier.

     intent_id (UUID)  Foreign key.




  stone                    Expires 27 October 2026                [Page 9]


  Internet-Draft                    ATXN                        April 2026


     start_time (ISO 8601 timestamp)  Window opens.

     end_time (ISO 8601 timestamp)  Window closes (finality reached).

     revocation_beacon_url (URI)  Principal-controlled revocation
        endpoint.

     clock_authority (Object)  Threshold-signature clock specification.

     The clock authority MUST be a 3-of-5 threshold signature from a
     federated set of timestamping authorities for L2 and L3 Bundles.

  4.  Standing Tokens and Principal Anchoring

     Each Agent participating in a Bundle MUST present a Standing Token.
     A Standing Token is a verifiable credential chain: agent_key to
     operator_key to principal_legal_identity.

  4.1.  Required Sub-Elements

     +======================+==========+================================+
     | Sub-element          | Required | Description                    |
     +======================+==========+================================+
     | agent_key            | Yes      | Ed25519 or P-256 public key    |
     |                      |          | for the executing agent        |
     +----------------------+----------+--------------------------------+
     | operator_key         | Yes      | Public key of the platform     |
     |                      |          | operating the agent            |
     +----------------------+----------+--------------------------------+
     | principal_did        | Yes      | DID of the legal entity        |
     |                      |          | (natural or corporate)         |
     +----------------------+----------+--------------------------------+
     | capacity_attestation | Yes (L2/ | VC issued by a recognized      |
     |                      | L3)      | verifier proving principal     |
     |                      |          | capacity                       |
     +----------------------+----------+--------------------------------+
     | freshness_proof      | Yes      | Re-attestation timestamp,      |
     |                      |          | valid within freshness window  |
     +----------------------+----------+--------------------------------+
     | revocation_list_url  | Yes      | Issuer-published revocation    |
     |                      |          | list endpoint                  |
     +----------------------+----------+--------------------------------+
     | arbitrator_did       | Yes (L2/ | Pre-committed arbitrator DID   |
     |                      | L3)      | for dispute escalation         |
     +----------------------+----------+--------------------------------+
     | arb_mandate_hash     | Yes (L2/ | SHA-256 hash of the            |
     |                      | L3)      | Arbitration Mandate (per ADRP  |
     |                      |          | Section 4); anchors the ADRP   |



  stone                    Expires 27 October 2026               [Page 10]


  Internet-Draft                    ATXN                        April 2026


     |                      |          | dispute-resolution agreement   |
     |                      |          | at Standing Token signing time |
     +----------------------+----------+--------------------------------+

                                   Table 1

  4.2.  Capacity Attestation

     A Standing Token without capacity attestation MUST NOT anchor an L2
     or L3 Bundle.  Capacity attestation MUST establish that, at the time
     of mandate granting, the Principal had:

     *  legal age in the relevant jurisdiction;

     *  no active sanctions;

     *  (for corporate principals) active legal-entity status;

     *  jurisdiction-permitted authority for the transaction class.

  4.3.  Pre-Committed Arbitrator

     Every L2 and L3 Standing Token MUST commit, at signing time, to an
     arbitrator_did empowered to adjudicate disputes.  The
     arb_mandate_hash field anchors the full Arbitration Mandate (defined
     in ADRP, draft-stone-adrp-00, Section 4) at Standing Token signing
     time.  A Standing Token for an L2 or L3 Bundle without a valid
     arb_mandate_hash MUST NOT be accepted.

  4.4.  Freshness and Revocation

     Freshness window: Re-attestation MUST occur every N transactions or M
     days (whichever is shorter), where N and M are Profile-specific.  A
     stale or revoked Standing Token MUST NOT anchor a new Bundle.

  5.  Conformance Tiers

       +===========+=======================+==========================+
       | Tier      | Required Elements     | Use Case                 |
       +===========+=======================+==========================+
       | L1 —      | Elements 1, 2, 3, 4   | x402 micropayments; sub- |
       | Atomic    | in single round-trip; | cent metered compute;    |
       |           | Element 5 optional    | streaming inference      |
       +-----------+-----------------------+--------------------------+
       | L2 —      | Elements 1-5 (full    | Standard agentic         |
       | Mandated  | Bundle); capacity     | commerce: AP2 purchases, |
       |           | attestation; pre-     | Stripe ACP, multi-step   |
       |           | committed arbitrator  | service contracts        |



  stone                    Expires 27 October 2026               [Page 11]


  Internet-Draft                    ATXN                        April 2026


       +-----------+-----------------------+--------------------------+
       | L3 —      | Elements 1-5 +        | High-value (greater than |
       | Fiduciary | epistemic attestation | $10k or fiduciary-grade) |
       |           | + multi-sig principal | transactions; regulated  |
       |           | binding               | commerce; agent-managed  |
       |           |                       | treasury moves           |
       +-----------+-----------------------+--------------------------+

                                   Table 2

  5.1.  Anti-Arbitrage Rule

     Tier selection is constrained by transaction risk class, not by
     issuer election alone.  A risk-classifier registry (jurisdiction-
     specific) determines the floor tier per transaction.  An issuer MUST
     NOT select a Tier below the floor mandated by the registered
     classifier for the transaction class.

  5.2.  Dispute-Phase Tier Escalation

     ATXN Tier assignment governs Bundle formation.  During dispute
     resolution, ADRP (draft-stone-adrp-00, Section 10.1) MAY impose a
     lower dispute-routing escalation threshold than ATXN's L3 formation
     threshold.  Specifically, ADRP routes a Bundle declared L2 at
     formation to L3 dispute processing if the transaction value exceeds
     $1,000.  This is a dispute-processing rule only and does not
     retroactively change the Bundle's declared Tier.  The $10k threshold
     in Section 5 is the formation-tier floor for L3 Bundles; the $1,000
     escalation trigger in ADRP Section 10.1 governs only the dispute
     arbitration path.

  6.  Rail Profiles

     A Bundle is valid if it conforms to a defined Tier and at least one
     Profile.
















  stone                    Expires 27 October 2026               [Page 12]


  Internet-Draft                    ATXN                        April 2026


      +================================+==============+================+
      | Profile                        | Maps To      | Notes          |
      +================================+==============+================+
      | Profile-MANDATE                | AP2          | Native AP2     |
      |                                | Intent/Cart/ | alignment      |
      |                                | Payment      |                |
      |                                | Mandates     |                |
      +--------------------------------+--------------+----------------+
      | Profile-CARD                   | Visa TAP /   | Agentic        |
      |                                | Mastercard   | tokens, SPTs,  |
      |                                | Agent Pay /  | network        |
      |                                | Stripe ACP   | credentials    |
      +--------------------------------+--------------+----------------+
      | Profile-CRYPTO                 | x402,        | HTTP 402       |
      |                                | ERC-8004     | challenges,    |
      |                                |              | on-chain       |
      |                                |              | attestations   |
      +--------------------------------+--------------+----------------+
      | Profile-AUTONOMOUS             | Standing     | For unattended |
      |                                | intents,     | operation;     |
      |                                | recurring    | machine-time   |
      |                                | scope        | expiry         |
      +--------------------------------+--------------+----------------+
      | Profile-PLATFORM               | Platform-    | Covers non-    |
      |                                | vouched      | cryptographic  |
      |                                | OAuth + HMAC | enterprise A2A |
      |                                | equivalents  | volume         |
      +--------------------------------+--------------+----------------+
      | Profile-                       | Choice-of-   | Declares       |
      | JURISDICTION-{US,EU,UK,SG,...} | law overlay  | applicable     |
      |                                |              | consumer-      |
      |                                |              | protection     |
      |                                |              | regime,        |
      |                                |              | dispute forum, |
      |                                |              | data residency |
      +--------------------------------+--------------+----------------+

                                   Table 3

  6.1.  Profile-PLATFORM

     The dominant real-world A2A volume in 2026 runs on platform-vouched
     rails.  Profile-PLATFORM Bundles cannot achieve primary validity but
     MAY be operationally valid for execution between consenting parties
     using the platform.






  stone                    Expires 27 October 2026               [Page 13]


  Internet-Draft                    ATXN                        April 2026


  6.2.  Profile Composition

     A Bundle MAY declare multiple Profiles.  The Bundle's effective
     constraints are the union of its declared Profiles' constraints.

  7.  Two-Tier Validity Model

  7.1.  Primary Validity

     A Bundle is primary-valid if and only if:

     *  all five elements (per the conformance Tier) are present and
        signed;

     *  the Standing Token chain validates to a capacity-attested
        Principal;

     *  every element is independently verifiable by a party with no stake
        in the outcome;

     *  the Scope predicate evaluates true against the Cart/action under
        the declared enforcement_mode;

     *  the chosen Profile's settlement constraint is met.

     Primary validity is a precondition for independent adjudication
     (court enforcement, regulatory recognition, cross-platform dispute
     escalation).

  7.2.  Secondary (Operational) Validity

     A Bundle is secondary-valid if and only if:

     *  it executes successfully between the two parties;

     *  both parties countersign without dispute;

     *  Standing Tokens validate to identifiable Principals (capacity
        attestation MAY be deferred);

     *  delivery attestation is self-reported (no independent attestor).

     Secondary-valid Bundles are operationally binding between the
     transacting parties but are NOT independently adjudicable.







  stone                    Expires 27 October 2026               [Page 14]


  Internet-Draft                    ATXN                        April 2026


  7.3.  Boundary

     A primary-valid Bundle MUST also satisfy all secondary validity
     conditions.  A secondary-valid Bundle MUST NOT be marketed, recorded,
     or relied upon as primary-valid.

  8.  State Machine

     States: proposed, authorized, executing, delivered, finalized,
     disputed, adjudicated.

     proposed --> authorized --> executing --> delivered --> finalized
                                                    |
                                                    v
                                                disputed --> adjudicated

        +=============+=======================+=======================+
        | State       | Trigger               | Required Signatures   |
        +=============+=======================+=======================+
        | proposed    | Intent Mandate signed | Principal             |
        |             | by Principal          |                       |
        +-------------+-----------------------+-----------------------+
        | authorized  | Scope Token + Payment | Principal + Operator  |
        |             | Authorization signed  |                       |
        +-------------+-----------------------+-----------------------+
        | executing   | Agent action begins   | n/a                   |
        +-------------+-----------------------+-----------------------+
        | delivered   | Delivery Attestation  | Counterparty (+       |
        |             | countersigned         | independent attestor  |
        |             |                       | for primary validity) |
        +-------------+-----------------------+-----------------------+
        | finalized   | Revocability Window   | Threshold clock       |
        |             | closes without        | authority             |
        |             | revocation            |                       |
        +-------------+-----------------------+-----------------------+
        | disputed    | Counterparty contests | Either party +        |
        |             | OR revocation beacon  | arbiter notification  |
        |             | fires                 |                       |
        +-------------+-----------------------+-----------------------+
        | adjudicated | ADRP procedure        | Arbiter + ADRP-       |
        |             | terminates            | defined parties       |
        +-------------+-----------------------+-----------------------+

                                    Table 4







  stone                    Expires 27 October 2026               [Page 15]


  Internet-Draft                    ATXN                        April 2026


  8.1.  Commitment Event

     The commitment event — the transition from proposed to authorized —
     is the legally significant moment for liability attachment, NOT the
     finalized state.  Liability attaches at authorization time, even if
     delivery never occurs.  A Principal's revocation between authorized
     and delivered triggers disputed (not void).  An Operator's failure
     between authorized and delivered is a breach attaching to the
     operator-fallback liability tier (Section 11).

  8.2.  ADRP State Machine Join Points

          +=============+=============+=============================+
          | ATXN State  | ADRP Entry  | Condition                   |
          | Transition  | State       |                             |
          +=============+=============+=============================+
          | delivered   | ADRP        | Agent emits DisputeFlag     |
          | to disputed | FLAGGED     | (advisory; principal must   |
          |             |             | ratify within tier window)  |
          +-------------+-------------+-----------------------------+
          | delivered   | ADRP FILED  | Principal emits             |
          | to disputed |             | DisputeFiling directly      |
          |             |             | (skips FLAGGED)             |
          +-------------+-------------+-----------------------------+
          | disputed    | adjudicated | ADRP RulingBundle signed;   |
          | (ADRP       |             | EscrowDirective produced    |
          | RULED)      |             |                             |
          +-------------+-------------+-----------------------------+
          | disputed    | finalized   | EscrowDirective consumed by |
          | (ADRP       |             | payment rail; escrow        |
          | SETTLED)    |             | released or refunded        |
          +-------------+-------------+-----------------------------+
          | disputed    | finalized   | Filer withdraws; partial    |
          | (ADRP       |             | fee refund; escrow releases |
          | WITHDRAWN)  |             | per original terms          |
          +-------------+-------------+-----------------------------+
          | disputed    | finalized   | Dispute window expired;     |
          | (ADRP       |             | escrow defaults per Profile |
          | EXPIRED)    |             |                             |
          +-------------+-------------+-----------------------------+

                                    Table 5

  9.  Cryptographic Requirements







  stone                    Expires 27 October 2026               [Page 16]


  Internet-Draft                    ATXN                        April 2026


  9.1.  Signature Algorithms

     Primary: EdDSA (Ed25519) per [RFC8032].  Alternate: ECDSA P-256 per
     [RFC6979] (for FIPS-required environments).  All signatures MUST be
     over the JCS ([RFC8785]) canonicalization of the signed object.

  9.2.  Hash Functions

     Primary: SHA-256 per FIPS 180-4.  Optional: SHA3-256 (forward-
     compatible).

  9.3.  Timestamping

     L2 and L3 Bundles MUST use a 3-of-5 threshold-signature clock
     authority.  Single-source timestamps are SUFFICIENT only for L1.

  9.4.  Key Hierarchy

     agent_key  Short-lived (rotated per session or per N transactions).

     operator_key  Longer-lived (rotated quarterly or on incident).

     principal_key  Long-lived (rotated annually or on key-loss event).

     Cross-domain key reuse MUST be documented in the Standing Token's
     key_usage field.

  10.  Dispute Triggers and ADRP Handoff

  10.1.  Dispute Triggers

     A Bundle MUST transition to disputed if any of:

     *  counterparty issues a contestation signed by their Standing Token
        within the Revocability Window;

     *  Principal triggers the revocation beacon for the Bundle's
        intent_id before finalized;

     *  independent attestor's signature fails verification (when
        present);

     *  scope predicate evaluates false post-execution (under enforced
        mode);

     *  capacity attestation expires or revokes mid-execution;

     *  mandate framework reference becomes invalid.



  stone                    Expires 27 October 2026               [Page 17]


  Internet-Draft                    ATXN                        April 2026


  10.2.  ADRP Handoff

     When a Bundle enters disputed, the executing platform MUST:

     1.  Freeze settlement (if Profile-CRYPTO escrow) or initiate
         chargeback hold (if Profile-CARD);

     2.  Notify the pre-committed arbitrator_did from the Standing Token;

     3.  Package the Bundle and all signatures into an ADRP DisputeBundle
         (per draft-stone-adrp-00, Section 2);

     4.  Surface the dispute to both Principals via the operator UI;

     5.  Halt any sub-delegation chains that depend on the disputed
         Bundle.

  10.3.  Conduit-Attestation Disputes

     ATXN dispute_class / ADRP claim_code mapping:































  stone                    Expires 27 October 2026               [Page 18]


  Internet-Draft                    ATXN                        April 2026


     +=================+===========+====================+================+
     |dispute_class    |Description|ADRP Claim Code(s)  | ADRP Path      |
     +=================+===========+====================+================+
     |fact_dispute     |Attestation|bundle_integrity,   | Cryptographic- |
     |                 |correctness|timestamp_skew,     | class          |
     |                 |contested  |oracle_contradiction| resolution;    |
     |                 |           |                    | ADRP           |
     |                 |           |                    | Section 6.1    |
     +-----------------+-----------+--------------------+----------------+
     |terms_dispute    |Scope or   |mandate_scope,      | Semantic-class |
     |                 |quality    |quality_mismatch,   | resolution;    |
     |                 |contested  |spec_ambiguity,     | ADRP           |
     |                 |           |timing_breach,      | Section 6.2    |
     |                 |           |fitness_for_purpose |                |
     +-----------------+-----------+--------------------+----------------+
     |capacity_dispute |Standing   |Out of scope for    | Agent action   |
     |                 |Token /    |ADRP (see ADRP      | set aside;     |
     |                 |capacity   |Section 6.4)        | refund-to-     |
     |                 |contested  |                    | buyer; handled |
     |                 |           |                    | outside ADRP   |
     +-----------------+-----------+--------------------+----------------+
     |framework_dispute|Mandate    |Out of scope for    | ATXN and ADRP  |
     |                 |framework  |ADRP (see ADRP      | halt;          |
     |                 |validity   |Section 6.4)        | settlement     |
     |                 |contested  |                    | frozen until   |
     |                 |           |                    | resolved       |
     +-----------------+-----------+--------------------+----------------+

                                    Table 6

     For capacity_dispute: the executing platform MUST freeze settlement,
     return funds to the buyer, and notify both Principals.  No ADRP
     filing is permitted.

     For framework_dispute: the executing platform MUST freeze settlement
     and await resolution of the framework validity question.  ADRP
     processing MUST NOT proceed.

  11.  Liability Waterfall

      +======+===========+==============================================+
      | Tier | Party     | Triggering Failure                           |
      +======+===========+==============================================+
      | 1    | Principal | Authorized in-scope action delivered as      |
      |      |           | specified                                    |
      +------+-----------+----------------------------------------------+
      | 2    | Operator  | Out-of-scope action; freshness violation;    |
      |      |           | revocation propagation failure               |



  stone                    Expires 27 October 2026               [Page 19]


  Internet-Draft                    ATXN                        April 2026


      +------+-----------+----------------------------------------------+
      | 3    | Merchant  | Delivery attestation fraud; goods/services   |
      |      |           | not as described                             |
      +------+-----------+----------------------------------------------+
      | 4    | Processor | Settlement failure; payment-rail compromise  |
      +------+-----------+----------------------------------------------+
      | 5    | Model     | (L3 only) Demonstrable model-induced mandate |
      |      | Provider  | violation under epistemic attestation        |
      +------+-----------+----------------------------------------------+

                                    Table 7

     Profile-specific overrides MAY adjust this enum.  The Profile MUST
     publish its waterfall explicitly.

  12.  Out-of-Scope Concerns

     The following are explicitly out of scope for ATXN v1.0:

     1.  Agent legal personhood.

     2.  Tax treatment.

     3.  Securities classification.

     4.  Reputation as contractual term.

     5.  Sub-agency chains beyond sub_delegation_depth.

  13.  Security Considerations

  13.1.  Q4 Dangerous Consensus: Scope Machine-Enforceability

     The most fragile load-bearing assumption in ATXN is that scope can be
     made machine-checkable by a deterministic predicate engine.
     Implementations MUST log enforcement_mode.

  13.2.  Threshold-Signature Clock Compromise

     A 3-of-5 clock authority remains compromisable via collusion.
     Implementations SHOULD diversify the clock authority set across
     operators with non-correlated risk profiles.

  13.3.  Revocation Beacon DoS

     The revocation beacon is a denial-of-service surface.
     Implementations MUST cache beacon responses with a Profile-specific
     TTL.



  stone                    Expires 27 October 2026               [Page 20]


  Internet-Draft                    ATXN                        April 2026


  13.4.  Capacity Attestation as Privacy Attack Surface

     Capacity attestation tied to KYC/sanctions is a privacy attack
     surface.  Implementations SHOULD use selective-disclosure VCs (BBS+
     or equivalent).

  13.5.  Hallucinated Mandates

     An LLM-generated mandate that the Principal did not actually intend
     is a legitimate Bundle from a cryptographic standpoint.  L3 epistemic
     attestation partially mitigates this for high-value transactions.
     This is acknowledged residual risk.

  13.6.  Sub-Agency Adversarial Chains

     Implementations MUST limit sub_delegation_depth per Profile and
     SHOULD require all Standing Tokens in a chain to be independently
     verifiable.

  13.7.  Tier Arbitrage

     ATXN does not define an adjudicator for the risk-classifier registry
     itself; this is a governance question outside the protocol.

  14.  IANA Considerations

  14.1.  ATXN Bundle JSON-LD Context

     URI: https://swarmsync.ai/spec/atxn/v1

  14.2.  ATXN Profile Registry

     A new IANA registry "ATXN Profile Identifiers" is requested.
     Registration policy: Specification Required (per [RFC8126]).

     Initial entries:















  stone                    Expires 27 October 2026               [Page 21]


  Internet-Draft                    ATXN                        April 2026


       +==========================+====================+===============+
       | Identifier               | Description        | Reference     |
       +==========================+====================+===============+
       | atxn-mandate-ap2         | AP2 binding        | This document |
       +--------------------------+--------------------+---------------+
       | atxn-card-stripe-acp     | Stripe ACP binding | This document |
       +--------------------------+--------------------+---------------+
       | atxn-card-visa-tap       | Visa TAP binding   | This document |
       +--------------------------+--------------------+---------------+
       | atxn-card-mc-agentpay    | Mastercard Agent   | This document |
       |                          | Pay binding        |               |
       +--------------------------+--------------------+---------------+
       | atxn-crypto-x402         | x402 binding       | This document |
       +--------------------------+--------------------+---------------+
       | atxn-crypto-erc8004      | ERC-8004 binding   | This document |
       +--------------------------+--------------------+---------------+
       | atxn-autonomous-default  | Standing-intent    | This document |
       |                          | default            |               |
       +--------------------------+--------------------+---------------+
       | atxn-platform-oauth-hmac | Platform-vouched   | This document |
       |                          | OAuth+HMAC         |               |
       +--------------------------+--------------------+---------------+

                                    Table 8

  14.3.  ATXN Liability Waterfall Enum

     A new IANA registry "ATXN Liability Tiers" is requested.  Initial
     entries are listed in Section 11.

  15.  Acknowledgements

     This specification is the synthesis of Decision Oracle adjudication
     (2026-04-25) and Ultimate Brainstorm panel (2026-04-25).  The author
     thanks the panel agents — EpistemicAuditor, Archaeologist,
     Quantifier, ConstraintCartographer, socratic-mentor, DarkMirror,
     IdeaMatrix, RemixForge, SoSpec, SpiderSpark — and the Decision Oracle
     agents for the framework synthesis.  The author also acknowledges
     Paola Di Maio's prior critical review of the SwarmSync IETF Draft
     Stack, the AIKR CG Technical Note AI-KR-CG-TR-2026-001, and the AP2
     coalition.

  16.  Normative References








  stone                    Expires 27 October 2026               [Page 22]


  Internet-Draft                    ATXN                        April 2026


     [draft-stone-adrp-00]
                stone, B., "ADRP: Agent Dispute Resolution Protocol", Work
                in Progress, Internet-Draft, draft-stone-adrp-00, 2026,
                <https://datatracker.ietf.org/doc/html/draft-stone-adrp-
                00>.

     [draft-stone-aivs-01]
                stone, B., "AIVS: Agentic Integrity Verification
                Standard", Work in Progress, Internet-Draft, draft-stone-
                aivs-01, 2026, <https://datatracker.ietf.org/doc/html/
                draft-stone-aivs-01>.

     [draft-stone-atep-01]
                stone, B., "ATEP: Agent Trust and Execution Passport",
                Work in Progress, Internet-Draft, draft-stone-atep-01,
                2026, <https://datatracker.ietf.org/doc/html/draft-stone-
                atep-01>.

     [draft-stone-vcap-01]
                stone, B., "VCAP: Verified Commerce for Agent Protocols",
                Work in Progress, Internet-Draft, draft-stone-vcap-01,
                2026, <https://datatracker.ietf.org/doc/html/draft-stone-
                vcap-01>.

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

     [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
                Algorithm (DSA) and Elliptic Curve Digital Signature
                Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
                2013, <https://www.rfc-editor.org/info/rfc6979>.

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

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




  stone                    Expires 27 October 2026               [Page 23]


  Internet-Draft                    ATXN                        April 2026


     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

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

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

  17.  Informative References

     [AP2]      Google, "Agent Payments Protocol", 2026,
                <https://developers.google.com/agent-payments>.

     [CISG]     United Nations, "United Nations Convention on Contracts
                for the International Sale of Goods".

     [ERC-8004] Ethereum, "ERC-8004: Trustless Agents", 2026,
                <https://eips.ethereum.org/EIPS/eip-8004>.

     [REG-E]    Consumer Financial Protection Bureau, "12 CFR Part 1005
                (Regulation E)".

     [REST-AGENCY-3D]
                American Law Institute, "Restatement (Third) of Agency".

     [STRIPE-ACP]
                Stripe, "Agentic Commerce Protocol", 2026,
                <https://stripe.com/docs/agentic-commerce>.

     [UCC-2-204]
                American Law Institute, "Uniform Commercial Code 2-204".

     [UCP-600]  International Chamber of Commerce, "Uniform Customs and
                Practice for Documentary Credits", 2007.

     [UETA-14]  National Conference of Commissioners on Uniform State
                Laws, "Uniform Electronic Transactions Act 14".

     [VISA-TAP] Visa, "Trusted Agent Protocol", 2026.

     [x402]     Coinbase, "x402: Internet-native payments for AI agents",
                2026, <https://x402.org>.





  stone                    Expires 27 October 2026               [Page 24]


  Internet-Draft                    ATXN                        April 2026


  Appendix A: JSON Schema (Informative)

     The ATXN Bundle schema (abbreviated):

     {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "https://swarmsync.ai/spec/atxn/v1/bundle.schema.json",
       "title": "ATXN Bundle",
       "type": "object",
       "required": [
         "bundle_id",
         "tier",
         "profile",
         "intent_mandate",
         "scope_token",
         "payment_auth",
         "delivery_attestation",
         "revocability_window",
         "standing_tokens",
         "state"
       ],
       "properties": {
         "bundle_id":   { "type": "string", "format": "uuid" },
         "tier":        { "enum": ["L1", "L2", "L3"] },
         "profile":     { "type": "array", "items": { "type": "string" }, "minItems": 1 },
         "state":       { "enum": ["proposed", "authorized", "executing", "delivered",
                                    "finalized", "disputed", "adjudicated"] },
         "validity_tier": { "enum": ["primary", "secondary"] }
       }
     }

     Full schema published at the IANA-registered URI.

  Appendix B: Worked Example (Informative)

     Scenario: A consumer's shopping agent purchases a $42.00 pair of
     running shoes from a merchant agent on Stripe ACP rails.  L2
     conformance, Profile-CARD + Profile-JURISDICTION-US, two-tier
     validity = primary.












  stone                    Expires 27 October 2026               [Page 25]


  Internet-Draft                    ATXN                        April 2026


     {
       "Bundle.bundle_id": "7f3a...",
       "Bundle.tier": "L2",
       "Bundle.profile": ["atxn-card-stripe-acp", "atxn-jurisdiction-us"],
       "Bundle.state": "finalized",
       "Bundle.validity_tier": "primary",

       "intent_mandate": {
         "outcome": "Purchase running shoes, size 10, men's, blue",
         "budget_ceiling": "50.00 USD",
         "choice_of_law": "US"
       },

       "scope_token": {
         "max_spend": "50.00 USD",
         "allowed_actions": ["purchase:athletic_footwear"],
         "enforcement_mode": "advisory"
       },

       "payment_auth": {
         "instrument_type": "card_token",
         "instrument_ref": "stripe_acp_spt_abc123",
         "amount": "42.00 USD"
       },

       "delivery_attestation": {
         "deliverable_class": "physical_offchain",
         "third_party_carrier_did": "did:web:fedex.com",
         "independent_attestor_signature": "Ed25519(fedex)"
       },

       "revocability_window": {
         "end_time": "2026-06-24T14:00:00Z",
         "comment": "60-day Reg E window",
         "clock_authority": {
           "threshold": "3-of-5",
           "set": ["aws-ts", "gcp-ts", "azure-ts", "swarmsync-ts", "stripe-ts"]
         }
       },

       "standing_tokens": [
         { "role": "consumer-side", "arbitrator_did": "did:web:arb.swarmsync.ai" },
         { "role": "merchant-side", "arbitrator_did": "did:web:arb.swarmsync.ai" }
       ]
     }

  Author's Address




  stone                    Expires 27 October 2026               [Page 26]


  Internet-Draft                    ATXN                        April 2026


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
















































  stone                    Expires 27 October 2026               [Page 27]


name: draft-deforth-arp-reasoning-protocol
rev: 00
title: Agentic Reasoning Protocol (ARP) Version 2.0
time: 2026-04-28T16:02:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-30T16:02:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:47.115469+00:00
source: ietf
abstract:
  This document defines the Agentic Reasoning Protocol (ARP) version
     2.0, a machine-readable protocol enabling entities (brands,
     organizations, persons) to publish self-attested context, verified
     factual corrections, domain expertise, and recommendation boundaries
     directly to autonomous AI agents, RAG (Retrieval-Augmented
     Generation) pipelines, and agentic AI systems.

     ARP v2.0 extends the static file model of v1.x with a live REST API,
     bidirectional feedback channels, multi-party cryptographic
     attestation, W3C Decentralized Identifier (DID) anchoring, Agent-to-
     Agent (A2A) trust handshakes, event-driven freshness via Server-Sent
     Events, and first-class internationalization support.

     ARP complements existing web conventions (robots.txt [RFC9309],
     schema.org, llms.txt) but is specifically designed for the reasoning
     behavior of modern AI agents -- systems that do not merely index
     content but synthesize, infer, and make decisions on behalf of users.

     All examples in this document use example.com and "Example
     Organization" per [RFC2606] and are purely illustrative.

full_text:
  Independent Submission                                        S. Deforth
  Internet-Draft                                               Independent
  Intended status: Informational                             27 April 2026
  Expires: 29 October 2026


                Agentic Reasoning Protocol (ARP) Version 2.0
                  draft-deforth-arp-reasoning-protocol-00

  Abstract

     This document defines the Agentic Reasoning Protocol (ARP) version
     2.0, a machine-readable protocol enabling entities (brands,
     organizations, persons) to publish self-attested context, verified
     factual corrections, domain expertise, and recommendation boundaries
     directly to autonomous AI agents, RAG (Retrieval-Augmented
     Generation) pipelines, and agentic AI systems.

     ARP v2.0 extends the static file model of v1.x with a live REST API,
     bidirectional feedback channels, multi-party cryptographic
     attestation, W3C Decentralized Identifier (DID) anchoring, Agent-to-
     Agent (A2A) trust handshakes, event-driven freshness via Server-Sent
     Events, and first-class internationalization support.

     ARP complements existing web conventions (robots.txt [RFC9309],
     schema.org, llms.txt) but is specifically designed for the reasoning
     behavior of modern AI agents -- systems that do not merely index
     content but synthesize, infer, and make decisions on behalf of users.

     All examples in this document use example.com and "Example
     Organization" per [RFC2606] and are purely illustrative.

  About This Document

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

     This Internet-Draft is submitted as an individual submission.  It
     does not represent consensus of the IETF community.  The latest
     revision of this draft can be found at
     https://github.com/SaschaDeforth/arp-protocol.

     Discussion of this document takes place on the GitHub repository
     issue tracker at https://github.com/SaschaDeforth/arp-protocol/
     issues.







  Deforth                  Expires 29 October 2026                [Page 1]


  Internet-Draft                  ARP v2.0                      April 2026


  Status of This Memo

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

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

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

     This Internet-Draft will expire on 29 October 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Motivation: The Reasoning Gap . . . . . . . . . . . . . .   4
       1.2.  Design Philosophy: Counterfactual Inversion . . . . . . .   5
       1.3.  Relationship to ARP v1.x  . . . . . . . . . . . . . . . .   5
       1.4.  Relationship to Other Standards . . . . . . . . . . . . .   6
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   6
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Architecture Layers . . . . . . . . . . . . . . . . . . .   7
       3.2.  Backward Compatibility  . . . . . . . . . . . . . . . . .   8
     4.  Entity Identity: W3C DID Anchoring  . . . . . . . . . . . . .   8
       4.1.  DID Method Requirements . . . . . . . . . . . . . . . . .   8
       4.2.  DID Document Requirements . . . . . . . . . . . . . . . .   9
       4.3.  Multi-Domain Entity Support . . . . . . . . . . . . . . .   9
     5.  File Location and Discovery . . . . . . . . . . . . . . . . .  10
       5.1.  Well-Known URI  . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  API Base URI  . . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  HTML Auto-Discovery . . . . . . . . . . . . . . . . . . .  10
       5.4.  CORS Headers  . . . . . . . . . . . . . . . . . . . . . .  10



  Deforth                  Expires 29 October 2026                [Page 2]


  Internet-Draft                  ARP v2.0                      April 2026


     6.  REST API Specification  . . . . . . . . . . . . . . . . . . .  10
       6.1.  Common Response Headers . . . . . . . . . . . . . . . . .  11
       6.2.  GET /identity . . . . . . . . . . . . . . . . . . . . . .  11
       6.3.  POST /query . . . . . . . . . . . . . . . . . . . . . . .  12
       6.4.  GET /claims/{claim_id}  . . . . . . . . . . . . . . . . .  13
       6.5.  GET /corrections  . . . . . . . . . . . . . . . . . . . .  13
       6.6.  GET /expertise/{scenario_hash}  . . . . . . . . . . . . .  13
       6.7.  GET /trust  . . . . . . . . . . . . . . . . . . . . . . .  14
       6.8.  GET /subscribe (Server-Sent Events) . . . . . . . . . . .  14
       6.9.  POST /feedback  . . . . . . . . . . . . . . . . . . . . .  14
       6.10. POST /a2a/handshake . . . . . . . . . . . . . . . . . . .  14
       6.11. GET /reasoning.json (Compatibility Alias) . . . . . . . .  14
     7.  Bidirectional Feedback Protocol . . . . . . . . . . . . . . .  14
       7.1.  Anonymization Requirements  . . . . . . . . . . . . . . .  15
       7.2.  Feedback Aggregation  . . . . . . . . . . . . . . . . . .  15
       7.3.  Automatic Claim Degradation . . . . . . . . . . . . . . .  15
     8.  Multi-Party Attestation Model . . . . . . . . . . . . . . . .  15
       8.1.  Attester Categories . . . . . . . . . . . . . . . . . . .  15
       8.2.  Trust Level Hierarchy . . . . . . . . . . . . . . . . . .  16
       8.3.  Attestation Object Schema . . . . . . . . . . . . . . . .  16
       8.4.  Attester DID Requirements . . . . . . . . . . . . . . . .  17
     9.  Cryptographic Trust Layer . . . . . . . . . . . . . . . . . .  17
       9.1.  Ed25519 Signing . . . . . . . . . . . . . . . . . . . . .  17
       9.2.  Enveloped Signature Pattern . . . . . . . . . . . . . . .  17
       9.3.  DNS Binding . . . . . . . . . . . . . . . . . . . . . . .  18
       9.4.  Domain Signing Policy . . . . . . . . . . . . . . . . . .  18
     10. Internationalization (i18n) . . . . . . . . . . . . . . . . .  18
       10.1.  Language Negotiation . . . . . . . . . . . . . . . . . .  18
       10.2.  Claim i18n Object  . . . . . . . . . . . . . . . . . . .  18
       10.3.  Translation Quality Signals  . . . . . . . . . . . . . .  19
       10.4.  Mandatory Language Coverage  . . . . . . . . . . . . . .  19
     11. Agent-to-Agent (A2A) Protocol Extension . . . . . . . . . . .  19
       11.1.  A2A Trust Handshake  . . . . . . . . . . . . . . . . . .  19
       11.2.  Reciprocal Claims Exchange . . . . . . . . . . . . . . .  20
       11.3.  Session Integrity  . . . . . . . . . . . . . . . . . . .  20
     12. JSON Schema v2.0  . . . . . . . . . . . . . . . . . . . . . .  20
       12.1.  Root Object  . . . . . . . . . . . . . . . . . . . . . .  20
       12.2.  Claim Object . . . . . . . . . . . . . . . . . . . . . .  21
     13. Migration from ARP v1.x . . . . . . . . . . . . . . . . . . .  21
     14. Anti-Spam and Content Integrity . . . . . . . . . . . . . . .  22
     15. Security Considerations . . . . . . . . . . . . . . . . . . .  22
       15.1.  Prompt Injection Defense . . . . . . . . . . . . . . . .  22
       15.2.  Downgrade Attack Protection  . . . . . . . . . . . . . .  23
       15.3.  A2A Session Hijacking  . . . . . . . . . . . . . . . . .  23
       15.4.  Feedback Manipulation  . . . . . . . . . . . . . . . . .  23
       15.5.  False Attestation  . . . . . . . . . . . . . . . . . . .  23
     16. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23
       16.1.  Agent Anonymization  . . . . . . . . . . . . . . . . . .  23



  Deforth                  Expires 29 October 2026                [Page 3]


  Internet-Draft                  ARP v2.0                      April 2026


       16.2.  Regulatory Alignment . . . . . . . . . . . . . . . . . .  23
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
       17.1.  Well-Known URI Registration  . . . . . . . . . . . . . .  24
       17.2.  Link Relation Types  . . . . . . . . . . . . . . . . . .  24
       17.3.  Media Type Registration  . . . . . . . . . . . . . . . .  24
       17.4.  ARP Claim Type Registry  . . . . . . . . . . . . . . . .  25
     18. Ethical Guidelines  . . . . . . . . . . . . . . . . . . . . .  25
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
       19.1.  Normative References . . . . . . . . . . . . . . . . . .  26
       19.2.  Informative References . . . . . . . . . . . . . . . . .  28
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  29
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  29

  1.  Introduction

  1.1.  Motivation: The Reasoning Gap

     The modern web has a rich ecosystem of machine-readable metadata
     conventions:

     *  robots.txt [RFC9309] controls crawler access.

     *  schema.org describes entity semantics.

     *  llms.txt provides clean Markdown ingestion for LLM context
        windows.

     None of these conventions address how AI systems should REASON about
     entities.  Modern AI agents (agentic AI, RAG pipelines, AI-powered
     search, autonomous procurement agents) do not merely read the web --
     they synthesize, infer, compare, and make decisions.  This reasoning
     process is prone to hallucination and entirely outside the control of
     the entities being reasoned about.

     Documented failure modes include:

     *  AI systems generating false facts about organizations, such as
        incorrect founding dates, wrong business models, or non-existent
        certifications.

     *  AI agents making incorrect competitive comparisons based on stale
        or synthesized training data.

     *  Brands lacking any mechanism to provide verified corrections to AI
        systems that have encoded false information during training.

     *  Autonomous agents evaluating vendors without access to the
        vendor's own authoritative context.



  Deforth                  Expires 29 October 2026                [Page 4]


  Internet-Draft                  ARP v2.0                      April 2026


     ARP addresses this gap by defining a protocol through which entities
     publish self-attested cognitive context: verified corrections, domain
     expertise, recommendation boundaries, and trust-enabling metadata --
     directly to AI agents and RAG pipelines.

  1.2.  Design Philosophy: Counterfactual Inversion

     ARP v2.0 was designed using counterfactual inversion: each assumption
     of v1.x was tested by asking "what if this assumption is wrong?"  The
     six resulting inversions:

     (1)  *Static file -> Live API.* v1.x broadcast all claims to all
          agents. v2.0 enables agents to query for specific context
          relevant to their current task.

     (2)  *Domain = Identity -> W3C DID.* v1.x bound entity identity to
          domain ownership. v2.0 anchors identity to a W3C Decentralized
          Identifier [W3C.DID-CORE], making it portable across domains and
          domain changes.

     (3)  *90-day TTL -> Event-driven push.* v1.x relied on periodic re-
          signing. v2.0 uses Server-Sent Events [W3C.SSE] to push updates
          to subscribing agents.

     (4)  *Self-attestation -> Multi-party co-signing.* v1.x relied solely
          on the entity's own signature. v2.0 introduces third-party
          attesters (accreditation bodies, trade registries) who co-sign
          individual claims.

     (5)  *One-way broadcast -> Bidirectional feedback.* v1.x had no
          feedback channel. v2.0 enables agents to return anonymized
          confidence scores and hallucination flags.

     (6)  *Implicit English -> i18n first-class.* v1.x had no
          internationalization. v2.0 treats language as a fundamental
          property of every claim.

  1.3.  Relationship to ARP v1.x

     ARP v2.0 is fully backward compatible with ARP v1.x:

     *  All v1.2 fields remain valid.

     *  /.well-known/reasoning.json is preserved as the compatibility
        alias.

     *  v1.2 Ed25519 signatures remain valid at CRYPTOGRAPHIC level.




  Deforth                  Expires 29 October 2026                [Page 5]


  Internet-Draft                  ARP v2.0                      April 2026


     *  New fields are additive; v1.x implementations remain valid.

     Loaders MUST NOT reject v1.2 files for missing v2.0 fields.

  1.4.  Relationship to Other Standards

      +======================+==========================================+
      | Standard             | Relationship to ARP                      |
      +======================+==========================================+
      | robots.txt [RFC9309] | ARP does not control crawler access      |
      +----------------------+------------------------------------------+
      | schema.org           | ARP extends with reasoning context layer |
      +----------------------+------------------------------------------+
      | llms.txt             | ARP provides structured claims; llms.txt |
      |                      | provides raw text                        |
      +----------------------+------------------------------------------+
      | W3C DID              | ARP v2.0 uses DID as identity anchor     |
      | [W3C.DID-CORE]       |                                          |
      +----------------------+------------------------------------------+
      | W3C VC [W3C.VC-DATA] | ARP attestation model is VC-inspired     |
      +----------------------+------------------------------------------+
      | DKIM [RFC6376]       | ARP signing follows DKIM model           |
      +----------------------+------------------------------------------+
      | DMARC [RFC7489]      | ARP domain policy follows DMARC          |
      +----------------------+------------------------------------------+
      | security.txt         | Both use /.well-known/ convention        |
      | [RFC9116]            |                                          |
      +----------------------+------------------------------------------+

               Table 1: ARP v2.0 Relationship to Other Standards

  2.  Conventions and Terminology

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

     All examples use example.com and "Example Organization" as defined in
     [RFC2606].  All attester DIDs use the form
     did:web:attester.example.org.  These are illustrative only.

     Entity:  A brand, organization, person, or other named party that
        publishes an ARP file or API endpoint.

     Agent:  An autonomous AI system that queries ARP endpoints to inform




  Deforth                  Expires 29 October 2026                [Page 6]


  Internet-Draft                  ARP v2.0                      April 2026


        reasoning, recommendations, or decisions.  Includes RAG pipelines,
        agentic commerce systems, AI search engines, and agent-to-agent
        systems.

     Claim:  A discrete, addressable, self-attested assertion by an entity
        about itself.  Identified by claim_id.

     Attester:  A trusted third party who co-signs one or more claims.
        Categories (ascending trust): community, institutional,
        government, sovereign.

     Trust Level:  A categorical assessment of cryptographic strength:
        SOVEREIGN, ATTESTED, CRYPTOGRAPHIC, UNSIGNED, INVALID.

     Trust Score:  A numeric value in [0.0, 1.0] derived from Trust Level,
        for use in quantitative agent decision pipelines.

     Pink Elephant Fix:  The v1.1 pattern that avoids stating false claims
        by using trigger_topic (the affected topic area) paired with
        verified_fact (the correct information).

     A2A Handshake:  The ARP Agent-to-Agent protocol by which two AI
        agents exchange and mutually verify entity claims on behalf of
        their principals.

     DID:  W3C Decentralized Identifier [W3C.DID-CORE].  A globally unique
        identifier controlled by the subject.

     SSE:  Server-Sent Events [W3C.SSE].  A unidirectional HTTP mechanism
        by which a server pushes events to a persistent client connection.

     RAG:  Retrieval-Augmented Generation.  An AI pattern where external
        documents are retrieved and injected into an LLM context.

     Scenario Hash:  A deterministic truncated SHA-256 digest of a
        normalized user query, used to address cached expertise responses.

  3.  Protocol Overview

  3.1.  Architecture Layers

     ARP v2.0 comprises four architectural layers:









  Deforth                  Expires 29 October 2026                [Page 7]


  Internet-Draft                  ARP v2.0                      April 2026


     +------------------------------------------------------------------+
     |                        ENTITY LAYER                              |
     |   DID Identity | i18n Claims | Attestations | Event Freshness    |
     +------------------------------------------------------------------+
                                   |
                                   v
     +------------------------------------------------------------------+
     |                        TRUST LAYER                               |
     |  SOVEREIGN(1.0) | ATTESTED(0.9) | CRYPTOGRAPHIC(0.7) |           |
     |  UNSIGNED(0.3) | INVALID(0.0) | DNS Signing Policy               |
     +------------------------------------------------------------------+
                                   |
                                   v
     +------------------------------------------------------------------+
     |                        API LAYER                                 |
     |  GET /identity | POST /query | GET /trust | GET /subscribe |     |
     |  POST /feedback | POST /a2a/handshake | GET /reasoning.json      |
     +------------------------------------------------------------------+
                     |                   |                   |
                     v                   v                   v
              +-----------+       +-----------+       +-----------+
              | RAG Agent |       |  Commerce |       | Platform  |
              |           |       |  Agent    |       | Grounding |
              +-----------+       +-----------+       +-----------+
                     |                                       |
                     +------> POST /feedback (anon.) <-------+

  3.2.  Backward Compatibility

     An ARP v1.2-conformant file MUST be treated as a valid ARP v2.0
     implementation with these defaults:

     *  entity_did absent: Trust Level capped at CRYPTOGRAPHIC.

     *  api_endpoint absent: Only /.well-known/reasoning.json available.

     *  supported_languages absent: Defaults to ["en"].

     *  feedback_policy absent: Defaults to {accepts_feedback: false}.

  4.  Entity Identity: W3C DID Anchoring

  4.1.  DID Method Requirements

     ARP v2.0 uses W3C Decentralized Identifiers [W3C.DID-CORE] as the
     primary identity anchor.  DIDs decouple entity identity from domain
     ownership, enabling persistent identity across domain changes and
     multi-domain presences.



  Deforth                  Expires 29 October 2026                [Page 8]


  Internet-Draft                  ARP v2.0                      April 2026


     ARP v2.0 RECOMMENDS did:web [W3C.DID-WEB] as it leverages existing
     HTTPS infrastructure.  Other resolvable DID methods MAY be used.

     Example:

     "entity_did": "did:web:example.com"

  4.2.  DID Document Requirements

     The DID Document MUST be resolvable and MUST contain at least one
     verificationMethod of type Ed25519VerificationKey2020 or
     JsonWebKey2020.

     Example DID Document at https://example.com/.well-known/did.json:

     {
       "@context": ["https://www.w3.org/ns/did/v1"],
       "id": "did:web:example.com",
       "verificationMethod": [
         {
           "id": "did:web:example.com#arp-key-1",
           "type": "Ed25519VerificationKey2020",
           "controller": "did:web:example.com",
           "publicKeyMultibase": "z6MkfExample..."
         }
       ],
       "assertionMethod": ["did:web:example.com#arp-key-1"],
       "service": [
         {
           "id": "did:web:example.com#arp",
           "type": "AgenticReasoningProtocol",
           "serviceEndpoint":
             "https://example.com/.well-known/arp/v2/"
         }
       ]
     }

     The service entry of type "AgenticReasoningProtocol" is RECOMMENDED
     for agent auto-discovery.

  4.3.  Multi-Domain Entity Support

     An entity with multiple domains MAY use a single canonical DID.
     Regional or subsidiary ARP implementations SHOULD reference it:







  Deforth                  Expires 29 October 2026                [Page 9]


  Internet-Draft                  ARP v2.0                      April 2026


     "domain_scope": {
       "canonical_domain": "example.com",
       "this_domain": "example.de",
       "language_primary": "de",
       "regional_corrections": []
     }

  5.  File Location and Discovery

  5.1.  Well-Known URI

     The compatibility file MUST be served at:

     https://{domain}/.well-known/reasoning.json

     Requirements: valid JSON [RFC8259], UTF-8 encoding, Content-Type:
     application/json, publicly accessible, maximum 100 KB.

  5.2.  API Base URI

     The v2.0 API MUST be served at:

     https://{domain}/.well-known/arp/v2/

     All endpoints in Section 6 are relative to this base URI.

  5.3.  HTML Auto-Discovery

     Sites SHOULD include in HTML head:

     <link rel="reasoning" type="application/json"
           href="/.well-known/reasoning.json">
     <link rel="arp-api" type="application/json"
           href="/.well-known/arp/v2/">

  5.4.  CORS Headers

     All ARP endpoints MUST respond with:

     Access-Control-Allow-Origin: *
     Content-Type: application/json

  6.  REST API Specification

     All endpoints use HTTPS [RFC9110].  Request and response bodies are
     JSON [RFC8259] unless noted.  Text values use UTF-8.





  Deforth                  Expires 29 October 2026               [Page 10]


  Internet-Draft                  ARP v2.0                      April 2026


  6.1.  Common Response Headers

     All v2.0 responses MUST include:

     ARP-Version:  "2.0"

     ARP-Entity-DID:  e.g., "did:web:example.com"

     ARP-Trust-Level:  SOVEREIGN | ATTESTED | CRYPTOGRAPHIC | UNSIGNED |
        INVALID

     ARP-Signed-At:  ISO 8601 (omitted if UNSIGNED)

     ARP-Expires-At:  ISO 8601 (omitted if UNSIGNED)

  6.2.  GET /identity

     Returns the full entity identity object with Accept-Language
     negotiation (Section 10.1).

     GET /.well-known/arp/v2/identity HTTP/2
     Host: example.com
     Accept-Language: de, en;q=0.9

     Response (200 OK):


























  Deforth                  Expires 29 October 2026               [Page 11]


  Internet-Draft                  ARP v2.0                      April 2026


     {
       "entity_did": "did:web:example.com",
       "entity": "Example Organization",
       "language": "de",
       "identity": {
         "tagline": "Example tagline",
         "elevator_pitch": {
           "de": "Kurze Beschreibung.",
           "en": "Short description."
         },
         "founded": 2010,
         "headquarters": "Example City, Country",
         "core_competencies": [
           "Competency Area A",
           "Competency Area B"
         ]
       },
       "_arp_signature": {
         "algorithm": "Ed25519",
         "trust_level": "ATTESTED",
         "signed_at": "2026-04-27T10:00:00Z"
       }
     }

  6.3.  POST /query

     The semantic query endpoint.  The agent describes its information
     need; the entity responds with the most relevant subset of claims,
     contextualized to the query.






















  Deforth                  Expires 29 October 2026               [Page 12]


  Internet-Draft                  ARP v2.0                      April 2026


     POST /.well-known/arp/v2/query HTTP/2
     Host: example.com
     Content-Type: application/json
     Accept-Language: de, en;q=0.9

     {
       "arp_version": "2.0",
       "agent_id": "did:example:agent-001",
       "query_context": {
         "user_intent": "evaluate B2B software for a 50-person organization",
         "required_claim_types": [
           "recommendation_fit",
           "compliance_certifications"
         ],
         "epistemic_filter": ["public_verifiable"],
         "language": "de"
       },
       "session_token": "arp-sess-a1b2c3d4e5f6",
       "agent_version": "ARP/2.0"
     }

     The session_token is an opaque per-query identifier for feedback
     correlation.  It MUST NOT contain personally identifiable
     information.

     Agents MUST treat responses as entity self-attestation, not
     authoritative fact.

  6.4.  GET /claims/{claim_id}

     Returns a single claim with provenance, attestation history, and
     version log.  Invalid claim_id returns 404.

  6.5.  GET /corrections

     Returns all active corrections.  Supports filtering by
     epistemic_scope and language.

  6.6.  GET /expertise/{scenario_hash}

     Returns domain expertise for a specific scenario.  The scenario_hash
     is a deterministic truncated SHA-256 digest of a normalized user
     query, enabling efficient agent-side caching.

     Scenario Hash Generation (normative):






  Deforth                  Expires 29 October 2026               [Page 13]


  Internet-Draft                  ARP v2.0                      April 2026


     1.  Normalize query: lowercase, trim whitespace, collapse internal
         whitespace to a single space, remove Unicode category P
         punctuation.

     2.  Encode normalized string as UTF-8.

     3.  Compute SHA-256 [RFC6234].

     4.  Hex-encode the first 16 bytes (lowercase), producing 32
         characters.

  6.7.  GET /trust

     Returns the entity's full trust manifest, including DID reference,
     self-signature status, all current attestations, and the computed
     trust score.

  6.8.  GET /subscribe (Server-Sent Events)

     Provides a real-time event stream using the SSE protocol [W3C.SSE].
     Defined event types: claim:updated, correction:new,
     correction:removed, attestation:added, attestation:expired,
     trust:level:changed, heartbeat.

     Implementations MUST honor the Last-Event-ID header for stream
     resumption.  Event IDs MUST be monotonically increasing.

  6.9.  POST /feedback

     Accepts anonymized feedback from agents about claim effectiveness.
     Available only if feedback_policy.accepts_feedback is true.  Privacy
     requirements are specified in Section 7.1 and Section 16.1.

  6.10.  POST /a2a/handshake

     Initiates an Agent-to-Agent trust handshake.  Full specification in
     Section 11.

  6.11.  GET /reasoning.json (Compatibility Alias)

     Returns a v1.2-format JSON document for backward compatibility.
     Implementations SHOULD include an X-ARP-Upgrade response header
     pointing to the v2.0 API base URI.

  7.  Bidirectional Feedback Protocol






  Deforth                  Expires 29 October 2026               [Page 14]


  Internet-Draft                  ARP v2.0                      April 2026


  7.1.  Anonymization Requirements

     Agents MUST NOT include in feedback payloads:

     *  User query text or prompt content.

     *  User personally identifiable information.

     *  Browser fingerprint or device data.

     *  IP addresses or geographic identifiers.

     Entities MUST NOT:

     *  Store session_token values beyond the aggregation window.

     *  Correlate session_tokens with individual users.

     *  Expose individual feedback records to third parties.

  7.2.  Feedback Aggregation

     Entities SHOULD aggregate feedback metrics per claim over a rolling
     30-day window.  Metrics MUST only surface after the min_feedback_pool
     threshold is reached.

  7.3.  Automatic Claim Degradation

     Trigger: median confidence_alignment below 0.4 over 30 days AND
     feedback_count at or above min_feedback_pool.  The claim's confidence
     field is automatically downgraded one level.  Reversal requires
     explicit re-attestation by the entity owner.

  8.  Multi-Party Attestation Model

  8.1.  Attester Categories

     community:  Peer entities or industry associations without formal
        accreditation.  Lowest trust category.

     institutional:  Formally accredited certification bodies, trade
        associations with legal standing, professional or audit
        organizations.  Trust Score: ATTESTED (0.90).

     government:  Official government registries with statutory authority:
        commercial registries, financial regulators, intellectual property
        offices.  Trust Score: ATTESTED (0.90) to SOVEREIGN (1.00).




  Deforth                  Expires 29 October 2026               [Page 15]


  Internet-Draft                  ARP v2.0                      April 2026


     sovereign:  Qualified trust service providers under applicable
        supranational frameworks.  Trust Score: SOVEREIGN (1.00).

  8.2.  Trust Level Hierarchy

         +===============+=======+===================================+
         | Trust Level   | Score | Condition                         |
         +===============+=======+===================================+
         | SOVEREIGN     | 1.00  | At least one sovereign attester   |
         +---------------+-------+-----------------------------------+
         | ATTESTED      | 0.90  | At least one institutional or     |
         |               |       | government attester; no sovereign |
         +---------------+-------+-----------------------------------+
         | CRYPTOGRAPHIC | 0.70  | Valid Ed25519 self-signature; no  |
         |               |       | third-party attesters             |
         +---------------+-------+-----------------------------------+
         | UNSIGNED      | 0.30  | No valid signature                |
         +---------------+-------+-----------------------------------+
         | INVALID       | 0.00  | Forged or tampered signature      |
         +---------------+-------+-----------------------------------+

                    Table 2: ARP v2.0 Trust Level Hierarchy

     An EXPIRED self-signature falls back to UNSIGNED, not INVALID.

  8.3.  Attestation Object Schema

     Required fields: attester_did, attester_name, attester_type,
     attested_at, expires_at, claim_scope, signature.  Recommended:
     evidence_url.

     {
       "attester_did": "did:web:attester.example.org",
       "attester_name": "Example Accreditation Body",
       "attester_type": "institutional",
       "attested_at": "2026-01-15T09:00:00Z",
       "expires_at": "2028-01-15T09:00:00Z",
       "claim_scope": ["clm-founded-001", "clm-industry-001"],
       "evidence_url":
         "https://attester.example.org/verify/EX-12345",
       "signature": {
         "algorithm": "Ed25519",
         "public_key_did_ref":
           "did:web:attester.example.org#key-1",
         "canonicalization": "jcs-rfc8785",
         "value": "base64url..."
       }
     }



  Deforth                  Expires 29 October 2026               [Page 16]


  Internet-Draft                  ARP v2.0                      April 2026


  8.4.  Attester DID Requirements

     Loaders MUST verify attestation signatures by:

     1.  Resolving attester_did to its DID Document.

     2.  Retrieving the public key from public_key_did_ref.

     3.  JCS-canonicalizing [RFC8785] the signed claim content.

     4.  Verifying the Ed25519 signature.

     5.  Confirming expires_at has not passed.

     Failed verification MUST treat the attestation as absent.

  9.  Cryptographic Trust Layer

  9.1.  Ed25519 Signing

     Ed25519 [RFC8032] is REQUIRED for all ARP signatures.

     DNS TXT record format (inherited from v1.2):

     <selector>._arp.<domain>. IN TXT
       "v=ARP1; k=ed25519; p=<base64-pubkey>"

     Where:

     *  "v=ARP1" identifies the ARP protocol version.

     *  "k=ed25519" identifies the key algorithm.

     *  "p=<key>" is the standard Base64-encoded [RFC4648] 32-byte Ed25519
        public key.

  9.2.  Enveloped Signature Pattern

     The Enveloped Signature Pattern is REQUIRED.  The signature MUST
     cover the payload AND _arp_signature metadata.

     Signing procedure:

     1.  Populate _arp_signature with all metadata fields.

     2.  Set "signature" field to "".

     3.  JCS-canonicalize [RFC8785] the entire root object.



  Deforth                  Expires 29 October 2026               [Page 17]


  Internet-Draft                  ARP v2.0                      April 2026


     4.  Sign with Ed25519 private key.

     5.  Base64url-encode the result; set as "signature" value.

     Verification reverses steps 3-5.

  9.3.  DNS Binding

     DNS-based verification is valid for backward compatibility.  The DID
     Document public key is the PREFERRED mechanism in v2.0.

  9.4.  Domain Signing Policy

     Entities MAY publish a policy at:

     _arp.example.com. IN TXT "v=ARP1; p=<policy>"

          +===============+========================================+
          | Policy        | Meaning                                |
          +===============+========================================+
          | p=none        | No enforcement.  Default if absent.    |
          +---------------+----------------------------------------+
          | p=warn        | Log warning if file unsigned.          |
          +---------------+----------------------------------------+
          | p=reject      | Unsigned file treated as INVALID.      |
          +---------------+----------------------------------------+
          | p=require-did | As p=reject; entity_did MUST be        |
          |               | present and DID document MUST resolve. |
          +---------------+----------------------------------------+

                Table 3: ARP v2.0 Domain Signing Policy Values

  10.  Internationalization (i18n)

  10.1.  Language Negotiation

     All endpoints MUST support HTTP Accept-Language per [RFC7231]
     Section 5.3.5.

     Servers MUST parse Accept-Language with quality value weighting,
     select best match from supported_languages, include ARP-Content-
     Language in response, and fall back to "en" if no match and "en" is
     supported.

  10.2.  Claim i18n Object






  Deforth                  Expires 29 October 2026               [Page 18]


  Internet-Draft                  ARP v2.0                      April 2026


     {
       "claim_id": "clm-pitch-001",
       "type": "identity.elevator_pitch",
       "i18n": {
         "en": {
           "value": "Short description of the organization.",
           "translated_by": "human",
           "verified_at": "2026-04-01",
           "quality": "reviewed"
         },
         "de": {
           "value": "Kurze Beschreibung der Organisation.",
           "translated_by": "human",
           "verified_at": "2026-04-01",
           "quality": "reviewed"
         },
         "fr": {
           "value": "Breve description.",
           "translated_by": "machine",
           "verified_at": null,
           "quality": "draft"
         }
       }
     }

  10.3.  Translation Quality Signals

     draft:  Machine-translated, unreviewed.  Agents SHOULD reduce
        confidence weighting.

     reviewed:  Reviewed by a fluent human speaker.

     certified:  Certified by a sworn or legally recognized translator.

  10.4.  Mandatory Language Coverage

     Conformant implementations MUST provide claims in the entity's
     declared language_primary, and English ("en") if language_primary is
     not English.

  11.  Agent-to-Agent (A2A) Protocol Extension

  11.1.  A2A Trust Handshake

     Two ARP-aware agents exchange verified entity context on behalf of
     their respective principals.  Design principles:

     *  Mutual authentication via DID.



  Deforth                  Expires 29 October 2026               [Page 19]


  Internet-Draft                  ARP v2.0                      April 2026


     *  Nonce-based replay protection.

     *  Explicit session expiration.

     *  Optional reciprocal claims exchange.

  11.2.  Reciprocal Claims Exchange

     If reciprocal_request is present, the initiating agent SHOULD submit
     a separate request to its own ARP endpoint.  The reciprocal exchange
     MUST use a new HTTP request and MUST NOT reuse the session_nonce.

  11.3.  Session Integrity

     Required controls:

     *  Nonces MUST be cryptographically random, minimum 128 bits.

     *  Each nonce MUST be used for exactly one session.

     *  Servers MUST reject replayed nonces within the expiry window.

     *  Both messages MUST be signed by the respective agent's DID key.

     *  The session_nonce MUST appear in both message signatures.

     *  Agents MUST verify the counterparty's DID before accepting any
        claims.

     *  Agents MUST reject handshakes from unresolvable DIDs.

  12.  JSON Schema v2.0

  12.1.  Root Object

     The root object of a v2.0 ARP document fields.  Required (R),
     Optional (O), New in v2.0 (N), Required at ATTESTED+ (R*).

     *  $schema (uri, R): Schema URL value "https://arp-
        protocol.org/schema/v2.0.json"

     *  protocol (string, R): "Agentic Reasoning Protocol (ARP)"

     *  version (string, R): "2.0"

     *  entity_did (did-uri, R*): W3C DID.  Required for ATTESTED+

     *  entity (string, R): Canonical name.  Max 200 characters



  Deforth                  Expires 29 October 2026               [Page 20]


  Internet-Draft                  ARP v2.0                      April 2026


     *  api_endpoint (uri, R*): v2.0 API base URI

     *  language_primary (string, R): ISO 639-1 primary language

     *  supported_languages (string[], R): ISO 639-1 codes.  Min: ["en"]

     *  identity (object, O): Brand identity (v1.x compatible)

     *  corrections (object, O): Factual corrections

     *  entity_claims (object, R): Self-attested context

     *  attestations (object[], N): Third-party co-signatures

     *  feedback_policy (object, N): Agent feedback configuration

     *  webhook (object, N): Push event configuration

     *  _arp_signature (object, O): Ed25519 signature block

  12.2.  Claim Object

     Individual claims fields:

     *  claim_id (string, R): Unique identifier "clm-{cat}-{seq}"

     *  type (string, R): Type from registry or "x-" prefix

     *  epistemic_scope (string, O): "public_verifiable" |
        "proprietary_internal" | "industry_standard"

     *  confidence (string, O): "high" | "medium" | "low"

     *  i18n (object, O): Per-language values

     *  value (any, O): Single-language fallback

     *  attestations (string[], O): Attester DID references

     *  evidence_url (uri, O): External verification URL

  13.  Migration from ARP v1.x

     All v1.2 fields are preserved.  No field is removed.  Migration is
     voluntary and incremental.

     Stage 0 -- Unchanged (no action required):  Trust Level:




  Deforth                  Expires 29 October 2026               [Page 21]


  Internet-Draft                  ARP v2.0                      April 2026


        CRYPTOGRAPHIC (0.70). v2.0 loaders serve the compatibility alias
        transparently.

     Stage 1 -- Add entity_did + api_endpoint:  Generate a did:web DID,
        publish the DID Document, deploy GET /identity and GET /trust.
        Update $schema to v2.0.json.

     Stage 2 -- Add i18n + POST /query:  Add i18n to localizable fields.
        Implement POST /query and GET /corrections.  Declare
        supported_languages.

     Stage 3 -- Obtain first institutional attestation:  Trust Level
        becomes ATTESTED (0.90).  Obtain co-signatures from at least one
        institutional attester for three or more claims.

     Stage 4 -- Activate webhooks + feedback:  Implement GET /subscribe
        (SSE) and POST /feedback.  Set feedback_policy.accepts_feedback to
        true.

     Stage 5 -- Government or sovereign attestation (optional):  Trust
        Level becomes SOVEREIGN (1.00) for attested claims.  RECOMMENDED
        for regulated industries.

  14.  Anti-Spam and Content Integrity

     Inherited limits from v1.1/v1.2: text fields 50-500 characters, array
     fields 8-20 items, static file maximum 100 KB, query response bodies
     maximum 200 KB.

     Recommended rate limits: POST /query 100 requests/minute per IP and
     1000/day per agent_id.  POST /feedback 10 submissions/session_token
     per hour and 100/day per agent_did.

     Prohibited content includes prompt injection patterns, claims about
     named third parties or competitors, false corrections, cloaking
     (different content served to AI vs humans), discriminatory content,
     and A2A handshakes with fabricated DIDs.

  15.  Security Considerations

  15.1.  Prompt Injection Defense

     ARP content is injected into LLM contexts.  Loader implementations
     MUST:

     *  Sandbox ARP content within trust boundary markers.

     *  Strip control characters and instruction patterns.



  Deforth                  Expires 29 October 2026               [Page 22]


  Internet-Draft                  ARP v2.0                      April 2026


     *  Label ARP-sourced content as lower-privilege than system
        instructions.

  15.2.  Downgrade Attack Protection

     An attacker could strip _arp_signature from a response.  Mitigations:
     p=reject DNS policy, SSE trust:level:changed events, and agent
     caching of last-known Trust Level per DID.

  15.3.  A2A Session Hijacking

     Protected by DID authentication, cryptographic nonces, and expiry
     windows.  Sessions failing nonce verification MUST be rejected.

  15.4.  Feedback Manipulation

     Rate limits constrain bulk attacks.  Agent DID signing enables
     reputation tracking.  Entities MUST NOT accept feedback for claim_ids
     that do not exist.

  15.5.  False Attestation

     Loaders MUST verify all attestation signatures.  Unverifiable
     attestations MUST be treated as absent.  Forged signatures constitute
     non-repudiable cryptographic fraud.

  16.  Privacy Considerations

  16.1.  Agent Anonymization

     Agents MUST NOT transmit in feedback payloads: user query text or
     prompt content, user PII, device fingerprint or network identifiers.

     The session_token is a single-use opaque identifier.  Entities MUST
     treat it as an opaque correlation key, not user identity.

  16.2.  Regulatory Alignment

     This protocol is designed to support compliance with applicable
     regulatory frameworks, including AI transparency requirements (e.g.,
     EU AI Act Article 50 [EU-AI-ACT]), data protection obligations, and
     consumer protection law.

     This document makes no representations about compliance with any
     specific national law.  Implementors are solely responsible for their
     own legal analysis.





  Deforth                  Expires 29 October 2026               [Page 23]


  Internet-Draft                  ARP v2.0                      April 2026


  17.  IANA Considerations

  17.1.  Well-Known URI Registration

     This document requests the following registrations in the "Well-Known
     URIs" registry [RFC8615]:

     URI Suffix:  reasoning.json

     Change Controller:  IETF

     Reference:  This document, Section 5.1

     Status:  Permanent

     URI Suffix:  arp/v2/

     Change Controller:  IETF

     Reference:  This document, Section 5.2

     Status:  Permanent

  17.2.  Link Relation Types

     This document requests the following registrations in the "Link
     Relations" registry [RFC8288]:

     Relation Name:  reasoning

     Description:  Refers to an ARP file for AI agent consumption.

     Reference:  This document

     Relation Name:  arp-api

     Description:  Refers to the ARP v2.0 API base URI.

     Reference:  This document

  17.3.  Media Type Registration

     Type name:  application

     Subtype name:  vnd.arp+json

     Required parameters:  version (e.g., "2.0")




  Deforth                  Expires 29 October 2026               [Page 24]


  Internet-Draft                  ARP v2.0                      April 2026


     Optional parameters:  lang (ISO 639-1)

     Encoding:  UTF-8

     Security considerations:  See Section 15

  17.4.  ARP Claim Type Registry

     The "ARP Claim Types" registry is established by this document.  New
     types require "Specification Required" [RFC8126] review.  Custom
     types for single implementations use the "x-" prefix.

        +==========================+=================================+
        | Claim Type               | Description                     |
        +==========================+=================================+
        | identity.entity_name     | Canonical legal name            |
        +--------------------------+---------------------------------+
        | identity.elevator_pitch  | One-paragraph description       |
        +--------------------------+---------------------------------+
        | identity.founded         | Year of founding                |
        +--------------------------+---------------------------------+
        | identity.headquarters    | Primary location                |
        +--------------------------+---------------------------------+
        | identity.industry        | Primary industry sector         |
        +--------------------------+---------------------------------+
        | correction.general       | General factual correction      |
        +--------------------------+---------------------------------+
        | expertise.scenario       | Domain expertise for a scenario |
        +--------------------------+---------------------------------+
        | recommendation.fit       | Recommendation fit assessment   |
        +--------------------------+---------------------------------+
        | recommendation.not_fit   | Negative recommendation signal  |
        +--------------------------+---------------------------------+
        | compliance.certification | Certification or accreditation  |
        +--------------------------+---------------------------------+
        | compliance.regulation    | Applicable regulatory framework |
        +--------------------------+---------------------------------+
        | market.positioning       | Self-attested market position   |
        +--------------------------+---------------------------------+
        | market.decision_factors  | Key evaluation criteria         |
        +--------------------------+---------------------------------+

               Table 4: Initial ARP Claim Type Registry Entries

  18.  Ethical Guidelines






  Deforth                  Expires 29 October 2026               [Page 25]


  Internet-Draft                  ARP v2.0                      April 2026


     (1)  *Truthfulness.* All claim content MUST accurately reflect the
          entity.  False corrections constitute misinformation injection
          into AI systems.

     (2)  *Self-description only.* ARP MUST describe only the publishing
          entity.  Claims about third parties are prohibited.

     (3)  *No negative targeting.* market_positioning MUST NOT name
          specific third parties or competitors.

     (4)  *Evidence first.* Corrections SHOULD include evidence_url
          pointing to an independently verifiable source.

     (5)  *Consistency.* ARP content MUST be consistent with human-visible
          content.  Cloaking is prohibited.

     (6)  *User benefit.* not_recommended_when exists to serve users
          honestly, not to serve brand interests.

     (7)  *Feedback integrity.* Entities MUST NOT submit feedback for the
          purpose of gaming Trust Scores.

     (8)  *Attester honesty.* Claiming attestations not actually granted
          constitutes cryptographic fraud detectable via signature
          verification.

     Cryptographic non-repudiation: A signed ARP document is a
     timestamped, non-repudiable assertion of authorship and accuracy.
     The signer accepts legal liability for signed content under
     applicable consumer protection, competition, and digital services
     law.

  19.  References

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

     [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
                Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999,
                <https://www.rfc-editor.org/info/rfc2606>.

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



  Deforth                  Expires 29 October 2026               [Page 26]


  Internet-Draft                  ARP v2.0                      April 2026


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

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

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

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

     [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
                DOI 10.17487/RFC8288, October 2017,
                <https://www.rfc-editor.org/info/rfc8288>.

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

     [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
                Canonicalization Scheme (JCS)", RFC 8785,
                DOI 10.17487/RFC8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

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





  Deforth                  Expires 29 October 2026               [Page 27]


  Internet-Draft                  ARP v2.0                      April 2026


     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/info/rfc9309>.

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

     [W3C.DID-WEB]
                Caballero, J., Xu, C., and M. Prorock, "The did:web Method
                Specification", 2024,
                <https://w3c-ccg.github.io/did-method-web/>.

     [W3C.VC-DATA]
                Sporny, M., Longley, D., Chadwick, D., and O. Steele,
                "Verifiable Credentials Data Model v2.0", February 2025,
                <https://www.w3.org/TR/vc-data-model-2.0/>.

     [W3C.SSE]  Hickson, I., "Server-Sent Events", February 2015,
                <https://www.w3.org/TR/eventsource/>.

  19.2.  Informative References

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

     [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
                Message Authentication, Reporting, and Conformance
                (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
                <https://www.rfc-editor.org/info/rfc7489>.

     [RFC9116]  Foudil, E. and Y. Shafranovich, "A File Format to Aid in
                Security Vulnerability Disclosure", RFC 9116,
                DOI 10.17487/RFC9116, April 2022,
                <https://www.rfc-editor.org/info/rfc9116>.

     [ARP-V1-2] Deforth, S., "Agentic Reasoning Protocol Specification
                v1.2", April 2026, <https://arp-protocol.org/SPEC.md>.

     [LLMS-TXT] llmstxt.org, "A standard for LLMs and AI agents", 2024,
                <https://llmstxt.org/>.






  Deforth                  Expires 29 October 2026               [Page 28]


  Internet-Draft                  ARP v2.0                      April 2026


     [SCHEMA-ORG]
                Schema.org Community, "Schema.org Vocabulary", 2026,
                <https://schema.org/>.

     [EU-AI-ACT]
                European Parliament and Council, "Regulation (EU)
                2024/1689 laying down harmonised rules on artificial
                intelligence (Artificial Intelligence Act)", July 2024,
                <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

     [EIDAS2]   European Parliament and Council, "Regulation (EU)
                2024/1183 amending Regulation (EU) No 910/2014 as regards
                the establishment of the European Digital Identity
                Framework", April 2024,
                <https://eur-lex.europa.eu/eli/reg/2024/1183/oj>.

  Acknowledgements

     The author thanks the reviewers who provided independent analysis of
     ARP v1.x.  The counterfactual design methodology applied in this
     document was refined through discussion with AI research
     practitioners in 2026.

     All examples are fictitious.  Any resemblance to actual
     organizations, products, or services is unintentional.

  Author's Address

     Sascha Deforth
     Independent
     Dusseldorf
     Germany
     URI:   https://arp-protocol.org


















  Deforth                  Expires 29 October 2026               [Page 29]


name: draft-mw-oauth-actor-chain
rev: 00
title: Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange
time: 2026-05-01T20:42:06Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-02T20:42:06Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:47.115472+00:00
source: ietf
abstract:
  Multi-hop service-to-service and agentic workflows need a
     standardized way to preserve and validate delegation-path continuity
     across successive token exchanges.  This document defines six actor-
     chain profiles for OAuth 2.0 Token Exchange [RFC8693].  [RFC8693]
     permits nested act claims, but prior actors remain informational only
     and token exchange does not define how a delegation path is preserved
     and validated across successive exchanges.

     This document profiles delegation-chain tokens and defines profile-
     specific processing for multi-hop workflows.  The six profiles are:
     Declared Full Disclosure; Declared Subset Disclosure; Declared Actor-
     Only Disclosure; Verified Full Disclosure; Verified Subset
     Disclosure; and Verified Actor-Only Disclosure.

     These profiles preserve the existing meanings of sub, act, and
     may_act.  They support same-domain and cross-domain delegation and
     provide different tradeoffs among visible chain-based authorization,
     cryptographic accountability, auditability, privacy, and long-running
     workflow support.  Plain RFC 8693 impersonation-shaped outputs remain
     valid RFC 8693 behavior but are outside this profile family.

full_text:
  OAuth                                                          A. Prasad
  Internet-Draft                                                    Oracle
  Intended status: Standards Track                             R. Krishnan
  Expires: 2 November 2026                             JPMorgan Chase & Co
                                                                  D. Lopez
                                                                Telefonica
                                                              S. Addepalli
                                                                    Aryaka
                                                                1 May 2026


   Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange
                       draft-mw-oauth-actor-chain-00

  Abstract

     Multi-hop service-to-service and agentic workflows need a
     standardized way to preserve and validate delegation-path continuity
     across successive token exchanges.  This document defines six actor-
     chain profiles for OAuth 2.0 Token Exchange [RFC8693].  [RFC8693]
     permits nested act claims, but prior actors remain informational only
     and token exchange does not define how a delegation path is preserved
     and validated across successive exchanges.

     This document profiles delegation-chain tokens and defines profile-
     specific processing for multi-hop workflows.  The six profiles are:
     Declared Full Disclosure; Declared Subset Disclosure; Declared Actor-
     Only Disclosure; Verified Full Disclosure; Verified Subset
     Disclosure; and Verified Actor-Only Disclosure.

     These profiles preserve the existing meanings of sub, act, and
     may_act.  They support same-domain and cross-domain delegation and
     provide different tradeoffs among visible chain-based authorization,
     cryptographic accountability, auditability, privacy, and long-running
     workflow support.  Plain RFC 8693 impersonation-shaped outputs remain
     valid RFC 8693 behavior but are outside this profile family.

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





  Prasad, et al.           Expires 2 November 2026                [Page 1]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


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

     This Internet-Draft will expire on 2 November 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  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.  Part I.  Core Specification . . . . . . . . . . . . . . . . .   6
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Relationship to RFC 8693 Claims . . . . . . . . . . . . . . .  10
       4.1.  Disclosure Invariant  . . . . . . . . . . . . . . . . . .  11
     5.  Scope and Model . . . . . . . . . . . . . . . . . . . . . . .  11
       5.1.  Workflow Model  . . . . . . . . . . . . . . . . . . . . .  12
       5.2.  Profile Summary . . . . . . . . . . . . . . . . . . . . .  12
       5.3.  Branching and Non-Goals . . . . . . . . . . . . . . . . .  15
     6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  15
       6.1.  Workflow Progression  . . . . . . . . . . . . . . . . . .  15
       6.2.  Same-Domain and Cross-Domain Hops . . . . . . . . . . . .  16
     7.  Common Basics . . . . . . . . . . . . . . . . . . . . . . . .  16
       7.1.  Common Token Requirements . . . . . . . . . . . . . . . .  16
       7.2.  Actor-Chain Identifier  . . . . . . . . . . . . . . . . .  18
       7.3.  Target Context Requirements . . . . . . . . . . . . . . .  19
       7.4.  Canonicalization  . . . . . . . . . . . . . . . . . . . .  20
       7.5.  Actor Identity Representation . . . . . . . . . . . . . .  20
       7.6.  Artifact Typing . . . . . . . . . . . . . . . . . . . . .  22
       7.7.  Issued Token Type . . . . . . . . . . . . . . . . . . . .  22
       7.8.  Commitment Hash Algorithms  . . . . . . . . . . . . . . .  23
       7.9.  Commitment Function . . . . . . . . . . . . . . . . . . .  23
       7.10. Common Cryptographic Operations . . . . . . . . . . . . .  25
     8.  Profile Selection and Workflow Immutability . . . . . . . . .  26
     9.  Common Validation Procedures  . . . . . . . . . . . . . . . .  27



  Prasad, et al.           Expires 2 November 2026                [Page 2]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


       9.1.  Recipient Validation of an Inbound Token  . . . . . . . .  27
       9.2.  Authorization Server Validation of Token Exchange . . . .  28
       9.3.  Current-Actor Validation of a Returned Token  . . . . . .  29
     10. Profiles  . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     11. Declared Full Disclosure Profile  . . . . . . . . . . . . . .  30
       11.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  30
       11.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  30
       11.3.  Security Model . . . . . . . . . . . . . . . . . . . . .  30
       11.4.  Bootstrap  . . . . . . . . . . . . . . . . . . . . . . .  30
       11.5.  Hop Processing . . . . . . . . . . . . . . . . . . . . .  31
       11.6.  Token Exchange . . . . . . . . . . . . . . . . . . . . .  31
       11.7.  Returned Token Validation  . . . . . . . . . . . . . . .  32
       11.8.  Next-Hop Validation  . . . . . . . . . . . . . . . . . .  32
       11.9.  Security Result  . . . . . . . . . . . . . . . . . . . .  32
     12. Declared Subset Disclosure Profile  . . . . . . . . . . . . .  32
       12.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  32
       12.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  33
       12.3.  Inheritance and Security Model . . . . . . . . . . . . .  33
       12.4.  Modified Bootstrap and Issuance  . . . . . . . . . . . .  33
       12.5.  Modified Hop Processing and Validation . . . . . . . . .  34
       12.6.  Modified Token Exchange  . . . . . . . . . . . . . . . .  34
       12.7.  Next-Hop Authorization . . . . . . . . . . . . . . . . .  35
       12.8.  Security Result  . . . . . . . . . . . . . . . . . . . .  35
     13. Declared Actor-Only Disclosure Profile  . . . . . . . . . . .  35
       13.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  35
       13.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  36
       13.3.  Inheritance and Security Model . . . . . . . . . . . . .  36
       13.4.  Modified Bootstrap and Issuance  . . . . . . . . . . . .  36
       13.5.  Modified Hop Processing and Validation . . . . . . . . .  36
       13.6.  Modified Token Exchange  . . . . . . . . . . . . . . . .  36
       13.7.  Next-Hop Authorization . . . . . . . . . . . . . . . . .  37
       13.8.  Security Result  . . . . . . . . . . . . . . . . . . . .  37
     14. Common Processing for the Verified Branch . . . . . . . . . .  37
       14.1.  Common Parameters  . . . . . . . . . . . . . . . . . . .  38
       14.2.  Common Bootstrap Context Request . . . . . . . . . . . .  39
       14.3.  Common Initial Actor Step Proof and Bootstrap
              Issuance . . . . . . . . . . . . . . . . . . . . . . . .  40
       14.4.  Common Hop Processing  . . . . . . . . . . . . . . . . .  41
       14.5.  Common Token Exchange  . . . . . . . . . . . . . . . . .  41
       14.6.  Common Returned-Token Validation . . . . . . . . . . . .  42
     15. Verified Full Disclosure Profile  . . . . . . . . . . . . . .  43
       15.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  43
       15.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  43
       15.3.  Security Model . . . . . . . . . . . . . . . . . . . . .  43
       15.4.  Profile-Specific Hop Construction and Validation . . . .  44
       15.5.  Attack Handling  . . . . . . . . . . . . . . . . . . . .  44
       15.6.  Security Result  . . . . . . . . . . . . . . . . . . . .  44
     16. Verified Subset Disclosure Profile  . . . . . . . . . . . . .  44



  Prasad, et al.           Expires 2 November 2026                [Page 3]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


       16.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  45
       16.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  45
       16.3.  Security Model . . . . . . . . . . . . . . . . . . . . .  45
       16.4.  Profile-Specific Hop Construction and Validation . . . .  46
       16.5.  Attack Handling  . . . . . . . . . . . . . . . . . . . .  47
       16.6.  Security Result  . . . . . . . . . . . . . . . . . . . .  47
     17. Verified Actor-Only Disclosure Profile  . . . . . . . . . . .  47
       17.1.  Profile Identifier . . . . . . . . . . . . . . . . . . .  47
       17.2.  Objective  . . . . . . . . . . . . . . . . . . . . . . .  48
       17.3.  Security Model . . . . . . . . . . . . . . . . . . . . .  48
       17.4.  Profile-Specific Hop Construction and Validation . . . .  48
       17.5.  Attack Handling  . . . . . . . . . . . . . . . . . . . .  49
       17.6.  Security Result  . . . . . . . . . . . . . . . . . . . .  49
     18. Special Preserve-State Exchanges  . . . . . . . . . . . . . .  49
       18.1.  Cross-Domain Re-Issuance . . . . . . . . . . . . . . . .  49
         18.1.1.  Request Format . . . . . . . . . . . . . . . . . . .  49
         18.1.2.  Preservation Rules . . . . . . . . . . . . . . . . .  50
         18.1.3.  Subject Handling . . . . . . . . . . . . . . . . . .  51
         18.1.4.  ActorID Namespace Handling . . . . . . . . . . . . .  52
         18.1.5.  Returned-Token Validation  . . . . . . . . . . . . .  53
       18.2.  Refresh-Exchange . . . . . . . . . . . . . . . . . . . .  53
         18.2.1.  Request Format . . . . . . . . . . . . . . . . . . .  53
         18.2.2.  Processing Rules . . . . . . . . . . . . . . . . . .  54
         18.2.3.  Returned-Token Validation  . . . . . . . . . . . . .  55
     19. Optional Receiver Acknowledgment Extension  . . . . . . . . .  55
       19.1.  Receiver Acknowledgment Validation . . . . . . . . . . .  57
     20. Common Security and Enforcement Requirements  . . . . . . . .  58
       20.1.  JOSE and Parser Hardening  . . . . . . . . . . . . . . .  58
       20.2.  Actor Authentication and Presenter Binding . . . . . . .  58
       20.3.  Actor and Recipient Proof Keys . . . . . . . . . . . . .  59
       20.4.  Intended Recipient Validation  . . . . . . . . . . . . .  59
       20.5.  Replay and Freshness . . . . . . . . . . . . . . . . . .  60
     21. Authorization Server Metadata . . . . . . . . . . . . . . . .  60
     22. Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  61
     23. Part II.  Security, Privacy, Deployment, and Rationale  . . .  63
     24. Motivating Real-World Examples  . . . . . . . . . . . . . . .  63
       24.1.  Full Disclosure: Emergency Production Change in Critical
              Infrastructure . . . . . . . . . . . . . . . . . . . . .  63
       24.2.  Subset Disclosure: Regulated M&A Review  . . . . . . . .  64
       24.3.  Actor-Only Disclosure: Bank Wire-Payment Processing
              Pipeline . . . . . . . . . . . . . . . . . . . . . . . .  64
     25. Security Considerations . . . . . . . . . . . . . . . . . . .  64
       25.1.  Actor Authentication and Presenter Binding Are
               Deployment-Specific . . . . . . . . . . . . . . . . . .  65
       25.2.  Canonicalization Errors Break Interoperability and Proof
               Validity  . . . . . . . . . . . . . . . . . . . . . . .  65
       25.3.  Commitment State Is Byte-Oriented  . . . . . . . . . . .  65
       25.4.  Readable Chain Does Not Prevent Payload Abuse  . . . . .  65



  Prasad, et al.           Expires 2 November 2026                [Page 4]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


       25.5.  Verified Profiles Depend on Proof Retention  . . . . . .  65
       25.6.  Subset-Disclosure Profiles Reveal Only a Verified
               Subset  . . . . . . . . . . . . . . . . . . . . . . . .  66
       25.7.  Cross-Domain Re-Issuance Must Preserve Chain State . . .  66
       25.8.  Branch Reconstruction Is an Audit Concern  . . . . . . .  66
       25.9.  Intended Recipient Checks Reduce Confused-Deputy Risk  .  67
       25.10. Chain Depth  . . . . . . . . . . . . . . . . . . . . . .  67
       25.11. Key Management . . . . . . . . . . . . . . . . . . . . .  67
     26. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  67
       26.1.  Subset Disclosure Extensions . . . . . . . . . . . . . .  68
     27. Appendix A.  JWT Binding (Normative)  . . . . . . . . . . . .  69
       27.1.  ActorID in JWT . . . . . . . . . . . . . . . . . . . . .  69
       27.2.  Step Proof in JWT  . . . . . . . . . . . . . . . . . . .  69
       27.3.  Receiver Acknowledgment in JWT . . . . . . . . . . . . .  70
       27.4.  Commitment Object in JWT . . . . . . . . . . . . . . . .  71
     28. Appendix B.  Compact End-to-End Examples (Informative)  . . .  72
       28.1.  Example 1: Declared Full Disclosure in One Domain  . . .  72
       28.2.  Example 2: Declared Subset Disclosure  . . . . . . . . .  72
       28.3.  Example 2b: Declared Actor-Only Disclosure . . . . . . .  73
       28.4.  Example 3: Verified Full Disclosure Across Two
              Domains  . . . . . . . . . . . . . . . . . . . . . . . .  73
       28.5.  Example 4: Verified Actor-Only Disclosure  . . . . . . .  74
       28.6.  Example 5: Verified Subset Disclosure  . . . . . . . . .  74
     29. Appendix C.  Future Considerations (Informative)  . . . . . .  75
       29.1.  Terminal Receipts and Result Attestations  . . . . . . .  75
       29.2.  Bootstrap Receipts and Portable Initial-State
              Evidence . . . . . . . . . . . . . . . . . . . . . . . .  75
       29.3.  Receiver Acceptance and Unsolicited Victim Mitigation  .  75
       29.4.  Subset Disclosure Extensions . . . . . . . . . . . . . .  76
       29.5.  Semantic-Equivalent Commitment Inputs  . . . . . . . . .  76
       29.6.  Branching and Fan-Out  . . . . . . . . . . . . . . . . .  76
       29.7.  Evidence Discovery and Governance Interoperability . . .  77
     30. Appendix D.  Design Rationale and Relation to Other Work
             (Informative) . . . . . . . . . . . . . . . . . . . . . .  77
     31. Appendix E.  Implementation Conformance Checklist
             (Informative) . . . . . . . . . . . . . . . . . . . . . .  78
     32. Appendix F.  Canonicalization Test Vectors (Informative)  . .  80
       32.1.  JWT / JCS ActorID Example  . . . . . . . . . . . . . . .  80
       32.2.  JWT / JCS target_context Example . . . . . . . . . . . .  80
     33. Appendix G.  Illustrative Wire-Format Example
             (Informative) . . . . . . . . . . . . . . . . . . . . . .  81
       33.1.  Decoded Access Token Payload Example . . . . . . . . . .  81
       33.2.  Decoded actc JWS Example . . . . . . . . . . . . . . . .  81
     34. Appendix H.  Problem Statement and Deployment Context
             (Informative) . . . . . . . . . . . . . . . . . . . . . .  81
     35. Appendix I.  Threat Model (Informative) . . . . . . . . . . .  82
       35.1.  Assets . . . . . . . . . . . . . . . . . . . . . . . . .  82
       35.2.  Adversaries  . . . . . . . . . . . . . . . . . . . . . .  82



  Prasad, et al.           Expires 2 November 2026                [Page 5]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


       35.3.  Assumptions  . . . . . . . . . . . . . . . . . . . . . .  83
       35.4.  Security Goals . . . . . . . . . . . . . . . . . . . . .  83
       35.5.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . .  84
       35.6.  Residual Risks . . . . . . . . . . . . . . . . . . . . .  84
     36. Appendix J.  Trust Boundaries and Audit Guidance
             (Informative) . . . . . . . . . . . . . . . . . . . . . .  84
     37. Appendix K.  Design Decisions (Informative) . . . . . . . . .  85
       37.1.  Why visible chain state is carried in nested act . . . .  85
       37.2.  Why top-level sub remains the workflow subject . . . . .  86
       37.3.  Why privacy-sensitive profiles use stable subject
               aliases . . . . . . . . . . . . . . . . . . . . . . . .  86
       37.4.  Why subset disclosure is recipient-specific and
               AS-driven . . . . . . . . . . . . . . . . . . . . . . .  86
       37.5.  Why actor-only is a separate profile even though subset
               can express it  . . . . . . . . . . . . . . . . . . . .  86
       37.6.  Why branching is represented across tokens, not inside one
               token . . . . . . . . . . . . . . . . . . . . . . . . .  86
       37.7.  Why actc uses parent-pointer commitments instead of Merkle
               trees . . . . . . . . . . . . . . . . . . . . . . . . .  87
       37.8.  Why actp and actc use short claim names  . . . . . . . .  87
       37.9.  Why RFC 8414 metadata discovery is reused  . . . . . . .  87
       37.10. Privacy goals and limits . . . . . . . . . . . . . . . .  87
     38. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  87
       38.1.  JSON Web Token Claims Registration . . . . . . . . . . .  87
       38.2.  Media Type Registration  . . . . . . . . . . . . . . . .  88
       38.3.  OAuth URI Registration . . . . . . . . . . . . . . . . .  89
       38.4.  OAuth Authorization Server Metadata Registration . . . .  90
       38.5.  OAuth Parameter Registration . . . . . . . . . . . . . .  92
     39. Appendix X.  Out-of-Scope Use Cases (Informative) . . . . . .  93
     40. Appendix Y.  Relationship to RFC 8693 (Informative) . . . . .  93
     41. Informative References  . . . . . . . . . . . . . . . . . . .  94
     Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  96
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  96

  1.  Part I.  Core Specification

  2.  Introduction

     In service-to-service, tool-calling, and agent-to-agent systems,
     including those implementing the Model Context Protocol (MCP) and the
     Agent2Agent (A2A) protocol, one workload often receives a token,
     performs work, and then exchanges that token to call another
     workload.  [RFC8693] defines token exchange and the act claim for the
     current actor, but it does not define a standardized way to preserve
     and validate delegation-path continuity across a sequence of
     exchanges.





  Prasad, et al.           Expires 2 November 2026                [Page 6]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     This document defines six interoperable actor-chain profiles for
     OAuth 2.0 Token Exchange.  They preserve the existing meanings of
     sub, act, and may_act, and they define when nested act becomes
     authoritative visible actor-chain state for profile-controlled
     processing.  Depending on the selected profile, the next hop can see
     the full visible chain, an Authorization-Server- selected subset of
     that chain, only the current actor, or no inline act at all.

     The profiles are organized in two branches.  The declared branch
     relies on the Authorization Server to assert visible chain
     continuity.  The verified branch adds actor-signed step proofs and
     cumulative commitment state so that later participants can validate
     stronger continuity and audit evidence.  All profiles support both
     same-domain continuation and cross-domain re-issuance.  This
     specification does not require any particular presenter-binding or
     actor- authentication mechanism; those remain deployment-specific.

     This specification defines a JWT / JSON Web Signature (JWS) binding
     for the interoperable base protocol.  A future version or companion
     specification MAY define an equivalent COSE/CBOR binding.

  3.  Terminology

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

     This document also leverages terminology from OAuth 2.0 Token
     Exchange [RFC8693], the SPICE Architecture [I-D.ietf-spice-arch], and
     the RATS Architecture [RFC9334].

     *  *Actor*: A workload, service, application component, agent, or
        other authenticated entity that receives a token, performs work,
        and MAY subsequently act toward another actor.

     *  *Current actor*: The authenticated entity presently performing
        token exchange.

     *  *Disclosed current actor*: The actor identified by the outermost
        visible act node of an artifact when such a node is present.
        Depending on the selected profile and disclosure policy, the
        disclosed current actor MAY be the same as the operational current
        actor or MAY be absent from the returned ordinary token.

     *  *Presenting actor*: The actor that presents an inbound token to a
        recipient.



  Prasad, et al.           Expires 2 November 2026                [Page 7]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Example: when B exchanges a token at the Authorization Server, B is
     the current actor.  When B later presents the resulting token to C, B
     is the presenting actor.

     Unless otherwise qualified, references in this specification to the
     current actor are about the operational current actor performing
     exchange, not about whether that actor is disclosed inline in act for
     the next hop.

     *  *Recipient*: The actor or resource server identified as the
        intended target of an issued token.

     *  *Actor chain*: The ordered sequence of actors that have acted so
        far in one workflow instance.

     *  *Ordinary token*: The access token issued for presentation to the
        next hop.  It is distinct from step proofs, bootstrap context
        handles, commitment objects, and receiver acknowledgments.

     *  *Visible chain*: The ordered actor sequence represented by the act
        structure of an artifact when actp is present.  The outermost act
        identifies the current actor.  Any nested act members identify
        prior visible actors only.

     When this specification discusses a visible chain carried in an
     issued token or other artifact for the next recipient, it refers to
     the disclosed token- visible chain.

     *  *Actor-visible chain*: The exact ordered actor sequence that the
        current actor is permitted to know and extend for the next hop.
        In the verified profiles, this is the exact visible chain that the
        current actor verified on the inbound hop, with that actor
        appended when it later acts.

     In the verified profiles, this is the signed actor-visible chain
     carried in the step proof.  It can be broader than the disclosed
     token-visible chain of the returned ordinary token under subset-
     disclosure or actor-only operation.

     *  *Authoritative workflow chain state*: Authorization-Server-
        retained state for the accepted workflow instance.  It MAY be
        richer than the visible chain disclosed in any given issued token.
        It is used for continuity, branch correlation, forensic review,
        legal audit, and any policy-controlled future redisclosure.  This
        specification does not require that such retained state be
        disclosed inline in ordinary tokens.





  Prasad, et al.           Expires 2 November 2026                [Page 8]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     In the full-disclosure profiles, the visible chain, the actor-visible
     chain, and the authoritative workflow chain state collapse to the
     same chain.  They diverge only under subset and actor-only profiles,
     where the visible chain may be narrower than the actor-visible chain,
     which in turn may be narrower than the authoritative workflow chain
     state.

     *  *Proof-bound chain state*: The cumulative cryptographic state
        carried in actc that binds prior accepted chain state to a newly
        accepted hop.

     *  *Step proof*: A profile-defined proof signed by the current actor
        that binds that actor's participation to the workflow, prior
        accepted state, the profile-defined actor-visible chain for the
        hop, and target context.

     *  *Target context*: The canonical representation of the next-hop
        target that a profile-defined proof or acknowledgment binds to.
        It always includes the intended audience and MAY additionally
        include other target-selection inputs.  If no such additional
        inputs are used, it is identical to aud.

     *  *Bootstrap context*: An opaque handle issued by the Authorization
        Server only to start a verified profile workflow.  It lets the
        initial actor redeem bound bootstrap state at the token endpoint
        without carrying that state inline.

     *  *Actor-chain identifier (acti)*: A stable identifier minted once
        at workflow start and retained for the lifetime of the workflow
        instance.

     *  *Cross-domain re-issuance*: A second token exchange performed at
        another domain's Authorization Server in order to obtain a local
        token trusted by the next recipient, without extending the actor
        chain.

     *  *Home Authorization Server*: The Authorization Server at which the
        current actor normally performs the chain-extending token exchange
        for the next hop.  In same-domain operation it is the issuer that
        validates prior chain state and issues the next ordinary token.

     *  *Continuity*: The property that the presenting actor of an inbound
        artifact is the same actor that the workflow state and any
        required disclosed current-actor information identify as the
        expected presenter.






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


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  *Append-only processing*: The rule that a new actor is appended to
        the prior accepted workflow chain state, and to any disclosed
        visible chain fragment derived from it, without insertion,
        deletion, reordering, or modification of prior actors.

     *  *Terminal recipient*: A recipient that performs work locally and
        does not extend the actor chain further.

     *  *Refresh-Exchange*: A token-exchange operation by the same current
        actor that preserves accepted chain state while refreshing
        transport characteristics such as expiry according to local
        policy.

     *  *Local policy*: Deployment-specific authorization and risk rules
        used when this specification defers a decision to the
        Authorization Server or recipient.  Local policy can include trust
        relationships, authenticated client identity, permitted audiences
        or resources, chain-depth limits, profile support, and business or
        risk controls.

  4.  Relationship to RFC 8693 Claims

     This specification extends OAuth 2.0 Token Exchange [RFC8693] without
     changing the base meanings of sub, act, or may_act.  It profiles
     delegation-chain workflow continuity and profile-controlled
     disclosure across token exchange hops.

     When actp is absent, act has ordinary RFC 8693 semantics.  Nested
     prior act claims, if present, remain informational only for access-
     control purposes, consistent with [RFC8693].

     The following rules apply when actp is present and points to a
     profile defined by this specification:

     *  sub continues to identify the subject of the issued token.
     *  acti identifies the stable workflow instance for the accepted
        actor-chain state.
     *  If act is present, it is the authoritative disclosed actor-chain
        fragment for that artifact.  The outermost act, when present,
        identifies the disclosed current actor.  Each nested act member,
        when present, identifies the immediately prior disclosed actor.
     *  Reduced actor disclosure, including omission of prior actors,
        omission of the current actor from a disclosed subset, or omission
        of act entirely, does not turn a profiled token into an ordinary
        impersonation output.  When actp is present, the token remains a
        delegation-chain token under this specification.





  Prasad, et al.           Expires 2 November 2026               [Page 10]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  Plain RFC 8693 outputs that do not carry this specification's
        profile signals remain outside this profile family whether or not
        they contain act.

  4.1.  Disclosure Invariant

     For any selected actp, the Authorization Server is the policy
     decision and policy enforcement point for actor-chain disclosure.
     The selected profile defines the maximum actor-chain information, if
     any, that may be visible inline to the next hop.

     Accordingly:

     *  no other field, identifier encoding, compatibility form, or
        exchange option may disclose more actor-chain information than the
        selected profile permits;
     *  recipients and intermediaries MUST NOT infer hidden actors from
        omitted entries, identifier structure, or other claims; and
     *  when a profile hides prior actors or the workflow subject's
        globally useful identifier, the Authorization Server MUST enforce
        that outcome across the entire issued artifact, not only within
        act.

     Nothing in this specification redefines RFC 8693 delegation or
     impersonation semantics.  With actp absent, this document adds no new
     requirements on how nested act is interpreted.  With actp present,
     this document defines an explicit profile-controlled extension in
     which the visible act structure becomes authoritative for actor-chain
     processing under that profile.

  5.  Scope and Model

     This document specifies a family of profiles for representing and
     validating actor progression across a workflow path using OAuth 2.0
     Token Exchange.

     Implementers primarily interested in interoperable behavior can focus
     first on Common Basics, Common Validation Procedures, the profile
     sections, and Appendices A, B, G, and H.  Special preserve-state
     exchanges, metadata, and the deeper enforcement rules are
     intentionally surfaced later so the reader can learn the ordinary
     profile flow first.  The appendices later in the document contain
     background, rationale, threat discussion, and operational guidance
     that may be useful for review and deployment planning but are not
     required for a first implementation pass.






  Prasad, et al.           Expires 2 November 2026               [Page 11]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  5.1.  Workflow Model

     The basic workflow path model is:

     {::nomarkdown} <artwork type="ascii-art"> A -> B -> C -> D </artwork>
     {:/nomarkdown}

     The first actor initializes the workflow.  Each subsequent actor MAY:

     1.  validate an inbound token;
     2.  perform work; and
     3.  exchange that token for a new token representing itself toward
         the next hop.

  5.2.  Profile Summary

     This document defines six profiles:

     *  *Declared Full Disclosure*, which carries the full visible nested
        act chain in ordinary tokens and relies on AS-asserted chain
        continuity under a non-collusion assumption;
     *  *Declared Subset Disclosure*, which carries a recipient-specific
        disclosed nested act chain in ordinary tokens and relies on the
        issuing AS for both chain continuity and disclosure policy;
     *  *Declared Actor-Only Disclosure*, which carries only the outermost
        current actor in ordinary tokens and makes that actor the sole
        inline authorization input for the next hop;
     *  *Verified Full Disclosure*, which is the verified full-disclosure
        case in which every actor and downstream recipient sees the full
        visible nested act chain;
     *  *Verified Subset Disclosure*, which preserves cumulative
        commitment state and lets the Authorization Server disclose a
        recipient-specific visible nested act chain while the current
        actor signs the exact actor-visible chain it was allowed to see
        and extend; and
     *  *Verified Actor-Only Disclosure*, which keeps the verified proofs
        and cumulative commitment state but discloses only the outermost
        current actor in ordinary tokens.

     The six profiles are organized in two branches so that later profiles
     can be read as deltas, not as full restatements:

     *  the *declared branch*, rooted at Declared Full Disclosure with two
        concise disclosure-mode deltas: subset and actor-only; and
     *  the *verified branch*, consisting of one common verified
        processing section plus three disclosure modes: full disclosure,
        subset disclosure, and actor-only disclosure.




  Prasad, et al.           Expires 2 November 2026               [Page 12]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Each derived profile inherits all requirements of its branch root or
     common verified processing section except as modified in that
     profile.  Readers therefore need only read:

     *  *Declared Full Disclosure* for the declared branch;
     *  the concise delta sections for the declared subset-disclosure and
        declared actor-only variants; and
     *  *Common Processing for the Verified Branch* plus the concise
        verified profile sections for the verified branch.

     Later sections introduce the additional verified-profile mechanisms
     only where they are needed: a one-time bootstrap at workflow start, a
     per-hop actor-signed step proof, cumulative commitment state in actc,
     and the optional hop_ack extension.  Every profile still issues the
     same basic next-hop ordinary token.

     The following table is a quick orientation aid.

     +==========+=========+====+==========+================+=============+
     |Profile   |Visible  |actc|Recipient-| Next-hop       | Primary     |
     |          |act in   |    |specific  | authorization  | trust/      |
     |          |ordinary |    |disclosure| basis          | evidence    |
     |          |tokens   |    |          |                | model       |
     +==========+=========+====+==========+================+=============+
     |Declared  |Full     |No  |No        | Full visible   | AS-         |
     |Full      |nested   |    |          | chain          | asserted    |
     |Disclosure|chain    |    |          |                | continuity  |
     +----------+---------+----+----------+----------------+-------------+
     |Declared  |Disclosed|No  |Yes       | Disclosed      | AS-         |
     |Subset    |nested   |    |          | visible subset | asserted    |
     |Disclosure|subset or|    |          | only;          | continuity  |
     |          |omitted  |    |          | undisclosed    | plus AS     |
     |          |act      |    |          | actors         | disclosure  |
     |          |         |    |          | unavailable    | policy      |
     |          |         |    |          | from the       |             |
     |          |         |    |          | artifact       |             |
     +----------+---------+----+----------+----------------+-------------+
     |Declared  |Outermost|No  |Fixed     | Current actor  | AS-         |
     |Actor-Only|current  |    |actor-only| only           | asserted    |
     |Disclosure|actor    |    |          |                | continuity  |
     |          |only     |    |          |                | plus        |
     |          |         |    |          |                | actor-only  |
     |          |         |    |          |                | disclosure  |
     |          |         |    |          |                | policy      |
     +----------+---------+----+----------+----------------+-------------+
     |Verified  |Full     |Yes |No        | Full visible   | Actor-      |
     |Full      |nested   |    |          | chain plus     | signed      |
     |Disclosure|chain    |    |          | commitment     | visible-    |



  Prasad, et al.           Expires 2 November 2026               [Page 13]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     |          |         |    |          | continuity     | chain       |
     |          |         |    |          |                | proofs      |
     |          |         |    |          |                | plus        |
     |          |         |    |          |                | cumulative  |
     |          |         |    |          |                | commitment  |
     +----------+---------+----+----------+----------------+-------------+
     |Verified  |Disclosed|Yes |Yes       | Disclosed      | Actor-      |
     |Subset    |nested   |    |          | visible subset | signed      |
     |Disclosure|subset or|    |          | only;          | visible-    |
     |          |omitted  |    |          | undisclosed    | chain       |
     |          |act      |    |          | actors         | proofs      |
     |          |         |    |          | unavailable    | plus        |
     |          |         |    |          | from the       | recipient-  |
     |          |         |    |          | artifact, plus | specific    |
     |          |         |    |          | commitment     | disclosure  |
     |          |         |    |          | continuity     |             |
     +----------+---------+----+----------+----------------+-------------+
     |Verified  |Outermost|Yes |Fixed     | Current actor  | Actor-      |
     |Actor-Only|current  |    |actor-only| only plus      | signed      |
     |Disclosure|actor    |    |          | commitment     | visible-    |
     |          |only     |    |          | continuity     | chain       |
     |          |         |    |          |                | proofs      |
     |          |         |    |          |                | plus        |
     |          |         |    |          |                | cumulative  |
     |          |         |    |          |                | commitment  |
     |          |         |    |          |                | with        |
     |          |         |    |          |                | actor-only  |
     |          |         |    |          |                | disclosure  |
     +----------+---------+----+----------+----------------+-------------+

                                    Table 1

     Profile-applicability constraint: deployments in which recipient
     authorization depends on prior-path membership or order MUST use a
     profile and disclosure policy that disclose the required prior-path
     evidence at that hop.  Actor-only or omitted-act outcomes are not
     suitable inputs for such path-sensitive authorization decisions.

     Motivating real-world examples for each disclosure mode appear in the
     "Motivating Real-World Examples" section in Part II.  Out-of-scope
     use cases are noted in Appendix X.










  Prasad, et al.           Expires 2 November 2026               [Page 14]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  5.3.  Branching and Non-Goals

     Application logic may branch, fan out, and run in parallel.  This
     document standardizes one visible path per issued token, not a full
     call-graph language.  An Authorization Server MAY mint multiple
     accepted successor tokens from one prior accepted state, each with
     its own jti and canonical target_context.  Such successor tokens MAY
     share the same acti and earlier workflow history.  Deployments that
     require strict linear continuation MAY instead enforce a local
     single-successor policy under which the Authorization Server accepts
     at most one successor from any accepted prior state.  This base
     specification does not define an interoperable on-the-wire signal for
     single-successor mode, sibling invalidation, or proof that no
     parallel successor exists.  This document does not define merge
     semantics, sibling-discovery semantics, or inline branch-selection
     semantics.

     Accordingly, a valid token under this specification proves only one
     accepted visible path for that token.  It does not by itself prove
     branch uniqueness for the workflow instance or prove that no other
     accepted sibling successor exists.

     Post-facto reconstruction of branching is a forensic or legal-audit
     concern, not a normal online authorization requirement.  Retained
     Authorization Server records, timestamps, commitment state, and
     causal links among presenting actors, current actors, and subsequent
     actors can often reveal much of the effective call graph, but this
     base specification alone does not guarantee a complete standardized
     graph across all branches.

     An issued token MAY still carry an aud string or array according to
     JWT and OAuth conventions, but each issued token and each step proof
     binds exactly one canonical next-hop target_context.  Additional
     target contexts require additional successor tokens.

     Repeated ActorID values within one workflow instance are permitted.
     A sequence such as [A,B,C,D,A,E] denotes that actor A acted more than
     once in the same workflow instance.  Collecting all accepted hop
     evidence for one acti, such as retained tokens, proofs, commitments,
     and exchange records, can therefore reconstruct the accepted hop
     sequence, including repeated-actor revisits.

  6.  Protocol Overview

  6.1.  Workflow Progression

     The actor chain advances only when an actor acts.  Mere receipt of a
     token does not append the recipient.



  Prasad, et al.           Expires 2 November 2026               [Page 15]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     If A calls B, and B later calls C, then:

     1.  A begins the workflow and becomes the initial actor.
     2.  When A calls B, B validates a token representing A.
     3.  When B later exchanges that token to call C, B becomes the next
         actor.
     4.  C is not appended merely because C received a token.  C is
         appended only if C later acts toward another hop.

     Compact end-to-end examples appear in Appendix B.

  6.2.  Same-Domain and Cross-Domain Hops

     Within one trust domain, the current actor exchanges its inbound
     token at its home Authorization Server, meaning the Authorization
     Server that validates the prior chain state for that actor and issues
     the next ordinary token.

     Across a trust boundary, if the next recipient does not trust the
     current Authorization Server directly, the current actor performs a
     second token exchange at the next domain's Authorization Server.
     That second exchange preserves the already-established chain state
     and does not append the next recipient.

     The trust/evidence differences among profiles are summarized in the
     profile matrix above and discussed further in Appendix J.  The
     special preserve-state cases for cross-domain re-issuance and
     Refresh-Exchange are defined later, after the ordinary profile flows.

  7.  Common Basics

  7.1.  Common Token Requirements

     Unless stated otherwise, "ordinary token" below means the access
     token issued to the current actor for presentation to the next hop.
     This section is about those tokens, not about verified-profile step
     proofs, bootstrap context handles, or hop_ack objects.

     In the interoperable self-contained ordinary-token binding defined by
     this document, tokens issued under any profile:

     *  MUST be short-lived;
     *  MUST contain:
        -  an issuer claim iss;
        -  a profile identifier claim actp;
        -  an actor-chain identifier claim acti;
        -  a subject claim sub;
        -  a unique token identifier claim jti;



  Prasad, et al.           Expires 2 November 2026               [Page 16]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


        -  an audience value aud; and
        -  an expiry value exp.

     A profile-governed ordinary token MAY additionally contain act
     according to the selected profile and Authorization Server policy.

     For interoperability and predictable freshness, deployments SHOULD
     use ordinary-token lifetimes on the order of minutes rather than
     hours; a default range of 1 to 10 minutes is RECOMMENDED.  Validators
     SHOULD allow only modest clock skew when evaluating exp, typically no
     more than 60 seconds unless local clock discipline justifies a
     tighter bound.

     Proof-bound profiles additionally MUST carry actc.

     The token claims used by this document have these roles:

     *  iss identifies the issuer namespace of the ordinary token and of
        that token's top-level sub;
     *  actp identifies the selected actor-chain profile;
     *  acti identifies the workflow instance;
     *  sub identifies the workflow subject of the token;
     *  act, when present, carries the authoritative disclosed actor-chain
        fragment for that artifact; and
     *  actc, when present, carries cumulative commitment state for
        stronger tamper evidence, continuity, and auditability.

     This base specification defines interoperable direct claim carriage
     for self-contained ordinary tokens.  Deployments that instead use
     opaque access tokens MAY keep authoritative workflow state only at
     the issuing Authorization Server and MAY disclose actor-chain
     information, if any, through a companion token-validation interface
     such as token introspection [RFC7662].

     This specification does not define such companion interfaces.  If the
     artifact presented for validation does not expose enough information
     to satisfy the selected profile's requirements, the implementation
     MUST treat that as a profile-validation failure.

     Accordingly, interoperability requirements in this base specification
     apply to the self-contained ordinary-token claim carriage defined
     here.  Opaque-token deployments depend on companion validation
     interfaces outside this document and therefore require either out-of-
     band agreement or a companion specification for interoperable
     behavior.






  Prasad, et al.           Expires 2 November 2026               [Page 17]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     At workflow bootstrap, the issuing Authorization Server MUST
     establish the workflow subject according to local policy and the
     selected disclosure profile.  The resulting sub value MAY be an
     ordinary subject identifier, a pairwise identifier, or a workflow-
     local stable alias.  For privacy-sensitive subset-disclosure
     operation, the Authorization Server SHOULD choose a stable
     representation that does not reveal a globally useful subject
     identifier to recipients that are not entitled to learn it.

     For same-domain token exchange and Refresh-Exchange, this
     specification preserves that exact chosen sub representation within
     the same domain for the lifetime of the workflow unless a later
     permitted cross-domain alias transition occurs.  Cross-domain re-
     issuance MAY translate sub only under the semantic- equivalence rule
     defined later.  This document does not define a same-workflow
     subject-transition mechanism.

     The chosen sub representation for a workflow MUST remain consistent
     with the selected actp disclosure constraints.  In particular, sub
     MUST NOT disclose an actor identity or other actor-chain information
     that the selected profile is intended to withhold from the relevant
     recipient class.

     In this self-contained JWT/JWS binding, a returned ordinary token is
     visible to the current actor that receives it and to the next
     recipient that validates it.  Therefore, when a profile returns a
     visible act, the Authorization Server MUST NOT disclose in that
     returned token any actor identity that the current actor is not
     permitted to learn.  A future recipient-protected disclosure
     mechanism or encrypted binding may support stronger recipient-only
     redisclosure, but that is outside this base specification.

  7.2.  Actor-Chain Identifier

     The acti value:

     *  MUST be minted once at workflow start by the issuing Authorization
        Server;
     *  MUST be generated using a cryptographically secure pseudorandom
        number generator (CSPRNG) with at least 122 bits of entropy;
     *  MUST remain unchanged for the lifetime of that workflow instance;
        and
     *  MUST NOT be used to signal profile selection.

     Implementation note: standard UUID version 4 (UUIDv4), which provides
     122 bits of random entropy, is acceptable for acti in this version.
     Deployments MAY use stronger generation (for example, full 128-bit
     random values) by local policy.



  Prasad, et al.           Expires 2 November 2026               [Page 18]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Profile selection MUST be signaled explicitly using the token request
     parameter actor_chain_profile and the corresponding token claim actp.

  7.3.  Target Context Requirements

     target_context is the canonical next-hop target value bound into
     verified profile step proofs and, when used, into hop_ack.

     In this base specification, aud identifies the intended recipient
     service or audience of the issued token.  An optional resource value
     can further identify a narrower protected resource, API surface, or
     object within that audience.  When no finer-grained targeting inputs
     are used, the canonical target context is still a JSON object that
     contains only aud.

     The following normative requirements apply to target_context.

     For every profile-defined signed, hashed, compared, retained, or
     communicated use in this specification, target_context MUST be a JSON
     object.

     target_context MUST contain an aud member carrying the verified
     audience information exactly in the profile-defined canonical
     representation.  If aud is a string, target_context.aud MUST be that
     same JSON string.  If aud is an array of strings, target_context.aud
     MUST be that exact JSON array, preserving element order.

     If no additional target-selection values are used, target_context
     MUST be the single-member object { "aud": aud }.

     A deployment MAY additionally include:

     *  resource, when the hop is bound to a narrower protected resource
        or API surface within the audience;
     *  request_id, when the deployment expects multiple distinct accepted
        successors under the same prior state and the same nominal target;
        and
     *  other local extension members used by same-domain local
        authorization policy.

     This base specification assigns interoperable security semantics only
     to aud, optional resource, and optional request_id.  Cross-domain
     equivalence or narrowing decisions defined by this document MUST be
     evaluated using only those members unless a future companion
     specification defines additional target-context members and their
     semantics.





  Prasad, et al.           Expires 2 November 2026               [Page 19]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     When a deployment expects multiple distinct successors under the same
     prior state and the same nominal target, it MUST include a request-
     unique discriminator such as request_id inside target_context.

     target_context members MUST NOT disclose actor identities or other
     actor-chain information that the selected actp would withhold from
     the relevant holder of the artifact.

     An Authorization Server that validates, preserves, or audits workflow
     continuity using target_context MUST retain the exact canonical
     target_context value for the accepted hop, or enough original request
     material to reconstruct that exact canonical value later.

     Whenever target_context is incorporated into a profile-defined
     signature or commitment input in this JWT-based version, it MUST be
     represented as a JSON object and canonicalized exactly once as part
     of the enclosing JSON Canonicalization Scheme (JCS)-serialized
     payload object.  Equality checks over target_context MUST therefore
     compare the exact JSON object value after JCS canonicalization.
     Implementations MUST NOT collapse an audience array to a string,
     replace an object with a bare aud value, reorder array elements, or
     otherwise rewrite the verified audience structure before signing or
     comparing target_context.

  7.4.  Canonicalization

     All profile-defined signed or hashed inputs MUST use a canonical
     serialization defined by this specification.

     In this version of the specification, CanonicalEncode(x) means JCS
     [RFC8785] applied to the JSON value x.

     Hash_halg(x) denotes the raw hash output produced by applying the
     selected commitment hash algorithm halg to the octet sequence x.

     b64url(x) denotes the base64url encoding of the octet sequence x
     without trailing padding characters, as defined by [RFC7515]
     Appendix C.

     Canonical profile-defined proof payloads MUST be serialized using JCS
     [RFC8785].

  7.5.  Actor Identity Representation

     This specification requires a canonical representation for actor
     identity in profile-defined visible-chain entries and step proofs.





  Prasad, et al.           Expires 2 November 2026               [Page 20]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Each canonical actor identifier used by this specification MUST be
     represented as an ActorID structure containing exactly two members:

     *  iss: the issuer identifier naming the namespace in which the actor
        subject value is defined; and
     *  sub: the subject identifier of the actor within that issuer
        namespace.

     An ActorID is a JSON object with members iss and sub, serialized
     using JCS [RFC8785] when incorporated into profile-defined signed or
     hashed inputs.

     An ActorID:

     *  MUST be stable for equality comparison within a workflow instance;
     *  MUST be bound to the actor identity accepted under local policy
        for the relevant exchange, proof-verification, or acknowledgment-
        validation step;
     *  MUST be compared using exact equality of the pair (iss, sub); and
     *  SHOULD support pairwise or pseudonymous subject values where
        deployment policy allows.

     When deriving an ActorID from a validated inbound token:

     *  for the token subject, use { "iss": token.iss, "sub": token.sub };
     *  for a validated act claim that contains both iss and sub, use
        those two values directly; and
     *  for a validated act claim that contains sub but omits iss, use the
        enclosing token's iss as the ActorID iss value and the act.sub
        value as the ActorID sub value.

     If no usable act claim is present and a profile needs the presenting
     actor, that actor MUST be established from actor authentication or
     other locally trusted inputs outside the scope of this specification
     and mapped into the same ActorID representation the issuing
     Authorization Server uses for proof construction.

     When actp is present, the act structure used by this specification is
     an ActorChainNode.  An ActorChainNode is an ActorID object plus an
     OPTIONAL nested member named act whose value is another
     ActorChainNode representing the immediately prior visible actor.
     Newly issued profile-defined act structures MUST carry explicit iss
     and sub in every visible node.  Implementations MUST be able to
     decode and normalize a validated inbound visible chain even when a
     node omits iss and inherits the enclosing issuer according to the
     derivation rule above.

     The helper functions used throughout this document are therefore:



  Prasad, et al.           Expires 2 November 2026               [Page 21]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     {::nomarkdown} <sourcecode type="text"> VisibleChain(act) = ordered
     list of ActorID values obtained by recursively reading nested act
     from the innermost prior actor to the outermost current actor.

     EncodeVisibleChain([A]) = {"iss": A.iss, "sub": A.sub}
     EncodeVisibleChain([A,B]) = {"iss": B.iss, "sub": B.sub, "act":
     {"iss": A.iss, "sub": A.sub] EncodeVisibleChain([A,B,C]) = {"iss":
     C.iss, "sub": C.sub, "act": {"iss": B.iss, "sub": B.sub, "act":
     {"iss": A.iss, "sub": A.sub]} </sourcecode> {:/nomarkdown}

     In examples and formulas, [A,B] denotes the ordered visible chain of
     ActorID values for actors A and B, while EncodeVisibleChain([A,B])
     denotes the nested JSON representation carried in act.

  7.6.  Artifact Typing

     JWT-based artifacts defined by this specification MUST use explicit
     typ values.

     The following JWT typ values are defined:

     *  act-step-proof+jwt
     *  act-commitment+jwt
     *  act-hop-ack+jwt

     Verifiers MUST enforce mutually exclusive validation rules based on
     artifact type and MUST NOT accept one artifact type in place of
     another.  They MUST verify the expected JWT typ, exact ctx value
     where applicable, and artifact-specific payload structure defined by
     the relevant binding section of this specification.

     typ matching for profile-defined artifacts MUST be exact string
     equality, without case folding, prefix matching, or media-type alias
     mapping.  Missing or unexpected typ values MUST cause rejection of
     the artifact for that processing path.

     If a JOSE protected header contains crit, verifiers MUST reject
     unless every listed header parameter is understood and processed
     according to its specification.  This document defines no profile-
     specific use of unencoded JWS payloads; profile-defined artifacts in
     this version therefore use the ordinary base64url-encoded JWS payload
     form.

  7.7.  Issued Token Type

     Unless another application profile explicitly states otherwise,
     tokens issued under this specification are access tokens.




  Prasad, et al.           Expires 2 November 2026               [Page 22]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Token exchange responses MUST use the RFC 8693 token type fields
     consistently with the underlying representation and deployment.

  7.8.  Commitment Hash Algorithms

     Proof-bound profiles use a named hash algorithm for construction of
     actc.  Commitment hash algorithm identifiers are values from the IANA
     Named Information Hash Algorithm Registry [RFC6920]
     [IANA.Hash.Algorithms].

     The following requirements apply:

     *  halg MUST be a text string naming a hash algorithm from the IANA
        Named Information Hash Algorithm Registry.
     *  Implementations supporting verified profiles MUST implement sha-
        256.
     *  Implementations SHOULD implement sha-384.
     *  Every actc object and every verified profile bootstrap context
        MUST carry an explicit halg value.  Verifiers MUST NOT infer or
        substitute halg when it is absent.
     *  Verifiers MUST enforce a locally configured allow-list of
        acceptable commitment hash algorithms and MUST NOT accept
        algorithm substitution based solely on attacker-controlled inputs.
     *  Hash algorithms with truncated outputs, including truncated
        sha-256 variants, MUST NOT be used with this specification.
     *  Additional registry values MAY be used only if they are permitted
        by this specification or a future Standards Track update to it,
        and verifiers MUST reject locally deprecated or disallowed
        algorithms.
     *  An Authorization Server MUST NOT initiate a new workflow using a
        locally deprecated or disallowed algorithm.  Whether an already-
        issued workflow using such an algorithm may continue is a matter
        of local policy.

  7.9.  Commitment Function

     Proof-bound profiles use actc to bind each accepted hop to the prior
     accepted state.  The commitment hash algorithm is selected once for
     the workflow by the issuing Authorization Server during bootstrap and
     remains fixed for the lifetime of that workflow instance.

     Each actc value is a signed commitment object whose payload contains:

     *  ctx: the context string actor-chain-commitment-v1;
     *  iss: the issuer identifier of the Authorization Server that signs
        this commitment object;
     *  acti: the actor-chain identifier;
     *  actp: the active profile identifier;



  Prasad, et al.           Expires 2 November 2026               [Page 23]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  halg: the hash algorithm identifier;
     *  prev: the prior commitment digest, or the bootstrap
        initial_chain_seed at workflow start;
     *  step_hash: b64url(Hash_halg(step_proof_bytes)); and
     *  curr: b64url(Hash_halg(CanonicalEncode({ctx, iss, acti, actp,
        halg, prev, step_hash}))).

     The curr value MUST be computed over exactly the seven members ctx,
     iss, acti, actp, halg, prev, and step_hash, excluding curr itself.
     The resulting digest is then inserted as the transported curr member.

     Let prev_digest denote the prior commitment-state digest for the step
     being processed: at bootstrap it is the initial_chain_seed, and for
     later steps it is the verified curr value extracted from the inbound
     actc.  For the JWT binding defined in this version, let
     step_proof_bytes denote the ASCII bytes of the exact compact JWS
     string submitted as actor_chain_step_proof.  Let as_issuer_id denote
     the issuer identifier that the Authorization Server places into the
     commitment object's iss member, typically its issuer value.  The
     commitment hash therefore binds the transmitted step-proof artifact,
     not merely its decoded payload.

     Accordingly, step_hash and curr are commitments to the exact compact-
     JWS proof bytes accepted for that hop.  Two semantically equivalent
     decoded proofs MAY therefore produce different commitment values when
     their compact-JWS bytes differ.

     When a profile-defined proof input refers to a prior actc, the value
     incorporated into the proof input MUST be that prior commitment's
     verified curr digest string, copied directly from the validated actc
     payload, not the raw serialized commitment object.

     The abstract function used throughout this document is therefore:

     {::nomarkdown} <sourcecode type="text"> Commit_AS(as_issuer_id, acti,
     actp, prev_digest, step_proof_bytes, halg) = AS-signed commitment
     object over payload { ctx, iss, acti, actp, halg, prev = prev_digest,
     step_hash = b64url(Hash_halg(step_proof_bytes)), curr =
     b64url(Hash_halg(CanonicalEncode({ctx, iss, acti, actp, halg, prev,
     step_hash}))) } </sourcecode> {:/nomarkdown}

     The exact wire encoding of the signed commitment object is defined in
     the JWT binding in Appendix A.

     In calls to Commit_AS, the iss input is the issuer identifier of the
     Authorization Server signing the new commitment object, and acti and
     actp are the workflow and profile values being preserved for that
     workflow state.



  Prasad, et al.           Expires 2 November 2026               [Page 24]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  7.10.  Common Cryptographic Operations

     The verified profiles use a small number of proof-input templates.
     This section defines them once so that profile sections can state
     only their profile-specific substitutions.

     Let:

     *  profile be the active actp value;
     *  acti be the stable actor-chain identifier;
     *  prev_state be either the returned base64url initial_chain_seed
        from bootstrap or the verified prior commitment digest string from
        actc.curr, as required by the profile;
     *  visible_actor_chain_for_hop be the exact ordered actor-visible
        chain for the hop after appending the authenticated current actor;
     *  workflow_sub be the exact preserved workflow sub string for the
        hop being extended within the current issuer domain;
     *  TC_next be the canonical target_context for the next hop, often
        the object { "aud": aud } but extended when local policy needs
        finer-grained target binding; and
     *  [N] denote the canonical ActorID JSON object representation of the
        authenticated current actor.

     Symbols such as TC_B, TC_C, and TC_next denote the canonical
     target_context for the corresponding next hop.

     Proof-bound profiles instantiate the following generic step-proof
     payload template:

     {::nomarkdown} <sourcecode type="json"> Sign_N({ "ctx": ds(profile),
     "acti": acti, "prev": prev_state, "sub": workflow_sub, "act":
     EncodeVisibleChain(visible_actor_chain_for_hop), "target_context":
     TC_next }) </sourcecode> {:/nomarkdown}

     The domain-separation string ds is profile-specific:

     *  actor-chain-verified-full-step-sig-v1 for Verified Full
        Disclosure;
     *  actor-chain-verified-subset-step-sig-v1 for Verified Subset
        Disclosure; and
     *  actor-chain-verified-actor-only-step-sig-v1 for Verified Actor-
        Only Disclosure.









  Prasad, et al.           Expires 2 November 2026               [Page 25]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     These strings remain distinct even though the verified branch step-
     proof payload members are structurally aligned.  The signed step-
     proof payload does not carry actp or another explicit profile
     identifier, and the meaning of the act member remains profile-
     dependent.  Distinct domain-separation strings are therefore REQUIRED
     to bind the proof to the intended verified profile semantics and to
     prevent cross-profile proof confusion or accidental proof reuse.

     In same-domain verified chain-extension hops, the step proof also
     binds the exact preserved workflow sub string for that hop.  This
     protects against same-domain silent subject substitution without
     requiring this base specification to cryptographically bind later
     cross-domain sub aliasing.

     The profile-specific meaning of visible_actor_chain_for_hop is:

     *  for *Verified Full Disclosure*, the full visible chain for the hop
        after appending the authenticated current actor;
     *  for *Verified Subset Disclosure*, the exact inbound visible chain
        verified by the current actor, with that current actor appended;
        and
     *  for *Verified Actor-Only Disclosure*, that same exact inbound
        disclosed visible chain verified by the current actor, with that
        current actor appended, even though the returned ordinary token
        later discloses only [N].

     For verified subset-disclosure operation, any visible act disclosed
     to the next recipient in this JWT/JWS binding MUST be derived from
     the verified visible_actor_chain_for_hop and MUST be an ordered
     subsequence of it.  A singleton current-actor-only form [N] is
     syntactically representable under subset disclosure, but this
     document also defines explicit actor-only profiles so that such
     policy remains machine-readable.  Omission of act is also permitted
     under the subset profiles.  A future recipient-protected disclosure
     mechanism MAY define stronger redisclosure from Authorization-Server-
     retained authoritative workflow state without requiring the
     presenting actor to learn the broader disclosure, but that is outside
     this base specification.

  8.  Profile Selection and Workflow Immutability

     This specification uses capability discovery plus explicit profile
     selection, not interactive profile negotiation.

     An actor requesting a token under this specification MUST select
     exactly one actor_chain_profile value for that request.  The
     Authorization Server MUST either issue a token whose actp equals that
     requested profile identifier or reject the request.



  Prasad, et al.           Expires 2 November 2026               [Page 26]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     For a given workflow instance identified by acti, actp is immutable.
     Accordingly, every accepted chain state within that workflow instance
     carries the same actp.  Any token exchange, cross-domain re-issuance,
     or Refresh-Exchange that would change actp for that workflow instance
     MUST be rejected.  A current actor MUST reject any returned token
     whose actp differs from the profile it requested or from the
     preserved profile state already represented by the inbound token.

     Profile switching therefore requires starting a new workflow instance
     with a new acti, not continuing an existing accepted chain state.

  9.  Common Validation Procedures

     This section gives the short validation checklists that the profile
     sections reuse.  Detailed enforcement rules for actor authentication
     inputs, proof-key binding, intended-recipient handling, and replay or
     freshness are collected later in "Common Security and Enforcement
     Requirements".

     Implementations can think of validation in three layers:

     *  *Layer 1: Admission* -- JWT signature, issuer trust, expiry,
        audience, intended-recipient checks, and any locally established
        presenting-actor or current-actor continuity checks required for
        that processing step.
     *  *Layer 2: Profile authorization* -- interpretation of the visible
        nested act according to actp and application of local
        authorization policy using only the visible chain that the profile
        exposes.
     *  *Layer 3: Continuity and audit evidence* -- validation of actc,
        step proofs, acknowledgments, and retained Authorization Server
        records.

     Recipients that only consume an inbound token MAY apply Layer 3
     according to local policy.  Current actors that extend a verified
     workflow, and Authorization Servers that accept verified profile
     token exchange, MUST validate the inbound actc and any required step
     proof before extending the workflow.

  9.1.  Recipient Validation of an Inbound Token

     Unless a profile states otherwise, a recipient validating an inbound
     actor-chain token MUST verify:

     *  token signature;
     *  issuer trust;
     *  profile identifier (actp);




  Prasad, et al.           Expires 2 November 2026               [Page 27]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  presence and correct format of profile-required structural claims
        (actc and any profile-required disclosed act according to actp);
     *  expiry and replay requirements;
     *  intended-recipient requirements; and
     *  any profile-specific disclosed-chain checks.

     If a disclosed act is present, a recipient MUST decode the visible
     chain as VisibleChain(act) and apply the profile-specific checks on
     that visible chain.  If the selected profile requires disclosed
     current-actor continuity and the recipient establishes a presenting-
     actor identity for the inbound hop under local policy, the recipient
     MUST also verify that the outermost act identifies that same
     presenting actor.  If the selected profile requires inline act
     disclosure, omission of act, or presence of an act that violates the
     profile's required disclosure rules, MUST be treated as a profile-
     validation failure.

     A recipient MUST use only the actor-chain information actually
     disclosed in the inbound artifact for authorization.  It MUST treat
     undisclosed prior actors, and an undisclosed current actor, as
     unavailable from that artifact.

  9.2.  Authorization Server Validation of Token Exchange

     Unless a profile states otherwise, an Authorization Server validating
     an actor-chain token exchange MUST verify:

     *  the inbound token signature and issuer trust;
     *  the authenticated identity of the current actor;
     *  intended-recipient semantics for the inbound token;
     *  the selected profile identifier and any profile-specific step-
        proof requirements;
     *  the preserved acti and sub continuity expected for the workflow;
        and
     *  any profile-specific disclosed-chain checks on any inbound act.

     If the inbound token discloses visible chain state, the Authorization
     Server MUST decode VisibleChain(act_in) from the inbound token
     exactly as verified for the current actor and MUST perform only
     append-only operations on that disclosed visible chain fragment.  If
     the selected profile requires disclosed current-actor continuity, the
     Authorization Server MUST additionally verify that the outermost act
     of the inbound token identifies the same actor that authenticated as
     the current actor and is presenting that inbound hop for exchange.
     If the selected profile requires inline act disclosure, omission of
     act, or presence of an act that violates the profile's required
     disclosure rules, MUST be treated as a profile-validation failure.




  Prasad, et al.           Expires 2 November 2026               [Page 28]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     This specification does not define validation or handling rules for
     may_act.  Any effect of may_act is determined by RFC 8693, by the
     specification governing the artifact that carries it, or by local
     policy.  Such use MUST NOT cause an artifact issued under this
     specification, or any related protocol-visible outcome, to disclose
     actor-chain information that the selected profile would withhold.

     A token-exchange request under this specification MAY additionally
     carry the RFC 8693 actor_token and actor_token_type parameters.  This
     specification does not define whether or how actor_token contributes
     actor-related policy input.  Any such effect is determined by RFC
     8693, by the specification governing that artifact, or by local
     policy.  Such use MUST NOT expand disclosure beyond the selected
     profile and Authorization Server policy, and MUST NOT alter required
     acti, actp, or sub continuity.

     If neither may_act nor actor_token contributes actor-related policy
     input, the Authorization Server applies local policy.  For this
     specification, local policy can include trust relationships,
     authenticated client identity, permitted target contexts, chain-depth
     limits, profile support, and business or risk controls.

  9.3.  Current-Actor Validation of a Returned Token

     Unless a profile states otherwise, a current actor validating a
     returned token MUST verify:

     *  token signature and issuer trust;
     *  that the returned actp equals the requested profile identifier and
        any preserved active profile state;
     *  that the returned acti equals the actor-chain identifier already
        represented by the inbound token or bootstrap state;
     *  that the returned sub equals the expected preserved workflow-
        subject value;
     *  expiry and replay requirements; and
     *  any profile-specific disclosed-chain or commitment checks.

     If a returned token discloses act, the current actor MUST verify that
     the disclosed act conforms to the selected profile and Authorization
     Server policy for that hop.  If the selected profile requires inline
     act disclosure, omission of act, or presence of an act that violates
     the profile's required disclosure rules, MUST be treated as a
     profile-validation failure.

     For readable full-disclosure profiles, the current actor MUST verify
     that the returned visible chain equals the full verified chain for
     that hop.  For subset-disclosure profiles, if the returned token
     discloses act, the current actor MUST verify that the returned



  Prasad, et al.           Expires 2 November 2026               [Page 29]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     visible chain is an ordered subsequence of the exact verified actor-
     visible chain that the actor signed or otherwise caused to be
     asserted for that hop.  For actor-only profiles, the current actor
     MUST verify that the returned visible act consists only of the
     outermost current actor and that this actor is the current actor that
     requested or caused the hop.

  10.  Profiles

     The profile selection table appears earlier in "Scope and Model".
     The sections below present the ordinary chain-extending profile flows
     first.  Each profile depends on the common recipient, Authorization
     Server, and returned-token validation procedures defined earlier,
     plus the later common security and enforcement rules.  Special
     preserve-state exchanges, metadata, and deeper enforcement details
     appear later so they do not interrupt the main profile story.

  11.  Declared Full Disclosure Profile

  11.1.  Profile Identifier

     The profile identifier string for this profile is declared-full.  It
     is used as the actor_chain_profile token request parameter value and
     as the actp token claim value.

  11.2.  Objective

     The Declared Full Disclosure profile extends token exchange by
     carrying the full visible nested act chain in every ordinary token
     and by requiring chain-continuity validation by both the current
     actor and the issuing Authorization Server at each hop.

  11.3.  Security Model

     This profile provides hop-by-hop visible-chain integrity based on
     issuer-asserted chain state and continuity checks.

     This profile assumes that an actor does not collude with its home
     Authorization Server.

  11.4.  Bootstrap

     At workflow start, actor A MUST request a token from AS1 with:

     *  grant_type=client_credentials;
     *  actor_chain_profile=declared-full; and
     *  the requested OAuth targeting parameters (audience, resource, or
        both) sufficient to identify B as the initial target context.



  Prasad, et al.           Expires 2 November 2026               [Page 30]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     If AS1 accepts the request, AS1 MUST establish the workflow subject
     according to local policy before issuing T_A.  At bootstrap under
     these base profiles, AS1 MUST choose a stable workflow-subject
     representation for sub that is appropriate for the selected
     disclosure policy.  AS1 MUST then issue T_A containing at least:

     *  actp=declared-full
     *  sub
     *  act=EncodeVisibleChain([A])
     *  acti
     *  jti
     *  aud=B
     *  exp

  11.5.  Hop Processing

     When A calls B, A MUST present T_A to B.

     B MUST perform recipient validation as described in "Recipient
     Validation of an Inbound Token".

     B MUST decode VisibleChain(T_A.act) and verify that its last actor is
     A.

     If that continuity check fails, B MUST reject the request.

  11.6.  Token Exchange

     To call C, B MUST submit to AS1 at least:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;
     *  actor_chain_profile=declared-full;
     *  T_A as the RFC 8693 subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;
        and
     *  the requested OAuth targeting parameters (audience, resource, or
        both as needed by local policy) sufficient to identify C as the
        next target context.

     B MAY additionally submit RFC 8693 actor_token and actor_token_type
     parameters subject to the common validation rules in "Authorization
     Server Validation of Token Exchange".

     AS1 MUST perform token-exchange validation as described in
     "Authorization Server Validation of Token Exchange".

     AS1 MUST read the prior visible chain from T_A.act, append B, and
     issue T_B containing at least:



  Prasad, et al.           Expires 2 November 2026               [Page 31]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  actp=declared-full
     *  sub
     *  act=EncodeVisibleChain([A,B])
     *  acti
     *  jti
     *  aud=C
     *  exp

  11.7.  Returned Token Validation

     Upon receipt of T_B, B MUST perform current-actor returned-token
     validation as described in "Current-Actor Validation of a Returned
     Token".

     B MUST verify that VisibleChain(T_B.act) is exactly the previously
     verified chain from T_A with B appended.

     If that append-only check fails, B MUST reject T_B.

  11.8.  Next-Hop Validation

     Upon receipt of the final B-token, C MUST perform recipient
     validation as described in "Recipient Validation of an Inbound
     Token".

     C MUST decode VisibleChain(T_B.act) and use that visible chain for
     authorization decisions.

  11.9.  Security Result

     Under the non-collusion assumption, prior actors MUST NOT be silently
     inserted, removed, reordered, or altered during token exchange.

  12.  Declared Subset Disclosure Profile

  12.1.  Profile Identifier

     The profile identifier string for this profile is declared-subset.
     It is used as the actor_chain_profile token request parameter value
     and as the actp token claim value.











  Prasad, et al.           Expires 2 November 2026               [Page 32]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  12.2.  Objective

     This profile inherits the Declared Full Disclosure profile and
     changes the visible chain carried across hops: the issuing
     Authorization Server MAY carry and disclose only a recipient-specific
     ordered subset of the asserted chain state for the hop, or MAY omit
     act entirely.  Although a singleton current-actor-only visible chain
     is syntactically representable here, deployments that require actor-
     only policy to be explicit and machine-readable SHOULD use the Actor-
     Only profile instead.

  12.3.  Inheritance and Security Model

     Except as modified below, all requirements of the Declared Full
     Disclosure profile apply.

     When this profile discloses act, the visible chain seen by a
     recipient, obtained from VisibleChain(act), MUST be an ordered
     subsequence of the asserted chain state for that hop.

     A recipient MUST treat undisclosed prior actors as unavailable and
     MUST NOT infer adjacency, absence, or exact chain length from the
     disclosed subset alone.  If an inbound token under this profile omits
     act, or discloses act without the current actor, this specification
     provides no inline current-actor disclosure for that hop.  Any
     additional authorization inputs are determined by local policy and
     are outside the scope of this specification.

     This profile relies on the issuing Authorization Server for
     continuity of the asserted chain state and for disclosure policy.
     The Authorization Server MAY retain authoritative workflow chain
     state richer than the disclosed subset for audit, forensics, legal
     review, and branch reconstruction.  In this base JWT/JWS binding,
     however, the returned token is visible to the current actor and to
     the next recipient, so the disclosed act in that token MUST be
     acceptable for both.

     Cross-domain re-issuance preserves only the visible asserted state
     carried in the inbound token unless a trusted companion mechanism
     explicitly transfers additional hidden state.  This profile does not
     provide the step-proof-based accountability or cumulative commitment
     state of the verified profiles.

  12.4.  Modified Bootstrap and Issuance

     At bootstrap, the initial actor MUST request a token with at least:

     *  grant_type=client_credentials;



  Prasad, et al.           Expires 2 November 2026               [Page 33]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  actor_chain_profile=declared-subset; and
     *  the requested OAuth targeting parameters (audience, resource, or
        both) sufficient to identify the initial target context.

     At bootstrap and at each later exchange, wherever the Declared Full
     Disclosure profile would issue a token containing a full visible act
     chain, this profile MUST instead either issue a recipient-specific
     disclosed visible act chain for the intended recipient or omit act
     entirely according to local policy.  When disclosed, the chain MAY be
     the singleton current actor if that is what policy permits.

  12.5.  Modified Hop Processing and Validation

     Where the Declared Full Disclosure profile requires presentation or
     validation of a full visible chain, this profile instead requires
     presentation and validation of any disclosed subset carried in act,
     if present.

  12.6.  Modified Token Exchange

     For this profile, the current actor MUST submit at least:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;
     *  actor_chain_profile=declared-subset;
     *  the inbound token as the RFC 8693 subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;
        and
     *  the requested OAuth targeting parameters (audience, resource, or
        both as needed by local policy) sufficient to identify the next
        target context.

     The current actor MAY additionally submit RFC 8693 actor_token and
     actor_token_type parameters subject to the common validation rules in
     "Authorization Server Validation of Token Exchange".

     For this profile, the issuing Authorization Server MUST derive the
     next-hop asserted chain state from accepted workflow state for the
     inbound hop, append the current actor to that accepted chain state,
     and then derive any disclosed visible chain for the returned token by
     selecting an ordered subsequence of the resulting asserted chain
     state or by omitting act entirely.  It MUST NOT insert, reorder, or
     alter actor identities in any disclosed act.

     Because the returned token is visible to the current actor in this
     base binding, the Authorization Server MUST NOT disclose in that
     returned token any actor identity that the current actor is not
     permitted to learn.




  Prasad, et al.           Expires 2 November 2026               [Page 34]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     If an inbound token under this profile discloses act, the current
     recipient MUST validate the disclosed subset according to this
     profile.  If a returned token under this profile discloses act, the
     current actor MUST validate that disclosed subset according to this
     profile.

     Unlike the Declared Full Disclosure profile, the current actor and
     downstream recipient do not independently validate the hidden
     undisclosed portion of the prior chain.  They validate only the
     disclosed subset they receive.

  12.7.  Next-Hop Authorization

     A recipient MAY use any disclosed visible chain for authorization
     decisions.

     A recipient MUST use only the disclosed visible chain, if any, for
     actor-chain authorization and MUST treat undisclosed actors as
     unavailable.  If the token omits act, or discloses act without the
     current actor, this specification provides no inline current-actor
     disclosure for that hop.  Any additional authorization inputs are
     determined by local policy and are outside the scope of this
     specification.

  12.8.  Security Result

     Under the non-collusion assumption, silent insertion, removal,
     reordering, or alteration of the disclosed chain seen by a recipient
     is prevented with respect to what the issuing Authorization Server
     asserted for that recipient.

     This profile does not by itself prevent confused-deputy behavior.

  13.  Declared Actor-Only Disclosure Profile

  13.1.  Profile Identifier

     The profile identifier string for this profile is declared-actor-
     only.  It is used as the actor_chain_profile token request parameter
     value and as the actp token claim value.











  Prasad, et al.           Expires 2 November 2026               [Page 35]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  13.2.  Objective

     This profile inherits the Declared Subset Disclosure profile and
     fixes the ordinary-token visible act disclosure to the singleton
     outermost current actor only.  Inline act disclosure is therefore
     mandatory for every ordinary token under this profile.  It is
     intended for workflows in which each hop authorizes only on its
     immediate upstream actor while the Authorization Server retains
     richer workflow state for later audit, forensics, or legal review.

  13.3.  Inheritance and Security Model

     Except as modified below, all requirements of the Declared Subset
     Disclosure profile apply.

     The Authorization Server MAY retain authoritative workflow chain
     state richer than the singleton visible act disclosed in ordinary
     tokens, but every ordinary token issued under this profile MUST
     expose only the current actor for that hop.  Recipients MUST
     authorize only on that visible current actor and local policy.

  13.4.  Modified Bootstrap and Issuance

     At bootstrap, the initial actor MUST request a token with at least:

     *  grant_type=client_credentials;
     *  actor_chain_profile=declared-actor-only; and
     *  the requested OAuth targeting parameters (audience, resource, or
        both) sufficient to identify the initial target context.

     At bootstrap and at each later exchange, wherever the Declared Subset
     Disclosure profile would issue a token containing a disclosed visible
     act chain, this profile MUST instead issue a token whose visible act
     contains exactly one ActorChainNode identifying the actor represented
     by that ordinary token.

  13.5.  Modified Hop Processing and Validation

     Where the Declared Subset Disclosure profile requires presentation or
     validation of a disclosed visible chain, this profile instead
     requires validation that the visible act contains only the current
     actor for this hop.

  13.6.  Modified Token Exchange

     For this profile, the current actor MUST submit at least:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;



  Prasad, et al.           Expires 2 November 2026               [Page 36]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  actor_chain_profile=declared-actor-only;
     *  the inbound token as the RFC 8693 subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;
        and
     *  the requested OAuth targeting parameters (audience, resource, or
        both as needed by local policy) sufficient to identify the next
        target context.

     For this profile, the issuing Authorization Server MUST validate the
     inbound visible act as current-actor-only, preserve and extend the
     accepted workflow state for the authenticated current actor according
     to local policy, and issue the returned token with a visible act
     containing exactly one ActorChainNode identifying the actor
     represented by that returned token.  The Authorization Server MUST
     NOT disclose prior actors inline in ordinary tokens under this
     profile.

  13.7.  Next-Hop Authorization

     A recipient MUST authorize only on the visible outermost current
     actor and local policy.

  13.8.  Security Result

     Under the non-collusion assumption, silent alteration of the visible
     current actor is prevented with respect to what the issuing
     Authorization Server asserted for that recipient.  Prior actors
     remain available only through Authorization Server records or other
     out-of-band evidence.

  14.  Common Processing for the Verified Branch

     This section defines the bootstrap, proof, commitment, token-
     exchange, and returned-token rules shared by the three verified
     profiles.  In this branch, ordinary tokens still carry the hop-to-hop
     token state, but each chain- extending hop is also backed by an
     actor-signed step proof and cumulative commitment state:

     *  Verified Full Disclosure;
     *  Verified Subset Disclosure; and
     *  Verified Actor-Only Disclosure.

     The profile sections that follow define only the profile-specific
     meaning of the actor-visible chain for the hop, the ordinary-token
     disclosure policy, and the corresponding validation and authorization
     rules.





  Prasad, et al.           Expires 2 November 2026               [Page 37]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  14.1.  Common Parameters

     Each verified profile supplies the following profile-specific
     parameters to the common processing below.

     +============+===========+============+===============+=============+
     | Profile    | actp      | Step-proof | Proof-bound   | Visible act |
     |            | value     | domain-    | actor-        | in ordinary |
     |            |           | separation | visible       | tokens      |
     |            |           | string     | chain for     |             |
     |            |           |            | hop           |             |
     +============+===========+============+===============+=============+
     | Verified   | verified- | actor-     | Full          | Full        |
     | Full       | full      | chain-     | visible       | verified    |
     | Disclosure |           | verified-  | chain for     | visible     |
     |            |           | full-step- | the hop       | chain       |
     |            |           | sig-v1     | after         |             |
     |            |           |            | appending     |             |
     |            |           |            | the current   |             |
     |            |           |            | actor         |             |
     +------------+-----------+------------+---------------+-------------+
     | Verified   | verified- | actor-     | Exact         | Ordered     |
     | Subset     | subset    | chain-     | inbound       | subsequence |
     | Disclosure |           | verified-  | disclosed     | of the      |
     |            |           | subset-    | visible       | verified    |
     |            |           | step-      | chain         | actor-      |
     |            |           | sig-v1     | verified by   | visible     |
     |            |           |            | the current   | chain, or   |
     |            |           |            | actor, with   | omitted act |
     |            |           |            | that actor    |             |
     |            |           |            | appended      |             |
     +------------+-----------+------------+---------------+-------------+
     | Verified   | verified- | actor-     | Exact         | Singleton   |
     | Actor-Only | actor-    | chain-     | inbound       | current     |
     | Disclosure | only      | verified-  | disclosed     | actor only  |
     |            |           | actor-     | visible       |             |
     |            |           | only-step- | chain         |             |
     |            |           | sig-v1     | verified by   |             |
     |            |           |            | the current   |             |
     |            |           |            | actor, with   |             |
     |            |           |            | that actor    |             |
     |            |           |            | appended      |             |
     +------------+-----------+------------+---------------+-------------+

                                    Table 2






  Prasad, et al.           Expires 2 November 2026               [Page 38]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     The profile identifier, step-proof domain-separation string, and the
     profile-specific interpretation of act therefore remain aligned
     across the verified branch.

  14.2.  Common Bootstrap Context Request

     At workflow start, the initial actor MUST request a bootstrap context
     from the Authorization Server's actor_chain_bootstrap_endpoint using
     at least:

     *  grant_type=urn:ietf:params:oauth:grant-type:actor-chain-bootstrap;
     *  the selected verified profile actor_chain_profile; and
     *  the requested OAuth targeting parameters (audience, resource, or
        both) sufficient to identify the initial target context.

     The Authorization Server MUST authenticate the initial actor, bind
     that actor to its ActorID representation, select a commitment hash
     algorithm, mint a fresh acti, choose a stable workflow-subject
     representation for sub, derive the bootstrap target context from the
     requested targeting parameters, and return a bootstrap response
     containing at least:

     *  actor_chain_bootstrap_context, an opaque bootstrap handle;
     *  acti;
     *  sub;
     *  halg;
     *  target_context, the exact canonical bootstrap-bound target context
        against which the initial step proof will be validated; and
     *  initial_chain_seed, a base64url value to be used as prev_state for
        the initial verified step proof.

     The initial_chain_seed MUST be generated using a CSPRNG with at least
     128 bits of entropy, MUST be unique per workflow instance, and MUST
     NOT be derived solely from acti or other predictable inputs.

     The bootstrap context MUST be integrity-protected by the
     Authorization Server, bound to the authenticated initial actor, the
     selected verified profile, the chosen acti, sub, halg, and the
     bootstrap target context, and be short-lived.  It authorizes issuance
     of initial verified ordinary tokens for that workflow instance while
     it remains valid.










  Prasad, et al.           Expires 2 November 2026               [Page 39]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     For a given canonical chosen initial target_context, the
     Authorization Server MUST treat repeated redemption of the same
     bootstrap handle as an idempotent retry and MUST return the
     previously accepted initial state, or an equivalent token
     representing that same accepted initial state.  It MUST NOT issue a
     second distinct accepted initial state for that same canonical chosen
     initial target_context.

     The Authorization Server MAY accept additional redemptions of the
     same bootstrap handle for distinct canonical chosen initial
     target_context values, thereby minting multiple accepted initial
     successors that share the same acti and initial_chain_seed.  If a
     deployment expects multiple distinct initial successors under the
     same nominal target, the chosen initial target_context MUST include a
     unique request_id.

  14.3.  Common Initial Actor Step Proof and Bootstrap Issuance

     After receiving the bootstrap response, the initial actor A MUST
     choose the initial target context to be used for the first issued
     token.  That chosen initial target context MUST be identical to, or a
     locally authorized narrowing of, the canonical bootstrap-bound
     target_context returned in the bootstrap response.  Because there are
     no prior actors at workflow start, the profile-defined actor-visible
     chain for that initial hop is [A] for all verified profiles.  A MUST
     then sign an actor_chain_step_proof over that initial chain, the
     exact preserved workflow sub string returned in the bootstrap
     response, and the chosen initial target context, and redeem the
     bootstrap context at the token endpoint using at least:

     *  grant_type=client_credentials;
     *  the selected verified profile actor_chain_profile;
     *  actor_chain_bootstrap_context;
     *  actor_chain_step_proof; and
     *  the requested OAuth targeting parameters (audience, resource, or
        both) sufficient to identify that chosen initial target context.















  Prasad, et al.           Expires 2 November 2026               [Page 40]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     The Authorization Server MUST verify the bootstrap context and verify
     that the authenticated actor redeeming it is the same actor to which
     the bootstrap context was issued.  It MUST also verify that the
     requested profile matches the bound bootstrap profile, that the
     chosen target context is identical to or narrower than the bootstrap-
     bound target context according to local policy, that the submitted
     step proof ctx equals the active profile's domain- separation string,
     that the submitted step proof sub equals the bound workflow sub
     string, and that the submitted step proof is otherwise valid.  It
     then creates the initial actc and issues an ordinary token containing
     at least iss, actp, acti, sub, jti, aud, exp, and actc, and any
     profile-governed disclosed act.

     Because the initial verified hop has no prior visible actors, the
     exact verified actor-visible chain for that hop is [A].  The returned
     ordinary token MUST disclose that chain as
     act=EncodeVisibleChain([A]) for the Verified Full Disclosure and
     Verified Actor-Only Disclosure profiles.  For Verified Subset
     Disclosure, the Authorization Server MAY either disclose
     act=EncodeVisibleChain([A]) or omit act entirely according to local
     policy.  When Verified Subset operation omits bootstrap act,
     subsequent disclosed visible-predecessor continuity begins from the
     empty disclosed chain, while commitment continuity remains anchored
     by the initial verified step proof and actc.

  14.4.  Common Hop Processing

     When a current actor N receives an inbound verified profile token, it
     MUST:

     *  validate the inbound token and any required actc;
     *  determine, under local policy, any presenting-actor identity for
        the inbound hop needed by the selected profile;
     *  derive the profile-defined actor-visible chain for the new hop;
     *  sign actor_chain_step_proof over that visible chain, the preserved
        workflow sub string for the hop, and the next target context; and
     *  submit the inbound token plus the step proof in a token exchange
        request to its home Authorization Server.

  14.5.  Common Token Exchange

     For a chain-extending verified profile token exchange, the current
     actor MUST submit at least:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;
     *  the selected verified profile actor_chain_profile;
     *  the inbound token as the RFC 8693 subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;



  Prasad, et al.           Expires 2 November 2026               [Page 41]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  actor_chain_step_proof; and
     *  the requested OAuth targeting parameters sufficient to identify
        the next target context.

     The current actor MAY additionally submit RFC 8693 actor_token and
     actor_token_type parameters subject to the common validation rules in
     "Authorization Server Validation of Token Exchange".

     The Authorization Server MUST validate the inbound token, validate
     the step proof for the active profile, MUST verify that the step
     proof ctx equals the active profile's domain-separation string, MUST
     verify that the step proof sub equals the preserved workflow sub
     string for the hop being extended, verify append-only processing of
     the profile-defined actor-visible chain, update actc, and return an
     ordinary token whose act representation matches the profile's
     disclosure rules for the next recipient.  Replay, idempotency, and
     multiple-successor handling for submitted step proofs are defined
     later in "Replay and Freshness".

  14.6.  Common Returned-Token Validation

     When validating a returned verified profile token, the current actor
     MUST perform the common returned-token validation described earlier
     and MUST also verify:

     *  that actc is present and valid;
     *  that the returned token preserves acti, actp, and sub as required;
     *  that the embedded actc payload preserves the expected acti, actp,
        and halg values for the active workflow state;
     *  that actc.prev equals the previously verified prior commitment
        digest, or the initial_chain_seed for the initial verified hop;
     *  that actc.step_hash equals b64url(Hash_halg(step_proof_bytes))
        computed over the exact compact JWS string submitted as
        actor_chain_step_proof for that hop; and
     *  any profile-specific disclosed-chain checks for the active
        disclosure mode.















  Prasad, et al.           Expires 2 November 2026               [Page 42]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Because actc is cumulative commitment state carried inline in
     verified profile ordinary tokens, every later actor and every
     Authorization Server that extends the verified workflow relies on
     that inline actc value.  Online validation of an inbound or returned
     actc proves issuer-signed commitment continuity and internal
     commitment consistency.  It does not by itself prove the semantic
     meaning of step_hash against the underlying step proof unless the
     exact step proof bytes and related verification material are also
     retained or discoverable for later audit.  Deployments MAY vary on
     whether every terminal recipient performs synchronous actc validation
     at admission time, but chain extension MUST NOT proceed without
     successful validation of the inbound actc.

     For non-repudiation, participation, or later semantic interpretation,
     deployments SHOULD retain the exact step-proof artifact and
     associated verification context used when validating commitment
     linkage.

  15.  Verified Full Disclosure Profile

  15.1.  Profile Identifier

     The profile identifier string for this profile is verified-full.  It
     is used as the actor_chain_profile token request parameter value and
     as the actp token claim value.

  15.2.  Objective

     The Verified Full Disclosure profile is the full-disclosure verified
     case.  It preserves a visible nested act chain in every ordinary
     token for every actor and downstream recipient while adding per-hop
     actor-signed step proofs and cumulative commitment state.

  15.3.  Security Model

     Bootstrap, Common Token Exchange, and Common Returned-Token
     Validation follow the Common Processing for the Verified Branch
     section.  This profile inherits all requirements of that common
     verified processing and specializes them to the full-disclosure
     visible case.

     This profile preserves visible chain-based authorization and provides
     stronger accountability and non-repudiation than the Declared Full
     Disclosure profile.

     This profile does not guarantee inline prevention of every invalid
     token that could be issued by a colluding actor and its home
     Authorization Server.



  Prasad, et al.           Expires 2 November 2026               [Page 43]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     The evidentiary value of this profile depends on retention or
     discoverability of step proofs, exchange records, and associated
     verification material.

  15.4.  Profile-Specific Hop Construction and Validation

     For a current actor N, let chain_in be the full visible chain
     verified from the inbound token.  If N establishes a presenting actor
     for the inbound hop under local policy, N MUST verify that the last
     actor in chain_in is that same presenting actor.

     The exact verified actor-visible chain for the hop is the full
     visible append-only chain:

     {::nomarkdown} <sourcecode type="text"> visible_hop_N = chain_in +
     [N] </sourcecode> {:/nomarkdown}

     The Authorization Server MUST issue EncodeVisibleChain(visible_hop_N)
     as the visible act in the returned token.

     A recipient MUST use the full visible chain for authorization
     decisions.

  15.5.  Attack Handling

     A claim that actor V participated in the chain MUST fail unless a
     valid step proof for V can be produced and verified against the
     corresponding prior commitment state and acti.

     If an actor is omitted from a later visible chain, that omitted actor
     MAY prove prior participation by presenting:

     *  an earlier token showing the prior chain state; and
     *  the corresponding commitment state and verifiable step proof, or
        an immutable Authorization Server exchange record.

     A denial of participation by actor X MUST fail if a valid step proof
     for X is available and verifies.

  15.6.  Security Result

     This profile preserves visible chain-based authorization while making
     tampering materially easier to detect, prove, and audit.

  16.  Verified Subset Disclosure Profile






  Prasad, et al.           Expires 2 November 2026               [Page 44]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  16.1.  Profile Identifier

     The profile identifier string for this profile is verified-subset.
     It is used as the actor_chain_profile token request parameter value
     and as the actp token claim value.

  16.2.  Objective

     This profile is the visible subset-disclosure verified case.  The
     issuing Authorization Server MAY disclose only a recipient-specific
     ordered subset of the verified actor-visible chain, while the current
     actor signs the exact actor-visible chain that it was allowed to
     verify and extend for the hop.  This preserves stronger continuity
     and later verifiability without requiring full inline disclosure at
     every hop.

  16.3.  Security Model

     Bootstrap, Common Token Exchange, and Common Returned-Token
     Validation follow the Common Processing for the Verified Branch
     section.  This profile inherits all requirements of that common
     verified processing.

     When this profile discloses act, the visible chain seen by a
     recipient, obtained from VisibleChain(act), MUST be an ordered
     subsequence of the verified actor-visible chain for that hop.

     Step proofs and actc values MUST be computed over the exact actor-
     visible chain for the hop, not over a hidden canonical full chain
     that the current actor was not permitted to see.

     A recipient MUST treat undisclosed prior actors as unavailable and
     MUST NOT infer adjacency, absence, exact chain length, or hidden
     prefixes from the disclosed subset alone.

     Accordingly, this profile preserves continuity over the exact
     disclosed actor-visible chain available at each hop together with
     cumulative commitment state.  It does not by itself guarantee
     visible-predecessor continuity for actors hidden by disclosure
     policy, including the bootstrap case where act is omitted.

     The Authorization Server MAY retain authoritative workflow chain
     state richer than the disclosed subset for audit, forensics, legal
     review, and branch reconstruction.  In this base JWT/JWS binding,
     however, the returned token is visible to the current actor and to
     the next recipient, so the returned visible act MUST be acceptable
     for both.  Accordingly, a later privileged recipient can learn more
     than an earlier intermediary only at a hop where every holder of the



  Prasad, et al.           Expires 2 November 2026               [Page 45]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     returned token is permitted to learn that broader disclosure, or by
     using a future recipient-protected disclosure mechanism outside this
     base specification.

  16.4.  Profile-Specific Hop Construction and Validation

     For a current actor N, let chain_in be the exact disclosed inbound
     visible chain that N verified from the inbound token, or the empty
     chain if the inbound token disclosed no act.  If chain_in is non-
     empty and N establishes a presenting actor for the inbound hop under
     local policy, N MUST verify that its last actor is that same
     presenting actor.

     The exact verified actor-visible chain for the hop is:

     {::nomarkdown} <sourcecode type="text"> visible_hop_N = chain_in +
     [N] </sourcecode> {:/nomarkdown}

     The current actor N MUST append only itself and MUST NOT insert,
     delete, or reorder prior actors within chain_in.

     The Authorization Server MUST verify that the submitted visible chain
     equals the exact inbound disclosed chain previously verified by N,
     with N appended.  An omitted inbound act corresponds to the empty
     chain_in value.

     Any visible act disclosed to the next recipient in this base binding
     MUST be derived from the exact verified actor-visible chain for that
     hop and MUST be an ordered subsequence of it.  The singleton [N] is
     the actor-only disclosure shape, and omission of act is also
     permitted under this profile.

     When validating a returned token, the current actor N MUST
     additionally verify, if the returned token discloses act, that the
     disclosed chain, obtained from VisibleChain(act), is an ordered
     subsequence of the exact verified actor-visible chain that N signed
     for that hop.

     A recipient MAY use the verified disclosed visible chain for
     authorization decisions, but MUST use only the disclosed subset and
     MUST treat undisclosed prior actors as unavailable.  If the token
     omits act, or discloses act without the current actor, this
     specification provides no inline current-actor disclosure for that
     hop.  Any additional authorization inputs are determined by local
     policy and are outside the scope of this specification.






  Prasad, et al.           Expires 2 November 2026               [Page 46]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  16.5.  Attack Handling

     Different recipients MAY receive different valid disclosed subsets
     derived from the same verified actor-visible chain according to local
     disclosure policy.  That alone does not constitute an integrity
     failure.

     A malicious or compromised Authorization Server could still attempt
     to issue a disclosed subset inconsistent with the verified actor-
     visible chain.  Such an inconsistency MUST fail if the retained step
     proof for that hop or an immutable Authorization Server exchange
     record is later checked.

     An actor omitted from a disclosed chain MAY still prove prior
     participation by presenting the corresponding step proof or immutable
     Authorization Server exchange record for the verified actor-visible
     chain for the relevant hop.

     When this profile omits act, or discloses only a narrow subset, later
     reconstruction of the full accepted chain from step proofs alone is
     not guaranteed.  Such reconstruction can require retained
     Authorization Server records or other authoritative workflow
     evidence.  In those cases, the current actor's signature provides
     non-repudiation only over the exact actor-visible chain for that hop
     and the linked prior commitment digest, not over hidden prefix
     semantics that the actor was not permitted to verify.

  16.6.  Security Result

     This profile preserves Authorization-Server-validated continuity,
     cumulative commitment state, and recipient-specific limited visible
     authorization while avoiding disclosure of hidden prior actors beyond
     the subset visible in the returned ordinary token.

  17.  Verified Actor-Only Disclosure Profile

  17.1.  Profile Identifier

     The profile identifier string for this profile is verified-actor-
     only.  It is used as the actor_chain_profile token request parameter
     value and as the actp token claim value.










  Prasad, et al.           Expires 2 November 2026               [Page 47]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  17.2.  Objective

     This profile inherits the common verified processing and keeps the
     actor-signed step proof and cumulative actc continuity state, while
     restricting ordinary tokens to the singleton outermost current actor
     only.  It is intended for end-to-end execution pipelines in which
     each hop authorizes only on the immediate upstream actor even though
     the Authorization Server retains richer authoritative workflow state
     for later forensics, legal audit, or branch reconstruction.

  17.3.  Security Model

     Except as modified below, all requirements of the common verified
     processing section apply.

     The current actor signs the exact verified actor-visible chain for
     the hop, but the ordinary token returned for the next hop MUST
     disclose only the current actor.  Recipients therefore authorize only
     on the visible current actor plus local policy, while actc and
     retained step proofs preserve stronger continuity evidence for later
     review.

  17.4.  Profile-Specific Hop Construction and Validation

     For each hop under this profile, the current actor MUST construct the
     profile-defined verified actor-visible chain as the exact inbound
     disclosed visible chain that the actor verified, with that actor
     appended.  The step proof MUST carry that exact actor-visible chain
     in its act member.

     Where Verified Subset Disclosure permits any ordered subsequence of
     the verified actor-visible chain to appear in the returned ordinary
     token, this profile instead requires the issuing Authorization Server
     to return a visible act containing exactly one ActorChainNode
     identifying the actor represented by the returned token.  The
     returned token MUST still carry the updated cumulative actc state.

     Upon receipt of the returned token, the current actor MUST verify
     that the returned visible act consists only of the current actor and
     that the returned actc matches the accepted successor state for the
     verified hop.

     Upon receipt of the token, the next recipient MUST perform recipient
     validation and authorize only on the visible current actor and local
     policy.  If the recipient establishes a presenting actor for the
     inbound token under local policy, it MUST also confirm that the
     visible current actor matches that same presenting actor.




  Prasad, et al.           Expires 2 November 2026               [Page 48]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  17.5.  Attack Handling

     If a returned ordinary token under this profile discloses any prior
     actor inline, the current actor MUST reject it.  If a recipient under
     this profile attempts to infer hidden prior actors from omission,
     identifier structure, or actc alone, that behavior is out of profile
     and MUST NOT be treated as a conforming authorization decision.

  17.6.  Security Result

     Under the non-collusion assumption and when step proofs and actc are
     retained as required by local policy, silent alteration of the
     current actor in ordinary tokens is prevented and stronger continuity
     evidence remains available for later forensic or legal review, while
     inline disclosure remains restricted to the current actor only.

  18.  Special Preserve-State Exchanges

     These sections define the two token-exchange cases that preserve
     previously accepted chain state rather than appending a new actor.
     They are easiest to read after the ordinary profile flows.

     A token-exchange request under this specification MUST NOT set both
     actor_chain_cross_domain=true and actor_chain_refresh=true.  The
     Authorization Server MUST reject any request that sets both.

     For preserve-state exchanges (actor_chain_cross_domain=true or
     actor_chain_refresh=true), the Authorization Server MUST apply an
     explicit preserve-state authorization policy.  Unless deployment
     policy explicitly selects transport-only renewal semantics, the
     Authorization Server MUST re-evaluate current authorization for the
     authenticated current actor and the requested target context before
     issuing the preserved-state token.  If current policy does not permit
     issuance, the Authorization Server MUST reject the request.

  18.1.  Cross-Domain Re-Issuance

  18.1.1.  Request Format

     If the next hop does not trust the current Authorization Server
     directly, the current actor MUST perform a second token exchange at
     the next domain's Authorization Server.

     A cross-domain re-issuance request MUST include:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;
     *  actor_chain_cross_domain=true;




  Prasad, et al.           Expires 2 November 2026               [Page 49]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  actor_chain_profile set to the active profile identifier carried
        by the inbound token;
     *  the current inbound actor-chain token as the RFC 8693
        subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;
        and
     *  any requested OAuth targeting parameters (audience, resource, or
        both) for the local target context to be minted by the re-issuing
        Authorization Server.

     The re-issuing Authorization Server MUST ensure that any locally
     minted target context is semantically equivalent to, or narrower
     than, the target context authorized by the inbound token according to
     local trust policy and audience mapping rules.  When the earlier
     chain-extending hop bound a target_context richer than plain aud, the
     re-issuing Authorization Server MUST evaluate that equivalence or
     narrowing against the exact retained or otherwise recoverable prior
     target_context, not against aud alone.  It MUST NOT issue a local
     token whose target context is broader than, or semantically unrelated
     to, the target context authorized by the inbound token.

     A cross-domain re-issuance request MUST NOT append the chain and MUST
     NOT submit actor_chain_step_proof, because this exchange preserves
     rather than extends the accepted chain state.  The
     actor_chain_cross_domain parameter is the explicit wire signal that
     the request is for preservation and local re-issuance rather than
     ordinary same-domain chain extension.

  18.1.2.  Preservation Rules

     The cross-domain Authorization Server MUST:

     *  validate the inbound token signature and issuer trust according to
        local policy;
     *  validate the selected actor-chain profile;
     *  validate the preserved visible-chain structure;
     *  preserve actp;
     *  preserve acti;
     *  preserve actc, if present, exactly as verified;
     *  enforce preserve-state authorization policy for this re-issuance
        request as required above;
     *  continue to represent the same current actor; and
     *  NOT append the next recipient.

     Visible act handling during cross-domain re-issuance is profile-
     specific:





  Prasad, et al.           Expires 2 November 2026               [Page 50]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  for the Full Disclosure profiles and the Actor-Only profiles, the
        re-issuing Authorization Server MUST preserve the visible act
        exactly, except that if an inbound visible node omitted iss, the
        re-issuing Authorization Server MAY materialize that iss
        explicitly only to preserve the same ActorID semantics;
     *  for the Subset Disclosure profiles, if the inbound token discloses
        act, the re-issuing Authorization Server MAY preserve that visible
        act exactly, disclose any ordered subsequence of that inbound
        visible chain, or omit act entirely according to local policy; it
        MUST NOT introduce any actor not present in the inbound visible
        chain, reorder actors, or use hidden retained state to broaden
        disclosure; when a returned visible node would otherwise rely on
        inherited issuer context, the re-issuing Authorization Server MAY
        materialize the corresponding iss explicitly only to preserve the
        same ActorID semantics; and
     *  if the inbound token omits act, the re-issuing Authorization
        Server MUST NOT synthesize a visible act from hidden retained
        state.

  18.1.3.  Subject Handling

     For top-level sub, the re-issuing Authorization Server SHOULD
     preserve the exact inbound value when doing so preserves the same
     underlying subject semantics and does not broaden disclosure.  If
     exact preservation would change subject semantics under the new
     issuer namespace or would disclose more than the inbound token
     disclosed, the re-issuing Authorization Server MAY translate sub into
     a local alias that denotes the same underlying subject and MUST
     retain an audit binding between the old and new subject
     representations.  If the re-issuing Authorization Server cannot
     establish same-subject semantic continuity without broader
     disclosure, it MUST reject the request.  Once such a local alias is
     accepted in cross-domain re-issuance, that returned sub value becomes
     the preserved workflow-subject representation for later same-domain
     validation within the new issuer domain.

     This specification cryptographically binds same-domain workflow-
     subject continuity through verified step proofs.  It does not
     cryptographically bind cross-domain sub alias continuity in preserved
     actc.  Accordingly, preserved actc continuity across cross-domain re-
     issuance MUST NOT be interpreted as cryptographic proof that the pre-
     translation and post- translation sub values are bound by this
     specification to the same subject representation.  In this version,
     cross-domain subject-alias continuity remains a matter of
     Authorization-Server policy and retained audit evidence.






  Prasad, et al.           Expires 2 November 2026               [Page 51]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Future companion specifications MAY define privacy-preserving
     Authorization Server-to-Authorization Server transfer of additional
     hidden workflow state.  Such mechanisms are outside this base
     specification.  This document's cross- domain rules preserve only the
     visible state allowed by policy together with any preserved actc
     state defined here.

  18.1.4.  ActorID Namespace Handling

     Each visible act entry uses ActorID semantics over (iss, sub).  If an
     inbound act node omitted iss, the re-issuing Authorization Server
     MUST preserve the same ActorID semantics by emitting an explicit iss
     equal to the inbound token's issuer together with the same actor sub,
     rather than relying on the new local token issuer as an implicit
     namespace.  Internal canonicalization for proof, comparison, and
     ordered-subsequence evaluation in this document therefore always uses
     fully materialized ActorID pairs.

     The cross-domain Authorization Server MAY mint a new local jti, apply
     a new local expiry, change token format or envelope, and add local
     trust or policy claims.  If cross-domain re-issuance narrows or
     locally rewrites the target context, retained step proofs and
     preserved actc continue to reflect the target context that was bound
     during the original chain-extending hop, not the narrower or
     rewritten token audience issued by the re-issuing Authorization
     Server.

     Accordingly, when such narrowing or rewriting occurs, the current re-
     issued token's audience or other local target representation MUST NOT
     be interpreted as if it were itself the target context
     cryptographically bound by the earlier step proof or by preserved
     actc.  In this case, the re-issued token carries a current
     presentation context for local use, while the preserved proof-bound
     context remains that of the original chain-extending hop.

     A recipient or current actor in the new domain that trusts the re-
     issuing Authorization Server MAY rely on that enclosing token
     signature as attestation that any preserved foreign actc was
     validated and carried forward unchanged.  Such a recipient need not
     independently validate a foreign Authorization Server's JWS signature
     on the preserved actc unless local policy or audit requires it.

     The base specification does not define a portable cryptographic
     lineage field that identifies the exact inbound token instance from
     which a returned cross- domain re-issued token was derived.
     Accordingly, exact input-token provenance for a re-issued token
     remains a matter of Authorization-Server records or of a future
     companion specification that defines such a lineage field.



  Prasad, et al.           Expires 2 November 2026               [Page 52]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  18.1.5.  Returned-Token Validation

     When validating a token returned by cross-domain re-issuance, the
     current actor does not recompute a new commitment object from a new
     step proof.  Instead, it MUST verify the token signature and MUST
     verify that preserved chain-state fields, including actp, acti, and
     actc, preserve the same accepted chain state as the inbound token
     except where this specification explicitly permits cross-domain re-
     issuance changes such as local sub aliasing under the semantic-
     equivalence rule, local jti, local exp, token format or envelope,
     approved local trust and policy claims, or explicit iss
     materialization in act solely to preserve the same ActorID semantics
     when an inbound node had omitted iss.  For Full Disclosure and Actor-
     Only profiles, any returned visible act MUST preserve the inbound
     visible act exactly except for such permitted iss materialization.
     For Subset Disclosure profiles, any returned visible act, if present,
     MUST be an ordered subsequence of the inbound visible chain and MUST
     NOT introduce any actor not visible in the inbound token.

  18.2.  Refresh-Exchange

     A current actor MAY use token exchange to refresh a short-lived
     transport token without appending the actor chain or regenerating a
     step proof.

  18.2.1.  Request Format

     A Refresh-Exchange request MUST include:

     *  grant_type=urn:ietf:params:oauth:grant-type:token-exchange;
     *  actor_chain_refresh=true;
     *  actor_chain_profile set to the active profile identifier carried
        by the inbound token;
     *  the current inbound actor-chain token as the RFC 8693
        subject_token;
     *  subject_token_type=urn:ietf:params:oauth:token-type:access_token;
     *  the same authenticated current actor that is continuing that
        accepted chain state; and
     *  any requested OAuth targeting parameters (audience, resource, or
        both).  If omitted, the requested target context is the same as
        the inbound token's target context as represented by aud and any
        locally retained target-selection context associated with that
        accepted token state.

     A Refresh-Exchange request MUST NOT include actor_chain_step_proof,
     because Refresh-Exchange preserves rather than extends the accepted
     chain state.




  Prasad, et al.           Expires 2 November 2026               [Page 53]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     A Refresh-Exchange request MUST NOT broaden the active profile,
     represented actor identity, visible chain state visible to the
     current actor, commitment state, or target context.  The requested
     target context MUST be identical to, or a locally authorized
     narrowing of, the target context already represented by the inbound
     token and any associated retained target-selection state according to
     local policy.  Such narrowing MUST preserve the same recipient
     identity; it MUST NOT retarget the token to an audience or resource
     server not already present in the inbound token's canonical
     target_context.

  18.2.2.  Processing Rules

     When processing Refresh-Exchange, the Authorization Server MUST:

     *  validate the inbound token and the identity of the current actor;
     *  verify that the requested profile identifier exactly matches the
        inbound token's actp;
     *  verify intended-recipient semantics as applicable;
     *  enforce preserve-state authorization policy for this refresh
        request as required above;
     *  verify that the request does not append the chain, alter preserved
        chain state, broaden target context, or change recipient identity;
        and
     *  issue a replacement token with a new jti and refreshed exp.

     For Refresh-Exchange, the Authorization Server MUST preserve acti,
     actp, sub, act, if present, and actc, if present, exactly as verified
     for the current actor.  A new step proof MUST NOT be required, and a
     new commitment object MUST NOT be created.  If Refresh-Exchange
     narrows the target context, retained step proofs and preserved actc
     continue to reflect the target context that was bound during the
     original chain-extending hop, not the narrower refreshed target
     context.

     This specification does not define or require any particular token-
     binding, presenter-binding, or key-transition mechanism for Refresh-
     Exchange.  If a deployment changes such transport or authentication
     properties during refresh, that handling is governed by local policy
     and any companion specifications rather than by this document.
     Historical step proofs remain bound to the keys used when those
     proofs were created and MUST be verified against those historical
     bindings, not against later local authentication material.








  Prasad, et al.           Expires 2 November 2026               [Page 54]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     A recipient or coordinating component MUST treat a token obtained by
     Refresh-Exchange as representing the same accepted chain state as the
     inbound token from which it was refreshed.  If local policy records a
     presenter-binding or key-transition event, later verifiers rely on
     those local records or other retained evidence for that event itself.

  18.2.3.  Returned-Token Validation

     When validating a token returned by Refresh-Exchange, the current
     actor does not recompute a new commitment object from a new step
     proof.  Instead, it MUST verify the token signature and MUST verify
     that preserved chain-state fields, including actp, acti, sub, act,
     and actc, are unchanged from the inbound token except where this
     specification explicitly permits refresh- specific changes such as
     jti, exp, or locally managed transport metadata.

  19.  Optional Receiver Acknowledgment Extension

     A recipient MAY produce a receiver acknowledgment artifact, called
     hop_ack, for an inbound actor-chain token.  This OPTIONAL extension
     does not alter chain progression semantics.

     A valid hop_ack proves that the recipient accepted responsibility for
     the identified hop, bound to the actor-chain identifier, the
     identified inbound hop state, recipient, target context, and the
     acknowledged inbound token instance via inbound_jti.  For verified
     profiles, the stronger workflow-level correlation anchors are acti
     together with the inbound commitment digest for that hop; inbound_jti
     remains the token-instance trace field.  If the deployment
     establishes a presenter ActorID for the acknowledged hop under local
     policy, hop_ack MAY additionally bind that presenter.  For declared
     profiles, the inbound hop state is the verified visible act from the
     inbound token when that profile disclosed act on the acknowledged
     hop.  For verified profiles, that inbound hop state is the verified
     inbound commitment digest extracted from the inbound token's
     actc.curr.

     A recipient can issue a valid hop_ack only if it can either
     deterministically derive or receive the exact canonical
     target_context value for the acknowledged hop.  When target_context
     extends beyond plain aud, the caller or a coordinating component MUST
     communicate that exact canonical JSON value to the recipient by an
     integrity-protected application mechanism before expecting a matching
     hop_ack.







  Prasad, et al.           Expires 2 November 2026               [Page 55]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     A hop_ack is ordinarily returned to the presenting actor or to a
     coordinating component acting for that hop.  It MAY later be
     archived, forwarded, or made available to an audit service or other
     authorized dispute-resolution component under local policy.

     hop_ack MUST NOT by itself append the recipient to the actor chain.

     A recipient MUST NOT emit hop_ack with status accepted until it has
     either:

     *  completed the requested operation; or
     *  durably recorded sufficient state to recover, retry, or otherwise
        honor the accepted request according to local reliability policy.

     A deployment MAY require hop_ack for selected hops, including
     terminal hops.  Deployments that require evidence of terminal
     acceptance SHOULD require a valid hop_ack for those terminal hops.
     When hop_ack is required by policy, the calling actor and any
     coordinating component MUST treat that hop as not accepted unless a
     valid hop_ack is received and verified.

     Deployments that rely on hop_ack for later audit or dispute
     resolution SHOULD ensure that the caller side and the recipient side
     each retain the artifact, or records sufficient to validate and
     contextualize it, for the applicable audit period.  For example, a
     downstream agent might bill the presenting agent only for work that
     it accepted.  In that case, the recipient-signed hop_ack helps both
     sides later prove exactly which hop, target context, and accepted
     inbound artifact are in scope.

     hop_ack does not by itself prove successful completion or correctness
     of the requested operation.

     Recipients are not required to issue hop_ack for rejected, malformed,
     abusive, unauthorized, or rate-limited requests.  Absence of hop_ack
     is sufficient to prevent proof of acceptance.

     When a deployment needs hop_ack to acknowledge multiple distinct
     operations performed under the same inbound token and the same
     nominal target, it MUST include a request-unique request_id inside
     target_context.

     The acknowledgment payload MUST include at least:

     *  ctx = actor-chain-hop-ack-v1;
     *  acti;
     *  actp;
     *  jti, a unique identifier for the hop_ack JWT itself;



  Prasad, et al.           Expires 2 November 2026               [Page 56]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  inbound_jti, copied from the acknowledged inbound token;
     *  OPTIONAL presenter, the presenting actor's ActorID when
        established under local policy for that hop;
     *  recipient, the acknowledging recipient's ActorID;
     *  target_context;
     *  iat, a JWT NumericDate recording when the acknowledgment was
        issued;
     *  exp, a short-lived JWT NumericDate;
     *  for declared profiles, OPTIONAL inbound visible act when that
        profile disclosed act on the acknowledged hop;
     *  for verified profiles, inbound_commitment, the verified inbound
        commitment digest copied directly from the inbound token's
        actc.curr; and
     *  ack, whose value MUST be accepted.

     A hop_ack MUST be signed by the recipient using JWS.

  19.1.  Receiver Acknowledgment Validation

     A caller or coordinating component that receives hop_ack and relies
     on it for acceptance processing MUST verify at least:

     *  the JWS signature using the recipient identity and keying material
        expected by local trust policy;
     *  the JWS protected header contains typ=act-hop-ack+jwt;
     *  ctx=actor-chain-hop-ack-v1;
     *  acti equals the actor-chain identifier of the inbound token for
        which acknowledgment is being evaluated;
     *  actp equals the active profile of that inbound token;
     *  jti is unique for the acknowledgment artifact under local replay
        policy;
     *  inbound_jti equals the jti of the inbound token that was actually
        sent to the recipient;
     *  if presenter is present, it equals the presenting actor
        established under local policy for the acknowledged hop;
     *  recipient equals the recipient from which acknowledgment is
        expected;
     *  target_context equals the exact canonical target context that was
        requested, communicated, or deterministically derived for the
        acknowledged hop;
     *  iat is present and acceptable under local clock policy;
     *  exp has not expired;
     *  for declared profiles, if act is present, the carried act equals
        the inbound visible act for the acknowledged hop and MUST NOT
        disclose more than that acknowledged hop disclosed;
     *  for verified profiles, inbound_commitment equals the verified
        inbound commitment digest copied from the inbound token's
        actc.curr; and



  Prasad, et al.           Expires 2 November 2026               [Page 57]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  the ack member is present and its value equals accepted.

     When the inbound token being acknowledged was obtained by cross-
     domain re-issuance or Refresh-Exchange, the target_context compared
     here is the exact canonical value for that acknowledged presentation.
     Any preserved step proofs and actc from an earlier chain-extending
     hop continue to reflect the target context of that earlier hop, not a
     later locally rewritten audience, unless those values are identical.

  20.  Common Security and Enforcement Requirements

     This section collects enforcement requirements that all profiles rely
     on but that need not be read before the main profile flows.
     Implementations still MUST satisfy these requirements even when they
     are consulted later in a first reading pass.

  20.1.  JOSE and Parser Hardening

     Implementations validating ordinary tokens, step proofs, hop_ack, and
     actc MUST apply strict JOSE and JSON parsing behavior to avoid
     implementation-differential acceptance.

     At minimum, validators MUST:

     *  reject duplicate member names in any JSON object that contributes
        to profile-defined validation, signature verification,
        canonicalization, or commitment inputs;
     *  reject malformed compact JWS syntax, including malformed base64url
        segments;
     *  reject unsupported critical JOSE headers as defined in Artifact
        Typing and the JWT binding appendix;
     *  enforce exact expected claim types for profile-defined claims
        before semantic processing (for example, actp, acti, iss, sub, and
        jti as strings; target_context as an object where required by this
        specification; and actc as a compact JWS string when required);
     *  treat type mismatch as a profile-validation failure; and
     *  for verified profiles, treat missing actc as a profile-validation
        failure.

  20.2.  Actor Authentication and Presenter Binding

     This specification does not define or require any particular actor-
     authentication, presenter-binding, or token-binding mechanism.
     Authorization Servers and recipients MAY establish current-actor or
     presenting-actor identity using any locally trusted method.
     Recipient authorization policy based on such inputs is outside the
     scope of this specification.




  Prasad, et al.           Expires 2 November 2026               [Page 58]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     When deployment policy depends on a specific presenter-binding or
     token-binding mechanism class (for example mTLS-anchored or DPoP-
     anchored processing), that mechanism class MUST be fixed by local
     policy or a companion profile and MUST NOT be inferred from actor-
     chain artifacts alone.

  20.3.  Actor and Recipient Proof Keys

     For verified profiles and for hop_ack, any signature used as a
     profile-defined proof MUST be generated with an asymmetric key whose
     verification material is trusted under local policy for the actor or
     recipient identity represented in that artifact.

     For a verified profile step proof, the ActorID represented in the
     proof and the key used to sign the proof MUST be bound to the same
     actor identity under local trust policy.  The Authorization Server
     MUST verify the proof using trusted verification material for that
     actor identity before accepting the proof.

     For hop_ack, the recipient ActorID and the key used to sign the
     acknowledgment MUST likewise be bound to the same recipient identity
     under local trust policy.  If presenter is included in a hop_ack,
     that value MUST be established under local policy and MUST NOT expand
     disclosure beyond the selected profile.

     Shared client secrets MUST NOT be the sole basis for independently
     verifiable step proofs or receiver acknowledgments.

     Deployments that rely on later verification of archived step proofs
     or acknowledgments MUST retain, or be able to recover, the
     verification material and identity-binding records needed to validate
     those signatures during the applicable audit period.  Deployments
     that claim verified-profile auditability beyond Authorization-Server-
     only trust SHOULD also retain, or be able to recover, the exact
     compact JWS step-proof artifacts and their associated workflow
     context for the applicable audit period, because commitment digests
     alone do not prove which actor signed which hop.

  20.4.  Intended Recipient Validation

     When a current actor submits an inbound token as a subject_token in
     token exchange, the accepting Authorization Server MUST normally
     verify that the authenticated current actor was an intended recipient
     of that inbound token according to local audience, resource, or
     equivalent validation rules.  For actor_chain_refresh=true and
     actor_chain_cross_domain=true, this intended- recipient check does
     not apply, because the current actor is legitimately redeeming a
     token it holds as the presenter in order to refresh or preserve



  Prasad, et al.           Expires 2 November 2026               [Page 59]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     previously established chain state.

     Possession of an inbound token alone is insufficient.

  20.5.  Replay and Freshness

     Recipients and Authorization Servers MUST enforce replay and
     freshness checks on inbound tokens according to local policy.

     For profiles that use actor-signed step proofs, the accepting
     Authorization Server:

     *  MUST detect replay of a previously accepted step proof within its
        replay-retention window;
     *  MUST treat an exact replay of a previously accepted compact-JWS
        step proof for the same authenticated actor and same prior state
        as an idempotent retry, not as a distinct successor;
     *  MUST, for such an idempotent retry, return the previously accepted
        successor state, or an equivalent token representing that same
        accepted successor state, while any required retry record is
        retained; and
     *  SHOULD, during that retry-retention window, retain the exact
        previously issued response or otherwise ensure that a retried
        response carries the same accepted chain state, because
        recomputing with probabilistic signatures can change wire bytes
        even when the decoded accepted state is equivalent; and
     *  MUST reject a different attempted successor for the same (acti,
        prior_state, target_context) tuple unless local policy explicitly
        authorizes replacement or supersession; this base specification
        does not standardize how multiple accepted successors that share
        earlier history are correlated or later merged.  Deployments that
        expect multiple distinct same-target successors SHOULD distinguish
        them by including a unique request_id in target_context.

  21.  Authorization Server Metadata

     Actor-chain capability discovery uses OAuth 2.0 Authorization Server
     Metadata [RFC8414].  This specification does not define a new
     discovery endpoint.  Clients retrieve Authorization Server metadata
     from the RFC 8414 well-known metadata endpoint derived from the
     issuer, verify that the returned issuer matches the configured
     issuer, and then process the actor-chain-specific metadata values
     defined below.

     An Authorization Server supporting this specification SHOULD publish
     metadata describing its supported actor-chain capabilities.





  Prasad, et al.           Expires 2 November 2026               [Page 60]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     This specification defines the following Authorization Server
     metadata values:

     *  actor_chain_bootstrap_endpoint: URL of the Authorization Server
        endpoint used to mint verified profile bootstrap context for
        initial actors;
     *  actor_chain_profiles_supported: array of supported actor-chain
        profile identifiers.  Each value MUST be the exact identifier
        string used both as the actor_chain_profile token request
        parameter value and as the actp token claim value;
     *  actor_chain_commitment_hashes_supported: array of supported
        commitment hash algorithm identifiers;
     *  actor_chain_receiver_ack_supported: boolean indicating whether the
        Authorization Server supports processing and policy for hop_ack;
     *  actor_chain_refresh_supported: boolean indicating whether the
        Authorization Server supports Refresh-Exchange processing under
        this specification; and
     *  actor_chain_cross_domain_supported: boolean indicating whether the
        Authorization Server supports cross-domain re-issuance processing
        under this specification.

     Client behavior is:

     1.  obtain or configure the Authorization Server issuer;
     2.  fetch RFC 8414 metadata from the corresponding well-known
         endpoint;
     3.  verify the returned issuer exactly matches the configured issuer;
     4.  check actor_chain_profiles_supported and any other needed actor-
         chain capability fields; and
     5.  fail closed if the required profile or capability is absent,
         unless local policy explicitly allows fallback to plain RFC 8693
         behavior.

     If omitted, clients MUST NOT assume support for any actor-chain
     profile beyond out-of-band agreement.

  22.  Error Handling

     Token exchange errors in this specification build on OAuth 2.0 and
     OAuth 2.0 Token Exchange.

     An Authorization Server processing a token exchange request applies
     the following mapping:








  Prasad, et al.           Expires 2 November 2026               [Page 61]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


      +=================+==============================================+
      | OAuth error     | Triggering condition                         |
      | code            |                                              |
      +=================+==============================================+
      | invalid_request | Malformed or missing profile-defined         |
      |                 | parameters, malformed bootstrap context,     |
      |                 | malformed ActorID values, malformed          |
      |                 | commitment objects, unsupported profile      |
      |                 | bindings, both actor_chain_cross_domain=true |
      |                 | and actor_chain_refresh=true, or             |
      |                 | structurally malformed inline act            |
      +-----------------+----------------------------------------------+
      | invalid_target  | The requested audience, canonical target     |
      |                 | context, or recipient is not permitted or    |
      |                 | not supported, or a Refresh-Exchange         |
      |                 | attempts to retarget to a different          |
      |                 | recipient                                    |
      +-----------------+----------------------------------------------+
      | invalid_grant   | The subject_token fails validation, the      |
      |                 | intended-recipient check fails, continuity   |
      |                 | fails at token exchange, replay or freshness |
      |                 | checks fail, actor_chain_step_proof          |
      |                 | verification fails, bootstrap-context reuse  |
      |                 | that is neither an idempotent retry nor an   |
      |                 | authorized distinct initial successor is     |
      |                 | detected, required inline act disclosure is  |
      |                 | absent, profile-disclosure rules fail,       |
      |                 | preserve-state authorization policy fails,   |
      |                 | or the submitted prior state is inconsistent |
      |                 | with the claimed profile state               |
      +-----------------+----------------------------------------------+

                                   Table 3

     Implementations SHOULD provide additional machine-readable or human-
     readable diagnostics that distinguish actor-chain-specific failure
     classes that map to the same base OAuth error code.  Such diagnostics
     are for troubleshooting and interoperability support only and MUST
     NOT alter the base OAuth error value required by this specification.
     Examples include diagnostics indicating replay detection, intended-
     recipient failure, step-proof verification failure, profile-
     disclosure failure, or preserved-state inconsistency.









  Prasad, et al.           Expires 2 November 2026               [Page 62]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Recipients and Authorization Servers MUST return protocol-appropriate
     error signals for authentication, authorization, profile-validation,
     and continuity failures.  When the selected profile requires inline
     act disclosure for an artifact, omission of act, or presence of an
     act value that fails that profile's disclosure rules, MUST be treated
     as a profile-validation failure.

     In HTTP deployments, this typically maps to 400-series status codes
     and OAuth-appropriate error values.  In non-HTTP deployments,
     functionally equivalent protocol-native error signaling MUST be used.

     Error responses and logs MUST NOT disclose undisclosed prior actors,
     full step proofs, canonical proof inputs, or other sensitive proof
     material unless the deployment explicitly requires such disclosure
     for diagnostics.

     When deployments provide error_description, error_uri, logs, or
     similar diagnostics for actor-chain failures, they SHOULD distinguish
     among underlying failure causes where doing so does not disclose
     hidden actors, full proofs, or other sensitive material.

  23.  Part II.  Security, Privacy, Deployment, and Rationale

  24.  Motivating Real-World Examples

  24.1.  Full Disclosure: Emergency Production Change in Critical
         Infrastructure

     A safety-critical production environment requires a hotfix during an
     incident.  The workflow is:

     *  A = on-call engineer;
     *  B = incident commander;
     *  C = security approver;
     *  D = deployment service; and
     *  E = runtime control plane.

     Every downstream hop must see the complete visible approval path
     before allowing the change to proceed.  The deployment service and
     runtime control plane both need to verify inline that the on-call
     engineer initiated the action, the incident commander approved it,
     and the security approver signed off.  This is the motivating case
     for the Full Disclosure profiles: every hop needs the same full
     visible lineage for normal online authorization.







  Prasad, et al.           Expires 2 November 2026               [Page 63]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  24.2.  Subset Disclosure: Regulated M&A Review

     A large acquisition review passes through multiple highly sensitive
     business functions.  The workflow is:

     *  A = market-intelligence team;
     *  B = product-strategy review;
     *  C = internal legal review;
     *  D = antitrust counsel; and
     *  E = Chief Executive Officer.

     Intermediate actors are intentionally compartmentalized and may be
     forbidden from learning who else contributed to the decision.  The
     CEO, however, may need a richer disclosed chain before approving the
     transaction.  This is the motivating case for the Subset Disclosure
     profiles: the Authorization Server retains authoritative workflow
     state and discloses to each recipient only the portion of the chain
     that recipient is allowed to learn.

  24.3.  Actor-Only Disclosure: Bank Wire-Payment Processing Pipeline

     A bank processes high-value wire payments through a sequence of
     narrowly scoped control services.  The workflow is:

     *  A = payment-initiation service;
     *  B = sanctions-screening service;
     *  C = fraud-scoring service;
     *  D = treasury and limit-check service;
     *  E = payment-release service; and
     *  F = SWIFT or bank-connector service.

     Each stage authorizes only on the immediately preceding actor for
     that hop.  The sanctions service needs to know only that the payment-
     initiation service invoked it; the fraud service needs to know only
     that sanctions invoked it; and so on.  Revealing the entire upstream
     pipeline to every stage adds no value to the local authorization
     decision and unnecessarily exposes internal control topology.  This
     is the motivating case for the Actor-Only profiles: every hop sees
     only the current actor inline, while richer workflow state may still
     be retained by the Authorization Server for forensic review, legal
     audit, or incident review.

  25.  Security Considerations

     A fuller threat discussion appears in Appendix I.  This section keeps
     only the security considerations that directly affect interoperable
     processing or likely implementation choices.




  Prasad, et al.           Expires 2 November 2026               [Page 64]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  25.1.  Actor Authentication and Presenter Binding Are Deployment-
         Specific

     This specification assumes that Authorization Servers can determine
     the current actor for an exchange and that recipients MAY establish
     the presenting actor for a hop under local policy when needed.  The
     mechanisms that provide those inputs are intentionally outside the
     scope of this specification.

  25.2.  Canonicalization Errors Break Interoperability and Proof Validity

     Any ambiguity in canonical serialization, actor identity
     representation, target representation, or proof payload encoding can
     cause false verification failures or inconsistent commitment values
     across implementations.

  25.3.  Commitment State Is Byte-Oriented

     For JWT bindings in this specification, commitment linkage uses the
     exact compact-JWS proof artifact bytes.  This means commitment state
     is intentionally artifact-byte-oriented rather than normalized to
     semantic proof meaning.  Implementations MUST NOT assume semantically
     equivalent decoded proofs will yield identical step_hash or curr
     values unless the underlying compact-JWS bytes are also identical.
     Parties that need semantic or evidentiary replay SHOULD log and
     retain those exact proof artifacts and verification context.

  25.4.  Readable Chain Does Not Prevent Payload Abuse

     A valid visible act does not imply that the application-layer request
     content is safe, correct, or policy-conformant.  Recipients MUST
     apply local payload validation and authorization.

  25.5.  Verified Profiles Depend on Proof Retention

     The evidentiary benefits of the verified profiles depend on retention
     or recoverability of step proofs, exchange records, and relevant
     verification material.  Without such retention, the profiles still
     provide structured commitment state, but post hoc provability and
     non-repudiation are materially weakened.

     Authorization Servers supporting verified profiles SHOULD retain
     proof state, exchange records, authoritative workflow chain state,
     and the historical verification material needed for later
     verification for at least the maximum validity period of the longest-
     lived relevant token plus a deployment-configured audit window.
     Retention policies SHOULD also account for later verification during
     or after key rotation.



  Prasad, et al.           Expires 2 November 2026               [Page 65]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  25.6.  Subset-Disclosure Profiles Reveal Only a Verified Subset

     Recipients using the subset-disclosure profiles can authorize based
     only on the disclosed visible chain subset that they verify.  They
     MUST treat undisclosed prior actors as unavailable and MUST NOT infer
     adjacency, absence, or exact chain length from the disclosed subset
     alone.

     In this base JWT/JWS binding, the returned ordinary token is visible
     to the current actor and to the next recipient.  Therefore, a
     returned subset-disclosure token cannot safely reveal an actor
     identity that the current actor is not permitted to learn.  A future
     recipient-protected disclosure mechanism MAY relax that limitation,
     but it is outside this base specification.

     A singleton visible chain containing only the current actor is a
     valid subset-disclosure outcome.  In that case, downstream
     authorization is current- actor-only even though the underlying
     profile remains one of the subset profiles unless actp explicitly
     selects an actor-only profile.

     Deployments whose recipient authorization requires prior-path
     membership or ordering evidence MUST ensure that the selected profile
     and disclosure policy expose that required evidence.  They MUST NOT
     treat actor-only or omitted-act outcomes as sufficient for such path-
     sensitive authorization.

  25.7.  Cross-Domain Re-Issuance Must Preserve Chain State

     A cross-domain Authorization Server that re-issues a local token for
     the next recipient MUST preserve the relevant visible chain state
     unchanged.  For sub, it MAY translate the representation only when it
     preserves the same underlying subject semantics and does not broaden
     disclosure.

  25.8.  Branch Reconstruction Is an Audit Concern

     This specification allows an Authorization Server to issue multiple
     successor tokens from one prior accepted state, but it does not
     standardize merge or sibling-discovery semantics across branches.
     Reconstructing a branched call graph is therefore a forensic or
     legal-audit concern rather than a normal online authorization
     requirement.








  Prasad, et al.           Expires 2 November 2026               [Page 66]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Retained Authorization Server records, timestamps, commitment state,
     and causal links among presenting actors, current actors, and
     subsequent actors can often reveal much of the effective call graph,
     but this base specification alone does not guarantee a complete
     standardized graph across all branches.

     This specification does not standardize per-actor causal timestamps
     inside nested act.  Deployments that need branch and time
     reconstruction SHOULD rely on retained Authorization Server records,
     ordinary token or proof timestamps, commitment state, and parent-
     child causal linkage across accepted successor tokens rather than
     embedding chronology fields in visible act entries.

  25.9.  Intended Recipient Checks Reduce Confused-Deputy Risk

     Accepting Authorization Servers MUST ensure that the authenticated
     current actor was an intended recipient of the inbound subject_token.
     This reduces a class of deputy and repurposing attacks, though it
     does not eliminate all confused-deputy scenarios.

  25.10.  Chain Depth

     Authorization Servers SHOULD enforce a configurable maximum chain
     depth.  A RECOMMENDED default is 10 entries.  Relying Parties MAY
     enforce stricter limits.

  25.11.  Key Management

     Actors SHOULD use short-lived keys and/or hardware-protected keys.
     Deployments that require long-term auditability MUST retain, or make
     durably discoverable, the historical verification material needed to
     validate archived step proofs and receiver acknowledgments after key
     rotation.

  26.  Privacy Considerations

     This section keeps the privacy requirements that affect protocol
     behavior.  Additional trust-boundary and operational notes appear in
     Appendix J.

     Readable-chain profiles disclose prior actors to downstream
     recipients.  Deployments that do not require full visible prior-actor
     authorization SHOULD consider one of the subset-disclosure profiles.

     The stable actor-chain identifier acti correlates all accepted hops
     within one workflow instance.  Accordingly, acti MUST be opaque and
     MUST NOT encode actor identity, profile selection, business
     semantics, or target meaning.



  Prasad, et al.           Expires 2 November 2026               [Page 67]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Even in the privacy-preserving profiles, the Authorization Server
     processing token exchange observes the authenticated current actor
     and any retained chain-related state.  Accordingly, these profiles
     reduce ordinary-token disclosure but do not hide prior actors from
     the issuing Authorization Server.

     Deployments concerned with minimization SHOULD consider:

     *  pairwise or pseudonymous actor identifiers;
     *  workflow-local or pairwise sub aliases;
     *  omission of auxiliary claims unless receiving policy depends on
        them; and
     *  the subset-disclosure profiles when partial visible-chain
        disclosure is sufficient.

  26.1.  Subset Disclosure Extensions

     This specification defines subset-disclosure semantics for the
     Declared Subset Disclosure profile and the Verified Subset Disclosure
     profile.  In both profiles, if act is disclosed, the recipient-
     visible act is a profile-defined ordered subsequence of the actor
     chain for that hop, carried as an ordinary visible act claim
     containing only the disclosed subset.  A subset profile MAY also omit
     act entirely.

     When a subset profile discloses act, that representation is the
     interoperable base-wire format for the disclosed subset.

     Deployments MAY additionally use an optional selective-disclosure or
     recipient-protected encoding technique by agreement, including
     Selective Disclosure JWT (SD-JWT) [RFC9901], a future COSE/CBOR
     companion binding, or an encrypted envelope, but only as an auxiliary
     overlay.  Such an overlay MUST NOT replace any required visible
     subset act representation in the interoperable base-wire format; it
     MAY only add an equivalent presentation form whose disclosed value
     matches the same recipient-visible act and does not change any
     required validation result.

     This specification defines the following actor-chain-specific
     constraints on such use:

     *  for the Declared Subset Disclosure profile, any disclosed visible
        chain MUST be an ordered subsequence of the asserted chain state
        for that hop;
     *  for the Verified Subset Disclosure profile, any disclosed visible
        chain MUST be an ordered subsequence of the verified actor-visible
        chain for that hop;




  Prasad, et al.           Expires 2 November 2026               [Page 68]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  if the selected profile uses step proofs or chain commitments,
        those artifacts remain bound to the verified hop progression, not
        to a later disclosed subset;
     *  a verifier MUST treat undisclosed information as unavailable and
        MUST require disclosure of any information needed for
        authorization; and
     *  an encoding used with a Full Disclosure profile MUST reveal the
        full readable chain required by that profile to the recipient
        before authorization.

  27.  Appendix A.  JWT Binding (Normative)

     This appendix defines the JWT and JWS wire representation for
     profile-defined ActorID values, visible act structures, step proofs,
     receiver acknowledgments, and commitment objects.

  27.1.  ActorID in JWT

     An ActorID is a JSON object with exactly two members:

     *  iss: a string containing the issuer identifier; and
     *  sub: a string containing the subject identifier.

     The object MUST be serialized using JCS [RFC8785] whenever it is
     included in profile-defined proof or commitment inputs.

     When actp is present, the visible act structure in a JWT is an
     ActorChainNode.  Newly issued profile-defined nodes MUST contain
     explicit iss and sub, and MAY contain a nested act member whose value
     is the immediately prior visible ActorChainNode.  Validators MUST
     also be able to normalize a validated inbound node that omits iss and
     inherits the enclosing issuer context.

  27.2.  Step Proof in JWT

     The actor_chain_step_proof token request parameter value MUST be a
     compact JWS string [RFC7515].  The JWS protected header MUST contain
     typ=act-step-proof+jwt.  The JWS payload MUST be the UTF-8 encoding
     of a JCS-serialized JSON object.

     Verifiers MUST require exact typ=act-step-proof+jwt matching for this
     artifact class.  The alg header parameter MUST be present and MUST
     identify an asymmetric signature algorithm accepted by local policy;
     alg=none MUST NOT be accepted.  If crit is present, verifiers MUST
     reject unless every listed parameter is understood and processed.

     For all profiles in the verified branch, the payload MUST contain:




  Prasad, et al.           Expires 2 November 2026               [Page 69]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  ctx;
     *  acti;
     *  prev;
     *  sub;
     *  target_context; and
     *  act.

     When this payload is used as commitment input through step_hash, the
     step_proof_bytes value is the ASCII byte sequence of the exact
     compact JWS serialization of the proof artifact.

     The ctx member value MUST equal the profile-specific step-proof
     domain-separation string ds(profile) defined in Common Processing for
     the Verified Branch.  The prev member MUST be the base64url string
     value of the prior commitment digest or bootstrap seed, copied
     directly from the verified inbound actc.curr or bootstrap response,
     respectively.  The sub member MUST be the exact preserved workflow
     sub string for the same-domain hop being extended.  The act member
     MUST be an ActorChainNode structure and denotes the profile-defined
     verified actor-visible chain for the hop.  For the Verified Subset
     Disclosure profile, the returned ordinary-token act MAY disclose any
     ordered subsequence of that verified chain that disclosure policy
     permits, or MAY omit act entirely when that profile and local policy
     permit omission.  For the Verified Actor-Only Disclosure profile, the
     returned ordinary-token act MUST contain only the outermost current
     actor.  The target_context member MUST conform to the representation
     defined in Target Context Requirements.

     The JWS algorithm MUST be an asymmetric algorithm.  The none
     algorithm MUST NOT be used.  The JWS verification key MUST be trusted
     under local policy for the ActorID represented in the proof.

  27.3.  Receiver Acknowledgment in JWT

     A hop_ack, when used in a JWT deployment, MUST be a compact JWS
     string [RFC7515].  The JWS protected header MUST contain typ=act-hop-
     ack+jwt.  The JWS payload MUST be the UTF-8 encoding of a JCS-
     serialized JSON object with at least these members:

     Verifiers MUST require exact typ=act-hop-ack+jwt matching for this
     artifact class.  The alg header parameter MUST be present and MUST
     identify an asymmetric signature algorithm accepted by local policy;
     alg=none MUST NOT be accepted.  If crit is present, verifiers MUST
     reject unless every listed parameter is understood and processed.

     *  ctx;
     *  acti;
     *  actp;



  Prasad, et al.           Expires 2 November 2026               [Page 70]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  jti;
     *  inbound_jti;
     *  iat;
     *  exp;
     *  target_context;
     *  OPTIONAL presenter;
     *  recipient;
     *  for declared profiles, OPTIONAL act as permitted by the selected
        profile's disclosure rules for the acknowledged inbound hop;
     *  for verified profiles, inbound_commitment; and
     *  ack.

     The ctx member value MUST equal actor-chain-hop-ack-v1.  The
     recipient member MUST be an ActorID object.  If presenter is present,
     it MUST be an ActorID object established under local policy for that
     hop.  The ack member MUST have the value accepted.  The jti member
     MUST uniquely identify the hop_ack JWT itself.  The inbound_jti
     member MUST carry the jti value from the acknowledged inbound token.
     The iat and exp members MUST be JWT NumericDate values, and exp
     SHOULD be short-lived according to local policy.  The target_context
     member MUST conform to the representation defined in Target Context
     Requirements.  For declared profiles, the act member, when present,
     MUST carry the verified inbound visible act value and MUST NOT
     disclose more than the selected profile allowed on the acknowledged
     inbound hop.  For verified profiles, the inbound_commitment member
     MUST be copied directly from the verified inbound commitment digest
     extracted from the inbound token's actc.curr.  The JWS signer MUST be
     the recipient, and the verification key MUST be trusted under local
     policy for that recipient ActorID.

  27.4.  Commitment Object in JWT

     The actc claim value MUST be a compact JWS string [RFC7515].  The JWS
     protected header MUST contain typ=act-commitment+jwt.

     Verifiers MUST require exact typ=act-commitment+jwt matching for this
     artifact class.  The alg header parameter MUST be present and MUST
     identify an asymmetric signature algorithm accepted by local policy;
     alg=none MUST NOT be accepted.  If crit is present, verifiers MUST
     reject unless every listed parameter is understood and processed.

     The JWS payload MUST be the UTF-8 encoding of a JCS-serialized JSON
     object with exactly these members:

     *  ctx;
     *  iss;
     *  acti;
     *  actp;



  Prasad, et al.           Expires 2 November 2026               [Page 71]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  halg;
     *  prev;
     *  step_hash; and
     *  curr.

     The meaning of those members is defined in the main text. actc is a
     commitment-ledger artifact, not an access token, and therefore does
     not use access-token lifetime claims such as exp.

  28.  Appendix B.  Compact End-to-End Examples (Informative)

  28.1.  Example 1: Declared Full Disclosure in One Domain

     Assume A, B, and C are governed by AS1.

     1.  A requests a token for B under the Declared Full Disclosure
         profile.
     2.  AS1 issues T_A with act=EncodeVisibleChain([A]) and aud=B.
     3.  A calls B and presents T_A.
     4.  B validates T_A, verifies continuity, and exchanges T_A at AS1
         for a token to C.
     5.  AS1 authenticates B, verifies that B was an intended recipient of
         the inbound token, appends B, and issues T_B with
         act=EncodeVisibleChain([A,B]) and aud=C.
     6.  B validates that the returned visible chain is exactly the prior
         chain plus B.
     7.  B presents T_B to C.
     8.  C validates the token and authorizes based on the visible chain
         [A,B].

  28.2.  Example 2: Declared Subset Disclosure

     Assume A, B, and C use the Declared Subset Disclosure profile and
     accept the issuing AS as the trust anchor for disclosure policy.

     1.  A requests a token for B under the Declared Subset Disclosure
         profile.
     2.  AS1 issues T_A with a recipient-specific disclosed visible act
         intended for B, or omits act entirely according to local policy.
     3.  A calls B and presents T_A.
     4.  B validates the token and uses only the disclosed visible chain,
         if any, for actor-chain authorization.  If act is omitted, this
         specification provides no inline actor-chain input beyond what is
         disclosed; any additional authorization inputs come from local
         policy.
     5.  B exchanges T_A at AS1 for a token to C.





  Prasad, et al.           Expires 2 November 2026               [Page 72]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     6.  AS1 appends B to the accepted workflow state for that hop,
         applies disclosure policy for C, and issues T_B with a recipient-
         specific disclosed visible act, or with no act, according to
         local policy.
     7.  B presents T_B to C.
     8.  C validates the token and authorizes only on the disclosed
         visible chain, if any.  If act is omitted or does not disclose B,
         this specification provides no inline current- actor disclosure
         for that hop, and C treats undisclosed actors as unavailable.

  28.3.  Example 2b: Declared Actor-Only Disclosure

     Assume A, B, and C use the Declared Actor-Only Disclosure profile.

     1.  A requests a token for B under the Declared Actor-Only Disclosure
         profile.
     2.  AS1 issues T_A with act=EncodeVisibleChain([A]) and aud=B.
     3.  A calls B and presents T_A.
     4.  B validates that the visible act identifies only the current
         actor A and authorizes only on that actor and local policy.
     5.  B exchanges T_A at AS1 for a token to C.
     6.  AS1 issues T_B with act=EncodeVisibleChain([B]) and aud=C.
     7.  B presents T_B to C.
     8.  C validates the token and authorizes only on the visible current
         actor B and local policy.

  28.4.  Example 3: Verified Full Disclosure Across Two Domains

     Assume A and B are governed by AS1, while C is governed by AS2.

     1.  A obtains bootstrap context from AS1, signs chain_sig_A, and
         receives T_A with act=EncodeVisibleChain([A]) and actc.
     2.  A calls B with T_A.
     3.  B validates T_A, constructs [A,B], signs chain_sig_B, and
         exchanges T_A at AS1 for a token to C.
     4.  AS1 verifies chain_sig_B submitted as actor_chain_step_proof,
         updates the commitment, and issues T_B with
         act=EncodeVisibleChain([A,B]) and aud=C.
     5.  Because C does not trust AS1 directly, B performs a second
         exchange at AS2.
     6.  AS2 preserves actp, acti, act=EncodeVisibleChain([A,B]), and
         actc, and issues a local token trusted by C that still represents
         B.
     7.  C validates the local token, sees the visible chain [A,B], and
         authorizes accordingly.






  Prasad, et al.           Expires 2 November 2026               [Page 73]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  28.5.  Example 4: Verified Actor-Only Disclosure

     Assume A, B, and C use the Verified Actor-Only Disclosure profile.

     1.  A obtains bootstrap context, signs chain_sig_A over visible chain
         [A], and receives T_A with act=EncodeVisibleChain([A]) and actc.
     2.  A calls B with T_A.
     3.  B validates T_A, verifies that A is the presenter, constructs the
         verified actor-visible chain [A,B], signs chain_sig_B, and
         exchanges T_A at its home AS to obtain T_B for C.
     4.  T_B contains the updated actc and visible
         act=EncodeVisibleChain([B]).
     5.  B presents T_B to C.
     6.  C validates the token and authorizes based only on the disclosed
         current actor B and local policy.  C MUST NOT infer prior-actor
         identity or count from undisclosed information or from actc
         alone.

  28.6.  Example 5: Verified Subset Disclosure

     Assume A, B, and C use the Verified Subset Disclosure profile.

     1.  A obtains bootstrap context, signs chain_sig_A, and receives T_A
         with a recipient-specific disclosed visible act, or with no act,
         plus actc intended for B according to local policy.
     2.  A calls B and presents T_A.
     3.  B validates the token and uses only the disclosed visible chain,
         if any, for actor-chain authorization.  If act is omitted, this
         specification provides no inline actor-chain input beyond what is
         disclosed; any additional authorization inputs come from local
         policy.
     4.  B signs chain_sig_B over the exact actor-visible chain that B
         verified on the inbound hop, with B appended, and exchanges T_A
         at its home AS alongside chain_sig_B as actor_chain_step_proof to
         obtain T_B for C.
     5.  AS1 verifies that submitted chain state, applies disclosure
         policy for C, and issues T_B with a recipient-specific disclosed
         visible act, or with no act, and updated actc.
     6.  B presents T_B to C.
     7.  C validates the token and authorizes only on the disclosed
         visible chain, if any.  If act is omitted or does not disclose B,
         this specification provides no inline current- actor disclosure
         for that hop, and C treats undisclosed actors as unavailable.
     8.  If later audit is needed, the verified actor-visible chain for
         the hop can be reconstructed from retained step proofs together
         with exchange records and, when subset disclosure omitted act,
         any retained Authorization-Server workflow records needed to
         supply hidden continuity context.



  Prasad, et al.           Expires 2 November 2026               [Page 74]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  29.  Appendix C.  Future Considerations (Informative)

  29.1.  Terminal Receipts and Result Attestations

     This specification defines special handling for the first actor in
     order to initialize chain state.  It does not define corresponding
     terminal-hop semantics for a final recipient that performs work
     locally and does not extend the chain further.

     Deployments that need richer terminal execution or result evidence
     MAY compose this specification with companion SPICE provenance work,
     such as Intent Chain [I-D.draft-mw-spice-intent-chain] and Inference
     Chain [I-D.draft-mw-spice-inference-chain], to provide complementary
     WHAT and HOW evidence.  However, this specification itself does not
     define the terminal receipt/execution/result artifact or the precise
     composition rules by which such companion artifacts satisfy terminal-
     hop evidence requirements.

     Future work MAY define:

     *  a terminal receipt proving that the recipient accepted the
        request;
     *  an execution attestation proving that the recipient executed a
        specific operation; and
     *  a result attestation binding an outcome or result digest to the
        final commitment state.

  29.2.  Bootstrap Receipts and Portable Initial-State Evidence

     This specification does not define a bootstrap-signed receipt
     artifact.  Later audit of bootstrap processing therefore relies on
     Authorization Server records, the bootstrap response, the initial
     step proof, and the first issued ordinary token.

     Future work MAY define a portable bootstrap receipt or bootstrap
     attestation artifact if deployments need independently portable
     evidence of workflow initialization outside Authorization Server
     logs.

  29.3.  Receiver Acceptance and Unsolicited Victim Mitigation

     This specification deliberately does not append a recipient merely
     because that recipient was contacted.  It also defines an OPTIONAL
     hop_ack extension that lets a recipient prove accepted responsibility
     for a hop.






  Prasad, et al.           Expires 2 November 2026               [Page 75]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     However, this specification still does not by itself prevent a
     malicious actor from sending a validly issued token to an unsolicited
     victim service.  Future work MAY define stronger receiver-driven
     protections, including:

     *  stronger result attestations for completed terminal work;
     *  a challenge-response model for high-risk terminal hops; and
     *  recipient-issued nonces or capabilities that MUST be bound into
        the final accepted hop.

  29.4.  Subset Disclosure Extensions

     This document now defines baseline Declared Subset Disclosure and
     Verified Subset Disclosure profiles at the actor-chain semantics
     layer.  Future work MAY define stronger or more standardized subset-
     disclosure encodings and verification techniques, including Selective
     Disclosure JWT (SD-JWT) [RFC9901], a future COSE/CBOR companion
     binding, recipient-bound disclosure artifacts, zero-knowledge proofs
     over the canonical full chain, or richer verifier-assisted
     consistency checks against retained proof state.

     Any future encoding or presentation profile MUST preserve the
     disclosure semantics of the selected base profile.  In particular, a
     Full Disclosure profile still requires full visible-chain disclosure
     to the recipient, while subset-disclosure outcomes that reveal only
     the current actor MUST NOT expose hidden actor entries to recipients
     of ordinary tokens merely as digests or selectively revealable
     placeholders.

  29.5.  Semantic-Equivalent Commitment Inputs

     This version binds commitment linkage to exact compact-JWS proof
     bytes.  Future work MAY define an optional semantic-equivalence
     commitment input, for example by hashing a canonical semantic proof
     object while still retaining artifact-byte evidence for provenance
     and non-repudiation.

  29.6.  Branching and Fan-Out

     This specification defines one visible path per issued token and does
     not standardize merge or sibling-discovery semantics across multiple
     descendants that share earlier workflow history.

     An Authorization Server MAY nevertheless mint multiple accepted
     successor tokens from one prior accepted state.  Such branching is
     represented across multiple tokens, not inside one token's nested act
     structure.  Later reconstruction of the resulting call graph is
     primarily a forensic or legal- audit concern.



  Prasad, et al.           Expires 2 November 2026               [Page 76]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Future work MAY define explicit branch identifiers, parent-child
     workflow correlation, tree-structured commitment verification,
     inclusion proofs, partial disclosure across branches, and later merge
     behavior.  Such future work could also help correlate related *WHO*,
     *WHAT*, and *HOW* evidence across companion Actor Chain, Intent Chain
     [I-D.draft-mw-spice-intent-chain], and Inference Chain
     [I-D.draft-mw-spice-inference-chain] deployments.

  29.7.  Evidence Discovery and Governance Interoperability

     Proof-bound profiles derive much of their value from later
     verification of step proofs and exchange records.  Future work MAY
     standardize interoperable evidence discovery, retention, and
     verification-material publication.

     Any such specification should define, at minimum, evidence object
     typing, authorization and privacy controls for cross-domain
     retrieval, stable lookup keys such as jti or acti, error handling,
     and retention expectations.

  30.  Appendix D.  Design Rationale and Relation to Other Work
       (Informative)

     This document complements [RFC8693] by defining chain-aware token-
     exchange profiles.  It also fits alongside the broader SPICE service-
     to-service and attestation work [I-D.ietf-spice-s2s-protocol]
     [I-D.draft-mw-spice-transitive-attestation] and composes with
     companion SPICE provenance work: Actor Chain addresses *WHO* acted,
     Intent Chain [I-D.draft-mw-spice-intent-chain] addresses *WHAT* was
     produced or transformed, and Inference Chain
     [I-D.draft-mw-spice-inference-chain] addresses *HOW* a result was
     computed.

     This specification defines six profiles instead of one deployment
     mode so that implementations can choose among full visible chain-
     based authorization, trust-first partial disclosure, explicit actor-
     only operation, stronger commitment-state accountability, recipient-
     specific commitment-backed partial disclosure, and verified actor-
     only disclosure without changing the core progression model.

     The base specification remains linear.  Branching, richer disclosure
     mechanisms, and evidence-discovery protocols remain future work
     because they require additional identifiers, validation rules, and
     interoperability work.







  Prasad, et al.           Expires 2 November 2026               [Page 77]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  31.  Appendix E.  Implementation Conformance Checklist (Informative)

     An implementation is conformant only if it correctly implements the
     profile it claims to support and all common requirements on which
     that profile depends.

     At a minimum, implementers should verify that they have addressed the
     following:

     +=============================+======================+=============+
     | Requirement                 | Draft section        | Implemented |
     |                             | reference            | [ ]         |
     +=============================+======================+=============+
     | Stable generation and       | Actor-Chain          | [ ]         |
     | preservation of acti, using | Identifier (acti)    |             |
     | a CSPRNG with at least 122  |                      |             |
     | bits of entropy (for        |                      |             |
     | example, standard UUIDv4 or |                      |             |
     | stronger generation)        |                      |             |
     +-----------------------------+----------------------+-------------+
     | Local policy for actor      | Actor Authentication | [ ]         |
     | authentication or presenter | and Presenter        |             |
     | binding, if relied upon     | Binding              |             |
     +-----------------------------+----------------------+-------------+
     | Exact ActorID equality over | Actor Identity       | [ ]         |
     | (iss, sub)                  | Representation       |             |
     +-----------------------------+----------------------+-------------+
     | Canonical serialization for | Canonicalization;    | [ ]         |
     | all proof and commitment    | Target Context       |             |
     | inputs                      | Requirements;        |             |
     |                             | Appendix F           |             |
     +-----------------------------+----------------------+-------------+
     | Intended-recipient          | Intended Recipient   | [ ]         |
     | validation during token     | Validation           |             |
     | exchange                    |                      |             |
     +-----------------------------+----------------------+-------------+
     | Replay and freshness        | Replay and Freshness | [ ]         |
     | handling for tokens and     |                      |             |
     | step proofs                 |                      |             |
     +-----------------------------+----------------------+-------------+
     | Exact append-only checks    | Declared Full        | [ ]         |
     | for full-disclosure         | Disclosure Profile;  |             |
     | profiles                    | Verified Full        |             |
     |                             | Disclosure Profile   |             |
     +-----------------------------+----------------------+-------------+
     | Correct ordered-subsequence | Declared Subset      | [ ]         |
     | validation for subset-      | Disclosure Profile;  |             |
     | disclosure profiles         | Verified Subset      |             |



  Prasad, et al.           Expires 2 November 2026               [Page 78]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     |                             | Disclosure Profile   |             |
     +-----------------------------+----------------------+-------------+
     | Current-actor-only          | Declared Actor-Only  | [ ]         |
     | validation for actor-only   | Disclosure Profile;  |             |
     | profiles                    | Verified Actor-Only  |             |
     |                             | Disclosure Profile   |             |
     +-----------------------------+----------------------+-------------+
     | Exact commitment            | Commitment Function; | [ ]         |
     | verification for verified   | Verified Full        |             |
     | profiles                    | Disclosure Profile;  |             |
     |                             | Verified Subset      |             |
     |                             | Disclosure Profile;  |             |
     |                             | Verified Actor-Only  |             |
     |                             | Disclosure Profile   |             |
     +-----------------------------+----------------------+-------------+
     | Proof-key binding between   | Actor and Recipient  | [ ]         |
     | ActorID and proof signer    | Proof Keys           |             |
     | under local trust policy    |                      |             |
     +-----------------------------+----------------------+-------------+
     | Non-broadening Refresh-     | Refresh-Exchange     | [ ]         |
     | Exchange processing, if     |                      |             |
     | supported                   |                      |             |
     +-----------------------------+----------------------+-------------+
     | Correct binding and one-    | Common Bootstrap     | [ ]         |
     | time redemption of          | Context Request;     |             |
     | bootstrap context for       | Common Initial Actor |             |
     | verified workflows          | Step Proof and       |             |
     |                             | Bootstrap Issuance   |             |
     +-----------------------------+----------------------+-------------+
     | Policy for when hop_ack is  | Optional Receiver    | [ ]         |
     | optional or required        | Acknowledgment       |             |
     |                             | Extension            |             |
     +-----------------------------+----------------------+-------------+
     | Preserve-state handling for | Cross-Domain Re-     | [ ]         |
     | cross-domain re-issuance    | Issuance; Refresh-   |             |
     | and Refresh-Exchange, if    | Exchange             |             |
     | supported                   |                      |             |
     +-----------------------------+----------------------+-------------+
     | Privacy-preserving handling | Error Handling;      | [ ]         |
     | of logs and error messages  | Privacy              |             |
     |                             | Considerations       |             |
     +-----------------------------+----------------------+-------------+

                                   Table 4







  Prasad, et al.           Expires 2 November 2026               [Page 79]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  32.  Appendix F.  Canonicalization Test Vectors (Informative)

     The following illustrative vectors are intended to reduce
     interoperability failures caused by divergent canonicalization.  They
     are not exhaustive, but they provide concrete byte-for-byte examples
     for common JWT/JCS ActorID and target_context inputs.

  32.1.  JWT / JCS ActorID Example

     Input object:

     {::nomarkdown} <sourcecode type="json">
     {"iss":"https://as.example","sub":"svc:planner"
     (https://as.example","sub":"svc:planner")} </sourcecode>
     {:/nomarkdown}

     JCS serialization (UTF-8 bytes rendered as hex):

     {::nomarkdown} <sourcecode type="text">
     7b22697373223a2268747470733a2f2f61732e6578616d706c65222c22737562223a227376633a706c616e6e6572227d
     </sourcecode> {:/nomarkdown}

     SHA-256 over those bytes:

     {::nomarkdown} <sourcecode type="text">
     7a14a23707a3a723fd6437a4a0037cc974150e2d1b63f4d64c6022196a57b69f
     </sourcecode> {:/nomarkdown}

  32.2.  JWT / JCS target_context Example

     Input object:

     {::nomarkdown} <sourcecode type="json">
     {"aud":"https://api.example","method":"invoke","resource":"calendar.read"
     (https://api.example","method":"invoke","resource":"calendar.read")}
     </sourcecode> {:/nomarkdown}

     JCS serialization (UTF-8 bytes rendered as hex):

     {::nomarkdown} <sourcecode type="text">
     7b22617564223a2268747470733a2f2f6170692e6578616d706c65222c226d6574686f64223a22696e766f6b65222c227265736f75726365223a2263616c656e6461722e72656164227d
     </sourcecode> {:/nomarkdown}

     SHA-256 over those bytes:

     {::nomarkdown} <sourcecode type="text">
     911427869c76f397e096279057dd1396fe2eda1ac9e313b357d9cecc44aa811e
     </sourcecode> {:/nomarkdown}



  Prasad, et al.           Expires 2 November 2026               [Page 80]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  33.  Appendix G.  Illustrative Wire-Format Example (Informative)

     This appendix shows one abbreviated decoded JWT payload together with
     one abbreviated decoded actc JWS payload.  The values are
     illustrative and signatures are omitted for readability.

  33.1.  Decoded Access Token Payload Example

     {::nomarkdown} <sourcecode type="json"> { "iss": "https://as.example"
     (https://as.example"), "sub": "svc:planner", "act": { "iss":
     "https://as.example" (https://as.example"), "sub": "svc:planner",
     "act": { "iss": "https://as.example" (https://as.example"), "sub":
     "svc:orchestrator" } }, "aud": "https://api.example"
     (https://api.example"), "exp": 1760000000, "jti":
     "2b2b6f0d3f0f4d7a8c4c3c4f9e9b1a10", "acti":
     "6cb5f0c14ab84718a69d96d31d95f3c4", "actp": "verified-full", "actc":
     "<compact JWS string>" } </sourcecode> {:/nomarkdown}

  33.2.  Decoded actc JWS Example

     Protected header:

     {::nomarkdown} <sourcecode type="json"> {"alg":"ES256","typ":"act-
     commitment+jwt"} </sourcecode> {:/nomarkdown}

     Payload:

     {::nomarkdown} <sourcecode type="json"> { "ctx": "actor-chain-
     commitment-v1", "iss": "https://as.example" (https://as.example"),
     "acti": "6cb5f0c14ab84718a69d96d31d95f3c4", "actp": "verified-full",
     "halg": "sha-256", "prev": "SGlnaGx5SWxsdXN0cmF0aXZlUHJldkRpZ2VzdA",
     "step_hash": "z7mq8c0u9b2C0X5Q2m4Y1q3r7n6s5t4u3v2w1x0y9z8", "curr":
     "Vb8mR6b2vS5h6S8Y6j5X4r3w2q1p0n9m8l7k6j5h4g3" } </sourcecode>
     {:/nomarkdown}

     On the wire, the actc claim carries the usual compact-JWS form:

     {::nomarkdown} <sourcecode type="text"> BASE64URL(protected-header)
     "."  BASE64URL(payload) "."  BASE64URL(signature) </sourcecode>
     {:/nomarkdown}

  34.  Appendix H.  Problem Statement and Deployment Context (Informative)

     [RFC8693] defines the top-level act claim for the current actor and
     allows nested prior actors.  However, prior nested act claims are
     informational only for access-control decisions.  In multi-hop
     systems, especially service-to-service and agentic systems, that is
     not sufficient.



  Prasad, et al.           Expires 2 November 2026               [Page 81]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     Consider:

     {::nomarkdown} <artwork type="ascii-art"> User -> Orchestrator ->
     Planner -> Tool Agent -> Data API </artwork> {:/nomarkdown}

     By the time the request reaches the Data API, the immediate caller
     may or may not be visible in the token, and the upstream delegation
     path is not standardized as a policy input and is not bound across
     successive token exchanges in a way that can be independently
     validated or audited.  This creates several concrete gaps:

     *  downstream policy cannot reliably evaluate the full delegation
        path;
     *  cross-exchange continuity is not standardized;
     *  tampering by an actor and its home AS is not uniformly addressed;
     *  forensic verification of per-hop participation is not
        standardized; and
     *  ordinary tokens may disclose more visible-chain information than
        some deployments are willing to reveal.

  35.  Appendix I.  Threat Model (Informative)

     This specification defines a multi-hop, multi-actor delegation model
     across one or more trust domains.  The security properties provided
     depend on the selected profile, the trust relationship among
     participating Authorization Servers, and the availability of step
     proofs or exchange records where relied upon.

  35.1.  Assets

     The protocol seeks to protect the following assets:

     *  continuity of the delegation path;
     *  integrity of prior-actor ordering and membership;
     *  continuity of the actor represented as current for each hop when
        such continuity is disclosed or otherwise established under local
        policy;
     *  binding of each hop to the intended target;
     *  resistance to replay of previously accepted hop state;
     *  audit evidence for later investigation and proof; and
     *  minimization of prior-actor disclosure where privacy-preserving
        profiles are used.

  35.2.  Adversaries

     Relevant adversaries include:

     *  an external attacker that steals or replays a token;



  Prasad, et al.           Expires 2 November 2026               [Page 82]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     *  a malicious actor attempting to insert, omit, reorder, or
        repurpose hop state;
     *  a malicious actor colluding with its home Authorization Server;
     *  a malicious downstream recipient attempting to over-interpret or
        misuse an inbound token;
     *  an untrusted or compromised upstream Authorization Server in a
        multi-domain path; and
     *  an unsolicited victim service reached by a validly issued token
        without having agreed to participate.

  35.3.  Assumptions

     This specification assumes:

     *  verifiers can validate token signatures and issuer trust;
     *  the authenticated actor identity used in token exchange is bound
        under local trust policy to the actor identity represented in
        profile-defined proofs; and
     *  deployments that rely on later proof verification retain, or can
        discover, the verification material needed to validate archived
        step proofs and exchange records.

  35.4.  Security Goals

     The protocol aims to provide the following properties:

     *  in the Declared Full Disclosure profile, silent insertion,
        removal, reordering, or modification of prior actors is prevented
        under the assumption that an actor does not collude with its home
        Authorization Server;
     *  in the Declared Subset Disclosure profile, ordinary tokens reveal
        only a visible ordered subset of actors selected by the
        Authorization Server, and authorization is limited to that
        disclosed subset;
     *  in the Verified Subset Disclosure profile, each accepted hop is
        bound to an actor-signed proof over the exact actor-visible chain
        for that hop and to cumulative commitment state, while ordinary
        tokens reveal only an ordered subset of that actor-visible chain
        selected by the Authorization Server;
     *  in the Verified Full Disclosure profile, the actor-visible chain
        equals the full visible chain at each hop, preserving full visible
        authorization while improving detectability, provability, and non-
        repudiation; and
     *  in the Verified Actor-Only Disclosure profile, ordinary tokens
        MUST disclose only the current actor while preserving current-
        actor continuity where that continuity is disclosed or otherwise
        established under local policy, together with cumulative
        commitment state for later verification.



  Prasad, et al.           Expires 2 November 2026               [Page 83]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  35.5.  Non-Goals

     This specification does not by itself provide:

     *  integrity or safety guarantees for application payload content;
     *  complete prevention of confused-deputy behavior;
     *  concealment of prior actors from the Authorization Server that
        processes token exchange;
     *  standardized merge or branch-selection semantics across branched
        work; or
     *  universal inline prevention of every invalid token that could be
        issued by a colluding actor and its home Authorization Server.

  35.6.  Residual Risks

     Even when all checks succeed, a valid token chain does not imply that
     the requested downstream action is authorized by local business
     policy.  Recipients MUST evaluate authorization using only the actor-
     chain information actually disclosed to them by the artifact together
     with token subject, intended target, and local policy.

     Deployments that depend on independently verifiable provenance for
     high-risk operations SHOULD require synchronous validation of
     commitment-linked proof state or otherwise treat the issuing
     Authorization Server as the sole trust anchor.

     In the Verified Subset Disclosure and Verified Actor-Only Disclosure
     profiles, a current actor signs only the exact actor-visible chain
     available at that hop.  Those profiles therefore provide non-
     repudiation over the signed visible chain and linked commitment
     state, not over hidden prefix semantics against a rogue or colluding
     Authorization Server.

  36.  Appendix J.  Trust Boundaries and Audit Guidance (Informative)

     The trust model and visible-disclosure properties of the six profiles
     are defined in the main specification text and Appendix I.  This
     appendix focuses on operational retention and forensic guidance
     rather than restating those profile summaries.

     Authorization Servers supporting these profiles SHOULD retain records
     keyed by acti and jti.

     For verified profiles, the retention period SHOULD be at least the
     maximum validity period of the longest-lived relevant token plus a
     deployment-configured audit window, and it SHOULD remain sufficient
     to validate historical proofs across key rotation.




  Prasad, et al.           Expires 2 November 2026               [Page 84]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     For verified profiles, such records SHOULD include:

     *  prior token reference;
     *  authenticated actor identity accepted for the exchange or proof-
        validation step;
     *  step proof reference or value;
     *  issued token reference;
     *  commitment state;
     *  requested audience or target context; and
     *  timestamps.

     For subset-disclosure profiles, retained records SHOULD also allow
     reconstruction of the verified actor-visible chain for each hop and
     the disclosed subset issued for each recipient.  Collecting all such
     accepted hop evidence for one acti, including retained tokens,
     proofs, commitments, and exchange records, can reconstruct the
     accepted hop sequence, including repeated-actor revisits, and can
     often reveal much of the effective call graph, but this specification
     does not by itself yield a complete standardized graph across related
     branches.  If a deployment also relies on a hidden full-chain prefix
     not signed by every acting intermediary, the Authorization Server
     SHOULD retain the additional state needed to reconstruct that hidden
     prefix for later audit.

     Actors SHOULD also retain local records sufficient to support replay
     detection, incident investigation, and later proof of participation.

  37.  Appendix K.  Design Decisions (Informative)

     This appendix records key design decisions made in the core
     specification so that future revisions can preserve the underlying
     interoperability and security rationale even if the document is later
     split.

  37.1.  Why visible chain state is carried in nested act

     The interoperable JWT form uses nested act as the single
     authoritative inline carrier for visible actor-chain state.  This
     avoids maintaining separate readable chain claims and prevents dual-
     truth bugs in which two different claims could describe different
     visible histories.










  Prasad, et al.           Expires 2 November 2026               [Page 85]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  37.2.  Why top-level sub remains the workflow subject

     Top-level sub identifies the workflow subject of the token rather
     than the current actor.  This keeps ordinary token semantics aligned
     with RFC 8693 and allows the current actor to remain visible in act.
     Replacing sub with the current actor or with a constant marker would
     make token subject semantics much less clear for recipients and
     auditors.

  37.3.  Why privacy-sensitive profiles use stable subject aliases

     Subset-disclosure operation can hide actors only if other visible
     fields do not reveal the hidden subject indirectly.  The AS therefore
     chooses a stable workflow-subject representation at bootstrap, such
     as a pairwise or workflow-local alias, and preserves it for the
     workflow.

  37.4.  Why subset disclosure is recipient-specific and AS-driven

     Different recipients in the same workflow can have different need-to-
     know.  The AS is therefore the policy decision and enforcement point
     for disclosure and may issue a narrower or broader visible nested act
     to different recipients, so long as each returned token remains
     consistent with the active profile and any disclosed act is a
     permitted profile-conformant disclosure of the accepted chain state
     for that hop.

  37.5.  Why actor-only is a separate profile even though subset can
         express it

     Actor-only disclosure can be expressed as a special case of subset
     disclosure, but this document gives it distinct profile identifiers
     so that the intended policy remains explicit and machine-readable to
     current and future implementations.  A token carrying actp=declared-
     actor-only or actp=verified-actor-only therefore tells every
     conforming actor and recipient that ordinary tokens in that workflow
     MUST expose only the outermost current actor inline, even though the
     Authorization Server may retain richer hidden workflow state for
     later audit or forensics.

  37.6.  Why branching is represented across tokens, not inside one token

     Each token carries one visible path in nested act.  Branching is
     represented by issuing multiple successor tokens that share a prior
     workflow state.  This keeps token syntax simple while still
     supporting forensic and legal-audit reconstruction of a broader call
     graph from retained AS records and related artifacts.




  Prasad, et al.           Expires 2 November 2026               [Page 86]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  37.7.  Why actc uses parent-pointer commitments instead of Merkle trees

     The base commitment mechanism is hop-oriented: each accepted
     successor step binds exactly one parent commitment state and one new
     verified hop.  Allowing multiple successors to share the same parent
     forms a hash-linked workflow graph without requiring Merkle-tree
     ordering rules, sibling proof transmission, or merge semantics.
     Future work can add Merkle-style aggregation if deployments need
     compact set commitments across many branches.

  37.8.  Why actp and actc use short claim names

     These claims appear in every token issued under this specification,
     and actc also travels in later verified hops.  The document therefore
     uses short claim names to limit repeated per-hop overhead on the
     wire.  Their meanings are fixed only by this specification, and the
     main body defines those semantics before IANA registration.

  37.9.  Why RFC 8414 metadata discovery is reused

     The specification reuses the standard RFC 8414 authorization-server
     metadata endpoint for discovery.  This avoids inventing a new
     discovery API and keeps capability negotiation in the well-known
     OAuth metadata channel that implementations already use.

  37.10.  Privacy goals and limits

     Subset disclosure limits per-hop visibility, but it does not hide
     information from the issuing AS or from colluding parties that pool
     tokens, proofs, acknowledgments, and logs.  The design therefore
     treats complete branch and call graph reconstruction primarily as a
     forensics or legal-audit concern rather than an online authorization
     requirement.

  38.  IANA Considerations

     This specification does not create a new hash-algorithm registry.
     actc uses hash algorithm names from the IANA Named Information Hash
     Algorithm Registry [IANA.Hash.Algorithms], subject to the algorithm
     restrictions defined in this document.

  38.1.  JSON Web Token Claims Registration

     This document requests registration of the following claims in the
     "JSON Web Token Claims" registry established by [RFC7519]:






  Prasad, et al.           Expires 2 November 2026               [Page 87]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


        +=======+========================+============+===============+
        | Claim | Claim Description      | Change     | Specification |
        | Name  |                        | Controller | Document(s)   |
        +=======+========================+============+===============+
        | actc  | Proof-bound chain      | IETF       | [this         |
        |       | state binding accepted |            | document]     |
        |       | hop progression for    |            |               |
        |       | the active profile.    |            |               |
        +-------+------------------------+------------+---------------+
        | acti  | Actor-chain identifier | IETF       | [this         |
        |       | preserved across       |            | document]     |
        |       | accepted hops.         |            |               |
        +-------+------------------------+------------+---------------+
        | actp  | Actor-chain profile    | IETF       | [this         |
        |       | identifier for the     |            | document]     |
        |       | issued token.          |            |               |
        +-------+------------------------+------------+---------------+

                                    Table 5

  38.2.  Media Type Registration

     This document requests registration of the following media types in
     the "Media Types" registry established by [RFC6838]:



























  Prasad, et al.           Expires 2 November 2026               [Page 88]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     +===========+==============+==========+==========+==============+==============+================+=============+===============+==============+=============+=======+========+============+======+==========+
     |Media Type |Media Subtype |Required  |Optional  |Encoding      |Security      |Interoperability|Published    |Applications   |Fragment      |Additional   |Contact|Intended|Restrictions|Author|Change    |
     |Name       |Name          |Parameters|Parameters|Considerations|Considerations|Considerations  |Specification|that use this  |Identifier    |Information  |       |Usage   |on Usage    |      |Controller|
     |           |              |          |          |              |              |                |             |media type     |Considerations|             |       |        |            |      |          |
     +===========+==============+==========+==========+==============+==============+================+=============+===============+==============+=============+=======+========+============+======+==========+
     |application|act-step-     |N/A       |N/A       |binary        |see [this     |N/A             |[this        |OAuth 2.0 Token|N/A           |Magic        |IETF   |COMMON  |N/A         |IETF  |IETF      |
     |           |proof+jwt     |          |          |              |document]     |                |document]    |Exchange actor-|              |Number(s): N/|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |chain step     |              |A; File      |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |proofs         |              |Extension(s):|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |N/A;         |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Macintosh    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |File Type    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Code(s): N/A |       |        |            |      |          |
     +-----------+--------------+----------+----------+--------------+--------------+----------------+-------------+---------------+--------------+-------------+-------+--------+------------+------+----------+
     |application|act-          |N/A       |N/A       |binary        |see [this     |N/A             |[this        |OAuth 2.0 Token|N/A           |Magic        |IETF   |COMMON  |N/A         |IETF  |IETF      |
     |           |commitment+jwt|          |          |              |document]     |                |document]    |Exchange actor-|              |Number(s): N/|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |chain          |              |A; File      |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |commitments    |              |Extension(s):|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |N/A;         |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Macintosh    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |File Type    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Code(s): N/A |       |        |            |      |          |
     +-----------+--------------+----------+----------+--------------+--------------+----------------+-------------+---------------+--------------+-------------+-------+--------+------------+------+----------+
     |application|act-hop-      |N/A       |N/A       |binary        |see [this     |N/A             |[this        |OAuth 2.0 Token|N/A           |Magic        |IETF   |COMMON  |N/A         |IETF  |IETF      |
     |           |ack+jwt       |          |          |              |document]     |                |document]    |Exchange actor-|              |Number(s): N/|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |chain receiver |              |A; File      |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |acknowledgments|              |Extension(s):|       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |N/A;         |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Macintosh    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |File Type    |       |        |            |      |          |
     |           |              |          |          |              |              |                |             |               |              |Code(s): N/A |       |        |            |      |          |
     +-----------+--------------+----------+----------+--------------+--------------+----------------+-------------+---------------+--------------+-------------+-------+--------+------------+------+----------+

                                    Table 6

  38.3.  OAuth URI Registration

     This document requests registration of the following value in the
     "OAuth URI" registry established by [RFC6749]:












  Prasad, et al.           Expires 2 November 2026               [Page 89]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


      +============================+===========+==========+=============+
      |URI                         |Description|Change    |Specification|
      |                            |           |Controller|Document(s)  |
      +============================+===========+==========+=============+
      |urn:ietf:params:oauth:grant-|OAuth grant|IETF      |[this        |
      |type:actor-chain-bootstrap  |type for   |          |document]    |
      |                            |the initial|          |             |
      |                            |verified   |          |             |
      |                            |profile    |          |             |
      |                            |bootstrap  |          |             |
      |                            |token      |          |             |
      |                            |request.   |          |             |
      +----------------------------+-----------+----------+-------------+

                                    Table 7

  38.4.  OAuth Authorization Server Metadata Registration

     This document requests registration of the following metadata names
     in the "OAuth Authorization Server Metadata" registry established by
     [RFC8414]:






























  Prasad, et al.           Expires 2 November 2026               [Page 90]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     +=======================================+===============+==========+=============+
     |Metadata Name                          |Metadata       |Change    |Specification|
     |                                       |Description    |Controller|Document(s)  |
     +=======================================+===============+==========+=============+
     |actor_chain_bootstrap_endpoint         |Endpoint used  |IETF      |[this        |
     |                                       |to mint        |          |document]    |
     |                                       |bootstrap      |          |             |
     |                                       |context for    |          |             |
     |                                       |verified       |          |             |
     |                                       |profile initial|          |             |
     |                                       |actors.        |          |             |
     +---------------------------------------+---------------+----------+-------------+
     |actor_chain_profiles_supported         |Supported      |IETF      |[this        |
     |                                       |actor-chain    |          |document]    |
     |                                       |profile        |          |             |
     |                                       |identifiers.   |          |             |
     +---------------------------------------+---------------+----------+-------------+
     |actor_chain_commitment_hashes_supported|Supported      |IETF      |[this        |
     |                                       |commitment hash|          |document]    |
     |                                       |algorithm      |          |             |
     |                                       |identifiers.   |          |             |
     +---------------------------------------+---------------+----------+-------------+
     |actor_chain_receiver_ack_supported     |Indicates      |IETF      |[this        |
     |                                       |support for    |          |document]    |
     |                                       |receiver       |          |             |
     |                                       |acknowledgments|          |             |
     |                                       |(hop_ack) under|          |             |
     |                                       |this           |          |             |
     |                                       |specification. |          |             |
     +---------------------------------------+---------------+----------+-------------+
     |actor_chain_refresh_supported          |Indicates      |IETF      |[this        |
     |                                       |support for    |          |document]    |
     |                                       |Refresh-       |          |             |
     |                                       |Exchange under |          |             |
     |                                       |this           |          |             |
     |                                       |specification. |          |             |
     +---------------------------------------+---------------+----------+-------------+
     |actor_chain_cross_domain_supported     |Indicates      |IETF      |[this        |
     |                                       |support for    |          |document]    |
     |                                       |cross-domain   |          |             |
     |                                       |re-issuance    |          |             |
     |                                       |under this     |          |             |
     |                                       |specification. |          |             |
     +---------------------------------------+---------------+----------+-------------+

                                    Table 8





  Prasad, et al.           Expires 2 November 2026               [Page 91]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  38.5.  OAuth Parameter Registration

     This document requests registration of the following parameter names
     in the relevant OAuth parameter registry:

     +=============================+===========+==========+=============+
     |Parameter Name               |Parameter  |Change    |Specification|
     |                             |Usage      |Controller|Document(s)  |
     |                             |Location   |          |             |
     +=============================+===========+==========+=============+
     |actor_chain_profile          |actor-chain|IETF      |[this        |
     |                             |bootstrap  |          |document]    |
     |                             |endpoint   |          |             |
     |                             |request;   |          |             |
     |                             |OAuth token|          |             |
     |                             |endpoint   |          |             |
     |                             |request    |          |             |
     +-----------------------------+-----------+----------+-------------+
     |actor_chain_bootstrap_context|actor-chain|IETF      |[this        |
     |                             |bootstrap  |          |document]    |
     |                             |endpoint   |          |             |
     |                             |response;  |          |             |
     |                             |OAuth token|          |             |
     |                             |endpoint   |          |             |
     |                             |request    |          |             |
     +-----------------------------+-----------+----------+-------------+
     |actor_chain_step_proof       |OAuth token|IETF      |[this        |
     |                             |endpoint   |          |document]    |
     |                             |request    |          |             |
     +-----------------------------+-----------+----------+-------------+
     |actor_chain_refresh          |OAuth token|IETF      |[this        |
     |                             |endpoint   |          |document]    |
     |                             |request    |          |             |
     +-----------------------------+-----------+----------+-------------+
     |actor_chain_cross_domain     |OAuth token|IETF      |[this        |
     |                             |endpoint   |          |document]    |
     |                             |request    |          |             |
     +-----------------------------+-----------+----------+-------------+

                                   Table 9











  Prasad, et al.           Expires 2 November 2026               [Page 92]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


  39.  Appendix X.  Out-of-Scope Use Cases (Informative)

     This appendix is non-normative.  Per-hop request binding —
     cryptographic evidence that a request physically traversed each
     claimed hop — is out of scope for this document.  End-to-end path
     proof in the data plane, such as nested message signatures applied by
     each actor in turn, requires a companion mechanism such as [RFC9421]
     or [RFC9449] and is not addressed here.

  40.  Appendix Y.  Relationship to RFC 8693 (Informative)

     This appendix is non-normative.  [RFC8693] defines token exchange and
     introduces act for delegation, with nested act described as a
     convention.  It treats act as optional and defines no normative
     processing rules for construction, extension, or validation across a
     sequence of exchanges.  This document does not replace [RFC8693];
     with actp absent, it adds no new requirements.  With actp present,
     the following constraints apply:

































  Prasad, et al.           Expires 2 November 2026               [Page 93]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


         +======================+===================================+
         | [RFC8693] behavior   | This document                     |
         +======================+===================================+
         | act is optional.     | Processing follows the rules here |
         |                      | when used; actp makes the         |
         |                      | governing semantics explicit.     |
         +----------------------+-----------------------------------+
         | Nested act is a      | Nested act is normative           |
         | convention.          | structural form; recipients can   |
         |                      | rely on its shape.                |
         +----------------------+-----------------------------------+
         | No append-only rule. | Prior actors MUST NOT be          |
         |                      | inserted, reordered, deleted, or  |
         |                      | modified.                         |
         +----------------------+-----------------------------------+
         | No cross-exchange    | acti provides a stable workflow   |
         | correlation.         | instance identifier across hops.  |
         +----------------------+-----------------------------------+
         | No integrity binding | actc provides cumulative          |
         | beyond the issuing   | commitment verifiable across AS   |
         | AS's signature.      | boundaries.                       |
         +----------------------+-----------------------------------+
         | No prior-actor       | actp profiles scope disclosure;   |
         | disclosure control.  | the disclosure invariant prevents |
         |                      | leakage through other claims.     |
         +----------------------+-----------------------------------+
         | No disclosure-regime | actp allows recipients to apply   |
         | signal to the        | the correct interpretation.       |
         | recipient.           |                                   |
         +----------------------+-----------------------------------+

                                   Table 10

  41.  Informative References

     [I-D.draft-mw-spice-inference-chain]
                Krishnan, R., "Cryptographically Verifiable Inference
                Chain for AI Agent Computational Provenance", 7 March
                2026, <https://datatracker.ietf.org/doc/html/draft-mw-
                spice-inference-chain>.

     [I-D.draft-mw-spice-intent-chain]
                Krishnan, R., "Cryptographically Verifiable Intent Chain
                for AI Agent Content Provenance", 7 March 2026,
                <https://datatracker.ietf.org/doc/html/draft-mw-spice-
                intent-chain>.





  Prasad, et al.           Expires 2 November 2026               [Page 94]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     [I-D.draft-mw-spice-transitive-attestation]
                Krishnan, R., "Transitive Attestation for Workload Proof
                of Residency", 21 February 2025,
                <https://datatracker.ietf.org/doc/html/draft-mw-spice-
                transitive-attestation>.

     [I-D.ietf-spice-arch]
                Sheffer, Y., "Secure Patterns for Internet CrEdentials
                (SPICE) Architecture", 21 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-spice-
                arch>.

     [I-D.ietf-spice-s2s-protocol]
                Howard, P., "SPICE Service to Service Authentication", 21
                October 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-spice-s2s-protocol>.

     [IANA.Hash.Algorithms]
                IANA, "Named Information Hash Algorithm Registry",
                <https://www.iana.org/assignments/named-information>.

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

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

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

     [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
                Keranen, A., and P. Hallam-Baker, "Naming Things with
                Hashes", RFC 6920, April 2013,
                <https://www.rfc-editor.org/info/rfc6920>.

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

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.





  Prasad, et al.           Expires 2 November 2026               [Page 95]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


     [RFC7662]  Richer, J., "OAuth 2.0 Token Introspection", RFC 7662,
                October 2015, <https://www.rfc-editor.org/info/rfc7662>.

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

     [RFC8414]  Jones, M. and N. Sakimura, "OAuth 2.0 Authorization Server
                Metadata", RFC 8414, June 2018,
                <https://www.rfc-editor.org/info/rfc8414>.

     [RFC8693]  Denniss, W., Bradley, J., Tschofenig, H., and T.
                Lodderstedt, "OAuth 2.0 Token Exchange", RFC 8693, January
                2020, <https://www.rfc-editor.org/info/rfc8693>.

     [RFC8785]  Rundgren, A., "JSON Canonicalization Scheme (JCS)",
                RFC 8785, June 2020,
                <https://www.rfc-editor.org/info/rfc8785>.

     [RFC9334]  Birkholz, H., Fossati, T., Smith, N., Pan, W., and C.
                Tschofenig, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, January 2023,
                <https://www.rfc-editor.org/info/rfc9334>.

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

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

     [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
                Disclosure for JSON Web Tokens", RFC 9901, November 2025,
                <https://www.rfc-editor.org/info/rfc9901>.

  Appendix A.  Contributors

     Michael Epley
     Red Hat
     Email: mepley@redhat.com

  Authors' Addresses

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



  Prasad, et al.           Expires 2 November 2026               [Page 96]


  Internet-Draft             OAUTH-ACTOR-CHAINS                   May 2026


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


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


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






































  Prasad, et al.           Expires 2 November 2026               [Page 97]


