# drafts

name: draft-zhang-dmsc-ioa-semantic-interaction
rev: 01
title: Ontology-based Semantic Interaction for Internet of Agents
time: 2026-02-27T09:19:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-31T09:19:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:06.864884+00:00
abstract:
This document specifies a normative semantic layer for agent-to-agent
   interaction in the Internet of Agents (IoA).  The semantic layer
   provides a common ontology model and a JSON-LD serialization profile
   (RECOMMENDED), while allowing other RDF serializations for expressing
   capabilities, intents, tasks, and context.  The document defines
   required classes and properties, a negotiation procedure, and
   alignment rules for heterogeneous ontologies.  This layer is designed
   to be used by interaction and discovery protocols but does not define
   transport, session, or security protocols.  It enables deterministic
   semantic interoperability across domains.

full_text:
Network Working Group                                           L. Zhang
Internet-Draft                                                   S. Wang
Intended status: Standards Track                                   Y. Li
Expires: 31 August 2026                                          H. Yang
                                      AsiaInfo Technologies (China) Inc.
                                                        27 February 2026


       Ontology-based Semantic Interaction for Internet of Agents
              draft-zhang-dmsc-ioa-semantic-interaction-01

Abstract

   This document specifies a normative semantic layer for agent-to-agent
   interaction in the Internet of Agents (IoA).  The semantic layer
   provides a common ontology model and a JSON-LD serialization profile
   (RECOMMENDED), while allowing other RDF serializations for expressing
   capabilities, intents, tasks, and context.  The document defines
   required classes and properties, a negotiation procedure, and
   alignment rules for heterogeneous ontologies.  This layer is designed
   to be used by interaction and discovery protocols but does not define
   transport, session, or security protocols.  It enables deterministic
   semantic interoperability across domains.

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

Copyright Notice

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






Zhang, et al.            Expires 31 August 2026                 [Page 1]

Internet-Draft        Semantic Interaction for IoA         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.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   4
   4.  Semantic Layer Architecture . . . . . . . . . . . . . . . . .   4
   5.  Ontology Model (Normative)  . . . . . . . . . . . . . . . . .   5
     5.1.  Core Classes  . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  Core Properties . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Profiles and Versions . . . . . . . . . . . . . . . . . .   7
     5.4.  Constraints and Consistency Rules . . . . . . . . . . . .   7
     5.5.  Example Ontology Fragment . . . . . . . . . . . . . . . .   8
   6.  JSON-LD Serialization Profile (Normative) . . . . . . . . . .   9
     6.1.  @context Requirements . . . . . . . . . . . . . . . . . .   9
     6.2.  Message Semantic Envelope . . . . . . . . . . . . . . . .   9
     6.3.  Capability Registration Payload . . . . . . . . . . . . .  10
   7.  Semantic Negotiation and Alignment  . . . . . . . . . . . . .  10
     7.1.  Compatibility Determination . . . . . . . . . . . . . . .  11
     7.2.  Alignment Artifacts . . . . . . . . . . . . . . . . . . .  11
     7.3.  Conflict Resolution Rules . . . . . . . . . . . . . . . .  11
     7.4.  Alignment Algorithm Details . . . . . . . . . . . . . . .  11
   8.  Discovery and Capability Semantics  . . . . . . . . . . . . .  12
   9.  Interaction Semantics . . . . . . . . . . . . . . . . . . . .  12
   10. Mapping to ACPs/ADP/AIP . . . . . . . . . . . . . . . . . . .  12
   11. Example Flow and Examples . . . . . . . . . . . . . . . . . .  13
     11.1.  Cross-Domain Discovery Example . . . . . . . . . . . . .  13
     11.2.  Interaction Example  . . . . . . . . . . . . . . . . . .  14
     11.3.  Consistency Validation Example . . . . . . . . . . . . .  14
     11.4.  Alignment Artifact Example . . . . . . . . . . . . . . .  15
     11.5.  Illustrative NLIP HTTP Encapsulation Example . . . . . .  16
   12. Compliance Requirements . . . . . . . . . . . . . . . . . . .  16
   13. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   15. Normative References  . . . . . . . . . . . . . . . . . . . .  17
   16. Informative References  . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18






Zhang, et al.            Expires 31 August 2026                 [Page 2]

Internet-Draft        Semantic Interaction for IoA         February 2026


1.  Introduction

   The Internet of Agents (IoA) envisions large-scale collaboration
   among heterogeneous agents across domains, vendors, and execution
   environments.  Current agent ecosystems often fail to interoperate
   because capability descriptions, task intents, and context semantics
   are expressed using incompatible vocabularies.  This semantic
   mismatch blocks cross-domain discovery, reliable task decomposition,
   and predictable coordination.

   This document defines an ontology-based semantic layer for agent
   interaction.  The layer provides:

   - A minimal ontology model for capabilities, intents, tasks, and
   context.

   - A JSON-LD serialization profile (RECOMMENDED) for exchange over
   existing interaction protocols, with allowance for other RDF
   serializations.

   - A negotiation and alignment procedure for heterogeneous ontologies.

   The semantic layer complements existing interaction and discovery
   protocols.  It does not define transport, session, or security
   protocols, and it does not mandate a specific discovery system.  It
   provides deterministic semantics that those protocols can carry.

2.  Conventions and Terminology

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

   The following terms are used in this document:

   Internet of Agents (IoA): An ecosystem and architecture enabling
   interoperable collaboration among heterogeneous agents across domains
   and environments.

   Semantic Layer: A logical layer that standardizes meaning
   representation for agent interaction, independent of transport.

   Ontology: A formal vocabulary of concepts and relations that can be
   used to describe capabilities, intents, tasks, and context.

   Semantic Profile: A minimal, structured set of fields used to express
   interaction semantics.



Zhang, et al.            Expires 31 August 2026                 [Page 3]

Internet-Draft        Semantic Interaction for IoA         February 2026


   Capability: A well-defined function or service that an agent can
   provide, described semantically.

   Intent: A goal-oriented statement describing the desired outcome of
   an interaction.

   Task: A unit of work with a lifecycle and status, linked to intent
   and capability.

   Context: Constraints, assumptions, and environmental conditions
   relevant to a task or interaction.

   Alignment: A mapping procedure between ontologies to reconcile
   equivalent or related concepts.

3.  Scope and Non-Goals

   This document specifies:

   - A normative semantic ontology model.

   - A JSON-LD serialization profile (RECOMMENDED) for interaction and
   discovery semantics, with allowance for other RDF serializations.

   - A negotiation procedure for semantic compatibility.

   - Alignment artifacts and conflict resolution rules.

   This document does not specify:

   - Transport, session, or security protocols.

   - A specific discovery or registration protocol.

   - A full ontology library for a specific industry domain.

4.  Semantic Layer Architecture

   The semantic layer sits above interaction protocols and below
   application logic.  It provides a structured meaning representation
   that can be exchanged, validated, and mapped across heterogeneous
   agents.  The semantic layer is protocol-agnostic and can be carried
   by existing agent-to-agent interaction mechanisms.

   The layer enables:

   - Capability alignment across different vocabularies.




Zhang, et al.            Expires 31 August 2026                 [Page 4]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - Intent clarity for task decomposition and coordination.

   - Context sharing for constraints and assumptions.

   For cross-domain deployments, a shared semantic knowledge base (e.g.,
   ontology and concept registries with version history) MAY be used as
   a common reference to improve semantic consistency.

   The semantic layer is illustrated in Figure 1.

           +------------------------------+
           |      Application Logic       |
           +------------------------------+
           |   Semantic Layer (this doc)  |
           +------------------------------+
           |   Interaction Protocols      |
           +------------------------------+
           |   Transport / Security       |
           +------------------------------+

                                  Figure 1

   Figure 1: Semantic Layer Position

   This layer positioning is consistent with the unified layered
   architecture shown in Figure 5 of [MACP-01].

5.  Ontology Model (Normative)

   The ontology model defines the minimal classes and properties that
   MUST be supported for interoperable interaction.  This model is
   RECOMMENDED to be expressed using RDF/OWL concepts [RDF11-CONCEPTS]
   [OWL2-OVERVIEW].

   RDF provides a graph-based, globally identifiable data model that is
   well-suited to cross-domain integration, incremental extension, and
   ontology alignment.  It enables explicit semantics, constraint
   validation, and reasoning using mature tooling, which improves
   interoperability, verifiability, and long-term reuse.

5.1.  Core Classes

   The following classes are REQUIRED:

   - ioa:Agent An entity that can perform tasks and exchange messages.

   - ioa:Capability A function or service an agent can provide.




Zhang, et al.            Expires 31 August 2026                 [Page 5]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - ioa:Intent A goal-oriented description of desired outcome.

   - ioa:Task A unit of work with status and lifecycle.

   - ioa:Context Constraints and environmental conditions.

   - ioa:SemanticProfile A container for semantic references used in
   interaction.

   Optional classes MAY include:

   - ioa:Skill Reusable expertise or competency that refines a
   Capability.

   - ioa:Resource Data, tools, or assets required to perform a Task.

   - ioa:Constraint Policy, rule, or limit that bounds Task execution.

   Optional classes provide domain-specific extensions and are not
   required for baseline interoperability.

5.2.  Core Properties

   The following properties are REQUIRED:

   - ioa:hasCapability (Agent -> Capability) Links an agent to its
   provided capabilities.

   - ioa:hasIntent (Task -> Intent) Associates a task with its intended
   goal.

   - ioa:hasContext (Task -> Context) Binds a task to its contextual
   constraints.

   - ioa:requiresCapability (Task -> Capability) Declares capabilities
   required to fulfill a task.

   - ioa:providedBy (Capability -> Agent) Identifies the agent that
   provides a capability.

   - ioa:hasProfile (Message -> SemanticProfile) Attaches the semantic
   profile to a message.

   - ioa:ontologyId (SemanticProfile -> IRI) Identifier of the ontology
   used for interpretation.

   - ioa:ontologyVersion (SemanticProfile -> literal) Version of the
   referenced ontology.



Zhang, et al.            Expires 31 August 2026                 [Page 6]

Internet-Draft        Semantic Interaction for IoA         February 2026


   The following properties are RECOMMENDED:

   - ioa:profileVersion (SemanticProfile -> literal) Version of the
   semantic profile instance.

   - ioa:alignmentRef (SemanticProfile -> IRI) Reference to alignment
   artifacts used for mapping.

   - ioa:profileContext (SemanticProfile -> Context) Contextual
   constraints used for interpretation.

   These properties link core classes into a minimal graph that enables
   capability discovery, intent interpretation, and semantic alignment.

