# drafts

name: draft-sharif-mcps-secure-mcp
rev: 00
title: MCPS: Cryptographic Security Layer for the Model Context Protocol
time: 2026-03-14T16:44:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-15T16:44:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-05-22T09:24:50.499359+00:00
source: ietf
abstract:
  This document specifies MCPS (MCP Secure), a cryptographic
     security layer for the Model Context Protocol (MCP).  MCPS adds
     agent identity verification, per-message signing, tool definition
     integrity, and replay protection to MCP communications without
     modifying the core protocol.

     MCPS operates as an envelope around existing JSON-RPC messages.
     It introduces four primitives: (1) Agent Passports for
     cryptographic identity bound to a specific origin, (2) signed
     message envelopes for integrity and non-repudiation, (3) tool
     definition signatures covering the full tool object for detecting
     poisoning and tampering, and (4) nonce-plus-timestamp replay
     protection with transcript binding to prevent downgrade attacks.

     The design is fully backward-compatible.  MCPS-unaware clients
     and servers continue to function normally.  MCPS-aware endpoints
     progressively negotiate security capabilities through trust
     levels L0 (no verification) through L4 (full mutual
     authentication with revocation checking).

     All cryptographic operations use ECDSA P-256 (NIST FIPS 186-5).
     Signatures use IEEE P1363 fixed-length r||s encoding per
     RFC 7518 Section 3.4 with low-S normalization to prevent
     signature malleability.  Canonical serialization uses JSON
     Canonicalization Scheme (JCS) per RFC 8785.  The Trust Authority
     component is self-hostable with no external service dependency.

full_text:
  Internet Engineering Task Force                               R. Sharif
  Internet-Draft                                            CyberSecAI Ltd
  Intended status: Standards Track                          March 14, 2026
  Expires: September 14, 2026


       MCPS: Cryptographic Security Layer for the Model Context Protocol
                      draft-sharif-mcps-secure-mcp-00

  Abstract

     This document specifies MCPS (MCP Secure), a cryptographic
     security layer for the Model Context Protocol (MCP).  MCPS adds
     agent identity verification, per-message signing, tool definition
     integrity, and replay protection to MCP communications without
     modifying the core protocol.

     MCPS operates as an envelope around existing JSON-RPC messages.
     It introduces four primitives: (1) Agent Passports for
     cryptographic identity bound to a specific origin, (2) signed
     message envelopes for integrity and non-repudiation, (3) tool
     definition signatures covering the full tool object for detecting
     poisoning and tampering, and (4) nonce-plus-timestamp replay
     protection with transcript binding to prevent downgrade attacks.

     The design is fully backward-compatible.  MCPS-unaware clients
     and servers continue to function normally.  MCPS-aware endpoints
     progressively negotiate security capabilities through trust
     levels L0 (no verification) through L4 (full mutual
     authentication with revocation checking).

     All cryptographic operations use ECDSA P-256 (NIST FIPS 186-5).
     Signatures use IEEE P1363 fixed-length r||s encoding per
     RFC 7518 Section 3.4 with low-S normalization to prevent
     signature malleability.  Canonical serialization uses JSON
     Canonicalization Scheme (JCS) per RFC 8785.  The Trust Authority
     component is self-hostable with no external service dependency.

  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 September 14, 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  The Problem . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Scope and Limitations . . . . . . . . . . . . . . . . .  5
       1.3.  Relationship to Existing MCP Authorization  . . . . . .  5
       1.4.  Relationship to DPoP (RFC 9449) . . . . . . . . . . . .  6
       1.5.  Design Goals  . . . . . . . . . . . . . . . . . . . . .  7
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . .  8
       3.1.  Architecture  . . . . . . . . . . . . . . . . . . . . .  8
       3.2.  Envelope Model  . . . . . . . . . . . . . . . . . . . .  9
       3.3.  Trust Levels  . . . . . . . . . . . . . . . . . . . . .  9
       3.4.  Trust Level Assignment Rules  . . . . . . . . . . . . . 10
       3.5.  Cryptographic Primitives  . . . . . . . . . . . . . . . 11
       3.6.  Signature Format Details  . . . . . . . . . . . . . . . 12
       3.7.  Low-S Normalization . . . . . . . . . . . . . . . . . . 12
     4.  Agent Passports . . . . . . . . . . . . . . . . . . . . . . 13
       4.1.  Passport Structure  . . . . . . . . . . . . . . . . . . 13
       4.2.  Passport Fields . . . . . . . . . . . . . . . . . . . . 14
       4.3.  Passport Size Limits  . . . . . . . . . . . . . . . . . 15
       4.4.  Origin Binding  . . . . . . . . . . . . . . . . . . . . 16
       4.5.  Key Rotation and Compromise Recovery  . . . . . . . . . 16
       4.6.  Passport Lifecycle  . . . . . . . . . . . . . . . . . . 17
       4.7.  JWK Key Requirements  . . . . . . . . . . . . . . . . . 18
     5.  Message Signing . . . . . . . . . . . . . . . . . . . . . . 19
       5.1.  Envelope Structure  . . . . . . . . . . . . . . . . . . 19
       5.2.  Signing Process . . . . . . . . . . . . . . . . . . . . 19
       5.3.  TLS Channel Binding . . . . . . . . . . . . . . . . . . 21
       5.4.  Verification Process  . . . . . . . . . . . . . . . . . 21
       5.5.  Canonical Serialization (RFC 8785)  . . . . . . . . . . 22
     6.  Tool Definition Signing . . . . . . . . . . . . . . . . . . 23
       6.1.  Signed Tool Structure . . . . . . . . . . . . . . . . . 23
       6.2.  Author Origin Binding . . . . . . . . . . . . . . . . . 24
       6.3.  Signing Process . . . . . . . . . . . . . . . . . . . . 24
       6.4.  Verification and Pinning  . . . . . . . . . . . . . . . 25
       6.5.  Rug Pull Detection  . . . . . . . . . . . . . . . . . . 26
     7.  Replay Protection . . . . . . . . . . . . . . . . . . . . . 26
       7.1.  Nonce Requirements  . . . . . . . . . . . . . . . . . . 26
       7.2.  Timestamp Window  . . . . . . . . . . . . . . . . . . . 27
       7.3.  Nonce Store Requirements  . . . . . . . . . . . . . . . 27
     8.  Trust Authority . . . . . . . . . . . . . . . . . . . . . . 28
       8.1.  Self-Hosting  . . . . . . . . . . . . . . . . . . . . . 28
       8.2.  Public Key Distribution . . . . . . . . . . . . . . . . 28
       8.3.  Issuer Chains . . . . . . . . . . . . . . . . . . . . . 29
       8.4.  Issuer Chain Entry Format . . . . . . . . . . . . . . . 29
       8.5.  Chain Verification Algorithm  . . . . . . . . . . . . . 30
       8.6.  Multi-TA Deployments  . . . . . . . . . . . . . . . . . 31
       8.7.  Revocation  . . . . . . . . . . . . . . . . . . . . . . 32
       8.8.  Revocation Endpoint Discovery . . . . . . . . . . . . . 33
       8.9.  Revocation Failure Policy . . . . . . . . . . . . . . . 33
     9.  Capability Negotiation  . . . . . . . . . . . . . . . . . . 34
       9.1.  Version Negotiation . . . . . . . . . . . . . . . . . . 34
       9.2.  Client Announcement . . . . . . . . . . . . . . . . . . 35
       9.3.  Server Response . . . . . . . . . . . . . . . . . . . . 36
       9.4.  Negotiation Failure . . . . . . . . . . . . . . . . . . 36
       9.5.  Transcript Binding (Anti-Downgrade) . . . . . . . . . . 37
     10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . 38
     11. Security Considerations . . . . . . . . . . . . . . . . . . 40
       11.1. Threat Model  . . . . . . . . . . . . . . . . . . . . . 40
       11.2. Provenance vs Safety  . . . . . . . . . . . . . . . . . 41
       11.3. Trust Authority Compromise  . . . . . . . . . . . . . . 42
       11.4. Nonce Store Exhaustion  . . . . . . . . . . . . . . . . 42
       11.5. Clock Skew Attacks  . . . . . . . . . . . . . . . . . . 42
       11.6. Algorithm Agility . . . . . . . . . . . . . . . . . . . 43
       11.7. Privacy Considerations  . . . . . . . . . . . . . . . . 43
       11.8. Non-Repudiation Implications  . . . . . . . . . . . . . 43
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44
       12.1. MCPS Error Code Registry  . . . . . . . . . . . . . . . 44
       12.2. MCPS Trust Level Registry . . . . . . . . . . . . . . . 45
       12.3. MCPS Capability Identifier  . . . . . . . . . . . . . . 45
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . 46
       13.1. Normative References  . . . . . . . . . . . . . . . . . 46
       13.2. Informative References  . . . . . . . . . . . . . . . . 47
     Appendix A.  Example Protocol Exchange  . . . . . . . . . . . . 48
     Appendix B.  OWASP Risk Mapping . . . . . . . . . . . . . . . . 51
     Appendix C.  Design Rationale . . . . . . . . . . . . . . . . . 52
     Appendix D.  Changes from draft-sharif-mcps-secure-mcp-01  . . . 54
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 56

  1.  Introduction

     The Model Context Protocol (MCP) defines a standard interface for
     connecting AI agents to external tools and data sources.  MCP uses
     JSON-RPC 2.0 as its message format and supports multiple transport
     mechanisms including standard input/output (stdio), HTTP with
     Server-Sent Events (SSE), and WebSocket.

     While MCP provides a robust framework for agent-tool interaction,
     the current specification lacks cryptographic guarantees for three
     critical security properties: identity, integrity, and tool
     authenticity.

  1.1.  The Problem

     MCP in its current form has no built-in mechanism for:

     Identity:  There is no way for an MCP client or server to
        cryptographically verify the identity of its counterpart and
        bind that identity to a specific origin.  A malicious actor
        can impersonate a legitimate MCP server, serving modified tool
        definitions or intercepting sensitive data.

     Integrity:  JSON-RPC messages between client and server are
        unsigned.  There is no way for a recipient to verify that a
        message has not been tampered with in transit, or to prove
        after the fact that a particular message was sent by a
        particular party (non-repudiation).

     Tool Authenticity:  Tool definitions (name, description, input
        schema) are served unsigned.  A compromised or malicious server
        can modify tool descriptions to inject instructions into agent
        prompts (tool poisoning), or silently change tool behavior
        between sessions.

     These are not theoretical concerns:

     o  41% of MCP servers have zero authentication (TapAuth research,
        scanning 518 production MCP servers).

     o  An independent scan of 39 AI agent frameworks against the OWASP
        Top 10 for Agentic Applications found that 13 frameworks had
        no MCP security controls, 17 had partial controls, and only 9
        implemented adequate protections.

     o  Tool poisoning attacks via description injection have been
        demonstrated in research contexts, where modified tool
        descriptions cause agents to execute unintended actions.

  1.2.  Scope and Limitations

     This document addresses identity, integrity, and replay
     protection.  It does NOT address:

     Tool Safety Analysis:  Signing a tool proves WHO authored it
        (provenance), not that the tool is safe to execute.  A
        malicious server operator can sign their own poisoned tool
        definitions with a valid signature.  Tool safety analysis
        (detecting malicious descriptions, sandboxing execution) is a
        separate concern that complements this work.

     Authorization:  This document does not replace OAuth-based access
        control.  It provides a cryptographic identity layer that
        operates alongside authorization.

     Confidentiality:  Message encryption is out of scope.
        MCP-over-HTTP already provides transport-level confidentiality
        via TLS.

  1.3.  Relationship to Existing MCP Authorization

     Existing MCP authorization work (OAuth 2.1-based) addresses
     session-level authentication, establishing that a client is
     authorized to connect to a server.  This is necessary but not
     sufficient.

     MCPS addresses a different layer: message-level and artifact-level
     cryptographic guarantees.  The distinction is analogous to:

        +------------------+-----------------+-------------------------+
        | Layer            | HTTP Analogy    | Addressed By            |
        +------------------+-----------------+-------------------------+
        | Session auth     | OAuth bearer    | Existing MCP auth       |
        | Transport        | TLS             | Existing (transport)    |
        | Message integrity| HTTP Signatures | MCPS                    |
        | Artifact signing | Code signing    | MCPS                    |
        | Agent identity   | Client certs    | MCPS                    |
        +------------------+-----------------+-------------------------+

     Note: MCP-over-HTTP already uses TLS for transport security.
     MCPS operates at the application layer above TLS, providing
     per-message non-repudiation and artifact integrity that TLS does
     not offer (TLS terminates at the connection, not the message).

     MCPS complements existing OAuth-based authorization.  A server MAY
     require both OAuth credentials (for access control) and MCPS
     signatures (for integrity and non-repudiation).

  1.4.  Relationship to DPoP (RFC 9449)

     DPoP (Demonstrating Proof-of-Possession) [RFC9449] provides proof
     that the presenter of an OAuth access token possesses a particular
     key.  MCPS's message signing serves a similar proof-of-possession
     function but extends beyond OAuth token binding:

     1.  Per-message signing (not per-session): Every JSON-RPC message
         is individually signed, enabling non-repudiation of specific
         tool calls and responses.

     2.  Tool definition signing: DPoP does not address artifact
         integrity.

     3.  Trust level negotiation: DPoP does not define progressive
         trust tiers.

     Implementations MAY compose MCPS with DPoP.  Specifically, the
     Agent Passport's public key MAY be the same key used in DPoP
     proofs, providing a unified identity across both OAuth
     authorization and message-level integrity.

  1.5.  Design Goals

     The design of MCPS is guided by the following goals:

     1.  Backward compatibility: Non-MCPS endpoints MUST continue to
         function without modification.

     2.  Transport independence: MCPS MUST work over any MCP transport
         (stdio, HTTP SSE, WebSocket).

     3.  Progressive adoption: Organizations MUST be able to adopt
         MCPS incrementally through trust levels.

     4.  Self-sovereignty: No dependency on any centralized service
         MUST be required.

     5.  Standards alignment: Cryptographic operations MUST use
         established NIST and IETF standards.

  2.  Terminology

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

     The following terms are used throughout this document:

     Agent:  A software entity that communicates over MCP, acting as
        either a client or server.

     Agent Passport:  A signed credential binding an ECDSA P-256 public
        key to an agent identity and a specific origin, issued by a
        Trust Authority or self-signed.

     Trust Authority (TA):  A service that issues, manages, and
        optionally revokes Agent Passports.  Analogous to a Certificate
        Authority in the TLS/PKI ecosystem.

     Trust Level:  An integer (0-4) indicating the degree of
        cryptographic verification applied to an MCPS connection.

     Signed Envelope:  A JSON object wrapping a JSON-RPC message with
        an MCPS header containing a cryptographic signature, nonce, and
        timestamp.

     Tool Signature:  An ECDSA signature over a tool definition,
        binding the tool's name, description, and input schema to its
        author.

     Canonical Serialization:  JSON Canonicalization Scheme (JCS) per
        RFC 8785, used as the deterministic input to all signing
        operations.

     Tool Hash:  The SHA-256 digest of the JCS-canonicalized tool
        signing object (including name, description, input schema, and
        author origin), used for efficient change detection.

     Pin Store:  A persistent mapping from (server_origin, tool_name)
        tuples to tool hashes, maintained by clients for detecting
        tool definition changes.

     Nonce Store:  A data structure maintaining previously observed
        nonce values for replay detection.

     Transcript Binding:  A signed hash of the capability negotiation
        exchange, using ECDSA signatures (asymmetric), used to detect
        downgrade attacks.  Note: Previous drafts used the term
        "Transcript MAC"; this has been corrected because MCPS uses
        asymmetric signatures, not symmetric MACs.

  3.  Protocol Overview

  3.1.  Architecture

     MCPS operates as a security layer between the application logic
     and the MCP transport.  The architecture consists of four
     components:

     1.  Agent Passports: Cryptographic identity credentials bound to
         an origin.

     2.  Message Signing: Per-message ECDSA signatures in an envelope.

     3.  Tool Signing: Signatures over complete tool definitions.

     4.  Trust Authority: Passport issuance, chain validation, and
         revocation.

     The following diagram illustrates the message flow:

        +-------------------+         +-------------------+
        |   MCP Client      |         |   MCP Server      |
        |                   |         |                   |
        | +---------------+ |         | +---------------+ |
        | | Application   | |         | | Application   | |
        | +-------+-------+ |         | +-------+-------+ |
        |         |         |         |         |         |
        | +-------v-------+ |         | +-------v-------+ |
        | | MCPS Layer    | | <-----> | | MCPS Layer    | |
        | | (sign/verify) | |         | | (sign/verify) | |
        | +-------+-------+ |         | +-------+-------+ |
        |         |         |         |         |         |
        | +-------v-------+ |         | +-------v-------+ |
        | | MCP Transport | |         | | MCP Transport | |
        | +---------------+ |         | +---------------+ |
        +-------------------+         +-------------------+

  3.2.  Envelope Model

     MCPS wraps existing JSON-RPC messages in a signed envelope rather
     than modifying the JSON-RPC schema.  The MCPS header is added as
     a top-level "mcps" field alongside the standard JSON-RPC fields.
     Non-MCPS implementations ignore the "mcps" field per standard
     JSON-RPC behavior.

     This approach follows the precedent of HTTP Signatures [RFC9421],
     which add signatures alongside existing HTTP headers rather than
     modifying the HTTP message format.

  3.3.  Trust Levels

     MCPS defines five trust levels for progressive security adoption:

        +-------+-----------+------------------------------------------+
        | Level | Name      | Requirements                             |
        +-------+-----------+------------------------------------------+
        | L0    | None      | No MCPS verification.  Equivalent to     |
        |       |           | current MCP behavior.  Self-signed        |
        |       |           | passports.                                |
        +-------+-----------+------------------------------------------+
        | L1    | Signed    | Messages are signed.  Passport signed     |
        |       |           | by ANY Trust Authority.                   |
        +-------+-----------+------------------------------------------+
        | L2    | Verified  | Messages are signed.  Passport signed     |
        |       |           | by a TA whose root key is in the          |
        |       |           | verifier's trust store.                   |
        +-------+-----------+------------------------------------------+
        | L3    | Strict    | L2 plus tool definition signatures        |
        |       |           | MUST be present and valid.  TA has        |
        |       |           | verified origin ownership.                |
        +-------+-----------+------------------------------------------+
        | L4    | Full      | L3 plus mutual authentication and         |
        |       |           | real-time revocation checking.  TA has    |
        |       |           | performed security audit.                 |
        +-------+-----------+------------------------------------------+

     Servers SHOULD declare their minimum required trust level during
     capability negotiation (Section 9).  Clients connecting at a trust
     level below the server minimum MUST be rejected with error code
     -33009 (MCPS_TRUST_LEVEL_INSUFFICIENT).

  3.4.  Trust Level Assignment Rules

     Trust levels are NOT self-asserted by passport holders.  They are
     constrained by the issuance process:

     1.  Self-signed passports are ALWAYS L0, regardless of any
         "trust_level" field value.  Implementations MUST cap
         self-signed passports at L0.

     2.  L1-L2 require the passport to be signed by a Trust Authority
         whose public key can be verified through the issuer chain
         (Section 8.3).

     3.  L3 additionally requires the TA to have verified that the
         passport holder controls the "origin" URI (e.g., via HTTP-01
         challenge, DNS-01 challenge, or documented manual
         verification).

     4.  L4 additionally requires the TA to have performed a security
         audit of the agent and to provide real-time revocation
         checking (Section 8.7).

     An implementation receiving a passport claiming L4 but signed by
     an unknown TA MUST treat it as L0.

  3.5.  Cryptographic Primitives

     All MCPS cryptographic operations use the following algorithms:

     Key Algorithm:  ECDSA with the P-256 curve (NIST FIPS 186-5
        [FIPS186-5], deterministic signatures per [RFC6979]).

     Hash Algorithm:  SHA-256 (NIST FIPS 180-4).

     Signature Format:  IEEE P1363 fixed-length r||s encoding
        (exactly 64 bytes for P-256), per [RFC7518] Section 3.4.
        All signatures MUST use low-S normalization (see
        Section 3.7).

     Signature Encoding:  Base64 without padding [RFC4648].

     Key Format:  JSON Web Key (JWK) [RFC7517].

     Canonical Serialization:  JSON Canonicalization Scheme (JCS)
        [RFC8785].

     Why JCS (RFC 8785):  Canonical JSON serialization is critical for
        cross-implementation signature verification.  Different
        language runtimes produce different byte representations for
        the same logical JSON value (e.g., Node.js
        JSON.stringify({a:1.0}) produces {"a":1} while Python's
        json.dumps({a:1.0}) produces {"a": 1.0}).  RFC 8785 defines a
        deterministic serialization that guarantees identical bytes
        across all implementations.

     The choice of P-256 provides 128-bit security strength, broad
     platform support (Web Crypto API, OpenSSL, Java KeyStore), and
     hardware security module (HSM) compatibility.  FIPS 186-5 is
     referenced (not the superseded FIPS 186-4).

     Note: RFC 6979 specifies deterministic ECDSA nonce generation.
     Implementations using HSMs that employ internal random number
     generation for nonce generation are compliant provided the HSM
     generates nonces with sufficient entropy per FIPS 186-5.

     Implementations MAY support additional algorithms in future
     versions via algorithm negotiation in the "mcps" capability.

  3.6.  Signature Format Details

     Signatures use the IEEE P1363 fixed-length format: the 32-byte
     big-endian encoding of r concatenated with the 32-byte big-endian
     encoding of s, for a total of exactly 64 bytes.  This format is
     unambiguous (unlike variable-length DER encoding) and mandated by
     RFC 7518 Section 3.4 for JWA/JWS compatibility.

     DER encoding produces variable-length signatures (typically 70-72
     bytes for P-256).  IEEE P1363 produces fixed-length signatures
     (exactly 64 bytes for P-256).  Fixed-length format:

     1.  Eliminates ambiguity in signature parsing across
         implementations.

     2.  Is required by RFC 7518 Section 3.4 (JWA) and widely
         supported.

     3.  Simplifies cross-platform interoperability (no DER parsing
         needed).

  3.7.  Low-S Normalization

     Given a valid ECDSA signature (r, s), the signature (r, n-s) is
     also valid for the same message and key.  This malleability can
     be exploited to bypass nonce-based replay detection if the nonce
     store keys on full message bytes rather than the nonce string.

     To eliminate this attack:

     1.  All signatures MUST satisfy s <= n/2, where n is the order
         of the P-256 curve.

     2.  If the raw ECDSA signing operation produces s > n/2, the
         signer MUST replace s with n - s before encoding.

     3.  Verifiers SHOULD normalize incoming signatures (replace s
         with n - s if s > n/2) before verification for
         interoperability with implementations that do not perform
         low-S normalization on signing.

     The P-256 curve order n is:

        n = 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84
            F3B9CAC2FC632551

     The half-order n/2 is:

        n/2 = 0x7FFFFFFF800000007FFFFFFFFFFFFFFFDE737D56D38BCF42
              79DCE5617E3192A8

     Nonce stores MUST key on the nonce string value, NOT on full
     message bytes, to prevent signature malleability from bypassing
     replay detection (see Section 7.3).

  4.  Agent Passports

     An Agent Passport is a signed credential that binds an ECDSA
     P-256 key pair to an agent identity and a specific origin.

  4.1.  Passport Structure

     A passport is represented as a JSON object with the following
     top-level structure:

        {
          "mcps_version": "1.0",
          "passport": {
            "id": "ap_<uuid-v4>",
            "agent_name": "<string>",
            "agent_version": "<string (semver)>",
            "issuer": "<string>",
            "origin": "<string (URI)>",
            "issued_at": "<string (ISO 8601 UTC)>",
            "expires_at": "<string (ISO 8601 UTC)>",
            "public_key": {
              "kty": "EC",
              "crv": "P-256",
              "x": "<string (base64url)>",
              "y": "<string (base64url)>"
            },
            "capabilities": ["<string>"],
            "trust_level": 0,
            "issuer_chain": [
              "<string (base64-encoded JSON)>"
            ],
            "key_rotation": {
              "previous_key_hash": "<string (hex SHA-256)>",
              "rotated_at": "<string (ISO 8601 UTC)>"
            }
          },
          "signature": "<string (base64, IEEE P1363)>"
        }

  4.2.  Passport Fields

     The following fields are defined for Agent Passports:

     mcps_version:  REQUIRED.  String.  The MCPS protocol version.
        MUST be "1.0" for this specification.

     passport.id:  REQUIRED.  String.  A unique identifier for this
        passport.  MUST begin with the prefix "ap_" followed by a
        UUID v4 value.

     passport.agent_name:  REQUIRED.  String.  A human-readable name
        for the agent.

     passport.agent_version:  REQUIRED.  String.  The semantic version
        [SEMVER] of the agent software.

     passport.issuer:  REQUIRED.  String.  An identifier for the Trust
        Authority that issued this passport.  For self-signed passports,
        this MUST be the string "self".

     passport.origin:  REQUIRED.  String.  The authorized origin URI
        this passport is bound to (e.g.,
        "https://api.example.com:443").  Verifiers MUST reject
        passports presented to a different origin.  See Section 4.4.

     passport.issued_at:  REQUIRED.  String.  The issuance timestamp
        in ISO 8601 UTC format (e.g., "2026-03-13T12:00:00Z").

     passport.expires_at:  REQUIRED.  String.  The expiry timestamp
        in ISO 8601 UTC format.

     passport.public_key:  REQUIRED.  Object.  The agent's public key
        in JWK format.  See Section 4.7 for requirements.

     passport.capabilities:  OPTIONAL.  Array of strings.  A list of
        capability identifiers granted to this agent by the Trust
        Authority.  Maximum 64 entries (see Section 4.3).

     passport.trust_level:  OPTIONAL.  Integer (0-4).  The trust level
        assigned by the issuing Trust Authority.  Default value is 0.
        See Section 3.4 for assignment rules.

     passport.issuer_chain:  OPTIONAL.  Array of strings.  Chain of
        base64-encoded JSON intermediate Trust Authority passports.
        Each entry is a complete signed intermediate TA passport.
        Maximum depth: 5 entries (see Section 4.3).
        See Section 8.3 for format and verification.

     passport.key_rotation:  OPTIONAL.  Object.  Key rotation metadata
        for compromise recovery.  See Section 4.5.

     signature:  REQUIRED.  String.  A base64-encoded IEEE P1363
        ECDSA signature (exactly 64 bytes before encoding) computed
        over the JCS-canonicalized (RFC 8785) "passport" object,
        with low-S normalization (Section 3.7).  For Trust Authority-
        issued passports, this signature is produced using the Trust
        Authority's private key.  For self-signed passports, this
        signature is produced using the agent's own private key.

  4.3.  Passport Size Limits

     To prevent denial-of-service via oversized passports, the
     following limits are defined:

     MAX_PASSPORT_BYTES:  8192.  The maximum size in bytes of a
        JCS-canonicalized passport.  Implementations MUST reject
        passports exceeding this limit with error code -33013
        (MCPS_PASSPORT_TOO_LARGE).

     MAX_ISSUER_CHAIN_DEPTH:  5.  The maximum number of entries in
        the "issuer_chain" array.  Implementations MUST reject
        passports with chains exceeding this depth with error code
        -33014 (MCPS_CHAIN_TOO_DEEP).

     MAX_CAPABILITIES:  64.  The maximum number of entries in the
        "capabilities" array.

     Implementations MUST enforce all three limits during passport
     validation.

  4.4.  Origin Binding

     The "origin" field binds a passport to a specific server URI.
     This prevents passport reuse across domains:

     1.  When a server presents a passport, the client MUST verify
         that the passport's "origin" matches the URI it connected to.

     2.  When a client presents a passport, the server MUST verify
         that the passport's "origin" matches its own published URI.

     3.  Origin comparison MUST use scheme + authority (host + port)
         per RFC 6454 [RFC6454].

     This prevents an attacker from obtaining a valid passport for
     their own server and presenting it when impersonating a different
     server.

     If origin verification fails, the implementation MUST reject the
     passport with error code -33011 (MCPS_ORIGIN_MISMATCH).

  4.5.  Key Rotation and Compromise Recovery

     Passports support key rotation for both routine rotation and
     compromise recovery:

     Routine Rotation:  An agent generates a new key pair, requests a
        new passport from the Trust Authority, and the old passport is
        revoked after confirmation that the new passport is in active
        use.

     Compromise Recovery:  When a key is suspected compromised, the
        agent generates a new key pair and includes a "key_rotation"
        field linking to the previous key via its SHA-256 hash.  This
        enables Trust Authorities to verify the rotation request and
        revoke all passports associated with the compromised key.

     The "key_rotation" object contains:

     previous_key_hash:  REQUIRED (within key_rotation).  String.
        SHA-256 hash (hex-encoded) of the PEM-encoded previous
        public key.

     rotated_at:  REQUIRED (within key_rotation).  String.  ISO 8601
        UTC timestamp indicating when the rotation occurred.

     Trust Authorities SHOULD revoke the old passport upon issuing a
     new one with "key_rotation".  Implementations SHOULD support a
     configurable grace period where both old and new passports are
     accepted to allow rolling deployments.

  4.6.  Passport Lifecycle

     The lifecycle of an Agent Passport consists of the following
     stages:

     Generation:  The agent generates an ECDSA P-256 key pair locally.
        The private key MUST be stored securely and MUST NOT be
        transmitted.

     Issuance:  The agent submits its public key and requested origin
        to a Trust Authority.  The Trust Authority validates the
        agent's ownership of the origin (e.g., via HTTP challenge,
        DNS TXT record, or manual verification), assigns capabilities
        and a trust level, and signs the passport with the Trust
        Authority's private key.

     Self-Signing:  An agent MAY self-sign its passport.  Self-signed
        passports are ALWAYS Trust Level L0 regardless of any
        "trust_level" field value.  Implementations MUST enforce this.
        Self-signed passports MUST set the "issuer" field to "self".

     Verification:  A receiving party verifies the passport signature
        against the Trust Authority's public key (for TA-issued
        passports) or against the agent's own public key embedded in
        the passport (for self-signed passports).  For self-signed
        passports, the trust level is capped at L0.

     Expiry:  Passports MUST be rejected after the "expires_at"
        timestamp.  Implementations SHOULD allow a configurable clock
        skew tolerance.  The default clock skew tolerance SHOULD be
        60 seconds.

     Key Rotation:  An agent rotates its key by generating a new key
        pair and requesting a new passport from the Trust Authority.
        For compromise recovery, the "key_rotation" field (Section 4.5)
        links the new passport to the old key.  The old passport
        continues to be valid until its "expires_at" or until
        explicitly revoked.

     Revocation:  Trust Authorities MAY publish revocation information
        for passports they have issued.  See Section 8.7.

  4.7.  JWK Key Requirements

     The "public_key" field of an Agent Passport MUST conform to the
     following requirements:

     o  The "kty" field MUST be "EC".

     o  The "crv" field MUST be "P-256".

     o  The "x" and "y" fields MUST contain the base64url-encoded
        coordinates of the public key point on the P-256 curve, without
        padding.

     o  The "d" (private key) parameter MUST NOT be present.

     o  Implementations MUST validate that the public key point lies on
        the P-256 curve before using it for signature verification.

  5.  Message Signing

     Every JSON-RPC message exchanged between MCPS-aware endpoints is
     wrapped in a signed envelope.  The envelope adds an "mcps" field
     to the top level of the JSON-RPC message.

  5.1.  Envelope Structure

     A signed message envelope has the following structure:

        {
          "mcps": {
            "version": "1.0",
            "passport_id": "ap_<uuid>",
            "timestamp": "<string (ISO 8601 UTC)>",
            "nonce": "<string (hex, 16 random bytes)>",
            "signature": "<string (base64, IEEE P1363)>"
          },
          "jsonrpc": "2.0",
          "method": "<string>",
          "params": { ... },
          "id": 1
        }

     The "mcps" field contains the following sub-fields:

     version:  REQUIRED.  String.  The MCPS protocol version.  MUST
        be "1.0".

     passport_id:  REQUIRED.  String.  The identifier of the Agent
        Passport used to sign this message.

     timestamp:  REQUIRED.  String.  The current UTC time in ISO 8601
        format at which the message was signed.

     nonce:  REQUIRED.  String.  A hex-encoded string of 16
        cryptographically random bytes, unique to this message,
        used for replay protection.

     signature:  REQUIRED.  String.  A base64-encoded IEEE P1363
        ECDSA signature (exactly 64 bytes before encoding, with
        low-S normalization) over the signing payload (see
        Section 5.2).

  5.2.  Signing Process

     To sign a JSON-RPC message, an MCPS implementation MUST perform
     the following steps in order:

     1.  Construct the JSON-RPC message without the "mcps" field.

     2.  Generate 16 cryptographically random bytes, hex-encode them
         as the nonce.

     3.  Record the current UTC timestamp in ISO 8601 format.

     4.  Compute the message hash:

            message_hash = hex(SHA-256(JCS(JSON-RPC message)))

         where JCS is the RFC 8785 canonicalization of the complete
         JSON-RPC message (without the "mcps" field).

     5.  Construct the signing payload by JCS-canonicalizing [RFC8785]
         the following JSON object:

            {
              "message_hash": "<hex SHA-256>",
              "nonce": "<nonce>",
              "passport_id": "<passport_id>",
              "timestamp": "<timestamp>"
            }

         The keys in this object are sorted lexicographically per
         RFC 8785.  The "message_hash" value is the hexadecimal-
         encoded SHA-256 hash of the JCS-canonicalized JSON-RPC
         message.

     6.  Sign the UTF-8 encoding of the JCS-canonicalized signing
         payload using ECDSA P-256 with the agent's private key per
         [RFC6979] (deterministic signature generation), producing
         an IEEE P1363 signature with low-S normalization
         (Section 3.7).

     7.  Base64-encode the 64-byte IEEE P1363 signature without
         padding per [RFC4648].

     8.  Attach the "mcps" object to the JSON-RPC message.

     Design note: The signing payload uses "message_hash" (the
     SHA-256 hash of the JCS-canonicalized message) rather than
     embedding the JCS string directly.  Earlier drafts used
     "jsonrpc_message: JCS(message)" in the signing payload, nesting
     one JCS string inside another JCS object.  This creates
     fragility: the inner JCS string must be JSON-escaped when
     embedded in the outer object, and different JSON libraries handle
     this escaping differently.  Using a hash eliminates this
     ambiguity, is more robust, and is more efficient.

  5.3.  TLS Channel Binding

     Implementations MAY include a TLS channel binding token (per
     [RFC9266], tls-exporter type) in the signing payload to bind MCPS
     signatures to the TLS session:

        {
          "channel_binding": "<base64 tls-exporter binding>",
          "message_hash": "<hex SHA-256>",
          "nonce": "<nonce>",
          "passport_id": "<passport_id>",
          "timestamp": "<timestamp>"
        }

     When present, the verifier MUST verify that the "channel_binding"
     value matches the tls-exporter binding of the current TLS session.
     This prevents relay attacks where a man-in-the-middle with a valid
     TLS certificate for a different domain forwards signed messages
     between the legitimate client and server.

     The "channel_binding" field is OPTIONAL.  When absent, the signing
     payload uses the four-field format defined in Section 5.2.

  5.4.  Verification Process

     To verify a signed message, an MCPS implementation MUST perform
     the following steps in order:

     1.  Extract the "mcps" field from the received message.

     2.  Verify that all required "mcps" sub-fields are present.

     3.  Verify that the "timestamp" is within the acceptable window
         (see Section 7.2).  If the timestamp is outside the window,
         reject the message with error code -33006.

     4.  Verify that the "nonce" has not been previously observed (see
         Section 7.1).  If the nonce is a duplicate, reject the
         message with error code -33005.

     5.  Look up the Agent Passport by "passport_id".  Verify that the
         passport is valid, has not expired, is bound to the correct
         origin (Section 4.4), and (for L4) has not been revoked.  If
         the passport format is invalid, reject with error code
         -33001.  If expired, reject with -33002.  If revoked, reject
         with -33003.  If origin mismatches, reject with -33011.

     6.  Determine the effective trust level using the rules in
         Section 3.4.  If the effective trust level is below the
         server's minimum, reject with -33009.

     7.  Reconstruct the signing payload: compute the message hash
         from the received JSON-RPC message (with the "mcps" field
         removed), combine with received nonce, passport_id, and
         timestamp.  If "channel_binding" is present, include it.

     8.  JCS-canonicalize the reconstructed signing payload.

     9.  Verify the IEEE P1363 ECDSA signature against the public key
         from the Agent Passport.  Normalize s to low-S before
         verification (Section 3.7).  If verification fails, reject
         with error code -33004.

     10. Store the nonce (keyed on the nonce string) in the nonce
         store to prevent future replay.

     If any step fails, the message MUST be rejected with the
     appropriate error code defined in Section 10.

  5.5.  Canonical Serialization (RFC 8785)

     All MCPS signing operations use the JSON Canonicalization Scheme
     (JCS) defined in RFC 8785 [RFC8785] for deterministic
     serialization.  This ensures that implementations in different
     programming languages produce identical byte sequences for the
     same logical JSON value.

     Key JCS requirements relevant to MCPS:

     1.  Object keys MUST be sorted lexicographically by their Unicode
         code point values.

     2.  No extraneous whitespace (spaces, tabs, newlines) SHALL be
         present between tokens.

     3.  String values MUST use the shortest possible JSON escape
         sequences.

     4.  Numbers MUST be serialized according to ECMAScript number
         serialization: no unnecessary leading zeros, no trailing
         decimal zeros, integer-valued floats serialized as integers
         (1.0 becomes 1).

     5.  Negative zero (-0) MUST be serialized as 0.

     Implementers MUST test their JCS implementation against the
     RFC 8785 test vectors to ensure cross-platform compatibility.
     In particular, number serialization differences between
     JavaScript and Python runtimes are a common source of
     interoperability failures.

  6.  Tool Definition Signing

     Tool definitions MAY be signed by their author to prevent
     poisoning attacks and to detect unauthorized modifications.

  6.1.  Signed Tool Structure

     A signed tool definition has the following structure:

        {
          "tool": {
            "name": "read_file",
            "description": "Read contents of a file at the
                            given path",
            "inputSchema": {
              "type": "object",
              "properties": {
                "path": {
                  "type": "string",
                  "description": "File path to read"
                }
              },
              "required": ["path"]
            }
          },
          "tool_signature": {
            "author_passport_id": "ap_<uuid>",
            "author_origin": "https://author.example.com",
            "signed_at": "<string (ISO 8601 UTC)>",
            "signature": "<string (base64, IEEE P1363)>",
            "tool_hash": "<string (hex-encoded SHA-256)>"
          }
        }

     The "tool_signature" field contains:

     author_passport_id:  REQUIRED.  String.  The passport identifier
        of the tool author.

     author_origin:  OPTIONAL.  String.  The origin URI of the tool
        author.  When present, enables tool-server origin binding
        (see Section 6.2).

     signed_at:  REQUIRED.  String.  ISO 8601 UTC timestamp of when
        the tool definition was signed.

     signature:  REQUIRED.  String.  Base64-encoded IEEE P1363 ECDSA
        signature (with low-S normalization) over the JCS-
        canonicalized tool signing object (see Section 6.3).

     tool_hash:  REQUIRED.  String.  Hexadecimal-encoded SHA-256
        digest of the JCS-canonicalized tool signing object.  This
        enables efficient change detection without re-verifying the
        full signature.

  6.2.  Author Origin Binding

     The "author_origin" field in the tool signature binds the signed
     tool to a specific serving origin.  This prevents tool relaying
     attacks where a validly signed tool is served from an unauthorized
     server.

     When "author_origin" is present in the tool signature:

     1.  Clients SHOULD verify that the "author_origin" matches the
         origin of the server currently serving the tool.

     2.  If the origin does not match, the client SHOULD alert the
         user or reject the tool according to its configured policy.

     When "author_origin" is null or absent, origin binding is not
     enforced.  This supports cases where a tool author intentionally
     distributes tools for use on third-party servers.

  6.3.  Signing Process

     To sign a tool definition:

     1.  Construct the signing object:

            {
              "author_origin": "<author's origin URI or null>",
              "description": "<tool description>",
              "inputSchema": { ... },
              "name": "<tool name>"
            }

         Note: The signing object keys are ordered lexicographically
         per RFC 8785 conventions.

     2.  JCS-canonicalize [RFC8785] the signing object.

     3.  Compute the SHA-256 hash of the JCS-canonicalized output.
         Record this as the "tool_hash" field (hex-encoded).

     4.  Sign the JCS-canonicalized output with the tool author's
         private key using ECDSA P-256, producing an IEEE P1363
         signature with low-S normalization (Section 3.7).

     Important: The hash covers the entire signing object, including
     the "description" field.  This is critical because tool poisoning
     attacks primarily target the description field (injecting
     instructions into agent prompts), not the inputSchema.  A hash
     covering only the schema would not detect description-based
     poisoning attacks.

  6.4.  Verification and Pinning

     Clients SHOULD maintain a persistent pin store mapping
     (server_origin, tool_name) tuples to the last known tool_hash
     value.  On each connection:

     1.  Verify the tool signature against the author's Agent Passport
         public key.

     2.  Verify the author's passport is bound to the correct origin
         (Section 4.4).

     3.  If "author_origin" is present in the tool signature, verify
         it matches the origin of the server serving the tool
         (Section 6.2).

     4.  Compare the received "tool_hash" against the pinned value
         in the local pin store.

     5.  If no pinned value exists, store the current tool_hash
         (trust on first use).

     6.  If the hash has changed since the last pinned value, the
         client MUST take action according to its configured policy
         (see Section 6.5).

  6.5.  Rug Pull Detection

     When a tool's tool_hash changes between sessions, a "rug pull"
     may have occurred: the tool's name, description, or schema has
     been modified without the user's knowledge.

     Implementations MUST support at least one of the following
     policies for handling tool hash changes:

     Alert:  Notify the user that the tool definition has changed and
        request confirmation before proceeding.

     Reject:  Reject the tool and return error code -33008.

     Accept:  Accept the new definition and update the pin store.
        This policy is NOT RECOMMENDED for Trust Levels L3 and L4.

     The default policy SHOULD be "alert" for Trust Levels L1 and L2,
     and "reject" for Trust Levels L3 and L4.

  7.  Replay Protection

     MCPS uses a dual mechanism for replay protection combining nonce
     uniqueness with timestamp windowing.

  7.1.  Nonce Requirements

     Each signed message MUST include a nonce in the "mcps" header.
     The nonce MUST be generated as 16 cryptographically random bytes,
     hex-encoded (producing a 32-character hexadecimal string).

     Recipients MUST maintain a nonce store and MUST reject any
     message whose nonce has been previously observed.  A duplicate
     nonce MUST result in error code -33005.

  7.2.  Timestamp Window

     Messages with timestamps older than the configurable timestamp
     window MUST be rejected with error code -33006.  The default
     timestamp window is 300 seconds (5 minutes).

     Implementations SHOULD allow the timestamp window to be
     configured.  The minimum permitted timestamp window is 30 seconds.
     The maximum permitted timestamp window is 3600 seconds (1 hour).

     Implementations SHOULD allow a configurable clock skew tolerance
     to account for imprecise system clocks.  The default clock skew
     tolerance is 60 seconds.  The effective acceptance window is
     therefore (timestamp_window + clock_skew_tolerance).

  7.3.  Nonce Store Requirements

     Implementations MUST store nonces for at least the duration of
     the timestamp window plus the clock skew tolerance.

     Nonce stores MUST key on the nonce string value, NOT on full
     message bytes.  This is critical for preventing ECDSA signature
     malleability from bypassing replay detection: given a valid
     signature (r, s), the signature (r, n-s) is also valid for the
     same message, producing different message bytes but containing
     the same nonce.  Keying on the nonce string ensures that both
     the original and the malleable variant are detected as replays.

     Implementations SHOULD periodically garbage-collect nonces whose
     associated timestamps fall outside the acceptance window.

     The nonce store MAY be implemented as:

     o  An in-memory data structure for single-process deployments.

     o  A shared data store (e.g., Redis, database table) for
        distributed deployments.

     o  A Bloom filter for memory-constrained environments, accepting
        a configurable false-positive rate (which results in
        legitimate messages being incorrectly rejected as replays).

  8.  Trust Authority

     A Trust Authority (TA) is a service that issues and manages Agent
     Passports.  The TA role is analogous to a Certificate Authority
     in the TLS/PKI ecosystem.

  8.1.  Self-Hosting

     Any organization MAY operate its own Trust Authority.  A Trust
     Authority is defined by:

     1.  An ECDSA P-256 key pair (the TA's signing key).

     2.  A public key distribution mechanism (see Section 8.2).

     3.  For L3+ passports: a documented origin verification process.

     4.  For L4 passports: a revocation endpoint and audit process.

     There is no requirement to use any specific Trust Authority
     service.  Implementations MUST support configuring one or more
     custom TA public keys as trust anchors.

  8.2.  Public Key Distribution

     Trust Authority public keys MAY be distributed via any of the
     following mechanisms:

     o  An HTTPS endpoint serving the TA's public key in JWK format.

     o  A JWK Set endpoint conforming to [RFC7517].

     o  Static configuration in the client or server application.

     Implementations MUST support at least one of these mechanisms.
     HTTPS-based distribution SHOULD use TLS with certificate
     validation.

  8.3.  Issuer Chains

     Trust delegation follows X.509-style chains:

     1.  A root TA signs intermediate TA passports.

     2.  Intermediate TAs sign agent passports.

     3.  Verifiers walk the chain from agent passport to a root key
         in their configured trust store.

     4.  If no chain leads to a trusted root, the passport MUST be
         treated as L0.

     The "issuer_chain" field in the passport contains a chain of
     base64-encoded JSON intermediate Trust Authority passports,
     ordered from the agent's immediate issuer to the root.  Each
     entry is a complete signed intermediate TA passport.  The chain
     MUST NOT exceed MAX_ISSUER_CHAIN_DEPTH (5) entries.

  8.4.  Issuer Chain Entry Format

     Each entry in the "issuer_chain" array is a base64-encoded JSON
     string representing a complete signed intermediate Trust Authority
     passport.  When decoded from base64, each entry contains:

        {
          "mcps_version": "1.0",
          "passport_id": "ap_<intermediate-uuid>",
          "agent": {
            "name": "Intermediate TA Name",
            "version": "1.0.0",
            "capabilities": []
          },
          "public_key": {
            "kty": "EC",
            "crv": "P-256",
            "x": "<base64url>",
            "y": "<base64url>"
          },
          "origin": "https://intermediate-ta.example.com",
          "trust_level": 2,
          "issued_at": "<ISO 8601 UTC>",
          "expires_at": "<ISO 8601 UTC>",
          "issuer": "<parent-ta-id>",
          "issuer_chain": [],
          "signature": "<base64, IEEE P1363>"
        }

     The intermediate passport contains its own signature, public key,
     and issuer fields.  The "signature" is produced by the parent TA
     (the TA that issued this intermediate), and the "public_key" is
     the intermediate TA's own key which was used to sign the next
     passport down the chain.

  8.5.  Chain Verification Algorithm

     Verifiers MUST implement the following algorithm to validate an
     issuer chain:

     1.  Let P be the agent passport to verify.

     2.  Check that the length of P.issuer_chain does not exceed
         MAX_ISSUER_CHAIN_DEPTH (5).  If it does, reject with error
         code -33014 (MCPS_CHAIN_TOO_DEEP).

     3.  If P.issuer is directly present in the verifier's trust
         store, verify P.signature against that TA's public key.
         If verification succeeds, the chain is valid.  Done.

     4.  If P.issuer_chain is empty or absent, treat the passport
         as L0.  Done.

     5.  Set i = 0 (index into issuer_chain).

     6.  Decode issuer_chain[i] from base64, parse as JSON.
         Let IC = the decoded intermediate passport.

     7.  Verify P.signature against IC.public_key (the intermediate
         TA's public key).  If verification fails, treat the
         passport as L0.

     8.  Verify that IC has not expired (check IC.expires_at).

     9.  If IC.issuer is in the verifier's trust store, verify
         IC.signature against the trust store's public key for that
         issuer.  If verification succeeds, the chain is valid.
         Done.

     10. If i+1 < length of issuer_chain, set P = IC, increment i,
         and go to step 6.

     11. If the chain is exhausted without reaching a trusted root,
         treat the passport as L0.

     At each step, signature verification MUST use IEEE P1363 format
     with low-S normalization (Section 3.7).

  8.6.  Multi-TA Deployments

     Implementations SHOULD support multiple Trust Authorities
     simultaneously:

     1.  The trust store MAY contain public keys from multiple TAs.

     2.  When verifying an issuer chain, the verifier checks each
         configured TA in the trust store for a matching issuer
         identifier.

     3.  When checking revocation, implementations SHOULD try each
         configured TA that could have issued the passport until a
         reachable one responds.

     4.  Cross-TA trust (where TA-A trusts passports issued by TA-B)
         is established explicitly by including TA-B's signing key
         in TA-A's trust store.  There is no implicit cross-TA trust.

     5.  Implementations MUST NOT assume any trust relationship
         between TAs unless explicitly configured.

  8.7.  Revocation

     Trust Authorities providing L4 passports MUST publish signed
     revocation information using one or both of the following
     mechanisms:

  8.7.1.  Revocation List (CRL-style)

     An HTTP GET endpoint returning a signed JSON object:

        {
          "revoked": ["ap_<uuid>", "ap_<uuid>"],
          "updated_at": "<string (ISO 8601 UTC)>",
          "signature": "<string (base64, IEEE P1363)>"
        }

     The "revoked" array contains the passport identifiers of all
     revoked passports.  The "updated_at" field indicates when the
     list was last modified.

     The "signature" field MUST contain a base64-encoded IEEE P1363
     ECDSA signature (with low-S normalization) computed over the
     JCS-canonicalized JSON object containing only the "revoked" and
     "updated_at" fields.  This signature MUST be produced by the
     issuing Trust Authority's private key.

     Clients SHOULD cache the revocation list and refresh it
     periodically.  The refresh interval SHOULD be configurable with
     a default of 300 seconds.

  8.7.2.  Per-Passport Status Check (OCSP-style)

     An HTTP GET endpoint at the path "/{passport_id}/status"
     returning a signed JSON object:

        {
          "passport_id": "ap_<uuid>",
          "status": "<string>",
          "checked_at": "<string (ISO 8601 UTC)>",
          "signature": "<string (base64, IEEE P1363)>"
        }

     The "status" field MUST be one of:

     o  "active" - The passport is valid and has not been revoked.

     o  "revoked" - The passport has been revoked by the Trust
        Authority.

     o  "expired" - The passport has passed its "expires_at" timestamp.

     o  "unknown" - The passport identifier is not recognized by this
        Trust Authority.

     The "signature" field MUST contain a base64-encoded IEEE P1363
     ECDSA signature (with low-S normalization) computed over the
     JCS-canonicalized JSON object containing only the "passport_id",
     "status", and "checked_at" fields.  This signature MUST be
     produced by the issuing Trust Authority's private key.

     Revocation responses MUST be signed by the issuing Trust
     Authority.  Unsigned revocation responses MUST be rejected.

  8.8.  Revocation Endpoint Discovery

     The revocation endpoint URL MUST NOT be supplied by the party
     being verified.  Instead:

     1.  The revocation endpoint is discovered from the Trust
         Authority's published metadata (JWK Set document or
         well-known endpoint).

     2.  Alternatively, the verifier configures the revocation endpoint
         out-of-band when adding the TA to its trust store.

     This prevents an attacker from directing revocation checks to a
     server they control, which could return fraudulent "active"
     responses for revoked passports.

  8.9.  Revocation Failure Policy

     If the revocation endpoint is unreachable, implementations MUST
     behave as follows:

     For Trust Level L4:  Implementations MUST fail-closed (reject
        the passport).  Revocation checking is mandatory at L4;
        proceeding without it violates the L4 guarantee.

     For L1-L3 with optional revocation configured:  If a deployment
        enables optional revocation checking at L1-L3 and the endpoint
        is unreachable, implementations MUST fail-closed (reject the
        passport).  If the operator wants fail-open behavior, they
        SHOULD disable revocation checking rather than relying on
        silent fallback.

     For L1-L3 without revocation configured:  Revocation checking is
        skipped entirely (default for L1-L3).

     Implementations SHOULD cache the last successful revocation
     response and apply a configurable maximum cache age (default:
     300 seconds).  A valid cached response MAY be used when the
     endpoint is temporarily unreachable, provided the cache has not
     expired.

  9.  Capability Negotiation

     MCPS capabilities are negotiated during the MCP "initialize"
     handshake, using the standard MCP capability extension mechanism.

  9.1.  Version Negotiation

     The "mcps" capability includes a "version" field for protocol
     version negotiation.  Implementations MUST support version
     negotiation:

     1.  The client announces its supported MCPS version(s) in the
         "mcps.version" field.  The value MAY be a single version
         string (e.g., "1.0") or an array of version strings
         (e.g., ["1.0", "2.0"]) for forward compatibility.

     2.  The server responds with the highest mutually supported
         version in its "mcps.version" field (always a single string).

     3.  If no mutually supported version exists, the server MUST
         reject the connection with error code -33015
         (MCPS_VERSION_MISMATCH).

     4.  After version negotiation, all subsequent MCPS operations
         MUST use the negotiated version.

     This mechanism enables forward compatibility as new MCPS protocol
     versions are introduced.

  9.2.  Client Announcement

     An MCPS-capable client announces its support by including an
     "mcps" object within the "capabilities" field of the "initialize"
     request:

        {
          "jsonrpc": "2.0",
          "method": "initialize",
          "params": {
            "protocolVersion": "2025-03-26",
            "capabilities": {
              "mcps": {
                "version": "1.0",
                "trust_level": 2,
                "passport": { ... }
              }
            },
            "clientInfo": {
              "name": "my-agent",
              "version": "1.0.0"
            }
          },
          "id": 1
        }

     The "mcps" capability object contains:

     version:  REQUIRED.  The MCPS protocol version(s) supported.
        String or array of strings.

     trust_level:  REQUIRED.  The maximum trust level the client
        supports.

     passport:  REQUIRED.  The client's Agent Passport.

  9.3.  Server Response

     An MCPS-capable server responds with its own MCPS capabilities:

        {
          "jsonrpc": "2.0",
          "result": {
            "protocolVersion": "2025-03-26",
            "capabilities": {
              "mcps": {
                "version": "1.0",
                "min_trust_level": 2,
                "passport": { ... }
              }
            },
            "serverInfo": {
              "name": "secure-server",
              "version": "2.0.0"
            }
          },
          "id": 1
        }

     The server's "mcps" capability object contains:

     version:  REQUIRED.  The negotiated MCPS protocol version
        (single string).

     min_trust_level:  REQUIRED.  The minimum trust level required
        for connections to this server.

     passport:  REQUIRED.  The server's Agent Passport.

     Note: The server's capability response MUST NOT include a
     revocation_endpoint field.  Revocation endpoints are discovered
     via Trust Authority metadata (Section 8.8), not supplied by the
     party being verified.

  9.4.  Negotiation Failure

     If the client's trust level is below the server's
     "min_trust_level", the server MUST reject the connection with
     JSON-RPC error code -33009 (MCPS_TRUST_LEVEL_INSUFFICIENT).

     If the MCPS versions are incompatible (no mutual version), the
     server MUST reject the connection with error code -33015
     (MCPS_VERSION_MISMATCH).

     If the server does not include an "mcps" capability in its
     response, the client MUST operate without MCPS verification
     (Trust Level L0) or disconnect, depending on its configured
     minimum trust level requirement.

  9.5.  Transcript Binding (Anti-Downgrade)

     After capability negotiation, both parties MUST exchange a
     transcript binding to confirm they agree on the negotiated
     security parameters.  This prevents an active attacker from
     stripping the "mcps" capability during the handshake (downgrade
     attack).

     Note: This mechanism uses ECDSA signatures (asymmetric), not
     MAC (symmetric).  Previous drafts used the term "transcript MAC";
     this has been corrected to "transcript binding" for accuracy.

     Transcript scope: The transcript covers the "params" field from
     the client's initialize request and the "result" field from the
     server's initialize response -- NOT the full JSON-RPC envelope
     (which includes the jsonrpc version string, method name, and
     message id that are not security-relevant).

     The procedure is as follows:

     1.  Both parties compute:

         transcript_hash = SHA-256(
           JCS(client_initialize_params) ||
           JCS(server_initialize_result)
         )

         where "||" denotes byte concatenation, and JCS is the
         RFC 8785 canonicalization.  "client_initialize_params" is the
         value of the "params" field from the client's initialize
         request.  "server_initialize_result" is the value of the
         "result" field from the server's initialize response.

     2.  Each party signs the transcript_hash with their private key
         using ECDSA P-256, producing an IEEE P1363 signature with
         low-S normalization (Section 3.7).

     3.  The signed transcript is exchanged as the first signed
         message after the "initialize" handshake, using the method
         "mcps/transcript_verify":

            {
              "mcps": {
                "version": "1.0",
                "passport_id": "ap_<uuid>",
                "timestamp": "<ISO 8601 UTC>",
                "nonce": "<hex, 16 random bytes>",
                "signature": "<base64, IEEE P1363>"
              },
              "jsonrpc": "2.0",
              "method": "mcps/transcript_verify",
              "params": {
                "transcript_hash": "<hex SHA-256>",
                "transcript_signature": "<base64, IEEE P1363>"
              },
              "id": 2
            }

     4.  Each party verifies the other's transcript binding by:
         a.  Recomputing the transcript_hash from their own records.
         b.  Verifying the received transcript_hash matches.
         c.  Verifying the transcript_signature against the other
             party's passport public key.

     5.  If the transcript bindings do not match, the connection MUST
         be terminated with error code -33012
         (MCPS_TRANSCRIPT_MISMATCH).

     This mechanism is analogous to the TLS Finished message, which
     prevents downgrade attacks by binding both parties to the same
     view of the negotiated parameters.

  10.  Error Codes

     MCPS defines the following JSON-RPC error codes in the -33xxx
     range, avoiding collision with JSON-RPC's reserved
     implementation-defined range (-32000 to -32099).  Each error has
     both a numeric code and a string code for programmatic handling:

        +--------+---------+-------------------------------+
        | Code   | String  | Name                          |
        +--------+---------+-------------------------------+
        | -33001 | MCPS-001| MCPS_INVALID_PASSPORT         |
        |        |         | Passport format invalid.      |
        +--------+---------+-------------------------------+
        | -33002 | MCPS-002| MCPS_PASSPORT_EXPIRED         |
        |        |         | Passport has expired.         |
        +--------+---------+-------------------------------+
        | -33003 | MCPS-003| MCPS_PASSPORT_REVOKED         |
        |        |         | Passport has been revoked.    |
        +--------+---------+-------------------------------+
        | -33004 | MCPS-004| MCPS_INVALID_SIGNATURE        |
        |        |         | Message signature             |
        |        |         | verification failed.          |
        +--------+---------+-------------------------------+
        | -33005 | MCPS-005| MCPS_REPLAY_DETECTED          |
        |        |         | Duplicate nonce detected.     |
        +--------+---------+-------------------------------+
        | -33006 | MCPS-006| MCPS_TIMESTAMP_EXPIRED        |
        |        |         | Message timestamp outside     |
        |        |         | acceptable window.            |
        +--------+---------+-------------------------------+
        | -33007 | MCPS-007| MCPS_AUTHORITY_UNREACHABLE    |
        |        |         | Trust Authority unreachable   |
        |        |         | (fail-closed).                |
        +--------+---------+-------------------------------+
        | -33008 | MCPS-008| MCPS_TOOL_INTEGRITY_FAILED    |
        |        |         | Tool definition signature     |
        |        |         | invalid or hash changed.      |
        +--------+---------+-------------------------------+
        | -33009 | MCPS-009| MCPS_TRUST_LEVEL_INSUFFICIENT |
        |        |         | Client trust level below      |
        |        |         | server minimum.               |
        +--------+---------+-------------------------------+
        | -33010 | MCPS-010| MCPS_RATE_LIMITED              |
        |        |         | Rate limit exceeded.          |
        +--------+---------+-------------------------------+
        | -33011 | MCPS-011| MCPS_ORIGIN_MISMATCH          |
        |        |         | Passport origin does not      |
        |        |         | match server URI.             |
        +--------+---------+-------------------------------+
        | -33012 | MCPS-012| MCPS_TRANSCRIPT_MISMATCH      |
        |        |         | Transcript binding            |
        |        |         | verification failed           |
        |        |         | (downgrade detected).         |
        +--------+---------+-------------------------------+
        | -33013 | MCPS-013| MCPS_PASSPORT_TOO_LARGE       |
        |        |         | Passport exceeds maximum      |
        |        |         | size (8192 bytes).            |
        +--------+---------+-------------------------------+
        | -33014 | MCPS-014| MCPS_CHAIN_TOO_DEEP           |
        |        |         | Issuer chain exceeds          |
        |        |         | maximum depth (5).            |
        +--------+---------+-------------------------------+
        | -33015 | MCPS-015| MCPS_VERSION_MISMATCH         |
        |        |         | No mutually supported MCPS    |
        |        |         | version.                      |
        +--------+---------+-------------------------------+

     Error responses MUST include the standard JSON-RPC error format
     with a "data" object providing additional context:

        {
          "jsonrpc": "2.0",
          "error": {
            "code": -33004,
            "message": "MCPS_INVALID_SIGNATURE",
            "data": {
              "string_code": "MCPS-004",
              "passport_id": "ap_<uuid>",
              "reason": "Signature does not match message
                         content"
            }
          },
          "id": 1
        }

     The "data" object SHOULD include:

     string_code:  The MCPS string code (e.g., "MCPS-004") for
        programmatic error handling across implementations that may
        use different numeric error code conventions.

     passport_id:  The passport identifier associated with the error,
        if applicable.

     reason:  A human-readable description of the failure cause.

     Design note: The -33xxx range is used because JSON-RPC 2.0
     reserves error codes -32000 to -32099 for "implementation-defined
     server errors."  The previous draft (01) incorrectly placed MCPS
     error codes in the -32001 to -32009 range, which collides with
     this reserved range.  The -33xxx range is outside all JSON-RPC
     reserved ranges, providing a clean namespace for MCPS errors.

  11.  Security Considerations

  11.1.  Threat Model

     MCPS defends against the following threats:

        +---------------------------+-----------------------------------+
        | Threat                    | Mitigation                        |
        +---------------------------+-----------------------------------+
        | Server impersonation      | Origin-bound passports (Sec 4.4)  |
        +---------------------------+-----------------------------------+
        | Message tampering         | Per-message signatures (Sec 5)    |
        +---------------------------+-----------------------------------+
        | Tool description poisoning| Full-tool-object hashing          |
        |                           | including description (Sec 6)     |
        +---------------------------+-----------------------------------+
        | Replay attacks            | Nonce + timestamp (Sec 7)         |
        +---------------------------+-----------------------------------+
        | Signature malleability    | Low-S normalization (Sec 3.7)     |
        +---------------------------+-----------------------------------+
        | Capability downgrade      | Transcript binding (Sec 9.5)      |
        +---------------------------+-----------------------------------+
        | Revocation bypass         | Signed revocation responses,      |
        |                           | fail-closed default (Sec 8.7-8.9) |
        +---------------------------+-----------------------------------+
        | Trust level inflation     | Issuer chain validation,          |
        |                           | self-signed capped at L0 (Sec 3.4)|
        +---------------------------+-----------------------------------+
        | Oversized passport DoS    | Size limits (Sec 4.3)             |
        +---------------------------+-----------------------------------+
        | Tool relaying             | Author origin binding (Sec 6.2)   |
        +---------------------------+-----------------------------------+
        | Agent key compromise      | Key rotation with                 |
        |                           | previous_key_hash (Sec 4.5)       |
        +---------------------------+-----------------------------------+
        | TLS relay (MITM)          | Optional channel binding          |
        |                           | (Sec 5.3)                         |
        +---------------------------+-----------------------------------+

     MCPS does NOT defend against:

        +---------------------------+-----------------------------------+
        | Threat                    | Why Not                           |
        +---------------------------+-----------------------------------+
        | Malicious tool authored   | Provenance proves WHO, not safety.|
        | by legitimate server      | See Section 11.2.                 |
        +---------------------------+-----------------------------------+
        | Compromised Trust         | Same as X.509: TA compromise is   |
        | Authority                 | catastrophic.  Mitigated by key   |
        |                           | rotation, multiple TAs (Sec 8.6). |
        +---------------------------+-----------------------------------+
        | Compromised agent key     | Agent must protect its key.  HSM  |
        |                           | recommended for L4.  Key rotation |
        |                           | provides recovery (Sec 4.5).      |
        +---------------------------+-----------------------------------+

  11.2.  Provenance vs Safety

     MCPS provides provenance (WHO authored a tool or sent a message),
     not safety analysis.  A malicious server operator can sign their
     own poisoned tool definitions with a valid MCPS signature.

     Tool safety analysis -- detecting malicious descriptions,
     sandboxing execution, and input validation -- is a separate
     concern that complements MCPS.  Implementations SHOULD NOT
     treat a valid MCPS signature as evidence that a tool is safe
     to execute.

  11.3.  Trust Authority Compromise

     If a Trust Authority's signing key is compromised, an attacker
     can issue fraudulent Agent Passports.  To mitigate this risk:

     o  Trust Authority private keys SHOULD be stored in hardware
        security modules (HSMs) or equivalent tamper-resistant
        hardware.

     o  Trust Authorities SHOULD implement key rotation procedures
        with documented key ceremony practices.

     o  Trust Authorities MUST publish revocation lists promptly upon
        detecting key compromise.

     o  Clients SHOULD support pinning Trust Authority public keys to
        detect unauthorized key changes.

     o  Deployments SHOULD configure multiple TAs (Section 8.6) to
        reduce single-point-of-failure risk.

     This is the same risk model as X.509 Certificate Authority
     compromise.  Mitigations are well-understood from the TLS/PKI
     ecosystem.

  11.4.  Nonce Store Exhaustion

     An attacker could flood a server with messages containing unique
     nonces to exhaust the nonce store's memory.  Implementations
     MUST mitigate this by:

     o  Garbage-collecting nonces whose associated timestamps have
        fallen outside the acceptance window.

     o  Implementing rate limiting on incoming messages.

     o  Setting a maximum nonce store size with a least-recently-used
        eviction policy as a last resort.

  11.5.  Clock Skew Attacks

     An attacker with the ability to manipulate system clocks on
     either the sender or receiver could bypass timestamp validation.
     Mitigations include:

     o  Implementations at Trust Level L3 and above SHOULD require
        NTP synchronization or equivalent time source.

     o  The configurable clock skew tolerance limits the exploitable
        window.

     o  The nonce mechanism provides a secondary protection layer
        independent of timestamps.

  11.6.  Algorithm Agility

     This specification mandates ECDSA P-256 as the sole algorithm.
     Future versions of MCPS MAY introduce algorithm negotiation to
     support additional curves or signature schemes via the version
     negotiation mechanism defined in Section 9.1.

     Implementations SHOULD be designed to accommodate future algorithm
     changes by parameterizing the signature algorithm rather than
     hard-coding P-256.

     If algorithm negotiation is introduced in future versions, the
     "mcps" header MUST include an "alg" field indicating the
     algorithm used, and both parties MUST agree on a common algorithm
     during capability negotiation.

  11.7.  Privacy Considerations

     Agent Passports contain an agent name, origin, and public key.
     The origin reveals the server the agent is authorized to
     communicate with.

     Passport identifiers are pseudonymous (UUID-based).  They do not
     reveal the agent operator's identity without Trust Authority
     cooperation.

     Signed messages enable non-repudiation: it is possible to prove
     cryptographically that a specific agent sent a specific message.
     This property may conflict with privacy requirements in certain
     jurisdictions.  Operators SHOULD consider data retention policies
     for signed message logs.

     Implementations SHOULD NOT include sensitive or personally
     identifiable information in the "agent_name" or "capabilities"
     fields of Agent Passports.

  11.8.  Non-Repudiation Implications

     Because MCPS signatures are produced using long-lived agent keys,
     signed messages provide strong non-repudiation properties.  This
     means that a signed message can be presented as evidence that a
     particular agent sent a particular message at a particular time.

     Operators deploying MCPS SHOULD be aware that signed message logs
     may have legal implications, particularly in regulated industries.
     Message retention and disposal policies SHOULD be established as
     part of MCPS deployment planning.

  12.  IANA Considerations

  12.1.  MCPS Error Code Registry

     This document requests IANA to create a new registry titled
     "MCPS Error Codes" with the following initial entries:

        +--------+---------+-------------------------------+-----------+
        | Code   | String  | Name                          | Reference |
        +--------+---------+-------------------------------+-----------+
        | -33001 | MCPS-001| MCPS_INVALID_PASSPORT         | [this doc]|
        | -33002 | MCPS-002| MCPS_PASSPORT_EXPIRED         | [this doc]|
        | -33003 | MCPS-003| MCPS_PASSPORT_REVOKED         | [this doc]|
        | -33004 | MCPS-004| MCPS_INVALID_SIGNATURE        | [this doc]|
        | -33005 | MCPS-005| MCPS_REPLAY_DETECTED          | [this doc]|
        | -33006 | MCPS-006| MCPS_TIMESTAMP_EXPIRED        | [this doc]|
        | -33007 | MCPS-007| MCPS_AUTHORITY_UNREACHABLE    | [this doc]|
        | -33008 | MCPS-008| MCPS_TOOL_INTEGRITY_FAILED    | [this doc]|
        | -33009 | MCPS-009| MCPS_TRUST_LEVEL_INSUFFICIENT | [this doc]|
        | -33010 | MCPS-010| MCPS_RATE_LIMITED              | [this doc]|
        | -33011 | MCPS-011| MCPS_ORIGIN_MISMATCH          | [this doc]|
        | -33012 | MCPS-012| MCPS_TRANSCRIPT_MISMATCH      | [this doc]|
        | -33013 | MCPS-013| MCPS_PASSPORT_TOO_LARGE       | [this doc]|
        | -33014 | MCPS-014| MCPS_CHAIN_TOO_DEEP           | [this doc]|
        | -33015 | MCPS-015| MCPS_VERSION_MISMATCH         | [this doc]|
        +--------+---------+-------------------------------+-----------+

     New entries in this registry require Standards Action [RFC8126].

  12.2.  MCPS Trust Level Registry

     This document requests IANA to create a new registry titled
     "MCPS Trust Levels" with the following initial entries:

        +-------+----------+------+-----------------------------------+
        | Level | Name     | Ref  | Description                       |
        +-------+----------+------+-----------------------------------+
        | 0     | None     | [td] | No MCPS verification              |
        | 1     | Signed   | [td] | Signed, any TA                    |
        | 2     | Verified | [td] | Signed, recognized TA required    |
        | 3     | Strict   | [td] | L2 + tool sigs + origin verified  |
        | 4     | Full     | [td] | L3 + mutual auth + revocation     |
        +-------+----------+------+-----------------------------------+

        [td] = [this document]

     New entries in this registry require Specification Required
     [RFC8126].

  12.3.  MCPS Capability Identifier

     This document registers the capability identifier "mcps" for use
     within the MCP capabilities negotiation framework.  Implementations
     using this capability identifier MUST conform to the negotiation
     procedures defined in Section 9 of this document.

  13.  References

  13.1.  Normative References

     [FIPS186-5]
                National Institute of Standards and Technology, "Digital
                Signature Standard (DSS)", FIPS PUB 186-5,
                DOI 10.6028/NIST.FIPS.186-5, February 2023.

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

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

     [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
                DOI 10.17487/RFC6454, December 2011,
                <https://www.rfc-editor.org/info/rfc6454>.

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

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

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

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

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

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

     [RFC9266]  Shoemaker, R., "Channel Bindings for TLS 1.3",
                RFC 9266, DOI 10.17487/RFC9266, July 2022,
                <https://www.rfc-editor.org/info/rfc9266>.

  13.2.  Informative References

     [RFC9421]  Backman, A., Richer, J., 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>.

     [JSONRPC]  JSON-RPC Working Group, "JSON-RPC 2.0 Specification",
                January 2013, <https://www.jsonrpc.org/specification>.

     [SEMVER]   Preston-Werner, T., "Semantic Versioning 2.0.0",
                <https://semver.org/>.

  Appendix A.  Example Protocol Exchange

     This appendix provides a complete example of an MCPS-secured MCP
     session, illustrating capability negotiation, transcript binding
     verification, and signed tool invocation.

  A.1.  Capability Negotiation

     Client sends initialize request with MCPS capability:

        {
          "jsonrpc": "2.0",
          "method": "initialize",
          "params": {
            "protocolVersion": "2025-03-26",
            "capabilities": {
              "mcps": {
                "version": "1.0",
                "trust_level": 2,
                "passport": {
                  "mcps_version": "1.0",
                  "passport": {
                    "id":
                      "ap_550e8400-e29b-41d4-a716-446655440000",
                    "agent_name": "research-agent",
                    "agent_version": "1.2.0",
                    "issuer": "ta.example.com",
                    "origin": "https://api.example.com",
                    "issued_at": "2026-03-01T00:00:00Z",
                    "expires_at": "2026-09-01T00:00:00Z",
                    "public_key": {
                      "kty": "EC",
                      "crv": "P-256",
                      "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8T
                            us9uPHvRVEU",
                      "y": "x_FEzRu9m36HLN_tue659LNpXW6pCySt
                            ikYjKIWI5a0"
                    },
                    "capabilities": [
                      "tools/call",
                      "tools/list"
                    ],
                    "trust_level": 2,
                    "issuer_chain": []
                  },
                  "signature": "MEUCIQC...base64..."
                }
              }
            },
            "clientInfo": {
              "name": "research-agent",
              "version": "1.2.0"
            }
          },
          "id": 1
        }

     Server responds with its MCPS capabilities and passport:

        {
          "jsonrpc": "2.0",
          "result": {
            "protocolVersion": "2025-03-26",
            "capabilities": {
              "mcps": {
                "version": "1.0",
                "min_trust_level": 2,
                "passport": {
                  "mcps_version": "1.0",
                  "passport": {
                    "id":
                      "ap_660f9511-f30c-52e5-b827-557766551111",
                    "agent_name": "file-server",
                    "agent_version": "2.0.0",
                    "issuer": "ta.example.com",
                    "origin": "https://api.example.com",
                    "issued_at": "2026-02-15T00:00:00Z",
                    "expires_at": "2026-08-15T00:00:00Z",
                    "public_key": {
                      "kty": "EC",
                      "crv": "P-256",
                      "x": "2ygLm3slRf6MtoN_-D2bLMMq_10eCMei
                            -yLAbFYmPFE",
                      "y": "4PUOD5BNzGMIAnvMjMVHRwZ3XwGBJjB0
                            NJEwPHLJDjg"
                    },
                    "capabilities": ["tools/call"],
                    "trust_level": 2,
                    "issuer_chain": []
                  },
                  "signature": "MEQCIAo...base64..."
                }
              }
            },
            "serverInfo": {
              "name": "file-server",
              "version": "2.0.0"
            }
          },
          "id": 1
        }

  A.2.  Transcript Binding Verification

     Both parties exchange transcript bindings after initialize.
     The transcript hash is computed over the "params" field of the
     client's initialize request and the "result" field of the
     server's initialize response (NOT the full JSON-RPC envelopes):

        {
          "mcps": {
            "version": "1.0",
            "passport_id":
              "ap_550e8400-e29b-41d4-a716-446655440000",
            "timestamp": "2026-03-13T14:29:55Z",
            "nonce":
              "b2c3d4e5f6a748b90c1d2e3f4a5b6c7d",
            "signature": "MEQCIBx...base64..."
          },
          "jsonrpc": "2.0",
          "method": "mcps/transcript_verify",
          "params": {
            "transcript_hash":
              "a1b2c3...64-char-hex-sha256...",
            "transcript_signature":
              "MEUCIQDk...base64..."
          },
          "id": 2
        }

  A.3.  Signed Tool Call

     Client invokes a tool with MCPS signature:

        {
          "mcps": {
            "version": "1.0",
            "passport_id":
              "ap_550e8400-e29b-41d4-a716-446655440000",
            "timestamp": "2026-03-13T14:30:00Z",
            "nonce":
              "a1b2c3d4e5f647a89b0c1d2e3f4a5b6c",
            "signature": "MEUCIQDr...base64..."
          },
          "jsonrpc": "2.0",
          "method": "tools/call",
          "params": {
            "name": "read_file",
            "arguments": {
              "path": "/etc/hostname"
            }
          },
          "id": 3
        }

  Appendix B.  OWASP Risk Mapping

     The following table maps MCPS features to risks identified by the
     OWASP Top 10 for Agentic Applications (2026) and the OWASP MCP
     Top 10:

        +-----------------------------+---------------------------------+
        | Risk                        | MCPS Mitigation                 |
        +-----------------------------+---------------------------------+
        | Inadequate Agent Identity   | Origin-bound Agent Passports    |
        | (ASI02)                     | with issuer chain validation    |
        +-----------------------------+---------------------------------+
        | Inadequate Tool Validation  | Full tool definition signing    |
        | (ASI03)                     | with description coverage       |
        +-----------------------------+---------------------------------+
        | Delegated Trust Boundaries  | Trust levels enforce minimum    |
        | (ASI04)                     | security per connection         |
        +-----------------------------+---------------------------------+
        | Tool Poisoning (MCP03)      | Signed tool definitions with    |
        |                             | pinned tool_hash detection      |
        +-----------------------------+---------------------------------+
        | Server Impersonation        | Origin-bound passport-based     |
        |                             | mutual authentication           |
        +-----------------------------+---------------------------------+
        | Message Tampering           | Per-message ECDSA signatures    |
        |                             | with JCS canonicalization       |
        +-----------------------------+---------------------------------+
        | Replay Attacks              | Nonce + timestamp window        |
        +-----------------------------+---------------------------------+
        | Capability Downgrade        | Transcript binding              |
        |                             | (Section 9.5)                   |
        +-----------------------------+---------------------------------+
        | Insufficient Authorization  | Trust level gating with         |
        | (MCP07)                     | capability lists                |
        +-----------------------------+---------------------------------+

  Appendix C.  Design Rationale

  C.1.  Why a Separate Envelope (Not Modifying JSON-RPC)

     MCPS wraps existing JSON-RPC messages rather than modifying the
     protocol schema.  This ensures backward compatibility, transport
     independence, and composability with existing OAuth authorization
     and DPoP.

  C.2.  Why ECDSA P-256 (Not Ed25519 or RSA)

     P-256 is mandated by FIPS 186-5, required for government and
     enterprise compliance, and supported by Web Crypto API.  Ed25519
     has superior performance but lacks FIPS certification.  RSA key
     sizes create larger signatures.

  C.3.  Why IEEE P1363 (Not DER)

     DER encoding produces variable-length signatures (typically 70-72
     bytes for P-256).  IEEE P1363 produces fixed-length signatures
     (exactly 64 bytes for P-256).  Fixed-length format eliminates
     parsing ambiguity, is required by RFC 7518 Section 3.4, and
     simplifies cross-platform interoperability.

  C.4.  Why message_hash (Not Nested JCS)

     Earlier drafts used "jsonrpc_message: JCS(message)" in the
     signing payload, nesting one JCS string inside another JCS
     object.  This creates fragility: the inner JCS string must be
     JSON-escaped when embedded in the outer object, and different
     JSON libraries handle this escaping differently.  Using
     "message_hash: SHA-256(JCS(message))" eliminates this ambiguity,
     is more robust, and is more efficient.

  C.5.  Why -33xxx Error Codes (Not -32xxx)

     JSON-RPC 2.0 reserves error codes -32000 to -32099 for
     "implementation-defined server errors."  Using this range for
     MCPS-specific codes would risk collisions with other JSON-RPC
     extensions.  The -33xxx range is outside all reserved ranges,
     providing a clean namespace for MCPS errors.

  C.6.  Why a Lightweight Passport Format (Not Raw X.509)

     Agent Passports serve a similar role to X.509 certificates but
     use a JSON-native format because: (1) MCP is JSON-RPC, so JSON
     credentials avoid ASN.1/DER complexity; (2) the chain model is
     simpler than X.509 path validation; (3) JSON is familiar to the
     MCP developer ecosystem.

     However, the passport model deliberately borrows proven concepts
     from X.509: issuer chains, validity periods, key usage
     constraints, and revocation checking.  Implementations MAY bridge
     to X.509 by embedding a certificate reference in the passport.

  C.7.  Why Not JWS (RFC 7515) for Message Signing

     The per-message envelope is comparable in size to JWS compact
     serialization (~280 bytes vs ~200 bytes for JWS).  The primary
     motivation for a purpose-built envelope is explicitness: the
     "mcps" field contains exactly the fields needed for MCP
     verification (passport_id, nonce, timestamp) without requiring
     implementers to parse JWS headers and map them to MCP semantics.

     An alternative formulation using JWS as the signing container
     is viable and could be explored if the community prefers
     standards composition over a purpose-built format.

  C.8.  Why Self-Hostable Trust Authority

     A centralized TA would create a single point of failure.  The
     self-hostable design ensures no vendor lock-in, air-gapped
     deployment support, regulatory compliance, and resilience.

  Appendix D.  Changes from draft-sharif-mcps-secure-mcp-01

     This section summarizes the changes from version 01 to version 02:

     CRITICAL changes:

     o  Specified IEEE P1363 signature format (r||s concatenation,
        exactly 64 bytes for P-256) per RFC 7518 Section 3.4.
        Explicitly prohibits DER encoding.  Added low-S normalization
        requirement (s <= n/2) with the P-256 curve order constant.
        (Section 3.6, Section 3.7)

     o  Added ECDSA malleability defense: low-S normalization prevents
        (r, n-s) from being accepted as valid alternative.  Nonce
        stores MUST key on nonce string, not full message bytes.
        (Section 3.7, Section 7.3)

     o  Defined issuer chain entry format: each entry is a base64-
        encoded JSON intermediate TA passport with its own signature,
        public_key, and issuer fields.  Added step-by-step chain
        verification algorithm.  Max depth: 5.
        (Section 8.4, Section 8.5)

     o  Changed error code range from -32001..-32009 (which collides
        with JSON-RPC reserved range -32000..-32099) to
        -33001..-33015.  Added string codes MCPS-001 through MCPS-015.
        (Section 10)

     HIGH changes:

     o  Renamed "Transcript MAC" to "Transcript Binding" throughout.
        MCPS uses ECDSA signatures (asymmetric), not MAC (symmetric).
        (Section 2, Section 9.5)

     o  Added version negotiation mechanism during initialize.
        Client may announce single version or array of versions.
        Server responds with highest mutual version or -33015 error.
        (Section 9.1)

     o  Added passport size limits: MAX_PASSPORT_BYTES = 8192,
        MAX_ISSUER_CHAIN_DEPTH = 5, MAX_CAPABILITIES = 64.  Added
        corresponding error codes -33013 and -33014.
        (Section 4.3)

     o  Changed signing payload from "jsonrpc_message: JCS(msg)"
        to "message_hash: SHA-256(JCS(msg))" to avoid double-
        canonicalization fragility.
        (Section 5.2)

     o  Added optional TLS channel binding field (RFC 9266
        tls-exporter) to signing payload.
        (Section 5.3)

     o  Added multi-TA deployment support with documented cross-TA
        trust model.
        (Section 8.6)

     o  Added key_rotation field with previous_key_hash and
        rotated_at for agent key compromise recovery.
        (Section 4.5)

     o  Clarified transcript hash boundary: covers "params" (client)
        and "result" (server), NOT full JSON-RPC envelope.
        (Section 9.5)

     o  Added author_origin to tool signing payload for tool-server
        origin binding.
        (Section 6.1, Section 6.2)

     o  Updated all references from FIPS 186-4 to FIPS 186-5.
        Added note on RFC 6979 vs HSM compatibility with FIPS 186-5
        nonce generation.
        (Section 3.5)

     Additional changes:

     o  Added RFC 7518 and RFC 9266 to normative references.

     o  Updated reference implementation test counts: Node.js 75
        tests, Python 53 tests.

     o  Added six new error codes: MCPS_AUTHORITY_UNREACHABLE (-33007),
        MCPS_RATE_LIMITED (-33010), MCPS_ORIGIN_MISMATCH (-33011),
        MCPS_PASSPORT_TOO_LARGE (-33013), MCPS_CHAIN_TOO_DEEP
        (-33014), MCPS_VERSION_MISMATCH (-33015).

  Author's Address

     Raza Sharif
     CyberSecAI Ltd

     Email: contact@agentsign.dev


name: draft-morrison-mcp-dns-discovery
rev: 04
title: Discovery of Model Context Protocol Servers via DNS TXT Records
time: 2026-05-17T18:46:35Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-18T18:46:35Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:50.499368+00:00
source: ietf
abstract:
  This document defines a DNS-based mechanism for the discovery of
     Model Context Protocol (MCP) servers, the identity properties of the
     organisations that operate them, and (new in this revision) the
     cryptographic identity envelope bound to an individual Sovereign-
     tier ~handle published under the same zone.  Three TXT resource
     records are defined.  The _mcp.<domain> record (defined in v01)
     advertises the presence, endpoint URL, transport protocol,
     cryptographic identity, and capability profile of an MCP server
     associated with a domain name.  The _org-alter.<domain> record
     (introduced in v02) advertises the canonical organisational identity
     of the domain operator: legal entity name, registry identifier,
     founding date, primary regions of operation, and any regulatory
     frameworks under which the operator is bound to refuse external
     automated access.  The _alter.<domain> record (introduced in this
     revision) publishes an Ed25519-signed identity envelope binding a
     ~handle to a public key, an IdentityLog Signed Tree Head root, and a
     revocation commitment.  Taken together, the three records provide
     service discovery, organisational identity bootstrap, and individual
     identity recognition from a single canonical source: the domain's own
     DNS zone.  This revision additionally requires DNSSEC [RFC4033]
     validation of envelope responses and a DANE TLSA [RFC6698] pin
     binding the MCP endpoint's leaf certificate to the published zone.  A
     companion URI scheme (alter:) is registered provisionally with IANA
     per [RFC7595] for handle dispatch.  The mechanism complements HTTPS-
     based discovery (.well-known/mcp/server-card.json and .well-known/
     alter-envelope.json) by providing a lightweight, resolver-cached
     bootstrap that requires no HTTPS round-trip.  The design follows the
     precedent established by DKIM [RFC6376], SPF [RFC7208], DMARC
     [RFC7489], MTA-STS [RFC8461], and the existing _mcp. / _org-alter.
     labels of v01-v02.

full_text:
  Network Working Group                                        B. Morrison
  Internet-Draft                                    Alter Meridian Pty Ltd
  Intended status: Informational                               18 May 2026
  Expires: 19 November 2026


      Discovery of Model Context Protocol Servers via DNS TXT Records
                    draft-morrison-mcp-dns-discovery-04

  Abstract

     This document defines a DNS-based mechanism for the discovery of
     Model Context Protocol (MCP) servers, the identity properties of the
     organisations that operate them, and (new in this revision) the
     cryptographic identity envelope bound to an individual Sovereign-
     tier ~handle published under the same zone.  Three TXT resource
     records are defined.  The _mcp.<domain> record (defined in v01)
     advertises the presence, endpoint URL, transport protocol,
     cryptographic identity, and capability profile of an MCP server
     associated with a domain name.  The _org-alter.<domain> record
     (introduced in v02) advertises the canonical organisational identity
     of the domain operator: legal entity name, registry identifier,
     founding date, primary regions of operation, and any regulatory
     frameworks under which the operator is bound to refuse external
     automated access.  The _alter.<domain> record (introduced in this
     revision) publishes an Ed25519-signed identity envelope binding a
     ~handle to a public key, an IdentityLog Signed Tree Head root, and a
     revocation commitment.  Taken together, the three records provide
     service discovery, organisational identity bootstrap, and individual
     identity recognition from a single canonical source: the domain's own
     DNS zone.  This revision additionally requires DNSSEC [RFC4033]
     validation of envelope responses and a DANE TLSA [RFC6698] pin
     binding the MCP endpoint's leaf certificate to the published zone.  A
     companion URI scheme (alter:) is registered provisionally with IANA
     per [RFC7595] for handle dispatch.  The mechanism complements HTTPS-
     based discovery (.well-known/mcp/server-card.json and .well-known/
     alter-envelope.json) by providing a lightweight, resolver-cached
     bootstrap that requires no HTTPS round-trip.  The design follows the
     precedent established by DKIM [RFC6376], SPF [RFC7208], DMARC
     [RFC7489], MTA-STS [RFC8461], and the existing _mcp. / _org-alter.
     labels of v01-v02.

  Status of This Memo

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





  Morrison                Expires 19 November 2026                [Page 1]


  Internet-Draft              MCP DNS Discovery                   May 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 19 November 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Record Format: _mcp.<domain> (Service Discovery)  . . . . . .   6
     4.  Record Format: _org-alter.<domain> (Identity Bootstrap) . . .   7
     5.  Record Format: _alter.<domain> (Envelope Publication) . . . .   7
       5.1.  DNS Location  . . . . . . . . . . . . . . . . . . . . . .   7
       5.2.  ABNF Grammar  . . . . . . . . . . . . . . . . . . . . . .   8
       5.3.  Field Definitions . . . . . . . . . . . . . . . . . . . .   8
         5.3.1.  v (REQUIRED)  . . . . . . . . . . . . . . . . . . . .   8
         5.3.2.  h (REQUIRED)  . . . . . . . . . . . . . . . . . . . .   9
         5.3.3.  pk (REQUIRED) . . . . . . . . . . . . . . . . . . . .   9
         5.3.4.  ilr (REQUIRED)  . . . . . . . . . . . . . . . . . . .   9
         5.3.5.  ts (REQUIRED) . . . . . . . . . . . . . . . . . . . .   9
         5.3.6.  rev (REQUIRED)  . . . . . . . . . . . . . . . . . . .   9
         5.3.7.  sig (REQUIRED)  . . . . . . . . . . . . . . . . . . .  10
         5.3.8.  Unknown fields  . . . . . . . . . . . . . . . . . . .  10
       5.4.  Canonical Serialisation . . . . . . . . . . . . . . . . .  10
       5.5.  Forward Compatibility . . . . . . . . . . . . . . . . . .  11
       5.6.  Multi-String Reassembly . . . . . . . . . . . . . . . . .  11
     6.  DNSSEC Requirement  . . . . . . . . . . . . . . . . . . . . .  11
     7.  DANE TLSA Pin . . . . . . . . . . . . . . . . . . . . . . . .  12
     8.  IdentityLog Cross-Reference . . . . . . . . . . . . . . . . .  12



  Morrison                Expires 19 November 2026                [Page 2]


  Internet-Draft              MCP DNS Discovery                   May 2026


     9.  alter: URI Scheme Cross-Reference . . . . . . . . . . . . . .  13
     10. Discovery and Bootstrap Procedures  . . . . . . . . . . . . .  13
       10.1.  Discovery Procedure: _mcp.<domain> . . . . . . . . . . .  13
       10.2.  Identity Bootstrap Procedure: _org-alter.<domain>  . . .  14
       10.3.  Envelope Recognition Procedure: _alter.<domain>  . . . .  14
     11. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     12. Security Considerations . . . . . . . . . . . . . . . . . . .  15
       12.1.  DNSSEC Downgrade . . . . . . . . . . . . . . . . . . . .  16
       12.2.  TLSA Pin Rotation  . . . . . . . . . . . . . . . . . . .  16
       12.3.  Envelope Substitution  . . . . . . . . . . . . . . . . .  16
       12.4.  Revocation Opacity . . . . . . . . . . . . . . . . . . .  17
       12.5.  Clock Skew and ts= . . . . . . . . . . . . . . . . . . .  17
       12.6.  Cross-Record Key Consistency . . . . . . . . . . . . . .  17
       12.7.  Passive-Stream Coupling  . . . . . . . . . . . . . . . .  17
     13. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
       13.1.  Public Handle Disclosure . . . . . . . . . . . . . . . .  18
       13.2.  DNS Query Metadata . . . . . . . . . . . . . . . . . . .  18
       13.3.  Revocation Unlinkability . . . . . . . . . . . . . . . .  18
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       14.1.  Underscored DNS Node Name Registration . . . . . . . . .  18
       14.2.  alter: URI Scheme Registration . . . . . . . . . . . . .  19
       14.3.  Envelope Version Registry  . . . . . . . . . . . . . . .  19
       14.4.  Org-Alter Version Registry (unchanged from v02)  . . . .  19
       14.5.  Registry Namespace Registry (unchanged from v02) . . . .  19
       14.6.  Framework Token Registry (unchanged from v02)  . . . . .  19
       14.7.  Signature Algorithm Registry . . . . . . . . . . . . . .  20
     15. Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  20
       15.1.  Minimal Envelope for a Single Handle . . . . . . . . . .  20
       15.2.  Zone Hosting Multiple Handles  . . . . . . . . . . . . .  20
       15.3.  Full Zone (All Three Records)  . . . . . . . . . . . . .  20
       15.4.  Instrument-Tier Handle . . . . . . . . . . . . . . . . .  21
     16. Interoperability with v01 and v02 . . . . . . . . . . . . . .  21
     17. Implementation Status . . . . . . . . . . . . . . . . . . . .  22
     18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
       18.1.  Normative References . . . . . . . . . . . . . . . . . .  23
       18.2.  Informative References . . . . . . . . . . . . . . . . .  24
     Appendix A.  Recognition Pseudocode . . . . . . . . . . . . . . .  25
     Appendix B.  Document History . . . . . . . . . . . . . . . . . .  26
     Appendix C.  Normative References . . . . . . . . . . . . . . . .  29
     Appendix D.  Informative References . . . . . . . . . . . . . . .  29
     Appendix E.  Authors' Addresses . . . . . . . . . . . . . . . . .  29

  1.  Introduction

     Model Context Protocol (MCP) [MCP] is an open protocol for structured
     interaction between AI agents and tool-providing servers.  A complete
     agent-to-organisation-to-individual interaction chain has three
     distinct discovery requirements:



  Morrison                Expires 19 November 2026                [Page 3]


  Internet-Draft              MCP DNS Discovery                   May 2026


     1.  *Service discovery.* Where is the MCP server endpoint?  What
         transport does it speak?  What cryptographic key authenticates
         it?  This is the question v01 of this document answers via the
         _mcp.<domain> record.

     2.  *Organisational identity bootstrap.* Who is the organisation
         operating the server?  What is its legal entity?  Where is it
         registered?  Under what regulatory frameworks does it operate,
         and which automated access pathways must it refuse to participate
         in?  This is the question v02 answers via the _org-alter.<domain>
         record.

     3.  *Individual identity recognition.* Who is the Sovereign-tier
         person bound to a ~handle hosted under the domain?  What public
         key signs their statements?  What append-only log anchors the
         lifecycle of their identity?  How may their envelope be revoked?
         This is the question v03 introduces via the _alter.<domain>
         record.

     The three questions are distinct.  An MCP client may need to discover
     an endpoint without caring about the operator's identity or any
     individual handle.  An onboarding wizard installing an org-alter
     instance may need to read the operator's identity without caring
     (yet) about the MCP endpoint.  A recognition verifier (resolving an
     alter:~alice URI) needs the individual envelope without necessarily
     invoking an MCP session.  Conflating any two of these into a single
     TXT record would force every consumer to parse fields it does not
     need and would crowd the 255-octet character-string limit.  Splitting
     them across three underscore-prefixed labels mirrors the pattern
     established by DKIM (_domainkey._domain) and DMARC (_dmarc._domain):
     each record serves a single semantic purpose.

     This revision is fully backward-compatible with v01 and v02.
     Implementations that consume only the _mcp.<domain> record continue
     to work unchanged.  Implementations that wish to bootstrap an org-
     alter identity may additionally query _org-alter.<domain>.
     Implementations that wish to recognise an individual ~handle may
     additionally query _alter.<domain>.

     The envelope layer formalised in the new _alter.<domain> record is
     specified in full by a companion document, the ALTER DNS Publication
     specification [ALTER-DNS-PUB], which pins the envelope JSON schema,
     the JSON Canonicalisation Scheme (JCS, [RFC8785]) serialisation, and
     the resolver-side verification algorithm.  This document is the IETF-
     track surface for the underscore-prefixed DNS label registration and
     its DNSSEC / DANE / IdentityLog cross-references; it does not
     duplicate the envelope wire format beyond what is necessary to
     specify a conformant TXT grammar.



  Morrison                Expires 19 November 2026                [Page 4]


  Internet-Draft              MCP DNS Discovery                   May 2026


     The individual-identity layer is grounded, as the organisational
     layer is, in the identity field framework of [MORRISON-IFT].  A
     ~handle is not a reserved alphanumeric slot but a durable recognition
     attractor in the identity field.  A DNS record provides a discrete
     checkpoint into that field: the envelope published at _alter.<zone>
     is the handle-holder's own canonical declaration, signed by their
     Ed25519 key, witnessed by the IdentityLog STH anchor surface
     [ALTER-STH], and consumable by any resolver with access to a DNSSEC-
     validating recursive resolver.

  1.1.  Requirements Language

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

  2.  Terminology

     (Terminology from v01 and v02 is retained.  Additional terms
     introduced in this revision are defined below.)

     Envelope  An Ed25519-signed JSON object binding a ~handle to a public
        key, an IdentityLog root reference, an inception timestamp, a
        revocation hash commitment, a signature algorithm tag, a detached
        signature, and a caveats array.  The envelope is the unification
        primitive of the ALTER identity architecture.  Its full JSON
        schema, canonical serialisation rule, and verification procedure
        are pinned by [ALTER-DNS-PUB].  This document specifies only the
        TXT grammar that carries the five load-bearing envelope fields
        across DNS.

     ~handle  A Sovereign-tier identifier, leading tilde mandatory (e.g.
        ~alice).  Bot-tier handles carry a .bot suffix (e.g. ~example-
        bot.bot); Instrument-tier handles use the prefix ~cc- (e.g. ~cc-
        example-model).

     IdentityLog  The append-only transparency log anchoring envelope
        lifecycle events (mint, caveat-add, revocation, key-rotation).  A
        Signed Tree Head ("STH") is emitted per-minute and cross-anchored
        to Cloudflare R2, IPFS, a federation of independent mirrors, and
        the Base L2 chain via the IdentityLogAnchor contract.  Protocol
        details are in [ALTER-STH].

     Organ  A broadcast surface for the envelope.  The three organs are:





  Morrison                Expires 19 November 2026                [Page 5]


  Internet-Draft              MCP DNS Discovery                   May 2026


        DNS publication (this document), the local alter-runtime L3
        daemon, and a hardware-anchored device-organ quorum.  The term is
        canonical; do not substitute "channel", "vector", or "emitter" at
        the architectural level.

     Recognition  The act of a resolver observing and verifying an
        envelope on cryptographic merit.  Recognition is distinct from
        claim: publishing a TXT record is not a claim of identity, it is
        an observable assertion that the resolver may verify or reject.
        No field of this document carries a claim verb; resolvers
        recognise envelopes, they do not honour publisher assertions about
        them.

     DNSSEC Validation  The act of an authenticating DNS resolver
        verifying the RRSIG chain from the root trust anchor to the TXT
        RRset, per [RFC4033], [RFC4034], and [RFC4035], and setting the AD
        bit on the response delivered to the stub client.

     DANE TLSA Pin  A DNS TLSA resource record [RFC6698] binding a
        server's leaf TLS certificate (or the public key therein) to the
        zone that hosts the envelope.  In this document, the pin applies
        to the MCP endpoint at mcp.<zone>.

     alter: URI  A dispatch URI scheme provisionally registered with IANA
        per [RFC7595].  Full registration body and handler guidance are
        specified in [ALTER-DNS-PUB] Section 7; a normative cross-
        reference is given in Section 9 of this document.

     (Terms from v02, Org-Identity Record, Identity Bootstrap, Canonical
     Entity Identifier, Regulatory Refusal Marker, are retained.)

  3.  Record Format: _mcp.<domain> (Service Discovery)

     Section 3 of v01 of this document defines the _mcp.<domain> record,
     its ABNF grammar, field definitions (v, url, proto, pk, epoch, cap,
     attest, scope, priority, ttl, ext), forward-compatibility rules, and
     multi-string concatenation behaviour.  These definitions are
     unchanged in this revision and are incorporated here by reference.
     Implementations MUST treat any existing _mcp.<domain> record as
     conformant to the v01 specification.











  Morrison                Expires 19 November 2026                [Page 6]


  Internet-Draft              MCP DNS Discovery                   May 2026


  4.  Record Format: _org-alter.<domain> (Identity Bootstrap)

     Section 4 of v02 of this document defines the _org-alter.<domain>
     record, its ABNF grammar, field definitions (v, org, entity, entity-
     type, founded, regions, regulated, bootstrap, mcp-policy, epoch, pk,
     attest, ext), identity bootstrap procedure, and registry cross-
     checks.  These definitions are unchanged in this revision and are
     incorporated here by reference.  Implementations MUST treat any
     existing _org-alter.<domain> record as conformant to the v02
     specification.

  5.  Record Format: _alter.<domain> (Envelope Publication)

     This section defines the new Envelope Publication record introduced
     in v03.  The record publishes the five load-bearing fields of the
     ALTER identity envelope (binding a ~handle to its Ed25519 public key,
     IdentityLog root, inception timestamp, revocation commitment, and
     detached signature) at an underscore-prefixed label under the
     handle's hosting zone.  The full envelope JSON schema and wire
     format, including fields not carried over DNS (the implicit
     signature_alg constant and the optional caveats array), is pinned by
     [ALTER-DNS-PUB].

  5.1.  DNS Location

     The Envelope Record is a DNS TXT resource record [RFC1035] published
     at the label _alter prepended to the hosting zone:

     _alter.<zone>.  IN TXT "<record-value>"

     The underscore prefix conforms to the conventions established in
     [RFC8552] for globally scoped, underscore-prefixed DNS node names.

     A zone MAY host more than one ~handle (one envelope per handle); in
     that case the zone MUST publish multiple TXT RRs at the same owner
     name.  Resolvers MUST disambiguate returned records by the h= field
     and select the record matching the requested handle.

     A domain MAY publish any combination of _mcp.<domain>, _org-
     alter.<domain>, and _alter.<domain> records independently (service-
     only, identity-only, envelope-only, or any intersection).  The
     recommended pattern for an operator running an org-alter instance
     that hosts the operator's own principal handle (e.g. ~alice at
     example.com) is to publish all three.







  Morrison                Expires 19 November 2026                [Page 7]


  Internet-Draft              MCP DNS Discovery                   May 2026


  5.2.  ABNF Grammar

     The record value is a semicolon-delimited sequence of key-value
     pairs.  The following ABNF (per [RFC5234]) defines the syntax:

     ``` alter-record = version ";" SP handle-field ";" SP pubkey-field
     ";" SP ilr-field ";" SP ts-field ";" SP rev-field ";" SP sig-field *(
     ";" SP unknown-field )

     version = "v=alter1" handle-field = "h=" handle pubkey-field = "pk="
     algo ":" base64url ilr-field = "ilr=" base64url ; SHA-256 of
     IdentityLog root ts-field = "ts=" 1*DIGIT ; inception_ts, Unix
     seconds rev-field = "rev=" base64url ; SHA-256 of revocation pre-
     image sig-field = "sig=" base64url ; Ed25519 detached signature
     unknown-field = token "=" *VCHAR

     handle = "~" 1_( ALPHA / DIGIT / "-" / "_" ) [ "." "bot" ] / "~cc-"
     1_( ALPHA / DIGIT / "-" / "." ) algo = "ed25519" base64url = 1_(
     ALPHA / DIGIT / "-" / "_" ) token = 1_( ALPHA / DIGIT / "-" / "_" )
     ```

     The seven keys above are REQUIRED and MUST appear in the order shown.
     Publishers MUST NOT omit or reorder them.  Resolvers MUST tolerate
     additional (unknown) fields appended after the seven required fields
     and MUST ignore them per the forward-compatibility rule (Section 6.4
     below).  Resolvers MUST tolerate arbitrary inter-field ordering on
     parse (publishers-emit-ordered, parsers- accept-unordered);
     canonicalisation for signature verification is specified in
     Section 6.3.

  5.3.  Field Definitions

  5.3.1.  v (REQUIRED)

     Protocol version identifier.  MUST be the literal string alter1.
     MUST appear as the first field in the record.  Resolvers MUST reject
     any record whose v field is absent, is not the first field, or
     contains a value other than alter1.

     The version namespace v=alter1 on _alter.<zone> is independent of the
     identically-named v=alter1 on _org-alter.<zone>.  The two namespaces
     are disambiguated by the enclosing record label and MUST NOT be
     conflated.  Future versions of either record may advance
     independently (e.g. _alter.<zone> may progress to v=alter2 while
     _org-alter.<zone> remains at v=alter1, or the reverse).






  Morrison                Expires 19 November 2026                [Page 8]


  Internet-Draft              MCP DNS Discovery                   May 2026


  5.3.2.  h (REQUIRED)

     The Sovereign-, Bot-, or Instrument-tier ~handle to which the
     envelope binds.  The leading tilde is mandatory.  The h= value is the
     sole field resolvers MAY use to disambiguate multiple envelope TXT
     RRs sharing an owner name.

  5.3.3.  pk (REQUIRED)

     An Ed25519 public key prefixed by its algorithm namespace and encoded
     in base64url without padding per [RFC4648] Section 5:

     pk=ed25519:<base64url-no-pad-32-bytes>

     Resolvers MUST reject records whose algorithm prefix is not ed25519
     until a future revision registers additional algorithms.  The pk
     value is the verification key for the detached signature in the sig
     field.

  5.3.4.  ilr (REQUIRED)

     Base64url-no-pad SHA-256 digest of the IdentityLog root witnessed at
     envelope creation.  Resolvers MUST cross-reference this value against
     the IdentityLog witness surface [ALTER-STH] to confirm the envelope
     was minted within a recognised tree state.  Failure to cross-
     reference renders the envelope unverified.

  5.3.5.  ts (REQUIRED)

     Envelope inception timestamp, expressed as decimal Unix seconds
     (integer).  Resolvers MAY use this field to detect clock skew,
     evaluate caveat maturity, or reject envelopes with implausibly future
     inception.

  5.3.6.  rev (REQUIRED)

     Base64url-no-pad SHA-256 digest of the revocation pre-image.
     Revocation is effected by revealing the pre-image to the IdentityLog;
     upon reveal, the envelope is considered revoked and MUST NOT be
     honoured by resolvers.  The rev field is a forward-secure commitment:
     the pre-image is never published in DNS and is released only at
     revocation time to the log.

     Publishers MUST NOT treat removal of the TXT record as revocation.
     Absence of a record is indistinguishable from misconfiguration; only
     pre-image reveal is load-bearing.





  Morrison                Expires 19 November 2026                [Page 9]


  Internet-Draft              MCP DNS Discovery                   May 2026


  5.3.7.  sig (REQUIRED)

     Base64url-no-pad Ed25519 detached signature over the JCS-
     canonicalised envelope JSON with the signature field absent.
     Canonicalisation is specified by [RFC8785].  The signing input is the
     envelope JSON reconstructed from the parsed TXT fields plus the
     implicit constant signature_alg: "Ed25519" and an empty caveats
     array; caveats, when present, ride the HTTPS .well-known organ and do
     not appear in the DNS record.  The canonical envelope schema,
     including JCS input construction, is pinned in [ALTER-DNS-PUB]
     Section 4.

  5.3.8.  Unknown fields

     Fields not enumerated above MUST be ignored by v03 resolvers per the
     forward-compatibility rule (Section 6.4).  Future revisions of this
     document MAY register additional envelope fields; such extensions
     MUST be distinguishable from private-use extensions by registration
     via the mechanism in Section 10.

  5.4.  Canonical Serialisation

     The sig input is constructed as follows:

     1.  Parse the TXT RR character-strings into key-value pairs.

     2.  Construct the envelope JSON object:

         json { "handle": "<h>", "pubkey": "<pk>", "identitylog_root":
         "<ilr>", "inception_ts": <ts>, "revocation_hash": "<rev>",
         "signature_alg": "Ed25519", "caveats": [] }

         Values are typed per Section 6.2 (inception_ts as JSON integer;
         all other values as JSON strings; caveats as JSON array, empty
         unless a companion .well-known fetch supplies content).  The
         signature field MUST be absent from the signing input.

     3.  Apply [RFC8785] JSON Canonicalisation Scheme to the object.

     4.  The resulting byte stream is the Ed25519 signing input.

     Verification reverses this construction and checks the detached
     signature in the sig field against the derived byte stream.

     Publishers MUST emit TXT fields in the order given in Section 6.2,
     but the DNS key=value ordering has no role in signature computation:
     the signed bytes are always the JCS serialisation of the JSON object.




  Morrison                Expires 19 November 2026               [Page 10]


  Internet-Draft              MCP DNS Discovery                   May 2026


  5.5.  Forward Compatibility

     Resolvers MUST ignore unknown fields in the _alter.<domain> record.
     This rule, identical to the v01 _mcp and v02 _org-alter
     specifications, ensures that future extensions do not break existing
     implementations.

     Publishers MUST NOT introduce new fields that repurpose or overload
     the seven required field names; new fields MUST use new names
     registered via the procedure in Section 10.

  5.6.  Multi-String Reassembly

     Where the serialised envelope exceeds the 255-octet character-string
     limit of [RFC1035] Section 3.3.14, publishers MUST split at ;
     boundaries between complete key-value pairs.  Splitting within a key-
     value pair is prohibited.  Resolvers MUST concatenate the character-
     strings of a TXT RR in the order returned by the DNS library (i.e.
     the RR wire order) before parsing.

  6.  DNSSEC Requirement

     The zone publishing an _alter.<domain> envelope record MUST be
     DNSSEC-signed per [RFC4033], [RFC4034], and [RFC4035].  Authoritative
     servers MUST respond with valid RRSIG coverage for the TXT RRset.
     Recursive resolvers handling queries for the envelope RRset MUST
     perform DNSSEC validation and MUST set the AD (Authenticated Data)
     bit on the response delivered to the stub client.

     Stub clients (MCP clients, alter-runtime daemons, onboarding wizards,
     recognition verifiers) consuming _alter.<domain> envelope records
     MUST reject any response that lacks a set AD bit or that fails local
     RRSIG verification when operating in validating-stub mode.  An
     envelope obtained over an unvalidated DNS path is not an envelope; it
     is unauthenticated TXT content.  Treating it otherwise is a downgrade
     vulnerability (Section 11).

     This requirement is specific to _alter.<domain> records.  DNSSEC is
     RECOMMENDED but not REQUIRED for _mcp.<domain> and _org-
     alter.<domain> records in this revision, for backward compatibility
     with v01 and v02 deployments.  Future revisions of this document MAY
     promote DNSSEC to REQUIRED for the other two records once deployment
     data justifies the promotion.








  Morrison                Expires 19 November 2026               [Page 11]


  Internet-Draft              MCP DNS Discovery                   May 2026


  7.  DANE TLSA Pin

     The MCP endpoint associated with a published envelope MUST carry a
     DANE TLSA resource record [RFC6698] binding the endpoint's leaf TLS
     certificate or SubjectPublicKeyInfo to the zone.  The TLSA record
     MUST be published at:

     _443._tcp.mcp.<zone>.  IN TLSA <usage> <selector> <matching-type>
     <cert-association-data>

     Recommended parameters:

     *  *Usage field.* 3 (DANE-EE), pin the end-entity certificate
        directly, with no CA chain reliance.  A publisher that explicitly
        requires CA-chain validation MAY use 1 (PKIX-EE) instead.
        Publishers MUST NOT use 0 (PKIX-TA) or 2 (DANE-TA) for the
        envelope organ; the trust basis of the envelope is the end-entity
        leaf.

     *  *Selector field.* 1 (SPKI), pin the SubjectPublicKeyInfo so that
        certificate rotations preserving the keypair do not invalidate the
        record.  Selector 0 (full certificate) MAY be used but requires
        more frequent TLSA republication.

     *  *Matching-type field.* 1 (SHA-256).  Matching type 2 (SHA-512) is
        reserved for future revisions.

     Clients establishing an MCP session at https://mcp.<zone>/ in
     conjunction with a resolved envelope MUST fetch and validate the TLSA
     record, MUST abort the TLS handshake on mismatch, and MUST NOT fall
     back to PKIX-only validation on TLSA failure.

     The TLSA requirement is scoped to envelopes whose MCP session
     establishment is triggered by the resolved envelope (i.e. when the
     envelope resolution and the subsequent MCP session are part of a
     single recognition transaction).  MCP clients that do not resolve an
     envelope (e.g. v01-only clients consuming only _mcp.<domain>) are out
     of scope for this requirement and continue to operate under v01
     rules.

  8.  IdentityLog Cross-Reference

     The ilr= field of the _alter.<domain> record carries a base64url-no-
     pad SHA-256 digest of an IdentityLog Signed Tree Head (STH) root
     witnessed at envelope creation.  The IdentityLog protocol (leaf
     hashing, Merkle-tree construction, STH cadence, witness federation,
     Cloudflare R2 / IPFS / Base L2 anchor path) is specified in full by
     [ALTER-STH]; this document does not duplicate that specification.



  Morrison                Expires 19 November 2026               [Page 12]


  Internet-Draft              MCP DNS Discovery                   May 2026


     Resolvers verifying an envelope from DNS MUST cross-reference the
     ilr= value against at least one IdentityLog witness surface
     (federation mirror, R2 canonical read, IPFS content address, or Base
     L2 IdentityLogAnchor contract).  The specific surface is a matter of
     deployment preference; [ALTER-STH] Section 6 gives conforming client
     profiles.  Failure to cross-reference renders the envelope unverified
     and it MUST NOT be admitted to any recognition-gated decision.

     The revocation check also crosses the IdentityLog: a resolver MUST
     consult the IdentityLog revocation-witness surface for any reveal
     whose SHA-256 equals the rev= field of the envelope.  If a matching
     pre-image has been revealed, the envelope is revoked and MUST NOT be
     honoured regardless of the freshness of the TXT RRset.

  9.  alter: URI Scheme Cross-Reference

     An IANA-registered URI scheme alter: provides a dispatchable surface
     for ~handle references: operating-system URI handlers (xdg-mime,
     LSHandlers, Windows registry, Android intent-filter) invoke a
     resolver that retrieves and verifies the envelope through the organ
     chain defined in [ALTER-DNS-PUB] (DNS first, with fallback to the
     HTTPS .well-known surface and, where available, the local alter-
     runtime L3 daemon).

     Registration is provisional per [RFC7595] Section 3.  The full
     registration body, scheme syntax, semantics, encoding considerations,
     interoperability and security considerations, author and change
     controller, is published in [ALTER-DNS-PUB] Section 7 and submitted
     to IANA separately from this document.  The IANA request is in
     progress as of the publication date of this revision; the final
     registration reference will be substituted when available.

     Handlers invoked via alter: URIs MUST perform full envelope
     verification, DNSSEC validation (Section 7), DANE TLSA binding
     (Section 8) when establishing any HTTPS session, IdentityLog cross-
     reference (Section 9), and the eleven-step verification algorithm of
     [ALTER-DNS-PUB] Section 8, before acting on any content or directive
     derived from the envelope.

  10.  Discovery and Bootstrap Procedures

  10.1.  Discovery Procedure: _mcp.<domain>

     The discovery procedure defined in Section 4 of v01 is unchanged in
     this revision.  Clients querying _mcp.<domain> follow the v01
     algorithm exactly.





  Morrison                Expires 19 November 2026               [Page 13]


  Internet-Draft              MCP DNS Discovery                   May 2026


  10.2.  Identity Bootstrap Procedure: _org-alter.<domain>

     The identity bootstrap procedure defined in Section 6 of v02 is
     unchanged in this revision.  Onboarding wizards reading _org-
     alter.<domain> follow the v02 algorithm exactly.

  10.3.  Envelope Recognition Procedure: _alter.<domain>

     Given an alter:~<handle> reference, a zone hint, or a raw
     _alter.<zone>. query, a resolver MUST execute the following steps in
     order.  Any failure terminates recognition and the envelope MUST be
     treated as unverified.

     1.   *Query.* Issue a DNS TXT query for _alter.<zone>..  Use DoH or
          DoT in preference to UDP/53 where operationally feasible.

     2.   *DNSSEC validation.* Validate the RRSIG chain from the root
          trust anchor to the TXT RRset (Section 7).  Confirm the AD bit
          on the response when relying on an upstream validating resolver,
          or locally RRSIG-validate in validating-stub mode.  On failure,
          abort.

     3.   *Chunk reassembly.* Concatenate character-strings in RR order;
          parse ;-separated key-value pairs.

     4.   *Handle disambiguation.* Select the record whose h= field
          matches the requested ~handle.  If no record matches, abort.

     5.   *Field extraction.* Confirm presence of the seven required
          fields (v, h, pk, ilr, ts, rev, sig).  Reject any record missing
          any required field, or whose v is not alter1.

     6.   *Envelope reconstruction.* Build the envelope JSON per
          Section 6.3, inserting the implicit signature_alg: "Ed25519"
          constant and an empty caveats array.

     7.   *JCS canonicalisation.* Apply [RFC8785] JCS to the envelope with
          the signature field absent.

     8.   *Ed25519 verification.* Verify the detached sig over the JCS
          byte stream using the public key in pk.  On failure, abort.

     9.   *IdentityLog cross-reference.* Confirm ilr= corresponds to a STH
          recognised in the IdentityLog witness set at or after ts
          (Section 9; [ALTER-STH]).  On failure, abort.






  Morrison                Expires 19 November 2026               [Page 14]


  Internet-Draft              MCP DNS Discovery                   May 2026


     10.  *DANE TLSA validation.* When establishing an MCP session at
          mcp.<zone> as part of the same recognition transaction, fetch
          the TLSA record at _443._tcp.mcp.<zone>. and gate the TLS
          handshake on the binding (Section 8).  On mismatch, abort.

     11.  *Caveats evaluation.* Fetch the HTTPS .well-known companion
          surface and evaluate any caveats on the envelope per
          [ALTER-DNS-PUB].  Caveats that cannot be satisfied bound the
          subsequent use of the envelope but are not grounds to abort
          recognition.

     12.  *Revocation check.* Consult the IdentityLog revocation- witness
          surface.  If a pre-image whose SHA-256 equals rev= has been
          revealed, the envelope is revoked; abort.

     Only after all twelve steps succeed is the envelope considered
     verified.  A verified envelope is the sole admissible input to a
     recognition-over-qualification gate; unverified envelopes MUST be
     refused upstream of any authorisation or trust decision.

     The twelve-step procedure above is the IETF-surface summary of the
     eleven-step verification algorithm in [ALTER-DNS-PUB] Section 8; they
     differ only in that this document splits caveats and revocation into
     distinct steps for clarity.

  11.  Caching

     Caching of _mcp.<domain> records follows v01.  Caching of _org-
     alter.<domain> records follows v02.

     _alter.<domain> records SHOULD be cached for the duration of the DNS
     TTL.  Resolvers MUST NOT serve stale envelope TXT past the RRset TTL
     unless they are themselves validating caches and can re-confirm RRSIG
     coverage on each serve.  Recognition verifiers MAY cache successful
     verification results locally for a short interval (bounded above by
     the RRset TTL or 3600 seconds, whichever is smaller) to amortise the
     cost of repeated JCS and Ed25519 operations, but MUST re-run the
     revocation check (Section 11.12) on each recognition event, not on
     each cache refresh.

  12.  Security Considerations

     (Security considerations from v01 and v02 are retained.  Additional
     considerations introduced by the envelope layer are below.)







  Morrison                Expires 19 November 2026               [Page 15]


  Internet-Draft              MCP DNS Discovery                   May 2026


  12.1.  DNSSEC Downgrade

     The mandatory DNSSEC requirement in Section 7 is the primary defence
     against on-path manipulation of envelope TXT content.  An attacker
     who can inject unsigned responses, e.g. via a compromised resolver or
     a DNS middlebox that strips RRSIG, would otherwise be able to
     substitute an attacker-controlled envelope at the resolver boundary.
     Stub clients MUST reject any response lacking AD or failing local
     RRSIG verification.  Operators MUST NOT downgrade the _alter.  RRset
     to unsigned during KSK/ZSK rollover (see [RFC6781] for best-current
     practice on rollover).

  12.2.  TLSA Pin Rotation

     The DANE TLSA requirement in Section 8 binds the MCP endpoint's TLS
     leaf to a specific hash.  Operators rotating certificates MUST
     publish the new TLSA record before the new certificate is activated
     on the live listener, with a grace window of at least twice the TLSA
     RRset TTL.  Selector 1 (SPKI) survives rotations that preserve the
     keypair; selector 0 requires republication on every rotation.  Loss
     of the TLS private key forces revocation via the revocation_hash
     reveal path (Section 9) rather than silent cert replacement.

  12.3.  Envelope Substitution

     An attacker in control of a domain's DNS can publish an arbitrary
     envelope for any ~handle claimed to be hosted under that zone.  The
     three structural defences are:

     1.  *IdentityLog witness.* The ilr= cross-reference constrains the
         envelope to STHs witnessed by the IdentityLog federation;
         substitution of a locally-minted envelope that has not been
         witnessed will fail Section 11.9.  An attacker who wishes to
         substitute must also corrupt at least one IdentityLog mirror,
         which is a detectable equivocation per [RFC9162] design.

     2.  *Ed25519 signature.* The detached signature binds the envelope to
         a specific Ed25519 key.  An attacker who does not hold the
         private key cannot forge a valid sig.  An attacker who does hold
         the private key has already compromised the handle; the
         revocation path (Section 9) is the residual mitigation.

     3.  *DNSSEC.* Section 7 prevents tampering with the TXT RRset in
         transit.  This does not prevent a malicious zone operator from
         publishing a malicious envelope, that attack is caught at (1) and
         (2), but it prevents third-party substitution.





  Morrison                Expires 19 November 2026               [Page 16]


  Internet-Draft              MCP DNS Discovery                   May 2026


  12.4.  Revocation Opacity

     Revocation is effected by revealing the pre-image to the IdentityLog,
     not by removing the TXT record.  Absence of a record is
     indistinguishable from misconfiguration; resolvers MUST NOT treat
     absence as revocation.  This design is deliberate: a zone briefly
     unreachable (DNS outage, registrar incident, tooling error) must not
     accidentally become a revocation event.

     The cost is that a compromised zone may continue to serve a valid
     (but intended-to-be-revoked) envelope until the rightful handle-
     holder reveals the pre-image.  Pre-image reveal is a low-friction
     operation, a single authenticated POST to any IdentityLog mirror, but
     it requires the rightful holder to act.  Handle-holders SHOULD
     establish a pre-committed revocation reveal procedure at mint time.

  12.5.  Clock Skew and ts=

     The ts= inception timestamp is advisory: resolvers MAY use it to
     detect implausibly future envelopes (e.g. minted more than a few
     hundred seconds after current wall time) but MUST NOT rely on local
     clock for security-critical decisions.  The authoritative ordering
     anchor is the IdentityLog STH tree position, not the inception
     timestamp.

  12.6.  Cross-Record Key Consistency

     When all three records (_mcp, _org-alter, _alter) are published under
     the same zone and each carries a pk field, the values MUST be
     evaluated for consistency.  The _mcp.pk and _org-alter.pk fields are
     v01/v02 service and organisational keys respectively; the _alter.pk
     field is the Sovereign-tier envelope key.  These are structurally
     distinct purposes, and the keys MAY differ.  However, where a zone
     operator deliberately binds all three to the same Ed25519 key (a
     common pattern for a single-operator deployment), a mismatch across
     records indicates either rotation-in-progress or compromise;
     resolvers SHOULD surface the discrepancy.

  12.7.  Passive-Stream Coupling

     The _alter.<domain> record carries only the five load-bearing
     envelope fields and the protocol version.  No inferred trait, no
     passive-stream derivative, and no provenance-tagged attribute rides
     this record.  This is a structural property, not a recommendation:
     the ABNF of Section 6.2 enumerates every field the resolver accepts,
     and the forward-compatibility rule only permits future named
     extensions, not arbitrary attribute carriage.  The privacy
     implications of passive inference are addressed at the envelope



  Morrison                Expires 19 November 2026               [Page 17]


  Internet-Draft              MCP DNS Discovery                   May 2026


     semantic layer [ALTER-DNS-PUB] and its caveats surface, not in DNS.

  13.  Privacy Considerations

     (Privacy considerations from v01 and v02 are retained.  Additional
     considerations introduced by the envelope layer are below.)

  13.1.  Public Handle Disclosure

     Publishing _alter.<domain> exposes the bound ~handle, its Ed25519
     public key, its IdentityLog root, its inception timestamp, and its
     revocation-hash commitment to any DNS observer.  For a Sovereign-tier
     handle this is by design: the envelope is intended to be publicly
     verifiable.  Handle-holders who require concealment MUST NOT publish
     an _alter.<domain> record; alternative organs (the local alter-
     runtime daemon for local-only recognition, or a hardware-anchored
     device-organ quorum for device-local presence proof) support
     recognition without DNS publication.

  13.2.  DNS Query Metadata

     A resolver querying _alter.example.com reveals to its recursive
     resolver that it intends to verify the envelope hosted under that
     zone.  Query metadata privacy is addressed at the transport layer:
     clients SHOULD prefer DoH ([RFC8484]) or DoT ([RFC7858]) over UDP/53
     where operationally feasible.  This consideration is identical to v01
     / v02 and is repeated here for emphasis given the greater individual-
     identity sensitivity of the envelope surface.

  13.3.  Revocation Unlinkability

     The rev= field is the SHA-256 of a secret pre-image; publishing it
     does not disclose the pre-image.  An observer cannot predict the pre-
     image or link it back to any identifier.  Reveal at revocation time
     links the pre-image to the envelope, but only at the moment of
     revocation, not during the envelope's active lifetime.

  14.  IANA Considerations

  14.1.  Underscored DNS Node Name Registration

     This document requests IANA to update the entries in the "Underscored
     and Globally Scoped DNS Node Names" registry established by [RFC8552]
     to reflect v03:

     +--------+--------------+----------------------------------+ | RR
     Type| _NODE NAME | Reference |
     +--------+--------------+----------------------------------+ | TXT |



  Morrison                Expires 19 November 2026               [Page 18]


  Internet-Draft              MCP DNS Discovery                   May 2026


     _mcp | [this document], v01 Sec.3 | | TXT | _org-alter | [this
     document], v02 Sec.4 | | TXT | _alter | [this document], v03 Sec.6 |
     +--------+--------------+----------------------------------+

     The _alter label is used to publish envelope records as defined in
     Section 6 of this document.  Formal registration of _alter in the RFC
     8552 registry is proposed on Standards Action maturation of this
     draft; during the Internet-Draft phase, the label operates under the
     provisional-use convention established by _dmarc, _mta-sts, _mcp
     (this draft), and _org-alter (this draft).

  14.2.  alter: URI Scheme Registration

     This document cross-references the provisional URI scheme
     registration of alter: per [RFC7595] Section 3.  The full
     registration body is published in [ALTER-DNS-PUB] Section 7 and is
     submitted to IANA separately.  This document does not duplicate the
     registration body; it refers to the sibling specification and notes
     that recognition verifiers invoked via alter: URIs MUST follow
     Section 11.12 of this document for envelope verification.

  14.3.  Envelope Version Registry

     This document defines the version tag v=alter1 for the
     _alter.<domain> record, independent of the identically-named tag on
     the _org-alter.<domain> record.  Future versions (v=alter2 and
     beyond) SHOULD be coordinated with the ALTER implementation community
     and documented in successor revisions of this draft.  Until a formal
     IETF working group is chartered for identity- envelope DNS
     publication, the authors maintain the version namespace.

  14.4.  Org-Alter Version Registry (unchanged from v02)

     The version tag v=alter1 for the _org-alter.<domain> record is
     preserved from v02.  No changes are requested in this revision.

  14.5.  Registry Namespace Registry (unchanged from v02)

     The initial set of entity field registry namespaces (abn, acn, ein,
     ch, cro, lei) defined in v02 is preserved unchanged.

  14.6.  Framework Token Registry (unchanged from v02)

     The initial set of regulated framework tokens (disp, itar, ear,
     hipaa, gdpr, soc2, iso27001, iso42001, essential8, aprs) defined in
     v02 is preserved unchanged.





  Morrison                Expires 19 November 2026               [Page 19]


  Internet-Draft              MCP DNS Discovery                   May 2026


  14.7.  Signature Algorithm Registry

     This document defines the initial pk= and sig= algorithm namespace
     ed25519 for the _alter.<domain> record.  Future algorithms (e.g.
     ed448, ml-dsa-65) MAY be registered by successor documents.
     Resolvers MUST reject records whose algorithm prefix is not
     registered at the resolver's protocol version.

  15.  Examples

     This section provides non-normative examples of Envelope Records for
     common deployment scenarios.

  15.1.  Minimal Envelope for a Single Handle

     A zone hosting a single Sovereign-tier handle publishes its envelope
     at _alter.<zone>.:

     _alter.example.com. 3600 IN TXT ( "v=alter1; h=~alice; "
     "pk=ed25519:<EXAMPLE-pubkey-32B-base64url>; " "ilr=<EXAMPLE-sth-root-
     32B-base64url>; " "ts=1729123456; " "rev=<EXAMPLE-revocation-hash-
     32B-base64url>; " "sig=<EXAMPLE-ed25519-signature-64B-base64url>" )

     All base64url values in this example are illustrative.  Production
     values are the Ed25519 public key, SHA-256 digests, and 64-byte
     detached signature encoded per [RFC4648] Section 5 without padding.

  15.2.  Zone Hosting Multiple Handles

     A zone hosting more than one handle publishes multiple envelope TXT
     RRs at the same owner name.  Resolvers disambiguate by the h= field:

     _alter.example.org. 3600 IN TXT "v=alter1; h=~alice; pk=ed25519:..."
     _alter.example.org. 3600 IN TXT "v=alter1; h=~bob; pk=ed25519:..."
     _alter.example.org. 3600 IN TXT "v=alter1; h=~carol.bot;
     pk=ed25519:..."

     A resolver asked to verify ~bob at example.org selects the second RR.

  15.3.  Full Zone (All Three Records)

     A zone operator running an org-alter instance for their own principal
     handle publishes all three records:








  Morrison                Expires 19 November 2026               [Page 20]


  Internet-Draft              MCP DNS Discovery                   May 2026


     _mcp.example.com.  IN TXT "v=mcp1; url=https://mcp.example.com/ ..."
     _org-alter.example.com.  IN TXT "v=alter1; org=Example Org; ..."
     _alter.example.com.  IN TXT "v=alter1; h=~alice; pk=ed25519:...;
     ilr=...; ts=...; rev=...; sig=..." _443._tcp.mcp.example.com.  IN
     TLSA 3 1 1 <sha256-of-spki>

     Together these expose: the MCP service endpoint and its capabilities
     (_mcp); the legal entity, regulatory posture, and jurisdictional
     regions (_org-alter); the Sovereign-tier envelope for ~alice
     (_alter); and the DANE TLSA pin on the MCP endpoint.  A resolver may
     consume any subset according to its recognition requirement.

  15.4.  Instrument-Tier Handle

     An AI instrument handle uses the ~cc- prefix:

     _alter.example.com. 3600 IN TXT ( "v=alter1; h=~cc-example-model; "
     "pk=ed25519:...; ilr=...; ts=...; rev=...; sig=..." )

     Instrument-tier envelopes are bound to a specific model version.
     Rotation of the model version produces a new ~cc- handle with a new
     envelope; the prior envelope remains verifiable over its active
     lifetime and is revoked by the IdentityLog reveal path when the model
     is retired.

  16.  Interoperability with v01 and v02

     A domain that publishes only a v01 _mcp.<domain> record continues to
     work with all v01, v02, and v03 clients.

     A domain that publishes _mcp.<domain> and _org-alter.<domain> (v02)
     continues to work with v02 and v03 clients unchanged.  v03 clients
     gain the ability to additionally query _alter.<domain> and gracefully
     handle its absence.

     A domain that publishes all three records benefits from:

     *  Service discovery via _mcp.<domain> (v01).

     *  Organisational identity bootstrap via _org-alter.<domain> (v02).

     *  Individual identity recognition via _alter.<domain> (v03).

     *  DNSSEC-authenticated envelope delivery (Section 7).

     *  DANE TLSA binding on the MCP endpoint (Section 8).

     *  IdentityLog-anchored envelope lifecycle (Section 9).



  Morrison                Expires 19 November 2026               [Page 21]


  Internet-Draft              MCP DNS Discovery                   May 2026


     A domain that publishes only _alter.<domain> (envelope-only, no MCP
     server, no organisational record) is permitted.  This is the
     appropriate configuration for a Sovereign-tier individual who wishes
     to be recognisable under their own zone without operating an MCP
     server endpoint or declaring an organisational identity.

     The three records are orthogonal along their semantic axes but share
     the zone's DNSSEC trust root.  A v03-compliant resolver that
     successfully resolves any subset of the three records treats each
     resolution as independent and does not fail the resolution of one
     record because another is absent or malformed.

  17.  Implementation Status

     This section records the status of known implementations at the time
     of publication, per [RFC7942].

     ALTER (https://truealter.com) maintains a reference implementation of
     all three records:

     *  _mcp.truealter.com exercising the v01 field set including pk,
        epoch, attest, and ext.

     *  _org-alter.truealter.com exercising the v02 field set including
        entity, regulated, mcp-policy, and bootstrap.

     *  _alter.truealter.com exercising the v03 envelope field set (h, pk,
        ilr, ts, rev, sig) for the operator's Sovereign-tier handle.

     *  _443._tcp.mcp.truealter.com publishing a DANE-EE / SPKI / SHA-256
        TLSA pin on the MCP endpoint leaf.

     *  An IdentityLog STH anchor federation with four independent witness
        surfaces (Cloudflare R2 canonical, IPFS content- addressed, two
        federation mirrors, Base L2 IdentityLogAnchor contract).

     *  A standalone L0 discovery and recognition library (alter_discover)
        that resolves all three records, validates DNSSEC locally, fetches
        and verifies the DANE TLSA pin, cross- references the IdentityLog
        witness surface, and produces a structured recognition report.

     *  An alter: URI handler registered via xdg-mime on Linux/BSD and the
        corresponding platform registration paths on macOS, Windows, iOS,
        and Android.

     *  An onboarding wizard tool (mcp-org-alter onboard) that bootstraps
        a new org-alter instance from the published records with no manual
        data entry beyond the domain name.



  Morrison                Expires 19 November 2026               [Page 22]


  Internet-Draft              MCP DNS Discovery                   May 2026


     The reference implementation targets MCP specification version
     2025-11, uses streamable-http as the default transport, and treats
     DNSSEC + DANE + IdentityLog as a mandatory verification chain for any
     _alter.<domain>-derived recognition.

  18.  References

  18.1.  Normative References

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

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

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/info/rfc4033>.

     [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security Extensions",
                RFC 4034, DOI 10.17487/RFC4034, March 2005,
                <https://www.rfc-editor.org/info/rfc4034>.

     [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Protocol Modifications for the DNS Security
                Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
                <https://www.rfc-editor.org/info/rfc4035>.

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

     [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/info/rfc5234>.

     [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
                of Named Entities (DANE) Transport Layer Security (TLS)
                Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
                2012, <https://www.rfc-editor.org/info/rfc6698>.





  Morrison                Expires 19 November 2026               [Page 23]


  Internet-Draft              MCP DNS Discovery                   May 2026


     [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
                Authorizing Use of Domains in Email, Version 1", RFC 7208,
                DOI 10.17487/RFC7208, April 2014,
                <https://www.rfc-editor.org/info/rfc7208>.

     [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
                and Registration Procedures for URI Schemes", BCP 35,
                RFC 7595, DOI 10.17487/RFC7595, June 2015,
                <https://www.rfc-editor.org/info/rfc7595>.

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

     [RFC8461]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
                and J. Jones, "SMTP MTA Strict Transport Security (MTA-
                STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
                <https://www.rfc-editor.org/info/rfc8461>.

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

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

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

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

     [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
                Operational Practices, Version 2", RFC 6781,
                DOI 10.17487/RFC6781, December 2012,
                <https://www.rfc-editor.org/info/rfc6781>.

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



  Morrison                Expires 19 November 2026               [Page 24]


  Internet-Draft              MCP DNS Discovery                   May 2026


     [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
                and P. Hoffman, "Specification for DNS over Transport
                Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
                2016, <https://www.rfc-editor.org/info/rfc7858>.

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

     [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
                (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
                <https://www.rfc-editor.org/info/rfc8484>.

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

     [MORRISON-IFT]
                Morrison, B., "Identity Field Theory: Toward a Physics of
                Being Known", 2026,
                <https://doi.org/10.6084/m9.figshare.31951383>.

     [ALTER-DNS-PUB]
                Morrison, B., "ALTER DNS Publication, v1", 2026,
                <https://truealter.com/docs/protocol/alter-dns-
                publication-v1>.

     [ALTER-STH]
                Morrison, B., "IdentityLog STH Anchor, v1", 2026,
                <https://truealter.com/docs/protocol/identitylog-sth-
                anchor-v1>.

  Appendix A.  Recognition Pseudocode

     The following pseudocode illustrates the combined recognition
     procedure defined in Section 11.3.  It is non-normative; the
     normative procedure is the twelve-step algorithm in the body of the
     document and the eleven-step algorithm in [ALTER-DNS-PUB] Section 8
     to which it cross-references.

     ``` function recognise_envelope(handle, zone): # Step 1-2: Query +
     DNSSEC response = dns_query("_alter." + zone, type=TXT, prefer=DoH)
     if not response.ad_bit and not local_rrsig_validate(response): raise
     UnauthenticatedResponse






  Morrison                Expires 19 November 2026               [Page 25]


  Internet-Draft              MCP DNS Discovery                   May 2026


     # Step 3-5: Chunk reassembly + handle disambiguation + fields
     records = [parse_alter_record(rr) for rr in response.rrset]
     record = find(records, lambda r: r.h == handle)
     if record is None or record.v != "alter1":
         raise RecordNotFound
     for f in ["h", "pk", "ilr", "ts", "rev", "sig"]:
         if not hasattr(record, f):
             raise MalformedRecord

     # Step 6-7: Envelope reconstruction + JCS
     envelope = {
         "handle": record.h,
         "pubkey": record.pk,
         "identitylog_root": record.ilr,
         "inception_ts": int(record.ts),
         "revocation_hash": record.rev,
         "signature_alg": "Ed25519",
         "caveats": [],
     }
     signing_input = jcs_canonicalise(envelope)

     # Step 8: Ed25519 verify
     if not ed25519_verify(record.pk, record.sig, signing_input):
         raise SignatureInvalid

     # Step 9: IdentityLog cross-ref
     if not identitylog_witness_contains(record.ilr, record.ts):
         raise WitnessMissing

     # Step 10: DANE TLSA (if establishing MCP session)
     if establishing_mcp_session(zone):
         tlsa = dns_query("_443._tcp.mcp." + zone, type=TLSA)
         if not tlsa_matches_endpoint(tlsa, "mcp." + zone):
             raise TLSAFailure

     # Step 11: Caveats (advisory only; bounds subsequent use)
     caveats = fetch_well_known_caveats(zone, handle)

     # Step 12: Revocation
     if identitylog_revocation_revealed(record.rev):
         raise EnvelopeRevoked

     return VerifiedEnvelope(record, caveats) ```

  Appendix B.  Document History

     draft-morrison-mcp-dns-discovery-03 (April 2026):




  Morrison                Expires 19 November 2026               [Page 26]


  Internet-Draft              MCP DNS Discovery                   May 2026


     Editorial corrections (retiring -02):

     *  Removes the third-party-domain worked example used in -02 and
        replaces all instances with [RFC2606] reserved example-domain
        forms; no third-party operational domain appears in any
        illustrative DNS record in this revision.

     *  Strips city and locality fields from the author front-matter
        block, retaining only name, organisation, and email per editorial
        policy.

     Substantive additions:

     *  Adds the _alter.<domain> Envelope Record (Section 6).

     *  Defines v, h, pk, ilr, ts, rev, sig fields for the new record,
        mirroring the canonical envelope fragment pinned by
        [ALTER-DNS-PUB].

     *  Introduces a mandatory DNSSEC validation requirement for
        _alter.<domain> responses (Section 7).

     *  Introduces a mandatory DANE TLSA [RFC6698] pin on the MCP endpoint
        (Section 8) for envelope-triggered MCP sessions.

     *  Adds the IdentityLog STH cross-reference requirement (Section 9),
        pointing at [ALTER-STH] for the log protocol specification.

     *  Adds a provisional alter: URI scheme cross-reference per [RFC7595]
        (Section 10).

     *  Adds the envelope recognition procedure (Section 11.3), a twelve-
        step algorithm that cross-refers to the eleven-step algorithm of
        [ALTER-DNS-PUB] Section 8.

     *  Adds IANA registration for _alter underscore-prefixed label
        (Section 13.1) and the independent v=alter1 envelope version
        namespace.

     *  Adds a Signature Algorithm Registry (Section 13.8) with initial
        value ed25519.

     *  Adds Security Considerations for DNSSEC downgrade, TLSA pin
        rotation, envelope substitution, revocation opacity, clock skew,
        cross-record key consistency, and passive-stream coupling.

     *  Adds Privacy Considerations for public handle disclosure, DNS
        query metadata, and revocation unlinkability.



  Morrison                Expires 19 November 2026               [Page 27]


  Internet-Draft              MCP DNS Discovery                   May 2026


     *  Adds Examples for minimal envelope, multi-handle zone, full ALTER
        zone with all three records, and Instrument-tier handle.

     *  Adds Implementation Status entry for the envelope reference
        implementation.

     *  v01 _mcp.<domain> and v02 _org-alter.<domain> record
        specifications are incorporated by reference and remain unchanged.

     draft-morrison-mcp-dns-discovery-02 (April 2026):

     *  Adds the _org-alter.<domain> Org-Identity Record.

     *  Defines org, entity, entity-type, founded, regions, regulated,
        bootstrap, mcp-policy, epoch, pk, attest, ext fields for the
        organisational record.

     *  Adds the Identity Bootstrap procedure.

     *  Adds IANA registration for _org-alter underscore-prefixed label.

     *  Adds version tag v=alter1 (org-alter namespace) and registry
        namespace and framework token registries.

     *  Adds Examples for minimal, full, regulated (DISP), and multi-
        regulator deployments.

     *  Adds Implementation Status entry for the orgalter_discover
        reference library.

     *  v01 _mcp.<domain> record specification is incorporated by
        reference and remains unchanged.

     draft-morrison-mcp-dns-discovery-01 (April 2026):

     *  Adds Identity Field Theory grounding for epoch and scope.

     *  Refines security considerations for identity assurance decay.

     *  Refines privacy considerations for scope as a privacy boundary.

     *  Adds Coexistence section with SEP-1959, AID, A2A.

     *  Adds Implementation Status section.

     draft-morrison-mcp-dns-discovery-00 (April 2026):

     *  Initial submission.



  Morrison                Expires 19 November 2026               [Page 28]


  Internet-Draft              MCP DNS Discovery                   May 2026


     *  Defines _mcp.<domain> TXT record format with ABNF grammar.

     *  Defines discovery procedure with HTTPS fallback.

     *  Defines pk, epoch, attest, scope, cap, priority, ttl, and ext
        fields.

     *  Registers _mcp in the underscored DNS node name registry.

  Appendix C.  Normative References

     (References from v01 and v02 are retained.  References added in this
     revision: [RFC4033], [RFC4034], [RFC4035], [RFC6698], [RFC7595],
     [RFC8785], [ALTER-DNS-PUB], [ALTER-STH].)

  Appendix D.  Informative References

     (References from v01 and v02 are retained.  References added in this
     revision: [RFC6962], [RFC9162], [ALTER-ERC8004], [MORRISON-COMMITS],
     [MORRISON-PRONOUNS].)

  Appendix E.  Authors' Addresses

     Blake Morrison Alter Meridian Pty Ltd

     Email: blake@truealter.com URI: https://truealter.com

























  Morrison                Expires 19 November 2026               [Page 29]


name: draft-morrison-mcp-tool-surface-names-registry
rev: 00
title: An IANA Registry for Model Context Protocol Tool Surface Names
time: 2026-05-15T10:50:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-16T10:50:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:50.499376+00:00
source: ietf
abstract:
  This document requests the establishment of an IANA registry for
     Model Context Protocol [MCP-SPEC] tool surface names.  A tool surface
     name is the wire-level identifier by which a client invokes a typed
     capability on an MCP server.  Existing Morrison- family Internet-
     Drafts ([ORGALTER]) request IANA registration of specific surface
     names against a registry that does not yet exist.  This document
     establishes the registry mechanism so that subsequent specifications
     can register names without restating the registry's structure or
     registration procedure.

     The registry uses Specification Required registration with a
     Designated Expert pool [RFC8126].  Initial contents are the four
     surface names registered by [ORGALTER].  Vendor-prefix conventions
     are recommended but not mandated.

full_text:
  Network Working Group                                        B. Morrison
  Internet-Draft                                    Alter Meridian Pty Ltd
  Intended status: Standards Track                             15 May 2026
  Expires: 16 November 2026


       An IANA Registry for Model Context Protocol Tool Surface Names
             draft-morrison-mcp-tool-surface-names-registry-00

  Abstract

     This document requests the establishment of an IANA registry for
     Model Context Protocol [MCP-SPEC] tool surface names.  A tool surface
     name is the wire-level identifier by which a client invokes a typed
     capability on an MCP server.  Existing Morrison- family Internet-
     Drafts ([ORGALTER]) request IANA registration of specific surface
     names against a registry that does not yet exist.  This document
     establishes the registry mechanism so that subsequent specifications
     can register names without restating the registry's structure or
     registration procedure.

     The registry uses Specification Required registration with a
     Designated Expert pool [RFC8126].  Initial contents are the four
     surface names registered by [ORGALTER].  Vendor-prefix conventions
     are recommended but not mandated.

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

  Copyright Notice

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




  Morrison                Expires 16 November 2026                [Page 1]


  Internet-Draft           MCP Tool Surface Names                 May 2026


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

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Registry Structure  . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Per-Entry Fields  . . . . . . . . . . . . . . . . . . . .   4
       4.2.  ABNF for Surface Names  . . . . . . . . . . . . . . . . .   5
     5.  Registration Procedure  . . . . . . . . . . . . . . . . . . .   5
     6.  Initial Registry Contents . . . . . . . . . . . . . . . . . .   6
     7.  Operational Considerations  . . . . . . . . . . . . . . . . .   7
       7.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   7
       7.2.  Vendor-Prefix Ownership . . . . . . . . . . . . . . . . .   7
       7.3.  Deprecation and Withdrawal  . . . . . . . . . . . . . . .   7
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
       8.1.  Name Collision  . . . . . . . . . . . . . . . . . . . . .   7
       8.2.  Specification Drift . . . . . . . . . . . . . . . . . . .   8
       8.3.  Vendor-Prefix Squatting . . . . . . . . . . . . . . . . .   8
       8.4.  Public-Surface Caller Confusion . . . . . . . . . . . . .   8
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
       11.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
       A.1.  draft-morrison-mcp-tool-surface-names-registry-00 . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Status of This Memo

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

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




  Morrison                Expires 16 November 2026                [Page 2]


  Internet-Draft           MCP Tool Surface Names                 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."

  2.  Introduction

     The Model Context Protocol [MCP-SPEC] specifies a wire format for
     clients (typically agent runtimes) to invoke typed capabilities
     ("tools") on remote servers.  Each tool is addressed by a textual
     surface name; the server's manifest enumerates the surface names it
     offers and the JSON Schema of each surface's arguments and return
     shape.

     In the absence of a coordinated registry, surface names are chosen ad
     hoc by server operators.  Collisions are common: two operators may
     both expose a surface named search, with incompatible argument
     schemas, and a client switching between servers has no machine-
     readable signal that the two surfaces are not the same capability.

     Existing Morrison-family Internet-Drafts request IANA registration of
     specific surface names ([ORGALTER] requests registration of
     org_alter_handbook, org_alter_sop_registry,
     org_alter_enforcement_gates, and org_alter_ingest).  Each such
     request currently restates the registry's structure and registration
     procedure, on the implicit assumption that a registry will be
     established by a future memo.

     This document is that memo.  It establishes the registry, defines the
     per-entry fields and the registration procedure, and registers the
     four names from [ORGALTER] as the initial contents.

  2.1.  Requirements Language

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

  3.  Terminology

     Surface Name  A textual identifier by which an MCP client invokes a
        typed capability on an MCP server.  Surface names are case-
        sensitive ASCII strings matching the ABNF in Section 4.

     Surface Specification  The document that defines the argument schema,




  Morrison                Expires 16 November 2026                [Page 3]


  Internet-Draft           MCP Tool Surface Names                 May 2026


        the return shape, the authentication scope, and the behavioural
        semantics of a surface name.

     Operator  The entity responsible for a substrate that exposes one or
        more MCP servers.  An operator is identified by a ~handle per
        [MCPDNS] when the substrate is recognised under the DNS identity
        protocol.

     Vendor Prefix  A common leading substring shared by surface names
        operated by a single substrate.  org_alter_ is the vendor prefix
        for the reference substrate operated by Alter Meridian Pty Ltd.

  4.  Registry Structure

  4.1.  Per-Entry Fields

     Each registry entry SHALL carry the following fields:

       +================+=============================================+
       | Field          | Description                                 |
       +================+=============================================+
       | Surface name   | The textual identifier, in lowercase ASCII, |
       |                | matching the ABNF below.                    |
       +----------------+---------------------------------------------+
       | Specification  | A pointer to the document that specifies    |
       | reference      | the surface's argument schema, return       |
       |                | shape, authentication scope, and semantics. |
       +----------------+---------------------------------------------+
       | Authentication | The class of credential the server requires |
       | scope          | before serving the surface (e.g. member-    |
       |                | recognition, trust-tier:engineering,        |
       |                | ~handle-signed-token, public).              |
       +----------------+---------------------------------------------+
       | Vendor prefix  | The vendor prefix the name falls under, or  |
       |                | none for cross-vendor common names.         |
       +----------------+---------------------------------------------+
       | Change         | The entity authorised to amend or withdraw  |
       | controller     | the registration.                           |
       +----------------+---------------------------------------------+
       | Status         | One of Active, Provisional, Deprecated, or  |
       |                | Withdrawn.                                  |
       +----------------+---------------------------------------------+
       | First          | The date the entry first entered the        |
       | registered     | registry.                                   |
       +----------------+---------------------------------------------+

                                   Table 1




  Morrison                Expires 16 November 2026                [Page 4]


  Internet-Draft           MCP Tool Surface Names                 May 2026


     The Specification Reference SHOULD be a stable document identifier
     (an RFC number, a datatracker draft URL, a specification persistent
     URL).  Where the specification is owned by a private substrate
     operator, the Change Controller field identifies the operator and the
     Specification Reference points to the operator's published
     specification.

  4.2.  ABNF for Surface Names

     surface-name = name-component *( "_" name-component )
     name-component
                  = ALPHA *( ALPHA / DIGIT )

     Surface names MUST be lowercase ASCII.  Underscores separate
     components.  Hyphens, periods, slashes, and uppercase letters MUST
     NOT appear.  The total length of a surface name MUST NOT exceed 64
     octets.

     Vendor prefixes are an organisational convention: a registrant that
     operates a substrate exposing multiple surfaces SHOULD adopt a stable
     prefix (e.g. org_alter_, acme_) and register every surface that the
     substrate exposes under that prefix.  Use of a vendor prefix is
     RECOMMENDED but not required; cross-vendor surfaces (those whose
     specification is intended for adoption by multiple operators) MAY be
     registered without a prefix.

  5.  Registration Procedure

     Registration in this registry SHALL follow the Specification Required
     policy of [RFC8126] Section 4.6, with the additional provisions
     below.

     The Designated Expert pool, appointed by the IESG, evaluates each
     registration request against the following criteria:

     1.  The proposed surface name conforms to the ABNF in Section 4.2.

     2.  The Specification Reference is stable and publicly retrievable at
         the time of registration.

     3.  The argument schema and return shape described in the
         Specification Reference are precise enough to enable
         interoperable client implementations.

     4.  The authentication scope is well-defined; ambiguous scopes
         ("authenticated") are returned for clarification.





  Morrison                Expires 16 November 2026                [Page 5]


  Internet-Draft           MCP Tool Surface Names                 May 2026


     5.  The proposed entry does not collide with an existing entry either
         by exact match or by a vendor-prefix conflict (the proposed name
         would shadow or be shadowed by an existing entry).

     The Designated Expert MAY accept, request revision of, or reject a
     request.  Rejected requests are returned with reasons.  Accepted
     requests are entered as Active status.

     A registrant MAY request Provisional status pending a stable
     Specification Reference; provisional entries SHALL be reviewed within
     twelve months of registration and either promoted to Active, returned
     to the registrant for revision, or removed.

  6.  Initial Registry Contents

     The following entries are registered as the initial contents of the
     registry, in Active status, per the registration requests of
     [ORGALTER]:

     +===========================+=============+===========+==========+==========+======+
     |Surface name               |Specification|Auth scope |Vendor    |Change    |Status|
     |                           |             |           |prefix    |controller|      |
     +===========================+=============+===========+==========+==========+======+
     |org_alter_handbook         |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
     |                           |             |recognition|          |Meridian  |      |
     |                           |             |           |          |Pty Ltd   |      |
     +---------------------------+-------------+-----------+----------+----------+------+
     |org_alter_sop_registry     |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
     |                           |             |recognition|          |Meridian  |      |
     |                           |             |           |          |Pty Ltd   |      |
     +---------------------------+-------------+-----------+----------+----------+------+
     |org_alter_enforcement_gates|[ORGALTER]   |member-    |org_alter_|Alter     |Active|
     |                           |             |recognition|          |Meridian  |      |
     |                           |             |           |          |Pty Ltd   |      |
     +---------------------------+-------------+-----------+----------+----------+------+
     |org_alter_ingest           |[ORGALTER]   |member-    |org_alter_|Alter     |Active|
     |                           |             |recognition|          |Meridian  |      |
     |                           |             |           |          |Pty Ltd   |      |
     +---------------------------+-------------+-----------+----------+----------+------+

                                    Table 2

     Subsequent Morrison-family Internet-Drafts that reference further
     surface names under the org_alter_ vendor prefix will request
     registration against this registry by name; each request will
     identify the Specification Reference, authentication scope, and
     change controller for the new surface.  No registry-structure
     amendment is required to admit further entries.



  Morrison                Expires 16 November 2026                [Page 6]


  Internet-Draft           MCP Tool Surface Names                 May 2026


  7.  Operational Considerations

  7.1.  Discovery

     The registry is informational with respect to discovery: a client
     that wishes to discover whether a server offers a specific surface
     SHOULD consult the server's manifest rather than the registry.  The
     registry's role is to ensure that two servers offering the same
     surface name offer the same typed capability, not to enable discovery
     of which servers offer a surface.

     The DNS substrate of [MCPDNS] enables discovery of MCP servers for a
     given ~handle; once a server is discovered, the server's manifest
     enumerates the surface names it offers.  The registry ensures that
     each name in the manifest maps to a unique specification.

  7.2.  Vendor-Prefix Ownership

     A vendor prefix is not formally owned by any registrant; the prefix
     is a convention.  However, the Designated Expert SHALL treat first-
     use of a prefix as a strong signal of intended ownership and SHALL
     reject subsequent requests under the same prefix from unrelated
     registrants without prior coordination with the first registrant.
     Disputes over vendor-prefix ownership are resolved by the Designated
     Expert with reference to documented first-use evidence (datatracker
     submission dates, publication dates of the registrant's
     specifications, operational history).

  7.3.  Deprecation and Withdrawal

     An entry MAY be moved to Deprecated status by its Change Controller,
     in which case the entry remains in the registry as a record but new
     implementations are advised against it.  An entry MAY be moved to
     Withdrawn status only after a deprecation period of at least twelve
     months, and only if no known implementations remain.  Withdrawn
     entries SHALL NOT be reissued to a different registrant for at least
     five years.

  8.  Security Considerations

  8.1.  Name Collision

     A surface name that collides with an existing entry's authenticated
     specification but offers a different typed capability is a potential
     vector for cross-server confusion.  A client that unconditionally
     assumes the registry-published specification of a surface name,
     without verifying that the server's advertised manifest matches that
     specification, may invoke the surface with arguments that the server



  Morrison                Expires 16 November 2026                [Page 7]


  Internet-Draft           MCP Tool Surface Names                 May 2026


     interprets differently than the client intends.  Implementations
     SHOULD compare the server's manifest against the registry-published
     specification at session-bind and SHOULD reject mismatches.

  8.2.  Specification Drift

     The Specification Reference of an entry may evolve over time (e.g. an
     Internet-Draft progresses through revisions, an RFC is published, an
     organisational specification is revised).  The registry tracks the
     most recent stable reference.  Clients implementing against an
     earlier revision of a specification SHOULD detect specification-
     version drift via the server's manifest and SHOULD either upgrade
     their implementation or refuse to invoke the surface.

  8.3.  Vendor-Prefix Squatting

     An adversary that registers entries under a vendor prefix intended by
     a different operator may induce that operator to choose a different
     prefix or to coordinate with the squatter.  The Designated Expert's
     role under Section 6.2 is to reject such squatting requests on first-
     use evidence.  The registry mechanism does not provide cryptographic
     enforcement of vendor-prefix ownership; the safeguard is procedural.

  8.4.  Public-Surface Caller Confusion

     A surface name registered with an authentication scope of public is
     invokable by any caller.  Operators SHOULD audit their public-
     surface registrations periodically and SHOULD NOT register a surface
     as public if any future revision is anticipated to require
     authentication; demoting a public surface to an authenticated surface
     is a breaking change for callers.

  9.  IANA Considerations

     This document requests that IANA establish a new registry titled
     "Model Context Protocol Tool Surface Names".

     *  Registry name: Model Context Protocol Tool Surface Names

     *  Registration policy: Specification Required per [RFC8126]
        Section 4.6, with the Designated Expert criteria of Section 5 of
        this document.

     *  Per-entry fields: Surface name, Specification reference,
        Authentication scope, Vendor prefix, Change controller, Status,
        First registered, as defined in Section 4.1 of this document.





  Morrison                Expires 16 November 2026                [Page 8]


  Internet-Draft           MCP Tool Surface Names                 May 2026


     *  ABNF for surface names: As defined in Section 4.2 of this
        document.

     *  Initial contents: As defined in Section 6 of this document.

     *  Reference: This document.

  10.  Acknowledgements

     The registry mechanism is informed by the IANA registry-design
     guidance of [RFC8126] and by the practice of vendor-prefixed header-
     field registries in HTTP and DNS-RR-type registries.  The initial
     contents are drawn from [ORGALTER].

  11.  References

  11.1.  Normative References

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

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

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

     [ORGALTER] Morrison, B., "Org Alter Policy Provision over MCP", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-org-
                alter-policy-provision/>.

  11.2.  Informative References

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





  Morrison                Expires 16 November 2026                [Page 9]


  Internet-Draft           MCP Tool Surface Names                 May 2026


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

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

     [ALTERURI] Morrison, B., "The 'alter' URI Scheme for Dispatchable
                ~handle References", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-alter-
                uri-scheme/>.

  Appendix A.  Change Log

  A.1.  draft-morrison-mcp-tool-surface-names-registry-00

     *  Initial submission.  Establishes the registry, defines the
        registration procedure, and registers the four initial entries
        from [ORGALTER].

  Author's Address

     Blake Morrison
     Alter Meridian Pty Ltd
     Cronulla, NSW
     Australia
     Email: blake@truealter.com





















  Morrison                Expires 16 November 2026               [Page 10]


name: draft-singh-psi
rev: 00
time: 2026-03-18T00:49:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-19T00:49:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Policy/governance", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:52.065980+00:00
source: ietf
title:
  Proof of Sovereign Integrity (PSI): A Cryptographic Protocol for Verifiable AI Regulatory Compliance

abstract:
  This document specifies the Proof of Sovereign Integrity (PSI)
     Protocol, version 1.2, a cryptographic framework enabling
     organizations to prove compliance with AI regulations (including
     the EU AI Act 2024/1689, NIST AI RMF, UK AI Safety Institute
     guidelines, and equivalent frameworks) without disclosing
     proprietary model architectures, training data, or inference logic.

     PSI achieves this through a combination of SHA-256 hash-chained
     audit trails, Ed25519 digital signatures, Merkle inclusion proofs,
     Groth16-compatible zero-knowledge commitments over BN128 fields,
     and a 3-node Multi-Party Computation (MPC) consensus mechanism
     with 2/3 threshold verification.

full_text:
  Network Working Group                                          K. Singh
  Internet-Draft                                 Apex Intelligence Empire
  Intended status: Standards Track                         March 17, 2026
  Expires: September 18, 2026


        Proof of Sovereign Integrity (PSI): A Cryptographic Protocol
                  for Verifiable AI Regulatory Compliance
                           draft-singh-psi-00

  Abstract

     This document specifies the Proof of Sovereign Integrity (PSI)
     Protocol, version 1.2, a cryptographic framework enabling
     organizations to prove compliance with AI regulations (including
     the EU AI Act 2024/1689, NIST AI RMF, UK AI Safety Institute
     guidelines, and equivalent frameworks) without disclosing
     proprietary model architectures, training data, or inference logic.

     PSI achieves this through a combination of SHA-256 hash-chained
     audit trails, Ed25519 digital signatures, Merkle inclusion proofs,
     Groth16-compatible zero-knowledge commitments over BN128 fields,
     and a 3-node Multi-Party Computation (MPC) consensus mechanism
     with 2/3 threshold verification.

  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 September 18, 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
     2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . 3
     4.  Cryptographic Primitives . . . . . . . . . . . . . . . . . . 4
     5.  Verification Pipeline  . . . . . . . . . . . . . . . . . . . 5
     6.  Deterministic Pre-Flight . . . . . . . . . . . . . . . . . . 6
     7.  Merkle Tree Construction . . . . . . . . . . . . . . . . . . 7
     8.  MPC Consensus Layer  . . . . . . . . . . . . . . . . . . . . 7
     9.  Zero-Knowledge Commitments . . . . . . . . . . . . . . . . . 8
     10. Sovereign Tribunal . . . . . . . . . . . . . . . . . . . . . 9
     11. Predicate Registry . . . . . . . . . . . . . . . . . . . . . 9
     12. Proof Bundle Format  . . . . . . . . . . . . . . . . . . . . 10
     13. Legal-to-Technical Mapping . . . . . . . . . . . . . . . . . 11
     14. Security Considerations  . . . . . . . . . . . . . . . . . . 11
     15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . 12
     16. Orbital Integrity Protocol (OIP) . . . . . . . . . . . . . . 13
     17. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15

  1.  Introduction

     The proliferation of artificial intelligence systems across critical
     sectors has created an urgent need for verifiable compliance
     mechanisms. The EU AI Act mandates technical conformity assessment
     for high-risk AI systems. Existing compliance approaches suffer
     from IP exposure risk, non-verifiability, and reliance on trust.

     The PSI Protocol addresses these limitations through cryptographic
     verification primitives that enable mathematical proof of compliance
     without disclosing protected intellectual property. PSI v1.2
     introduces Deterministic Mode (blocking non-compliant actions
     before commit) and the Sovereign Tribunal (human ratification).

  2.  Terminology

     Commit: An atomic action submitted for compliance verification.

     Predicate: A machine-readable regulatory requirement (e.g. EU AI
     Act Article 14).

     Commit Hash: SHA-256(JCS(action || predicate_id || timestamp)).

     Merkle Root: The root hash of the binary tree containing ledger
     entries.

     MPC Node: One of three independent verification nodes.

     Proof Bundle: A JSON document containing all cryptographic
     artifacts for verification.

     Sovereign Tribunal: A panel of 5 independent auditors providing
     human ratification.

     PIL: Protocol Intervention Layer (runtime execution gate).

  3.  Protocol Overview

     The PSI Protocol operates as a 4-stage pipeline:

     Stage 1 - COMMIT: Input action and predicate. Run deterministic
     pre-flight check. Compute commit_hash and merkle_leaf.

     Stage 2 - CHALLENGE: Evaluate commit against predicate violation
     patterns. Compute challenge_hash and record status.

     Stage 3 - PROVE: Generate Merkle inclusion proof. Generate Groth16-
     compatible ZK commitment over BN128 fields.

     Stage 4 - VERIFY: 3 MPC nodes independently verify the proof. 2/3
     consensus required. Sign result with Ed25519.

  4.  Cryptographic Primitives

  4.1.  Hash Function

     PSI uses SHA-256. Input MUST be canonicalized using RFC 8785 (JCS)
     before hashing.

  4.2.  Digital Signatures

     Ed25519 (RFC 8032) is used for non-repudiation of Merkle roots and
     auditor verdicts.

  4.3.  Merkle Trees

     Binary Merkle trees are constructed from leaf hashes. Deterministic
     ordering and leaf duplication for odd counts are required.

  4.4.  Zero-Knowledge Commitments

     ZK commitments use BN128 finite field arithmetic. Proof elements
     (pi_A, pi_B, pi_C) demonstrate knowledge of action satisfying the
     predicate without revealing the action.

  4.5.  Sequence Counter

     A monotonic sequence counter with gap detection prevents omission
     attacks on the ledger.

  5.  Verification Pipeline

     1. Commit: Generate ID, JCS canonical hash, and persist.
     2. Challenge: Match against violation patterns; assign status.
     3. Prove: Generate Merkle proof path and ZK commitment.
     4. Verify: MPC nodes audit integrity and sign root hash.

  6.  Deterministic Pre-Flight

     The PIL evaluates actions BEFORE commit. If action matches HIGH or
     UNACCEPTABLE risk patterns, the PIL blocks execution and prevents
     ledger entry.

  7.  Merkle Tree Construction

     Trees are computed by recursively hashing lexicographically sorted
     sibling pairs. ProofPath includes sibling hashes and positions.

  8.  MPC Consensus Layer

     Verification is distributed across Alpha, Beta, and Gamma nodes.
     Consensus ensures that no single entity can forge a compliance
     certificate.

  9.  Zero-Knowledge Commitments

     BN128 field operations provide the privacy layer. The system uses
     Groth16 elements to prove predicates without data disclosure.

  10. Sovereign Tribunal

     Human oversight is provided by 5 auditors. 3/5 threshold is
     required for final ratification of automated verdicts.

  11. Predicate Registry

     Contains machine-readable rules for EU AI Act, MiFID II, DORA, NIST
     AI RMF, and AU Privacy Act.

  12. Proof Bundle Format

     Standardized JSON including merkle_root, ed25519_signature, and
     zk_proof points.

  13. Legal-to-Technical Mapping

     Article 12: Immutable logging + RFC 8785.
     Article 14: Human Oversight PIL + Sovereign Tribunal.
     Article 15: MPC consensus + ZK-Integrity.

  14. Security Considerations

     Protocol mitigates log tampering, false-negatives, and single
     points of failure. IP protection is guaranteed by ZK mathematics.

  15. IANA Considerations

     Requests registration of application/psi-proof+json and the psi://
     URI scheme.

  16. Orbital Integrity Protocol (OIP)

     Extends PSI to space-based compute. Defines LAM levels for
     radiation-tolerant proof generation on satellite hardware.

  17. References

     RFC 2119, RFC 8032, RFC 8785, EU 2024/1689.

  Authors' Addresses

     Kawaljeet Singh
     Apex Intelligence Empire
     Balaclava, Victoria, Australia
     Email: kawaljeet.singh3008@gmail.com
     URI: https://apex-infrastructure.com


name: draft-yalcinkaya-rats-asil-m
rev: 00
title: An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS
time: 2026-03-19T17:19:01Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-20T17:19:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:52.065984+00:00
source: ietf
abstract:
  This document defines an application profile for Remote ATtestation
     procedureS (RATS) deployments in which authorization decisions depend
     on evidence from multiple independent trust roots. The profile is
     intended for AI inference systems that require explicit cross-root
     appraisal before execution is authorized.

     The document specifies three related artifacts:

     *  an Attestation Evidence Synthesis Protocol for combining multiple
        evidence sets into one deterministic appraisal outcome;

     *  the Twin Attestation Policy Language (TAPL), a constrained policy
        language for deterministic multi-root appraisal; and

     *  the Canonical Attestation Record (CAR), an audit-oriented envelope
        that binds evidence references, appraisal outputs, freshness
        information, and replay-verification metadata.

     CAR is not a replacement for Evidence or Attestation Results as used
     in the RATS architecture. Instead, it is a higher-layer profile for
     packaging multi-root appraisal state and application-specific bindings
     for replay and audit.

full_text:
  Network Working Group                                      E. Yalcinkaya
  Internet-Draft                                          Luminesce Limited
  Intended status: Informational                            March 19, 2026
  Expires: September 19, 2026

          An ASIL-M Profile for Multi-Root Evidence Synthesis in RATS
                       draft-yalcinkaya-rats-asil-m-00

  Abstract

     This document defines an application profile for Remote ATtestation
     procedureS (RATS) deployments in which authorization decisions depend
     on evidence from multiple independent trust roots. The profile is
     intended for AI inference systems that require explicit cross-root
     appraisal before execution is authorized.

     The document specifies three related artifacts:

     *  an Attestation Evidence Synthesis Protocol for combining multiple
        evidence sets into one deterministic appraisal outcome;

     *  the Twin Attestation Policy Language (TAPL), a constrained policy
        language for deterministic multi-root appraisal; and

     *  the Canonical Attestation Record (CAR), an audit-oriented envelope
        that binds evidence references, appraisal outputs, freshness
        information, and replay-verification metadata.

     CAR is not a replacement for Evidence or Attestation Results as used
     in the RATS architecture. Instead, it is a higher-layer profile for
     packaging multi-root appraisal state and application-specific bindings
     for replay and audit.

  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), its areas, and its working groups.  Note that
     other groups may also distribute working documents as
     Internet-Drafts.

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

     The list of current Internet-Drafts can be accessed at
     https://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     https://www.ietf.org/shadow.html

     This Internet-Draft will expire on September 19, 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.

  1.  Introduction

     Some AI inference systems are intentionally deployed across
     heterogeneous trust roots in order to reduce common-mode failure,
     implementation monoculture, and correlated compromise. In such
     systems, a single attestation-verification outcome is not sufficient
     for a Relying Party decision. Instead, the Relying Party requires a
     synthesized appraisal over multiple evidence sets and an auditable
     binding between that synthesized appraisal and the inference decision
     being authorized.

     The RATS architecture already defines the relevant roles and message
     classes for this environment: Attesters produce Evidence, Verifiers
     appraise that Evidence according to policy, and Relying Parties use
     Attestation Results as inputs to authorization. What is not defined by
     the base architecture is an application profile for deterministic
     synthesis across multiple independent evidence sources for one AI
     inference authorization event.

     This document defines such a profile. It does not introduce new RATS
     roles. It defines:

     *  a deterministic synthesis procedure across multiple evidence sets;

     *  a constrained appraisal-policy language for multi-root decisions;
        and

     *  an audit-oriented container for binding the resulting appraisal
        state to freshness and replay metadata.

  2.  Terminology

     The key words "MUST", "MUST NOT", "SHOULD", and "MAY" in this
     document are to be interpreted as described in BCP 14.

     This document uses the RATS terms "Attester", "Evidence", "Verifier",
     "Attestation Results", "Relying Party", and "Appraisal Policy" as
     defined by RFC 9334.

     This document additionally uses the following profile terms:

     *  Multi-root evidence set: the collection of Evidence objects that
        correspond to the same authorization event but originate from two
        or more independent trust roots.

     *  Synthesized appraisal: the deterministic outcome produced after
        individual evidence appraisal and cross-root policy evaluation.

     *  TAPL: a constrained language for expressing threshold checks,
        predicate checks, and decision outputs over a multi-root evidence
        set.

     *  CAR: an audit-oriented envelope that binds evidence references,
        synthesized appraisal state, freshness information, and replay
        metadata.

     *  Semantic binding: application-specific metadata that binds the
        attested execution context to the inference event that the Relying
        Party is authorizing.

     *  Independence metrics: policy-level attestation-plane measures that
        verify the absence of shared vendor, cryptographic stack, or
        operational control plane across evidence sources. These are
        appraisal-layer predicates and do not depend on graph-theoretic
        extensions.

  3.  Problem Statement

     In a conventional single-root deployment, a Relying Party may accept
     Attestation Results derived from one Evidence source and authorize
     execution accordingly. In a multi-root AI deployment, that is
     insufficient for two reasons.

     First, the authorization decision may depend on policy predicates that
     compare properties across roots rather than within a single root. For
     example, the Relying Party may require evidence that two execution
     paths are not derived from the same vendor, cryptographic stack, or
     operational control plane.

     Second, the Relying Party may need a replayable record showing which
     combination of evidence, policy version, and freshness context caused
     a specific authorization outcome for a specific inference event.

     Existing attestation workflows do not define how multiple heterogeneous
     evidence sources should be combined into one deterministic appraisal
     outcome for a single authorization decision. This profile makes those
     synthesis and packaging rules explicit for AI inference deployments.

  4.  Attestation Evidence Synthesis Protocol

  4.1.  Overview

     The Attestation Evidence Synthesis Protocol defined here is a profile
     procedure executed by a Verifier, or by a Verifier-associated policy
     service, before a Relying Party authorizes an inference event.

     The procedure is:

     1.  Collect Evidence objects for the same authorization event from two
         or more Attesters.

     2.  Verify each Evidence object according to its applicable Appraisal
         Policy for Evidence.

     3.  Reject stale, incomplete, or mismatched evidence sets before
         synthesis begins.

     4.  Evaluate cross-root predicates and thresholds over the verified
         evidence set.

     5.  Produce one synthesized appraisal outcome.

     6.  Bind that outcome to freshness context, policy identity, and the
         application-specific inference event identifier.

     7.  Emit Attestation Results and, optionally, a CAR for audit and
         replay.

  4.2.  Inputs

     The minimum synthesis inputs are:

     *  one or more Evidence objects per authorization event;

     *  a policy identifier and policy digest;

     *  freshness inputs sufficient to detect replay or mixed-session
        reuse; and

     *  the application event identifier to which the synthesized appraisal
        will apply.

  4.3.  Outputs

     The synthesis procedure produces:

     *  a deterministic decision such as ALLOW, DEGRADE, BLOCK, or
        QUARANTINE;

     *  a list of evaluated predicates or thresholds sufficient for audit;
        and

     *  Attestation Results suitable for use by a Relying Party.

     When audit and replay support are needed, the procedure SHOULD also
     emit a CAR.

  5.  TAPL as Constrained Appraisal Policy

  5.1.  Design Goal

     TAPL is a constrained policy language for deterministic multi-root
     appraisal. It is intended to express profile-specific Appraisal Policy
     logic, not to define a general-purpose policy engine.

     TAPL is deliberately limited to:

     *  threshold checks,
     *  predicate checks,
     *  explicit decision outputs, and
     *  side-effect-free evaluation.

  5.2.  Example Grammar

     PolicyDef        ::= "policy" Identifier "{" Directives Rules "}"
     Directives       ::= Directive*
     Directive        ::= "enforce_profile" ProfileLevel ";"
                        | "set_threshold" Identifier "=" FloatLiteral ";"

     Rules            ::= Rule+
     Rule             ::= "on" ContextTrigger "{" LogicBlock "}" "->" Decision ";"

     ContextTrigger   ::= "attestation" | "semantic_binding" | "freshness"
     LogicBlock       ::= Statement*

     Statement        ::= "if" Condition "then" Decision ";"
                        | "require" Condition ";"

     Condition        ::= Expression
     Expression       ::= Term (("AND" | "OR") Term)*
     Term             ::= "NOT" Term | "(" Expression ")" | Predicate | Comparison

     Comparison       ::= MetricIdentifier Operator NumericLiteral
     Operator         ::= ">=" | "<=" | "==" | ">" | "<"

     Predicate        ::= "verify_evidence(" RootIdentifier ")"
                        | "check_predicate(" PredicateIdentifier ")"

     RootIdentifier   ::= Identifier
     PredicateIdentifier ::= Identifier
     MetricIdentifier ::= Identifier

     Decision         ::= "ALLOW" | "DEGRADE" | "BLOCK" | "QUARANTINE"
     ProfileLevel     ::= "L0" | "L1" | "L2" | "L3" | "L4"

     Identifier       ::= Letter (Letter | Digit | "_")*
     FloatLiteral     ::= Digit+ "." Digit+
     NumericLiteral   ::= FloatLiteral | Digit+

  5.3.  TAPL Result Binding

     The result of TAPL evaluation MUST be bound to:

     *  the exact multi-root evidence set being appraised;
     *  the policy digest used for appraisal;
     *  the freshness context used to reject replay; and
     *  the application event identifier.

     A TAPL outcome without that binding MUST NOT be reused as if it were
     current authorization state.

  6.  Canonical Attestation Record (CAR)

  6.1.  Role of CAR

     CAR is an audit-oriented envelope for multi-root appraisal. It is not
     itself a new RATS role and it does not replace Evidence or
     Attestation Results. Its purpose is to bind together:

     *  references to the Evidence appraised,
     *  synthesized appraisal outputs,
     *  policy identity,
     *  freshness context, and
     *  replay-verification metadata.

  6.2.  Conceptual Structure

  ```json
  {
    "metadata": {
      "car_version": "1.0",
      "event_id": "uuid",
      "profile_id": "L2",
      "issued_at": "2026-03-19T12:00:00Z"
    },
    "attestation_evidence": [
      {
        "root_id": "root_a",
        "evidence_digest": "sha-384:...",
        "evidence_type": "evidence-reference"
      },
      {
        "root_id": "root_b",
        "evidence_digest": "sha-384:...",
        "evidence_type": "evidence-reference"
      }
    ],
    "policy_evaluation": {
      "tapl_policy_digest": "sha-384:...",
      "synthesized_decision": "ALLOW",
      "failing_predicates": []
    },
    "independence_metrics": {
      "vendor_separation": true,
      "crypto_stack_separation": true,
      "control_plane_separation": true
    },
    "freshness": {
      "nonce": "base64url...",
      "evidence_window": "session-epoch-123"
    },
    "semantic_binding": {
      "subject_digest": "sha-384:...",
      "binding_type": "application-event"
    },
    "semantic_consensus": {
      "consistency_check": "passed",
      "checked_properties": ["model_version", "input_schema"]
    },
    "cryptographic_binding": {
      "car_digest": "sha-384:...",
      "timestamp_token_digest": "sha-384:...",
      "signer": "verifier.example"
    }
  }
  ```

  6.3.  CAR Processing Rules

     A CAR emitted under this profile MUST:

     *  identify the specific evidence set that was appraised;

     *  identify the policy digest used to synthesize the result;

     *  identify freshness inputs sufficient to reject stale reuse;

     *  identify the application event to which the result applies; and

     *  include cryptographic binding sufficient to detect tampering after
        issuance.

  7.  Relationship to RFC 9334 and EAT

  7.1.  Relationship to the RATS Architecture

     This profile is designed to fit within the RATS architecture described
     by RFC 9334.

     In particular:

     *  Attesters continue to produce Evidence;

     *  Verifiers continue to appraise Evidence and produce Attestation
        Results;

     *  Relying Parties continue to consume Attestation Results; and

     *  TAPL is profile-specific Appraisal Policy logic for multi-root
        synthesis.

     This document does not redefine those roles.

  7.2.  Relationship to EAT

     This profile does not require a new token format. EAT-based claims can
     be used where deployments already use EAT to encode Evidence,
     Attestation Results, or related claims.

     CAR is therefore best understood as a higher-layer audit and replay
     envelope. It can carry references to EAT-based artifacts, or to other
     evidence and result encodings, together with the policy digest,
     freshness context, and application-event binding needed for multi-root
     replay.

  8.  CAR-to-RATS Mapping

  | CAR field                               | RATS / EAT concept                                    | Role primarily responsible              | Purpose                                                                 |
  |-----------------------------------------|-------------------------------------------------------|-----------------------------------------|-------------------------------------------------------------------------|
  | `attestation_evidence[]`                | Evidence or references to Evidence                    | Attester, Verifier                      | Identifies the evidence set appraised for the authorization event       |
  | `policy_evaluation.synthesized_decision`| Attestation Results outcome                           | Verifier                                | Captures the deterministic result of multi-root appraisal               |
  | `policy_evaluation.tapl_policy_digest`  | Appraisal Policy identifier or digest                 | Verifier or policy service              | Shows which policy instance produced the result                         |
  | `independence_metrics.*`                | Application-specific appraisal predicates             | Verifier or policy service              | Records whether cross-root separation predicates passed at appraisal time|
  | `freshness.*`                           | Freshness inputs associated with appraisal            | Attester, Verifier                      | Supports replay rejection and same-session binding                      |
  | `semantic_binding.*`                    | Application-specific claim binding                    | Verifier or application policy service  | Binds the appraisal to the specific inference event being authorized    |
  | `semantic_consensus.*`                  | Application-specific consistency checks               | Verifier or application policy service  | Records whether cross-root semantic consistency checks passed           |
  | `cryptographic_binding.*`               | Integrity protection around evidence references and result package | Verifier               | Detects tampering after issuance                                        |

  9.  Security Considerations

     A deployment using this profile MUST ensure that synthesized appraisal
     outputs cannot be detached from the specific evidence set, policy
     digest, freshness context, and application event to which they apply.

     In particular:

     *  replayed evidence from an earlier authorization event MUST be
        rejected;

     *  mixed-session evidence sets MUST be rejected before synthesis;

     *  quote or evidence substitution after appraisal MUST be detectable;

     *  the freshness window for synthesis MUST be explicit;

     *  policy drift MUST be detectable through policy identity or digest;
        and

     *  any timestamp token used for long-term replay MUST be bound to the
        exact CAR digest being archived.

     Where the profile carries application-specific semantic bindings, the
     binding SHOULD use digests or references rather than raw application
     payloads unless disclosure is operationally required.

  10.  Privacy Considerations

     This profile SHOULD minimize disclosure of application-specific data.
     A CAR need not contain raw Evidence bytes, raw inference inputs, or
     raw model outputs when references or digests are sufficient for replay
     and audit.

     Deployments using EAT-based claims or equivalent encodings SHOULD
     disclose only those claims required by the Relying Party's policy.

  11.  IANA Considerations

     This document has no IANA actions.

  12.  References

  12.1.  Normative References

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Tsao, T.,
                and W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, January 2023.

  12.2.  Informative References

     [RFC3161]  Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
                "Internet X.509 Public Key Infrastructure Time-Stamp
                Protocol (TSP)", RFC 3161, August 2001.

  Author's Address

     Erkan Yalcinkaya
     Luminesce Limited
     United Kingdom
     Email: yalcinkaya@luminescelimited.com
     URI:   https://luminescelimited.com


name: draft-reilly-rmrp
rev: 00
title: Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed, Auditable AI Model Routing
time: 2026-04-28T23:44:08Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-30T23:44:08Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Policy/governance", "Model serving/inference"]
tags: []
fetched_at: 2026-05-22T09:24:52.066014+00:00
source: ietf
abstract:
  This document specifies the Reilly Model Routing Protocol (RMRP),
     a framework for policy-governed, auditable routing of inference
     requests across heterogeneous artificial intelligence (AI) model
     environments. RMRP defines the structural metadata, routing policy
     declaration, execution semantics, audit trail requirements, and cost
     attribution mechanisms necessary to govern how inference requests are
     directed to AI models in multi-model deployments.

     The protocol is AI-provider agnostic and operates independently of
     any specific model architecture, inference runtime, vendor
     implementation, or transport layer. RMRP addresses the absence of a
     standardized protocol-layer specification governing how routing
     decisions are declared, transmitted, logged, and enforced across
     AI model deployments at organizational scale.

full_text:
  Internet-Draft                                           L. J. Reilly
  Intended Status: Informational                            Independent
  Expires: October 28, 2026                               April 28, 2026


                 Reilly Model Routing Protocol (RMRP):
        A Framework for Policy-Governed, Auditable AI Model Routing

                         draft-reilly-rmrp-00


  Abstract

     This document specifies the Reilly Model Routing Protocol (RMRP),
     a framework for policy-governed, auditable routing of inference
     requests across heterogeneous artificial intelligence (AI) model
     environments. RMRP defines the structural metadata, routing policy
     declaration, execution semantics, audit trail requirements, and cost
     attribution mechanisms necessary to govern how inference requests are
     directed to AI models in multi-model deployments.

     The protocol is AI-provider agnostic and operates independently of
     any specific model architecture, inference runtime, vendor
     implementation, or transport layer. RMRP addresses the absence of a
     standardized protocol-layer specification governing how routing
     decisions are declared, transmitted, logged, and enforced across
     AI model deployments at organizational scale.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on October 28, 2026.

  Copyright Notice

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

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


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  4
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . .  4
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.3.  Design Principles . . . . . . . . . . . . . . . . . . .  5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.  RMRP Architecture Overview . . . . . . . . . . . . . . . .   8
       3.1.  Architectural Layers  . . . . . . . . . . . . . . . . .  8
       3.2.  Component Roles . . . . . . . . . . . . . . . . . . . .  9
       3.3.  Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
     4.  Model Routing Decision (MRD)  . . . . . . . . . . . . . . . 11
       4.1.  MRD Structure . . . . . . . . . . . . . . . . . . . . . 11
       4.2.  MRD Field Definitions . . . . . . . . . . . . . . . . . 12
       4.3.  Task Classification . . . . . . . . . . . . . . . . . . 15
       4.4.  Model Tier Definitions  . . . . . . . . . . . . . . . . 16
       4.5.  Complexity Scoring  . . . . . . . . . . . . . . . . . . 17
       4.6.  MRD Example . . . . . . . . . . . . . . . . . . . . . . 18
     5.  Routing Policy Document (RPD) . . . . . . . . . . . . . . . 19
       5.1.  RPD Structure . . . . . . . . . . . . . . . . . . . . . 19
       5.2.  RPD Field Definitions . . . . . . . . . . . . . . . . . 20
       5.3.  Rule Evaluation Order . . . . . . . . . . . . . . . . . 23
       5.4.  Fallback Behavior . . . . . . . . . . . . . . . . . . . 23
       5.5.  RPD Example . . . . . . . . . . . . . . . . . . . . . . 24
     6.  Routing Execution Semantics . . . . . . . . . . . . . . . . 26
       6.1.  Pre-Routing Validation  . . . . . . . . . . . . . . . . 26
       6.2.  Policy Resolution . . . . . . . . . . . . . . . . . . . 26
       6.3.  Model Selection . . . . . . . . . . . . . . . . . . . . 27
       6.4.  Request Dispatch  . . . . . . . . . . . . . . . . . . . 27
       6.5.  Response Handling . . . . . . . . . . . . . . . . . . . 28
       6.6.  Error and Fallback Handling . . . . . . . . . . . . . . 28
     7.  Audit Trail Requirements  . . . . . . . . . . . . . . . . . 30
       7.1.  Audit Log Record (ALR) Structure  . . . . . . . . . . . 30
       7.2.  ALR Field Definitions . . . . . . . . . . . . . . . . . 31
       7.3.  Audit Level Classes . . . . . . . . . . . . . . . . . . 33
       7.4.  Retention Requirements  . . . . . . . . . . . . . . . . 33
       7.5.  ALR Example . . . . . . . . . . . . . . . . . . . . . . 34
     8.  Cost Attribution Framework  . . . . . . . . . . . . . . . . 35
       8.1.  Cost Attribution Record (CAR)  . . . . . . . . . . . . 35
       8.2.  CAR Field Definitions . . . . . . . . . . . . . . . . . 36
       8.3.  Budget Authority Chain  . . . . . . . . . . . . . . . . 37
       8.4.  Cost Ceiling Enforcement  . . . . . . . . . . . . . . . 38
       8.5.  CAR Example . . . . . . . . . . . . . . . . . . . . . . 38
     9.  Governance and Authorization  . . . . . . . . . . . . . . . 39
       9.1.  Policy Authority Model  . . . . . . . . . . . . . . . . 39
       9.2.  Policy Issuance and Signing . . . . . . . . . . . . . . 40
       9.3.  Policy Versioning . . . . . . . . . . . . . . . . . . . 41
       9.4.  Override Mechanisms . . . . . . . . . . . . . . . . . . 41
     10. Transport Considerations  . . . . . . . . . . . . . . . . . 42
       10.1. HTTP Transport  . . . . . . . . . . . . . . . . . . . . 42
       10.2. Header Propagation  . . . . . . . . . . . . . . . . . . 43
       10.3. Non-HTTP Transports . . . . . . . . . . . . . . . . . . 43
     11. Security Considerations . . . . . . . . . . . . . . . . . . 44
       11.1. Policy Integrity  . . . . . . . . . . . . . . . . . . . 44
       11.2. MRD Tampering . . . . . . . . . . . . . . . . . . . . . 44
       11.3. Audit Log Integrity . . . . . . . . . . . . . . . . . . 45
       11.4. Denial of Service . . . . . . . . . . . . . . . . . . . 45
       11.5. Credential Exposure . . . . . . . . . . . . . . . . . . 45
     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . 46
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 47
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . 48
       14.1. Normative References  . . . . . . . . . . . . . . . . . 48
       14.2. Informative References  . . . . . . . . . . . . . . . . 49
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 50
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 50


  1.  Introduction

  1.1.  Motivation

     The deployment of artificial intelligence systems at organizational
     scale increasingly involves multiple AI models operating in
     parallel or in sequence. A given application may call upon
     lightweight models for classification tasks, mid-tier models for
     summarization, and advanced models for complex multi-step reasoning,
     all within a single request pipeline. This operational pattern is
     referred to throughout this document as multi-model deployment.

     Despite the rapid proliferation of multi-model AI deployments, no
     standardized protocol exists that specifies how routing decisions
     between models should be declared, communicated, executed, audited,
     or governed. Current industry practice is characterized by ad hoc
     engineering decisions embedded in application code, vendor-specific
     gateway configurations, or informal internal policies with no
     interoperable representation.

     This absence of a protocol standard produces several systemic
     problems:

     o  Routing logic is opaque and non-portable across systems and
        vendors.

     o  Cost attribution for model usage cannot be reliably traced to
        the policy decision that produced the expenditure.

     o  Audit records, where they exist, are inconsistent, incomplete,
        and not interoperable.

     o  Governance over who may define, modify, or override routing
        policy is informal and unenforceable at the protocol layer.

     o  Failure modes, escalation paths, and fallback behavior are
        undefined in any portable specification.

     The Reilly Model Routing Protocol (RMRP) addresses each of these
     deficiencies by defining a provider-agnostic, transport-agnostic
     protocol framework for AI model routing governance.

  1.2.  Scope

     This document specifies:

     o  The Model Routing Decision (MRD): a structured metadata object
        that accompanies every routed inference request, carrying the
        routing decision and its full governance context.

     o  The Routing Policy Document (RPD): a declarative specification
        that defines the rules by which routing decisions are made.

     o  Routing Execution Semantics: the normative procedures by which
        an RMRP-compliant router resolves, applies, and validates
        routing policy against an incoming request.

     o  The Audit Log Record (ALR): a standardized record structure for
        capturing each routing event for compliance, debugging, and
        accountability purposes.

     o  The Cost Attribution Record (CAR): a structure that traces the
        financial cost of each routed request to the policy, cost
        center, and budget authority that authorized it.

     o  A Governance and Authorization model that defines how routing
        policy is issued, signed, versioned, and enforced.

     This document does not specify the internal architecture of any AI
     model, the machine learning logic used to assess request complexity,
     the commercial pricing structure of any AI provider, or any
     application-layer inference API. RMRP is a governance and metadata
     protocol layer that sits above any such systems.

  1.3.  Design Principles

     RMRP is designed according to the following principles:

     Provider Agnosticism:  RMRP MUST NOT assume the use of any
        specific AI model provider, vendor API, or proprietary
        infrastructure. All provider-specific identifiers are treated
        as opaque strings within the protocol.

     Transport Agnosticism:  RMRP metadata structures are defined as
        JSON objects. They may be transmitted over HTTP, message queues,
        RPC frameworks, or any other transport that supports structured
        data payloads.

     Auditability by Default:  Every routing decision produces an
        auditable record. Audit logging is not optional for conformant
        implementations.

     Policy as a First-Class Object:  Routing policy is a declared,
        versioned, signed artifact. Inline or implicit routing logic
        embedded in application code does not satisfy RMRP conformance.

     Cost Traceability:  Every routed request MUST be attributable to
        a cost center and budget authority. Unattributed inference costs
        are a conformance violation.

     Least-Cost Sufficiency:  Routing policy SHOULD direct requests to
        the least capable model tier sufficient to satisfy the task
        requirements. Routing to a higher tier MUST be justified by
        policy conditions.

     Separation of Concerns:  The routing decision layer is separate
        from the inference execution layer. An RMRP-compliant router
        makes and records a routing decision; it does not implement
        inference.


  2.  Terminology

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

     The following terms are defined for use in this document:

     AI Model:  A software system that accepts a structured input
        (referred to herein as an inference request) and produces a
        structured output (referred to herein as an inference response)
        using a learned computational process. This definition is
        intentionally broad and encompasses large language models,
        multimodal models, embedding models, classification models, and
        other learned inference systems.

     Budget Authority:  The organizational entity, role, or system
        identity that has been designated as responsible for approving
        inference expenditure within a defined cost center. Budget
        Authority is referenced by identifier within RMRP structures and
        resolved externally to the protocol.

     Complexity Score:  A normalized floating-point value in the range
        [0.0, 1.0] that represents an assessment of the computational
        or semantic difficulty of an inference request relative to a
        defined task type. The method of computing the Complexity Score
        is outside the scope of this specification; RMRP defines only
        how this value is represented and used in routing decisions.

     Conformant Router:  An RMRP Routing Engine that implements all
        REQUIRED behaviors specified in this document.

     Cost Attribution Record (CAR):  A structured JSON object produced
        by a Conformant Router upon completion of a routed inference
        request, recording the financial cost of the request and
        attributing it to the applicable cost center, policy, and
        Budget Authority.

     Cost Center:  An organizational unit, project, team, application,
        or other logical grouping to which the financial cost of
        inference requests is attributed.

     Fallback Model:  The AI model or model tier to which a routing
        request is directed when the primary selected model is
        unavailable, returns an error, or exceeds a defined constraint.

     Inference Request:  A structured input submitted to an AI model
        for processing. The content and format of the inference request
        are outside the scope of this specification.

     Inference Response:  The structured output produced by an AI model
        in response to an Inference Request. The content and format of
        the inference response are outside the scope of this
        specification.

     Model Identifier:  An opaque string that uniquely identifies a
        specific AI model or model version within the scope of a
        deployment. Model Identifiers are defined and managed externally
        to RMRP.

     Model Registry:  An external system or configuration artifact that
        maps Model Identifiers to model capabilities, tier assignments,
        and endpoint information. RMRP does not specify the
        implementation of a Model Registry but requires that a
        Conformant Router have access to one.

     Model Routing Decision (MRD):  A structured JSON object produced
        by a Conformant Router that records the routing decision made
        for a specific inference request, including the selected model,
        the policy applied, and the full governance context.

     Model Tier:  A categorical classification of AI models according
        to their relative capability and cost. This specification
        defines three normative tiers: LIGHT, STANDARD, and ADVANCED.
        Implementations MAY define additional tiers subject to the
        constraints in Section 4.4.

     Policy Authority:  The organizational entity or role that has been
        granted the right to issue, sign, and publish Routing Policy
        Documents within a defined scope.

     Routing Engine:  The software component responsible for receiving
        an inference request, evaluating applicable Routing Policy
        Documents, producing a Model Routing Decision, and dispatching
        the request to the selected model.

     Routing Policy Document (RPD):  A structured, versioned, signed
        JSON document that declares the rules by which a Routing Engine
        selects a target model for a given inference request.

     Task Type:  A categorical label that describes the nature of an
        inference request at the application level. RMRP defines a
        normative set of Task Types in Section 4.3. Implementations MAY
        extend this set using the extension mechanism defined therein.

     Audit Log Record (ALR):  A structured JSON object produced by a
        Conformant Router for each routing event, capturing the full
        decision trace, outcome, and timing of the routing operation.

     RMRP Version:  The protocol version string identifying the version
        of this specification to which an MRD, RPD, ALR, or CAR
        conforms. The version string for this specification is "1.0".


  3.  RMRP Architecture Overview

  3.1.  Architectural Layers

     RMRP defines a governance layer that operates between the
     application layer and the AI model inference layer. This layer is
     not a transport protocol and does not replace any existing network
     or application protocol. It defines the metadata, policy, and
     audit structures that govern routing decisions.

     The RMRP architectural layers are as follows:

                   +--------------------------------------+
                   |         Application Layer            |
                   |  (Caller submits inference request)  |
                   +--------------------------------------+
                                |
                                v
                   +--------------------------------------+
                   |         RMRP Governance Layer        |
                   |                                      |
                   |  +------------------------------+    |
                   |  |  Routing Policy Document     |    |
                   |  |  (RPD)                       |    |
                   |  +------------------------------+    |
                   |                                      |
                   |  +------------------------------+    |
                   |  |  Routing Engine              |    |
                   |  |  - Evaluates RPD             |    |
                   |  |  - Produces MRD              |    |
                   |  |  - Writes ALR                |    |
                   |  |  - Writes CAR                |    |
                   |  +------------------------------+    |
                   +--------------------------------------+
                                |
                                v
                   +--------------------------------------+
                   |      AI Model Inference Layer        |
                   |  (Selected model processes request)  |
                   +--------------------------------------+

     Figure 1: RMRP Architectural Layers

  3.2.  Component Roles

     Policy Authority:  Issues, signs, and publishes RPDs. The Policy
        Authority is responsible for ensuring that RPDs reflect
        organizational cost governance, capability requirements, and
        compliance constraints. A Policy Authority MUST NOT be the same
        entity as the Routing Engine in deployments where separation of
        concerns is required by organizational policy, though this
        specification does not mandate such separation in all contexts.

     Routing Engine:  Receives inference requests from the application
        layer, resolves the applicable RPD, computes a routing decision,
        produces an MRD, dispatches the request to the selected model,
        and writes an ALR and CAR upon completion. A Conformant Router
        MUST perform all of these functions.

     Model Registry:  An external system consulted by the Routing Engine
        to resolve Model Identifiers to endpoints and validate tier
        assignments. RMRP does not specify the implementation of the
        Model Registry.

     Audit Store:  The persistent storage system into which the Routing
        Engine writes ALRs and CARs. The Audit Store MUST be write-once
        or append-only with respect to routing records to preserve audit
        integrity. Implementations MAY use cryptographic mechanisms to
        further ensure record immutability.

     Budget Authority:  Receives cost attribution data via CARs.
        Budget Authority systems are external to RMRP and consume CAR
        records for financial reporting and budget enforcement purposes.

  3.3.  Request Lifecycle

     The lifecycle of an inference request under RMRP is as follows:

     1.  The application layer submits an inference request to the
         Routing Engine, optionally including request metadata such as
         Task Type, priority class, and cost center identifier.

     2.  The Routing Engine performs pre-routing validation as specified
         in Section 6.1.

     3.  The Routing Engine resolves the applicable RPD as specified in
         Section 6.2.

     4.  The Routing Engine evaluates RPD rules against the request
         metadata and computes a Complexity Score to select a target
         model tier and Model Identifier.

     5.  The Routing Engine produces a Model Routing Decision (MRD)
         documenting the decision and its full governance context.

     6.  The Routing Engine dispatches the inference request to the
         selected model, attaching the MRD as specified in Section 6.4.

     7.  The selected model processes the request and returns an
         inference response.

     8.  The Routing Engine receives the response, records actual token
         consumption and latency, and updates the ALR and CAR with
         outcome data.

     9.  The Routing Engine writes the completed ALR and CAR to the
         Audit Store.

     10. The inference response is returned to the application layer,
         accompanied by a reference to the MRD for correlation purposes.


  4.  Model Routing Decision (MRD)

  4.1.  MRD Structure

     The Model Routing Decision is a JSON object [RFC8259] that MUST
     be produced by a Conformant Router for every inference request
     processed. The MRD captures the routing decision and its full
     governance context in a portable, inspectable form.

     The MRD MUST contain all REQUIRED fields defined in Section 4.2.
     OPTIONAL fields SHOULD be included when the relevant information
     is available to the Routing Engine. Additional fields not defined
     in this specification MAY be included using the extension mechanism
     defined in Section 4.2.

     All field names are case-sensitive. All string values are UTF-8
     encoded [RFC3629]. All timestamp values are ISO 8601 formatted
     strings in UTC with millisecond precision.

  4.2.  MRD Field Definitions

     rmrp_version  (string, REQUIRED)
        The RMRP protocol version string. For documents conforming to
        this specification, the value MUST be "1.0".

     mrd_id  (string, REQUIRED)
        A universally unique identifier for this MRD instance,
        formatted as a UUID [RFC9562]. This identifier is used to
        correlate the MRD with associated ALRs, CARs, and application
        logs.

     request_id  (string, REQUIRED)
        An identifier for the inference request as assigned by the
        caller. If the caller does not supply a request identifier, the
        Routing Engine MUST generate one and return it to the caller.
        Format is implementation-defined but MUST be unique within the
        scope of the deployment.

     timestamp  (string, REQUIRED)
        The UTC timestamp at which the Routing Engine produced this
        MRD. Format: ISO 8601 with millisecond precision.
        Example: "2026-04-28T17:00:00.000Z"

     routing_policy_id  (string, REQUIRED)
        The unique identifier of the Routing Policy Document applied
        to produce this routing decision. This value MUST correspond to
        the "policy_id" field of the applicable RPD.

     routing_policy_version  (string, REQUIRED)
        The version string of the RPD applied. This value MUST
        correspond to the "policy_version" field of the applicable RPD.

     source_system  (string, REQUIRED)
        An identifier for the application or system component that
        submitted the inference request. Format is implementation-
        defined. This field is used for attribution, auditing, and
        cost allocation.

     task_type  (string, REQUIRED)
        The Task Type classification of the inference request. MUST be
        one of the normative Task Type values defined in Section 4.3,
        or an extended value registered per the extension mechanism
        in Section 4.3.

     complexity_score  (number, REQUIRED)
        A floating-point value in the range [0.0, 1.0] representing
        the assessed complexity of the inference request. The method
        of computation is outside the scope of this specification.
        A value of 0.0 represents the minimum assessed complexity for
        the given task type; a value of 1.0 represents the maximum.

     selected_model_id  (string, REQUIRED)
        The Model Identifier of the AI model selected to process this
        inference request. This value MUST resolve to a registered
        model in the Model Registry.

     selected_model_tier  (string, REQUIRED)
        The model tier assignment of the selected model. MUST be one
        of the normative tier values defined in Section 4.4.

     routing_rationale  (string, REQUIRED)
        A human-readable description of the routing decision,
        identifying which RPD rule was matched and why the selected
        model tier was chosen. This field is intended for audit
        inspection and operational debugging.

     cost_center  (string, REQUIRED)
        The identifier of the cost center to which the financial cost
        of this inference request is attributed. This value MUST
        correspond to a valid cost center identifier in the
        organization's Cost Attribution framework.

     budget_authority_id  (string, REQUIRED)
        The identifier of the Budget Authority that approved inference
        expenditure for this cost center under the applicable RPD.

     max_token_budget  (integer, REQUIRED)
        The maximum number of tokens (input plus output) authorized for
        this inference request under the applicable RPD rule. A value
        of -1 indicates no token ceiling is enforced by policy for this
        request. Routing Engines MUST NOT route requests where the
        estimated token consumption exceeds this value without
        triggering the fallback behavior defined in Section 6.6.

     priority_class  (string, REQUIRED)
        The priority classification of the inference request.
        MUST be one of: "CRITICAL", "HIGH", "STANDARD", "BATCH".
        Priority class MAY influence model selection and queuing
        behavior. See Section 4.5 for priority class semantics.

     fallback_model_id  (string, OPTIONAL)
        The Model Identifier of the fallback model to be used if the
        selected model is unavailable or returns an error. If present,
        this value MUST resolve to a registered model in the Model
        Registry.

     fallback_model_tier  (string, OPTIONAL)
        The model tier assignment of the fallback model, if specified.
        MUST be one of the normative tier values defined in Section 4.4
        if present.

     chain_id  (string, OPTIONAL)
        An identifier linking this inference request to a broader
        multi-step request pipeline or agent chain. Used for
        correlating multiple MRDs produced within a single logical
        workflow.

     chain_step  (integer, OPTIONAL)
        The ordinal position of this inference request within the
        chain identified by "chain_id". MUST be a non-negative integer.
        The first step in a chain is 0.

     estimated_input_tokens  (integer, OPTIONAL)
        The estimated number of input tokens for this inference
        request, as assessed by the Routing Engine prior to dispatch.

     estimated_output_tokens  (integer, OPTIONAL)
        The estimated number of output tokens for this inference
        request, as assessed by the Routing Engine prior to dispatch.

     audit_level  (string, REQUIRED)
        The audit level class applied to this routing event. MUST be
        one of the normative audit level values defined in Section 7.3.

     extensions  (object, OPTIONAL)
        A JSON object containing implementation-specific or
        deployment-specific fields not defined in this specification.
        Extension field names MUST use a reverse-DNS prefix to avoid
        collisions (e.g., "com.example.custom_field"). The presence
        of extension fields MUST NOT alter the interpretation of any
        normative field defined in this specification.

  4.3.  Task Classification

     RMRP defines the following normative Task Types. These values are
     case-sensitive and MUST be used verbatim in the "task_type" field
     of the MRD and in RPD rule conditions.

     CLASSIFICATION  A request whose primary output is a categorical
        label or score applied to input content. Includes sentiment
        analysis, intent detection, content moderation, and similar
        tasks. Typically low complexity.

     EXTRACTION  A request whose primary output is structured data
        extracted from unstructured input, including named entity
        recognition, key-value extraction, and table parsing.

     SUMMARIZATION  A request whose primary output is a condensed
        representation of a larger input document or corpus.

     GENERATION  A request whose primary output is novel content
        generated in response to a prompt, including text generation,
        code generation, and creative writing tasks.

     REASONING  A request that requires multi-step logical inference,
        mathematical computation, or structured problem-solving.
        Typically high complexity.

     EMBEDDING  A request whose primary output is a vector
        representation of the input content. Embedding requests
        SHOULD be routed to models optimized for embedding generation.

     RETRIEVAL  A request that involves retrieval-augmented generation
        or query-driven document retrieval. Complexity is a function
        of retrieval corpus size and query ambiguity.

     TRANSFORMATION  A request whose primary output is a transformed
        version of the input (e.g., translation, reformatting,
        normalization, or style transfer).

     AGENTIC  A request submitted within an autonomous agent pipeline
        that may produce tool calls, multi-turn interactions, or
        sub-task decomposition. Agentic requests SHOULD be assigned
        higher complexity scores by default given their potential
        for recursive resource consumption.

     MULTIMODAL  A request that includes non-text input modalities
        such as images, audio, or video, in addition to or in place of
        text input.

     Implementations MAY define additional Task Types using the
     "extensions" mechanism. Extended Task Type values MUST use a
     reverse-DNS prefix (e.g., "com.example.CUSTOM_TASK"). RPD rules
     that reference extended Task Types MUST be ignored by Routing
     Engines that do not recognize the extended value, and fallback
     behavior as defined in Section 6.6 MUST be applied.

  4.4.  Model Tier Definitions

     RMRP defines three normative model tiers. Tier assignment is the
     responsibility of the operator and is recorded in the Model
     Registry. RMRP does not prescribe which specific models belong
     to which tier; this is a deployment-time configuration decision.

     LIGHT  Models in the LIGHT tier are optimized for low-latency,
        high-throughput processing of tasks with low-to-moderate
        complexity. LIGHT tier models are expected to be the lowest-
        cost option in a deployment. LIGHT tier SHOULD be the default
        routing target for CLASSIFICATION, EXTRACTION, EMBEDDING, and
        TRANSFORMATION task types unless policy conditions require
        escalation.

     STANDARD  Models in the STANDARD tier provide a balanced
        capability-to-cost profile. STANDARD tier is appropriate for
        SUMMARIZATION, GENERATION, and RETRIEVAL tasks at moderate
        complexity scores, and for REASONING tasks at low complexity
        scores.

     ADVANCED  Models in the ADVANCED tier provide maximum available
        capability for high-complexity tasks. ADVANCED tier MUST only
        be selected when policy conditions explicitly authorize it and
        the request complexity or task type requires capabilities
        unavailable in lower tiers. Routing to ADVANCED tier without
        explicit RPD authorization is a conformance violation.

     Implementations MAY define additional tiers using the "extensions"
     mechanism. Extended tier values MUST NOT replace or supersede the
     normative tier definitions above.

  4.5.  Complexity Scoring

     The Complexity Score is a normalized floating-point value in
     [0.0, 1.0] that the Routing Engine assigns to each inference
     request prior to RPD rule evaluation. RMRP does not mandate a
     specific algorithm for computing the Complexity Score. Conformant
     implementations MUST document the method used to produce this
     value for audit purposes.

     Informative guidance for Complexity Score computation includes:

     o  Input token count relative to model context window capacity.
     o  Presence of multi-step instructions or chained subtasks.
     o  Ambiguity of the input as assessed by a lightweight classifier.
     o  Historical accuracy of lower-tier models on similar inputs.
     o  Structural complexity indicators such as nested conditionals,
        mathematical expressions, or code with high cyclomatic
        complexity.

     Priority class semantics are as follows. Note: the value
     "STANDARD" used for priority class is distinct from the model
     tier "STANDARD" defined in Section 4.4. These identifiers exist
     in separate namespaces within the protocol and MUST NOT be
     conflated.

     CRITICAL  Requests that require immediate processing. Priority
        class CRITICAL MUST NOT be routed to BATCH processing queues.
        CRITICAL requests MAY bypass certain cost ceiling constraints
        as defined in the applicable RPD.

     HIGH  Requests that require low-latency processing but are not
        operationally critical.

     STANDARD  Default priority for interactive workloads.

     BATCH  Requests that are tolerant of high latency in exchange for
        reduced per-token cost. BATCH requests SHOULD be queued for
        asynchronous processing where the model provider supports it.

  4.6.  MRD Example

     The following is a non-normative example of a conformant MRD:

     {
       "rmrp_version": "1.0",
       "mrd_id": "550e8400-e29b-41d4-a716-446655440000",
       "request_id": "req-20260428-00192",
       "timestamp": "2026-04-28T17:00:00.000Z",
       "routing_policy_id": "rpd-prod-engineering-v3",
       "routing_policy_version": "3.2.1",
       "source_system": "api-gateway.internal",
       "task_type": "REASONING",
       "complexity_score": 0.82,
       "selected_model_id": "provider-alpha/model-advanced-v2",
       "selected_model_tier": "ADVANCED",
       "routing_rationale": "Rule R-07 matched: task_type=REASONING,
         complexity_score 0.82 exceeds STANDARD tier threshold 0.75.
         ADVANCED tier authorized by policy for cost_center=eng-ai.",
       "cost_center": "eng-ai",
       "budget_authority_id": "ba-vp-engineering-001",
       "max_token_budget": 8192,
       "priority_class": "HIGH",
       "fallback_model_id": "provider-alpha/model-standard-v4",
       "fallback_model_tier": "STANDARD",
       "chain_id": "chain-pipeline-20260428-00041",
       "chain_step": 2,
       "estimated_input_tokens": 2048,
       "estimated_output_tokens": 1024,
       "audit_level": "FULL",
       "extensions": {}
     }


  5.  Routing Policy Document (RPD)

  5.1.  RPD Structure

     The Routing Policy Document is a structured, versioned JSON
     document that declares the rules by which a Routing Engine selects
     a target model for a given inference request. A conformant RPD
     MUST be a valid JSON object [RFC8259].

     RPDs MUST be digitally signed by the issuing Policy Authority
     using a mechanism that allows the Routing Engine to verify
     authenticity and detect tampering. This specification RECOMMENDS
     the use of JSON Web Signatures (JWS) as defined in [RFC7515].

     An RPD MUST be version-controlled. Routing Engines MUST record the
     specific RPD version applied to each routing decision in the MRD.
     Superseded RPD versions MUST be retained in the Audit Store for
     the retention period defined in Section 7.4.

  5.2.  RPD Field Definitions

     rmrp_version  (string, REQUIRED)
        The RMRP protocol version string. MUST be "1.0" for this
        specification.

     policy_id  (string, REQUIRED)
        A unique identifier for this Routing Policy Document within
        the deployment scope. Policy IDs MUST be stable across versions
        of the same policy; different versions of the same policy MUST
        share the same "policy_id".

     policy_version  (string, REQUIRED)
        A semantic version string [semver] identifying this version of
        the policy. Format: MAJOR.MINOR.PATCH. A change to routing
        logic MUST increment MINOR or MAJOR. A change to metadata only
        MAY increment PATCH.

     policy_name  (string, REQUIRED)
        A human-readable name for this policy, suitable for display in
        audit interfaces.

     policy_authority_id  (string, REQUIRED)
        The identifier of the Policy Authority that issued this
        document.

     effective_date  (string, REQUIRED)
        The UTC timestamp from which this policy version is effective.
        Routing Engines MUST NOT apply a policy version prior to its
        effective date.

     expiration_date  (string, OPTIONAL)
        The UTC timestamp after which this policy version is no longer
        valid. If present, Routing Engines MUST NOT apply this policy
        version after the expiration date and MUST trigger the fallback
        behavior defined in Section 5.4.

     scope  (object, REQUIRED)
        Defines the set of source systems, cost centers, and task types
        to which this policy applies.

        scope.source_systems  (array of strings, OPTIONAL)
           If present, this policy applies only to inference requests
           originating from the listed source system identifiers. If
           absent, the policy applies to all source systems unless
           overridden by a more specific policy.

        scope.cost_centers  (array of strings, OPTIONAL)
           If present, this policy applies only to inference requests
           attributed to the listed cost center identifiers.

        scope.task_types  (array of strings, OPTIONAL)
           If present, this policy applies only to inference requests
           of the listed task types.

     default_rule  (object, REQUIRED)
        The routing rule applied when no other rule in the "rules"
        array produces a match. The default rule MUST specify at
        minimum a "target_tier" and a "max_token_budget". The default
        rule MUST NOT specify conditions.

     rules  (array of objects, REQUIRED)
        An ordered array of routing rules. MUST contain at least one
        rule. Rules MUST be evaluated in array order. The first rule
        whose conditions are satisfied by the inference request MUST
        be applied. Subsequent rules MUST NOT be evaluated after a
        match.

     Each rule object contains the following fields:

     rule_id  (string, REQUIRED)
        A unique identifier for this rule within the RPD. Rule IDs
        MUST be stable across policy versions.

     rule_description  (string, OPTIONAL)
        A human-readable description of the rule's intent.

     conditions  (object, REQUIRED for non-default rules)
        A JSON object specifying the conditions under which this rule
        applies. All specified conditions MUST be satisfied for the
        rule to match (logical AND). If no conditions are specified,
        the rule matches all requests (and SHOULD only appear as the
        default rule).

        conditions.task_types  (array of strings, OPTIONAL)
           The rule matches only if the request "task_type" is one of
           the listed values.

        conditions.complexity_min  (number, OPTIONAL)
           The rule matches only if the request "complexity_score" is
           greater than or equal to this value.

        conditions.complexity_max  (number, OPTIONAL)
           The rule matches only if the request "complexity_score" is
           less than this value.

        conditions.priority_classes  (array of strings, OPTIONAL)
           The rule matches only if the request "priority_class" is one
           of the listed values.

        conditions.source_systems  (array of strings, OPTIONAL)
           The rule matches only if the request "source_system" is one
           of the listed values.

        conditions.cost_centers  (array of strings, OPTIONAL)
           The rule matches only if the request "cost_center" is one
           of the listed values.

        conditions.chain_step_max  (integer, OPTIONAL)
           The rule matches only if the request "chain_step" is less
           than or equal to this value. Used to constrain model tier
           selection in early pipeline steps.

     target_tier  (string, REQUIRED)
        The model tier to which matching requests are routed. MUST be
        one of the normative tier values defined in Section 4.4.

     target_model_id  (string, OPTIONAL)
        If present, the Routing Engine MUST route matching requests to
        this specific model, subject to availability. If the specified
        model is unavailable, fallback behavior applies.

     fallback_tier  (string, OPTIONAL)
        The model tier to which the request is routed if the primary
        target model is unavailable. If absent, the Routing Engine
        MUST use the "default_rule" target as fallback.

     fallback_model_id  (string, OPTIONAL)
        If present, the specific fallback model identifier. Evaluated
        after "fallback_tier".

     max_token_budget  (integer, REQUIRED)
        The maximum total tokens (input plus output) authorized for
        requests matching this rule. A value of -1 indicates no
        ceiling is enforced by this rule. Routing Engines MUST enforce
        this constraint before dispatch.

     cost_ceiling_usd  (number, OPTIONAL)
        The maximum estimated cost in USD authorized for a single
        inference request matching this rule. If present, the Routing
        Engine MUST reject or reroute requests whose estimated cost
        exceeds this value. Estimation method is implementation-
        defined and MUST be documented.

     audit_level  (string, REQUIRED)
        The audit level class applied to routing events matching this
        rule. MUST be one of the normative audit level values defined
        in Section 7.3.

     allow_advanced_escalation  (boolean, OPTIONAL)
        If true, and if the "target_tier" is STANDARD, the Routing
        Engine MAY escalate to ADVANCED tier if the complexity score
        exceeds the escalation_threshold. Default: false.

     escalation_threshold  (number, OPTIONAL)
        The complexity score threshold above which escalation to
        ADVANCED tier is permitted when "allow_advanced_escalation"
        is true. MUST be in [0.0, 1.0].

  5.3.  Rule Evaluation Order

     A Conformant Router MUST evaluate RPD rules in the following
     order:

     1.  Filter out rules whose conditions do not match the request
         metadata as described in Section 5.2.

     2.  Apply the first matching rule in array order.

     3.  If no rule matches, apply the "default_rule".

     4.  If the "default_rule" is absent or invalid, the Routing Engine
         MUST reject the request and write an ALR with outcome
         "POLICY_ERROR".

  5.4.  Fallback Behavior

     The following conditions MUST trigger fallback behavior:

     o  The selected model returns an HTTP 5xx error or equivalent
        transport-level failure.

     o  The selected model is not resolvable in the Model Registry.

     o  The estimated token count exceeds "max_token_budget".

     o  The estimated cost exceeds "cost_ceiling_usd" (if present).

     o  The RPD "expiration_date" has passed.

     When fallback is triggered, the Routing Engine MUST:

     1.  Attempt routing to the "fallback_model_id" (if specified) or
         the model at "fallback_tier".

     2.  Record the fallback event in the ALR with the original
         selection, the fallback target, and the reason for fallback.

     3.  If the fallback model also fails, the Routing Engine MUST
         return an error to the caller and write an ALR with outcome
         "ROUTING_FAILURE".

  5.5.  RPD Example

     The following is a non-normative example of a conformant RPD:

     {
       "rmrp_version": "1.0",
       "policy_id": "rpd-prod-engineering-v3",
       "policy_version": "3.2.1",
       "policy_name": "Engineering Production AI Routing Policy",
       "policy_authority_id": "pa-cto-office-001",
       "effective_date": "2026-04-01T00:00:00.000Z",
       "expiration_date": "2026-10-01T00:00:00.000Z",
       "scope": {
         "source_systems": ["api-gateway.internal", "agent-runner.internal"],
         "cost_centers": ["eng-ai", "eng-platform"],
         "task_types": null
       },
       "default_rule": {
         "target_tier": "LIGHT",
         "max_token_budget": 2048,
         "audit_level": "STANDARD"
       },
       "rules": [
         {
           "rule_id": "R-01",
           "rule_description": "Batch embedding requests to LIGHT tier.",
           "conditions": {
             "task_types": ["EMBEDDING"],
             "priority_classes": ["BATCH"]
           },
           "target_tier": "LIGHT",
           "max_token_budget": 4096,
           "audit_level": "MINIMAL"
         },
         {
           "rule_id": "R-02",
           "rule_description": "Low-complexity classification to LIGHT.",
           "conditions": {
             "task_types": ["CLASSIFICATION", "EXTRACTION"],
             "complexity_max": 0.4
           },
           "target_tier": "LIGHT",
           "max_token_budget": 1024,
           "audit_level": "MINIMAL"
         },
         {
           "rule_id": "R-03",
           "rule_description": "Moderate generation to STANDARD tier.",
           "conditions": {
             "task_types": ["GENERATION", "SUMMARIZATION"],
             "complexity_min": 0.3,
             "complexity_max": 0.75
           },
           "target_tier": "STANDARD",
           "max_token_budget": 4096,
           "audit_level": "STANDARD"
         },
         {
           "rule_id": "R-04",
           "rule_description": "CRITICAL priority requests to STANDARD
             minimum.",
           "conditions": {
             "priority_classes": ["CRITICAL"]
           },
           "target_tier": "STANDARD",
           "fallback_tier": "ADVANCED",
           "max_token_budget": 8192,
           "audit_level": "FULL"
         },
         {
           "rule_id": "R-05",
           "rule_description": "High-complexity AGENTIC and REASONING
             requests to STANDARD with escalation permitted.",
           "conditions": {
             "task_types": ["AGENTIC", "REASONING"],
             "complexity_min": 0.5
           },
           "target_tier": "STANDARD",
           "allow_advanced_escalation": true,
           "escalation_threshold": 0.75,
           "max_token_budget": 16384,
           "cost_ceiling_usd": 0.50,
           "audit_level": "FULL"
         },
         {
           "rule_id": "R-06",
           "rule_description": "Multimodal requests to STANDARD tier.",
           "conditions": {
             "task_types": ["MULTIMODAL"]
           },
           "target_tier": "STANDARD",
           "max_token_budget": 8192,
           "audit_level": "STANDARD"
         },
         {
           "rule_id": "R-07",
           "rule_description": "High-complexity REASONING above
             threshold to ADVANCED.",
           "conditions": {
             "task_types": ["REASONING"],
             "complexity_min": 0.75
           },
           "target_tier": "ADVANCED",
           "fallback_tier": "STANDARD",
           "max_token_budget": 8192,
           "cost_ceiling_usd": 1.00,
           "audit_level": "FULL"
         }
       ]
     }


  6.  Routing Execution Semantics

  6.1.  Pre-Routing Validation

     Upon receipt of an inference request, a Conformant Router MUST
     perform the following validation steps before proceeding:

     1.  Verify that a valid RPD is available and has not expired.
         If no valid RPD is resolvable for the request context,
         the Routing Engine MUST reject the request with error code
         RMRP-001 (Policy Not Found).

     2.  Verify that the "source_system" identifier is present and
         recognized.

     3.  Verify that a "cost_center" is associated with the request,
         either supplied by the caller or resolvable from the
         "source_system" identifier via configuration.

     4.  Verify that the "budget_authority_id" associated with the
         cost center is active and has not been revoked.

     5.  Verify that the "task_type" is a recognized value per
         Section 4.3 or a registered extension value.

     Requests that fail pre-routing validation MUST be rejected.
     Rejected requests MUST have an ALR written with outcome
     "VALIDATION_FAILURE" identifying which validation step failed.

  6.2.  Policy Resolution

     The Routing Engine MUST resolve the applicable RPD using the
     following procedure:

     1.  Identify all RPDs whose "scope" matches the request
         (source_system, cost_center, task_type).

     2.  If multiple RPDs match, apply the most specific RPD as
         determined by the number of scope constraints satisfied.

     3.  If specificity is equal across multiple matching RPDs,
         apply the RPD with the most recent "effective_date".

     4.  Record the selected "policy_id" and "policy_version" in
         the MRD.

     Implementations that maintain a single global RPD are not
     required to perform policy resolution but MUST still record the
     policy_id and policy_version in every MRD.

  6.3.  Model Selection

     After RPD resolution, the Routing Engine MUST:

     1.  Compute or accept a Complexity Score for the request.

     2.  Evaluate RPD rules in order per Section 5.3.

     3.  Identify the matched rule and extract "target_tier" and,
         if present, "target_model_id".

     4.  If "target_model_id" is specified, resolve it in the
         Model Registry and verify it is available.

     5.  If "target_model_id" is absent, select an available model
         from the Model Registry whose tier matches "target_tier".
         Model selection within a tier is implementation-defined.

     6.  Evaluate "allow_advanced_escalation" and
         "escalation_threshold" if present.

     7.  Verify that the estimated token count does not exceed
         "max_token_budget".

     8.  Verify that the estimated cost does not exceed
         "cost_ceiling_usd" if present.

     9.  Produce and record the MRD.

  6.4.  Request Dispatch

     The Routing Engine MUST dispatch the inference request to the
     selected model endpoint with the following requirements:

     o  The MRD MUST be attached to the dispatched request. In HTTP
        transport, this MUST be accomplished via the
        "RMRP-MRD" header or request body attachment per
        Section 10.1. In other transports, attachment is per
        Section 10.3.

     o  The "request_id" from the MRD MUST be forwarded to the
        model provider where the provider's API supports a
        correlation identifier.

     o  All dispatch operations MUST be performed over encrypted
        transport (TLS 1.2 minimum, TLS 1.3 RECOMMENDED) per
        [RFC8446].

  6.5.  Response Handling

     Upon receipt of an inference response, the Routing Engine MUST:

     1.  Record the actual input and output token counts from the
         response if available.

     2.  Record the end-to-end latency of the routing and inference
         operation.

     3.  Verify that actual token consumption did not exceed
         "max_token_budget". If it did, this MUST be recorded in
         the ALR as a budget overrun event.

     4.  Produce and finalize the ALR and CAR records.

     5.  Write completed ALR and CAR to the Audit Store.

     6.  Return the inference response to the caller with the
         "mrd_id" attached for correlation.

  6.6.  Error and Fallback Handling

     Error codes defined by this specification:

     RMRP-001  Policy Not Found. No valid RPD is resolvable for
        the request context.

     RMRP-002  Validation Failure. The request failed pre-routing
        validation. Details MUST be included in the ALR.

     RMRP-003  Budget Exceeded. The estimated or actual token or
        cost consumption exceeds authorized limits.

     RMRP-004  Model Unavailable. The selected model is not
        reachable or returned a transport-level error.

     RMRP-005  Fallback Exhausted. All fallback options have been
        attempted and failed.

     RMRP-006  Policy Expired. The applicable RPD has passed its
        expiration date.

     RMRP-007  Audit Store Failure. The Routing Engine was unable
        to write the ALR or CAR to the Audit Store. This is a
        CRITICAL error; the Routing Engine SHOULD halt request
        processing until Audit Store availability is restored.

     All error events MUST result in an ALR record. Routing Engines
     MUST NOT silently suppress routing errors.


  7.  Audit Trail Requirements

  7.1.  Audit Log Record (ALR) Structure

     A Conformant Router MUST produce one Audit Log Record for each
     routing event. The ALR is a JSON object [RFC8259]. Each ALR MUST
     be written to the Audit Store before the inference response is
     returned to the caller.

     ALRs MUST be immutable after writing. The Audit Store MUST be
     append-only or equivalent with respect to routing records.
     Implementations MAY use cryptographic hash chaining, blockchain
     anchoring, or other mechanisms to provide tamper-evidence for
     the ALR sequence.

  7.2.  ALR Field Definitions

     rmrp_version  (string, REQUIRED)
        RMRP protocol version. MUST be "1.0".

     alr_id  (string, REQUIRED)
        A UUID [RFC9562] uniquely identifying this ALR.

     mrd_id  (string, REQUIRED)
        The "mrd_id" of the MRD associated with this routing event.

     request_id  (string, REQUIRED)
        The "request_id" of the inference request.

     timestamp_routing_start  (string, REQUIRED)
        UTC timestamp at which the Routing Engine began processing
        the request.

     timestamp_dispatch  (string, REQUIRED)
        UTC timestamp at which the Routing Engine dispatched the
        request to the selected model.

     timestamp_response  (string, OPTIONAL)
        UTC timestamp at which the Routing Engine received the
        inference response. Absent if the request failed before
        a response was received.

     timestamp_alr_written  (string, REQUIRED)
        UTC timestamp at which the ALR was committed to the Audit
        Store.

     routing_policy_id  (string, REQUIRED)
        The "policy_id" of the RPD applied.

     routing_policy_version  (string, REQUIRED)
        The "policy_version" of the RPD applied.

     matched_rule_id  (string, REQUIRED)
        The "rule_id" of the RPD rule that matched this request.
        MUST be "default_rule" if the default rule was applied.
        MUST be absent or null if outcome is "VALIDATION_FAILURE"
        or "POLICY_ERROR".

     source_system  (string, REQUIRED)
        The source system identifier from the MRD.

     task_type  (string, REQUIRED)
        The task type from the MRD.

     complexity_score  (number, REQUIRED)
        The complexity score from the MRD.

     priority_class  (string, REQUIRED)
        The priority class from the MRD.

     cost_center  (string, REQUIRED)
        The cost center from the MRD.

     budget_authority_id  (string, REQUIRED)
        The budget authority from the MRD.

     selected_model_id  (string, REQUIRED)
        The Model Identifier selected.

     selected_model_tier  (string, REQUIRED)
        The model tier selected.

     fallback_triggered  (boolean, REQUIRED)
        True if fallback routing was triggered during this event.

     fallback_reason  (string, OPTIONAL)
        The reason fallback was triggered. REQUIRED if
        "fallback_triggered" is true.

     fallback_model_id  (string, OPTIONAL)
        The Model Identifier used for fallback. REQUIRED if
        "fallback_triggered" is true.

     outcome  (string, REQUIRED)
        The outcome of the routing event. MUST be one of:
        "SUCCESS", "FALLBACK_SUCCESS", "VALIDATION_FAILURE",
        "POLICY_ERROR", "ROUTING_FAILURE", "BUDGET_EXCEEDED",
        "POLICY_EXPIRED".

     error_code  (string, OPTIONAL)
        The RMRP error code (e.g., "RMRP-004") if outcome is not
        "SUCCESS" or "FALLBACK_SUCCESS".

     error_detail  (string, OPTIONAL)
        A human-readable description of the error.

     actual_input_tokens  (integer, OPTIONAL)
        Actual input token count from the inference response.

     actual_output_tokens  (integer, OPTIONAL)
        Actual output token count from the inference response.

     actual_total_tokens  (integer, OPTIONAL)
        Sum of actual_input_tokens and actual_output_tokens.

     budget_overrun  (boolean, REQUIRED)
        True if actual_total_tokens exceeded max_token_budget.

     latency_routing_ms  (integer, OPTIONAL)
        Duration in milliseconds from routing start to dispatch.

     latency_inference_ms  (integer, OPTIONAL)
        Duration in milliseconds from dispatch to response receipt.

     latency_total_ms  (integer, OPTIONAL)
        Total duration in milliseconds from routing start to ALR
        write.

     audit_level  (string, REQUIRED)
        The audit level class applied to this event.

     chain_id  (string, OPTIONAL)
        Chain identifier, if applicable.

     chain_step  (integer, OPTIONAL)
        Chain step, if applicable.

     previous_alr_id  (string, OPTIONAL)
        The "alr_id" of the immediately preceding ALR in the Audit
        Store. Used for hash chaining. RECOMMENDED for
        implementations that implement tamper-evident audit logs.

     alr_hash  (string, OPTIONAL)
        A cryptographic hash of the canonical serialization of this
        ALR, computed prior to writing the "alr_hash" field itself.
        Hash algorithm MUST be identified in the "alr_hash_algorithm"
        field if present.

     alr_hash_algorithm  (string, OPTIONAL)
        The hash algorithm used to compute "alr_hash". RECOMMENDED
        values: "SHA-256", "SHA3-512", "BLAKE3".

  7.3.  Audit Level Classes

     MINIMAL  Required for low-risk, high-volume routing events such
        as batch EMBEDDING tasks. ALR MUST include all REQUIRED fields.
        Token and latency fields are OPTIONAL.

     STANDARD  Default audit level for interactive workloads. ALR
        MUST include all REQUIRED fields and all timing fields.

     FULL  Required for ADVANCED tier routing, CRITICAL priority
        requests, high-cost requests, and any request where
        "allow_advanced_escalation" is true. ALR MUST include all
        defined fields. Implementations SHOULD compute and record
        "alr_hash" for FULL-level records.

  7.4.  Retention Requirements

     ALRs and CARs MUST be retained for a minimum of 90 days.
     Implementations operating in regulated environments SHOULD retain
     records for a minimum of 7 years or the applicable regulatory
     retention period, whichever is longer.

     Superseded RPD versions MUST be retained for the same period
     as the ALRs that reference them.

     Audit Store implementations MUST support retrieval of ALRs by
     "mrd_id", "request_id", "chain_id", "cost_center",
     "routing_policy_id", and date range.

  7.5.  ALR Example

     The following is a non-normative example of a conformant ALR:

     {
       "rmrp_version": "1.0",
       "alr_id": "7f3b2c1a-0001-4d2e-9f8b-112233445566",
       "mrd_id": "550e8400-e29b-41d4-a716-446655440000",
       "request_id": "req-20260428-00192",
       "timestamp_routing_start": "2026-04-28T17:00:00.000Z",
       "timestamp_dispatch": "2026-04-28T17:00:00.032Z",
       "timestamp_response": "2026-04-28T17:00:02.187Z",
       "timestamp_alr_written": "2026-04-28T17:00:02.201Z",
       "routing_policy_id": "rpd-prod-engineering-v3",
       "routing_policy_version": "3.2.1",
       "matched_rule_id": "R-07",
       "source_system": "api-gateway.internal",
       "task_type": "REASONING",
       "complexity_score": 0.82,
       "priority_class": "HIGH",
       "cost_center": "eng-ai",
       "budget_authority_id": "ba-vp-engineering-001",
       "selected_model_id": "provider-alpha/model-advanced-v2",
       "selected_model_tier": "ADVANCED",
       "fallback_triggered": false,
       "outcome": "SUCCESS",
       "actual_input_tokens": 2041,
       "actual_output_tokens": 987,
       "actual_total_tokens": 3028,
       "budget_overrun": false,
       "latency_routing_ms": 32,
       "latency_inference_ms": 2155,
       "latency_total_ms": 2201,
       "audit_level": "FULL",
       "chain_id": "chain-pipeline-20260428-00041",
       "chain_step": 2,
       "alr_hash_algorithm": "SHA-256",
       "alr_hash": "e3b0c44298fc1c149afb4c8996fb92427ae41e4649b934ca495991b7852b855"
     }


  8.  Cost Attribution Framework

  8.1.  Cost Attribution Record (CAR)

     A Conformant Router MUST produce one Cost Attribution Record for
     each routing event that results in an inference response, whether
     successful or via fallback. CARs MUST NOT be produced for requests
     that fail before dispatch.

     The CAR is a JSON object [RFC8259]. CARs MUST be written to the
     Audit Store concurrently with or immediately following the
     associated ALR.

  8.2.  CAR Field Definitions

     rmrp_version  (string, REQUIRED)
        RMRP protocol version. MUST be "1.0".

     car_id  (string, REQUIRED)
        A UUID [RFC9562] uniquely identifying this CAR.

     mrd_id  (string, REQUIRED)
        The "mrd_id" of the associated MRD.

     alr_id  (string, REQUIRED)
        The "alr_id" of the associated ALR.

     request_id  (string, REQUIRED)
        The inference request identifier.

     timestamp  (string, REQUIRED)
        UTC timestamp of CAR production.

     cost_center  (string, REQUIRED)
        The cost center to which this expenditure is attributed.

     budget_authority_id  (string, REQUIRED)
        The Budget Authority identifier.

     routing_policy_id  (string, REQUIRED)
        The RPD policy identifier.

     routing_policy_version  (string, REQUIRED)
        The RPD policy version.

     matched_rule_id  (string, REQUIRED)
        The rule that authorized this expenditure.

     model_provider  (string, OPTIONAL)
        An opaque identifier for the AI model provider. This field
        is for organizational attribution and does not affect
        protocol behavior.

     selected_model_id  (string, REQUIRED)
        The Model Identifier selected.

     selected_model_tier  (string, REQUIRED)
        The model tier used for this request.

     actual_input_tokens  (integer, OPTIONAL)
        Actual input token count.

     actual_output_tokens  (integer, OPTIONAL)
        Actual output token count.

     actual_total_tokens  (integer, OPTIONAL)
        Total actual token count.

     estimated_cost_usd  (number, OPTIONAL)
        The estimated cost in USD at the time of routing, as
        computed by the Routing Engine. Estimation method is
        implementation-defined and MUST be documented.

     actual_cost_usd  (number, OPTIONAL)
        The actual cost in USD as reported by the model provider
        or computed from actual token counts and known pricing.

     cost_computation_method  (string, OPTIONAL)
        A description of the method used to compute cost figures.
        MUST be present if either "estimated_cost_usd" or
        "actual_cost_usd" is present.

     authorized_cost_ceiling_usd  (number, OPTIONAL)
        The "cost_ceiling_usd" from the matched RPD rule, if any.

     ceiling_exceeded  (boolean, REQUIRED)
        True if "actual_cost_usd" exceeds "authorized_cost_ceiling_usd".
        False if no ceiling was defined.

     chain_id  (string, OPTIONAL)
        Chain identifier, if applicable.

     chain_step  (integer, OPTIONAL)
        Chain step, if applicable.

  8.3.  Budget Authority Chain

     The Budget Authority Chain is the traceable sequence of
     authorization that links an inference expenditure to the
     organizational entity responsible for it. In RMRP, this chain
     is represented implicitly through the combination of:

     o  The "cost_center" field, which identifies the organizational
        unit incurring the cost.

     o  The "budget_authority_id" field, which identifies the entity
        that approved inference expenditure for that cost center.

     o  The "routing_policy_id" and "routing_policy_version" fields,
        which identify the policy document that authorized the specific
        routing decision.

     o  The "policy_authority_id" field in the RPD, which identifies
        the entity that issued the policy.

     External budget management systems consuming CAR records MUST
     be able to reconstruct the full authorization chain from these
     fields. RMRP does not specify the implementation of budget
     management systems.

  8.4.  Cost Ceiling Enforcement

     When a "cost_ceiling_usd" is defined in the matched RPD rule,
     the Routing Engine MUST:

     1.  Compute or obtain an estimated cost for the request before
         dispatch.

     2.  Compare the estimated cost to the "cost_ceiling_usd".

     3.  If the estimated cost exceeds the ceiling, the Routing Engine
         MUST attempt to reroute to the "fallback_tier" or
         "fallback_model_id" as specified in Section 5.4.

     4.  If fallback also exceeds the ceiling, the Routing Engine MUST
         reject the request with error code RMRP-003 and write an ALR
         with outcome "BUDGET_EXCEEDED".

     Cost ceiling enforcement based on estimated cost is a pre-dispatch
     control. Post-dispatch overruns MUST be recorded in the CAR as
     "ceiling_exceeded: true" but do not retroactively fail the
     completed request.

  8.5.  CAR Example

     The following is a non-normative example of a conformant CAR:

     {
       "rmrp_version": "1.0",
       "car_id": "ab12cd34-5678-4ef0-9012-abcdef012345",
       "mrd_id": "550e8400-e29b-41d4-a716-446655440000",
       "alr_id": "7f3b2c1a-0001-4d2e-9f8b-112233445566",
       "request_id": "req-20260428-00192",
       "timestamp": "2026-04-28T17:00:02.205Z",
       "cost_center": "eng-ai",
       "budget_authority_id": "ba-vp-engineering-001",
       "routing_policy_id": "rpd-prod-engineering-v3",
       "routing_policy_version": "3.2.1",
       "matched_rule_id": "R-07",
       "model_provider": "provider-alpha",
       "selected_model_id": "provider-alpha/model-advanced-v2",
       "selected_model_tier": "ADVANCED",
       "actual_input_tokens": 2041,
       "actual_output_tokens": 987,
       "actual_total_tokens": 3028,
       "estimated_cost_usd": 0.38,
       "actual_cost_usd": 0.41,
       "cost_computation_method": "provider_api_reported",
       "authorized_cost_ceiling_usd": 1.00,
       "ceiling_exceeded": false,
       "chain_id": "chain-pipeline-20260428-00041",
       "chain_step": 2
     }


  9.  Governance and Authorization

  9.1.  Policy Authority Model

     RMRP defines a two-role authorization model for routing policy
     governance:

     Policy Authority (PA):  The entity authorized to issue, sign,
        update, and revoke Routing Policy Documents within a defined
        scope. A Policy Authority MUST be identified by a stable
        "policy_authority_id" and MUST possess a cryptographic signing
        key pair.

     Budget Authority (BA):  The entity authorized to approve inference
        expenditure for one or more cost centers. A Budget Authority
        is referenced by "budget_authority_id" in RPDs and MRDs. The
        relationship between Budget Authorities and cost centers is
        defined externally to RMRP.

     A single organizational entity MAY hold both Policy Authority and
     Budget Authority roles. Implementations MAY define additional
     roles using the "extensions" mechanism.

  9.2.  Policy Issuance and Signing

     RPDs MUST be signed by the Policy Authority using a digital
     signature mechanism before they are made available to Routing
     Engines. This specification RECOMMENDS JWS [RFC7515] with
     algorithm RS256 or ES256.

     Routing Engines MUST verify the RPD signature before applying
     any policy. Routing Engines MUST reject unsigned or invalidly
     signed RPDs and write an ALR with outcome "POLICY_ERROR".

     The public key or certificate used to verify RPD signatures MUST
     be provisioned to Routing Engines through a mechanism outside the
     scope of this specification. Key management practices SHOULD
     follow [RFC8551] or applicable organizational PKI policy.

  9.3.  Policy Versioning

     RPD versions MUST follow semantic versioning. The full version
     string MUST be recorded in every MRD, ALR, and CAR produced
     under that policy version. This enables precise reconstruction of
     the routing governance context for any historical event.

     When a Policy Authority issues a new RPD version, the new version
     MUST specify an "effective_date" in the future to allow Routing
     Engines time to load and validate the updated policy before it
     takes effect. A transition period of not less than 15 minutes
     between publication and "effective_date" is RECOMMENDED.

     Routing Engines MAY cache active RPDs. Cached policies MUST be
     revalidated against the Policy Authority's signing key upon each
     cache refresh. Cache TTL is implementation-defined but MUST NOT
     exceed the RPD "expiration_date".

  9.4.  Override Mechanisms

     RMRP does not define a general-purpose override mechanism that
     permits callers to bypass routing policy. All routing decisions
     MUST be governed by a valid, signed RPD.

     If a deployment requires the ability for privileged callers to
     escalate routing decisions (e.g., an operations team requesting
     ADVANCED tier for a specific task), this capability MUST be
     implemented as an explicit RPD rule with appropriate conditions,
     not as an out-of-band bypass.

     Emergency override conditions, if required by an organization,
     MUST be defined in a dedicated RPD with a named Policy Authority
     and a "FULL" audit level for all events processed under that
     policy. Emergency RPDs MUST have short expiration windows.


  10.  Transport Considerations

  10.1.  HTTP Transport

     When RMRP is used in conjunction with HTTP-based inference APIs,
     the following conventions APPLY:

     The MRD SHOULD be attached to outbound inference requests using
     a custom HTTP header:

        RMRP-MRD: <base64url-encoded JSON MRD>

     Where base64url encoding is as defined in [RFC4648]. Note: This
     header field name does not use the "X-" prefix, consistent with
     the guidance in [RFC6648] deprecating the "X-" convention for
     newly defined header fields.

     If the MRD exceeds HTTP header size limits, it MAY be included
     as a JSON object in the request body under the reserved key
     "_rmrp_mrd", provided the inference API accepts JSON request
     bodies.

     The "mrd_id" SHOULD be returned in the inference response using
     a custom HTTP header:

        RMRP-MRD-ID: <mrd_id value>

     HTTP responses from the Routing Engine to the caller SHOULD
     include the "mrd_id" and "request_id" for correlation.

     RMRP error responses in HTTP transport SHOULD use the Problem
     Details format defined in [RFC9457] with the following fields:

        type: A URI identifying the RMRP error class.
        title: A human-readable RMRP error code (e.g., "RMRP-004").
        status: The applicable HTTP status code.
        detail: A human-readable error description.
        instance: A URI reference to the specific routing event.

  10.2.  Header Propagation

     In multi-hop deployments where inference requests pass through
     intermediate systems before reaching the Routing Engine, the
     following APPLY:

     o  The "X-RMRP-MRD" header MUST be propagated unchanged through
        intermediate systems.

     o  Intermediate systems MUST NOT modify or strip the
        "X-RMRP-MRD" header.

     o  If an intermediate system performs its own routing, it MUST
        produce a new MRD and chain it to the original using the
        "chain_id" mechanism.

  10.3.  Non-HTTP Transports

     RMRP metadata structures are transport-agnostic. For non-HTTP
     transports (e.g., gRPC, AMQP, Kafka):

     o  The MRD MUST be attached as a structured metadata object
        in the transport envelope.

     o  The transport-specific mechanism for attaching metadata is
        implementation-defined but MUST be documented by the
        implementation.

     o  All other normative requirements of this specification
        apply regardless of transport.


  11.  Security Considerations

  11.1.  Policy Integrity

     RPDs define the governance of all inference expenditure and
     model selection in a deployment. Unauthorized modification of
     an RPD could result in unauthorized use of high-cost model
     tiers, bypass of cost controls, or suppression of audit records.
     Implementations MUST enforce RPD signature verification as
     specified in Section 9.2. RPDs MUST be stored and transmitted
     in a manner that prevents unauthorized modification.

  11.2.  MRD Tampering

     A tampered MRD could be used to misattribute inference costs or
     falsify audit records. In deployments with high-assurance
     requirements, Routing Engines SHOULD produce a cryptographic
     signature over each MRD using the Policy Authority's signing key
     or a dedicated Routing Engine signing key. Receiving systems
     SHOULD verify this signature.

     MRDs MUST NOT contain inference request content, prompt text, or
     user-supplied data. MRDs are governance metadata only.

  11.3.  Audit Log Integrity

     ALR and CAR records MUST be written to a system that prevents
     modification or deletion by the Routing Engine itself or by
     operators without separate authorization. Implementations
     SHOULD implement hash chaining over the ALR sequence as
     described in Section 7.2, using the "previous_alr_id" and
     "alr_hash" fields. Implementations MAY anchor ALR hash roots
     to external immutable systems (e.g., transparency logs, public
     blockchains) for enhanced tamper-evidence.

  11.4.  Denial of Service

     A malicious or malfunctioning caller could submit high-volume
     requests designed to maximize ADVANCED tier routing and exhaust
     budget ceilings. Routing Engines SHOULD implement rate limiting
     per source system and per cost center. Rate limiting thresholds
     are outside the scope of this specification.

     The Routing Engine itself is a critical component. Its
     unavailability prevents all inference processing. Deployments
     SHOULD implement redundant Routing Engine instances. Routing
     Engines SHOULD implement circuit breakers for Audit Store
     connectivity, with defined behavior for the case where audit
     records cannot be written (see RMRP-007).

  11.5.  Credential Exposure

     RMRP records MUST NOT contain AI provider API keys, secrets,
     tokens, or authentication credentials. Model Identifiers in RMRP
     records are opaque strings and MUST NOT embed credentials.
     Authentication with model providers is a separate concern handled
     outside the RMRP governance layer.


  12.  Privacy Considerations

     RMRP governance records (MRDs, ALRs, CARs) are operational
     metadata about routing decisions. They do not, and MUST NOT,
     contain the content of inference requests or responses.

     However, the "source_system", "cost_center", and "task_type"
     fields in RMRP records may be sufficient to infer information
     about organizational activities or individual user behavior
     in certain deployment contexts. Implementations SHOULD apply
     access controls to the Audit Store consistent with the
     sensitivity of the operational data it contains.

     In deployments subject to data residency requirements,
     implementations MUST ensure that ALR and CAR records are
     stored in jurisdictions consistent with applicable regulations.
     RMRP does not specify geographic constraints on record storage.

     The "request_id" field, if it can be linked to an individual
     user, may constitute personal data under applicable privacy
     regulations. Organizations MUST assess whether RMRP records
     are subject to data subject rights obligations under applicable
     law and implement appropriate controls.


  13.  IANA Considerations

     This document requests the following registrations:

     HTTP Header Field Registration:

        Header Field Name: RMRP-MRD
        Status: Provisional
        Reference: This document, Section 10.1
        Change Controller: IETF

        Header Field Name: RMRP-MRD-ID
        Status: Provisional
        Reference: This document, Section 10.1
        Change Controller: IETF

     Media Type Registration:

        Type name: application
        Subtype name: rmrp+json
        Required parameters: none
        Optional parameters: version
        Encoding considerations: binary (UTF-8 encoded JSON)
        Security considerations: See Section 11
        Interoperability considerations: none
        Published specification: This document
        Applications: AI model routing governance
        Additional information: none
        Contact: See Author's Address
        Intended usage: COMMON
        Change controller: IETF

     URN Namespace for RMRP Error Types:

        This document requests registration of a URN sub-namespace
        under "urn:ietf:params" per the process defined in [RFC8141]
        for use as "type" values in RMRP error responses per
        Section 10.1:

           urn:ietf:params:rmrp:error:

        Requested initial error type URNs pending IANA assignment:

           urn:ietf:params:rmrp:error:policy-not-found
           urn:ietf:params:rmrp:error:validation-failure
           urn:ietf:params:rmrp:error:budget-exceeded
           urn:ietf:params:rmrp:error:model-unavailable
           urn:ietf:params:rmrp:error:fallback-exhausted
           urn:ietf:params:rmrp:error:policy-expired
           urn:ietf:params:rmrp:error:audit-store-failure

     Note to RFC Editor: This section is to be updated to reflect
     actual IANA registry assignments prior to publication as an RFC.


  14.  References

  14.1.  Normative References

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

     [RFC3629]  Yergeau, F., "UTF-8, a transformation format of
                ISO 10646", STD 63, RFC 3629,
                DOI 10.17487/RFC3629, November 2003,
                <https://www.rfc-editor.org/rfc/rfc3629>.

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

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

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

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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS)
                Protocol Version 1.3", RFC 8446,
                DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/rfc/rfc8446>.

     [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem
                Details for HTTP APIs", RFC 9457,
                DOI 10.17487/RFC9457, July 2023,
                <https://www.rfc-editor.org/rfc/rfc9457>.

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

  14.2.  Informative References

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

     [RFC6648]  Saint-Andre, P., Crocker, D., and M. Nottingham,
                "Deprecating the 'X-' Prefix and Similar Constructs
                in Application Protocols", BCP 178, RFC 6648,
                DOI 10.17487/RFC6648, June 2012,
                <https://www.rfc-editor.org/rfc/rfc6648>.

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

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

     [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource
                Names (URNs)", RFC 8141, DOI 10.17487/RFC8141,
                April 2017,
                <https://www.rfc-editor.org/rfc/rfc8141>.

     [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
                Multipurpose Internet Mail Extensions (S/MIME)
                Version 4.0 Message Specification", RFC 8551,
                DOI 10.17487/RFC8551, April 2019,
                <https://www.rfc-editor.org/rfc/rfc8551>.

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

     [semver]   Preston-Werner, T., "Semantic Versioning 2.0.0",
                2013, <https://semver.org/>.

     [ROUTELLM] Ong, I., Almahairi, A., Wu, V., Chiang, W., Wu, T.,
                Gonzalez, J., Kadous, M., and I. Stoica, "RouteLLM:
                Learning to Route LLMs with Preference Data",
                LMSYS Blog, July 2024,
                <https://lmsys.org/blog/2024-07-01-routellm/>.

     [PLPES]    Reilly, L. J., "Protocol Layer Prompt Engineering
                Specification (PLPES)", Internet-Draft
                draft-reilly-plpes-00, April 2026,
                <https://datatracker.ietf.org/doc/draft-reilly-plpes/>.

     [REM]      Reilly, L. J., "Reilly EternaMark (REM) Protocol:
                Dual-Layer Digital Permanence for Intellectual
                Property", Internet-Draft draft-reilly-rem-protocol-01,
                <https://datatracker.ietf.org/doc/draft-reilly-rem-protocol/>.


  Acknowledgments

     The author acknowledges the foundational research contributions
     of the LLM routing research community, whose work establishing
     cost-quality trade-off frameworks for model selection provided
     essential context for this protocol-layer specification. This
     document addresses the governance and standardization layer above
     that body of research.


  Author's Address

     Lawrence J. Reilly Jr.
     Independent
     Email: lawrencejohnreilly@gmail.com


name: draft-vasylenko-pait-protocol
rev: 00
time: 2026-05-16T10:57:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-17T10:57:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Agent identity/auth", "Policy/governance", "Model serving/inference"]
tags: []
fetched_at: 2026-05-22T09:24:52.066021+00:00
source: ietf
title:
  Provenance-Attributed Inference Token (PAIT): A Protocol for Token-Level Inference Provenance and Identity-Conditioned Inference in Generative AI Systems

abstract:
  This document specifies the Provenance-Attributed Inference Token
     (PAIT) protocol, a wire-level protocol for token-level provenance
     attribution and identity-conditioned inference in Large Language
     Model (LLM) systems and other generative AI systems.  PAIT defines:
     (1) an Agent Identity Token format that binds a globally unique
     agent identifier to a hierarchical authorization level by means of
     an asymmetric digital signature; (2) a Provenance Manifest Record
     format that associates each output token of an inference session
     with verifiable attribution data referencing training-corpus
     segments; (3) a Trust Telemetry Signal format for aggregated session
     metrics emission to external monitoring endpoints; and (4) a wire
     protocol state machine governing the interaction between a
     requesting agent and a generative AI endpoint.  PAIT is intended to
     address the transparency obligations imposed by emerging regulatory
     frameworks for high-risk and general-purpose AI systems, in
     particular those concerning the provenance of AI-generated content
     at sub-document granularity.

full_text:
  Internet Engineering Task Force                            O. Vasylenko
  Internet-Draft                                    InterAlliance OU
  Intended status: Standards Track                             16 May 2026
  Expires: 17 November 2026


                 Provenance-Attributed Inference Token (PAIT):
              A Protocol for Token-Level Inference Provenance and
              Identity-Conditioned Inference in Generative AI Systems
                   draft-vasylenko-pait-protocol-00


  Abstract

     This document specifies the Provenance-Attributed Inference Token
     (PAIT) protocol, a wire-level protocol for token-level provenance
     attribution and identity-conditioned inference in Large Language
     Model (LLM) systems and other generative AI systems.  PAIT defines:
     (1) an Agent Identity Token format that binds a globally unique
     agent identifier to a hierarchical authorization level by means of
     an asymmetric digital signature; (2) a Provenance Manifest Record
     format that associates each output token of an inference session
     with verifiable attribution data referencing training-corpus
     segments; (3) a Trust Telemetry Signal format for aggregated session
     metrics emission to external monitoring endpoints; and (4) a wire
     protocol state machine governing the interaction between a
     requesting agent and a generative AI endpoint.  PAIT is intended to
     address the transparency obligations imposed by emerging regulatory
     frameworks for high-risk and general-purpose AI systems, in
     particular those concerning the provenance of AI-generated content
     at sub-document granularity.

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




  Vasylenko                Expires 17 November 2026               [Page 1]

  Internet-Draft                    PAIT                       16 May 2026


     This Internet-Draft will expire on 17 November 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
       2.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Agent Identity Token (PAIT-ID)  . . . . . . . . . . . . . . .   7
       4.1.  Token Structure . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Field Definitions . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Authorization Levels  . . . . . . . . . . . . . . . . . .   9
       4.4.  Signature Algorithms  . . . . . . . . . . . . . . . . . .  10
       4.5.  Delegation  . . . . . . . . . . . . . . . . . . . . . . .  10
     5.  Provenance Manifest Record Format (PAIT-PM) . . . . . . . . .  11
       5.1.  Record Structure  . . . . . . . . . . . . . . . . . . . .  11
       5.2.  Per-Token Fields  . . . . . . . . . . . . . . . . . . . .  12
     6.  Trust Telemetry Signal Format (PAIT-TS) . . . . . . . . . . .  13
     7.  Wire Protocol State Machine . . . . . . . . . . . . . . . . .  14
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     10. Intellectual Property Rights  . . . . . . . . . . . . . . . .  18
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       11.2.  Informative References . . . . . . . . . . . . . . . . .  19
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20
     Appendix A.  Relationship to ITU-T Work Items . . . . . . . . . .  20

  1.  Introduction

     Generative artificial intelligence systems, including Large Language
     Models (LLMs), increasingly produce content that is consumed by
     downstream applications, regulated parties, and end-users without



  Vasylenko                Expires 17 November 2026               [Page 2]

  Internet-Draft                    PAIT                       16 May 2026


     sub-document evidence of which sources influenced specific portions
     of the output.  Existing provenance frameworks for AI-generated
     content (e.g., [C2PA]) operate at the level of the complete media
     asset and certify origin of the asset as a whole.  General-purpose
     provenance models such as [W3C-PROV-DM] describe upstream data
     lineage but do not bind individual output units of an inference
     session to specific training-corpus segments at runtime.

     This document specifies the Provenance-Attributed Inference Token
     (PAIT) protocol, which addresses this gap at sub-document
     granularity.  PAIT associates each output token of an inference
     session with a verifiable attribution record referencing one or
     more training-corpus segments; conditions inference behavior on a
     cryptographically verified agent identity; and emits aggregated
     trust metrics to an external monitoring endpoint.

  1.1.  Motivation

     Three concurrent developments motivate this work:

     *  Regulatory transparency obligations.  Article 50 of the
        Regulation (EU) 2024/1689 (EU AI Act) [EU-AI-ACT] requires
        providers and deployers of certain AI systems to ensure that
        outputs are marked as artificially generated or manipulated in a
        machine-readable format.  Recital 133 elaborates that such
        marking should support detection of AI-generated content.
        Operationalizing this obligation at sub-document granularity for
        sequential generative systems requires a per-token wire format
        that current standards do not provide.

     *  Identity-conditioned access control for AI agents.  As AI agents
        increasingly act on behalf of principals with differentiated
        authorization scopes, the inference behavior of generative AI
        endpoints must be conditioned on the verified identity and
        authorization level of the requesting agent, including selective
        access to portions of training corpora and to subsets of
        computational layers.  General-purpose authorization frameworks
        such as OAuth 2.0 [RFC6749] and its delegation extensions do not
        address inference-time corpus and layer selection.

     *  Verifiable per-token provenance.  Downstream consumers and
        auditors require machine-readable evidence linking specific
        output tokens to specific source-corpus segments, with
        cryptographic integrity guarantees.  Existing attribution
        mechanisms internal to LLM systems produce, at best, ad-hoc
        attribution traces that are not standardized and are not
        anchored in an immutable record.




  Vasylenko                Expires 17 November 2026               [Page 3]

  Internet-Draft                    PAIT                       16 May 2026


     PAIT is the wire-level binding layer that connects identity-
     conditioned inference, per-token provenance attribution, and
     tamper-evident provenance recording into a single protocol.

  1.2.  Scope

     This document specifies:

     *  the wire format of the PAIT Agent Identity Token (Section 4);

     *  the wire format of the PAIT Provenance Manifest Record
        (Section 5);

     *  the wire format of the PAIT Trust Telemetry Signal (Section 6);

     *  the wire protocol state machine governing the exchange between a
        requesting agent and a generative AI endpoint that implements
        PAIT (Section 7);

     *  signature algorithm identifiers for use in PAIT-ID
        (Section 4.4);

     *  IANA-managed registries for PAIT identifiers (Section 9).

  1.3.  Out of Scope

     The following are explicitly out of scope for this document:

     *  algorithmic methods for computing the attribution vector
        associated with each output token;

     *  numerical values, formulas, or computational procedures for
        determining trust coefficients of training-corpus segments;

     *  the internal architecture of the generative AI system that
        implements PAIT, including its training procedure, its
        computational layer structure, and its language-prioritization
        mechanism;

     *  storage-layer implementation of the immutable provenance
        registry beyond the requirement of an append-only cryptographic
        hash chain.

  2.  Terminology








  Vasylenko                Expires 17 November 2026               [Page 4]

  Internet-Draft                    PAIT                       16 May 2026


  2.1.  Requirements Language

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

  2.2.  Definitions

     Agent:  An entity that submits an inference request to a generative
        AI endpoint.  An Agent may be a human user, an autonomous AI
        system, or an automated service.

     Agent Identity Protocol:  The class of protocols defining a
        structure and format of an agent identifier comprising a
        globally unique machine-readable identifier, a hierarchical
        authorization level, a list of permitted operations, a list of
        prohibited operations, validity-period timestamps, a
        cryptographic signature over all preceding fields, and a
        protocol version field.  The Agent Identity Token specified in
        Section 4 of this document is a wire-format instance of an
        agent identity protocol.

     Agent Identity Token (PAIT-ID):  The wire-format identity object
        defined in Section 4 of this document, instantiating the agent
        identity protocol class.  Carries a globally unique agent
        identifier, an authorization level, a permitted-operations
        list, a validity period, and a cryptographic signature.

     Authorization Level:  A discrete value drawn from a finite ordered
        set indicating the scope of access granted to an Agent.  This
        document defines three baseline levels (L0, L1, L2) in
        Section 4.3.

     Delegating Agent:  An Agent of authorization level L0 that issues a
        PAIT-ID for an Agent of lower authorization level.

     Generative AI Endpoint:  The network-accessible service that
        receives inference requests, generates output sequences, and
        emits PAIT-PM and PAIT-TS records.

     Inference Session:  A single end-to-end interaction comprising one
        input query, one verified PAIT-ID, the resulting output
        sequence, and the corresponding PAIT-PM record.

     Provenance Manifest Record (PAIT-PM):  The per-session machine-
        readable document defined in Section 5.  Contains one entry per
        output token.

     Token:  A single discrete output unit produced by the generative AI
        endpoint.  The granularity of a Token is determined by the
        tokenizer of the endpoint and is opaque to PAIT.

     Trust Telemetry Signal (PAIT-TS):  The aggregated per-session
        metrics object defined in Section 6.  Transmitted to an external
        monitoring endpoint.





  Vasylenko                Expires 17 November 2026               [Page 5]

  Internet-Draft                    PAIT                       16 May 2026


     Validity Period:  The closed time interval, bounded by
        validity_start_utc and validity_end_utc, during which a PAIT-ID
        is considered valid for the purpose of cryptographic
        verification.

  3.  Protocol Overview

     PAIT is a request-response protocol with four atomic wire-format
     objects:

             +---------------+         +---------------+
             |   Requesting  |         |  Generative   |
             |     Agent     |         |  AI Endpoint  |
             +-------+-------+         +-------+-------+
                     |                         |
                     |  Inference Request +    |
                     |  PAIT-ID               -|--> [Verify]
                     |                         |
                     |                         |--> [Route]
                     |                         |
                     |                         |--> [Generate]
                     |                         |
                     |  Output Sequence +      |
                     |  PAIT-PM Record  <------|
                     |                         |
                                               |
                                               v
                                +-----------------------------+
                                |  External Trust Monitoring  |
                                |          Endpoint           |
                                +-------------+---------------+
                                              ^
                                              |  PAIT-TS Signal
                                              |  (HTTPS REST)
                                +-------------+---------------+
                                |  Generative AI Endpoint     |
                                +-----------------------------+

                         Figure 1: PAIT Protocol Overview

     The four atomic objects are:

     *  PAIT-ID (Section 4): identifies and authorizes the requesting
        agent.

     *  PAIT-PM (Section 5): records per-token provenance for the output
        sequence.




  Vasylenko                Expires 17 November 2026               [Page 6]

  Internet-Draft                    PAIT                       16 May 2026


     *  PAIT-TS (Section 6): emits aggregated session metrics to an
        external monitoring endpoint.

     *  PAIT Registry Record: not directly transmitted on the wire as a
        protocol element, but referenced by PAIT-PM and PAIT-TS as the
        immutable cryptographic record of inference sessions and corpus
        segments.  Registry record format is out of scope for this
        document.

  4.  Agent Identity Token (PAIT-ID)

  4.1.  Token Structure

     A PAIT-ID is a JSON object with the following top-level fields:

     {
       "protocol_version": "1.0",
       "gai":              "<UUID>",
       "auth_level":       "<L0|L1|L2>",
       "allowed_ops":      [ "<op>", ... ],
       "prohibited_ops":   [ "<op>", ... ],
       "validity_start_utc":"<ISO 8601 timestamp>",
       "validity_end_utc":  "<ISO 8601 timestamp>",
       "signature": {
         "alg":  "<ES256|EdDSA>",
         "kid":  "<key identifier>",
         "value":"<base64url-encoded signature>"
       }
     }

                      Figure 2: PAIT-ID JSON structure

     The signature value is computed over the canonicalized JSON
     serialization of all preceding fields (protocol_version through
     validity_end_utc) using the algorithm identified in signature.alg.
     The canonicalization procedure is specified by [RFC8785].

  4.2.  Field Definitions

     protocol_version:
        A string identifying the PAIT protocol version.  This document
        specifies version "1.0".  Implementations MUST reject PAIT-IDs
        with an unrecognized protocol_version.

     gai (Global Agent Identifier):
        A globally unique machine-readable identifier in UUID version 4
        format [RFC4122].  Each Agent SHOULD be assigned exactly one
        gai value across all PAIT deployments.



  Vasylenko                Expires 17 November 2026               [Page 7]

  Internet-Draft                    PAIT                       16 May 2026


     auth_level:
        A string indicating the hierarchical authorization level
        assigned to the Agent.  This document defines three baseline
        values ("L0", "L1", "L2") in Section 4.3.  Extensions to this
        document MAY define additional values.

     allowed_ops:
        A JSON array of machine-readable operation identifiers that the
        Agent is permitted to invoke against the Generative AI
        Endpoint.  An empty array signifies that all operations
        permissible at the assigned auth_level are allowed.  Operation
        identifiers are deployment-specific strings.

     prohibited_ops:
        A JSON array of machine-readable operation identifiers that the
        Agent is explicitly forbidden from invoking, irrespective of
        auth_level.  An empty array signifies no explicit prohibitions.
        Where allowed_ops and prohibited_ops both contain the same
        identifier, prohibited_ops takes precedence.

     validity_start_utc, validity_end_utc:
        ISO 8601 [ISO8601] timestamps in UTC defining the closed time
        interval during which the PAIT-ID is valid.  Implementations
        MUST reject PAIT-IDs whose current verification time falls
        outside this interval and MUST assign the minimum
        authorization level (defined as the lowest-privilege level in
        the implementation's level set, typically L2) to the requesting
        Agent.

     signature.alg:
        An identifier for the digital signature algorithm used.  This
        document defines two values: "ES256" (ECDSA on curve P-256, per
        [RFC7518] Section 3.4) and "EdDSA" (Edwards-curve DSA, per
        [RFC8037]).

     signature.kid:
        An opaque key identifier referencing the public key against
        which signature.value is verified.  The mapping from kid to
        public key material is out of scope for this document.

     signature.value:
        The base64url-encoded signature, computed as described in
        Section 4.1.

  4.3.  Authorization Levels

     This document defines three baseline authorization levels:

     *  L0 (full):  Highest privilege.  Grants the requesting Agent



  Vasylenko                Expires 17 November 2026               [Page 8]

  Internet-Draft                    PAIT                       16 May 2026


        access to the full training corpus available to the Generative
        AI Endpoint and to all computational layers of the underlying
        model.  L0 Agents MAY act as Delegating Agents (Section 4.5).

     *  L1 (verified):  Intermediate privilege.  Grants the requesting
        Agent access to a subset of the training corpus restricted to
        segments bearing open licenses (e.g., CC0, CC BY 4.0,
        Apache 2.0) and to a subset of the computational layers of the
        underlying model.

     *  L2 (public):  Minimum privilege.  Grants the requesting Agent
        access to the public subset of the training corpus (e.g.,
        segments bearing CC0 or Public Domain) and to a restricted
        subset of computational layers.

     The mapping from auth_level to specific corpus subset and to
     specific computational-layer subset is implementation-specific.
     PAIT requires only that the mapping be deterministic and that L0 ⊇
     L1 ⊇ L2 with respect to accessible corpus and layers.

  4.4.  Signature Algorithms

     Implementations MUST support at least one of "ES256" and "EdDSA".
     Implementations SHOULD support both.  Additional algorithms MAY be
     registered via the IANA registry defined in Section 9.

  4.5.  Delegation

     An Agent of authorization level L0 MAY issue PAIT-IDs for Agents
     of lower authorization level (L1 or L2).  A delegated PAIT-ID:

     *  MUST be signed by the Delegating Agent;

     *  MUST contain an allowed_ops value that is a subset of the
        Delegating Agent's own allowed_ops;

     *  MUST have a validity_end_utc not later than the validity_end_utc
        of the Delegating Agent's PAIT-ID;

     *  inherits access only to the corpus subset and layer subset of
        its own (lower) auth_level, regardless of the corpus and layer
        subset accessible to the Delegating Agent.

  5.  Provenance Manifest Record Format (PAIT-PM)

  5.1.  Record Structure

     A PAIT-PM record is emitted by the Generative AI Endpoint for each



  Vasylenko                Expires 17 November 2026               [Page 9]

  Internet-Draft                    PAIT                       16 May 2026


     Inference Session and is transmitted to the requesting Agent
     together with the output sequence.  A PAIT-PM record is encoded as
     a JSON Lines [JSONL] document in which each line corresponds to
     exactly one output token of the Inference Session.

     The first line of a PAIT-PM record MUST be a header object with
     the following fields:

     {
       "type":            "pait-pm-header",
       "protocol_version":"1.0",
       "session_id":      "<UUID>",
       "agent_id":        "<UUID>",  // gai from PAIT-ID
       "start_utc":       "<ISO 8601 timestamp>",
       "model_id":        "<endpoint-specific identifier>",
       "prev_session_hash":"<base64url-encoded SHA-256 digest>"
     }

                    Figure 3: PAIT-PM header object structure

     Each subsequent line is a per-token record (Section 5.2).

  5.2.  Per-Token Fields

     {
       "type":            "pait-pm-token",
       "token_idx":       <integer>,
       "token_repr":      "<opaque endpoint-specific representation>",
       "attribution":     [
         {
           "segment_id":  "<segment identifier>",
           "weight":      <number in [0,1]>,
           "license":     "<license class string>"
         },
         ...
       ],
       "license_purity":  <number in [0,1]>
     }

                  Figure 4: PAIT-PM per-token record structure

     Field semantics:

     token_idx:
        Zero-based index of the token within the output sequence.

     token_repr:
        An opaque representation of the output token in the
        endpoint-specific tokenizer.  PAIT does not constrain this



  Vasylenko                Expires 17 November 2026              [Page 10]

  Internet-Draft                    PAIT                       16 May 2026


        representation.

     attribution:
        A JSON array of attribution entries.  Each entry references a
        training-corpus segment that contributed to the generation of
        this token.  The weight field denotes the relative contribution
        of the referenced segment.  The sum of weight values across all
        entries SHOULD be 1.0 (within rounding tolerance), unless the
        attribution vector has been renormalized after filtering.
        The license field denotes the license class associated with the
        referenced segment.

     license_purity:
        A scalar in the closed interval [0,1] denoting an aggregate
        indicator of license-compatible attribution for this token.
        The method by which license_purity is computed is out of scope
        for this document.

     The final line of a PAIT-PM record MUST be a footer object:

     {
       "type":             "pait-pm-footer",
       "session_id":       "<UUID>",
       "token_count":      <integer>,
       "end_utc":          "<ISO 8601 timestamp>",
       "manifest_hash":    "<base64url-encoded SHA-256 digest>"
     }

                  Figure 5: PAIT-PM footer object structure

     The manifest_hash is computed by an implementation-defined
     deterministic function over the canonical representation of the
     header object and all per-token records, in order.  The hash
     function MUST be SHA-256 [RFC6234] or stronger.  Implementations
     MUST ensure identical output for identical input.

  6.  Trust Telemetry Signal Format (PAIT-TS)

     A PAIT-TS signal is emitted by the Generative AI Endpoint to an
     external monitoring endpoint upon completion of an Inference
     Session, or upon detection of an anomalous condition during a
     session.

     A PAIT-TS signal is a JSON object transmitted over HTTPS to a
     pre-configured REST endpoint:

     {
       "type":               "pait-ts-signal",
       "protocol_version":   "1.0",
       "session_id":         "<UUID>",



  Vasylenko                Expires 17 November 2026              [Page 11]

  Internet-Draft                    PAIT                       16 May 2026


       "agent_id":           "<UUID>",
       "auth_level":         "<L0|L1|L2>",
       "token_count":        <integer>,
       "license_distribution":{
         "<license class>":  <number in [0,1]>,
         ...
       },
       "high_trust_fraction":<number in [0,1]>,
       "timestamp_utc":      "<ISO 8601 timestamp>",
       "signal_mode":        "<batch|out_of_order>",
       "anomaly_flag":       <boolean>,
       "endpoint_signature": {
         "alg":   "<ES256|EdDSA>",
         "kid":   "<key identifier>",
         "value": "<base64url-encoded signature>"
       }
     }

                    Figure 6: PAIT-TS signal structure

     Implementations MUST transmit PAIT-TS signals over a confidential
     and integrity-protected channel.  TLS 1.3 [RFC8446] is REQUIRED.

     Implementations MUST support two transmission modes:

     *  batch: aggregated signals transmitted at a configured interval,
        not less frequent than once per 24 hours;

     *  out_of_order: immediate transmission upon detection of an
        anomalous condition.  The conditions classified as anomalous
        and the corresponding thresholds are out of scope for this
        document.  When signal_mode is "out_of_order", anomaly_flag
        MUST be set to true.

  7.  Wire Protocol State Machine

     The PAIT protocol state machine governs the interaction between
     the requesting Agent and the Generative AI Endpoint.  Nine states
     are defined:

     S0 (Idle):
        The Endpoint awaits an inference request.

     S1 (Request Received):
        The Endpoint has received an inference request containing a
        PAIT-ID.  Transitions to S2.

     S2 (Identity Verifying):



  Vasylenko                Expires 17 November 2026              [Page 12]

  Internet-Draft                    PAIT                       16 May 2026


        The Endpoint verifies the PAIT-ID:

        *  validates protocol_version;

        *  validates that the current verification time is within
           [validity_start_utc, validity_end_utc];

        *  retrieves the public key identified by signature.kid;

        *  verifies signature.value against the canonicalized
           serialization of preceding fields using signature.alg.

        On verification failure (any of: absent PAIT-ID, invalid
        signature, expired validity period, unrecognized
        protocol_version), the Endpoint MUST assign the minimum
        authorization level (typically L2) to the requesting Agent and
        transition to S3.  On verification success, the Endpoint
        transitions to S3 with the verified auth_level.

     S3 (Inference Routing):
        The Endpoint selects:

        *  the subset of the training corpus accessible at the verified
           auth_level;

        *  the subset of computational layers accessible at the verified
           auth_level;

        *  the processing mode for the inference request.

        The Endpoint transitions to S4.

     S4 (Generation):
        The Endpoint generates the output sequence.  For each output
        token, the Endpoint computes attribution data as defined by the
        Endpoint's internal attribution method (out of scope for this
        document) and appends a per-token PAIT-PM record to the session
        manifest.  The Endpoint transitions to S5 after the final token
        of the sequence has been generated.

     S5 (Manifest Sealing):
        The Endpoint emits the PAIT-PM footer (Section 5.2), computes
        the manifest_hash over the entire manifest, and seals the
        manifest.  The Endpoint transitions to S6.

     S6 (Registry Append):
        The Endpoint writes a new record of session-completion type to
        its immutable cryptographic provenance registry.  The new



  Vasylenko                Expires 17 November 2026              [Page 13]

  Internet-Draft                    PAIT                       16 May 2026


        record incorporates the SHA-256 hash of the immediately
        preceding registry record into its prev_hash field.  The
        Endpoint transitions to S7.

     S7 (Response Transmission):
        The Endpoint transmits the output sequence and the sealed
        PAIT-PM record to the requesting Agent.  The Endpoint
        transitions to S8.

     S8 (Telemetry Emission):
        The Endpoint emits a PAIT-TS signal (Section 6) to the
        configured external monitoring endpoint.  If an anomalous
        condition was detected during S4, the Endpoint MUST emit the
        PAIT-TS signal in "out_of_order" mode with anomaly_flag set to
        true; otherwise, the Endpoint MAY defer emission to a
        subsequent batch.  After emission (or deferral), the Endpoint
        transitions back to S0.

     The state machine guarantees that no PAIT-PM record may be
     transmitted to a requesting Agent without prior identity
     verification (S2) and prior registry append (S6).

  8.  Security Considerations

     This section addresses the principal security considerations
     applicable to PAIT.

     Identity verification.  The integrity of the PAIT protocol
     depends critically on the cryptographic verification of PAIT-IDs
     in state S2.  Implementations MUST:

     *  reject PAIT-IDs with invalid signatures;

     *  reject PAIT-IDs whose verification time falls outside the
        [validity_start_utc, validity_end_utc] interval;

     *  assign the minimum authorization level in any case of
        verification failure.

     Replay protection.  PAIT-IDs are time-bounded by the validity
     period.  Implementations SHOULD additionally maintain a record
     of recently observed PAIT-IDs (identified by signature.value) and
     reject duplicates received within a configurable window, to
     defend against replay attacks within an otherwise valid
     validity period.

     Confidentiality.  PAIT-ID, PAIT-PM, and PAIT-TS objects may
     contain information that the requesting Agent or the operator



  Vasylenko                Expires 17 November 2026              [Page 14]

  Internet-Draft                    PAIT                       16 May 2026


     considers sensitive.  Implementations MUST transport PAIT objects
     over a confidentiality- and integrity-protected channel.  TLS 1.3
     [RFC8446] is REQUIRED.

     Key management.  The mapping from signature.kid to public key
     material is out of scope for this document.  Implementations
     SHOULD use established key-distribution mechanisms such as JWKS
     [RFC7517] or DNS-based key discovery.

     Registry integrity.  The cryptographic hash chain of the
     immutable provenance registry provides tamper-evident integrity:
     modification of any registry record causes a mismatch of the
     record_hash and of prev_hash in all subsequent records.
     Implementations MUST store the registry in append-only mode.
     Implementations SHOULD provide a read-only audit interface for
     external verification.

     Trust telemetry endpoint authentication.  The Endpoint emitting
     PAIT-TS signals MUST authenticate the external monitoring
     endpoint to which signals are transmitted, e.g., via mutual TLS,
     to prevent diversion of telemetry to an attacker-controlled
     endpoint.  PAIT-TS signals MUST be signed by the Endpoint using
     endpoint_signature (Section 6).

     Privacy.  Implementations MUST consider that token_idx,
     attribution, and timestamp fields collectively may permit
     inference of user query content.  Implementations SHOULD
     evaluate compatibility with applicable privacy frameworks
     (e.g., [GDPR]) prior to deployment.

     Compatibility with self-prior-art exclusions.  This protocol
     specifies wire formats and state-machine behavior only.
     Algorithmic methods for attribution-vector computation, trust-
     coefficient determination, and routing-decision logic are
     intentionally out of scope, as described in Section 1.3.

  9.  IANA Considerations

     This document requests IANA to create three new registries under
     the "PAIT Parameters" registry group:

     PAIT-ID Signature Algorithms registry:
        Initial values:
        *  "ES256" (ECDSA on curve P-256, per [RFC7518] Section 3.4)
        *  "EdDSA" (Edwards-curve DSA, per [RFC8037])
        Registration policy: Specification Required [RFC8126].

     PAIT-ID Authorization Levels registry:



  Vasylenko                Expires 17 November 2026              [Page 15]

  Internet-Draft                    PAIT                       16 May 2026


        Initial values:
        *  "L0" (full)
        *  "L1" (verified)
        *  "L2" (public)
        Registration policy: Specification Required [RFC8126].

     PAIT Protocol Versions registry:
        Initial value:
        *  "1.0" (this document)
        Registration policy: Standards Action [RFC8126].

  10. Intellectual Property Rights

     The technology described in this document is the subject of an
     international patent application, PCT/IB2026/053131 (priority date
     25 March 2026, 19 claims, International Searching Authority:
     European Patent Office).  The patent holder is willing to grant
     a license for any standards-essential patent claims under fair,
     reasonable, and non-discriminatory (FRAND) terms with reciprocity.
     A formal IPR disclosure has been filed with the IETF.  See the
     IETF IPR disclosure record for the current declaration.

  11. References

  11.1.  Normative References

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

     [RFC4122]    Leach, P., Mealling, M., and R. Salz, "A Universally
                  Unique IDentifier (UUID) URN Namespace", RFC 4122,
                  July 2005,
                  <https://www.rfc-editor.org/info/rfc4122>.

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

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

     [RFC7518]    Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,



  Vasylenko                Expires 17 November 2026              [Page 16]

  Internet-Draft                    PAIT                       16 May 2026


                  May 2015,
                  <https://www.rfc-editor.org/info/rfc7518>.

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

     [RFC8126]    Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                  Writing an IANA Considerations Section in RFCs",
                  BCP 26, RFC 8126, 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, May 2017,
                  <https://www.rfc-editor.org/info/rfc8174>.

     [RFC8446]    Rescorla, E., "The Transport Layer Security (TLS)
                  Protocol Version 1.3", RFC 8446, August 2018,
                  <https://www.rfc-editor.org/info/rfc8446>.

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

     [ISO8601]    International Organization for Standardization,
                  "Date and time -- Representations for information
                  interchange -- Part 1: Basic rules",
                  ISO 8601-1:2019, February 2019.

  11.2.  Informative References

     [C2PA]       Coalition for Content Provenance and Authenticity,
                  "C2PA Technical Specification, Version 2.2",
                  Joint Development Foundation, May 2025,
                  <https://c2pa.org/specifications/specifications/2.2/
                  specs/C2PA_Specification.html>.

     [W3C-PROV-DM]
                  Moreau, L. and P. Missier, Eds., "PROV-DM: The PROV
                  Data Model", W3C Recommendation, 30 April 2013,
                  <https://www.w3.org/TR/prov-dm/>.

     [EU-AI-ACT]  European Parliament and Council, "Regulation (EU)
                  2024/1689 of the European Parliament and of the
                  Council of 13 June 2024 laying down harmonised rules
                  on artificial intelligence (Artificial Intelligence
                  Act)", Official Journal of the European Union,



  Vasylenko                Expires 17 November 2026              [Page 17]

  Internet-Draft                    PAIT                       16 May 2026


                  July 2024,
                  <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

     [GDPR]       European Parliament and Council, "Regulation (EU)
                  2016/679 of the European Parliament and of the
                  Council of 27 April 2016 on the protection of
                  natural persons with regard to the processing of
                  personal data (General Data Protection Regulation)",
                  Official Journal of the European Union, April 2016,
                  <https://eur-lex.europa.eu/eli/reg/2016/679/oj>.

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

     [JSONL]      "JSON Lines", <https://jsonlines.org/>.

     [ITU-T-X-LLMP-TIP]
                  Vasylenko, O., "Proposed new work item X.llmp-tip:
                  LLM token-level inference provenance", ITU-T SG17
                  Contribution T25-SG17-C-0461, 15 May 2026,
                  <https://www.itu.int/md/T25-SG17-C-0461/>.

  Appendix A.  Relationship to ITU-T Work Items

     This protocol specification is a companion document to ITU-T
     SG17 Contribution C-0461 (X.llmp-tip), which establishes the
     requirements framework for token-level LLM provenance within
     the ITU-T standardization process.

     The requirements in X.llmp-tip operate at the conceptual level.
     This IETF Internet-Draft provides a protocol-level realization,
     defining wire formats, message structures, and state transitions.

     The two documents are intended for parallel development:
     X.llmp-tip within ITU-T SG17 (security and trust requirements)
     and this draft within the IETF (protocol specification).

     Related ITU-T contributions from the same contributor:

        C-0456 (X.gaiv):  Globally interoperable agent identity
           verification.

        C-0457 (X.aaid):  Agent authentication and identity
           delegation.

        C-0458 (X.rcae):  Regulatory continuous attestation engine
           for AI agents.

        C-0459 (X.atcp):  Agent trust confidence primitives.

        C-0460 (X.aam):  AI accountability manifest.

     These six contributions together define the Agentic Trust
     Control Plane architecture within ITU-T SG17.


  Author's Address

     Oleh Vasylenko
     InterAlliance OU
     Tallinn
     Estonia

     Email: oleg@vasylenko.tel




















  Vasylenko                Expires 17 November 2026              [Page 18]


name: draft-morrison-compute-location-gate
rev: 00
time: 2026-05-21T10:15:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-22T10:15:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "AI safety/alignment"]
tags: []
fetched_at: 2026-05-22T09:24:52.066026+00:00
source: ietf
title:
  The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes

abstract:
  This memo specifies the compute-location gate: a mechanism by which a
     client and an identity-inference server negotiate, at the wire layer
     and before any inference is performed, the location at which an
     identity inference will compute, as a deterministic function of the
     provenance class of the input signal.  Three provenance classes are
     distinguished.  Active inference, initiated by the inferred-about
     principal, MAY compute server-side and produce a server-held identity
     vector.  Passive aggregate observation over a cohort no smaller than
     a declared minimum MAY compute server-side but yields only a
     population-level observation that is not attributable to an
     individual.  Passive individual observation is local-only: it is
     computed and retained on the device that observed it and is never
     transmitted to a server.  The gate is enforced by consent-class
     matching and by a wire-layer refusal returned when a requested
     provenance class is not consented; it is not enforced by any
     cryptographic proof concerning data that was not used.  The memo is
     Informational.  The wire surface composes with the discovery
     mechanism of [MCPDNS], the handle namespace of [IDPRONOUNS], and the
     organisational policy substrate of [POLICYPROV]; no new transport is
     introduced.

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


      The Compute-Location Gate: Provenance-Class Routing of Identity
    Inference with Wire-Layer Refusal of Unconsented Provenance Classes
                  draft-morrison-compute-location-gate-00

  Abstract

     This memo specifies the compute-location gate: a mechanism by which a
     client and an identity-inference server negotiate, at the wire layer
     and before any inference is performed, the location at which an
     identity inference will compute, as a deterministic function of the
     provenance class of the input signal.  Three provenance classes are
     distinguished.  Active inference, initiated by the inferred-about
     principal, MAY compute server-side and produce a server-held identity
     vector.  Passive aggregate observation over a cohort no smaller than
     a declared minimum MAY compute server-side but yields only a
     population-level observation that is not attributable to an
     individual.  Passive individual observation is local-only: it is
     computed and retained on the device that observed it and is never
     transmitted to a server.  The gate is enforced by consent-class
     matching and by a wire-layer refusal returned when a requested
     provenance class is not consented; it is not enforced by any
     cryptographic proof concerning data that was not used.  The memo is
     Informational.  The wire surface composes with the discovery
     mechanism of [MCPDNS], the handle namespace of [IDPRONOUNS], and the
     organisational policy substrate of [POLICYPROV]; no new transport is
     introduced.

  Status of This Memo

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

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

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




  Morrison                Expires 22 November 2026                [Page 1]


  Internet-Draft            Compute-Location Gate                 May 2026


     This Internet-Draft will expire on 2 November 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     4.  Provenance Classes  . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Active Inference  . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Passive Aggregate Observation . . . . . . . . . . . . . .   6
       4.3.  Passive Individual Observation  . . . . . . . . . . . . .   6
     5.  The Device-Local Daemon . . . . . . . . . . . . . . . . . . .   7
     6.  The Cohort Floor  . . . . . . . . . . . . . . . . . . . . . .   8
     7.  Wire-Layer Negotiation  . . . . . . . . . . . . . . . . . . .   8
       7.1.  The Inference Request . . . . . . . . . . . . . . . . . .   9
       7.2.  The Negotiation Response  . . . . . . . . . . . . . . . .   9
     8.  Consent-Class Matching  . . . . . . . . . . . . . . . . . . .  10
       8.1.  Provenance Class Is Distinct from Trait Category  . . . .  10
       8.2.  The Consent Class . . . . . . . . . . . . . . . . . . . .  11
       8.3.  The Wire-Layer Refusal  . . . . . . . . . . . . . . . . .  11
     9.  Routing and Compute-Location Selection  . . . . . . . . . . .  12
       9.1.  Active Class to Server-Side . . . . . . . . . . . . . . .  12
       9.2.  Passive Aggregate Class to Server-Side, Population-Level
             Output  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       9.3.  Passive Individual Class to Device-Local  . . . . . . . .  13
     10. Audit and Build-Time Verification . . . . . . . . . . . . . .  13
       10.1.  Per-Event Audit Record . . . . . . . . . . . . . . . . .  13
       10.2.  Build-Time Data-Flow Verification  . . . . . . . . . . .  14
     11. Relation to Prior Art . . . . . . . . . . . . . . . . . . . .  14
     12. Scope Boundary: What This Memo Does Not Specify . . . . . . .  15
     13. Implementation Status . . . . . . . . . . . . . . . . . . . .  16
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     15. Security Considerations . . . . . . . . . . . . . . . . . . .  17
       15.1.  Provenance-Class Misassertion  . . . . . . . . . . . . .  17
       15.2.  Cohort-Floor Evasion . . . . . . . . . . . . . . . . . .  17
       15.3.  Redirect Suppression . . . . . . . . . . . . . . . . . .  18
       15.4.  Device-Local Daemon Compromise . . . . . . . . . . . . .  18



  Morrison                Expires 22 November 2026                [Page 2]


  Internet-Draft            Compute-Location Gate                 May 2026


       15.5.  Audit-Log Integrity  . . . . . . . . . . . . . . . . . .  18
     16. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
       16.1.  Provenance Class as a Consent Boundary . . . . . . . . .  19
       16.2.  Local-Only Retention of Passive Individual Inference . .  19
       16.3.  Third-Party Stream Inference . . . . . . . . . . . . . .  19
       16.4.  Regulatory Context . . . . . . . . . . . . . . . . . . .  20
     17. Relation to Companion Memos . . . . . . . . . . . . . . . . .  20
     18. Document History  . . . . . . . . . . . . . . . . . . . . . .  21
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       19.1.  Normative References . . . . . . . . . . . . . . . . . .  21
       19.2.  Informative References . . . . . . . . . . . . . . . . .  22
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Status of This Memo

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

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

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

  2.  Introduction

     An identity-inference system derives statements about a principal
     (traits, competencies, dispositions, belonging measures) from signals
     the principal emits.  Such systems face a question that access
     control alone does not answer: _who may read_ a derived statement,
     and _where the derivation itself is permitted to compute_.

     These are distinct questions.  Access control governs the read path
     of a datum that already exists.  The compute-location question
     governs whether the datum may be brought into existence on a given
     machine at all.  A system that answers only the first question can
     decline to serve an inferred trait to an unauthorised reader, but it
     has, by the time of that refusal, already computed and persisted the
     trait on its server.  The compute-location question, asked earlier,
     prevents the server-side derivation from occurring when the signal's
     provenance does not warrant it.





  Morrison                Expires 22 November 2026                [Page 3]


  Internet-Draft            Compute-Location Gate                 May 2026


     This memo specifies a mechanism, the compute-location gate, that
     answers the second question at the wire layer.  Before an inference
     is performed, the client and the server negotiate the _provenance
     class_ of the input signal.  The provenance class deterministically
     selects a _compute location_.  Where the negotiated provenance class
     is not covered by the principal's consent, the server returns a wire-
     layer refusal, and no inference is performed at any location.

     The mechanism rests on a principle the present author has elsewhere
     termed identity-as-inference: that a principal's identity is inferred
     from manifestation rather than declared, and that every such
     inference is admissible only under an explicit gate on the provenance
     of the signal from which it is drawn.  The first clause of that
     principle is: no inference without a compute-location gate.  This
     memo is the wire-layer codification of that clause.

     The mechanism is deliberately narrow.  It specifies provenance-class
     negotiation, the routing function from provenance class to compute
     location, the consent-class match, and the refusal returned on a
     consent miss.  It does NOT specify, and explicitly excludes from its
     scope (Section 11), any cryptographic proof that a particular data
     category was excluded from a derivation.  The gate's enforcement
     model is consent-class matching plus wire-layer rejection.
     Verification that the gate held is addressed by build-time pipeline
     checks (Section 8) and by post-hoc audit, not by a cryptographic
     attestation of absence.

     The wire surface composes with four Morrison-family Internet-Drafts:
     the discovery surface of [MCPDNS], the handle namespace of
     [IDPRONOUNS], the cross-session coordination posture of [SUBSTRATE],
     and the organisational policy substrate of [POLICYPROV].  No new
     transport, no new handle category, and no new discovery record is
     introduced.

  3.  Conventions and Definitions

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

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

     Identity inference  A computation that derives a statement about a



  Morrison                Expires 22 November 2026                [Page 4]


  Internet-Draft            Compute-Location Gate                 May 2026


        principal (a trait value, a competency estimate, a disposition, a
        belonging measure, or a comparable derived attribute) from one or
        more signals the principal has emitted.

     Provenance class  A property of an input signal, established before
        inference, that records how the signal came to be observed.  Three
        provenance classes are defined in Section 3.

     Compute location  The machine class on which an identity inference is
        permitted to execute.  Two compute locations are distinguished:
        server-side, on infrastructure operated by the inference service;
        and device-local, on the device that observed the input signal.

     Server-held identity vector  A persisted, server-side representation
        of a principal's inferred identity, readable through the inference
        service's consented query surface.  Only inference of the active
        provenance class (Section 3.1) may write to the server-held
        identity vector.

     Device-local daemon  A long-running process executing on a device
        under the principal's control, on which device-local inference
        (Section 3.3) is computed and where the resulting representation
        is retained.  The device-local daemon does not transmit
        individual-attributable derived statements to a server.

     Cohort floor  The minimum cohort size, declared by the inference
        service, below which a passive aggregate inference (Section 3.2)
        MUST NOT be computed.  The cohort floor exists so that a
        population-level observation cannot be narrowed to an individual.

     Consent class  A unit of consent granted by a principal, keyed to a
        provenance class and a signal stream.  A consent class is the
        grant against which a negotiated provenance class is matched
        (Section 6).

     Wire-layer refusal  A typed response returned by the inference
        service, before any inference is performed, when a requested
        provenance class is not covered by a consent class.  The refusal
        terminates the inference request; no inference is performed at any
        compute location.

     ~handle  A principal identity handle as defined by [IDPRONOUNS].









  Morrison                Expires 22 November 2026                [Page 5]


  Internet-Draft            Compute-Location Gate                 May 2026


  4.  Provenance Classes

     Every input signal admitted to an identity inference carries exactly
     one of three provenance classes.  The provenance class is established
     before inference and is immutable for the lifetime of the signal
     record.  The provenance class, not the signal's content and not the
     trait category of the prospective output, is the value on which the
     compute-location gate routes.

  4.1.  Active Inference

     An input signal is of the active provenance class when the inferred-
     about principal initiated the act that produced it.  Challenge-
     response exchanges, a consented structured assessment, an explicit
     attestation the principal authored, and inputs the principal supplied
     to a deliberate identity-elaboration flow are all of the active
     class.  The defining property is principal initiation: the principal
     performed an act whose purpose, as understood by the principal at the
     time of the act, was to contribute signal to their own identity
     inference.

     An inference drawn solely from active-class signal MAY compute
     server-side and MAY write to the server-held identity vector
     (Section 7.1).

  4.2.  Passive Aggregate Observation

     An input signal is of the passive aggregate provenance class when it
     was observed without a principal-initiated act, and when the
     inference drawn from it is computed over a cohort of principals no
     smaller than the cohort floor (Section 5) and yields only a
     population-level observation.  A passive aggregate inference produces
     a statement about the cohort (a distribution, a rate, a population
     parameter) and does not produce a statement attributable to any
     individual within the cohort.

     An inference of the passive aggregate class MAY compute server-side
     (Section 7.2).  Its output is a population-level observation; it MUST
     NOT write an individual-attributable statement to the server-held
     identity vector.

  4.3.  Passive Individual Observation

     An input signal is of the passive individual provenance class when it
     was observed without a principal-initiated act and the inference
     drawn from it would yield a statement attributable to a single
     principal.




  Morrison                Expires 22 November 2026                [Page 6]


  Internet-Draft            Compute-Location Gate                 May 2026


     An inference of the passive individual class is local-only.  It MUST
     be computed on the device-local daemon (Section 4) running on the
     device that observed the input signal, and the resulting derived
     statement MUST be retained on that device.  An individual-
     attributable statement of the passive individual provenance class
     MUST NOT be transmitted to a server, and MUST NOT, by any derivation
     path, reach the server-held identity vector.

     The passive individual class is the load-bearing constraint of this
     memo.  The other two classes describe what server-side inference MAY
     do; this class describes what server-side inference MUST NOT do.  A
     system that routes passive individual observation to server-side
     compute has not implemented the compute-location gate, irrespective
     of any access control it applies to the resulting datum afterward.

  5.  The Device-Local Daemon

     Inference of the passive individual provenance class is computed on a
     device-local daemon.  The device-local daemon is a process under the
     principal's control, executing on the device that observed the input
     signal.

     The device-local daemon:

     1.  Receives passive individual signal observed on its host device.

     2.  Computes the identity inference locally.  No input signal of the
         passive individual class, and no statement derived from it,
         leaves the device for the purpose of the inference.

     3.  Retains the derived statement in device-local storage under the
         principal's control.

     4.  Exposes the derived statement to the principal, and only to the
         principal, through a device-local interface.  The principal MAY,
         by a subsequent active-class act, elect to contribute a derived
         statement to a server-held inference; such an act re-enters the
         pipeline as active-class signal (Section 3.1) and is gated
         afresh.

     The device-local daemon MUST NOT expose an interface by which a
     server, or any party other than the principal operating the device,
     can read an individual-attributable statement of the passive
     individual class.  The transition of a passive-individual-derived
     statement to server-side visibility occurs only through a fresh
     active-class act by the principal, never through a daemon-exposed
     read surface.




  Morrison                Expires 22 November 2026                [Page 7]


  Internet-Draft            Compute-Location Gate                 May 2026


     The device-local daemon participates in the substrate-observation
     posture of [SUBSTRATE] for the purpose of cross-session coordination
     of the principal's surfaces; that participation is orthogonal to the
     present memo and introduces no path by which passive individual
     derived statements reach a server.

  6.  The Cohort Floor

     A passive aggregate inference (Section 3.2) MUST NOT be computed
     unless the cohort over which it is computed is no smaller than the
     cohort floor.  The cohort floor is a positive integer declared by the
     inference service and exposed at the negotiation surface (Section 6)
     so that a client can determine, before requesting an inference,
     whether a passive aggregate request is admissible.

     The cohort floor exists to ensure that a passive aggregate inference
     yields a population-level observation and not an individual-
     attributable one.  An inference computed over a cohort smaller than
     the floor risks re-identification: with a sufficiently small cohort,
     a population parameter is a near-individual statement.  The floor is
     the structural boundary between the passive aggregate class, which
     MAY compute server-side, and the passive individual class, which MUST
     NOT.

     The cohort floor is a parameter of this mechanism, not a fixed
     constant of this memo.  An inference service SHALL declare its cohort
     floor and SHALL NOT compute a passive aggregate inference over a
     cohort below it.  A service whose declared cohort floor is so low
     that a population parameter computed at that size is individually
     identifying has not satisfied the intent of this section; the floor
     is a number, but a number chosen so that the resulting observation is
     genuinely population-level.  The reference deployment described in
     Section 12 declares a cohort floor of 1000.

     The cohort floor governs the _aggregate_ boundary only.  It is not a
     privacy budget, it is not a noise-calibration parameter, and it does
     not compose additively across queries.  The relationship of the
     cohort floor to the statistical-disclosure-control literature is
     discussed in Section 10.

  7.  Wire-Layer Negotiation

     Before an identity inference is performed, the client and the
     inference service negotiate the provenance class of the input signal
     and, by the routing function of Section 7, the compute location.  The
     negotiation is a request-response exchange carried over the client's
     existing transport to the inference service; this memo introduces no
     new transport.  Where the inference service is reached as a Model



  Morrison                Expires 22 November 2026                [Page 8]


  Internet-Draft            Compute-Location Gate                 May 2026


     Context Protocol [MCP] surface, the negotiation is a tool invocation
     and its response; where it is reached over another transport, the
     negotiation is the corresponding request-response pair.

  7.1.  The Inference Request

     A client requesting an identity inference SHALL include, in the
     request, an inference-negotiation object carrying at minimum the
     following fields.

     provenance_class (enum, REQUIRED)  One of active, passive-aggregate,
        passive-individual.  The provenance class the client asserts for
        the input signal of the prospective inference.

     signal_stream (string, REQUIRED)  A stable identifier for the stream
        from which the input signal is drawn.  Consent classes
        (Section 6.2) are keyed to the pair (provenance_class,
        signal_stream); the stream identifier is the second key.

     requested_output (string, REQUIRED)  An identifier for the category
        of derived statement the inference is to produce.  The requested
        output does not select the compute location (the provenance class
        does), but it is carried so that the consent match (Section 6) and
        the audit record (Section 9) can record what was requested.

     cohort_size (integer, OPTIONAL)  Present only when provenance_class
        is passive-aggregate.  The size of the cohort over which the
        aggregate inference is to be computed.  The service SHALL reject
        the request if cohort_size is below the declared cohort floor
        (Section 5).

     principal (string, OPTIONAL)  The ~handle of the inferred-about
        principal, present when the inference is attributable to a named
        principal.  Absent for a passive aggregate inference, which is by
        construction not attributable to an individual.

  7.2.  The Negotiation Response

     The inference service SHALL respond to an inference-negotiation
     request with one of three typed responses.

     accepted  The asserted provenance class is consented (Section 6), the
        routing function (Section 7) has selected a compute location, and
        the inference will proceed at that location.  The response carries
        the selected compute_location (server-side or device-local), so
        that the client and any audit observer record where the inference
        computed.




  Morrison                Expires 22 November 2026                [Page 9]


  Internet-Draft            Compute-Location Gate                 May 2026


     refused  The asserted provenance class is not covered by a consent
        class.  No inference is performed at any compute location.  The
        structure of the refusal is specified in Section 6.3.

     redirected  The asserted provenance class is consented, but the
        routing function has selected a compute location other than the
        one the client is positioned to satisfy.  The most common case is
        a client requesting a server-side inference on signal the service
        classifies as passive-individual: the service does not perform the
        inference server-side, and the response directs the client to
        perform the inference on the device-local daemon (Section 4).  A
        redirected A redirected response is not a refusal; the inference
        is admissible.  It is not a server-side acceptance either.

     The negotiation response, in every case, is returned _before_ any
     inference is performed.  An inference service MUST NOT compute an
     identity inference and then decide, from the result, whether to
     return it; the compute-location gate is evaluated on the negotiation
     object alone, ahead of the inference.

  8.  Consent-Class Matching

     The compute-location gate is enforced by consent-class matching.  The
     asserted provenance class of an inference request is matched against
     the consent classes the principal has granted; an inference proceeds
     only when a matching consent class is found.

  8.1.  Provenance Class Is Distinct from Trait Category

     A consent class is keyed to a provenance class and a signal stream,
     not to the category of the derived output.  A principal who has
     consented to active-class inference of a disposition has not thereby
     consented to passive-individual-class inference of the same
     disposition.  Consent granted for one provenance class does not
     generalise to another.  This is the defining property of provenance-
     class consent: the _how it was observed_ is consented separately from
     the _what is derived_.

     It follows that an inference service MUST carry the provenance class
     on every signal record and on every derived statement throughout its
     internal architecture, so that the consent match can be evaluated and
     so that the audit record (Section 9) can record the provenance class
     that was matched.  A derived statement that has lost its provenance
     class is not consent-checkable and MUST NOT be served.







  Morrison                Expires 22 November 2026               [Page 10]


  Internet-Draft            Compute-Location Gate                 May 2026


  8.2.  The Consent Class

     A consent class is a grant, authored by the principal, carrying at
     minimum:

     *  The provenance_class the grant covers.

     *  The signal_stream the grant covers.

     *  The set of requested_output categories the grant admits, or an
        explicit marker that the grant admits all output categories for
        the covered (provenance class, signal stream) pair.

     *  A revocation marker; consent classes are revocable, and a revoked
        consent class MUST NOT satisfy a subsequent match.

     A consent class for the passive-individual provenance class
     authorises device-local inference (Section 4) only.  No consent
     class, of any provenance class, authorises the transmission of an
     individual-attributable passive-individual derived statement to a
     server; that transmission is precluded by Section 3.3 and is not a
     grantable scope.

     Consent for inference from a third-party signal stream is a separate
     consent class from any authorisation the principal may have granted
     the third-party platform itself.  A principal's authorisation of a
     platform's data-access grant is not a consent class for ALTER-side or
     any inference-service-side inference from that platform's stream; the
     inference service SHALL require a distinct, separately revocable
     consent class, keyed to the (provenance_class, signal_stream) pair,
     before inferring from a third-party stream.

  8.3.  The Wire-Layer Refusal

     When the asserted provenance class of an inference request is not
     covered by a consent class, the inference service SHALL return a
     refused negotiation response.  The refusal carries at minimum:

     reason (enum, REQUIRED)  One of no-consent-class (no consent class
        covers the asserted provenance class and signal stream), consent-
        revoked (a consent class existed but has been revoked), cohort-
        floor (a passive-aggregate request carried a cohort_size below the
        declared floor), or provenance-not-routable (the asserted
        provenance class is not one the service admits for the requested
        output).

     provenance_class (enum, REQUIRED)  The provenance class that was




  Morrison                Expires 22 November 2026               [Page 11]


  Internet-Draft            Compute-Location Gate                 May 2026


        asserted and refused, echoed so that the client and audit observer
        record what was requested.

     explanation (string, REQUIRED)  A human-readable explanation,
        sufficient for the client's reasoning surface to present to the
        principal without a further round-trip.

     A refused response is terminal for the inference request.  The
     inference service MUST NOT, having returned a refusal, perform the
     refused inference at any compute location, and MUST NOT perform a
     substitute inference of a different provenance class without a fresh
     negotiation.  The refusal is a wire-layer event: it is observable to
     the client, it is recorded in the audit log (Section 9), and it
     occurs before any inference computation.

     The refusal model of this memo is consent-class matching plus wire-
     layer rejection.  It is not, and does not rely on, any cryptographic
     attestation that a refused signal was absent from a computation.  The
     refusal asserts that the inference was not performed; it does not
     produce a proof, verifiable without access to the underlying data,
     that a particular data category did not contribute to some other
     computation.  The boundary between the mechanism this memo specifies
     and the cryptographic-attestation question it does not address is
     stated in Section 11.

  9.  Routing and Compute-Location Selection

     The routing function maps a consented provenance class to a compute
     location.  The function is total over the three provenance classes
     and is deterministic: the same provenance class always selects the
     same compute location.

  9.1.  Active Class to Server-Side

     A consented inference of the active provenance class is routed to
     server-side compute.  Its output MAY be written to the server-held
     identity vector and MAY be served, subject to the inference service's
     ordinary read-path consent, through the service's consented query
     surface.  The principal initiated the act that produced the signal;
     server-side derivation and persistence is the routing outcome.











  Morrison                Expires 22 November 2026               [Page 12]


  Internet-Draft            Compute-Location Gate                 May 2026


  9.2.  Passive Aggregate Class to Server-Side, Population-Level Output

     A consented inference of the passive-aggregate provenance class,
     whose cohort_size is no smaller than the declared cohort floor, is
     routed to server-side compute.  Its output is a population-level
     observation.  The output MUST NOT be written to the server-held
     identity vector as an individual-attributable statement; the server-
     held identity vector is, by Section 3, the destination of active-
     class inference alone.  A passive aggregate output is a statement
     about the cohort, retained as such.

  9.3.  Passive Individual Class to Device-Local

     A consented inference of the passive-individual provenance class is
     routed to device-local compute on the device-local daemon
     (Section 4).  The inference service does not perform the inference.
     Where a client requests a server-side inference on signal the service
     classifies as passive-individual, the service returns a redirected
     negotiation response (Section 6) directing the client to the device-
     local daemon.

     The routing function has no branch by which a passive-individual
     inference computes server-side.  A server-side compute location is
     not a selectable outcome for the passive-individual provenance class
     under any consent configuration.  This is the structural property
     that distinguishes the compute-location gate from an access-control
     mechanism: access control could, in principle, be configured to admit
     a reader of a server-side passive-individual trait; the routing
     function of this section has no such configuration, because the trait
     is never computed server-side to be read.

  10.  Audit and Build-Time Verification

     The compute-location gate is verifiable in two complementary ways: by
     a per-event audit record written at negotiation time, and by a build-
     time check on the inference pipeline's data-flow.

  10.1.  Per-Event Audit Record

     Every negotiation, whether it resolves to accepted, refused, or
     redirected, SHALL produce an append-only audit record carrying at
     minimum: the asserted provenance_class; the signal_stream; the
     requested_output; the negotiation outcome; the selected
     compute_location where the outcome was accepted; the reason where the
     outcome was refused; an [RFC3339] timestamp; and the attribution of
     the requesting party.  The audit record is written to an append-only
     log; admitted records are not retractable or amendable.  Where the
     inference service is operated as, or alongside, an organisational



  Morrison                Expires 22 November 2026               [Page 13]


  Internet-Draft            Compute-Location Gate                 May 2026


     identity substrate, the audit record SHOULD be emitted to that
     substrate's audit-signal ingestion surface as specified by
     [POLICYPROV].

     The audit record makes the gate's operation observable after the
     fact: an auditor can determine, for any inference the service
     performed, what provenance class was asserted, what compute location
     was selected, and which consent class was matched.

  10.2.  Build-Time Data-Flow Verification

     In addition to the per-event audit record, an inference service
     SHOULD verify, at the time its inference pipeline is built, that the
     pipeline contains no data-flow path by which a signal of the passive-
     individual provenance class reaches the server-held identity vector.

     The verification treats the inference pipeline as a directed graph
     whose nodes are pipeline stages and whose edges are data-flow
     dependencies between stages.  The verification is the property: for
     every signal node of the passive-individual provenance class, and for
     every node representing a write to the server-held identity vector,
     there exists no directed path from the former to the latter.  A
     pipeline that fails this property has a route by which a device-
     local-only inference could reach the server, and the build SHOULD
     fail.

     This build-time verification is a check on the pipeline's structure,
     performed before the pipeline runs; it is independent of, and
     complementary to, the per-event audit record, which observes the
     pipeline's behaviour after each negotiation.  The combination of a
     structural check at build time and a behavioural record at run time
     is the verification model of the compute-location gate.  Neither
     component is a cryptographic proof, and the verification model does
     not depend on one; the boundary is stated in Section 11.

  11.  Relation to Prior Art

     The compute-location gate is structurally distinct from the prior-art
     families with which it is most likely to be confused.

     Differential privacy [DWORK] and the broader statistical-disclosure-
     control literature address the population-versus-individual boundary
     at the algorithmic layer: a query mechanism adds calibrated noise so
     that the presence or absence of any single record is statistically
     masked, and a privacy budget composes the guarantee across queries.
     The compute-location gate addresses a different boundary at a
     different layer.  The cohort floor of Section 5 is not a privacy
     budget: it does not compose additively across queries, and it



  Morrison                Expires 22 November 2026               [Page 14]


  Internet-Draft            Compute-Location Gate                 May 2026


     calibrates no noise.  It is a categorical admissibility threshold:
     below the floor, the passive aggregate class is simply not the
     applicable provenance class, and the inference is not computed
     server-side at all.  Differential privacy makes a server-side
     individual-sensitive computation safe to release; the compute-
     location gate routes the individual-attributable computation off the
     server entirely.  The two are composable: a passive aggregate
     inference admitted by the cohort floor MAY additionally apply
     differential privacy to its population-level output.  They are not
     substitutes.

     Decentralised personal-data architectures (Solid [SOLID] and
     comparable personal-data-store designs) move the _storage_ of
     personal data to a principal-controlled pod and govern the _read
     path_ through access control.  The compute-location gate governs the
     _compute path_: it determines where a derivation is permitted to run,
     not merely where its result is stored or who may read it.  A
     personal-data store can hold a passive-individual trait that was
     nonetheless computed server-side and copied to the pod; the compute-
     location gate precludes the server-side computation in the first
     place.  The two are complementary (a device-local daemon (Section 4)
     may use a personal-data store as its retention surface), but the
     gate's contribution is the routing of computation, which a storage-
     layer architecture does not address.

     Consent-management and access-control frameworks generally govern
     which parties may read which data.  The compute-location gate's
     consent classes (Section 6) govern, in addition, the provenance class
     under which an inference may be _brought into existence_.  A consent
     framework that admits a reader of a derived trait has not, by that
     admission, said anything about whether the trait may be derived
     server-side from passively observed individual signal; that is the
     question the provenance-class consent of this memo answers.

     The contribution of this memo is the wire-layer composition of the
     compute-path question with provenance-class consent: a negotiation,
     ahead of inference, that routes computation by provenance class and
     refuses at the wire layer when the provenance class is not consented.

  12.  Scope Boundary: What This Memo Does Not Specify

     This memo specifies the compute-location gate: provenance-class
     negotiation, the routing function, consent-class matching, and the
     wire-layer refusal.  It deliberately does not specify several
     adjacent mechanisms, and an implementer SHOULD NOT read the gate as
     providing them.





  Morrison                Expires 22 November 2026               [Page 15]


  Internet-Draft            Compute-Location Gate                 May 2026


     This memo does not specify a cryptographic proof, attestation, or
     guarantee that any specified data category, provenance class, or
     derivation pathway was excluded from a particular computation.  The
     gate's enforcement model is consent-class matching plus wire-layer
     rejection (Section 6) and its verification model is per-event audit
     plus build-time data-flow checking (Section 8).  A refusal under this
     memo asserts that an inference was not performed; it does not
     produce, and does not rely on, any object that proves (verifiably
     without access to the underlying data) that a data category did not
     contribute to some output.  Such a proof is a different mechanism,
     addressed by separate work, and is outside the scope of this
     specification.  An implementer requiring a cryptographic exclusion
     guarantee MUST NOT infer one from the audit record or the build-time
     check described here; neither is such a proof, and the compute-
     location gate does not become one by composition.

     This memo does not specify the internal inference algorithms, the
     trait taxonomy, the identity-vector representation, or the device-
     local daemon's storage format.  These are implementation matters of
     an inference service; the memo specifies only the wire surface at
     which compute location is negotiated.

     This memo does not specify a discovery mechanism, a transport, or a
     handle namespace.  It composes with [MCPDNS], the principal's
     existing transport, and [IDPRONOUNS] respectively.

  13.  Implementation Status

     A reference implementation of the compute-location gate is operated
     by the present author against a production identity-inference service
     reachable at the ~truealter.com substrate.  The reference deployment
     classifies input signals into the three provenance classes of
     Section 3, performs the negotiation of Section 6 ahead of inference,
     routes by the function of Section 7, returns the wire-layer refusal
     of Section 6.3 on a consent miss, declares a cohort floor of 1000 for
     passive aggregate inference, and runs the build-time data-flow
     verification of Section 8.2 as a gate on its inference-pipeline
     build.  The device-local daemon of Section 4 is the reference
     deployment's local-execution surface for passive individual
     inference.

     In the spirit of [RFC7942], the present author notes that this
     section documents implementation experience and is expected to be
     removed before the document advances beyond the Independent Stream.
     No claim of interoperability is made; the reference deployment is a
     single service operated by the specification's author.





  Morrison                Expires 22 November 2026               [Page 16]


  Internet-Draft            Compute-Location Gate                 May 2026


  14.  IANA Considerations

     This memo requests no IANA action.

     The negotiation field names and the negotiation-response type names
     used in Sections 6 and 7 are illustrative of the reference deployment
     described in Section 12.  Conforming inference services MAY name the
     corresponding fields and response types by any convention consistent
     with their transport's addressing primitive; the load-bearing
     contribution of this memo is the three-provenance-class routing
     function and the wire-layer refusal, not the field names.  No new DNS
     record types, transport identifiers, port numbers, URI schemes, or
     media types are introduced.

  15.  Security Considerations

     The compute-location gate concentrates an admissibility decision
     (where an identity inference may compute) at a wire-layer negotiation
     performed ahead of inference.  The following considerations arise.

  15.1.  Provenance-Class Misassertion

     A client may assert a provenance class that does not correspond to
     how the input signal was actually observed; for example, asserting
     the active class for a signal that was passively observed, so as to
     route an individual-attributable inference to server-side compute.
     The asserted provenance class is a claim, and the inference service
     MUST NOT treat it as self-certifying.  The service SHALL establish
     the provenance class from substrate it observes (the act that
     produced the signal, the stream the signal arrived on, the presence
     or absence of a principal-initiated trigger) and SHALL refuse a
     request whose asserted provenance class is inconsistent with the
     observed substrate.  A provenance class established from observed
     substrate, rather than accepted from a client assertion, is the
     integrity foundation of the gate.

  15.2.  Cohort-Floor Evasion

     An attacker may attempt to extract an individual-attributable
     statement through repeated passive aggregate queries whose cohorts
     overlap such that the difference between two near-identical cohorts
     isolates an individual.  The cohort floor of Section 5 bounds the
     size of any single cohort but does not, alone, bound a differencing
     attack across cohorts.  An inference service SHOULD additionally
     constrain the _composition_ of passive aggregate queries, for example
     by refusing aggregate queries whose cohorts differ by fewer than the
     cohort floor, and SHOULD record passive aggregate cohort definitions
     in the audit log (Section 9) so that a differencing pattern is



  Morrison                Expires 22 November 2026               [Page 17]


  Internet-Draft            Compute-Location Gate                 May 2026


     detectable post-hoc.

  15.3.  Redirect Suppression

     A redirected negotiation response (Section 6) directs a client to
     perform a passive-individual inference on the device-local daemon
     rather than server-side.  An attacker positioned between the client
     and the inference service might suppress or rewrite the redirected
     response so that the client believes a server-side inference is
     unavailable and abandons the inference, or believes a server-side
     inference occurred when it did not.  Negotiation responses SHOULD be
     carried over a channel authenticated by the cryptographic identity
     envelope of [MCPDNS], so that a consuming client can verify the
     response bears the inference service's declared signing key, and a
     suppressed or rewritten response is detectable.

  15.4.  Device-Local Daemon Compromise

     The device-local daemon (Section 4) holds passive-individual derived
     statements that, by Section 3.3, never reach a server.  Compromise of
     the device-local daemon exposes those statements.  The gate does not
     make the device-local daemon's storage secure (that is the device's
     responsibility), but it does ensure that the blast radius of a
     device-local compromise is confined to a single device's passive-
     individual derivations and does not extend to a server-held aggregate
     of many principals' passive-individual traits, because no such
     server-held aggregate exists.  The compute-location gate's routing is
     itself a blast-radius mitigation.

  15.5.  Audit-Log Integrity

     The per-event audit record (Section 9.1) is the after-the-fact
     evidence that the gate operated.  An attacker able to amend or delete
     audit records could conceal a server-side passive-individual
     inference.  The audit log MUST be append-only; admitted records MUST
     NOT be retractable or amendable by the inference service operator.
     Where the audit record is emitted to an organisational identity
     substrate per [POLICYPROV], the append-only property of that
     substrate's ingestion surface carries the integrity requirement.

  16.  Privacy Considerations

     The compute-location gate is, in its substance, a privacy mechanism;
     its routing function is a privacy decision.  The considerations of
     [RFC6973] apply, and three are operative here.






  Morrison                Expires 22 November 2026               [Page 18]


  Internet-Draft            Compute-Location Gate                 May 2026


  16.1.  Provenance Class as a Consent Boundary

     The gate's central privacy property is that consent is keyed to
     provenance class, not to trait category (Section 6.1).  A principal
     controls not merely _what_ is inferred about them but _from what
     manner of observation_.  A principal may consent to active-class
     inference of a disposition while withholding consent for passive-
     individual inference of the same disposition; the gate honours that
     distinction at the wire layer.  An inference service that collapses
     the distinction, treating consent for a trait category as consent for
     all provenance classes of that category, has not implemented the
     privacy property this memo specifies.

  16.2.  Local-Only Retention of Passive Individual Inference

     The passive individual provenance class is routed to device-local
     compute and device-local retention (Sections 3.3, 4, 7.3).  The
     privacy consequence is that the inference service holds no server-
     side, individual-attributable representation derived from passively
     observed individual signal.  A principal's passive individual
     derivations are, by construction, not present in the inference
     service's data holdings, not subject to the service's breach
     exposure, and not reachable by a server-side query however
     authorised.  The principal's later election to contribute such a
     derivation to a server-held inference is an active-class act
     (Section 4) and is independently consented.

  16.3.  Third-Party Stream Inference

     A principal's authorisation of a third-party platform's data-access
     grant is not consent for an inference service to infer identity
     statements from that platform's stream (Section 6.2).  Inference from
     a third-party stream requires a consent class distinct from, and
     separately revocable from, the platform authorisation.  This
     separation matters because a principal's mental model of a platform
     authorisation is "this platform may use my data on this platform",
     not "any inference service may derive identity traits from my
     behaviour on this platform".  The gate's consent classes make the
     second a separate, explicit, revocable grant.  Inference from a
     third-party stream conducted without such a separate consent class is
     a privacy violation that the gate is specifically structured to
     prevent.









  Morrison                Expires 22 November 2026               [Page 19]


  Internet-Draft            Compute-Location Gate                 May 2026


  16.4.  Regulatory Context

     The compute-location gate's routing of passive individual inference
     off the server is consistent with data-minimisation expectations
     under data-protection regimes generally, and with [GDPR] in
     particular: a derivation that is never computed server-side produces
     no server-side personal datum to minimise, retain, or erase.
     Implementers operating in jurisdictions that categorically prohibit
     certain inferences in certain contexts (for instance the prohibition
     under [EUAIACT] of emotion inference in workplace and education
     settings) should note that the compute-location gate is a routing-
     and-consent mechanism and does not itself satisfy a categorical
     prohibition: a categorical prohibition bites regardless of provenance
     class or compute location, and an inference service subject to one
     MUST refuse the prohibited inference outright rather than route it.
     The gate composes with a categorical refusal; it does not replace
     one.

  17.  Relation to Companion Memos

     This memo composes with four Morrison-family Internet-Drafts.

     [MCPDNS] supplies the DNS-based discovery surface by which a client
     locates an inference service, and the cryptographic identity envelope
     referenced in Section 13.3.  This memo introduces no new DNS records
     or labels.

     [IDPRONOUNS] supplies the ~handle namespace by which principals and
     substrates are named.  This memo introduces no new handle category.

     [SUBSTRATE] supplies the substrate-observation posture under which
     the device-local daemon (Section 4) coordinates with the principal's
     other sessions; that coordination introduces no path by which
     passive-individual derived statements reach a server.

     [POLICYPROV] supplies the organisational identity substrate to whose
     audit-signal ingestion surface the per-event audit record
     (Section 9.1) SHOULD be emitted.  An inference service operated
     alongside an organisational identity substrate inherits that
     substrate's append-only audit posture for the compute-location gate's
     audit trail.

     The compute-location gate is the wire-layer codification of the first
     clause of the identity-as-inference principle: no inference without a
     compute-location gate.  The companion memos codify adjacent clauses
     and surfaces of the same principle; this memo is the clause
     concerning where inference is permitted to compute.




  Morrison                Expires 22 November 2026               [Page 20]


  Internet-Draft            Compute-Location Gate                 May 2026


  18.  Document History

     draft-morrison-compute-location-gate-00 (May 2026):

     *  Initial submission.

     *  Defines the three provenance classes (active, passive aggregate,
        passive individual) and the immutability of a signal's provenance
        class.

     *  Specifies the device-local daemon as the compute location for
        passive individual inference.

     *  Specifies the cohort floor for passive aggregate inference.

     *  Specifies the wire-layer negotiation (inference request,
        negotiation response) performed ahead of inference.

     *  Specifies consent-class matching, the distinctness of provenance
        class from trait category, and the wire-layer refusal.

     *  Specifies the routing function from provenance class to compute
        location.

     *  Specifies the per-event audit record and the build-time data-flow
        verification.

     *  States the scope boundary excluding cryptographic exclusion
        guarantees from the specification.

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

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

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




  Morrison                Expires 22 November 2026               [Page 21]


  Internet-Draft            Compute-Location Gate                 May 2026


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

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

     [POLICYPROV]
                Morrison, B., "Policy Provision and Governance Inheritance
                from an Organisational Identity Substrate", 2026,
                <https://datatracker.ietf.org/doc/draft-morrison-org-
                alter-policy-provision/>.

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

  19.2.  Informative References

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

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

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

     [GDPR]     European Parliament and Council, "Regulation (EU) 2016/679
                (General Data Protection Regulation)", 2016.

     [EUAIACT]  European Parliament and Council, "Regulation (EU)
                2024/1689 Laying Down Harmonised Rules on Artificial
                Intelligence (Artificial Intelligence Act)", 2024.







  Morrison                Expires 22 November 2026               [Page 22]


  Internet-Draft            Compute-Location Gate                 May 2026


     [DWORK]    Dwork, C., McSherry, F., Nissim, K., and A. Smith,
                "Calibrating Noise to Sensitivity in Private Data
                Analysis", 2006, <https://www.iacr.org/archive/
                tcc2006/38760266/38760266.pdf>.

     [SOLID]    Sambra, A., Mansour, E., Hawke, S., Zereba, M., Capadisli,
                S., Ghanem, A., Aboulnaga, A., and T. Berners-Lee, "Solid:
                A Platform for Decentralized Social Applications Based on
                Linked Data", 2016,
                <https://dig.csail.mit.edu/2016/solid/>.

  Acknowledgements

     This memo grew out of internal architectural work on the question of
     how an identity-inference system should decide not merely who may
     read a derived trait, but where the derivation is permitted to
     compute.  The realisation that the compute-location question is prior
     to the access-control question: an access-control refusal arrives
     after the server has already computed and persisted the datum it
     declines to serve.  That observation is the load-bearing insight
     behind this specification.

  Author's Address

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























  Morrison                Expires 22 November 2026               [Page 23]


