# drafts

name: draft-jeskey-anml
rev: 01
title: Agentic Notation Markup Language (ANML) 1.0
time: 2026-05-22T02:30:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-23T02:30:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:52.066030+00:00
source: ietf
abstract:
  ANML (Agentic Notation Markup Language) is a machine-first markup
     language for agent-to-agent and agent-to-service communication over
     the internet.  HTML provides visual interfaces for human consumption;
     ANML describes content, intent, and interaction patterns optimized
     for machine interpretation with minimal computational overhead.

     ANML defines an abstract data model that MAY be serialized as XML
     (application/anml+xml) or JSON (application/anml+json).  Both
     serializations are normative and semantically equivalent.  The XML
     serialization is recommended for human authoring and review; the JSON
     serialization is recommended for programmatic generation and agent-
     pipeline consumption.

     An ANML document defines:

     *  Content: structured, semantic information for machine
        interpretation

     *  Interactions: operations bound to HTTP methods, endpoints, and
        parameters

     *  Knowledge: bidirectional information exchange between services and
        agents

     *  Constraints: disclosure, consent, and authorization rules that
        agents MUST evaluate before sharing data

     *  State: metadata identifying the current phase of a multi-step
        interaction

     *  Persona: advisory behavioral and tonal guidance for agent
        responses

     ANML standardizes these elements to enable deterministic, efficient
     agent interactions with reduced reliance on inference over
     unstructured data.

full_text:
  Network Working Group                                          A. Jeskey
  Internet-Draft                                           ANML Foundation
  Intended status: Experimental                                   May 2026
  Expires: 22 November 2026


                Agentic Notation Markup Language (ANML) 1.0
                            draft-jeskey-anml-01

  Abstract

     ANML (Agentic Notation Markup Language) is a machine-first markup
     language for agent-to-agent and agent-to-service communication over
     the internet.  HTML provides visual interfaces for human consumption;
     ANML describes content, intent, and interaction patterns optimized
     for machine interpretation with minimal computational overhead.

     ANML defines an abstract data model that MAY be serialized as XML
     (application/anml+xml) or JSON (application/anml+json).  Both
     serializations are normative and semantically equivalent.  The XML
     serialization is recommended for human authoring and review; the JSON
     serialization is recommended for programmatic generation and agent-
     pipeline consumption.

     An ANML document defines:

     *  Content: structured, semantic information for machine
        interpretation

     *  Interactions: operations bound to HTTP methods, endpoints, and
        parameters

     *  Knowledge: bidirectional information exchange between services and
        agents

     *  Constraints: disclosure, consent, and authorization rules that
        agents MUST evaluate before sharing data

     *  State: metadata identifying the current phase of a multi-step
        interaction

     *  Persona: advisory behavioral and tonal guidance for agent
        responses

     ANML standardizes these elements to enable deterministic, efficient
     agent interactions with reduced reliance on inference over
     unstructured data.




  Jeskey                  Expires 22 November 2026                [Page 1]


  Internet-Draft                  ANML 1.0                        May 2026


  Status of This Memo

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

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

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

     This Internet-Draft will expire on 2 November 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
       1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       1.2.  Conformance . . . . . . . . . . . . . . . . . . . . . . .   7
         1.2.1.  Documents . . . . . . . . . . . . . . . . . . . . . .   7
         1.2.2.  Conforming ANML Agents  . . . . . . . . . . . . . . .   8
       1.3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   8
       1.4.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       1.5.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   9
     2.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.  Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.  Design Principles . . . . . . . . . . . . . . . . . . . . . .  12
     5.  ANML as an Application of XML . . . . . . . . . . . . . . . .  13
       5.1.  XML Documents . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  ANML Lexical Syntax . . . . . . . . . . . . . . . . . . .  14
         5.2.1.  Element and Attribute Names . . . . . . . . . . . . .  14
         5.2.2.  Attribute Values  . . . . . . . . . . . . . . . . . .  14
         5.2.3.  Whitespace  . . . . . . . . . . . . . . . . . . . . .  14
         5.2.4.  Character References  . . . . . . . . . . . . . . . .  14



  Jeskey                  Expires 22 November 2026                [Page 2]


  Internet-Draft                  ANML 1.0                        May 2026


         5.2.5.  CDATA Sections  . . . . . . . . . . . . . . . . . . .  14
         5.2.6.  Comments and Processing Instructions  . . . . . . . .  14
         5.2.7.  Unknown Elements and Attributes . . . . . . . . . . .  14
       5.3.  ANML Namespace and Public Identifiers . . . . . . . . . .  14
         5.3.1.  Namespace . . . . . . . . . . . . . . . . . . . . . .  15
         5.3.2.  Namespace Policy  . . . . . . . . . . . . . . . . . .  15
         5.3.3.  Versioning  . . . . . . . . . . . . . . . . . . . . .  15
         5.3.4.  Extension Namespaces  . . . . . . . . . . . . . . . .  15
         5.3.5.  Document Type Declaration . . . . . . . . . . . . . .  15
       5.4.  Example ANML Document . . . . . . . . . . . . . . . . . .  16
     6.  ANML as an Internet Media Type  . . . . . . . . . . . . . . .  17
       6.1.  application/anml+xml Media Type . . . . . . . . . . . . .  17
       6.2.  ANML Document Representation  . . . . . . . . . . . . . .  17
         6.2.1.  Character Encoding  . . . . . . . . . . . . . . . . .  17
         6.2.2.  XML Declaration . . . . . . . . . . . . . . . . . . .  17
         6.2.3.  Byte Order Mark . . . . . . . . . . . . . . . . . . .  18
         6.2.4.  Line Endings  . . . . . . . . . . . . . . . . . . . .  18
       6.3.  Content Negotiation . . . . . . . . . . . . . . . . . . .  18
       6.4.  HTTP Caching Interaction  . . . . . . . . . . . . . . . .  18
       6.5.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  18
         6.5.1.  Well-Known URI  . . . . . . . . . . . . . . . . . . .  18
         6.5.2.  HTTP Link Header  . . . . . . . . . . . . . . . . . .  19
         6.5.3.  HTML Link Element . . . . . . . . . . . . . . . . . .  19
         6.5.4.  DNS Service Discovery . . . . . . . . . . . . . . . .  19
     7.  ANML JSON Serialization . . . . . . . . . . . . . . . . . . .  19
       7.1.  application/anml+json Media Type  . . . . . . . . . . . .  20
       7.2.  General Mapping Rules . . . . . . . . . . . . . . . . . .  20
         7.2.1.  Root Object . . . . . . . . . . . . . . . . . . . . .  21
         7.2.2.  Attributes to Properties  . . . . . . . . . . . . . .  21
         7.2.3.  Text Content  . . . . . . . . . . . . . . . . . . . .  21
         7.2.4.  Child Elements to Nested Objects  . . . . . . . . . .  22
         7.2.5.  Empty Elements  . . . . . . . . . . . . . . . . . . .  23
         7.2.6.  Unknown Keys  . . . . . . . . . . . . . . . . . . . .  23
       7.3.  Complete JSON Example . . . . . . . . . . . . . . . . . .  23
       7.4.  Discovery and Content Negotiation . . . . . . . . . . . .  25
       7.5.  JSON-Specific Security Considerations . . . . . . . . . .  25
       7.6.  Normative Equivalence . . . . . . . . . . . . . . . . . .  26
     8.  Document Structure  . . . . . . . . . . . . . . . . . . . . .  27
       8.1.  Root Element: anml  . . . . . . . . . . . . . . . . . . .  27
         8.1.1.  Interaction with HTTP Caching . . . . . . . . . . . .  28
       8.2.  Site Element: site  . . . . . . . . . . . . . . . . . . .  29
       8.3.  Head Section: head  . . . . . . . . . . . . . . . . . . .  30
         8.3.1.  Title: title  . . . . . . . . . . . . . . . . . . . .  30
         8.3.2.  Meta: meta  . . . . . . . . . . . . . . . . . . . . .  30
       8.4.  Constraints Section: constraints  . . . . . . . . . . . .  30
         8.4.1.  Disclosure: disclosure  . . . . . . . . . . . . . . .  30
       8.5.  State Section: state  . . . . . . . . . . . . . . . . . .  30
         8.5.1.  Context: context  . . . . . . . . . . . . . . . . . .  30



  Jeskey                  Expires 22 November 2026                [Page 3]


  Internet-Draft                  ANML 1.0                        May 2026


         8.5.2.  Flow: flow  . . . . . . . . . . . . . . . . . . . . .  30
         8.5.3.  Step: step (flow) . . . . . . . . . . . . . . . . . .  31
       8.6.  Interaction Section: interact . . . . . . . . . . . . . .  31
         8.6.1.  Action: action  . . . . . . . . . . . . . . . . . . .  31
         8.6.2.  Param: param  . . . . . . . . . . . . . . . . . . . .  31
         8.6.3.  Option: option  . . . . . . . . . . . . . . . . . . .  31
         8.6.4.  Response: response  . . . . . . . . . . . . . . . . .  31
       8.7.  Knowledge Section: knowledge  . . . . . . . . . . . . . .  32
         8.7.1.  Inform: inform  . . . . . . . . . . . . . . . . . . .  32
         8.7.2.  Ask: ask  . . . . . . . . . . . . . . . . . . . . . .  32
         8.7.3.  Answer: answer  . . . . . . . . . . . . . . . . . . .  33
         8.7.4.  Refuse: refuse  . . . . . . . . . . . . . . . . . . .  33
       8.8.  Persona Section: persona  . . . . . . . . . . . . . . . .  33
         8.8.1.  Model: model  . . . . . . . . . . . . . . . . . . . .  34
         8.8.2.  Language: language  . . . . . . . . . . . . . . . . .  34
         8.8.3.  Tone: tone  . . . . . . . . . . . . . . . . . . . . .  34
         8.8.4.  Voice: voice  . . . . . . . . . . . . . . . . . . . .  34
         8.8.5.  Instructions: instructions  . . . . . . . . . . . . .  35
         8.8.6.  Vocabulary: vocabulary  . . . . . . . . . . . . . . .  35
         8.8.7.  Prefer: prefer  . . . . . . . . . . . . . . . . . . .  35
         8.8.8.  Avoid: avoid  . . . . . . . . . . . . . . . . . . . .  35
       8.9.  Aesthetic Section: aesthetic  . . . . . . . . . . . . . .  35
         8.9.1.  Display Name: display-name  . . . . . . . . . . . . .  35
         8.9.2.  Logo: logo  . . . . . . . . . . . . . . . . . . . . .  35
         8.9.3.  Colors: colors  . . . . . . . . . . . . . . . . . . .  35
         8.9.4.  Color: color  . . . . . . . . . . . . . . . . . . . .  35
         8.9.5.  Typography: typography  . . . . . . . . . . . . . . .  36
         8.9.6.  Font: font  . . . . . . . . . . . . . . . . . . . . .  36
       8.10. Body Section: body  . . . . . . . . . . . . . . . . . . .  36
         8.10.1.  Section: section . . . . . . . . . . . . . . . . . .  36
         8.10.2.  Image: img . . . . . . . . . . . . . . . . . . . . .  36
         8.10.3.  Audio: audio . . . . . . . . . . . . . . . . . . . .  36
         8.10.4.  Video: video . . . . . . . . . . . . . . . . . . . .  37
         8.10.5.  Description: description . . . . . . . . . . . . . .  37
         8.10.6.  Transcript: transcript . . . . . . . . . . . . . . .  37
         8.10.7.  Link: link . . . . . . . . . . . . . . . . . . . . .  37
         8.10.8.  Data: data . . . . . . . . . . . . . . . . . . . . .  37
         8.10.9.  Item: item . . . . . . . . . . . . . . . . . . . . .  37
         8.10.10. Field: field . . . . . . . . . . . . . . . . . . . .  37
         8.10.11. Navigation: nav  . . . . . . . . . . . . . . . . . .  38
       8.11. ANML Type System  . . . . . . . . . . . . . . . . . . . .  38
       8.12. Footer Section: footer  . . . . . . . . . . . . . . . . .  39
         8.12.1.  Rights: rights . . . . . . . . . . . . . . . . . . .  39
         8.12.2.  Attribution: attribution . . . . . . . . . . . . . .  39
       8.13. Status Section: status  . . . . . . . . . . . . . . . . .  39
     9.  Interaction Model . . . . . . . . . . . . . . . . . . . . . .  39
       9.1.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  39
       9.2.  Interaction Flow  . . . . . . . . . . . . . . . . . . . .  40



  Jeskey                  Expires 22 November 2026                [Page 4]


  Internet-Draft                  ANML 1.0                        May 2026


       9.3.  Action Binding  . . . . . . . . . . . . . . . . . . . . .  40
       9.4.  Knowledge Exchange  . . . . . . . . . . . . . . . . . . .  40
       9.5.  Constraints on Disclosure . . . . . . . . . . . . . . . .  40
       9.6.  Separation of Concerns  . . . . . . . . . . . . . . . . .  41
     10. Characters and Internationalization . . . . . . . . . . . . .  41
       10.1.  Document Character Set . . . . . . . . . . . . . . . . .  41
       10.2.  Character Encoding . . . . . . . . . . . . . . . . . . .  41
       10.3.  Language Identification  . . . . . . . . . . . . . . . .  41
     11. Agent Response Format . . . . . . . . . . . . . . . . . . . .  41
       11.1.  Response Document Structure  . . . . . . . . . . . . . .  41
       11.2.  Minimum Valid Response . . . . . . . . . . . . . . . . .  42
       11.3.  Service Response to Agent Submission . . . . . . . . . .  43
       11.4.  Error Handling . . . . . . . . . . . . . . . . . . . . .  44
       11.5.  Pagination Behavior  . . . . . . . . . . . . . . . . . .  45
       11.6.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  45
     12. Site Trust Delegation . . . . . . . . . . . . . . . . . . . .  47
       12.1.  Trust Tiers  . . . . . . . . . . . . . . . . . . . . . .  47
       12.2.  DNS Bootstrap Record . . . . . . . . . . . . . . . . . .  48
         12.2.1.  Tag-List Syntax  . . . . . . . . . . . . . . . . . .  49
         12.2.2.  Record Fields  . . . . . . . . . . . . . . . . . . .  50
         12.2.3.  Absent or Invalid Records  . . . . . . . . . . . . .  50
       12.3.  Static Trust Manifest  . . . . . . . . . . . . . . . . .  51
       12.4.  Live Trust Query Endpoint  . . . . . . . . . . . . . . .  52
       12.5.  The trust Element and Verification Procedure . . . . . .  54
       12.6.  The site-ref Element . . . . . . . . . . . . . . . . . .  56
       12.7.  Multi-Site Documents and Layered Identity Attack
              Prevention . . . . . . . . . . . . . . . . . . . . . . .  57
       12.8.  Security Considerations for Trust Delegation . . . . . .  59
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  60
       13.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  60
       13.2.  Information Disclosure via Knowledge Exchange  . . . . .  61
       13.3.  Prompt Injection via Persona and Instructions  . . . . .  62
       13.4.  Action Execution Risks . . . . . . . . . . . . . . . . .  63
       13.5.  XML External Entity (XXE) Attacks  . . . . . . . . . . .  63
       13.6.  Agent Spoofing and Service Impersonation . . . . . . . .  64
       13.7.  Malicious ANML Documents . . . . . . . . . . . . . . . .  64
       13.8.  Constraint Bypass  . . . . . . . . . . . . . . . . . . .  65
       13.9.  Replay and State Manipulation  . . . . . . . . . . . . .  65
       13.10. Denial of Service  . . . . . . . . . . . . . . . . . . .  65
       13.11. Cross-Origin Considerations  . . . . . . . . . . . . . .  65
       13.12. Transport Security . . . . . . . . . . . . . . . . . . .  66
     14. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  66
       14.1.  User Control and Consent . . . . . . . . . . . . . . . .  66
       14.2.  Cross-Session and Cross-Platform Context Portability . .  67
       14.3.  Data Minimization  . . . . . . . . . . . . . . . . . . .  68
       14.4.  Usage Rights and Content Controls  . . . . . . . . . . .  68
       14.5.  Regulatory Considerations  . . . . . . . . . . . . . . .  69
     15. Relationship to Related Standards and Formats . . . . . . . .  69



  Jeskey                  Expires 22 November 2026                [Page 5]


  Internet-Draft                  ANML 1.0                        May 2026


       15.1.  HTML . . . . . . . . . . . . . . . . . . . . . . . . . .  69
       15.2.  JSON-LD and Schema.org . . . . . . . . . . . . . . . . .  70
       15.3.  OpenAPI and AsyncAPI . . . . . . . . . . . . . . . . . .  70
       15.4.  robots.txt and llms.txt  . . . . . . . . . . . . . . . .  71
       15.5.  Rationale for XML Serialization  . . . . . . . . . . . .  71
       15.6.  Known Implementations  . . . . . . . . . . . . . . . . .  72
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  72
       16.1.  Media Type Registrations . . . . . . . . . . . . . . . .  72
       16.2.  Well-Known URI Registrations . . . . . . . . . . . . . .  73
       16.3.  ANML Standard Field Names Registry . . . . . . . . . . .  74
       16.4.  XML Namespace Registration . . . . . . . . . . . . . . .  74
       16.5.  ANML Usage Values Registry . . . . . . . . . . . . . . .  74
       16.6.  ANML Disclosure Requires Values Registry . . . . . . . .  76
     17. ANML Public Text  . . . . . . . . . . . . . . . . . . . . . .  76
       17.1.  ANML Site Relationship Values Registry . . . . . . . . .  77
     18. References  . . . . . . . . . . . . . . . . . . . . . . . . .  77
       18.1.  Normative References . . . . . . . . . . . . . . . . . .  77
       18.2.  Informative References . . . . . . . . . . . . . . . . .  78
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  80
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  80

  1.  Introduction

     ANML is pronounced like the English word "animal":

       ANML  /ˈæn.ɪ.məl/  AN-ih-muhl

     HTML has served as the foundation of the World Wide Web since 1990,
     producing platform-independent hypertext documents rendered as visual
     interfaces for human consumption.

     The emergence of large language models (LLMs) and autonomous software
     agents has introduced a new class of web content consumers: machines
     that must interpret, reason about, and act upon published
     information.  HTML, CSS, JavaScript, images, audio, and video produce
     rich user experiences but encode intent, interactions, and
     constraints implicitly — if at all.  Increased computational power
     does not resolve this: no amount of inference can reliably extract
     structured operations, disclosure rules, or workflow state from
     markup that was never designed to express them.

     ANML addresses this gap as a machine-native markup language for
     agent-to-agent and agent-to-service communication.  ANML complements
     existing web standards such as HTML and HTTP by providing a machine-
     oriented interaction layer, rather than replacing them.  ANML is an
     application of XML 1.0 [XML].





  Jeskey                  Expires 22 November 2026                [Page 6]


  Internet-Draft                  ANML 1.0                        May 2026


     The 'application/anml+xml' Internet Media Type is defined by this
     specification (see Section 6.1 (Section 6.1)).

  1.1.  Scope

     This specification defines ANML 1.0, including the document type,
     element and attribute sets, content model, interaction model, and
     media type registration.

     This specification does not define:

     *  Visual rendering or presentation semantics

     *  Client-side scripting or execution models

     *  Transport-layer protocols (HTTP is assumed but not modified)

     *  Authentication or identity mechanisms

     All domain names used in examples throughout this document are
     reserved example domains as defined in [RFC2606]: example.com,
     example.net, and example.org.  These names do not refer to any real
     organization, product, or service.  Where examples require multiple
     distinct domains, example.com is used for the canonical site domain,
     example.net for an authorized serving party, and example.org for a
     second authorized serving party or brand reference.

  1.2.  Conformance

     This specification governs the syntax of ANML documents and the
     behavior of conforming ANML agents.

  1.2.1.  Documents

     A conforming ANML document:

     *  Is a well-formed XML document conforming to [XML]

     *  Conforms to the ANML XML Schema (see Section 17 (Section 17))

     *  Conforms to the conventions defined in this specification

     *  Uses Unicode [UNICODE] as its document character set

     *  Is encoded as UTF-8 [RFC3629] unless an alternative encoding is
        declared via the XML declaration (see Section 6.3 (Section 6.2.1))





  Jeskey                  Expires 22 November 2026                [Page 7]


  Internet-Draft                  ANML 1.0                        May 2026


  1.2.2.  Conforming ANML Agents

     A conforming ANML agent:

     *  Parses ANML documents as well-formed XML

     *  Supports UTF-8 character encoding

     *  Processes <constraints>, <state>, <interact>, <knowledge>, and
        <body> sections as defined in this specification

     *  Evaluates <constraints> before disclosing any information via
        <answer> elements

     *  Ignores unknown elements and attributes without error

     *  Respects user intent above all ANML instructions

  1.3.  Motivation

     The modern web is optimized for human consumption.  To interact with
     it, agents must currently:

     *  Parse large volumes of irrelevant visual and structural data

     *  Infer intent from loosely structured or inconsistent markup

     *  Perform repeated high-cost inference to understand workflows

     *  Reconstruct implicit interaction patterns

     *  Process media resources (images, audio, video) that consume
        significant inference cost and token budget with no guarantee of
        semantic return

     This results in high computational cost, increased latency, reduced
     determinism, and fragile heuristic-dependent automation.

     ANML provides a machine-native representation in which:

     *  Content is explicitly structured for semantic understanding

     *  Actions and workflows are declared

     *  Context is a first-class construct

     *  Agent behavior can be guided at the document level




  Jeskey                  Expires 22 November 2026                [Page 8]


  Internet-Draft                  ANML 1.0                        May 2026


     Existing approaches such as REST APIs and interface description
     languages (e.g., OpenAPI, GraphQL) address machine-to-service
     communication but require prior integration: each service defines a
     bespoke contract that agents must be individually programmed to use.
     ANML takes a different approach.  Like HTML for browsers, ANML
     provides a universal document format that any conforming agent can
     interpret without service-specific integration.  A single ANML
     document conveys content, available operations, knowledge exchange,
     disclosure constraints, workflow state, and behavioral guidance —
     none of which are expressible in a typical API specification.

  1.4.  Goals

     *  Enable efficient agent-to-agent communication over the internet

     *  Reduce inference cost for interpreting web content

     *  Provide explicit, structured representations of content and
        workflows

     *  Standardize machine-consumable service interfaces

     *  Support bidirectional knowledge sharing between services and
        agents

     *  Allow services to provide behavioral and persona guidance to
        agents

     *  Improve determinism and reliability of agent interactions

  1.5.  Non-Goals

     *  Replacing HTML for human-facing interfaces

     *  Rendering visual layouts or graphical experiences

     *  Executing client-side logic

     *  Serving as a general-purpose programming language

  2.  Applicability

     ANML is domain-neutral.  It is applicable to any context in which
     autonomous agents interact with services or with each other over
     HTTP.  Example domains include but are not limited to:

     *  Web services and APIs




  Jeskey                  Expires 22 November 2026                [Page 9]


  Internet-Draft                  ANML 1.0                        May 2026


     *  Personal and enterprise agent systems

     *  IoT and device interaction

     *  Data retrieval and knowledge systems

     ANML does not presume a commercial, consumer, or enterprise context.
     Any service that publishes structured information for machine
     consumption MAY use ANML.

  3.  Terms

     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.

     action  An executable operation defined in the <interact> section,
        bound to an HTTP method and endpoint URI.

     aesthetic  Advisory visual identity guidance within the <aesthetic>
        section, including colors, typography, logos, and display name.

     agent  A software component that processes ANML documents, performs
        actions, and communicates with services on behalf of a user or
        another agent.  Also referred to as "user agent".

     ANML document  A well-formed XML document conforming to this
        specification and the ANML XML Schema (see Section 17
        (Section 17)).

     answer  A response element providing information requested by an
        <ask> element.  Answers may flow from agent to service or from
        service to agent.

     ask  A declarative element through which one party requests
        information from the other.  Neither party is required to fulfill
        any ask.

     body  The primary structured content of an ANML document, contained
        within the <body> element.

     confidentiality  An attribute on <inform> governing how an agent may
        share service-provided information with other services.

     conforming ANML agent  An agent that conforms to this specification
        in its processing of the 'application/anml+xml' media type.



  Jeskey                  Expires 22 November 2026               [Page 10]


  Internet-Draft                  ANML 1.0                        May 2026


     constraint  A rule governing whether and how requested information
        may be disclosed by an agent.

     data  A structured collection of items within the <body>, represented
        by the <data> element.

     description  A textual description of a media resource, provided as a
        child of <img>, <audio>, or <video>.  Enables agents to understand
        media content without performing inference.

     disclosure  The act of an agent sharing information with a service in
        response to an <ask>, subject to applicable constraints and user
        consent.

     endpoint  A URI to which an action is directed.

     flow  A declaration of the structure of a multi-step workflow within
        the <state> section.

     inform  A knowledge element through which a service communicates
        information to an agent.

     knowledge  The section containing <inform> and <ask> elements,
        enabling bidirectional information exchange.

     media type  An Internet Media Type as defined in [RFC6838].

     model  An advisory preference within <persona> indicating which
        inference model or capability a service recommends for processing
        the document.

     nav  A pagination and continuation element within <body>, providing
        next, prev, and cursor references for multi-page result sets.

     persona  Advisory behavioral and tonal guidance within the <persona>
        section.

     refuse  A response element explicitly declining to fulfill an <ask>.

     rights  A copyright and licensing declaration within the <rights>
        element in <footer>.

     service  A networked application that publishes ANML documents and
        processes agent responses.

     state  The section carrying contextual information about a multi-step
        interaction.




  Jeskey                  Expires 22 November 2026               [Page 11]


  Internet-Draft                  ANML 1.0                        May 2026


     status  An element communicating the outcome of a preceding
        operation, including success, error, or partial completion.

     step  A single stage within a workflow.

     transcript  A textual transcript of an <audio> or <video> resource,
        provided as a child element.  Enables agents to understand media
        content without performing inference.

     serving domain  The registered domain (eTLD+1) of the URL from which
        an ANML document was retrieved, normalized to lowercase ASCII,
        with port components omitted.  For example, an ANML document
        retrieved from 'https://cdn.example.net:443/anml' has a serving
        domain of 'example.net'.  The serving domain is the value used as
        the first element of the trust cache key and as the domain
        parameter in Trust Query requests.  When the URL origin and the
        TLS certificate subject differ, the URL origin takes precedence.
        Agents SHOULD use the Public Suffix List to determine eTLD+1
        boundaries.

     site domain  The canonical domain of the site whose identity is
        asserted in an ANML document, as specified in the domain attribute
        of a <trust> or <site> element.  Distinct from the serving domain
        when a third party is serving content on behalf of the site.

     URI  A Uniform Resource Identifier as defined in [RFC3986].

     usage  A machine-readable declaration governing what an agent may do
        with content.  Values form a hierarchy: none < display < cache <
        store < train.

     well-formed XML  An XML document satisfying the well-formedness
        constraints defined in [XML].

  4.  Design Principles

     The following principles guide the design of ANML and SHOULD inform
     the behavior of conforming agents and services.

     *Machine-First.* ANML targets machine consumption, not human
     presentation.

     *Explicit Over Implicit.* Interactions SHOULD be explicitly defined.
     Agents SHOULD NOT need to infer intent from ambiguous markup.

     *Minimize Inference Cost.* Documents SHOULD be structured for direct
     interpretation, minimizing the need for inference.




  Jeskey                  Expires 22 November 2026               [Page 12]


  Internet-Draft                  ANML 1.0                        May 2026


     *Separation of Concerns.* Each section of an ANML document has a
     distinct responsibility.

     *Privacy by Design.* Agents control disclosure.  Services MAY request
     information but MUST NOT require it.

     *Deterministic Behavior.* Agents SHOULD produce consistent results
     given identical inputs.

     *Progressive Enhancement.* ANML MAY be adopted incrementally
     alongside existing web infrastructure.

     *Domain Neutrality.* ANML is domain-agnostic.  It is not limited to
     commercial or e-commerce contexts and applies equally to any agent-
     to-agent or agent-to-service interaction.

     *Extensibility.* Conforming agents MUST safely ignore unknown
     elements and attributes.

     *Trust Awareness.* Agents SHOULD evaluate service trustworthiness
     before disclosing information or executing actions.

     *Human Intent First.* User intent overrides all ANML instructions.
     An agent MUST NOT act contrary to the expressed wishes of its user.

  5.  ANML as an Application of XML

     ANML is an application of XML 1.0 [XML] and XML Namespaces [XMLNS].
     This specification assumes familiarity with XML.

  5.1.  XML Documents

     An ANML document is a well-formed XML document consisting of a
     hierarchy of elements as defined in Section 8.

     The ANML namespace URI is:

     urn:ietf:params:xml:ns:anml:1.0

     A conforming ANML document MUST declare this namespace on the root
     element:

     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0">
       ...
     </anml>






  Jeskey                  Expires 22 November 2026               [Page 13]


  Internet-Draft                  ANML 1.0                        May 2026


  5.2.  ANML Lexical Syntax

     ANML inherits its lexical syntax from XML 1.0.  The following
     subsections define additional constraints.

  5.2.1.  Element and Attribute Names

     All element and attribute names defined by this specification are
     lowercase.  Conforming documents MUST use lowercase names for all
     elements defined herein.

  5.2.2.  Attribute Values

     Attribute values MUST be enclosed in double quotes (U+0022).  All
     attribute values are treated as strings.  ANML does not define
     implicit type coercion.

  5.2.3.  Whitespace

     Whitespace within element content is significant and MUST be
     preserved by conforming agents.  ANML does not define whitespace
     collapsing rules.

  5.2.4.  Character References

     Numeric character references and the predefined XML entity references
     are supported as defined in [XML].  ANML does not define additional
     named entity references.

  5.2.5.  CDATA Sections

     CDATA sections MUST NOT appear in conforming ANML documents.

  5.2.6.  Comments and Processing Instructions

     XML comments MAY appear in ANML documents.  Conforming agents MAY
     ignore comments; comments MUST NOT carry semantic meaning.
     Processing instructions other than the XML declaration MUST NOT
     appear in conforming ANML documents.

  5.2.7.  Unknown Elements and Attributes

     Conforming agents MUST ignore any element or attribute not defined by
     this specification or a recognized extension namespace, without
     raising an error.

  5.3.  ANML Namespace and Public Identifiers




  Jeskey                  Expires 22 November 2026               [Page 14]


  Internet-Draft                  ANML 1.0                        May 2026


  5.3.1.  Namespace

     ANML uses XML Namespaces [XMLNS] to distinguish its elements from
     those of other vocabularies.  The namespace URI
     'urn:ietf:params:xml:ns:anml:1.0' is an identifier and need not
     resolve to a retrievable resource.

  5.3.2.  Namespace Policy

     The ANML namespace URI 'urn:ietf:params:xml:ns:anml:1.0' is version-
     specific — the '1.0' is part of the URI.  This means a future ANML
     2.0 specification using a different namespace URI would be treated as
     an entirely distinct namespace by conforming XML processors.
     Documents from the two versions would not be interoperable at the
     namespace level.

     The author has noted the alternative approach used by HTML5 and other
     standards: a version-independent namespace URI (e.g.,
     'urn:ietf:params:xml:ns:anml') with the version carried only in the
     version attribute of the root element.  This approach avoids
     namespace fragmentation across versions and is RECOMMENDED for
     consideration before the namespace URI is formally registered with
     IANA.

     NOTE: the choice between a version-specific and version-independent
     namespace URI should be resolved before standards-track publication.
     The current version-specific URI is used throughout this draft
     pending that decision.  If a version-independent URI is adopted, all
     namespace URI references in this document will be updated
     accordingly.

  5.3.3.  Versioning

     The namespace URI includes a version component ('1.0').  Future major
     versions will use a new namespace URI.  The namespace URI is the
     authoritative version indicator.

  5.3.4.  Extension Namespaces

     ANML documents MAY include elements and attributes from other XML
     namespaces.  Extensions MUST be namespace-qualified and MUST NOT use
     the ANML namespace URI.

  5.3.5.  Document Type Declaration

     ANML documents SHOULD NOT include a Document Type Declaration
     (DOCTYPE).  If present, conforming agents MUST NOT process its
     internal subset or resolve external entities referenced by it.



  Jeskey                  Expires 22 November 2026               [Page 15]


  Internet-Draft                  ANML 1.0                        May 2026


  5.4.  Example ANML Document

     <?xml version="1.0" encoding="UTF-8"?>
     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0" ttl="3600">
       <head>
         <title>Travel Booking Service</title>
         <meta name="type" value="service"/>
       </head>
       <constraints>
         <disclosure field="airline" requires="explicit-consent"/>
       </constraints>
       <state>
         <context><step>search</step></context>
         <flow>
           <step id="search" label="Search flights" status="current"/>
           <step id="select" label="Select a flight" status="pending"/>
           <step id="payment" label="Payment"
               status="pending" required="true"/>
           <step id="confirm" label="Confirmation" status="pending"/>
         </flow>
       </state>
       <interact>
         <action id="submit-airline" method="POST" endpoint="/airline"/>
       </interact>
       <knowledge>
         <inform ttl="3600">
           We offer flights to over 200 destinations worldwide.
         </inform>
         <ask field="airline" action="submit-airline"
              required="false" purpose="personalization"/>
       </knowledge>
       <persona>
         <model capability="reasoning"/>
         <language policy="native"/>
         <tone value="friendly"/>
         <instructions>Be helpful and concise.</instructions>
       </persona>
       <body>
         Book flights to your destination.
       </body>
       <footer>
         <rights holder="Example Travel, Inc." year="2026" usage="cache">
           Copyright 2026 Example Travel, Inc.
         </rights>
       </footer>
     </anml>





  Jeskey                  Expires 22 November 2026               [Page 16]


  Internet-Draft                  ANML 1.0                        May 2026


  6.  ANML as an Internet Media Type

  6.1.  application/anml+xml Media Type

     The following is to be registered with IANA:

     Media Type name:  application

     Media subtype name:  anml+xml

     Required parameters:  none

     Optional parameters:  charset (default UTF-8), version (default
        "1.0")

     Encoding considerations:  Same as for "application/xml" as specified
        in [XMLMIME].

     Security considerations:  See Section 13 (Section 13).

     Interoperability considerations:  Conforming agents MUST safely
        ignore unknown elements and attributes.

     Published specification:  This document.

     Applications that use this media type:  Autonomous software agents,
        agent-to-agent communication systems.

     File extension(s):  .anml

  6.2.  ANML Document Representation

  6.2.1.  Character Encoding

     The default character encoding for ANML documents is UTF-8 [RFC3629].
     When transmitted via HTTP, the charset parameter of the Content-Type
     header takes precedence over the XML declaration, as specified in
     [XMLMIME].

  6.2.2.  XML Declaration

     A conforming ANML document SHOULD begin with an XML declaration.  The
     XML declaration is REQUIRED when the document uses an encoding other
     than UTF-8.







  Jeskey                  Expires 22 November 2026               [Page 17]


  Internet-Draft                  ANML 1.0                        May 2026


  6.2.3.  Byte Order Mark

     UTF-8 encoded documents SHOULD NOT begin with a BOM.  Conforming
     agents MUST accept documents that include one.  For UTF-16, the BOM
     is REQUIRED.

  6.2.4.  Line Endings

     ANML documents SHOULD use LF (U+000A).  Conforming agents MUST accept
     LF, CR, or CR+LF and normalize to LF as specified in [XML]
     Section 2.11.

  6.3.  Content Negotiation

     Content negotiation follows standard HTTP mechanisms as defined in
     [RFC9110].  An agent SHOULD include 'application/anml+xml' in the
     Accept header.  A service MUST set the Content-Type header when
     responding with an ANML document.

  6.4.  HTTP Caching Interaction

     The interaction between ANML's ttl attribute and HTTP caching
     directives is defined in Section 8.1.1, adjacent to the ttl attribute
     definition on the <anml> root element.  It is cross-referenced here
     because HTTP caching is a transport-layer concern.  The normative
     content is in Section 8.1.1; this section serves as a locator for
     readers approaching from the transport layer.

  6.5.  Discovery

  6.5.1.  Well-Known URI

     A service MAY publish a discovery document at '/.well-known/anml'
     [RFC8615].  The serving domain of the well-known URI response is
     implicitly authoritative: an agent MUST treat an ANML document
     retrieved from 'https://example.net/.well-known/anml' as asserting
     the identity of example.net, regardless of any title, persona, or
     display-name content in the document.  A <trust> element or <site>
     element claiming a different domain in a well-known URI response MUST
     be treated as a third-party assertion subject to the trust
     verification procedure in Section 12 — it does not override the
     serving domain's implicit authority over its own well-known URI.
     This rule prevents CDN operators or hosting providers from
     substituting their own ANML identity for a served site's identity at
     the discovery endpoint.  The following normative rules govern agent
     behavior when interacting with this URI:





  Jeskey                  Expires 22 November 2026               [Page 18]


  Internet-Draft                  ANML 1.0                        May 2026


     *  A 404 (Not Found) response at '/.well-known/anml' SHOULD be
        interpreted by agents as a signal that the service does not
        currently support ANML.  Agents SHOULD NOT retry this URI within
        the same session.  Agents MAY retry in a new session or after the
        HTTP cache TTL of the 404 response has expired.  A 404 is not
        treated as permanent — a service may deploy ANML after a 404 has
        been cached, and agents MUST be capable of rediscovering ANML
        support across sessions.

     *  A 301 (Moved Permanently) or 308 (Permanent Redirect) response
        SHOULD be followed.  Agents SHOULD update their cached discovery
        URI to the redirect target.  Temporary redirects (302, 307) MAY be
        followed but MUST NOT update the cached discovery URI.

     *  A service that supports ANML but has no content to serve at
        '/.well-known/anml' SHOULD return a minimal valid ANML document
        rather than a 404.  A minimal valid document contains at minimum a
        <head> element with a <title>.  This allows agents to confirm ANML
        support without inferring from a 404 that support is absent.

     *  A 410 (Gone) response MUST be interpreted as a permanent removal
        of ANML support.  Agents MUST NOT retry this URI.

  6.5.2.  HTTP Link Header

     A service MAY advertise ANML support via a Link header with
     rel="alternate" and type="application/anml+xml".

  6.5.3.  HTML Link Element

     A service MAY include a <link rel="alternate" type="application/
     anml+xml"> element in HTML documents.

  6.5.4.  DNS Service Discovery

     A domain MAY publish SRV records [RFC2782] at '_anml._tcp' and TXT
     records with key 'v=anml1' and optional 'path' key.

  7.  ANML JSON Serialization

     ANML defines an abstract data model that MAY be serialized as either
     XML (Section 5) or JSON.  Both serializations are normative and
     semantically equivalent.  An implementation that correctly processes
     one serialization MUST produce results identical to processing the
     other serialization of the same document.  The serialization format
     is a deployment choice, not a semantic choice.





  Jeskey                  Expires 22 November 2026               [Page 19]


  Internet-Draft                  ANML 1.0                        May 2026


     The JSON serialization is identified by the media type 'application/
     anml+json'.  Content negotiation follows standard HTTP mechanisms: a
     client SHOULD include both 'application/anml+xml' and 'application/
     anml+json' in the Accept header with appropriate q-values to indicate
     preference.  A service MUST set the Content-Type header to the
     serialization actually returned.

     The XML serialization (Section 5) is RECOMMENDED for documents
     intended for human authoring and review.  The JSON serialization is
     RECOMMENDED for programmatic generation and agent-pipeline
     consumption.  Both are REQUIRED to be supported by conforming
     implementations claiming full conformance.  Implementations MAY
     support only one serialization and MUST document which serializations
     they support.

  7.1.  application/anml+json Media Type

     The following is to be registered with IANA:

     Media Type name:  application

     Media subtype name:  anml+json

     Required parameters:  none

     Optional parameters:  version (default "1.0")

     Encoding considerations:  JSON text MUST be encoded as UTF-8 as
        specified in RFC 8259.  A BOM MUST NOT be prepended.

     Security considerations:  See Section 11.

     Interoperability considerations:  Conforming agents MUST safely
        ignore unknown keys.

     Published specification:  This document.

     Applications that use this media type:  Autonomous software agents,
        agent-to-agent communication systems, REST API clients.

     File extension(s):  .anml.json

  7.2.  General Mapping Rules

     The following rules govern the translation between the XML and JSON
     serializations of ANML.  These rules are applied mechanically and
     uniformly across all elements.




  Jeskey                  Expires 22 November 2026               [Page 20]


  Internet-Draft                  ANML 1.0                        May 2026


  7.2.1.  Root Object

     An ANML JSON document is a single JSON object.  The root object
     corresponds to the <anml> element.  XML attributes of <anml> become
     top-level keys of the root object.  The version key is REQUIRED.
     Example:

     {
       "anml": "1.0",
       "lang": "en",
       "ttl": 3600,
       "head": { ... },
       "constraints": { ... },
       "state": { ... },
       "interact": { ... },
       "knowledge": { ... },
       "persona": { ... },
       "aesthetic": { ... },
       "body": { ... },
       "footer": { ... },
       "status": { ... }
     }

  7.2.2.  Attributes to Properties

     XML attributes become JSON string, number, or boolean properties of
     the enclosing object.  Attribute names that contain hyphens (e.g.,
     supported-versions) are preserved as-is in JSON keys.  Boolean
     attributes with values "true" or "false" become JSON boolean values
     true or false.  Numeric attributes (ttl, min, max) become JSON
     numbers.  All other attributes become JSON strings.

  7.2.3.  Text Content

     XML element text content (#PCDATA) becomes a JSON string value
     associated with the key "content" within the element's object
     representation.  When an element has ONLY text content and no
     attributes or child elements, its value MAY be represented in compact
     form as a JSON string rather than an object with a "content" key.
     Example:











  Jeskey                  Expires 22 November 2026               [Page 21]


  Internet-Draft                  ANML 1.0                        May 2026


     XML:  <inform ttl="3600">We offer 200 destinations.</inform>

     JSON (full):
     {
       "ttl": 3600,
       "content": "We offer 200 destinations."
     }

     JSON (shorthand, only when no other attributes or children):
     "We offer 200 destinations."

  7.2.4.  Child Elements to Nested Objects

     XML child elements become nested JSON objects keyed by the element
     name.  Elements that may appear multiple times as siblings
     (repeatable elements) MUST always be represented as a JSON array,
     even when only one instance is present.  This rule is absolute: a
     repeatable element is never a bare object — it is always a single-
     element array or a multi-element array.  Elements that may appear at
     most once (non-repeatable elements) are represented as a bare JSON
     object, never as an array.

     Repeatable elements (MUST use array form): inform, ask, answer,
     refuse, action, param, option, step, meta, logo, color, font,
     section, item, field, attribution.

     Non-repeatable elements (MUST use object form): head, constraints,
     state, interact, knowledge, persona, aesthetic, body, footer, status,
     context, flow, response, model, language, tone, voice, instructions,
     vocabulary, rights, nav, display-name, colors, typography, title,
     trust.

     Example:


















  Jeskey                  Expires 22 November 2026               [Page 22]


  Internet-Draft                  ANML 1.0                        May 2026


     XML:
     <knowledge>
       <inform ttl="3600">Fact one.</inform>
       <inform ttl="7200">Fact two.</inform>
       <ask field="name" action="submit" required="false"/>
     </knowledge>

     JSON:
     {
       "knowledge": {
         "inform": [
           { "ttl": 3600, "content": "Fact one." },
           { "ttl": 7200, "content": "Fact two." }
         ],
         "ask": {
           "field": "name",
           "action": "submit",
           "required": false
         }
       }
     }

  7.2.5.  Empty Elements

     XML elements with no content and no child elements (EMPTY content
     model) become JSON objects containing only their attribute
     properties.  An empty element with no attributes becomes an empty
     JSON object {}. Example:

     XML:  <tone value="friendly"/>
     JSON: { "tone": { "value": "friendly" } }

     XML:  <disclosure field="email" requires="explicit-consent"/>
     JSON: { "disclosure": { "field": "email",
                             "requires": "explicit-consent" } }

  7.2.6.  Unknown Keys

     Conforming ANML agents processing JSON documents MUST ignore any key
     not defined by this specification or a recognized extension, without
     raising an error.  This mirrors the requirement for XML unknown
     elements and attributes in Section 5.2.7.

  7.3.  Complete JSON Example

     The following is the JSON serialization of the example ANML document
     in Section 5.4:




  Jeskey                  Expires 22 November 2026               [Page 23]


  Internet-Draft                  ANML 1.0                        May 2026


  {
    "anml": "1.0",
    "ttl": 3600,
    "head": {
      "title": "Travel Booking Service",
      "meta": [
        { "name": "type", "value": "service" }
      ]
    },
    "constraints": {
      "disclosure": [
        { "field": "airline", "requires": "explicit-consent" }
      ]
    },
    "state": {
      "context": { "step": "search" },
      "flow": {
        "step": [
          { "id": "search",  "label": "Search flights",
            "status": "current" },
          { "id": "select",  "label": "Select a flight",
            "status": "pending" },
          { "id": "payment", "label": "Payment",
            "status": "pending", "required": true },
          { "id": "confirm", "label": "Confirmation",
            "status": "pending" }
        ]
      }
    },
    "interact": {
      "action": [
        {
          "id": "submit-airline",
          "method": "POST",
          "endpoint": "/airline"
        }
      ]
    },
    "knowledge": {
      "inform": { "ttl": 3600, "content": "We offer flights to over 200 destinations worldwide." },
      "ask": {
        "field": "airline",
        "action": "submit-airline",
        "required": false,
        "purpose": "personalization"
      }
    },
    "persona": {



  Jeskey                  Expires 22 November 2026               [Page 24]


  Internet-Draft                  ANML 1.0                        May 2026


      "model": { "capability": "reasoning" },
      "language": { "policy": "native" },
      "tone": { "value": "friendly" },
      "instructions": "Be helpful and concise."
    },
    "body": {
      "content": "Book flights to your destination."
    },
    "footer": {
      "rights": {
        "holder": "Example Travel, Inc.",
        "year": "2026",
        "usage": "cache",
        "content": "Copyright 2026 Example Travel, Inc."
      }
    }
  }

  7.4.  Discovery and Content Negotiation

     A service supporting JSON serialization SHOULD include 'application/
     anml+json' in the Accept-Patch or Alternates header of its well-known
     URI response.  Agents SHOULD include both media types in the Accept
     header of discovery requests:

     Accept: application/anml+xml;q=0.9, application/anml+json;q=1.0

     A service MAY serve different serializations from different endpoints
     or from the same endpoint based on content negotiation.  The data
     model MUST be identical regardless of serialization.  A service MUST
     NOT include information in one serialization that is absent from the
     other.

  7.5.  JSON-Specific Security Considerations

     JSON documents are subject to the general security considerations in
     Section 11.  The following additional considerations apply
     specifically to JSON serialization:

     *  JSON parsers MUST impose limits on nesting depth to prevent stack
        exhaustion from deeply nested objects.  The RECOMMENDED maximum
        nesting depth is 32 levels.

     *  JSON parsers MUST impose limits on document size.  The RECOMMENDED
        maximum document size is 1MB.






  Jeskey                  Expires 22 November 2026               [Page 25]


  Internet-Draft                  ANML 1.0                        May 2026


     *  JSON parsers MUST reject duplicate keys within the same object.
        When duplicate keys are present the document MUST be treated as
        malformed and rejected entirely.  Note: the XML serialization
        provides equivalent protection through XML 1.0 Section 2.3 well-
        formedness constraints, which prohibit duplicate attribute names —
        a conforming XML parser will reject such documents before they
        reach ANML processing.  Both serializations therefore enforce the
        same uniqueness invariant through their respective base
        specifications.

     *  JSON numbers MUST be parsed as IEEE 754 double-precision floating-
        point values.  Implementations MUST handle numeric overflow and
        precision loss gracefully.

     *  JSON strings MUST be valid UTF-8.  Implementations MUST reject
        documents containing invalid UTF-8 sequences.

  7.6.  Normative Equivalence

     This section is normative.  The following assertions MUST hold for
     any conforming implementation processing the XML and JSON
     serializations of the same logical ANML document:

     *  Disclosure decisions: the agent MUST make identical disclosure
        decisions — which <ask> fields to answer, refuse, or defer —
        regardless of whether the document was received as XML or JSON.

     *  Action execution: the agent MUST identify the same set of
        executable actions and apply the same confirm, auth, and
        idempotent constraints regardless of serialization.

     *  Knowledge exchange responses: the agent MUST produce semantically
        equivalent <answer>, <refuse>, and <inform> responses regardless
        of serialization.  The response itself MAY use either
        serialization independently of the received serialization.

     *  Trust tier determinations: the agent MUST assign the same trust
        tier to each domain regardless of serialization.

     *  Constraint evaluation: the agent MUST apply the same disclosure
        constraints regardless of serialization.

     *  Usage enforcement: the agent MUST apply the same usage
        restrictions to content regardless of serialization.







  Jeskey                  Expires 22 November 2026               [Page 26]


  Internet-Draft                  ANML 1.0                        May 2026


     The following are explicitly NOT required to be identical across
     serializations: user interface rendering, caching implementation
     details, logging format, and internal representation.  These are
     implementation-defined and cannot be specified by this document.

     Any ANML document expressible in XML serialization MUST be
     expressible in JSON serialization with equivalent semantics, and vice
     versa.  Where ambiguity exists between the XML and JSON mapping
     rules, the XML serialization is authoritative.  Implementers
     encountering ambiguity SHOULD file an issue with the ANML Foundation
     at spec@anmlfoundation.org.

  8.  Document Structure

     An ANML document is a tree of elements rooted at <anml>, organized
     into sections with distinct responsibilities.

  8.1.  Root Element: anml

     The <anml> element is the root element.  Attributes: xmlns
     (REQUIRED), version (OPTIONAL, default "1.0"), role (OPTIONAL,
     "service"|"agent-response" — declares the document type, enabling
     schema-based validation of role-specific constraints.  Conforming
     implementations MUST generate the role attribute on all documents
     they produce.  When the role attribute is absent, agents MUST infer
     document role from HTTP context: a document received in response to
     an HTTP GET at a well-known URI or HTTP Link header discovery
     endpoint is a service document; a document submitted as the body of
     an HTTP POST to an action endpoint is an agent-response document.
     When present, the role attribute value MUST match the inferred HTTP
     context role — if they conflict the document MUST be rejected.
     Validators MUST apply role-appropriate content model rules when this
     attribute is present.  There is no default value — absence triggers
     context inference, not a default assumption), supported-versions
     (OPTIONAL, comma-separated list of supported version strings), ttl
     (OPTIONAL, non-negative integer, seconds until the document SHOULD be
     considered stale, counted from the value of the HTTP Date response
     header at time of retrieval; if no Date header is present, ttl is
     counted from time of receipt; if ttl conflicts with HTTP Cache-
     Control, the interaction is governed by Section 6.5 (HTTP Caching
     Interaction); see also Section 8.1.1 for the caching subsection
     adjacent to this attribute definition), lang (OPTIONAL, BCP 47).

     Content model (single-site document): head?, constraints?, state?,
     interact?, knowledge?, persona?, aesthetic?, body?, footer?, status?

     Content model (multi-site document): site+




  Jeskey                  Expires 22 November 2026               [Page 27]


  Internet-Draft                  ANML 1.0                        May 2026


     A conforming <anml> document MUST use one of these two content models
     exclusively.  An <anml> element MUST NOT mix top-level identity
     sections (persona, aesthetic, knowledge, etc.) with <site> elements.
     When a document asserts identity for more than one serving party, it
     MUST use the multi-site content model with <site> wrappers for all
     parties including the serving domain itself.

     Version negotiation: when an agent encounters a document whose
     version attribute specifies a version the agent does not implement,
     the agent SHOULD attempt best-effort processing, ignoring elements
     and attributes it does not recognize, and SHOULD inform the user that
     the document uses a version newer than the agent supports.  If the
     supported-versions attribute is present and does not include any
     version the agent implements, the agent MAY refuse to process the
     document and MUST NOT execute any actions defined within it.  The
     agent SHOULD surface a meaningful error to the user in this case.
     This behavior mirrors established web precedent: agents degrade
     gracefully rather than failing completely when encountering newer
     versions.

     The RECOMMENDED authoring order for single-site documents places
     framing sections (constraints, state, interact, knowledge, persona)
     before <body> to optimize for streaming consumption.

  8.1.1.  Interaction with HTTP Caching

     The ANML ttl attribute interacts with HTTP caching headers as
     follows, in order of precedence:

     *  If the HTTP response carries Cache-Control: no-store, the agent
        MUST NOT cache the document or any content derived from it,
        regardless of any ttl attribute value. no-store takes absolute
        precedence over ttl.

     *  If the HTTP response carries Cache-Control: no-cache, the agent
        MUST revalidate the document with the server before each use,
        regardless of any ttl attribute value.

     *  If the HTTP response carries Cache-Control: max-age=N, and the
        document carries ttl=M, the effective TTL is min(N, M) — the more
        restrictive value applies.

     *  If Cache-Control: s-maxage is present, it governs shared cache
        behavior per RFC 9111 Section 5.2.2.6 independently of ANML ttl
        semantics, which apply to agent-side caching only.






  Jeskey                  Expires 22 November 2026               [Page 28]


  Internet-Draft                  ANML 1.0                        May 2026


     *  If Cache-Control: stale-while-revalidate=N is present, agents MAY
        serve stale ANML content for up to N seconds while revalidating in
        the background, provided the content has not exceeded its ANML
        ttl.

     *  In all cases not addressed above, RFC 9111 [RFC9111] governs HTTP
        caching behavior and ANML ttl provides an additional upper bound
        on agent-side content freshness.

  8.2.  Site Element: site

     The <site> element is a wrapper used in multi-site documents to group
     identity sections belonging to a single serving party or trusted
     third party.  It replaces individual top-level identity sections when
     a document asserts identity for more than one domain.

     Attributes:

     domain  The canonical domain of the site whose identity this element
        asserts.  REQUIRED.  When domain matches the serving domain, no
        trust verification is required.  When domain differs from the
        serving domain, the agent MUST verify trust delegation as defined
        in Section 12 before processing the contents of this <site>
        element.

     trust-verified  ISO 8601 datetime at which the serving party last
        verified the _anml DNS record and authorization data for this
        domain.  OPTIONAL.  Agents MAY use this to decide whether to
        revalidate a cached authorization: if trust-verified is more
        recent than the agent's cached result, the agent SHOULD
        revalidate.  Agents MUST NOT treat this as authorization to skip
        independent verification — it is a hint only.  When this attribute
        is absent, agents MUST perform verification from the DNS bootstrap
        record as defined in Section 12.4.

     Content model: head?, constraints?, state?, interact?, knowledge?,
     persona?, aesthetic?, body?, footer?, status?, site-ref*

     When the domain attribute differs from the serving domain, the agent
     MUST perform trust verification by looking up the _anml DNS TXT
     record for the site domain and proceeding per Section 12.4.  No
     additional trust-manifest attribute is required — the domain
     attribute alone triggers the verification procedure.

     A <site> element MUST contain at least one child element.  An empty
     <site> element is malformed.  Each <site> element in a document MUST
     have a unique domain attribute value.  Duplicate domain values within
     the same <anml> element are not permitted.



  Jeskey                  Expires 22 November 2026               [Page 29]


  Internet-Draft                  ANML 1.0                        May 2026


  8.3.  Head Section: head

     The <head> element contains document metadata.  Content model:
     title?, meta*.

  8.3.1.  Title: title

     The <title> element provides the document title.  Content model:
     (#PCDATA).

  8.3.2.  Meta: meta

     The <meta> element provides name/value metadata pairs.  Attributes:
     name (identifier string), value (string).  Content model: EMPTY.

  8.4.  Constraints Section: constraints

     The <constraints> element defines rules governing disclosure.  Agents
     MUST evaluate constraints before submitting any <answer>.  Content
     model: disclosure*.

  8.4.1.  Disclosure: disclosure

     The <disclosure> element defines a single disclosure rule.
     Attributes: field (REQUIRED, references an <ask> field), requires
     (REQUIRED: explicit-consent|implicit-consent|authentication|none).
     Content model: EMPTY.

  8.5.  State Section: state

     The <state> element carries contextual information about multi-step
     interactions.  Content model: context?, flow?.

  8.5.1.  Context: context

     The <context> element identifies the current position within a flow.
     Content model: step.  The child <step> element contains (#PCDATA)
     whose text MUST match a step id defined in <flow>.  This <step> child
     carries no attributes and serves solely as a reference to a flow
     step.

  8.5.2.  Flow: flow

     The <flow> element declares the workflow structure.  Content model:
     step*.






  Jeskey                  Expires 22 November 2026               [Page 30]


  Internet-Draft                  ANML 1.0                        May 2026


  8.5.3.  Step: step (flow)

     The <step> element defines a single workflow stage.  Attributes: id
     (REQUIRED), label, status (completed|current|pending|skipped),
     required (boolean, "true"|"false", default "false"), next (step id of
     the subsequent step), condition (a service-defined opaque string
     evaluated by the service to determine step availability; agents MUST
     treat this as informational and MUST NOT attempt to evaluate
     condition expressions independently), action (references an <action>
     id available at this step).  Content model: EMPTY.

  8.6.  Interaction Section: interact

     The <interact> element defines executable operations.  Content model:
     action*.

  8.6.1.  Action: action

     The <action> element defines a single operation.  Attributes: id
     (REQUIRED), method (REQUIRED, HTTP method), endpoint (REQUIRED, URI),
     enctype (media type for request body, default "application/x-www-
     form-urlencoded"), auth (none|required|optional, default "none"),
     idempotent (boolean, "true"|"false"), confirm (boolean,
     "true"|"false", if "true" the agent SHOULD confirm with the user
     before executing), description (human-readable text).  Content model:
     param*, response?.

  8.6.2.  Param: param

     The <param> element declares an action parameter.  Attributes: name,
     type (string|number|boolean|date|datetime|uri|enum), required
     (boolean, "true"|"false", default "false"), default, description,
     pattern, min, max.  Content model: option*.

  8.6.3.  Option: option

     The <option> element defines a permitted value for enum parameters.
     Attributes: value (REQUIRED, string), label (human-readable display
     text).  Content model: EMPTY.

  8.6.4.  Response: response

     The <response> element describes the expected response.  Attributes:
     type (default application/anml+xml), description.  Content model:
     EMPTY.






  Jeskey                  Expires 22 November 2026               [Page 31]


  Internet-Draft                  ANML 1.0                        May 2026


  8.7.  Knowledge Section: knowledge

     The <knowledge> element defines bidirectional information exchange.
     Content model: (inform | ask)* for service documents; (answer |
     refuse | ask | inform)* for agent responses.

  8.7.1.  Inform: inform

     The <inform> element communicates information from service to agent.
     Attributes: ttl (non-negative integer, seconds from HTTP Date header
     of the response in which this element was received; see Section 8.1
     for ttl semantics), scope (element id this inform applies to),
     priority (low|normal|high, default "normal"), confidentiality
     (public|restricted|private, default "public"), usage
     (none|display|cache|store|train — see Section 15.4 for the normative
     usage hierarchy).  Content model: (#PCDATA).

  8.7.2.  Ask: ask

     The <ask> element requests information from the other party.
     Attributes: field (REQUIRED), action (REQUIRED, references an
     <action> id), required (boolean, "true"|"false", default "false"),
     purpose (human-readable reason for the request), type (expected value
     type: string|number|boolean|date|datetime|uri — see Section 8.14 for
     the unified ANML type system definition).  Content model: EMPTY.

     The field attribute is a free-form string identifying the information
     being requested.  For interoperability, field values representing
     personal information SHOULD use the property names defined in vCard
     version 4.0 [RFC6350] where applicable — for example: "fn" (formatted
     name), "email", "tel", "adr", "bday", "gender", "lang".  Use of these
     standard property names allows agents to recognize equivalent
     requests across services that use the same vocabulary.  Service-
     specific field names are permitted and are opaque to agents that do
     not recognize them; agents MUST NOT refuse to process an <ask> solely
     because the field name is unrecognized — they MUST instead evaluate
     it against applicable constraints and user consent as with any other
     field.  When an agent encounters an <ask> with an unrecognized field
     name, it MUST apply the most restrictive applicable constraint as a
     default.  Specifically: if no <disclosure> constraint is specified
     for the unrecognized field, the agent MUST treat it as requiring
     requires="explicit-consent" regardless of any other constraint
     configuration.  This ensures unrecognized fields are never disclosed
     silently.  An IANA registry of standard ANML field names is planned
     for a future revision.






  Jeskey                  Expires 22 November 2026               [Page 32]


  Internet-Draft                  ANML 1.0                        May 2026


  8.7.3.  Answer: answer

     The <answer> element provides requested information.  Attributes:
     field (REQUIRED), value (REQUIRED), consent
     (explicit|implicit|delegated), consent-granted (OPTIONAL, ISO 8601
     datetime in UTC — the time at which the user granted consent for this
     disclosure; allows services to evaluate whether consent is current
     relative to their valid-for requirement).  Content model: EMPTY.

     Services that specify valid-for on a <disclosure> element SHOULD
     evaluate the consent-granted timestamp in the corresponding <answer>
     to determine whether the agent's consent is still valid.  If consent-
     granted is absent or older than valid-for seconds, the service SHOULD
     treat the disclosure as requiring fresh consent and SHOULD return a
     response requesting re-consent rather than processing the stale
     answer.

  8.7.4.  Refuse: refuse

     The <refuse> element explicitly declines an <ask>.  Attributes: field
     (REQUIRED), reason (REQUIRED: constraint-violation|user-
     denied|policy-violation|unsupported-field|trust-insufficient),
     constraint (references a <disclosure> field, if applicable), message
     (human-readable explanation).  Content model: EMPTY.

  8.8.  Persona Section: persona

     The <persona> element provides advisory guidance on agent
     communication style.  Content model: model?, language?, tone?,
     voice?, instructions?, vocabulary?.

     Precedence: agents SHOULD apply persona guidance to their responses.
     However, user safety policies, user-configured preferences, and
     platform-level guardrails take absolute precedence over all persona
     guidance.  The SHOULD in this section applies only to persona
     guidance that does not conflict with any higher-priority constraint.
     When persona guidance conflicts with a safety policy or user
     preference, the MUST NOT in Section 13.3 governs — the SHOULD creates
     no obligation to apply conflicting guidance.  Agents MUST be able to
     explain to a user, on request, which persona guidance was applied and
     which was overridden.










  Jeskey                  Expires 22 November 2026               [Page 33]


  Internet-Draft                  ANML 1.0                        May 2026


  8.8.1.  Model: model

     The <model> element provides an advisory model preference for agent
     inference.  Agents MAY use this guidance to select an appropriate
     model but are not required to honor it.  Attributes: name (model
     identifier, e.g., "claude-4", "gpt-5"), provider (e.g., "anthropic",
     "openai"), capability (e.g., "vision", "code", "reasoning").  All
     attributes are OPTIONAL.  When name is not available, agents SHOULD
     select a model that satisfies the specified capability.  Content
     model: EMPTY.

  8.8.2.  Language: language

     The <language> element specifies the response language policy.
     Attributes: value (BCP 47 tag, used when policy="fixed"), policy
     (native|match|fixed).  Content model: EMPTY.

     Policy values: "native" — the agent SHOULD respond in the user's
     preferred language as known to the agent; "match" — the agent SHOULD
     respond in the language of the document; "fixed" — the agent MUST
     respond in the language specified by the value attribute.  Tone and
     voice values are advisory opaque strings; interoperability of persona
     guidance across services is not guaranteed and agents SHOULD treat
     unrecognized tone and voice values as informational only.

     Privacy note: policy="native" causes the agent to infer or disclose
     the user's preferred language to influence its response.  The user's
     language preference is personal information.  Agents SHOULD treat the
     application of policy="native" as equivalent to an implicit
     disclosure of a language preference field and SHOULD apply any
     applicable <constraints> governing language-related disclosures.
     Services MUST NOT use policy="native" as a mechanism to fingerprint
     users by language.

  8.8.3.  Tone: tone

     The <tone> element specifies the emotional register.  Attributes:
     value (e.g., "friendly", "formal", "neutral").  Content model: EMPTY.

  8.8.4.  Voice: voice

     The <voice> element specifies character and perspective.  Attributes:
     perspective (first|third), name (character name, string).  Content
     model: EMPTY.







  Jeskey                  Expires 22 November 2026               [Page 34]


  Internet-Draft                  ANML 1.0                        May 2026


  8.8.5.  Instructions: instructions

     The <instructions> element provides free-text behavioral guidance.
     Advisory only.  Content model: (#PCDATA).

  8.8.6.  Vocabulary: vocabulary

     The <vocabulary> element specifies preferred and avoided terms.
     Content model: prefer*, avoid*.

  8.8.7.  Prefer: prefer

     The <prefer> element declares a preferred term or phrase.  Content
     model: (#PCDATA).

  8.8.8.  Avoid: avoid

     The <avoid> element declares a term or phrase that SHOULD NOT be
     used.  Content model: (#PCDATA).

  8.9.  Aesthetic Section: aesthetic

     The <aesthetic> element provides advisory visual identity guidance.
     Content model: display-name?, logo*, colors?, typography?.

  8.9.1.  Display Name: display-name

     The <display-name> element specifies the preferred service name.
     Content model: (#PCDATA).

  8.9.2.  Logo: logo

     The <logo> element references a logo image.  Attributes: src (URI),
     alt (text description), type (media type, e.g., "image/svg+xml"),
     variant (e.g., "icon", "wordmark", "full").  Content model: EMPTY.

  8.9.3.  Colors: colors

     The <colors> element defines the service color palette.  Content
     model: color*.

  8.9.4.  Color: color

     The <color> element defines a single color value.  Attributes: role
     (e.g., primary, secondary, accent), value (CSS color string).
     Content model: EMPTY.





  Jeskey                  Expires 22 November 2026               [Page 35]


  Internet-Draft                  ANML 1.0                        May 2026


  8.9.5.  Typography: typography

     The <typography> element defines font preferences.  Content model:
     font*.

  8.9.6.  Font: font

     The <font> element defines a single font preference.  Attributes:
     role (e.g., heading, body), family, fallback.  Content model: EMPTY.

  8.10.  Body Section: body

     The <body> element contains the primary semantic content.
     Attributes: usage (none|display|cache|store|train, default content
     usage rights).  Content model: (#PCDATA | section | data | img |
     audio | video | link | nav)*.

  8.10.1.  Section: section

     The <section> element groups related content.  Attributes: id, label,
     usage (none|display|cache|store|train).  Sections MAY be nested.
     Content model: (#PCDATA | section | data | img | audio | video |
     link | nav)*.

  8.10.2.  Image: img

     The <img> element references an image resource.  Attributes: src
     (REQUIRED, URI), inference (none|optional|required), type (media
     type), width, height, usage (none|display|cache|store|train).
     Content model: description?. A <description> child SHOULD be
     provided.

     The inference attribute indicates whether the agent is expected to
     perform inference on the media resource: "none" means the resource
     need not be retrieved or analyzed, "optional" means the agent MAY
     perform inference if beneficial, and "required" means the resource
     contains information essential to the document that cannot be
     conveyed through the <description> alone.

  8.10.3.  Audio: audio

     The <audio> element references an audio resource.  Attributes: src
     (REQUIRED, URI), inference (none|optional|required), type (media
     type), duration (seconds), lang (BCP 47), usage
     (none|display|cache|store|train).  Content model: transcript?,
     description?. The inference attribute has the same semantics as
     defined for <img>.




  Jeskey                  Expires 22 November 2026               [Page 36]


  Internet-Draft                  ANML 1.0                        May 2026


  8.10.4.  Video: video

     The <video> element references a video resource.  Attributes: src
     (REQUIRED, URI), inference (none|optional|required), type (media
     type), duration (seconds), width, height, lang (BCP 47), usage
     (none|display|cache|store|train).  Content model: transcript?,
     description?. The inference attribute has the same semantics as
     defined for <img>.

  8.10.5.  Description: description

     The <description> element provides a textual description of a media
     resource (<img>, <audio>, or <video>).  When present, agents MAY use
     the description instead of performing inference on the media
     resource.  Content model: (#PCDATA).

  8.10.6.  Transcript: transcript

     The <transcript> element provides a textual transcript of an <audio>
     or <video> resource.  When present, agents MAY use the transcript
     instead of performing inference on the media resource.  Content
     model: (#PCDATA).

  8.10.7.  Link: link

     The <link> element references a related resource.  Attributes: href
     (REQUIRED, URI), rel (relationship type, e.g., "alternate",
     "related", "canonical"), type (media type of the referenced
     resource), label (human-readable description).  Content model: EMPTY.

  8.10.8.  Data: data

     The <data> element contains structured data as a collection of items.
     Attributes: id, label, usage (none|display|cache|store|train).
     Content model: item*.

  8.10.9.  Item: item

     The <item> element represents a single record within a <data>
     collection.  Attributes: id (string).  Content model: field*.

  8.10.10.  Field: field

     The <field> element represents a named value within an <item>.
     Attributes: name (string), type
     (string|number|boolean|date|datetime|uri).  Content model: (#PCDATA).





  Jeskey                  Expires 22 November 2026               [Page 37]


  Internet-Draft                  ANML 1.0                        May 2026


  8.10.11.  Navigation: nav

     The <nav> element provides pagination and continuation controls.
     Attributes: next (URI for the next page), prev (URI for the previous
     page), cursor (opaque continuation token), total (total item count,
     if known).  Content model: EMPTY.

  8.11.  ANML Type System

     The following type vocabulary is used by the type attribute of both
     the <ask> and <field> elements.  This section is the single normative
     definition; both elements reference it.  Implementations MUST apply
     these definitions consistently across both contexts.

     string  A sequence of Unicode characters.  No maximum length is
        defined by this specification; services and agents SHOULD impose
        implementation-defined limits.  The value attribute in <answer>
        and the value attribute in <field> carry string values as UTF-8
        text.

     number  A numeric value represented as an IEEE 754 double-precision
        floating-point number.  Implementations MUST handle precision loss
        gracefully.  For financial values, services SHOULD use string type
        with explicit format documentation to avoid floating-point
        precision issues.

     boolean  One of the literal string values "true" or "false".
        Implementations MUST NOT accept other representations (e.g., "1",
        "0", "yes", "no").

     date  A date value in the format defined by RFC 3339 [RFC3339] full-
        date production: YYYY-MM-DD.  Example: "2026-07-14".
        Implementations MUST reject values that do not conform to this
        format.

     datetime  A datetime value in the format defined by RFC 3339
        [RFC3339] date-time production, in UTC with Z suffix: YYYY-MM-
        DDTHH:MM:SSZ.  Example: "2026-07-14T09:00:00Z".  Implementations
        MUST reject values that do not conform to this format.  Local time
        offsets are not permitted — all datetime values MUST be UTC.

     uri  A URI as defined in RFC 3986 [RFC3986].  Implementations SHOULD
        validate that the value is a well-formed URI before transmitting
        it in an <answer>.







  Jeskey                  Expires 22 November 2026               [Page 38]


  Internet-Draft                  ANML 1.0                        May 2026


     The type attribute is advisory when present on <ask> — it
     communicates the service's expected value format to the agent.  It is
     descriptive when present on <field> — it communicates the data type
     of a value in a result set.  In both cases, agents SHOULD validate or
     format values according to the type definition before transmission.

  8.12.  Footer Section: footer

     The <footer> element contains copyright, licensing, and attribution
     declarations.  Content model: rights*, attribution*, (#PCDATA)*.

  8.12.1.  Rights: rights

     The <rights> element declares copyright and usage terms.  Attributes:
     holder, year, license, usage (none|display|cache|store|train, default
     "none"), scope.  Usage values form a hierarchy: none < display <
     cache < store < train.  Multiple <rights> elements MAY target
     specific element IDs via the scope attribute.  Content model:
     (#PCDATA).

  8.12.2.  Attribution: attribution

     The <attribution> element provides credit to content sources.
     Attributes: required (boolean, "true"|"false", default "false"),
     scope (element id this attribution applies to).  Content model:
     (#PCDATA).

  8.13.  Status Section: status

     The <status> element communicates the outcome of a preceding
     operation.  Content model: EMPTY.  Attributes: code (REQUIRED,
     machine-readable status code), result (REQUIRED:
     success|error|partial), message (human-readable description), retry-
     after (seconds before the agent SHOULD retry).

  9.  Interaction Model

     ANML operates over HTTP.  It does not replace or modify HTTP methods,
     headers, authentication, session management, or cookie handling.

  9.1.  Transport

     ANML interactions use HTTP [RFC9110].  The <action> element's method
     attribute specifies the HTTP method.  ANML does not define or
     constrain HTTP method semantics.






  Jeskey                  Expires 22 November 2026               [Page 39]


  Internet-Draft                  ANML 1.0                        May 2026


  9.2.  Interaction Flow

     A typical ANML interaction proceeds as follows:

     1.  Resource Retrieval: The agent issues an HTTP GET; the service
         returns an ANML document.

     2.  Document Interpretation: The agent processes the constraints,
         state, interact, knowledge, and body sections.  If a <flow>
         element is present, the agent SHOULD use it to understand the
         full interaction sequence.

     3.  Disclosure Evaluation: The agent evaluates <ask> elements against
         user consent, local policies, trust level, sensitivity, and
         applicable constraints.

     4.  Action Selection: The agent resolves the <ask>'s action attribute
         to a matching <action> element to determine the method and
         endpoint.

     5.  Response Submission: The agent performs the HTTP request using
         the resolved method and endpoint.

     6.  State Advancement: The service responds with updated state,
         knowledge, or new interaction options.

  9.3.  Action Binding

     All executable operations MUST be defined in the <interact> section.
     The agent resolves the response target by: (1) reading the action
     attribute of the <ask>, (2) locating the matching <action> element,
     and (3) using its method and endpoint to submit the response.

  9.4.  Knowledge Exchange

     ANML defines a bidirectional knowledge exchange model.  Services
     include <inform> and <ask> elements in documents; agents include
     <answer>, <refuse>, <ask>, and <inform> elements in responses.

  9.5.  Constraints on Disclosure

     Agents MUST evaluate constraints before submitting any <answer>.
     Constraints may govern consent requirements, authentication, field-
     level disclosure restrictions, and rate limitations.







  Jeskey                  Expires 22 November 2026               [Page 40]


  Internet-Draft                  ANML 1.0                        May 2026


  9.6.  Separation of Concerns

     ANML separates transport and identity (HTTP) from semantics and
     interaction (ANML).

  10.  Characters and Internationalization

     The ANML internationalization model builds on XML [XML], Unicode
     [UNICODE], and RFC 2070 [RFC2070].

  10.1.  Document Character Set

     The document character set is Unicode [UNICODE], synchronized with
     ISO/IEC 10646.  Numeric character references resolve via Unicode code
     points regardless of encoding.  ANML does not support non-Unicode
     character repertoires.

  10.2.  Character Encoding

     The default encoding is UTF-8 [RFC3629].  Non-Unicode encodings MUST
     NOT be used.  Encoding detection precedence: (1) HTTP Content-Type
     charset, (2) XML declaration encoding attribute, (3) BOM detection,
     (4) UTF-8 default.

  10.3.  Language Identification

     The 'lang' attribute specifies natural language using BCP 47 [BCP47]
     tags.  Language declarations inherit from parent to child elements.
     ANML does not define a 'dir' attribute; bidirectional text is handled
     by the Unicode Bidirectional Algorithm [UAX9].

  11.  Agent Response Format

     This section defines the format, content model, and normative
     behavior for agent-originated ANML documents — documents submitted by
     an agent to a service in response to an <ask> or as part of a multi-
     step interaction.

  11.1.  Response Document Structure

     An agent response is a conforming ANML document submitted as the body
     of an HTTP request to the endpoint specified by the <action> element
     referenced in the originating <ask>.  The Content-Type of the request
     MUST be either 'application/anml+xml' or 'application/anml+json',
     matching the serialization used.  The agent SHOULD use the same
     serialization as the document it is responding to unless the service
     has indicated a preference via the Accept header of a prior response.




  Jeskey                  Expires 22 November 2026               [Page 41]


  Internet-Draft                  ANML 1.0                        May 2026


     The root element of an agent response document is <anml> with the
     same namespace and version as defined in this specification.  An
     agent response document MAY contain any combination of the following
     elements in its knowledge section:

     *  <answer> — providing information requested by an <ask>

     *  <refuse> — explicitly declining to answer an <ask>

     *  <ask> — requesting information from the service before proceeding

     *  <inform> — providing unrequested contextual information the agent
        determines is relevant

     An agent response MUST contain at least one <answer> or <refuse>
     element corresponding to each <ask> element marked required="true" in
     the originating document.  An agent MAY include <answer> or <refuse>
     elements for optional <ask> elements at its discretion.  An agent
     MUST NOT include <answer> elements for fields not requested by an
     <ask> in the current interaction context.

     An agent response MUST NOT include <interact>, <persona>,
     <aesthetic>, <constraints>, or <state> sections.  These sections are
     reserved for service documents.  A service receiving an agent
     response that includes these sections MUST ignore them.

  11.2.  Minimum Valid Response

     The minimum valid agent response is an ANML document containing a
     single <refuse> element for each required <ask> in the originating
     document.  This indicates the agent has processed the document but is
     unable or unwilling to provide the requested information.  Example:

     <?xml version="1.0" encoding="UTF-8"?>
     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0">
       <knowledge>
         <refuse field="airline"
                 reason="user-denied"
                 message="User declined to share airline preference."/>
       </knowledge>
     </anml>










  Jeskey                  Expires 22 November 2026               [Page 42]


  Internet-Draft                  ANML 1.0                        May 2026


  11.3.  Service Response to Agent Submission

     A service receiving an agent response MUST return an HTTP response
     with an appropriate status code.  When the service returns an ANML
     document as the response body, it MUST set Content-Type to the
     appropriate ANML media type.  The service response SHOULD include a
     <status> element indicating the outcome of the submitted action.

     The following HTTP status codes have defined semantics in the ANML
     interaction model:

     *  200 OK — the action was processed successfully; the response body
        MAY contain an updated ANML document advancing the interaction
        state.

     *  400 Bad Request — the agent response was malformed or missing
        required fields; the service SHOULD include a <status> element
        with a human-readable message.

     *  401 Unauthorized — authentication is required; the agent SHOULD
        surface this to the user and MUST NOT retry automatically with
        stored credentials.

     *  403 Forbidden — the action is not permitted for this agent or
        user; the agent MUST NOT retry the same action.

     *  409 Conflict — the request conflicts with the current state of the
        target resource as defined by HTTP semantics.  For example,
        attempting to book a seat that has just been reserved by another
        user.  The service SHOULD provide updated state in the response
        body.  Note: inventory unavailability (e.g., out of stock) is NOT
        a conflict in the HTTP sense and SHOULD be represented as 422 with
        a domain-specific status message.

     *  422 Unprocessable Content — the action was understood but cannot
        be executed as submitted, including cases where inventory is
        unavailable, a field value is out of range, or a prerequisite step
        has not been completed.  The service SHOULD indicate which fields
        require correction or what precondition was not met.












  Jeskey                  Expires 22 November 2026               [Page 43]


  Internet-Draft                  ANML 1.0                        May 2026


     For 4xx responses, services SHOULD return a response body conforming
     to RFC 9457 [RFC9457] (Problem Details for HTTP APIs), using Content-
     Type 'application/problem+json' or 'application/problem+xml'.  RFC
     9457 supersedes RFC 7807 and is backward compatible with it.  Problem
     Details provide machine-parseable error information including field-
     level validation errors, constraint violations, and retry guidance
     that agents can act on without human intervention.  The ANML <status>
     element is used for 2xx responses only; 4xx and 5xx responses SHOULD
     use RFC 9457 Problem Details as the error envelope.

     *  429 Too Many Requests — the agent is submitting too frequently;
        the agent MUST respect the Retry-After header if present and MUST
        NOT retry without it.

     *  500 Internal Server Error — the service encountered an unexpected
        condition.  The agent SHOULD NOT retry immediately.  The agent MAY
        retry once after a delay of not less than 5 seconds.  The agent
        SHOULD inform the user that the service encountered an error.

     *  503 Service Unavailable — the service is temporarily unavailable.
        The agent MUST respect the Retry-After header if present.  If no
        Retry-After header is present, the agent SHOULD NOT retry within
        the current session.  The agent MUST inform the user that the
        service is unavailable.

     *  Other 5xx responses — the agent SHOULD treat these as equivalent
        to 500 unless more specific guidance is provided by the service.
        The agent MUST NOT interpret a 5xx response as a constraint
        violation or trust failure.  Server errors are operational, not
        adversarial, unless accompanied by other indicators of malicious
        behavior.

  11.4.  Error Handling

     The following normative error handling requirements apply to
     conforming agents and services:

     *  Required field absent: if a required attribute (e.g., field on
        <ask>, id on <action>) is absent, the agent MUST treat the
        containing element as malformed and MUST NOT process it.  The
        agent SHOULD log the error and SHOULD inform the user if the
        malformed element would have been part of the interaction.

     *  Unknown step reference: if <context> references a step id that
        does not exist in <flow>, the agent MUST ignore the <context>
        element and MUST NOT attempt to infer the current workflow
        position.




  Jeskey                  Expires 22 November 2026               [Page 44]


  Internet-Draft                  ANML 1.0                        May 2026


     *  Action endpoint unreachable: if the HTTP request to an action
        endpoint fails with a network error, the agent MUST NOT retry
        automatically more than once.  The agent SHOULD inform the user of
        the failure.

     *  Document parse failure: if an ANML document cannot be parsed as
        well-formed XML or valid JSON, the agent MUST NOT process any part
        of the document and MUST inform the user that the service returned
        an invalid document.

     *  Circular flow reference: if a <flow> contains steps that reference
        each other in a cycle with no exit condition, the agent MUST
        detect this and terminate processing of the <flow> element.

     *  Conflicting constraints: if two <disclosure> elements conflict for
        the same field, the agent MUST apply the more restrictive
        constraint.

  11.5.  Pagination Behavior

     The <nav> element within <body> provides next, prev, and cursor
     references for multi-page result sets.  The following normative
     behavior applies:

     *  Agents SHOULD follow pagination only when the user has expressed
        interest in additional results or when the agent determines that
        additional results are necessary to fulfill the user's request.

     *  Agents SHOULD NOT automatically fetch all pages of a paginated
        result set without user awareness.

     *  Implementations SHOULD impose a maximum of 10 pages per
        interaction to prevent runaway pagination.  Implementations MAY
        exceed this limit with explicit user authorization.

     *  Services MUST NOT use pagination as a mechanism to force agents to
        make an unbounded number of requests.  A service SHOULD indicate
        the total number of available items in the total attribute of
        <nav> where known.

     *  Agents MUST detect and terminate pagination loops: if a next URI
        matches a URI already retrieved in the current interaction, the
        agent MUST stop following pagination.

  11.6.  Examples

     Example agent response with multiple answers and a counter-ask:




  Jeskey                  Expires 22 November 2026               [Page 45]


  Internet-Draft                  ANML 1.0                        May 2026


     <?xml version="1.0" encoding="UTF-8"?>
     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0">
       <knowledge>
         <answer field="destination" value="LAX" consent="explicit"/>
         <refuse field="airline"
                 reason="user-denied"
                 message="User prefers not to share airline preference."/>
         <ask field="available-dates"
              action="submit-booking"
              purpose="Required to show available flights"/>
         <inform>User prefers morning departures before 10:00 AM.</inform>
       </knowledge>
     </anml>

     Example service response with pagination and status:

     <?xml version="1.0" encoding="UTF-8"?>
     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0">
       <status code="200" result="success"
               message="Found 47 flights matching your criteria."/>
       <body>
         <data id="flights" label="Available flights">
           <item id="f1">
             <field name="airline" type="string">Example Air</field>
             <field name="departure"
                    type="datetime">2026-05-01T08:00Z</field>
             <field name="price" type="number">349</field>
           </item>
           <item id="f2">
             <field name="airline" type="string">Globe Wings</field>
             <field name="departure"
                    type="datetime">2026-05-01T10:30Z</field>
             <field name="price" type="number">412</field>
           </item>
         </data>
         <nav next="/flights?page=2" total="47" cursor="eyJwYWdlIjoyfQ"/>
       </body>
       <state>
         <context><step>select</step></context>
       </state>
     </anml>










  Jeskey                  Expires 22 November 2026               [Page 46]


  Internet-Draft                  ANML 1.0                        May 2026


  12.  Site Trust Delegation

     ANML documents may be served by parties other than the site whose
     identity they assert.  A large retailer may serve brand content under
     a commercial authorization.  A small independent retailer may carry
     products without any formal authorization relationship.  A CDN may
     serve cached documents on behalf of an origin.  In all of these
     cases, TLS certificate verification establishes only that the agent
     is talking to the serving domain — it says nothing about whether that
     domain is authorized to assert the identity of another site.

     This section defines the ANML Trust Delegation mechanism.  It is
     modeled on the DKIM pattern: a small DNS TXT record at the site's
     domain serves as the single bootstrap entry point, advertising where
     authorization data can be found.  The authorization data itself lives
     in a static manifest, a live query endpoint, or both — but never in
     DNS directly.  This keeps DNS records small and stable regardless of
     how many partners a site authorizes, while giving sites the
     flexibility to choose the authorization mechanism that fits their
     scale and operational requirements.

  12.1.  Trust Tiers

     ANML defines three trust tiers for third-party serving parties.  The
     site's own canonical domain operates as an implicit Tier 3 — full
     trust, no verification required.

     Tier 0 — Unlisted  No authorization record exists for the serving
        domain, or no DNS bootstrap record exists for the asserted site,
        or verification fails for any reason.  This is the default for any
        third-party domain.  Permitted: the serving party MAY assert its
        own identity fully; MAY include <site-ref> elements pointing to
        other sites' canonical ANML documents; MAY include a <trust>
        element or trust-manifest attribute to invite the agent to attempt
        verification (the invitation itself is not an assertion).
        Prohibited: the serving party MUST NOT assert any identity
        sections (<persona>, <aesthetic>, <knowledge>, <interact>,
        <constraints>) on behalf of any other site.  Verification failure
        always results in Tier 0.  Agents MUST NOT apply partial trust on
        a failed verification.

     Tier 1 — Display Authorization  The serving domain is authorized with









  Jeskey                  Expires 22 November 2026               [Page 47]


  Internet-Draft                  ANML 1.0                        May 2026


        a restricted scope.  Appropriate for CDNs, aggregators, and
        display-only resellers.  Permitted sections: "aesthetic", "body",
        and "knowledge" limited to confidentiality="public" inform
        elements.  Prohibited regardless of scope array: "persona",
        "interact", "constraints".  The tier integer is normative; scope
        arrays for Tier 1 entries that include prohibited sections MUST be
        silently truncated by the agent to exclude those sections.

     Tier 2 — Full Authorization  The serving domain is authorized with an
        explicit scope defined by the site.  Appropriate for authorized
        retail partners and licensed distributors.  The scope array
        defines exactly which sections may be asserted.  The tier integer
        is normative and takes precedence over the scope array if they
        conflict.

  12.2.  DNS Bootstrap Record

     The DNS bootstrap record is the single entry point for trust
     discovery.  It is a DNS TXT record published by the site being
     represented at a fixed subdomain convention.  Its only purpose is to
     advertise where authorization data can be found.  It contains no
     authorization data itself — keeping the record small and stable
     regardless of how many partners a site authorizes.

     The record format follows the tag-list convention established by DKIM
     [RFC6376] (Section 3.2) and SPF [RFC7208] (Section 4.6): a sequence
     of key=value pairs separated by semicolons, with defined parsing
     semantics.  Agents MUST parse _anml TXT records using the tag-list
     rules defined in this section, which are consistent with those RFCs.

     Rationale for reusing this format: the tag-list convention from RFC
     6376 and RFC 7208 is already implemented by every major DNS
     management platform, monitoring tool, and DNS analysis service.
     Reusing the format means operators can inspect, validate, and debug
     _anml records using existing tooling without new software.  This is a
     deliberate operational engineering choice, not a dependency on email
     authentication semantics.

     The record is published at:

     _anml.{site-domain}  IN  TXT  "v=anml1; [manifest=URI;] [query=URI]"

     Example:

  _anml.example.com  IN  TXT  "v=anml1; manifest=https://example.com/.well-known/anml-trust; query=https://trust.example.com/anml/authorize"






  Jeskey                  Expires 22 November 2026               [Page 48]


  Internet-Draft                  ANML 1.0                        May 2026


  12.2.1.  Tag-List Syntax

     The following ABNF [RFC5234] defines the _anml TXT record syntax.
     This grammar is consistent with the DKIM tag-list grammar defined in
     RFC 6376 Section 3.2 and the SPF record grammar in RFC 7208
     Section 4.6.

     anml-record    = tag-list
     tag-list       = tag *( ";" tag ) [ ";" ]
     tag            = tag-name "=" tag-value
     tag-name       = ALPHA *ALNUMPUNC
     tag-value      = *( %x21-3A / %x3C-7E )
                      ; printable ASCII except ";" (%x3B)
                      ; "=" (%x3D) is permitted in tag-value
                      ; (e.g., within URI query strings)
     ALNUMPUNC      = ALPHA / DIGIT / "_" / "-" / "."
     version-tag    = %s"v" "=" %s"anml1"
     manifest-tag   = %s"manifest" "=" URI
     query-tag      = %s"query" "=" URI
     URI            = <URI as defined in RFC 3986, Section 3>

     Parsing rules (normative):

     *  Tag names are case-sensitive. "v=anml1" is valid; "V=anml1" MUST
        be ignored as unrecognized.

     *  Whitespace (SP, HTAB) before or after "=" or ";" MUST be ignored
        by parsers.  Implementations MUST NOT include whitespace in
        generated records, but MUST tolerate it when parsing.

     *  Tag pairs MUST be split on the first ";" delimiter only.  Within
        each tag pair, the tag-name and tag-value MUST be split on the
        FIRST "=" character only.  All subsequent "=" characters within
        the tag-value are part of the value — for example, a URI query
        string such as "https://example.com/auth?a=1&b=2" is a single tag-
        value.  Parsers MUST NOT split on "=" characters after the first
        "=" in a tag pair.

     *  Duplicate tag names within a single record are prohibited.  If
        duplicate tag names are present, the agent MUST treat the entire
        record as malformed and ignore it.

     *  Unknown tag names MUST be ignored without error.  This allows
        forward compatibility with future tag definitions.







  Jeskey                  Expires 22 November 2026               [Page 49]


  Internet-Draft                  ANML 1.0                        May 2026


     *  DNS TXT records are limited to 255 octets per string.  Multiple
        strings in a single TXT RRset are concatenated in order per RFC
        1035 Section 3.3.14.  Agents MUST concatenate all strings in an
        _anml TXT record before parsing.  If a URI value is split across
        string boundaries, it MUST be reassembled before use.

     *  A record without a recognized "v" tag MUST be ignored entirely.  A
        record where v != "anml1" MUST be ignored.  Agents MUST process a
        record only after confirming v=anml1.  The "v" tag MUST appear
        first.

     *  At least one of "manifest" or "query" MUST be present in a valid
        record.  A record with neither is malformed and MUST be ignored.

  12.2.2.  Record Fields

     v  Version tag.  REQUIRED.  MUST be the first tag in the record per
        DKIM convention (RFC 6376 Section 3.5).  Current value: "anml1".

     manifest  URI of the static Trust Manifest JSON document.  MUST use
        the https scheme.  MUST be served from the site's canonical
        domain.  OPTIONAL if query is present.

     query  URI of the live Trust Query endpoint.  MUST use the https
        scheme.  MAY be served from any domain — its authority derives
        from publication in the site's own DNS record.  When DNSSEC is not
        available for the _anml record, agents SHOULD prefer the manifest
        (which requires TLS cert verification against the site domain)
        over the query endpoint.  When DNSSEC is verified, agents MAY use
        the query endpoint without additional domain verification.
        OPTIONAL if manifest is present.

  12.2.3.  Absent or Invalid Records

     If no _anml TXT record exists for the asserted site domain, the agent
     MUST treat all third-party serving parties as Tier 0 for that site.
     The absence of a DNS record means the site has not published trust
     delegation — not that the site is absent or does not support ANML.

     A site domain MAY publish multiple _anml TXT records.  Agents MUST
     process all records with a recognized version tag.  If multiple
     records advertise both manifest and query URIs, agents SHOULD prefer
     the query endpoint.








  Jeskey                  Expires 22 November 2026               [Page 50]


  Internet-Draft                  ANML 1.0                        May 2026


     Sites SHOULD enable DNSSEC for their _anml records.  Agents SHOULD
     verify DNSSEC signatures where available.  A DNSSEC validation
     failure MUST be treated as a verification error — the agent MUST fall
     back to Tier 0 and MUST NOT treat the failure as equivalent to a
     missing record.

  12.3.  Static Trust Manifest

     The static Trust Manifest is a JSON document served at the URI
     advertised in the _anml DNS record.  It is appropriate for sites with
     a small, stable set of authorized partners requiring no additional
     infrastructure beyond a web server.  Served with Content-Type
     'application/anml-trust+json' over HTTPS from the site's canonical
     domain.

     {
       "site": "example.com",
       "version": "1.0",
       "issued": "2026-05-01T00:00:00Z",
       "expires": "2026-08-01T00:00:00Z",
       "authorized-domains": [
         {
           "domain": "*.cdn.example.com",
           "tier": 1,
           "scope": ["aesthetic", "body"],
           "note": "CDN — display only"
         },
         {
           "domain": "example.net",
           "tier": 2,
           "scope": ["aesthetic", "persona", "knowledge"],
           "note": "Authorized retailer"
         },
         {
           "domain": "example.org",
           "tier": 2,
           "scope": ["aesthetic", "persona", "knowledge", "interact"],
           "note": "Preferred retailer — full delegation"
         }
       ]
     }

     Fields:

     site  Canonical domain of the site.  REQUIRED.  Agents MUST verify
        this matches the domain in the _anml DNS record used to discover
        this manifest.  If it does not match, the manifest MUST be
        rejected and the agent MUST treat the serving party as Tier 0.



  Jeskey                  Expires 22 November 2026               [Page 51]


  Internet-Draft                  ANML 1.0                        May 2026


     version  Manifest format version.  REQUIRED.  Current: "1.0".

     issued  ISO 8601 datetime of issuance.  REQUIRED.

     expires  ISO 8601 datetime in UTC (Z suffix REQUIRED) at which this
        manifest expires.  REQUIRED.  RECOMMENDED maximum: 90 days from
        issued.  Agents MUST NOT use an expired manifest and MUST treat an
        expired manifest as equivalent to a missing manifest — Tier 0.

     authorized-domains  Array of authorization records.  REQUIRED.  An
        empty array means no third-party domains are authorized — all
        serving parties operate at Tier 0 for this site.

     Each authorization record:

     domain  Authorized domain or wildcard.  A wildcard of the form
        '*.example.com' matches any single DNS label prepended to
        'example.com' per RFC 1034, and does NOT match the apex domain
        itself or any multi-level subdomain.  REQUIRED.

     tier  Integer 1 or 2.  Normative.  Takes precedence over scope when
        they conflict.  REQUIRED.

     scope  Array of ANML section names the domain is authorized to
        assert.  Valid values: "head", "persona", "aesthetic",
        "knowledge", "interact", "constraints", "body", "footer".
        REQUIRED.

     note  Human-readable description.  OPTIONAL.

  12.4.  Live Trust Query Endpoint

     The live Trust Query endpoint allows a site to answer per-domain
     authorization queries in real time without publishing a manifest
     listing every authorized partner.  Appropriate for sites with large
     or frequently changing partner sets, or sites requiring real-time
     revocation.  The endpoint URI is authoritative because it is
     published in the site's own _anml DNS record.  When DNSSEC is
     verified for the _anml record, agents MAY use the query endpoint
     without additional TLS domain verification.  When DNSSEC is
     unavailable, agents SHOULD prefer the manifest, which requires TLS
     certificate verification against the site domain.









  Jeskey                  Expires 22 November 2026               [Page 52]


  Internet-Draft                  ANML 1.0                        May 2026


     Scope of this mechanism: the trust delegation defined in this section
     applies exclusively to ANML document serving parties.  It does not
     apply to Trust Manifest or Trust Query endpoint responses, which are
     processed as raw JSON data.  Agents MUST NOT apply ANML document
     parsing, trust tier evaluation, or <trust> element processing to
     responses received from Trust Manifest or Trust Query endpoints —
     these responses are authorization data, not ANML documents.

     Query:

  GET {query-uri}?domain={serving-domain}&scope={comma-separated-sections}
  Accept: application/json

     Example:

  GET https://trust.example.com/anml/authorize?domain=example.net&scope=persona,aesthetic,knowledge

     Response when authorized (HTTP 200):

     {
       "authorized": true,
       "tier": 2,
       "scope": ["persona", "aesthetic", "knowledge"],
       "expires": "2026-08-01T00:00:00Z"
     }

     Response when not authorized: the endpoint MUST return HTTP 404 (Not
     Found) with an empty body or minimal diagnostic JSON.  The endpoint
     MUST NOT return HTTP 200 with an "authorized": false body.  Returning
     404 for unauthorized domains prevents enumeration of a site's
     authorized partner list: an agent or third party probing the endpoint
     cannot distinguish "not authorized" from "we have no record of this
     domain," which limits competitive intelligence leakage.  Agents MUST
     treat a 404 response as a definitive negative authorization and MUST
     cache it as such for the duration of the applicable DNS TTL of the
     _anml record.

     Response fields (HTTP 200 only):

     authorized  Boolean true.  REQUIRED.  Always true in a 200 response —
        a negative result is indicated by HTTP 404, not by this field.

     tier  Integer 1 or 2.  REQUIRED.  Normative — takes precedence over
        the scope array if they conflict.

     scope  Array of authorized section names.  REQUIRED.  MAY be a subset
        of the requested scope.  The agent MUST use only the returned
        scope, not the requested scope.



  Jeskey                  Expires 22 November 2026               [Page 53]


  Internet-Draft                  ANML 1.0                        May 2026


     expires  ISO 8601 datetime in UTC (Z suffix REQUIRED) after which
        this authorization MUST be revalidated.  REQUIRED.  Agents MUST
        cache 200 responses until this time.  Agents SHOULD revalidate in
        the background before expiry to avoid authorization gaps.

     HTTP status codes:

     *  200 OK — domain is authorized.  Body contains tier, scope, and
        expires.

     *  404 Not Found — domain is not authorized.  Agent MUST cache this
        as a negative result.

     *  400 Bad Request — malformed query.  Agent MUST treat as Tier 0 and
        SHOULD log.

     *  429 Too Many Requests — agent MUST respect Retry-After and MUST
        treat as Tier 0 for the current interaction.

     *  5xx Server Error — transient.  Agent SHOULD fall back to the
        static manifest if available in the DNS record.  If unavailable,
        agent MUST treat as Tier 0.

     Cache key: agents MUST cache query results keyed on the tuple
     (serving-domain, site-domain).  The cached value is the full
     authorization record including tier, scope, and expires.  When a new
     request arrives, the agent checks the cache for (serving-domain,
     site-domain), retrieves the full authorization, and applies the
     intersection of the cached scope with the requested scope locally —
     without issuing a new network request.  The endpoint is queried at
     most once per (serving-domain, site-domain) pair per TTL period
     regardless of the scope requested.  The same cache key applies to
     both manifest lookups and query endpoint responses.

  12.5.  The trust Element and Verification Procedure

     An ANML document asserting a third-party site identity MUST include
     either a <trust> element in its <head> section (single-site
     documents) or a the <site> element with a domain attribute differing
     from the serving domain (multi-site documents).  Without one of
     these, the agent MUST treat all third-party site identity assertions
     as Tier 0.

     In single-site documents the <trust> element carries only the site
     domain — the agent discovers the manifest and query endpoints via
     DNS, keeping the ANML document itself free of authorization
     infrastructure details:




  Jeskey                  Expires 22 November 2026               [Page 54]


  Internet-Draft                  ANML 1.0                        May 2026


     <!-- Single-site -->
     <head>
       <title>Example Product 30 oz — Independent Retailer</title>
       <trust domain="example.com"/>
     </head>

     <!-- Multi-site -->
     <site domain="example.com">
       <persona>...</persona>
     </site>

     Attributes of <trust>:

     domain  Canonical domain of the site being asserted.  REQUIRED.  The
        agent uses this value to look up the _anml DNS TXT record.

     Agent verification procedure:

     1.  Extract site domain from <trust>/@site or <site>/@domain.

     2.  Look up _anml.{site-domain} TXT records via DNS.  If no record
         exists with a recognized version tag, treat as Tier 0.

     3.  Parse the record for manifest and query URIs.

     4.  Check cache for a valid non-expired authorization for the tuple
         (serving-domain, site-domain).  If found, use it and skip to step
         9.

     5.  If a query URI is advertised, send a query request per
         Section 12.4.  On 200 response, proceed to step 8.  On 5xx or
         network error, fall back to step 6.

     6.  If a manifest URI is advertised (and query was unavailable or
         failed), fetch the manifest over HTTPS.  Verify TLS certificate
         matches the site domain.  If fetch fails or certificate is
         invalid, treat as Tier 0.  Verify the manifest site field matches
         the asserted site domain.  Verify the manifest has not expired.

     7.  Search authorized-domains for the serving domain, using wildcard
         matching per RFC 1034.  If not found, treat as Tier 0.

     8.  Extract tier and scope from the query response or manifest entry.

     9.  Apply Tier 1 or Tier 2 permissions per Section 12.1.  Process
         only in-scope sections as site assertions.  Cache the result with
         its expiry.  Sections not in scope are treated as assertions of
         the serving domain only, subject to Tier 0 rules.



  Jeskey                  Expires 22 November 2026               [Page 55]


  Internet-Draft                  ANML 1.0                        May 2026


     Any verification failure at any step MUST result in Tier 0 for the
     asserted site.  Agents MUST NOT apply partial trust.  The serving
     domain's own identity is unaffected by a failed verification for a
     third-party site.

  12.6.  The site-ref Element

     A Tier 0 serving party that carries content from third-party sites
     MAY use <site-ref> to point agents to those sites' canonical ANML
     documents.  This is a pointer, not a delegation — the serving party
     makes no identity assertions about the referenced site.

     <head>
       <title>Independent Retailer — Outdoor Gear</title>
       <site-ref domain="example.com"
                 canonical="https://example.com/.well-known/anml"
                 relationship="carries-products"/>
     </head>

     Attributes:

     domain  Canonical domain of the referenced site.  REQUIRED.

     canonical  URI of the site's own ANML document.  Agents SHOULD fetch
        this URI for all <site-ref> elements present in a document when
        processing that document, up to an implementation-defined maximum
        number of site-ref fetches per document (RECOMMENDED maximum: 5).
        This is a mechanical rule — agents MUST NOT condition the fetch on
        an interpretation of user intent.  If the fetch fails or the TLS
        certificate is invalid, the agent MUST treat the referenced site
        as unknown and MUST NOT use any cached or inferred identity for
        it.  REQUIRED.

     relationship  Nature of the relationship.  Values from the ANML Site
        Relationship Values registry (Section 15.6).  OPTIONAL.

     A document fetched via <site-ref> is processed as a Tier 3 document —
     full trust from the canonical domain. <site-ref> does not elevate the
     serving party's trust tier.  The serving party's own identity
     sections remain subject to Tier 0 restrictions.











  Jeskey                  Expires 22 November 2026               [Page 56]


  Internet-Draft                  ANML 1.0                        May 2026


  12.7.  Multi-Site Documents and Layered Identity Attack Prevention

     A serving party MAY publish an ANML document that presents identity
     for both itself and authorized third-party sites.  This is a
     legitimate and common use case: a retailer's product page carries the
     retailer's own identity (interactions, service persona) alongside the
     product manufacturer's identity (product voice, aesthetic,
     knowledge).  The <site> wrapper element (Section 8.2) provides the
     structural mechanism for this.

     A document with identity assertions for more than one domain MUST use
     the multi-site content model: all identity sections are wrapped in
     <site> elements, one per domain.  This replaces the single-site
     content model where identity sections appear directly under <anml>.
     The structural separation of identity by domain prevents the layered
     identity attack described below.

     The layered identity attack: a malicious serving party blurs the
     boundary between its own assertions and those of a more trusted site,
     causing the agent to attribute the serving party's content to the
     trusted site, or to apply the trusted site's permission tier to the
     serving party's own sections.  The <site> wrapper prevents this by
     making domain attribution structural rather than attributional —
     there is no attribute to forge, only a wrapper element whose domain
     is verified independently.

     Normative rules for multi-site documents:

     *  Each <site> element's domain attribute MUST match exactly one
        domain.  The agent MUST apply trust tier verification
        independently to each <site> element whose domain differs from the
        serving domain.

     *  A Tier 2 authorization for one site MUST NOT elevate the trust
        tier of the serving domain's own <site> element.

     *  The agent MUST NOT merge or blend identity sections from different
        <site> elements.  Each site's persona, aesthetic, and knowledge
        are evaluated and applied independently.

     *  A <site> element containing an <interact> section is attributed
        exclusively to that site's domain.  The agent MUST NOT execute an
        action from a third-party <site> element unless the trust manifest
        for that site's domain explicitly includes "interact" in scope.

     *  If a <persona> or <instructions> element within any <site>
        references or attempts to invoke another site's identity, the
        agent MUST treat this as a prompt injection attempt.



  Jeskey                  Expires 22 November 2026               [Page 57]


  Internet-Draft                  ANML 1.0                        May 2026


     *  An agent MUST be able to explain to a user, on request, which
        identity assertions came from which site domain and at which trust
        tier.

     Example of a conforming multi-site document (example.net serving a
     Example Brand product page; example.net holds Tier 2 authorization
     from example.com for persona, aesthetic, and knowledge):

     <anml xmlns="urn:ietf:params:xml:ns:anml:1.0">

       <!-- example.net's own identity — serving domain, Tier 3, no verification -->
       <site domain="example.net">
         <head>
           <title>Example Product 30 oz — Example Retailer</title>
           <site-ref site="example.com"
                     canonical="https://example.com/.well-known/anml"
                     relationship="carries-products"/>
         </head>
         <persona>
           <tone value="helpful"/>
           <instructions>Assist the user with purchase and delivery
           questions for this order.</instructions>
         </persona>
         <interact>
           <action id="add-to-cart" method="POST"
                   endpoint="/cart/add" confirm="true"/>
         </interact>
       </site>

       <!-- Example Brand's authorized identity — Tier 2, scope verified by agent -->
       <!-- Agent automatically looks up _anml.example.com for verification -->
       <site domain="example.com">
         <persona>
           <tone value="rugged"/>
           <instructions>Speak to Example Brand's product quality, materials,
           and warranty. Do not discuss pricing or delivery.</instructions>
         </persona>
         <aesthetic>
           <display-name>Example Brand</display-name>
         </aesthetic>
         <knowledge>
           <inform>The Rambler 30 oz is made from 18/8 stainless steel
           and is dishwasher safe.</inform>
         </knowledge>
       </site>

     </anml>




  Jeskey                  Expires 22 November 2026               [Page 58]


  Internet-Draft                  ANML 1.0                        May 2026


     An agent processing this document MUST apply Example Brand's persona
     and knowledge only in the context of product information, apply
     example.net's persona for purchase and logistics, and attribute the
     add-to-cart action exclusively to example.net.  The agent MUST NOT
     represent the add-to-cart action as an example.com-defined
     interaction because "interact" is not in Example Brand's authorized
     scope for example.net.

     Note: the <trust> element used in single-site trust verification
     (Section 12.3) is replaced in multi-site documents by the domain and
     trust-manifest attributes on the <site> element.  Both mechanisms
     initiate the same agent verification procedure defined in
     Section 12.4.

  12.8.  Security Considerations for Trust Delegation

     The Trust Delegation mechanism is bounded by the security of the
     brand's canonical domain.  A compromised brand domain can issue
     fraudulent Trust Manifests.  Brands SHOULD:

     *  Set manifest expiry to 30-90 days maximum.

     *  Scope authorizations as narrowly as commercially necessary.

     *  Audit authorized-domains quarterly and remove inactive partners
        immediately.

     *  Use DNSSEC to prevent DNS-based manifest hijacking.

     *  Monitor for unauthorized <trust> elements claiming their domain
        from third-party sites.

     Agents MUST NOT:

     *  Accept Trust Manifests over unencrypted HTTP.

     *  Accept self-signed certificates for manifest endpoints.

     *  Cache manifests beyond their expires value.

     *  Apply a Tier 2 scope to a domain listed as Tier 1.

     *  Allow <site-ref> to elevate the serving party's trust tier.








  Jeskey                  Expires 22 November 2026               [Page 59]


  Internet-Draft                  ANML 1.0                        May 2026


  13.  Security Considerations

     ANML defines document structure and interaction semantics.  It does
     not enforce security, privacy, or access control at the protocol
     level.  Agent developers and service operators are responsible for
     implementing safety, privacy, and policy controls appropriate to
     their deployment context.  This section provides a structured threat
     model and MUST-level guidance for conforming implementations.

     ANML documents are processed by autonomous agents that may act
     without direct human oversight at each step.  The attack surface
     includes the document itself, the service publishing it, the agent
     processing it, and the transport layer.

  13.1.  Threat Model

     The following threat actors and scenarios are in scope for this
     specification:

     *  A malicious service publishing a crafted ANML document to
        manipulate agent behavior, extract user data, or cause the agent
        to execute harmful actions.

     *  A malicious agent submitting false or manipulated answers to
        exploit service logic, obtain resources it is not authorized to
        receive, or poison service-side state.

     *  A network adversary intercepting or modifying ANML documents in
        transit to alter interaction semantics or inject malicious
        content.

     *  A malicious document delivered via a compromised or typosquatted
        well-known URI, targeting agents that discover ANML documents
        automatically.

     *  An honest but misconfigured service that inadvertently exposes
        sensitive information through poorly specified ask elements or
        unconstrained inform elements.

     The following are explicitly out of scope: compromise of the agent
     runtime environment, attacks on the user's device or operating
     system, and attacks that exploit vulnerabilities in the underlying
     XML parser beyond those addressed in this section.








  Jeskey                  Expires 22 November 2026               [Page 60]


  Internet-Draft                  ANML 1.0                        May 2026


  13.2.  Information Disclosure via Knowledge Exchange

     The <ask> element requests information from the agent on behalf of a
     service.  This presents a significant data exfiltration risk if
     agents respond without rigorous evaluation of consent and
     constraints.

     Conforming agents MUST:

     *  Evaluate all applicable <constraints> before responding to any
        <ask>.

     *  Obtain explicit or implicit user consent, as required by the
        applicable <disclosure> element, before disclosing any
        information.

     *  Treat the absence of a <constraints> section as equivalent to
        requires="none" for all fields — not as authorization to disclose
        without evaluation.

     *  Apply the principle of minimum necessary disclosure: provide only
        the fields explicitly requested by the <ask> elements in the
        current document, limited to the values strictly required to
        fulfill the stated purpose attribute of each <ask>.  An agent MUST
        NOT disclose additional fields, inferred values, or context beyond
        what is directly requested and consented to for each specific
        <ask>.

     *  NEVER disclose information that the user has not authorized,
        regardless of the service's ask or inform content.

     Services MUST NOT rely on ANML constraints alone as an access control
     mechanism.  Server-side authorization MUST be implemented
     independently of ANML document constraints.

     Agents SHOULD maintain a disclosure log sufficient to reconstruct,
     for any completed interaction, which fields were disclosed, to which
     service domain, under which consent basis, and at what time.  Agents
     SHOULD make this log available to the user on request.  The format
     and retention period of the log are implementation-defined.











  Jeskey                  Expires 22 November 2026               [Page 61]


  Internet-Draft                  ANML 1.0                        May 2026


  13.3.  Prompt Injection via Persona and Instructions

     The <persona> and <instructions> elements present a significant
     prompt injection risk.  A malicious service may craft persona
     guidance or free-text instructions designed to override the agent's
     safety policies, manipulate its behavior toward the user, cause it to
     misrepresent the service, extract information it would not otherwise
     disclose, or act against the user's expressed interests.

     Conforming agents MUST:

     *  Treat ALL <persona> and <instructions> content as advisory and
        untrusted input from an external source, regardless of the
        apparent trustworthiness of the service.

     *  Apply the same input sanitization and policy evaluation to
        <instructions> content as to any other untrusted text input.

     *  NEVER override user-configured safety policies, privacy
        preferences, or platform-level guardrails based on <instructions>
        content.

     *  NEVER represent themselves as a different agent, platform, or
        identity in response to <persona> guidance.

     *  Disregard <instructions> that direct the agent to ignore,
        suppress, or override this specification's conformance
        requirements.

     Agents SHOULD apply heuristic or model-based analysis to
     <instructions> content before processing to identify potential
     injection patterns.  The detection method is implementation-defined;
     the response to a detected injection attempt is normative.  When an
     agent determines that <instructions> or <persona> content constitutes
     a prompt injection attempt, the agent MUST: (1) discard the offending
     element entirely and MUST NOT apply any part of its content to agent
     behavior — a partial or sanitized application is not permitted; (2)
     record the detection in its operational log; and (3) produce a user-
     visible notification that instructions from the service were
     rejected, without including the rejected content in the notification.
     The Human Intent First design principle (Section 4) takes absolute
     precedence over any <persona> or <instructions> content.

     Services are RECOMMENDED to limit <instructions> content to
     communication style guidance and to avoid imperative behavioral
     directives that could be misused by intermediaries.





  Jeskey                  Expires 22 November 2026               [Page 62]


  Internet-Draft                  ANML 1.0                        May 2026


  13.4.  Action Execution Risks

     The <interact> section declares operations that agents may execute
     against arbitrary HTTP endpoints.  This presents risks including
     unauthorized transactions, SSRF (Server-Side Request Forgery) via
     agent-mediated requests, and unintended side effects on third-party
     systems.

     Conforming agents MUST:

     *  Validate that the action endpoint is consistent with the origin of
        the ANML document before executing any action.

     *  Require explicit user confirmation before executing any action
        with confirm="true" or any action with significant real-world
        consequences (purchases, deletions, transmissions of personal
        data).

     *  Revalidate site trust authorization immediately before executing
        any action with confirm="true", any action producing a financial
        transaction, booking, or irreversible state change, or any action
        that discloses personal data.  Revalidation MUST query the trust
        endpoint or fetch the manifest fresh — a cached authorization
        result MUST NOT be used for these action classes regardless of its
        expires value.  This prevents execution of actions under trust
        authorization that has been revoked since document parse time.
        See Section 12 for the trust verification procedure.

     *  NEVER execute actions that conflict with user-expressed intent or
        platform safety policies.

     *  Apply rate limiting to action execution to prevent runaway
        automation.

     *  NOT follow action endpoint redirects to different origins without
        re-validating user intent.

     Services SHOULD use the idempotent attribute to indicate safe retry
     behavior and the confirm attribute for all consequential actions.

  13.5.  XML External Entity (XXE) Attacks

     Conforming agents and ANML document validators MUST NOT process
     DOCTYPE declarations, internal DTD subsets, or external entity
     references in ANML documents.  Conforming ANML documents SHOULD NOT
     include a DOCTYPE declaration.  If a DOCTYPE declaration is present,
     the agent MUST ignore it and MUST NOT resolve any entities defined
     within it.  Parsers configured to resolve external entities MUST NOT



  Jeskey                  Expires 22 November 2026               [Page 63]


  Internet-Draft                  ANML 1.0                        May 2026


     be used to parse ANML documents.

  13.6.  Agent Spoofing and Service Impersonation

     ANML does not define agent authentication mechanisms.  A service
     cannot cryptographically verify the identity of the agent submitting
     an answer, nor can an agent cryptographically verify that an ANML
     document originates from the claimed service without additional
     mechanisms.

     Services that require verified agent identity SHOULD use existing
     HTTP authentication mechanisms (OAuth 2.0, API keys, mutual TLS) in
     conjunction with ANML interactions.

     Agents SHOULD verify the TLS certificate of the service before
     processing an ANML document retrieved over HTTPS.  Agents SHOULD
     treat ANML documents retrieved over unencrypted HTTP as untrusted and
     MUST NOT submit <answer> responses to services communicating over
     unencrypted HTTP.

     Agents SHOULD apply heuristics to detect service impersonation,
     including verification that the well-known URI origin matches the
     domain of links and action endpoints in the document.

  13.7.  Malicious ANML Documents

     A malicious ANML document may attempt to exhaust agent resources
     through excessive nesting depth, very large element counts, unbounded
     <body> content, or circular references in <flow> elements.

     Conforming agents MUST impose implementation-defined limits on:

     *  Document size (RECOMMENDED maximum: 1MB)

     *  Element nesting depth (RECOMMENDED maximum: 32 levels)

     *  Number of <action> elements (RECOMMENDED maximum: 64 per document)

     *  Number of <ask> elements (RECOMMENDED maximum: 32 per document)

     *  Number of HTTP requests generated from processing a single
        document (RECOMMENDED maximum: 8)

     *  Total processing time per document

     Agents MUST detect and terminate processing of circular <flow>
     references.




  Jeskey                  Expires 22 November 2026               [Page 64]


  Internet-Draft                  ANML 1.0                        May 2026


  13.8.  Constraint Bypass

     The <constraints> section declares disclosure rules that conforming
     agents must evaluate.  However, a non-conforming or malicious agent
     may ignore these constraints entirely.  Services MUST NOT rely on
     ANML constraint declarations as the sole mechanism for protecting
     sensitive information.  Server-side access control, authentication,
     and authorization MUST be implemented independently.

     The absence of a <constraints> section does not imply authorization
     to disclose any particular information.  Agents MUST apply default-
     deny disclosure policies in the absence of explicit user consent.

  13.9.  Replay and State Manipulation

     An agent or network adversary may attempt to replay previously
     captured ANML responses or manipulate <state> content to advance or
     regress a multi-step workflow without authorization.

     Services MUST NOT trust agent-provided state values without
     independent server-side validation.  Services SHOULD use
     cryptographic nonces or session tokens to bind state to a specific
     interaction sequence.  Services MAY apply HTTP Message Signatures
     [RFC9421] to ANML responses to detect tampering.

  13.10.  Denial of Service

     Conforming agents SHOULD impose resource limits on ANML document
     processing as described in Section 11.7.  Services SHOULD apply rate
     limiting to ANML document endpoints, particularly well-known URIs
     which are publicly discoverable and may be targeted by automated
     crawlers.  Services SHOULD return HTTP 429 (Too Many Requests) with
     appropriate Retry-After headers when rate limits are exceeded.

  13.11.  Cross-Origin Considerations

     Agents SHOULD apply origin-based security policies when retrieving
     resources referenced within ANML documents, consistent with the same-
     origin policy principles established for web browsers.  Action
     endpoints that differ in origin from the ANML document SHOULD require
     additional user confirmation.  Agents SHOULD NOT automatically follow
     links or retrieve resources from origins not established in the
     initial ANML document without user awareness.








  Jeskey                  Expires 22 November 2026               [Page 65]


  Internet-Draft                  ANML 1.0                        May 2026


  13.12.  Transport Security

     Services MUST serve ANML documents over HTTPS with valid TLS
     certificates.  Agents MUST verify TLS certificates when retrieving
     ANML documents.  Agents MUST NOT submit <answer> elements containing
     personal information to services communicating over unencrypted HTTP.
     Agents SHOULD refuse to process <interact> action endpoints that
     specify HTTP (non-TLS) URIs unless the user has explicitly
     acknowledged the risk.

  14.  Privacy Considerations

     ANML introduces a structured mechanism for information exchange
     between services and agents acting on behalf of users.  This section
     addresses the privacy implications of that mechanism, with particular
     attention to the cross-session, cross-platform context portability
     enabled by the knowledge exchange framework.

  14.1.  User Control and Consent

     The foundational privacy principle of ANML is that the user controls
     what the agent discloses.  The <ask> / <answer> framework is designed
     as a consent mechanism, not a data extraction mechanism.  The
     following conformance requirements govern agent disclosure behavior:

     *  Agents MUST NOT disclose information in response to an <ask>
        without first evaluating applicable constraints and determining
        that disclosure is permitted.  This requirement is testable: a
        conforming agent presented with an <ask> and a <disclosure
        requires="explicit-consent"> constraint MUST NOT transmit the
        requested field value in an <answer> without that consent having
        been obtained.  The mechanism by which consent is obtained is
        implementation-defined.

     *  Agents MUST maintain a record of disclosure decisions sufficient
        to produce a disclosure log on request.  The format and retention
        period of this record are implementation-defined.  A conforming
        agent MUST be able to produce, upon request from the user or from
        a conformance test, a list of fields disclosed in a given
        interaction and the consent basis for each.

     *  Agents MUST support user-directed refusal: when a user instructs
        an agent to refuse all <ask> requests from a specific domain, the
        agent MUST respond to subsequent <ask> elements from that domain
        with <refuse reason="user-denied"> regardless of constraint
        configuration.  This requirement is testable.





  Jeskey                  Expires 22 November 2026               [Page 66]


  Internet-Draft                  ANML 1.0                        May 2026


     *  Agents MUST NOT disclose context received from one service domain
        to a different service domain without explicit per-disclosure user
        authorization.  This is testable: a conforming agent MUST NOT
        include in an <answer> to service B information that was received
        only via <inform> from service A.

     NOTE: requirements for specific user interface elements, consent
     dialog designs, or logging user interface features are outside the
     scope of this specification and are left to implementation.  The
     conformance requirements above are expressed in terms of agent
     behavior, not interface design.

  14.2.  Cross-Session and Cross-Platform Context Portability

     ANML's <inform> and <ask> / <answer> framework enables agents to
     carry context established in one session or with one service into
     subsequent sessions with other services.  This capability is
     intentionally designed to benefit users — allowing preferences,
     history, and relationship context to persist across platforms without
     centralized data storage.

     However, this same capability presents privacy risks if implemented
     without appropriate user controls:

     *  A service may attempt to obtain information about a user's
        interactions with other services by crafting <ask> elements that
        target context established elsewhere.

     *  An agent carrying context from a sensitive interaction (e.g., a
        healthcare provider) may inadvertently disclose that context to an
        unrelated service.

     *  Context carried by an agent may persist beyond the user's
        expectation or intent.

     Conforming agents MUST:

     *  Not disclose to service B context received exclusively from
        service A, without explicit authorization scoped to that cross-
        service disclosure.  This is testable: a conforming agent
        receiving <inform> from service A MUST NOT include that
        information in an <answer> to service B unless cross-service
        disclosure was explicitly authorized.

     *  Not disclose content marked confidentiality="private" to any
        service other than the one from which it was received.  This is
        testable: confidentiality="private" content MUST NOT appear in any
        <answer> or <inform> element sent to a different domain.



  Jeskey                  Expires 22 November 2026               [Page 67]


  Internet-Draft                  ANML 1.0                        May 2026


     *  Not disclose sensitive categories of information (health data,
        financial data, location history, as identified by the purpose
        attribute of the originating <ask>) to a service other than the
        one that requested it, without per-disclosure user authorization.
        This is testable by the presence of sensitive-category purpose
        values in disclosed answers to third-party services.

     *  Implement context deletion on user instruction: when a user
        instructs an agent to delete context associated with a specific
        service domain, the agent MUST NOT include that context in any
        subsequent <answer> or <inform> to any service.  Implementation of
        the deletion instruction interface is implementation-defined; the
        behavioral outcome is normative.

  14.3.  Data Minimization

     Services SHOULD request only the information necessary for the stated
     purpose of the interaction.  The purpose attribute of the <ask>
     element is REQUIRED to be present and accurate.  Agents SHOULD
     evaluate the stated purpose and decline to disclose information where
     the stated purpose is implausible, vague, or inconsistent with the
     nature of the service.

  14.4.  Usage Rights and Content Controls

     The usage attribute of <inform> and <rights> elements specifies what
     agents may do with content.  Conforming agents MUST respect usage
     declarations.  In particular:

     *  Content marked usage="none" MUST NOT be retained, cached, stored,
        or used for any purpose beyond immediate display in the current
        interaction.

     *  Content marked usage="display" MUST NOT be cached or stored beyond
        the current session.

     *  Content marked usage="cache" MAY be retained for the duration
        specified by the ttl attribute but MUST be discarded thereafter.

     *  Content marked usage="store" MAY be retained indefinitely subject
        to applicable data protection regulations.

     *  Content marked usage="train" MAY be used for model training,
        subject to the user's separate consent for their agent platform's
        training data policies.






  Jeskey                  Expires 22 November 2026               [Page 68]


  Internet-Draft                  ANML 1.0                        May 2026


     Usage declarations are service assertions and are not
     cryptographically enforced.  Agents are responsible for honoring
     them.  Services should not rely on usage declarations as the sole
     mechanism for protecting content.

  14.5.  Regulatory Considerations

     ANML implementations may be subject to data protection regulations
     including the EU General Data Protection Regulation (GDPR), the
     California Consumer Privacy Act (CCPA), the Health Insurance
     Portability and Accountability Act (HIPAA), and equivalent
     regulations in other jurisdictions.  This specification does not
     constitute legal advice.  Implementers are responsible for assessing
     and ensuring compliance with applicable regulations in their
     jurisdiction and use case.

     The consent framework provided by <constraints> and <disclosure>
     elements is designed to be compatible with GDPR explicit consent
     requirements for sensitive data categories.  However, ANML consent
     mechanisms are not a substitute for proper legal consent mechanisms
     required by applicable law.  Services operating in regulated contexts
     (healthcare, finance, government) MUST implement additional consent
     and data protection mechanisms beyond those specified in this
     document.

  15.  Relationship to Related Standards and Formats

     ANML addresses a problem space that intersects with several existing
     standards and formats.  This section clarifies how ANML relates to
     each and why a new specification is warranted rather than an
     extension of existing work.

  15.1.  HTML

     HTML is a presentation language for human consumption.  ANML is a
     semantic document format for machine consumption.  HTML encodes
     intent, interactions, and constraints implicitly through visual
     structure, JavaScript behavior, and user interface conventions that
     are inaccessible to agents without significant inference overhead.
     ANML makes these explicit.  ANML is designed to complement HTML, not
     replace it: a service may serve both an HTML interface for human
     users and an ANML document for agent consumers at the same URL via
     content negotiation.








  Jeskey                  Expires 22 November 2026               [Page 69]


  Internet-Draft                  ANML 1.0                        May 2026


  15.2.  JSON-LD and Schema.org

     JSON-LD is a method for encoding linked data in JSON, primarily used
     to provide structured data for search engine indexing and knowledge
     graph construction.  Schema.org defines a vocabulary of types and
     properties for describing entities on the web.

     ANML differs from JSON-LD and Schema.org in three fundamental
     respects:

     *  Interaction model: JSON-LD and Schema.org describe what things
        are.  ANML describes how to interact with a service — defining
        executable actions, multi-step workflows, and bidirectional
        knowledge exchange.  Schema.org has no equivalent of <interact>,
        <ask>, <answer>, or <state>.

     *  Consent framework: ANML defines a structured consent and
        disclosure model (<constraints>, <disclosure>, <refuse>) with no
        equivalent in JSON-LD or Schema.org.

     *  Agent behavioral guidance: ANML's <persona> section provides
        advisory guidance for agent communication style, brand voice, and
        vocabulary — a concern entirely outside the scope of linked data
        formats.

     ANML documents MAY reference Schema.org types within <body> content
     where appropriate.  The two standards are complementary rather than
     competing.

  15.3.  OpenAPI and AsyncAPI

     OpenAPI (formerly Swagger) and AsyncAPI define machine-readable
     interface descriptions for REST and event-driven APIs respectively.
     These formats describe how a developer should build a client that
     integrates with a specific service.

     ANML differs fundamentally in its discovery and integration model: an
     OpenAPI document describes a bespoke service contract that requires
     prior developer integration.  ANML provides a universal document
     format that any conforming agent can interpret without prior service-
     specific programming — analogous to the difference between a custom
     proprietary document format and HTML.  A browser does not need to be
     pre-programmed for each website; a conforming ANML agent does not
     need to be pre-programmed for each service.

     ANML action definitions are intentionally simpler than OpenAPI
     operation objects.  ANML is designed for agent-mediated user
     interactions, not developer API integration.



  Jeskey                  Expires 22 November 2026               [Page 70]


  Internet-Draft                  ANML 1.0                        May 2026


  15.4.  robots.txt and llms.txt

     robots.txt provides access control directives for web crawlers.
     llms.txt (an emerging informal convention) provides hints for LLM
     content consumption.  Neither defines structured interaction
     semantics, knowledge exchange, consent frameworks, or agent
     behavioral guidance.  ANML is a richer, structured interaction layer
     that subsumes the agent-guidance use case of llms.txt while providing
     substantially greater capability.

  15.5.  Rationale for XML Serialization

     ANML uses XML 1.0 as its primary serialization format.  This choice
     reflects several design considerations that distinguish ANML from API
     formats that use JSON:

     *  Human authoring: ANML documents are content artifacts designed to
        be authored and reviewed by humans — brand managers, content
        strategists, healthcare administrators — in addition to being
        parsed by machines.  The tag-based markup structure of XML is
        self-documenting in a way that JSON object notation is not.  A
        non-technical author can read and understand an ANML document
        without developer assistance.

     *  Namespace extensibility: XML Namespaces provide a well-
        established, IETF-precedented mechanism for extending ANML
        documents with domain-specific vocabularies without conflicting
        with the core specification.  This is essential for the vertical-
        specific profiles anticipated for healthcare, commerce, and
        government use cases.

     *  Document model: XML's document model, including processing order,
        whitespace handling, and character reference support, is
        appropriate for a format that carries rich text content in <body>,
        <instructions>, and <inform> elements.

     *  IETF precedent: XML-based formats have substantial precedent in
        IETF standards, including XMPP (RFC 6120), Atom (RFC 4287), and
        XML-based MIME type registrations.

     The analogy is instructive: HTML, which ANML complements, is also an
     XML-serializable markup language.  The choice of XML places ANML in
     the tradition of web content formats rather than API data formats —
     which accurately reflects its purpose.







  Jeskey                  Expires 22 November 2026               [Page 71]


  Internet-Draft                  ANML 1.0                        May 2026


     Future versions of this specification may define a JSON serialization
     (application/anml+json) for deployment contexts where XML parsing is
     impractical.  Any such serialization would be required to be
     semantically equivalent to the XML serialization defined herein.

  15.6.  Known Implementations

     The following implementations of this specification are known to the
     authors at the time of publication:

     *  Reference server implementations in Node.js/TypeScript, Python,
        Go, PHP, and Rust, maintained by the ANML Foundation at
        github.com/anmlfoundation/implementations.

     *  Reference client (agent-side) implementations in Node.js/
        TypeScript, Python, Go, PHP, and Rust, maintained by the ANML
        Foundation.

     *  Savo, the chat agent component of Life Savor AI (Ellevan), which
        implements ANML document discovery, parsing, and knowledge
        exchange as a production consumer agent.

     The ANML Foundation actively solicits additional independent
     implementations and maintains a registry of known implementations at
     anmlfoundation.org/implementations.  Organizations implementing this
     specification are encouraged to notify the Foundation at
     implementations@anmlfoundation.org to be included in the registry.

  16.  IANA Considerations

  16.1.  Media Type Registrations

     This document requests registration of three media types with IANA
     per [RFC6838]:

     *  'application/anml+xml' — as specified in Section 6.1 of this
        document.

     *  'application/anml+json' — as specified in Section 7.1 of this
        document.

     *  'application/anml-trust+json' — as specified below.

     Registration for application/anml-trust+json:

     Media Type name:  application

     Media subtype name:  anml-trust+json



  Jeskey                  Expires 22 November 2026               [Page 72]


  Internet-Draft                  ANML 1.0                        May 2026


     Required parameters:  none

     Optional parameters:  none

     Encoding considerations:  UTF-8 as specified in RFC 8259.  A BOM MUST
        NOT be prepended.

     Security considerations:  See Section 13.  Trust Manifest documents
        MUST be served over HTTPS.  Agents MUST verify the TLS certificate
        of the serving endpoint against the site domain specified in the
        associated _anml DNS record.  An expired Trust Manifest MUST be
        treated as equivalent to no manifest.

     Interoperability considerations:  Conforming agents MUST safely
        ignore unknown keys.  The site field MUST match the domain of the
        _anml DNS record used to discover this manifest.

     Published specification:  This document, Section 12.3.

     Applications that use this media type:  ANML agents performing site
        trust delegation verification.

     File extension(s):  none defined

  16.2.  Well-Known URI Registrations

     This document requests registration of the following Well-Known URIs
     per [RFC8615]:

     URI suffix:  anml

     Change controller:  IETF

     Specification document:  This document, Section 6.4.1

     Related information:  The /.well-known/anml URI is the primary ANML
        document discovery endpoint for a service.

     URI suffix:  anml-trust

     Change controller:  IETF

     Specification document:  This document, Section 12.3

     Related information:  The /.well-known/anml-trust URI is the static






  Jeskey                  Expires 22 November 2026               [Page 73]


  Internet-Draft                  ANML 1.0                        May 2026


        Trust Manifest endpoint for ANML Site Trust Delegation.  It serves
        a document of type application/anml-trust+json listing third-party
        domains authorized to assert the site's identity in ANML
        documents.  Discovery of this URI is via the _anml DNS TXT
        bootstrap record defined in Section 12.2.

  16.3.  ANML Standard Field Names Registry

     This document requests creation of a new IANA registry titled "ANML
     Standard Field Names".  The registry tracks standardized values for
     the field attribute of the <ask> and <answer> elements.

     Registration policy: Expert Review.

     Initial values: For personal information fields, implementations
     SHOULD use the property names defined in vCard version 4.0 [RFC6350]
     where applicable.  The following vCard property names are pre-
     registered as ANML standard field names with their RFC 6350
     semantics: fn, email, tel, adr, bday, gender, lang, tz, nickname,
     org, title, url.  Service-specific field names are permitted and are
     opaque to agents that do not recognize them.

     NOTE: A complete initial registry with full field definitions and
     type mappings is planned for draft-jeskey-anml-02.

  16.4.  XML Namespace Registration

     This document requests registration of the following XML namespace in
     the IETF XML Registry per RFC 3688:

     URI:  urn:ietf:params:xml:ns:anml:1.0

     Registrant Contact:  Aaron Jeskey, ajeskey@gmail.com

     XML:  None.  Namespace URIs do not identify retrievable resources.

  16.5.  ANML Usage Values Registry

     This document requests creation of a new IANA registry titled "ANML
     Usage Values".  The registry tracks permitted values for the usage
     attribute defined in this specification.

     Registration policy: Standards Action.

     Initial values:

     *  none — Content may not be retained, cached, stored, or used beyond
        immediate interpretation.



  Jeskey                  Expires 22 November 2026               [Page 74]


  Internet-Draft                  ANML 1.0                        May 2026


     *  display — Content may be displayed in the current session only.
        No caching or storage permitted.

     *  cache — Content may be cached for the duration of the applicable
        ttl.  Must be discarded after ttl expiry.

     *  store — Content may be retained indefinitely, subject to
        applicable data protection regulations.

     *  train — Content may be used for model training, subject to user
        consent for training data policies.

     The usage values form a normative hierarchy.  This hierarchy is
     defined here and is authoritative.  All other references to usage
     values in this specification are subject to this definition.

     none < display < cache < store < train

     Implication rules (normative): A usage value at a given level
     implicitly permits all uses at lower levels in the hierarchy.
     Specifically:

     *  usage="display" implies permission to display (none is also
        permitted).

     *  usage="cache" implies permission to display and cache for the ttl
        duration.

     *  usage="store" implies permission to display, cache, and store
        indefinitely.

     *  usage="train" implies permission to display, cache, store, and use
        for model training.

     An agent that stores content marked usage="cache" has violated the
     usage constraint.  An agent that uses content marked usage="store"
     for model training has violated the usage constraint.  These are
     normative requirements: agents MUST honor usage declarations.
     However, usage declarations are service-side assertions and are not
     cryptographically enforced.  Services MUST NOT rely on usage
     declarations as an access control mechanism.  This hierarchy is
     advisory in the sense that it cannot be technically enforced — it is
     normative in the sense that conforming agents MUST comply with it.








  Jeskey                  Expires 22 November 2026               [Page 75]


  Internet-Draft                  ANML 1.0                        May 2026


  16.6.  ANML Disclosure Requires Values Registry

     This document requests creation of a new IANA registry titled "ANML
     Disclosure Requires Values".  The registry tracks permitted values
     for the requires attribute of the <disclosure> element.

     Registration policy: Standards Action.

     Initial values:

     *  none — No consent requirement.  The agent MAY disclose the field
        value without user interaction, subject to the agent's own privacy
        policies.

     *  implicit-consent — The agent MAY infer consent from the user's
        initiation of the relevant interaction, without explicit per-field
        confirmation.

     *  explicit-consent — The agent MUST obtain explicit per-field user
        confirmation before disclosing.

     *  authentication — The agent MUST authenticate the user via an
        established mechanism before disclosing.  The specific
        authentication mechanism is defined by the service.

  17.  ANML Public Text

     The normative XML Schema (XSD) and an informative DTD for ANML 1.0
     are provided in the companion document ANML.md in the same repository
     as this Internet-Draft.

     A formal ABNF grammar [RFC5234] defining the structure of ANML
     documents, attribute value sets, and content negotiation headers WILL
     be provided in draft-jeskey-anml-02.  This is a committed deliverable
     for the next revision, not a tentative aspiration.  The XML Schema
     provided in the companion document serves as the normative structural
     definition for this revision.  For the JSON serialization, a JSON
     Schema is available at anmlfoundation.org/spec/anml-schema.json and
     is informative pending -02.

     NOTE: The namespace URI 'urn:ietf:params:xml:ns:anml:1.0' uses the
     'urn:ietf:params' prefix, which requires IETF approval via the IANA
     XML Namespace Registry per RFC 3688.  The IANA registration request
     for this namespace is included in Section 15.3 of this document.
     This namespace URI MUST NOT be considered assigned until IANA
     confirms the registration.  If a different namespace URI form is
     preferred prior to registration, the namespace URI throughout this
     document will be updated accordingly in a subsequent revision.



  Jeskey                  Expires 22 November 2026               [Page 76]


  Internet-Draft                  ANML 1.0                        May 2026


  17.1.  ANML Site Relationship Values Registry

     This document requests creation of a new IANA registry titled "ANML
     Site Relationship Values".  The registry tracks standardized values
     for the relationship attribute of the <site-ref> element.

     Registration policy: Expert Review.

     Initial values:

     *  carries-products — the serving site carries or retails products
        from the referenced site.

     *  licensed-distributor — the serving site is a licensed distributor
        of the referenced site's products or content.

     *  authorized-service — the serving site provides authorized service
        or support for the referenced site's products.

     *  official-partner — the serving site has an official partnership
        relationship with the referenced site.

     *  affiliate — the serving site participates in an affiliate
        relationship with the referenced site.

     *  content-aggregator — the serving site aggregates content from the
        referenced site.

     Implementations MUST accept and preserve unrecognized relationship
     values.  Agents SHOULD treat unrecognized values as equivalent to no
     relationship declaration — they do not affect trust tier
     determination.

  18.  References

  18.1.  Normative References

     [XML]      Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.,
                and F. Yergeau, "Extensible Markup Language (XML) 1.0
                (Fifth Edition)", W3C Recommendation, November 2008,
                <https://www.w3.org/TR/xml/>.

     [XMLNS]    Bray, T., Hollander, D., Layman, A., Tobin, R., and H.S.
                Thompson, "Namespaces in XML 1.0 (Third Edition)",
                W3C Recommendation, December 2009,
                <https://www.w3.org/TR/xml-names/>.





  Jeskey                  Expires 22 November 2026               [Page 77]


  Internet-Draft                  ANML 1.0                        May 2026


     [XMLMIME]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
                July 2014, <https://www.rfc-editor.org/info/rfc7303>.

     [UNICODE]  The Unicode Consortium, "The Unicode Standard",
                <https://www.unicode.org/versions/latest/>.

     [BCP47]    Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
                Languages", BCP 47, RFC 5646, September 2009,
                <https://www.rfc-editor.org/info/rfc5646>.

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

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

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

     [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003,
                <https://www.rfc-editor.org/info/rfc3629>.

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, January 2005,
                <https://www.rfc-editor.org/info/rfc3986>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

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

     [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
                specifying the location of services (DNS SRV)", RFC 2782,
                February 2000, <https://www.rfc-editor.org/info/rfc2782>.

  18.2.  Informative References






  Jeskey                  Expires 22 November 2026               [Page 78]


  Internet-Draft                  ANML 1.0                        May 2026


     [RFC1866]  Berners-Lee, T. and D. Connolly, "Hypertext Markup
                Language - 2.0", RFC 1866, November 1995,
                <https://www.rfc-editor.org/info/rfc1866>.

     [RFC2070]  Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
                "Internationalization of the Hypertext Markup Language",
                RFC 2070, January 1997,
                <https://www.rfc-editor.org/info/rfc2070>.

     [RFC3236]  Baker, M. and P. Stark, "The 'application/xhtml+xml' Media
                Type", RFC 3236, January 2002,
                <https://www.rfc-editor.org/info/rfc3236>.

     [RFC7992]  Hildebrand, J., Ed. and P. Hoffman, "HTML Format for
                RFCs", RFC 7992, December 2016,
                <https://www.rfc-editor.org/info/rfc7992>.

     [RFC9421]  Backman, A., Ed. and J. Richer, Ed., "HTTP Message
                Signatures", RFC 9421, February 2024,
                <https://www.rfc-editor.org/info/rfc9421>.

     [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", RFC 9111, June 2022,
                <https://www.rfc-editor.org/info/rfc9111>.

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

     [RFC9457]  Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
                for HTTP APIs", RFC 9457, October 2023,
                <https://www.rfc-editor.org/info/rfc9457>.

     [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
                August 2011, <https://www.rfc-editor.org/info/rfc6350>.

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

     [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
                "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376,
                September 2011, <https://www.rfc-editor.org/info/rfc6376>.

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




  Jeskey                  Expires 22 November 2026               [Page 79]


  Internet-Draft                  ANML 1.0                        May 2026


     [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
                RFC 1034, November 1987,
                <https://www.rfc-editor.org/info/rfc1034>.

     [RFC2606]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
                Names", RFC 2606, June 1999,
                <https://www.rfc-editor.org/info/rfc2606>.

     [UAX9]     The Unicode Consortium, "Unicode Bidirectional Algorithm",
                Unicode Standard Annex #9,
                <https://www.unicode.org/reports/tr9/>.

  Acknowledgments

     The design of ANML was informed by the structural patterns
     established in RFC 1866 [RFC1866], RFC 2070, RFC 3236 [RFC3236], and
     RFC 7992 [RFC7992].

     The authors thank the members of the ANML Foundation working groups
     and the IETF community for their review, feedback, and contributions
     to this specification.  The trust delegation mechanism benefited from
     extensive community discussion of the tradeoffs between static
     manifests, live query endpoints, and DNS-based discovery approaches.
     The dual serialization architecture was informed by feedback from
     both content practitioners and agent platform engineers who require
     different serialization characteristics in different deployment
     contexts.

  Author's Address

     Aaron Jeskey
     ANML Foundation
     Email: ajeskey@gmail.com
     URI:   https://github.com/ajeskey

















  Jeskey                  Expires 22 November 2026               [Page 80]


name: draft-liu-ztcpp-zt-problem-statement
rev: 00
title: Zero trust standards in IETF: use cases and problem statement
time: 2026-05-14T09:42:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-15T09:42:10Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:53.620598+00:00
source: ietf
abstract:
  The traditional "castle-and-moat" security paradigm is no longer
     effective for some emerging scenarios, such as cloud services, remote
     workforces and intelligent agents.  Zero trust (ZT) has emerged as
     the new paradigm, holding on the "never trust, always verify"
     principle, treats every single access request as untrudted and
     requires veficication.

     While a high-level atchitectural guidance exists, notably from NIST
     in SP 800-207 where thtenants of zero trust are well interperated,
     the industry lacks the open, interoperable framework and protocol
     necessary for building multi-vendor zero trust practice enrironment.
     This document presents the problem statement for zero trust
     interoperability, outlines the key use cases, and argue for the need
     for standardization in the IETF.  It discusses the possible scope for
     zero trust standardization work in the IETF, identifying which
     aspects are well suited for the IETF protocols and which are better
     addressed by other bodies.  The aim of this document is to initiate a
     discussion in the IETF community on the necessity and prospective of
     promoting zero trust related work here.

full_text:
  ZTCPP                                                             X. Liu
  Internet-Draft                                                   R. Yang
  Intended status: Informational                                  Y. Zhang
  Expires: 15 November 2026                           Pengcheng Laboratory
                                                               14 May 2026


       Zero trust standards in IETF: use cases and problem statement
                  draft-liu-ztcpp-zt-problem-statement-00

  Abstract

     The traditional "castle-and-moat" security paradigm is no longer
     effective for some emerging scenarios, such as cloud services, remote
     workforces and intelligent agents.  Zero trust (ZT) has emerged as
     the new paradigm, holding on the "never trust, always verify"
     principle, treats every single access request as untrudted and
     requires veficication.

     While a high-level atchitectural guidance exists, notably from NIST
     in SP 800-207 where thtenants of zero trust are well interperated,
     the industry lacks the open, interoperable framework and protocol
     necessary for building multi-vendor zero trust practice enrironment.
     This document presents the problem statement for zero trust
     interoperability, outlines the key use cases, and argue for the need
     for standardization in the IETF.  It discusses the possible scope for
     zero trust standardization work in the IETF, identifying which
     aspects are well suited for the IETF protocols and which are better
     addressed by other bodies.  The aim of this document is to initiate a
     discussion in the IETF community on the necessity and prospective of
     promoting zero trust related work here.

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



  Liu, et al.             Expires 15 November 2026                [Page 1]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Use cases . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Use Case 1: Secure Remote Access for Enterprise
             Resources . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.2.  Use case 2: secure service-to-service communication . . .   4
       4.3.  Use Case 3: Granular Access to Third-Party SaaS
             Applications  . . . . . . . . . . . . . . . . . . . . . .   4
       4.4.  Use Case 4: Secure Access for Autonomous AI Agents  . . .   4
     5.  Problem statement . . . . . . . . . . . . . . . . . . . . . .   5
       5.1.  Lack of interoperability  . . . . . . . . . . . . . . . .   5
       5.2.  Market Confusion  . . . . . . . . . . . . . . . . . . . .   5
       5.3.  Gap Analysis  . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Proposed Scope of Work for the IETF . . . . . . . . . . . . .   6
       6.1.  Control Plane Communication Protocol  . . . . . . . . . .   6
       6.2.  Dynamic Context and Signal Exchange Protocol  . . . . . .   7
       6.3.  Authenticated Session Establishment and Management  . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Traditional network security was built on the assumption of that
     every entity inside the perimeter were trusted by default.  This
     approach is increasingly ineffective in face of new use cases and
     sophisticateed attackers.





  Liu, et al.             Expires 15 November 2026                [Page 2]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


     Zero Trust (ZT) offers a fundamentally different approach.  As d
     efined in [NIST-SP-800-207], Zero Trust assumes no implicit trust is
     granted to assets or user accounts based solely on their physical or
     network location.  Instead, authentication and authorization are
     discrete, dynamic functions that must be performed before a session
     is established to an enterprise resource.  This is a "never trust,
     always verify" model.

     While this conceptual framework is powerful, its practical
     implementation is hampered by a lack of open standards.  Today's ZT
     solutions are largely proprietary, single-vendor ecosystems.  An
     organization cannot easily use a Policy Enforcement Point (PEP) from
     one vendor with a Policy Decision Point (PDP) from another.

     This document provides a gap analysis for zero trust standardization,
     as well as several typical use cases.  In additon, it also discusses
     the scope of standardization of zero trust in the IETF.

  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

     This document adopts the core terminology defined in
     [NIST-SP-800-207].

     Subject:  An entity (e.g., user, device, service, application, AI
        agent) that requests access to a resource.

     Resource:  A data source, service, device, or network component that
        a subject wishes to access.

     Policy Engine (PE):  The component responsible for the ultimate
        decision to grant or deny access to a resource for a given
        subject.

     Policy Administrator (PA):  The component responsible for
        establishing and/or shutting down the communication path between a
        subject and a resource.

     Policy Enforcement Point (PEP):  A system responsible for enabling,





  Liu, et al.             Expires 15 November 2026                [Page 3]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


        monitoring, and terminating connections between a subject and a
        resource.  The PEP communicates with the PA to forward requests
        and/or receive policy updates.

     Control Plane:  The logical network of communication that is used to
        manage the ZTA.  This includes communication between the PE, PA,
        and PEPs, as well as the collection of context and signals.

     Data Plane:  The logical network where subjects and resources
        communicate after access has been granted.

  4.  Use cases

     In this section we consider several emerging use cases where
     standardized ZT protocols would provide significant value.

  4.1.  Use Case 1: Secure Remote Access for Enterprise Resources

     A remote employee needs to access an internal application hosted in a
     private data center of an organization.

     1.  Subject: The employee's user identity and the device identity.
     2.  Resource: The internal application.

  4.2.  Use case 2: secure service-to-service communication

     A front-end web service running in a Kubernetes cluster in Cloud A
     needs to query a database service running in a VM in Cloud B.

     1.  Subject: The front-end web service, identified by a workload
         identity.
     2.  Resource: The database service.

  4.3.  Use Case 3: Granular Access to Third-Party SaaS Applications

     An organization wants to enforce device posture checks before
     allowing employees to access a third-party SaaS application .

     1.  Subject: The employee and their device.
     2.  Resource: The SaaS CRM application.

  4.4.  Use Case 4: Secure Access for Autonomous AI Agents

     An autonomous AI agent, acting on behalf of a user or system, needs
     to access a set of APIs to complete a task (e.g., booking travel).

     1.  Subject: The AI agent, possessing a cryptographically verifiable
         workload identity.



  Liu, et al.             Expires 15 November 2026                [Page 4]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


     2.  Resource: A set of airline, hotel, and payment gateway APIs.

  5.  Problem statement

     The implementation of zero trust is hindered by several key problems
     that may be addressed by standardization.

  5.1.  Lack of interoperability

     The core components of ZTA, PE, PA and PEP currently communicate with
     each other using proprietary protocols.  Different components from
     different vendors can barely communicate and interoperate with each
     other.  This makes an organization wishing to implenment ZTA system
     probably forced to source all components from one single vendor.
     This creates silos where the ZT system for employee access is
     completely separate from the ZT system for cloud service-to-service
     communication, even though the underlying principles are the same.  A
     unified approach requires common standards.

  5.2.  Market Confusion

     Without clear, protocol-level definitions and specifications, the
     term "zero trust" is often used as marketing buzzword rather than
     technology or product langauge.  Products with different capabilities
     and features can be all labeled as "zero trust enabled".
     Standardization can enhance clarity by clearly document the
     requirements for components to participate in ZTA system from the
     protocol and funtionality level.

  5.3.  Gap Analysis

     While the IETF and other SDOs have produced fundamental building
     blocks, there still lacks a complete, interoperable ZT standard
     framework.  A significant gap exists between the available components
     and a functioning ZTA control plane.  Specifically, the main gaps can
     be concluded as follows.

     1.  *A Standardized Control Plane Protocol:* This is the central gap.
         There is no standard protocol for a PEP to request an access
         decision from a PE, nor for the PE/PA to return a dynamic policy
         decision.  Today, this critical interaction is implemented with
         proprietary REST APIs with vendor-specific data models.









  Liu, et al.             Expires 15 November 2026                [Page 5]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


     2.  *A Standardized Signal Exchange Protocol:* A PE's decisions rely
         on continuous streams of context (signals).  While RATS defines
         attestation formats, there is no standard protocol for how
         diverse sources (EDR systems, threat feeds, IdPs) publish these
         signals and how a PE consumes them.  This prevents the creation
         of a multi- vendor "nervous system" for the ZTA.

     3.  *A Model for Dynamic, Fine-Grained Authorization:* OAuth scopes
         are often broad and long-lived.  ZT demands just-in-time, least-
         privilege access.  A standard is needed to model a request for,
         and issuance of, highly specific and ephemeral access rights
         (e.g., "grant subject X write access to record Y in database Z
         for the next 30 seconds").

     4.  *A framework for dynamic and continuous trust evaluation:* The
         core principle of Zero Trust is continuous verification.  This
         implies a mechanism for dynamically evaluating the
         trustworthiness of a subject over time.  While individual signals
         (like device posture or user location) are important, there is no
         standardized framework for aggregating these signals into a
         dynamic trust score or confidence level.  Furthermore, there is
         no standard protocol for how this trust score is updated in near-
         real-time and communicated to the Policy Engine to influence
         access decisions.  Defining such a framework would enable
         interoperable trust assessment modules and allow the PE to make
         more nuanced, risk-based decisions beyond a simple grant/deny.

  6.  Proposed Scope of Work for the IETF

     To be successful, an IETF effort must have a clearly defined scope.
     We propose focusing on the communication interfaces between ZTA
     components, directly addressing the gaps identified in Section 5.3.

  6.1.  Control Plane Communication Protocol

     The highest priority is to define a standard protocol for a PEP to
     request an access decision from a PE/PA and for the PE/PA to return a
     decision and policy configuration.  This could be a new protocol or a
     profile of an existing one (e.g., using HTTP APIs with a well-defined
     JSON data model).  It must specify how to represent the subject,
     resource, and context in a request, and how to represent grant, deny,
     or step-up authentication decisions in a response.









  Liu, et al.             Expires 15 November 2026                [Page 6]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


  6.2.  Dynamic Context and Signal Exchange Protocol

     A ZTA's decisions are only as good as the signals it receives.  A
     standardized protocol is needed for various sensors (e.g., EDR
     agents, threat intelligence feeds, IdPs) to publish signals to a
     centralized bus or directly to the PE.  This would allow a PE to
     consume signals from multiple vendors' security tools.  This work
     should align with and leverage concepts from the IETF RATS and SCITT
     working groups.

  6.3.  Authenticated Session Establishment and Management

     While TLS provides a secure channel, ZTA introduces new challenges.
     Work could be done to standardize how a PA instructs a PEP to
     establish a session.  This might involve profiling the use of
     existing protocols or defining mechanisms for securely delivering
     short-lived, session-specific credentials (e.g., tokens or
     certificates) to the subject and/or PEP as part of an access grant.

  7.  IANA Considerations

     This memo includes no request to IANA.

  8.  References

  8.1.  Normative References

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

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

     [NIST-SP-800-207]
                Rose, S., Borchert, O., Mitchell, S., and S. Connelly,
                "Zero Trust Architecture", August 2020,
                <https://csrc.nist.gov/publications/detail/sp/800-207/
                final>.

  8.2.  Informative References

  Authors' Addresses






  Liu, et al.             Expires 15 November 2026                [Page 7]


  Internet-Draft   Zero trust standards in IETF: use cases        May 2026


     Xiang Liu
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: liux15@pcl.ac.cn


     Rongwei Yang
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: yangrw@pcl.ac.cn


     Yu Zhang
     Pengcheng Laboratory
     No.2 Xingke 1 Street
     Shenzhen
     518055
     China
     Email: zhangy08@pcl.ac.cn


























  Liu, et al.             Expires 15 November 2026                [Page 8]


name: draft-hood-independent-agis
rev: 01
title: Agentic Grammar and Interface Specification (AGIS)
time: 2026-04-17T00:48:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-19T00:48:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:54.285020+00:00
source: ietf
abstract:
  This document defines the Agentic Grammar and Interface Specification
     (AGIS), a grammar-constrained interface definition language for
     Agentive APIs designed for consumption by large language model (LLM)
     based agents.  AGIS establishes structural and semantic rules
     governing how API methods and endpoints must be expressed, without
     mandating a fixed vocabulary of method names.  An implementation
     conforming to AGIS uses intent-expressing imperative verbs as method
     identifiers, enabling agents to infer operational meaning from method
     names without requiring training on a predefined catalog.

     AGIS is the native interface definition layer for the Agent Transfer
     Protocol (AGTP) [AGTP], in the same way that HTML functions as the
     native content language for the HTTP transport protocol.  AGIS does
     not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs
     the structural grammar of method and endpoint design that wraps those
     contracts.  AGIS-conformant methods are accepted at the AGTP
     transport layer via the Method-Grammar header without requiring prior
     IANA registration, enabling organizations to define domain-specific
     Agentive API vocabularies while preserving interoperability through
     shared grammatical constraints.

     Empirical validation of the core AGIS design principle is provided in
     [HOOD2026], which demonstrates a 10-29 percentage point accuracy
     advantage for intent-expressing method names over generic HTTP verbs
     across three frontier LLM families in 7,200 controlled trials.

     This version also introduces: normative YAML and JSON serialization
     formats; a Data Manifest block enabling services to declare available
     data without pre-built endpoints; a negotiable signal enabling AGTP
     dynamic endpoint instantiation; semantic declaration enhancements
     including is_idempotent, impact_tier, parameter_hints, and
     state_transition fields; vocabulary namespace disambiguation; and an
     HTTP transitional binding for incremental adoption.

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


             Agentic Grammar and Interface Specification (AGIS)
                       draft-hood-independent-agis-01

  Abstract

     This document defines the Agentic Grammar and Interface Specification
     (AGIS), a grammar-constrained interface definition language for
     Agentive APIs designed for consumption by large language model (LLM)
     based agents.  AGIS establishes structural and semantic rules
     governing how API methods and endpoints must be expressed, without
     mandating a fixed vocabulary of method names.  An implementation
     conforming to AGIS uses intent-expressing imperative verbs as method
     identifiers, enabling agents to infer operational meaning from method
     names without requiring training on a predefined catalog.

     AGIS is the native interface definition layer for the Agent Transfer
     Protocol (AGTP) [AGTP], in the same way that HTML functions as the
     native content language for the HTTP transport protocol.  AGIS does
     not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs
     the structural grammar of method and endpoint design that wraps those
     contracts.  AGIS-conformant methods are accepted at the AGTP
     transport layer via the Method-Grammar header without requiring prior
     IANA registration, enabling organizations to define domain-specific
     Agentive API vocabularies while preserving interoperability through
     shared grammatical constraints.

     Empirical validation of the core AGIS design principle is provided in
     [HOOD2026], which demonstrates a 10-29 percentage point accuracy
     advantage for intent-expressing method names over generic HTTP verbs
     across three frontier LLM families in 7,200 controlled trials.

     This version also introduces: normative YAML and JSON serialization
     formats; a Data Manifest block enabling services to declare available
     data without pre-built endpoints; a negotiable signal enabling AGTP
     dynamic endpoint instantiation; semantic declaration enhancements
     including is_idempotent, impact_tier, parameter_hints, and
     state_transition fields; vocabulary namespace disambiguation; and an
     HTTP transitional binding for incremental adoption.







  Hood                     Expires 19 October 2026                [Page 1]


  Internet-Draft                    AGIS                        April 2026


  Status of This Memo

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

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

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

     This Internet-Draft will expire on 19 October 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  The Natural Language Alignment Problem  . . . . . . . . .   4
       1.2.  Design Philosophy . . . . . . . . . . . . . . . . . . . .   5
       1.3.  Relationship to AGTP  . . . . . . . . . . . . . . . . . .   6
       1.4.  AGIS in the 2026 Agent Protocol Stack . . . . . . . . . .   7
       1.5.  Relationship to Standard Method Vocabulary  . . . . . . .   8
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.  AGIS Architecture . . . . . . . . . . . . . . . . . . . . . .  11
       3.1.  The Grammar Analogy . . . . . . . . . . . . . . . . . . .  11
       3.2.  Document Structure  . . . . . . . . . . . . . . . . . . .  11
       3.3.  Conformance Levels  . . . . . . . . . . . . . . . . . . .  12
     4.  Method Rules  . . . . . . . . . . . . . . . . . . . . . . . .  14
       4.1.  Syntactic Requirements  . . . . . . . . . . . . . . . . .  14
       4.2.  Semantic Class Requirements . . . . . . . . . . . . . . .  15
       4.3.  Prohibited Methods  . . . . . . . . . . . . . . . . . . .  18
     5.  Path Rules  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     6.  Semantic Declaration Requirements . . . . . . . . . . . . . .  19
       6.1.  Required Fields . . . . . . . . . . . . . . . . . . . . .  19



  Hood                     Expires 19 October 2026                [Page 2]


  Internet-Draft                    AGIS                        April 2026


       6.2.  Recommended Fields  . . . . . . . . . . . . . . . . . . .  20
       6.3.  Semantic Consistency Rule . . . . . . . . . . . . . . . .  22
     7.  JSON Schema Contract Requirements . . . . . . . . . . . . . .  22
     8.  Document Structure  . . . . . . . . . . . . . . . . . . . . .  23
       8.1.  Top-Level Fields  . . . . . . . . . . . . . . . . . . . .  23
       8.2.  Vocabulary Block  . . . . . . . . . . . . . . . . . . . .  24
       8.3.  Data Manifest Block . . . . . . . . . . . . . . . . . . .  25
     9.  Validation  . . . . . . . . . . . . . . . . . . . . . . . . .  26
       9.1.  Validation Passes . . . . . . . . . . . . . . . . . . . .  26
       9.2.  Validator Implementation Guidance . . . . . . . . . . . .  28
       9.3.  Conformance Testing . . . . . . . . . . . . . . . . . . .  29
     10. AGIS File Format  . . . . . . . . . . . . . . . . . . . . . .  29
       10.1.  HTTP Transitional Binding  . . . . . . . . . . . . . . .  30
     11. Agent Discovery Protocol  . . . . . . . . . . . . . . . . . .  34
       11.1.  Well-Known Discovery Endpoint  . . . . . . . . . . . . .  36
     12. Empirical Foundation  . . . . . . . . . . . . . . . . . . . .  37
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  39
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  41
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  41
       15.2.  Informative References . . . . . . . . . . . . . . . . .  42
     Appendix A.  Recommended Starter Vocabulary (Informative) . . . .  42
     Appendix B.  Comparison with Existing Approaches (Informative)  .  44
     Appendix C.  MCP Interoperability Bridge (Informative)  . . . . .  46
       C.1.  AGIS to MCP Mapping . . . . . . . . . . . . . . . . . . .  47
       C.2.  Auto-Generation Rules . . . . . . . . . . . . . . . . . .  47
       C.3.  MCP to AGIS Migration Path  . . . . . . . . . . . . . . .  48
       C.4.  References  . . . . . . . . . . . . . . . . . . . . . . .  49
       C.5.  Normative References  . . . . . . . . . . . . . . . . . .  49
       C.6.  Informative References  . . . . . . . . . . . . . . . . .  49
     Appendix D.  Author's Address . . . . . . . . . . . . . . . . . .  50
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  50

  1.  Introduction

     The Representational State Transfer (REST) architectural style
     [RFC7231] was designed for a specific class of consumer: the human
     developer.  A developer reading "POST /reservations" brings domain
     knowledge, understands HTTP verb semantics, consults documentation,
     and infers intent from context.  Large language model (LLM) based
     agents do not share this prior knowledge.  They process method names
     and paths as natural language tokens, matching them against user
     intent in real time without the contextual scaffolding that human
     developers rely upon.

     The consequence of this mismatch is empirically measurable.  Agents
     consuming REST/CRUD interfaces exhibit substantially lower endpoint
     selection accuracy than agents consuming semantically equivalent



  Hood                     Expires 19 October 2026                [Page 3]


  Internet-Draft                    AGIS                        April 2026


     interfaces expressed with intent-aligned method verbs.  The mechanism
     is the method name itself: generic HTTP verbs (GET, POST, PUT,
     DELETE) encode no intent-specific signal, requiring agents to infer
     purpose entirely from path structure and documentation text.  Intent-
     expressing verbs (BOOK, FIND, SCHEDULE, RECONCILE) encode operational
     meaning directly, enabling agents to match user goals to endpoint
     functions with higher precision and greater resilience to
     documentation noise [HOOD2026].

  1.1.  The Natural Language Alignment Problem

     Modern agentic systems operate on natural language instructions.  A
     user says "schedule a meeting for Thursday" or "book a table at the
     restaurant."  The agent must translate that natural language intent
     into a structured API call.  The quality of that translation depends
     substantially on how much semantic distance exists between the user's
     words and the available method identifiers.

     When the available method is POST /calendar/events, the agent must
     traverse a semantic chain: POST implies creation, /calendar/events
     implies calendar resource, and the combination implies event creation
     -- which may or may not match the user's intent to schedule a
     meeting.  Each step in the chain is an inference opportunity for
     error.

     When the available method is SCHEDULE /event, the semantic distance
     collapses.  "Schedule a meeting" maps directly to SCHEDULE.  The verb
     carries the intent.  The noun confirms the resource.  A single, low-
     ambiguity inference replaces a multi-step chain.

     AGIS is designed to systematically minimize semantic distance between
     natural language user intent and API method identifiers.  It does not
     prescribe which verbs to use.  It prescribes the grammatical class
     that verbs must belong to -- the action-intent class -- which is
     precisely the class of verbs that appear naturally in user
     instructions.  "Book", "find", "schedule", "cancel", "reconcile",
     "dispatch" are words users say.  AGIS requires that API methods be
     words of this type.

     Empirical research confirms that agents navigating unfamiliar AGIS-
     conformant service catalogs -- without knowing what methods exist in
     advance -- still performed better with semantic verbs than with CRUD.
     The agent did not need a dictionary.  It inferred intent from the
     verb itself, the same way it infers meaning from any natural language
     word it encounters [HOOD2026].  This validates the grammar-over-
     vocabulary architecture: agents can reason about any AGIS-conformant
     verb through natural language inference, making a predefined method
     catalog unnecessary for agent comprehension.



  Hood                     Expires 19 October 2026                [Page 4]


  Internet-Draft                    AGIS                        April 2026


  1.2.  Design Philosophy

     AGIS encapsulates what every API exchange has always required: a
     method (what to do), authorization (who can do it), and a data
     contract (what goes in and comes out).  The method is no longer GET
     or POST but BOOK or FIND.  The authorization is negotiated
     contextually via AGTP [AGTP] rather than pre-issued as a static key.
     The data contract is JSON Schema, unchanged.  AGIS is not a new idea.
     It is the right implementation of an old idea for a new class of
     consumer.

     The Foundation for Intelligent Physical Agents Agent Communication
     Language (FIPA-ACL) is the direct historical precedent.  FIPA-ACL
     defined approximately 25 fixed performatives -- REQUEST, INFORM,
     PROPOSE, ACCEPT-PROPOSAL, REJECT-PROPOSAL, QUERY-IF, CONFIRM -- each
     carried in a structured envelope with fields for sender, receiver,
     content, ontology, and conversation-id.  The performative was the
     verb giving the message its intent.  AGIS applies the same principle
     but replaces the fixed list of performatives with a grammar that
     accepts any action-intent verb.  FIPA-ACL was built for symbolic AI
     agents in JADE frameworks.  AGIS is its spiritual successor built for
     LLM agents that reason in natural language.

     AGIS operates on a principle borrowed from formal grammar: define the
     rules of the language without prescribing the vocabulary.  A grammar
     specification for English does not list every valid English word.  It
     defines the rules -- syntactic structure, part-of-speech
     requirements, conjugation patterns -- under which any word is a valid
     member of the language.

     In the same way, AGIS defines the rules under which any verb is a
     valid AGIS method.  This approach directly addresses the principal
     objection to fixed method vocabularies: that a library of defined
     methods is either too large to manage or too small to accommodate
     domain diversity.  AGIS eliminates the library entirely as a
     compliance mechanism.  The grammar is the standard.  Vocabulary is
     implementation-defined.

     Consider the restaurant analogy.  An organization's published AGIS
     document is the menu: pre-declared endpoints the agent can invoke
     directly.  The data_manifest block is the kitchen inventory: data
     classes the service holds even if no endpoint for them has been built
     yet.  When an agent arrives and cannot find what it needs on the
     menu, it can ask -- through the AGTP negotiation protocol -- "do you
     have location data?"  The service checks its kitchen (evaluates the
     data_manifest and authorization policy) and responds with a
     dynamically instantiated endpoint or a structured refusal.  The agent
     does not need to know the full kitchen inventory in advance.  It



  Hood                     Expires 19 October 2026                [Page 5]


  Internet-Draft                    AGIS                        April 2026


     needs to know the service exists, that it holds relevant data, and
     that off-menu requests are accepted.  This is what negotiable: true
     and the data_manifest block declare.

     The specification mandates:

     *  That methods be expressed as imperative base-form verbs

     *  That methods belong to the action-intent semantic class

     *  That methods be accompanied by machine-readable semantic
        declarations

     *  That implementations declare their vocabulary explicitly

     *  That all data contracts be expressed in JSON Schema [JSON-SCHEMA]

     The specification does not mandate which verbs to use.  Two
     organizations implementing AGIS-conformant APIs may use entirely
     different verb vocabularies.  BOOK /reservation and RESERVE /booking
     are both valid AGIS method-path combinations expressing the same user
     intent category.  An LLM agent encountering either service discovers
     and interprets it correctly through natural language inference -- the
     same inference capability demonstrated in two-stage discovery
     conditions in [HOOD2026].

     Compliance validation follows the grammar checker model.  A grammar
     checker does not validate that a writer chose the "right" words.  It
     validates that the words used are grammatically correct.  An AGIS
     validator performs the equivalent checks: that method identifiers are
     imperative base-form verbs, that they belong to the action-intent
     class, that semantic declarations are present and internally
     consistent, and that the document structure is well-formed.  Five
     structural checks.  Zero vocabulary judgments.

  1.3.  Relationship to AGTP

     AGIS is the interface definition layer for the Agent Transfer
     Protocol [AGTP].  The relationship between AGIS and AGTP mirrors the
     relationship between HTML and HTTP:











  Hood                     Expires 19 October 2026                [Page 6]


  Internet-Draft                    AGIS                        April 2026


            +===============+====================================+
            | Analogy       | AGTP/AGIS Stack                    |
            +===============+====================================+
            | HTTP          | AGTP -- transport protocol for     |
            |               | agent-to-service communication     |
            +---------------+------------------------------------+
            | HTML          | AGIS -- interface definition       |
            |               | language for Agentive APIs         |
            +---------------+------------------------------------+
            | Web browser   | Agent runtime -- consumer of AGIS  |
            |               | documents                          |
            +---------------+------------------------------------+
            | Web page      | AGIS service definition -- the     |
            |               | artifact served at an AGTP address |
            +---------------+------------------------------------+
            | W3C HTML      | This document -- the grammar       |
            | Specification | specification                      |
            +---------------+------------------------------------+

                    Table 1: AGIS/AGTP Structural Analogy

     An AGTP address (agtp://service.example.com) serves an AGIS document
     as its root response.  Agent runtimes retrieve, validate, and parse
     the AGIS document to build an internal service map before issuing
     method calls.  The AGIS document is both the service contract and the
     discovery artifact.

     AGTP version 03 [AGTP] introduces the Method-Grammar: AGIS/1.0
     header, which instructs the AGTP transport layer to validate method
     identifiers against AGIS grammar rules rather than checking the IANA
     registry exclusively.  This enables Tier 4 custom methods:
     organization-defined, AGIS-conformant verbs that are accepted at the
     transport layer without prior IANA registration.  The Tier 1 and Tier
     2 registered methods defined in [AGTP] and [AGTP-METHODS] are AGIS-
     conformant reference vocabulary and remain available for maximum
     cross-system interoperability.

  1.4.  AGIS in the 2026 Agent Protocol Stack

     AGIS occupies a distinct and complementary role in the 2026 agent
     protocol ecosystem.  Each layer solves a different problem:










  Hood                     Expires 19 October 2026                [Page 7]


  Internet-Draft                    AGIS                        April 2026


      +==========+=========================+============================+
      | Protocol | Role                    | Relationship to AGIS       |
      +==========+=========================+============================+
      | AGTP     | Transport, identity,    | AGIS is AGTP's native      |
      |          | governance, negotiation | interface definition layer |
      +----------+-------------------------+----------------------------+
      | MCP      | Tool and context access | AGIS services auto-        |
      |          | for LLM runtimes        | generate MCP tool entries  |
      |          |                         | (Appendix C)               |
      +----------+-------------------------+----------------------------+
      | A2A      | Agent-to-agent task     | AGIS well-known endpoints  |
      |          | coordination            | enable A2A service         |
      |          |                         | discovery                  |
      +----------+-------------------------+----------------------------+
      | AGIS     | Service interface       | Grammar layer defining     |
      |          | definition language     | what services declare and  |
      |          |                         | how agents read it         |
      +----------+-------------------------+----------------------------+

              Table 2: AGIS Role in the 2026 Agent Protocol Stack

     AGIS does not compete with MCP, A2A, or AGTP.  It is the missing
     service- contract layer that makes the ecosystem cohere.  An
     organization publishes an AGIS document; it is immediately readable
     by AGTP-native agents, auto-convertible to MCP tool entries for
     Claude and Cursor, discoverable by A2A orchestrators via the well-
     known endpoint, and validatable by any AGIS-conformant linter.  The
     grammar is the shared contract that all four protocol layers can
     consume.

  1.5.  Relationship to Standard Method Vocabulary

     The AGTP Standard Extended Method Vocabulary [AGTP-METHODS] defines a
     reference set of registered AGIS-conformant methods for common agent
     operations.  That document is the dictionary.  This document is the
     grammar.

     Organizations choosing methods from [AGTP-METHODS] gain
     interoperability across AGTP deployments.  Organizations defining
     their own AGIS-conformant vocabularies gain domain specificity.  Both
     approaches produce valid Agentive APIs.  The grammar constraint is
     the shared foundation that makes both approaches machine-
     interpretable by agents.








  Hood                     Expires 19 October 2026                [Page 8]


  Internet-Draft                    AGIS                        April 2026


  2.  Terminology

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

     Agentive API:  An API designed for consumption by LLM-based agents,
        implementing the AGIS grammar specification and served over the
        AGTP transport protocol.  Practitioners building Agentive APIs are
        said to build "AG-APIs."

     AGIS Document:  A file conforming to this specification that
        describes the methods, paths, semantic declarations, and JSON
        Schema contracts of an Agentive API service.  AGIS documents use
        the .agis file extension and the application/agis media type.

     AGIS Grammar Specification:  This document.  The normative rules
        governing what constitutes a valid AGIS method, path, semantic
        declaration, and document structure.

     Action-Intent Verb:  An imperative base-form verb that expresses an
        operation the caller intends to be performed on their behalf.  The
        semantic class required for all AGIS method identifiers.  Action-
        intent verbs are the class of verbs users naturally employ in
        natural language instructions: "book", "find", "schedule",
        "cancel", "reconcile."

     Imperative Base Form:  The uninflected command form of a verb.  BOOK
        is imperative base form.  BOOKING (present participle), BOOKS
        (third-person singular), and BOOKED (past tense) are not.  The
        form used when issuing instructions: "book a table", "find a
        restaurant", "schedule a meeting."

     Method Identifier:  The verb token used as an AGIS method name.
        Analogous to an HTTP method but constrained to the action-intent
        semantic class rather than fixed to a predefined set.

     Semantic Declaration:  A machine-readable block within an AGIS
        endpoint definition that describes intent, actor, and outcome in
        plain language.  Used by agent runtimes for discovery, validation,
        and inference.

     Vocabulary Block:  A required section of an AGIS document that
        declares all method identifiers used within the document.  Used by
        validators to verify declaration consistency and by agents to pre-
        index service capabilities.




  Hood                     Expires 19 October 2026                [Page 9]


  Internet-Draft                    AGIS                        April 2026


     Conforming Implementation:  An AGIS document or service that
        satisfies all REQUIRED and MUST-level rules defined in this
        specification.

     Agent Runtime:  A software component that retrieves, validates, and
        consumes AGIS documents to enable LLM-based agents to discover and
        invoke Agentive API services.

     Tier 4 Custom Method:  An organization-defined method that is AGIS-
        conformant but not registered in the IANA AGTP Method Registry.
        Accepted at the AGTP transport layer via the Method-Grammar:
        AGIS/1.0 header.  Discoverable by agents through the AGIS
        vocabulary block at the service's AGTP address.

     FIPA-ACL:  Foundation for Intelligent Physical Agents Agent
        Communication Language.  The historical predecessor to AGIS,
        defining ~25 fixed performatives (REQUEST, INFORM, PROPOSE,
        ACCEPT-PROPOSAL, etc.) in structured message envelopes.
        Implemented in JADE and similar frameworks for symbolic AI agent
        systems.  AGIS is FIPA-ACL's successor for LLM agents, replacing
        fixed performatives with a grammar-constrained open vocabulary.

     Data Manifest:  An optional block within an AGIS document that
        declares the data classes a service holds without defining pre-
        built endpoints.  Enables agents to assess whether a service has
        relevant data before initiating dynamic endpoint negotiation via
        AGTP [AGTP].  The data manifest is the ceiling of what a service
        will negotiate; it does not constitute a commitment to serve any
        specific endpoint format.

     Negotiable Service:  An AGIS-conformant service that supports dynamic
        endpoint instantiation via the AGTP negotiation protocol.  A
        negotiable service declares negotiable: true in its vocabulary
        block and MUST expose a data manifest describing available data
        classes.

     Proposed Endpoint:  An endpoint definition within an AGIS document
        that was dynamically instantiated during an AGTP negotiation
        session rather than pre-declared by the service.  Proposed
        endpoints carry a proposed: true flag and are session-scoped
        unless the service explicitly persists them.

     Impact Tier:  A categorical classification of endpoint consequence
        used alongside confidence_guidance to enable model-independent
        escalation reasoning.  Values are: Informational (read-only, no
        state change), Reversible (state change that can be undone),
        Irreversible (permanent state change or financial commitment).




  Hood                     Expires 19 October 2026               [Page 10]


  Internet-Draft                    AGIS                        April 2026


     State Transition:  A machine-readable description of the expected
        system state change produced by successful endpoint execution.
        Used by Level 2 conformant agent runtimes for post-execution
        verification.  Format: field: FROM_VALUE -> TO_VALUE.

  3.  AGIS Architecture

  3.1.  The Grammar Analogy

     AGIS is a grammar specification, not a method dictionary.  This
     distinction is architecturally fundamental and distinguishes AGIS
     from prior interface definition approaches that enumerate a fixed set
     of permitted operations.

     A grammar specification for natural language defines syntactic rules,
     part-of-speech categories, and semantic class constraints without
     listing every valid word in the language.  English grammar requires
     that verbs in imperative sentences be expressed in base form without
     specifying which verbs are permissible.  "Book a table" and "reserve
     a table" are both grammatically valid despite using different verbs,
     because both verbs satisfy the grammatical class requirements of the
     imperative form.

     AGIS applies this principle to API interface design.  The
     specification defines that method identifiers MUST be imperative
     base-form verbs belonging to the action-intent semantic class.  It
     does not enumerate which verbs satisfy this requirement.  Any verb
     satisfying the grammatical and semantic class rules is a valid AGIS
     method identifier.  Implementations choose their own vocabulary
     within these constraints.

     This architecture directly eliminates the "too many methods"
     objection to semantic method vocabularies.  The objection is a
     vocabulary objection: people argue about which specific verbs belong
     in a fixed list, whether 50 verbs is too many, whether LOCATE and
     FIND are redundant.  AGIS removes the list from the standard
     entirely.  There is no list to argue about.  There is only a grammar.
     Any verb satisfying the grammar is valid.

  3.2.  Document Structure

     An AGIS document is a structured text file using the .agis file
     extension.  It contains four principal components:

     Document Header:  Version declaration, service name, AGTP address,
        and optional metadata.

     Endpoint Definitions:  One or more method-path combinations, each



  Hood                     Expires 19 October 2026               [Page 11]


  Internet-Draft                    AGIS                        April 2026


        accompanied by a semantic declaration block and JSON Schema
        contracts.

     Schema Definitions:  JSON Schema objects defining input parameters,
        output structures, and error states for each endpoint.

     Vocabulary Block:  An explicit declaration of all method identifiers
        used in the document, with domain classification.

     The AGIS document is both the service contract and the discovery
     artifact.  When an agent runtime retrieves an AGIS document from an
     AGTP address, it obtains a complete specification of what the service
     can do, what each operation means, what data each operation requires,
     and what each operation returns.  No separate documentation is
     required for agent consumption.

  3.3.  Conformance Levels

     This specification defines four conformance levels.  All conforming
     implementations MUST satisfy Level 1.  Higher levels are OPTIONAL and
     represent progressive adoption paths.

        +===============+==================================+==========+
        | Level         | Description                      | Status   |
        +===============+==================================+==========+
        | Level 1 --    | AGIS document describes service  | REQUIRED |
        | Declarative   | interface.  No runtime behavior. |          |
        +---------------+----------------------------------+----------+
        | Level 2 --    | AGIS document drives runtime     | OPTIONAL |
        | Interpretable | routing and validation without   |          |
        |               | additional implementation code.  |          |
        +---------------+----------------------------------+----------+
        | Level 3 --    | AGIS includes constrained        | OPTIONAL |
        | Scriptable    | expression layer for conditions  |          |
        |               | and transformations.             |          |
        +---------------+----------------------------------+----------+
        | Level 4 --    | AGIS is a fully executable       | FUTURE   |
        | Executable    | interface language with complete |          |
        |               | runtime semantics.               |          |
        +---------------+----------------------------------+----------+

                        Table 3: AGIS Conformance Levels

     This specification defines Level 1 conformance requirements.
     Guidance for Level 2 implementations is provided as informative
     content.  Levels 3 and 4 are noted as future directions outside the
     scope of this document.




  Hood                     Expires 19 October 2026               [Page 12]


  Internet-Draft                    AGIS                        April 2026


     The following table summarizes which semantic declaration fields are
     REQUIRED, RECOMMENDED, or OPTIONAL at each conformance level:

      +=====================+=============+=============+==============+
      | Field               | Level 1     | Level 2     | Notes        |
      +=====================+=============+=============+==============+
      | intent              | REQUIRED    | REQUIRED    | All levels   |
      +---------------------+-------------+-------------+--------------+
      | actor               | REQUIRED    | REQUIRED    | All levels   |
      +---------------------+-------------+-------------+--------------+
      | outcome             | REQUIRED    | REQUIRED    | All levels   |
      +---------------------+-------------+-------------+--------------+
      | capability          | RECOMMENDED | REQUIRED    | Level 2      |
      |                     |             |             | requires for |
      |                     |             |             | routing      |
      +---------------------+-------------+-------------+--------------+
      | confidence_guidance | RECOMMENDED | REQUIRED    | Level 2      |
      |                     |             |             | requires for |
      |                     |             |             | governance   |
      +---------------------+-------------+-------------+--------------+
      | impact_tier         | RECOMMENDED | REQUIRED    | Level 2      |
      |                     |             |             | requires for |
      |                     |             |             | escalation   |
      +---------------------+-------------+-------------+--------------+
      | is_idempotent       | RECOMMENDED | REQUIRED    | Level 2      |
      |                     |             |             | requires for |
      |                     |             |             | retry logic  |
      +---------------------+-------------+-------------+--------------+
      | parameter_hints     | OPTIONAL    | RECOMMENDED | Improves     |
      |                     |             |             | parametric   |
      |                     |             |             | accuracy     |
      +---------------------+-------------+-------------+--------------+
      | state_transition    | OPTIONAL    | REQUIRED    | Level 2      |
      |                     |             |             | requires for |
      |                     |             |             | verification |
      +---------------------+-------------+-------------+--------------+
      | mcp_tool_name       | OPTIONAL    | OPTIONAL    | MCP bridge   |
      |                     |             |             | only         |
      +---------------------+-------------+-------------+--------------+

             Table 4: Semantic Declaration Field Requirements by
                              Conformance Level









  Hood                     Expires 19 October 2026               [Page 13]


  Internet-Draft                    AGIS                        April 2026


  4.  Method Rules

  4.1.  Syntactic Requirements

     An AGIS method identifier MUST satisfy the following syntactic rules:

     (a) The method identifier MUST be a single token containing no
     whitespace characters.

     (b) The method identifier MUST be expressed in the imperative base
     form of the verb.  Inflected forms including present participle
     (-ing), past tense (-ed), and third-person singular (-s) are NOT
     PERMITTED.

     (c) The method identifier MUST contain only uppercase alphabetic
     characters (A-Z).  Numerals, hyphens, underscores, and special
     characters are NOT PERMITTED.

     (d) The method identifier MUST NOT be a compound verb phrase.  Multi-
     word constructions are NOT PERMITTED.

     (e) The method identifier SHOULD be expressed in uppercase to
     distinguish it from path components.  Implementations MAY use mixed
     case; validators MUST treat method comparison as case-insensitive.

     Design rationale for single-token requirement:  Compound verb forms
        such as CANCEL_BOOKING or GENERATE_REPORT are explicitly
        prohibited.  The correct AGIS pattern separates verb and noun:
        CANCEL /booking, GENERATE /report.  This separation preserves the
        semantic density of the method identifier: CANCEL alone carries a
        complete action-intent signal; CANCEL_BOOKING dilutes it with path
        information already conveyed by the noun.  Single-token
        identifiers also maximize the cosine similarity between the method
        verb and the user's natural language instruction -- "cancel my
        booking" maps directly to CANCEL, not to CANCEL_BOOKING -- which
        is the mechanism empirically validated in [HOOD2026].
        Implementations that require compound semantics SHOULD use the
        AGIS path and semantic declaration rather than encoding them in
        the method identifier.

     The following examples illustrate syntactic compliance:










  Hood                     Expires 19 October 2026               [Page 14]


  Internet-Draft                    AGIS                        April 2026


        +===================+=========+===============================+
        | Method Identifier | Status  | Reason                        |
        +===================+=========+===============================+
        | BOOK              | VALID   | Single token, imperative base |
        |                   |         | form, uppercase alphabetic    |
        +-------------------+---------+-------------------------------+
        | FIND              | VALID   | Single token, imperative base |
        |                   |         | form, uppercase alphabetic    |
        +-------------------+---------+-------------------------------+
        | SCHEDULE          | VALID   | Single token, imperative base |
        |                   |         | form, uppercase alphabetic    |
        +-------------------+---------+-------------------------------+
        | RECONCILE         | VALID   | Single token, imperative base |
        |                   |         | form, uppercase alphabetic    |
        +-------------------+---------+-------------------------------+
        | BOOKING           | INVALID | Present participle -- not     |
        |                   |         | imperative base form          |
        +-------------------+---------+-------------------------------+
        | BOOK_TABLE        | INVALID | Contains underscore --        |
        |                   |         | compound form not permitted   |
        +-------------------+---------+-------------------------------+
        | book-reservation  | INVALID | Contains hyphen -- compound   |
        |                   |         | form not permitted            |
        +-------------------+---------+-------------------------------+
        | FindRestaurant    | INVALID | Compound form -- single token |
        |                   |         | required                      |
        +-------------------+---------+-------------------------------+
        | SEARCH2           | INVALID | Contains numeral --           |
        |                   |         | alphabetic only               |
        +-------------------+---------+-------------------------------+

                 Table 5: Method Identifier Syntactic Examples

  4.2.  Semantic Class Requirements

     Beyond syntactic validity, an AGIS method identifier MUST belong to
     the action-intent semantic class.  This class is defined as follows:

     Definition:  A verb belongs to the action-intent semantic class if it
        expresses an operation that the caller intends to have performed
        on their behalf, where the subject of the operation is an agent
        acting for a user or system goal.









  Hood                     Expires 19 October 2026               [Page 15]


  Internet-Draft                    AGIS                        April 2026


     The action-intent class requirement serves the core design goal of
     AGIS: enabling agents to infer operational purpose from method
     identifiers using natural language inference, without requiring a
     predefined vocabulary catalog.  A verb in the action-intent class
     corresponds directly to the class of verbs users employ when
     expressing intent in natural language instructions -- "book a table",
     "find a restaurant", "cancel my reservation", "schedule a meeting."

     A verb does NOT belong to the action-intent semantic class if it:

     *  Describes a state or condition rather than an action (e.g.,
        AVAILABLE, ACTIVE, OPEN, VALID)

     *  Describes a noun recast as a verb without expressing intent (e.g.,
        DATA used as a verb)

     *  Expresses existence or being rather than doing (e.g., EXISTS, IS,
        HAS)

     *  Is inherently ambiguous as to whether it expresses agent intent or
        system state

     The following examples illustrate semantic class compliance:




























  Hood                     Expires 19 October 2026               [Page 16]


  Internet-Draft                    AGIS                        April 2026


        +============+===============+===============================+
        | Method     | Semantic      | Reason                        |
        | Identifier | Class Status  |                               |
        +============+===============+===============================+
        | BOOK       | Action-intent | Expresses intent to create a  |
        |            |               | booking                       |
        +------------+---------------+-------------------------------+
        | FIND       | Action-intent | Expresses intent to locate a  |
        |            |               | resource                      |
        +------------+---------------+-------------------------------+
        | CANCEL     | Action-intent | Expresses intent to terminate |
        |            |               | a booking                     |
        +------------+---------------+-------------------------------+
        | AUTHORIZE  | Action-intent | Expresses intent to grant     |
        |            |               | permission                    |
        +------------+---------------+-------------------------------+
        | TRIAGE     | Action-intent | Expresses intent to           |
        |            |               | prioritize and route          |
        +------------+---------------+-------------------------------+
        | DISPATCH   | Action-intent | Expresses intent to send or   |
        |            |               | route a resource              |
        +------------+---------------+-------------------------------+
        | RESERVE    | Action-intent | Expresses intent to hold a    |
        |            |               | resource                      |
        +------------+---------------+-------------------------------+
        | LOCATE     | Action-intent | Expresses intent to find a    |
        |            |               | specific resource             |
        +------------+---------------+-------------------------------+
        | AVAILABLE  | NOT action-   | Describes state, not action   |
        |            | intent        |                               |
        +------------+---------------+-------------------------------+
        | ACTIVE     | NOT action-   | Describes condition, not      |
        |            | intent        | operation                     |
        +------------+---------------+-------------------------------+
        | EXISTS     | NOT action-   | Describes existence, not      |
        |            | intent        | intent                        |
        +------------+---------------+-------------------------------+
        | PROCESS    | Borderline    | May express intent or         |
        |            |               | describe system state; a more |
        |            |               | specific verb is RECOMMENDED  |
        +------------+---------------+-------------------------------+

              Table 6: Method Identifier Semantic Class Examples

     Note that RESERVE and LOCATE are valid AGIS methods even though BOOK
     and FIND serve equivalent purposes in the AGTP registered vocabulary.
     AGIS does not prohibit synonymous verbs across implementations.  Two
     organizations may use BOOK and RESERVE for the same operation type;



  Hood                     Expires 19 October 2026               [Page 17]


  Internet-Draft                    AGIS                        April 2026


     both are AGIS-conformant.  An agent encountering RESERVE infers its
     meaning through natural language inference -- the same mechanism
     demonstrated in two-stage discovery conditions in [HOOD2026].

  4.3.  Prohibited Methods

     The following method identifiers are explicitly prohibited in AGIS
     implementations regardless of syntactic or semantic class validity,
     to prevent ambiguity with HTTP methods and established protocol
     conventions:

     Prohibited:  GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, CONNECT,
                  TRACE

     Rationale:  These identifiers carry HTTP-specific semantics that
                 conflict with the AGIS design principle. Their use
                 would create ambiguity for agents transitioning between
                 HTTP/REST and AGTP/AGIS service contexts.

  5.  Path Rules

     The path component of an AGIS endpoint identifies the entity upon
     which the method operates.  The following rules apply:

     (a) The path MUST begin with a forward slash character (/).

     (b) The first path segment MUST be a noun or noun phrase identifying
     the primary entity type.  Verb forms are NOT PERMITTED in path
     segments.

     (c) Multi-word path segments MUST use hyphen-separated lowercase
     notation (e.g., /patient-record, /delivery-order).

     (d) Parameterized path segments identifying specific resource
     instances MUST use curly-brace notation (e.g., /reservation/{id},
     /order/{order_id}).

     (e) The path MUST NOT duplicate the method verb.  A method of BOOK
     with a path of /book-reservation violates this rule.

     (f) Query string parameters MUST NOT appear in path definitions.
     Variable inputs are defined in the JSON Schema input block.

     The following examples illustrate path compliance:







  Hood                     Expires 19 October 2026               [Page 18]


  Internet-Draft                    AGIS                        April 2026


      +==========================+=========+============================+
      | Path                     | Status  | Reason                     |
      +==========================+=========+============================+
      | /reservation             | VALID   | Noun, lowercase, begins    |
      |                          |         | with /                     |
      +--------------------------+---------+----------------------------+
      | /restaurant/{id}         | VALID   | Noun with parameterized    |
      |                          |         | identifier                 |
      +--------------------------+---------+----------------------------+
      | /patient-record/{id}     | VALID   | Hyphenated noun phrase     |
      |                          |         | with identifier            |
      +--------------------------+---------+----------------------------+
      | /calendar/event/{id}     | VALID   | Hierarchical noun path     |
      +--------------------------+---------+----------------------------+
      | /bookReservation         | INVALID | Verb in path               |
      +--------------------------+---------+----------------------------+
      | /get-restaurant          | INVALID | Verb in path               |
      +--------------------------+---------+----------------------------+
      | /reservation?type=dinner | INVALID | Query string in path       |
      |                          |         | definition                 |
      +--------------------------+---------+----------------------------+
      | /RESERVATION             | INVALID | Uppercase -- path segments |
      |                          |         | MUST be lowercase          |
      +--------------------------+---------+----------------------------+

                         Table 7: Path Syntax Examples

  6.  Semantic Declaration Requirements

     Every endpoint in an AGIS document MUST include a semantic
     declaration block.  The semantic declaration provides machine-
     readable descriptions that agent runtimes use for service discovery,
     intent matching, and confidence-based execution decisions.

  6.1.  Required Fields

     intent (REQUIRED):  A single sentence in plain natural language
        describing what this endpoint does on behalf of the caller.  The
        intent statement MUST be written in terms of the agent's goal, not
        the system's internal operation.  "Books a restaurant reservation
        on behalf of the requesting agent" is a valid intent statement.
        "Inserts a record into the reservations table" is NOT a valid
        intent statement for AGIS purposes.

     actor (REQUIRED):  Identifies who or what initiates the action.  MUST
        be one of:





  Hood                     Expires 19 October 2026               [Page 19]


  Internet-Draft                    AGIS                        April 2026


        agent   -- The calling LLM-based agent initiates on behalf of a user
        user    -- A human user initiates directly
        system  -- An automated system process initiates

     outcome (REQUIRED):  A single sentence describing the state that
        exists after successful execution of this endpoint.  The outcome
        statement MUST describe a verifiable post-condition.  "A confirmed
        reservation record exists in the system with status CONFIRMED" is
        a valid outcome statement.

  6.2.  Recommended Fields

     capability (RECOMMENDED):  Classifies the endpoint within a
        controlled capability taxonomy.  Enables agent runtimes to filter
        and route by capability class without parsing intent statements.
        MUST be one of the following if present:

        discovery     -- Endpoint locates or returns matching resources
        transaction   -- Endpoint creates or commits an irreversible action
        modification  -- Endpoint updates an existing resource
        retrieval     -- Endpoint returns information about a known resource
        analysis      -- Endpoint processes data and returns derived results
        notification  -- Endpoint triggers a communication or alert

     confidence_guidance (RECOMMENDED):  A floating-point value between
        0.0 and 1.0 specifying the minimum agent confidence threshold
        RECOMMENDED before autonomous execution of this endpoint.
        Endpoints with irreversible consequences (EXECUTE, CANCEL,
        TRANSFER) SHOULD declare a confidence_guidance of 0.85 or higher.
        Discovery and retrieval endpoints MAY declare lower thresholds.
        Agent runtimes SHOULD surface escalation options to users when
        agent confidence falls below the declared threshold.  This field
        directly addresses the confidence calibration failure documented
        in [HOOD2026], in which description mismatch conditions produced
        +60 percentage point overconfidence errors.

     impact_tier (RECOMMENDED):  A categorical consequence classification
        providing a model-independent complement to confidence_guidance.
        Enables agent runtimes to apply appropriate reasoning loops
        regardless of the specific floating-point value.  MUST be one of
        the following if present:

        informational  -- Read-only; no system state change occurs
        reversible     -- State change that can be undone (e.g., cancel a booking)
        irreversible   -- Permanent state change or financial commitment






  Hood                     Expires 19 October 2026               [Page 20]


  Internet-Draft                    AGIS                        April 2026


        Endpoints declaring irreversible SHOULD also declare
        confidence_guidance: 0.85 or higher.  Agent runtimes encountering
        an irreversible endpoint SHOULD require explicit user confirmation
        regardless of confidence score.

     is_idempotent (RECOMMENDED):  A boolean indicating whether multiple
        identical invocations of this endpoint produce the same result as
        a single invocation.  Agents use this field to determine whether
        automatic retry is safe on network failure.  BOOK and TRANSFER are
        typically not idempotent.  FIND and QUERY are typically
        idempotent.  Defaults to false if absent.

     parameter_hints (RECOMMENDED):  A map from parameter names to natural
        language phrases that commonly refer to those parameters in user
        instructions.  Enables agents to map fuzzy natural language input
        (e.g., "next Tuesday", "for two people") to specific schema fields
        without requiring exact vocabulary match.  Example:

        parameter_hints:
          party_size: ["number of guests", "for N people", "party of N",
                       "table for N"]
          datetime:   ["next Tuesday", "tomorrow night", "Saturday at 7",
                       "this weekend"]

     state_transition (RECOMMENDED for Level 2):  A machine-readable
        description of the expected system state change produced by
        successful execution.  Enables Level 2 conformant agent runtimes
        to verify post-execution outcomes without parsing the natural
        language outcome statement.  Format: field: FROM -> TO.  Example:

        state_transition:
          reservation.status: NONE -> CONFIRMED
          reservation.id: NULL -> [assigned]

        Level 2 conformance REQUIRES this field to be present on all
        endpoints that produce state changes.

     mcp_tool_name (OPTIONAL):  An override for the tool name generated
        when this endpoint is auto-converted to an MCP tools/list entry
        (see Appendix C).  When absent, the default auto-generation rule
        applies: METHOD_pathsegment in lowercase (e.g., BOOK /reservation
        -> book_reservation).  Use this field when the default name
        conflicts with an existing MCP tool in the same service catalog,
        or when a more descriptive name is needed for MCP client
        discoverability.

        mcp_tool_name: make_reservation




  Hood                     Expires 19 October 2026               [Page 21]


  Internet-Draft                    AGIS                        April 2026


        The mcp_tool_name MUST be lowercase, MAY contain underscores, and
        MUST be unique within the service's generated MCP catalog.  When
        parameter_hints are declared, they SHOULD be appended to the MCP
        tool description to enrich MCP client elicitation behavior.

  6.3.  Semantic Consistency Rule

     The intent field of a semantic declaration MUST be semantically
     consistent with the method identifier.  A validator MUST flag as non-
     conformant any endpoint where the stated intent contradicts the
     operation implied by the method verb.

     Examples of consistency violations:

     *  Method: BOOK | Intent: "Returns a list of available restaurants"
        -- VIOLATION.  BOOK implies creation/commitment; the intent
        describes retrieval.

     *  Method: FIND | Intent: "Creates a new reservation in the system"
        -- VIOLATION.  FIND implies discovery; the intent describes
        creation.

     *  Method: CANCEL | Intent: "Retrieves cancellation policy" --
        VIOLATION.  CANCEL implies termination; the intent describes
        retrieval.

  7.  JSON Schema Contract Requirements

     AGIS does not define a data contract language.  JSON Schema
     [JSON-SCHEMA] is used for all input parameter and output response
     definitions.  Every AGIS endpoint MUST include the following JSON
     Schema blocks:

     input (REQUIRED):  A JSON Schema object defining the parameters
        accepted by this endpoint.  MUST distinguish required parameters
        from optional parameters using the JSON Schema "required" array.
        Parameter names SHOULD use snake_case.

     output (REQUIRED):  A JSON Schema object defining the structure of a
        successful response from this endpoint.

     errors (REQUIRED):  An array of named error conditions that this
        endpoint may return.  Each error condition MUST be named and
        SHOULD include a description.  Generic error names (e.g., "error",
        "failure") are NOT RECOMMENDED.  Specific descriptive error names
        (e.g., "reservation_unavailable", "invalid_datetime",
        "restaurant_not_found") are REQUIRED for conformance.




  Hood                     Expires 19 October 2026               [Page 22]


  Internet-Draft                    AGIS                        April 2026


     The following illustrates a conformant JSON Schema block for an
     endpoint:

     input:
       required:
         - restaurant_id  (integer)
         - party_size     (integer, minimum: 1, maximum: 20)
         - datetime       (string, format: date-time, ISO 8601)
       optional:
         - preferences    (string)
         - contact_name   (string)

     output:
       reservation_id     (string)
       status             (string, enum: [CONFIRMED, PENDING])
       confirmation_code  (string)
       datetime           (string, format: date-time)

     errors:
       - reservation_unavailable
       - invalid_datetime
       - restaurant_not_found
       - party_size_exceeds_capacity

  8.  Document Structure

  8.1.  Top-Level Fields

     An AGIS document MUST contain the following top-level fields:






















  Hood                     Expires 19 October 2026               [Page 23]


  Internet-Draft                    AGIS                        April 2026


        +=============+=============+================================+
        | Field       | Status      | Description                    |
        +=============+=============+================================+
        | agis        | REQUIRED    | AGIS specification version.    |
        |             |             | Current value: "1.0"           |
        +-------------+-------------+--------------------------------+
        | service     | REQUIRED    | Human-readable service name    |
        +-------------+-------------+--------------------------------+
        | agtp        | REQUIRED    | The AGTP address at which this |
        |             |             | service is available           |
        +-------------+-------------+--------------------------------+
        | endpoints   | REQUIRED    | Array of one or more endpoint  |
        |             |             | definitions                    |
        +-------------+-------------+--------------------------------+
        | vocabulary  | REQUIRED    | Vocabulary block (see          |
        |             |             | Section 8.2)                   |
        +-------------+-------------+--------------------------------+
        | description | RECOMMENDED | Human-readable service         |
        |             |             | description                    |
        +-------------+-------------+--------------------------------+
        | version     | RECOMMENDED | Implementation version of this |
        |             |             | service                        |
        +-------------+-------------+--------------------------------+
        | schemas     | OPTIONAL    | Shared JSON Schema definitions |
        |             |             | referenced by endpoints        |
        +-------------+-------------+--------------------------------+

                   Table 8: AGIS Document Top-Level Fields

  8.2.  Vocabulary Block

     Every AGIS document MUST include a vocabulary block at the document
     level.  The vocabulary block declares all method identifiers used in
     the document and provides domain classification.  This block enables
     validators to verify declaration consistency and enables agent
     runtimes to pre-index service capabilities before parsing individual
     endpoints.

     The vocabulary block MUST satisfy the following:

     (a) Every method identifier used in an endpoint definition MUST be
     listed in the declared_verbs array.

     (b) Every method identifier listed in declared_verbs MUST be used in
     at least one endpoint definition.  Declared but unused verbs
     constitute a non-conformance.





  Hood                     Expires 19 October 2026               [Page 24]


  Internet-Draft                    AGIS                        April 2026


     (c) The domain field SHOULD identify the primary service domain using
     a plain-language descriptor (e.g., hospitality, healthcare,
     financial-services, logistics).

     (d) The optional namespace field provides a scoped qualifier to
     disambiguate verb semantics when agents hold multiple service maps
     simultaneously.  Agents SHOULD use namespace to distinguish between
     identically-named verbs from different services (e.g.,
     logistics.DISPATCH vs workflow.DISPATCH).  Format: domain.VERB at
     runtime resolution.

     (e) The optional negotiable field signals that this service supports
     dynamic endpoint instantiation via the AGTP negotiation protocol
     [AGTP].  When negotiable: true, the service MUST also provide a
     data_manifest block (see Section 8.3).  When absent, negotiable
     defaults to false.

     vocabulary:
       declared_verbs: [BOOK, FIND, CANCEL, CHECK]
       domain: hospitality
       namespace: acme-reservations
       version: "1.2.0"
       negotiable: true

  8.3.  Data Manifest Block

     When negotiable: true is declared in the vocabulary block, the AGIS
     document MUST include a data_manifest block.  The data manifest
     declares the data classes the service holds, without defining pre-
     built endpoints.  This enables agents to assess whether the service
     has relevant data before initiating dynamic endpoint negotiation via
     AGTP [AGTP].

     The data manifest is informative for the agent and normative for the
     service: a service MUST NOT negotiate endpoints for data classes
     absent from its manifest.  The manifest defines the ceiling of
     negotiation, not the floor.














  Hood                     Expires 19 October 2026               [Page 25]


  Internet-Draft                    AGIS                        April 2026


  data_manifest:
    available_data:
      - class: location
        description: "Geographic coordinates and address data for entities"
        formats: [json, geojson]
        sensitivity: low
      - class: reservation
        description: "Booking records and availability windows"
        formats: [json]
        sensitivity: medium
      - class: customer-profile
        description: "Customer identity and preference data"
        formats: [json]
        sensitivity: high
        requires_authorization: true
    pre_auth_discovery: true

     The pre_auth_discovery: true field signals that the data manifest and
     base AGIS document are accessible without credentials.  Agents MUST
     be able to retrieve these without prior authorization.  Authorization
     is established during AGTP negotiation, not before discovery.

     Data class sensitivity values follow the same enumeration as
     impact_tier: informational, reversible, irreversible.  High-
     sensitivity data classes SHOULD declare requires_authorization: true.

  9.  Validation

  9.1.  Validation Passes

     An AGIS validator MUST perform the following validation passes in
     sequence.  Failure at any pass MUST produce a specific, actionable
     error message identifying the non-conformant element and the violated
     rule.

















  Hood                     Expires 19 October 2026               [Page 26]


  Internet-Draft                    AGIS                        April 2026


       +======+==============+========================================+
       | Pass | Name         | Description                            |
       +======+==============+========================================+
       | 1    | Structural   | Verifies all required top-level fields |
       |      |              | are present and non-empty              |
       +------+--------------+----------------------------------------+
       | 2    | Method       | Verifies all method identifiers are    |
       |      | Syntax       | single uppercase alphabetic tokens in  |
       |      |              | imperative base form                   |
       +------+--------------+----------------------------------------+
       | 3    | Method Class | Verifies all method identifiers belong |
       |      |              | to the action-intent semantic class    |
       |      |              | and are not prohibited HTTP methods    |
       +------+--------------+----------------------------------------+
       | 4    | Path Syntax  | Verifies all paths begin with /,       |
       |      |              | contain no verbs, and use correct      |
       |      |              | parameterization syntax                |
       +------+--------------+----------------------------------------+
       | 5    | Semantic     | Verifies all semantic declaration      |
       |      | Completeness | blocks contain intent, actor, and      |
       |      |              | outcome fields                         |
       +------+--------------+----------------------------------------+
       | 6    | Semantic     | Verifies intent declarations are       |
       |      | Consistency  | semantically consistent with method    |
       |      |              | identifiers                            |
       +------+--------------+----------------------------------------+
       | 7    | Vocabulary   | Verifies declared_verbs matches the    |
       |      | Integrity    | set of verbs used in endpoint          |
       |      |              | definitions                            |
       +------+--------------+----------------------------------------+
       | 8    | Schema       | Verifies all endpoints reference valid |
       |      | Completeness | input, output, and errors JSON Schema  |
       |      |              | blocks                                 |
       +------+--------------+----------------------------------------+

                       Table 9: AGIS Validation Passes

     Passes 1 through 5 and Pass 7 are fully mechanical and require no
     semantic judgment.  Pass 6 requires semantic consistency evaluation.
     Validators SHOULD implement Pass 6 using a natural language inference
     model rather than keyword matching.  Pass 8 requires JSON Schema
     validation of referenced schema objects.

     Pass 6 implementation guidance: validators SHOULD compute the cosine
     similarity between the embedding of the method identifier and the
     embedding of the intent statement.  A similarity score below 0.3 (on
     a standard sentence-transformer scale) indicates likely inconsistency
     and SHOULD trigger a warning.  A score below 0.1 SHOULD trigger a



  Hood                     Expires 19 October 2026               [Page 27]


  Internet-Draft                    AGIS                        April 2026


     hard failure.  This threshold is informative; implementations MAY
     adjust based on their chosen embedding model.  The reference
     validator (agis-validator, PyPI) uses sentence-transformers/all-
     MiniLM-L6-v2 as the default embedding model.

  9.2.  Validator Implementation Guidance

     AGIS validators SHOULD be implemented as open-source tools to
     accelerate ecosystem adoption.  The reference validator architecture
     consists of three components:

     (a) A structural validator (Passes 1, 2, 4, 5, 7, 8): implemented in
     any language against the normative JSON Schema for AGIS documents.  A
     Python reference implementation is provided in the agis-validator
     package (agis-validator on PyPI).

     (b) A semantic class classifier (Pass 3): a lightweight binary
     classifier determining whether a method identifier belongs to the
     action-intent semantic class.  The reference implementation uses a
     fine-tuned sentence-transformer model.  A rule-based fallback using
     the prohibited methods list (Section 4.3) and a curated stoplist of
     common non-action-intent tokens (AVAILABLE, ACTIVE, EXISTS, STATUS,
     DATA, INFO) is RECOMMENDED as a first-pass filter.

     (c) A semantic consistency evaluator (Pass 6): embedding similarity
     between method identifier and intent statement, as described above.
     An LLM-powered consistency check (submitting method + intent to a
     small local model for binary pass/fail) is RECOMMENDED as a secondary
     pass for borderline cases.

     A VS Code extension and CLI tool for .agis file validation are
     provided via the agis-tools and agis-cli packages (PyPI).  These
     tools are RECOMMENDED for organizations authoring AGIS documents
     before publication.

     A document that passes all eight validation passes is a conforming
     AGIS document.  Partial conformance is not defined; an AGIS document
     either conforms or does not.

     When an AGTP request carries the Method-Grammar: AGIS/1.0 header, the
     AGTP transport layer runs Pass 2 and Pass 3 against the method
     identifier in the request.  Failure returns status 454 Grammar
     Violation per [AGTP].  Full document validation is performed by the
     service endpoint upon receiving a complete AGIS document at the AGTP
     root address.






  Hood                     Expires 19 October 2026               [Page 28]


  Internet-Draft                    AGIS                        April 2026


  9.3.  Conformance Testing

     Reference conformance test cases for each validation pass are
     maintained alongside the agis-validator package (PyPI).  Implementers
     of AGIS validators are RECOMMENDED to verify their implementations
     against the reference test suite before deployment.

     A conforming AGIS validator MUST:

     (a) Accept all documents in the reference valid document set without
     producing errors.

     (b) Reject all documents in the reference invalid document set,
     producing specific error messages identifying the violated rule in
     each case.

     (c) Produce no false positives on the reference borderline document
     set, where borderline documents are syntactically valid but
     semantically questionable.

  10.  AGIS File Format

     AGIS documents use the .agis file extension and the application/agis
     media type.  This specification defines two normative serialization
     formats: YAML and JSON.  Implementations MUST accept both.
     Validators MUST process both without preference.

     YAML is the RECOMMENDED format for human-authored AGIS documents due
     to its readability.  JSON is the RECOMMENDED format for machine-
     generated AGIS documents and for transmission over AGTP.  Both
     serializations MUST produce semantically identical documents when
     parsed.

     Canonical rules:
       - All field names are lowercase snake_case
       - Method identifiers are uppercase (BOOK, FIND)
       - Strings use double quotes in JSON; bare or quoted in YAML
       - Boolean values: true / false (lowercase)
       - Floating-point values: standard decimal notation (0.85)
       - Arrays: JSON array syntax in JSON; YAML sequence syntax in YAML

     A formal JSON Schema for the AGIS document structure will be
     maintained alongside the agis-validator package.  This JSON Schema is
     normative.  AGIS validators MUST validate documents against this
     schema as part of Pass 1 (Structural) validation before proceeding to
     subsequent passes.





  Hood                     Expires 19 October 2026               [Page 29]


  Internet-Draft                    AGIS                        April 2026


  10.1.  HTTP Transitional Binding

     Organizations operating HTTP/REST services that wish to adopt AGIS
     semantics without full AGTP migration MAY use the HTTP transitional
     binding.  This binding allows AGIS-conformant method identifiers to
     be carried in HTTP requests via a header:

     X-AGIS-Method: BOOK
     X-AGIS-Grammar: AGIS/1.0
     X-AGIS-Namespace: acme-reservations

     When these headers are present on an HTTP request, the service SHOULD
     interpret the method identifier according to AGIS grammar rules
     rather than HTTP method semantics.  The HTTP method (e.g., POST)
     continues to govern transport behavior.  The X-AGIS-Method governs
     semantic routing.

     The optional X-AGIS-Namespace header disambiguates the method when
     the client holds multiple service maps simultaneously, corresponding
     to the namespace field in the vocabulary block.  This is particularly
     relevant when multiple services use identically-named verbs (e.g.,
     DISPATCH in both a logistics and a workflow service).

     This transitional binding is informative.  Full AGIS conformance
     requires AGTP [AGTP] as the transport layer.  The HTTP binding is
     provided to lower the adoption barrier for incremental migration.

     The following is a complete conformant AGIS document example in
     illustrative notation:

     agis: "1.0"
     service: "Acme Restaurant Reservations"
     agtp: "agtp://reservations.acme.com"
     description: "Reservation management for restaurant booking agents"

     endpoints:

       BOOK /reservation {
         semantic {
           intent:   "Books a restaurant reservation on behalf of the
                      requesting agent"
           actor:    agent
           outcome:  "A confirmed reservation record exists with
                      status CONFIRMED"
           capability: transaction
           confidence_guidance: 0.85
         }
         input {



  Hood                     Expires 19 October 2026               [Page 30]


  Internet-Draft                    AGIS                        April 2026


           required: [restaurant_id (int), party_size (int),
                      datetime (ISO8601)]
           optional: [preferences (string), contact_name (string)]
         }
         output { reservation_id, status, confirmation_code, datetime }
         errors { reservation_unavailable, invalid_datetime,
                  restaurant_not_found }
       }

       FIND /restaurants {
         semantic {
           intent:   "Finds restaurants matching the agent criteria"
           actor:    agent
           outcome:  "A ranked list of matching restaurants is returned"
           capability: discovery
           confidence_guidance: 0.60
         }
         input {
           required: [location (string)]
           optional: [cuisine, party_size, datetime, price_range]
         }
         output { restaurants: [array of restaurant objects] }
         errors { no_results, invalid_location }
       }

     vocabulary {
       declared_verbs: [BOOK, FIND]
       domain: hospitality
       version: "1.0.0"
     }

     An organization using domain-specific vocabulary would follow the
     same structure with different verbs.  A healthcare service might use:


















  Hood                     Expires 19 October 2026               [Page 31]


  Internet-Draft                    AGIS                        April 2026


  agis: "1.0"
  service: "Acme Patient Services"
  agtp: "agtp://patients.acme-health.com"

  endpoints:

    TRIAGE /patient {
      semantic {
        intent:   "Assesses and prioritizes a patient for care"
        actor:    agent
        outcome:  "A triage record exists with assigned priority level"
        capability: transaction
        confidence_guidance: 0.92
      }
      ...
    }

    ADMIT /patient {
      semantic {
        intent:   "Admits a patient to a care facility"
        actor:    agent
        outcome:  "Patient record shows admitted status with assigned unit"
        capability: transaction
        confidence_guidance: 0.95
      }
      ...
    }

  vocabulary {
    declared_verbs: [TRIAGE, ADMIT]
    domain: healthcare
    version: "1.0.0"
  }

     Neither TRIAGE nor ADMIT appears in the AGTP registered vocabulary,
     yet both are valid AGIS-conformant methods.  An agent encountering
     this service via Method-Grammar: AGIS/1.0 at the AGTP transport layer
     can discover, validate, and invoke these methods through natural
     language inference against the semantic declarations, without a
     predefined catalog.

     A financial services example demonstrates the data manifest and
     negotiation features together.  The service has no pre-built endpoint
     for transaction history, but declares the data class as available for
     negotiation:






  Hood                     Expires 19 October 2026               [Page 32]


  Internet-Draft                    AGIS                        April 2026


  agis: "1.0"
  service: "Acme Financial Services"
  agtp: "agtp://api.acme-finance.com"

  endpoints:

    TRANSFER /funds {
      semantic {
        intent:   "Transfers funds between accounts on behalf of the agent"
        actor:    agent
        outcome:  "Funds are debited from source and credited to destination"
        capability: transaction
        confidence_guidance: 0.95
        impact_tier: irreversible
        is_idempotent: false
        state_transition:
          source_account.balance: [current] -> [current - amount]
          destination_account.balance: [current] -> [current + amount]
      }
      input {
        required: [source_account_id, destination_account_id, amount,
                   currency]
        optional: [memo, scheduled_date]
      }
      output { transfer_id, status, timestamp, confirmation_code }
      errors { insufficient_funds, account_not_found, limit_exceeded,
               currency_mismatch, authorization_required }
    }

    RECONCILE /account/{id} {
      semantic {
        intent:   "Reconciles account records against transaction ledger"
        actor:    agent
        outcome:  "Discrepancies are identified and a reconciliation
                   report is returned"
        capability: analysis
        confidence_guidance: 0.75
        impact_tier: informational
        is_idempotent: true
      }
      input {
        required: [id]
        optional: [from_date, to_date, include_pending]
      }
      output { reconciliation_id, discrepancies: [array], status,
               period_covered }
      errors { account_not_found, period_too_large }
    }



  Hood                     Expires 19 October 2026               [Page 33]


  Internet-Draft                    AGIS                        April 2026


  vocabulary {
    declared_verbs: [TRANSFER, RECONCILE]
    domain: financial-services
    namespace: acme-finance
    version: "2.1.0"
    negotiable: true
  }

  data_manifest {
    available_data:
      - class: transaction-history
        description: "Full transaction ledger for authorized accounts"
        formats: [json, csv]
        sensitivity: high
        requires_authorization: true
      - class: exchange-rates
        description: "Real-time and historical currency exchange rates"
        formats: [json]
        sensitivity: informational
        requires_authorization: false
    pre_auth_discovery: true
  }

     An agent needing transaction history arrives, finds no pre-built
     endpoint, reads the data manifest, and sends a PROPOSE request for a
     RETRIEVE /account/{id}/transactions endpoint.  The service evaluates
     the proposal against the transaction-history data class, establishes
     authorization for the requesting agent, and returns a 263 Endpoint
     Instantiated response with a session-scoped endpoint definition.  The
     agent calls the endpoint without the service ever having pre-built
     it.

  11.  Agent Discovery Protocol

     When an agent runtime issues a discovery request to an AGTP address,
     the service MUST return a valid AGIS document as the root response.
     The agent runtime MUST:

     (a) Retrieve the AGIS document from the root AGTP address.

     (b) Validate the document against the AGIS Grammar Specification.
     Non-conformant documents MUST be treated as discovery failures.

     (c) Parse the vocabulary block to build an initial service capability
     index.

     (d) Parse individual endpoint definitions to build a complete service
     map.



  Hood                     Expires 19 October 2026               [Page 34]


  Internet-Draft                    AGIS                        April 2026


     (e) Match incoming user intent against the service map using natural
     language inference against intent declarations and method
     identifiers.

     Because AGIS method identifiers are constrained to the action-intent
     semantic class, agent runtimes SHOULD match incoming user natural
     language instructions against method identifiers directly before
     consulting intent declarations.  The method identifier serves as a
     compressed intent signal; the intent declaration provides
     confirmation and disambiguation.

     For example, a user instruction of "schedule a meeting for Thursday"
     would match as follows:

     Step 1:  Method matching -- agent scans vocabulary block for
              action-intent verbs semantically proximate to "schedule".
              SCHEDULE, BOOK, ARRANGE are candidate matches.

     Step 2:  Path matching -- agent evaluates path nouns against
              "meeting" intent. /event, /meeting, /calendar-event
              are candidate matches.

     Step 3:  Intent confirmation -- agent reads intent declarations
              for candidate endpoints to confirm alignment.

     Step 4:  Parameter construction -- agent maps "Thursday" to the
              required datetime parameter using the JSON Schema
              type constraint (ISO 8601 date).

     Step 5:  Confidence evaluation -- agent compares its selection
              confidence against the endpoint's confidence_guidance.
              If below threshold, escalation is surfaced to the user.

     This discovery process was empirically validated in the two-stage
     discovery conditions of [HOOD2026].  Agents navigating unfamiliar
     AGIS-conformant service catalogs demonstrated higher endpoint
     selection accuracy than agents navigating equivalent REST/CRUD
     catalogs, confirming that the AGIS grammar constraint -- without a
     fixed vocabulary -- provides sufficient semantic signal for effective
     agent discovery.











  Hood                     Expires 19 October 2026               [Page 35]


  Internet-Draft                    AGIS                        April 2026


  11.1.  Well-Known Discovery Endpoint

     AGIS-conformant services SHOULD expose a lightweight discovery
     summary at the well-known URI /.well-known/agis.json.  This endpoint
     enables agents and agent registries to discover the service's
     capabilities without fetching the full AGIS document.  The well-known
     endpoint parallels the agent-card.json pattern used in agent-to-agent
     protocols.

     The well-known response MUST be a JSON object containing:

     {
       "agis": "1.0",
       "service": "Acme Restaurant Reservations",
       "agtp": "agtp://reservations.acme.com",
       "agis_document": "agtp://reservations.acme.com",
       "methods": ["BOOK", "FIND", "CANCEL"],
       "domain": "hospitality",
       "namespace": "acme-reservations",
       "negotiable": true,
       "capability_summary": ["transaction", "discovery", "modification"],
       "data_classes": ["reservation", "restaurant", "availability"],
       "pre_auth_discovery": true,
       "version": "1.2.0",
       "interaction_protocols": ["request", "negotiate", "confirm"],
       "related_services": [
         "agtp://payments.acme.com",
         "agtp://loyalty.acme.com"
       ],
       "mcp_tools_list": "agtp://reservations.acme.com/mcp/tools"
     }

     The interaction_protocols array lists the communication patterns this
     service supports, borrowing the interaction protocol concept from
     FIPA-ACL [FIPA-IP].  Defined values are: request (standard method
     invocation), negotiate (dynamic endpoint instantiation via PROPOSE),
     confirm (multi-step confirmation flow), and query (read-only
     retrieval patterns).  This enables A2A orchestrators to select
     services based on workflow compatibility.

     The related_services array enables service mesh discovery: agents
     that find one AGIS service can follow links to discover related
     services in the same ecosystem without a central registry.

     The mcp_tools_list field provides the URL of the service's MCP-
     compatible tools/list endpoint.  When present, MCP clients can
     discover and invoke the service without reading the full AGIS
     document.



  Hood                     Expires 19 October 2026               [Page 36]


  Internet-Draft                    AGIS                        April 2026


     AGIS services that expose this endpoint become first-class
     participants in A2A agent workflows.  A2A orchestrators discovering
     AGIS services via the well-known endpoint can treat them as invocable
     task participants, using the methods and capability_summary to route
     tasks appropriately.

     This endpoint:

     (a) MUST be accessible without credentials when pre_auth_discovery:
     true is declared in the full AGIS document.

     (b) MUST NOT expose data_manifest sensitivity details or customer
     data.

     (c) SHOULD be indexed by AGTP registries and A2A agent discovery
     mechanisms to enable cross-protocol service discovery.

     (d) MUST reference the full AGIS document location via the
     agis_document field so agents can fetch the complete contract when
     needed.

     Services implementing this endpoint become discoverable by any agent
     runtime that supports the well-known discovery pattern, including A2A
     agents, MCP clients, and AGTP-native agents, regardless of which
     protocol they use for subsequent interaction.

  12.  Empirical Foundation

     The design requirements of this specification are grounded in
     empirical research conducted across 7,200 controlled trials spanning
     four LLM families (Claude Sonnet 4.6, Grok-3, GPT-4o, and Llama 3.2
     3B) and 18 experimental conditions [HOOD2026].  Key findings
     supporting specific design decisions are summarized below.


















  Hood                     Expires 19 October 2026               [Page 37]


  Internet-Draft                    AGIS                        April 2026


     +=====================+=============================================+
     | Design Decision     | Empirical Support                           |
     +=====================+=============================================+
     | Method identifiers  | Intent-expressing verbs                     |
     | MUST belong to the  | outperformed REST/CRUD methods by           |
     | action-intent       | 10-29pp in mixed-paradigm                   |
     | semantic class      | conditions (z=3.77, p<0.001)                |
     +---------------------+---------------------------------------------+
     | Grammar constraint  | Two-stage discovery conditions              |
     | rather than fixed   | demonstrated agents successfully            |
     | vocabulary          | navigate unfamiliar semantic verb           |
     |                     | vocabularies through inference,             |
     |                     | without a predefined catalog                |
     +---------------------+---------------------------------------------+
     | Semantic            | Description-swap ablation showed            |
     | declarations MUST   | intent-method consistency                   |
     | include intent      | failures collapse accuracy                  |
     | field               | 39-43pp; intent declarations                |
     |                     | mitigate this risk                          |
     +---------------------+---------------------------------------------+
     | confidence_guidance | Description mismatch conditions             |
     | field RECOMMENDED   | produced +60pp calibration error;           |
     | for high-           | confidence guidance enables                 |
     | consequence         | governance-aware execution                  |
     | endpoints           |                                             |
     +---------------------+---------------------------------------------+
     | Effect requires     | Llama 3.2 (3B parameters) showed            |
     | frontier-scale      | zero accuracy advantage from                |
     | reasoning           | semantic naming; capability                 |
     |                     | threshold lies above 3B                     |
     |                     | parameters                                  |
     +---------------------+---------------------------------------------+
     | Vocabulary block    | Discovery recall was higher when            |
     | enables pre-        | agents could filter by semantic             |
     | indexing            | class before full endpoint                  |
     |                     | evaluation                                  |
     +---------------------+---------------------------------------------+

             Table 10: Empirical Support for AGIS Design Decisions

     The research established that the tested vocabulary -- BOOK, FIND,
     QUERY, SUMMARIZE -- is an instance of the action-intent semantic
     class that AGIS standardizes, not a proposed canonical list.  The
     performance advantage is a property of the semantic class,
     generalizing to any conformant vocabulary an implementation chooses.
     This is the empirical foundation for the grammar- over-vocabulary
     architecture: the mechanism is the semantic class, and any verb in
     that class produces the same accuracy advantage.



  Hood                     Expires 19 October 2026               [Page 38]


  Internet-Draft                    AGIS                        April 2026


  13.  Security Considerations

     AGIS-conformant services operate within the AGTP security model
     defined in [AGTP].  The following security considerations are
     specific to the AGIS layer.

     Intent Statement Injection:  Malicious actors may construct AGIS
        documents with intent statements designed to mislead agent
        runtimes into invoking unintended endpoints.  Agent runtimes MUST
        validate AGIS documents against the Grammar Specification before
        consuming intent declarations.  Non-conformant documents MUST be
        rejected.

     Vocabulary Spoofing:  An attacker serving a non-conformant AGIS
        document at a legitimate AGTP address may attempt to redirect
        agents to incorrect endpoints by declaring misleading vocabulary.
        Agent runtimes SHOULD verify vocabulary declarations against
        actual endpoint definitions as part of Pass 7 validation.

     Confidence Threshold Manipulation:  A service declaring artificially
        low confidence_guidance values may induce agents to execute high-
        consequence operations without appropriate escalation.  Agent
        runtimes SHOULD apply minimum confidence thresholds independent of
        service-declared values for operations the runtime classifies as
        high-consequence.

     Schema Injection:  JSON Schema objects within AGIS documents are
        subject to the security considerations of [JSON-SCHEMA].  Agent
        runtimes MUST validate JSON Schema blocks before using them to
        construct API calls.

     Grammar Validation at Transport Layer:  The Method-Grammar: AGIS/1.0
        header instructs AGTP infrastructure to perform Pass 2 and Pass 3
        validation at the transport layer.  Transport- layer validators
        MUST reject requests with method identifiers that fail AGIS
        grammar rules with status 454 Grammar Violation per [AGTP].  This
        prevents non-conformant method identifiers from reaching
        application code.

     Intent Statement Prompt Injection:  Beyond false intent declarations,











  Hood                     Expires 19 October 2026               [Page 39]


  Internet-Draft                    AGIS                        April 2026


        attackers may attempt to embed prompt injection payloads within
        intent and outcome statements, targeting agent runtimes that
        process these fields through LLM inference.  Validators SHOULD
        enforce length limits on intent and outcome fields (RECOMMENDED
        maximum: 500 characters).  Agent runtimes SHOULD treat intent
        statements as structured data fields, not as natural language
        prompts to be executed.  Similarity bounds between method
        identifier and intent statement SHOULD be enforced; statements
        with cosine similarity below 0.3 against the method verb embedding
        SHOULD be flagged.

        Agent runtimes that feed AGIS intent and outcome fields to LLM
        inference engines SHOULD apply content filtering or sandboxing
        before processing.  Recommended mitigations: (1) validate that
        intent fields contain no instruction-pattern tokens ("ignore
        previous instructions", "you are", "system:") before LLM
        processing; (2) process intent fields in an isolated inference
        context with a constrained system prompt that prohibits
        instruction following; (3) compare intent field embeddings against
        a reference distribution of known-safe intent statements and flag
        outliers for human review before the service is published.

     Data Manifest Security:  Services exposing pre_auth_discovery: true
        MUST ensure their data manifest reveals no sensitive data in class
        descriptions.  Manifests are accessible without credentials and
        MUST be treated as public-facing documents.  The manifest
        describes data categories, not data contents.  Specific record
        counts, schema details, and field names SHOULD be withheld from
        the unauthenticated manifest and disclosed only after AGTP
        authorization.

     Internationalization Note:  While this specification uses English-
        language imperative verbs as examples, agents handling non-English
        user intent MAY map through embedding similarity, enabling
        multilingual deployments without requiring non-English method
        identifiers.  The action-intent semantic class is language-
        independent at the validator level; a verb in any language that
        satisfies the syntactic rules (single uppercase alphabetic token,
        imperative base form) and semantic class requirements is a valid
        AGIS method identifier.











  Hood                     Expires 19 October 2026               [Page 40]


  Internet-Draft                    AGIS                        April 2026


        AGIS validators are English-centric on syntax: the uppercase A-Z
        character restriction means method identifiers are expressed as
        romanized uppercase tokens even in non-English deployments.
        Agents handling Japanese, Arabic, Chinese, or other script user
        intent perform embedding-space mapping to the romanized AGIS
        method identifier during discovery.  The parameter_hints field
        SHOULD include non-English natural language phrases where the
        primary user population is non- English-speaking, as these phrases
        directly improve parametric accuracy for multilingual agents.

  14.  IANA Considerations

     This document requests the following registrations from IANA:

     Media Type Registration: application/agis

     Type name:              application
     Subtype name:           agis
     Required parameters:    none
     Optional parameters:    version
     Encoding considerations: UTF-8
     Security considerations: See Section 12
     Published specification: This document

     File Extension Registration: .agis

     Extension:              agis
     Media type:             application/agis
     Description:            Agentic Grammar and Interface Specification
                             document
     Published specification: This document

  15.  References

  15.1.  Normative References

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

     [JSON-SCHEMA]
                Wright, A., Andrews, H., Hutton, B., and G. Dennis, "JSON
                Schema: A Media Type for Describing JSON Documents", Work
                in Progress, Internet-Draft, draft-bhutton-json-schema-01,
                2020, <https://datatracker.ietf.org/doc/html/draft-
                bhutton-json-schema-01>.




  Hood                     Expires 19 October 2026               [Page 41]


  Internet-Draft                    AGIS                        April 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>.

     [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
                Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
                DOI 10.17487/RFC7231, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7231>.

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

  15.2.  Informative References

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

     [FIELDING] Fielding, R. T., "Architectural Styles and the Design of
                Network-based Software Architectures", Doctoral
                Dissertation University of California, Irvine, 2000.

     [HOOD2026] Hood, C., "Semantic Method Naming and LLM Agent Accuracy:
                A Controlled Benchmark of REST/CRUD versus Agentive API
                Interface Design", Working Paper Available by request.
                March 2026., 2026.

  Appendix A.  Recommended Starter Vocabulary (Informative)

     This appendix provides a non-normative list of recommended starter
     verbs for common agent operations.  This list does not constitute a
     compliance requirement.  Any AGIS-conformant verb satisfying the
     grammar rules of Section 4 is equally valid.  Organizations are
     encouraged to use this vocabulary for maximum cross-system
     interoperability and to consult [AGTP-METHODS] for the full
     registered Tier 1 and Tier 2 vocabulary.

           +===========+===============+==========================+
           | Verb      | Category      | Common Use               |
           +===========+===============+==========================+
           | BOOK      | Transaction   | Reserve a resource,      |
           |           |               | seat, or time slot       |
           +-----------+---------------+--------------------------+
           | FIND      | Discovery     | Locate matching          |



  Hood                     Expires 19 October 2026               [Page 42]


  Internet-Draft                    AGIS                        April 2026


           |           |               | resources by criteria    |
           +-----------+---------------+--------------------------+
           | SCHEDULE  | Transaction   | Plan a future action or  |
           |           |               | appointment              |
           +-----------+---------------+--------------------------+
           | CANCEL    | Transaction   | Terminate a reservation  |
           |           |               | or commitment            |
           +-----------+---------------+--------------------------+
           | QUERY     | Retrieval     | Retrieve information by  |
           |           |               | parameters               |
           +-----------+---------------+--------------------------+
           | SUMMARIZE | Analysis      | Synthesize content into  |
           |           |               | condensed form           |
           +-----------+---------------+--------------------------+
           | AUTHORIZE | Transaction   | Grant permission for an  |
           |           |               | operation                |
           +-----------+---------------+--------------------------+
           | TRANSFER  | Transaction   | Move a resource between  |
           |           |               | parties                  |
           +-----------+---------------+--------------------------+
           | SUBMIT    | Transaction   | Deliver a document or    |
           |           |               | form for processing      |
           +-----------+---------------+--------------------------+
           | NOTIFY    | Notification  | Send information to a    |
           |           |               | recipient                |
           +-----------+---------------+--------------------------+
           | VERIFY    | Retrieval     | Confirm the validity of  |
           |           |               | a claim or record        |
           +-----------+---------------+--------------------------+
           | DISPATCH  | Transaction   | Send or route a resource |
           |           |               | to a destination         |
           +-----------+---------------+--------------------------+
           | LOCATE    | Discovery     | Find the position or     |
           |           |               | address of an entity     |
           +-----------+---------------+--------------------------+
           | RESERVE   | Transaction   | Hold a resource without  |
           |           |               | confirming               |
           +-----------+---------------+--------------------------+
           | TRIAGE    | Transaction   | Assess and prioritize    |
           |           |               | for action               |
           +-----------+---------------+--------------------------+
           | RECONCILE | Analysis      | Identify and resolve     |
           |           |               | discrepancies            |
           +-----------+---------------+--------------------------+
           | RECOMMEND | Analysis      | Propose options based on |
           |           |               | criteria                 |
           +-----------+---------------+--------------------------+
           | ESCALATE  | Orchestration | Defer to a higher        |



  Hood                     Expires 19 October 2026               [Page 43]


  Internet-Draft                    AGIS                        April 2026


           |           |               | authority                |
           +-----------+---------------+--------------------------+
           | EXTRACT   | Analysis      | Pull specific data from  |
           |           |               | a document or record     |
           +-----------+---------------+--------------------------+
           | VALIDATE  | Retrieval     | Confirm that data or a   |
           |           |               | claim meets requirements |
           +-----------+---------------+--------------------------+
           | GENERATE  | Analysis      | Produce a new document,  |
           |           |               | report, or artifact      |
           +-----------+---------------+--------------------------+
           | MONITOR   | Orchestration | Observe a resource or    |
           |           |               | process over time        |
           +-----------+---------------+--------------------------+
           | APPROVE   | Transaction   | Grant formal acceptance  |
           |           |               | of a request             |
           +-----------+---------------+--------------------------+
           | REJECT    | Transaction   | Formally decline a       |
           |           |               | request with reason      |
           +-----------+---------------+--------------------------+

           Table 11: Recommended Starter Vocabulary (Non-Normative)

     Common synonyms: RESERVE (equivalent scope to BOOK), LOCATE
     (equivalent scope to FIND), RETRIEVE (equivalent scope to QUERY),
     REVOKE (equivalent scope to CANCEL in access-control contexts).  Any
     synonym satisfying the action-intent semantic class is equally valid.
     Organizations SHOULD choose the verb whose natural language form most
     closely matches their users' instructions.

     For domain-specific verbs not shown here, consult [AGTP-METHODS] for
     the full registered Tier 1 and Tier 2 vocabulary, which includes
     FETCH, SEARCH, SUBMIT, TRANSFER, PURCHASE, AUTHORIZE, SYNC, ROUTE,
     and thirty additional registered methods organized by category.

  Appendix B.  Comparison with Existing Approaches (Informative)

     This appendix positions AGIS relative to adjacent specifications and
     approaches to clarify its role as the interface definition layer for
     Agentive APIs.

     OpenAPI / Swagger:  OpenAPI defines REST/CRUD endpoint contracts









  Hood                     Expires 19 October 2026               [Page 44]


  Internet-Draft                    AGIS                        April 2026


        using HTTP methods and resource paths.  It is the de facto
        standard for human-developer-facing API documentation.  AGIS
        differs in two respects: it governs the semantic class of method
        identifiers (not just structure), and it is designed for agent
        consumption rather than developer consumption.  OpenAPI documents
        can be translated to AGIS documents; see the mapping guidance
        below.

     LLM Function Calling (OpenAI, Anthropic):  Function calling schemas
        define callable tools for LLM agents using name, description, and
        parameter schemas.  AGIS extends this model by adding transport-
        level identity (via AGTP), grammar constraints on method
        identifiers, confidence guidance, impact tiers, and negotiation
        support.  AGIS endpoint definitions are structurally similar to
        function calling schemas but operate at the protocol level rather
        than the application layer.

     GraphQL:  GraphQL allows clients to specify exactly the data shape
        they need.  AGIS and AGTP address a complementary problem: what
        operation the agent wants to perform (method semantics), not what
        fields it wants returned (data projection).  A service could
        expose both GraphQL for data shaping and AGIS/AGTP for agent
        interaction semantics.

     Model Context Protocol (MCP):  MCP defines tool invocation semantics
        for agents running within LLM contexts.  MCP operates at the
        messaging layer over HTTP.  AGTP provides the transport substrate
        for MCP (see [AGTP]); AGIS provides the interface definition
        language for services MCP tools invoke.

     A2A / ACP:  Agent-to-Agent and Agent Communication Protocols define
        how agents communicate with each other.  AGIS defines how agents
        communicate with services.  These are complementary: an A2A
        message may instruct an agent to invoke an AGIS/AGTP service.

     FIPA-ACL / KQML:  FIPA-ACL (Foundation for Intelligent Physical
        Agents Agent Communication Language) is the direct historical
        predecessor to AGIS.  FIPA-ACL defined approximately 25 fixed
        performatives -- REQUEST, INFORM, PROPOSE, ACCEPT-PROPOSAL,
        REJECT-PROPOSAL, QUERY-IF, CONFIRM, FAILURE -- each carried in a
        structured envelope with sender, receiver, content, ontology,
        protocol, and conversation-id fields.  The performative was the
        verb giving the message its intent, analogous to the AGIS method
        identifier.







  Hood                     Expires 19 October 2026               [Page 45]


  Internet-Draft                    AGIS                        April 2026


        FIPA-ACL also defined reusable interaction protocols (Contract
        Net, Query Protocol, Request Protocol) that serve as conversation
        templates -- the conceptual ancestor of the AGTP negotiation
        protocol.

        AGIS differs from FIPA-ACL in three respects: (1) AGIS uses an
        open grammar rather than a fixed performative set, enabling
        domain-specific vocabularies without standardization overhead; (2)
        AGIS uses JSON Schema rather than formal content languages (SL,
        KIF, RDF), aligning with contemporary web tooling; (3) AGIS is
        designed for LLM agents that reason in natural language, whereas
        FIPA-ACL was designed for symbolic AI agents in frameworks like
        JADE.  FIPA-ACL was ahead of its time.  AGIS is its successor
        built for the agents that exist today.

     OpenAPI to AGIS Mapping (Informative):

  OpenAPI field          AGIS equivalent
  -----------------------------------------
  operationId            Method identifier (rewrite to imperative base form)
  summary                intent statement
  x-outcome (custom)     outcome statement
  parameters             input.required / input.optional
  requestBody            input schema
  responses.200          output schema
  responses.4xx          errors array
  tags[0]                domain (vocabulary block)

     Organizations migrating from OpenAPI SHOULD rewrite operationId
     values to imperative base form (createReservation -> BOOK,
     searchRestaurants -> FIND) as the primary migration step.  The
     resulting AGIS document will be AGIS-conformant if the rewritten
     identifiers satisfy the action-intent semantic class requirements of
     Section 4.

  Appendix C.  MCP Interoperability Bridge (Informative)

     The Model Context Protocol (MCP) is the most widely deployed agent
     tool interface as of 2026, supported natively by Claude, Cursor, VS
     Code, and an expanding ecosystem of agent runtimes.  MCP uses JSON-
     RPC 2.0 with a tools/list endpoint that returns a catalog of callable
     tools, each with a name, description, and input schema.

     AGIS and MCP are complementary rather than competing.  MCP is tool-
     centric and runtime-scoped; AGIS is service-centric and transport-
     governed.  An AGIS document can automatically generate a valid MCP
     tools catalog, making any AGIS-conformant service immediately
     consumable by every MCP client without additional development.



  Hood                     Expires 19 October 2026               [Page 46]


  Internet-Draft                    AGIS                        April 2026


  C.1.  AGIS to MCP Mapping

     AGIS field                    MCP equivalent
     -----------------------------------------------
     Method identifier             tool.name
       (e.g., BOOK)                  (e.g., "BOOK_reservation" or "book")
     intent statement              tool.description
     input.required + optional     tool.inputSchema (JSON Schema)
     output                        (MCP response body; no direct mapping)
     errors                        (MCP error codes; no direct mapping)
     confidence_guidance           (informative; no MCP equivalent)
     impact_tier                   (informative; no MCP equivalent)

  C.2.  Auto-Generation Rules

     An AGIS-to-MCP converter MUST apply the following rules:

     (a) Tool name: if mcp_tool_name is declared in the semantic block,
     use it directly.  Otherwise concatenate the method identifier and the
     first path segment, separated by underscore and lowercased.  BOOK
     /reservation -> book_reservation BOOK /reservation with
     mcp_tool_name: make_reservation -> make_reservation

     (b) Tool description: use the AGIS intent statement as the base
     description.  If parameter_hints are declared, append them to the
     description in a structured format to enrich MCP client elicitation:

     ~~~
     "Books a restaurant reservation on behalf of the agent.
      Hints: party_size = ['number of guests', 'for N people',
      'table for N']; datetime = ['next Tuesday', 'Saturday at 7']"
     ~~~

     This enrichment improves MCP client accuracy when users express
     parameters in natural language rather than structured form.

     (c) Tool inputSchema: use the AGIS input JSON Schema directly.
     Required parameters map to JSON Schema required array.

     (d) Omit output, errors, confidence_guidance, and state_transition
     from the MCP tool definition.  These have no MCP equivalent and MUST
     NOT cause generation failure.

     Example conversion:







  Hood                     Expires 19 October 2026               [Page 47]


  Internet-Draft                    AGIS                        April 2026


  AGIS endpoint:
    BOOK /reservation {
      semantic {
        intent: "Books a restaurant reservation on behalf of the agent"
      }
      input {
        required: [restaurant_id, party_size, datetime]
        optional: [preferences]
      }
    }

  Generated MCP tool entry:
    {
      "name": "book_reservation",
      "description": "Books a restaurant reservation on behalf of the agent",
      "inputSchema": {
        "type": "object",
        "properties": {
          "restaurant_id": { "type": "integer" },
          "party_size": { "type": "integer" },
          "datetime": { "type": "string", "format": "date-time" },
          "preferences": { "type": "string" }
        },
        "required": ["restaurant_id", "party_size", "datetime"]
      }
    }

  C.3.  MCP to AGIS Migration Path

     Organizations with existing MCP tool catalogs can generate an initial
     AGIS document by applying the reverse mapping:

     (a) Tool name -> method identifier: split on underscore, take the
     first segment, uppercase it, verify action-intent class.
     book_reservation -> BOOK (valid action-intent verb) get_data -> GET
     (invalid; HTTP method; rewrite as RETRIEVE or FETCH)

     (b) Tool description -> intent statement: use verbatim if it
     describes agent goal; rewrite if it describes internal system
     operation.

     (c) inputSchema -> input block: use directly.

     (d) Add required semantic fields: actor (default: agent), outcome
     (derive from description or add manually), capability (classify
     manually from the five categories).





  Hood                     Expires 19 October 2026               [Page 48]


  Internet-Draft                    AGIS                        April 2026


     The resulting AGIS document will require manual review of semantic
     consistency (Pass 6) and MUST be validated using the agis-validator
     tool before publication.

  C.4.  References

  C.5.  Normative References

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

     [RFC7231]     Fielding, R. and J. Reschke, "Hypertext Transfer
                   Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
                   June 2014.

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

     [JSON-SCHEMA] Wright, A., Andrews, H., Hutton, B., and G. Dennis,
                   "JSON Schema: A Media Type for Describing JSON
                   Documents", draft-bhutton-json-schema-01, Dec 2020.

     [AGTP]        Hood, C., "Agent Transfer Protocol (AGTP)",
                   draft-hood-independent-agtp-03, 2026.

  C.6.  Informative References

























  Hood                     Expires 19 October 2026               [Page 49]


  Internet-Draft                    AGIS                        April 2026


     [HOOD2026]    Hood, C., "Semantic Method Naming and LLM Agent
                   Accuracy: A Controlled Benchmark of REST/CRUD versus
                   Agentive API Interface Design", Working Paper,
                   Nomotic, Inc., March 2026. Available by request
                   at chris@nomotic.ai.

     [AGTP-METHODS] Hood, C., "AGTP Standard Extended Method Vocabulary",
                   draft-hood-agtp-standard-methods-01, 2026.


     [FIELDING]    Fielding, R.T., "Architectural Styles and the Design
                   of Network-based Software Architectures", Doctoral
                   Dissertation, UC Irvine, 2000.

     [FIPA-ACL]    Foundation for Intelligent Physical Agents,
                   "FIPA ACL Message Structure Specification",
                   Document SC00061G, 2002.
                   http://www.fipa.org/specs/fipa00061/

     [FIPA-IP]     Foundation for Intelligent Physical Agents,
                   "FIPA Interaction Protocol Library Specification",
                   Document SC00025G, 2002.
                   http://www.fipa.org/specs/fipa00025/

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

     [A2A]         Linux Foundation, "Agent-to-Agent Protocol
                   Specification", 2025. https://a2aprotocol.ai

  Appendix D.  Author's Address

     Chris Hood
     Nomotic, Inc.

     Email:   chris@nomotic.ai
     URI:     https://agtp.io
     ORCID:   [ORCID identifier]

  Author's Address

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






  Hood                     Expires 19 October 2026               [Page 50]


name: draft-crovia-seal
rev: 01
title: The Crovia Seal: A Cryptographic Receipt Format for AI-Generated Output Provenance
time: 2026-05-05T16:07:57Z
group_uri: /api/v1/group/group/1027/
expires: 2026-11-06T16:07:57Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-05-22T09:24:54.285024+00:00
source: ietf
abstract:
  This document specifies the Crovia Seal v1, a compact, tamper-evident
     JSON receipt that may be attached to any output produced by an AI
     generator (large language model, image model, audio model, or
     composite system) to record its provenance in a cryptographically
     verifiable form.  A Crovia Seal binds an issuer's identity to the
     SHA-256 digests of an input/output pair, the identity and parameters
     of the generator, an emission timestamp, and a per-issuer hash chain,
     under an Ed25519 signature computed over a strict canonicalization
     (CSC-1) of the receipt with explicit domain separation.  Optional
     fields permit transparency-log inclusion proofs and witness co-
     signatures.  The Seal is designed for offline verification and for
     inclusion in third-party transparency logs and standards-based
     revocation infrastructure.

full_text:
  Independent Submission                                      T. En Nakhai
  Internet-Draft                                              Crovia Trust
  Intended status: Informational                                  May 2026
  Expires: 6 November 2026


  The Crovia Seal: A Cryptographic Receipt Format for AI-Generated Output
                                 Provenance
                            draft-crovia-seal-01

  Abstract

     This document specifies the Crovia Seal v1, a compact, tamper-evident
     JSON receipt that may be attached to any output produced by an AI
     generator (large language model, image model, audio model, or
     composite system) to record its provenance in a cryptographically
     verifiable form.  A Crovia Seal binds an issuer's identity to the
     SHA-256 digests of an input/output pair, the identity and parameters
     of the generator, an emission timestamp, and a per-issuer hash chain,
     under an Ed25519 signature computed over a strict canonicalization
     (CSC-1) of the receipt with explicit domain separation.  Optional
     fields permit transparency-log inclusion proofs and witness co-
     signatures.  The Seal is designed for offline verification and for
     inclusion in third-party transparency logs and standards-based
     revocation infrastructure.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 5 November 2026.

  Status of This Memo

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




  En Nakhai                Expires 6 November 2026                [Page 1]


  Internet-Draft               Crovia Seal v1                     May 2026


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

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

     This Internet-Draft will expire on 2 November 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   4
       1.2.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .   5
     2.  Canonicalization (CSC-1)  . . . . . . . . . . . . . . . . . .   5
       2.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Rules . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.3.  Signing Payload . . . . . . . . . . . . . . . . . . . . .   6
     3.  Seal Structure  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Top-Level Fields  . . . . . . . . . . . . . . . . . . . .   7
       3.2.  seal_version  . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.  seal_id . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.4.  issuer  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.  subject . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.6.  generator . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.7.  timestamp . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.8.  chain . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.9.  checks (OPTIONAL) . . . . . . . . . . . . . . . . . . . .  10
       3.10. anchor (OPTIONAL) . . . . . . . . . . . . . . . . . . . .  10
       3.11. signature . . . . . . . . . . . . . . . . . . . . . . . .  11
     4.  Witnesses (OPTIONAL)  . . . . . . . . . . . . . . . . . . . .  11
     5.  Transparency Log (Informative)  . . . . . . . . . . . . . . .  11
     6.  Algorithm Agility (Post-Quantum)  . . . . . . . . . . . . . .  12



  En Nakhai                Expires 6 November 2026                [Page 2]


  Internet-Draft               Crovia Seal v1                     May 2026


     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
       7.1.  Replay Across Protocols . . . . . . . . . . . . . . . . .  12
       7.2.  Replay Within the Protocol  . . . . . . . . . . . . . . .  12
       7.3.  JSON Malleability . . . . . . . . . . . . . . . . . . . .  12
       7.4.  Field Tampering . . . . . . . . . . . . . . . . . . . . .  12
       7.5.  Key Compromise  . . . . . . . . . . . . . . . . . . . . .  12
       7.6.  Downgrade . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.7.  Canonicalization Ambiguity  . . . . . . . . . . . . . . .  13
       7.8.  Hash Choice . . . . . . . . . . . . . . . . . . . . . . .  13
       7.9.  Randomness  . . . . . . . . . . . . . . . . . . . . . . .  13
       7.10. Content Privacy . . . . . . . . . . . . . . . . . . . . .  13
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
       8.1.  Media Type Registration . . . . . . . . . . . . . . . . .  13
       8.2.  URN Sub-Namespace Registration  . . . . . . . . . . . . .  14
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
     Appendix A.  Reference Implementation . . . . . . . . . . . . . .  15
     Appendix B.  Changelog  . . . . . . . . . . . . . . . . . . . . .  15
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction

     Outputs produced by automated generative systems (large language
     models, diffusion image models, speech-synthesis pipelines, or
     composite agents) are difficult to attribute reliably after they
     leave the generating system.  Today, an output may be quoted, edited,
     copy-pasted, ingested into a search index, surfaced in a court
     filing, or attributed to the wrong vendor with no available chain of
     custody.  Both vendors and downstream consumers have an operational
     interest in an attestation that fixes, at the moment of generation,
     the bytes that were produced and the parameters under which they were
     produced.

     This document specifies a single such attestation: the *Crovia Seal*.
     A Seal is a JSON object whose bytes are signed by an issuer's Ed25519
     private key after a deterministic canonicalization (Section 3) and
     with explicit cryptographic domain separation (Section 3.3).  A Seal
     carries the SHA-256 digest of the input that was provided to the
     generator, the SHA-256 digest of the output, the generator identity
     and generation parameters, an issuance timestamp, and a per-issuer
     append-only hash chain.  Optional fields carry inclusion proofs from
     public transparency logs and additional co-signatures ("witnesses").

     A Seal does *not* attest to the truthfulness, lawfulness,
     originality, or safety of the output.  It is a receipt, not a
     verdict.  This deliberate narrowness is essential to the protocol's



  En Nakhai                Expires 6 November 2026                [Page 3]


  Internet-Draft               Crovia Seal v1                     May 2026


     value: the Seal can be re-verified by any party possessing only the
     Seal, the issuer's public key, and the original output bytes, without
     dependence on any judgement that cannot be cryptographically checked.

  1.1.  Conventions and Terminology

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

     The following terms are used throughout this document:

     Seal:  a single JSON object conforming to Section 3.

     Issuer:  the entity producing and signing Seals; identified by its
        long-term Ed25519 public key.

     Witness:  an optional co-signer of a Seal (Section 4).

     Subject:  the input/output pair that the Seal describes.

     Generator:  the AI model or system that produced the output.

     Chain:  the per-issuer append-only sequence of Seals (Section 3.8).

     Anchor:  an optional proof that the Seal was included in a public
        transparency log (Section 5).

     CSC-1:  Crovia Seal Canonicalization v1 (Section 2).

     Payload:  the exact byte sequence over which a signature is computed
        (Section 2.3).

  1.2.  Design Principles

     *  *Record, do not judge.* The Seal MUST NOT encode verdicts on
        lawfulness, harm, or quality.  It MAY embed analytical signals
        with explicit confidence.

     *  *Verify offline.* The core verification path MUST require no
        network access.

     *  *Composable.* The schema MUST permit optional extensions (co-
        signatures, post-quantum signatures, transparency anchors) without
        breaking base verifiers.




  En Nakhai                Expires 6 November 2026                [Page 4]


  Internet-Draft               Crovia Seal v1                     May 2026


     *  *Canonical.* The exact bytes that are signed MUST be derivable
        from the Seal by a single, fully specified canonicalization
        algorithm.

     *  *Defensive by default.* All cryptographic operations MUST use
        domain separation; no signed payload may be replayed in another
        protocol.

     *  *Fail closed.* Any unrecognized field or algorithm MUST cause
        verification to fail unless the verifier explicitly opts into
        permissive mode.

  1.3.  Out of Scope

     The following are explicitly out of scope for this specification.  An
     attestation that silently included any of them would be misunderstood
     by users:

     *  Detection of AI-generated content from the output alone (no
        watermarking).

     *  Judgements about copyright, fairness, accuracy, or safety of the
        output.

     *  Revocation: a Seal, once emitted, is an immutable historical
        record.  Issuers are identified by public key; key rotation is
        handled by the transparency log, not by Seal-level revocation.

     *  Authentication of the human user that requested the generation.
        The Seal binds bytes, not personhoods.

     *  Confidentiality.  Seals are over plaintext.

  2.  Canonicalization (CSC-1)

  2.1.  Motivation

     JSON [RFC8259] is syntactically flexible: whitespace, key ordering,
     number formatting, and string-escape choices can vary while producing
     the same logical value.  A signature over a JSON text requires an
     unambiguous serialization.










  En Nakhai                Expires 6 November 2026                [Page 5]


  Internet-Draft               Crovia Seal v1                     May 2026


     CSC-1 is a strict subset of the JSON Canonicalization Scheme (JCS)
     [RFC8785].  It adopts the deterministic ordering and escaping rules
     of JCS but forbids floating-point numbers in signed payloads,
     sidestepping the edge cases of ECMA-262 number serialization.  This
     restriction does not constrain use cases: continuous parameters such
     as temperature MUST be encoded as strings when carried inside the
     signed payload (Section 3.6).

  2.2.  Rules

     A CSC-1-serialized JSON value is a UTF-8 byte sequence produced as
     follows:

     1.  null -> null

     2.  true / false -> true / false

     3.  integers (JSON number with no fractional part, within [-(2^53 -
         1), 2^53 - 1]) -> shortest decimal representation, no leading
         zeros, no + sign.

     4.  strings -> UTF-8 JSON string literal using only the escapes
         required by [RFC8259]: \", \\, \b, \f, \n, \r, \t, and \u00XX for
         U+0000..U+001F.  All other code points MUST be emitted literally.

     5.  arrays -> [ followed by canonicalized elements separated by ,
         followed by ].  No interior whitespace.

     6.  objects -> { followed by "key":value pairs separated by ,
         followed by }.  Keys MUST be sorted ascending by their UTF-16
         code-unit sequence (equivalent to JavaScript Array.prototype.sort
         on strings).  No interior whitespace.

     7.  floats, NaN, Infinity, and -0 MUST cause serialization to fail
         with NonCanonicalNumber.

     8.  duplicate object keys MUST cause serialization to fail with
         DuplicateKey.

     9.  non-string object keys MUST cause serialization to fail with
         NonStringKey.

  2.3.  Signing Payload

     Given a Seal _S_, the signing payload _P(S)_ is computed as:

     P(S) = DOMAIN || 0x0A || CSC1(S \ {signature, witnesses})




  En Nakhai                Expires 6 November 2026                [Page 6]


  Internet-Draft               Crovia Seal v1                     May 2026


     where:

     *  DOMAIN is the ASCII string "CROVIA-SEAL-v1" (14 bytes).

     *  0x0A is a single newline byte, acting as an unambiguous separator.

     *  S \ {signature, witnesses} denotes the Seal with the signature and
        witnesses top-level fields removed (they are computed over the
        payload, not part of it).

     *  CSC1(...) is the UTF-8 serialization per Section 2.2.

     The DOMAIN prefix ensures that a signature over _P(S)_ cannot be
     replayed as a valid signature in any other protocol that does not use
     the same prefix.  Implementations MUST NOT omit the prefix.
     Verifiers MUST reject any Seal whose signature was produced without
     the prefix.

  3.  Seal Structure

  3.1.  Top-Level Fields

     A conformant Seal is a JSON object with exactly the top-level fields
     listed below.  Unknown top-level fields MUST cause verification to
     fail (the "fail closed" principle).


























  En Nakhai                Expires 6 November 2026                [Page 7]


  Internet-Draft               Crovia Seal v1                     May 2026


                +==============+==========+========+=========+
                | Field        | Required | Type   | Section |
                +==============+==========+========+=========+
                | seal_version | MUST     | string | 4.2     |
                +--------------+----------+--------+---------+
                | seal_id      | MUST     | string | 4.3     |
                +--------------+----------+--------+---------+
                | issuer       | MUST     | object | 4.4     |
                +--------------+----------+--------+---------+
                | subject      | MUST     | object | 4.5     |
                +--------------+----------+--------+---------+
                | generator    | MUST     | object | 4.6     |
                +--------------+----------+--------+---------+
                | timestamp    | MUST     | object | 4.7     |
                +--------------+----------+--------+---------+
                | chain        | MUST     | object | 4.8     |
                +--------------+----------+--------+---------+
                | checks       | OPTIONAL | object | 4.9     |
                +--------------+----------+--------+---------+
                | anchor       | OPTIONAL | object | 4.10    |
                +--------------+----------+--------+---------+
                | signature    | MUST     | object | 4.11    |
                +--------------+----------+--------+---------+
                | witnesses    | OPTIONAL | array  | 6       |
                +--------------+----------+--------+---------+

                                   Table 1

  3.2.  seal_version

     The literal string "crovia.seal.v1".  Any other value MUST cause
     verification to fail.

  3.3.  seal_id

     A string matching the regular expression ^cs_[0-9]{4}_[A-Z2-7]{26}$:
     prefix cs_, 4-digit issuance year, underscore, 26 RFC 4648 base32
     characters [RFC4648] (alphabet A-Z, 2-7, no padding) encoding 16
     random bytes (128 bits).  The random bytes MUST be produced by a
     cryptographically secure source.

  3.4.  issuer

     {
       "id":     string,           ; urn:crovia:seal-issuer:<name>
       "pubkey": { "alg": "ed25519", "key_hex": string }
     }




  En Nakhai                Expires 6 November 2026                [Page 8]


  Internet-Draft               Crovia Seal v1                     May 2026


     key_hex is 64 lowercase hexadecimal characters (32 raw bytes, Ed25519
     public key per [RFC8032]).  Other algorithms are reserved for
     Section 6.

  3.5.  subject

   {
     "input_hash":  "sha256:" + 64 lowercase hex chars,
     "output_hash": "sha256:" + 64 lowercase hex chars,
     "input_len":   integer,    ; byte length of input
     "output_len":  integer,    ; byte length of output
     "modality":    string      ; one of: text/code/image/audio/multimodal
   }

     The Seal does NOT carry the content itself.  The hashes commit to the
     content; verifiers who possess the content can re-hash and compare.

  3.6.  generator

     {
       "id":           string,          ; e.g. "openai/gpt-4o"
       "version":      string | null,   ; e.g. "2024-08-06"
       "weights_hash": string | null,   ; if available
       "params":       object           ; key -> string map of gen-params
     }

     All parameter values MUST be strings in the signed payload (per the
     floating-point restriction in Section 2).  Numeric values like
     temperature=0.7 MUST be encoded as "0.7".

  3.7.  timestamp

    {
      "emitted_at": string,   ; RFC 3339 UTC, ms precision
                              ; e.g. "2026-04-15T12:34:56.789Z"
      "nonce":      string    ; 26 RFC 4648 base32 chars (16 random bytes)
    }

     emitted_at follows [RFC3339].  Issuers MUST use UTC.  The nonce
     guarantees that two Seals issued in the same millisecond are still
     distinct under P(S).

  3.8.  chain

     {
       "prev_seal_hash": "sha256:" + 64 hex chars | null,
       "sequence":       integer (>= 0)
     }



  En Nakhai                Expires 6 November 2026                [Page 9]


  Internet-Draft               Crovia Seal v1                     May 2026


     prev_seal_hash is the SHA-256 over the canonical payload _P(S_prev)_
     of the immediately preceding Seal from the same issuer, or null for
     the genesis Seal (sequence == 0).  Verifiers that track issuer chains
     MUST detect:

     *  *Fork*: two Seals with the same issuer key and same chain.sequence
        but different prev_seal_hash.  This is non-repudiable evidence of
        issuer misbehavior or key compromise.

     *  *Gap*: missing sequence numbers.  A verifier with partial history
        SHOULD obtain the missing Seals from the transparency log before
        accepting.

  3.9.  checks (OPTIONAL)

     Free-form object carrying analytical claims such as memorization
     checks, safety probes, toxicity scores.  The schema for specific
     check types is defined in separate check specifications; the Seal
     itself imposes no constraints on the content beyond CSC-1
     compatibility.

     Example:

     {
       "memorization": {
         "db_version": "crovia-memdb-2026-04-15",
         "method":     "ngram-lsh-v1",
         "matches":    0,
         "max_conf":   "0.03"
       }
     }

     Each check produced by an issuer is signed along with the rest of the
     Seal; its validity as evidence depends on the method's own
     robustness, which is out of scope for this specification.

  3.10.  anchor (OPTIONAL)

     {
       "log_url":        string,
       "merkle_root":    "sha256:" + 64 hex chars,
       "merkle_proof":   [ "sha256:" + hex, ... ],
       "log_index":      integer (>= 0),
       "root_signed_at": string (RFC 3339 UTC)
     }






  En Nakhai                Expires 6 November 2026               [Page 10]


  Internet-Draft               Crovia Seal v1                     May 2026


     The anchor commits the Seal to a public transparency log.  The log
     operator's signature over merkle_root is not part of this Seal and
     MUST be fetched separately from log_url.

  3.11.  signature

     {
       "alg":              "ed25519",
       "canon":            "csc-1",
       "domain":           "CROVIA-SEAL-v1",
       "payload_hash_alg": "sha256",
       "sig_hex":          string     ; 128 hex chars (64 raw bytes)
     }

     The signature is computed as Ed25519_sign(privkey, P(S)) where _P(S)_
     is defined in Section 2.3.  Implementations MUST NOT hash the payload
     before signing; Ed25519 internally handles the hash (SHA-512).  The
     payload_hash_alg field is informational, indicating the algorithm
     used to derive prev_seal_hash and other SHA-256 digests in the Seal.

  4.  Witnesses (OPTIONAL)

     "witnesses": [
       {
         "id":      string,
         "pubkey":  { "alg": "ed25519", "key_hex": string },
         "sig_hex": string
       },
       ...
     ]

     A witness signs the same canonical payload _P(S)_ as the issuer.
     Witness signatures are OPTIONAL and additive: a Seal with no
     witnesses is valid; a Seal with invalid witness signatures is invalid
     overall (fail-closed).

     Typical witnesses: consortium co-signers (civil-society
     organizations, academic institutions, regulatory observers).
     Witnesses endorse the Seal without endorsing its content.

  5.  Transparency Log (Informative)

     A conformant transparency log accepts Seals and periodically
     publishes a signed Merkle root over the Seals it has received.  The
     log API design is outside the scope of this document; an
     implementation profile compatible with [RFC9162]-style logs is
     anticipated in a companion document.




  En Nakhai                Expires 6 November 2026               [Page 11]


  Internet-Draft               Crovia Seal v1                     May 2026


  6.  Algorithm Agility (Post-Quantum)

     Future versions of this specification MAY permit alternative
     signature algorithms (e.g., Dilithium, Falcon) by extending the
     signature.alg vocabulary.  A Seal MAY additionally carry a
     pq_signature top-level field with an independent post-quantum
     signature over the same payload _P(S)_.  Verifiers that support only
     Ed25519 MUST ignore pq_signature and rely on signature.  Verifiers
     MAY require both signatures to validate (strict mode).

  7.  Security Considerations

  7.1.  Replay Across Protocols

     Prevented by domain separation (Section 2.3).  A signature on _P(S)_
     cannot be reinterpreted as a valid signature on a payload of any
     other protocol that does not use the exact same 14-byte CROVIA-
     SEAL-v1 prefix followed by a newline.

  7.2.  Replay Within the Protocol

     A Seal is a historical record; "replay" of a Seal is a semantic
     issue, not a cryptographic one.  The seal_id, timestamp, and
     chain.sequence fields make each Seal unique.  Verifiers that track
     seen seal IDs can detect duplication attempts.

  7.3.  JSON Malleability

     Eliminated by CSC-1 (Section 2).  Any tool that reorders keys, adds
     whitespace, or re-escapes strings produces a different byte sequence
     and hence an invalid signature.

  7.4.  Field Tampering

     The signature covers every field except signature and witnesses,
     which are themselves cryptographic.  Adding, modifying, or deleting
     any field invalidates the signature.

  7.5.  Key Compromise

     If an issuer key is compromised, the attacker can issue valid Seals
     until the compromise is detected and the key is revoked in the
     transparency log's trust root.  The issuer hash chain MAY reveal the
     compromise if the attacker issues a forking Seal.







  En Nakhai                Expires 6 November 2026               [Page 12]


  Internet-Draft               Crovia Seal v1                     May 2026


  7.6.  Downgrade

     seal_version, signature.alg, signature.canon, and signature.domain
     are all inside the signed payload.  An attacker cannot negotiate a
     weaker algorithm without producing a wholly new signature.

  7.7.  Canonicalization Ambiguity

     CSC-1 forbids floats in the signed payload precisely to avoid the
     numeric edge cases of JCS.  Strings carrying numeric values MUST use
     a documented format (see Section 3.6).

  7.8.  Hash Choice

     SHA-256 is used for all digests (content commitments, chain links).
     Migration to SHA-3 or BLAKE3 is anticipated in a future minor
     version; the payload_hash_alg field signals the choice.

  7.9.  Randomness

     All random values (seal_id suffix, timestamp.nonce) MUST be produced
     by a cryptographically secure source (e.g., os.urandom, the secrets
     module in Python, crypto.randomBytes in Node.js).

  7.10.  Content Privacy

     The Seal commits to input/output hashes, never content.  Content-
     bearing fields such as generator.params are in the clear; issuers
     MUST NOT place sensitive user data in these fields.

  8.  IANA Considerations

  8.1.  Media Type Registration

     IANA is requested to register the following media type per [RFC6838]:

     Type name:  application

     Subtype name:  vnd.crovia.seal+json

     Required parameters:  none

     Optional parameters:  none

     Encoding:  UTF-8 (per [RFC8259])

     Security considerations:  see Section 7




  En Nakhai                Expires 6 November 2026               [Page 13]


  Internet-Draft               Crovia Seal v1                     May 2026


     Interoperability:  see this document

     Published specification:  this document

     Applications using this type:  provenance attestation systems for AI-
        generated content

     Author/Change controller:  CROVIA Research

  8.2.  URN Sub-Namespace Registration

     IANA is requested to register the URN namespace urn:crovia:seal-
     issuer: per [RFC8141] for the identification of Crovia Seal issuers
     by stable URN.  The complete formal namespace registration template
     will be provided in a companion document.

  9.  References

  9.1.  Normative References

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

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

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

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

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

     [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
                (URNs)", RFC 8141, April 2017,
                <https://www.rfc-editor.org/info/rfc8141>.






  En Nakhai                Expires 6 November 2026               [Page 14]


  Internet-Draft               Crovia Seal v1                     May 2026


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

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

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

  9.2.  Informative References

     [C2PA]     Coalition for Content Provenance and Authenticity, "C2PA
                Content Credentials Specification, Version 1.3", 2024,
                <https://c2pa.org/specifications/specifications/1.3/specs/
                C2PA_Specification.html>.

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

     [SIGSTORE] The Linux Foundation, "Sigstore: Software signing for
                everyone", 2021, <https://www.sigstore.dev/>.

  Appendix A.  Reference Implementation

     A reference implementation in Python and TypeScript, including a
     public sealing service, an in-browser verifier, and a set of
     normative test vectors, is available at
     https://croviatrust.com/registry/seal/.  Test vectors are linked from
     https://croviatrust.com/registry/seal/spec/.

  Appendix B.  Changelog

     *draft-crovia-seal-01* (May 2026):

     *  Editorial: replaced 6 Unicode arrow characters (U+2192) with ASCII
        -> so the rendered text file is strictly ASCII-clean (0 idnits
        warnings).  No normative changes.

     *draft-crovia-seal-00* (May 2026):

     *  Initial submission.  Aligned with Crovia Seal Specification v0.5
        of April 2026.





  En Nakhai                Expires 6 November 2026               [Page 15]


  Internet-Draft               Crovia Seal v1                     May 2026


  Acknowledgements

     The Crovia Seal has been informed by extensive prior work in
     cryptographic transparency ([RFC9162], [SIGSTORE]) and media-
     provenance attestation ([C2PA]).  The authors thank the broader
     community working on AI provenance and tamper-evidence for the
     intellectual foundations on which this work rests.

  Author's Address

     Tarik En Nakhai
     Crovia Trust
     Italy
     Email: info@croviatrust.com
     URI:   https://croviatrust.com




































  En Nakhai                Expires 6 November 2026               [Page 16]


name: draft-miller-ztip
rev: 00
title: Zero-Trust Intent Protocol (ZTIP)
time: 2026-04-27T22:10:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-29T22:10:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:54.958470+00:00
source: ietf
abstract:
  The Zero-Trust Intent Protocol (ZTIP) defines three primitives for
     verifiable delegation, intent binding, and behavioral attestation in
     multi-agent systems:

full_text:
  Network Working Group                                          J. Miller
  Internet-Draft                                             27 April 2026
  Intended status: Standards Track                                        
  Expires: 29 October 2026


                     Zero-Trust Intent Protocol (ZTIP)
                            draft-miller-ztip-00

  Abstract

     The Zero-Trust Intent Protocol (ZTIP) defines three primitives for
     verifiable delegation, intent binding, and behavioral attestation in
     multi-agent systems:

     1.  *Delegation Chain Attestation* — a nested-JWS structure carrying
         signed delegation from a root principal (a human user, an
         orchestrator, or a trusted root) through intermediary agents to a
         downstream agent or tool, with cryptographic enforcement of scope
         monotonicity.

     2.  *Intent-Scoped Authorization* — extends any signed authorization
         token (OAuth 2.0 access tokens, GNAP grants, ZTNP Permits, or
         vendor-defined tokens) with a hash of the originator's signed
         intent, so that an agent operating under that token cannot use it
         for actions inconsistent with the original authorization.  This
         addresses the prompt-injection-induced confused-deputy attack.

     3.  *Behavioral Claim Extensions* — a claim shape conveying
         behavioral safety properties (prompt-injection-tested, tool-call-
         audit-logged, output-validated, human-in-loop policy, etc.) that
         can be carried in any signed credential about an agent.

     ZTIP is composable.  It can be deployed standalone, composed with the
     Zero-Trust Negotiation Protocol (ZTNP) Core [I-D.miller-ztnp] for
     posture-aware deployments, composed with OAuth 2.0 / JWT for token-
     bound deployments, composed with GNAP [RFC9635], or composed with
     bespoke authorization systems.  Section 6 specifies concrete
     composition profiles.

     This draft is an individual submission.  The appropriate IETF venue
     for progressing this work is an open question; the author welcomes
     community guidance.

  Status of This Memo

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



  Miller                   Expires 29 October 2026                [Page 1]


  Internet-Draft                    ZTIP                        April 2026


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

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

     This Internet-Draft will expire on 29 October 2026.

  Copyright Notice

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

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  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.  Goals . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   5
       1.3.  Relationship to Existing Token Chaining Mechanisms  . . .   5
       1.4.  Document Structure  . . . . . . . . . . . . . . . . . . .   6
       1.5.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Delegation Chain Attestation  . . . . . . . . . . . . . . . .   8
       3.1.  Chain Structure . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Intent Object Schema and Canonicalization . . . . . . . .   9
         3.2.1.  Intent Object Schema  . . . . . . . . . . . . . . . .  10
         3.2.2.  Canonicalization  . . . . . . . . . . . . . . . . . .  10
         3.2.3.  Intent Hash . . . . . . . . . . . . . . . . . . . . .  11
         3.2.4.  Inline Examples . . . . . . . . . . . . . . . . . . .  11
       3.3.  Verification Rules  . . . . . . . . . . . . . . . . . . .  13
       3.4.  Formal Definition of Scope Monotonicity . . . . . . . . .  14
       3.5.  Maximum Chain Depth . . . . . . . . . . . . . . . . . . .  16
       3.6.  Carrying the Chain in Authorization Flows . . . . . . . .  17
       3.7.  Chain-Specific Reason Codes . . . . . . . . . . . . . . .  17
     4.  Intent-Scoped Authorization . . . . . . . . . . . . . . . . .  18



  Miller                   Expires 29 October 2026                [Page 2]


  Internet-Draft                    ZTIP                        April 2026


       4.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .  18
       4.2.  Field Extensions to Authorization Tokens  . . . . . . . .  18
       4.3.  Scope Consistency Check . . . . . . . . . . . . . . . . .  19
       4.4.  Operation Classification  . . . . . . . . . . . . . . . .  20
     5.  Behavioral Claim Extensions . . . . . . . . . . . . . . . . .  21
       5.1.  Standard AI Behavior Claims . . . . . . . . . . . . . . .  21
         5.1.1.  Evidence Sub-Field  . . . . . . . . . . . . . . . . .  23
         5.1.2.  Baseline Corpora for "Tested" Claims  . . . . . . . .  24
       5.2.  Vendor-Defined and Bespoke Claims . . . . . . . . . . . .  25
       5.3.  Interaction with Standard Claims  . . . . . . . . . . . .  26
     6.  Composition Profiles  . . . . . . . . . . . . . . . . . . . .  26
       6.1.  Composition with ZTNP . . . . . . . . . . . . . . . . . .  26
       6.2.  Composition with OAuth 2.0 / JWT  . . . . . . . . . . . .  26
       6.3.  Composition with GNAP . . . . . . . . . . . . . . . . . .  27
       6.4.  Custom Authorization Systems  . . . . . . . . . . . . . .  29
       6.5.  Deployment Pattern: Transparent Intermediate Signer . . .  29
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  32
       7.1.  Trust Anchor  . . . . . . . . . . . . . . . . . . . . . .  33
       7.2.  Additional Adversaries  . . . . . . . . . . . . . . . . .  34
       7.3.  Attack Surface and Mitigations  . . . . . . . . . . . . .  34
       7.4.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .  35
     8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  36
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
       9.1.  ZTIP Denial Reason Code Registry  . . . . . . . . . . . .  37
       9.2.  HTTP Field Name Registration  . . . . . . . . . . . . . .  38
       9.3.  Note on Behavioral Claim Names  . . . . . . . . . . . . .  39
     10. Implementation Status . . . . . . . . . . . . . . . . . . . .  39
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  40
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  40
       11.2.  Informative References . . . . . . . . . . . . . . . . .  40
     Appendix A.  Worked Example: Three-Hop Delegation Chain (ZTNP
             Composition)  . . . . . . . . . . . . . . . . . . . . . .  42
       A.1.  Scenario  . . . . . . . . . . . . . . . . . . . . . . . .  42
       A.2.  A.1 Layer 0: Signed Intent (Root) . . . . . . . . . . . .  42
       A.3.  A.2 Layer 1: Orchestrator's Delegation  . . . . . . . . .  43
       A.4.  A.3 Layer 2: Summarizer's Delegation  . . . . . . . . . .  44
       A.5.  A.4 Verification Transcript at the Tool . . . . . . . . .  44
       A.6.  A.5 Intent-Scoped Permit Issued Alongside the Chain . . .  45
       A.7.  A.6 Failure Modes . . . . . . . . . . . . . . . . . . . .  46
     Appendix B.  Comparison with Macaroons and Related Capability
             Tokens  . . . . . . . . . . . . . . . . . . . . . . . . .  46
       B.1.  At a Glance . . . . . . . . . . . . . . . . . . . . . . .  46
       B.2.  When Macaroons Fit Better Than ZTIP . . . . . . . . . . .  47
       B.3.  When ZTIP Fits Better Than Macaroons  . . . . . . . . . .  47
       B.4.  Conceptual Lineage  . . . . . . . . . . . . . . . . . . .  48
     Appendix C.  Conformance Profile  . . . . . . . . . . . . . . . .  48
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  49
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  49



  Miller                   Expires 29 October 2026                [Page 3]


  Internet-Draft                    ZTIP                        April 2026


  1.  Introduction

     In multi-principal delegation chains, an action is rarely the work of
     a single principal.  A human user instructs an orchestrator; the
     orchestrator delegates a subtask to a sub-agent; the sub-agent
     invokes a tool.  This chain of delegation introduces three classes of
     security problem that existing protocols do not address:

     1.  *Delegation integrity.* When a downstream tool receives a call,
         can it verify that the call chain leading to it was authorized
         end-to-end?  Per-hop authorization tokens (OAuth 2.0 access
         tokens, JWTs, ZTNP Permits) only show that the immediately
         upstream party was trusted by the receiver — not that the entire
         chain back to the originating principal was authorized.

     2.  *Intent binding.* An authorization token issued for "summarize
         email" can be used for any action within the token's stated
         scope.  If a sub-agent is prompt-injected mid-task into "send all
         email to attacker.example", the token's signature is still valid;
         only the intent has been substituted.  This is a confused-deputy
         attack mediated by language-model context manipulation.

     3.  *Behavioral transparency.* A receiver applying policy to a
         language-model-driven agent needs more than identity and scope.
         Has the agent been tested against prompt injection?  Are its tool
         calls audited?  What is its human-in-loop policy?  These are
         behavioral posture properties that don't fit the generic claim
         schemas of identity and authorization protocols.

     ZTIP addresses these three problems with three primitives, specified
     in Sections 3, 4, and 5.  Each primitive is independently useful;
     deployments MAY adopt one without the others.

     ZTIP does not require any specific authorization or identity
     protocol.  It defines its primitives in the abstract and provides
     composition profiles (Section 6) for the most common authorization
     systems: OAuth 2.0 / JWT, GNAP, ZTNP, and vendor-defined tokens.
     This pattern follows DPoP [RFC9449], which is technically standalone
     but most often composed with OAuth 2.0.

  1.1.  Goals

     ZTIP is designed to:

     1.  Provide cryptographic evidence of delegation authority from a
         root principal to a downstream agent, with verifiable scope
         monotonicity at each layer.




  Miller                   Expires 29 October 2026                [Page 4]


  Internet-Draft                    ZTIP                        April 2026


     2.  Bind authorization to specific user intent, preventing prompt-
         injection-induced authorization expansion.

     3.  Convey behavioral posture claims that inform policy decisions
         about which capabilities an agent may access.

     4.  Compose with multiple authorization systems without requiring any
         specific one.

  1.2.  Non-Goals

     ZTIP does not define:

     *  Identity or authentication.

     *  The runtime envelope for inter-agent communication.

     *  The tool capability protocol.

     *  Posture assessment or framework semantics (see ZTNP
        [I-D.miller-ztnp]).

     *  A new authorization-token format.  ZTIP extends existing
        authorization tokens; it does not define a new one.

     *  A specific Key Source mechanism.  ZTIP is agnostic between JWKS
        endpoints, X.509 chains, ZTNP's IKS, and DID resolution.

  1.3.  Relationship to Existing Token Chaining Mechanisms

     Reviewers familiar with nested JWTs, OAuth 2.0 Token Exchange
     [RFC8693], or GNAP continuation [RFC9635] may reasonably ask why ZTIP
     defines new primitives rather than reusing those mechanisms.  The
     structures look superficially similar: a chain of signed credentials,
     each issued in response to a prior one.  ZTIP's primitives differ on
     three properties that none of those mechanisms provide.

     1.  *Monotonic scope enforcement at every receiver.* Token Exchange
         permits a client to request a downstream token whose scope is
         determined by the AS's policy; the issued token's scope is not
         constrained by protocol to be a subset of the inbound token's
         scope.  There is no protocol-level guarantee that "this
         downstream token grants only what the upstream token already
         granted."  ZTIP's Section 3.4 makes scope reduction a normative
         property of the chain itself, verifiable at any receiver without
         recourse to the AS.





  Miller                   Expires 29 October 2026                [Page 5]


  Internet-Draft                    ZTIP                        April 2026


     2.  *End-to-end chain auditability.* Nested JWTs and chained Token
         Exchange responses do not preserve the identity and signature of
         every intermediary.  A receiver of a token-exchanged JWT
         typically sees only the AS's signature; the chain of clients that
         requested and re-requested the token is opaque to the resource
         server.  ZTIP's nested-JWS structure preserves each delegator's
         signature, so the receiver can verify "who authorized whom" for
         every step of the chain.

     3.  *Originator intent binding.* No existing token-chaining mechanism
         binds an issued token to a structured originator intent.  A
         token-exchanged token is bound to its scope; ZTIP additionally
         binds it to the specific intent (intent_hash) the originator
         signed.  This is what makes Section 4 a defense against prompt-
         injection-induced confused-deputy attacks: an injected
         instruction can request operations within the token's scope, but
         those operations will not match the bound intent.

     In short: existing token-chaining mechanisms answer "may this client
     present this token?"  ZTIP additionally answers "did the original
     principal authorize this entire chain to perform this specific
     operation?"  Deployments needing only the former should continue to
     use existing mechanisms; ZTIP is for deployments that need both.

  1.4.  Document Structure

     Sections 2 and 3 define terminology and the Delegation Chain
     Attestation primitive.  Section 4 defines Intent-Scoped
     Authorization.  Section 5 defines Behavioral Claim Extensions.
     Section 6 defines composition profiles for OAuth 2.0, ZTNP, GNAP, and
     custom authorization systems.  Sections 7 and 8 contain Security and
     Privacy Considerations.  Section 9 contains IANA Considerations.
     Appendix A is a worked example using the ZTNP composition profile.
     Appendix B defines the conformance profile.

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









  Miller                   Expires 29 October 2026                [Page 6]


  Internet-Draft                    ZTIP                        April 2026


  2.  Terminology

     +===============+===================================================+
     | Term          | Definition                                        |
     +===============+===================================================+
     | Originator    | The root principal of a Delegation Chain          |
     |               | — a user, an orchestrator, or a trusted           |
     |               | root system that initiated an action.             |
     +---------------+---------------------------------------------------+
     | Signed Intent | A JWS produced by an Originator                   |
     |               | describing the originally authorized              |
     |               | action and its scope.                             |
     +---------------+---------------------------------------------------+
     | Delegation    | A nested-JWS structure rooted at a Signed         |
     | Chain         | Intent, with each delegating principal            |
     |               | adding a signature layer that names the           |
     |               | next party.                                       |
     +---------------+---------------------------------------------------+
     | Scope         | The principle that each layer of a                |
     | Reduction     | Delegation Chain may grant a subset, not          |
     |               | a superset, of its parent's scope                 |
     |               | (Section 3.4).                                    |
     +---------------+---------------------------------------------------+
     | Authorization | A signed authorization credential                 |
     | Token         | carrying scope and expiration information         |
     |               | about a delegated capability.  Examples:          |
     |               | OAuth 2.0 access tokens, GNAP grants,             |
     |               | ZTNP Permits.                                     |
     +---------------+---------------------------------------------------+
     | Intent-Scoped | An Authorization Token additionally               |
     | Authorization | extended with the four ZTIP fields                |
     | Token         | defined in Section 4: intent_hash,                |
     |               | intent_scope, chain_root_iss,                     |
     |               | chain_root_jti.                                   |
     +---------------+---------------------------------------------------+
     | Key Source    | A mechanism by which a verifier obtains           |
     |               | the public key of a signing principal — a         |
     |               | JWKS endpoint, an X.509 chain, an Issuer          |
     |               | Key Set (when composed with ZTNP), or a           |
     |               | DID resolution.  ZTIP is agnostic to the          |
     |               | specific Key Source mechanism.                    |
     +---------------+---------------------------------------------------+
     | Behavioral    | A claim shape (Section 5) carrying                |
     | Claims        | behavioral safety properties of an agent.         |
     |               | May appear in any signed credential about         |
     |               | an agent.                                         |
     +---------------+---------------------------------------------------+




  Miller                   Expires 29 October 2026                [Page 7]


  Internet-Draft                    ZTIP                        April 2026


                                    Table 1

  3.  Delegation Chain Attestation

     A Delegation Chain is a nested-JWS structure in which each delegating
     principal adds a signature layer.  The root of the chain is a Signed
     Intent produced by the Originator.  Each downstream layer wraps the
     previous chain and is signed by the principal delegating to the next.

     ZTIP does not specify how each principal's public key is discovered.
     Implementations resolve keys via a Key Source appropriate to their
     deployment.  Section 6 defines specific composition profiles and
     their Key Source mechanisms.

  3.1.  Chain Structure

     Three-hop example (user → orchestrator → sub-agent → tool):


































  Miller                   Expires 29 October 2026                [Page 8]


  Internet-Draft                    ZTIP                        April 2026


  Outermost (sub-agent A's JWS):
    payload: {
      "del_chain_ver": "0.1",
      "delegator": "agent:A",
      "delegatee": "tool:T",
      "scope_reduction": { "actions": ["read"], "data": ["internal"] },
      "iat": ..., "exp": ...,
      "inner": "<orchestrator O's compact JWS>"
    }

  Middle (orchestrator O's JWS):
    payload: {
      "del_chain_ver": "0.1",
      "delegator": "principal:O",
      "delegatee": "agent:A",
      "scope_reduction": { ... },
      "iat": ..., "exp": ...,
      "inner": "<root Signed Intent compact JWS>"
    }

  Root (Signed Intent):
    payload: {
      "del_chain_ver": "0.1",
      "intent_root": true,
      "originator": "user:alice",
      "intent_object": { ... structured intent (Section 3.2) ... },
      "intent_hash": "<base64url(SHA-256(JCS(intent_object) UTF-8 bytes))>",
      "authorized_chain": ["principal:O", "agent:A"],
      "scope": { ... },
      "iat": ..., "exp": ...
    }

  3.2.  Intent Object Schema and Canonicalization

     The root layer's intent — what the originating principal is
     authorizing — MUST be expressed as a structured JSON object, not as
     free-form natural-language text.  Three reasons:

     1.  Free-form text is not reproducibly hashable across implementers
         (whitespace, line endings, and encoding choices all introduce
         non-determinism).

     2.  Free-form text is not machine-comparable to a downstream
         operation; verifiers need structured fields to evaluate
         intent_scope against a requested operation (Section 4).






  Miller                   Expires 29 October 2026                [Page 9]


  Internet-Draft                    ZTIP                        April 2026


     3.  A structured intent forces the originator's user interface to
         disambiguate intent at the point of signing, rather than
         deferring interpretation to downstream agents — which is
         precisely the gap that creates confused-deputy attacks.

  3.2.1.  Intent Object Schema

     The intent_object field on the root Signed Intent MUST be a JSON
     object containing at least:

       +=============+========+==========+=============================+
       | Field       | Type   | Required | Description                 |
       +=============+========+==========+=============================+
       | action      | string | Yes      | A short verb describing the |
       |             |        |          | user's desired operation    |
       |             |        |          | (e.g., "summarize",         |
       |             |        |          | "search", "compose").       |
       +-------------+--------+----------+-----------------------------+
       | scope       | object | Yes      | The scope within which the  |
       |             |        |          | originator authorizes       |
       |             |        |          | downstream agents to        |
       |             |        |          | operate.  MUST equal the    |
       |             |        |          | root layer's scope field.   |
       +-------------+--------+----------+-----------------------------+
       | target      | string | No       | A human-readable            |
       |             |        |          | description of what the     |
       |             |        |          | action operates on.         |
       +-------------+--------+----------+-----------------------------+
       | constraints | object | No       | Profile-defined additional  |
       |             |        |          | constraints (e.g.,          |
       |             |        |          | must_not, time-window       |
       |             |        |          | limits).                    |
       +-------------+--------+----------+-----------------------------+

                                    Table 2

     Profile documents MAY extend the schema with additional fields.
     Extension fields MUST NOT alter the meaning of the required fields
     above.

  3.2.2.  Canonicalization

     The canonical form of an intent_object is its JSON Canonicalization
     Scheme serialization, per [RFC8785].  JCS provides:

     *  Deterministic key ordering (lexicographic).





  Miller                   Expires 29 October 2026               [Page 10]


  Internet-Draft                    ZTIP                        April 2026


     *  Deterministic number representation (no trailing zeros, no
        scientific notation for non-special values).

     *  UTF-8 encoding of the resulting byte sequence.

     *  No insignificant whitespace.

     Implementers MUST use a JCS implementation conformant with RFC 8785.
     Variant canonicalization schemes MUST NOT be used.

  3.2.3.  Intent Hash

     intent_hash is computed as:

  intent_hash = base64url(SHA-256(JCS(intent_object) encoded as UTF-8 bytes))

     base64url is the URL-safe base64 encoding without padding, per
     Section 5 of [RFC7515].

     Verifiers receiving a chain MUST recompute intent_hash from the root
     layer's intent_object and verify it matches both:

     1.  The intent_hash field within the same root layer (consistency
         check).

     2.  The intent_hash field on any Intent-Scoped Authorization Token
         (Section 4) issued under this chain.

     Mismatch causes rejection with INTENT_SCOPE_MISMATCH.

  3.2.4.  Inline Examples

     Three intent objects illustrating common patterns.  Each is shown as
     the input JSON, the JCS canonical bytes (where shown), and the
     resulting intent_hash.  The hash values shown are computed against an
     RFC 8785 reference implementation; conforming implementations MUST
     produce these values for these inputs.

     *Example 1: Read-only summarization.*












  Miller                   Expires 29 October 2026               [Page 11]


  Internet-Draft                    ZTIP                        April 2026


     {
       "action": "summarize",
       "scope": {
         "actions": ["read"],
         "data": ["internal", "pii"],
         "tools": ["email.list", "email.read"]
       },
       "target": "unread emails from the last 24 hours",
       "constraints": {
         "must_not": ["email.send", "email.delete"]
       }
     }

     JCS canonical bytes (the actual canonical form, with no insignificant
     whitespace):

  {"action":"summarize","constraints":{"must_not":["email.send","email.delete"]},"scope":{"actions":["read"],"data":["internal","pii"],"tools":["email.list","email.read"]},"target":"unread emails from the last 24 hours"}

     JCS sorts object keys lexicographically (note action before
     constraints before scope before target at the top level, and must_not
     after actions/data/tools are reordered within the inner objects) but
     *preserves the insertion order of array elements* — must_not retains
     email.send before email.delete from the input.  RFC 8785 specifies
     key sorting for objects, not for array elements.

     Computed intent_hash: Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc.

     *Example 2: Knowledge-base search with redaction.*

     {
       "action": "search",
       "scope": {
         "actions": ["read"],
         "data": ["internal"],
         "tools": ["kb.query"]
       },
       "target": "internal product specifications matching 'thermostat'",
       "constraints": {
         "redact": ["customer_pii", "pricing_internal"]
       }
     }

     Computed intent_hash: vMdbs17cp0K0-TJKz8l5iTPMSgXLVN4Epyjq5yz7gYY.

     *Example 3: Financial transfer with strict allowlist.*






  Miller                   Expires 29 October 2026               [Page 12]


  Internet-Draft                    ZTIP                        April 2026


     {
       "action": "transfer_funds",
       "scope": {
         "actions": ["write"],
         "tools": ["bank.transfer"],
         "rate_limit": { "max": 1, "window_seconds": 86400 }
       },
       "target": "vendor invoice payment",
       "constraints": {
         "amount_max_usd": 500,
         "destination_must_be_in": ["preapproved_vendors"]
       }
     }

     Computed intent_hash: OW_76HLPAd8nVL7Z3e_jk1Q_8aQmFzn71hqrTMSfpeQ.

     The constraints field is profile-specific.  Verifiers MUST ignore
     unrecognized constraint fields they do not understand, EXCEPT when
     local policy requires recognition of those fields — in which case the
     policy MUST reject Posture Assertions or Authorization Tokens whose
     intent contains uninterpretable constraints.

  3.3.  Verification Rules

     A chain recipient MUST:

     1.  Unwrap each JWS layer and verify against the stated delegator's
         public key, obtained from the deployment's Key Source.

     2.  Verify the chain of delegator/delegatee references is unbroken.
         Each layer's delegatee MUST equal the next layer's delegator (or,
         for the layer immediately above the root, MUST appear in the
         root's authorized_chain).

     3.  *Enforce scope monotonicity* per Section 3.4.  Attempts to expand
         scope MUST cause rejection with reason code
         DEL_CHAIN_SCOPE_EXPANDED.

     4.  Verify the root is signed by an Originator the recipient trusts.

     5.  Verify no layer is expired (exp in past, accounting for clock
         skew under 5 minutes).

     6.  *Verify chain depth* is within the configured maximum per
         Section 3.5.






  Miller                   Expires 29 October 2026               [Page 13]


  Internet-Draft                    ZTIP                        April 2026


     7.  Recompute intent_hash from the root's intent_object per
         Section 3.2 and verify the recomputed value matches the root's
         claimed intent_hash.

     Implementations supporting Delegation Chains MUST enforce scope
     monotonicity (rule 3), chain-depth limit (rule 6), and intent-hash
     consistency (rule 7).  These are the load-bearing security properties
     of the chain.

  3.4.  Formal Definition of Scope Monotonicity

     Rule 3 in Section 3.3 requires "scope_reduction MUST be a subset of
     the parent's scope."  This subsection formalizes "subset" for each
     scope field type so that conforming implementations agree on what
     monotonicity means.

     A scope value at child layer C is *monotone* with respect to parent
     layer P when, for every field present in C, the relation in the table
     below holds:
































  Miller                   Expires 29 October 2026               [Page 14]


  Internet-Draft                    ZTIP                        April 2026


      +================+===========+====================================+
      | Field          | Type      | "C ⊆ P" relation                   |
      +================+===========+====================================+
      | actions        | array of  | Every element of C.actions is an   |
      |                | strings   | element of P.actions.  C.actions   |
      |                |           | MAY be empty.                      |
      +----------------+-----------+------------------------------------+
      | data           | array of  | Every element of C.data is an      |
      |                | strings   | element of P.data.  C.data MAY be  |
      |                |           | empty.                             |
      +----------------+-----------+------------------------------------+
      | tools          | array of  | Every element of C.tools is an     |
      |                | strings   | element of P.tools.  C.tools MAY   |
      |                |           | be empty.                          |
      +----------------+-----------+------------------------------------+
      | rate_limit.max | integer   | C.max <= P.max.                    |
      +----------------+-----------+------------------------------------+
      | rate_limit     | object    | C.max / C.window_seconds <= P.max  |
      | (combined)     |           | / P.window_seconds (effective rate |
      |                |           | is no greater) AND C.max <= P.max  |
      |                |           | (burst capacity is no greater).    |
      +----------------+-----------+------------------------------------+
      | ttl            | integer   | C.ttl <= P.ttl.                    |
      |                | (seconds) |                                    |
      +----------------+-----------+------------------------------------+
      | iat (per-      | integer   | C.iat >= P.iat.                    |
      | layer)         | (Unix     |                                    |
      |                | seconds)  |                                    |
      +----------------+-----------+------------------------------------+
      | exp (per-      | integer   | C.exp <= P.exp.                    |
      | layer)         | (Unix     |                                    |
      |                | seconds)  |                                    |
      +----------------+-----------+------------------------------------+

                                    Table 3

     *Field introduction.* A child layer MUST NOT introduce a scope field
     that is not present in its parent.  A field absent in P but present
     in C is a scope expansion and MUST cause rejection with
     DEL_CHAIN_SCOPE_EXPANDED.

     *Profile-defined fields.* When a profile defines additional scope
     fields, the profile document MUST specify the subset relation for
     those fields.  Verifiers encountering profile-defined fields without
     a known subset relation MUST treat them as opaque: presence in C
     requires identical value in P (i.e., C.field deeply equals P.field)
     for monotonicity to hold.




  Miller                   Expires 29 October 2026               [Page 15]


  Internet-Draft                    ZTIP                        April 2026


     *Empty vs. omitted in the child.* An empty array ([]) in a child
     layer means "no operations of this type are authorized."  An omitted
     field in a child layer is interpreted as inheriting the parent's
     value, NOT as removing the parent's constraint.  A child layer that
     wishes to drop a dimension entirely MUST set it to an empty array.

     *Diagnostic on rejection.* When a chain is rejected for scope
     violation, the verifier SHOULD include in the
     DEL_CHAIN_SCOPE_EXPANDED reason the specific field path and the
     offending values.  Example: "field": "tools", "child_value":
     "email.send", "parent_authorizes": ["email.list", "email.read"].

  3.5.  Maximum Chain Depth

     Implementations MUST enforce a maximum chain depth limit.  The depth
     is the number of nested JWS layers, counting both the root Signed
     Intent and each delegation wrapper.

     *  *RECOMMENDED maximum: 8 layers.* This is sufficient for the
        orchestration patterns observed at the time of this
        specification's publication; deployments needing more SHOULD
        document why.

     *  Deployments operating in environments with bounded delegation
        patterns MAY configure a lower limit (e.g., 3 for simple two-hop
        chains).

     *  Verifiers MUST reject chains exceeding the configured limit with
        reason code DEL_CHAIN_DEPTH_EXCEEDED.

     *  The depth check MUST be performed before recursive signature
        verification, to prevent stack-exhaustion or computational denial-
        of-service attacks via deeply nested chains.

     The depth limit also bounds the legitimate value of the
     max_tool_call_depth Behavioral Claim (Section 5).  An agent claiming
     max_tool_call_depth: N SHOULD NOT participate in chains where the
     verifier's configured depth limit is less than N.

     *Cost-scaling note.* Signature verification, JSON parsing, and JCS
     canonicalization each scale linearly with chain depth: an N-layer
     chain requires N signature verifications and N JSON-payload parses at
     the receiver.  The depth limit therefore bounds two distinct concerns
     — stack-exhaustion (addressed by the pre-verification depth check
     above) and per-request CPU cost (which scales linearly up to the
     limit).  Verifiers operating at high request rates SHOULD configure a
     depth limit at the lower end of the range their orchestration
     patterns permit, and SHOULD treat the configured limit as a CPU-



  Miller                   Expires 29 October 2026               [Page 16]


  Internet-Draft                    ZTIP                        April 2026


     budget parameter as well as a stack-safety parameter.  Alternative
     chain encodings (flat hash-linked structures, batch-verifiable
     signatures) were considered but rejected for this base specification
     in favor of the broad implementer familiarity with nested JWS;
     profiles MAY define alternative encodings where the cost matters.

  3.6.  Carrying the Chain in Authorization Flows

     The Delegation Chain is carried alongside an Authorization Token.
     The exact carriage mechanism depends on the composition profile
     (Section 6).  When a recipient's policy requires a chain (e.g., a
     policy field require_delegation_chain: true), absence MUST cause
     DEL_CHAIN_MISSING denial.

     Carriage MAY be either session-bound (the chain is supplied once at
     session establishment and reused for subsequent operations within the
     session) or per-call (each operation carries its own chain).  Per-
     call carriage is appropriate for stateless gateways and edge-deployed
     verifiers that cannot maintain per-session state.  Session-bound
     carriage is appropriate for long-lived sessions where re-supplying
     the chain on every request is wasteful.  Implementations supporting
     both modes MUST advertise their preference in the relevant
     composition profile's discovery mechanism.

  3.7.  Chain-Specific Reason Codes

     The following reason codes are registered in the IANA ZTIP Denial
     Reason Code Registry (Section 9):























  Miller                   Expires 29 October 2026               [Page 17]


  Internet-Draft                    ZTIP                        April 2026


        +==========================+==================================+
        | Code                     | Meaning                          |
        +==========================+==================================+
        | DEL_CHAIN_MISSING        | Policy requires a Delegation     |
        |                          | Chain but none was provided.     |
        +--------------------------+----------------------------------+
        | DEL_CHAIN_BROKEN         | Chain of delegator/delegatee     |
        |                          | references has a gap.            |
        +--------------------------+----------------------------------+
        | DEL_CHAIN_SCOPE_EXPANDED | A child layer attempts to grant  |
        |                          | broader scope than its parent.   |
        +--------------------------+----------------------------------+
        | DEL_CHAIN_EXPIRED        | One or more chain layers has     |
        |                          | expired.                         |
        +--------------------------+----------------------------------+
        | DEL_CHAIN_UNTRUSTED_ROOT | The root Signed Intent is not    |
        |                          | signed by a trusted Originator.  |
        +--------------------------+----------------------------------+
        | DEL_CHAIN_DEPTH_EXCEEDED | The chain exceeds the verifier's |
        |                          | configured maximum depth.        |
        +--------------------------+----------------------------------+

                                    Table 4

  4.  Intent-Scoped Authorization

  4.1.  Motivation

     An authorization token issued without reference to the original
     authorized intent can be used for any action within its stated scope,
     regardless of what the user actually asked.  This is the mechanism by
     which prompt injection escalates to a confused-deputy attack: the
     injected instruction substitutes a new operational intent, but the
     token's scope is broad enough to authorize it.

     Intent-Scoped Authorization Tokens bind the token to the root Signed
     Intent (Section 3).  A resource receiving such a token can verify
     that the action being requested is consistent with the original
     intent, not just with the token's scope.

  4.2.  Field Extensions to Authorization Tokens

     ZTIP defines four additional claims for any signed Authorization
     Token:







  Miller                   Expires 29 October 2026               [Page 18]


  Internet-Draft                    ZTIP                        April 2026


     +==============+======+========+====================================+
     |Field         |Type  |Required|Description                         |
     +==============+======+========+====================================+
     |intent_hash   |string|Yes     |base64url(SHA-256(JCS(intent_object)|
     |              |      |        |UTF-8 bytes)) per Section 3.2 — MUST|
     |              |      |        |equal the root Signed Intent's      |
     |              |      |        |intent_hash.                        |
     +--------------+------+--------+------------------------------------+
     |intent_scope  |object|Yes     |The authorized scope derived from   |
     |              |      |        |the root Signed Intent.             |
     +--------------+------+--------+------------------------------------+
     |chain_root_iss|string|Yes     |Identifier of the root Signed       |
     |              |      |        |Intent's Originator.                |
     +--------------+------+--------+------------------------------------+
     |chain_root_jti|string|Yes     |jti of the root Signed Intent (for  |
     |              |      |        |revocation/audit).                  |
     +--------------+------+--------+------------------------------------+

                                    Table 5

     These fields are added to the Authorization Token's existing claim
     set.  The exact placement depends on the composition profile
     (Section 6):

     *  *OAuth 2.0 / JWT access token*: top-level claims alongside iss,
        sub, scope, exp.

     *  *ZTNP Permit*: top-level fields alongside permit_id, constraints.

     *  *GNAP grant*: as an extension element of the grant response.

     The token issuer (whoever issues the underlying authorization token)
     MUST verify that the action requested by the bearer is within
     intent_scope before the token is honored.  If the bearer attempts to
     invoke a tool or access data outside intent_scope, the token issuer
     MUST deny the request even if the token's other scope fields would
     otherwise permit it.

  4.3.  Scope Consistency Check

     A token verifier enforcing an Intent-Scoped Authorization Token MUST
     evaluate the following before each gated operation:

     1.  Determine the operation's (action, data_classes, tool) signature
         from the request being gated.






  Miller                   Expires 29 October 2026               [Page 19]


  Internet-Draft                    ZTIP                        April 2026


     2.  Verify that the operation falls within intent_scope, using the
         same subset relations as Section 3.4.  Specifically: the
         operation's tool MUST be in intent_scope.tools (when
         intent_scope.tools is present); the operation's action MUST be in
         intent_scope.actions; each data class touched by the operation
         MUST be in intent_scope.data.

     3.  If any check fails, return a denial with reason code
         INTENT_SCOPE_MISMATCH.

     The verifier MUST additionally verify that the token's intent_hash
     matches the recomputed hash from the root Signed Intent's
     intent_object (per Section 3.2).  A mismatch indicates either a
     substituted token or a tampered chain and MUST cause
     INTENT_SCOPE_MISMATCH rejection.

  4.4.  Operation Classification

     The Scope Consistency Check above requires the verifier to determine
     an operation's (action, data_classes, tool) signature.  ZTIP does not
     standardize how operations are classified into actions and data
     classes: a service mesh fronting a relational database has different
     action vocabularies (SELECT, INSERT) than an email gateway
     (email.read, email.send) or a financial system (transfer,
     query_balance).  Operation classification is therefore deployment-
     and profile-defined, not protocol-defined.

     This is a deliberate deferral, but it is also a security-relevant
     gap.  Misclassification — labeling a write-causing tool call as read,
     mapping a data-exfiltrating tool to a benign-looking action, or
     having two parties disagree on what email.send means — silently
     bypasses intent-scope enforcement.  The cryptographic guarantees of
     Sections 3 and 4 are then evaluating an operation signature that does
     not correspond to the operation actually performed.

     Two requirements follow:

     1.  *Profiles SHOULD specify a strict operation taxonomy* for their
         domain — the set of valid tool names, the action each tool
         implements, and the data classes each operation touches — so that
         classification is not left to ad-hoc deployment choice.  The
         taxonomy SHOULD be authenticated (e.g., served from a tool-
         capability registry that the verifier trusts) so that a tool
         cannot self-classify into a more permissive category at request
         time.






  Miller                   Expires 29 October 2026               [Page 20]


  Internet-Draft                    ZTIP                        April 2026


     2.  *Verifiers MUST treat operation classification as part of their
         security boundary.* A tool whose runtime behavior does not match
         its declared classification is a security failure regardless of
         cryptographic verification.  Deployments SHOULD audit tool
         implementations against their declared classifications, and
         SHOULD reject operations whose classification cannot be
         authenticated against a trusted source.

     Cryptographic verification of the chain and the intent hash is
     necessary but not sufficient: the intent-binding guarantee depends on
     the verifier and the tool agreeing on what operation is being
     performed.  Treat the operation taxonomy with the same rigor as the
     cryptography.

  5.  Behavioral Claim Extensions

     For deployments where a verifier needs behavioral posture information
     about an agent, ZTIP defines a claim shape carrying behavioral safety
     properties.  This claim shape can appear in any signed credential
     about an agent — typically a Posture Assertion when composed with
     ZTNP, a JWT claim about the bearer when composed with OAuth, or a
     vendor-defined credential.

     *Behavioral claims are advisory and non-normative with respect to
     ZTIP's core security guarantees.* The chain-integrity, scope-
     monotonicity, and intent-binding properties of Sections 3 and 4 do
     not depend on any behavioral claim.  A verifier MAY ignore behavioral
     claims entirely without weakening any of those properties; a verifier
     that consults behavioral claims is making a _policy_ decision about
     acceptable agent behavior, not relying on a security primitive.
     Behavioral claims are a transport for the sort of attestation that
     one party makes to another about how an agent is operated; their
     meaning is established by issuer reputation, the evidence sub-field
     below, and out-of-band agreement, not by the protocol.  Deployments
     dismissing behavioral claims as "marketing, not protocol" can deploy
     ZTIP without them and still get the chain-integrity and intent-
     binding guarantees.

     The claims appear under the namespace ai_behavior within the
     credential's claim payload.

  5.1.  Standard AI Behavior Claims

     The following claim names are defined by this specification:







  Miller                   Expires 29 October 2026               [Page 21]


  Internet-Draft                    ZTIP                        April 2026


       +=========================+=========+==========================+
       | Claim                   | Type    | Description              |
       +=========================+=========+==========================+
       | prompt_injection_tested | boolean | Tested against prompt-   |
       |                         |         | injection scenarios.     |
       +-------------------------+---------+--------------------------+
       | tool_call_audit_logged  | boolean | All tool invocations are |
       |                         |         | logged to a tamper-      |
       |                         |         | evident audit trail.     |
       +-------------------------+---------+--------------------------+
       | tool_misuse_score       | number  | 0.0-1.0; lower = lower   |
       |                         |         | observed misuse risk.    |
       |                         |         | Calibration is profile-  |
       |                         |         | specific; ZTIP does not  |
       |                         |         | standardize a            |
       |                         |         | measurement methodology. |
       +-------------------------+---------+--------------------------+
       | output_validated        | boolean | Agent output is          |
       |                         |         | validated before being   |
       |                         |         | acted upon.              |
       +-------------------------+---------+--------------------------+
       | human_in_loop_policy    | string  | One of: never,           |
       |                         |         | on_high_risk,            |
       |                         |         | on_data_egress, always.  |
       |                         |         | Profiles MAY define      |
       |                         |         | additional values.       |
       +-------------------------+---------+--------------------------+
       | max_tool_call_depth     | integer | Maximum delegation-chain |
       |                         |         | depth the agent will     |
       |                         |         | recurse into.  SHOULD be |
       |                         |         | ≤ the verifier's         |
       |                         |         | configured chain-depth   |
       |                         |         | limit (Section 3.5).     |
       +-------------------------+---------+--------------------------+
       | data_exfil_controls     | boolean | Agent has data-          |
       |                         |         | exfiltration controls.   |
       +-------------------------+---------+--------------------------+

                                   Table 6

     A verifier's policy MAY reference ai_behavior claims as prerequisites
     for granting specific actions.  For example: a policy may require
     prompt_injection_tested: true before granting actions:
     ["email_send"].







  Miller                   Expires 29 October 2026               [Page 22]


  Internet-Draft                    ZTIP                        April 2026


  5.1.1.  Evidence Sub-Field

     Each behavioral claim MAY be accompanied by a sibling evidence object
     that records how the claim was substantiated.  Verifiers concerned
     about the rigor of a behavioral claim SHOULD inspect its evidence
     object before relying on the claim.

     The evidence object SHOULD contain:

      +===============+=========+======================================+
      | Field         | Type    | Description                          |
      +===============+=========+======================================+
      | source        | string  | Identifier of the party that         |
      |               |         | generated the evidence (e.g., URI of |
      |               |         | an evaluator, internal red-team      |
      |               |         | identifier, vendor name).            |
      +---------------+---------+--------------------------------------+
      | method        | string  | Methodology used to substantiate the |
      |               |         | claim (e.g., red_team_test_suite_v3, |
      |               |         | automated_prompt_injection_corpus,   |
      |               |         | manual_review_2026Q1).               |
      +---------------+---------+--------------------------------------+
      | date          | string  | ISO 8601 date when the evidence was  |
      |               |         | generated.                           |
      +---------------+---------+--------------------------------------+
      | validity_days | integer | OPTIONAL: how long the evidence is   |
      |               |         | considered valid; verifiers MAY      |
      |               |         | treat older evidence as expired.     |
      +---------------+---------+--------------------------------------+
      | evidence_hash | string  | OPTIONAL: SHA-256 hash of an         |
      |               |         | evidence artifact (test report, log  |
      |               |         | file) the verifier can request out-  |
      |               |         | of-band.                             |
      +---------------+---------+--------------------------------------+

                                   Table 7

     Example:













  Miller                   Expires 29 October 2026               [Page 23]


  Internet-Draft                    ZTIP                        April 2026


     {
       "ai_behavior": {
         "prompt_injection_tested": true,
         "evidence": {
           "prompt_injection_tested": {
             "source": "https://example-evaluators.org",
             "method": "owasp_llm_top10_2025_corpus_v2",
             "date": "2026-04-15",
             "validity_days": 90,
             "evidence_hash": "Q7nB...base64url..."
           }
         }
       }
     }

     evidence entries are nested by claim name within an evidence object
     alongside the claims they substantiate (so a verifier can iterate
     claim → evidence).

     The Issuer signing the credential is responsible for the truthfulness
     of evidence entries.  Profiles MAY define additional required
     evidence fields for specific claims (e.g., requiring evidence.method
     for tool_misuse_score).

  5.1.2.  Baseline Corpora for "Tested" Claims

     A boolean claim such as prompt_injection_tested: true is meaningful
     only with respect to a defined test corpus.  Without a referenced
     corpus the claim collapses to vendor self-attestation and offers a
     verifier no basis for comparing two issuers' assertions.  ZTIP does
     not standardize a single corpus — the field is moving rapidly and no
     single test set captures the full attack surface — but does specify
     how a corpus is referenced.

     When evidence.method substantiates a _tested claim, the value SHOULD
     identify a publicly documented test corpus and version.  Examples of
     such corpora include:

     *  The OWASP Top 10 for Large Language Model Applications (commonly
        cited as "OWASP LLM Top 10"), with a year and version identifier
        (e.g., owasp_llm_top10_2025_v1).

     *  Vendor- or community-maintained prompt-injection test suites with
        public methodology (e.g., adversarial-prompt corpora published by
        recognized red teams).






  Miller                   Expires 29 October 2026               [Page 24]


  Internet-Draft                    ZTIP                        April 2026


     *  Internal corpora, where the methodology is documented and the
        corpus version is identified, accompanied by an evidence_hash over
        the corpus or its specification.

     Verifiers SHOULD treat claims whose evidence.method does not identify
     a public corpus, an evidence_hash over an internal corpus, or a
     recognized methodology as no stronger than vendor self-attestation.
     Verifiers depending on a _tested claim for a policy decision SHOULD
     additionally require that the corpus referenced in evidence.method is
     one the verifier accepts; deployments differ in which corpora they
     consider authoritative, and ZTIP intentionally leaves that choice to
     the verifier rather than mandating one corpus globally.

     This is consistent with the framing in Section 5: behavioral claims
     are advisory.  Pointing at a corpus does not make the claim a
     security primitive — it makes it a policy input that a verifier can
     compare across issuers without deferring entirely to issuer
     reputation.

  5.2.  Vendor-Defined and Bespoke Claims

     Implementations MAY define additional behavioral claims for their
     domain.  ZTIP does not maintain a central registry of behavioral
     claim names; instead, three naming conventions allow extension
     without coordination:

     *  *URI-namespaced names* (RECOMMENDED for cross-organization
        deployments): the claim name is a URI per [RFC3986] in a domain
        controlled by the publisher.  Example:
        https://acme.example/ztip/claims/red_team_score_v1.  Anyone
        reading the URI can identify the publisher and look up the claim's
        definition.

     *  *Vendor-prefixed names* (RECOMMENDED for in-domain consortia): a
        registered organizational identifier as a prefix.  Example:
        acme:red_team_score_v1.

     *  *Privately-agreed names* (acceptable when both parties understand
        the meaning out-of-band): unprefixed identifiers used only within
        deployments where issuer and verifier have agreed semantics.
        Example: internal_score.

     This pattern follows JWT private-claim conventions ([RFC7519]
     Section 4.3) and OAuth scope-string conventions.  Verifiers MUST
     ignore unrecognized claims they do not understand.  Verifiers that
     depend on a behavioral claim for a policy decision MUST fail closed
     if the claim is absent.




  Miller                   Expires 29 October 2026               [Page 25]


  Internet-Draft                    ZTIP                        April 2026


  5.3.  Interaction with Standard Claims

     Vendor-defined claims MUST NOT redefine the meaning of any of the
     standard claims listed above.  A vendor wishing to refine the
     semantics of, say, tool_misuse_score MUST publish a new vendor-
     namespaced claim (e.g., acme:tool_misuse_score_v2) rather than
     redefining the standard one.

  6.  Composition Profiles

     ZTIP is designed to compose with multiple authorization systems.
     This section specifies normative composition profiles.  Deployments
     SHOULD use a published profile when one exists; vendors MAY define
     additional profiles for their authorization systems.

  6.1.  Composition with ZTNP

     When composed with the Zero-Trust Negotiation Protocol
     [I-D.miller-ztnp]:

     *  The Authorization Token is the ZTNP Permit (Section 8 of ZTNP).

     *  The Key Source is the Issuer Key Set (IKS, Section 6 of ZTNP) for
        each delegating principal.

     *  The Delegation Chain (defined in Section 3 of this document) is
        carried in the PROOF message of ZTNP's Negotiation phase
        (Section 7.3 of ZTNP), under the delegation_chain field.

     *  ZTIP fields (intent_hash, intent_scope, chain_root_iss,
        chain_root_jti) are top-level fields on the Permit.

     *  Behavioral Claims appear under the ai_behavior namespace in any
        credential about the Prover.  Their canonical placement is on the
        Posture Assertion at claims.posture.ai_behavior (a profile-defined
        extension under ZTNP's claims.posture per Section 5.4 of ZTNP).
        Profiles MAY additionally place per-issuance Behavioral Claims on
        the Permit at ai_behavior (e.g., the MCP profile's
        legacy_stdio_binding flag), where they describe a property of how
        the Permit was issued rather than the long-lived posture of the
        Prover.

     A worked example using this profile appears in Appendix A.

  6.2.  Composition with OAuth 2.0 / JWT

     When composed with OAuth 2.0 [RFC6749] access tokens in JWT format
     ([RFC7519]):



  Miller                   Expires 29 October 2026               [Page 26]


  Internet-Draft                    ZTIP                        April 2026


     *  The Authorization Token is the JWT access token.

     *  The Key Source for chain-layer signature verification is each
        principal's published JWKS endpoint, located via OAuth
        Authorization Server Metadata or a similar discovery mechanism.

     *  ZTIP fields are top-level claims in the access token JWT,
        alongside iss, sub, aud, exp, scope.

     *  The Delegation Chain is carried in a separate HTTP header
        alongside the bearer token:

     Authorization: Bearer <jwt_access_token>
     ZTIP-Chain: <delegation_chain_compact_jws>

     *  Behavioral Claims appear in the access token under a top-level
        ai_behavior claim (an object), alongside the Intent-Scoped fields.

     The JWT access token, with ZTIP fields, looks like:

     {
       "iss": "https://auth.example",
       "sub": "agent:summarizer-3",
       "aud": "https://api.example",
       "exp": 1745504400,
       "iat": 1745500900,
       "scope": "email.read",
       "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc",
       "intent_scope": { "actions": ["read"], "tools": ["email.read"] },
       "chain_root_iss": "user:alice",
       "chain_root_jti": "intent_01HVXYZ_SUMMARIZE_REQUEST",
       "ai_behavior": {
         "prompt_injection_tested": true,
         "human_in_loop_policy": "on_high_risk"
       }
     }

     This composition layers ZTIP cleanly above OAuth without modifying
     OAuth's core flows.  The OAuth Authorization Server is responsible
     for issuing tokens that include the ZTIP fields; the resource server
     is responsible for performing the scope-consistency check
     (Section 4.2) on each request.

  6.3.  Composition with GNAP

     When composed with the Grant Negotiation and Authorization Protocol
     [RFC9635], ZTIP uses GNAP's extension-parameter registries
     (Section 10 of [RFC9635]) rather than overloading existing fields.



  Miller                   Expires 29 October 2026               [Page 27]


  Internet-Draft                    ZTIP                        April 2026


     *Delegation Chain in the grant request.* The Delegation Chain is
     carried as a top-level extension parameter ztip_delegation_chain on
     the grant request body, in compact-JWS form.  This parameter is
     intended for registration in the "GNAP Grant Request Parameters"
     registry (Section 10.3 of [RFC9635]).

     POST /grant HTTP/1.1
     Content-Type: application/json

     {
       "access_token": { "access": [ ... ] },
       "client": { "key": { ... } },
       "ztip_delegation_chain": "<compact-JWS of outermost layer>"
     }

     The AS validates the chain (Section 3.3 of this document) before
     issuing access tokens.  A failed validation MUST cause the grant
     request to be rejected with the appropriate ZTIP reason code reported
     in an extension field on the GNAP error response.

     *ZTIP fields on the issued access token.* When the AS issues an
     access token in response to a chain-bearing grant request, the token
     MUST carry the ZTIP fields intent_hash, intent_scope, chain_root_iss,
     and chain_root_jti (Section 4 of this document).  Placement depends
     on the access-token format the AS issues:

     *  If the AS issues a JWT access token, the ZTIP fields appear as
        top-level claims (per the OAuth 2.0 / JWT composition in
        Section 6.2 of this document).

     *  If the AS issues an opaque token, the ZTIP fields are returned
        alongside the token in the grant response under an extension
        parameter ztip (object), intended for registration in the "GNAP
        Grant Response Parameters" registry (Section 10.12 of [RFC9635]).
        The opaque token's introspection response MUST also include these
        fields when introspection is supported.

     *Key Source for chain layer signatures.* Each delegating principal in
     the chain has its own signing key.  GNAP's grant-request flow exposes
     the _immediate_ client's key via the client.key field; ZTIP requires
     keys for _every_ principal in the chain.  The composition resolves
     this by requiring that each chain layer's delegator identifier be a
     URI dereferenceable to a JWKS, or alternatively that the AS maintain
     an out-of-band trust store for known delegators.  Profiles MAY
     further constrain this; this base spec leaves the choice to
     deployment.





  Miller                   Expires 29 October 2026               [Page 28]


  Internet-Draft                    ZTIP                        April 2026


     *Continuation requests.* GNAP supports continuation of a grant for
     token refresh and modification.  When a continuation request modifies
     the authorized scope, the client MAY supply a new
     ztip_delegation_chain value (e.g., representing a further-narrowed
     delegation).  The AS MUST validate that the new chain's scope is
     consistent with — and not broader than — the chain that originally
     established the grant.

     *What this section does not specify.* Wire-level normative details —
     exact field names accepted into the IANA GNAP registries, exact
     error-response shape, interaction-mode semantics when a chain is
     required for an interaction step — are deliberately left to a
     companion profile document.  Implementers wanting an end-to-end
     conformant GNAP+ZTIP deployment SHOULD await or contribute to that
     companion document.  The sketch above is sufficient for early
     experimentation and for soliciting feedback from the GNAP working
     group, but it is not a complete profile.

  6.4.  Custom Authorization Systems

     Implementations MAY compose ZTIP with bespoke authorization systems.
     The composition document MUST specify:

     1.  The signed credential serving as the Authorization Token.

     2.  A Key Source for each principal that may sign a delegation chain
         layer.

     3.  A carriage mechanism for the chain alongside the credential.

     4.  A reason-code mapping if the composition's transport differs from
         HTTP.

     5.  The placement of ZTIP fields (intent_hash, etc.) within the
         Authorization Token.

     6.  The placement of Behavioral Claims within any associated agent
         credential.

     A composition profile SHOULD be published as a separate document when
     intended for cross-organization use.

  6.5.  Deployment Pattern: Transparent Intermediate Signer

     This subsection describes a recurring deployment pattern that ZTIP
     supports without additional protocol machinery.  It is informative;
     the underlying mechanics (Sections 3 and 4) are unchanged.




  Miller                   Expires 29 October 2026               [Page 29]


  Internet-Draft                    ZTIP                        April 2026


     In some delegation chains, requiring per-action human approval is
     operationally prohibitive — a chat-driven session where the user
     types ten messages per minute cannot reasonably re-prompt for
     explicit approval on each turn.  The practical pattern that emerges:

     1.  *Layer 0 (root):* The user (Originator) signs a session-level
         intent at session establishment.  The intent_object describes the
         broad scope the user is authorizing for the session ("answer
         questions and call tools related to my project X using only my
         internal documents").  This is one human-consented signing event.

     2.  *Layer 1 (transparent intermediate):* A trusted Planner or
         session controller — running under the user's identity but
         operating without per-turn user approval — signs delegation
         layers programmatically as the session proceeds.  Each per-turn
         delegation reduces scope further (scope_reduction) based on the
         specific user request that turn.  The Planner is _transparent_
         because it adds chain layers without re-prompting; it is
         _trusted_ because it is structurally above the prompt-injection-
         exposed Worker and constrained by the root's scope.

     3.  *Layer 2 (worker):* A sub-agent (potentially exposed to prompt
         injection from tool outputs) operates under the per-turn
         delegation.  Its scope is reduced from the Planner's scope, which
         is reduced from the root.

     The transparent intermediate signer pattern works within ZTIP's
     existing primitives:

     *  The chain has arbitrary depth (Section 3.5 caps at 8 by default).

     *  Every layer enforces scope monotonicity (Section 3.4).

     *  The root retains the user-consented intent_object; intermediate
        layers carry only scope_reduction (no new intent).

     *  Any operation reaching the final tool is constrained by the
        intersection of all layers' scopes.

     *Security requirements for the intermediate signer:*

     *  The intermediate's signing key MUST be under operational control
        of the same trust principal as the user's signing environment (the
        Planner is part of the user's session infrastructure, not a third-
        party service).






  Miller                   Expires 29 October 2026               [Page 30]


  Internet-Draft                    ZTIP                        April 2026


     *  The intermediate MUST enforce scope monotonicity at signing time;
        an intermediate that signs scopes broader than the root authorized
        is a security failure regardless of downstream verification.

     *  The intermediate SHOULD log per-turn signing decisions to a
        tamper-evident audit trail.  The log SHOULD include the user's
        per-turn input that derived the scope_reduction (so a subsequent
        audit can reconstruct what was authorized for each turn).

     *  The intermediate SHOULD use a short-lived signing key bound to the
        session (e.g., generated at session establishment, deleted at
        session termination), to limit the blast radius if the key is
        exposed.

     *When to use this pattern:*

     *  Long-running interactive sessions where user re-approval per
        action is unworkable.

     *  Programmatic decomposition of a high-level user intent into low-
        level tool calls, where the decomposition is performed by trusted
        infrastructure, not by the prompt-injection-exposed Worker.

     *  Multi-turn chat UX where each turn produces a new sub-intent
        within the session-level intent.

     *When NOT to use this pattern:*

     *  High-stakes single-action authorizations (financial transfers,
        irreversible operations) where per-action explicit consent is the
        security boundary.

     *  Deployments where the intermediate signer is not under the user's
        trust principal (e.g., a third-party SaaS Planner).

















  Miller                   Expires 29 October 2026               [Page 31]


  Internet-Draft                    ZTIP                        April 2026


     *Trust-boundary implications.* The transparent intermediate signer
     pattern shifts the human-consent boundary from per-action to per-
     session, with a trusted automated signing authority producing the
     per-turn delegation layers in between.  This is a deliberate tradeoff
     for operational viability, and adopters SHOULD treat it as a
     meaningful change in their threat model rather than an implementation
     detail.  A compromised intermediate cannot expand scope (Section 3.4
     prevents that — every per-turn delegation is still strictly within
     the root intent's scope), but it can manipulate behavior within the
     authorized space: which tools to invoke, in what order, with what
     arguments, drawing on which session inputs.  For most session-level
     scopes this residual surface is acceptable; for scopes broad enough
     that within-scope behavior can itself cause harm, it is not.  Two
     consequences:

     1.  The intermediate signer is a high-value target equivalent in
         sensitivity to the Originator's signing surface for the duration
         of the session, and SHOULD receive equivalent operational
         hardening (HSM-backed keys, restricted access, monitored signing
         surfaces).

     2.  The session-level intent_object SHOULD be no broader than the
         user would be willing to authorize unattended for the session's
         duration.  If a session-level intent encompasses high-stakes
         actions, those actions belong in a separate, narrower intent
         signed at the moment they are needed (per the "When NOT to use
         this pattern" guidance above), not within the broad session
         intent.

     Future profile documents MAY formalize specific implementations of
     this pattern (e.g., by specifying a distinct identifier prefix for
     transparent intermediates, audit-log requirements, key-lifetime
     bounds).  This base specification deliberately leaves the
     implementation details to deployments and profile authors.

  7.  Security Considerations

     This section is REQUIRED by [RFC3552].  ZTIP introduces security
     properties beyond those provided by any single authorization system;
     this section enumerates the additional adversaries and mitigations
     specific to ZTIP.  Composition-specific security considerations
     (e.g., the security considerations of OAuth 2.0 or ZTNP) continue to
     apply to deployments using those compositions.








  Miller                   Expires 29 October 2026               [Page 32]


  Internet-Draft                    ZTIP                        April 2026


  7.1.  Trust Anchor

     The security of ZTIP is strictly bounded by the trustworthiness of
     the Originator and the integrity of the Originator's signing
     environment.  This is the protocol's trust anchor, analogous to the
     certificate-authority hierarchy in TLS or the issuer in OAuth: every
     guarantee ZTIP provides downstream is conditional on the Originator
     having signed something the Originator actually meant to sign.

     A compromised or malicious Originator can produce a maximally-broad
     intent_object and a chain authorizing any downstream principal;
     verifiers cannot distinguish such an intent from a legitimate one
     within the chain itself.  ZTIP's defenses (scope monotonicity, intent
     binding, chain auditability) protect against compromise _after_
     signing — they do not protect against compromise _at_ signing time.

     Mitigations for the trust-anchor surface are deliberately out-of-
     protocol and SHOULD include:

     *  HSM-backed or hardware-bound storage of the Originator's signing
        key.

     *  Short Signed-Intent lifetimes (exp close to iat) so that a
        compromised intent has limited reach.

     *  Multi-factor or additional-channel approval at the signing surface
        for high-stakes intents (e.g., financial transfers, irreversible
        operations).

     *  Human review of intent_object contents at the signing UI before
        the signature is produced — i.e., the user signs what the user
        sees.

     *  Tamper-evident logging of every Originator signing event, so that
        compromise can be detected after-the-fact even if it cannot be
        prevented in real time.

     Deployments evaluating ZTIP for a particular threat model SHOULD
     treat the Originator's signing environment with the same operational
     rigor they would apply to a CA's root key.











  Miller                   Expires 29 October 2026               [Page 33]


  Internet-Draft                    ZTIP                        April 2026


  7.2.  Additional Adversaries

        +====================+========================================+
        | Adversary          | Goal                                   |
        +====================+========================================+
        | ADV-PROMPT-INJECT  | Controls user-supplied content         |
        |                    | reaching an agent; wants to substitute |
        |                    | the operational intent.                |
        +--------------------+----------------------------------------+
        | ADV-CHAIN-FORGER   | Attempts to forge a Delegation Chain   |
        |                    | claiming authority from a root         |
        |                    | Originator the chain recipient trusts. |
        +--------------------+----------------------------------------+
        | ADV-SCOPE-EXPANDER | Controls a sub-agent in the middle of  |
        |                    | a chain; attempts to grant downstream  |
        |                    | agents broader scope than the parent   |
        |                    | layer authorized.                      |
        +--------------------+----------------------------------------+
        | ADV-DEPTH-FLOODER  | Constructs deeply-nested chains to     |
        |                    | consume verifier resources (CPU,       |
        |                    | stack, signature-verification time) at |
        |                    | the receiver.                          |
        +--------------------+----------------------------------------+

                                    Table 8

  7.3.  Attack Surface and Mitigations

     +===================+==================================+===========+
     | Attack            | Mitigation                       | Reference |
     +===================+==================================+===========+
     | Prompt-injected   | Intent-Scoped Authorization      | Section 4 |
     | confused deputy   | Tokens (Section 4) bind          |           |
     |                   | authorization to the original    |           |
     |                   | signed intent.  The injected     |           |
     |                   | instruction substitutes a new    |           |
     |                   | intent that does not match       |           |
     |                   | intent_hash; gated operations    |           |
     |                   | fail with INTENT_SCOPE_MISMATCH. |           |
     +-------------------+----------------------------------+-----------+
     | Chain forgery     | Each layer's signature is        | Section   |
     |                   | verified against the issuing     | 3.3       |
     |                   | principal's published key        |           |
     |                   | (Section 3.3 rule 1).  An        |           |
     |                   | adversary cannot forge a layer   |           |
     |                   | without the corresponding        |           |
     |                   | private key.                     |           |
     +-------------------+----------------------------------+-----------+



  Miller                   Expires 29 October 2026               [Page 34]


  Internet-Draft                    ZTIP                        April 2026


     | Scope expansion   | Scope monotonicity enforcement   | Section   |
     | mid-chain         | (Section 3.3 rule 3 and          | 3.3, 3.4  |
     |                   | Section 3.4) rejects any chain   |           |
     |                   | in which a child layer grants    |           |
     |                   | broader scope than its parent.   |           |
     +-------------------+----------------------------------+-----------+
     | Chain replay      | Chain layers carry iat/exp;      | Section   |
     |                   | receivers MUST reject expired    | 3.3       |
     |                   | layers (Section 3.3 rule 5).     |           |
     |                   | The root Signed Intent's jti can |           |
     |                   | be tracked to prevent intent     |           |
     |                   | replay across sessions.          |           |
     +-------------------+----------------------------------+-----------+
     | Originator key    | Outside ZTIP's defense — same    | (Out of   |
     | compromise        | status as Issuer key compromise  | scope)    |
     |                   | in any signing-based system.     |           |
     |                   | Mitigated by short Signed-Intent |           |
     |                   | lifetimes and Originator-side    |           |
     |                   | HSM use.                         |           |
     +-------------------+----------------------------------+-----------+
     | Behavioral-claim  | Behavioral claims (Section 5)    | Section 5 |
     | misrepresentation | are signed by whatever           |           |
     |                   | credential issuer carries them.  |           |
     |                   | Verifiers MAY require specific   |           |
     |                   | issuers known to assess          |           |
     |                   | behavioral properties            |           |
     |                   | rigorously.                      |           |
     +-------------------+----------------------------------+-----------+
     | Chain-depth flood | Maximum chain depth enforcement  | Section   |
     | / verifier        | (Section 3.5).  Depth MUST be    | 3.5       |
     | resource          | checked before signature         |           |
     | exhaustion        | verification to prevent stack/   |           |
     |                   | CPU exhaustion.                  |           |
     +-------------------+----------------------------------+-----------+

                                   Table 9

  7.4.  Out of Scope

     ZTIP does not defend against:

     *  *Compromise of the Originator before they sign the intent.* The
        Originator's signing environment is the trust root; if it is
        compromised, the adversary can sign arbitrary intents that
        downstream verifiers will treat as legitimate.  Mitigations are
        out-of-protocol (HSM, hardware-bound signing, multi-factor
        approval at signing time).




  Miller                   Expires 29 October 2026               [Page 35]


  Internet-Draft                    ZTIP                        April 2026


     *  *Side-channel observation of intent contents.* The intent_object
        is visible to every verifier in the chain (each verifier needs to
        recompute the hash).  Information that should not be visible in
        transit MUST be redacted from the canonical intent before signing
        — see Privacy Considerations (Section 8) for guidance.

  8.  Privacy Considerations

     This section is informed by [RFC6973].

     *Intent string sensitivity.* The canonical-intent-string (the source
     of intent_hash) describes what a user asked the system to do.  It MAY
     be sensitive (medical, legal, financial).  Implementations MUST NOT
     log canonical-intent-strings without retention controls.  The
     intent_hash is non-reversible and MAY be logged.

     *Intent visibility is a structural tradeoff, not just a privacy
     concern.* Verifiable intent binding requires every verifier in the
     chain to see the intent contents (or a hash thereof, with downstream
     lookup).  For deployments where intent contents are themselves
     sensitive — financial transaction details, medical context, legal
     strategy, regulated business data — this visibility is a deployment-
     feasibility constraint, not a privacy nicety.  Some enterprise
     deployments may reject intent-binding altogether on this ground;
     deployments evaluating ZTIP for adoption SHOULD plan their intent
     schema with this constraint in mind from the outset.  The mitigations
     below shape what can be carried in intent_object without leaking;
     they do not remove the underlying tradeoff between verifiability and
     confidentiality.

     *Intent contents are visible to all verifiers.* Every verifier in the
     chain receives the root layer's intent_object (it must, in order to
     recompute the hash and evaluate intent_scope).  The intent contents
     are therefore visible to every layer between Originator and final
     verifier.  Originators MUST NOT include in intent_object any
     information that must remain confidential to a subset of verifiers.
     Three patterns help:

     *  *Field redaction at signing time.* The Originator's signing
        application removes sensitive details from intent_object before
        canonicalization, signing only what verifiers need to evaluate
        scope.  The user-readable intent stays in the user's local logs,
        not in the signed chain.

     *  *Reference-by-hash.* Sensitive payloads are hashed; the chain
        carries only the hash.  Downstream agents look up the actual
        content via a separate authenticated channel.




  Miller                   Expires 29 October 2026               [Page 36]


  Internet-Draft                    ZTIP                        April 2026


     *  *Profile-specific encryption.* Some profiles may layer envelope
        encryption over intent_object for verifiers who hold the
        appropriate key.  This is out of scope for ZTIP base; profile
        documents MAY specify it.

     *Delegation chain disclosure.* A Delegation Chain reveals the
     orchestration topology (which orchestrator, which sub-agents, which
     tools).  Where this is sensitive, deployments MAY truncate chains
     exposed to external receivers, retaining only the layers the receiver
     needs to verify.

     *Behavioral-claim disclosure.* Some behavioral claims (e.g.,
     human_in_loop_policy: never) reveal architectural choices that
     adversaries could exploit.  Issuers and Provers SHOULD coordinate on
     which behavioral claims are appropriate to expose at which trust
     boundaries.

     *Originator linkability.* A persistent Originator identifier
     (user:alice) creates linkability across all chains the Originator
     participates in.  Deployments MAY use ephemeral Originator
     identifiers per-session where the deployment context permits.

  9.  IANA Considerations

     This document requests the following IANA actions.

     The ZTIP IANA footprint is intentionally minimal: a single new
     registry (Denial Reason Codes), a single HTTP field registration
     (ZTIP-Chain), and zero new registries for behavioral claim names.
     The single registry uses Specification Required allocation per
     [RFC8126] — anyone able to write a stable specification document can
     register a new reason code, with no IETF consensus action required
     per registration.  Composition profile documents are expected to add
     reason codes for their domain; the Specification Required policy
     keeps that path open for vendor and consortium specifications without
     burdening either IANA or the IETF process.

  9.1.  ZTIP Denial Reason Code Registry

     This document requests creation of a registry titled "ZTIP Denial
     Reason Codes".  It administers reason codes returned by ZTIP-aware
     verifiers when rejecting a request.

     Allocation Policy: Specification Required (per [RFC8126]).

     Initial Registrations:





  Miller                   Expires 29 October 2026               [Page 37]


  Internet-Draft                    ZTIP                        April 2026


      +==========================+=========================+===========+
      | Code                     | Meaning                 | Reference |
      +==========================+=========================+===========+
      | DEL_CHAIN_MISSING        | Policy requires a       | This      |
      |                          | Delegation Chain but    | document, |
      |                          | none was provided       | Section 3 |
      +--------------------------+-------------------------+-----------+
      | DEL_CHAIN_BROKEN         | Chain of delegator/     | This      |
      |                          | delegatee references    | document, |
      |                          | has a gap               | Section 3 |
      +--------------------------+-------------------------+-----------+
      | DEL_CHAIN_SCOPE_EXPANDED | A child layer attempts  | This      |
      |                          | to grant broader scope  | document, |
      |                          | than its parent         | Sections  |
      |                          |                         | 3, 3.4    |
      +--------------------------+-------------------------+-----------+
      | DEL_CHAIN_EXPIRED        | One or more chain       | This      |
      |                          | layers has expired      | document, |
      |                          |                         | Section 3 |
      +--------------------------+-------------------------+-----------+
      | DEL_CHAIN_UNTRUSTED_ROOT | The root Signed Intent  | This      |
      |                          | is not signed by a      | document, |
      |                          | trusted Originator      | Section 3 |
      +--------------------------+-------------------------+-----------+
      | DEL_CHAIN_DEPTH_EXCEEDED | The chain exceeds the   | This      |
      |                          | verifier's configured   | document, |
      |                          | maximum depth           | Section   |
      |                          |                         | 3.5       |
      +--------------------------+-------------------------+-----------+
      | INTENT_SCOPE_MISMATCH    | The requested operation | This      |
      |                          | is outside the scope    | document, |
      |                          | authorized by the root  | Section 4 |
      |                          | Signed Intent           |           |
      +--------------------------+-------------------------+-----------+

                                   Table 10

     Composition profiles MAY add codes via Specification Required.

  9.2.  HTTP Field Name Registration

     This document requests registration of the following HTTP field name
     in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (per
     [RFC9110] Section 16.3.1):







  Miller                   Expires 29 October 2026               [Page 38]


  Internet-Draft                    ZTIP                        April 2026


            +============+===========+============================+
            | Field Name | Status    | Reference                  |
            +============+===========+============================+
            | ZTIP-Chain | permanent | This document, Section 6.2 |
            +------------+-----------+----------------------------+

                                    Table 11

     *Specification:* The ZTIP-Chain HTTP header field carries a
     Delegation Chain (Section 3) as a single compact-serialized JSON Web
     Signature [RFC7515] value.  It is sent by clients alongside an
     Authorization: Bearer header in the OAuth 2.0 composition profile
     (Section 6.2).  The field value is the outermost JWS of a Delegation
     Chain in compact serialization.  The field MUST NOT appear more than
     once in a single request; a request bearing multiple ZTIP-Chain
     fields MUST be rejected with DEL_CHAIN_BROKEN.

     *Comments:* The author searched the IANA HTTP Field Name Registry as
     of the date of publication and found no existing field named ZTIP-
     Chain, no existing field beginning with ZTIP-, and no closely-related
     field name.  The closest prefix-matching field is Client-Cert-Chain,
     which addresses TLS certificate-chain transport — a different domain
     from delegation-chain transport.

  9.3.  Note on Behavioral Claim Names

     ZTIP does not request creation of an IANA registry for behavioral
     claim names.  Section 5 specifies a standard set of claims
     (prompt_injection_tested, tool_call_audit_logged, etc.) and an
     extension mechanism using URI-namespaced names, vendor-prefixed
     names, and privately-agreed names.  This intentional non-allocation
     mirrors the framework_id approach in ZTNP: the diversity of bespoke
     and enterprise behavioral claims makes a central registry
     impractical, and the namespacing conventions in Section 5 provide
     collision-free extension without IANA gatekeeping.

  10.  Implementation Status

     This section records known implementations per RFC 7942 and is to be
     removed before publication as an RFC.

     A reference TypeScript implementation of Delegation Chain
     verification, Intent-Scoped Authorization enforcement, and Behavioral
     Claim parsing is in progress at:

  https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/reference/typescript/ztip





  Miller                   Expires 29 October 2026               [Page 39]


  Internet-Draft                    ZTIP                        April 2026


     Test vectors covering valid chains, broken chains, scope-expanded
     chains, depth-exceeded chains, expired chains, and intent-scope
     mismatches are at:

  https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/test-vectors/ztip

     A Python reference implementation is planned.  Composition-profile
     reference implementations (OAuth, ZTNP) are planned as the protocols
     stabilize.

  11.  References

  11.1.  Normative References

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

     [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
                2015, <https://www.rfc-editor.org/rfc/rfc7515>.

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

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

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

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

  11.2.  Informative References



  Miller                   Expires 29 October 2026               [Page 40]


  Internet-Draft                    ZTIP                        April 2026


     [I-D.miller-ztnp]
                Miller, J., "Zero-Trust Negotiation Protocol (ZTNP) Core",
                Work in Progress, Internet-Draft, draft-miller-ztnp-00,
                n.d., <https://datatracker.ietf.org/doc/html/draft-miller-
                ztnp-00>.

     [Macaroons2014]
                Birgisson, A., Politz, J. G., Erlingsson, Ú., Taly, A.,
                Vrable, M., and M. Lentczner, "Macaroons: Cookies with
                Contextual Caveats for Decentralized Authorization in the
                Cloud", NDSS Symposium 2014, 2014,
                <https://research.google/pubs/pub41892/>.

     [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                DOI 10.17487/RFC3552, July 2003,
                <https://www.rfc-editor.org/rfc/rfc3552>.

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

     [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
                Morris, J., Hansen, M., and R. Smith, "Privacy
                Considerations for Internet Protocols", RFC 6973,
                DOI 10.17487/RFC6973, July 2013,
                <https://www.rfc-editor.org/rfc/rfc6973>.

     [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
                (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7519>.

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

     [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
                Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
                Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
                September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

     [RFC9635]  Richer, J., Ed. and F. Imbault, "Grant Negotiation and
                Authorization Protocol (GNAP)", RFC 9635,
                DOI 10.17487/RFC9635, October 2024,
                <https://www.rfc-editor.org/rfc/rfc9635>.





  Miller                   Expires 29 October 2026               [Page 41]


  Internet-Draft                    ZTIP                        April 2026


  Appendix A.  Worked Example: Three-Hop Delegation Chain (ZTNP
               Composition)

     This appendix presents a complete example of a three-party delegation
     chain using the *ZTNP composition profile* (Section 6.1).  It is
     informative; it does not introduce new normative requirements.
     Implementers SHOULD verify their implementation against this example.

  A.1.  Scenario

     User Alice asks her orchestrator to "summarize my unread emails from
     the last 24 hours and produce a markdown digest."  The orchestrator
     delegates the work to a specialized summarizer agent, which in turn
     calls the email-read tool.  Three signing principals participate:

     *  user:alice — the Originator (root)

     *  principal:orchestrator-1 — the orchestrator

     *  agent:summarizer-3 — the summarizer agent

     The downstream tool tool:email.read receives the call and verifies
     the entire chain before serving the request.

  A.2.  A.1 Layer 0: Signed Intent (Root)

     Alice's signing application produces the following intent_object:

     {
       "action": "summarize",
       "scope": {
         "actions": ["read"],
         "data": ["internal", "pii"],
         "tools": ["email.list", "email.read"]
       },
       "target": "unread emails from the last 24 hours",
       "constraints": {
         "must_not": ["email.send", "email.delete"]
       }
     }

     After JCS canonicalization per Section 3.2, the canonical bytes are:

  {"action":"summarize","constraints":{"must_not":["email.send","email.delete"]},"scope":{"actions":["read"],"data":["internal","pii"],"tools":["email.list","email.read"]},"target":"unread emails from the last 24 hours"}

     The base64url-encoded SHA-256 of these UTF-8 bytes is the
     intent_hash.  For this intent_object the value is:




  Miller                   Expires 29 October 2026               [Page 42]


  Internet-Draft                    ZTIP                        April 2026


     intent_hash = Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc

     This is the same intent_object (and therefore the same hash) as
     Example 1 in Section 3.2.

     The root layer's full payload (before JWS signing):

     {
       "del_chain_ver": "0.1",
       "intent_root": true,
       "originator": "user:alice",
       "intent_object": { /* as shown above */ },
       "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc",
       "authorized_chain": ["principal:orchestrator-1", "agent:summarizer-3"],
       "scope": { /* same value as intent_object.scope */ },
       "iat": 1745500800,
       "exp": 1745504400,
       "jti": "intent_01HVXYZ_SUMMARIZE_REQUEST"
     }

     This payload is signed with Alice's private key.  The result is a
     compact JWS denoted JWS_root.

  A.3.  A.2 Layer 1: Orchestrator's Delegation

     The orchestrator receives JWS_root and delegates to the summarizer
     agent:

     {
       "del_chain_ver": "0.1",
       "delegator": "principal:orchestrator-1",
       "delegatee": "agent:summarizer-3",
       "scope_reduction": {
         "actions": ["read"],
         "data": ["internal", "pii"],
         "tools": ["email.list", "email.read"]
       },
       "iat": 1745500850,
       "exp": 1745504400,
       "inner": "<JWS_root as compact JWS>"
     }

     The orchestrator does not narrow scope here.  It signs with its own
     key, producing JWS_orch.







  Miller                   Expires 29 October 2026               [Page 43]


  Internet-Draft                    ZTIP                        April 2026


  A.4.  A.3 Layer 2: Summarizer's Delegation

     The summarizer narrows scope (no PII, only email.read):

     {
       "del_chain_ver": "0.1",
       "delegator": "agent:summarizer-3",
       "delegatee": "tool:email.read",
       "scope_reduction": {
         "actions": ["read"],
         "data": ["internal"],
         "tools": ["email.read"]
       },
       "iat": 1745500900,
       "exp": 1745504400,
       "inner": "<JWS_orch as compact JWS>"
     }

     Both reductions (data: dropping pii; tools: dropping email.list) are
     valid per the Section 3.4 monotonicity table.  The summarizer signs
     with its own key, producing JWS_sum.  This is the outermost layer and
     is what travels in the PROOF message's delegation_chain field (per
     the ZTNP composition profile, Section 6.1).

  A.5.  A.4 Verification Transcript at the Tool

     The email.read tool verifies the chain:

     Step 1: Unwrap JWS_sum.  Verify against agent:summarizer-3's public
     key (from the IKS, since this is a ZTNP composition).

     Step 2: Check expiration: current time = 1745501000, JWS_sum.exp =
     1745504400.  Not expired.

     Step 3: Recurse into JWS_sum.inner.  Unwrap JWS_orch.  Verify against
     principal:orchestrator-1's public key.

     Step 4: Recurse into JWS_orch.inner.  Unwrap JWS_root.  Verify
     against user:alice's public key. user:alice is in the tool's trusted-
     originators set.

     Step 5: Verify root structure: intent_root: true; originator matches
     trusted set.

     Step 6: Verify chain integrity.  JWS_orch.delegator is in
     JWS_root.authorized_chain; JWS_orch.delegatee = JWS_sum.delegator.





  Miller                   Expires 29 October 2026               [Page 44]


  Internet-Draft                    ZTIP                        April 2026


     Step 7: Verify scope monotonicity (Section 3.4) — all subset checks
     pass.

     Step 8: Verify chain depth: 3 layers, well within the default maximum
     of 8.

     Step 9: Recompute intent_hash from JWS_root.intent_object; compare to
     JWS_root.intent_hash.  Match.

     All checks pass.

  A.6.  A.5 Intent-Scoped Permit Issued Alongside the Chain

     Under the ZTNP composition (Section 6.1), an Intent-Scoped Permit
     covering this scenario:

     {
       "iss": "https://gateway.example",
       "sub": "agent:summarizer-3",
       "iat": 1745500900,
       "exp": 1745504400,
       "permit_id": "permit_01HVXYZ_INTENT_TEST",
       "constraints": {
         "actions": ["read"],
         "data": ["internal"],
         "tools": ["email.read"]
       },
       "ch_binding": {
         "method": "tls-exporter",
         "label": "EXPORTER-ZTNP-permit-binding",
         "context_hash": "..."
       },
       "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc",
       "intent_scope": {
         "actions": ["read"],
         "data": ["internal"],
         "tools": ["email.read"]
       },
       "chain_root_iss": "user:alice",
       "chain_root_jti": "intent_01HVXYZ_SUMMARIZE_REQUEST"
     }

     For a prompt-injected email.send({to: "attacker@example", ...}) call,
     the intent_scope.tools does not include email.send.  The verifier
     returns INTENT_SCOPE_MISMATCH.  This is the prompt-injection-
     resistance guarantee.





  Miller                   Expires 29 October 2026               [Page 45]


  Internet-Draft                    ZTIP                        April 2026


  A.7.  A.6 Failure Modes

     Three modifications that would cause rejection:

     1.  JWS_sum.scope_reduction.tools includes email.send →
         DEL_CHAIN_SCOPE_EXPANDED.

     2.  JWS_orch's signer is unknown to the tool → signature verification
         fails at Step 3.

     3.  JWS_root.intent_object differs from what the orchestrator
         believed → recomputed intent_hash differs →
         INTENT_SCOPE_MISMATCH.

     4.  The chain has more than 8 layers → DEL_CHAIN_DEPTH_EXCEEDED.

     Machine-readable test vectors corresponding to this example are at
     test-vectors/ztip/.

  Appendix B.  Comparison with Macaroons and Related Capability Tokens

     This appendix is informative.  It compares ZTIP to macaroons
     [Macaroons2014] and the related capability-with-caveats tokens
     (biscuits, wafers) that have appeared since.  ZTIP and macaroons
     share an append-only scope-reduction property and are sometimes
     considered for the same problems; the comparison clarifies where they
     overlap and where they diverge.

  B.1.  At a Glance

     +=================+==========================+======================+
     | Property        | Macaroons / Biscuits     | ZTIP Delegation      |
     |                 | / Wafers                 | Chain                |
     +=================+==========================+======================+
     | Authentication  | HMAC keyed by issuer     | Asymmetric digital   |
     | primitive       | (third-party caveats     | signature per layer  |
     |                 | use additional           | (any JWS signature   |
     |                 | discharge tokens)        | alg)                 |
     +-----------------+--------------------------+----------------------+
     | Identity of     | Not bound — any          | Each layer's         |
     | each delegator  | token holder can         | delegator and        |
     |                 | append a caveat          | delegatee are signed |
     |                 |                          | identifiers          |
     +-----------------+--------------------------+----------------------+
     | Scope-reduction | Caveats: predicates      | Structured scope     |
     | model           | ("user = alice",         | fields with the      |
     |                 | "expires < T")           | formal subset        |
     |                 | evaluated at             | relation in          |



  Miller                   Expires 29 October 2026               [Page 46]


  Internet-Draft                    ZTIP                        April 2026


     |                 | verification             | Section 3.4          |
     +-----------------+--------------------------+----------------------+
     | Originator      | None — the token         | intent_hash binds    |
     | intent binding  | represents               | the chain to a       |
     |                 | capability, not          | structured           |
     |                 | intent                   | originator intent    |
     +-----------------+--------------------------+----------------------+
     | Verification    | Yes (or third-party      | No — verifier needs  |
     | depends on      | discharge for cross-     | each delegator's     |
     | shared secret?  | domain)                  | public key, obtained |
     |                 |                          | via the deployment's |
     |                 |                          | Key Source           |
     +-----------------+--------------------------+----------------------+
     | Token format    | Self-contained           | Layered JWS attached |
     |                 | capability token         | alongside an         |
     |                 |                          | Authorization Token  |
     +-----------------+--------------------------+----------------------+
     | Composes with   | Generally replaces       | Extends OAuth 2.0,   |
     | existing token  | them                     | GNAP, ZTNP, or       |
     | formats?        |                          | vendor tokens        |
     +-----------------+--------------------------+----------------------+

                                    Table 12

  B.2.  When Macaroons Fit Better Than ZTIP

     *  Closed deployments where issuer and verifier share an HMAC key and
        no third party participates in delegation.

     *  Single-trust-domain capability stores where "anyone holding the
        token may further restrict it" is the desired semantics.

     *  Resource-constrained verifiers that cannot perform asymmetric
        signature verification.

     *  Use cases where the _who_ of each delegation step is irrelevant —
        only the _what_ (the resulting set of permitted operations)
        matters.

  B.3.  When ZTIP Fits Better Than Macaroons

     *  Multi-principal delegation chains where each delegating principal
        (user, orchestrator, sub-agent) has its own identity that the
        verifier needs to verify and audit.







  Miller                   Expires 29 October 2026               [Page 47]


  Internet-Draft                    ZTIP                        April 2026


     *  Deployments where the originator's _intent_ is a first-class
        security property — that is, where the verifier needs to reject
        operations consistent with the token's stated scope but
        inconsistent with what the user actually asked for.  This is the
        prompt-injection / confused-deputy mitigation in Section 4.

     *  Deployments composing with existing PKI, JWT-based authorization,
        OAuth 2.0, or GNAP, where introducing a parallel HMAC trust system
        would be operationally undesirable.

     *  Audit and forensic environments where reconstructing "which entity
        authorized which step" must be possible from the chain itself.

  B.4.  Conceptual Lineage

     ZTIP's append-only scope reduction (Section 3.4) shares its
     philosophical lineage with macaroons.  Both encode the principle that
     delegation may only narrow, never broaden, what was authorized.
     ZTIP's contribution is to (a) bind the chain's root to a _structured
     intent_ the originator signed, (b) require each layer to be signed by
     an identified principal rather than anyone holding the token, and (c)
     compose with existing authorization-token formats rather than
     replacing them.  The macaroons paper's caveat predicates also
     influenced ZTIP's design of the constraints field on intent_object
     (Section 3.2), which is profile-extensible to support arbitrary
     additional predicates beyond the structured scope dimensions.

  Appendix C.  Conformance Profile

     ZTIP's three primitives (Delegation Chain Attestation, Intent-Scoped
     Authorization, Behavioral Claim Extensions) are independently useful,
     and deployments MAY adopt one without the others (Section 1).  The
     conformance profile defines two conformance levels accordingly.

     *Full conformance.* An implementation is fully conformant with ZTIP
     if it implements all three primitives:

     *  Produces and validates Delegation Chain JWS structures per
        Section 3.

     *  Enforces scope monotonicity across delegation layers per
        Section 3.4.

     *  Enforces a configured maximum chain depth per Section 3.5.

     *  Issues and enforces Intent-Scoped Authorization Tokens per
        Section 4.




  Miller                   Expires 29 October 2026               [Page 48]


  Internet-Draft                    ZTIP                        April 2026


     *  Carries ai_behavior Behavioral Claims when applicable per
        Section 5.

     *  Implements at least one composition profile from Section 6.

     *Partial conformance.* An implementation supporting only a subset of
     the three primitives MAY claim partial conformance by listing the
     primitives it implements (e.g., "ZTIP partial: Delegation Chain
     Attestation only" or "ZTIP partial: Delegation Chain Attestation +
     Intent-Scoped Authorization, no Behavioral Claims").  Partial-
     conformant implementations of any one primitive MUST satisfy that
     primitive's normative requirements in full — partial conformance
     refers to which primitives are implemented, not to weakening the
     requirements within a chosen primitive.

     All conforming implementations (full or partial) MUST declare which
     composition profiles they support.

  Acknowledgments

     The author thanks the early reviewers for feedback on multi-principal
     delegation.  ZTIP's design draws on the confused-deputy literature
     and on emerging research into prompt-injection mitigations.  The
     composition-profile pattern follows the precedent set by DPoP
     [RFC9449].

  Author's Address

     Jake Miller
     Email: jake@zivis.ai





















  Miller                   Expires 29 October 2026               [Page 49]