5.3.  Profiles and Versions

   A SemanticProfile is an instance-level declaration of the ontology
   concepts and context used in a specific interaction.

   A SemanticProfile SHOULD include:

   - ioa:ontologyId Identifier of the ontology used for interpretation.

   - ioa:ontologyVersion Version of the referenced ontology.

   - ioa:capabilityRefs One or more Capability IRIs referenced by this
   interaction.

   - ioa:intentRef The Intent IRI that declares the interaction goal.

   SemanticProfile versioning SHOULD be explicit and SHOULD be
   comparable using a version string or numeric identifier.  Agents
   SHOULD support backwards compatibility within the same major version.

5.4.  Constraints and Consistency Rules

   Ontologies used with this specification SHOULD define constraints
   that enable semantic validation.  Constraints MAY be expressed using
   RDF/OWL axioms or constraint languages such as SHACL.

   At minimum, the following consistency rules are RECOMMENDED:

   - Capability domain/range constraints: ioa:hasCapability MUST relate
   an Agent to a Capability.

   - Intent applicability: ioa:intentRef MUST reference an Intent that
   is compatible with the referenced capabilities.




Zhang, et al.            Expires 31 August 2026                 [Page 7]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - Context consistency: if profileContext.domain is present,
   termBindings MUST resolve to concepts within that domain.

   - Disallowed sense mapping: a termBinding MAY be rejected if the
   sense conflicts with the declared domain.

   Agents SHOULD validate semantic profiles against these rules before
   task execution and reject or renegotiate when violations are
   detected.

5.5.  Example Ontology Fragment

   The following simplified fragments illustrate a base ontology and two
   domain extensions.  Domain ontologies extend the base by importing or
   referencing it.

   Base ontology (ioa core):

      @prefix ioa: <https://ex.org/ioa/semantic#> .

      @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

      ioa:Domain   a rdfs:Class .
      ioa:Concept  a rdfs:Class .
      ioa:inDomain a rdfs:Property .
      ioa:abbr     a rdfs:Property .
      ioa:preferredAbbr a rdfs:Property .
      ioa:profileContext a rdfs:Property .

                                  Figure 2

   Computer-science extension:

      @prefix ioa: <https://ex.org/ioa/semantic#> .
      @prefix cs:  <https://ex.org/onto/cs#> .

      cs:ComputerScience  a ioa:Domain .
      cs:LargeLanguageModel  a ioa:Concept ;
        ioa:inDomain cs:ComputerScience ;
        ioa:abbr "LLM" .

      cs:TechTranslation  a ioa:Capability .
      cs:TranslateTechDoc a ioa:Intent ;
        ioa:requiresCapability cs:TechTranslation ;
        ioa:appliesToDomain cs:ComputerScience .

                                  Figure 3




Zhang, et al.            Expires 31 August 2026                 [Page 8]

Internet-Draft        Semantic Interaction for IoA         February 2026


   Legal-domain extension:

      @prefix ioa: <https://ex.org/ioa/semantic#> .
      @prefix law: <https://ex.org/onto/law#> .

      law:Law  a ioa:Domain .
      law:MasterOfLaws  a ioa:Concept ;
        ioa:inDomain law:Law ;
        ioa:abbr "LLM" ;
        ioa:preferredAbbr "LL.M." .

                                  Figure 4

6.  JSON-LD Serialization Profile (Normative)

   JSON-LD is the RECOMMENDED serialization for semantic payloads
   [JSON-LD].  Other semantically equivalent representations MAY be used
   if they preserve the required fields and deterministic
   interpretation.  Other RDF serializations (Turtle, RDF/XML) MAY be
   supported for offline exchange.

6.1.  @context Requirements

   A JSON-LD payload MUST include a @context that defines ioa: terms and
   any domain-specific extensions.  The base context for this document
   is:

   https://ex.org/ctx

   This base context defines the ioa: prefix as https://ex.org/ioa/
   semantic# and MAY be extended.  Domain extensions MAY be declared
   inline by adding prefixes that map to ontology IRIs, thereby
   inheriting the common ioa: semantics.

6.2.  Message Semantic Envelope

   A semantic envelope is an object that can be embedded in interaction
   messages.  The envelope MUST contain:

   - "@context"

   - "type": "ioa:SemanticProfile"

   - "ontologyId"

   - "ontologyVersion"

   - "capabilityRefs"



Zhang, et al.            Expires 31 August 2026                 [Page 9]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - "intentRef"

   Example:

      {
        "@context": [
          "https://ex.org/ctx",
          { "cs": "https://ex.org/onto/cs#" }
        ],
        "type": "ioa:SemanticProfile",
        "ontologyId": "https://ex.org/onto/agent-core",
        "ontologyVersion": "1.0",
        "capabilityRefs": ["cs:TechTranslation"],
        "intentRef": "cs:TranslateTechDoc",
        "profileContext": {
          "domain": "cs:ComputerScience",
          "termBindings": [
            {
              "term": "LLM",
              "sense": "cs:LargeLanguageModel"
            }
          ]
        }
      }

                                  Figure 5

6.3.  Capability Registration Payload

   Capability registration payloads MUST include ioa:Capability objects
   with identifiers and input/output constraints.  Example:

      {
        "@context": [
          "https://ex.org/ctx",
          { "cs": "https://ex.org/onto/cs#" }
        ],
        "type": "ioa:Capability",
        "id": "cs:TechTranslation",
        "label": "Technical Document Translation",
        "inputs": ["text/plain"],
        "outputs": ["text/plain"]
      }

                                  Figure 6

7.  Semantic Negotiation and Alignment




Zhang, et al.            Expires 31 August 2026                [Page 10]

Internet-Draft        Semantic Interaction for IoA         February 2026


7.1.  Compatibility Determination

   Agents MUST determine semantic compatibility prior to executing a
   task.  Compatibility outcomes are:

   - Direct match: identical ontologyId and compatible versions.

   - Mapped match: alignment artifacts allow translation.

   - No match: reject or fallback.

7.2.  Alignment Artifacts

   Alignment artifacts MUST be represented as mapping tables or graphs.
   The artifact SHOULD include:

   - sourceOntologyId

   - targetOntologyId

   - mappingRules

   - confidence

7.3.  Conflict Resolution Rules

   When multiple mappings are possible, agents SHOULD apply conflict
   resolution rules in this order:

   1.  Local policy priority

   2.  Higher confidence mapping

   3.  Explicit user override

7.4.  Alignment Algorithm Details

   Alignment MAY be performed by combining lexical, structural, and
   behavioral signals.  The following steps are RECOMMENDED:

   - Lexical Matching: compare labels, synonyms, and aliases.

   - Structural Matching: compare parent/child relationships and
   property constraints.

   - Behavioral Matching: compare expected inputs/outputs of
   capabilities and historical success.




Zhang, et al.            Expires 31 August 2026                [Page 11]

Internet-Draft        Semantic Interaction for IoA         February 2026


   The alignment process SHOULD yield a mapping score between 0 and 1.
   Mappings below a local threshold SHOULD be rejected or require
   explicit user confirmation.

8.  Discovery and Capability Semantics

   This semantic layer can be used by discovery systems to match
   capability requirements against registered capabilities.  Agents
   SHOULD advertise capabilities using ioa:Capability objects and
   include semantic profiles in discovery responses.  The discovery
   protocol itself is out of scope; for example interactions see
   [IoA-Task].

9.  Interaction Semantics

   Interaction messages SHOULD carry a semantic envelope.  Agents MUST
   ensure that semantic profiles associated with a task remain stable
   for the lifetime of the task unless renegotiated.  If semantic
   renegotiation occurs, a new profile MUST be recorded with the task.

   An implementation may use natural language or other task content as
   the primary interaction content, while carrying the semantic envelope
   alongside the task-specific input so that intent, capability, and
   context remain explicit to both endpoints.  As discussed in
   [DMSC-NLIP-NOTES], this semantic layer MAY be carried by an NLIP-
   based interaction.  In such cases, the semantic requirements defined
   by this document still apply, while the concrete message encoding and
   transport realization remain outside the scope of this document.

   Semantic compatibility checks, profile updates, and alignment
   renegotiation SHOULD be performed using a control exchange separate
   from ordinary task execution messages.  A control exchange for
   semantic renegotiation SHOULD carry the proposed ontology identifier,
   version, and any candidate alignment artifacts, and a successful
   renegotiation MUST result in a new semantic profile being recorded
   for subsequent task messages.

10.  Mapping to ACPs/ADP/AIP

   This semantic layer is intended to complement the Agent Collaboration
   Protocols (ACPs) architecture [ACPs-ARC] and can be mapped as
   follows:

   - ADP (Agent Discovery Protocol): use SemanticProfile to represent
   capability requirements and results for semantic matching.

   - AIP (Agent Interaction Protocol): attach SemanticProfile to
   interaction messages to make task intent and context explicit.



Zhang, et al.            Expires 31 August 2026                [Page 12]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - Identity/authentication components: no changes required; semantic
   profiles are orthogonal to identity and authentication.

   - NLIP-based realization: carry the semantic envelope as a structured
   payload and use control exchanges for semantic negotiation and
   profile renegotiation.

   The NLIP-based mappings in this section and in Section 11.5 are
   illustrative deployment examples only.  This document defines the
   semantic layer and its payload requirements, but does not normatively
   depend on NLIP or any other transport, session, or security mechanism
   for conformance.

   This mapping allows ACPs deployments to adopt semantic
   interoperability without modifying transport or security components.

   This semantic layer also complements the DMSC infrastructure
   architecture draft [INF-ARCH] by providing semantic descriptions for
   capability directories (Section 6.1), discovery matching
   (Section 6.2), and semantic routing inputs (Section 6.3).  An
   illustrative HTTP encapsulation example for the semantic envelope in
   an NLIP-style realization is shown in Section 11.5.

11.  Example Flow and Examples

11.1.  Cross-Domain Discovery Example

   Agent A (domain X) requests a capability "radiology-report-summary".
   Agent B (domain Y) advertises capability "clinical-note-summarize".
   The domains use different ontologies.  Alignment produces a mapping
   with confidence 0.91, enabling cross-domain discovery.

   Example discovery response (simplified):

      {
        "@context": [
          "https://ex.org/ctx",
          { "clinical": "https://y.org/onto/clinical#" }
        ],
        "type": "ioa:SemanticProfile",
        "ontologyId": "https://y.org/onto/clinical",
        "ontologyVersion": "2.1",
        "capabilityRefs": ["clinical:note-summarize"],
        "intentRef": "clinical:summary-intent",
        "alignmentRef": "https://ex.org/align/X-Y-2026"
      }

                                  Figure 7



