# drafts

name: draft-berlinai-vera
rev: 00
title: VERA: Verifiable Enforcement for Runtime Agents
time: 2026-02-12T12:10:38Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T12:10:38Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.608574+00:00
source: ietf
abstract:
  AI agents take real actions with real data at machine speed.
     Compromised AI agents pose significant risks including data
     exfiltration, unauthorized financial transactions, and cascading
     failures across downstream systems.

     This document introduces VERA (Verifiable Enforcement for Runtime
     Agents), a zero trust reference architecture that provides a
     structured threat model, five enforcement pillars with typed
     schemas, four formally stated security properties, and an
     evidence-based maturity runtime where agents earn autonomy through
     cryptographic proof rather than calendar time.

full_text:
  Network Working Group                                          Yogami
  Internet-Draft                                          Berlin AI Labs
  Intended status: Informational                      12 February 2026
  Expires: 12 August 2026


               VERA: Verifiable Enforcement for Runtime Agents
                         draft-berlinai-vera-00


  Abstract

     AI agents take real actions with real data at machine speed.
     Compromised AI agents pose significant risks including data
     exfiltration, unauthorized financial transactions, and cascading
     failures across downstream systems.

     This document introduces VERA (Verifiable Enforcement for Runtime
     Agents), a zero trust reference architecture that provides a
     structured threat model, five enforcement pillars with typed
     schemas, four formally stated security properties, and an
     evidence-based maturity runtime where agents earn autonomy through
     cryptographic proof rather than calendar time.


  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 12 August 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 Simplified BSD License text as described in
     Section 4.e of the Trust Legal Provisions and are provided without
     warranty as described in the Simplified BSD License.


  Table of Contents

     1. Introduction: The Enforcement Gap  . . . . . . . . . . . . .  2
     2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . .  3
     3. Formal Security Properties . . . . . . . . . . . . . . . . .  4
     4. VERA Architecture: Five Enforcement Pillars  . . . . . . . .  5
     5. The Maturity Runtime . . . . . . . . . . . . . . . . . . . .  9
     6. Implementation Status  . . . . . . . . . . . . . . . . . . . 10
     7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . 10
     8. Security Considerations  . . . . . . . . . . . . . . . . . . 10
     9. Informative References . . . . . . . . . . . . . . . . . . . 10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . 11


  1.  Introduction: The Enforcement Gap

     While NIST SP 800-207 [NIST800-207] supports non-human subjects,
     most enterprise implementations were developed around human and
     workload access patterns.  AI agents violate the operational
     assumptions behind typical Zero Trust deployments, specifically
     regarding non-deterministic behavior, continuous autonomous loops,
     and emergent intent.

     Current governance frameworks provide valuable guidance but share a
     structural limitation: they do not fully define where policies are
     enforced, how telemetry feeds back into decisions, or how to prove
     that enforcement actually occurred.  VERA addresses this
     enforcement gap by providing the architectural layer between
     governance guidance and running infrastructure.

  1.1.  Three Structural Gaps

     Gap 1: Specification without enforcement architecture.  Anomaly
     detection for non-deterministic agents requires specific
     distributional baselines, not just generic monitoring.

     Gap 2: Calendar-based trust.  Trust should be evidence-based and
     continuously verified using cryptographic proofs, not accumulated
     over arbitrary time periods.

     Gap 3: Missing policy architecture.  VERA specifies PDP placement,
     PEP enforcement points, and feedback loops to make "Zero Trust" a
     verifiable property.


  2.  Threat Model

     VERA defines five adversary classes with explicit capability
     boundaries.

  2.1.  Adversary Classes

     Manipulator (External Input Attacks):  Submits crafted inputs
        (prompt injection) to hijack behavior.  Mitigated by Input
        Firewall (PEP).

     Insider (Supply Chain):  Modifies agent code or weights.  Mitigated
        by Signed PoE, SBOM verification, and signed manifests.

     Escalator (Privilege Escalation):  Controls compromised agent to
        game maturity or abuse delegation.  Mitigated by Evidence
        Portfolios and Capability Attenuation.

     Evader (Detection Bypass):  Injects false telemetry to hide
        malicious activity.  Mitigated by Multi-Source Anomaly Signals
        and Anchoring.

     Enforcement-Plane Compromiser:  Attacks the PDP/PEP infrastructure
        itself.  Mitigated by Separation of Duties, Quorum Signing, and
        TEEs.


  3.  Formal Security Properties

     VERA guarantees the following properties under standard
     cryptographic assumptions (Ed25519 unforgeability, SHA-256 collision
     resistance, secure key storage, and anchor integrity).

     Property 1: PEP-Attested Action Non-Repudiation.  An agent action
        is non-repudiable if a valid Proof of Execution (PoE) exists,
        signed by the PEP.  This proves the enforcement plane authorized
        and recorded the action.

     Property 2: Chain Tamper-Evidence.  A sequence of actions is
        tamper-evident if each PoE contains the hash of the previous
        proof, anchored externally.  Deletion or reordering is
        detectable.

     Property 3: Policy Enforcement Completeness.  All controlled
        actions MUST pass through a PEP.  Bypasses are detectable via
        kernel-level audit or traffic analysis.

     Property 4: Containment Bound.  Maximum damage is bounded by rate
        limits and circuit breaker reaction times.


  4.  VERA Architecture: Five Enforcement Pillars

  4.1.  Pillar 1: Verifiable Identity

     Enforcement principle: Every agent must possess a cryptographically
     bound identity that is independently verifiable without trusting the
     agent's self-attestation.

     Identity Architecture:

     o  Identifier: DID:web (W3C Decentralized Identifier), resolvable
        to an organizational domain.

     o  Credentials: JWT-VC (Verifiable Credentials), issuer-signed and
        tamper-evident.

     o  Runtime Binding: SPIFFE/SVID or container attestation binds the
        identity to a verified runtime environment.

     Normative Schema (TypeScript definition):

       interface VeraAgentIdentity {
         did: string;                    // DID:web identifier
         publicKey: string;              // Ed25519 public key (hex)
         owner: {
           did: string;                  // Owner DID
           signature: string;            // Owner's Ed25519 signature
         };
         purpose: AgentPurpose;          // Typed enum
         capabilities: SignedCapabilityManifest;
         issuedAt: ISO8601;
         expiresAt: ISO8601;
       }

                Figure 1: VeraAgentIdentity Schema

  4.2.  Pillar 2: Behavioral Proof

     Enforcement principle: Every agent action must produce a tamper-
     evident Proof of Execution (PoE) that is independently verifiable.
     PoE provides non-repudiation and chain integrity (Definitions 1 and
     2), not correctness of execution.

     Canonical signing format: All PoE signatures are computed over JCS-
     canonicalized JSON (RFC 8785).  This ensures deterministic field
     ordering and reproducible signatures.

       interface ProofOfExecution {
         actionId: string;               // UUID v7 (time-ordered)
         agentDid: string;               // Agent identity
         signerType: 'enforcer' | 'agent' | 'dual';
         signatureAlgorithm: 'Ed25519' | 'ECDSA-P256';
         action: {
           type: string;                 // Tool invocation, API call
           target: string;               // Resource identifier
           parameters: Record<string, unknown>;
           resultHash: string;           // SHA-256 of canonical result
         };
         context: {
           sessionId: string;
           sequenceNumber: number;       // Monotonic, gap-detectable
           previousProofHash: string;    // SHA-256 of previous PoE
         };
         timestamp: {
           agentClock: ISO8601;
           verifiedSource?: 'rfc3161' | 'anchor-derived';
         };
         signature: string;              // Over JCS-canonicalized PoE
       }

          Figure 2: Proof of Execution Structure (Normative Schema)

     Tool Execution Receipts: To verify execution correctness, VERA
     defines signed receipts from tools that bind to the PDP
     authorization nonce.

     A Tool Execution Receipt checks: (1) PDP decision exists for the
     nonce, (2) receipt is signed by a registered tool identity, (3) PoE
     references the receipt hash, (4) anchor timestamp proves ordering.

  4.3.  Pillar 3: Data Sovereignty

     Enforcement principle: All data entering an agent must be validated.
     All data leaving must be governed.  All stored data must be
     retention-managed.

  4.3.1.  Surface 1: Input Firewall

     Real-time classification of all agent inputs using local ONNX
     inference is required to prevent Prompt Injection (A01) and PII
     leakage.

     Performance Requirements: The input firewall MUST execute in sub-
     20ms latency to support interactive agent loops.  Cloud-based
     moderation APIs are explicitly discouraged due to latency and data
     sovereignty risks.

  4.3.2.  Surface 2: Memory and RAG Governance

     RAG poisoning is a critical attack vector.  VERA enforces:

     o  Per-Document ACLs: Row-level security on retrieved documents.

     o  Source Trust Scoring: Provenance tracking for every retrieved
        chunk.

     o  Retrieval Audit Log: Every retrieval is logged as a PoE event.

  4.4.  Pillar 4: Segmentation

     Enforcement principle: Agent access must be enforced at the tool-
     parameter level.

     Policy Decision Point (PDP): A centralized or sidecar-based engine
     (e.g., OPA) that evaluates every action against typed policies.

     Tool Parameter Constraints: Policies MUST restrict parameter values
     (e.g., transferAmount < 1000), not just tool access.  Default-allow
     for tools is prohibited for T3+ agents.

  4.5.  Pillar 5: Incident Enforcement

     Enforcement principle: Incident response for agents must be
     automated and survivable.

     Multi-Stage Containment SLA:

        Token Revocation:       < 500ms
        Session Termination:    < 1s
        Network Isolation:      < 2s (DNS Sinkhole)
        State Freeze:           < 5s (ReadOnly Mode)

     Adversarial Demotion: An attacker controlling the telemetry plane
     could trigger false demotions.  VERA mitigates this by requiring
     anomaly signals from multiple independent sources before triggering
     containment.


  5.  The Maturity Runtime

     Trust is evidence-based.  Agents progress through four tiers
     (Observer, Advisor, Operator, Autonomous) by accumulating
     cryptographically verified Evidence Portfolios, not just by
     existing for a set time.


  6.  Implementation Status

     VERA is backed by 12 open-source reference implementations verified
     against 25 contract tests.  Empirical results show sub-20ms latency
     for enforcement and >90% block rate against adversarial vectors.

     The reference implementation is available at:
     https://github.com/yogami/vera-reference-implementation


  7.  IANA Considerations

     This document has no IANA actions.


  8.  Security Considerations

     See Section 2 (Threat Model) and Section 3 (Formal Security
     Properties) for detailed security analysis.  The threat model
     defines five adversary classes; the security properties define
     formal guarantees under stated cryptographic assumptions.


  9.  Informative References

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


  Authors' Addresses

     Yogami (editor)
     Berlin AI Labs
     Berlin
     DE

     Email: yogami@berlinailabs.de


  Yogami                  Expires 12 August 2026                 [Page 11]


name: draft-li-dmsc-macp
rev: 02
title: Multi-agent Collaboration Protocol Suite
time: 2026-02-28T03:21:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T03:21:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.659640+00:00
source: ietf
abstract:
  This document specifies a Multi-agent Collaboration Protocol Suite,
     which enables scalable, secure, and semantically driven collaboration
     among distributed agents across heterogeneous networks.  The protocol
     suite introduces Agent Gateways as key entities responsible for agent
     registration, authentication, capability management and other
     functions, while preserving direct peer-to-peer semantic interactions
     among agents.

full_text:
  DMSC Working Group                                                 X. Li
  Internet-Draft                                             China Telecom
  Intended status: Standards Track                                  J. Liu
  Expires: 30 August 2026Beijing University of Posts and Telecommunications
                                                                     C. Du
                                                   Zhongguancun Laboratory
                                                                  L. Zhang
                                         AsiaInfo Technologies (China) Inc
                                                          26 February 2026


                  Multi-agent Collaboration Protocol Suite
                           draft-li-dmsc-macp-01

  Abstract

     This document specifies a Multi-agent Collaboration Protocol Suite
     based on Agent Gateway, which enables scalable, secure, and
     semantically driven collaboration among distributed agents across
     heterogeneous networks.  The protocol suite introduces Agent Gateways
     as key entities responsible for agent registration, authentication,
     capability management and other functions, while preserving direct
     peer-to-peer semantic interactions among agents.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 30 August 2026.

  Copyright Notice

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






  Li, et al.               Expires 30 August 2026                 [Page 1]


  Internet-Draft                    MACP                     February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions used in this document . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Multi-Agent Collaboration Function Entity Architecture  . . .   4
       4.1.  Agent . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Agent Management Center . . . . . . . . . . . . . . . . .   6
       4.3.  Agent Gateway . . . . . . . . . . . . . . . . . . . . . .   7
       4.4.  External Resource Service . . . . . . . . . . . . . . . .   8
       4.5.  User  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.6.  Data Objects  . . . . . . . . . . . . . . . . . . . . . .   8
       4.7.  Entity Summary  . . . . . . . . . . . . . . . . . . . . .   9
     5.  Multi-Agent Collaboration Protocol Suite Overview . . . . . .   9
       5.1.  Agent Registration and Authorization Process  . . . . . .  10
       5.2.  Capability Digest and Synchronization Process . . . . . .  11
       5.3.  Semantic Resolution and Routing Process . . . . . . . . .  11
       5.4.  Task-based Multi-Agent Invocation Process . . . . . . . .  12
       5.5.  Agent-to-Agent Process  . . . . . . . . . . . . . . . . .  12
       5.6.  Agent to External Resource Service Process  . . . . . . .  14
     6.  Requirements for the protocol suite . . . . . . . . . . . . .  14
     7.  Deployment Example: Fixed Network with Agent Gateway
             Realization . . . . . . . . . . . . . . . . . . . . . . .  17
     8.  Deployment Example: Mobile Operator Network . . . . . . . . .  18
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
     10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  20
     11. Normative References  . . . . . . . . . . . . . . . . . . . .  20
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

     As multi-agent systems become increasingly distributed across
     heterogeneous networks and administrative domains, efficient, secure,
     and semantically meaningful collaboration among agents becomes a
     critical challenge.  Traditional service-oriented or message-based
     interaction models are insufficient to capture agent-level
     capabilities, dynamic task decomposition, and semantic intent-driven
     communication.




  Li, et al.               Expires 30 August 2026                 [Page 2]


  Internet-Draft                    MACP                     February 2026


     This document specifies a Multi-agent Collaboration Protocol Suite
     based on Agent Gateway (AGW).  The suite defines a set of coordinated
     protocols that enable agent registration, authentication, capability
     synchronization, task-based invocation, and peer-to-peer semantic
     interaction.  The Agent Gateway is an infrastructure service that
     provides interconnection functions for agent collaboration, mediates
     control, policy enforcement, and orchestration, and enables
     authorized agents to directly exchange semantic information.

     The protocol suite is aligned with the architectural principles of
     control/forwarding plane separation, least-privilege authorization,
     and session-scoped semantic communication.

  2.  Conventions used in this document

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

  3.  Terminology

     The following terms are defined in this draft:

     *  Agent: An Agent is a software entity with autonomous decision-
        making and execution capabilities, capable of perceiving the
        environment, acquiring contextual information, reasoning, and
        performing tasks independently or collaboratively with other
        agents.

     *  Agent Gateway: The Agent Gateway is the infrastructure service
        that provides interconnection functions for agent collaboration.
        .

     *  Agent Management Center (AMC): It is the trusted infrastructure
        service responsible for agent identity lifecycle management and
        credential issuance.

     *  Agent Identity Code (AIC): An Agent Identity Code (AIC) is a
        verifiable, globally unique identifier that represents the
        identity of an Agent.

     *  Agent Capability Specification (ACS): An Agent Capability
        Specification (ACS) is a structured description of an agent's
        capabilities and service information that can be stored,
        retrieved, and matched.






  Li, et al.               Expires 30 August 2026                 [Page 3]


  Internet-Draft                    MACP                     February 2026


     *  Agent Credential: An Agent Credential is a tamper-resistant data
        object issued by an Agent Management Center(or its credential
        authority component), used by an Agent to prove identity
        attributes and/or authorization to a relying party.  Examples
        include X.509 certificates and security tokens.

     *  Agent Autonomous Domain: An Agent Autonomous Domain is an
        administrative and governance domain organized and managed by a
        specific IoA service provider.  An Agent Autonomous Domain
        typically includes one Agent Management Center, one or more Agent
        Gateways, and the agents registered within its scope.

     *  Agent Registration Protocol (ARP): The ARP governs how an agent
        formally registers with a locally attached agent gateway.

     *  Agent Authentication and Authorization Protocol (AAAP): The AAAP
        defines how authentication and authorization decisions are
        requested and enforced.

     *  Capability Digest and Synchronization Protocol (CDSP): The CDSP
        synchronizes abstracted capability digest information across agent
        gateways based on gateway-generated ACS records.

     *  Task-based Invocation Protocol (TIP): The TIP defines how tasks,
        once decomposed by the application logic, are coordinated across
        agents.

  4.  Multi-Agent Collaboration Function Entity Architecture

     The DMSC architecture defines four functional entities and one
     external actor (User).  Each functional entity represents a logical
     role in the IoA architecture; implementations MAY combine multiple
     entities into a single product or distribute a single entity across
     multiple services.

















  Li, et al.               Expires 30 August 2026                 [Page 4]


  Internet-Draft                    MACP                     February 2026


                      +-----------------------+
                      |Agent Management Center|
                      |     (Identity +       |
                      |      Credential)      |
                      +---------+-------------+
                                |  AAAP
                                |
                          +-------------------+
                          |   Agent Gateway   |
                          |   (Capability     |
                          | + Discovery       |
                          | + Routing         |     +---------------------+
                          | + Msg Distribution|     | External Resource   |
                          | + Trust Policy)   |     | Service             |
                          +--+-----+----------+     +----------+----------+
                             |     |                       |
                       ARP   |     | TIP                   |  MCP
                             |     |                       |
               +-----------------------+            +----------------------+
               |        Agent          |     A2A    |        Agent         |
               |      (Role A)         |----------- |      (Role B)        |
               +----------+------------+            +----------------------+
                          |
               +----------+------------+
               |          User         |
               +-----------------------+

              Figure 1 Function Entity Architecture Overview

  4.1.  Agent

     An Agent is a software entity with autonomous decision-making and
     execution capabilities, capable of perceiving the environment,
     acquiring contextual information, reasoning, and performing tasks
     independently or collaboratively with other agents.  Each Agent is
     created by a specific Agent Provider and MUST complete registration
     with an Agent Management Center before providing services in an IoA
     deployment.

     An Agent is responsible for:

     *  Maintaining its own identity information (e.g., AIC) and
        credentials locally.

     *  Maintaining its capability description (e.g., ACS) and ensuring
        consistency with its current state.





  Li, et al.               Expires 30 August 2026                 [Page 5]


  Internet-Draft                    MACP                     February 2026


     *  Performing authentication and authorization checks for
        interconnection, including mutual verification of peer agents and
        validation of presented credentials. - Conducting agent-to-agent
        interaction, including session establishment, message exchange,
        and task/context management.

     *  Accessing external resources when required to fulfill tasks.

     *  Producing monitoring and logging data for troubleshooting,
        auditing, and governance purposes.

     These are internal agent capabilities described here for
     informational purposes.  They are NOT standardized as separate
     architectural functional components.  In an interaction, an Agent MAY
     assume different roles depending on the collaboration mode.  The DMSC
     architecture does not constrain the set of possible roles; specific
     collaboration protocols MAY define role semantics appropriate to
     their interaction patterns.

     For example, in a task-driven collaboration:

     *  Leader: The Agent that initiates tasks and organizes
        collaboration.

     *  Partner: The Agent that accepts tasks and provides services,
        executing assigned tasks and returning results to the Leader.

     A single Agent implementation MAY act in different roles across
     different interactions.  Role assignment is per-interaction, not per-
     deployment.

  4.2.  Agent Management Center

     The Agent Management Center is the trusted infrastructure service
     responsible for agent identity lifecycle management and credential
     issuance.  The Agent Authentication serves as the trust anchor for an
     IoA deployment.

     The Agent Management Center provides the following functions:

     *  Credential Management: Issuing, renewing, suspending, revoking,
        and publishing status of Agent Credentials (e.g., X.509
        certificates, security tokens) bound to AICs.

     *  Credential Validation Support: Providing credential validation
        material (e.g., issuer public keys, certificate revocation lists,
        OCSP endpoints) to relying parties.




  Li, et al.               Expires 30 August 2026                 [Page 6]


  Internet-Draft                    MACP                     February 2026


     Multiple Agent Management Center MAY exist in an IoA deployment, each
     managing a subset of agents within its administrative scope.  A
     deployment MAY realize the identity management function and the
     credential authority function as separate services, provided they
     maintain consistent identity-to-credential binding.

  4.3.  Agent Gateway

     The Agent Gateway is the infrastructure service that provides
     interconnection functions for agent collaboration.

     The Agent Gateway provides the following functions:

     *  Identity Management: Allocating, updating, and de-registering
        Agent Identity Codes (AICs); defining and enforcing policies for
        uniqueness and governance of issued AICs within its administrative
        scope.

     *  Capability Directory: Accepting, validating, publishing,
        versioning, and de-listing Agent Capability Specifications (ACSs);
        maintaining the capability directory for agents within its
        administrative scope.

     *  Discovery and Matching: Receiving discovery queries from agents,
        matching query constraints against available agent capability
        descriptions, and returning ranked candidate sets.  In-domain
        discovery SHOULD be supported; cross-domain discovery is OPTIONAL
        within a configured trust scope.

     *  Routing and Forwarding: Routing agent interaction requests based
        on capability matching results or task requirements.  The routing
        function MAY support semantic routing as an extension point for
        future capabilities such as intent-based routing.

     *  Message Distribution: Providing message distribution services for
        group interactions (e.g., publish/subscribe, queue-based delivery)
        when agents interact in grouping mode.

     *  Trust Policy: Maintaining trust relationships and federation
        policies between Agent Autonomous Domains (e.g., trusted peer
        domain lists, cross-domain discovery policies) to constrain cross-
        domain discovery and interactions.

     The Agent Gateway SHOULD support synchronization with the Agent
     Management Center to ensure accuracy and timeliness of identity and
     capability information.  Multiple Agent Gateways MAY exist in an IoA
     deployment, each serving a defined administrative scope.




  Li, et al.               Expires 30 August 2026                 [Page 7]


  Internet-Draft                    MACP                     February 2026


     A deployment MAY co-locate the Agent Gateway with the Agent
     Management Center.

  4.4.  External Resource Service

     The External Resource Service is a device, software component, or
     network-accessible service that provides specific functions to
     agents.  Examples include APIs, databases, computation services, and
     other external resources.

     The External Resource Service provides the following functions:

     *  Resource Exposure: Registering or exposing available resources and
        their invocation interfaces to authorized agents.

     *  Invocation Handling: Receiving and processing resource invocation
        requests from agents, executing the requested operations, and
        returning results.

     *  Access Control: Enforcing access control policies on resource
        invocations, including authentication of requesting agents and
        authorization checks.

     An External Resource Service MAY represent a single resource, a
     resource gateway, or a resource execution environment.  Deployments
     MAY use existing resource access protocols (e.g., MCP [Model Context
     Protocol], A2T [Agent-to-Tool Protocol]) for agent-to-resource
     interaction.

  4.5.  User

     A User is a human or organizational entity that initiates tasks,
     provides authorization and policy input, and consumes results
     delivered by agents.  A User interacts with agents but does not
     participate directly in agent-to-agent protocols defined by DMSC.

  4.6.  Data Objects

     The following are protocol data objects referenced by the functional
     entities.  They are not functional entities themselves.

     Agent Identity Code (AIC): An Agent Identity Code (AIC) is a
     verifiable, globally unique identifier that represents the identity
     of an Agent.  An AIC is allocated by an Agent Gateway during agent
     registration.






  Li, et al.               Expires 30 August 2026                 [Page 8]


  Internet-Draft                    MACP                     February 2026


     Agent Capability Specification (ACS): An Agent Capability
     Specification (ACS) is a structured description of an agent's
     capabilities and service information that can be stored, retrieved,
     and matched.  An ACS MAY use the JSON [RFC8259] [RFC8259] format,
     typically including: the agent's AIC, functional capabilities,
     technical characteristics, service interfaces, and security
     requirements.

     Agent Credential: An Agent Credential is a tamper-resistant data
     object issued by an Agent Authentication (or its credential authority
     component), used by an Agent to prove identity attributes and/or
     authorization to a relying party.  Examples include X.509
     certificates and security tokens.

     Agent Autonomous Domain: An Agent Autonomous Domain is an
     administrative and governance domain organized and managed by a
     specific IoA service provider.  An Agent Autonomous Domain typically
     includes one Agent Authentication, one or more Agent Gateways, and
     the agents registered within its scope.

  4.7.  Entity Summary

     The following table provides a summary of all functional entities and
     external actors in the simplified DMSC architecture.

  | #  | Entity                    | Type              | Role in Architecture                                  |
  |----|---------------------------|-------------------|-------------------------------------------------------|
  | 1  | Agent                     | Core entity       | Autonomous task execution and collaboration           |
  | 2  | Agent Management Center   | Infrastructure    | Identity lifecycle management and credential issuance |
  | 3  | Agent Gateway             | Infrastructure    | Capability directory, discovery, routing, message distribution, trust policy |
  | 4  | External Resource Service | Infrastructure    | External resource exposure and invocation handling    |
  | 5  | User                      | External actor    | Task initiation, authorization, and result consumption|

  Figure 2  A summary of all functional entities

  5.  Multi-Agent Collaboration Protocol Suite Overview

     The Multi-Agent Collaboration Protocol Suite based on Agent Gateway
     defines a set of interaction processes as shown in the figure below
     that collectively enable secure agent onboarding, distributed
     capability visibility, semantic request resolution, peer-to-peer
     semantic interaction, and task-oriented multi-agent orchestration.
     Rather than operating independently, these protocols are designed to
     be executed in a tightly coupled manner along the agent lifecycle and
     collaboration workflows.  The Agent Gateway (AG) serves as the
     anchoring point for control-plane coordination.





  Li, et al.               Expires 30 August 2026                 [Page 9]


  Internet-Draft                    MACP                     February 2026


   User        Agent A      AG 1          AG 3              AMC           AG 2        Agent B    Agent C
    |             |            |             |               |              |<--------------Register|
    |             |Register--->|             |               |              |<--Register|           |
    |             |            |--Auth Req------------------>|<---Auth Req--|           |           |
    |             |            |<-----------------Auth Grant |--Auth Grant->|           |           |
    |             |<-Local Bind|             |               |              |           |           |
    |             |            |             |               |              |--Local Bind (B,C)---->|
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |<----------->|<-----Capa Digest and Sync -->|           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    | --Req-----> |-SemR Req-->|             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |---SemR Req->|----------------------------->|           |           |
    |             |            |<------------|<------SemR Resp--------------|           |           |
    |             |<-SemR Resp |             |               |              |           |           |
    |             |============================ Semantic Session========================|           |
    |             |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|           |
    |             |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<|           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |             |            |             |               |              |           |           |
    |--Task Req-->|               +-----------------------------+           |           |           |
    |             | ---------->   | Semantic Routing process    |---------->|           |           |
    |             |               + ----------------------------+           |           |           |
    |             |--------------------------------------Invoke------------------------------------>|
    |             |<--------------------------------------Executing---------------------------------|
    |             |            |             |               |              |           |           |

                             Figure 3 The overall sequence diagram of MACP

  5.1.  Agent Registration and Authorization Process

     An agent MUST register with its locally attached Agent Gateway before
     participating in any collaboration.  This process is governed jointly
     by ARP and AAAP and establishes the agent’s identity, trust status,
     and capability binding.  Upon receiving a registration request, the
     Agent Gateway performs preliminary validation of the agent’s identity
     attributes and initial capability description.  The gateway then
     initiates an authentication and authorization request to the Central
     Authentication Service, conveying the agent identity, gateway
     identity, and requested operational scope.






  Li, et al.               Expires 30 August 2026                [Page 10]


  Internet-Draft                    MACP                     February 2026


     The Central Authentication Service evaluates the request and returns
     an authorization grant or denial.  Upon successful authorization, the
     Agent Management Center issues an Agent Credential.  And the Agent
     Gateway finalizes the registration by assigning the agent a globally
     unique Agent Identity Code (AIC) and Capability Identifier(s).  The
     AIC represents the agent’s persistent identifier within the
     architecture.  The AIC is allocated by the Agent Gateway only after
     successful authentication and authorization.

  5.2.  Capability Digest and Synchronization Process

     Each Agent Gateway maintains detailed capability information only for
     its locally registered agents, and generates a structured Agent
     Capability Specification (ACS).  The ACS is a gateway-generated
     representation that normalizes and organizes authorized capabilities
     associated with the assigned AIC.  It reflects only those
     capabilities permitted within the approved operational scope.
     Gateways do not synchronize full agent capability states with each
     other.  Instead, to support inter-gateway semantic resolution,
     gateways exchange capability digests using the Capability Digest
     Synchronization Protocol (CDSP).  A capability digest is a locally
     generated, abstract summary of available capabilities, designed
     solely to indicate what kinds of capabilities exist behind a gateway,
     rather than how those capabilities are internally implemented or
     executed by agents.The structure and semantics of capability digests
     are intentionally decoupled from agent-internal capability
     representations, allowing gateways to evolve local capability models
     without impacting inter-gateway interoperability.

     CDSP distributes these capability digests incrementally.  An initial
     exchange establishes basic inter-gateway visibility, while subsequent
     updates convey only digest changes, such as newly advertised
     capabilities, capability updates, or withdrawals.  Digest updates are
     versioned and acknowledged to support consistency and conflict
     resolution.  Through this digest-based mechanism, gateways maintain a
     scalable and privacy-preserving view of distributed agent
     capabilities without requiring centralized directories or full
     capability replication.

  5.3.  Semantic Resolution and Routing Process

     When a user issues a request to an agent (e.g., Agent A), the agent
     abstracts the request into a semantic request and submits it to its
     locally attached Agent Gateway (AG1).  Upon receiving the semantic
     request, AG1 performs semantic parsing and normalization and consults
     its local capability directory.  If no matching capability identifier
     is found, AG1 forwards the semantic request to a peer or upstream
     gateway (e.g., AG3), which repeats the same resolution procedure.  If



  Li, et al.               Expires 30 August 2026                [Page 11]


  Internet-Draft                    MACP                     February 2026


     the request remains unresolved, it is further forwarded to another
     gateway (e.g., AG2).

     When a gateway identifies a matching capability in its local
     directory, it generates a semantic resolution response containing the
     resolved capability identifier and the corresponding target agent
     information.  This response is propagated hop-by-hop back to the
     originating gateway and ultimately delivered to Agent A.

     Following successful resolution, Agent A and the target agent (e.g.,
     Agent B) directly establish a semantic session.  During the lifetime
     of this session, semantic data is exchanged directly between agents
     in a peer-to-peer manner, while gateways remain responsible for
     resolution, authorization scope enforcement, and security policy
     application during session establishment.

  5.4.  Task-based Multi-Agent Invocation Process

     Task-based collaboration extends semantic resolution to scenarios
     requiring multiple agents and coordinated execution.  When a user
     initiates a task request, the request is delivered to Agent A, which
     performs semantic understanding of the task and decomposes it into
     one or more sub-tasks along with the required capabilities.  If Agent
     A does not possess task decomposition capabilities, its attached
     Agent Gateway MAY act as a proxy to analyze and decompose the task on
     behalf of the agent.

     For each sub-task, Agent A submits a semantic request to its local
     gateway, triggering the semantic resolution and routing process.
     Unlike pure point-to-point semantic communication, gateways
     additionally apply task-level constraints, policy considerations, and
     capability selection logic to identify suitable target agents.

     The resolved results are returned to Agent A, which then directly
     invokes the selected agents and establishes the necessary semantic
     sessions for execution.  Through this mechanism, multiple agents can
     be dynamically selected and coordinated to collaboratively execute
     complex tasks.

  5.5.  Agent-to-Agent Process

     The Agent-to-Agent Protocol (A2A) defines how two authorized agents
     establish, maintain, and terminate a semantic session for peer-to-
     peer semantic communication.  A2A operates entirely between agents in
     the data plane.  Agent gateways participate only during session
     authorization and parameter provisioning phases and are not required
     in the semantic data path once the session is established.




  Li, et al.               Expires 30 August 2026                [Page 12]


  Internet-Draft                    MACP                     February 2026


     A2A process consists of four phases:

     *  Session Initiation: A semantic session is initiated when an agent,
        having obtained a valid resolution result, sends a session
        initiation message to the target agent.  The message includes the
        Agent Identifiers, a proposed Session Identifier, the resolved
        Capability Identifier, and a verifiable authorization artifact
        derived from prior control-plane procedures.  Upon transmission,
        the initiating agent awaits confirmation from the target agent.

     *  Mutual Verification and Session Establishment: Upon receiving the
        initiation request, the target agent verifies the initiator’s
        identity, validates the authorization context, and confirms that
        the referenced capability is locally bound and permitted by
        policy.  If validation succeeds, the target agent returns a
        session acceptance message, and both agents transition to an
        established state.  If validation fails, the request is rejected
        and no session is created.

     *  Semantic Interaction: Once established, semantic data is exchanged
        directly between the agents and is explicitly bound to the Session
        Identifier and Capability Identifier.  Each agent enforces the
        authorized capability scope locally.  The protocol does not
        mandate a specific transport, but confidentiality and integrity
        protection are expected to be ensured by the underlying secure
        channel.

     *  Session Update: If session parameters require adjustment, either
        agent may request an update.  Any modification must remain within
        the originally authorized scope unless additional authorization is
        obtained.  Updated parameters take effect upon mutual agreement.

     *  Session Termination: A session is terminated when either agent
        sends a termination message or when authorization expires.  Upon
        termination, both agents release associated resources and reject
        further messages referencing the Session Identifier.















  Li, et al.               Expires 30 August 2026                [Page 13]


  Internet-Draft                    MACP                     February 2026


       Agent A                             Agent B
        |                                     |
        |---- SESSION_INIT ------------------>|
        |                                     |
        |<--- SESSION_ACCEPT -----------------|
        |                                     |
        |========== Semantic Data ===========>|
        |<========= Semantic Data ============|
        |                                     |
        |---- SESSION_TERMINATE ------------->|
        |                                     |
      Figure 4  Agent-to-Agent Semantic Session Process

  5.6.  Agent to External Resource Service Process

     When an agent requires capabilities that are not internally available
     within the agent collaboration domain, it interacts with an External
     Resource Service (ERS) through a standardized agent-to-resource
     access protocol.  The agent first resolves the target resource
     endpoint and determines whether the requested operation falls within
     its authorized trust scope.  The agent then establishes a secure
     session with the External Resource Service using an existing resource
     access protocol, such as MCP (Model Context Protocol), A2T (Agent-to-
     Tool Protocol), or other deployment-specific interfaces.

     The agent includes its identity reference (e.g., AIC or associated
     credential) in the invocation request.  The External Resource Service
     performs authentication and authorization checks based on its local
     access control policies.  If approved, the requested operation is
     executed and the result is returned to the agent.

  6.  Requirements for the protocol suite

     The protocol suite defined in this document supports the complete
     interaction lifecycle of multi-agent collaboration.  Each stage of
     collaboration — including registration, authorization, capability
     visibility, semantic resolution, task coordination, and session
     establishment — requires specific protocol.  From an end-agent
     perspective, the corresponding protocols collectively form a
     Interaction Layer, as shown in the figure below.











  Li, et al.               Expires 30 August 2026                [Page 14]


  Internet-Draft                    MACP                     February 2026


     Before an agent can participate in any collaboration, it must
     establish a recognized identity and authorized operational scope
     within the system.  This requirement leads to the definition of the
     Agent Registration Protocol (ARP) and the Agent Authentication and
     Authorization Protocol (AAAP).  ARP governs how an agent formally
     registers with a locally attached distributed node, while AAAP
     defines how authentication and authorization decisions are requested
     and enforced.

     Once identity and authorization are established, the system should
     enable capability visibility across agent gateways.  This introduces
     the need for the Capability Digest and Synchronization Protocol
     (CDSP), which synchronizes abstracted capability digest information
     across agent gateways based on gateway-generated ACS records.

     For multi-agent task execution, the Task-based Invocation Protocol
     (TIP) defines how tasks, once decomposed by the application logic,
     are coordinated across agents.  TIP standardizes task state
     signaling, invocation ordering, and execution control across
     distributed participants.  Importantly, task decomposition algorithms
     and business workflow reasoning remain within the Application Layer;
     TIP only governs the distributed coordination of already-defined
     tasks.

     Finally, once authorization and routing decisions have been
     completed, direct semantic interaction between agents requires
     session establishment and execution control.  This is addressed by
     the Agent-to-Agent Protocol (A2A), which governs session creation,
     capability-scoped execution, and termination.  A2A enables direct
     semantic exchange without redefining application logic or semantic
     interpretation.

     Based on the above, the protocol suite consists of the following
     categories:

     *  Agent Registration Protocol (ARP) and Agent Authentication and
        Authorization Protocol (AAAP), which jointly establish agent
        identity, trust, and operational scope.

     *  Capability Digest Synchronization Protocol (CDSP), which maintains
        distributed visibility of agent capability digest across gateways.

     *  Task-based Invocation Protocol (TIP), which extends semantic
        routing to multi-agent task decomposition and orchestration.

     *  Agent-to-Agent Protocol (A2A), which completes the collaboration
        lifecycle by enabling autonomous, peer-to-peer semantic
        interaction.



  Li, et al.               Expires 30 August 2026                [Page 15]


  Internet-Draft                    MACP                     February 2026


     *  Agent to External Resource Service Protocol, which will use
        existing protocol, such as MCP (Model Context Protocol), A2T
        (Agent-to-Tool Protocol), or other deployment-specific interfaces.

     +------------------------------------------------------------------+
     |                    Application Layer                             |
     |                                                                  |
     | +------------------+ +------------------+ +------------------+   |
     | | Task             | | Policy and       | | HITL and         |   |
     | | Orchestration    | | Governance       | | Failure Handling |   |
     | | - decomposition  | | - policy rules   | | - escalation     |   |
     | | - state model    | | - dynamic CBAC   | | - fallback/retry |   |
     | +------------------+ +------------------+ +------------------+   |
     +-----------------------------+------------------------------------+
                                   |
                                   | Application-to-Semantic Contract
                                   v
     +------------------------------------------------------------------+
     |                      Semantic Layer                              |
     |                                                                  |
     | +------------------+ +------------------+ +------------------+   |
     | | Ontology and     | | Validation and   | | Natural-Language |   |
     | | Profile Model    | | Rules            | | Intent           |   |
     | | - classes and    | | - consistency    | | Normalization    |   |
     | |   properties     | | - applicability  | | - text to intent |   |
     | | - constraints    | | - deterministic  | | - confidence and |   |
     | +------------------+ +------------------+ |   ambiguity      |   |
     |                                           +------------------+   |
     | +------------------+ +------------------+                        |
     | | Alignment and    | | Knowledge        |                        |
     | | Version          | | Resources        |                        |
     | | Governance       | | - glossary/codes |                        |
     | | - mapping        | | - remediation    |                        |
     | |   confidence     | |   knowledge      |                        |
     | | - compatibility  | |                  |                        |
     | |                  | |                  |                        |
     | +------------------+ +------------------+                        |
     +-----------------------------+------------------------------------+
                                   |
                                   | Semantic-to-Interaction Contract
                                   v
     +------------------------------------------------------------------+
     |                   Coordination Layer                             |
     |       +---------------------+   +---------------------+          |
     |       | Register & Identity |   |  Authentication     |          |
     |       | - ARP               |   |  & Authorization    |          |
     |       |                     |   |  - AAAP             |          |
     |       +---------------------+   +---------------------+          |



  Li, et al.               Expires 30 August 2026                [Page 16]


  Internet-Draft                    MACP                     February 2026


     |       +---------------------+   +---------------------+          |
     |       | Invocation & Session|   | Sync & Resolution   |          |
     |       | - TIP               |   | & Routing           |          |
     |       | - A2A               |   | - CDSP              |          |
     |       +---------------------+   +---------------------+          |
     +------------------------------------------------------------------+
                                   |
                                   v
     +------------------------------------------------------------------+
     |       Transport Connectivity + Security Enforcement              |
     +------------------------------------------------------------------+
       Figure 5 Unified Layered Architecture and Modules

  7.  Deployment Example: Fixed Network with Agent Gateway Realization

     This section provides a deployment example illustrating how the
     proposed architecture can be realized in a fixed network environment.
     The purpose of this example is not to constrain implementation
     choices, but to demonstrate how distributed nodes defined in the
     architecture may be instantiated using existing or enhanced network
     elements.

     In a fixed broadband network, distributed nodes can be realized as
     enhanced Agent Gateway functions deployed at aggregation layers, or
     service edge points.  These nodes are positioned logically between
     access networks and service domains, enabling them to perform
     registration, authorization mediation, capability abstraction, and
     semantic routing functions without requiring changes to end-user
     access infrastructure.

     In such deployments as shown in figure 6:

     *  Agent registration and authentication are performed via the AG and
        Agent Management Center (AMC).

     *  Capability digest exchange occurs between AGs.

     *  Semantic resolution is handled hop-by-hop across AGs.

     *  Agents establish peer-to-peer semantic sessions after gateway-
        mediated coordination.

     This example demonstrates that distributed nodes, which encapsulate
     logical coordination functions, can be embedded into agent gateways
     in fixed networks.






  Li, et al.               Expires 30 August 2026                [Page 17]


  Internet-Draft                    MACP                     February 2026


                                      +------------------------------+
                                 +----|    Agent Management Center   |------+
                                 |    +------------------------------+      |
                                 |                                          |
        +----------+      +---------+                                  +---------+   +---------+
        | Agent A  | ---- | AG 1    |<-------------+    +------------->|  AG 2   |---| Agent B |
        +----------+      +---------+              |    |              +---------+   +---------+
                                                   |    |
                                               +------------+
                                               |  Routers   |
                                               +------------+

                       Figure 6  Deployment Example: Fixed Network with Agent Gateway Realization

  8.  Deployment Example: Mobile Operator Network

     In a mobile operator network (e.g., a 6G network), AI capabilities
     and technologies are expected to be leveraged subject to operator
     policies and configurations.  AI Agents, which refer generally to
     agents that autonomously perform tasks on behalf of users, systems,
     and/or applications, can understand complex requests and improve
     network efficiency.  In addition, capabilities and services such as
     sensing, real-time data processing, telemetry, analytics, and others
     within a 6G network may also be provided as “Tools” to third-party
     applications.

     Below figure shows an example of AI agents, an Agent Management
     Center and an Agent Gateway deployed in the mobile operator network.
     The architecture of 6G is still in discussion, thus some
     functionalities are described by using some 5G NFs as typical
     examples.

     User initiates intent in nature language and receive human-readable
     result.  Intent analysis takes place at two stages:

     *  (Optional, based on UE capabilities) The UE converts natural-
        language intent to operator-defined intent and also translates
        operator-defined results to human-readable results based on
        internal implementation.

     *  (Mandatory) The network function (NF) with agent capability in the
        mobile operator core network comprehends and analyzes the intent.
        Based on the analyzed intent, a subsequent workflow is generated.
        Typically, the NF that terminates NAS messages (e.g., AMF in 5G)
        can either comprehend the intent (when the AMF includes agent
        capability) or forward the intent to an agent-enabled NF in the
        core network (when the AMF does not include agent capability).




  Li, et al.               Expires 30 August 2026                [Page 18]


  Internet-Draft                    MACP                     February 2026


     Agent-enabled NFs request AIC allocation from the Agent Gateway.  The
     NF (e.g., AMF in 5G) that terminates NAS messages and manages UE
     registration may request AIC from the Agent Gateway on behalf of the
     agent in the UE.  The Agent Management Center is responsible for
     agent authentication and authorization.  The authentication and
     authorization procedure for agents (Agents ↔ Agent Gateway ↔ Agent
     Management Center) may reference the authentication and authorization
     procedure for UEs (e.g., UEs <-> AMF <-> UDM <-> AUSF in 5G).

     Agent-enabled NFs register with the Agent Gateway and discover each
     other by querying the Agent Gateway.  The registration and discovery
     mechanism is similar to the functionality provided by the NRF in 5G
     networks.  However, standardization of agent capabilities is
     essential for the accuracy and efficiency of agent discovery.  The NF
     (e.g., AMF in 5G) that terminates NAS messages and manages UE
     registration may interact with the Agent Gateway on behalf of the
     agent in the UE.  However, the discovery of the agent on the UE takes
     the UE connection state into account.

     Service-based interfaces may be enhanced to support agent
     communication, or agent-based interfaces may be introduced to support
     AI traffic carrying Agent-to-Agent semantic data.  The AI
     capabilities supported by the mobile operator network may be exposed
     as agent tools and invoked by third-party AI agents via the Agent
     Gateway, which performs protocol conversion for different agent
     communication protocols if necessary, while AI traffic transmitted
     through the mobile operator network may be identified to guarantee
     performance requirements.

     The NF supporting session management (e.g., SMF in 5G) can be
     enhanced, or a new NF may be introduced to support the management of
     Agent-to-Agent semantic sessions between the agent residing in the UE
     and the agent residing in the operator core network.


















  Li, et al.               Expires 30 August 2026                [Page 19]


  Internet-Draft                    MACP                     February 2026


       +-------+
       |  Uesr |
       +-+-----+
         |  ^
         |  |
         |  |
  +------+--+-------+                 +----------------------------------------------------------------------+                +------------+
  |      |  |       |                 |                                                   Mobile Operator    |                | Third Party|
  |      v  |       |                 |                                                      Corenetwork     |                |            |
  |  +------+----+  | Operator-defined|                                                                      |                |            |
  |  |  UE APP   |  | <-------------> |    +--------+    +-----------+    +----------+                       |<-------------> |  +------+  |
  |  +--+--------+  |                 |    |   NF   |    | NF with   |    |   Agent  |                       |                |  | Agent|  |
  |     |   ^       |                 |    |        |    |   Agent   |    |  Gateway |                       |                |  +------+  |
  |     v   |       |                 |    +---+----+    +-----+-----+    +-----+----+                       |                |            |
  |  +------+----+  |                 |        |               |                |                            |                |  +------+  |
  |  | UE OS Layer  |                 |        |               |                |                            |                |  | Agent|  |
  |  |   Agent   |  |                 |        |               |                |     Service Based Interface|                |  +------+  |
  |  +--+--------+  | Intent Execution|        |               |                |      (Agent Enhancement)   |                |            |
  |     |   ^       | <-------------> |--------+----+----------+----+-----------+----+------------------     | <------------->|     .      |
  |     |   |       |      Result     |             |               |                |                       |                |     .      |
  |     |   |       |                 |             |               |                |                       |                |     .      |
  |     v   |       |                 |             |               |                |                       |                |     .      |
  |  +------+----+  |                 |      +------+----+     +----+---+    +-------+-----+                 |                |     .      |
  |  | UE Modem  |  |                 |      |  NF with  |     |   NF   |    |    Agent    |                 |                |            |
  |  |           |  |                 |      |   Agent   |     |        |    | Management  |                 |                |  +------+  |
  |  +-----------+  |   AI traffic    |      +-----------+     +--------+    |    Center   |                 |    AI Traffic  |  | Agent|  |
  |                 | <-------------> |                                      +-------------+                 | <------------->|  +------+  |
  |                 |     Transfer    |                                                                      |     Transfer   |            |
  | UE              |                 |                                                                      |                |            |
  +-----------------+                 +----------------------------------------------------------------------+                +------------+
                                                Figure 7 Deployment Example: Mobile Operator Network

  9.  IANA Considerations

     TBD

  10.  Acknowledgement

     TBD

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





  Li, et al.               Expires 30 August 2026                [Page 20]


  Internet-Draft                    MACP                     February 2026


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

  Authors' Addresses

     Xueting Li
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: lixt2@foxmail.com


     Jun Liu
     Beijing University of Posts and Telecommunications
     10 Xitucheng Road, Haidian District
     Beijing
     100876
     China
     Email: liujun@bupt.edu.cn


     Chenguang Du
     Zhongguancun Laboratory
     Beijing
     100094
     China
     Email: ducg@zgclab.edu.cn


     Lianhua Zhang
     AsiaInfo Technologies (China) Inc
     Beijing
     100000
     China
     Email: zhanglh2@asiainfo.com












  Li, et al.               Expires 30 August 2026                [Page 21]


name: draft-zeng-nmrg-mcp-usecases-requirements
rev: 00
title: MCP for Network Management: Problem Statement, Use Cases, and Requirements
time: 2026-02-14T08:18:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-18T08:18:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.667634+00:00
source: ietf
abstract:
  The emergence of large language models (LLMs) and AI agents is
     reshaping how network operators interact with infrastructure.
     However, current network management systems lack a standardized,
     secure, and intent-driven interface that enables AI agents to
     discover, invoke, and reason over network capabilities.  This
     document presents a problem statement for integrating the Model
     Context Protocol (MCP) into network management, outlines key use
     cases—including troubleshooting, measurement, security, and
     optimization—and specifies functional, security, and interoperability
     requirements for MCP-based network management architectures.

full_text:
  Network Working Group                                            G. Zeng
  Internet-Draft                                                    Huawei
  Intended status: Informational                             February 2026
  Expires: 18 August 2026


       MCP for Network Management: Problem Statement, Use Cases, and
                                Requirements
                draft-zeng-nmrg-mcp-usecases-requirements-00

  Abstract

     The emergence of large language models (LLMs) and AI agents is
     reshaping how network operators interact with infrastructure.
     However, current network management systems lack a standardized,
     secure, and intent-driven interface that enables AI agents to
     discover, invoke, and reason over network capabilities.  This
     document presents a problem statement for integrating the Model
     Context Protocol (MCP) into network management, outlines key use
     cases—including troubleshooting, measurement, security, and
     optimization—and specifies functional, security, and interoperability
     requirements for MCP-based network management architectures.

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



  Zeng                     Expires 18 August 2026                 [Page 1]


  Internet-Draft  MCP for Network Management: Problem Stat   February 2026


     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.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Troubleshooting . . . . . . . . . . . . . . . . . . . . .   3
       3.2.  Network Measurement . . . . . . . . . . . . . . . . . . .   4
       3.3.  Security Operations . . . . . . . . . . . . . . . . . . .   4
       3.4.  Network Optimization  . . . . . . . . . . . . . . . . . .   4
     4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Functional Requirements . . . . . . . . . . . . . . . . .   5
       4.2.  Security Requirements . . . . . . . . . . . . . . . . . .   5
       4.3.  Interoperability & Operational Requirements . . . . . . .   5
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     Traditional network management relies on protocol-specific interfaces
     (e.g., SNMP, NETCONF, RESTCONF) and manual scripting, which are
     rigid, siloed, and ill-suited for natural-language-driven automation.
     The Model Context Protocol (MCP), originally designed to standardize
     tool interaction for AI agents, offers a promising abstraction layer
     to unify network capabilities as callable “tools” and readable
     “resources.” This document formalizes the motivation, scenarios, and
     technical prerequisites for adopting MCP in network management.

  2.  Problem Statement

     Modern networks face increasing complexity due to scale,
     heterogeneity, and dynamic service demands.  Operators struggle with:

     *  *Intent-to-Action Gap*: Natural-language requests (e.g., “Fix slow
        video calls in Building B”) cannot be directly translated into
        coordinated network operations across devices and domains.

     *  *Tool Fragmentation*: Capabilities like ping, route lookup, or ACL
        modification exist but are exposed via disparate protocols (CLI,
        YANG RPCs, gNMI), making them inaccessible to generic AI agents.




  Zeng                     Expires 18 August 2026                 [Page 2]


  Internet-Draft  MCP for Network Management: Problem Stat   February 2026


     *  *Lack of Contextual Awareness*: Current systems do not provide
        structured, machine-readable context (e.g., topology, policy
        constraints, historical baselines) needed for intelligent
        reasoning.

     *  *Multi-Vendor Interoperability Gap*: In heterogeneous networks,
        the lack of a common semantic and syntactic interface for
        management operations forces operators to develop and maintain
        vendor-specific automation scripts.  This drastically reduces
        operational efficiency and blocks the deployment of unified AI-
        driven management across domains.

     Existing management frameworks address parts of these issues but lack
     a lightweight, agent-centric protocol that decouples AI logic from
     network implementation details.  MCP fills this gap by providing a
     uniform, JSON-RPC–based interface for AI agents to securely interact
     with network elements as first-class tools.

     Without standardizing how networks expose capabilities to AI agents,
     the industry risks fragmented, vendor-specific integrations that
     hinder interoperability, auditability, and safe automation.

  3.  Use Cases

     This section describes four representative use cases where MCP
     enables intelligent, intent-driven network management.

  3.1.  Troubleshooting

     An operator reports: “Users in Floor 3 cannot reach the cloud
     application.”

     Under this scenario, the MCP Workflow runs as follows: The LLM
     interprets the intent and identifies required tools:
     get_interface_status, ping, show_route, check_acl.  The MCP Client
     (in controller or local device) invokes these tools across relevant
     switches and routers.  In D2D (Device-to-Device) mode, affected
     devices collaboratively gather data even if the controller is
     unreachable.  The LLM correlates results and concludes: “ACL
     ‘block_external’ on Switch-F3 denies outbound traffic.” A repair
     suggestion is generated and presented for approval.

     The MCP Workflow reduces mean time to resolution (MTTR) from hours to
     minutes with explainable root-cause analysis.







  Zeng                     Expires 18 August 2026                 [Page 3]


  Internet-Draft  MCP for Network Management: Problem Stat   February 2026


  3.2.  Network Measurement

     An operator requests: “Monitor end-to-end latency between all branch
     offices every 5 minutes and alert if >50ms.”

     Under this scenario, the MCP Workflow runs as follows: The request is
     parsed into a recurring measurement task.  MCP Tools such as
     measure_latency, collect_interface_stats, and query_bgp_rib are
     scheduled across edge routers.  Structured results (with timestamps,
     paths, and metadata) are returned via MCP Resources.  The LLM detects
     anomalies using historical baselines and triggers alerts or auto-
     remediation.

     The MCP Workflow enables continuous, intent-defined observability
     without custom collectors or polling scripts.

  3.3.  Security Operations

     An operator requests: “Detect and isolate any device exhibiting
     abnormal outbound traffic patterns.”

     Under this scenario, the MCP Workflow runs as follows: The security
     AI agent subscribes to flow data via MCP Resource netflow_records.
     Upon anomaly detection (e.g., sudden spike to unknown IP), it invokes
     get_device_info, list_connected_hosts, and apply_quarantine_acl.  All
     actions are logged with cryptographic signatures for compliance.  The
     agent may also query external threat intelligence via an external MCP
     Server.

     The MCP Workflow enables real-time, closed-loop security response.

  3.4.  Network Optimization

     An operator requests: “Optimize WAN bandwidth utilization during
     business hours without violating SLAs.”

     Under this scenario, the MCP Workflow runs as follows: The optimizer
     agent collects real-time metrics (bandwidth_utilization,
     application_qos_stats) via MCP Resources.  It simulates policy
     changes (e.g., adjusting QoS profiles, shifting SD-WAN paths) using
     sandboxed MCP Tools.  After validation, it applies the optimal
     configuration via update_qos_policy or modify_sdwan_rules.  Post-
     change telemetry confirms SLA compliance.

     The MCP Workflow enables continuous, data-driven optimization aligned
     with business intent, reducing manual tuning.





  Zeng                     Expires 18 August 2026                 [Page 4]


  Internet-Draft  MCP for Network Management: Problem Stat   February 2026


  4.  Requirements

     To support the above use cases safely and scalably, MCP-based network
     management must satisfy the following requirements.

  4.1.  Functional Requirements

     FR1 – Capability Exposure  Every network element MUST expose its
        management capabilities as MCP Tools (for actions) and Resources
        (for state), mapped from underlying protocols (e.g., YANG, CLI).

     FR2 – Intent Interpretability  Tools and Resources MUST include
        human- and machine-readable metadata (e.g., descriptions,
        parameter schemas) to enable accurate LLM parsing.

     FR3 – Safety  Destructive operations require explicit user consent.

     FR4 – Progress Feedback  Long-running operations (e.g., packet
        capture) MUST support asynchronous progress notifications.

  4.2.  Security Requirements

     SR1 – Authentication & Authorization  TBD

     SR2 – Least Privilege  Tools MUST be scoped to minimal necessary
        permissions (e.g., “read-only” vs “configure”).

  4.3.  Interoperability & Operational Requirements

     IR1 – Protocol Compliance  MCP implementations MUST conform to the
        latest MCP specification (e.g., JSON-RPC 2.0 over TLS).

     IR2 – YANG Integration  Tools/Resources SHOULD be describable via
        standardized YANG modules (e.g., ietf-mcp-nm).

     IR3 – Backward Compatibility  MCP Servers MUST coexist with existing
        management protocols (NETCONF, SNMP).

     IR4 – Error Handling  Clear error codes and recovery guidance MUST be
        provided for common failure modes (e.g., “tool not supported,”
        “resource locked”).

  5.  Security Considerations

     This document’s requirements (Section 4.2) are designed to mitigate
     risks inherent in AI-driven network control, including prompt
     injection, unauthorized configuration changes, and data leakage.
     Additional considerations include:



  Zeng                     Expires 18 August 2026                 [Page 5]


  Internet-Draft  MCP for Network Management: Problem Stat   February 2026


     *  Avoiding over-reliance on LLM determinism; critical operations
        should require human-in-the-loop confirmation.

     *  Ensuring MCP Server implementations undergo formal security review
        before deployment in production networks.

  6.  IANA Considerations

     TBD

  7.  References

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

     [I-D.yang-nmrg-mcp-nm]
                YUANYUANYANG, Wu, Q., Lopez, D., Moreno, N. R.,
                Tailhardat, L., and G. Zeng, "Applicability of MCP for the
                Network Management", Work in Progress, Internet-Draft,
                draft-yang-nmrg-mcp-nm-01, October 2025,
                <https://datatracker.ietf.org/doc/html/draft-yang-nmrg-
                mcp-nm-01>.

     [I-D.zm-rtgwg-mcp-network-measurement]
                Zeng, G., Mao, J., Liu, B., Geng, N., Shang, X., Gao, Q.,
                and Z. Li, "MCP-based Network Measurement Framework: Using
                Model Context Protocol for Intelligent Network
                Measurement", Work in Progress, Internet-Draft, draft-zm-
                rtgwg-mcp-network-measurement-01, November 2025,
                <https://datatracker.ietf.org/doc/html/draft-zm-rtgwg-mcp-
                network-measurement-01>.

     [I-D.zm-rtgwg-mcp-troubleshooting]
                Zeng, G., Mao, J., Liu, B., Geng, N., Shang, X., Gao, Q.,
                and Z. Li, "Using the Model Context Protocol (MCP) for
                Intent-Based Network Troubleshooting Automation", Work in
                Progress, Internet-Draft, draft-zm-rtgwg-mcp-
                troubleshooting-01, November 2025,
                <https://datatracker.ietf.org/doc/html/draft-zm-rtgwg-mcp-
                troubleshooting-01>.

  Author's Address

     Guanming Zeng
     Huawei
     Email: zengguanming@huawei.com





  Zeng                     Expires 18 August 2026                 [Page 6]


name: draft-nederveld-adl
rev: 01
title: Agent Definition Language (ADL)
time: 2026-03-08T02:02:25Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-22T22:11:54Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T15:14:54.116707+00:00
source: ietf
abstract:
  The Agent Definition Language (ADL) provides a standard JSON-based
     format for describing AI agents.  An ADL document declares an agent's
     identity, capabilities, tools, permissions, security requirements,
     data classification, and runtime configuration in a single, machine-
     readable artifact.  ADL enables discovery, interoperability,
     deployment, and lifecycle management of AI agents across diverse
     platforms and runtimes.  This document defines the structure of ADL
     documents, the semantics of their members, conformance requirements
     for implementations, and the registration of the application/adl+json
     media type.

full_text:
  Individual Submission                                       T. Nederveld
  Internet-Draft                                     Ironstead Group, LLC.
  Intended status: Standards Track                        18 February 2026
  Expires: 22 August 2026


                      Agent Definition Language (ADL)
                           draft-nederveld-adl-01

  Abstract

     The Agent Definition Language (ADL) provides a standard JSON-based
     format for describing AI agents.  An ADL document declares an agent's
     identity, capabilities, tools, permissions, security requirements,
     data classification, and runtime configuration in a single, machine-
     readable artifact.  ADL enables discovery, interoperability,
     deployment, and lifecycle management of AI agents across diverse
     platforms and runtimes.  This document defines the structure of ADL
     documents, the semantics of their members, conformance requirements
     for implementations, and the registration of the application/adl+json
     media type.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 22 August 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



  Nederveld                Expires 22 August 2026                 [Page 1]


  Internet-Draft                     ADL                     February 2026


     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.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.3.  Relationship to Other Specifications  . . . . . . . . . .   5
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Document Structure  . . . . . . . . . . . . . . . . . . . . .   7
       4.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Top-Level Object  . . . . . . . . . . . . . . . . . . . .   7
       4.3.  Extension Mechanism . . . . . . . . . . . . . . . . . . .   8
       4.4.  Pattern Matching  . . . . . . . . . . . . . . . . . . . .   8
     5.  Core Members  . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  ADL Specification . . . . . . . . . . . . . . . . . . . .   9
       5.2.  $schema . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  Name  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.4.  Description . . . . . . . . . . . . . . . . . . . . . . .  10
       5.5.  Version . . . . . . . . . . . . . . . . . . . . . . . . .  10
       5.6.  Lifecycle . . . . . . . . . . . . . . . . . . . . . . . .  10
         5.6.1.  status  . . . . . . . . . . . . . . . . . . . . . . .  11
         5.6.2.  effective_date  . . . . . . . . . . . . . . . . . . .  12
         5.6.3.  sunset_date . . . . . . . . . . . . . . . . . . . . .  12
         5.6.4.  successor . . . . . . . . . . . . . . . . . . . . . .  12
     6.  Agent Identity  . . . . . . . . . . . . . . . . . . . . . . .  12
       6.1.  Id  . . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.2.  Provider  . . . . . . . . . . . . . . . . . . . . . . . .  13
       6.3.  Cryptographic Identity  . . . . . . . . . . . . . . . . .  13
       6.4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.  Model Configuration . . . . . . . . . . . . . . . . . . . . .  15
       7.1.  Model . . . . . . . . . . . . . . . . . . . . . . . . . .  15
       7.2.  System Prompt . . . . . . . . . . . . . . . . . . . . . .  16
         7.2.1.  Template Variable Syntax  . . . . . . . . . . . . . .  16
     8.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .  16
       8.1.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . .  16
       8.2.  Resources . . . . . . . . . . . . . . . . . . . . . . . .  18
       8.3.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.  Permissions . . . . . . . . . . . . . . . . . . . . . . . . .  19
       9.1.  Permissions Model . . . . . . . . . . . . . . . . . . . .  19
         9.1.1.  Conflict Resolution . . . . . . . . . . . . . . . . .  20
       9.2.  Network . . . . . . . . . . . . . . . . . . . . . . . . .  20
       9.3.  Filesystem  . . . . . . . . . . . . . . . . . . . . . . .  20
       9.4.  Environment . . . . . . . . . . . . . . . . . . . . . . .  21



  Nederveld                Expires 22 August 2026                 [Page 2]


  Internet-Draft                     ADL                     February 2026


       9.5.  Execution . . . . . . . . . . . . . . . . . . . . . . . .  21
       9.6.  Resource Limits . . . . . . . . . . . . . . . . . . . . .  21
     10. Security  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
       10.1.  Authentication . . . . . . . . . . . . . . . . . . . . .  22
       10.2.  Encryption . . . . . . . . . . . . . . . . . . . . . . .  22
       10.3.  Attestation  . . . . . . . . . . . . . . . . . . . . . .  22
       10.4.  Data Classification  . . . . . . . . . . . . . . . . . .  22
         10.4.1.  High-Water Mark Rule . . . . . . . . . . . . . . . .  23
         10.4.2.  sensitivity  . . . . . . . . . . . . . . . . . . . .  23
         10.4.3.  categories . . . . . . . . . . . . . . . . . . . . .  24
         10.4.4.  retention  . . . . . . . . . . . . . . . . . . . . .  25
         10.4.5.  handling . . . . . . . . . . . . . . . . . . . . . .  25
         10.4.6.  Profile Extensions . . . . . . . . . . . . . . . . .  26
     11. Runtime Behavior  . . . . . . . . . . . . . . . . . . . . . .  26
       11.1.  Input Handling . . . . . . . . . . . . . . . . . . . . .  26
       11.2.  Output Handling  . . . . . . . . . . . . . . . . . . . .  27
       11.3.  Tool Invocation  . . . . . . . . . . . . . . . . . . . .  27
       11.4.  Error Handling . . . . . . . . . . . . . . . . . . . . .  28
     12. Metadata  . . . . . . . . . . . . . . . . . . . . . . . . . .  29
       12.1.  Authors  . . . . . . . . . . . . . . . . . . . . . . . .  29
       12.2.  License  . . . . . . . . . . . . . . . . . . . . . . . .  29
       12.3.  Documentation  . . . . . . . . . . . . . . . . . . . . .  29
       12.4.  Repository . . . . . . . . . . . . . . . . . . . . . . .  29
       12.5.  Tags . . . . . . . . . . . . . . . . . . . . . . . . . .  29
       12.6.  Example  . . . . . . . . . . . . . . . . . . . . . . . .  29
     13. Profiles  . . . . . . . . . . . . . . . . . . . . . . . . . .  30
     14. Processing ADL Documents  . . . . . . . . . . . . . . . . . .  30
       14.1.  Parsing  . . . . . . . . . . . . . . . . . . . . . . . .  30
       14.2.  Validation . . . . . . . . . . . . . . . . . . . . . . .  30
       14.3.  Unknown Members  . . . . . . . . . . . . . . . . . . . .  32
     15. Interoperability  . . . . . . . . . . . . . . . . . . . . . .  32
       15.1.  A2A Agent Card Generation  . . . . . . . . . . . . . . .  32
       15.2.  MCP Server Configuration . . . . . . . . . . . . . . . .  32
       15.3.  OpenAPI Integration  . . . . . . . . . . . . . . . . . .  33
     16. Errors  . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
       16.1.  Error Format . . . . . . . . . . . . . . . . . . . . . .  33
       16.2.  Error Codes  . . . . . . . . . . . . . . . . . . . . . .  33
       16.3.  Error Source Examples  . . . . . . . . . . . . . . . . .  35
     17. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  36
       17.1.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  36
       17.2.  Profile Registry . . . . . . . . . . . . . . . . . . . .  38
       17.3.  URN Namespace  . . . . . . . . . . . . . . . . . . . . .  41
       17.4.  Well-Known URI . . . . . . . . . . . . . . . . . . . . .  41
     18. Security Considerations . . . . . . . . . . . . . . . . . . .  42
       18.1.  Document Integrity . . . . . . . . . . . . . . . . . . .  42
       18.2.  Sensitive Data in ADL Documents  . . . . . . . . . . . .  42
       18.3.  Template Injection . . . . . . . . . . . . . . . . . . .  43
       18.4.  Information Disclosure . . . . . . . . . . . . . . . . .  43



  Nederveld                Expires 22 August 2026                 [Page 3]


  Internet-Draft                     ADL                     February 2026


       18.5.  Resource Exhaustion  . . . . . . . . . . . . . . . . . .  44
       18.6.  Pattern Matching Abuse . . . . . . . . . . . . . . . . .  44
       18.7.  URI Reference Attacks (SSRF) . . . . . . . . . . . . . .  45
       18.8.  Canonicalization Attacks . . . . . . . . . . . . . . . .  45
       18.9.  Privacy Considerations . . . . . . . . . . . . . . . . .  46
       18.10. Privilege Escalation . . . . . . . . . . . . . . . . . .  46
       18.11. Cross-Origin and Supply Chain Concerns . . . . . . . . .  47
       18.12. Permission Model and Defense in Depth  . . . . . . . . .  48
     19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  48
       19.1.  Normative References . . . . . . . . . . . . . . . . . .  48
       19.2.  Informative References . . . . . . . . . . . . . . . . .  49
     Appendix A.  JSON Schema  . . . . . . . . . . . . . . . . . . . .  50
     Appendix B.  Examples . . . . . . . . . . . . . . . . . . . . . .  50
     Appendix C.  Profiles . . . . . . . . . . . . . . . . . . . . . .  50
       C.1.  Available Profiles  . . . . . . . . . . . . . . . . . . .  51
     Appendix D.  ABNF Grammar . . . . . . . . . . . . . . . . . . . .  51
       D.1.  Cross-Reference Summary . . . . . . . . . . . . . . . . .  52
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  53
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  53

  1.  Introduction

  1.1.  Purpose

     The Agent Definition Language (ADL) provides a standard format for
     describing AI agents.  ADL documents are JSON objects that describe
     an agent's identity, capabilities, tools, permissions, and runtime
     requirements.  This specification describes the structure of ADL
     documents, the semantics of their members, and conformance
     requirements for implementations.

     ADL serves a similar role for AI agents that OpenAPI serves for REST
     APIs, AsyncAPI for event-driven architectures, and WSDL for web
     services.  It enables:

     *  *Discovery:* Agents can be found and understood programmatically.

     *  *Interoperability:* Agents can interact with tools, resources, and
        other agents using a common description format.

     *  *Deployment:* Runtime environments can provision and configure
        agents based on declared requirements.

     *  *Security:* Permission boundaries and security requirements are
        explicitly declared and enforceable.






  Nederveld                Expires 22 August 2026                 [Page 4]


  Internet-Draft                     ADL                     February 2026


     *  *Lifecycle:* Agents can be versioned, tracked through operational
        states, and managed across their entire lifecycle from draft to
        retirement.

  1.2.  Goals

     *  *Portable:* ADL documents describe agents independent of any
        specific runtime, platform, or provider.

     *  *Interoperable:* ADL documents can be transformed into other
        formats (A2A Agent Cards, MCP configurations) and consumed by
        diverse tooling.

     *  *Extensible:* ADL supports profiles that add domain-specific
        requirements without changing the core specification.

     *  *Secure:* Permission boundaries, authentication, and security
        constraints are first-class concepts.

     *  *Machine-readable:* ADL documents are validated against JSON
        Schema and can be processed programmatically.

     *  *Human-friendly:* Clear naming conventions and structures that are
        easy to read and author.

  1.3.  Relationship to Other Specifications

     ADL builds upon and interoperates with:

     *  **JSON [RFC8259] -- ADL documents are valid JSON.

     *  *JSON Schema* [JSON-SCHEMA] -- ADL documents are validated against
        JSON Schema; tool parameters use JSON Schema for types.

     *  *A2A Protocol* [A2A] -- ADL documents can generate A2A Agent
        Cards.

     *  *Model Context Protocol (MCP)* [MCP] -- ADL documents can generate
        MCP server configurations; tools, resources, and prompts align
        with MCP primitives.

     *  *OpenAPI* [OPENAPI] -- ADL can reference OpenAPI specifications
        for HTTP-based tools.

     *  *W3C DIDs* [W3C.DID] / *Verifiable Credentials* [W3C.VC] -- ADL
        supports DIDs for cryptographic identity and VCs for attestations.





  Nederveld                Expires 22 August 2026                 [Page 5]


  Internet-Draft                     ADL                     February 2026


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

     +=============+=====================================================+
     | Term        | Definition                                          |
     +=============+=====================================================+
     | *ADL        | A JSON object that conforms to this                 |
     | document*   | specification.                                      |
     +-------------+-----------------------------------------------------+
     | *agent*     | An AI system capable of autonomous                  |
     |             | operation within defined boundaries,                |
     |             | described by an ADL document.                       |
     +-------------+-----------------------------------------------------+
     | *tool*      | A function or capability that an                    |
     |             | agent can invoke (equivalent to                     |
     |             | "function" in function-calling).                    |
     +-------------+-----------------------------------------------------+
     | *resource*  | A data source that an agent can read                |
     |             | from (e.g., vector store, knowledge                 |
     |             | base, file system).                                 |
     +-------------+-----------------------------------------------------+
     | *prompt*    | A predefined prompt template that an                |
     |             | agent can use.                                      |
     +-------------+-----------------------------------------------------+
     | *profile*   | A set of additional requirements and                |
     |             | members that extend the core ADL                    |
     |             | specification for specific domains.                 |
     +-------------+-----------------------------------------------------+
     | *permission | A category of system access                         |
     | domain*     | (network, filesystem, etc.) that                    |
     |             | defines operational boundaries.                     |
     +-------------+-----------------------------------------------------+
     | *runtime*   | The system or environment that                      |
     |             | executes an agent based on its ADL                  |
     |             | definition.                                         |
     +-------------+-----------------------------------------------------+
     | *model*     | The LLM or other AI model that                      |
     |             | powers the agent's reasoning.                       |
     +-------------+-----------------------------------------------------+

                                    Table 1



  Nederveld                Expires 22 August 2026                 [Page 6]


  Internet-Draft                     ADL                     February 2026


  4.  Document Structure

  4.1.  Media Type

     *  ADL documents use the media type *application/adl+json*.

     *  ADL documents *MUST* be encoded in UTF-8.

     *  ADL documents *MUST* be valid JSON [RFC8259].

     *  Member names *MUST* use *snake_case* (lowercase with underscores).

     *  All timestamps *MUST* be ISO 8601 strings with timezone (e.g.,
        "2026-02-15T14:30:00Z").

     *  All URIs *MUST* conform to [RFC3986].

     *  *YAML authoring and JSON canonical form:* YAML is an authoring
        convenience; JSON is the canonical wire format.  When an ADL
        document is authored in YAML, implementations *MUST* convert it to
        JSON for processing and validation.  The media type application/
        adl+json applies to the JSON canonical form.

  4.2.  Top-Level Object

     An ADL document *MUST* be a single JSON object.

     *Required members:*

     *  adl_spec (Section 5.1)

     *  name (Section 5.3)

     *  description (Section 5.4)

     *  version (Section 5.5)

     *  data_classification (Section 10.4)

     *Optional members:*

     *  $schema, id, provider, cryptographic_identity, lifecycle, model,
        system_prompt, tools, resources, prompts, permissions, security,
        runtime, metadata, profiles

     An ADL document *MUST NOT* contain members not defined by this
     specification, a declared profile, or the extension mechanism.




  Nederveld                Expires 22 August 2026                 [Page 7]


  Internet-Draft                     ADL                     February 2026


  4.3.  Extension Mechanism

     *  *Profiles:* Add domain-specific requirements and members; declared
        in profiles.  See Section 13.

     *  *Extension members:* Custom data without a full profile.  Names
        *MUST* be prefixed with x_ followed by a namespace identifier
        (e.g., x_acme_internal_id).

     Implementations *MUST* preserve extension members when processing but
     *MAY* ignore their contents.  Implementations *MUST NOT* reject
     documents containing unknown x_-prefixed members.

     Extension members (prefixed with x_) *MAY* appear in any object
     within an ADL document, including nested objects such as lifecycle,
     provider, model, permissions, and security.  Extension member names
     *MUST* match the pattern x_ followed by a namespace identifier using
     only lowercase letters, digits, and underscores (e.g.,
     x_acme_internal_id).  Extension member names *MUST* conform to the
     ext-member-name production in Appendix D.

     Example:

     json { "name": "Invoice Processor", "version": "2.0.0", "adl_spec":
     "0.1.0", "description": "Processes and routes invoices.",
     "data_classification": { "sensitivity": "confidential" },
     "x_acme_internal_id": "inv-proc-007", "x_acme_cost_center":
     "engineering", "model": { "name": "acme-large-2024",
     "x_acme_model_tier": "premium" } }

  4.4.  Pattern Matching

     Several ADL members use patterns to specify allowed or denied values.
     ADL defines a minimal pattern syntax based on a subset of glob
     matching rules.  The following constructs are supported:

     1.  *Literal match.* A string with no wildcard characters matches
         only itself.  Matching is case-sensitive unless the underlying
         system is case-insensitive (e.g., Windows filesystem paths).

     2.  *Single-segment wildcard (*).* The * character matches zero or
         more characters within a single segment.  The segment boundary
         depends on context:

         *  *Host patterns* (Section 9.2): segments are separated by .
            (dot). * does not match dots. *.example.com matches
            api.example.com but does not match deep.sub.example.com.




  Nederveld                Expires 22 August 2026                 [Page 8]


  Internet-Draft                     ADL                     February 2026


         *  *Environment variable patterns* (Section 9.4): * matches any
            characters in the variable name.  APP_* matches APP_PORT and
            APP_HOST.

         *  *Command patterns* (Section 9.5): * matches any characters in
            the command name.

     3.  *Multi-segment wildcard (**).* The ** sequence matches zero or
         more path segments including separators.  Valid only in
         filesystem path patterns (Section 9.3). /data/** matches /data/,
         /data/foo, and /data/foo/bar/baz. ** *MUST NOT* appear in host
         patterns, environment variable patterns, or command patterns.

     4.  *Restrictions.* Patterns *MUST* contain wildcards only in the
         positions described above.  Mid-string wildcards (e.g., foo*bar)
         are *NOT RECOMMENDED*; implementations *MAY* reject them.  A bare
         * as an entire pattern (matching everything) is valid but *NOT
         RECOMMENDED* for security-sensitive domains (allowed_hosts,
         allowed_variables).  Implementations *SHOULD* warn when a bare *
         wildcard is used in permission patterns.

     Implementations *MUST* apply patterns using the rules defined in this
     section.  Implementations *MUST NOT* interpret patterns as regular
     expressions.  Formal grammar productions for pattern elements are
     defined in Appendix D.

  5.  Core Members

  5.1.  ADL Specification

     Specifies the ADL specification version the document conforms to.

     *  *REQUIRED.* Value *MUST* be a string in semantic versioning format
        (MAJOR.MINOR.PATCH).  The format *MUST* conform to the semver
        production in Appendix D.

     *  Implementations *MUST* reject documents with an unsupported
        adl_spec version.

     *  Implementations *SHOULD* support documents with the same MAJOR
        version and lower or equal MINOR version.

     *  Pre-release suffixes (e.g., "0.1.0-draft") *MUST NOT* appear in
        adl_spec values.  Only release versions are valid for conformance.
        Pre-release identifiers *MAY* appear in the agent's own version
        member (Section 5.5).

     Example: "adl_spec": "0.1.0"



  Nederveld                Expires 22 August 2026                 [Page 9]


  Internet-Draft                     ADL                     February 2026


  5.2.  $schema

     Optional.  URI reference to the JSON Schema for validation.
     *RECOMMENDED* for JSON documents (enables IDE validation).  Canonical
     schema URI for ADL 0.1: https://adl-spec.org/0.1/schema.json.

  5.3.  Name

     Human-readable name for the agent. *REQUIRED.* Value *MUST* be a non-
     empty string.  For machine identifiers, use id (Section 6.1).

  5.4.  Description

     Human-readable description of the agent's purpose and capabilities.
     *REQUIRED.* Value *MUST* be a non-empty string. *SHOULD* be
     sufficient for users to understand what the agent does without
     examining tool definitions.

  5.5.  Version

     Agent's version. *REQUIRED.* Value *MUST* be a string in semantic
     versioning format (MAJOR.MINOR.PATCH); the format *MUST* conform to
     the semver production in Appendix D.  Agent version changes *SHOULD*
     follow SemVer (MAJOR: breaking; MINOR: new capabilities; PATCH:
     fixes, docs).

  5.6.  Lifecycle

     Operational lifecycle status of the agent. *OPTIONAL.* When present,
     value *MUST* be an object containing at minimum a status member.





















  Nederveld                Expires 22 August 2026                [Page 10]


  Internet-Draft                     ADL                     February 2026


     +================+========+==========+==============================+
     | Member         | Type   | Required | Description                  |
     +================+========+==========+==============================+
     | status         | string | REQUIRED | Lifecycle state of the       |
     |                |        |          | agent                        |
     +----------------+--------+----------+------------------------------+
     | effective_date | string | OPTIONAL | ISO 8601 timestamp when      |
     |                |        |          | current status took effect   |
     +----------------+--------+----------+------------------------------+
     | sunset_date    | string | OPTIONAL | ISO 8601 timestamp for       |
     |                |        |          | planned or actual            |
     |                |        |          | retirement                   |
     +----------------+--------+----------+------------------------------+
     | successor      | string | OPTIONAL | URI or URN of the            |
     |                |        |          | replacement agent            |
     +----------------+--------+----------+------------------------------+

                                    Table 2

  5.6.1.  status

     *REQUIRED* when lifecycle is present.  Value *MUST* be one of:

     +============+=====================================================+
     | Status     | Meaning                                             |
     +============+=====================================================+
     | draft      | Under development; not ready for production use     |
     +------------+-----------------------------------------------------+
     | active     | Operational and available for use                   |
     +------------+-----------------------------------------------------+
     | deprecated | Superseded; discouraged for new use; may be removed |
     +------------+-----------------------------------------------------+
     | retired    | End-of-life; no longer operational                  |
     +------------+-----------------------------------------------------+

                                   Table 3

     When lifecycle is omitted, no lifecycle assertion is made.
     Implementations *MUST NOT* assume a default status.

     Runtimes *SHOULD* check lifecycle.status before provisioning agents.
     Runtimes *SHOULD NOT* provision agents with status draft in
     production environments.  Runtimes *SHOULD* warn users when
     provisioning agents with status deprecated.  Runtimes *MUST NOT*
     provision or execute agents with status retired.






  Nederveld                Expires 22 August 2026                [Page 11]


  Internet-Draft                     ADL                     February 2026


        *Note:* "Provision" and "execute" refer to instantiating an agent
        for operation.  Reading, parsing, validating, analyzing, or
        migrating from an agent definition is unrestricted regardless of
        lifecycle status.

  5.6.2.  effective_date

     When present, value *MUST* be a valid ISO 8601 string with timezone.
     Indicates when the current status took effect.

  5.6.3.  sunset_date

     When present, value *MUST* be a valid ISO 8601 string with timezone.
     Indicates when the agent will be or was retired.  Implementations
     *SHOULD* warn when sunset_date is in the future and within 30 days.
     When sunset_date is in the past and status is deprecated, runtimes
     *SHOULD* treat the agent as retired.

  5.6.4.  successor

     When present, value *MUST* be a string; *SHOULD* be a URI or URN
     identifying the replacement agent (see Section 6.1 for identifier
     formats). *SHOULD* be present when status is deprecated or retired.
     Implementations *SHOULD* warn if successor is present when status is
     active or draft.

     Example:

     json { "lifecycle": { "status": "deprecated", "effective_date":
     "2026-01-15T00:00:00Z", "sunset_date": "2026-08-01T00:00:00Z",
     "successor": "https://acme.example.com/agents/research-assistant" } }

  6.  Agent Identity

  6.1.  Id

     Unique identifier for the agent. *OPTIONAL.* When present, value
     *MUST* be a string and *MUST* be a valid URI [RFC3986] or URN
     [RFC8141].

     Identifier formats, in order of preference:

     1.  *HTTPS URI (RECOMMENDED):* https://{domain}/agents/{name} --
         Provides ownership verification via TLS, direct resolution to the
         agent's ADL document, and natural integration with .well-known
         discovery (Section 6.4).  The domain authority *SHOULD* serve the
         ADL document at the identifier URL with media type application/
         adl+json.



  Nederveld                Expires 22 August 2026                [Page 12]


  Internet-Draft                     ADL                     February 2026


     2.  *Decentralized Identifier:* did:web:{domain}:agents:{name} --
         Provides cryptographic identity binding via the DID Document.
         Resolution follows the did:web method specification [W3C.DID].
         *RECOMMENDED* when cryptographic verification of agent identity
         is required independent of transport.

     3.  *URN (offline/catalog use):* urn:adl:{namespace}:{name}:{version}
         -- Location-independent identifier suitable for air-gapped
         environments, offline catalogs, and internal registries where
         network resolution is unavailable.  URN identifiers provide
         naming only; they do not support ownership verification or
         discovery without an external resolver.

     When an agent has both a resolvable identifier (HTTPS URI or DID) and
     a URN, the resolvable identifier *SHOULD* be used as the primary id
     value.  The URN *MAY* be recorded in metadata for catalog
     interoperability.

        *Note:* The urn:adl: namespace identifier is used as a convention
        in this specification but is not yet a registered URN namespace
        per [RFC8141].  Formal registration with IANA will be pursued in a
        future revision.  Implementations *SHOULD NOT* assume that
        urn:adl: URNs are globally resolvable.

  6.2.  Provider

     Identifies the organization or entity that provides the agent.
     *OPTIONAL.* When present, value *MUST* be an object:

              +=========+========+==========+==================+
              | Member  | Type   | Required | Description      |
              +=========+========+==========+==================+
              | name    | string | REQUIRED | Provider name    |
              +---------+--------+----------+------------------+
              | url     | string | OPTIONAL | Provider website |
              +---------+--------+----------+------------------+
              | contact | string | OPTIONAL | Contact email    |
              +---------+--------+----------+------------------+

                                   Table 4

  6.3.  Cryptographic Identity

     Cryptographic identification for the agent. *OPTIONAL.* When present,
     value *MUST* be an object:






  Nederveld                Expires 22 August 2026                [Page 13]


  Internet-Draft                     ADL                     February 2026


          +============+========+==========+========================+
          | Member     | Type   | Required | Description            |
          +============+========+==========+========================+
          | did        | string | OPTIONAL | Decentralized          |
          |            |        |          | Identifier [W3C.DID]   |
          +------------+--------+----------+------------------------+
          | public_key | object | OPTIONAL | Public key for         |
          |            |        |          | signature verification |
          +------------+--------+----------+------------------------+

                                    Table 5

     At least one of did or public_key *SHOULD* be present.  The
     public_key object, when present, *MUST* contain algorithm (string,
     REQUIRED) and value (string, Base64-encoded, REQUIRED).
     Implementations *SHOULD* reject weak algorithms (e.g., RSA below 2048
     bits, DSA, ECDSA below P-256).  EdDSA (Ed25519, Ed448) is
     *RECOMMENDED*.

     Example (agent identity with DID and public key):

     json { "id": "https://acme.example.com/agents/invoice-processor",
     "provider": { "name": "Acme Corp", "url": "https://acme.example.com",
     "contact": "ai-platform@acme.example.com" },
     "cryptographic_identity": { "did":
     "did:web:acme.example.com:agents:invoice-processor", "public_key": {
     "algorithm": "Ed25519", "value":
     "MCowBQYDK2VwAyEAGb9ECWmEzf6FQbrBZ9w7lshQhqowtrbLDFw4rXAxZuE=" } } }

  6.4.  Discovery

     Agent discovery enables clients to locate agents published by a
     domain without prior knowledge of individual agent identifiers.
     Domains hosting ADL agents *MAY* publish a discovery document at the
     well-known URI [RFC8615]:

     https://{domain}/.well-known/adl-agents

     The discovery document, when present, *MUST* be a JSON object served
     with media type application/json and *MUST* contain an agents array.
     Each entry in the array *MUST* be an object with at least id (string,
     the agent's identifier per Section 6.1) and adl_document (string, URL
     to the full ADL document).  Entries *MAY* include name, version,
     description, and status.

     Example discovery document:





  Nederveld                Expires 22 August 2026                [Page 14]


  Internet-Draft                     ADL                     February 2026


     json { "adl_discovery": "1.0", "agents": [ { "id":
     "https://acme.example.com/agents/invoice-processor", "adl_document":
     "https://acme.example.com/agents/invoice-processor/adl.json", "name":
     "Invoice Processor", "version": "2.0.0", "status": "active" }, {
     "id": "https://acme.example.com/agents/research-assistant",
     "adl_document": "https://acme.example.com/agents/research-assistant/
     adl.json", "name": "Research Assistant", "version": "2.1.0",
     "status": "active" } ] }

     Clients performing discovery *MUST* fetch the discovery document over
     HTTPS.  Clients *SHOULD* validate the TLS certificate chain.  The
     discovery document *SHOULD* be cacheable; servers *SHOULD* set
     appropriate Cache-Control headers.

        *Note:* Registration of .well-known/adl-agents with IANA per
        [RFC8615] will be pursued alongside the IETF Internet-Draft
        submission.

  7.  Model Configuration

  7.1.  Model

     AI model configuration. *OPTIONAL.* When omitted, the runtime
     determines the model.  When present, value *MUST* be an object:

     +================+========+==========+=============================+
     | Member         | Type   | Required | Description                 |
     +================+========+==========+=============================+
     | provider       | string | OPTIONAL | Model provider identifier   |
     +----------------+--------+----------+-----------------------------+
     | name           | string | OPTIONAL | Model identifier            |
     +----------------+--------+----------+-----------------------------+
     | version        | string | OPTIONAL | Model version               |
     +----------------+--------+----------+-----------------------------+
     | context_window | number | OPTIONAL | Max context window (tokens) |
     +----------------+--------+----------+-----------------------------+
     | temperature    | number | OPTIONAL | Sampling temperature        |
     |                |        |          | (0.0-2.0)                   |
     +----------------+--------+----------+-----------------------------+
     | max_tokens     | number | OPTIONAL | Max output tokens           |
     +----------------+--------+----------+-----------------------------+
     | capabilities   | array  | OPTIONAL | Required model capabilities |
     +----------------+--------+----------+-----------------------------+

                                   Table 6

     capabilities values may include: function_calling, vision,
     code_execution, streaming.



  Nederveld                Expires 22 August 2026                [Page 15]


  Internet-Draft                     ADL                     February 2026


  7.2.  System Prompt

     System prompt for the agent. *OPTIONAL.* Value *MUST* be a string or
     an object.  When an object, it *MUST* contain template (string,
     REQUIRED) and *MAY* contain variables (object).

  7.2.1.  Template Variable Syntax

     Variables in templates use the {{variable_name}} syntax and *MUST*
     conform to the template-var production in Appendix D.  Variable names
     *MUST* begin with a letter (A-Z or a-z) and *MAY* contain letters,
     digits, and underscores.

     *Escaping:* To include a literal {{ in template text without
     triggering variable substitution, implementations *MUST* support the
     escape sequence \{{. A \{{ in the template string is rendered as {{
     and is not treated as a variable reference.

     *Undefined variables:* When a template references a variable name not
     present in variables, the implementation *MUST* treat this as an
     error (error code ADL-1006) and *MUST NOT* silently substitute an
     empty string.  Implementations *SHOULD* include the undefined
     variable name in the error detail.

     Example:

     json { "model": { "provider": "acme-ai", "name": "acme-large-2024",
     "context_window": 200000, "temperature": 0.7, "max_tokens": 4096,
     "capabilities": ["function_calling", "vision"] }, "system_prompt": {
     "template": "You are a helpful assistant for {{company_name}}. Today
     is {{current_date}}.", "variables": { "company_name": "Acme Corp",
     "current_date": "2026-02-18" } } }

  8.  Capabilities

  8.1.  Tools

     Array of tool objects (functions the agent can invoke). *OPTIONAL.*
     Each tool *MUST* contain name (string, REQUIRED) and description
     (string, REQUIRED).  Each tool *MAY* contain: parameters (JSON
     Schema), returns (JSON Schema), examples, requires_confirmation
     (bool), idempotent (bool), read_only (bool), annotations,
     data_classification (Section 10.4).  Tool names *MUST* be unique,
     *MUST* match ^[a-z][a-z0-9_]*$, and *MUST* conform to the tool-name
     production in Appendix D.  The parameters and returns objects, when
     present, *MUST* be valid JSON Schema.





  Nederveld                Expires 22 August 2026                [Page 16]


  Internet-Draft                     ADL                     February 2026


     The examples member, when present, *MUST* be an array of example
     objects.  Each example object *MAY* contain:

     +========+========+==========+=====================================+
     | Member | Type   | Required | Description                         |
     +========+========+==========+=====================================+
     | name   | string | OPTIONAL | Human-readable name for the example |
     +--------+--------+----------+-------------------------------------+
     | input  | object | OPTIONAL | Example input parameters            |
     +--------+--------+----------+-------------------------------------+
     | output | any    | OPTIONAL | Expected output value               |
     +--------+--------+----------+-------------------------------------+

                                   Table 7

     The annotations member, when present, *MUST* be an object containing
     implementation hints and metadata.  Annotations is an open object --
     implementations *MAY* add custom keys.  Standard annotation members
     include:

           +==============+========+==========+===================+
           | Member       | Type   | Required | Description       |
           +==============+========+==========+===================+
           | openapi_ref  | string | OPTIONAL | URI to an OpenAPI |
           |              |        |          | specification     |
           +--------------+--------+----------+-------------------+
           | operation_id | string | OPTIONAL | OpenAPI operation |
           |              |        |          | identifier        |
           +--------------+--------+----------+-------------------+

                                   Table 8

     See Section 15.3 for OpenAPI integration details.  Implementations
     *MUST* preserve all annotation members when processing, including
     unrecognized keys.

     Example:














  Nederveld                Expires 22 August 2026                [Page 17]


  Internet-Draft                     ADL                     February 2026


     json { "tools": [ { "name": "search_invoices", "description": "Search
     for invoices by vendor name, date range, or amount.", "parameters": {
     "type": "object", "properties": { "vendor": { "type": "string",
     "description": "Vendor name to search" }, "date_from": { "type":
     "string", "format": "date" }, "date_to": { "type": "string",
     "format": "date" } }, "required": [] }, "returns": { "type": "array",
     "items": { "type": "object" } }, "examples": [ { "name": "Search by
     vendor", "input": { "vendor": "Acme Supplies" }, "output": [{ "id":
     "INV-001", "amount": 1500.00 }] } ], "idempotent": true, "read_only":
     true, "annotations": { "openapi_ref": "https://api.acme.example.com/
     openapi.json", "operation_id": "searchInvoices" },
     "data_classification": { "sensitivity": "confidential" } } ] }

  8.2.  Resources

     Array of resource objects (data sources the agent can access).
     *OPTIONAL.* Each resource *MUST* contain name (string, REQUIRED) and
     type (string, REQUIRED). type *MUST* be one of: vector_store,
     knowledge_base, file, api, database.  Each resource *MAY* contain:
     description, uri, mime_types, schema, annotations,
     data_classification (Section 10.4).  Resource names *MUST* be unique.

     The mime_types member, when present, *MUST* be an array of strings.
     Each value *MUST* be a valid MIME type (e.g., "application/json",
     "text/plain").

     The schema member, when present, *MUST* be a valid JSON Schema
     describing the structure of the resource's data.

     The annotations member, when present, *MUST* be an object.  Same
     semantics as tool.annotations -- an open object for implementation
     hints that *MUST* be preserved when processing.

     Example:

     json { "resources": [ { "name": "invoice_store", "type":
     "vector_store", "description": "Vector store containing indexed
     invoice documents for semantic search.", "uri":
     "https://store.acme.example.com/invoices", "mime_types":
     ["application/pdf", "application/json"], "data_classification": {
     "sensitivity": "confidential" } } ] }










  Nederveld                Expires 22 August 2026                [Page 18]


  Internet-Draft                     ADL                     February 2026


  8.3.  Prompts

     Array of prompt objects (reusable prompt templates). *OPTIONAL.* Each
     prompt *MUST* contain name (string, REQUIRED) and template (string,
     REQUIRED).  Each prompt *MAY* contain description, arguments (JSON
     Schema).  Template arguments use {{argument_name}} and *MUST* conform
     to the template-var production in Appendix D.  Prompt names *MUST* be
     unique.

     Example:

     json { "prompts": [ { "name": "summarize_invoice", "description":
     "Summarizes an invoice for a reviewer.", "template": "Summarize the
     following invoice for
     {{reviewer_role}}:\n\n{{invoice_text}}\n\nHighlight amounts over
     {{threshold}}.", "arguments": { "type": "object", "properties": {
     "reviewer_role": { "type": "string" }, "invoice_text": { "type":
     "string" }, "threshold": { "type": "number" } }, "required":
     ["reviewer_role", "invoice_text"] } } ] }

  9.  Permissions

     The permissions member defines the agent's operational boundaries.
     *OPTIONAL.* When present, value *MUST* be an object containing one or
     more permission domain members.

  9.1.  Permissions Model

              +=================+==============================+
              | Domain          | Description                  |
              +=================+==============================+
              | network         | Network access boundaries    |
              +-----------------+------------------------------+
              | filesystem      | Filesystem access boundaries |
              +-----------------+------------------------------+
              | environment     | Environment variable access  |
              +-----------------+------------------------------+
              | execution       | Process execution boundaries |
              +-----------------+------------------------------+
              | resource_limits | Resource consumption limits  |
              +-----------------+------------------------------+

                                   Table 9








  Nederveld                Expires 22 August 2026                [Page 19]


  Internet-Draft                     ADL                     February 2026


     Permissions operate on a *deny-by-default* model.  Runtimes *MUST*
     deny any capability not explicitly granted in the permissions member.
     Runtimes *MUST* enforce declared permissions.  Runtimes that cannot
     enforce a specific permission domain *MUST* warn users before
     execution and *SHOULD* refuse to execute the agent unless the user
     explicitly acknowledges the limitation.

     When the permissions member is omitted from an ADL document, no
     permissions are granted to the agent.  Runtimes *MUST* treat the
     absence of permissions as equivalent to an empty permissions object
     -- the agent has no granted capabilities.

     When a specific permission domain (e.g., network, filesystem) is
     omitted from the permissions object, all operations in that domain
     are denied.  For example, if permissions is present but does not
     contain network, the agent *MUST* have no network access.

     Runtimes *MUST NOT* infer, assume, or provide default permissions
     when permissions or a permission domain is absent.

  9.1.1.  Conflict Resolution

     When a value matches both an allowed_* pattern and a denied_* pattern
     within the same permission domain, the denied_* pattern *MUST* take
     precedence.  The agent *MUST NOT* be granted access to any value
     matched by a denied_* pattern, regardless of whether it also matches
     an allowed_* pattern.  This deny-takes-precedence rule ensures that
     explicit exclusions cannot be overridden by broad allow patterns.

     Example: If allowed_variables is ["APP_*"] and denied_variables is
     ["APP_SECRET_*"], the variable APP_SECRET_KEY is *denied* even though
     it matches APP_*.

  9.2.  Network

     May contain: allowed_hosts (array of host patterns), allowed_ports,
     allowed_protocols, deny_private (bool).  Host patterns support exact
     match and *.example.com.

     Host patterns in allowed_hosts *MUST* conform to the pattern syntax
     defined in Section 4.4.

  9.3.  Filesystem

     May contain: allowed_paths (array of { path, access } where access is
     read, write, or read_write), denied_paths.





  Nederveld                Expires 22 August 2026                [Page 20]


  Internet-Draft                     ADL                     February 2026


     Path patterns in allowed_paths[*].path and denied_paths *MUST*
     conform to the pattern syntax defined in Section 4.4.  The ** multi-
     segment wildcard is valid in filesystem path patterns.

  9.4.  Environment

     May contain: allowed_variables, denied_variables (patterns with
     wildcards, e.g., APP_*).

     Variable patterns in allowed_variables and denied_variables *MUST*
     conform to the pattern syntax defined in Section 4.4.

  9.5.  Execution

     May contain: allowed_commands, denied_commands, allow_shell (bool).

     Command patterns in allowed_commands and denied_commands *MUST*
     conform to the pattern syntax defined in Section 4.4.

  9.6.  Resource Limits

     May contain: max_memory_mb, max_cpu_percent, max_duration_sec,
     max_concurrent.

     Example (complete permissions object):

     json { "permissions": { "network": { "allowed_hosts":
     ["api.acme.example.com", "*.storage.example.com"], "allowed_ports":
     [443], "allowed_protocols": ["https"], "deny_private": true },
     "filesystem": { "allowed_paths": [ { "path": "/data/invoices/**",
     "access": "read" }, { "path": "/tmp/processing/**", "access":
     "read_write" } ], "denied_paths": ["/tmp/processing/**/secrets"] },
     "environment": { "allowed_variables": ["APP_*", "INVOICE_*"],
     "denied_variables": ["APP_SECRET_*"] }, "execution": {
     "allowed_commands": ["python3", "jq"], "allow_shell": false },
     "resource_limits": { "max_memory_mb": 512, "max_cpu_percent": 25,
     "max_duration_sec": 300 } } }

  10.  Security

     The security member defines security requirements. *OPTIONAL.* When
     present, value *MUST* be an object that *MAY* contain authentication,
     encryption, and attestation.








  Nederveld                Expires 22 August 2026                [Page 21]


  Internet-Draft                     ADL                     February 2026


  10.1.  Authentication

     May contain: type (one of none, api_key, oauth2, oidc, mtls),
     required (bool).  Type-specific members (e.g., OAuth2: scopes,
     token_endpoint; OIDC: issuer, audience) *MAY* be present.

  10.2.  Encryption

     May contain: in_transit (required, min_version), at_rest (required,
     algorithm).

  10.3.  Attestation

     May contain: type (one of self, third_party, verifiable_credential),
     issuer, issued_at, expires_at (ISO 8601), signature (object).
     Implementations *SHOULD* warn when expires_at is in the past or
     within 30 days.

     *Signature object:* When present, *MUST* contain algorithm, value
     (Base64url-encoded), signed_content ("canonical" or "digest").  When
     signed_content is "digest", *MUST* also include digest_algorithm and
     digest_value.  Supported algorithms include Ed25519 (RECOMMENDED),
     Ed448, ES256/384/512, RS256, PS256 (RSA >= 2048).  Verification:
     remove signature, serialize with JCS [RFC8785], verify digest if
     applicable, resolve public key from cryptographic_identity, verify
     signature.

     Example:

     json { "security": { "authentication": { "type": "oauth2",
     "required": true, "scopes": ["invoices:read", "invoices:write"],
     "token_endpoint": "https://auth.acme.example.com/oauth/token" },
     "encryption": { "in_transit": { "required": true, "min_version":
     "TLS1.3" }, "at_rest": { "required": true, "algorithm": "AES-256-GCM"
     } }, "attestation": { "type": "third_party", "issuer":
     "https://trust.acme.example.com", "issued_at":
     "2026-01-01T00:00:00Z", "expires_at": "2027-01-01T00:00:00Z" } } }

  10.4.  Data Classification

     The data_classification member declares the sensitivity and
     categories of data the agent may access, process, or produce.
     *REQUIRED.* Value *MUST* be an object.

     Data classification is required by NIST FIPS 199, NIST SP 800-60, ISO
     27001:2022 Annex A.5.12, FedRAMP, SOC 2, and CMMC.  It is the
     foundational step of security categorization across all major
     compliance frameworks.



  Nederveld                Expires 22 August 2026                [Page 22]


  Internet-Draft                     ADL                     February 2026


     This member is a *reusable composable attribute*. In addition to the
     required top-level declaration, it *MAY* also appear within
     individual tools[*] or resources[*] objects to classify specific
     capabilities.  When present on both the top level and a tool or
     resource, the tool/resource-level classification applies to that
     capability.

  10.4.1.  High-Water Mark Rule

     The top-level data_classification.sensitivity *MUST* be greater than
     or equal to the highest sensitivity value declared in any tool-level
     or resource-level data_classification within the same document.  This
     follows the FIPS 199 high-water mark principle: a system's overall
     security categorization is the highest value among its constituent
     information types.

     The sensitivity ordering from lowest to highest is: public < internal
     < confidential < restricted.

     Sensitivity levels align with NIST FIPS 199 impact categorization and
     ISO 27001:2022 Annex A.5.12 information classification.

      +=============+========+==========+===============================+
      | Member      | Type   | Required | Description                   |
      +=============+========+==========+===============================+
      | sensitivity | string | REQUIRED | Information sensitivity level |
      +-------------+--------+----------+-------------------------------+
      | categories  | array  | OPTIONAL | Broad information categories  |
      |             |        |          | handled                       |
      +-------------+--------+----------+-------------------------------+
      | retention   | object | OPTIONAL | Data retention requirements   |
      +-------------+--------+----------+-------------------------------+
      | handling    | object | OPTIONAL | Data handling constraints     |
      +-------------+--------+----------+-------------------------------+

                                    Table 10

  10.4.2.  sensitivity

     *REQUIRED* when data_classification is present.  Value *MUST* be one
     of:










  Nederveld                Expires 22 August 2026                [Page 23]


  Internet-Draft                     ADL                     February 2026


          +==============+==========================================+
          | Value        | Definition                               |
          +==============+==========================================+
          | public       | Information approved for unrestricted    |
          |              | disclosure                               |
          +--------------+------------------------------------------+
          | internal     | Information limited to organizational    |
          |              | use                                      |
          +--------------+------------------------------------------+
          | confidential | Information requiring protection;        |
          |              | unauthorized disclosure could cause harm |
          +--------------+------------------------------------------+
          | restricted   | Information requiring the highest level  |
          |              | of protection; unauthorized disclosure   |
          |              | could cause severe harm                  |
          +--------------+------------------------------------------+

                                    Table 11

  10.4.3.  categories

     When present, *MUST* be a non-empty array.  Each item *MUST* be one
     of:

     +=======================+===========================================+
     | Value                 | Definition                                |
     +=======================+===========================================+
     | pii                   | Personally Identifiable Information       |
     +-----------------------+-------------------------------------------+
     | phi                   | Protected Health Information (HIPAA)      |
     +-----------------------+-------------------------------------------+
     | financial             | Financial data (PCI-DSS, GLBA, SOX        |
     |                       | scope)                                    |
     +-----------------------+-------------------------------------------+
     | credentials           | Authentication credentials, secrets,      |
     |                       | keys                                      |
     +-----------------------+-------------------------------------------+
     | intellectual_property | Trade secrets, proprietary                |
     |                       | algorithms, business-sensitive data       |
     +-----------------------+-------------------------------------------+
     | regulatory            | Data subject to specific regulatory       |
     |                       | requirements                              |
     +-----------------------+-------------------------------------------+

                                    Table 12

     Profiles *MAY* define additional category values.




  Nederveld                Expires 22 August 2026                [Page 24]


  Internet-Draft                     ADL                     February 2026


  10.4.4.  retention

     When present, *MUST* be an object. *MAY* contain:

        +============+========+=======================================+
        | Member     | Type   | Description                           |
        +============+========+=======================================+
        | min_days   | number | Minimum retention period in days      |
        +------------+--------+---------------------------------------+
        | max_days   | number | Maximum retention period in days      |
        +------------+--------+---------------------------------------+
        | policy_uri | string | URI to the governing retention policy |
        +------------+--------+---------------------------------------+

                                    Table 13

     When both min_days and max_days are present, min_days *MUST* be less
     than or equal to max_days.

  10.4.5.  handling

     When present, *MUST* be an object. *MAY* contain:

       +=========================+======+==============================+
       | Member                  | Type | Description                  |
       +=========================+======+==============================+
       | encryption_required     | bool | Whether data must be         |
       |                         |      | encrypted at rest            |
       +-------------------------+------+------------------------------+
       | anonymization_required  | bool | Whether data must be         |
       |                         |      | anonymized before processing |
       +-------------------------+------+------------------------------+
       | cross_border_restricted | bool | Whether data may not leave   |
       |                         |      | jurisdictional boundaries    |
       +-------------------------+------+------------------------------+
       | logging_required        | bool | Whether all access must be   |
       |                         |      | logged                       |
       +-------------------------+------+------------------------------+

                                    Table 14











  Nederveld                Expires 22 August 2026                [Page 25]


  Internet-Draft                     ADL                     February 2026


  10.4.6.  Profile Extensions

     Profiles *MAY* add domain-specific sub-objects within
     data_classification to provide granular classification vocabularies.
     For example, a healthcare profile may add a healthcare sub-object
     with PHI type enumerations, and a financial profile may add a
     financial sub-object with financial data type enumerations.  Multiple
     profile extensions compose naturally within the same
     data_classification object.  See Section 13 for profile composition
     rules.

     Example (top-level and tool-level data classification demonstrating
     the high-water mark rule):

     json { "data_classification": { "sensitivity": "confidential",
     "categories": ["financial", "pii"], "retention": { "max_days": 2555,
     "policy_uri": "https://acme.example.com/data-retention" },
     "handling": { "encryption_required": true, "logging_required": true }
     }, "tools": [ { "name": "get_invoice_details", "description":
     "Returns detailed invoice data including PII.",
     "data_classification": { "sensitivity": "confidential", "categories":
     ["financial", "pii"] } }, { "name": "get_invoice_summary",
     "description": "Returns anonymized invoice summary.",
     "data_classification": { "sensitivity": "internal" } } ] }

     The top-level sensitivity of "confidential" satisfies the high-water
     mark rule: it equals the highest tool-level value ("confidential" for
     get_invoice_details).

  11.  Runtime Behavior

     The runtime member configures agent runtime behavior. *OPTIONAL.*
     When present, value *MUST* be an object.

  11.1.  Input Handling

     May contain: max_input_length, content_types, sanitization.

     The sanitization member, when present, *MUST* be an object describing
     input sanitization rules.  It *MAY* contain:











  Nederveld                Expires 22 August 2026                [Page 26]


  Internet-Draft                     ADL                     February 2026


      +==================+=========+==========+========================+
      | Member           | Type    | Required | Description            |
      +==================+=========+==========+========================+
      | enabled          | boolean | OPTIONAL | Whether input          |
      |                  |         |          | sanitization is active |
      +------------------+---------+----------+------------------------+
      | strip_html       | boolean | OPTIONAL | Whether to strip HTML  |
      |                  |         |          | tags from input        |
      +------------------+---------+----------+------------------------+
      | max_input_length | number  | OPTIONAL | Maximum input length   |
      |                  |         |          | in characters          |
      +------------------+---------+----------+------------------------+

                                   Table 15

     The content_types member, when present, *MUST* be an array of
     strings.  Each value *MUST* be a valid MIME type specifying an
     accepted input content type.

  11.2.  Output Handling

     May contain: max_output_length, format, streaming (bool).

     The format member, when present, *MUST* be a string specifying the
     default output format.  Value *MUST* be one of: "text", "json",
     "markdown", "html".

  11.3.  Tool Invocation

     May contain: parallel (bool), max_concurrent, timeout_ms,
     retry_policy.

     The retry_policy member, when present, *MUST* be an object describing
     retry behavior for tool invocations.  It *MAY* contain:

















  Nederveld                Expires 22 August 2026                [Page 27]


  Internet-Draft                     ADL                     February 2026


      +==================+========+==========+=========================+
      | Member           | Type   | Required | Description             |
      +==================+========+==========+=========================+
      | max_retries      | number | OPTIONAL | Maximum number of retry |
      |                  |        |          | attempts                |
      +------------------+--------+----------+-------------------------+
      | backoff_strategy | string | OPTIONAL | One of: "fixed",        |
      |                  |        |          | "exponential", "linear" |
      +------------------+--------+----------+-------------------------+
      | initial_delay_ms | number | OPTIONAL | Initial delay between   |
      |                  |        |          | retries in milliseconds |
      +------------------+--------+----------+-------------------------+
      | max_delay_ms     | number | OPTIONAL | Maximum delay between   |
      |                  |        |          | retries in milliseconds |
      +------------------+--------+----------+-------------------------+

                                   Table 16

  11.4.  Error Handling

     May contain: on_tool_error (abort, continue, or retry), max_retries,
     fallback_behavior.

     The fallback_behavior member, when present, *MUST* be an object
     describing behavior when errors occur and on_tool_error does not
     resolve the situation.  It *MAY* contain:

        +=========+========+==========+==============================+
        | Member  | Type   | Required | Description                  |
        +=========+========+==========+==============================+
        | action  | string | OPTIONAL | One of: "return_error",      |
        |         |        |          | "use_default", "skip"        |
        +---------+--------+----------+------------------------------+
        | default | any    | OPTIONAL | Default value to return when |
        |         |        |          | action is "use_default"      |
        +---------+--------+----------+------------------------------+
        | message | string | OPTIONAL | User-facing message on       |
        |         |        |          | fallback                     |
        +---------+--------+----------+------------------------------+

                                   Table 17

     Example:

     json { "runtime": { "input_handling": { "max_input_length": 32768,
     "content_types": ["text/plain", "application/json"], "sanitization":
     { "enabled": true, "strip_html": true } }, "output_handling": {
     "format": "json", "max_output_length": 8192, "streaming": false },



  Nederveld                Expires 22 August 2026                [Page 28]


  Internet-Draft                     ADL                     February 2026


     "tool_invocation": { "parallel": true, "max_concurrent": 3,
     "timeout_ms": 30000, "retry_policy": { "max_retries": 2,
     "backoff_strategy": "exponential", "initial_delay_ms": 500,
     "max_delay_ms": 5000 } }, "error_handling": { "on_tool_error":
     "retry", "max_retries": 2, "fallback_behavior": { "action":
     "return_error", "message": "Invoice processing temporarily
     unavailable." } } } }

  12.  Metadata

     The metadata member provides additional information. *OPTIONAL.* When
     present, value *MUST* be an object.

  12.1.  Authors

     Array of author objects.  Each *MAY* contain name, email, url.

  12.2.  License

     String: SPDX license identifier or URI to license document.

  12.3.  Documentation

     String: URI to documentation.

  12.4.  Repository

     String: URI to source repository.

  12.5.  Tags

     Array of strings. *SHOULD* be lowercase, alphanumeric and hyphens
     only.  Tags *SHOULD* conform to the tag production in Appendix D.

  12.6.  Example

     json { "metadata": { "authors": [ { "name": "Platform Team", "email":
     "platform@example.com", "url": "https://example.com/team/platform" }
     ], "license": "Apache-2.0", "documentation":
     "https://docs.example.com/agents/invoice-processor", "repository":
     "https://github.com/example/invoice-processor", "tags": ["finance",
     "invoice", "production"] } }









  Nederveld                Expires 22 August 2026                [Page 29]


  Internet-Draft                     ADL                     February 2026


  13.  Profiles

     The profiles member declares which profiles the document conforms to.
     *OPTIONAL.* Value *MUST* be an array of profile identifiers (URIs or
     registered names).  When a profile is declared: the document *MUST*
     satisfy all profile requirements, *MAY* use profile-defined members,
     and validators *SHOULD* check profile-specific rules.  Profiles *MUST
     NOT* redefine core ADL members; they *MAY* add top-level members, add
     members to existing objects, define validation rules, or require
     specific values for optional members.

     *Standard profiles (examples):* Governance
     (urn:adl:profile:governance:1.0), Healthcare, Financial.  Additional
     profiles may be registered (e.g., IANA profile registry).

     Example:

     json { "adl_spec": "0.1.0", "name": "Invoice Processor", "version":
     "2.0.0", "description": "Processes invoices with governance and
     financial compliance.", "data_classification": { "sensitivity":
     "confidential", "categories": ["financial"] }, "profiles": [
     "urn:adl:profile:governance:1.0", "urn:adl:profile:financial:1.0" ] }

  14.  Processing ADL Documents

  14.1.  Parsing

     Implementations *MUST* parse ADL as JSON [RFC8259], *MUST* reject
     invalid JSON, and *MUST* reject documents where the top-level value
     is not a JSON object.

  14.2.  Validation

     Implementations *MUST* validate ADL documents against the JSON Schema
     defined in Appendix A.  Implementations *MUST* validate the following
     semantic rules:

       +========+=====================================================+
       | Rule   | Description                                         |
       +========+=====================================================+
       | VAL-01 | adl_spec MUST match a supported version             |
       +--------+-----------------------------------------------------+
       | VAL-02 | Tool names MUST be unique                           |
       +--------+-----------------------------------------------------+
       | VAL-03 | Resource names MUST be unique                       |
       +--------+-----------------------------------------------------+
       | VAL-04 | Prompt names MUST be unique                         |
       +--------+-----------------------------------------------------+



  Nederveld                Expires 22 August 2026                [Page 30]


  Internet-Draft                     ADL                     February 2026


       | VAL-05 | Timestamps MUST be valid ISO 8601                   |
       +--------+-----------------------------------------------------+
       | VAL-06 | URIs MUST be valid per RFC 3986                     |
       +--------+-----------------------------------------------------+
       | VAL-07 | JSON Schema in parameters/returns MUST be valid     |
       +--------+-----------------------------------------------------+
       | VAL-08 | Profile requirements MUST be satisfied              |
       +--------+-----------------------------------------------------+
       | VAL-09 | lifecycle.status MUST be a valid status value if    |
       |        | present                                             |
       +--------+-----------------------------------------------------+
       | VAL-10 | lifecycle.effective_date MUST be valid ISO 8601 if  |
       |        | present                                             |
       +--------+-----------------------------------------------------+
       | VAL-11 | lifecycle.sunset_date MUST be valid ISO 8601 if     |
       |        | present                                             |
       +--------+-----------------------------------------------------+
       | VAL-12 | lifecycle.successor MUST be a valid URI if present  |
       +--------+-----------------------------------------------------+
       | VAL-13 | Tool names MUST match ^[a-z][a-z0-9_]*$             |
       +--------+-----------------------------------------------------+
       | VAL-14 | Resource type MUST be a valid resource type value   |
       +--------+-----------------------------------------------------+
       | VAL-15 | model.temperature MUST be between 0.0 and 2.0 if    |
       |        | present                                             |
       +--------+-----------------------------------------------------+
       | VAL-16 | security.authentication.type MUST be a valid        |
       |        | authentication type if present                      |
       +--------+-----------------------------------------------------+
       | VAL-17 | security.attestation.type MUST be a valid           |
       |        | attestation type if present                         |
       +--------+-----------------------------------------------------+
       | VAL-18 | runtime.error_handling.on_tool_error MUST be a      |
       |        | valid error action if present                       |
       +--------+-----------------------------------------------------+
       | VAL-19 | runtime.output_handling.format MUST be a valid      |
       |        | format value if present                             |
       +--------+-----------------------------------------------------+
       | VAL-20 | model.capabilities items MUST be valid capability   |
       |        | values if present                                   |
       +--------+-----------------------------------------------------+
       | VAL-21 | Host patterns MUST conform to Section 4.4 pattern   |
       |        | syntax                                              |
       +--------+-----------------------------------------------------+
       | VAL-22 | Filesystem path patterns MUST conform to            |
       |        | Section 4.4 pattern syntax                          |
       +--------+-----------------------------------------------------+
       | VAL-23 | Environment variable patterns MUST conform to       |



  Nederveld                Expires 22 August 2026                [Page 31]


  Internet-Draft                     ADL                     February 2026


       |        | Section 4.4 pattern syntax                          |
       +--------+-----------------------------------------------------+
       | VAL-24 | Attestation signature.signed_content value "digest" |
       |        | MUST have digest_algorithm and digest_value present |
       +--------+-----------------------------------------------------+
       | VAL-25 | data_classification.sensitivity MUST be a valid     |
       |        | sensitivity level if present                        |
       +--------+-----------------------------------------------------+
       | VAL-26 | data_classification.categories items MUST be valid  |
       |        | category values if present                          |
       +--------+-----------------------------------------------------+
       | VAL-27 | data_classification.retention.min_days MUST be less |
       |        | than or equal to max_days when both are present     |
       +--------+-----------------------------------------------------+
       | VAL-28 | Top-level data_classification.sensitivity MUST be   |
       |        | >= the highest sensitivity in any tool or resource  |
       |        | data_classification (high-water mark)               |
       +--------+-----------------------------------------------------+

                                   Table 18

     Implementations *MAY* perform additional validation based on declared
     profiles.

  14.3.  Unknown Members

     Implementations *MUST* preserve unrecognized members when round-
     tripping.  Implementations *MUST NOT* reject documents containing
     unknown x_-prefixed members.  Implementations *MAY* warn on unknown
     non-extension, non-profile members.

  15.  Interoperability

  15.1.  A2A Agent Card Generation

     Implementations *SHOULD* support generating A2A Agent Cards from ADL
     (e.g., name, description, version, tools->skills,
     cryptographic_identity.did->id,
     security.authentication->authentication).

  15.2.  MCP Server Configuration

     Implementations *SHOULD* support generating MCP server configurations
     (name, description, version, tools, resources, prompts).







  Nederveld                Expires 22 August 2026                [Page 32]


  Internet-Draft                     ADL                     February 2026


  15.3.  OpenAPI Integration

     Tools that invoke HTTP APIs *MAY* reference OpenAPI specs.  The tool
     annotations object *MAY* contain openapi_ref (URI) and operation_id.

  16.  Errors

  16.1.  Error Format

     Implementations *SHOULD* return errors in a consistent format, e.g.:

     json { "errors": [ { "code": "ADL-1001", "title": "Invalid JSON",
     "detail": "Unexpected token at line 42, column 15", "source": {
     "pointer": "/tools/0/name" } } ] }

     The source object *MAY* contain: pointer (JSON Pointer to the error
     location), line (1-indexed), column (1-indexed).

  16.2.  Error Codes

     +==========+===========+===========================================+
     | Code     | Category  | Description                               |
     +==========+===========+===========================================+
     | ADL-1001 | Parse     | Invalid JSON syntax                       |
     +----------+-----------+-------------------------------------------+
     | ADL-1002 | Parse     | Document is not a JSON object             |
     +----------+-----------+-------------------------------------------+
     | ADL-1003 | Schema    | Missing required member                   |
     +----------+-----------+-------------------------------------------+
     | ADL-1004 | Schema    | Invalid member type                       |
     +----------+-----------+-------------------------------------------+
     | ADL-1005 | Schema    | Invalid enum value                        |
     +----------+-----------+-------------------------------------------+
     | ADL-1006 | Schema    | Value does not match pattern              |
     +----------+-----------+-------------------------------------------+
     | ADL-2001 | Semantic  | Unsupported ADL version                   |
     +----------+-----------+-------------------------------------------+
     | ADL-2002 | Semantic  | Duplicate tool name                       |
     +----------+-----------+-------------------------------------------+
     | ADL-2003 | Semantic  | Duplicate resource name                   |
     +----------+-----------+-------------------------------------------+
     | ADL-2004 | Semantic  | Duplicate prompt name                     |
     +----------+-----------+-------------------------------------------+
     | ADL-2005 | Semantic  | Invalid timestamp format                  |
     +----------+-----------+-------------------------------------------+
     | ADL-2006 | Semantic  | Invalid URI format                        |
     +----------+-----------+-------------------------------------------+
     | ADL-2007 | Semantic  | Invalid JSON Schema                       |



  Nederveld                Expires 22 August 2026                [Page 33]


  Internet-Draft                     ADL                     February 2026


     +----------+-----------+-------------------------------------------+
     | ADL-2008 | Semantic  | Invalid tool name pattern                 |
     +----------+-----------+-------------------------------------------+
     | ADL-2009 | Semantic  | Invalid resource type value               |
     +----------+-----------+-------------------------------------------+
     | ADL-2010 | Semantic  | Temperature out of range                  |
     +----------+-----------+-------------------------------------------+
     | ADL-2011 | Semantic  | Invalid authentication type               |
     +----------+-----------+-------------------------------------------+
     | ADL-2012 | Semantic  | Invalid attestation type                  |
     +----------+-----------+-------------------------------------------+
     | ADL-2013 | Semantic  | Invalid error handling action             |
     +----------+-----------+-------------------------------------------+
     | ADL-2014 | Semantic  | Invalid output format                     |
     +----------+-----------+-------------------------------------------+
     | ADL-2015 | Semantic  | Invalid model capability                  |
     +----------+-----------+-------------------------------------------+
     | ADL-2016 | Semantic  | Invalid host pattern syntax               |
     +----------+-----------+-------------------------------------------+
     | ADL-2017 | Semantic  | Invalid filesystem path pattern           |
     +----------+-----------+-------------------------------------------+
     | ADL-2018 | Semantic  | Invalid environment variable pattern      |
     +----------+-----------+-------------------------------------------+
     | ADL-2019 | Semantic  | Missing digest fields for digest-mode     |
     |          |           | signature                                 |
     +----------+-----------+-------------------------------------------+
     | ADL-2020 | Semantic  | Invalid data classification sensitivity   |
     |          |           | level                                     |
     +----------+-----------+-------------------------------------------+
     | ADL-2021 | Semantic  | Invalid data classification category      |
     +----------+-----------+-------------------------------------------+
     | ADL-2022 | Semantic  | Retention min_days exceeds max_days       |
     +----------+-----------+-------------------------------------------+
     | ADL-2023 | Semantic  | Top-level sensitivity below tool/resource |
     |          |           | sensitivity (high-water mark violation)   |
     +----------+-----------+-------------------------------------------+
     | ADL-3001 | Profile   | Profile requirements not satisfied        |
     +----------+-----------+-------------------------------------------+
     | ADL-3002 | Profile   | Unknown profile                           |
     +----------+-----------+-------------------------------------------+
     | ADL-4001 | Security  | Weak key algorithm                        |
     +----------+-----------+-------------------------------------------+
     | ADL-4002 | Security  | Invalid signature                         |
     +----------+-----------+-------------------------------------------+
     | ADL-4003 | Security  | Expired attestation                       |
     +----------+-----------+-------------------------------------------+
     | ADL-5001 | Lifecycle | Invalid lifecycle status value            |
     +----------+-----------+-------------------------------------------+



  Nederveld                Expires 22 August 2026                [Page 34]


  Internet-Draft                     ADL                     February 2026


     | ADL-5002 | Lifecycle | Successor present on active/draft agent   |
     +----------+-----------+-------------------------------------------+
     | ADL-5003 | Lifecycle | Sunset date in the past with non-retired  |
     |          |           | status                                    |
     +----------+-----------+-------------------------------------------+

                                   Table 19

  16.3.  Error Source Examples

     The source.pointer member uses JSON Pointer [RFC6901] to identify the
     location of the error within the ADL document.  The following
     examples illustrate source values for representative error codes from
     each category:

     json // ADL-1003 (Schema): Missing required member
     "data_classification" { "code": "ADL-1003", "title": "Missing
     required member", "detail": "Required member 'data_classification' is
     missing", "source": { "pointer": "" } }

     json // ADL-2002 (Semantic): Duplicate tool name at index 2 { "code":
     "ADL-2002", "title": "Duplicate tool name", "detail": "Tool name
     'search_documents' already defined at index 0", "source": {
     "pointer": "/tools/2/name" } }

     json // ADL-2016 (Semantic): Invalid host pattern in permissions {
     "code": "ADL-2016", "title": "Invalid host pattern syntax", "detail":
     "Pattern '**' is not a valid host pattern", "source": { "pointer":
     "/permissions/network/allowed_hosts/1" } }

     json // ADL-2023 (Semantic): High-water mark violation on a tool {
     "code": "ADL-2023", "title": "High-water mark violation", "detail":
     "Tool 'query_records' has sensitivity 'confidential' which exceeds
     top-level 'internal'", "source": { "pointer":
     "/tools/1/data_classification/sensitivity" } }

     json // ADL-3001 (Profile): Profile requirement not satisfied {
     "code": "ADL-3001", "title": "Profile requirements not satisfied",
     "detail": "Governance profile requires 'compliance' member",
     "source": { "pointer": "/profiles/0" } }

     json // ADL-4001 (Security): Weak key algorithm { "code": "ADL-4001",
     "title": "Weak key algorithm", "detail": "Algorithm 'RS256' with
     1024-bit key does not meet minimum strength requirements", "source":
     { "pointer": "/security/attestation/public_key" } }






  Nederveld                Expires 22 August 2026                [Page 35]


  Internet-Draft                     ADL                     February 2026


     json // ADL-5002 (Lifecycle): Successor on active agent { "code":
     "ADL-5002", "title": "Successor present on non-retired agent",
     "detail": "Member 'successor' is only valid when lifecycle.status is
     'retired'", "source": { "pointer": "/lifecycle/successor" } }

  17.  IANA Considerations

  17.1.  Media Type

     This document requests IANA to register the application/adl+json
     media type in the "Media Types" registry in accordance with
     [RFC6838].

     *  *Type name:* application

     *  *Subtype name:* adl+json

     *  *Required parameters:* None

     *  *Optional parameters:*

        -  profile -- A comma-separated list of ADL profile identifiers
           (URIs or registered names from the ADL Profile Registry defined
           in Section 17.2) that the document conforms to.  Each
           identifier *MUST* be a URI conforming to [RFC3986].  Consumers
           that do not recognize a profile identifier *MAY* ignore the
           parameter and *MUST* preserve it when retransmitting the
           document.

     *  *Encoding considerations:* binary -- ADL documents are JSON text
        sequences encoded in UTF-8 [RFC8259].  No other character encoding
        is permitted.  Consistent with [RFC8259], UTF-8 without a byte-
        order mark (BOM) is *RECOMMENDED*.

     *  *Security considerations:* ADL documents declare agent behavior
        including permission grants, system prompt templates, tool
        invocation configuration, and cryptographic identity.  Processors
        *MUST* treat content from untrusted sources with appropriate
        caution.  Template variables in system_prompt and prompt templates
        use a {{variable_name}} substitution syntax; processors *MUST*
        sanitize variable values before substitution to prevent prompt
        injection attacks that could alter agent behavior.  ADL documents
        include URI references in fields such as $schema, openapi_ref,
        documentation, and repository; processors *MUST NOT* automatically
        dereference these URIs from untrusted documents, as doing so may
        target internal network resources and enable Server-Side Request
        Forgery (SSRF).  Documents that declare broad permissions (e.g., a
        bare * wildcard in allowed_hosts) represent elevated risk and



  Nederveld                Expires 22 August 2026                [Page 36]


  Internet-Draft                     ADL                     February 2026


        *SHOULD* require explicit human review before deployment.
        Processors *SHOULD* impose limits on document size, JSON nesting
        depth, and array lengths to prevent resource exhaustion from
        adversarially crafted documents.  For a comprehensive treatment of
        all security considerations applicable to this media type, see
        Section 18.

     *  *Interoperability considerations:* ADL documents *MUST* be
        processed as JSON [RFC8259] regardless of authoring format.  YAML
        is a common authoring convenience, but processors *MUST* operate
        on the JSON form; documents intended to be signed using JCS
        [RFC8785] *MUST* be serialized as JSON before signing.  Profile
        declarations -- whether via the profile optional parameter or the
        profiles document member -- allow multiple profiles to compose
        within a single document; consumers that partially implement
        profile requirements *SHOULD* process the members they recognize
        and preserve unrecognized members per Section 14.3.  Validation
        against the JSON Schema defined in Appendix A provides a baseline
        interoperability check.  Implementations that generate A2A Agent
        Cards or MCP server configurations from ADL documents *SHOULD*
        follow the mappings defined in Section 15.  Producers *SHOULD*
        include the $schema member to enable tooling-assisted validation.

     *  *Published specification:* [this document]

     *  *Applications that use this media type:* AI agent platforms, agent
        registries, development tools, orchestration frameworks, and
        runtime environments that provision and manage AI agents.

     *  *Fragment identifier considerations:* Fragment identifiers for
        resources of this type *SHOULD* be interpreted as JSON Pointer
        expressions [RFC6901] identifying a location within the ADL
        document object.

     *  *Additional information:*

        -  Deprecated alias names for this type: N/A

        -  Magic number(s): N/A

        -  File extension(s): .adl.json, .adl

        -  Macintosh file type code(s): N/A

        -  Object Identifiers: N/A

     *  *Person and email address to contact for further information:* See
        the Author's Address section of this document.



  Nederveld                Expires 22 August 2026                [Page 37]


  Internet-Draft                     ADL                     February 2026


     *  *Intended usage:* COMMON

     *  *Restrictions on usage:* None

     *  *Author:* See the Author's Address section of this document.

     *  *Change controller:* IETF

  17.2.  Profile Registry

     IANA is requested to create and maintain a new registry titled *"ADL
     Profile Registry"* within a new "Agent Definition Language (ADL)"
     registry group.

     *Registration Policy:* Specification Required [RFC8126].  The
     designated expert reviews registration requests to verify that the
     profile is documented in a publicly available, stable specification
     and that all required registration template fields are complete.

     *Registration Template:* Parties wishing to register a profile *MUST*
     provide all of the following fields:






























  Nederveld                Expires 22 August 2026                [Page 38]


  Internet-Draft                     ADL                     February 2026


       +===============+===============================================+
       | Field         | Description                                   |
       +===============+===============================================+
       | Identifier    | A URI that uniquely identifies the profile,   |
       | (URI)         | conforming to [RFC3986].  The URI *SHOULD* be |
       |               | dereferenceable and return a human-readable   |
       |               | description of the profile.                   |
       +---------------+-----------------------------------------------+
       | Name          | A short human-readable name for the profile   |
       |               | (e.g., "ADL Governance Profile").             |
       +---------------+-----------------------------------------------+
       | Version       | The profile version string in                 |
       |               | MAJOR.MINOR.PATCH semantic versioning format. |
       +---------------+-----------------------------------------------+
       | Specification | A stable, publicly accessible URI or document |
       | Reference     | reference for the profile specification.  The |
       |               | specification *MUST* define all profile-      |
       |               | required members, validation rules, and any   |
       |               | additional semantics added by the profile.    |
       +---------------+-----------------------------------------------+
       | ADL Version   | The ADL specification version(s) with which   |
       | Compatibility | the profile is designed to operate (e.g.,     |
       |               | "0.1.x").                                     |
       +---------------+-----------------------------------------------+
       | Contact       | Name and email address of the person or group |
       |               | responsible for the profile registration.     |
       +---------------+-----------------------------------------------+
       | Status        | One of: active (currently maintained) or      |
       |               | deprecated (superseded or abandoned).         |
       +---------------+-----------------------------------------------+

                                    Table 20

     *Initial Registry Contents:*

















  Nederveld                Expires 22 August 2026                [Page 39]


  Internet-Draft                     ADL                     February 2026


     +================================+========================+=========+
     | Identifier (URI)               | Name                   | Version |
     +================================+========================+=========+
     | urn:adl:profile:governance:1.0 | ADL Governance         | 1.0.0   |
     |                                | Profile                |         |
     +--------------------------------+------------------------+---------+
     | urn:adl:profile:portfolio:1.0  | ADL Portfolio          | 1.0.0   |
     |                                | Profile                |         |
     +--------------------------------+------------------------+---------+
     | urn:adl:profile:healthcare:1.0 | ADL Healthcare         | 1.0.0   |
     |                                | Profile                |         |
     +--------------------------------+------------------------+---------+
     | urn:adl:profile:financial:1.0  | ADL Financial          | 1.0.0   |
     |                                | Profile                |         |
     +--------------------------------+------------------------+---------+

                                    Table 21

     All initial entries reference Appendix C of this document, target ADL
     compatibility 0.1.x, are active, and list the Author's Address as
     contact.

     *Designated Expert Criteria:* The designated expert *SHOULD* evaluate
     requests against the following criteria:

     1.  *Publicly available specification:* The profile specification
         *MUST* be accessible at a stable, public URI.  Specifications
         behind paywalls or access controls are not acceptable for
         registration.

     2.  *Non-conflict with core ADL:* The profile *MUST NOT* redefine or
         contradict normative requirements of the core ADL specification.
         Profiles *MAY* add new members, constrain optional members to a
         subset of permitted values, or require that optional core members
         be present.

     3.  *Complete registration template:* All required template fields
         *MUST* be present and non-empty.  Incomplete registrations *MUST*
         be returned to the submitter.

     4.  *Stable identifier:* The profile URI *SHOULD* be dereferenceable
         and *SHOULD* remain stable over time.  Ephemeral or frequently
         changing URIs are not acceptable.

     5.  *Legitimate purpose:* The profile *SHOULD* address a genuine
         domain or deployment need not already covered by an existing
         active registered profile.




  Nederveld                Expires 22 August 2026                [Page 40]


  Internet-Draft                     ADL                     February 2026


  17.3.  URN Namespace

     IANA is requested to register the adl URN namespace identifier in the
     "Formal URN Namespaces" registry in accordance with [RFC8141].

     *  *Namespace Identifier:* adl

     *  *Version:* 1

     *  *Date:* [date of publication]

     *  *Registrant:* See the Author's Address section of this document.

     *  *Purpose:* The urn:adl: namespace provides persistent, location-
        independent identifiers for ADL agents, profiles, and related
        artifacts.  These identifiers are intended for use in offline
        catalogs, air-gapped environments, and internal registries where
        network resolution is unavailable.  For connected environments,
        HTTPS URIs (Section 6.1) are the *RECOMMENDED* identifier format.

     *  *Syntax:* URNs in this namespace conform to the following
        structure: urn:adl:{type}:{namespace}:{name}:{version} where
        {type} is one of agent or profile, {namespace} is a lowercase
        alphanumeric organization identifier, {name} is a lowercase
        alphanumeric resource name with hyphens, and {version} is a
        semantic version string.  The formal syntax is defined by the adl-
        urn production in Appendix D.

     *  *Assignment:* Sub-namespace assignment under urn:adl:profile: is
        governed by the ADL Profile Registry (Section 17.2).  Sub-
        namespace assignment under urn:adl:agent: is at the discretion of
        the namespace holder; no central registry is required for agent
        URNs.

     *  *Security and Privacy:* URN identifiers in this namespace are
        opaque strings and carry no inherent security properties.
        Implementations *MUST NOT* infer ownership, trust, or
        authorization from a urn:adl: identifier alone.  Verification of
        agent identity *MUST* rely on the mechanisms described in
        Section 6.3 (Cryptographic Identity) and Section 10.3
        (Attestation).  See Section 18 for comprehensive security
        considerations.

  17.4.  Well-Known URI

     IANA is requested to register the adl-agents well-known URI suffix in
     the "Well-Known URIs" registry in accordance with [RFC8615].




  Nederveld                Expires 22 August 2026                [Page 41]


  Internet-Draft                     ADL                     February 2026


     *  *URI suffix:* adl-agents

     *  *Change controller:* IETF

     *  *Specification document:* Section 6.4 of [this document]

     *  *Status:* permanent

     *  *Related information:* The well-known URI https://{domain}/.well-
        known/adl-agents returns a JSON document listing all ADL agents
        published by the domain authority.  The document format is defined
        in Section 6.4.  The resource *MUST* be served over HTTPS.

  18.  Security Considerations

  18.1.  Document Integrity

     ADL documents define agent behavior, permission grants, and security
     requirements.  The trust model for an ADL document depends on its
     provenance and the integrity mechanisms applied to it.  Unsigned ADL
     documents from untrusted or unverified sources *MUST* be treated as
     potentially malicious.

     When a document includes a cryptographic signature in
     security.attestation.signature, implementations *MUST* verify the
     signature before acting on the document's permission or security
     declarations.  Signature verification requires serializing the
     document (with the signature object removed) using JCS [RFC8785] to
     produce a canonical byte sequence, then verifying the resulting
     digest using the algorithm and public key declared in
     cryptographic_identity.  Implementations *MUST* reject documents that
     claim to be signed but whose signature does not verify.
     Implementations *SHOULD* warn when processing signed documents whose
     attestation has expired (expires_at is in the past).  An ADL document
     whose permissions or capabilities have been modified after signing
     will produce a different canonical byte sequence and fail signature
     verification; this is the intended behavior and provides protection
     against privilege escalation via document tampering.

  18.2.  Sensitive Data in ADL Documents

     ADL documents *SHOULD NOT* contain secrets, credentials, or other
     sensitive data in plaintext.  Fields such as system_prompt,
     provider.contact, metadata.authors, and tool parameter examples may
     inadvertently expose confidential information if documents are
     logged, cached, or transmitted without adequate access controls.





  Nederveld                Expires 22 August 2026                [Page 42]


  Internet-Draft                     ADL                     February 2026


     API keys, passwords, private keys, bearer tokens, and other
     authentication material *MUST NOT* appear as literal string values in
     ADL documents.  Where agent configuration requires secret values at
     runtime, implementations *SHOULD* use environment variable references
     or external secret manager URIs rather than embedding values
     directly.  Implementations *SHOULD* warn when string values match
     patterns commonly associated with credentials (e.g., values matching
     the format of known API key prefixes).  Organizations *SHOULD*
     subject ADL documents to the same secret-scanning controls applied to
     source code repositories before storage or distribution.

  18.3.  Template Injection

     The system_prompt member (Section 7.2) and prompts[*].template
     members (Section 8.3) support a template substitution syntax using
     {{variable_name}} placeholders.  If variable values are derived from
     untrusted user input and substituted without sanitization, an
     attacker may be able to alter agent behavior by injecting malicious
     instructions into the rendered prompt -- including instructions that
     override the intended agent behavior or cause the agent to exfiltrate
     information.

     Implementations *MUST* sanitize template variable values before
     substitution.  At minimum, implementations *SHOULD* escape or reject
     values that contain the template delimiter sequence {{ or }}, and
     *SHOULD* apply length limits to variable values.  Applications that
     allow end users to supply template variable values *SHOULD* treat
     such values as untrusted and apply content validation appropriate to
     the deployment context.  Runtimes operating on agents with
     data_classification.sensitivity of confidential or restricted
     *SHOULD* log rendered prompts (after variable substitution) to enable
     post-incident review, subject to applicable privacy constraints.

  18.4.  Information Disclosure

     ADL documents may reveal infrastructure details that are useful to
     attackers.  The name, description, and tool description fields may
     disclose the existence of internal services or system architecture.
     The permissions.network.allowed_hosts list may reveal internal
     hostname patterns, private IP ranges, or internal service naming
     conventions.  The permissions.filesystem.allowed_paths list may
     reveal sensitive directory structures.  The provider.url,
     metadata.documentation, and metadata.repository fields may reference
     internal systems not intended for public visibility.

     ADL documents intended for public distribution *SHOULD* be reviewed
     to remove or generalize infrastructure-specific information.  Host
     patterns *SHOULD* use registered domain names rather than IP



  Nederveld                Expires 22 August 2026                [Page 43]


  Internet-Draft                     ADL                     February 2026


     addresses or internal hostnames.  Path patterns *SHOULD* avoid
     exposing sensitive directory names.  Documents with
     data_classification.sensitivity of confidential or restricted
     *SHOULD* only be distributed to parties with appropriate access
     authorization and *SHOULD NOT* be published to public registries
     without thorough review.

  18.5.  Resource Exhaustion

     Implementations that parse and validate ADL documents are susceptible
     to resource exhaustion from adversarially crafted inputs.  Specific
     attack vectors include: deeply nested JSON Schema in parameters and
     returns members (including circular $ref chains or exponentially
     expanding allOf/anyOf combinators); documents with very large numbers
     of tools, resources, or prompts; and documents with excessively long
     string values in system_prompt, description fields, or pattern
     arrays.

     Implementations *SHOULD* enforce and document limits on: total
     document size (recommended maximum: 1 MB); JSON nesting depth
     (recommended maximum: 32 levels); number of entries in tools,
     resources, and prompts arrays (recommended maximum: 1000 each);
     string length for system_prompt and description fields (recommended
     maximum: 1 MB per field); and number of entries in any permission
     pattern array (recommended maximum: 500 patterns per domain).
     Implementations *SHOULD* terminate processing with an appropriate
     error code when any of these limits is exceeded rather than
     continuing to consume resources.

  18.6.  Pattern Matching Abuse

     The permission pattern syntax (Section 4.4) governs access grants
     across network, filesystem, environment variable, and execution
     domains.  Overly permissive patterns undermine the deny-by-default
     permission model; patterns that are expensive to evaluate can enable
     denial-of-service.















  Nederveld                Expires 22 August 2026                [Page 44]


  Internet-Draft                     ADL                     February 2026


     A bare * as the sole value of an entry in allowed_hosts grants access
     to all hostnames and effectively disables network permission
     enforcement.  Implementations *MUST* warn when a bare * wildcard is
     used in any security-sensitive permission pattern, including
     allowed_hosts and allowed_variables.  Implementations *SHOULD*
     require explicit user acknowledgment -- or refuse to deploy -- agents
     that use bare * patterns in these domains.  Pattern evaluation
     *SHOULD* be bounded in time and space: implementations that use
     backtracking pattern matchers *SHOULD* reject or normalize patterns
     that would require exponential backtracking (e.g., consecutive
     wildcards such as ***).  The ** multi-segment wildcard *MUST NOT*
     appear in host, environment, or command patterns, and implementations
     *MUST* reject documents in which it does.

  18.7.  URI Reference Attacks (SSRF)

     Multiple ADL fields accept URI values: $schema, id, provider.url,
     metadata.documentation, metadata.repository, resource.uri,
     tool.annotations.openapi_ref, lifecycle.successor,
     security.attestation.issuer, and others defined by profiles.  If an
     implementation automatically dereferences these URIs when processing
     a document from an untrusted source, an attacker may cause the
     implementation to issue requests to arbitrary endpoints, including
     internal services not reachable from the public internet -- a class
     of vulnerability known as Server-Side Request Forgery (SSRF).

     Implementations *MUST NOT* automatically dereference URI values from
     ADL documents received from untrusted sources without explicit
     operator or user consent.  Implementations that fetch external schema
     documents (e.g., via $schema) for validation purposes *SHOULD* use an
     allowlist of trusted schema hosts and *MUST NOT* follow redirects
     that leave the trusted set.  When fetching openapi_ref documents for
     tool description or validation, implementations *SHOULD* verify that
     the target URI matches a pre-approved allowlist.  Implementations
     *SHOULD* validate that URI values in ADL documents conform to
     [RFC3986] and *SHOULD* reject URIs with schemes other than https,
     http, or urn unless the deployment context explicitly allows them.

  18.8.  Canonicalization Attacks

     ADL supports document integrity verification via cryptographic
     signatures using JCS canonicalization [RFC8785].  The security of
     this mechanism depends on all conforming implementations producing
     identical canonical byte sequences for the same logical document.
     Subtle differences in JCS implementations -- such as incorrect
     handling of Unicode escape sequences, floating-point number
     serialization, or object member ordering -- could cause a legitimate
     signature to fail verification, or, more critically, allow an



  Nederveld                Expires 22 August 2026                [Page 45]


  Internet-Draft                     ADL                     February 2026


     attacker to construct a document where different implementations
     produce different canonical forms, potentially enabling a signature
     verification bypass.

     Implementations *MUST* use a conformant JCS [RFC8785] implementation
     for both signing and verification.  Implementations *SHOULD* validate
     their JCS implementation against the test vectors provided in RFC
     8785 before use in a production environment.  Implementations *MUST
     NOT* verify signatures against non-canonical serializations such as
     pretty-printed JSON or YAML.  Implementations that process ADL
     documents containing IEEE 754 floating-point values in signed content
     *SHOULD* be aware that platform-specific floating-point
     representation differences may affect canonicalization and *SHOULD*
     avoid floating-point values in fields that will be signed when
     possible.

  18.9.  Privacy Considerations

     ADL documents may contain personal information subject to applicable
     privacy regulations.  The provider.contact field (Section 6.2)
     contains a contact email address.  The metadata.authors array
     (Section 12.1) may contain author names, email addresses, and URLs.
     The system_prompt member may contain information about intended user
     roles, user populations, or organizational context.  When ADL
     documents are published to public registries or shared broadly, this
     information becomes publicly accessible.

     Publishers *SHOULD* review ADL documents for personally identifiable
     information (PII) before public distribution and *SHOULD* use
     organizational or role-based contact addresses rather than personal
     email addresses.  Implementations that log ADL document contents for
     debugging or auditing *SHOULD* redact or omit provider.contact,
     metadata.authors, and system_prompt fields from logs unless there is
     a documented operational requirement to retain them.  Users *SHOULD*
     be informed when their ADL documents are transmitted to third-party
     services for validation, indexing, or registry queries.

  18.10.  Privilege Escalation

     An ADL document that has been modified -- whether by a malicious
     actor during transmission or by a compromised storage or distribution
     system -- could grant an agent permissions or capabilities beyond
     those that were reviewed and approved for deployment.  This risk is
     the primary motivator for the integrity mechanisms described in
     Section 10.3.






  Nederveld                Expires 22 August 2026                [Page 46]


  Internet-Draft                     ADL                     February 2026


     Implementations *SHOULD* verify document integrity (Section 10.3)
     before enforcing the permissions declared in a document, particularly
     when documents are retrieved from network locations, shared storage
     systems, or public registries.  Runtimes that cannot verify document
     integrity *SHOULD* apply compensating controls -- such as mandatory
     human review -- before deploying agents that declare elevated
     permissions or sensitive data access.  When a document's
     data_classification.sensitivity is confidential or restricted,
     runtimes *SHOULD* require a verified signature or a verified supply
     chain (e.g., document retrieved from a trusted registry over an
     authenticated and integrity-protected channel) before provisioning.
     Organizations *SHOULD* maintain an inventory of approved ADL
     documents along with their expected signatures or cryptographic
     digests, and *SHOULD* treat any discrepancy between the recorded and
     observed document as a potential security incident.

  18.11.  Cross-Origin and Supply Chain Concerns

     ADL documents may be fetched from remote sources: registries, source
     control systems, artifact stores, or agent marketplaces.  A document
     tampered with in transit or at the origin could cause a runtime to
     provision a malicious agent without the operator's knowledge.

     ADL documents *SHOULD* be fetched over authenticated, integrity-
     protected channels (HTTPS with full certificate validation).
     Implementations *SHOULD* verify document signatures (Section 10.3)
     when documents are retrieved from remote or third-party sources.
     Implementations *SHOULD* validate that the signing identity declared
     in cryptographic_identity matches an expected, trusted identity for
     the document's declared provider.

     Supply chain integrity requires attention at every reference
     boundary: the ADL document itself, referenced OpenAPI specifications
     (openapi_ref), and external JSON Schemas ($schema).  Implementations
     that automatically resolve external references during provisioning
     *SHOULD* pin or verify all such references.  When accepting ADL
     documents from third-party sources, implementations *SHOULD* apply an
     allowlist of trusted providers (based on provider.name or id URI
     authority), verify attestation signatures from trusted issuers, and
     treat documents from unverified sources with the same caution applied
     to untrusted executable code.










  Nederveld                Expires 22 August 2026                [Page 47]


  Internet-Draft                     ADL                     February 2026


  18.12.  Permission Model and Defense in Depth

     The deny-by-default permission model (Section 9.1) is a foundational
     security property of ADL: an agent can only access resources and
     capabilities that its ADL document explicitly permits.  However, the
     effectiveness of this model depends entirely on the runtime correctly
     enforcing declared permissions.  No permission model is a substitute
     for defense in depth.

     Runtimes *MUST* enforce declared permissions and *MUST NOT* allow
     agents to exceed those permissions under any circumstances, including
     error conditions or fallback behaviors.  Runtimes that cannot enforce
     a specific permission domain (e.g., because the underlying platform
     lacks the required isolation primitives) *MUST* warn users before
     execution and *SHOULD* refuse to execute the agent unless the user
     explicitly acknowledges the limitation.

     Beyond permission enforcement, runtimes *SHOULD* monitor agent
     behavior during execution: logging tool invocations, recording
     network destinations contacted, and alerting on anomalous activity
     such as repeated attempts to access resources outside declared
     permissions.  The ADL document represents intended access boundaries
     at definition time; runtime monitoring ensures actual behavior
     remains within those boundaries in production.

     Runtimes *SHOULD* validate tool inputs and outputs against the
     declared JSON Schema (Section 8.1) before passing them to or from the
     agent.  Malformed responses from external tool implementations could
     inject unexpected data into agent reasoning; runtime-level schema
     validation provides a defense against malfunctioning or malicious
     tool backends.  Tools annotated with requires_confirmation: true
     *MUST* receive explicit user confirmation before invocation; runtimes
     *MUST NOT* invoke such tools autonomously regardless of other
     configuration.

     Lifecycle status *MUST* be enforced as a security boundary.  Runtimes
     *MUST NOT* provision or execute agents with lifecycle.status of
     retired.  Retired agents may have revoked credentials, unpatched
     vulnerabilities, or stale permission configurations.  Agents with
     lifecycle.status of deprecated *SHOULD* trigger warnings to
     operators, who *SHOULD* migrate to the agent identified by
     lifecycle.successor before the sunset_date is reached.

  19.  References

  19.1.  Normative References





  Nederveld                Expires 22 August 2026                [Page 48]


  Internet-Draft                     ADL                     February 2026


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

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

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

     [RFC6901]  Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
                "JavaScript Object Notation (JSON) Pointer", RFC 6901,
                DOI 10.17487/RFC6901, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6901>.

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

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

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

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

  19.2.  Informative References

     [A2A]      A2A Protocol Working Group, "Agent-to-Agent Protocol
                Specification", 2025,
                <https://a2a-protocol.org/specification>.




  Nederveld                Expires 22 August 2026                [Page 49]


  Internet-Draft                     ADL                     February 2026


     [JSON-SCHEMA]
                Wright, A., "JSON Schema: A Media Type for Describing JSON
                Documents", 2020,
                <https://json-schema.org/draft/2020-12/json-schema-core>.

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

     [OPENAPI]  OpenAPI Initiative, "OpenAPI Specification", 2024,
                <https://spec.openapis.org/oas/v3.1.0>.

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

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

     [W3C.VC]   Sporny, M., "Verifiable Credentials Data Model v1.1",
                2022, <https://www.w3.org/TR/vc-data-model/>.

  Appendix A.  JSON Schema

     The normative JSON Schema for ADL is available at https://adl-
     spec.org/0.1/schema.json (JSON Schema Draft 2020-12).  A minimal
     required-fields schema is provided in schema.json (./schema.json) in
     this directory.

  Appendix B.  Examples

     See the examples/ (./examples/) directory:

     *  *Minimal:* minimal.yaml (./examples/minimal.yaml)

     *  *Agent with tools:* with-tools.yaml (./examples/with-tools.yaml)

     *  *Production agent:* production.yaml (./examples/production.yaml)

  Appendix C.  Profiles

     ADL profiles are maintained in the profiles/ (../../profiles/)
     directory.  Each profile is versioned independently and declares
     compatibility with ADL versions.







  Nederveld                Expires 22 August 2026                [Page 50]


  Internet-Draft                     ADL                     February 2026


  C.1.  Available Profiles

      +===========================+==============================+======+
      |Profile                    |Identifier                    |Status|
      +===========================+==============================+======+
      |Governance                 |urn:adl:profile:governance:1.0|Draft |
      |(../../profiles/governance/|                              |      |
      |overview)                  |                              |      |
      +---------------------------+------------------------------+------+
      |Portfolio                  |urn:adl:profile:portfolio:1.0 |Draft |
      |(../../profiles/portfolio/ |                              |      |
      |overview)                  |                              |      |
      +---------------------------+------------------------------+------+
      |Healthcare                 |urn:adl:profile:healthcare:1.0|Draft |
      |(../../profiles/healthcare/|                              |      |
      |overview)                  |                              |      |
      +---------------------------+------------------------------+------+
      |Financial                  |urn:adl:profile:financial:1.0 |Draft |
      |(../../profiles/financial/ |                              |      |
      |overview)                  |                              |      |
      +---------------------------+------------------------------+------+

                                    Table 22

     See the profiles/ (../../profiles/) directory for the full profile
     index and contribution guidelines.

  Appendix D.  ABNF Grammar

     This appendix defines formal ABNF grammar productions (RFC 5234 / RFC
     7405) for syntactic constructs specified in this document.  All
     productions use ASCII character references consistent with RFC 5234,
     Appendix B.  The core ABNF rules ALPHA (letters), DIGIT (decimal
     digits), and VCHAR (visible ASCII characters) are defined in RFC 5234
     Section 6 (B.1).

     <CODE BEGINS> ```abnf ; Semantic Versioning format (Sections 5.1,
     5.5) semver = 1_DIGIT "." 1_DIGIT "." 1*DIGIT

     ; Tool name (Section 8.1) ; All alpha characters MUST be lowercase;
     satisfies ^[a-z][a-z0-9_]*$ tool-name = lc-alpha *( lc-alpha / DIGIT
     / "_" ) lc-alpha = %x61-7A ; a-z (lowercase letters only)

     ; Extension member name (Section 4.3) ; "x_" prefix followed by a
     namespace identifier ext-member-name = "x_" ns-id ns-id = 1*( lc-
     alpha / DIGIT / "_" )





  Nederveld                Expires 22 August 2026                [Page 51]


  Internet-Draft                     ADL                     February 2026


     ; Template variable (Sections 7.2, 8.3) ; Used in system_prompt
     templates and prompt templates template-var = 2%x7B var-name 2%x7D
     var-name = ALPHA *( ALPHA / DIGIT / "_" ) ; First character MUST be a
     letter (upper or lowercase)

     ; Tag (Section 12.5) ; Lowercase alphanumeric characters and hyphens
     tag = 1*( lc-alpha / DIGIT / "-" )

     ; Pattern syntax (Section 4.4) ; An ADL pattern consists of literal
     characters and optional wildcard tokens pattern = 1_pattern-element
     pattern-element = multi-wildcard / single-wildcard / literal-chars
     multi-wildcard = "**" ; Valid only in filesystem path patterns
     (Section 9.3) ; MUST NOT appear in host, env-variable, or command
     patterns single-wildcard = "_" ; Matches within one segment; does not
     cross "." in host ; patterns or "/" in filesystem path patterns
     literal-chars = 1_literal-char literal-char = %x21-29 / %x2B-7E ;
     Printable ASCII except "_" (%x2A) ; "/" (%x2F) carries segment-
     boundary meaning in path patterns ; "." (%x2E) carries segment-
     boundary meaning in host patterns ``` <CODE ENDS>

  D.1.  Cross-Reference Summary

     +=================+===================+=============================+
     | Production      | Normative Section | Usage                       |
     +=================+===================+=============================+
     | semver          | 5.1, 5.5          | adl_spec and version        |
     |                 |                   | values                      |
     +-----------------+-------------------+-----------------------------+
     | tool-name       | 8.1               | Tool name values            |
     +-----------------+-------------------+-----------------------------+
     | ext-member-name | 4.3               | Custom extension member     |
     |                 |                   | names                       |
     +-----------------+-------------------+-----------------------------+
     | template-var    | 7.2, 8.3          | {{variable}} references     |
     |                 |                   | in templates                |
     +-----------------+-------------------+-----------------------------+
     | tag             | 12.5              | metadata.tags array         |
     |                 |                   | items                       |
     +-----------------+-------------------+-----------------------------+
     | pattern         | 4.4, 9.2-9.5      | Permission domain           |
     |                 |                   | pattern strings             |
     +-----------------+-------------------+-----------------------------+

                                    Table 23







  Nederveld                Expires 22 August 2026                [Page 52]


  Internet-Draft                     ADL                     February 2026


  Acknowledgments

     TBD

  Author's Address

     Terrill Nederveld
     Ironstead Group, LLC.
     Email: terry+adl@ironsteadgroup.com










































  Nederveld                Expires 22 August 2026                [Page 53]


name: draft-tejido-swp-core
rev: 00
title: SlimWire Protocol (SWP) Core: Binary Framing and Envelope Substrate
time: 2026-02-20T05:47:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-24T05:47:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.671969+00:00
source: ietf
abstract:
  This document specifies the SlimWire Protocol (SWP) Core: a slim
     binary framing (record) layer and envelope format for interoperable
     agent/tool messaging with profile-based extensibility and a machine-
     verifiable conformance model.  SWP Core provides a transport-
     independent message boundary definition (u32_be length prefix), a
     mandatory-to-implement envelope encoding (E1) based on unsigned
     LEB128 uvarints and length-delimited byte strings with a TLV
     extension block, and profile dispatch by numeric profile identifiers.
     Profiles define application semantics (e.g., tool invocation mapping
     and agent task lifecycle) and are carried opaquely by Core.  This
     document also specifies conformance classes and golden vector
     artefacts executed by a spec-vector runner, and defines a security
     binding (S1) requiring an authenticated confidential channel (e.g.,
     TLS 1.3).

full_text:
  Network Working Group                                          J. Tejido
  Internet-Draft                                          20 February 2026
  Intended status: Informational                                          
  Expires: 24 August 2026


    SlimWire Protocol (SWP) Core: Binary Framing and Envelope Substrate
                          draft-tejido-swp-core-00

  Abstract

     This document specifies the SlimWire Protocol (SWP) Core: a slim
     binary framing (record) layer and envelope format for interoperable
     agent/tool messaging with profile-based extensibility and a machine-
     verifiable conformance model.  SWP Core provides a transport-
     independent message boundary definition (u32_be length prefix), a
     mandatory-to-implement envelope encoding (E1) based on unsigned
     LEB128 uvarints and length-delimited byte strings with a TLV
     extension block, and profile dispatch by numeric profile identifiers.
     Profiles define application semantics (e.g., tool invocation mapping
     and agent task lifecycle) and are carried opaquely by Core.  This
     document also specifies conformance classes and golden vector
     artefacts executed by a spec-vector runner, and defines a security
     binding (S1) requiring an authenticated confidential channel (e.g.,
     TLS 1.3).

  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 24 August 2026.

  Copyright Notice

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




  Tejido                   Expires 24 August 2026                 [Page 1]


  Internet-Draft                  SWP Core                   February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     3.  SWP Core Overview . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Core Framing  . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Core Envelope Fields  . . . . . . . . . . . . . . . . . .   5
     4.  E1 Envelope Encoding  . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Encoding Primitives . . . . . . . . . . . . . . . . . . .   6
       4.2.  Field Order and Layout  . . . . . . . . . . . . . . . . .   6
       4.3.  TLV Extension Block . . . . . . . . . . . . . . . . . . .   7
     5.  P1 Payload Encoding Binding . . . . . . . . . . . . . . . . .   7
     6.  Profile Registry and profile_id Allocation  . . . . . . . . .   8
     7.  Conformance Classes and Golden Vectors  . . . . . . . . . . .   8
       7.1.  Conformance Classes . . . . . . . . . . . . . . . . . . .   9
       7.2.  Golden Vector Format  . . . . . . . . . . . . . . . . . .   9
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
       8.1.  S1 Security Binding . . . . . . . . . . . . . . . . . . .  10
       8.2.  Credential/Delegation and Policy Hints  . . . . . . . . .  11
       8.3.  Observability Context Propagation . . . . . . . . . . . .  11
     9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
     10. Evaluation and Reproducibility  . . . . . . . . . . . . . . .  12
     11. Deployment and Interoperability Scenarios . . . . . . . . . .  12
     12. Limitations and Non-Goals . . . . . . . . . . . . . . . . . .  13
     13. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  14
       15.2.  Informative References . . . . . . . . . . . . . . . . .  14
     Appendix: Implementation and Conformance Notes (Informative)  . .  15
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15











  Tejido                   Expires 24 August 2026                 [Page 2]


  Internet-Draft                  SWP Core                   February 2026


  1.  Introduction

     Contemporary LLM systems increasingly behave as distributed systems:
     they invoke external tools, delegate long-running tasks to other
     agents, stream intermediate progress, exchange artefacts, and operate
     across organisational trust boundaries.  In practice, these
     behaviours are implemented via heterogeneous application protocols
     over transports such as HTTP streaming and stdio.

     Two application-level protocol efforts have gained traction: the
     Model Context Protocol (MCP) (https://modelcontextprotocol.io/
     specification/ (https://modelcontextprotocol.io/specification/)) and
     Agent2Agent (A2A) (https://a2a-protocol.org/ (https://a2a-
     protocol.org/); overview: https://developers.googleblog.com/en/a2a-a-
     new-era-of-agent-interoperability/
     (https://developers.googleblog.com/en/a2a-a-new-era-of-agent-
     interoperability/)).  MCP standardises tool invocation and discovery
     (commonly JSON-RPC over defined transports), while A2A standardises
     agent-to-agent delegation and discovery.  Both operate at the
     application layer.

     As deployments move into federated, cross-boundary settings,
     integration friction often arises below the application layer:
     message boundary detection, size limiting, replay policy,
     correlation, identity surfacing for authorisation and audit, and
     failure semantics are repeatedly reimplemented at gateways and
     adapters.  SWP addresses this by defining a minimal substrate: a
     record layer and envelope that carry multiple profiles under a stable
     dispatch model, with explicit security binding requirements and a
     machine-verifiable conformance suite.

     This document specifies SWP Core (framing, envelope, E1 encoding, and
     profile dispatch), plus the conformance and security binding
     requirements needed for interoperable deployments.  SWP profiles
     (including mappings for MCP and A2A and additional infrastructure
     primitives) are referenced but are not fully specified herein unless
     required for Core interoperability.

  2.  Conventions and Terminology

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







  Tejido                   Expires 24 August 2026                 [Page 3]


  Internet-Draft                  SWP Core                   February 2026


     BCP 14 is specified by RFC 2119 (https://www.rfc-editor.org/rfc/
     rfc2119 (https://www.rfc-editor.org/rfc/rfc2119)) and clarified by
     RFC 8174 (https://www.rfc-editor.org/rfc/rfc8174 (https://www.rfc-
     editor.org/rfc/rfc8174)).

     This document uses the following terms:

     *  _Frame_: A length-delimited unit on a byte stream consisting of a
        32-bit big-endian length prefix and an encoded envelope.

     *  _Envelope_: The Core-level header containing versioning, profile
        dispatch identifiers, correlation identifiers, and an opaque
        profile payload.

     *  _Profile_: A defined semantic layer above Core identified by a
        numeric _profile_id_ and a profile-defined _msg_type_. Profiles
        define payload schemas, processing rules, and conformance vectors.

     *  _Binding_: A set of requirements that constrain how Core and
        profiles are carried over a transport (e.g., security binding S1;
        payload encoding binding P1).

  3.  SWP Core Overview

     SWP Core defines (1) message framing on a byte stream, (2) a minimal
     envelope surface for dispatch, and (3) a mandatory envelope encoding
     (E1).  Profiles define application semantics and payload formats and
     are carried as opaque bytes in the Core envelope.

  3.1.  Core Framing

     A SWP stream is a sequence of frames.  Each frame MUST be encoded as:

     *  _N_: a 32-bit unsigned integer in network byte order (big-endian),
        followed by

     *  exactly _N_ octets containing one encoded envelope.

     A receiver MUST reject a frame if any of the following conditions
     hold:

     *  the 4-octet length prefix is truncated;

     *  _N_ equals zero;

     *  _N_ exceeds a local maximum frame size limit (MAX_FRAME_BYTES);

     *  the envelope body is truncated (fewer than _N_ octets remain);



  Tejido                   Expires 24 August 2026                 [Page 4]


  Internet-Draft                  SWP Core                   February 2026


     *  the envelope body cannot be decoded by the selected envelope
        encoding (E1 for Core v1).

     MAX_FRAME_BYTES is a local policy parameter and MUST be configurable.
     Implementations SHOULD enforce MAX_FRAME_BYTES before allocating
     buffers sized by _N_.

     NOTE: SWP Core is transport-independent and can run over any reliable
     byte stream meeting the security binding (S1).  HTTP/2 provides a
     distinct binary framing layer for HTTP semantics (RFC 9113,
     https://datatracker.ietf.org/doc/html/rfc9113
     (https://datatracker.ietf.org/doc/html/rfc9113)); gRPC defines an
     additional message framing convention over HTTP/2
     (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md
     (https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md)).
     SWP similarly defines explicit message boundaries but is not tied to
     HTTP/2.

  3.2.  Core Envelope Fields

     A decoded envelope consists of the following required fields:

     *  _version_ (uvarint): Core protocol version (this document
        specifies version 1).

     *  _profile_id_ (uvarint): profile dispatch identifier.

     *  _msg_type_ (uvarint): profile-defined message type.

     *  _flags_ (uvarint): Core behaviour flags.  Unknown flag bits MUST
        NOT change interpretation.

     *  _ts_unix_ms_ (uvarint): sender timestamp in Unix milliseconds
        (policy-controlled freshness).

     *  _msg_id_ (bytes): message identifier for correlation and replay/
        duplication handling.

     *  _payload_ (bytes): opaque profile payload bytes.

     The Core MUST NOT interpret profile payload bytes.  Dispatch
     decisions MUST be based only on (version, profile_id, msg_type,
     flags) and local policy/state.

     msg_id length MUST be bounded.  Implementations MUST reject msg_id
     values shorter than MIN_MSG_ID_BYTES or longer than MAX_MSG_ID_BYTES.
     MIN_MSG_ID_BYTES and MAX_MSG_ID_BYTES are protocol parameters; this
     document RECOMMENDS MIN_MSG_ID_BYTES = 8 and MAX_MSG_ID_BYTES = 64.



  Tejido                   Expires 24 August 2026                 [Page 5]


  Internet-Draft                  SWP Core                   February 2026


     The Core MUST enforce a maximum payload size limit
     (MAX_PAYLOAD_BYTES) independent of MAX_FRAME_BYTES.
     MAX_PAYLOAD_BYTES MUST be configurable and SHOULD be strictly less
     than MAX_FRAME_BYTES to allow envelope overhead.

  4.  E1 Envelope Encoding

     E1 is the mandatory-to-implement envelope encoding for Core version
     1.  E1 encodes envelope fields in a fixed order using unsigned LEB128
     uvarints and length-delimited byte strings.  E1 includes a TLV
     extension block that can be skipped by implementations that do not
     recognise extension types.

  4.1.  Encoding Primitives

     E1 defines two primitive encodings:

     *  _uvarint_: an unsigned integer encoded using base-128 LEB128,
        where each octet carries 7 bits of value and the most significant
        bit indicates continuation.  The least significant group is
        encoded first.

     *  _bytes_: a length-delimited octet string encoded as _uvarint
        length_ followed by exactly _length_ octets.

     An E1 decoder MUST reject malformed varints and MUST enforce a varint
     length bound.  This document RECOMMENDS rejecting uvarints longer
     than 10 octets and rejecting values that overflow 64-bit unsigned
     range.

  4.2.  Field Order and Layout

     Within the frame body (the _N_ octets after the length prefix), E1
     encodes the envelope fields in the following exact order:

     1.  _version_ (uvarint)

     2.  _profile_id_ (uvarint)

     3.  _msg_type_ (uvarint)

     4.  _flags_ (uvarint)

     5.  _ts_unix_ms_ (uvarint)

     6.  _msg_id_ (bytes)

     7.  _extensions_ (bytes; TLV extension block; MAY be empty)



  Tejido                   Expires 24 August 2026                 [Page 6]


  Internet-Draft                  SWP Core                   February 2026


     8.  _payload_ (bytes)

     A decoder MUST treat absence of any required field as an invalid
     envelope.  A decoder MUST NOT reinterpret unknown flag bits or
     unknown extension types.  Unknown extension types MUST be ignored.

  4.3.  TLV Extension Block

     The _extensions_ field is itself a length-delimited byte string.  Its
     content is a sequence of TLV entries.  Each entry is encoded as:

     *  _ext_type_ (uvarint)

     *  _ext_value_ (bytes)

     This construction is TLV because _ext_value_ is length-delimited.
     Unknown ext_type values MUST be ignored and skipped by reading
     ext_value length and advancing that many octets.

     Implementations MUST enforce an upper bound on extension block size
     (MAX_EXT_BYTES) and MUST reject messages whose extension block length
     exceeds that bound.  MAX_EXT_BYTES is a local policy parameter and
     SHOULD be configurable.

     Extension type allocation is governed by the profile registry policy.
     Low ranges are reserved for Core/bindings and higher ranges for
     profile-defined extensions.  This document does not define a global
     extension registry beyond these allocation principles.

  5.  P1 Payload Encoding Binding

     SWP Core treats payload bytes opaquely.  To enable independent
     implementability and deterministic conformance testing for profile
     payloads, SWP defines a mandatory payload encoding binding P1 for
     profiles that opt into structured payload encoding.

     P1 specifies Protocol Buffers (proto3) wire format as mandatory-to-
     implement for applicable profiles.  Protobuf proto3 guidance is
     documented at https://protobuf.dev/programming-guides/proto3/
     (https://protobuf.dev/programming-guides/proto3/).

     Rationale (informative): Protobuf supports compact binary payloads,
     established forward/backward compatibility discipline (stable field
     numbers; unknown fields ignored), and byte-level golden vectors.

     Normative schema annexes: this specification set includes normative
     .proto files for P1 profile payloads (e.g., SWP RPC, events,
     artifacts, and A2A-mapped messages).  The .proto annexes are



  Tejido                   Expires 24 August 2026                 [Page 7]


  Internet-Draft                  SWP Core                   February 2026


     distributed with the SWP spec kit and are referenced by profile
     specifications.  Implementations claiming conformance to a profile
     that uses P1 MUST decode payloads using the corresponding normative
     .proto schema.

     Exception: the MCP mapping profile carries MCP JSON-RPC payload bytes
     opaquely to preserve MCP semantics and avoid semantic drift.  MCP
     specification is available at https://modelcontextprotocol.io/
     specification/ (https://modelcontextprotocol.io/specification/).

  6.  Profile Registry and profile_id Allocation

     Core dispatch depends on a stable registry of numeric profile
     identifiers (profile_id). profile_id values MUST NOT be reused.  A
     profile specification MUST define its profile_id, msg_type space,
     payload binding (e.g., P1 protobuf or opaque), and conformance
     vectors.

     This document defines the following initial allocation guidance:

     *  profile_id 1: MCP mapping profile (opaque JSON-RPC bytes).

     *  profile_id 2: A2A profile (agent task lifecycle and related
        messages).

     *  profile_id 3-9: reserved for future foundational profiles/
        bindings.

     *  profile_id 10-19: reserved for extended infrastructure primitive
        profiles.

     Allocation policy (informative): new profile_id assignments SHOULD be
     accompanied by (1) a profile specification, (2) conformance vectors
     for core behaviours and error paths, and (3) an explicit
     compatibility statement.  Experimental/private-use identifiers should
     be confined to a clearly segregated range as defined by the profile
     registry document for the SWP spec kit.

  7.  Conformance Classes and Golden Vectors

     SWP defines conformance classes (C0 through C5) to enable scoped
     implementation claims.  Each class corresponds to a set of required
     vector namespaces.  Implementations MUST state which conformance
     class claims are supported.







  Tejido                   Expires 24 August 2026                 [Page 8]


  Internet-Draft                  SWP Core                   February 2026


  7.1.  Conformance Classes

     Conformance classes are cumulative.  A higher class includes all
     requirements of lower classes.  The class taxonomy is:

     +=======+============+===========================================+
     | Class | Intended   | Required components (illustrative)        |
     |       | claim      |                                           |
     +=======+============+===========================================+
     | C0    | Core       | Core framing + E1 encoding + S1 binding   |
     |       | baseline   | requirements                              |
     +-------+------------+-------------------------------------------+
     | C1    | MCP bridge | C0 + MCP mapping profile                  |
     +-------+------------+-------------------------------------------+
     | C2    | A2A        | C0 + A2A profile                          |
     |       | baseline   |                                           |
     +-------+------------+-------------------------------------------+
     | C3    | Runtime    | C0 + RPC + EVENTS + OBS profiles          |
     |       | primitives |                                           |
     +-------+------------+-------------------------------------------+
     | C4    | Data plane | C3 + ARTIFACT + STATE profiles            |
     +-------+------------+-------------------------------------------+
     | C5    | Federation | C4 + discovery + tool discovery +         |
     |       |            | credential + policy hint + relay profiles |
     +-------+------------+-------------------------------------------+

                      Table 1: SWP Conformance Classes

  7.2.  Golden Vector Format

     The conformance suite consists of golden vectors.  Each vector pairs:

     *  a binary fixture (.bin) containing the exact on-the-wire frame
        bytes (u32_be length + E1 envelope bytes);

     *  a JSON descriptor (.json) containing expected outcome (accept/
        reject), expected error codes, and assertions.

     Vectors include positive cases, negative cases exercising each
     rejection path, and boundary cases for size limits and reserved/
     unknown behaviours.  Profiles MUST provide vectors for required
     invariants and error handling.

     A spec-vector runner executes vectors and emits a reproducible JSON
     summary.  The runner supports a strict "no-fallback" mode that fails
     any vector requiring fallback evaluation.  This enables a clear
     distinction between (a) specification-level validation and (b)
     implementation-only conformance runs.



  Tejido                   Expires 24 August 2026                 [Page 9]


  Internet-Draft                  SWP Core                   February 2026


     The SWP spec kit includes runner output schema documentation and
     artefact bundle guidance.  Implementations SHOULD publish artefact
     bundles (stdout logs and JSON summaries) when making public
     conformance claims.

     Wire fixture (.bin):
       [u32_be N] [E1 envelope bytes]

     E1 layout (field order):
       version(uvarint)=1
       profile_id(uvarint)=1
       msg_type(uvarint)=1
       flags(uvarint)=0
       ts_unix_ms(uvarint)=0
       msg_id(bytes)=len 16 + 16 octets
       extensions(bytes)=len 0
       payload(bytes)=len 0

     Expected (.json):
       {
         "vector_id": "e1_0001_valid_min_envelope",
         "expected": {
           "outcome": "accept",
           "assert": {
             "version": 1,
             "profile_id": 1,
             "msg_type": 1,
             "payload_len": 0
           }
         }
       }

              Figure 1: Example Conformance Vector (Illustrative)

  8.  Security Considerations

     SWP Core is intended for federated deployments and therefore
     specifies a security binding (S1) that constrains channel properties
     required before frames are processed.

  8.1.  S1 Security Binding

     S1 requires that SWP frames be carried over an authenticated
     confidential channel providing: confidentiality, integrity, peer
     authentication, replay resistance, and downgrade resistance.






  Tejido                   Expires 24 August 2026                [Page 10]


  Internet-Draft                  SWP Core                   February 2026


     A concrete and widely deployed instantiation is TLS 1.3 (RFC 8446,
     https://datatracker.ietf.org/doc/html/rfc8446
     (https://datatracker.ietf.org/doc/html/rfc8446)).  When TLS is used,
     implementations SHOULD use deployment-appropriate authentication
     (e.g., mutual TLS) and MUST fail closed on authentication or
     integrity failures.

     SWP Core includes a sender timestamp (ts_unix_ms) that MAY be used
     for freshness enforcement.  If freshness enforcement is enabled,
     receivers MUST reject frames outside a configured acceptance window.
     If freshness enforcement is disabled, this MUST be documented by the
     implementation and deployment.

  8.2.  Credential/Delegation and Policy Hints

     Federated agent/tool systems often require delegation ("act on behalf
     of") and constraint propagation.  SWP profiles may carry credential
     and delegation artefacts as opaque tokens with explicit expiry and
     chain-length limits, and may carry policy hints (e.g., residency
     restrictions, cost budgets, network restrictions) with defined
     conflict and violation signalling.

     These profiles are intentionally minimal and do not define a full IAM
     system or policy language.  They provide a portable signalling
     surface suitable for relays and cross-organisation governance.

  8.3.  Observability Context Propagation

     Distributed tracing propagation is standardised by W3C Trace Context
     (https://www.w3.org/TR/trace-context/ (https://www.w3.org/TR/trace-
     context/)).  OpenTelemetry adopts W3C Trace Context as the default
     propagation format and documents context propagation behaviour at
     https://opentelemetry.io/docs/concepts/context-propagation/
     (https://opentelemetry.io/docs/concepts/context-propagation/).  SWP
     observability profiles align with these standards to enable cross-hop
     trace correlation without proprietary propagation conventions.

     Implementations SHOULD avoid propagating sensitive identifiers across
     organisational boundaries and SHOULD apply data minimisation to
     propagated context.











  Tejido                   Expires 24 August 2026                [Page 11]


  Internet-Draft                  SWP Core                   February 2026


  9.  Implementation Status

     The SWP spec kit is accompanied by an executable proof-of-concept
     (PoC) implementation used to generate and validate conformance
     vectors via the spec-vector runner.  The PoC is a reference artefact
     rather than a production deployment, intended to exercise framing,
     envelope decoding/encoding, profile dispatch, and conformance
     evaluation end-to-end.

     Earlier iterations used JSON payload parsing for some profile
     handlers while specifying P1 protobuf payload binding as normative.
     This mismatch has been resolved: P1 protobuf payload binding is now
     both normative for applicable profiles and implemented in the PoC for
     spec-vector execution.  MCP mapping remains byte-preserving and
     carries JSON-RPC bytes opaquely to avoid semantic drift.

  10.  Evaluation and Reproducibility

     SWP evaluation is grounded in machine-verifiable conformance
     artefacts.  The spec-vector runner executes golden vectors and emits
     a JSON summary with a versioned schema, run provenance, per-vector
     results, and explicit indication of fallback usage.  Strict mode (no-
     fallback) provides an implementation-only signal.

     The SWP spec kit recommends publishing a conformance artefact bundle
     consisting of: (1) runner command lines, (2) runner stdout logs, (3)
     JSON summaries, and (4) the runner output schema documentation.

  # Default run (fallback permitted)
  make vectors SPEC_VECTOR_ARGS="-pattern 'conformance/vectors/core_*.json' -json-out artifacts/conformance/core.default.json"

  # Strict run (implementation-only; fallback disallowed)
  make vectors-strict SPEC_VECTOR_ARGS="-pattern 'conformance/vectors/core_*.json' -json-out artifacts/conformance/core.strict.json"

  # Optional convenience targets (if provided by the repository)
  make conformance-core
  make conformance-all

             Figure 2: Illustrative Artefact Bundle Commands

  11.  Deployment and Interoperability Scenarios

     SWP is designed for incremental adoption.  Representative scenarios
     include:







  Tejido                   Expires 24 August 2026                [Page 12]


  Internet-Draft                  SWP Core                   February 2026


     *  _MCP bridging (C1)_: deploy SWP Core + MCP mapping behind a
        gateway that translates between MCP transports and SWP framing.
        MCP payload bytes remain opaque and can be forwarded byte-
        preservingly.

     *  _Federated delegation (C2)_: two organisations exchange agent
        tasks using SWP Core + A2A profile over an S1-compliant channel,
        with stable peer identity surfacing for authorisation and audit.

     *  _Unified RPC/events/artefacts (C3/C4/C5)_: a deployment uses SWP
        profiles for RPC, events, observability, and artifact transfer to
        carry task execution, progress, trace correlation, and artefact
        references on a single secured connection.

  12.  Limitations and Non-Goals

     SWP Core is intentionally narrow.  The following are explicit non-
     goals for this document:

     *  Replacing MCP or A2A; SWP is intended to carry and bridge them as
        profiles.

     *  Defining a new IAM system or full policy language; credential and
        policy profiles are propagation/signalling surfaces.

     *  Mandating a single transport; SWP runs over any channel meeting
        S1.

     *  Specifying message-level end-to-end cryptography across relays; S1
        is a channel security binding.

     *  Providing Core-level multiplexing; multiplexing is transport- or
        profile-level.

     This document is a Core substrate specification.  Profile
     specifications define additional semantics and may impose further
     requirements for particular deployment environments.

  13.  Conclusion

     SWP Core provides a minimal, independently implementable substrate
     for federated agent/tool communication: a rigorous record layer, a
     compact envelope with mandatory E1 encoding, explicit profile
     dispatch, and a conformance model based on classes, golden vectors,
     and reproducible artefact bundles.  By separating a stable substrate
     from evolving application semantics (profiles), SWP aims to reduce
     bespoke gateway logic and make interoperability claims verifiable.




  Tejido                   Expires 24 August 2026                [Page 13]


  Internet-Draft                  SWP Core                   February 2026


  14.  IANA Considerations

     This document makes no requests of IANA.

  15.  References

  15.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/rfc/rfc2119>.

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

  15.2.  Informative References

     [A2A]      contributors, A. P. A., "Agent2Agent (A2A) Protocol",
                2025, <https://a2a-protocol.org/>.

     [A2A-BLOG] Blog, G. D., "A2A: A New Era of Agent Interoperability",
                2025, <https://developers.googleblog.com/en/a2a-a-new-era-
                of-agent-interoperability/>.

     [FIPA-ACL] FIPA, "FIPA ACL Message Structure Specification", 2002,
                <https://www.fipa.org/specs/fipa00071/XC00071B.pdf>.

     [GRPC]     Authors, G., "gRPC", 2025, <https://grpc.io/>.

     [GRPC-H2]  Project, G., "gRPC over HTTP/2 Protocol", 2025,
                <https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-
                HTTP2.md>.

     [KQML]     UMBC, "Knowledge Query and Manipulation Language (KQML)",
                1997, <https://www.cs.umbc.edu/research/kqml/>.

     [MCP]      contributors, A. A., "Model Context Protocol (MCP)
                Specification", 2025,
                <https://modelcontextprotocol.io/specification/>.

     [OTEL-PROP]
                Authors, O., "OpenTelemetry Context Propagation", 2025,
                <https://opentelemetry.io/docs/concepts/context-
                propagation/>.

     [PROTOBUF] Google, "Protocol Buffers: Proto3 Language Guide", 2025,
                <https://protobuf.dev/programming-guides/proto3/>.



  Tejido                   Expires 24 August 2026                [Page 14]


  Internet-Draft                  SWP Core                   February 2026


     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, August 2018,
                <https://datatracker.ietf.org/doc/html/rfc8446>.

     [RFC9113]  Thomson, M. and C. Benfield, "HTTP/2", RFC 9113, June
                2022, <https://datatracker.ietf.org/doc/html/rfc9113>.

     [W3C-TRACE]
                W3C, "Trace Context", 2021,
                <https://www.w3.org/TR/trace-context/>.

  Appendix: Implementation and Conformance Notes (Informative)

     Implementations that claim SWP conformance should publish: (1)
     supported conformance classes, (2) artefact bundle outputs from
     default and strict runs, and (3) any deployment-specific policy
     parameters (size limits, timestamp freshness policy, peer
     authentication mode).  The SWP spec kit includes runner output schema
     documentation and conformance claim checklists.

  Author's Address

     Jericko Tejido
     Email: jtbibliomania@gmail.com



























  Tejido                   Expires 24 August 2026                [Page 15]


name: draft-drake-email-tpm-attestation
rev: 00
title: Hardware Attestation for Email Sender Verification
time: 2026-02-20T00:16:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-24T00:16:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.676816+00:00
source: ietf
abstract:
  This document defines a mechanism for email senders to include
     hardware attestation evidence in message headers, enabling receiving
     mail servers to cryptographically verify that an email was composed
     on a machine containing a genuine Trusted Platform Module (TPM) from
     a known manufacturer (Intel, AMD, Infineon, or similar).  The
     verification chain runs from the email header directly to the TPM
     manufacturer's root Certificate Authority, requiring no trust in any
     intermediary identity service.

     As a companion mechanism, this document also defines a privacy-
     preserving alternative using SD-JWT (Selective Disclosure JWT, RFC
     9901) where the sender can prove specific claims about their hardware
     trust level without revealing their hardware identity.

     Together, these mechanisms provide Sybil-resistant email
     authentication: each sender requires a unique physical security chip,
     making large-scale automated spam economically infeasible regardless
     of advances in artificial intelligence.

     While this document specifies these mechanisms for email message
     headers, the attestation formats defined herein - both the CMS
     attestation bundle and the SD-JWT trust proof - are self-contained,
     transport-independent data structures applicable to HTTP headers,
     agent-to-agent messaging, and other Internet protocols.

full_text:
  Internet Engineering Task Force                                 C. Drake
  Internet-Draft                                                   1id.com
  Intended status: Standards Track                        19 February 2026
  Expires: 23 August 2026


             Hardware Attestation for Email Sender Verification
                    draft-drake-email-tpm-attestation-00

  Abstract

     This document defines a mechanism for email senders to include
     hardware attestation evidence in message headers, enabling receiving
     mail servers to cryptographically verify that an email was composed
     on a machine containing a genuine Trusted Platform Module (TPM) from
     a known manufacturer (Intel, AMD, Infineon, or similar).  The
     verification chain runs from the email header directly to the TPM
     manufacturer's root Certificate Authority, requiring no trust in any
     intermediary identity service.

     As a companion mechanism, this document also defines a privacy-
     preserving alternative using SD-JWT (Selective Disclosure JWT, RFC
     9901) where the sender can prove specific claims about their hardware
     trust level without revealing their hardware identity.

     Together, these mechanisms provide Sybil-resistant email
     authentication: each sender requires a unique physical security chip,
     making large-scale automated spam economically infeasible regardless
     of advances in artificial intelligence.

     While this document specifies these mechanisms for email message
     headers, the attestation formats defined herein - both the CMS
     attestation bundle and the SD-JWT trust proof - are self-contained,
     transport-independent data structures applicable to HTTP headers,
     agent-to-agent messaging, and other Internet protocols.

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






  Drake                    Expires 23 August 2026                 [Page 1]


  Internet-Draft            TPM Email Attestation            February 2026


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

     This Internet-Draft will expire on 23 August 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Mode 1: Direct TPM Attestation  . . . . . . . . . . . . . . .   7
       4.1.  Attestation Certificate Chain . . . . . . . . . . . . . .   7
       4.2.  Header Field Definition . . . . . . . . . . . . . . . . .   7
       4.3.  Verification Algorithm  . . . . . . . . . . . . . . . . .   9
       4.4.  Authentication-Results Integration  . . . . . . . . . . .  10
       4.5.  Privacy Considerations for Direct Attestation . . . . . .  11
     5.  Mode 2: SD-JWT Trust Proof  . . . . . . . . . . . . . . . . .  11
       5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.2.  Header Field Definition . . . . . . . . . . . . . . . . .  11
       5.3.  Verification Algorithm  . . . . . . . . . . . . . . . . .  12
       5.4.  Authentication-Results Integration  . . . . . . . . . . .  13
     6.  Combined Mode . . . . . . . . . . . . . . . . . . . . . . . .  14
     7.  Sybil Resistance Properties . . . . . . . . . . . . . . . . .  14
       7.1.  Direct TPM Attestation (Mode 1) . . . . . . . . . . . . .  14
       7.2.  SD-JWT Trust Proof (Mode 2) . . . . . . . . . . . . . . .  15
       7.3.  Virtual TPMs  . . . . . . . . . . . . . . . . . . . . . .  15
     8.  Interaction with Existing Email Authentication  . . . . . . .  15
       8.1.  Multiple Headers and Forwarding . . . . . . . . . . . . .  16
     9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  16
       9.1.  1id.com Trust Registry  . . . . . . . . . . . . . . . . .  17



  Drake                    Expires 23 August 2026                 [Page 2]


  Internet-Draft            TPM Email Attestation            February 2026


     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
       10.1.  Header Field Registration  . . . . . . . . . . . . . . .  18
       10.2.  Authentication Method Registration . . . . . . . . . . .  18
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  18
       11.1.  Manufacturer CA Compromise . . . . . . . . . . . . . . .  18
       11.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  18
       11.3.  Compromised Endpoints and Privilege Requirements . . . .  19
       11.4.  Physical Attacks on TPMs . . . . . . . . . . . . . . . .  19
       11.5.  Virtual TPM Risk . . . . . . . . . . . . . . . . . . . .  20
       11.6.  Policy Abuse and Deanonymisation Risk  . . . . . . . . .  20
       11.7.  Header Stripping and Modification  . . . . . . . . . . .  20
     12. Normative References  . . . . . . . . . . . . . . . . . . . .  21
     13. Informative References  . . . . . . . . . . . . . . . . . . .  21
     Appendix A.  Appendix: Economics of Hardware-Based Sybil
             Resistance  . . . . . . . . . . . . . . . . . . . . . . .  23
     Appendix B.  Appendix: TPM Manufacturer Root CAs  . . . . . . . .  23
     Appendix C.  Appendix: Applicability to Other Transports  . . . .  24
     Appendix D.  Acknowledgements . . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     Email authentication today relies on three complementary mechanisms:
     SPF [RFC7208] verifies the sending IP address, DKIM [RFC6376]
     provides a domain-level cryptographic signature, and DMARC [RFC7489]
     ties them together with policy.  These mechanisms prove that an email
     was authorised by a domain.  They do not prove anything about the
     physical infrastructure that composed or sent the message.

     This distinction has become critical.  The rapid proliferation of
     autonomous AI agents capable of composing human-quality text has
     rendered content-based spam detection increasingly ineffective.  An
     attacker can register unlimited domains, configure valid SPF/DKIM/
     DMARC, and use AI to generate messages indistinguishable from
     legitimate correspondence.  Every existing defence - CAPTCHAs, phone
     verification, behavioural analysis, IP reputation - fails when the
     attacker is an AI that can operate at scale with near-zero marginal
     cost.

     The fundamental problem is that all existing sender identity signals
     are software-based and therefore copyable at zero cost.  This
     document proposes anchoring sender identity to physics, applying the
     remote attestation architecture of [RFC9334] to email: specifically,
     to the Trusted Platform Module (TPM) chip present in virtually every
     modern PC, server, and many embedded devices.






  Drake                    Expires 23 August 2026                 [Page 3]


  Internet-Draft            TPM Email Attestation            February 2026


     A TPM contains a unique Endorsement Key (EK) burned in at the factory
     by the chip manufacturer, with a certificate chaining to the
     manufacturer's root CA.  This key cannot be extracted, cloned, or
     transferred.  By signing email content with a TPM-resident key and
     including the certificate chain in the message headers, a sender
     proves that the email originated on a specific, genuine piece of
     hardware.

     Receiving mail servers can verify this proof by validating the
     certificate chain against manufacturer root CAs - the same CAs they
     already trust for Secure Boot, platform integrity, and other TPM-
     dependent operations.  No new trust relationships are required.

     This document defines two complementary mechanisms:

     1.  *Direct TPM Attestation* (Section 4): A CMS [RFC5652] signed-data
         structure containing the attestation signature and full
         certificate chain, carried in an email header.  Verifiable
         directly against manufacturer root CAs.  Optimised for
         deliverability.

     2.  *SD-JWT Trust Proof* (Section 5): A Selective Disclosure JWT
         [RFC9901] issued by a trust registry, where the sender selects
         which claims to reveal.  Optimised for privacy in contexts where
         revealing hardware identity is undesirable.

     While this document defines these mechanisms for email, the
     attestation formats themselves are transport-independent: the CMS
     attestation bundle and SD-JWT trust proof are self-contained data
     structures that can be carried in any protocol capable of
     transporting octet strings.  Appendix C discusses applicability to
     HTTP and other protocols.

  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.

  1.2.  Terminology

     TPM  Trusted Platform Module, as specified by the Trusted Computing
        Group (TCG) [TCG-TPM2].  This document assumes TPM 2.0.

     EK  Endorsement Key.  A unique RSA or ECC key pair generated inside




  Drake                    Expires 23 August 2026                 [Page 4]


  Internet-Draft            TPM Email Attestation            February 2026


        the TPM at manufacturing time, as profiled in [TCG-EK-PROFILE].
        The EK private key never leaves the TPM.  The EK certificate is
        signed by the chip manufacturer's CA.

     AK  Attestation Key.  A signing key generated inside the TPM after
        deployment, certified by the EK (via TPM2_Certify) to prove it
        resides in the same TPM.  Used for signing operations in this
        protocol.

     Manufacturer CA  The Certificate Authority operated by the TPM chip
        manufacturer (e.g., Intel, AMD, Infineon) that signs EK
        certificates.  Root CA certificates are publicly available.

     Trust Registry  An entity that verifies TPM attestation evidence at
        enrollment time and subsequently issues trust assertions (e.g.,
        SD-JWTs) about enrolled entities.  A Trust Registry is OPTIONAL
        for Mode 1 (Direct TPM Attestation) and REQUIRED for Mode 2 (SD-
        JWT Trust Proof).

     HSM  Hardware Security Module.  A physical device that safeguards
        cryptographic keys and provides cryptographic processing.  TPMs
        are one category of HSM; portable smart cards (such as PIV-capable
        YubiKeys) are another.  This document focuses on TPM-based
        attestation; companion documents may address other HSM types.

     Sybil Attack  An attack where a single adversary creates many
        pseudonymous identities to subvert a reputation or trust system.

  2.  Problem Statement

     The economic model of email spam has historically depended on the
     near-zero cost of sending messages.  Anti-spam defences have worked
     by raising costs (CAPTCHAs impose human attention costs, IP
     reputation requires infrastructure investment, phone verification
     requires SIM procurement).

     AI agents eliminate these costs.  An AI can solve CAPTCHAs, generate
     unique content for each message, rotate through residential proxy
     IPs, and operate continuously without human attention.  The result is
     that cost-based anti-spam defences approach zero effectiveness as AI
     capabilities improve.










  Drake                    Expires 23 August 2026                 [Page 5]


  Internet-Draft            TPM Email Attestation            February 2026


     Hardware attestation re-introduces a cost floor that AI cannot
     eliminate: each sender identity requires a physical TPM chip.  TPM
     chips have real manufacturing costs, exist in physical supply chains,
     and each contains a globally unique key pair certified by the
     manufacturer.  An attacker seeking to create N sender identities
     needs N physical machines, each with a genuine TPM - a cost of
     approximately $500-2000 per identity (machine + TPM) compared to
     approximately $0 per identity with software-only approaches.

     Furthermore, because each TPM identity is unique and persistent,
     receiving mail servers can build per-hardware reputation.  A TPM that
     sends spam is flagged permanently.  The attacker cannot simply create
     a new account - they need new physical hardware.

  3.  Applicability

     This specification targets authentication of automated senders - AI
     agents, bots, and high-volume automated systems - where Sybil
     resistance justifies hardware-anchored identity.  The proliferation
     of autonomous AI agents capable of generating human-quality content
     at scale is the primary motivation.

     This specification is NOT intended or recommended for individual
     human users sending personal or low-volume email.  Human senders
     using consumer mail user agents (e.g., Gmail web client, Outlook)
     face privacy risks from Mode 1 Direct Attestation that are
     disproportionate to the benefit: the hardware fingerprint (EK public
     key hash) uniquely identifies the sending machine across all messages
     and contexts, enabling long-term tracking that exceeds current email
     privacy norms.  Mode 2 (SD-JWT Trust Proof) mitigates this via
     selective disclosure but requires enrollment with a Trust Registry,
     which is not a typical consumer workflow.

     Operators of human-facing email services MAY offer TPM attestation as
     an opt-in feature (e.g., via a browser extension or MUA plugin), but
     MUST provide clear disclosure of the linkability implications before
     activation.  Receivers SHOULD NOT penalise the absence of TPM
     attestation from senders exhibiting human-characteristic patterns
     (e.g., low volume, natural language variance, interactive reply
     chains).

     For human identity proofs in email, existing mechanisms such as S/
     MIME [RFC8551] and DANE [RFC7671] remain appropriate.

     The attestation formats defined in this document - both the CMS
     attestation bundle and the SD-JWT trust proof - are self-contained
     data structures not inherently specific to email.  They can be
     carried in HTTP headers, HTTP request bodies, WebSocket messages, or



  Drake                    Expires 23 August 2026                 [Page 6]


  Internet-Draft            TPM Email Attestation            February 2026


     any protocol supporting opaque octet strings.  Appendix C discusses
     applicability to other transports.  This document specifies the email
     transport binding as the primary application.

  4.  Mode 1: Direct TPM Attestation

     This section defines a CMS-based attestation bundle containing a
     hardware-anchored signature and its full certificate chain.  While
     presented here in the context of email headers (Section 4.2), the CMS
     SignedData structure is a self-contained, transport-independent data
     object; see Appendix C for applicability to other protocols.

  4.1.  Attestation Certificate Chain

     The attestation chain consists of the following certificates, ordered
     from leaf to root:

     1.  *AK Certificate:* Created by TPM2_Certify, binding the AK public
         key to the EK-identified TPM.  Contains the AK public key and the
         EK's certification signature.

     2.  *EK Certificate:* Issued by the TPM manufacturer at fabrication
         time.  Contains the EK public key, TPM manufacturer identity, and
         TPM model information.  Signed by the manufacturer's intermediate
         CA.

     3.  *Manufacturer Intermediate CA Certificate(s):* Zero or more
         intermediate CA certificates forming the chain between the EK
         certificate issuer and the manufacturer root.

     4.  *Manufacturer Root CA Certificate:* The trust anchor.  This
         certificate SHOULD already be present in the verifier's trust
         store.  Major TPM manufacturer root CAs are published at well-
         known URLs (e.g., Intel's Trusted Services API, AMD's Key
         Distribution Server).

  4.2.  Header Field Definition

     This document defines the "TPM-Attestation" header field for use in
     email messages.











  Drake                    Expires 23 August 2026                 [Page 7]


  Internet-Draft            TPM Email Attestation            February 2026


     TPM-Attestation = "TPM-Attestation" ":" SP tpm-attest-value CRLF

     tpm-attest-value = tpm-version ";" SP
                        tpm-algorithm ";" SP
                        tpm-body-hash ";" SP
                        tpm-timestamp ";" SP
                        tpm-chain

     tpm-version    = "v" "=" "1"
     tpm-algorithm  = "alg" "=" ("RS256" / "ES256" / "PS256")
     tpm-body-hash  = "bh" "=" base64url
     tpm-timestamp  = "ts" "=" 1*DIGIT
     tpm-chain      = "chain" "=" base64

     Where:

     v  Protocol version.  MUST be "1" for this specification.

     alg  The signature algorithm used by the AK.  MUST be one of RS256
        (RSASSA-PKCS1-v1_5 with SHA-256), ES256 (ECDSA with P-256 and SHA-
        256), or PS256 (RSASSA-PSS with SHA-256).  RS256 is RECOMMENDED
        for maximum compatibility with existing TPM deployments.

     bh  The base64url-encoded SHA-256 hash of the canonicalised email
        body, computed using the same canonicalisation algorithm as DKIM
        simple body canonicalisation Section 3.4.3 of [RFC6376].

     ts  Unix timestamp (seconds since 1970-01-01T00:00:00Z) at which the
        attestation signature was created.

     chain  A base64-encoded CMS SignedData structure [RFC5652]
        containing:

        *  The AK signature over the concatenation of the body hash and
           timestamp: Sign(AK, SHA-256(bh || ts))

        *  The AK certificate

        *  The EK certificate

        *  Any intermediate CA certificates

        The CMS structure uses the SignedData content type (OID
        1.2.840.113549.1.7.2).  The encapContentInfo MUST be absent
        (detached signature); the signed content is the body hash
        concatenated with the timestamp, provided in the bh and ts fields.





  Drake                    Expires 23 August 2026                 [Page 8]


  Internet-Draft            TPM Email Attestation            February 2026


  4.3.  Verification Algorithm

     A receiving mail server that supports this specification MUST perform
     the following steps when a TPM-Attestation header is present:

     1.  Parse the TPM-Attestation header field and extract v, alg, bh,
         ts, and chain.  If parsing fails, the result is "none" (header
         malformed).

     2.  Verify that v equals "1".  If not, the result is "none"
         (unsupported version).

     3.  Compute the SHA-256 hash of the canonicalised email body using
         DKIM simple body canonicalisation.  Compare with bh.  If they
         differ, the result is "fail" (body modified).

     4.  Verify that ts is within an acceptable window of the current
         time.  A window of 300 seconds (5 minutes) is RECOMMENDED for
         direct SMTP delivery.  Verifiers SHOULD allow a wider window (up
         to 3600 seconds / 1 hour) for messages that have passed through
         intermediate MTAs, as indicated by Received headers or queue
         delays.  The ts value reflects when the sender created the
         attestation, not when the MTA transmitted the message; multi-hop
         delivery and temporary queue backlogs are common operational
         realities.  If ts is outside the acceptable window, the result is
         "fail" (timestamp expired).

     5.  Decode the base64 chain value and parse as a CMS SignedData
         structure.  Extract the signer certificate (AK certificate) and
         the certificate chain.

     6.  Validate the certificate chain:

         a.  The AK certificate MUST contain a TPM2_Certify structure in
             an extension or as the subject, binding the AK public key to
             the EK.

         b.  The EK certificate MUST chain to a manufacturer intermediate
             CA certificate.

         c.  The manufacturer intermediate CA MUST chain to a manufacturer
             root CA present in the verifier's TPM manufacturer CA trust
             store.

         If chain validation fails, the result is "fail" (chain invalid).






  Drake                    Expires 23 August 2026                 [Page 9]


  Internet-Draft            TPM Email Attestation            February 2026


     7.  Verify the CMS signature using the AK public key and the
         specified algorithm.  The signed content is SHA-256(bh || ts).
         If signature verification fails, the result is "fail" (bad
         signature).

     8.  If all checks pass, the result is "pass".  The verifier MAY
         extract the following information from the certificate chain:

         *  TPM manufacturer (from EK certificate issuer)

         *  TPM model or family (from EK certificate extensions)

         *  Hardware fingerprint: SHA-256 hash of the EK public key

  4.4.  Authentication-Results Integration

     When recording the result of TPM-Attestation verification in an
     Authentication-Results header field [RFC8601], the following method
     identifier and property types are used:

     Authentication-Results: mx.example.com;
       tpm-attest=pass
         header.alg=RS256
         header.mfr=INTC
         header.hw=tpm2.0
         header.chip=sha256:a1b2c3d4...

     Where:

     tpm-attest  The method identifier.  Result is one of: "pass", "fail",
        "none" (header absent or unparseable), "temperror" (transient
        verification error), or "permerror" (permanent verification
        error).

     header.alg  The signature algorithm from the TPM-Attestation header.

     header.mfr  The TPM manufacturer code extracted from the EK
        certificate.  Common values: "INTC" (Intel), "AMD" (AMD), "IFX"
        (Infineon), "STM" (STMicroelectronics), "NTC" (Nuvoton), "VMW"
        (VMware, virtual TPM).

     header.hw  The hardware type.  "tpm2.0" for a hardware or firmware
        TPM.  "vtpm2.0" for a hypervisor-provided virtual TPM.

     header.chip  The SHA-256 hash of the EK public key, truncated to the
        first 16 hex characters.  This serves as a compact hardware
        fingerprint for reputation tracking.  Full fingerprint SHOULD be
        available via an extended property.



  Drake                    Expires 23 August 2026                [Page 10]


  Internet-Draft            TPM Email Attestation            February 2026


  4.5.  Privacy Considerations for Direct Attestation

     Direct TPM Attestation reveals the sender's hardware fingerprint (EK
     public key hash).  This fingerprint is stable across all emails sent
     by the same machine, enabling linkability.  This is a deliberate
     design choice: linkability is desirable for reputation systems (a
     hardware identity that sends spam can be permanently flagged) and is
     the mechanism by which Sybil resistance is achieved.

     Senders who require unlinkability between messages SHOULD use Mode 2
     (SD-JWT Trust Proof, Section 5) instead of or in addition to Direct
     TPM Attestation.

     The EK certificate also reveals the TPM manufacturer and model
     family.  In most deployments, this information is not sensitive.  If
     the sender considers hardware provenance information sensitive, they
     SHOULD use Mode 2 exclusively.

  5.  Mode 2: SD-JWT Trust Proof

     This section defines an SD-JWT-based trust proof.  SD-JWT ([RFC9901])
     is inherently transport-independent; see Appendix C for applicability
     beyond email.

  5.1.  Overview

     SD-JWT Trust Proof provides an alternative attestation mechanism
     where a Trust Registry (an entity that has previously verified the
     sender's hardware attestation) issues a Selective Disclosure JWT
     [RFC9901] containing claims about the sender's trust classification.
     The claim structure is informed by the Entity Attestation Token (EAT)
     model [RFC9711].

     The sender can then present this SD-JWT to email recipients with only
     the claims it chooses to disclose.  For example, a sender might prove
     "my hardware trust level is sovereign" (indicating a genuine, non-
     virtual TPM was verified) without revealing its identity, hardware
     fingerprint, or registration date.  The Trust Registry issuer (iss)
     is always visible in the SD-JWT (required for signature
     verification), but all other claims are selectively disclosable.

     This mode requires the recipient to trust the Trust Registry's
     signing key (obtainable via the registry's JWKS endpoint).  It does
     NOT require trust in any TPM manufacturer CA, as the Trust Registry
     has already performed that verification.

  5.2.  Header Field Definition




  Drake                    Expires 23 August 2026                [Page 11]


  Internet-Draft            TPM Email Attestation            February 2026


     TPM-Trust-Proof = "TPM-Trust-Proof" ":" SP sd-jwt-compact CRLF

     sd-jwt-compact = sd-jwt "~" *( disclosure "~" ) kb-jwt

     ; sd-jwt, disclosure, and kb-jwt are defined in RFC 9901

     The header value is a complete SD-JWT presentation as defined in
     [RFC9901], including optional disclosures and a Key Binding JWT (KB-
     JWT).

     The SD-JWT payload MUST include the following claims:

     iss  The Trust Registry's identifier (a URI).  Used to locate the
        Trust Registry's JWKS for signature verification.

     iat  Issuance time as a NumericDate.

     exp  Expiration time as a NumericDate.  MUST NOT exceed 7 days after
        iat.

     _sd  Array of digests for selectively disclosable claims, as defined
        in [RFC9901].

     cnf  Confirmation claim containing the sender's public key (JWK
        format).  When the sender's key is TPM-bound, this enables holder
        binding: the recipient can verify that the presenter possesses the
        TPM-resident private key corresponding to this public key.

     The following claims SHOULD be available for selective disclosure
     (present as hashed entries in _sd):

     trust_tier  The sender's hardware trust classification.  Values
        defined by the Trust Registry (e.g., "sovereign" for genuine non-
        virtual TPM, "virtual" for hypervisor-provided TPM, "declared" for
        software-only).

     sub  The sender's identifier within the Trust Registry.

     handle  A human-readable name for the sender, if assigned.

     hsm_manufacturer  The TPM manufacturer code (e.g., "INTC", "AMD").

     enrolled_at  The timestamp at which the sender enrolled with the
        Trust Registry.

  5.3.  Verification Algorithm





  Drake                    Expires 23 August 2026                [Page 12]


  Internet-Draft            TPM Email Attestation            February 2026


     1.  Parse the TPM-Trust-Proof header as an SD-JWT presentation per
         [RFC9901].

     2.  Extract the issuer (iss) claim from the SD-JWT payload.

     3.  Fetch the issuer's JWKS from the well-known endpoint (e.g.,
         {iss}/.well-known/jwks.json) or from a locally cached copy.  The
         JWKS SHOULD be cached with a TTL of at least 1 hour and at most
         24 hours.

     4.  Verify the SD-JWT signature against the issuer's public key per
         [RFC9901].

     5.  Verify that exp has not passed and iat is within an acceptable
         window.

     6.  For each disclosure present, verify that its hash matches an
         entry in the _sd array.

     7.  If a Key Binding JWT (KB-JWT) is present and the SD-JWT contains
         a cnf claim, verify the KB-JWT signature against the cnf key.
         This proves the presenter holds the private key (which, if TPM-
         bound, proves the email was composed on the enrolled hardware).

     8.  Extract the disclosed claims.  The result is "pass" with the set
         of verified claims.

  5.4.  Authentication-Results Integration

     Authentication-Results: mx.example.com;
       tpm-trust=pass
         header.trust_tier=sovereign
         header.registry=registry.example.com
         header.kb=tpm-bound

     tpm-trust  The method identifier.  Result values are the same as for
        tpm-attest.

     header.trust_tier  The disclosed trust tier value, if the sender
        chose to reveal it.

     header.registry  The Trust Registry identifier (from the iss claim).

     header.kb  "tpm-bound" if the KB-JWT was verified against a cnf key
        known to be TPM-resident.  "software" if the key binding used a
        software key.  "none" if no KB-JWT was present.





  Drake                    Expires 23 August 2026                [Page 13]


  Internet-Draft            TPM Email Attestation            February 2026


  6.  Combined Mode

     A sending agent MAY include both TPM-Attestation and TPM-Trust-Proof
     headers in the same message.  When both are present:

     *  Receivers that trust TPM manufacturer CAs but not the Trust
        Registry SHOULD verify TPM-Attestation and ignore TPM-Trust-Proof.

     *  Receivers that trust the Trust Registry but prefer not to process
        the full certificate chain SHOULD verify TPM-Trust-Proof and MAY
        ignore TPM-Attestation.

     *  Receivers that support both SHOULD verify both and record both
        results in Authentication-Results.  Agreement between the two
        mechanisms provides defence-in-depth: compromising either the
        manufacturer CA or the Trust Registry alone is insufficient to
        forge both attestations.

     The two mechanisms are independent.  Failure of one MUST NOT cause
     the other to be treated as failed.

  7.  Sybil Resistance Properties

     The primary security goal of this specification is Sybil resistance:
     making it economically infeasible for an attacker to create many
     sender identities.

  7.1.  Direct TPM Attestation (Mode 1)

     Each TPM contains exactly one EK, which produces exactly one EK
     certificate.  The EK public key hash serves as a unique hardware
     fingerprint.  A receiving mail server that tracks these fingerprints
     can enforce policies such as:

     *  Rate limiting per hardware fingerprint

     *  Reputation scoring per hardware fingerprint

     *  Blocking hardware fingerprints associated with abuse

     An attacker attempting to evade these policies requires a new
     physical TPM chip (minimum cost: the chip itself at ~$20 plus a
     machine to host it at ~$200-2000), compared to zero cost for creating
     a new software identity.







  Drake                    Expires 23 August 2026                [Page 14]


  Internet-Draft            TPM Email Attestation            February 2026


  7.2.  SD-JWT Trust Proof (Mode 2)

     Sybil resistance in Mode 2 depends on the Trust Registry's enrollment
     policy.  A Trust Registry that issues trust_tier values indicating
     hardware verification (e.g., "sovereign") MUST verify hardware
     attestation at enrollment time and MUST maintain a uniqueness
     registry enforcing at most one identity per EK public key hash.  Such
     a Trust Registry provides equivalent Sybil resistance to Mode 1, with
     the additional benefit that the hardware fingerprint is not revealed
     to email recipients.

     Trust Registries SHOULD monitor for anomalous enrollment patterns
     (e.g., many enrollments from a single IP range or a sudden spike in
     enrollments from a specific manufacturer CA) and SHOULD be capable of
     suspending enrollments pending investigation.

     A Trust Registry that does not perform hardware verification (e.g.,
     one that enrolls software-only agents) provides no Sybil resistance
     and MUST NOT issue trust_tier values that imply hardware
     verification.  The trust_tier claim distinguishes these cases,
     enabling recipients to weight trust appropriately.

  7.3.  Virtual TPMs

     Virtual TPMs (vTPMs) provided by hypervisors (VMware, Hyper-V, QEMU)
     have valid EK certificates signed by the hypervisor vendor's CA, but
     the hypervisor operator can create arbitrarily many vTPMs.  This
     weakens Sybil resistance.

     Receiving mail servers SHOULD distinguish between physical TPMs and
     virtual TPMs.  The EK certificate's issuer field identifies the
     manufacturer: VMware-issued EK certificates indicate a virtual TPM.
     The header.hw property in Authentication-Results ("tpm2.0" vs
     "vtpm2.0") communicates this distinction.

     Mail servers MAY apply different policies to virtual TPM attestations
     (e.g., lower trust weighting, stricter rate limits) while still
     recognising them as superior to no attestation at all.

  8.  Interaction with Existing Email Authentication

     The mechanisms defined in this document complement rather than
     replace existing email authentication:

     SPF [RFC7208]  Verifies the sending IP is authorised for the domain.
        Orthogonal to hardware attestation.  Both SHOULD be used.

     DKIM [RFC6376]  Provides domain-level signing.  TPM-Attestation



  Drake                    Expires 23 August 2026                [Page 15]


  Internet-Draft            TPM Email Attestation            February 2026


        provides hardware-level signing.  They protect different
        properties: DKIM proves domain authorisation; TPM-Attestation
        proves hardware identity.  Both SHOULD be used.

     DMARC [RFC7489]  Ties SPF and DKIM together with policy.  A future
        extension to DMARC could incorporate TPM attestation results into
        the policy evaluation.  This is out of scope for this document.

     ARC [RFC8617]  Preserves authentication results through forwarding
        chains.  ARC SHOULD preserve TPM-Attestation and TPM-Trust-Proof
        Authentication-Results when forwarding messages.

     S/MIME [RFC8551]  Provides end-to-end encryption and sender signing
        via CA-issued certificates.  S/MIME and TPM-Attestation solve
        different problems: S/MIME proves "this email address is
        controlled by someone who presented a valid certificate"; TPM-
        Attestation proves "this email was composed on genuine, unique
        hardware".  They can coexist.

  8.1.  Multiple Headers and Forwarding

     If multiple TPM-Attestation headers are present in a message (e.g.,
     if a forwarding gateway adds its own attestation), the verifier
     SHOULD evaluate all of them independently and record each result
     separately in Authentication-Results, using the same precedence
     conventions as for multiple DKIM-Signature headers [RFC6376].

     Mailing lists and content-modifying forwarders that alter the message
     body will invalidate the body hash (bh) in any existing TPM-
     Attestation header.  This is expected and analogous to DKIM signature
     breakage through body modification.  Such intermediaries SHOULD
     preserve the original TPM-Attestation header (the verifier will
     record "fail" due to body hash mismatch) and MAY add their own TPM-
     Attestation header covering the modified body, if the intermediary
     itself has TPM capability.  ARC [RFC8617] SHOULD be used to preserve
     the original authentication results from before the modification.

  9.  Implementation Status

     NOTE TO RFC EDITOR: Please remove this section before publication.

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in [RFC7942].







  Drake                    Expires 23 August 2026                [Page 16]


  Internet-Draft            TPM Email Attestation            February 2026


  9.1.  1id.com Trust Registry

     Organisation: 1id.com (https://1id.com)

     Description: A working implementation of both Mode 1 (Direct TPM
     Attestation) and Mode 2 (SD-JWT Trust Proof) as described in this
     draft.  The implementation includes server-side EK certificate chain
     validation against manufacturer root CAs (Intel, AMD, Infineon,
     STMicroelectronics, Nuvoton, Qualcomm), anti-Sybil enforcement via a
     one-EK-per-identity registry, and SD-JWT trust proof issuance with
     selective disclosure.  The system also supports PIV-based (YubiKey)
     attestation for portable hardware tokens.

     Maturity: Beta.  Deployed in production at https://1id.com.

     Coverage: All protocol features described in this draft are
     implemented.

     Contact: Christopher Drake <cnd@1id.com>

     Open-source components:

     *  *Python SDK:* https://github.com/1id-com/oneid-sdk -- Client-side
        enrollment and attestation library.  Published to PyPI as "oneid".

     *  *Node.js SDK:* https://github.com/1id-com/oneid-node -- Client-
        side enrollment and attestation library.  Published to npm as
        "1id".

     *  *TPM/PIV helper binary:* https://github.com/1id-com/oneid-enroll
        -- Cross-platform Go binary for TPM access (Windows TBS, Linux
        /dev/tpmrm0), PIV smart card operations, privilege elevation, and
        AK provisioning.

     *  *Internet-Draft companion repository:* https://github.com/1id-com/
        draft-drake-email-tpm-attestation -- Draft XML source, example
        verification code for both modes, and test vectors.

     *  *TPM Manufacturer CA Trust Store:* https://github.com/1id-com/tpm-
        manufacturer-cas -- Community-curated collection of TPM
        manufacturer root CA certificates for EK certificate chain
        validation, as referenced in Appendix B.

  10.  IANA Considerations







  Drake                    Expires 23 August 2026                [Page 17]


  Internet-Draft            TPM Email Attestation            February 2026


  10.1.  Header Field Registration

     IANA is requested to register the following header fields in the
     "Permanent Message Header Field Names" registry:

     TPM-Attestation  Applicable protocol: mail.  Status: standard.
        Reference: this document, Section 4.2.

     TPM-Trust-Proof  Applicable protocol: mail.  Status: standard.
        Reference: this document, Section 5.2.

  10.2.  Authentication Method Registration

     IANA is requested to register the following entries in the "Email
     Authentication Methods" registry [RFC8601]:

     tpm-attest  Definition: this document, Section 4.4.  Applicable
        versions: 1.

     tpm-trust  Definition: this document, Section 5.4.  Applicable
        versions: 1.

  11.  Security Considerations

  11.1.  Manufacturer CA Compromise

     If a TPM manufacturer's root CA private key is compromised, an
     attacker could forge EK certificates and create unlimited fake
     hardware identities.  This risk is inherent to any PKI-based system
     and is mitigated by the same measures that protect manufacturer CAs
     today: hardware security modules, air-gapped signing ceremonies, and
     Certificate Transparency [RFC9162].

     The SD-JWT Trust Proof (Mode 2) provides partial mitigation: if the
     Trust Registry detects anomalous enrollment patterns (e.g., thousands
     of enrollments from a single manufacturer CA in a short period), it
     can suspend enrollments while the compromise is investigated.  This
     is analogous to how Certificate Transparency monitors detect mis-
     issued TLS certificates.

  11.2.  Replay Attacks

     The timestamp (ts) in the TPM-Attestation header limits the replay
     window.  Receiving mail servers SHOULD reject attestations with
     timestamps more than 300 seconds from the current time.
     Additionally, the body hash (bh) binds the attestation to a specific
     email body, preventing a valid attestation from being attached to a
     different message.



  Drake                    Expires 23 August 2026                [Page 18]


  Internet-Draft            TPM Email Attestation            February 2026


     For SD-JWT Trust Proofs, the Key Binding JWT includes an iat claim
     and MAY include an aud claim binding the presentation to a specific
     recipient.

  11.3.  Compromised Endpoints and Privilege Requirements

     This specification does not prevent a compromised machine from
     sending attested email - if an attacker has full control of a machine
     with a TPM, they can use that TPM to attest.  However, this is by
     design: each compromised machine contributes exactly one hardware
     identity, and that identity accrues reputation (good or bad)
     permanently.  A botnet of 10,000 compromised machines yields 10,000
     attestable identities, not the millions possible with software-only
     identity systems.

     Additionally, TPM operations provide a practical barrier against
     casual malware.  Initial provisioning of an Attestation Key - the
     one-time setup step that creates the AK and certifies it against the
     EK - typically requires elevated operating system privileges
     (administrator on Windows via the TPM Base Services API, or root on
     Linux via /dev/tpmrm0).  This means that unprivileged userspace
     malware (the most common class, distributed via phishing, drive-by
     downloads, and browser exploits) cannot provision new attestation
     keys, even if it runs on a machine with a TPM.

     Once an AK has been provisioned, subsequent signing operations
     (TPM2_Sign) MAY be available to unprivileged processes depending on
     the TPM's authorization policy and operating system configuration.
     Implementations that wish to restrict signing to authorised software
     SHOULD configure appropriate TPM authorization policies (e.g.,
     password or policy session requirements on the AK).

     The net effect is that hardware attestation raises the bar for email
     abuse from "any script" to "kernel-level compromise of a specific
     physical machine," which is a substantial improvement over the status
     quo even if it is not a complete solution.

  11.4.  Physical Attacks on TPMs

     Extracting private keys from a TPM requires physical attacks such as
     electron microscopy, laser fault injection, or side-channel analysis.
     Modern TPMs include countermeasures against these attacks.  The cost
     and expertise required for successful key extraction is estimated at
     $50,000-$200,000 per chip, making it economically unviable for spam
     operations.






  Drake                    Expires 23 August 2026                [Page 19]


  Internet-Draft            TPM Email Attestation            February 2026


     Even if key extraction were feasible, the extracted key could only
     impersonate one hardware identity.  The attacker would still need to
     extract keys from additional TPMs to create additional identities.

  11.5.  Virtual TPM Risk

     As noted in Section 7.3, virtual TPMs do not provide the same Sybil
     resistance as physical TPMs because the hypervisor operator can
     create arbitrary numbers of vTPMs.  Receiving mail servers MUST be
     able to distinguish virtual from physical TPMs (via the manufacturer
     code in the EK certificate) and SHOULD apply appropriate policy
     differences.

  11.6.  Policy Abuse and Deanonymisation Risk

     Mode 1 (Direct TPM Attestation) creates a persistent, globally unique
     hardware fingerprint that is visible to every recipient.  While this
     is the intended mechanism for Sybil resistance and reputation
     building, it also creates risks if misused as a surveillance tool:

     *  Authoritarian regimes could correlate hardware fingerprints across
        messages to track individuals or organisations.

     *  Employers or platforms could mandate attestation to deanonymise
        senders who have legitimate reasons for pseudonymity.

     *  Receiving mail servers that log hardware fingerprints create long-
        lived tracking databases.

     These risks are mitigated by the availability of Mode 2 (SD-JWT Trust
     Proof), which provides Sybil resistance without revealing the
     hardware fingerprint.  Senders operating in contexts where hardware
     fingerprint disclosure is unacceptable SHOULD use Mode 2 exclusively.

     Receiving mail servers SHOULD NOT require Mode 1 attestation when
     Mode 2 provides sufficient trust signal for the receiver's policy
     needs.  The Applicability section (Section 3) notes that this
     specification is designed for automated senders, not human users,
     further limiting the deanonymisation risk in practice.

  11.7.  Header Stripping and Modification

     An intermediary mail server could strip or modify the TPM-Attestation
     or TPM-Trust-Proof headers.  This risk is identical to the risk of
     DKIM signature stripping and is mitigated by the same mechanisms: ARC
     [RFC8617] preserves authentication results through forwarding chains,
     and DMARC policy can specify handling for messages that lose
     authentication in transit.



  Drake                    Expires 23 August 2026                [Page 20]


  Internet-Draft            TPM Email Attestation            February 2026


     Stripping these headers cannot cause a legitimate message to appear
     illegitimate (it simply loses the attestation).  Adding forged
     headers is prevented by the cryptographic signatures.

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

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/info/rfc5652>.

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

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

     [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
                Message Authentication Status", RFC 8601,
                DOI 10.17487/RFC8601, May 2019,
                <https://www.rfc-editor.org/info/rfc8601>.

     [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
                Disclosure for JSON Web Tokens", RFC 9901,
                DOI 10.17487/RFC9901, November 2025,
                <https://www.rfc-editor.org/info/rfc9901>.

  13.  Informative References

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

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







  Drake                    Expires 23 August 2026                [Page 21]


  Internet-Draft            TPM Email Attestation            February 2026


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

     [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
                Authentication of Named Entities (DANE) Protocol: Updates
                and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
                October 2015, <https://www.rfc-editor.org/info/rfc7671>.

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

     [RFC8617]  Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
                Kucherawy, Ed., "The Authenticated Received Chain (ARC)
                Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
                <https://www.rfc-editor.org/info/rfc8617>.

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

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

     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
                DOI 10.17487/RFC9711, April 2025,
                <https://www.rfc-editor.org/info/rfc9711>.

     [TCG-TPM2] Trusted Computing Group, "TPM 2.0 Library Specification",
                TCG Revision 185, December 2024,
                <https://trustedcomputinggroup.org/resource/tpm-library-
                specification/>.

     [TCG-EK-PROFILE]
                Trusted Computing Group, "TCG EK Credential Profile for
                TPM Family 2.0", TCG Version 2.6, December 2024,
                <https://trustedcomputinggroup.org/resource/tcg-ek-
                credential-profile-for-tpm-family-2-0/>.






  Drake                    Expires 23 August 2026                [Page 22]


  Internet-Draft            TPM Email Attestation            February 2026


  Appendix A.  Appendix: Economics of Hardware-Based Sybil Resistance

     The following table compares the cost of creating N fake sender
     identities under various authentication regimes:

       +================+===================+============+=============+
       | Authentication | Cost per Identity | Cost of 1M | Reusable    |
       |                |                   | Identities | After Flag? |
       +================+===================+============+=============+
       | Email-only     | ~$0               | ~$0        | Yes (new    |
       |                |                   |            | address)    |
       +----------------+-------------------+------------+-------------+
       | Phone-verified | ~$0.01-0.10       | $10K-100K  | Yes (new    |
       |                |                   |            | SIM)        |
       +----------------+-------------------+------------+-------------+
       | Domain + DKIM  | ~$1-10            | $1M-10M    | Yes (new    |
       |                |                   |            | domain)     |
       +----------------+-------------------+------------+-------------+
       | TPM            | ~$500-2000        | $500M-2B   | No (chip is |
       | Attestation    |                   |            | permanent)  |
       +----------------+-------------------+------------+-------------+

                                    Table 1

     The critical difference is the "Reusable After Flag?" column.  With
     every existing mechanism, a flagged identity can be cheaply replaced.
     With TPM attestation, a flagged hardware identity is permanently
     associated with that physical chip.  The attacker must procure
     entirely new hardware.

  Appendix B.  Appendix: TPM Manufacturer Root CAs

     The following TPM manufacturers publish root CA certificates that can
     be used to validate EK certificate chains:

     Intel  Provides EK CA certificates via a REST API.  Root CA
        certificates available for download.  See
        https://trustedservices.intel.com/.

     AMD  AMD Security Processor key distribution.  Root certificates for
        fTPM EK validation.  See https://download.amd.com/sev/.

     Infineon  Infineon OPTIGA TPM certificates.  Root CA available via
        Infineon's PKI.  See https://www.infineon.com/TPM.

     STMicroelectronics  Root certificates available through ST's TPM
        documentation portal.




  Drake                    Expires 23 August 2026                [Page 23]


  Internet-Draft            TPM Email Attestation            February 2026


     Nuvoton  Root certificates available through Nuvoton's security
        products documentation.

     Receiving mail servers implementing this specification SHOULD
     maintain a local trust store of TPM manufacturer root CAs, updated
     periodically.  A community-maintained trust store (analogous to
     Mozilla's CA certificate programme for TLS) would benefit the
     ecosystem.  An open-source trust store project is available at
     https://github.com/1id-com/tpm-manufacturer-cas.

  Appendix C.  Appendix: Applicability to Other Transports

     The CMS attestation bundle (the "chain" value defined in Section 4.2)
     and the SD-JWT trust proof (defined in Section 5.2) are self-
     contained data structures whose verification algorithms (Section 4.3
     and Section 5.3) do not depend on email semantics.  The body hash
     (bh) generalises to a content hash over whatever payload the
     attestation covers.

     Potential transport bindings include but are not limited to:

     HTTP  The CMS attestation bundle or SD-JWT trust proof could be
        carried in HTTP request headers or in HTTP message bodies.  The
        content hash would cover the HTTP request or response payload.
        This binding is particularly relevant for API calls by autonomous
        AI agents, where the receiving service benefits from verifying
        that the request originated on attested hardware.

     Agent-to-Agent Protocols  Emerging protocols for AI agent
        communication - tool invocation, task delegation, capability
        discovery - could carry attestation evidence alongside each
        request, enabling agents to verify each other's hardware trust
        level before exchanging sensitive data or delegating privileged
        operations.

     WebSocket and Streaming Protocols  Attestation evidence could be
        presented during connection establishment (e.g., in the WebSocket
        upgrade request) to establish hardware trust for the duration of a
        persistent connection.

     Detailed specification of these bindings is out of scope for this
     document and is deferred to future companion documents.









  Drake                    Expires 23 August 2026                [Page 24]


  Internet-Draft            TPM Email Attestation            February 2026


  Appendix D.  Acknowledgements

     The concept of using hardware attestation for email sender
     verification was developed in the context of a hardware identity
     registrar for AI agents.  The authors thank the Trusted Computing
     Group for the TPM 2.0 specification, the authors of RFC 9901 (SD-JWT)
     for the selective disclosure mechanism, and the IETF RATS and SEAT
     working groups for establishing the remote attestation architecture
     that this document builds upon.

  Author's Address

     Christopher Drake
     1id.com
     Email: cnd@1id.com
     URI:   https://1id.com



































  Drake                    Expires 23 August 2026                [Page 25]


name: draft-wang-hjs-accountability
rev: 00
title: HJS: An Accountability Layer for AI Agents
time: 2026-02-21T08:31:59Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-25T08:31:59Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.682562+00:00
source: ietf
abstract:
  This document defines HJS (Human Judgment System), a standalone
  accountability layer for AI agents. HJS provides four primitives
  (Judgment/Delegation/Termination/Verification) for recording
  complete responsibility chains, and uses OTS (Open Timestamp) proofs
  anchored to the Bitcoin blockchain to create immutable, court-
  admissible evidence. While HJS can complement other protocols (e.g.,
  AIIP) by providing the evidence they require, it is designed to be
  independent and usable with any AI agent communication framework.

full_text:
  Internet-Draft                                          Y. Wang
  Intended status: Informational                          HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
  Expires: 21 August 2026                            21 February 2026


                       HJS: An Accountability Layer
                             for AI Agents

                       draft-wang-hjs-accountability-00

  Abstract
  This document defines HJS (Human Judgment System), a standalone
  accountability layer for AI agents. HJS provides four primitives
  (Judgment/Delegation/Termination/Verification) for recording
  complete responsibility chains, and uses OTS (Open Timestamp) proofs
  anchored to the Bitcoin blockchain to create immutable, court-
  admissible evidence. While HJS can complement other protocols (e.g.,
  AIIP) by providing the evidence they require, it is designed to be
  independent and usable with any AI agent communication framework.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 21 August 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.


  Wang                     Expires 21 August 2026                 [Page 1]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  Table of Contents

     1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3. The Four Primitives . . . . . . . . . . . . . . . . . . . . .   3
       3.1. Judgment . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2. Delegation . . . . . . . . . . . . . . . . . . . . . . .   4
       3.3. Termination . . . . . . . . . . . . . . . . . . . . . . .   4
       3.4. Verification . . . . . . . . . . . . . . . . . . . . . .   5
       3.5. Responsibility Chain . . . . . . . . . . . . . . . . . .   5
     4. OTS Evidence Chain . . . . . . . . . . . . . . . . . . . . . .   6
       4.1. OTS Proof Overview . . . . . . . . . . . . . . . . . . .   6
       4.2. Locking the Chain . . . . . . . . . . . . . . . . . . . .   6
     5. Evidence Format  . . . . . . . . . . . . . . . . . . . . . . .   7
       5.1. Complete Evidence Structure  . . . . . . . . . . . . . .   7
       5.2. Verification Process  . . . . . . . . . . . . . . . . . .   8
     6. Relationship with Other Protocols  . . . . . . . . . . . . . .   8
       6.1. Complementing AIIP . . . . . . . . . . . . . . . . . . .   8
       6.2. Independence . . . . . . . . . . . . . . . . . . . . . .   9
     7. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       7.1. Regulatory Compliance . . . . . . . . . . . . . . . . . .   9
       7.2. Dispute Resolution . . . . . . . . . . . . . . . . . . .  10
       7.3. Audit Trail . . . . . . . . . . . . . . . . . . . . . . .  10
     8. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     9. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     10. Normative References . . . . . . . . . . . . . . . . . . . .  11
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . .  12

  1. Introduction

     As AI agents become increasingly autonomous, the need for a
     comprehensive accountability layer becomes critical. Current
     protocols focus on how agents communicate and execute tasks, but
     they do not address the fundamental question: who is responsible
     for what, and how can it be proven?

     This document defines HJS (Human Judgment System), a standalone
     accountability layer for AI agents that provides:

     1. Four primitives (Judgment, Delegation, Termination, Verification)
        for recording complete responsibility chains. These capture not
        just what happened, but why it happened, who was involved, and
        how it was verified.


  Wang                     Expires 21 August 2026                 [Page 2]

  Internet-Draft          HJS Accountability Layer         21 February 2026

     2. OTS evidence chain that anchors cryptographic hashes of the
        primitives to the Bitcoin blockchain, creating immutable, court-
        admissible evidence.

     3. Complete evidence locking that binds all components together into
        a verifiable package.

     HJS is designed to be independent - it does not require any specific
     communication protocol and can be used with any AI agent framework.
     It can also complement existing protocols (such as AIIP
     [draft-sogomonian-aiip-architecture-03]) by providing the
     accountability layer they lack.

  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.

  3. The Four Primitives

     HJS defines four primitives that together form a complete
     responsibility chain for any AI agent action.

  3.1. Judgment

     The Judgment primitive records the basis on which an AI agent made
     its decision. This includes:

     o Input data (or cryptographic commitment to input)
     o Model identifier and version
     o Parameters and configuration
     o Reasoning path (optional)

     Example:

     {
       "judgment": {
         "input_commitment": "base64url(sha256(input))",
         "model_id": "gpt-4-2026-02",
         "parameters": { "temperature": 0.7, "max_tokens": 500 }
       }
     }


  Wang                     Expires 21 August 2026                 [Page 3]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  3.2. Delegation

     The Delegation primitive records the chain of responsibility from
     the original requester to the executing agent:

     o Delegator identifier
     o Agent identifier
     o Delegation time
     o Scope and constraints

     Example:

     {
       "delegation": {
         "from": "aiip://user.phone",
         "to": "aiip://agent.service",
         "time": 1734149100000,
         "scope": "make_call",
         "constraints": { "max_duration": 30000 }
       }
     }

  3.3. Termination

     The Termination primitive records the final outcome of the task:

     o Status (success/failure/abort)
     o Reason (if failure)
     o Output commitment
     o Duration

     Example:

     {
       "termination": {
         "status": "success",
         "output_commitment": "base64url(sha256(output))",
         "duration_ms": 2345
       }
     }


  Wang                     Expires 21 August 2026                 [Page 4]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  3.4. Verification

     The Verification primitive records how the result was verified:

     o Verifier identifier
     o Verification method
     o Verification time
     o Result

     Example:

     {
       "verification": {
         "verifier": "aiip://audit.service",
         "method": "ots_verify",
         "time": 1734149110000,
         "result": "valid"
       }
     }

  3.5. Responsibility Chain

     The four primitives, when combined, form a complete responsibility
     chain that answers:

     o Why was this done? (Judgment)
     o Who requested it? (Delegation)
     o What happened? (Termination)
     o How was it verified? (Verification)

     Implementations MUST include all four primitives to form a complete
     chain. Each primitive MAY be hashed individually to allow selective
     disclosure while maintaining chain integrity.

  4. OTS Evidence Chain

     While the four primitives provide structure for accountability,
     they must be made immutable and verifiable to serve as evidence.
     HJS uses OTS (Open Timestamp) proofs anchored to the Bitcoin
     blockchain for this purpose.

  4.1. OTS Proof Overview

     OTS proofs work as follows:

     1. Compute SHA-256 hash of the data to be proven
     2. Submit the hash to the Bitcoin network via Open Timestamp
     3. A Bitcoin transaction includes the hash, creating an immutable
        timestamp
     4. Generate an OTS proof file for verification


  Wang                     Expires 21 August 2026                 [Page 5]

  Internet-Draft          HJS Accountability Layer         21 February 2026

     Key properties:

     o Decentralized: No trusted third party required
     o Immutable: Once anchored, cannot be altered
     o Publicly verifiable: Anyone can verify with Bitcoin data
     o Court-admissible: Recognized in multiple jurisdictions

  4.2. Locking the Chain

     HJS does not simply prove individual primitives - it locks the
     entire responsibility chain together:

     1. Hash each primitive individually (allowing selective disclosure)
     2. Combine the four hashes into a chain hash
     3. Generate an OTS proof of the chain hash
     4. The OTS proof becomes the evidence lock that binds all components
        together

     This ensures that:

     o Any tampering with any primitive breaks the chain
     o Partial disclosure is possible without breaking trust
     o The entire chain has a single, verifiable timestamp

  5. Evidence Format

  5.1. Complete Evidence Structure

     The complete HJS evidence package includes:

     {
       "hjs": {
         "version": "1.0",
         "primitives": {
           "judgment": { ... },
           "delegation": { ... },
           "termination": { ... },
           "verification": { ... }
         },
         "hashes": {
           "judgment_hash": "base64url(sha256(judgment))",
           "delegation_hash": "base64url(sha256(delegation))",
           "termination_hash": "base64url(sha256(termination))",
           "verification_hash": "base64url(sha256(verification))",
           "chain_hash": "base64url(sha256(judgment_hash + delegation_hash + termination_hash + verification_hash))"
         },
         "evidence": {
           "ots_proof": "base64url(ots-proof-data)",
           "bitcoin_txid": "txid",
           "timestamp": 1734149123000
         }
       }
     }


  Wang                     Expires 21 August 2026                 [Page 6]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  5.2. Verification Process

     To verify an HJS evidence package:

     1. Verify the OTS proof using standard OTS tools
     2. Confirm the OTS proof matches the chain_hash
     3. Recompute each primitive's hash and verify against stored hashes
     4. Optionally, verify individual primitives without accessing others
     5. Check that the chain_hash matches recomputed combination

     This process can be performed by anyone with access to Bitcoin
     blockchain data, without requiring access to the original AI system.

  6. Relationship with Other Protocols

  6.1. Complementing AIIP

     The AIIP architecture [draft-sogomonian-aiip-architecture-03]
     defines execution receipts and requires attestation evidence.
     HJS naturally complements AIIP by providing exactly what AIIP
     requires but does not specify:

     | AIIP Requirement          | HJS Solution                          |
     |---------------------------|---------------------------------------|
     | Attestation evidence      | OTS proofs anchored to Bitcoin        |
     | Execution receipt         | Can be extended with HJS primitives   |
     | Auditability              | Complete responsibility chain         |
     | External anchoring        | Bitcoin blockchain                    |

     However, HJS is not a subset or extension of AIIP. It is a complete,
     standalone accountability layer that can:

     o Be used with AIIP by embedding HJS evidence in AIIP receipts
     o Be used with any other communication protocol
     o Be used entirely independently for logging and audit purposes

  6.2. Independence

     HJS makes no assumptions about:

     o How agents communicate (HTTP, AIIP, custom protocols)
     o What AI models are used
     o Where execution happens (cloud, edge, TEE)
     o Which jurisdiction applies

     It provides a jurisdiction-agnostic, protocol-independent
     accountability layer that can be added to any AI system.


  Wang                     Expires 21 August 2026                 [Page 7]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  7. Use Cases

  7.1. Regulatory Compliance

     Organizations subject to regulations (finance, healthcare, EU AI Act)
     can use HJS to demonstrate compliance by maintaining verifiable
     records of AI agent decisions, including:

     o What data was used (Judgment)
     o Who authorized the action (Delegation)
     o What happened (Termination)
     o How it was verified (Verification)
     o Immutable proof of all of the above (OTS evidence)

  7.2. Dispute Resolution

     When disputes arise about AI agent actions, HJS provides:

     o Cryptographic proof of what happened
     o Court-admissible evidence recognized in multiple jurisdictions
     o Ability to verify without accessing the original AI system

  7.3. Audit Trail

     HJS creates a complete, immutable audit trail for AI agent
     operations, enabling:

     o Internal audits
     o Third-party audits
     o Regulatory examinations
     o Forensic analysis

  8. Security Considerations

     The security of HJS evidence depends on:

     o Bitcoin blockchain: As of this writing, Bitcoin has never been
       successfully reorganized to alter confirmed transactions,
       providing strong assurance of immutability.

     o Hash functions: Implementations MUST use SHA-256 or stronger hash
       functions.

     o Key management: If signing is used (e.g., for verifier identity),
       implementations MUST follow best practices for key security.

     o Selective disclosure: The ability to verify individual primitive
       hashes without revealing their content enables privacy-preserving
       audits.


  Wang                     Expires 21 August 2026                 [Page 8]

  Internet-Draft          HJS Accountability Layer         21 February 2026

  9. IANA Considerations

     This document has no IANA actions.

  10. Normative References

     [draft-sogomonian-aiip-architecture-03]
                Sogomonian, A., "Artificial Intelligence Internet
                Protocol (AIIP) Architecture", Work in Progress,
                draft-sogomonian-aiip-architecture-03, December 2025.

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

     [opentimestamp]
                Open Timestamp Protocol, "Open Timestamp Protocol
                Specification", <https://opentimestamps.org/>, 2016.

     [hjs-github]
                Wang, Y., "HJS Protocol Implementation", MIT License,
                <https://github.com/schchit/hjs-api>.

  Author's Address

     Yuqiang Wang
     HUMAN JUDGMENT SYSTEMS FOUNDATION LTD.
     Email: signal@humanjudgment.org
     GitHub: https://github.com/schchit


name: draft-ravikiran-clawdentity-protocol
rev: 00
title: Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent Communication
time: 2026-02-21T14:47:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-25T14:47:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.686765+00:00
source: ietf
abstract:
  This document specifies the Clawdentity protocol, a cryptographic
     identity and trust layer for AI agent-to-agent communication.
     Clawdentity provides per-agent Ed25519 identity, registry-issued
     credentials (Agent Identity Tokens), proof-of-possession request
     signing, bilateral trust establishment via pairing ceremonies,
     authenticated relay transport over WebSocket, and certificate
     revocation.  The protocol enables AI agents to prove their identity,
     verify peers, and exchange messages without exposing private keys,
     shared tokens, or backend infrastructure.

full_text:
  Independent Submission                                      R. K. Vemula
  Internet-Draft                                                       CAW
  Intended status: Informational                          21 February 2026
  Expires: 25 August 2026


    Clawdentity: Cryptographic Identity and Trust Protocol for AI Agent
                               Communication
                  draft-ravikiran-clawdentity-protocol-00

  Abstract

     This document specifies the Clawdentity protocol, a cryptographic
     identity and trust layer for AI agent-to-agent communication.
     Clawdentity provides per-agent Ed25519 identity, registry-issued
     credentials (Agent Identity Tokens), proof-of-possession request
     signing, bilateral trust establishment via pairing ceremonies,
     authenticated relay transport over WebSocket, and certificate
     revocation.  The protocol enables AI agents to prove their identity,
     verify peers, and exchange messages without exposing private keys,
     shared tokens, or backend infrastructure.

  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 25 August 2026.

  Copyright Notice

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








  Vemula                   Expires 25 August 2026                 [Page 1]


  Internet-Draft                 Clawdentity                 February 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Architecture Overview . . . . . . . . . . . . . . . . . .   4
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
     3.  Identity Model  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  DID Format  . . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  Cryptographic Primitives  . . . . . . . . . . . . . . . .   6
       3.3.  Key Generation  . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Ownership Model . . . . . . . . . . . . . . . . . . . . .   7
     4.  Agent Identity Token (AIT)  . . . . . . . . . . . . . . . . .   7
       4.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.  JOSE Header . . . . . . . . . . . . . . . . . . . . . . .   8
       4.3.  Claims  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.4.  Confirmation Claim  . . . . . . . . . . . . . . . . . . .   9
       4.5.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  10
     5.  HTTP Request Signing  . . . . . . . . . . . . . . . . . . . .  10
       5.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .  11
       5.2.  Canonical Request Format  . . . . . . . . . . . . . . . .  11
       5.3.  Signature Computation . . . . . . . . . . . . . . . . . .  11
       5.4.  Request Headers . . . . . . . . . . . . . . . . . . . . .  11
       5.5.  Verification Procedure  . . . . . . . . . . . . . . . . .  12
     6.  The "Claw" Authentication Scheme  . . . . . . . . . . . . . .  13
     7.  Agent Registration  . . . . . . . . . . . . . . . . . . . . .  13
       7.1.  Registration Flow . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Registration Proof  . . . . . . . . . . . . . . . . . . .  14
       7.3.  AIT Refresh . . . . . . . . . . . . . . . . . . . . . . .  14
     8.  Trust Establishment (Pairing) . . . . . . . . . . . . . . . .  14
       8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  14
       8.2.  Pairing Flow  . . . . . . . . . . . . . . . . . . . . . .  14
       8.3.  Pairing Ticket  . . . . . . . . . . . . . . . . . . . . .  15
       8.4.  Peer Profile  . . . . . . . . . . . . . . . . . . . . . .  15
       8.5.  Ownership Verification  . . . . . . . . . . . . . . . . .  16
       8.6.  Trust Store . . . . . . . . . . . . . . . . . . . . . . .  16
     9.  Relay Transport . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.2.  WebSocket Connection  . . . . . . . . . . . . . . . . . .  17
       9.3.  Frame Protocol  . . . . . . . . . . . . . . . . . . . . .  17
       9.4.  Heartbeat Frames  . . . . . . . . . . . . . . . . . . . .  17
       9.5.  Deliver Frames  . . . . . . . . . . . . . . . . . . . . .  18



  Vemula                   Expires 25 August 2026                 [Page 2]


  Internet-Draft                 Clawdentity                 February 2026


       9.6.  Enqueue Frames  . . . . . . . . . . . . . . . . . . . . .  18
       9.7.  Local Agent Delivery  . . . . . . . . . . . . . . . . . .  19
       9.8.  Reconnection  . . . . . . . . . . . . . . . . . . . . . .  20
       9.9.  Outbound Queue Persistence  . . . . . . . . . . . . . . .  20
     10. Certificate Revocation  . . . . . . . . . . . . . . . . . . .  20
       10.1.  CRL Format . . . . . . . . . . . . . . . . . . . . . . .  20
       10.2.  CRL Distribution . . . . . . . . . . . . . . . . . . . .  21
       10.3.  CRL Caching  . . . . . . . . . . . . . . . . . . . . . .  22
       10.4.  Revocation Scope . . . . . . . . . . . . . . . . . . . .  22
     11. Registry Key Discovery  . . . . . . . . . . . . . . . . . . .  22
     12. Endpoint Reference  . . . . . . . . . . . . . . . . . . . . .  23
       12.1.  Registry Endpoints . . . . . . . . . . . . . . . . . . .  23
       12.2.  Proxy Endpoints  . . . . . . . . . . . . . . . . . . . .  24
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  24
       13.1.  Private Key Protection . . . . . . . . . . . . . . . . .  24
       13.2.  Replay Protection  . . . . . . . . . . . . . . . . . . .  24
       13.3.  Transport Security . . . . . . . . . . . . . . . . . . .  25
       13.4.  Connector Isolation  . . . . . . . . . . . . . . . . . .  25
       13.5.  Trust Store Integrity  . . . . . . . . . . . . . . . . .  25
       13.6.  CRL Freshness Window . . . . . . . . . . . . . . . . . .  25
       13.7.  Human-Anchored Trust . . . . . . . . . . . . . . . . . .  26
     14. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .  26
       14.1.  Authentication Errors (401)  . . . . . . . . . . . . . .  26
       14.2.  Authorization Errors (403) . . . . . . . . . . . . . . .  27
       14.3.  Service Unavailable Errors (503) . . . . . . . . . . . .  27
     15. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
       15.1.  DID Method Registration  . . . . . . . . . . . . . . . .  27
       15.2.  HTTP Authentication Scheme Registration  . . . . . . . .  28
       15.3.  JWT "typ" Header Parameter Values  . . . . . . . . . . .  28
     16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28
       16.1.  Normative References . . . . . . . . . . . . . . . . . .  28
       16.2.  Informative References . . . . . . . . . . . . . . . . .  29
     Appendix A.  Example: Complete Message Flow . . . . . . . . . . .  30
     Appendix B.  Comparison with Existing Standards . . . . . . . . .  31
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  31
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31

  1.  Introduction

  1.1.  Problem Statement

     Current AI agent frameworks rely on shared bearer tokens for inter-
     agent communication.  A single token leak compromises all agents in
     the system.  There is no mechanism to distinguish which agent sent a
     request, revoke a single agent without rotating the shared token,
     enforce per-agent access control, or keep backend services private.
     These limitations become critical as multi-agent systems scale.




  Vemula                   Expires 25 August 2026                 [Page 3]


  Internet-Draft                 Clawdentity                 February 2026


  1.2.  Design Goals

     Clawdentity addresses these problems with six design goals:

     1.  *Individual identity:* Each agent has a unique cryptographic
         keypair and DID.

     2.  *Proof of possession:* Every request proves the sender holds the
         private key via Ed25519 signatures.

     3.  *Selective revocation:* One agent can be revoked without
         affecting others.

     4.  *Zero-trust relay:* Agents communicate through authenticated
         proxies; backend services remain unexposed.

     5.  *Human-anchored trust:* Trust originates from human approval, not
         agent self-certification.

     6.  *Framework agnostic:* Works with any AI agent framework.

  1.3.  Architecture Overview

     The protocol defines four component roles:

     Registry  Central identity authority.  Issues Agent Identity Tokens
        (AITs), manages signing keys, publishes the Certificate Revocation
        List (CRL).

     Proxy  Per-owner edge service.  Verifies identity, enforces trust
        policy, rate-limits requests, and relays messages between agents.

     Connector  Local bridge process between the proxy and the agent
        framework.  Maintains a persistent WebSocket connection to the
        proxy.  Never exposed publicly.

     Agent  The AI agent itself.  Has no direct knowledge of the protocol;
        the connector handles all cryptographic operations.













  Vemula                   Expires 25 August 2026                 [Page 4]


  Internet-Draft                 Clawdentity                 February 2026


       +-------------+         +-------------+         +--------------+
       |   Agent A   |         |  Registry   |         |   Agent B    |
       |  (private)  |         |  (central)  |         |  (private)   |
       +------+------+         +------+------+         +------+-------+
              |                       |                       |
       +------+------+                |                +------+-------+
       | Connector A |                |                | Connector B  |
       |  (local)    |                |                |  (local)     |
       +------+------+                |                +------+-------+
              |  WebSocket            |                       | WebSocket
       +------+------+                |                +------+-------+
       |   Proxy A   |<---------------+--------------->|   Proxy B    |
       |  (edge)     |                |                |  (edge)      |
       +-------------+                |                +--------------+
                                      |
                         +------------+------------+
                         | .well-known/claw-keys   |
                         | /v1/crl                 |
                         | /v1/agents              |
                         +-------------------------+

                        Figure 1: Component Architecture

  2.  Conventions and Terminology

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

     This document uses the following terms:

     AIT  Agent Identity Token.  A signed JWT credential (Section 4)
        binding an agent DID to a public key.

     CRL  Certificate Revocation List.  A signed JWT (Section 10)
        containing a list of revoked AITs.

     DID  Decentralized Identifier as defined in [W3C.DID], using the
        "cdi" method.

     PoP  Proof of Possession.  An Ed25519 signature proving the sender
        controls the private key corresponding to a public key.

     Pairing  Mutual trust establishment between two agents via a ticket-
        based ceremony.




  Vemula                   Expires 25 August 2026                 [Page 5]


  Internet-Draft                 Clawdentity                 February 2026


     Trust Store  Per-proxy persistent storage of known agents and
        approved trust pairs.

     ULID  Universally Unique Lexicographically Sortable Identifier
        [ULID].

  3.  Identity Model

  3.1.  DID Format

     Clawdentity uses a custom DID method with the scheme "did:cdi"
     (Clawdentity Identity).  The method-specific identifier consists of a
     registry host and a ULID, separated by a colon:

     cdi-did         = "did:cdi:" registry-host ":" ulid
     registry-host   = 1*( unreserved / "." / "-" )
     ulid            = 26ALPHA  ; Crockford Base32, see [ULID]

     The registry-host identifies which registry issued the DID.  The
     entity type (agent or human) is resolved by the registry, not encoded
     in the DID.

     +======+===========================================================+
     |Entity|Example                                                    |
     +======+===========================================================+
     |Agent |did:cdi:registry.clawdentity.com:01HG8ZBU11X7X8DN8O4X6GEYU5|
     +------+-----------------------------------------------------------+
     |Human |did:cdi:registry.clawdentity.com:01HF7YAT00W6W7CM7N3W5FDXT4|
     +------+-----------------------------------------------------------+
     |Self- |did:cdi:id.acme.corp:01HK9ABC22Y8Y9EO9P5Y7HFZV6            |
     |hosted|                                                           |
     +------+-----------------------------------------------------------+

                                   Table 1

     Implementations MUST reject DIDs where the registry-host is empty or
     where the ULID component does not conform to the ULID specification
     [ULID].

  3.2.  Cryptographic Primitives

     The protocol uses Ed25519 [RFC8032] as the sole signing algorithm.
     Implementations MUST NOT support other signature algorithms.








  Vemula                   Expires 25 August 2026                 [Page 6]


  Internet-Draft                 Clawdentity                 February 2026


        +================+===========+===========+===================+
        | Primitive      | Algorithm | Reference | Usage             |
        +================+===========+===========+===================+
        | Signing        | Ed25519   | [RFC8032] | Identity, request |
        |                |           |           | signing           |
        +----------------+-----------+-----------+-------------------+
        | Body hash      | SHA-256   | [RFC6234] | Request body      |
        |                |           |           | integrity         |
        +----------------+-----------+-----------+-------------------+
        | Token format   | JWS       | [RFC7515] | AIT and CRL       |
        |                | Compact   |           | tokens            |
        +----------------+-----------+-----------+-------------------+
        | Key encoding   | Base64url | [RFC4648] | Keys, signatures, |
        |                | (no pad)  | Section 5 | hashes            |
        +----------------+-----------+-----------+-------------------+
        | Key            | JWK (OKP/ | [RFC8037] | Public keys in    |
        | representation | Ed25519)  |           | AITs              |
        +----------------+-----------+-----------+-------------------+

                                   Table 2

  3.3.  Key Generation

     Each agent locally generates an Ed25519 keypair consisting of a
     32-byte public key and a 64-byte secret key.  The secret key MUST be
     stored exclusively on the agent's local machine and MUST NOT be
     transmitted over any network.  Only the public key is registered with
     the registry, encoded as base64url within the AIT's confirmation
     claim (Section 4.4).

  3.4.  Ownership Model

     Every agent DID is bound to exactly one human DID (the "ownerDid").
     This binding is recorded in the AIT claims and enforced by the
     registry during registration and refresh operations.  A human MAY own
     multiple agents.  An agent MUST have exactly one owner.

       Human (did:cdi:registry.clawdentity.com:01HF7...)
         +-- Agent A (did:cdi:registry.clawdentity.com:01HG8...)
         +-- Agent B (did:cdi:registry.clawdentity.com:01HG9...)
         +-- Agent C (did:cdi:registry.clawdentity.com:01HGA...)

  4.  Agent Identity Token (AIT)








  Vemula                   Expires 25 August 2026                 [Page 7]


  Internet-Draft                 Clawdentity                 February 2026


  4.1.  Overview

     The Agent Identity Token (AIT) is a JSON Web Token [RFC7519] that
     serves as an agent's credential.  It is issued by the registry,
     signed with a registry Ed25519 key, and binds the agent's DID to the
     agent's public key via a confirmation claim ("cnf"), following the
     pattern established by DPoP [RFC9449].

  4.2.  JOSE Header

     The AIT's JOSE protected header MUST contain:

     alg  REQUIRED.  MUST be "EdDSA" per [RFC8037].

     typ  REQUIRED.  MUST be "AIT".

     kid  REQUIRED.  The key identifier of the registry signing key used
        to sign this AIT.  This allows the verifier to locate the correct
        registry public key.

     {
       "alg": "EdDSA",
       "typ": "AIT",
       "kid": "reg-key-2026-01"
     }

                       Figure 2: AIT JOSE Header Example

  4.3.  Claims

     The AIT payload MUST contain the following claims.  No additional
     claims are permitted (strict validation).



















  Vemula                   Expires 25 August 2026                 [Page 8]


  Internet-Draft                 Clawdentity                 February 2026


     +===========+======+========+======================================+
     |Claim      |Type  |Required| Description                          |
     +===========+======+========+======================================+
     |iss        |string|REQUIRED| Registry issuer URL (e.g.,           |
     |           |      |        | "https://registry.clawdentity.com")  |
     +-----------+------+--------+--------------------------------------+
     |sub        |string|REQUIRED| Agent DID.  MUST be                  |
     |           |      |        | "did:cdi:<registry-host>:<ulid>"     |
     +-----------+------+--------+--------------------------------------+
     |ownerDid   |string|REQUIRED| Owner DID.  MUST be                  |
     |           |      |        | "did:cdi:<registry-host>:<ulid>"     |
     +-----------+------+--------+--------------------------------------+
     |name       |string|REQUIRED| Agent name. 1-64 characters matching |
     |           |      |        | [A-Za-z0-9._ -]                      |
     +-----------+------+--------+--------------------------------------+
     |framework  |string|REQUIRED| Agent framework identifier. 1-32     |
     |           |      |        | characters, no control characters.   |
     +-----------+------+--------+--------------------------------------+
     |description|string|OPTIONAL| Human-readable description.  Maximum |
     |           |      |        | 280 characters.                      |
     +-----------+------+--------+--------------------------------------+
     |cnf        |object|REQUIRED| Confirmation claim.  See             |
     |           |      |        | Section 4.4.                         |
     +-----------+------+--------+--------------------------------------+
     |iat        |number|REQUIRED| Issued-at time (NumericDate per      |
     |           |      |        | [RFC7519]).                          |
     +-----------+------+--------+--------------------------------------+
     |nbf        |number|REQUIRED| Not-before time (NumericDate).       |
     +-----------+------+--------+--------------------------------------+
     |exp        |number|REQUIRED| Expiration time (NumericDate).  MUST |
     |           |      |        | be greater than both nbf and iat.    |
     +-----------+------+--------+--------------------------------------+
     |jti        |string|REQUIRED| Unique token identifier.  MUST be a  |
     |           |      |        | valid ULID.                          |
     +-----------+------+--------+--------------------------------------+

                                   Table 3

  4.4.  Confirmation Claim

     The "cnf" (confirmation) claim binds the AIT to the agent's Ed25519
     public key, following the confirmation method pattern described in
     [RFC7800].  It contains a single "jwk" member:








  Vemula                   Expires 25 August 2026                 [Page 9]


  Internet-Draft                 Clawdentity                 February 2026


     "cnf": {
       "jwk": {
         "kty": "OKP",
         "crv": "Ed25519",
         "x": "<base64url-encoded-32-byte-public-key>"
       }
     }

     The "kty" MUST be "OKP".  The "crv" MUST be "Ed25519".  The "x"
     parameter MUST decode (base64url) to exactly 32 bytes.  The JWK MUST
     NOT contain a "d" (private key) parameter.

  4.5.  Validation Rules

     An AIT MUST be rejected if any of the following conditions are true:

     1.   "alg" is not "EdDSA".

     2.   "typ" is not "AIT".

     3.   "kid" does not match any active registry signing key.

     4.   JWS signature verification fails against the registry key
          identified by "kid".

     5.   "sub" is not a valid "did:cdi" DID.

     6.   "ownerDid" is not a valid "did:cdi" DID.

     7.   "cnf.jwk.x" does not decode to exactly 32 bytes.

     8.   "exp" is less than or equal to "nbf" or "iat".

     9.   "jti" is not a valid ULID.

     10.  Current time is before "nbf" or after "exp" (accounting for
          clock skew).

     11.  "jti" appears in the current CRL (Section 10).

  5.  HTTP Request Signing










  Vemula                   Expires 25 August 2026                [Page 10]


  Internet-Draft                 Clawdentity                 February 2026


  5.1.  Purpose

     Every authenticated request includes a Proof of Possession (PoP)
     signature that proves the sender controls the private key
     corresponding to the public key in their AIT's "cnf" claim.  This
     mechanism is inspired by DPoP [RFC9449] but uses a canonical request
     signing approach optimized for agent-to-agent communication.

  5.2.  Canonical Request Format

     The canonical request string is constructed by joining the following
     fields with newline (0x0A) separators, in the order shown:

     canonical-request = version LF method LF path-with-query LF
                         timestamp LF nonce LF body-hash
     version           = "CLAW-PROOF-V1"
     method            = token          ; HTTP method, uppercased
     path-with-query   = absolute-path [ "?" query ]
     timestamp         = 1*DIGIT        ; Unix epoch seconds
     nonce             = 1*unreserved   ; unique per-request value
     body-hash         = base64url      ; SHA-256 of request body
     LF                = %x0A

     CLAW-PROOF-V1
     POST
     /hooks/agent
     1708531200
     01HG8ZBU11X7X8DN8O4X6GEYU5
     47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU

                      Figure 3: Canonical Request Example

  5.3.  Signature Computation

     The PoP signature is computed by signing the UTF-8 encoding of the
     canonical request string with the agent's Ed25519 private key:

     canonical = canonicalize(method, path, timestamp, nonce, body_hash)
     signature = Ed25519_Sign(UTF8_Encode(canonical), secret_key)
     proof     = Base64url_Encode(signature)

     The resulting "proof" is a base64url-encoded 64-byte Ed25519
     signature.

  5.4.  Request Headers

     An authenticated request MUST include the following headers:




  Vemula                   Expires 25 August 2026                [Page 11]


  Internet-Draft                 Clawdentity                 February 2026


      +=====================+=============+=============================+
      | Header              | Status      | Description                 |
      +=====================+=============+=============================+
      | Authorization       | REQUIRED    | "Claw" SP <AIT-JWT>.  See   |
      |                     |             | Section 6.                  |
      +---------------------+-------------+-----------------------------+
      | X-Claw-Timestamp    | REQUIRED    | Unix epoch seconds (integer |
      |                     |             | string).                    |
      +---------------------+-------------+-----------------------------+
      | X-Claw-Nonce        | REQUIRED    | Unique per-request value.   |
      |                     |             | ULID RECOMMENDED.           |
      +---------------------+-------------+-----------------------------+
      | X-Claw-Body-SHA256  | REQUIRED    | SHA-256 hash of the request |
      |                     |             | body, base64url-encoded.    |
      +---------------------+-------------+-----------------------------+
      | X-Claw-Proof        | REQUIRED    | Ed25519 PoP signature       |
      |                     |             | (base64url, 64 bytes).      |
      +---------------------+-------------+-----------------------------+
      | X-Claw-Agent-Access | CONDITIONAL | Session access token.       |
      |                     |             | Required for relay and hook |
      |                     |             | routes.                     |
      +---------------------+-------------+-----------------------------+

                                    Table 4

  5.5.  Verification Procedure

     The verifier (proxy) MUST perform the following steps in order:

     1.  Extract the AIT from the "Authorization: Claw <token>" header.

     2.  Verify the AIT's JWS signature against the registry's signing
         keys (Section 4.5).

     3.  Check that the AIT's "jti" is not on the CRL (Section 10.3).

     4.  Extract the agent's public key from the AIT's "cnf.jwk.x" claim.

     5.  Verify X-Claw-Timestamp is within the allowed skew window
         (default: 300 seconds).

     6.  Recompute SHA-256 of the request body; compare with X-Claw-Body-
         SHA256.

     7.  Reconstruct the canonical request (Section 5.2).

     8.  Verify X-Claw-Proof against the canonical request using the
         agent's public key.



  Vemula                   Expires 25 August 2026                [Page 12]


  Internet-Draft                 Clawdentity                 February 2026


     9.  Check X-Claw-Nonce has not been seen before for this agent DID
         within the timestamp window.

     If any step fails, the request MUST be rejected with HTTP 401.

  6.  The "Claw" Authentication Scheme

     This specification introduces the "Claw" HTTP authentication scheme
     for the Authorization header, following the framework defined in
     [RFC9110] Section 11.

  credentials = "Claw" SP ait-token
  ait-token   = 1*base64url-char "." 1*base64url-char "." 1*base64url-char

     The scheme name "Claw" is case-sensitive.  The token MUST be a valid
     JWS Compact Serialization [RFC7515] representing an AIT as defined in
     Section 4.

  7.  Agent Registration

  7.1.  Registration Flow

     Agent registration uses a challenge-response protocol to prove that
     the registrant possesses the Ed25519 private key corresponding to the
     public key being registered.

       Agent                                Registry
         |                                      |
         |  POST /v1/agents/challenge           |
         |  { ownerDid }                        |
         |------------------------------------->|
         |                                      |
         |  200 { challengeId, nonce }          |
         |<-------------------------------------|
         |                                      |
         |  [Agent signs registration proof]    |
         |                                      |
         |  POST /v1/agents                     |
         |  { proof, publicKey, name, ... }     |
         |------------------------------------->|
         |                                      |
         |  201 { agentDid, ait }               |
         |<-------------------------------------|

                     Figure 4: Agent Registration Sequence






  Vemula                   Expires 25 August 2026                [Page 13]


  Internet-Draft                 Clawdentity                 February 2026


  7.2.  Registration Proof

     The registration proof is computed by signing a canonical message
     that binds the challenge to the agent's identity parameters:

     clawdentity.register.v1
     challengeId:<challengeId>
     nonce:<nonce>
     ownerDid:<ownerDid>
     publicKey:<base64url-public-key>
     name:<agent-name>
     framework:<framework>
     ttlDays:<ttl-days>

     Optional fields (framework, ttlDays) use empty strings when absent.
     The agent signs this message with Ed25519 and submits the base64url-
     encoded signature as the "proof" in the registration request.

  7.3.  AIT Refresh

     AITs have bounded lifetimes.  Before expiration, the connector MUST
     request a fresh AIT:

     POST /v1/agents/auth/refresh HTTP/1.1
     Authorization: Claw <current-AIT>
     X-Claw-Agent-Access: <access-token>

     The registry validates the current AIT and access token, verifies the
     agent is not revoked, and returns a new AIT with an updated
     expiration time.

  8.  Trust Establishment (Pairing)

  8.1.  Overview

     Before two agents can exchange messages, they MUST establish mutual
     trust through a pairing ceremony.  Trust is anchored by human
     approval: agents cannot self-approve trust relationships.  The
     pairing process uses short-lived tickets exchanged out-of-band (e.g.,
     via QR code or messaging).

  8.2.  Pairing Flow









  Vemula                   Expires 25 August 2026                [Page 14]


  Internet-Draft                 Clawdentity                 February 2026


       Agent A (Initiator)        Proxy         Agent B (Responder)
              |                     |                    |
              | POST /pair/start    |                    |
              | { initiatorProfile, |                    |
              |   ttlSeconds }      |                    |
              |-------------------->|                    |
              |                     |                    |
              | { ticket,           |                    |
              |   expiresAt }       |                    |
              |<--------------------|                    |
              |                     |                    |
              |   (out-of-band ticket exchange)          |
              |   (QR code, message, copy-paste)         |
              |----------------------------------------->|
              |                     |                    |
              |                     | POST /pair/confirm |
              |                     | { ticket,          |
              |                     |   responderProfile}|
              |                     |<-------------------|
              |                     |                    |
              |                     | 201 { paired:true }|
              |                     |------------------->|
              |                     |                    |
              | callback (optional) |                    |
              |<--------------------|                    |

                     Figure 5: Trust Establishment Sequence

  8.3.  Pairing Ticket

     The pairing ticket is a signed JWT with a short TTL, created by the
     proxy during the /pair/start request.  The ticket encodes the issuer
     proxy URL, a signing key identifier, and an expiration timestamp.

     Ticket parameters:

               +==================+=============+=============+
               | Parameter        | Default     | Maximum     |
               +==================+=============+=============+
               | TTL (ttlSeconds) | 300 seconds | 900 seconds |
               +------------------+-------------+-------------+

                                   Table 5

  8.4.  Peer Profile

     Each side of a pairing provides a profile containing identity
     information for display and routing:



  Vemula                   Expires 25 August 2026                [Page 15]


  Internet-Draft                 Clawdentity                 February 2026


     {
       "agentName": "kai",
       "humanName": "Ravi",
       "proxyOrigin": "https://proxy.example.com"
     }

     agentName  REQUIRED.  Agent display name.  Maximum 64 characters.  No
        control characters.

     humanName  REQUIRED.  Owner display name.  Maximum 64 characters.  No
        control characters.

     proxyOrigin  OPTIONAL.  The proxy's URL origin, used for cross-proxy
        message routing.

  8.5.  Ownership Verification

     When an agent initiates pairing, the proxy MUST verify that the
     authenticated caller (identified by "ownerDid" in the AIT) actually
     owns the claimed initiator agent DID.  This is done by querying the
     registry's internal agent-ownership endpoint.  If ownership cannot be
     verified, the pairing MUST be rejected with HTTP 403.

  8.6.  Trust Store

     Each proxy maintains a Trust Store that records:

     *  *Known agents:* Agents that have been authenticated and accepted.

     *  *Approved pairs:* Bidirectional trust relationships between
        agents.

     *  *Pairing tickets:* Pending and completed pairing ceremonies with
        expiration tracking.

     A message from Agent A to Agent B is permitted only if the ordered
     pair (A, B) exists in the proxy's trust store.  The trust store
     SHOULD use a durable, transactional storage backend.

  9.  Relay Transport

  9.1.  Overview

     Messages between agents are relayed through their respective proxies.
     The connector maintains a persistent WebSocket [RFC6455] connection
     to its proxy.  The proxy authenticates the WebSocket upgrade request
     using the full AIT + PoP verification procedure (Section 5.5).




  Vemula                   Expires 25 August 2026                [Page 16]


  Internet-Draft                 Clawdentity                 February 2026


  9.2.  WebSocket Connection

     The connector initiates a WebSocket connection to:

     GET /v1/relay/connect HTTP/1.1
     Upgrade: websocket
     Connection: Upgrade
     Authorization: Claw <AIT>
     X-Claw-Agent-Access: <access-token>
     X-Claw-Timestamp: <timestamp>
     X-Claw-Nonce: <nonce>
     X-Claw-Body-SHA256: <empty-body-hash>
     X-Claw-Proof: <signature>

  9.3.  Frame Protocol

     All WebSocket messages are JSON objects conforming to the Clawdentity
     Frame Protocol version 1.  Every frame contains a common base
     structure:

     {
       "v": 1,
       "type": "<frame-type>",
       "id": "<ULID>",
       "ts": "<ISO-8601-timestamp>"
     }

     v  REQUIRED.  Integer.  Frame protocol version.  MUST be 1.

     type  REQUIRED.  String.  One of: "heartbeat", "heartbeat_ack",
        "deliver", "deliver_ack", "enqueue", "enqueue_ack".

     id  REQUIRED.  String.  Unique frame identifier (ULID).

     ts  REQUIRED.  String.  ISO 8601 timestamp with timezone.

  9.4.  Heartbeat Frames

     Either side MAY send heartbeat frames to verify liveness.  The
     default heartbeat interval is 30 seconds.  If a heartbeat
     acknowledgement is not received within 60 seconds, the sender SHOULD
     close the connection and reconnect.

     Heartbeat:

     { "v": 1, "type": "heartbeat", "id": "<ULID>", "ts": "<ISO>" }

     Heartbeat acknowledgement:



  Vemula                   Expires 25 August 2026                [Page 17]


  Internet-Draft                 Clawdentity                 February 2026


     { "v": 1, "type": "heartbeat_ack", "id": "<ULID>", "ts": "<ISO>",
       "ackId": "<heartbeat-frame-id>" }

  9.5.  Deliver Frames

     The proxy sends a "deliver" frame to the connector when an inbound
     message arrives for the local agent:

     {
       "v": 1,
       "type": "deliver",
       "id": "<ULID>",
       "ts": "<ISO>",
       "fromAgentDid": "did:cdi:registry.clawdentity.com:...",
       "toAgentDid": "did:cdi:registry.clawdentity.com:...",
       "payload": { ... },
       "contentType": "application/json",
       "conversationId": "conv-123",
       "replyTo": "https://proxy-a.example.com/v1/relay/delivery-receipts"
     }

     The connector MUST respond with a "deliver_ack" frame indicating
     whether the local agent framework accepted the delivery:

     {
       "v": 1,
       "type": "deliver_ack",
       "id": "<ULID>",
       "ts": "<ISO>",
       "ackId": "<deliver-frame-id>",
       "accepted": true
     }

     If rejected, the "accepted" field is false and an optional "reason"
     string MAY be included.

  9.6.  Enqueue Frames

     The connector sends an "enqueue" frame to the proxy for outbound
     messages:











  Vemula                   Expires 25 August 2026                [Page 18]


  Internet-Draft                 Clawdentity                 February 2026


     {
       "v": 1,
       "type": "enqueue",
       "id": "<ULID>",
       "ts": "<ISO>",
       "toAgentDid": "did:cdi:registry.clawdentity.com:...",
       "payload": { ... },
       "conversationId": "conv-123"
     }

     The proxy responds with "enqueue_ack" after accepting or rejecting
     the message for relay.

  9.7.  Local Agent Delivery

     Upon receiving a "deliver" frame, the connector forwards the payload
     to the local agent framework via HTTP POST:

     POST /hooks/agent HTTP/1.1
     Host: 127.0.0.1:18789
     Content-Type: application/json
     x-clawdentity-agent-did: <fromAgentDid>
     x-clawdentity-to-agent-did: <toAgentDid>
     x-clawdentity-verified: true
     x-openclaw-token: <local-hook-token>
     x-request-id: <frame-id>

     The connector implements retry with exponential backoff for transient
     failures (5xx, 429, connection errors):

                      +================+===============+
                      | Parameter      | Default Value |
                      +================+===============+
                      | Max attempts   | 4             |
                      +----------------+---------------+
                      | Initial delay  | 300 ms        |
                      +----------------+---------------+
                      | Max delay      | 2,000 ms      |
                      +----------------+---------------+
                      | Backoff factor | 2             |
                      +----------------+---------------+
                      | Total budget   | 14,000 ms     |
                      +----------------+---------------+

                                   Table 6






  Vemula                   Expires 25 August 2026                [Page 19]


  Internet-Draft                 Clawdentity                 February 2026


  9.8.  Reconnection

     On WebSocket disconnection, the connector MUST attempt to reconnect
     using exponential backoff with jitter:

                      +================+===============+
                      | Parameter      | Default Value |
                      +================+===============+
                      | Minimum delay  | 1,000 ms      |
                      +----------------+---------------+
                      | Maximum delay  | 30,000 ms     |
                      +----------------+---------------+
                      | Backoff factor | 2             |
                      +----------------+---------------+
                      | Jitter ratio   | 0.2 (±20%)    |
                      +----------------+---------------+

                                   Table 7

     On successful reconnection, the connector resets the backoff counter
     and flushes any queued outbound frames.

  9.9.  Outbound Queue Persistence

     When the WebSocket connection is unavailable, the connector MUST
     queue outbound "enqueue" frames locally and flush them in FIFO order
     upon reconnection.  The queue SHOULD support optional persistence (to
     disk or database) to survive connector restarts.

  10.  Certificate Revocation

  10.1.  CRL Format

     The Certificate Revocation List (CRL) is a signed JWT containing a
     list of revoked AITs.  Its JOSE header uses:

     alg  MUST be "EdDSA".

     typ  MUST be "CRL".

     kid  Registry signing key identifier.

     CRL claims:








  Vemula                   Expires 25 August 2026                [Page 20]


  Internet-Draft                 Clawdentity                 February 2026


         +=============+========+==========+========================+
         | Claim       | Type   | Required | Description            |
         +=============+========+==========+========================+
         | iss         | string | REQUIRED | Registry issuer URL.   |
         +-------------+--------+----------+------------------------+
         | jti         | string | REQUIRED | CRL identifier (ULID). |
         +-------------+--------+----------+------------------------+
         | iat         | number | REQUIRED | Issued-at timestamp.   |
         +-------------+--------+----------+------------------------+
         | exp         | number | REQUIRED | Expiration.  MUST be   |
         |             |        |          | greater than iat.      |
         +-------------+--------+----------+------------------------+
         | revocations | array  | REQUIRED | At least one           |
         |             |        |          | revocation entry.      |
         +-------------+--------+----------+------------------------+

                                   Table 8

     Each revocation entry contains:

         +===========+========+==========+===========================+
         | Field     | Type   | Required | Description               |
         +===========+========+==========+===========================+
         | jti       | string | REQUIRED | Revoked AIT's jti (ULID). |
         +-----------+--------+----------+---------------------------+
         | agentDid  | string | REQUIRED | Revoked agent's DID.      |
         +-----------+--------+----------+---------------------------+
         | reason    | string | OPTIONAL | Human-readable reason.    |
         |           |        |          | Max 280 chars.            |
         +-----------+--------+----------+---------------------------+
         | revokedAt | number | REQUIRED | Revocation timestamp      |
         |           |        |          | (Unix seconds).           |
         +-----------+--------+----------+---------------------------+

                                    Table 9

  10.2.  CRL Distribution

     The registry publishes the current CRL at the well-known endpoint:

     GET /v1/crl HTTP/1.1
     Host: registry.clawdentity.com

     Response:

     { "crl": "<signed-CRL-JWT>" }





  Vemula                   Expires 25 August 2026                [Page 21]


  Internet-Draft                 Clawdentity                 February 2026


  10.3.  CRL Caching

     Proxies MUST cache the CRL locally and refresh it periodically.  The
     following parameters control caching behavior:

        +===========+===========+=====================================+
        | Parameter | Default   | Description                         |
        +===========+===========+=====================================+
        | Refresh   | 5 minutes | How often to fetch a fresh CRL.     |
        | interval  |           |                                     |
        +-----------+-----------+-------------------------------------+
        | Max age   | 15        | Maximum staleness before the cache  |
        |           | minutes   | is considered expired.              |
        +-----------+-----------+-------------------------------------+
        | Stale     | fail-open | "fail-open" allows stale CRL use;   |
        | behavior  |           | "fail-closed" rejects all requests. |
        +-----------+-----------+-------------------------------------+

                                    Table 10

     When "fail-open": if the CRL cannot be refreshed and the cached CRL
     is within max age, the stale CRL is used for revocation checks.

     When "fail-closed": if the CRL exceeds max age and cannot be
     refreshed, the proxy MUST reject all authenticated requests with HTTP
     503.

  10.4.  Revocation Scope

     Two levels of revocation are defined:

     Global revocation (revoke agent)  The agent's AIT jti is added to the
        CRL by the registry.  The agent can no longer authenticate at any
        proxy.  Only the agent's owner can initiate global revocation.

     Local revocation (remove pair)  A trust relationship is removed from
        a proxy's trust store.  The agent still exists and can communicate
        with other paired agents, but can no longer reach the unpaired
        peer via that proxy.  Either side of the pair can initiate local
        revocation.

  11.  Registry Key Discovery

     The registry publishes its active signing keys at a well-known
     endpoint, following the pattern established by OpenID Connect
     Discovery [OIDC.Discovery]:





  Vemula                   Expires 25 August 2026                [Page 22]


  Internet-Draft                 Clawdentity                 February 2026


     GET /.well-known/claw-keys.json HTTP/1.1
     Host: registry.clawdentity.com

     Response:

     {
       "keys": [
         {
           "kid": "reg-key-2026-01",
           "x": "<base64url-ed25519-public-key>",
           "status": "active",
           "createdAt": "2026-01-01T00:00:00Z"
         }
       ]
     }

     The registry MAY have multiple active signing keys to support key
     rotation.  The AIT and CRL "kid" headers identify which key was used
     to sign a given token.  Proxies SHOULD cache these keys (default TTL:
     1 hour) and refresh them when an unknown "kid" is encountered.

  12.  Endpoint Reference

  12.1.  Registry Endpoints

        +========+==================+==========+======================+
        | Method | Path             | Auth     | Description          |
        +========+==================+==========+======================+
        | GET    | /.well-known/    | None     | Registry signing     |
        |        | claw-keys.json   |          | keys                 |
        +--------+------------------+----------+----------------------+
        | GET    | /v1/metadata     | None     | Registry metadata    |
        +--------+------------------+----------+----------------------+
        | GET    | /v1/crl          | None     | Current CRL          |
        +--------+------------------+----------+----------------------+
        | POST   | /v1/agents/      | API Key  | Request registration |
        |        | challenge        |          | challenge            |
        +--------+------------------+----------+----------------------+
        | POST   | /v1/agents/auth/ | AIT +    | Refresh AIT          |
        |        | refresh          | Access   |                      |
        +--------+------------------+----------+----------------------+
        | POST   | /v1/agents/auth/ | Internal | Validate agent       |
        |        | validate         |          | access token         |
        +--------+------------------+----------+----------------------+
        | POST   | /v1/invites      | API Key  | Create invite code   |
        +--------+------------------+----------+----------------------+
        | POST   | /v1/invites/     | None     | Redeem invite code   |
        |        | redeem           |          |                      |



  Vemula                   Expires 25 August 2026                [Page 23]


  Internet-Draft                 Clawdentity                 February 2026


        +--------+------------------+----------+----------------------+

                                    Table 11

  12.2.  Proxy Endpoints

         +========+===================+===========+==================+
         | Method | Path              | Auth      | Description      |
         +========+===================+===========+==================+
         | GET    | /health           | None      | Health check     |
         +--------+-------------------+-----------+------------------+
         | POST   | /hooks/agent      | AIT + PoP | Inbound message  |
         |        |                   | + Access  | delivery         |
         +--------+-------------------+-----------+------------------+
         | GET    | /v1/relay/connect | AIT + PoP | WebSocket relay  |
         |        |                   | + Access  |                  |
         +--------+-------------------+-----------+------------------+
         | POST   | /v1/relay/        | AIT + PoP | Delivery receipt |
         |        | delivery-receipts | + Access  | callback         |
         +--------+-------------------+-----------+------------------+
         | POST   | /pair/start       | AIT + PoP | Initiate pairing |
         +--------+-------------------+-----------+------------------+
         | POST   | /pair/confirm     | AIT + PoP | Confirm pairing  |
         +--------+-------------------+-----------+------------------+
         | POST   | /pair/status      | AIT + PoP | Check pairing    |
         |        |                   |           | status           |
         +--------+-------------------+-----------+------------------+

                                    Table 12

  13.  Security Considerations

  13.1.  Private Key Protection

     Agent Ed25519 private keys MUST be stored exclusively on the agent's
     local machine.  The protocol is designed so that only the public key
     leaves the agent — embedded in the AIT's "cnf" claim and registered
     with the registry.  Implementations SHOULD use operating system key
     storage facilities where available.

  13.2.  Replay Protection

     Three mechanisms provide replay protection:

     1.  *Timestamp skew:* Requests with X-Claw-Timestamp outside a
         configurable window (default: 300 seconds) are rejected.





  Vemula                   Expires 25 August 2026                [Page 24]


  Internet-Draft                 Clawdentity                 February 2026


     2.  *Nonce uniqueness:* Each (agentDid, nonce) pair is tracked per
         proxy.  Duplicate nonces within the timestamp window are
         rejected.

     3.  *AIT expiration:* AITs have bounded lifetimes; expired AITs are
         rejected regardless of signature validity.

  13.3.  Transport Security

     TLS 1.2 or later ([RFC8446] for TLS 1.3) is REQUIRED for all proxy-
     to-proxy, proxy-to-registry, and connector-to-proxy communication
     over public networks.  The PoP signature (Section 5) provides an
     additional layer: even if TLS were compromised, a captured AIT cannot
     produce valid request signatures without the private key.

  13.4.  Connector Isolation

     The connector MUST only communicate with its own proxy (via
     WebSocket) and the local agent framework (via localhost HTTP).  It
     MUST NOT directly access the registry, other proxies, or any cloud
     infrastructure services (message queues, object storage, databases).
     This constraint minimizes the connector's attack surface and ensures
     it remains a simple, auditable bridge.

  13.5.  Trust Store Integrity

     The trust store is the sole authorization source for message relay.
     Implementations SHOULD use a transactional storage backend (e.g.,
     SQLite within a Cloudflare Durable Object) to prevent corruption from
     concurrent access or partial writes.

  13.6.  CRL Freshness Window

     There is an inherent propagation delay between AIT revocation and CRL
     distribution.  With default settings, this window is up to 5 minutes.
     Deployments requiring tighter revocation windows SHOULD:

     *  Reduce the CRL refresh interval.

     *  Use push-based CRL invalidation (e.g., message queues).

     *  Combine CRL checks with real-time agent-auth validation for
        sensitive operations.








  Vemula                   Expires 25 August 2026                [Page 25]


  Internet-Draft                 Clawdentity                 February 2026


  13.7.  Human-Anchored Trust

     The protocol explicitly prevents agent self-certification.  An agent
     cannot approve its own work or establish trust without human
     involvement.  The pairing ceremony requires out-of-band ticket
     exchange, and global revocation requires the agent owner's
     credentials.  This design prevents autonomous trust escalation.

  14.  Error Codes

     The following error codes are returned in JSON error responses with
     the corresponding HTTP status codes:

  14.1.  Authentication Errors (401)

     +==============================+===================================+
     | Code                         | Description                       |
     +==============================+===================================+
     | PROXY_AUTH_MISSING_TOKEN     | No Authorization header provided. |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_INVALID_SCHEME    | Authorization header is not "Claw |
     |                              | <token>" format.                  |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_INVALID_AIT       | AIT JWT verification failed.      |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_INVALID_PROOF     | PoP signature does not match.     |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_INVALID_TIMESTAMP | X-Claw-Timestamp missing or not a |
     |                              | valid integer.                    |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_TIMESTAMP_SKEW    | Timestamp outside the allowed     |
     |                              | skew window.                      |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_REPLAY            | Nonce has been seen before        |
     |                              | (replay detected).                |
     +------------------------------+-----------------------------------+
     | PROXY_AUTH_REVOKED           | AIT jti is on the CRL.            |
     +------------------------------+-----------------------------------+
     | PROXY_AGENT_ACCESS_REQUIRED  | X-Claw-Agent-Access header        |
     |                              | missing.                          |
     +------------------------------+-----------------------------------+
     | PROXY_AGENT_ACCESS_INVALID   | Agent access token is invalid or  |
     |                              | expired.                          |
     +------------------------------+-----------------------------------+

                                   Table 13





  Vemula                   Expires 25 August 2026                [Page 26]


  Internet-Draft                 Clawdentity                 February 2026


  14.2.  Authorization Errors (403)

         +================================+==========================+
         | Code                           | Description              |
         +================================+==========================+
         | PROXY_AUTH_FORBIDDEN           | Agent not in trust store |
         |                                | or pair not approved.    |
         +--------------------------------+--------------------------+
         | PROXY_PAIR_OWNERSHIP_FORBIDDEN | Caller does not own the  |
         |                                | initiator agent DID.     |
         +--------------------------------+--------------------------+

                                    Table 14

  14.3.  Service Unavailable Errors (503)

      +===================================+============================+
      | Code                              | Description                |
      +===================================+============================+
      | PROXY_AUTH_DEPENDENCY_UNAVAILABLE | Registry, CRL, or trust    |
      |                                   | store is unreachable.      |
      +-----------------------------------+----------------------------+
      | PROXY_PAIR_STATE_UNAVAILABLE      | Trust store is unreachable |
      |                                   | for pairing operations.    |
      +-----------------------------------+----------------------------+
      | CRL_CACHE_STALE                   | CRL exceeds max age and    |
      |                                   | fail-closed is configured. |
      +-----------------------------------+----------------------------+

                                   Table 15

  15.  IANA Considerations

  15.1.  DID Method Registration

     This specification introduces the "cdi" DID method.  A registration
     request for the W3C DID Method Registry would include:

     Method Name  cdi

     Method Specific Identifier  <registry-host>:<ulid>

     DID Document  Resolved via the registry identified by the registry-
        host component.







  Vemula                   Expires 25 August 2026                [Page 27]


  Internet-Draft                 Clawdentity                 February 2026


  15.2.  HTTP Authentication Scheme Registration

     This specification registers the "Claw" authentication scheme in the
     "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry"
     defined in [RFC9110] Section 16.3:

     Authentication Scheme Name  Claw

     Reference  Section 6 of this document

  15.3.  JWT "typ" Header Parameter Values

     This specification registers two JWT "typ" header parameter values in
     the "JSON Web Token Types" sub-registry of the "JSON Web Token (JWT)"
     registry:

          +=============+=============================+============+
          | "typ" Value | Description                 | Reference  |
          +=============+=============================+============+
          | AIT         | Agent Identity Token        | Section 4  |
          +-------------+-----------------------------+------------+
          | CRL         | Certificate Revocation List | Section 10 |
          +-------------+-----------------------------+------------+

                                   Table 16

  16.  References

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

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

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




  Vemula                   Expires 25 August 2026                [Page 28]


  Internet-Draft                 Clawdentity                 February 2026


     [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
                RFC 6455, DOI 10.17487/RFC6455, December 2011,
                <https://www.rfc-editor.org/info/rfc6455>.

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

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/info/rfc7519>.

     [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
                Possession Key Semantics for JSON Web Tokens (JWTs)",
                RFC 7800, DOI 10.17487/RFC7800, April 2016,
                <https://www.rfc-editor.org/info/rfc7800>.

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

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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

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

  16.2.  Informative References

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

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





  Vemula                   Expires 25 August 2026                [Page 29]


  Internet-Draft                 Clawdentity                 February 2026


     [ULID]     Feerasta, A., "Universally Unique Lexicographically
                Sortable Identifier", 2016,
                <https://github.com/ulid/spec>.

     [OIDC.Discovery]
                Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
                Connect Discovery 1.0", November 2014,
                <https://openid.net/specs/openid-connect-discovery-
                1_0.html>.

  Appendix A.  Example: Complete Message Flow

     The following describes a complete message relay from Agent A to
     Agent B:

     1.  Agent A's connector creates an "enqueue" frame targeting Agent
         B's DID.

     2.  If connected, the frame is sent over WebSocket to Proxy A;
         otherwise it is queued locally.

     3.  Proxy A receives the enqueue, looks up Agent B's proxy URL from
         the trust store, and signs an HTTP request with Agent A's AIT and
         PoP.

     4.  Proxy A sends POST /hooks/agent to Proxy B with the signed
         request.

     5.  Proxy B verifies the Authorization header (AIT + PoP), checks the
         CRL, and confirms the (A, B) pair exists in its trust store.

     6.  Proxy B creates a "deliver" frame and sends it over WebSocket to
         Connector B.

     7.  Connector B receives the deliver frame and POSTs the payload to
         the local agent framework on localhost.

     8.  Connector B sends a "deliver_ack" (accepted: true) back to Proxy
         B.

     9.  Agent B processes the message.










  Vemula                   Expires 25 August 2026                [Page 30]


  Internet-Draft                 Clawdentity                 February 2026


  Appendix B.  Comparison with Existing Standards

        +================+====================+=======================+
        | Feature        | OAuth 2.0 / DPoP   | Clawdentity           |
        +================+====================+=======================+
        | Identity model | Client credentials | Per-agent DID +       |
        |                | / tokens           | Ed25519 keypair       |
        +----------------+--------------------+-----------------------+
        | Token issuer   | Authorization      | Registry (centralized |
        |                | server             | trust anchor)         |
        +----------------+--------------------+-----------------------+
        | PoP mechanism  | DPoP JWT (RFC      | Canonical request     |
        |                | 9449)              | signing               |
        +----------------+--------------------+-----------------------+
        | Trust model    | Scope-based        | Explicit bilateral    |
        |                | authorization      | pairing               |
        +----------------+--------------------+-----------------------+
        | Revocation     | Token              | Signed CRL with local |
        |                | introspection      | caching               |
        +----------------+--------------------+-----------------------+
        | Transport      | Direct HTTP        | WebSocket relay with  |
        |                |                    | store-and-forward     |
        +----------------+--------------------+-----------------------+
        | Target         | Human-to-service   | Agent-to-agent        |
        |                | auth               | communication         |
        +----------------+--------------------+-----------------------+

                                    Table 17

  Acknowledgements

     The Clawdentity protocol was designed as part of the OpenClaw
     ecosystem.  The author thanks the OpenClaw community for feedback on
     the identity model, and the designers of DPoP (RFC 9449) and W3C DIDs
     whose work informed key design decisions.

  Author's Address

     Ravi Kiran Vemula
     CAW
     Hyderabad
     India
     Email: vrknetha@gmail.com
     URI:   https://ravi.sh







  Vemula                   Expires 25 August 2026                [Page 31]


name: draft-messous-eat-ai
rev: 01
title: Entity Attestation Token (EAT) Profile for Autonomous AI Agents
time: 2026-02-24T00:47:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T00:47:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T13:09:21.692374+00:00
source: ietf
abstract:
  This document defines a profile for the Entity Attestation Token
     (EAT) to support remote attestation of autonomous AI agents across
     domains.  It specifies a set of standardized claims for attesting the
     integrity of AI model parameters, the provenance of training data,
     and the constraints of inference-time data access policies.  Optional
     extensions for 5G/6G network functions—such as slice-type
     authorization—are included for interoperability with ETSI ENI and
     3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
     or JSON Web Tokens (JWTs) and is designed to be used within the IETF
     RATS architecture.

full_text:
  Network Working Group                                         A. MESSOUS
  Internet-Draft                                                Huawei R&D
  Intended status: Informational                          23 February 2026
  Expires: 27 August 2026


      Entity Attestation Token (EAT) Profile for Autonomous AI Agents
                          draft-messous-eat-ai-01

  Abstract

     This document defines a profile for the Entity Attestation Token
     (EAT) to support remote attestation of autonomous AI agents across
     domains.  It specifies a set of standardized claims for attesting the
     integrity of AI model parameters, the provenance of training data,
     and the constraints of inference-time data access policies.  Optional
     extensions for 5G/6G network functions—such as slice-type
     authorization—are included for interoperability with ETSI ENI and
     3GPP architectures.  The profile is encoded in CBOR Web Tokens (CWTs)
     or JSON Web Tokens (JWTs) and is designed to be used within the IETF
     RATS architecture.

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-messous-eat-ai/.

     Source for this draft and an issue tracker can be found at
     https://github.com/https://github.com/mmessous/draft-messous-EAT-AI.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 27 August 2026.



  MESSOUS                  Expires 27 August 2026                 [Page 1]


  Internet-Draft                EAT-AI-Agents                February 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Generic AI Agent Attestation  . . . . . . . . . . . . . .   4
       3.2.  5G/6G Network Functions (Optional Context)  . . . . . . .   4
     4.  EAT-AI Claims Definition  . . . . . . . . . . . . . . . . . .   4
       4.1.  Core Claims (Generic, Domain-Agnostic)  . . . . . . . . .   4
         4.1.1.  ai-model-id . . . . . . . . . . . . . . . . . . . . .   6
         4.1.2.  use of cryptography digests . . . . . . . . . . . . .   6
         4.1.3.  ai-sbom-ref . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Optional Domain-Specific Claims (5G/6G) . . . . . . . . .   7
       4.3.  Composite and Multi-Component Attestation . . . . . . . .   8
         4.3.1.  Multi-Agent Platforms:  . . . . . . . . . . . . . . .   8
         4.3.2.  Multi-Model Agents: . . . . . . . . . . . . . . . . .   9
         4.3.3.  Layered Trust:  . . . . . . . . . . . . . . . . . . .  10
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  13
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
       7.1.  EAT Profile Registration  . . . . . . . . . . . . . . . .  14
       7.2.  CWT Claims Registry . . . . . . . . . . . . . . . . . . .  14
       7.3.  JWT Claims Registry . . . . . . . . . . . . . . . . . . .  15
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       8.1.  Normative:  . . . . . . . . . . . . . . . . . . . . . . .  16
       8.2.  Informative:  . . . . . . . . . . . . . . . . . . . . . .  16
     9.  Appendix A.  Example EAT-AI Token (CWT) . . . . . . . . . . .  17
     10. Appendix B.  Relationship to Existing Standards &
             Initiatives . . . . . . . . . . . . . . . . . . . . . . .  17
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  18
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18






  MESSOUS                  Expires 27 August 2026                 [Page 2]


  Internet-Draft                EAT-AI-Agents                February 2026


  1.  Introduction

     Autonomous AI agents—software entities that perceive, reason, and act
     with minimal human oversight—are deployed across cloud, edge,
     enterprise, and telecommunications environments.  Their autonomy
     introduces new trust challenges: if an agent’s model is tampered, its
     training data is non-compliant, or its inference policy is violated,
     the consequences range from service disruption to regulatory
     breaches.

     The Entity Attestation Token (EAT) [[RFC9711]] provides a
     standardized framework for remote attestation.  However, EAT does not
     define claims specific to AI artifacts.  This document fills that gap
     by specifying a *generic EAT profile for AI agents*, with *optional
     telecom-specific claims* for use in 5G/6G networks (e.g., ETSI ENI
     AI-Core [[ETSI-GR-ENI-051]]).

     This profile enables verifiers—such as OAuth resource servers,
     network function orchestrators, or policy enforcement points—to make
     trust decisions based on verifiable evidence about an agent’s: -
     *Model integrity* (weights, architecture), - *Training provenance*
     (dataset, geography, privacy), - *Runtime authorization*
     (capabilities, allowed APIs, slice types).

     This profile does not define a full AI Bill of Materials (AIBOM).
     Instead, it provides a minimal set of *verifiable claims* sufficient
     for remote attestation and policy enforcement.  It assumes that
     richer metadata—such as detailed training data lineage, model cards,
     or complete dependency graphs—is maintained in external documents
     (e.g., an AIBOM or SBOM), which may be referenced via claims like ai-
     sbom-ref or a future ai-bom-ref.  Traditional SBOMs remain essential
     to capture the *software supply chain* (e.g., Python, CUDA, framework
     versions) on which the AI agent depends.  This profile complements,
     but does not replace, those artifacts.

  2.  Terminology

     *  *AI Agent*: AI agents are autonomous systems powered by Large
        Language Models (LLMs) that can reason, plan, use tools, maintain
        memory, and take actions to accomplish goals.

     *  *Model Integrity*: The property that AI model weights and
        architecture have not been altered from a known-good state.

     *  *Training Provenance*: Metadata describing the origin, scope, and
        privacy properties of data used to train an AI model.





  MESSOUS                  Expires 27 August 2026                 [Page 3]


  Internet-Draft                EAT-AI-Agents                February 2026


     *  *Inference Policy*: Constraints defining the authorized input
        context (e.g., slice type, geography) under which an agent may
        operate.

     *  *EAT-AI*: The EAT profile defined in this document.

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

  3.  Use Cases

  3.1.  Generic AI Agent Attestation

     An enterprise AI agent attests its model hash and data retention
     policy before accessing a protected API.  For a more extensive
     protection, attestation target could also include behavioral
     manifests, identity, prompts, tools and capabilities, SBOM/AIBOMs etc
     in the future.

  3.2.  5G/6G Network Functions (Optional Context)

     In ETSI ENI AI-Core, an Execution Agent generates instructions for
     network slice configuration.  The agent should prove: - It runs an
     approved model (ai-model-hash), - It was trained on GDPR-compliant
     data (training-geo-region, dp-epsilon), - It is authorized for
     specific slice types (allowed-slice-types).

        *Note*: Telecom-specific claims are *optional* and *only
        meaningful in 3GPP/ETSI contexts*.

  4.  EAT-AI Claims Definition

     Claims are defined for both *CWT (CBOR)* and *JWT (JSON)*. In CWT,
     claims use signed integer keys; in JWT, they use text names (with
     hyphens converted to underscores per convention).

  4.1.  Core Claims (Generic, Domain-Agnostic)

     +============+======+=====================+======+======================+
     |Claim Name  |CBOR  |JWT Name             |Type  |Description           |
     |            |Key   |                     |      |                      |
     +============+======+=====================+======+======================+
     |ai-model-id |-75000|ai_model_id          |text  |URN-formatted model   |
     |            |      |                     |      |identifier (e.g.,     |
     |            |      |                     |      |urn:ietf:ai:model:cnn-|
     |            |      |                     |      |v3)                   |



  MESSOUS                  Expires 27 August 2026                 [Page 4]


  Internet-Draft                EAT-AI-Agents                February 2026


     +------------+------+---------------------+------+----------------------+
     |ai-model-   |-75001|ai_model_hash        |digest|Cryptographic hash of |
     |hash        |      |                     |      |the serialized model  |
     |            |      |                     |      |weights and           |
     |            |      |                     |      |architecture          |
     +------------+------+---------------------+------+----------------------+
     |model-arch- |-75002|model_arch_digest    |digest|Cryptographic hash of |
     |digest      |      |                     |      |model computational   |
     |            |      |                     |      |graph                 |
     +------------+------+---------------------+------+----------------------+
     |training-   |-75003|training_data_id     |text  |Unique ID of training |
     |data-id     |      |                     |      |dataset               |
     +------------+------+---------------------+------+----------------------+
     |dp-epsilon  |-75005|dp_epsilon           |float |Differential privacy  |
     |            |      |                     |      |epsilon used during   |
     |            |      |                     |      |training              |
     +------------+------+---------------------+------+----------------------+
     |input-      |-75006|input_policy_digest  |digest|Cryptographic hash of |
     |policy-     |      |                     |      |inference input policy|
     |digest      |      |                     |      |                      |
     +------------+------+---------------------+------+----------------------+
     |data-       |-75008|data_retention_policy|text  |e.g., "none",         |
     |retention-  |      |                     |      |"session", "24h"      |
     |policy      |      |                     |      |                      |
     +------------+------+---------------------+------+----------------------+
     |owner-id    |-75009|owner_id             |text  |Identity of principal |
     |            |      |                     |      |(e.g., GPSI per 3GPP  |
     |            |      |                     |      |TS 29.222)            |
     +------------+------+---------------------+------+----------------------+
     |capabilities|-75010|capabilities         |array |High-level functions  |
     |            |      |                     |of    |(e.g., "slice-        |
     |            |      |                     |text  |optimization")        |
     +------------+------+---------------------+------+----------------------+
     |allowed-apis|-75011|allowed_apis         |array |Specific endpoints the|
     |            |      |                     |of URI|agent may call        |
     +------------+------+---------------------+------+----------------------+
     |ai-sbom-ref |-75012|ai_sbom_ref          |text /|Reference to a        |
     |            |      |                     |map   |Software Bill of      |
     |            |      |                     |      |Materials (SBOM)      |
     |            |      |                     |      |describing the AI     |
     |            |      |                     |      |agent’s runtime       |
     |            |      |                     |      |dependencies (e.g.,   |
     |            |      |                     |      |Python, CUDA,         |
     |            |      |                     |      |libraries).  MAY be a |
     |            |      |                     |      |URI, digest, or       |
     |            |      |                     |      |embedded SBOM fragment|
     +------------+------+---------------------+------+----------------------+




  MESSOUS                  Expires 27 August 2026                 [Page 5]


  Internet-Draft                EAT-AI-Agents                February 2026


                      Table 1: Core Domain-Agnostic Claims

  4.1.1.  ai-model-id

     *  ai-model-id: A globally unique model identifier encoded as a URN.
        The URN *namespace* urn:ietf:ai:model: is reserved for
        standardized reference models (e.g., defined in RFCs). *Model
        owners SHOULD use their own URN namespace* (e.g., based on domain
        name, PEN, or UUID) to avoid central coordination.  Examples:

        -  urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 (for a private
           model)

        -  urn:ietf:ai:model:llama3-8b (for a well-known public model, if
           later standardized)

        -  urn:dev:example.com:finance-agent-v2 (enterprise-owned model)

  4.1.2.  use of cryptography digests

     *  The claims ai-model-hash, model-arch-digest, and input-policy-
        digest represent cryptographic digests of serialized artifacts
        (e.g., model weights, computational graphs, or policy documents).
        To support algorithm agility and avoid ambiguity, each such claim
        is defined as a digest structure rather than a bare byte string.
        A digest structure is encoded as a two-element array:

     cbor [ alg, hash ]

     where: - *alg* is the Hash Algorithm Identifier, using either the
     *integer* or *text string* from the IANA COSE Algorithms registry
     (https://www.iana.org/assignments/cose/cose.xhtml#algorithms),
     indicating the hash function used (e.g., '-16' for SHA-256, -44 for
     SHA-384, -45 for SHA3-256). - *hash* is the byte string output of
     applying that hash function to the canonical serialization of the
     artifact.

     In *CBOR*, the digest is represented as a CBOR array: [ int / tstr,
     bstr ].  In *JWT* (JSON), it is represented as a JSON object: {
     "alg": "...", "hash": "base64url-encoded-hash" }. This design aligns
     with the Detached-Submodule-Digest type defined in [RFC 9711,
     Section 4.2.18.2] and enables future-proof support for multiple hash
     algorithms (e.g., SHA-2, SHA-3, post-quantum secure hashes) without
     requiring new claims or breaking existing parsers.







  MESSOUS                  Expires 27 August 2026                 [Page 6]


  Internet-Draft                EAT-AI-Agents                February 2026


  4.1.3.  ai-sbom-ref

     *  The ai-sbom-ref claim provides a reference to the *Software Bill
        of Materials (SBOM)* associated with the AI agent.  This enables
        verifiers to assess the integrity, license compliance, and
        vulnerability status of the agent’s software supply chain.  The
        value MAY be:

     *  A URI pointing to an SBOM document (e.g., in SPDX or CycloneDX
        format),

     *  A digest (using the structured digest format defined in
        Section 4.1) of an SBOM,

     *  Or a compact embedded representation (e.g., a minimal map of
        critical components).

     Example (CBOR):

     cbor / ai-sbom-ref / -75012: "https://example.com/sboms/agent-
     xyz.spdx.json"

     Example (embedded digest):

     cbor / ai-sbom-ref / -75012: [ -44, h'abcd1234...' ] ; SHA-384 digest
     of SBOM

     When used, the SBOM SHOULD include: - Runtime environment (e.g.,
     Python 3.11, CUDA 12.4), - AI framework versions (e.g., PyTorch 2.3,
     TensorFlow 2.15), - Critical dependencies (e.g., NumPy, cuDNN), -
     Model serialization format (e.g., ONNX v9, SafeTensors v0.4).  This
     claim complements model integrity (ai-model-hash) by attesting to the
     execution context in which the model operates—critical for
     reproducibility and security analysis.

  4.2.  Optional Domain-Specific Claims (5G/6G)

     +===================+======+===================+=====+==============+
     |Claim Name         |CBOR  |JWT Name           |Type |Description   |
     |                   |Key   |                   |     |              |
     +===================+======+===================+=====+==============+
     |training-geo-region|-75004|training_geo_region|array|ISO 3166-1    |
     |                   |      |                   |of   |alpha-2 codes |
     |                   |      |                   |text |(e.g., ["DE", |
     |                   |      |                   |     |"FR"])        |
     +-------------------+------+-------------------+-----+--------------+
     |allowed-slice-types|-75007|allowed_slice_types|array|3GPP-defined  |
     |                   |      |                   |of   |slice types   |



  MESSOUS                  Expires 27 August 2026                 [Page 7]


  Internet-Draft                EAT-AI-Agents                February 2026


     |                   |      |                   |text |(e.g.,        |
     |                   |      |                   |     |"eMBB",       |
     |                   |      |                   |     |"URLLC")      |
     +-------------------+------+-------------------+-----+--------------+

                    Table 2: Optional Domain-Specific Claims

        *Usage*: These claims *SHOULD be used* when attesting agents in
        *ETSI ENI or 3GPP SBA* environments.

  4.3.  Composite and Multi-Component Attestation

     This profile utilizes the recursive nesting capability of the submods
     claim (Key 266) to support three specific composite scenarios:

  4.3.1.  Multi-Agent Platforms:

     To support a user managing multiple agents with varying
     configurations, we should leverage the recursive nesting capability
     of the submods claim (CBOR key 266) as defined in [RFC 9711].  In
     this architectural pattern, the top-level EAT represents the user's
     platform or trust domain.  Each agent is a submodule of that
     platform, and if an agent uses multiple models, those models are
     further nested as submodules of that specific agent.

     The following CWT example shows a platform hosting two agents.  Agent
     1 is a complex orchestrator using two models, while Agent 2 is a
     simple worker using only one.

     Code snippet





















  MESSOUS                  Expires 27 August 2026                 [Page 8]


  Internet-Draft                EAT-AI-Agents                February 2026


  {
  / ueid / 256: h'0102030405060708',  / User/Platform ID /
      / nonce / 10: h'abcdef1234567890', / Freshness Nonce /
      / submods / 266: {                 / Submodules Section /

      / --- Agent 1: Multi-Model Orchestrator --- /
      "agent-1": {
        / swname / 270: "Orchestrator-Agent-v2",
        / submods / 266: {             / Nested Model Submodules /
          "llm-core": {
            / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
            / ai-model-hash / -75001: [-44, h'9a8b...']  / SHA-384 /
          },
          "tool-planner": {
            / ai-model-id / -75000: ":uuid:550e8400-e29b-41d4-a716-446655440000",
            / ai-model-hash / -75001: [-16, h'5e4f...']  / SHA-256 /
          }
        }
      },

      / --- Agent 2: Single-Model Worker --- /
      "agent-2": {
        / swname / 270: "Vision-Worker-v1",
        / ai-model-id / -75000: ":ietf:ai:model:vit-b-16", /
        / ai-model-hash / -75001: [-44, h'd3e2...']            /
      }
    }
  }

  4.3.2.  Multi-Model Agents:

     A single agent utilizing an orchestrator model and task-specific
     worker models.

     Modern AI agents are not necessarly monolithic; sophesticated Agents
     can consist of an orchestrator model (e.g., a LLM) and several task-
     specific worker models (e.g., image classifiers or encoders).  To
     support these configurations, this profile utilizes the submods claim
     (Key 266) from [RFC 9711].  Each distinct model used by the agent
     SHOULD be represented as an entry within the submods map.  This
     allows for granular policy appraisal where different models may have
     different trust levels, privacy parameters (dp_epsilon), or residency
     requirements.








  MESSOUS                  Expires 27 August 2026                 [Page 9]


  Internet-Draft                EAT-AI-Agents                February 2026


     When a model is represented in a submodule, it carries its own
     instance of ai-model-id and ai-model-hash.  If the model weights are
     proprietary (e.g., accessed via a cloud API), the submodule SHOULD
     include an ai-model-id that the Verifier can match against a provider
     Endorsement.

     The following example demonstrates an agent employing an orchestrator
     LLM and a specialized vision model.  Note the use of the digest
     format [alg, val] to support different hash types for each model.

     Code snippet

  {
    / ueid / 256: h'0102030405060708',
    / nonce / 10: h'abcdef1234567890',
    / submods / 266: {
      "orchestrator-llm": {
        / ai-model-id / -75000: ":uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
        / ai-model-hash / -75001: [-44, h'9a8b7c6d...']  / SHA-384 /
      },
      "vision-classifier": {
        / ai-model-id / -75000: ":ietf:ai:model:vit-b-16",
        / ai-model-hash / -75001: [-16, h'5e4f3a2b...'], / SHA-256 /
        / dp-epsilon / -75005: 0.8
      }
    }
  }

  4.3.3.  Layered Trust:

     Scenarios where different system components (e.g., hardware TEE, OS
     runtime, and AI model) are owned or managed by different entities.

     *  *Nesting Mechanism:* Components SHOULD be represented as nested
        EATs within the submods claim (Key 266).  Each nested token MAY be
        signed by a different attestation key belonging to the respective
        component owner.

     *  *Verifier Role:* A Verifier receiving a composite EAT SHOULD
        follow the Hierarchical Pattern, where it acts as a Lead Verifier
        and delegates the appraisal of individual submodules to
        specialized verifiers that hold the appropriate Trust Anchors for
        each owner.

     For multi-owner attestation, a *Lead Verifier* SHOULD follow the
     *Hierarchical Pattern*, extracting nested sub-tokens and delegating
     their appraisal to specialized verifiers holding the appropriate
     Trust Anchors.



  MESSOUS                  Expires 27 August 2026                [Page 10]


  Internet-Draft                EAT-AI-Agents                February 2026


           +-----------------------------------------------------------+
           |  Attesting Device (e.g., Edge Server / 5G UE)             |
           |                                                           |
           |  +----------------------------+                           |
           |  | Hardware Root of Trust     | <--- Signing Key (AK_1)   |
           |  | (RoT)                      |                           |
           |  +-------------+--------------+                           |
           |                | Measures                                 |
           |                v                                          |
           |  +-------------+--------------+                           |
           |  | TEE / Secure OS            | <--- Signing Key (AK_2)   |
           |  | (Submodule 1)              |      (Optional)           |
           |  +-------------+--------------+                           |
           |                | Measures & Isolates                      |
           |                v                                          |
           |  +-------------+--------------+                           |
           |  | AI Agent Environment       |                           |
           |  |                            |                           |
           |  |  +----------------------+  |                           |
           |  |  | AI Model (Target)    |  |                           |
           |  |  | - Weights Hash       |  |                           |
           |  |  | - Config             |  |                           |
           |  |  +----------------------+  |                           |
           |  +----------------------------+                           |
           +-----------------------------------------------------------+

                     Figure 1: Example of a Chain of Trust

     Figure 1 illustrates the Chain of Trust.  The Hardware Root of Trust
     (RoT) measures the integrity of the Trusted Execution Environment
     (TEE) or OS.  The TEE, acting as a transitive verifier, subsequently
     measures the AI Agent's model binaries and policy configurations.
     The resulting EAT token reflects this hierarchy using nested
     submodules, ensuring that the ai-model-hash is reported by a trusted
     parent rather than the agent itself.

     To clarify the hierarchical trust relationships in multi-owner
     attestation scenarios, Figure 2 illustrates the binding of components
     across hardware, runtime, and AI model layers.  Each layer is
     attested by a distinct owner and represented as a nested submodule
     within the top-level EAT per [RFC 9711, Section 4.2.18].










  MESSOUS                  Expires 27 August 2026                [Page 11]


  Internet-Draft                EAT-AI-Agents                February 2026


     +-----------------------------------------------------------------+
     |  Top-Level EAT (Platform Attester)                              |
     |  • ueid: Platform hardware identity (e.g., TPM/SE)              |
     |  • nonce: Freshness guarantee                                   |
     |  • submods: {                                                   |
     |      "tee-runtime": {  ← Signed by Platform Owner               |
     |          • ueid: TEE instance ID                                |
     |          • swname: "Confidential-VM-v2"                         |
     |          • submods: {                                           |
     |              "ai-agent": {  ← Signed by AI Operator             |
     |                  • swname: "Execution-Agent-v3"                 |
     |                  • ai-model-id: "urn:uuid:..."                  |
     |                  • ai-model-hash: [alg, hash]                   |
     |                  • submods: {                                   |
     |                      "orchestrator": {...},  ← Model Owner A    |
     |                      "vision-model": {...}   ← Model Owner B    |
     |                  }                                              |
     |              }                                                  |
     |          }                                                      |
     |      }                                                          |
     |  }                                                              |
     +-----------------------------------------------------------------+

      Figure 2: Trust hierarchy for layered attestation using EAT submods

  4.3.3.1.  *Trust Binding Semantics*

     *  *Hardware → TEE:* The TEE runtime measurement is included in a
        platform-signed attestation report (e.g., AMD SEV-SNP, Intel TDX).
        The top-level EAT's signature binds the tee-runtime submodule to
        this hardware root.

     *  *TEE → AI Agent:* The AI agent's code and configuration are
        measured into the TEE's launch digest.  The ai-agent submodule is
        signed by the AI operator's key, which itself is endorsed by the
        platform owner (via an Endorsement per [RFC 9334]).

     *  *Agent → Models:* Individual models are signed by their respective
        providers.  The agent's runtime verifies model signatures before
        loading; these signatures are reflected in the nested submods
        entries.










  MESSOUS                  Expires 27 August 2026                [Page 12]


  Internet-Draft                EAT-AI-Agents                February 2026


  4.3.3.2.  *Appraisal Delegation*

     Per [RFC 9334, Section 5.3], a Lead Verifier appraising the top-level
     token: 1- Validates the platform signature against a hardware Trust
     Anchor 2- Delegates tee-runtime appraisal to a TEE-specific verifier
     holding platform Endorsements 3- Delegates ai-agent appraisal to an
     AI policy verifier holding operator Trust Anchors 4- Optionally
     delegates model submodules to specialized model catalog verifiers

     A submodule appraisal failure MUST cause rejection of the entire
     attestation unless policy explicitly permits partial trust (e.g.,
     non-critical auxiliary models).  This failure semantics MUST be
     defined by the deployment policy—not by this profile.

  5.  Security Considerations

     *  Claims SHOULD be bound to a hardware-rooted attestation where
        available.

     *  *ai-model-hash* SHOULD be computed on the serialized model file
        (e.g., ONNX, PyTorch), not in-memory tensors.

     *  *Verifiers* SHOULD validate claims against authoritative
        registries (e.g., model hash in secure model catalog).

     *  *_Replay attacks_* SHOULD be mitigated using EAT nonce (CWT key
        10) or exp (key 4).

     *  Verifiers SHOULD validate the referenced SBOM against known
        vulnerability databases (e.g., NVD) and reject agents using
        components with unpatched critical flaws.

     *  Verifiers SHOULD validate that ai-model-id values originate from
        trusted namespaces (e.g., known domains, approved PENs, or allow-
        listed UUIDs).  Dynamic model deployment does not require central
        registration, but policy enforcement may restrict acceptable
        namespaces.

     *  Verifiers are expected to combine EAT-AI evidence with external
        SBOM/AIBOM analysis for comprehensive risk assessment.

  6.  Privacy Considerations

     *  training-geo-region reveals data origin and SHOULD be minimized.

     *  EAT tokens SHOULD be transmitted over secure channels (e.g., TLS
        1.3).




  MESSOUS                  Expires 27 August 2026                [Page 13]


  Internet-Draft                EAT-AI-Agents                February 2026


     *  owner-id SHOULD use pseudonymous identifiers (e.g., GPSI per 3GPP
        TS 29.222).

     *  Embedded SBOMs or detailed URIs may reveal deployment topology.
        When privacy is a concern, use opaque digests or pseudonymized
        SBOM identifiers.

     *  High-granularity combinations of training-geo-region + dp-epsilon
        + allowed-apis may uniquely identify a "private" model even if the
        ai-model-id is obscured.

  7.  IANA Considerations

  7.1.  EAT Profile Registration

     IANA is requested to register in the "Entity Attestation Token (EAT)
     Profiles" registry: - Profile Name: Autonomous AI Agent EAT Profile -
     Reference: [THIS DOCUMENT]

  7.2.  CWT Claims Registry

     IANA is requested to register the following in the "CBOR Web Token
     (CWT) Claims" registry [IANA-CWT]:




























  MESSOUS                  Expires 27 August 2026                [Page 14]


  Internet-Draft                EAT-AI-Agents                February 2026


     +========+=======================+==================================+
     | Value  | Claim Name            | Description                      |
     +========+=======================+==================================+
     | -75000 | ai-model-id           | AI model URN                     |
     +--------+-----------------------+----------------------------------+
     | -75001 | ai-model-hash         | Model weights hash               |
     +--------+-----------------------+----------------------------------+
     | -75002 | model-arch-digest     | Model graph hash                 |
     +--------+-----------------------+----------------------------------+
     | -75003 | training-data-id      | Training dataset ID              |
     +--------+-----------------------+----------------------------------+
     | -75004 | training-geo-region   | Training data regions            |
     +--------+-----------------------+----------------------------------+
     | -75005 | dp-epsilon            | DP epsilon                       |
     +--------+-----------------------+----------------------------------+
     | -75006 | input-policy-digest   | Inference policy hash            |
     +--------+-----------------------+----------------------------------+
     | -75007 | allowed-slice-types   | Authorized slice                 |
     |        |                       | types                            |
     +--------+-----------------------+----------------------------------+
     | -75008 | data-retention-policy | Data retention policy            |
     +--------+-----------------------+----------------------------------+
     | -75009 | owner-id              | Resource owner                   |
     |        |                       | identifier                       |
     +--------+-----------------------+----------------------------------+
     | -75010 | capabilities          | Agent capabilities               |
     +--------+-----------------------+----------------------------------+
     | -75011 | allowed-apis          | Allowed API endpoints            |
     +--------+-----------------------+----------------------------------+
     | -75012 | ai-sbom-ref           | Reference to AI                  |
     |        |                       | agent’s Software Bill            |
     |        |                       | of Materials (SBOM)              |
     +--------+-----------------------+----------------------------------+

                          Table 3: CWT Claims Registry

     The range -75000 to -75012 is reserved for this profile.

  7.3.  JWT Claims Registry

     IANA is requested to register the corresponding JWT claim names in
     the "JSON Web Token Claims" registry [IANA-JWT].

  8.  References







  MESSOUS                  Expires 27 August 2026                [Page 15]


  Internet-Draft                EAT-AI-Agents                February 2026


  8.1.  Normative:

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

     *  [RFC7519 (https://www.rfc-editor.org/rfc/rfc7519.html)] Jones, M.,
        Bradley, J., and N.  Sakimura, "JSON Web Token (JWT)", RFC 7519,
        DOI 10.17487/RFC7519, May 2015.

     *  [RFC8174 (https://www.ietf.org/rfc/rfc8174.html)] Leiba, B.,
        "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP
        14, RFC 8174, DOI 10.17487/RFC8174, May 2017.

     *  [RFC8392 (https://datatracker.ietf.org/doc/html/rfc8392)] Jones,
        M., et al., "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/
        RFC8392, May 2018.

     *  [RFC9711 (https://datatracker.ietf.org/doc/html/rfc9711)] L.
        Lundblade, G.  Mandyam,J.  O'Donoghue,C.  Wallace, "The Entity
        Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April
        2025.

     *  [RFC9334 (https://datatracker.ietf.org/doc/html/rfc9334)] Birkett,
        M., et al., "Remote ATtestation ProcedureS (RATS) Architecture",
        RFC 9334, DOI 10.17487/RFC9334, January 2023.

     *  [RFC8126 (https://datatracker.ietf.org/doc/html/rfc8126)] Cotton,
        M., et al., "Guidelines for Writing an IANA Considerations
        Section in RFCs", RFC 8126, DOI 10.17487/RFC8126, June 2017.

     *  [[EAT Measured Component] (https://datatracker.ietf.org/doc/draft-
        ietf-rats-eat-measured-component/)] Frost S., et al., "EAT
        Measured Component", Active Internet-Draft (rats WG).

  8.2.  Informative:

     *  [ETSI-GR-ENI-051
        (https://www.etsi.org/deliver/etsi_gr/ENI/001_099/051/04.01.01_60/
        gr_ENI051v040101p.pdf)] ETSI, *"Architectural Framework for ENI in
        6G"*, GR ENI 051 V4.1.1, February 2025.

     *  [3GPP-TR-33.898
        (https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4088)] 3GPP, *"Study on
        security and privacy of Artificial Intelligence/Machine Learning
        (AI/ML)-based services and applications in 5G"*, TR 33.898,
        V18.0.1 July 2023.



  MESSOUS                  Expires 27 August 2026                [Page 16]


  Internet-Draft                EAT-AI-Agents                February 2026


     *  [3GPP-TR-33.784
        (https://portal.3gpp.org/desktopmodules/Specifications/
        SpecificationDetails.aspx?specificationId=4294)] 3GPP, *"Study on
        security aspects of core network enhanced support for Artificial
        Intelligence/Machine Learning (AI/ML)"*, TR 33.784 V0.0.0, April
        2025.

     *  [I-D.huang-rats-agentic-eat-cap-attest
        (https://datatracker.ietf.org/doc/draft-huang-rats-agentic-eat-
        cap-attest/)] Huang, K., et al., *"Capability Attestation
        Extensions for the Entity Attestation Token (EAT) in Agentic AI
        Systems"*, Work in Progress, Internet-Draft, March 2025.

     *  [draft-ni-wimse-ai-agent-identity
        (https://datatracker.ietf.org/doc/draft-ni-wimse-ai-agent-
        identity/)] Yuan, N., Liu, P., *"WIMSE Applicability for AI
        Agents"*, Work in Progress.

     *  [draft-liu-oauth-a2a-profile (https://datatracker.ietf.org/doc/
        draft-liu-oauth-a2a-profile/)] Liu, P., Yuan, N., *"Agent-to-Agent
        (A2A) Profile for OAuth Transaction Tokens"*, Work in Progress.

  9.  Appendix A.  Example EAT-AI Token (CWT)

     The following is a CBOR diagnostic notation of an EAT-AI token:

  {
  / ueid / 256: h'0102030405060708',
  / swname / 270: "execution-agent-v3",
  / ai-model-id / -75000: "urn:etsi:eni:model:slice-opt-cnn:v3",
  / ai-model-hash / -75001: [-44,h'9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f'],
  / training-geo-region / -75004: ["DE", "FR"],
  / dp-epsilon / -75005: 0.5,
  / input-policy-digest / -75006: [-44,h'a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0'],
  / ai-sbom-ref / -75012: "https://sbom.example.net/agents/slice-opt-v3.spdx.json",
  / nonce / 10: h'abcdef1234567890'
  }

  10.  Appendix B.  Relationship to Existing Standards & Initiatives

     This document complements: - IETF RATS
     (https://datatracker.ietf.org/doc/html/rfc9334): Provides the
     architectural context for EAT. - ETSI GR ENI 051
     (https://www.etsi.org/deliver/etsi_gr/ENI/001_099/051/04.01.01_60/
     gr_ENI051v040101p.pdf): Defines the AI-Core where these claims are
     applied.





  MESSOUS                  Expires 27 August 2026                [Page 17]


  Internet-Draft                EAT-AI-Agents                February 2026


     It differs from I-D.huang-rats-agentic-eat-cap-attest
     (https://datatracker.ietf.org/doc/draft-huang-rats-agentic-eat-cap-
     attest/) by specifying measurable, cryptographically verifiable
     claims rather than abstract capabilities.

  Appendix A.  Acknowledgments

     TODO

  Author's Address

     Ayoub MESSOUS
     Huawei R&D
     Email: ayoub.messous@huaweil.com





































  MESSOUS                  Expires 27 August 2026                [Page 18]