Zhang, et al.            Expires 31 August 2026                [Page 13]

Internet-Draft        Semantic Interaction for IoA         February 2026


11.2.  Interaction Example

   Agent A sends a task request with a semantic profile that includes a
   domain context and term binding.  This helps disambiguate
   abbreviations, e.g., "LLM" is bound to "LargeLanguageModel" in
   computer science, not "MasterOfLaws" in legal education.

   Example task request (simplified):

      {
        "header": {
          "task_id": "t-1038",
          "message_type": "task_request"
        },
        "semantic": {
          "@context": [
            "https://ex.org/ctx",
            { "cs": "https://ex.org/onto/cs#" }
          ],
          "type": "ioa:SemanticProfile",
          "ontologyId": "https://ex.org/onto/agent-core",
          "ontologyVersion": "1.0",
          "capabilityRefs": ["cs:TechTranslation"],
          "intentRef": "cs:TranslateTechDoc",
           "profileContext": {
            "domain": "cs:ComputerScience",
            "sourceLang": "zh",
            "targetLang": "en",
            "termBindings": [
              {
                "term": "LLM",
                "sense": "cs:LargeLanguageModel"
              }
            ]
          }
        },
        "payload": {
          "input": "..."
        }
      }

                                  Figure 8

11.3.  Consistency Validation Example

   In this example, the profile declares a computer-science domain but
   binds "LLM" to a legal-education sense.  A validator SHOULD reject or
   request correction based on the consistency rules.



Zhang, et al.            Expires 31 August 2026                [Page 14]

Internet-Draft        Semantic Interaction for IoA         February 2026


   Example validation failure (simplified):

      {
        "semantic": {
          "@context": [
            "https://ex.org/ctx",
            { "cs": "https://ex.org/onto/cs#" },
            { "law": "https://ex.org/onto/law#" }
          ],
          "type": "ioa:SemanticProfile",
          "ontologyId": "https://ex.org/onto/agent-core",
          "ontologyVersion": "1.0",
          "intentRef": "cs:TranslateTechDoc",
          "profileContext": {
            "domain": "cs:ComputerScience",
            "termBindings": [
              {
                "term": "LLM",
                "sense": "law:MasterOfLaws"
              }
            ]
          }
        },
        "validation": {
          "status": "reject",
          "reason": "termBinding sense conflicts with domain"
        }
      }

                                  Figure 9

11.4.  Alignment Artifact Example

      {
        "sourceOntologyId": "https://x.org/onto/rad",
        "targetOntologyId": "https://y.org/onto/clinical",
        "mappingRules": [
          {
            "from": "rad:report-summary",
            "to": "clinical:note-summarize"
          }
        ],
        "confidence": 0.91
      }

                                 Figure 10





Zhang, et al.            Expires 31 August 2026                [Page 15]

Internet-Draft        Semantic Interaction for IoA         February 2026


11.5.  Illustrative NLIP HTTP Encapsulation Example

   This example is non-normative and shows how the semantic envelope can
   be carried in an NLIP-style HTTP exchange without changing the
   semantic requirements in Section 6.2.

      POST /nlip HTTP/1.1
      Host: ex.org
      Content-Type: application/json

      {
        "MessageType": "Request",
        "Format": "text",
        "Subformat": "en",
        "Content": "Translate the attached note into English.",
        "Submessages": [
          {
            "Label": "src-doc",
            "Format": "binary",
            "Subformat": "application/pdf",
            "Content": "<pdf>"
          },
          {
            "Label": "sem-profile",
            "Format": "structured",
            "Subformat": "json",
            "Content": {
               "@context": [
                "https://ex.org/c",
                { "cs": "https://ex.org/cs#" }
              ],
               "type": "ioa:SemanticProfile",
              "ontologyId": "https://ex.org/core",
              "ontologyVersion": "1.0",
              "capabilityRefs": ["cs:TechTrans"],
              "intentRef": "cs:TranslateDoc",
              "alignmentRef": "https://ex.org/a1"
            }
          }
        ]
      }

                                 Figure 11

12.  Compliance Requirements

   An implementation compliant with this specification MUST:




Zhang, et al.            Expires 31 August 2026                [Page 16]

Internet-Draft        Semantic Interaction for IoA         February 2026


   - Support the core classes and properties in Section 5.

   - Produce and parse semantic envelopes as specified in Section 6;
   JSON-LD support is RECOMMENDED.

   - Perform semantic negotiation prior to task execution (Section 7).

   An implementation MAY support extended domain ontologies.

13.  Security Considerations

   Semantic profiles may reveal sensitive capability and context
   information.  Implementations SHOULD consider:

   - Minimizing semantic disclosure (least-information profiles).

   - Integrity protection of semantic profiles and alignment artifacts.

   - Access control on ontology registries and mapping services.

   - Policy-based filtering of sensitive capabilities in discovery.

   If a shared semantic knowledge base is used, implementers SHOULD
   consider provenance, version control, and trust policies to prevent
   poisoning or unauthorized changes.

   Alignment artifacts can be a target for poisoning or downgrade
   attacks.  Implementations SHOULD validate alignment sources and
   require provenance for mappings used in critical tasks.

14.  IANA Considerations

   This document makes no request for IANA action.

15.  Normative References

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

16.  Informative References






Zhang, et al.            Expires 31 August 2026                [Page 17]

Internet-Draft        Semantic Interaction for IoA         February 2026


   [ACPs-ARC] Liu, J., Yu, K., Li, K., and K. Chen, "Agent Collaboration
              Protocols Architecture for Internet of Agents", Work in
              Progress, Internet-Draft, draft-liu-dmsc-acps-arc-03,
              2026, <https://datatracker.ietf.org/doc/draft-liu-dmsc-
              acps-arc/03/>.

   [DMSC-NLIP-NOTES]
              Verma, D., Bertino, E., Ratnaparkhi, A., and S. Hughes,
              "Use of Natural Language for Agent Communication", Work in
              Progress, Internet-Draft, draft-verma-dmsc-nlip-notes-00,
              2026, <https://datatracker.ietf.org/doc/draft-verma-dmsc-
              nlip-notes/00/>.

   [INF-ARCH] Li, X. and A. Wang, "Dynamic Multi-agent Secured
              Collaboration Infrastructure Architecture", Work in
              Progress, Internet-Draft, draft-li-dmsc-inf-architecture-
              03, 2026, <https://datatracker.ietf.org/doc/draft-li-dmsc-
              inf-architecture/03/>.

   [IoA-Task] Yang, C., "Internet of Agents Task Protocol", Work in
              Progress, Internet-Draft, draft-yang-dmsc-ioa-task-
              protocol-02, 2026, <https://datatracker.ietf.org/doc/
              draft-yang-dmsc-ioa-task-protocol/02/>.

   [JSON-LD]  W3C, "JSON-LD 1.1", 2020,
              <https://www.w3.org/TR/json-ld11/>.

   [MACP-01]  Li, X., Liu, J., Du, C., and L. Zhang, "Multi-Agent
              Collaboration Protocol for Internet of Agents", Work in
              Progress, Internet-Draft, draft-li-dmsc-macp-01, 2026,
              <https://datatracker.ietf.org/doc/draft-li-dmsc-macp/01/>.

   [OWL2-OVERVIEW]
              W3C, "OWL 2 Web Ontology Language Overview", 2012,
              <https://www.w3.org/TR/owl2-overview/>.

   [RDF11-CONCEPTS]
              W3C, "RDF 1.1 Concepts and Abstract Syntax", 2014,
              <https://www.w3.org/TR/rdf11-concepts/>.

Authors' Addresses

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



Zhang, et al.            Expires 31 August 2026                [Page 18]

Internet-Draft        Semantic Interaction for IoA         February 2026


   Shoufeng Wang
   AsiaInfo Technologies (China) Inc.
   Beijing
   100000
   China
   Email: wangsf11@asiainfo.com


   Yun Li
   AsiaInfo Technologies (China) Inc.
   Beijing
   100000
   China
   Email: liyun9@asiainfo.com


   Huiling Yang
   AsiaInfo Technologies (China) Inc.
   Beijing
   100000
   China
   Email: yanghl10@asiainfo.com





























Zhang, et al.            Expires 31 August 2026                [Page 19]


name: draft-sun-zhang-iaip
rev: 00
title: Intent-based Agent Interconnection Protocol at Agent Gateway
time: 2026-02-05T14:26:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-09T14:26:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:06.864886+00:00
abstract:
This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

full_text:
DMSC Working Group                                                S. Sun
Internet-Draft                                                  ICT, CAS
Intended status: Standards Track                                X. Zhang
Expires: 9 August 2026                                         CNIC, CAS
                                                           February 2026


      Intent-based Agent Interconnection Protocol at Agent Gateway
                        draft-sun-zhang-iaip-00

Abstract

   This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

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.






Sun & Zhang               Expires 9 August 2026                 [Page 1]

Internet-Draft                    IAIP                     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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Problem Statement and Use Cases . . . . . . . . . . . . . . .   4
     4.1.  Limitations of Address-Based Static Interconnection . . .   4
     4.2.  Representative Use Case . . . . . . . . . . . . . . . . .   5
   5.  Function Components . . . . . . . . . . . . . . . . . . . . .   6
   6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Protocol Operation and Core Procedures  . . . . . . . . . . .  12
     8.1.  Illustrative Protocol Examples  . . . . . . . . . . . . .  12
       8.1.1.  Example A: Agent Registration (CAP_ADV) . . . . . . .  12
       8.1.2.  Example B: Intent Resolution Flow . . . . . . . . . .  12
       8.1.3.  Example C: Routing Feedback . . . . . . . . . . . . .  13
     8.2.  Agent Access Component (AAC) Operations . . . . . . . . .  13
       8.2.1.  Session Authentication and Integrity  . . . . . . . .  13
       8.2.2.  Ingress Validation  . . . . . . . . . . . . . . . . .  13
     8.3.  Local Capability Registry (LCR) Management  . . . . . . .  14
       8.3.1.  Profile Creation and Updates  . . . . . . . . . . . .  14
       8.3.2.  Lifecycle Maintenance . . . . . . . . . . . . . . . .  14
     8.4.  Intent Forwarding Routing Table (IFR) Decision Logic  . .  14
       8.4.1.  Candidate Retrieval . . . . . . . . . . . . . . . . .  14
       8.4.2.  Constraint-Based Filtering  . . . . . . . . . . . . .  14
       8.4.3.  Semantic Evaluation and Ranking . . . . . . . . . . .  15
       8.4.4.  Selection and Fallback  . . . . . . . . . . . . . . .  15
     8.5.  Forwarding and Loop Prevention  . . . . . . . . . . . . .  15
     8.6.  Reliability and Error Handling  . . . . . . . . . . . . .  15
     8.7.  Protocol Processing procedure at Agent Gateways . . . . .  15
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18







Sun & Zhang               Expires 9 August 2026                 [Page 2]

Internet-Draft                    IAIP                     February 2026


1.  Introduction

   The emergence of agentic networks marks a fundamental shift from
   static, address-based networking to semantic, intent-driven
   interactions.  Autonomous agents powered by advanced artificial
   intelligence models are capable of reasoning, planning, and executing
   tasks on behalf of users or other agents.  Interactions are
   increasingly expressed in terms of high-level objectives or natural
   language intents, rather than predefined service endpoints or static
   interfaces.

   Traditional networking and service discovery mechanisms assume that
   communication targets are identified by fixed addresses, names, or
   service identifiers.  These assumptions no longer hold in agentic
   environments, where the appropriate execution entity for a request
   may depend on semantic interpretation, contextual constraints, and
   dynamic system conditions.  As a result, routing decisions based
   solely on static addressing or preconfigured bindings are
   insufficient to support flexible and scalable agent collaboration.

   Intent-based interconnection addresses this gap by enabling the Agent
   Gateway to resolve and forward requests according to their semantic
   intent, rather than their destination address.  By decoupling request
   dispatch from rigid topology and static identifiers, intent-based
   interconnection allows autonomous agents to be dynamically
   discovered, selected, and invoked based on their advertised
   capabilities.

   This document introduces the Intent-based Agent Interconnection
   Protocol (IAIP) to provide a standardized mechanism for capability-
   based registration and validation, intent-aware discovery and routing
   at AG.  IAIP is designed to operate as an application-layer protocol
   for interconnection service domain, complementing existing transport
   and networking infrastructure without requiring changes to underlying
   transport protocols.

2.  Conventions

   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 <xref
   target="RFC2119"/>.

3.  Terminology

   AI Agent  An agent is a software or hardware entity with autonomous





Sun & Zhang               Expires 9 August 2026                 [Page 3]

Internet-Draft                    IAIP                     February 2026


      decision-making and execution capabilities, capable of perceiving
      the environment, acquiring contextual information, reasoning, and
      learning.

   Agent Gateway (AG)  A Functional Component in the Interconnection
      Service Domain that possesses the capbilities of agent
      registration, capbility authentication, intent resolution and
      estabilishing interconnection betweens agents.

   Intent  A declarative expression of a desired outcome.  In the
      intent-driven routing protocol, intent is represented at three
      conceptual layers:

      *  *Human Intent:*A high-level, possibly ambiguous expression
         originating from a human user or application (e.g., natural
         language input).  Human Intent is out of scope for the
         protocol.

      *  *Task Intent:*An abstract, task-oriented description that
         captures the objective of a request, independent of any
         specific agent, algorithm, or execution plan.

      *  *Intent Descriptor:*A structured, machine-interpretable
         representation of Task Intent used within IAIP for routing and
         dispatching decisions.

   Leader Agent (LA)  Agent who issues tasks and launches interactions.
      There should only be one Leader Agent in a complete task execution
      process.

   Partner Agent (PA)  Agent who accepts tasks and provides services.
      After Partner Agent receives a task from the Leader Agent, it
      executes and returns the execution result.

4.  Problem Statement and Use Cases

4.1.  Limitations of Address-Based Static Interconnection

   Existing network interconnection and gateway mechanisms are
   predominantly organized around static identifiers, such as network
   addresses, domain names, or service labels.  At the application and
   service-dispatch layer, these mechanisms assume that the
   functionality associated with a agent behind a gateway is stable,
   explicitly addressable and functionally static.  While effective for
   traditional client-server and microservice architectures, this
   assumption becomes increasingly inadequate for the dynamic
   interconnection required by agentic networks.




Sun & Zhang               Expires 9 August 2026                 [Page 4]

Internet-Draft                    IAIP                     February 2026


   First, traditional interconnection protocols provide limited support
   for expressing semantic intent.  High-level requests such as "analyze
   this dataset" or "resolve a billing issue" do not naturally
   correspond to a single predefined endpoint.  Encoding semantic
   meaning into static addresses or service names requires manual
   configuration and tight coupling between task requesters and service
   providers, which undermines flexibility and scalability.

   Second, static interconnection lacks adaptability to dynamic
   lifecycle of AI Agents.  In the Agent Domain, agents may be
   instantiated, fine-tuned, or deprecated rapidly based on
   computational load or task requirements.  Static bindings or name-
   based resolution mechanisms are generally unable to reflect real-time
   changes in agent's availability or intent-processing capacity,
   leading to service selection or routing dispatch failures.

   Third, existing protocols offer limited support for intent-aware
   resolution.  When a request arrives at the gateway without a specific
   destination address, traditional gateway have no mechanism to parse
   the intent and match it against a local registry of vector-based
   capabilities.  This behavior is misaligned with agentic workflows,
   where ambiguous or underspecified intents are common and may require
   clarification, delegation, or escalation to more generalist agents.

   These limitations motivate the need for an intent-driven
   interconnection protocol specifically at the Agent Gateway that can
   manage registration and routing based on semantic intent and
   dynamically advertised capabilities, rather than relying solely on
   fixed addresses or static identifiers.  This protocol addresses these
   challenges by transforming the gateway from a static packet forwarder
   into a semantic ingress/egress point, enabling establishing agent
   interconnection while maintaining compatibility with the
   Interconnection Service Domain.

4.2.  Representative Use Case

   The following example illustrates a typical use case of the Intent-
   based Agent Interconnection Protocol operating at the Agent Gateway.

   A Customer Service Dispatcher Agent, acting as the Leader Agent,
   transmits a user inquiry to the AG for intent resolution and service
   response.  Specialized Partner Agents (Billing, Technical Support,
   Sales) have previously registered their specific semantic domains
   with the AG.  For explicit queries like "My credit card was charged
   twice," the AG identifies a high-confidence semantic match and routes
   the request to the Billing Agent.  Upon completion, the AG relays the
   result back to the Leader Agent.  Conversely, when handling ambiguous
   inputs (e.g., "I'm having a bad experience") where semantic



Sun & Zhang               Expires 9 August 2026                 [Page 5]

Internet-Draft                    IAIP                     February 2026


   similarity scores fail to meet the required confidence threshold, the
   AG encapsulates the intent and forwards the intent to a Generalist
   Fallback Agent.  This mechanism ensures the request is constructively
   resolved via clarifying questions or human escalation, thereby
   preventing service failure.

5.  Function Components

   Figure 1 illustrates the interaction diagram between AI agent and
   Agent Gateway.

  [Agent Domain]                [Interconnection Service Domain]
     +-----------+      IAIP       +---------------+
     |  AI Agent | <-------------> | Agent Gateway | <---> [Core Router]
     +-----------+                 +---------------+

     Figure 1: Interaction Diagram between AI Agent and Agent Gateway

   To support the interaction with AI Agents, the AG MUST implement the
   following specific Functional Components within the Interconnection
   Service Domain.

   *  *Local Capability Registry (LCR):*The LCR maintains a dynamic
      database of attached Agents.  The function of LCR is to store the
      Capability Profile of each registered agent.  When an Agent sends
      the capability updating request, the LCR updates the mapping.

   *  *Agent Access Component (AAC):*The AAC serves as the termination
      point for the interconnection session between the AI Agent and the
      Agent Gateway.  The function of AAC is to manage authentication,
      maintain session lifecycle, and verify message integrity.  When an
      AI Agent initiates a connection or transmits a message, the AAC
      validates the agent's identity credentials and establishes the
      interconnection for message forwarding.

   *  *Intent Forwarding Routing Table (IFR):*The IFR serves as the
      dynamic routing decision engine within the Agent Gateway for
      forwarding intent-based requests.  Its primary function is to map
      normalized intent vectors-derived from incoming task semantics-to
      a set of eligible Partner agents.  Based on real-time capability
      matching scores, performance metrics (e.g., latency, success rate,
      and resource availability), and policy constraints, the IFR
      selects the optimal next-hop Partner agent for request forwarding.

6.  Protocol Overview

   The protocol functions in two primary phases.




Sun & Zhang               Expires 9 August 2026                 [Page 6]

Internet-Draft                    IAIP                     February 2026


   *  *Phase 1: Agent Registration & Capability Advertisement.*This
      phase establishes the trust domain and service mesh.  Both Leader
      Agents and Partner Agents MUST complete Identity Registration with
      the Agent Gateway (AG) to obtain the verifiable Agent Identity
      Code (AIC).  Following identity registration, Partner Agents (or
      agents acting in a service-provisioning role) MUST additionally
      perform Capability Advertisement to publish their functional
      profiles to the Local Capability Registry (LCR).

   *  *Phase 2: Intent-based Routing and Forwarding.*This phase
      establishes intent-based interconnection.  The Leader Agent
      submits its intent.  The AG resolves it against the LCR and IFR,
      selects suitable Partner Agents, and facilitates the connection.

   Figure 2 illustrates the updated two-stage processing pipeline
   between AI Agents and AG.



































Sun & Zhang               Expires 9 August 2026                 [Page 7]

Internet-Draft                    IAIP                     February 2026


   +--------------+ +------------------------+ +--------------+
   | Leader Agent | |     Agent Gateway      | | Partner Agent|
   |(Intent Init.)| |(Network Infrastructure)| |(Intent Exec.)|
   +------+-------+ +------------+-----------+ +------+-------+
          |                      |                      |
          | Phase 1: Identity Reg & Capability Advt.    |
          |                      |                      |
          |--(1) Identity Reg -->|                      |
          |   [ACP-IF-01]        |                      |
          |                      |<--(2) Identity Reg --|
          |                      |    [ACP-IF-01]       |
          |                      |                      |
          |                      |<--(3) Publish Cap ---|
          |                      |    [ACP-IF-06]       |
          |                      |                      |
          |                      |-->(4) Sync & Trust --|
          |                      |    [ADF / DTMgF]     |
          |                      |                      |
          | Phase 2: Intent-based Routing               |
          |                      |                      |
          |--(5) Submit Intent ->|                      |
          |   [Signed Vector]    |                      |
          |                      |                      |
          |                      |-->(6) Resolve Intent-|
          |                      |     Match ADF DB     |
          |                      |     DTMgF Filter     |
          |                      |                      |
          |                      |<--(7) Cand. List ----|
          |                      |   [Ranked + Sig]     |
          |<--(8) Verify & Select|                      |
          |                      |                      |
          |=========(9) Routing and Execution =========>|
          |        [E2E via ACP-IF-08/09]               |
          |=============================================|

                Figure 2: Two-Stage Processing Flow of IAIP

   *Phase 1: Agent Registration & Capability Advertisement*

   This stage is the prerequisite for any agent participation.  It
   involves Identity Registration (mandatory for all) and Capability
   Publication (mandatory for service providers).  The steps are as
   follows:

   *  *Step1:*Identity Registration (Leader & Partner).  Any Agent
      (whether Leader or Partner) MUST register its identity with the
      Agent Gateway using the ACP-IF-01 interface (between AIMF in the
      agent and AIMgF in the AG).  This establishes a verifiable Agent



Sun & Zhang               Expires 9 August 2026                 [Page 8]

Internet-Draft                    IAIP                     February 2026


      Identity Code (AIC) and exchanges cryptographic credentials
      required for future intent signing (Leader) or service execution
      (Partner).

   *  *Step2:*Capability Publication (Partner Agent).  The Partner Agent
      publishes a structured capability description (e.g., supported
      task types, performance bounds, resource constraints) to the Agent
      Gateway via the ACP-IF-06 interface (ADMF <-> ADMgF).  Note: If a
      Leader Agent also wishes to serve tasks, it MUST also perform this
      step.

   *  *Step3:*Synchronization to Interconnection Service Domain.  The
      Agent Gateway forwards the capability description to the Agent
      Description Management Function (ADMgF) in the Interconnection
      Service Domain.  ADMgF persists the data and synchronizes it to
      the Agent Discovery Function (ADF) for indexing.

   *  *Step4:*Trust Scope Enforcement.  The Domain Trust Management
      Function (DTMgF) applies domain federation policies to determine
      whether the registered Agent is authorized to operate within the
      specific trust domain.  Only authorized capabilities are made
      queryable via ADF.

   *Phase 2: Intent-based Routing and Forwarding*

   This stage is triggered when a registered Leader Agent submits a
   semantic intent request.  The Agent Gateway resolves and routes the
   intent to eligible Partner Agents.  The steps are as follows:

   *  *Step5:*Intent Submission.  The Leader Agent sends a signed
      semantic intent vector to the Agent Gateway.  The signature MUST
      be generated using the credentials established in Step 1.  The
      payload contains abstract task semantics.

   *  *Step6:*Intent Resolution and Candidate Matching.  The Agent
      Gateway invokes the ACP-IF-07 interface to query the ADF.  The IFR
      (Intent Forwarding Routing Table) performs semantic matching
      against the LCR, filtering based on trust scopes, and ranking
      candidates.

   *  *Step7:*Candidate Agents Return.  The Gateway returns a ranked
      list of eligible Partner Agents to the Leader Agent.

   *  *Step8:*Leader-side Verification and Selection.  The Leader Agent
      verifies the gateway's signature and selects one or more Partners
      based on local policy.





Sun & Zhang               Expires 9 August 2026                 [Page 9]

Internet-Draft                    IAIP                     February 2026


   *  *Step9:*Routing and Execution.  The Leader Agent establishes a
      direct end-to-end session with the selected Partner Agent(s) using
      ACP-IF-08 for point-to-point interaction, or ACP-IF-09 for
      grouping-mode collaboration.  All task payloads are transmitted
      over this encrypted channel.

7.  Message Formats

   This section specifies the binary structure of IAIP messages.  The
   protocol uses a Type-Length-Value (TLV) design to ensure
   extensibility.

  +--------------------------------------------------------------------+
  |                      IAIP Message (TLV-based)                      |
  +--------------------------------------------------------------------+
  |                                                                    |
  |  +-------------------+------+-----------------------------------+  |
  |  | Type              | Len  | Value                             |  |
  |  +-------------------+------+-----------------------------------+  |
  |  | Common Header TLVs                                           |  |
  |  +-------------------+------+-----------------------------------+  |
  |  | VERSION           | 1    | Protocol version                  |  |
  |  | MSG_TYPE          | 1    | INTENT_REQ / CAP_ADV / ERROR      |  |
  |  | MSG_ID            | var  | Unique message identifier         |  |
  |  | SENDER_ID         | var  | Source agent / router ID          |  |
  |  | RECEIVER_ID       | var  | Target agent / router ID          |  |
  |  | TIMESTAMP         | 8    | Unix time / logical time          |  |
  |  | TTL / EXPIRY      | 4    | Validity / hop limit              |  |
  |  | CORRELATION_ID    | var  | Request-response correlation      |  |
  |  | INTEGRITY_TAG     | var  | MAC / signature                   |  |
  |  +-------------------+------+-----------------------------------+  |
  |                                                                    |
  |  +-------------------+------+-----------------------------------+  |
  |  | Payload TLVs (depend on MSG_TYPE)                            |  |
  |  +-------------------+------+-----------------------------------+  |
  |                                                                    |
  |  -- CAPABILITY ADVERTISEMENT (CAP_ADV) --------------------------  |
  |  | AGENT_ID          | var  | Advertising agent identifier      |  |
  |  | ENDPOINT          | var  | Network / logical endpoint        |  |
  |  | FUNC_DESC         | var  | Functional descriptors            |  |
  |  | INTENT_DOMAINS    | var  | Supported intent types            |  |
  |  | IO_SCHEMA         | var  | Input/output constraints          |  |
  |  | PERF_METRICS      | var  | Latency, success rate, etc.       |  |
  |  | RESOURCE_LIMITS   | var  | Token / compute budget            |  |
  |                                                                    |
  |  -- CAPABILITY REFRESH (CAP_REFRESH) ----------------------------  |
  |  | AGENT_ID          | var  | Agent identifier                  |  |
  |  | TTL_UPDATE        | 4    | Extended lifetime                 |  |



Sun & Zhang               Expires 9 August 2026                [Page 10]

Internet-Draft                    IAIP                     February 2026


  |  | METRIC_DELTA      | var  | Updated performance metrics       |  |
  |                                                                    |
  |  -- CAPABILITY DEREGISTER (CAP_DEREGISTER) ----------------------  |
  |  | AGENT_ID          | var  | Agent identifier                  |  |
  |  | REASON_CODE       | 2    | Deregistration reason             |  |
  |  | EFFECTIVE_TIME    | 8    | Time of effect                    |  |
  |                                                                    |
  |  -- INTENT REQUEST (INTENT_REQ) ---------------------------------  |
  |  | OBJECTIVE         | var  | Task objective                    |  |
  |  | CONSTRAINTS       | var  | Preferences / limits              |  |
  |  | CONTEXT           | var  | Context metadata                  |  |
  |  | PRIORITY          | 1    | Request priority                  |  |
  |  | BUDGET            | var  | Cost / token budget               |  |
  |  | PRIVACY_FLAG      | 1    | Intent privacy level              |  |
  |  | OBFUSCATED_INTENT | var  | Encrypted / masked intent         |  |
  |                                                                    |
  |  -- ROUTE DECISION / INTENT RESPONSE ----------------------------  |
  |  | TARGET_AGENT_LIST | var  | Selected target agent(s)          |  |
  |  | MATCH_CONFIDENCE  | var  | Similarity / rank score           |  |
  |  | FORWARDING_INFO   | var  | Next-hop / endpoint               |  |
  |  | FALLBACK_INDIC.   | 1    | Fallback used?                    |  |
  |                                                                    |
  |  -- ROUTING FEEDBACK --------------------------------------------  |
  |  | OUTCOME           | 1    | Success / failure                 |  |
  |  | OBSERVED_LATENCY  | var  | Execution latency                 |  |
  |  | OBSERVED_COST     | var  | Resource usage                    |  |
  |  | ERROR_INFO        | var  | Error details                     |  |
  |                                                                    |
  |  -- ERROR MESSAGE -----------------------------------------------  |
  |  | ERROR_CODE        | 2    | Error identifier                  |  |
  |  | DIAGNOSTIC        | var  | Human-readable info               |  |
  |  | RETRY_AFTER       | 4    | Backoff hint                      |  |
  |                                                                    |
  |  -- SECURITY EXTENSION (SECURITY_EXT) ---------------------------  |
  |  | AUTHN_INFO        | var  | Certificate / token ref           |  |
  |  | AUTHZ_SCOPE       | var  | Authorization scope               |  |
  |  | NONCE             | var  | Anti-replay                       |  |
  |  | SIGNATURE / MAC   | var  | Integrity protection              |  |
  |  | ENCRYPTION_CTX    | var  | Intent confidentiality ctx        |  |
  |                                                                    |
  +--------------------------------------------------------------------+

                      Figure 3: IAIP message format

   The table above summarizes the field requirements.  Key fields
   include:

   *MSG_TYPE*  Identifies the payload type (e.g., 0x01: CAP_ADV, 0x02:



Sun & Zhang               Expires 9 August 2026                [Page 11]

Internet-Draft                    IAIP                     February 2026


      INTENT_REQ).

   *TTL / EXPIRY*  Time-To-Live logic depending on message type.  For
      routing messages (INTENT_REQ), this represents the hop limit.  For
      registration messages, this represents the validity duration in
      seconds.

   *OBJECTIVE (in INTENT_REQ)*  The semantic vector or structured
      description of the task.

   *RESOURCE_LIMITS (in CAP_ADV)*  Specifies operational constraints,
      including token budget per request and computational cost.

   *FALLBACK_INDIC. (in RESPONSE)*  Flag indicating if a generalist
      fallback agent was used (0x01) or a direct match was found (0x00).

8.  Protocol Operation and Core Procedures

   This section specifies the normative processing behavior of the Agent
   Gateway (AG), organized by the functional components defined in
   Section 5.  The Agent Access Component (AAC) handles ingress
   connectivity and security; the Local Capability Registry (LCR)
   manages state; and the Intent Forwarding Routing Table (IFR) executes
   decision logic.

8.1.  Illustrative Protocol Examples

   The examples in this section are provided for illustration only and
   are non-normative.

8.1.1.  Example A: Agent Registration (CAP_ADV)

   A Partner Agent registers its translation service with cost
   constraints.

[Common Header] MSG_TYPE =
          CAP_ADV SENDER_ID = "agent-trans-01", TTL/EXPIRY = 3600 [Payload],
          FUNC_DESC = "service:translation; lang:en-to-zh", RESOURCE_LIMITS =
          "max_tokens=2048", SECURITY_EXT = "(signature bytes...)"

8.1.2.  Example B: Intent Resolution Flow

   *Step 1: Leader Agent sends Intent Request*

[Common Header] MSG_TYPE =
          INTENT_REQ SENDER_ID = "leader-agent-007", MSG_ID = "req-1024"
          [Payload], OBJECTIVE = "(vector: [0.12, 0.95, ...])", BUDGET =
          "100"



Sun & Zhang               Expires 9 August 2026                [Page 12]

Internet-Draft                    IAIP                     February 2026


   *Step 2: Gateway returns Candidate List (Response)*
   The AG finds two matching agents.  The first one is a direct match,
   so Fallback Indicator is 0.

[Common Header] MSG_TYPE =
          RESPONSE RECEIVER_ID = "leader-agent-007", CORRELATION_ID =
          "req-1024" [Payload], TARGET_AGENT_LIST = [1] "agent-trans-01"
          (Conf: 0.92, Endpoint: "10.0.1.5:8080"), [2] "agent-trans-03" (Conf:
          0.85, Endpoint: "10.0.1.8:8080"), FALLBACK_INDIC. = 0x00 (No
          Fallback)

8.1.3.  Example C: Routing Feedback

   After execution, the Leader Agent reports performance metrics back to
   the AG to update the LCR's dynamic scores.

[Common Header] MSG_TYPE =
          ROUTING_FEEDBACK SENDER_ID = "leader-agent-007" [Payload], OUTCOME =
          1 (Success), OBSERVED_LATENCY = 250 (ms), OBSERVED_COST = 50
          (tokens)

8.2.  Agent Access Component (AAC) Operations

   The AAC serves as the termination point for the interconnection
   session.  It MUST intercept all incoming IAIP messages before they
   reach the LCR or IFR.

8.2.1.  Session Authentication and Integrity

   Upon receiving any message, the AAC MUST perform the following
   validations:

   *  *Identity Verification:* Validate the SENDER_ID against the
      credentials provided in the AUTHN_INFO TLV or the underlying
      transport session (e.g., mTLS).
   *  *Message Integrity:* Verify the INTEGRITY_TAG or SIGNATURE.  If
      verification fails, the AAC MUST drop the message and return an
      ERROR with code AUTH_FAILED.

8.2.2.  Ingress Validation

   The AAC acts as the first line of defense.  It MUST validate the
   syntax of Common Header fields (e.g., VERSION, MSG_TYPE).  Malformed
   packets MUST be rejected immediately to protect the internal IFR
   engine.






Sun & Zhang               Expires 9 August 2026                [Page 13]

Internet-Draft                    IAIP                     February 2026


8.3.  Local Capability Registry (LCR) Management

   The LCR maintains the dynamic database of attached Agents.  It
   processes capability management messages validated by the AAC.

8.3.1.  Profile Creation and Updates

   When the AAC forwards a CAP_ADV message, the LCR MUST:

   1.  Extract the AGENT_ID and map it to the provided ENDPOINT.

   2.  Store the FUNC_DESC, INTENT_DOMAINS, and RESOURCE_LIMITS as the
       agent's Capability Profile.

   3.  Set the entry's expiration time to Current_Time + TTL.

8.3.2.  Lifecycle Maintenance

   Upon receiving a CAP_REFRESH, the LCR MUST look up the existing
   profile and extend its validity by TTL_UPDATE.

   The LCR MUST periodically purge entries that have exceeded their
   expiry time without refresh (STALE state) to ensure the IFR does not
   route to dead agents.

8.4.  Intent Forwarding Routing Table (IFR) Decision Logic

   The Intent Forwarding Routing Table (IFR) functions as the dynamic
   routing engine of the Agent Gateway.  After an INTENT_REQ
   successfully passes AAC validation, the IFR MUST evaluate the request
   and produce a ranked TARGET_AGENT_LIST containing one or more
   eligible Partner Agents.

8.4.1.  Candidate Retrieval

   The IFR MUST interpret the OBJECTIVE TLV as an intent descriptor and
   query the Local Capability Registry (LCR) to obtain the current set
   of active Capability Profiles.

8.4.2.  Constraint-Based Filtering

   The IFR MUST apply mandatory constraints to reduce the candidate set
   prior to semantic evaluation.  When a request includes constraint
   fields such as BUDGET, the IFR MUST compare these constraints against
   the corresponding attributes in the Capability Profiles (e.g.,
   RESOURCE_LIMITS) and exclude agents that do not satisfy the required
   conditions.




Sun & Zhang               Expires 9 August 2026                [Page 14]

Internet-Draft                    IAIP                     February 2026


   Additional policy-based constraints MAY be applied according to local
   administrative policy.

8.4.3.  Semantic Evaluation and Ranking

   For the remaining candidates, the IFR MUST perform semantic matching
   between the request intent and the advertised capabilities.  The
   specific matching method is implementation-dependent; however, the
   IFR MUST compute a relative confidence score that reflects the degree
   of intent-capability alignment.

   The IFR MAY incorporate additional operational signals, such as
   historical performance metrics (e.g., latency or success rate), when
   deriving the final ranking.

   The IFR MUST preserve the relative ordering of candidates when
   constructing the TARGET_AGENT_LIST.

8.4.4.  Selection and Fallback

   The IFR SHOULD select the highest-ranked candidates for inclusion in
   the response, subject to local policy.

   If no candidate satisfies the acceptance criteria (e.g., minimum
   confidence threshold), the IFR SHOULD invoke the Fallback Mechanism.
   When fallback is applied, the Agent Gateway MUST set FALLBACK_INDIC
   to 0x01.

8.5.  Forwarding and Loop Prevention

   For multi-hop scenarios, the AG enforces loop prevention using the
   TTL field in the Common Header.  If TTL <= 1, the request is dropped.
   Duplicate MSG_ID, are suppressed to prevent broadcast storms.

8.6.  Reliability and Error Handling

   Errors detected by any component (AAC auth failure, LCR parsing
   error, IFR no-route) MUST result in an ERROR message returned to the
   sender, containing the appropriate ERROR_CODE.

8.7.  Protocol Processing procedure at Agent Gateways

   Figure 3 illustrates the protocol processing pipeline within the
   Agent Gateway (AG).  The protocol operation relies on the
   coordination between three normative functional components: the Agent
   Access Component (AAC), the Local Capability Registry (LCR), and the
   Intent Forwarding Routing Table (IFR).




Sun & Zhang               Expires 9 August 2026                [Page 15]

Internet-Draft                    IAIP                     February 2026


   The process begins when a Partner Agent transmits a capability
   advertisement (CAP_ADV) [Section 8.1.1].

   *Ingress Validation:* The AAC [Section 8.2] intercepts the message to
   perform session authentication and integrity verification.

   *Registry Update:*Upon successful validation, the AAC forwards the
   payload to the LCR [Section 8.3].  The LCR parses the functional
   descriptors and updates its internal database, mapping the agent's
   semantic profile to its network endpoint.

   The routing process is triggered when a Leader Agent submits an
   intent request (INTENT_REQ) [Section 8.1.2].

   *Ingress Validation:*The AAC validates the request format and the
   sender's authorization scope.

   *Routing Decision:*Validated requests are passed to the IFR
   [Section 8.4], which executes the core decision logic:

   *  *Candidate Retrieval:*The IFR queries the LCR [Section 8.4.1] to
      retrieve active agents capable of satisfying the intent objective.

   *  *Filtering:*Mandatory constraints (e.g., budget, latency) are
      applied to prune ineligible candidates [Section 8.4.2].

   *  *Ranking:*The IFR performs semantic evaluation [Section 8.4.3] to
      assign confidence scores to the remaining candidates.

   *  *Selection:*The eligible partner agents are selected based on
      local policy and fallback mechanisms [Section 8.4.4].

   *Egress Processing:*The partner agent list is passed to the
   Forwarding module [Section 8.5].  This module enforces Time-To-Live
   (TTL) checks and duplicate suppression to prevent routing loops
   before dispatching the forwarded request to the Partner Agent.















Sun & Zhang               Expires 9 August 2026                [Page 16]

Internet-Draft                    IAIP                     February 2026


       +--------------+                  +--------------+
       | Leader Agent |                  | Partner Agent|
       | (Source/App) |                  | (Target/Phy) |
       +-------+------+                  +-------+------+
               | (2) Intent Req                  | (1) CAP_ADV
               | [Sec 8.1.2]                     | [Sec 8.1.1]
               v                                 v
   +------------------------------------------------------------------+
   |              Agent Gateway (Interconnection Domain)              |
   |------------------------------------------------------------------|
   |                                                                  |
   | +--------------+        (CAP_ADV)         +--------------------+ |
   | | Agent Access |------------------------->|  Local Capability  | |
   | |  Comp (AAC)  |                          |   Registry (LCR)   | |
   | |  [Sec 8.2]   |                          |     [Sec 8.3]      | |
   | +------+-------+                          +---------+----------+ |
   |        |                                            ^            |
   |        | (INTENT_REQ)                               | Candidate  |
   |        v                                            | Retrieval  |
   | +---------------------------------------------------+----------+ |
   | |      Intent Forwarding Routing Table (IFR) [Sec 8.4]         | |
   | |--------------------------------------------------------------| |
   | | 1. Candidate Retrieval (Query LCR) [Sec 8.4.1] --------------+ |
   | | 2. Constraint Filtering [Sec 8.4.2]                          | |
   | | 3. Semantic Eval & Ranking [Sec 8.4.3]                       | |
   | | 4. Selection & Fallback [Sec 8.4.4]                          | |
   | +------+-------------------------------------------------------+ |
   |        | Selected Target List                                    |
   |        v                                                         |
   | +----------------------+                                         |
   | |  Forwarding & Loop   |                                         |
   | | Prevention [Sec 8.5] |                                         |
   | +------+---------------+                                         |
   |        |                                                         |
   +--------+---------------------------------------------------------+
            | (3) Forwarded Request
            v
     +-------------+
     | Partner Agt |
     | (Execution) |
     +-------------+

         Figure 4: Protocol Processing procedure at Agent Gateways








Sun & Zhang               Expires 9 August 2026                [Page 17]

Internet-Draft                    IAIP                     February 2026


9.  Conclusions

   This document specifies the functional components, protocol
   procedures, and message formats of the Intent-based Agent
   Interconnection Protocol (IAIP).  It defines the mechanisms for
   capability-aware registration, semantic intent resolution, and
   dynamic routing.  By abstracting the complexity of agent discovery
   and intent matching, IAIP ensures scalable and adaptive collaboration
   across heterogeneous agent systems.

10.  Security Considerations

   This document focuses on the Intent-based Agent Interconnection
   Protocol at the Agent Gateway for inter-agent collaboration in the
   Internet of Agents (IoA).  Security of the IoA ecosystem is not
   detailed in this document.  Security considerations relevant to
   cross-domain intent routing, capability advertisement integrity,
   trust federation among multiple agent service providers, and end-to-
   end confidentiality of agent interactions are suggested to be deeply
   discussed through other proposals.

11.  IANA Considerations

   This document makes no request for IANA action.

12.  Normative References

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

Authors' Addresses

   Sheng Sun
   ICT, CAS
   Email: sunsheng@ict.ac.cn


   Xinyi Zhang
   CNIC, CAS
   Email: xyzhang@cnic.cn










Sun & Zhang               Expires 9 August 2026                [Page 18]


name: draft-verma-dmsc-nlip-notes
rev: 00
title: Use of Natural Language for Agent Communication
time: 2026-02-12T00:52:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T00:52:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864892+00:00
abstract:
In current communication protocol designs, the prevalent practice is
   to define a strict Application Programming Interface (API) for
   different types of interactions among software entities.  There is an
   explosion of APIs which makes interoperability hard, and the
   standards for interoperability fragile.  Specifically for agent to
   agent communications, defining strict APIs for interactions such as
   registration, discovery, telemetry and debugging creates significant
   operational challenges.  In this draft, we argue that a flexible
   design option -- where generative AI is used to create a flexible
   communication protocol for APIs, can lead to a common and flexible
   way for a single uniform API to be used between agents, and enables a
   better communication paradigm.

full_text:
DMSC Working Group                                              D. Verma
Internet-Draft                                                       IBM
Intended status: Informational                                E. Bertino
Expires: 14 August 2026                                Purdue University
                                                          A. Ratnaparkhi
                                                               eBay Inc.
                                                               S. Hughes
                                                             Service Now
                                                                 L. Xing
                                                                   Z. Li
                                                                 X. Liao
                                                                  J. Cui
                              University of Illinois at Urbana-Champaign
                                                            R. Topaloglu
                                                       Marist University
                                                              M. Rahouti
                                                      Fordham University
                                                        10 February 2026


            Use of Natural Language for Agent Communication
                     draft-verma-dmsc-nlip-notes-00

Abstract

   In current communication protocol designs, the prevalent practice is
   to define a strict Application Programming Interface (API) for
   different types of interactions among software entities.  There is an
   explosion of APIs which makes interoperability hard, and the
   standards for interoperability fragile.  Specifically for agent to
   agent communications, defining strict APIs for interactions such as
   registration, discovery, telemetry and debugging creates significant
   operational challenges.  In this draft, we argue that a flexible
   design option -- where generative AI is used to create a flexible
   communication protocol for APIs, can lead to a common and flexible
   way for a single uniform API to be used between agents, and enables a
   better communication paradigm.

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




Verma, et al.            Expires 14 August 2026                 [Page 1]

Internet-Draft             BGP-LS-Inter-AS-Ext             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 14 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.  Conventions used in this document . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Other Modalities  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Existing Standard . . . . . . . . . . . . . . . . . . . . . .   5
   6.  New Conventions . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  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 RFC 2119 [RFC2119] .

2.  Terminology

   The following terms are defined in this document:

   *  NLIP: Natural Language Interaction Protocol



Verma, et al.            Expires 14 August 2026                 [Page 2]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   *  ntohs: Network to Host Short

   *  htons: Host to Network Short

3.  Introduction

   Contemporary application-level protocols and Application Programming
   Interface (API) are designed by specifying a function name (or URI)
   and a data structure.  All communicating endpoints are required to
   use the same data structure, and this data structure is transferred
   between them using a structured representation such as JSON.  This
   design approach causes significant interoperability issues when the
   version upgrade of any software causes a change in the data structure
   that needs to be exchanged.

   A more flexible communication paradigm can be obtained by leveraging
   the ability of large language models to translate between
   unstructured natural language and a structured representation such as
   JSON or the internal structure of a programming language effectively.
   The communicating parties can transmit a natural language
   representation among each other, and each endpoint can maintain its
   own internal representation for the structure being maintained for
   its tasks.

   In this draft, we argue that this flexible exchange offers various
   benefits in agent to agent communications.

   The natural language text exchanged between communicating parties has
   the same semantics as the structures maintained at various
   communication endpoints, but the format is natural language.  A LLM
   at each end point can translate the wire format into the local
   structure format.  This allows for the internal representation of
   structures at endpoints to be independent of each other.  This
   independence allows for improved interoperability and the freedom for
   each end-point to upgrade its internal structures as needed.

   As an example, let us consider the simple but illustrative case where
   one of the endpoints is an agent that is sending its communication
   endpoint information to the other endpoint which is a registrar
   providing registration services for agents.  The registrar maintains
   information about each endpoint as a URL, while the agent maintains
   its internal information as a local host and port.  The agent can
   register itself to the registrar using plain text - "I am running on
   host hostname on port 1430" or an equivalent natural language text
   representation.  The registrar can use a local LLM to translate this
   text to an internal URL representation.





Verma, et al.            Expires 14 August 2026                 [Page 3]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   Using natural language provides two key advantages.  It provides
   resilience against upgrades of the endpoints.  Suppose the registrar
   is upgraded to a new version in which it supports each agent
   information as a structure consisting of a port, a protocol and a
   host address instead of the URL.  This upgrade can be made without
   any impact to any of the agents.  On the other hand, if the
   traditional approach of defining a fixed structure on the wire were
   to be used, the upgrade of the registrar would require changes in
   each of the agents interacting with it.

   The second advantage is the simplification in the versioning of
   protocols.  During any definition of a standard protocol, some key
   features or functions may be missed due to a variety of reasons.  If
   a new protocol version is defined, the protocol needs to be defined
   to support a version number and a careful handling of mismatches in
   the structural differences across versions.  By breaking the linkage
   between the internal representation of endpoint structures and the
   wire structure, natural language simplifies version management
   significantly.

   The separation of the wire format from the internal structures can be
   viewed as a modern take on the concept of ntohs and htons - concepts
   developed during the early stages of computer communications
   development to promote interoperability between computer systems.
   When big-endian machines needed to talk to little- endian machines,
   these two macros translated between network and host structure
   formats.  NLIP is providing the same functionality at the application
   level, leveraging the ability of LLMs to translate between
   unstructured natural text and structured representations.

   It is recommended that two communicating parties exchange information
   about their internal representation with each other.  When an agent
   registers with the registrar in the above example, the registrar can
   send a natural text representation of the internal information to the
   agent to validate that it has translated the text correctly to an
   internal representation and then translated it back.  The agent can
   do its own internal translation and validate that the information is
   consistent with its internal representation.  The same exchange also
   helps to validate if a field is missing or not incorporated properly.

4.  Other Modalities

   Natural language is not the only modality which is needed for general
   communication among software entities.  Some agents may require other
   modality such as images, video or audio/speech as part of their
   operation.  Nevertheless, the same principle of separating the wire
   format from the internal structures and capabilities of the software
   application can be used.



Verma, et al.            Expires 14 August 2026                 [Page 4]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   For each modality, the wire exchange format can specify the modality
   of the exchange.  However, it can leave the task of interpreting the
   contents and internal structure of the exchanged information to the
   local AI model.  The agent can use its local AI model to interpret
   the format and process it.

   This is an analogue of the way humans communicate using the different
   senses.  Our eyes process light/visual modality, our ears process the
   sound/speech modality etc.  Our internal intelligence processes these
   signals without relying on the strict adherence to internal
   structures.  We can simply identify the information modality and let
   the agent process the information.

5.  Existing Standard

   There is an existing standard which is designed based on this
   principle of using natural language for exchange among agents.  This
   standard - Natural Language Interaction Protocol (NLIP) [ECMA430]--
   defines a way for exchanged information to simply define the modality
   , and let interacting agents interpret the exchanged content without
   requiring a strict structure on the wire.

   Experiences implementing NLIP based services and the standard have
   shown that the approach is viable, has good performance and is
   secure.  For development and debugging, the NLIP protocol allowed for
   a single interface for trouble-shooting, and our performance
   evaluation showed that the protocol added little to no overhead, and
   in many cases out-performed registration functions using a more
   traditional API.

   As the IETF community works towards defining conventions for agent to
   agent communications, we want to bring this design approach to their
   attention, since leveraging a protocol like NLIP will provide
   tremendous flexibility and operational simplicity to software
   implementing the functions of agents.

6.  New Conventions

   With the presence of existing standard of NLIP, the task of defining
   common functions for any agent to agent communications becomes that
   of defining the semantics of the information that should be
   transferred, as opposed to defining a rigid structure for the
   interaction.  When agents need to communicate with each other, they
   need to perform functions such as discover other agents, register
   themselves with a registrar, or obtain the governing policies for
   security or data management from other agents.  While NLIP provides
   the basic envelop for transfer of the information, new conventions or
   standards would need to be developed for each of these functions.



Verma, et al.            Expires 14 August 2026                 [Page 5]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   The key difference from traditional approach is that one does not
   define a rigid structure (e.g. a JSON schema or a XML structure) for
   interaction but only the semantic content of the information to be
   exchanged.

   We would consider it a task of the IETF to define the exact
   semantics.  As an example for the task of registration, the semantic
   specification may define that the port number and server host name of
   the agent should be identified, along with the identity of the owning
   organization and the provider of security certificate.  This
   information can be expressed in natural language and converted into
   the local structured representation.

   Similarly, for the task of discovery, the agent looking for specific
   type of remote agent can describe their requirements in natural
   language, instead of defining a rigid schema for discovery of remote
   agents.  Each agent can convert the requirements to their local
   structure to decide whether or not they match the requirements.  IETF
   needs to define the semantic content for discovery requests -- e.g.
   specify that agents must define the type of capabilities they are
   looking for - such as image analysis, speech to text conversion,
   security requirements, performance constraints, or billing limits
   etc.  There is no need to define a specific structure for the task.

   By following this convention, the standardization process can be made
   more streamlined and agents implementing the protocol interoperate
   better with other agents.

7.  Security Considerations

   This document should not affect the security of the Internet.

8.  IANA Considerations

   This document includes no request to IANA.

9.  Acknowledgement

   This template uses extracts from templates written by Pekka Savola,
   Elwyn Davies and Henrik Levkowetz.

10.  References

10.1.  Normative References

   [ECMA430]  Ecma International, "Natural Language Interaction
              Protocol", Standard ECMA-430, Edition 1, December 2025,
              <https://www.ecma-international.org>.



Verma, et al.            Expires 14 August 2026                 [Page 6]

Internet-Draft             BGP-LS-Inter-AS-Ext             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/info/rfc2119>.

10.2.  Informative References

Authors' Addresses

   Dinesh Verma
   IBM
   P.O. Box 218, Yorktown Heights
   New York,  10598
   United States of America
   Email: dverma@us.ibm.com


   Elisa Bertino
   Purdue University
   CS Department
   West Lafayette , IN 47907
   United States of America
   Email: bertino@purdue.edu


   Abhay Ratnaparkhi
   eBay Inc.
   7700 West Parmer Lane
   Austin,  78729
   United States of America
   Email: abratnaparkhi@ebay.com


   Sean Hughes
   Service Now
   2225 Lawson Lane
   Santa Clara , CA 95054
   United States of America
   Email: sean.hughes@servicenow.com


   Luyi Xing
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: lxing2@illinois.edu




Verma, et al.            Expires 14 August 2026                 [Page 7]

Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026


   Zichuan Li
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: zichuan7@illinois.edu


   Xiaojing Liao
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: xjliao@illinois.edu


   Jian Cui
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: jiancui3@illinois.edu


   Rasit Topaloglu
   Marist University
   3399 North Road
   Poughkeepsie , NY 12601
   United States of America
   Email: rasit.topaloglu@marist.edu


   Mohamed Rahouti
   Fordham University
   113 W 60th Street
   New York , NY 10023
   United States of America
   Email: mohamed@fordham.edu













Verma, et al.            Expires 14 August 2026                 [Page 8]


name: draft-zhul-intarea-bnc-up-specific-suboption
rev: 00
title: Broadband Network UP-Specific Information Suboption for the DHCP Relay Agent Option
time: 2026-02-12T03:40:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-16T03:40:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:06.864894+00:00
abstract:
This document defines a new Broadband Network UP-Specific Information
   suboption for the Dynamic Host Configuration Protocol’s (DHCP) relay
   agent information option.  The suboption allows the DHCP relay agent
   (Broadband Network CP) to include UP-specific information in the DHCP
   messages it forwards, to ensure that subscribers within the same SGRP
   under the same UP are assigned IP addresses from the same address
   space by the DHCP server.

full_text:
intarea                                                      L. Zhu, Ed.
Internet-Draft                                             Y. Zhang, Ed.
Intended status: Standards Track                            China Unicom
Expires: 16 August 2026                                 12 February 2026


 Broadband Network UP-Specific Information Suboption for the DHCP Relay
                              Agent Option
            draft-zhul-intarea-bnc-up-specific-suboption-00

Abstract

   This document defines a new Broadband Network UP-Specific Information
   suboption for the Dynamic Host Configuration Protocol’s (DHCP) relay
   agent information option.  The suboption allows the DHCP relay agent
   (Broadband Network CP) to include UP-specific information in the DHCP
   messages it forwards, to ensure that subscribers within the same SGRP
   under the same UP are assigned IP addresses from the same address
   space by the DHCP server.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 16 August 2026.

Copyright Notice

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










Zhu & Zhang              Expires 16 August 2026                 [Page 1]

Internet-Draft  Broadband Network UP-Specific Informatio   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 and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Broadband Network UP-Specific Information Suboption . . . . .   4
   4.  DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . .   5
   5.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In the broadband network with CU separation, subscribers connecting
   via IPOE first send DHCP Request messages.  These messages are sent
   via the AN to a group of UPs.  UPs implement encapsulating the DHCP
   messages with a tunnel header, then send them to the CP.  After
   successful authentication of the subscribers, the CP selects an
   appropriate UP to carry the subscriber’s services and acts as a DHCP
   Relay Agent to forward the DHCP Request messages to the DHCP SERVER
   to obtain an IP address.




















Zhu & Zhang              Expires 16 August 2026                 [Page 2]

Internet-Draft  Broadband Network UP-Specific Informatio   February 2026


+--------------+
| Subscriber 1 |----|                                            1,3_SGRP1
+--------------+    |    +--------------+                   +--------------+
                    |----|      AN      |---------|---------|      UP      |----|
+--------------+    |    +--------------+         |         +--------------+    |
| Subscriber 2 |----|                             |                             |
+--------------+                                  |                             |
                                                  |              5_SGRP1        |
+--------------+         +--------------+         |         +--------------+    |
| Subscriber 3 |---------|      AN      |---------|---------|      UP      |----|      +---------------+     +---------------+
+--------------+         +--------------+                   +--------------+    |      |       CP      |     |               |
                                                                                |------| (Relay Agent) |-----|   DHCP Sever  |
                                                                                |      +---------------+     +---------------+
                                                                  2_SGRP2       |
+--------------+         +--------------+                   +--------------+    |
| Subscriber 4 |---------|      AN      |---------|---------|      UP      |----|
+--------------+         +--------------+         |         +--------------+    |
                                                  |                             |
+--------------+                                  |                             |
| Subscriber 5 |----|                             |              4,6_SGRP2      |
+--------------+    |    +--------------+         |         +--------------+    |
                    |----|      AN      |---------|---------|      UP      |----|
+--------------+    |    +--------------+                   +--------------+
| Subscriber 6 |----|
+--------------+

                 Figure 1: Broadband network diagram

   However, since the DHCP server cannot know that subscribers are borne
   by different UPs, it may assign addresses from different address
   segments to different subscribers accessing through the same UP,
   which is not conducive to address aggregation on the UP.  The best
   practice is that one SGRP on the specific UP should be assigned from
   the same address segment.

   Therefore, this document adds a new suboption, enabling the CP to add
   SGRP information and UP information involved in the DHCP request
   message.  After receiving the message, the DHCP server can divide the
   address pool into several continuous address segments, so that users
   accessing through the same UP can obtain addresses from the same
   address segment.  In this way, the UP can maximize route aggregation
   when advertising prefixes to the IP core network, reducing the
   advertisement of /32 host routes.

2.  Conventions and Definitions

   The following terms and acronyms are used in this document:




Zhu & Zhang              Expires 16 August 2026                 [Page 3]

Internet-Draft  Broadband Network UP-Specific Informatio   February 2026


   *  DHCP Relay Agent: This is a concept in all of the following
      protocols, although the details differ between them: BOOTP
      [RFC951] [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6[draft-
      ietf-dhc-rfc8415bis].

   *  Subscriber Group(or SGRP): Refers to group subscribers together
      that share states and resources; for example, subscribers sharing
      the same back-up state or subscribers sharing the same IP prefix.

   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.  Broadband Network UP-Specific Information Suboption

   Format of the Broadband Network UP-Specific Information suboption:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Code    |      Len      |          Reserverd            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SGRP-ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      UP-Identifier(variable)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2: Broadband Network UP-Specific Information suboption Format

   Where:

   *  Code: TBA

   *  Len: the number of octets in the sub-option (excluding the sub-
      option ID and length fields); the minimum length is 7.

   *  Reserved: Reserved fields, can be defined according to
      requirements in the future.

   *  SGRP-ID: the ID of SGRP, which is any integer value between 0 to
      2^32-1

   *  UP-Identifier: the identifier of UP which is currently carrying
      the group of users corresponding to the aforementioned SGRP-ID





Zhu & Zhang              Expires 16 August 2026                 [Page 4]

Internet-Draft  Broadband Network UP-Specific Informatio   February 2026


   The SGRP-ID has to be stable.  The CP (relay agent) SHOULD use a
   single identifier value consistently for a SGRP.  The SGRP-ID used by
   a relay device SHOULD be comitted to stable storage, unless the relay
   device can regenerate the value upon reboot.

   The UP-Identifier has to be stable and unique.  If the UP-Identifier
   configured in a relay agent is not unique within its administrative
   domain, resource allocation problems may occur as the DHCP server
   attempts to allocate the same resource to subscribers behind two
   different UPs, then UPs can’t implement ip prefix convergence.
   Therefore, a UP-Identifier configured in a relay agent MUST be unique
   within its administrative domain.

   DHCP server attempts to allocate the same resource to subscribers
   behind two different UPs, then UPs can’t implement ip prefix
   convergence.  Therefore, a UP-Identifier configured in a relay agent
   MUST be unique within its administrative domain.

4.  DHCP Relay Agent Behavior

   DHCP relay agent (THE CP) MAY be configured to include a Broadband
   Network UP-Specific Suboption if the include a relay agent
   information option in relayed DHCP messages.  The SGRP-ID strings
   themselves are preferred to be consistent with SGRP provisioning
   parameter.  The UP-Identifier strings themselves can be a loopback
   address of UP or some other ID.

5.  DHCP Server Behavior

   This suboption provides additional information to the DHCP server.
   If it is configured to support this option, the DHCP server may use
   this information to 1) divide the address pool into a smaller block
   using the SGRP-ID and UP-Identifier as indexes, 2) allocate an
   address in the address block indexed by the SGRP-ID and UP-
   Identifier.  There is no special additional processing for this
   suboption.

6.  Security Considerations

   TBD.

7.  IANA Considerations

   A registry is requested to be created for the sub-options in the
   option above.

8.  Normative References




Zhu & Zhang              Expires 16 August 2026                 [Page 5]

Internet-Draft  Broadband Network UP-Specific Informatio   February 2026


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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/info/rfc2131>.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              DOI 10.17487/RFC3396, November 2002,
              <https://www.rfc-editor.org/info/rfc3396>.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, DOI 10.17487/RFC3046, January 2001,
              <https://www.rfc-editor.org/info/rfc3046>.

Authors' Addresses

   Lin Zhu (editor)
   China Unicom
   Beijing
   China
   Email: zhul14@chinaunicom.cn


   Yutao Zhang (editor)
   China Unicom
   Beijing
   China
   Email: zhangyt118@chinaunicom.cn




















Zhu & Zhang              Expires 16 August 2026                 [Page 6]


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: ["AI safety/alignment", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:06.864896+00: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.

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: 01
title: Multi-agent Collaboration Protocol Suite
time: 2026-02-26T08:58:46Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-30T08:58:46Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864900+00:00
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.

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: ["Autonomous netops", "Human-agent interaction", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:06.864902+00: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.

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-02-18T22:11:54Z
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: ["Data formats/interop", "Agent discovery/reg", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:06.864906+00:00
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: ["A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864908+00: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).

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: ["Agent identity/auth", "AI safety/alignment", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:06.864910+00: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.

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]


