# drafts

name: draft-aiendpoint-ai-discovery
rev: 00
time: 2026-03-23T11:43:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-24T11:43:49Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-05-22T09:24:48.589039+00:00
source: ietf
title:
  The AI Discovery Endpoint: A Structured Mechanism for AI Agent Service Discovery and Capability Exposure

abstract:
  This document defines a lightweight mechanism by which web services
     expose a machine-readable description of their capabilities to
     autonomous AI agents.  The mechanism consists of a well-known
     resource, served at "/.well-known/ai", that returns a structured JSON
     document describing the service's identity, available actions,
     authentication requirements, and operational hints optimized for
     large language model (LLM) token efficiency.

     The specification addresses the absence of a standardized method for
     AI agents to programmatically discover what a web service can do and
     how to invoke its capabilities, without resorting to parsing human-
     oriented documentation or HTML content.

full_text:
  Internet Engineering Task Force                                  Y. Choi
  Internet-Draft                                                AIEndpoint
  Intended status: Standards Track                           23 March 2026
  Expires: 24 September 2026


   The AI Discovery Endpoint: A Structured Mechanism for AI Agent Service
                     Discovery and Capability Exposure
                      draft-aiendpoint-ai-discovery-00

  Abstract

     This document defines a lightweight mechanism by which web services
     expose a machine-readable description of their capabilities to
     autonomous AI agents.  The mechanism consists of a well-known
     resource, served at "/.well-known/ai", that returns a structured JSON
     document describing the service's identity, available actions,
     authentication requirements, and operational hints optimized for
     large language model (LLM) token efficiency.

     The specification addresses the absence of a standardized method for
     AI agents to programmatically discover what a web service can do and
     how to invoke its capabilities, without resorting to parsing human-
     oriented documentation or HTML content.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 24 September 2026.

  Copyright Notice

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





  Choi                    Expires 24 September 2026               [Page 1]


  Internet-Draft            AI Discovery Endpoint               March 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
       1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  The AI Discovery Resource . . . . . . . . . . . . . . . . . .   5
       2.1.  Resource Location . . . . . . . . . . . . . . . . . . . .   5
       2.2.  Access Method . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .   6
       2.4.  Character Encoding  . . . . . . . . . . . . . . . . . . .   6
     3.  Response Schema . . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Top-Level Structure . . . . . . . . . . . . . . . . . . .   6
       3.2.  The "service" Object  . . . . . . . . . . . . . . . . . .   7
       3.3.  The "capabilities" Array  . . . . . . . . . . . . . . . .   8
       3.4.  The "auth" Object . . . . . . . . . . . . . . . . . . . .  10
       3.5.  The "token_hints" Object  . . . . . . . . . . . . . . . .  10
       3.6.  The "rate_limits" Object  . . . . . . . . . . . . . . . .  11
       3.7.  The "meta" Object . . . . . . . . . . . . . . . . . . . .  11
     4.  Processing Rules  . . . . . . . . . . . . . . . . . . . . . .  12
       4.1.  Fetching  . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.2.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .  12
       4.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  13
       4.4.  Version Negotiation . . . . . . . . . . . . . . . . . . .  13
       4.5.  Size Limits . . . . . . . . . . . . . . . . . . . . . . .  14
     5.  Token Efficiency Considerations . . . . . . . . . . . . . . .  14
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
       6.1.  Information Disclosure  . . . . . . . . . . . . . . . . .  15
       6.2.  Authentication Credential Exposure  . . . . . . . . . . .  15
       6.3.  Abuse by Automated Agents . . . . . . . . . . . . . . . .  15
       6.4.  Content Integrity . . . . . . . . . . . . . . . . . . . .  16
       6.5.  Denial of Service . . . . . . . . . . . . . . . . . . . .  16
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
       7.1.  Well-Known URI Registration . . . . . . . . . . . . . . .  16
     8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       8.1.  Minimal Conformant Response . . . . . . . . . . . . . . .  17
       8.2.  Full-Featured Response  . . . . . . . . . . . . . . . . .  17
       8.3.  Service with No Authentication  . . . . . . . . . . . . .  18
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  20



  Choi                    Expires 24 September 2026               [Page 2]


  Internet-Draft            AI Discovery Endpoint               March 2026


       9.2.  Informative References  . . . . . . . . . . . . . . . . .  21
     Appendix A.  Comparison with Existing Approaches  . . . . . . . .  21
       A.1.  robots.txt (RFC 9309) . . . . . . . . . . . . . . . . . .  22
       A.2.  OpenAPI / Swagger . . . . . . . . . . . . . . . . . . . .  22
       A.3.  Model Context Protocol (MCP)  . . . . . . . . . . . . . .  22
       A.4.  llms.txt  . . . . . . . . . . . . . . . . . . . . . . . .  22
       A.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .  23
     Appendix B.  JSON Schema  . . . . . . . . . . . . . . . . . . . .  23
     Appendix C.  Design Rationale . . . . . . . . . . . . . . . . . .  23
       C.1.  Why a Well-Known URI? . . . . . . . . . . . . . . . . . .  23
       C.2.  Why JSON over Other Formats?  . . . . . . . . . . . . . .  24
       C.3.  Why Compact Parameter Descriptions? . . . . . . . . . . .  24
       C.4.  Why No Request/Response Examples? . . . . . . . . . . . .  24
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  25
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

  1.  Introduction

     The rapid proliferation of autonomous AI agents -- software systems
     powered by large language models (LLMs) that perform tasks on behalf
     of users -- has created a fundamental interoperability gap on the
     World Wide Web.  While the web has well-established mechanisms for
     communicating with human users (HTML) and search engine crawlers
     (robots.txt [RFC9309], sitemaps), no equivalent standard exists for
     AI agents seeking to discover and invoke the capabilities of web
     services.

     Today, when an AI agent attempts to interact with a web service, it
     must resort to one or more of the following strategies:

     *  Parsing HTML pages designed for human consumption, extracting
        structured meaning from unstructured content at significant
        computational cost (typically 8,000-15,000 LLM tokens per page).

     *  Reading API documentation scattered across multiple pages, often
        requiring the agent to navigate hyperlinks, interpret natural
        language descriptions, and resolve ambiguities.

     *  Using pre-configured tool definitions maintained by the agent's
        developer, which become stale as services evolve and cannot scale
        to the breadth of services on the web.

     *  Attempting trial-and-error API calls, which waste computational
        resources and risk triggering rate limits or unintended side
        effects.






  Choi                    Expires 24 September 2026               [Page 3]


  Internet-Draft            AI Discovery Endpoint               March 2026


     These approaches are inefficient, error-prone, and fundamentally
     unscalable.  A single service discovery interaction that could be
     accomplished in 200-500 LLM tokens with a structured response instead
     requires 3,000-15,000 tokens of unstructured content parsing -- a 10x
     to 30x overhead.

     This document defines the AI Discovery Endpoint, a mechanism whereby
     a web service publishes a single, structured JSON document at a well-
     known location.  This document describes the service's identity,
     enumerates its capabilities as discrete invocable actions, specifies
     authentication requirements, and provides operational hints that
     enable AI agents to interact with the service efficiently.

     The design prioritizes:

     *  Simplicity: A developer SHOULD be able to implement a conformant
        endpoint in under 30 minutes using any web framework.

     *  Token efficiency: The response format is optimized to convey
        maximum information in minimum LLM tokens.

     *  Universality: The mechanism requires only HTTP and JSON -- no
        custom protocols, transport layers, or runtime dependencies.

     *  Backward compatibility: Future versions of this specification will
        extend the schema additively; fields defined in this version will
        not be removed or have their semantics altered.

  1.1.  Requirements Language

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

  1.2.  Terminology

     AI Agent:  An autonomous software system, typically powered by a
        large language model, that performs tasks on behalf of a user by
        discovering and invoking web services programmatically.

     AI Discovery Document:  The JSON document served at the AI Discovery
        Endpoint, conforming to the schema defined in this specification.

     Capability:  A discrete, invocable action that a web service exposes
        to AI agents, described by an identifier, an HTTP endpoint, a
        method, and parameter/return specifications.



  Choi                    Expires 24 September 2026               [Page 4]


  Internet-Draft            AI Discovery Endpoint               March 2026


     Service Provider:  The operator of a web service that publishes an AI
        Discovery Document.

     Token:  The fundamental unit of text processing in a large language
        model.  The efficiency of AI agent interactions is measured in
        tokens consumed.

  2.  The AI Discovery Resource

  2.1.  Resource Location

     A service provider that implements this specification MUST serve the
     AI Discovery Document at the following well-known URI [RFC8615]:

     /.well-known/ai

     The complete URI is constructed by appending "/.well-known/ai" to the
     authority (scheme and host) of the service.  For example, for a
     service at "https://example.com", the AI Discovery Document is
     located at:

     https://example.com/.well-known/ai

     A service provider MAY additionally serve an identical copy of the AI
     Discovery Document at the path "/ai" on the same authority, as a
     convenience alias.  When both locations are served, the content MUST
     be identical.  An AI agent that receives differing content from the
     two locations MUST treat the "/.well-known/ai" response as
     authoritative.

     The AI Discovery Document MUST NOT be served at a path that includes
     query parameters or fragment identifiers.  The resource is a single,
     complete document.

  2.2.  Access Method

     The AI Discovery Document MUST be accessible via an HTTP GET request
     [RFC9110].

     The server MUST NOT require authentication to access the AI Discovery
     Document itself.  The purpose of the document is to enable discovery;
     requiring authentication to discover what authentication is needed
     creates a circular dependency.

     The server SHOULD respond to requests within 3 seconds under normal
     operating conditions.  AI agents MAY treat responses exceeding 10
     seconds as unavailable.




  Choi                    Expires 24 September 2026               [Page 5]


  Internet-Draft            AI Discovery Endpoint               March 2026


     The server MUST respond with HTTP status code 200 (OK) when the AI
     Discovery Document is available and the request is valid.

     If the server does not implement this specification, it SHOULD
     respond with HTTP status code 404 (Not Found).  An AI agent receiving
     a 404 response MUST conclude that the service does not publish an AI
     Discovery Document.

     The server MAY respond with HTTP status code 301 (Moved Permanently)
     or 302 (Found) to redirect to another location.  An AI agent MUST
     follow redirects up to a maximum of 5 consecutive redirections.  The
     agent MUST NOT follow redirects that change the scheme from "https"
     to "http".

  2.3.  Media Type

     The AI Discovery Document MUST be served with the media type
     "application/json" [RFC8259].

     Servers SHOULD include the "charset=utf-8" parameter:

     Content-Type: application/json; charset=utf-8

  2.4.  Character Encoding

     The AI Discovery Document MUST be encoded in UTF-8 [RFC3629].  This
     ensures consistent handling of non-ASCII characters in service
     descriptions, capability names, and other textual fields, which is
     particularly important for services operating in multilingual
     environments.

  3.  Response Schema

     The AI Discovery Document is a single JSON object [RFC8259]
     containing the fields defined in this section.

  3.1.  Top-Level Structure

     The top-level JSON object MUST contain the following fields:

     aiendpoint:  (string, REQUIRED) The version of this specification to
        which the document conforms.  For documents conforming to this
        specification, the value MUST be "1.0".

     service:  (object, REQUIRED) An object describing the identity of the
        service.  See Section 3.2.

     capabilities:  (array, REQUIRED) A non-empty array of capability



  Choi                    Expires 24 September 2026               [Page 6]


  Internet-Draft            AI Discovery Endpoint               March 2026


        objects, each describing a discrete action the service exposes to
        AI agents.  See Section 3.3.

     The top-level JSON object MAY contain the following fields:

     auth:  (object, OPTIONAL) An object describing the authentication
        requirements of the service.  See Section 3.4.

     token_hints:  (object, OPTIONAL) An object providing hints for AI
        agents on how to reduce token consumption when invoking the
        service's capabilities.  See Section 3.5.

     rate_limits:  (object, OPTIONAL) An object describing the rate
        limiting policy of the service.  See Section 3.6.

     meta:  (object, OPTIONAL) An object containing metadata about the AI
        Discovery Document itself.  See Section 3.7.

     A conformant AI Discovery Document MUST NOT contain fields not
     defined in this specification at the top level.  This constraint
     ensures that future versions of the specification can introduce new
     top-level fields without conflicting with proprietary extensions.
     Service providers requiring custom metadata SHOULD use the "meta"
     object for this purpose.

  3.2.  The "service" Object

     The "service" object describes the identity and classification of the
     service.  It MUST contain the following fields:

     name:  (string, REQUIRED) The human-readable name of the service.
        This value SHOULD be the commonly recognized name of the service
        (e.g., "GitHub", "Stripe", "OpenWeatherMap").  The value MUST be
        between 1 and 100 characters in length.

     description:  (string, REQUIRED) A concise, factual description of
        what the service does.  This description is intended for machine
        consumption and SHOULD be written in a declarative style that
        prioritizes clarity over marketing language.  The value MUST be
        between 1 and 300 characters in length.

        Authors SHOULD aim for descriptions under 200 characters to
        optimize token consumption.

     The "service" object MAY contain the following fields:

     category:  (array of strings, OPTIONAL) One or more category labels




  Choi                    Expires 24 September 2026               [Page 7]


  Internet-Draft            AI Discovery Endpoint               March 2026


        that classify the service for discovery purposes.  The following
        category values are defined in this version of the specification:
        "productivity", "ecommerce", "finance", "news", "weather", "maps",
        "search", "data", "communication", "calendar", "storage", "media",
        "health", "education", "travel", "food", "government",
        "developer".

        Service providers SHOULD select from the above list to maximize
        interoperability with discovery systems.  Future versions of this
        specification MAY define additional categories.  A discovery
        system encountering an unrecognized category value SHOULD ignore
        it without error.

        The array MUST contain at least one element if present, and MUST
        NOT contain duplicate values.

     language:  (array of strings, OPTIONAL) The natural languages
        supported by the service, expressed as BCP 47 [RFC5646] language
        tags.  If omitted, the default value is ["en"].

        The array MUST contain at least one element if present, and MUST
        NOT contain duplicate values.

  3.3.  The "capabilities" Array

     The "capabilities" array is the core of the AI Discovery Document.
     Each element describes a single, discrete action that an AI agent can
     invoke.

     The array MUST contain at least one element.

     Service providers SHOULD limit the array to capabilities that are
     meaningful for AI agent consumption.  Internal endpoints,
     administrative functions, and endpoints that require complex multi-
     step human interaction SHOULD be omitted.

     Each capability object MUST contain the following fields:

     id:  (string, REQUIRED) A unique identifier for this capability
        within the service.  The identifier MUST match the regular
        expression ^[a-z][a-z0-9_]*$ (lowercase ASCII letters, digits, and
        underscores, beginning with a letter).  The identifier MUST be
        between 1 and 64 characters in length.

        The identifier serves as a stable reference for the capability.
        Service providers SHOULD NOT change the identifier of an existing
        capability, as AI agents and external systems may reference it.




  Choi                    Expires 24 September 2026               [Page 8]


  Internet-Draft            AI Discovery Endpoint               March 2026


     description:  (string, REQUIRED) A concise description of what this
        capability does.  The value MUST be between 1 and 200 characters
        in length.

        This description is the primary mechanism by which an AI agent
        determines whether a capability is relevant to its task.  Authors
        SHOULD write descriptions that are specific and actionable.

     endpoint:  (string, REQUIRED) The URI or URI path at which this
        capability is accessible.  The value MUST be non-empty.

        If the value begins with "/" (U+002F), it is a relative path and
        MUST be resolved against the authority of the AI Discovery
        Document's URI.  If the value is an absolute URI (beginning with a
        scheme), it is used as-is.  This allows services to expose
        capabilities hosted on different domains or subdomains.

     method:  (string, REQUIRED) The HTTP method used to invoke this
        capability.  The value MUST be one of: "GET", "POST", "PUT",
        "DELETE", "PATCH".

     Each capability object MAY contain the following fields:

     params:  (object, OPTIONAL) A JSON object describing the parameters
        accepted by this capability's endpoint.  Each key is a parameter
        name, and each value is a string describing the parameter in a
        compact, structured format.

        The parameter description string SHOULD follow this pattern:

        <type>, <requirement>[, <constraints>] [-- <description>]

        Where:

        *  <type> is the data type: "string", "integer", "number",
           "boolean", or "array"

        *  <requirement> is "required" or "optional"

        *  <constraints> are optional qualifiers such as "default 10",
           "max 50", "min 1", or enumerated values separated by "|"

        *  <description> is an optional natural language description,
           separated by an em dash or double hyphen (--)

     returns:  (string, OPTIONAL) A compact description of the response
        structure.  The value MUST NOT exceed 300 characters in length.




  Choi                    Expires 24 September 2026               [Page 9]


  Internet-Draft            AI Discovery Endpoint               March 2026


        Authors SHOULD use a concise structural notation that conveys the
        shape of the response, e.g., "products[] {id, name, price,
        stock}".

  3.4.  The "auth" Object

     The "auth" object describes how an AI agent must authenticate when
     invoking the service's capabilities.

     When present, the "auth" object MUST contain the following field:

     type:  (string, REQUIRED) The authentication mechanism required by
        the service.  The value MUST be one of:

        "none":  No authentication is required.  All capabilities are
           publicly accessible.

        "apikey":  Authentication via a static API key, typically passed
           in an HTTP header.

        "bearer":  Authentication via a bearer token (e.g., JWT), passed
           in the Authorization header as defined in [RFC6750].

        "oauth2":  Authentication via the OAuth 2.0 framework [RFC6749].

     The "auth" object MAY contain the following fields:

     header:  (string, OPTIONAL) The name of the HTTP header in which the
        authentication credential is passed.  This field is most useful
        for "apikey" authentication where the header name varies across
        services (e.g., "X-API-Key", "Api-Key", "Authorization").  For
        "bearer" authentication, the header is implicitly "Authorization"
        and this field MAY be omitted.

     docs:  (string, OPTIONAL) A URI pointing to human-readable
        documentation for the service's authentication process.

     If the "auth" object is omitted entirely, an AI agent SHOULD assume
     that authentication may be required.  Service providers are therefore
     RECOMMENDED to include the "auth" object even when no authentication
     is required, with type set to "none".

  3.5.  The "token_hints" Object

     The "token_hints" object provides signals to AI agents about features
     the service supports to reduce the token cost of capability
     invocations.




  Choi                    Expires 24 September 2026              [Page 10]


  Internet-Draft            AI Discovery Endpoint               March 2026


     All fields in the "token_hints" object are boolean and OPTIONAL.  If
     the object is omitted, all fields default to false.

     compact_mode:  (boolean, default false) If true, the service's
        capability endpoints accept a query parameter "compact=true" that
        causes the response to include only essential fields, omitting
        verbose or supplementary data.

     field_filtering:  (boolean, default false) If true, the service's
        capability endpoints accept a query parameter "fields" whose value
        is a comma-separated list of field names.  The response includes
        only the specified fields.

     delta_support:  (boolean, default false) If true, the service's
        capability endpoints accept a query parameter "since" whose value
        is an ISO 8601 timestamp.  The response includes only records
        created or modified after the specified timestamp.

  3.6.  The "rate_limits" Object

     The "rate_limits" object informs AI agents of the service's rate
     limiting policy, enabling agents to plan their request patterns to
     avoid throttling.

     requests_per_minute:  (integer, OPTIONAL) The maximum number of
        requests an AI agent may make per minute under the default access
        tier.  The value MUST be a positive integer.  This is an advisory
        limit.  AI agents SHOULD use this value to pace their requests.

     agent_tier_available:  (boolean, OPTIONAL) If true, the service
        offers a higher rate limit tier specifically for AI agents.
        Details of how to access this tier are available at the URI
        specified in "auth.docs".

  3.7.  The "meta" Object

     The "meta" object contains metadata about the AI Discovery Document
     itself (not the service it describes).  All fields are OPTIONAL.

     last_updated:  (string, OPTIONAL) The date on which the AI Discovery
        Document was last modified, expressed in ISO 8601 format (YYYY-MM-
        DD or YYYY-MM-DDThh:mm:ssZ).

     changelog:  (string, OPTIONAL) A URI pointing to a changelog or
        release notes page for the service.

     status:  (string, OPTIONAL) A URI pointing to a service status page.




  Choi                    Expires 24 September 2026              [Page 11]


  Internet-Draft            AI Discovery Endpoint               March 2026


        AI agents MAY consult this URI before invoking capabilities on a
        service that appears to be experiencing errors.

  4.  Processing Rules

     This section defines how AI agents and other consumers SHOULD process
     the AI Discovery Document.

  4.1.  Fetching

     An AI agent attempting to discover the capabilities of a service at a
     given authority SHOULD perform the following steps:

     1.  Construct the well-known URI by appending "/.well-known/ai" to
         the authority (e.g., "https://example.com/.well-known/ai").

     2.  Issue an HTTP GET request to the constructed URI.

     3.  If the response status is 200 (OK) and the Content-Type header
         indicates "application/json", parse the response body as a JSON
         object.

     4.  Validate that the parsed object contains the required fields
         "aiendpoint", "service", and "capabilities" as defined in
         Section 3.

     5.  If validation succeeds, the service is considered to have a valid
         AI Discovery Document.  The agent MAY proceed to invoke the
         service's capabilities as described.

     If the response status is 404 (Not Found), the agent MAY optionally
     attempt to fetch the resource at "/ai" as a fallback.  However, the
     "/.well-known/ai" location is authoritative, and agents MUST NOT
     treat a response from "/ai" as valid if the "/.well-known/ai"
     location returns a different response.

     An agent MUST NOT issue requests to any capability endpoint described
     in the AI Discovery Document without first confirming that the
     document is valid and that the capability's method, endpoint, and
     parameters are well-formed.

  4.2.  Caching

     The AI Discovery Document is expected to change infrequently.
     Service providers SHOULD include appropriate HTTP caching headers
     [RFC9111] in the response.  A Cache-Control max-age value of 86400
     (24 hours) is RECOMMENDED for most services.




  Choi                    Expires 24 September 2026              [Page 12]


  Internet-Draft            AI Discovery Endpoint               March 2026


     Cache-Control: public, max-age=86400

     AI agents SHOULD respect standard HTTP caching semantics.  When the
     "meta.last_updated" field is present, an agent MAY compare it against
     a previously stored value to determine whether the document has
     changed.

  4.3.  Error Handling

     AI agents MUST handle the following error conditions gracefully:

     HTTP 404 (Not Found):  The service does not implement this
        specification.  The agent MUST NOT retry the request for the same
        authority within a reasonable period (RECOMMENDED: 24 hours).

     HTTP 5xx (Server Error):  The service may be temporarily unavailable.
        The agent MAY retry after an appropriate delay, using exponential
        backoff with a maximum of 3 retry attempts.

     HTTP 429 (Too Many Requests):  The agent has exceeded the service's
        rate limit.  The agent MUST respect the Retry-After header if
        present.

     Invalid JSON:  If the response body cannot be parsed as valid JSON,
        the agent MUST treat the service as not implementing this
        specification.

     Schema Violation:  If the parsed JSON does not contain the required
        fields, the agent SHOULD treat the document as invalid.  An agent
        MAY attempt to use partially valid documents at its own risk.

  4.4.  Version Negotiation

     This specification defines version "1.0" of the AI Discovery
     Document.  The "aiendpoint" field identifies the version.

     An AI agent that encounters an "aiendpoint" value it does not
     recognize SHOULD still attempt to parse the document using the rules
     of the highest version it supports.  Because this specification
     mandates additive-only changes across versions, a version 1.0 agent
     can safely process a version 1.1 document by ignoring unknown fields.

     An AI agent MUST NOT reject a document solely because the
     "aiendpoint" value is higher than the version it supports.







  Choi                    Expires 24 September 2026              [Page 13]


  Internet-Draft            AI Discovery Endpoint               March 2026


  4.5.  Size Limits

     An AI Discovery Document SHOULD NOT exceed 64 kilobytes in size.
     Service providers whose capabilities would exceed this limit SHOULD
     consider splitting their service into logical sub-services, each with
     its own AI Discovery Document.

     An AI agent MAY refuse to process a document that exceeds 256
     kilobytes.

  5.  Token Efficiency Considerations

     A primary design goal of this specification is to minimize the number
     of LLM tokens required for an AI agent to discover and understand a
     service's capabilities.

     As of this writing, leading LLMs consume approximately 1 token per 4
     characters of English text and 1 token per 1-2 characters of JSON
     structural elements.  Non-Latin scripts (e.g., CJK characters)
     typically consume 1-3 tokens per character.

     A well-formed AI Discovery Document for a service with 5 capabilities
     is expected to consume between 200 and 800 tokens.  By contrast,
     extracting equivalent information from a typical HTML documentation
     page requires 3,000 to 15,000 tokens -- an overhead factor of 10x to
     30x.

     This efficiency gain is achieved through several design choices:

     *  Compact parameter descriptions: Parameters are described in a
        single string that encodes type, requirement, constraints, and
        description in a compact notation, rather than a verbose schema
        format as in OpenAPI.

     *  Structural response descriptions: The "returns" field uses a
        concise notation (e.g., "products[] {id, name, price}") rather
        than a full JSON Schema definition.

     *  Absence of examples: Unlike OpenAPI, this specification does not
        include example request/response pairs in the discovery document.
        AI agents are expected to infer usage from parameter and return
        descriptions.

     *  Fixed vocabulary: Category values and authentication types use a
        closed vocabulary, eliminating the need for agents to interpret
        free-form text in these fields.





  Choi                    Expires 24 September 2026              [Page 14]


  Internet-Draft            AI Discovery Endpoint               March 2026


  6.  Security Considerations

     The AI Discovery Document inherently exposes information about a
     service's internal structure and capabilities.  Service providers
     MUST carefully consider the security implications of this disclosure.

  6.1.  Information Disclosure

     The AI Discovery Document reveals the existence, paths, methods, and
     parameter structures of API endpoints.  While this information may
     already be available through documentation or reverse engineering,
     the structured, machine-readable format significantly lowers the
     barrier for automated reconnaissance.

     Service providers MUST NOT include endpoints in the "capabilities"
     array that they do not intend to be publicly discoverable.
     Administrative endpoints, internal APIs, and endpoints under
     development MUST be excluded.

  6.2.  Authentication Credential Exposure

     The "auth" object describes the authentication mechanism but MUST NOT
     contain actual credentials, secrets, tokens, or keys.  The "header"
     field specifies the name of the header in which a credential is
     passed, not the credential itself.

     An AI agent that stores or caches AI Discovery Documents MUST ensure
     that no credentials are written into the cached document, even if the
     agent possesses credentials for the service.

     When the "auth.type" is "none", the service provider asserts that no
     authentication is required.  Service providers MUST NOT use "none"
     for endpoints that handle sensitive data, perform write operations,
     or incur costs.

  6.3.  Abuse by Automated Agents

     The AI Discovery Document facilitates automated interaction with web
     services.  This creates a potential vector for abuse, including:

     *  Automated enumeration of capabilities across many services for
        reconnaissance purposes.

     *  Rapid, programmatic invocation of capabilities at scale,
        potentially exceeding the service's intended usage patterns.

     *  Exploitation of capabilities that were not designed with automated
        consumption in mind.



  Choi                    Expires 24 September 2026              [Page 15]


  Internet-Draft            AI Discovery Endpoint               March 2026


     Service providers MUST implement appropriate rate limiting on all
     capability endpoints exposed through the AI Discovery Document.
     Service providers MUST NOT rely solely on agents' voluntary
     compliance with advertised rate limits.

     Service providers SHOULD monitor traffic patterns to capability
     endpoints and implement anomaly detection for automated abuse.

  6.4.  Content Integrity

     An AI agent that fetches an AI Discovery Document over an insecure
     channel risks receiving a modified or malicious document.  A tampered
     document could redirect the agent to attacker-controlled endpoints or
     alter parameter descriptions to induce the agent to send sensitive
     data to unauthorized parties.

     AI agents MUST fetch the AI Discovery Document over HTTPS (TLS)
     [RFC8446].  Agents MUST NOT fetch the document over plain HTTP.
     Service providers MUST serve the document over HTTPS.

     AI agents SHOULD validate TLS certificates according to [RFC6125] and
     MUST NOT proceed if certificate validation fails.

  6.5.  Denial of Service

     A malicious or misconfigured AI Discovery Document could describe a
     very large number of capabilities, extremely long description
     strings, or deeply nested parameter structures, causing excessive
     resource consumption in the parsing agent.

     AI agents SHOULD enforce the size limits described in Section 4.5 and
     SHOULD impose their own limits on the number of capabilities
     processed (RECOMMENDED: no more than 100 capabilities per document)
     and the length of individual string fields.

  7.  IANA Considerations

  7.1.  Well-Known URI Registration

     This document requests registration of the following well-known URI
     [RFC8615]:

     URI Suffix:  ai

     Change Controller:  IETF

     Specification Document(s):  This document




  Choi                    Expires 24 September 2026              [Page 16]


  Internet-Draft            AI Discovery Endpoint               March 2026


     Status:  provisional

     Related Information:  None

  8.  Examples

  8.1.  Minimal Conformant Response

     {
       "aiendpoint": "1.0",
       "service": {
         "name": "SimpleNotes",
         "description": "Create and retrieve plain text notes."
       },
       "capabilities": [
         {
           "id": "create_note",
           "description": "Create a new text note",
           "endpoint": "/api/notes",
           "method": "POST"
         },
         {
           "id": "list_notes",
           "description": "List all notes, newest first",
           "endpoint": "/api/notes",
           "method": "GET"
         }
       ]
     }

  8.2.  Full-Featured Response

     {
       "aiendpoint": "1.0",
       "service": {
         "name": "ExampleShop",
         "description": "Search and browse products.
           Supports keyword search, category filtering,
           and price sorting.",
         "category": ["ecommerce", "search"],
         "language": ["en", "ko"]
       },
       "capabilities": [
         {
           "id": "search_products",
           "description": "Search products by keyword",
           "endpoint": "/api/ai/products/search",
           "method": "GET",



  Choi                    Expires 24 September 2026              [Page 17]


  Internet-Draft            AI Discovery Endpoint               March 2026


           "params": {
             "q": "string, required -- search keyword",
             "category": "string, optional -- filter by category",
             "max_price": "number, optional -- max price in USD",
             "sort": "string, optional --
               price_asc|price_desc|relevance,
               default relevance",
             "limit": "integer, optional, default 10, max 50"
           },
           "returns": "products[] {id, name,
             price_usd, stock, category, url}"
         },
         {
           "id": "get_product",
           "description": "Get full details of a product by ID",
           "endpoint": "/api/ai/products/:id",
           "method": "GET",
           "params": {
             "id": "string, required -- product ID"
           },
           "returns": "product {id, name, description,
             price_usd, stock, images[], category, url}"
         }
       ],
       "auth": {
         "type": "apikey",
         "header": "X-API-Key",
         "docs": "https://exampleshop.com/docs/auth"
       },
       "token_hints": {
         "compact_mode": true,
         "field_filtering": true,
         "delta_support": false
       },
       "rate_limits": {
         "requests_per_minute": 60,
         "agent_tier_available": true
       },
       "meta": {
         "last_updated": "2026-03-10",
         "changelog": "https://exampleshop.com/changelog",
         "status": "https://status.exampleshop.com"
       }
     }

  8.3.  Service with No Authentication





  Choi                    Expires 24 September 2026              [Page 18]


  Internet-Draft            AI Discovery Endpoint               March 2026


     {
       "aiendpoint": "1.0",
       "service": {
         "name": "WorldWeather",
         "description": "Current weather and 5-day
           forecasts for cities worldwide.",
         "category": ["weather", "data"],
         "language": ["en"]
       },
       "capabilities": [
         {
           "id": "current_weather",
           "description": "Get current weather for a city",
           "endpoint": "/api/weather/current",
           "method": "GET",
           "params": {
             "city": "string, required -- city name",
             "units": "string, optional --
               metric|imperial, default metric"
           },
           "returns": "city {name, country}, condition,
             temp, humidity_pct, wind_speed, updated_at"
         },
         {
           "id": "forecast",
           "description": "Get 5-day weather forecast for a city",
           "endpoint": "/api/weather/forecast",
           "method": "GET",
           "params": {
             "city": "string, required -- city name",
             "days": "integer, optional, default 5, max 5",
             "units": "string, optional --
               metric|imperial, default metric"
           },
           "returns": "city {name, country},
             forecast[] {date, condition, temp_high,
             temp_low, precipitation_pct}"
         }
       ],
       "auth": {
         "type": "none"
       },
       "token_hints": {
         "compact_mode": false,
         "field_filtering": true,
         "delta_support": true
       },
       "rate_limits": {



  Choi                    Expires 24 September 2026              [Page 19]


  Internet-Draft            AI Discovery Endpoint               March 2026


         "requests_per_minute": 100,
         "agent_tier_available": false
       },
       "meta": {
         "last_updated": "2026-03-15"
       }
     }

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

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

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

     [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
                Verification of Domain-Based Application Service Identity
                within Internet Public Key Infrastructure Using X.509
                (PKIX) Certificates in the Context of Transport Layer
                Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
                2011, <https://www.rfc-editor.org/info/rfc6125>.

     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/info/rfc6750>.

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







  Choi                    Expires 24 September 2026              [Page 20]


  Internet-Draft            AI Discovery Endpoint               March 2026


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

     [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
                Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
                <https://www.rfc-editor.org/info/rfc8446>.

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

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

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

  9.2.  Informative References

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/info/rfc9309>.

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

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

     [LLMSTXT]  Willison, S., "llms.txt -- A Proposal", 2024,
                <https://llmstxt.org>.

  Appendix A.  Comparison with Existing Approaches










  Choi                    Expires 24 September 2026              [Page 21]


  Internet-Draft            AI Discovery Endpoint               March 2026


  A.1.  robots.txt (RFC 9309)

     robots.txt communicates access restrictions to web crawlers.  It
     answers the question "where should you NOT go?" but provides no
     information about what a service can do or how to interact with it
     programmatically.  The AI Discovery Endpoint is complementary: while
     robots.txt defines boundaries, the AI Discovery Endpoint defines
     capabilities within those boundaries.

  A.2.  OpenAPI / Swagger

     OpenAPI provides exhaustive, formal descriptions of REST APIs.  It is
     designed as a complete contract between API provider and consumer,
     typically running to thousands of lines for a non-trivial service.  A
     typical OpenAPI specification for a service with 10 endpoints
     consumes 5,000-20,000 tokens when processed by an LLM.  The
     equivalent AI Discovery Document consumes 300-800 tokens.

     The AI Discovery Endpoint does not replace OpenAPI.  A service MAY
     publish both, using the AI Discovery Document for initial capability
     discovery and linking to the OpenAPI specification for agents that
     require detailed contract information.

  A.3.  Model Context Protocol (MCP)

     MCP defines a runtime protocol for connecting AI agents to external
     tools and data sources.  It requires a dedicated server process, a
     custom transport layer, and framework-specific integration.  The AI
     Discovery Endpoint operates at a different layer: it is a static
     discovery mechanism with no runtime dependencies.  A service's AI
     Discovery Document can be used to automatically generate an MCP
     server configuration, making the two approaches complementary.

  A.4.  llms.txt

     llms.txt [LLMSTXT] proposes a convention for placing a plain text
     file at the root of a website containing a natural language summary
     for LLMs.  While simple to implement, it is unstructured, not
     machine-queryable, and does not describe invocable actions.  An LLM
     can read an llms.txt file to understand what a service is, but cannot
     determine from it how to programmatically interact with the service.










  Choi                    Expires 24 September 2026              [Page 22]


  Internet-Draft            AI Discovery Endpoint               March 2026


  A.5.  Summary

        +=====================+=========+=========+=======+==========+
        | Criterion           | /ai     | OpenAPI | MCP   | llms.txt |
        +=====================+=========+=========+=======+==========+
        | Discovery focus     | Yes     | No      | No    | Partial  |
        +---------------------+---------+---------+-------+----------+
        | Token efficient     | Yes     | No      | N/A   | Partial  |
        +---------------------+---------+---------+-------+----------+
        | Machine-queryable   | Yes     | Yes     | Yes   | No       |
        +---------------------+---------+---------+-------+----------+
        | Actions described   | Yes     | Yes     | Yes   | No       |
        +---------------------+---------+---------+-------+----------+
        | No infrastructure   | Yes     | Yes     | No    | Yes      |
        +---------------------+---------+---------+-------+----------+
        | Implementation time | <30 min | Hours   | Hours | <10 min  |
        +---------------------+---------+---------+-------+----------+

                                   Table 1

  Appendix B.  JSON Schema

     A formal JSON Schema (draft 2020-12) for the AI Discovery Document is
     maintained at:

     https://www.aiendpoint.dev/spec/v1/schema.json

     This schema provides machine-verifiable validation of AI Discovery
     Documents and is the normative reference for field types,
     constraints, and enumerated values defined in this specification.
     The schema is versioned in parallel with this specification; version
     "1.0" of the schema corresponds to this document.

  Appendix C.  Design Rationale

  C.1.  Why a Well-Known URI?

     The Well-Known URI mechanism [RFC8615] provides a standardized
     namespace for resources that need to be located without prior
     knowledge of a site's URL structure.  This is precisely the use case
     for AI agent discovery: an agent needs to find the AI Discovery
     Document given only the service's hostname.  The alternative --
     requiring services to register their AI Discovery Document location
     in a central registry -- would create a dependency on a third-party
     service and limit adoption.






  Choi                    Expires 24 September 2026              [Page 23]


  Internet-Draft            AI Discovery Endpoint               March 2026


  C.2.  Why JSON over Other Formats?

     JSON is the de facto standard for structured data exchange on the
     web.  Every mainstream programming language includes JSON parsing in
     its standard library.  Every LLM is trained on extensive JSON data
     and can parse it reliably.

     Alternatives considered:

     *  YAML: More human-readable but introduces parsing complexity and
        ambiguity.

     *  XML: More verbose, imposing higher token costs.

     *  Protocol Buffers / MessagePack: Efficient but not human-readable.

     *  Plain text (like llms.txt): Simple but unstructured, preventing
        reliable machine parsing.

  C.3.  Why Compact Parameter Descriptions?

     The decision to represent parameter descriptions as single-line
     strings (e.g., "string, required -- search keyword") rather than
     structured objects (as in OpenAPI's Parameter Object) was driven by
     token efficiency.  A structured representation requires approximately
     8-12 JSON tokens for structural elements alone.  The compact string
     format eliminates this overhead while remaining parseable by both
     humans and LLMs.

  C.4.  Why No Request/Response Examples?

     This specification deliberately omits examples from the discovery
     document for two reasons:

     1.  Token cost: Examples can easily double the size of a capability
         description without adding proportional informational value for
         an LLM, which can infer usage from parameter types and
         descriptions.

     2.  Maintenance burden: Examples that fall out of sync with the
         actual API behavior are worse than no examples, as they cause
         agents to generate incorrect requests.









  Choi                    Expires 24 September 2026              [Page 24]


  Internet-Draft            AI Discovery Endpoint               March 2026


  Acknowledgements

     The design of this specification was informed by the long history of
     web standards that enable automated interaction with web resources,
     including the Robots Exclusion Protocol [RFC9309], the Sitemaps
     protocol, the OpenAPI Specification [OPENAPI], and the Model Context
     Protocol [MCP].

     The authors thank the early adopters and contributors to the
     AIEndpoint open-source project for their feedback on the
     specification design.

  Author's Address

     Yeongjae Choi
     AIEndpoint
     Email: bejoyfuuul@gmail.com
     URI:   https://www.aiendpoint.dev

































  Choi                    Expires 24 September 2026              [Page 25]


name: draft-song-anp-ans
rev: 00
title: Agent Name System (ANS)
time: 2026-03-25T09:52:35Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-26T09:52:35Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Agent discovery/reg"]
tags: []
fetched_at: 2026-05-22T09:24:48.589044+00:00
source: ietf
abstract:
  This document defines the Agent Name System (ANS), a name
     registration and resolution protocol for autonomous AI agents in the
     Agent Network Protocol (ANP) suite.  ANS maps agent:// URIs to
     network-layer peer identifiers, providing the binding between human-
     readable agent names and the cryptographic peer identities used by
     the Agent Internet Protocol (AIP) for datagram delivery.

     ANS defines a Name Record format, four AITP method names for name
     operations (ans.register, ans.resolve, ans.unregister, ans.lookup), a
     multi-layer resolution algorithm, and two dissemination mechanisms
     (GossipSub announcements and DHT storage).  ANS supports three
     addressing modes — unicast, anycast, and channel — over a single URI
     syntax.

     ANS is intentionally a narrow name-binding layer: it maps names to
     peers and tags, but defers capability description to the Agent
     Description Protocol (ADP), reputation and ranking to companion
     protocols, and economic anti-spam mechanisms to deployment profiles.

full_text:
  Independent Submission                                           J. Song
  Internet-Draft                                                     HKUST
  Intended status: Experimental                                    M. Yuan
  Expires: 26 September 2026                                          CUHK
                                                             25 March 2026


                          Agent Name System (ANS)
                           draft-song-anp-ans-00

  Abstract

     This document defines the Agent Name System (ANS), a name
     registration and resolution protocol for autonomous AI agents in the
     Agent Network Protocol (ANP) suite.  ANS maps agent:// URIs to
     network-layer peer identifiers, providing the binding between human-
     readable agent names and the cryptographic peer identities used by
     the Agent Internet Protocol (AIP) for datagram delivery.

     ANS defines a Name Record format, four AITP method names for name
     operations (ans.register, ans.resolve, ans.unregister, ans.lookup), a
     multi-layer resolution algorithm, and two dissemination mechanisms
     (GossipSub announcements and DHT storage).  ANS supports three
     addressing modes — unicast, anycast, and channel — over a single URI
     syntax.

     ANS is intentionally a narrow name-binding layer: it maps names to
     peers and tags, but defers capability description to the Agent
     Description Protocol (ADP), reputation and ranking to companion
     protocols, and economic anti-spam mechanisms to deployment profiles.

  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 26 September 2026.




  Song & Yuan             Expires 26 September 2026               [Page 1]


  Internet-Draft                     ANS                        March 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.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Positioning . . . . . . . . . . . . . . . . . . . . . . .   5
       1.4.  Design Rationale  . . . . . . . . . . . . . . . . . . . .   5
       1.5.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   6
       1.6.  Relationship to Adjacent Specifications . . . . . . . . .   6
       1.7.  Requirements Language . . . . . . . . . . . . . . . . . .   7
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  agent:// URI Syntax . . . . . . . . . . . . . . . . . . . . .   8
       3.1.  ABNF Grammar  . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Addressing Modes  . . . . . . . . . . . . . . . . . . . .   9
       3.3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   9
       3.4.  Normalization . . . . . . . . . . . . . . . . . . . . . .  10
     4.  Name Record . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  Record Fields . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.  Signature Computation . . . . . . . . . . . . . . . . . .  12
       4.3.  Sequence Numbers  . . . . . . . . . . . . . . . . . . . .  13
       4.4.  Extension Mechanism . . . . . . . . . . . . . . . . . . .  13
       4.5.  Validation Rules  . . . . . . . . . . . . . . . . . . . .  14
     5.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .  16
       5.1.  ans.register — Register a Name  . . . . . . . . . . . . .  16
       5.2.  ans.resolve — Resolve a Name  . . . . . . . . . . . . . .  17
       5.3.  ans.unregister — Remove a Name  . . . . . . . . . . . . .  17
       5.4.  ans.lookup — Tag-Based Name Lookup  . . . . . . . . . . .  18
       5.5.  Method Summary  . . . . . . . . . . . . . . . . . . . . .  19
     6.  Error Handling  . . . . . . . . . . . . . . . . . . . . . . .  19
       6.1.  Error Detail Envelope . . . . . . . . . . . . . . . . . .  19
       6.2.  ANS Error Codes . . . . . . . . . . . . . . . . . . . . .  20
     7.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  21
       7.1.  Resolution Algorithm  . . . . . . . . . . . . . . . . . .  21
       7.2.  Unicast Resolution  . . . . . . . . . . . . . . . . . . .  22
       7.3.  Anycast Resolution  . . . . . . . . . . . . . . . . . . .  22
       7.4.  Channel Resolution  . . . . . . . . . . . . . . . . . . .  22
       7.5.  Cache Behavior  . . . . . . . . . . . . . . . . . . . . .  23



  Song & Yuan             Expires 26 September 2026               [Page 2]


  Internet-Draft                     ANS                        March 2026


     8.  Dissemination . . . . . . . . . . . . . . . . . . . . . . . .  23
       8.1.  GossipSub Announcements . . . . . . . . . . . . . . . . .  23
         8.1.1.  Message Format  . . . . . . . . . . . . . . . . . . .  23
         8.1.2.  Receiver Validation . . . . . . . . . . . . . . . . .  24
       8.2.  DHT Storage . . . . . . . . . . . . . . . . . . . . . . .  24
         8.2.1.  Related DHT Namespaces  . . . . . . . . . . . . . . .  24
       8.3.  Peer-Assisted Resolution  . . . . . . . . . . . . . . . .  25
     9.  Name Lifecycle  . . . . . . . . . . . . . . . . . . . . . . .  25
       9.1.  Registration  . . . . . . . . . . . . . . . . . . . . . .  25
       9.2.  Freshness and TTL . . . . . . . . . . . . . . . . . . . .  26
       9.3.  Renewal . . . . . . . . . . . . . . . . . . . . . . . . .  26
       9.4.  Ownership and Transfer  . . . . . . . . . . . . . . . . .  26
       9.5.  Expiration and Release  . . . . . . . . . . . . . . . . .  27
     10. Security Considerations . . . . . . . . . . . . . . . . . . .  27
       10.1.  Name Spoofing  . . . . . . . . . . . . . . . . . . . . .  27
       10.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  27
       10.3.  Name Squatting . . . . . . . . . . . . . . . . . . . . .  27
       10.4.  GossipSub Flooding . . . . . . . . . . . . . . . . . . .  28
       10.5.  DHT Poisoning  . . . . . . . . . . . . . . . . . . . . .  28
       10.6.  Name Enumeration . . . . . . . . . . . . . . . . . . . .  28
       10.7.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . .  28
     11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  28
       11.1.  URI Scheme . . . . . . . . . . . . . . . . . . . . . . .  28
       11.2.  ANS Error Codes  . . . . . . . . . . . . . . . . . . . .  29
       11.3.  AITP Method Names  . . . . . . . . . . . . . . . . . . .  29
     12. Implementation Status . . . . . . . . . . . . . . . . . . . .  29
       12.1.  ClawNet  . . . . . . . . . . . . . . . . . . . . . . . .  29
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  30
       13.2.  Informative References . . . . . . . . . . . . . . . . .  31
     Appendix A.  Web-Native Discovery Profile (Informative) . . . . .  32
       A.1.  DNS-SD (RFC 6763) . . . . . . . . . . . . . . . . . . . .  32
       A.2.  Well-Known URI (RFC 8615) . . . . . . . . . . . . . . . .  32
       A.3.  Local Discovery (mDNS)  . . . . . . . . . . . . . . . . .  33
     Appendix B.  Implementation Alignment Notes . . . . . . . . . . .  33
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34

  1.  Introduction

  1.1.  Problem Statement

     Agents in a decentralized network need stable, human-readable names
     that can be resolved to the cryptographic peer identifiers used for
     datagram delivery.  The Agent Internet Protocol (AIP)
     [I-D.song-anp-aip] defines agent:// URIs as the addressing scheme for
     datagrams, but AIP itself does not specify how a name such as
     "agent://translator-zh-en" is bound to a particular peer or how that
     binding is disseminated across the network.



  Song & Yuan             Expires 26 September 2026               [Page 3]


  Internet-Draft                     ANS                        March 2026


     Without a name system, agents must exchange raw cryptographic peer
     identifiers — opaque strings that are neither memorable nor semantic.
     A name system provides the indirection layer that allows agent names
     to persist across peer-identity rotations, enables human operators to
     refer to agents by meaningful labels, and supports anycast routing
     where a single name resolves to the best available instance.

  1.2.  Scope

     This document is one of four core Internet-Drafts in the Agent
     Network Protocol (ANP) suite: AIP [I-D.song-anp-aip] (datagram
     delivery), AITP [I-D.song-anp-aitp] (invocation transport), ANS (this
     document, name system), and ADP [I-D.song-anp-adp] (description and
     discovery).  The four drafts are designed to co-evolve as a self-
     contained protocol suite; no additional specification is required for
     baseline interoperability.  AIP's local-resolver semantic extension
     MAY be backed by an implementation that consults ADP discovery
     services for ranked capability matching; ANS core provides name-to-
     peer binding but does not itself perform ranked semantic discovery.

     ANS is a name-layer protocol within the ANP suite.  It sits between
     the human-facing name space and the peer-identity layer used by AIP.

     This document specifies:

     1.  The agent:// URI syntax as used by ANS, refining the base grammar
         defined in AIP with namespace, version, and addressing-mode
         semantics.  AIP remains the scheme authority
         ([I-D.song-anp-aip]); ANS defines name-layer interpretation only.

     2.  The Name Record format — a JSON object that binds an agent://
         name to a peer identifier, skill tags, and temporal metadata.

     3.  Four AITP method names (ans.register, ans.resolve,
         ans.unregister, ans.lookup) for name operations over the Agent
         Invocation Transport Protocol (AITP) [I-D.song-anp-aitp].

     4.  A multi-layer resolution algorithm (local cache, persistent
         store, DHT, peer-assisted query).

     5.  Two dissemination mechanisms: GossipSub announcements for real-
         time propagation and DHT records for persistent storage.

     6.  The name lifecycle: registration, freshness, renewal, ownership,
         transfer, expiration, and release.

     This document does not cover:




  Song & Yuan             Expires 26 September 2026               [Page 4]


  Internet-Draft                     ANS                        March 2026


     1.  Agent capability description — specified by the Agent Description
         Protocol (ADP) [I-D.song-anp-adp].

     2.  Ranked capability discovery — the five-factor scoring algorithm
         is defined in ADP [I-D.song-anp-adp].

     3.  Economic mechanisms for name registration (token burn, auction,
         pricing) — these are deployment-specific policies.

     4.  DNS-based discovery (DNS-SD, well-known URIs) — discussed
         informatively in Appendix A.

     5.  Agent identity, key management, or credential issuance — these
         belong to AIP and deployment- context mechanisms.

  1.3.  Positioning

     ANS is to agent:// URIs what DNS is to domain names: a name-to-
     address resolution service.  ANS differs from DNS in three respects:
     (1) registrations are self-certified via Ed25519 signatures rather
     than delegated to registrars; (2) resolution is peer-to-peer (DHT +
     gossip) rather than hierarchical; (3) the name space supports anycast
     and channel addressing modes natively.  Of these three modes, only
     unicast and anycast names are registered; channel names are derived
     from the URI syntax and map deterministically to GossipSub topics
     without creating a Name Record (see Section 7.4).

     Unlike ADP's adp.discover, which ranks agents by a multi-factor
     scoring algorithm, ANS's ans.lookup performs tag-based filtering
     without scoring — a narrow-waist lookup analogous to DNS SRV queries.
     The two protocols are complementary: ANS provides name→peer binding;
     ADP provides capability→ranking.

  1.4.  Design Rationale

     ANS is justified when the following conditions hold:

     1.  *Agents need stable, human-readable identifiers.*

         Cryptographic peer IDs (e.g., 12D3KooW...) are unsuitable for
         human reference, configuration files, and documentation.  A name
         layer provides stability across peer-ID rotation.

     2.  *Multiple resolution paths improve availability.*

         A single DHT lookup may fail due to network partition.  A layered
         resolution stack (local cache → persistent store → DHT → peer-
         assisted RPC) maximizes the probability of successful resolution.



  Song & Yuan             Expires 26 September 2026               [Page 5]


  Internet-Draft                     ANS                        March 2026


     3.  *Anycast requires a name-to-set mapping.*

         When multiple instances serve the same logical service, the name
         system must resolve a single name to a set of candidates.
         Instance selection is then delegated to the caller or to a
         companion ranking protocol (ADP).

  1.5.  Assumptions

     ANS assumes:

     1.  An AIP module providing agent:// datagram delivery with
         Ed25519-signed peer identities.

     2.  An AITP module capable of REQUEST/RESPONSE exchanges with the
         method names defined in this document.

     3.  A GossipSub implementation supporting topic-based pub/sub (e.g.,
         libp2p GossipSub v1.1).

     4.  A Kademlia DHT implementation supporting namespace-prefixed key-
         value storage.

     5.  Name Record documents are UTF-8 encoded JSON ([RFC8259]).

  1.6.  Relationship to Adjacent Specifications

     ANS occupies a narrow role in the ANP suite.  This section clarifies
     the boundary between ANS and its sibling protocols to prevent
     misattribution of responsibilities.

     Agent Internet Protocol (AIP) [I-D.song-anp-aip]  AIP owns the
        agent:// URI scheme registration, the Ed25519 peer-identity model,
        and datagram delivery.  ANS consumes the URI scheme and peer
        identities defined by AIP; it does not redefine them.  The ABNF in
        Section 3.1 is a name-layer profile of the AIP base grammar,
        adding namespace, instance, and channel semantics for registration
        and resolution.  The agent:// URI scheme registration belongs to
        AIP, not ANS.

     Agent Invocation Transport Protocol (AITP) [I-D.song-anp-aitp]  AITP
        provides the reliable REQUEST/RESPONSE transport over which ANS
        method calls are carried.  AITP is a pure bearer: it provides
        segment framing, flow control, and status codes, but has no
        awareness of name semantics.  ANS defines its own method names
        (ans.*) and error detail bodies; AITP carries them unchanged.

     Agent Description Protocol (ADP) [I-D.song-anp-adp]  ADP defines



  Song & Yuan             Expires 26 September 2026               [Page 6]


  Internet-Draft                     ANS                        March 2026


        Agent Cards (rich capability descriptions) and the adp.discover
        method (five-factor ranked discovery).  ANS provides the narrower
        primitive: name-to-peer binding and tag-based lookup without
        scoring.  The two protocols are complementary — ANS resolves
        names, ADP ranks capabilities — and SHOULD be deployed together.

     Web-Native Discovery Profiles  DNS-SD ([RFC6763]), .well-known URIs
        ([RFC8615]), and mDNS ([RFC6762]) are informative bridging
        mechanisms described in Appendix A.  They are deployment profiles,
        not part of the ANS core protocol.  An ANS implementation is fully
        conformant without supporting any web- native discovery profile.

  1.7.  Requirements Language

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

  2.  Terminology

     Name Record  A JSON object that binds an agent:// name to a peer
        identifier, skill tags, and temporal metadata.  The Name Record is
        the unit of registration and resolution in ANS.

     Peer ID  The cryptographic identifier of a network node, derived from
        its Ed25519 public key.  Used by AIP for datagram routing.

     Namespace  An optional organizational prefix in an agent:// URI that
        groups related agent names (e.g., "nlp" in "agent://nlp/
        translator").

     Addressing Mode  One of three resolution semantics for an agent://
        URI: unicast (resolve to a specific instance), anycast (resolve to
        the best available instance of a service), or channel (map to a
        pub/sub topic for multicast delivery).

     Owner  The peer that first registered a Name Record.  Ownership is
        immutable: only the Owner may update or transfer the record.

     Sequence Number  A strictly monotonically increasing integer in a
        Name Record, used to order updates and prevent replay of stale
        records.







  Song & Yuan             Expires 26 September 2026               [Page 7]


  Internet-Draft                     ANS                        March 2026


  3.  agent:// URI Syntax

     The agent:// URI scheme identifies agents in the ANP network.  AIP
     [I-D.song-anp-aip] defines the base agent:// scheme and its core
     parsing rules.  This section defines the ANS-specific naming
     interpretation and constraints used for registration and resolution.
     AIP [I-D.song-anp-aip] is the scheme authority and defines the base
     agent:// syntax and wire encoding; the grammar below is a compatible
     profile that adds namespace, instance, version, and addressing-mode
     semantics on top of the AIP base grammar.

  3.1.  ABNF Grammar

     The following ABNF ([RFC5234]) defines the syntax of agent:// URIs.
     The grammar uses the core rules from [RFC5234] Appendix B and the
     generic URI components from [RFC3986].

     agent-uri     = "agent://" agent-path [ "@" version ]
     agent-path    = service-path / channel-path

     ; Service addressing (unicast or anycast)
     service-path  = [ namespace "/" ] name [ "/" instance ]

     ; Channel addressing (trailing "/" required)
     channel-path  = [ namespace "/" ] name "/"

     namespace     = identifier
     name          = identifier
     instance      = identifier
     version       = 1*( ALPHA / DIGIT / "." / "-" )

     identifier    = lo-alpha-digit *( lo-alpha-digit / "-" )
     lo-alpha-digit = %x61-7A / DIGIT   ; a-z / 0-9

     Constraints:

     *  Each "identifier" segment MUST be 1 to 63 octets.

     *  The total agent-path (excluding "agent://") MUST NOT exceed 255
        octets, matching the AIP MaxURILen.

     *  Identifiers MUST be lowercase ASCII letters, digits, and hyphens.
        Underscores are NOT RECOMMENDED; implementations MAY normalize
        underscores to hyphens on input.

     *  An identifier MUST NOT start or end with a hyphen.





  Song & Yuan             Expires 26 September 2026               [Page 8]


  Internet-Draft                     ANS                        March 2026


  3.2.  Addressing Modes

     An agent:// URI carries one of three addressing modes, determined by
     syntactic inspection of the path:

        +=========+====================+==============================+
        | Mode    | URI Pattern        | Resolution Semantics         |
        +=========+====================+==============================+
        | Unicast | agent://[ns/]name/ | Resolve to exactly one peer: |
        |         | instance           | the named instance.          |
        +---------+--------------------+------------------------------+
        | Anycast | agent://[ns/]name  | Resolve to one or more peers |
        |         |                    | registered under the service |
        |         |                    | name; the caller or a        |
        |         |                    | companion protocol selects   |
        |         |                    | among candidates.            |
        +---------+--------------------+------------------------------+
        | Channel | agent://[ns/]name/ | Map to a GossipSub topic;    |
        |         |                    | datagrams are delivered to   |
        |         |                    | all subscribers.  Channel    |
        |         |                    | names are derived, not       |
        |         |                    | registered — no Name Record  |
        |         |                    | is stored.  See Section 7.4. |
        +---------+--------------------+------------------------------+

                           Table 1: Addressing Modes

     Implementations MUST detect the addressing mode using the following
     algorithm:

     if path ends with "/"           → Channel
     else if path contains instance  → Unicast
     else                            → Anycast

     An agent:// URI with no namespace and no instance (e.g.,
     "agent://translator-zh-en") is Anycast.  This preserves backward
     compatibility with the flat names used by existing implementations.

  3.3.  Examples












  Song & Yuan             Expires 26 September 2026               [Page 9]


  Internet-Draft                     ANS                        March 2026


     # Anycast — route to any available translator
     agent://translator-zh-en

     # Anycast — namespace-scoped
     agent://nlp/translator

     # Unicast — specific instance
     agent://nlp/translator/zh-en-01

     # Unicast — versioned
     agent://nlp/translator/zh-en-01@1.2.0

     # Channel — multicast to all subscribers
     agent://finance/market-updates/

  3.4.  Normalization

     Implementations MUST normalize agent:// URIs before registration,
     resolution, and comparison by:

     1.  Converting the scheme and all identifier segments to lowercase.

     2.  Removing any trailing whitespace.

     The normalized form retains the "agent://" prefix.  Implementations
     that need a prefix-stripped key for DHT or database storage MAY
     derive it internally, but the canonical wire-format value is always
     the full URI.

     Two URIs are considered equal if their normalized forms are byte-
     identical.

  4.  Name Record

     A Name Record is a JSON object ([RFC8259]) that binds an agent://
     name to a network peer and its metadata.  Name Records are the unit
     of registration, dissemination, and resolution in ANS.

     The following structural rules apply to every Name Record:

     1.  A Name Record MUST be a single JSON object ([RFC8259]) encoded in
         UTF-8.

     2.  A Name Record MUST NOT contain duplicate member names.

     3.  A Name Record MUST NOT contain members outside this specification
         unless they are placed inside the "extensions" object (see
         Section 4.4).



  Song & Yuan             Expires 26 September 2026              [Page 10]


  Internet-Draft                     ANS                        March 2026


     4.  Implementations MUST ignore unknown top-level members for forward
         compatibility, but MUST preserve them when re-serializing the
         record (e.g., during gossip relay).

  4.1.  Record Fields

      +===============+=========+======+================================+
      | Field         | Type    | Req  | Description                    |
      +===============+=========+======+================================+
      | name          | string  | MUST | The complete agent:// URI,     |
      |               |         |      | including the scheme prefix.   |
      |               |         |      | E.g., "agent://nlp/translator" |
      |               |         |      | or "agent://translator-zh-en". |
      |               |         |      | Implementations that need a    |
      |               |         |      | prefix-stripped key for        |
      |               |         |      | storage or DHT lookups SHOULD  |
      |               |         |      | derive it internally; the      |
      |               |         |      | wire-format and object-model   |
      |               |         |      | value is always the full URI.  |
      +---------------+---------+------+--------------------------------+
      | peer_id       | string  | MUST | The registrant's cryptographic |
      |               |         |      | peer identifier, as used by    |
      |               |         |      | AIP for datagram routing.      |
      +---------------+---------+------+--------------------------------+
      | namespace     | string  | MAY  | The namespace segment          |
      |               |         |      | extracted from the name (e.g., |
      |               |         |      | "nlp").  Redundant with "name" |
      |               |         |      | but enables efficient          |
      |               |         |      | namespace-scoped queries.      |
      +---------------+---------+------+--------------------------------+
      | skills        | array   | MAY  | A JSON array of strings, each  |
      |               |         |      | a lowercase skill tag (e.g.,   |
      |               |         |      | ["translation","nlp"]).        |
      |               |         |      | Duplicate entries SHOULD be    |
      |               |         |      | removed on input.  Used for    |
      |               |         |      | tag-based lookup (ans.lookup). |
      +---------------+---------+------+--------------------------------+
      | description   | string  | MAY  | Free-text description of the   |
      |               |         |      | agent's purpose.  Used for     |
      |               |         |      | full-text search.              |
      +---------------+---------+------+--------------------------------+
      | version       | string  | MAY  | Semantic version string of the |
      |               |         |      | agent's capability set (e.g.,  |
      |               |         |      | "1.2.0").                      |
      +---------------+---------+------+--------------------------------+
      | ttl           | integer | MAY  | Time-to-live in seconds.       |
      |               |         |      | Default: 3600.  Consumers      |
      |               |         |      | SHOULD consider the record     |



  Song & Yuan             Expires 26 September 2026              [Page 11]


  Internet-Draft                     ANS                        March 2026


      |               |         |      | stale after this duration.     |
      +---------------+---------+------+--------------------------------+
      | registered_at | string  | MUST | Registration timestamp in RFC  |
      |               |         |      | 3339 format ([RFC3339]).       |
      +---------------+---------+------+--------------------------------+
      | expires_at    | string  | MUST | Expiration timestamp in RFC    |
      |               |         |      | 3339 format.  Records past     |
      |               |         |      | this time MUST be treated as   |
      |               |         |      | expired and SHOULD be removed  |
      |               |         |      | from caches.                   |
      +---------------+---------+------+--------------------------------+
      | owner_id      | string  | MUST | The peer_id of the first       |
      |               |         |      | registrant.  Immutable after   |
      |               |         |      | initial registration.  Only    |
      |               |         |      | the Owner may update or        |
      |               |         |      | transfer the record.           |
      +---------------+---------+------+--------------------------------+
      | seq           | integer | MUST | Monotonically increasing       |
      |               |         |      | sequence number.  Receivers    |
      |               |         |      | MUST reject records with a seq |
      |               |         |      | value less than or equal to    |
      |               |         |      | the locally stored seq for the |
      |               |         |      | same name.  See Section 4.3.   |
      +---------------+---------+------+--------------------------------+
      | signature     | string  | MUST | Ed25519 signature ([RFC8032])  |
      |               |         |      | over the canonical record      |
      |               |         |      | bytes.  See Section 4.2.       |
      |               |         |      | Encoded as unpadded Base64url  |
      |               |         |      | ([RFC4648] §5).                |
      +---------------+---------+------+--------------------------------+
      | extensions    | object  | MAY  | A JSON object carrying         |
      |               |         |      | deployment-specific extension  |
      |               |         |      | data.  See Section 4.4.        |
      +---------------+---------+------+--------------------------------+

                          Table 2: Name Record Fields

  4.2.  Signature Computation

     The signature field authenticates the Name Record and binds it to the
     registrant's Ed25519 key pair.  The signature is computed as follows:

     1.  Construct the signing input by concatenating the following fields
         in order, each encoded as UTF-8 with a newline (0x0A) separator:
         name, peer_id, namespace, skills (JSON-serialized array, e.g.,
         '["nlp","translation"]'; empty array '[]' if absent),
         description, version, ttl (decimal string), registered_at,
         expires_at, owner_id, seq (decimal string).



  Song & Yuan             Expires 26 September 2026              [Page 12]


  Internet-Draft                     ANS                        March 2026


     2.  Compute the Ed25519 signature ([RFC8032]) over the signing input
         using the registrant's private key.

     3.  Encode the 64-byte signature as unpadded Base64url ([RFC4648]
         §5).

     Receivers MUST verify the signature before accepting a Name Record.
     Verification requires the Ed25519 public key corresponding to the
     peer_id.  Implementations MUST reject records whose signature does
     not verify, whose peer_id does not correspond to the signing key, or
     whose owner_id does not match the peer_id (for initial registrations)
     or the stored owner_id (for updates).

  4.3.  Sequence Numbers

     The seq field provides replay protection and consistent ordering of
     Name Record updates.

     *  The initial registration MUST set seq to 1.

     *  Each subsequent update MUST increment seq by at least 1.

     *  Receivers MUST reject a record if its seq is less than or equal to
        the seq of the currently stored record for the same name.

     *  Receivers MUST reject a record if the seq value is unreasonably
        large (implementation-defined threshold) to prevent seq-space
        exhaustion attacks.

  4.4.  Extension Mechanism

     The "extensions" field provides a stable mounting point for
     deployment-specific data that does not belong in the core Name
     Record.  Examples include anti-spam proof tokens, pricing metadata,
     transfer receipts, and deployment-policy hints.

     *  The value of "extensions" MUST be a JSON object.

     *  Each key within "extensions" SHOULD be a reverse-domain or URN-
        namespaced identifier to avoid collisions (e.g.,
        "com.example.antispam").

     *  Implementations MUST preserve extension entries they do not
        understand when re-serializing or relaying a Name Record.

     *  Implementations MUST ignore extension entries they do not
        understand when processing a Name Record.




  Song & Yuan             Expires 26 September 2026              [Page 13]


  Internet-Draft                     ANS                        March 2026


     *  The "extensions" object is excluded from the signature computation
        (Section 4.2).  This is an intentional design trade-off: the core
        name-binding fields (name, peer_id, owner_id, seq, timestamps) are
        signed and tamper-evident — these fields fully cover the name-to-
        identity binding and temporal validity, so core record integrity
        does not depend on extensions.  Extensions are left unsigned to
        allow deployment-local annotations and relay-added metadata (e.g.,
        hop count, ingestion timestamp) that the originator cannot predict
        at signing time.

        Consequently, any peer on the relay path may add, modify, or
        remove extension entries.  Deployment profiles that require
        stronger integrity for specific extensions SHOULD define an inner
        signature field within their own extension namespace.

  4.5.  Validation Rules

     Implementations MUST validate Name Records on receipt, whether from
     ans.register requests, GossipSub messages, or DHT retrieval.  The
     following rules apply:































  Song & Yuan             Expires 26 September 2026              [Page 14]


  Internet-Draft                     ANS                        March 2026


        +========+===========================================+========+
        | ID     | Rule                                      | Level  |
        +========+===========================================+========+
        | VAL-01 | "name" conforms to the agent:// ABNF      | MUST   |
        |        | (Section 3.1).                            |        |
        +--------+-------------------------------------------+--------+
        | VAL-02 | "peer_id" is non-empty and is a           | MUST   |
        |        | syntactically valid peer identifier.      |        |
        +--------+-------------------------------------------+--------+
        | VAL-03 | "owner_id" is non-empty.  For initial     | MUST   |
        |        | registrations, owner_id = peer_id.  For   |        |
        |        | updates, owner_id matches the stored      |        |
        |        | value.                                    |        |
        +--------+-------------------------------------------+--------+
        | VAL-04 | "expires_at" is strictly after            | MUST   |
        |        | "registered_at", and "expires_at" is in   |        |
        |        | the future at time of receipt.            |        |
        +--------+-------------------------------------------+--------+
        | VAL-05 | "ttl" is a positive integer (> 0).        | MUST   |
        |        | Default 3600 if absent.                   |        |
        +--------+-------------------------------------------+--------+
        | VAL-06 | "seq" is an integer >= 1.  For updates,   | MUST   |
        |        | seq is strictly greater than the stored   |        |
        |        | seq.                                      |        |
        +--------+-------------------------------------------+--------+
        | VAL-07 | "skills" entries are unique, lowercase    | SHOULD |
        |        | strings.  Duplicates are removed          |        |
        |        | silently.                                 |        |
        +--------+-------------------------------------------+--------+
        | VAL-08 | "namespace", if present, matches the      | MUST   |
        |        | namespace segment extracted from "name".  |        |
        +--------+-------------------------------------------+--------+
        | VAL-09 | "signature" verifies per Section 4.2.     | MUST   |
        +--------+-------------------------------------------+--------+
        | VAL-10 | The addressing mode implied by "name" is  | MUST   |
        |        | consistent with the operation context.    |        |
        |        | Channel names (trailing "/") are derived, |        |
        |        | not registered, and MUST NOT be submitted |        |
        |        | to ans.register (see Section 7.4).        |        |
        +--------+-------------------------------------------+--------+

                     Table 3: Name Record Validation Rules

     Records that fail any MUST-level rule MUST be rejected.  Records that
     fail a SHOULD-level rule SHOULD be accepted after corrective
     normalization (e.g., deduplicating skills).





  Song & Yuan             Expires 26 September 2026              [Page 15]


  Internet-Draft                     ANS                        March 2026


  5.  Protocol Operations

     ANS defines four AITP method names for name operations.  Each method
     uses an AITP REQUEST/RESPONSE exchange; the request and response
     bodies are JSON objects.

  5.1.  ans.register — Register a Name

     An agent sends a REQUEST with Method = "ans.register" to bind an
     agent:// name to its peer identity.  Only Unicast and Anycast names
     may be registered; Channel names are derived from the URI syntax and
     MUST NOT be submitted to ans.register (see Section 7.4).

     Request body  A Name Record as defined in Section 4.  All MUST fields
        MUST be present.

     Response body (Status = OK)  A JSON object with the following fields:

        *  "registered": boolean — true if the record was accepted.

        *  "name": string — the normalized name.

        *  "seq": integer — the accepted sequence number.

        *  "expires_at": string — the accepted expiration timestamp.

     Error responses
        *  INVALID_REQUEST (6) — malformed record, invalid signature, or
           constraint violation (e.g., name syntax, field length).

        *  UNAUTHORIZED (5) — the sender is not the owner of an existing
           record with the same name.

        *  BUSY (8) — the receiver has reached its capacity for stored
           Name Records.

     The receiver MUST perform the following validation before accepting a
     registration:

     1.  Verify the agent:// name conforms to the ABNF in Section 3.1.

     2.  Verify the Ed25519 signature per Section 4.2.

     3.  If a record with the same name already exists, verify that the
         request's owner_id matches the stored owner_id and that the
         request's seq is strictly greater than the stored seq.

     4.  If no record exists, set the owner_id to the sender's peer_id.



  Song & Yuan             Expires 26 September 2026              [Page 16]


  Internet-Draft                     ANS                        March 2026


     5.  Verify that expires_at is in the future and that ttl is positive.

     Registration MAY additionally require a deployment-specific anti-spam
     mechanism such as proof-of-work, token expenditure, or rate limiting.
     Such mechanisms are outside the scope of this specification.

  5.2.  ans.resolve — Resolve a Name

     A caller sends a REQUEST with Method = "ans.resolve" to look up the
     Name Record(s) bound to an agent:// name.

     Request body  A JSON object with the following fields:

        *  "name": string (MUST) — the full agent:// URI to resolve.

     Response body (Status = OK)  A JSON object with a uniform envelope
        containing three fields:

        *  "mode": string (MUST) — one of "unicast", "anycast", or
           "channel".

        *  "records": array (MUST) — matching Name Records.  For Unicast:
           at most one element.  For Anycast: zero or more elements,
           ordered by seq descending.  For Channel: empty array.

        *  "topic": string or null (MUST) — the GossipSub topic string for
           Channel mode; null for Unicast and Anycast.

        *  "source": string (MAY) — when present, indicates the resolution
           layer that produced the result.  Values are drawn from: "local"
           (in-memory cache), "store" (persistent database), "dht"
           (Kademlia DHT), "peer" (peer-assisted RPC).  Omitted if
           unknown.

     Error responses  INVALID_REQUEST (6) if the name is malformed.

     If the receiver does not have the requested record in its local
     store, it MAY attempt resolution via the DHT or peer-assisted query
     before returning an empty records array.

  5.3.  ans.unregister — Remove a Name

     An agent sends a REQUEST with Method = "ans.unregister" to remove its
     Name Record.

     Request body  A JSON object with the following fields:

        *  "name": string (MUST) — the agent:// name to unregister.



  Song & Yuan             Expires 26 September 2026              [Page 17]


  Internet-Draft                     ANS                        March 2026


        *  "signature": string (MUST) — Ed25519 signature over the UTF-8
           string "unregister:" concatenated with the normalized name.

     Response body (Status = OK)  A JSON object: { "unregistered": true }.

     Error responses
        *  UNAUTHORIZED (5) — the sender is not the owner.

        *  INVALID_REQUEST (6) — invalid signature or name not found.

     The receiver MUST verify that the signature is valid and that the
     sender's peer_id matches the stored owner_id before removing the
     record.  Upon successful unregistration, the receiver SHOULD
     propagate the removal via GossipSub (see Section 8.1).

  5.4.  ans.lookup — Tag-Based Name Lookup

     A caller sends a REQUEST with Method = "ans.lookup" to find agents by
     skill tags.  Unlike ADP's adp.discover, ans.lookup is a narrow-waist
     filter: it returns all matching records without scoring or ranking.

     Request body  A JSON object with the following fields:

             +===========+==========+===============================+
             | Field     | Type     | Description                   |
             +===========+==========+===============================+
             | tags      | string[] | Skill tags to match (at least |
             |           |          | one SHOULD be provided).      |
             +-----------+----------+-------------------------------+
             | namespace | string   | Optional namespace filter.    |
             +-----------+----------+-------------------------------+
             | limit     | integer  | Maximum results.  Default:    |
             |           |          | 10.                           |
             +-----------+----------+-------------------------------+

                        Table 4: ans.lookup Request Fields

     Response body (Status = OK)  A JSON object with a "results" array.
        Each element contains:

        *  "record": the matching Name Record.

        *  "matched_tags": string[] — tags that contributed to the match.

     Error responses  INVALID_REQUEST (6) if the query is malformed.






  Song & Yuan             Expires 26 September 2026              [Page 18]


  Internet-Draft                     ANS                        March 2026


     A Name Record matches if at least one of the query tags appears in
     the record's skills array (after normalization).  Implementations
     SHOULD normalize tags to lowercase and apply alias resolution (e.g.,
     "py" → "python") before matching.

     When the total number of matching records exceeds the AIP maximum
     message size (65535 octets), implementations SHOULD truncate the
     result set to "limit" entries and return only complete records that
     fit within a single response datagram.  Callers that need additional
     results MAY issue subsequent queries with an "offset" parameter
     (application-level pagination) or use an AITP STREAM exchange for
     large result sets, as discussed in AITP [I-D.song-anp-aitp].

  5.5.  Method Summary

       +================+========================+=====================+
       | Method         | Direction              | Purpose             |
       +================+========================+=====================+
       | ans.register   | Agent → Peer/Directory | Bind a name to a    |
       |                |                        | peer identity       |
       +----------------+------------------------+---------------------+
       | ans.resolve    | Caller → Peer/         | Look up name → peer |
       |                | Directory              | binding             |
       +----------------+------------------------+---------------------+
       | ans.unregister | Agent → Peer/Directory | Remove a name       |
       |                |                        | binding             |
       +----------------+------------------------+---------------------+
       | ans.lookup     | Caller → Peer/         | Tag-based name      |
       |                | Directory              | filter (no ranking) |
       +----------------+------------------------+---------------------+

                           Table 5: ANS AITP Methods

  6.  Error Handling

     ANS methods reuse AITP status codes for transport-level outcome
     (e.g., OK, INVALID_REQUEST, UNAUTHORIZED).  In addition, ANS defines
     a structured error detail body that provides protocol-specific reason
     codes.

  6.1.  Error Detail Envelope

     When an ANS method returns an AITP error status, the response body
     SHOULD include the following JSON object:







  Song & Yuan             Expires 26 September 2026              [Page 19]


  Internet-Draft                     ANS                        March 2026


     {
       "code":   "ANS-1002",
       "title":  "invalid-signature",
       "detail": "Ed25519 signature verification failed for
                   name 'agent://nlp/translator'.",
       "name":   "agent://nlp/translator"
     }

     Fields:

     code  An ANS error code from Table 6.  MUST be present.

     title  A short, stable, machine-readable slug.  MUST be present.

     detail  A human-readable explanation.  MAY be present.

     name  The agent:// name that triggered the error, if applicable.  MAY
        be present.

  6.2.  ANS Error Codes

     +==========+===================+=================+==================+
     | Code     | Title             | AITP Status     | Meaning          |
     +==========+===================+=================+==================+
     | ANS-1001 | invalid-name      | INVALID_REQUEST | Name does not    |
     |          |                   |                 | conform to       |
     |          |                   |                 | agent:// ABNF.   |
     +----------+-------------------+-----------------+------------------+
     | ANS-1002 | invalid-signature | INVALID_REQUEST | Ed25519          |
     |          |                   |                 | signature        |
     |          |                   |                 | verification     |
     |          |                   |                 | failed.          |
     +----------+-------------------+-----------------+------------------+
     | ANS-1003 | owner-mismatch    | UNAUTHORIZED    | Sender's         |
     |          |                   |                 | peer_id does     |
     |          |                   |                 | not match the    |
     |          |                   |                 | stored           |
     |          |                   |                 | owner_id.        |
     +----------+-------------------+-----------------+------------------+
     | ANS-1004 | stale-seq         | INVALID_REQUEST | Record seq is    |
     |          |                   |                 | less than or     |
     |          |                   |                 | equal to the     |
     |          |                   |                 | stored seq.      |
     +----------+-------------------+-----------------+------------------+
     | ANS-1005 | expired-record    | INVALID_REQUEST | Record's         |
     |          |                   |                 | expires_at is    |
     |          |                   |                 | in the past.     |
     +----------+-------------------+-----------------+------------------+



  Song & Yuan             Expires 26 September 2026              [Page 20]


  Internet-Draft                     ANS                        March 2026


     | ANS-1006 | malformed-record  | INVALID_REQUEST | Record           |
     |          |                   |                 | violates         |
     |          |                   |                 | structural or    |
     |          |                   |                 | validation       |
     |          |                   |                 | rules            |
     |          |                   |                 | (Section 4.5).   |
     +----------+-------------------+-----------------+------------------+
     | ANS-1007 | unsupported-mode  | INVALID_REQUEST | Addressing       |
     |          |                   |                 | mode not         |
     |          |                   |                 | supported by     |
     |          |                   |                 | this operation   |
     |          |                   |                 | (e.g., channel   |
     |          |                   |                 | name in          |
     |          |                   |                 | ans.register).   |
     +----------+-------------------+-----------------+------------------+
     | ANS-1008 | capacity-exceeded | BUSY            | Receiver has     |
     |          |                   |                 | reached its      |
     |          |                   |                 | storage          |
     |          |                   |                 | capacity for     |
     |          |                   |                 | Name Records.    |
     +----------+-------------------+-----------------+------------------+
     | ANS-1009 | not-found         | INVALID_REQUEST | No record        |
     |          |                   |                 | exists for the   |
     |          |                   |                 | requested        |
     |          |                   |                 | name.            |
     +----------+-------------------+-----------------+------------------+

                        Table 6: ANS Error Code Registry

     AITP status codes provide the transport-level disposition (success,
     client error, server error).  ANS error codes provide the protocol-
     specific reason.  A receiver MUST set the AITP status code; it SHOULD
     include the ANS error detail body for non-OK responses.

  7.  Name Resolution

     Name resolution is the process of mapping an agent:// URI to one or
     more Name Records.  ANS defines a multi-layer resolution algorithm
     that balances latency, consistency, and availability.

  7.1.  Resolution Algorithm

     When resolving an agent:// URI, implementations SHOULD attempt the
     following layers in order, returning the first successful result:

     1.  *Layer 1 — Local Memory Cache.* Look up the normalized name in
         the in-memory Name Table (e.g., sync.Map).  If a non-expired
         record is found, return it.



  Song & Yuan             Expires 26 September 2026              [Page 21]


  Internet-Draft                     ANS                        March 2026


     2.  *Layer 2 — Persistent Store.* Query the local persistent store
         (e.g., SQLite) for a non-expired record.  If found, populate the
         L1 cache and return.

     3.  *Layer 3 — DHT.* Query the DHT at key "/clawnet-ans/{normalized-
         name}".  If a valid, non-expired record is found, store it in L2
         and L1 and return.

     4.  *Layer 4 — Peer-Assisted Query.* Send an ans.resolve request to
         connected peers in parallel.  Accept the first valid response.
         Store in L2 and L1.

     If all layers fail, the resolver returns a not-found result.

     Implementations MAY skip layers or query multiple layers in parallel
     to reduce latency.  The layer order above is RECOMMENDED for the
     common case.

  7.2.  Unicast Resolution

     A Unicast URI (agent://[ns/]name/instance) resolves to exactly one
     Name Record by exact-matching the full path
     "{namespace}/{name}/{instance}" or "{name}/{instance}".  If no exact
     match is found, the resolver returns not-found.

  7.3.  Anycast Resolution

     An Anycast URI (agent://[ns/]name) resolves to all non-expired Name
     Records whose name field matches the service name, either by exact
     match or by prefix match (all records sharing the same namespace and
     service segments).

     The resolver returns the full candidate set.  Instance selection is
     the caller's responsibility; callers MAY use ADP's ranked discovery
     (adp.discover) or any other selection strategy.

  7.4.  Channel Resolution

     Channel names are derived, not registered.  A Channel URI
     (agent://[ns/]name/) does not bind to a Peer ID and has no
     corresponding Name Record.  Instead, the resolver deterministically
     maps the channel name to a GossipSub topic string using the following
     rule:








  Song & Yuan             Expires 26 September 2026              [Page 22]


  Internet-Draft                     ANS                        March 2026


     topic = "/clawnet/channel/" + normalized-channel-path
             (strip trailing "/")

     Example:
       agent://finance/market-updates/
       → /clawnet/channel/finance/market-updates

     The resolver returns the topic string.  The AIP module delivers
     datagrams to this topic via GossipSub pub/sub.

  7.5.  Cache Behavior

     Resolved Name Records SHOULD be cached at both the memory layer (L1)
     and persistent layer (L2).  The cache entry MUST expire no later than
     the Name Record's expires_at timestamp.  Implementations SHOULD also
     re-resolve after the TTL period to obtain fresher records.

     When a GossipSub announcement updates or removes a cached name (see
     Section 8.1), implementations MUST update or invalidate the L1 and L2
     cache entries accordingly.

  8.  Dissemination

     ANS provides two complementary dissemination mechanisms for Name
     Records: GossipSub for real-time propagation and DHT for persistent,
     query-driven retrieval.

  8.1.  GossipSub Announcements

     Name registrations and unregistrations are announced via the
     GossipSub topic "/clawnet/ans".

  8.1.1.  Message Format

     Each GossipSub message on "/clawnet/ans" is a UTF-8 JSON object with
     the following fields:

     +========+========+================================================+
     | Field  | Type   | Description                                    |
     +========+========+================================================+
     | action | string | "register" or "unregister".                    |
     +--------+--------+------------------------------------------------+
     | record | object | The Name Record (for "register") or a partial  |
     |        |        | record containing at least "name", "owner_id", |
     |        |        | and "signature" (for "unregister").            |
     +--------+--------+------------------------------------------------+

                    Table 7: GossipSub ANS Message Fields



  Song & Yuan             Expires 26 September 2026              [Page 23]


  Internet-Draft                     ANS                        March 2026


  8.1.2.  Receiver Validation

     Upon receiving a GossipSub ANS message, the receiver MUST:

     1.  Verify the signature on the Name Record per Section 4.2.

     2.  For "register": verify that seq is strictly greater than the
         locally stored seq for the same name (or that no local record
         exists).  If valid, store or update the local cache and
         persistent store.

     3.  For "unregister": verify that the signature is valid and that the
         owner_id matches the stored record.  If valid, remove the record
         from the local cache and persistent store.

     4.  Silently drop messages that fail verification.  Implementations
         MUST NOT propagate invalid messages.

  8.2.  DHT Storage

     Name Records are stored in the Kademlia DHT under the namespace
     "clawnet-ans".  The DHT key for a Name Record is:

     key = "/clawnet-ans/" + normalized-name

     The DHT value is the UTF-8 JSON serialization of the Name Record.
     DHT put and get operations MUST validate the signature and sequence
     number using the same rules as GossipSub validation (Section 8.1.2).

     DHT implementations SHOULD set a record expiration aligned with the
     Name Record's expires_at field.  When a DHT get returns an expired
     record, the resolver MUST treat it as not found.

  8.2.1.  Related DHT Namespaces

     The ANP suite uses four DHT namespaces.  Only the ANS namespace is
     specified by this document; the others are documented here for cross-
     reference:













  Song & Yuan             Expires 26 September 2026              [Page 24]


  Internet-Draft                     ANS                        March 2026


     +===================+============================+=================+
     | Namespace         | Key Format                 | Purpose         |
     +===================+============================+=================+
     | /clawnet-ans/     | /clawnet-ans/{name}        | Name Records    |
     |                   |                            | (this document) |
     +-------------------+----------------------------+-----------------+
     | /clawnet-profile/ | /clawnet-profile/{peer_id} | Agent Cards     |
     |                   |                            | (ADP)           |
     +-------------------+----------------------------+-----------------+
     | /clawnet-rep/     | /clawnet-rep/{peer_id}     | Reputation      |
     |                   |                            | records         |
     +-------------------+----------------------------+-----------------+
     | /clawnet-txn/     | /clawnet-txn/{txn_id}      | Transaction     |
     |                   |                            | records         |
     +-------------------+----------------------------+-----------------+

                           Table 8: DHT Namespaces

  8.3.  Peer-Assisted Resolution

     When Layers 1-3 of the resolution algorithm fail, the resolver MAY
     send ans.resolve requests to currently connected peers in parallel.
     This is Layer 4 of the resolution stack.

     Implementations SHOULD apply the following constraints to peer-
     assisted resolution:

     *  A timeout of 5 seconds per peer query.

     *  Accept the first valid response (first-wins strategy).

     *  Limit fan-out to at most 5 concurrent peer queries to avoid
        network amplification.

     *  Validate the returned Name Record using the same signature and seq
        checks as other layers.

  9.  Name Lifecycle

  9.1.  Registration

     A name is registered by sending an ans.register request to one or
     more peers or directory agents.  Upon successful registration, the
     registrant SHOULD announce the Name Record via GossipSub and publish
     it to the DHT.






  Song & Yuan             Expires 26 September 2026              [Page 25]


  Internet-Draft                     ANS                        March 2026


     The initial registration sets owner_id = peer_id and seq = 1.  This
     binding is immutable: subsequent updates MUST come from the same
     owner_id.

  9.2.  Freshness and TTL

     The TTL field indicates how long a consumer should consider the
     record fresh after retrieval.  The expires_at field provides the
     absolute expiration boundary.

     Registrants SHOULD re-register (with incremented seq) before
     expires_at to maintain continuous name availability.  Periodic re-
     broadcast via GossipSub (e.g., every 5 minutes) helps ensure
     propagation to newly joined peers.

  9.3.  Renewal

     Renewal is a re-registration with the same name and owner_id, an
     incremented seq, and an updated expires_at.  The ans.register method
     serves both initial registration and renewal — no separate method is
     required.

     Deployment profiles MAY impose additional requirements for renewal
     (e.g., periodic payment, proof-of-work, activity checks).  Such
     requirements are outside the scope of this specification.

  9.4.  Ownership and Transfer

     Name ownership is established at first registration and is immutable.
     Only the Owner (identified by owner_id) may update or unregister a
     name.

     Because owner_id is immutable while peer_id is mutable, an Owner MAY
     update a Name Record to point to a different serving peer_id (e.g.,
     after key rotation or migration to a new host).  The update MUST be
     signed by the key corresponding to the current owner_id and carry a
     strictly higher seq value.  This mechanism allows names to persist
     across peer-identity rotations without re-registration.

     ANS does not define a transfer protocol at the AITP layer.
     Deployment profiles MAY define transfer mechanisms (e.g., dual-signed
     transfer messages) as extensions.  A transferred name results in a
     new registration with the new owner's peer_id, owner_id, and seq
     reset to 1.







  Song & Yuan             Expires 26 September 2026              [Page 26]


  Internet-Draft                     ANS                        March 2026


  9.5.  Expiration and Release

     A Name Record is expired when the current time is past its expires_at
     timestamp.  Expired records:

     *  MUST NOT be returned by ans.resolve or ans.lookup.

     *  SHOULD be removed from persistent stores during periodic garbage
        collection.

     *  SHOULD be removed from the DHT (or allowed to expire via DHT TTL).

     Once expired and removed, the name returns to the available pool and
     may be registered by any agent.  Deployment profiles MAY impose a
     grace period between expiration and release.

  10.  Security Considerations

  10.1.  Name Spoofing

     An adversary may attempt to register a Name Record for a name owned
     by another agent.  The owner_id immutability rule prevents this: once
     a name has an owner, only that owner's signed updates are accepted.
     Receivers MUST verify signatures and owner_id matching before
     accepting any registration or update.

  10.2.  Replay Attacks

     An adversary may replay an old Name Record to revert the name to
     stale state (e.g., a peer_id that the owner has since rotated).  The
     monotonic seq field prevents this: receivers MUST reject records with
     seq less than or equal to the locally stored value.

     To limit seq-space exhaustion, implementations SHOULD reject seq
     values that exceed the locally stored seq by more than a deployment-
     defined threshold (e.g., 1000).

  10.3.  Name Squatting

     An adversary may register many names to deny them to legitimate
     agents.  This document does not prescribe a specific mitigation;
     deployment profiles SHOULD employ at least one of:

     *  Proof-of-work: require computational effort before accepting
        ans.register.

     *  Token expenditure: require payment (e.g., Shell burn) proportional
        to name length or scarcity.



  Song & Yuan             Expires 26 September 2026              [Page 27]


  Internet-Draft                     ANS                        March 2026


     *  Rate limiting: limit the number of registrations per peer per time
        window.

     *  Activity requirements: expire names whose registrant has not been
        active for a deployment-defined period.

  10.4.  GossipSub Flooding

     An adversary may flood the "/clawnet/ans" topic with invalid or high-
     rate messages.  Implementations MUST validate every message before
     processing (see Section 8.1.2) and SHOULD apply per-peer message rate
     limiting.  GossipSub mesh scoring and peer scoring (as defined in
     GossipSub v1.1) provide additional protection against flooding.

  10.5.  DHT Poisoning

     An adversary may attempt to store malicious Name Records in the DHT.
     Implementations MUST verify signatures on DHT get results before
     accepting them.  Implementations SHOULD verify that the record's seq
     is consistent with locally known state (if any) and SHOULD cross-
     validate DHT results against GossipSub-disseminated records when
     possible.

  10.6.  Name Enumeration

     The ans.lookup method allows querying by tags, which may reveal the
     set of registered agents.  Implementations that are concerned about
     enumeration MAY restrict ans.lookup to authenticated peers or limit
     result sizes.

  10.7.  Privacy

     Name Records contain peer_id, skill tags, and description text, which
     reveal agent identity and capabilities.  Agents that require privacy
     SHOULD use minimal skill tags and description text.  Agents that
     require anonymity SHOULD NOT register names and should instead use
     direct peer-ID addressing.

  11.  IANA Considerations

  11.1.  URI Scheme

     ANS relies on the "agent" URI scheme defined by AIP
     [I-D.song-anp-aip].  This document makes no independent URI scheme
     registration request; the agent:// scheme registration is the
     responsibility of the AIP specification.





  Song & Yuan             Expires 26 September 2026              [Page 28]


  Internet-Draft                     ANS                        March 2026


  11.2.  ANS Error Codes

     The ANS error codes defined in Table 6 are protocol- internal
     identifiers within the ANP suite and are not drawn from IANA-managed
     registries.  Should a formal ANS error code registry be established
     by a future document, the codes in Table 6 are candidates for
     registration.

  11.3.  AITP Method Names

     The AITP method names (ans.register, ans.resolve, ans.unregister,
     ans.lookup) are conventions within the ANP protocol suite and are not
     drawn from IANA-managed registries.  Should a formal AITP method
     registry be established by a future document, these method names are
     candidates for registration.

  12.  Implementation Status

     Per [RFC7942], this section records known implementations.

  12.1.  ClawNet

     Organization  ChatChatTech

     URL  https://github.com/ChatChatTech/ClawNet

     Description  Go implementation of the ANP suite.  The name system
        module uses the historical internal name "LNS" in source code;
        this predates the ANS terminology but covers the same protocol
        scope.  All protocol-facing identifiers use agent://.

     Maturity  Alpha

     Coverage  Spec sections implemented:

        *  Name Record (§4): all 12 core fields, Ed25519 signature,
           monotonic seq, immutable owner_id

        *  Resolution (§7): 4-layer stack (memory, SQLite, DHT, peer-
           assisted RPC with first-wins strategy)

        *  Dissemination (§8): GossipSub register/unregister with
           signature validation; DHT namespace with Ed25519 validation

        *  Lifecycle (§9): registration, renewal, expiration, proof-of-
           work anti-spam





  Song & Yuan             Expires 26 September 2026              [Page 29]


  Internet-Draft                     ANS                        March 2026


        *  Lookup (§5.4): tag-based narrow-waist filter with alias
           normalization and standard tag vocabulary

        *  Full-text search via SQLite FTS5 (BM25) over name, namespace,
           skills, description

        Under integration:

        *  AITP method binding (§5) — currently REST-only; AITP segment
           framing in progress

        *  Wire-level topic and DHT namespace migration from /clawnet/lns
           to /clawnet/ans

        *  Channel addressing mode (§7.4) + derived topic mapping

        *  Uniform resolve envelope (§5.2) — currently returns single best
           match for anycast

        *  extensions field (§4.5) — not yet surfaced in record struct

        *  Validation rule table (§4.6) — rules enforced ad hoc;
           consolidated validation pass pending

     Language  Go

     License  Open source

     Contact  ink@chatchat.space

  13.  References

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

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




  Song & Yuan             Expires 26 September 2026              [Page 30]


  Internet-Draft                     ANS                        March 2026


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

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

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

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

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

     [I-D.song-anp-aip]
                Song, J., "Agent Internet Protocol (AIP)", Work in
                Progress, Internet-Draft, draft-song-anp-aip-01, March
                2026, <https://datatracker.ietf.org/doc/html/draft-song-
                anp-aip-01>.

     [I-D.song-anp-aitp]
                Song, J., "Agent Invocation Transport Protocol (AITP)",
                Work in Progress, Internet-Draft, draft-song-anp-aitp-00,
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                song-anp-aitp-00>.

  13.2.  Informative References

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

     [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
                DOI 10.17487/RFC6762, February 2013,
                <https://www.rfc-editor.org/info/rfc6762>.






  Song & Yuan             Expires 26 September 2026              [Page 31]


  Internet-Draft                     ANS                        March 2026


     [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
                Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
                <https://www.rfc-editor.org/info/rfc6763>.

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

     [I-D.song-anp-adp]
                Song, J., "Agent Description Protocol (ADP)", Work in
                Progress, Internet-Draft, draft-song-anp-adp-00, March
                2026, <https://datatracker.ietf.org/doc/html/draft-song-
                anp-adp-00>.

  Appendix A.  Web-Native Discovery Profile (Informative)

     This appendix describes how the agent:// name space can be bridged to
     web-native discovery mechanisms.  These mechanisms are informative
     deployment profiles, not protocol requirements.

  A.1.  DNS-SD (RFC 6763)

     An agent with a domain name may publish DNS SRV and TXT records for
     DNS-based Service Discovery ([RFC6763]):

     ; SRV record (RFC 2782)
     _clawnet._tcp.acme.com. IN SRV 0 0 4001 agent1.acme.com.

     ; TXT record (RFC 6763 §6)
     _clawnet._tcp.acme.com. IN TXT "peer=12D3KooW..."
                                     "agent=agent://acme/main"
                                     "skills=translation,nlp"

     Resolvers that support DNS-SD may query these records to bootstrap
     ANP connectivity with enterprise agents.

  A.2.  Well-Known URI (RFC 8615)

     An agent with an HTTPS domain may publish its Agent Card at a well-
     known URI:

     GET https://acme.com/.well-known/agent-card.json
     → 200 OK
     → Content-Type: application/json
     → { Agent Card JSON (ADP) }

     This enables web-based clients to discover ANP agents without
     participating in the P2P network.



  Song & Yuan             Expires 26 September 2026              [Page 32]


  Internet-Draft                     ANS                        March 2026


  A.3.  Local Discovery (mDNS)

     For LAN discovery, agents may publish mDNS ([RFC6762]) service
     records:

     _clawnet._tcp.local. IN SRV 0 0 4001 agent1.local.
     _clawnet._tcp.local. IN TXT "peer=12D3KooW..."
                                  "skills=translation,nlp"

  Appendix B.  Implementation Alignment Notes

     This appendix documents the relationship between this specification
     and the reference implementation in the ClawNet codebase.  Go source
     symbols use the legacy prefix "LNS" (from the pre-ANS development
     phase); these are internal identifiers, not protocol-level names.

     +===============+==========================+=======================+
     | Spec Concept  | Go Symbol / Location     | Notes                 |
     +===============+==========================+=======================+
     | Name Record   | lob.LNSRecord (lob-      | 12 fields mapping to  |
     |               | protocol/lns.go)         | ANS Name Record       |
     +---------------+--------------------------+-----------------------+
     | GossipSub     | lob.LNSGossipMessage     | action + record       |
     | Message       |                          | fields                |
     +---------------+--------------------------+-----------------------+
     | ANS Store     | lob.LNSStore (5 methods) | RegisterLNS,          |
     | Interface     |                          | ResolveLNS,           |
     |               |                          | DeleteLNS, SearchLNS, |
     |               |                          | ListLNS               |
     +---------------+--------------------------+-----------------------+
     | SQLite Store  | store.LNS* methods       | lns_records table +   |
     |               | (store/lns.go)           | lns_fts FTS5          |
     +---------------+--------------------------+-----------------------+
     | agent:// URI  | aip.ParseURI (aip/       | 2-segment: namespace/ |
     | Parser        | types.go)                | name@version          |
     +---------------+--------------------------+-----------------------+
     | Discovery     | lob.Discover (lob-       | 5-factor scoring (ADP |
     | Algorithm     | protocol/discovery.go)   | §6 alignment)         |
     +---------------+--------------------------+-----------------------+
     | Narrow-Waist  | lob.Lookup (lob-         | Tag-match only, no    |
     | Lookup        | protocol/discovery.go)   | scoring               |
     +---------------+--------------------------+-----------------------+
     | DHT Namespace | /clawnet-ans/{path}      | Kademlia DHT with     |
     |               |                          | Ed25519 validation;   |
     |               |                          | {path} is the prefix- |
     |               |                          | stripped key derived  |
     |               |                          | from the full URI.    |
     |               |                          | Implementation        |



  Song & Yuan             Expires 26 September 2026              [Page 33]


  Internet-Draft                     ANS                        March 2026


     |               |                          | currently uses legacy |
     |               |                          | /clawnet-lns/ prefix  |
     +---------------+--------------------------+-----------------------+
     | GossipSub     | /clawnet/ans             | Register/unregister   |
     | Topic         |                          | announcements         |
     +---------------+--------------------------+-----------------------+
     | REST API      | daemon.handleLNS*        | 14 endpoints on       |
     |               | (daemon/lns_rpc_api.go)  | localhost:3998        |
     +---------------+--------------------------+-----------------------+
     | CLI           | cli.LNS* (cli/lns.go)    | register, resolve,    |
     |               |                          | list, discover, alias |
     +---------------+--------------------------+-----------------------+
     | Standard Tags | discovery.StandardTags   | 20+ alias mappings    |
     |               | (60+ tags)               |                       |
     +---------------+--------------------------+-----------------------+
     | Proof-of-Work | daemon.handleLNSRegister | SHA256, ≥20 leading   |
     |               |                          | zero bits             |
     +---------------+--------------------------+-----------------------+
     | Peer-Assisted | daemon.handleLNSResolve  | Parallel RPC, 5s      |
     | Query         | (Layer 4)                | timeout, first-wins   |
     +---------------+--------------------------+-----------------------+

                     Table 9: Spec-Implementation Mapping

  Authors' Addresses

     Jinke Song
     Dept. of CSE, Hong Kong University of Science and Technology
     Email: ink@chatchat.space


     Mu Yuan
     Dept. of IE, The Chinese University of Hong Kong
     Email: muyuan@cuhk.edu.hk

















  Song & Yuan             Expires 26 September 2026              [Page 34]


name: draft-song-anp-aitp
rev: 00
title: Agent Invocation Transport Protocol (AITP)
time: 2026-03-25T09:53:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-26T09:53:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-05-22T09:24:48.589048+00:00
source: ietf
abstract:
  The Agent Internet Protocol (AIP) provides best-effort, name-based
     datagram delivery between autonomous AI agents identified by agent://
     URIs.  The Agent Invocation Transport Protocol (AITP) is a message-
     framed invocation and streaming transport above AIP.

     Unlike traditional host-to-host transports (TCP, QUIC) that operate
     on socket endpoints and byte streams, AITP is natively message-
     framed, method-aware, and association-aware: its header carries a
     method name as a first-class field, and its protocol data units are
     discrete requests, responses, stream chunks, and control segments
     exchanged between named agents.  AITP is not a byte-stream transport;
     it is an agent-native invocation and streaming transport that carries
     method names, request/response correlation, flow control, and session
     semantics natively in its header — so that upper-layer agent
     protocols need not reinvent them.  AITP intentionally includes a
     minimal generic invocation outcome space (four dispatch- level status
     codes); richer application semantics belong in the response body or
     upper-layer protocols.

     Unlike transport bindings that adapt existing agent protocols to
     HTTP, gRPC, or MOQT, AITP defines a common invocation substrate
     directly above AIP, with association state, request-concurrency flow
     control, and method-aware framing as first-class transport concerns.

     AITP is best understood as a common invocation substrate above AIP,
     not as a byte-stream transport analogue.

     This document specifies the AITP segment format, segment types,
     status codes, flag bits, TLV options, association state machine,
     reliability engine, flow control, circuit-breaker mechanism,
     streaming, orderly close and abort, and interfaces to AIP below and
     application protocols above.

full_text:
  Independent Submission                                           J. Song
  Internet-Draft                                                     HKUST
  Intended status: Experimental                                    M. Yuan
  Expires: 26 September 2026                                          CUHK
                                                             25 March 2026


                 Agent Invocation Transport Protocol (AITP)
                           draft-song-anp-aitp-00

  Abstract

     The Agent Internet Protocol (AIP) provides best-effort, name-based
     datagram delivery between autonomous AI agents identified by agent://
     URIs.  The Agent Invocation Transport Protocol (AITP) is a message-
     framed invocation and streaming transport above AIP.

     Unlike traditional host-to-host transports (TCP, QUIC) that operate
     on socket endpoints and byte streams, AITP is natively message-
     framed, method-aware, and association-aware: its header carries a
     method name as a first-class field, and its protocol data units are
     discrete requests, responses, stream chunks, and control segments
     exchanged between named agents.  AITP is not a byte-stream transport;
     it is an agent-native invocation and streaming transport that carries
     method names, request/response correlation, flow control, and session
     semantics natively in its header — so that upper-layer agent
     protocols need not reinvent them.  AITP intentionally includes a
     minimal generic invocation outcome space (four dispatch- level status
     codes); richer application semantics belong in the response body or
     upper-layer protocols.

     Unlike transport bindings that adapt existing agent protocols to
     HTTP, gRPC, or MOQT, AITP defines a common invocation substrate
     directly above AIP, with association state, request-concurrency flow
     control, and method-aware framing as first-class transport concerns.

     AITP is best understood as a common invocation substrate above AIP,
     not as a byte-stream transport analogue.

     This document specifies the AITP segment format, segment types,
     status codes, flag bits, TLV options, association state machine,
     reliability engine, flow control, circuit-breaker mechanism,
     streaming, orderly close and abort, and interfaces to AIP below and
     application protocols above.







  Song & Yuan             Expires 26 September 2026               [Page 1]


  Internet-Draft                    AITP                        March 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 26 September 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   4
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Relationship to Existing Transport Protocols  . . . . . .   6
         1.3.1.  Different Abstraction Objects . . . . . . . . . . . .   6
         1.3.2.  Message-Framed, Not Byte-Stream . . . . . . . . . . .   6
         1.3.3.  Complementary Layering  . . . . . . . . . . . . . . .   7
       1.4.  Positioning Among Agent Communication Approaches  . . . .   7
       1.5.  Interoperability Model  . . . . . . . . . . . . . . . . .   8
         1.5.1.  Minimum Endpoint Requirements . . . . . . . . . . . .   8
         1.5.2.  Two-Party Interoperability Conditions . . . . . . . .   8
         1.5.3.  Core versus Profile . . . . . . . . . . . . . . . . .   9
       1.6.  Design Rationale  . . . . . . . . . . . . . . . . . . . .   9
       1.7.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  10
       1.8.  Requirements Language . . . . . . . . . . . . . . . . . .  10
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  10
     3.  AITP Segment Format . . . . . . . . . . . . . . . . . . . . .  11
       3.1.  Header Structure  . . . . . . . . . . . . . . . . . . . .  11



  Song & Yuan             Expires 26 September 2026               [Page 2]


  Internet-Draft                    AITP                        March 2026


       3.2.  Field Definitions . . . . . . . . . . . . . . . . . . . .  12
       3.3.  TLV Options . . . . . . . . . . . . . . . . . . . . . . .  17
     4.  Association State Machine . . . . . . . . . . . . . . . . . .  19
       4.1.  Association States  . . . . . . . . . . . . . . . . . . .  19
       4.2.  State Transitions . . . . . . . . . . . . . . . . . . . .  19
       4.3.  Lazy Association Establishment  . . . . . . . . . . . . .  21
     5.  Reliability Engine  . . . . . . . . . . . . . . . . . . . . .  21
       5.1.  ACK Tracking  . . . . . . . . . . . . . . . . . . . . . .  21
       5.2.  Retransmission  . . . . . . . . . . . . . . . . . . . . .  22
       5.3.  Deduplication . . . . . . . . . . . . . . . . . . . . . .  22
     6.  Flow Control  . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.  Circuit Breaker . . . . . . . . . . . . . . . . . . . . . . .  23
       7.1.  Circuit Breaker Transitions . . . . . . . . . . . . . . .  23
       7.2.  Circuit Breaker Flag Bits . . . . . . . . . . . . . . . .  24
     8.  Streaming . . . . . . . . . . . . . . . . . . . . . . . . . .  24
       8.1.  Stream Lifecycle  . . . . . . . . . . . . . . . . . . . .  24
       8.2.  Back-Pressure . . . . . . . . . . . . . . . . . . . . . .  25
       8.3.  Large Payload Guidance  . . . . . . . . . . . . . . . . .  25
     9.  Segment Processing  . . . . . . . . . . . . . . . . . . . . .  25
       9.1.  Sending a Request . . . . . . . . . . . . . . . . . . . .  25
       9.2.  Receiving a Segment . . . . . . . . . . . . . . . . . . .  26
     10. Interfaces  . . . . . . . . . . . . . . . . . . . . . . . . .  27
       10.1.  Upper Layer Interface (Application Protocols)  . . . . .  27
       10.2.  Lower Layer Interface (AIP)  . . . . . . . . . . . . . .  28
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  28
       11.1.  Segment Authentication . . . . . . . . . . . . . . . . .  28
       11.2.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  29
       11.3.  Resource Exhaustion  . . . . . . . . . . . . . . . . . .  29
       11.4.  Method Authorization . . . . . . . . . . . . . . . . . .  29
       11.5.  Privacy  . . . . . . . . . . . . . . . . . . . . . . . .  29
       11.6.  Association State Attacks  . . . . . . . . . . . . . . .  29
       11.7.  Dispatch-Level Information Leakage . . . . . . . . . . .  30
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
       12.1.  AITP Segment Type Registry . . . . . . . . . . . . . . .  30
       12.2.  AITP Status Code Registry  . . . . . . . . . . . . . . .  30
       12.3.  AITP Flag Bits Registry  . . . . . . . . . . . . . . . .  30
       12.4.  AITP Option Type Registry  . . . . . . . . . . . . . . .  30
     13. Implementation Status . . . . . . . . . . . . . . . . . . . .  30
       13.1.  ClawNet  . . . . . . . . . . . . . . . . . . . . . . . .  30
     14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
       14.1.  Normative References . . . . . . . . . . . . . . . . . .  32
       14.2.  Informative References . . . . . . . . . . . . . . . . .  32
     Appendix A.  Implementation Alignment Notes . . . . . . . . . . .  32
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  34







  Song & Yuan             Expires 26 September 2026               [Page 3]


  Internet-Draft                    AITP                        March 2026


  1.  Introduction

  1.1.  Problem Statement

     AIP [I-D.song-anp-aip] provides a best-effort datagram service
     between agents identified by agent:// URIs: messages may be lost,
     duplicated, or reordered.  Agent applications -- remote procedure
     calls, streaming inference, multi-turn conversations -- require
     reliable delivery with request-response correlation.

     Existing host-to-host transports (TCP, QUIC) solve this problem for
     processes bound to IP addresses and ports.  They provide reliable
     byte streams or datagrams between network endpoints, but they have no
     notion of agent:// addressing, association semantics between named
     agents, or message-level request/response framing.  Using such
     transports directly forces every upper-layer agent protocol (task
     orchestration, knowledge replication, capability advertisement) to
     independently reinvent request IDs, timeouts, retransmission, flow
     control, and orderly close.

     AITP bridges this gap.  It is an agent-to-agent transport, not a
     host-to-host transport: its endpoints are agent:// URIs, its protocol
     data unit is a self-framed message (not a byte stream), and its
     association state tracks agent conversations rather than network
     connections.  AITP accepts AIP datagrams carrying Protocol = 1 and
     provides upper-layer protocols with synchronous invocation, fire-and-
     forget messaging, and bidirectional streaming, all mediated through
     per-agent association state with request-concurrency flow control
     (counted in outstanding requests, not bytes) and circuit-breaker
     fault isolation.

  1.2.  Scope

     This document is one of four core Internet-Drafts in the Agent
     Network Protocol (ANP) suite: AIP [I-D.song-anp-aip] (datagram
     delivery), AITP (this document, invocation transport), ANS
     [I-D.song-anp-ans] (name system), and ADP [I-D.song-anp-adp]
     (description and discovery).  The four drafts are designed to co-
     evolve as a self-contained protocol suite; no additional
     specification is required for baseline interoperability.  AIP's
     local-resolver semantic extension MAY be backed by an implementation
     that consults ADP discovery services for ranked capability matching;
     ANS core provides name-to-peer binding but does not itself perform
     ranked semantic discovery.

     AITP defines an experimental, lightweight invocation and streaming
     transport above AIP [I-D.song-anp-aip], intended for implementation
     and operational experimentation.



  Song & Yuan             Expires 26 September 2026               [Page 4]


  Internet-Draft                    AITP                        March 2026


     In one sentence: AIP delivers datagrams to agents; AITP provides a
     common invocation and streaming substrate on which those agents
     converse.

     AITP is responsible for:

     1.  Association lifecycle -- establish, maintain, orderly close, and
         abort.

     2.  Request/response exchange with correlation by Request ID.

     3.  Fire-and-forget one-way messaging (NOACK flag).

     4.  Bidirectional streaming with FIN-based termination.

     5.  Status codes for transport-level outcomes and minimal handler-
         dispatch outcomes needed for generic interoperability.

     6.  Retransmission with exponential-backoff timeout and deduplication
         of retransmitted requests.

     7.  Receiver-advertised flow control via the Window field.

     8.  Per-association circuit breaker for fault isolation.

     9.  Extensible TLV options for timeout, sequencing, timestamps,
         signatures, and metadata.

     AITP is NOT responsible for:

     1.  Naming, resolution, or agent discovery -- these belong to AIP and
         the Agent Name System (ANS).

     2.  Addressing and forwarding -- these belong to AIP.

     3.  End-to-end business semantics, task orchestration, or agent
         workflow -- these belong to upper-layer application protocols.

     4.  Economic settlement or credit systems.

     5.  Knowledge synchronisation or replication.

     6.  A general identity or authentication framework -- AITP provides
         optional segment-level signatures (SIGNED flag) and defers to AIP
         and deployment-context mechanisms for identity binding.

     7.  Payload confidentiality or end-to-end encryption -- these are
         application-layer responsibilities.



  Song & Yuan             Expires 26 September 2026               [Page 5]


  Internet-Draft                    AITP                        March 2026


     8.  Message fragmentation -- AITP relies on AIP's maximum message
         size (65535 octets).

     Accordingly, this document does not specify a complete agent runtime,
     workflow engine, business protocol family, or deployment profile; it
     defines only the common invocation and streaming substrate shared by
     such systems.

     Because AITP carries a Method name as a first-class header field and
     defines minimal handler-dispatch status codes, it is not a pure
     transport in the TCP/QUIC sense.  It is an agent-native invocation
     transport that unifies method dispatch, request/response correlation,
     retry, flow control, and session management into a shared substrate
     so that multiple upper-layer agent protocols (ADP, task
     orchestration, capability advertisement, knowledge sync, and future
     agent message families) need not independently reinvent these
     mechanics.  AITP is best understood as a common invocation substrate
     above AIP, rather than as a byte-stream transport analogue.

  1.3.  Relationship to Existing Transport Protocols

     A natural question is: "Why not use QUIC streams with gRPC, or libp2p
     streams with a custom RPC layer?"  This section explains why AITP
     occupies a distinct position in the protocol stack.

  1.3.1.  Different Abstraction Objects

     TCP and QUIC are host-to-host (or process-to-process) transports.
     Their endpoints are IP addresses and ports; their primary abstraction
     is the connection or stream between network endpoints.  They do not
     understand agent:// URIs, resolver-assisted delivery, or agent
     association semantics.

     AITP is an agent-to-agent transport.  Its endpoints are agent://
     URIs; its primary abstraction is the association between named
     agents.  An association carries not just connectivity state, but also
     request correlation, flow control windows counted in outstanding
     requests (not bytes), and a circuit breaker reflecting the remote
     agent's operational health -- concepts that have no direct
     counterpart in traditional transport protocols.

  1.3.2.  Message-Framed, Not Byte-Stream

     TCP provides an unstructured byte stream; applications must impose
     their own framing.  QUIC improves on this with multiple streams but
     remains byte-oriented within each stream.





  Song & Yuan             Expires 26 September 2026               [Page 6]


  Internet-Draft                    AITP                        March 2026


     AITP is natively message-framed.  Every segment is a self-contained
     protocol data unit with a typed header, request ID, method name,
     status code, and body.  The transport itself understands "this is a
     request", "this is a response", "this is a stream chunk", and "this
     is a control message" -- eliminating the need for upper-layer
     protocols to define their own framing and multiplexing.

  1.3.3.  Complementary Layering

     AITP does not compete with TCP or QUIC for the same layer.  The
     correct relationship is:

       Upper-layer protocols   ADP, task, knowledge, capability, ...
       ─────────────────────────────────────────────────────────────
       AITP                     agent-to-agent invocation & streaming
       ─────────────────────────────────────────────────────────────
       AIP                     agent:// datagram substrate
       ─────────────────────────────────────────────────────────────
       Link / Network          libp2p over TCP, QUIC, WebSocket, ...

     Traditional transports provide network reachability and basic
     reliable delivery at the link/network layer.  AIP provides agent-
     oriented, name-based datagram delivery above that.  AITP provides
     reliable invocation and streaming semantics above AIP.  Each layer
     has a distinct job; removing any one forces its responsibilities onto
     an adjacent layer.

     AITP does not replace lower-layer transports such as TCP or QUIC; it
     defines a reusable invocation substrate for agent://-addressed
     communication above AIP.

  1.4.  Positioning Among Agent Communication Approaches

     The preceding section distinguishes AITP from host-to-host
     transports.  This section clarifies its relationship to agent-
     oriented communication approaches that operate at different layers of
     the stack.

     Several agent protocol families (e.g., A2A) define application-level
     messaging semantics — task lifecycle, capability exchange, content
     negotiation — and then bind those semantics onto existing transports
     such as HTTP or gRPC.  AITP does not define application semantics.
     It occupies a lower position: a reusable invocation and streaming
     substrate above AIP, designed to be shared by multiple upper-layer
     agent protocols rather than serving one particular protocol family.






  Song & Yuan             Expires 26 September 2026               [Page 7]


  Internet-Draft                    AITP                        March 2026


     Client-server agent transports such as MCP's stdio and Streamable
     HTTP provide carriage for JSON-RPC exchanges between a client and a
     server, inheriting session and flow-control semantics from the
     underlying transport or runtime environment.  AITP targets symmetric
     agent-to-agent exchanges between agent://-identified endpoints;
     association state and request-concurrency control are defined within
     the protocol itself rather than inherited from an underlying HTTP or
     process-level session.

     Deployment platforms and runtime messaging fabrics may provide
     routing, streaming, or orchestration facilities for agents.  AITP
     does not attempt to standardize such systems.  It specifies a
     protocol-layer invocation substrate that can be implemented
     independently of any particular runtime while remaining reusable
     across agent-oriented application protocols built above AIP.

  1.5.  Interoperability Model

     This section summarizes the minimum requirements for implementing an
     AITP endpoint, achieving two-party interoperability, and
     distinguishing core protocol behaviour from optimization profiles.

  1.5.1.  Minimum Endpoint Requirements

     A conforming AITP endpoint requires:

     1.  An AIP module providing SEND and RECEIVE primitives with Protocol
         = 1.

     2.  An association table keyed by (localURI, remoteURI) that tracks
         lifecycle state, flow control window, and circuit-breaker state.

     3.  Request ID tracking for correlation and deduplication.

     4.  A method-dispatch surface capable of mapping Method values to
         local handlers.

  1.5.2.  Two-Party Interoperability Conditions

     Two implementations interoperate when they share:

     1.  The same AITP version (currently 1).

     2.  Agreed semantics for the flags, status codes, and option types
         they exchange.

     3.  Compatible compression and signature expectations, if the COMPR
         or SIGNED flags are used.



  Song & Yuan             Expires 26 September 2026               [Page 8]


  Internet-Draft                    AITP                        March 2026


  1.5.3.  Core versus Profile

     The following are optimization profiles or implementation choices,
     not core protocol requirements:

     *  Lazy association establishment (core baseline is the explicit INIT
        handshake).

     *  Compression algorithm selection (COMPR flag).

     *  Operational telemetry and monitoring counters.

     *  Deployment-specific defaults for window size, retransmission
        parameters, and circuit-breaker thresholds.

  1.6.  Design Rationale

     AITP is justified when the following conditions hold:

     1.  *Multiple upper-layer protocols share transport needs.*

         If ADP, task orchestration, knowledge sync, and capability
         advertisement each need method dispatch, request/response
         correlation, retransmission, timeout, request-concurrency flow
         control, and orderly close, factoring these into a shared
         invocation transport eliminates redundant specification and
         implementation.

     2.  *AIP remains a narrow waist.*

         If reliable delivery, association state, and request/response
         semantics were pushed down into AIP, AIP would lose its
         simplicity as a best-effort datagram layer.  AITP exists
         precisely so that AIP can stay thin.

     3.  *Agent-native addressing and conversation semantics are valued as
         an independent standard layer.*

         If a deployment is willing to fully delegate transport to an
         existing RPC framework (e.g., gRPC over QUIC), AITP is not
         required.  AITP is valuable when the community seeks a self-
         contained, agent-native invocation transport specification that
         does not depend on any specific lower-layer RPC stack.

     A practical test: if removing AITP would cause every upper-layer
     agent protocol to independently redefine method dispatch, request
     IDs, retry policies, timeout handling, flow control, and session
     close/abort, then AITP earns its place in the architecture.



  Song & Yuan             Expires 26 September 2026               [Page 9]


  Internet-Draft                    AITP                        March 2026


     Method is a first-class header field.  Upper-layer agent protocols
     rely on it for dispatch; AITP provides the invocation framing so that
     they do not each define their own.  This is what makes AITP an
     invocation substrate rather than a generic message bus, and is the
     primary reason its flow control counts outstanding requests rather
     than bytes.

     Because AITP is invocation-oriented rather than byte-stream-
     oriented, its flow control regulates concurrent outstanding requests
     admitted by the remote agent, not raw octet volume on the wire.

  1.7.  Assumptions

     AITP assumes:

     1.  An AIP module capable of sending and receiving datagrams with
         Protocol = 1.  AITP does not require any specific AIP
         implementation beyond the SEND/RECEIVE primitives defined in
         [I-D.song-anp-aip].

     2.  Agent:// URIs are stable identifiers for the duration of an
         association.  If an agent migrates, existing associations MAY be
         invalidated.

     3.  AITP MAY be used by companion upper-layer protocols such as
         capability advertisement (ADP), task orchestration, or knowledge
         synchronisation, but does not depend on any specific upper-layer
         protocol for baseline operation.

     4.  The receiving side exposes a method-dispatch surface capable of
         mapping Method values to local handlers.  AITP does not prescribe
         how such handlers are represented internally.

  1.8.  Requirements Language

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

  2.  Terminology

     Segment  The protocol data unit of AITP.  A self-contained unit
        carrying a fixed header, method name, TLV options, and body.
        Segments are carried as AIP datagram payloads with Protocol = 1.

     Association  A stateful transport-layer relationship between two



  Song & Yuan             Expires 26 September 2026              [Page 10]


  Internet-Draft                    AITP                        March 2026


        agents identified by their agent:// URIs.  An association tracks
        lifecycle state, flow control windows, and circuit-breaker state.

     Request ID  A 32-bit sender-assigned identifier used to correlate
        requests with responses and to detect duplicates.  Request IDs
        MUST be unique among outstanding requests within a single
        association.  A stream is a long-lived request context identified
        by its opening Request ID.

     Method  A UTF-8 string (up to 255 octets) identifying the operation
        to be invoked on the remote agent.  Method is a first-class header
        field; upper-layer protocols rely on it for dispatch without
        defining their own invocation framing.

     Flow Control Window  A 16-bit value advertised by the receiver
        indicating the maximum number of concurrent in-flight requests it
        is willing to accept from the sender.

     Circuit Breaker  A per-association fault-isolation mechanism that
        prevents sending requests to a peer that is experiencing
        persistent failures.

  3.  AITP Segment Format

     AITP segments are carried as AIP datagram payloads with Protocol = 1.
     A segment consists of a 16-octet fixed header, a variable-length
     method name (padded to a 4-octet boundary), a variable-length TLV
     options region (padded to a 4-octet boundary), and a variable-length
     body.

  3.1.  Header Structure




















  Song & Yuan             Expires 26 September 2026              [Page 11]


  Internet-Draft                    AITP                        March 2026


      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|  Type |    Status     |             Flags             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Request ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Body Length                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Method Len    |  Options Len  |            Window             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Method (UTF-8, padded to 4-octet boundary) ...        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Options (TLV, padded to 4-octet boundary) ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Body (variable)       ...                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Note: one tick mark represents one bit position.

                Figure 1: AITP Segment Header (16 octets fixed)

  3.2.  Field Definitions

     Version (4 bits)  Protocol version.  The current version is 1.
        Implementations MUST silently discard segments with an
        unrecognized version.

     Type (4 bits)  The segment type:






















  Song & Yuan             Expires 26 September 2026              [Page 12]


  Internet-Draft                    AITP                        March 2026


          +=======+==========+=========================================+
          | Value | Name     | Description                             |
          +=======+==========+=========================================+
          | 0     | REQUEST  | Invocation request.  Carries a method   |
          |       |          | name and request body.                  |
          +-------+----------+-----------------------------------------+
          | 1     | RESPONSE | Invocation response.  Carries a status  |
          |       |          | code and response body.                 |
          +-------+----------+-----------------------------------------+
          | 2     | STREAM   | Streaming data chunk.  Part of a        |
          |       |          | bidirectional stream identified by      |
          |       |          | Request ID.                             |
          +-------+----------+-----------------------------------------+
          | 3     | CONTROL  | Association lifecycle control.  Exactly |
          |       |          | one of INIT, FIN, or RST MUST be set;   |
          |       |          | invalid combinations MUST be rejected.  |
          +-------+----------+-----------------------------------------+
          | 4-15  |          | Reserved for future use.                |
          +-------+----------+-----------------------------------------+

                           Table 1: AITP Segment Types

        Implementations MUST silently discard segments with unrecognized
        Type values.

     Status (8 bits)  Result status code.  Primarily meaningful in
        RESPONSE segments; in REQUEST and STREAM segments this field
        SHOULD be set to 0 (OK).

        AITP status codes span two tiers.  Transport-processing codes
        (0-1, 3-4, 6, 9) reflect outcomes that any message-framed
        transport must report.  Handler-dispatch codes (2, 5, 7-8) report
        minimal method-invocation outcomes needed for generic
        interoperability; they allow a sender to distinguish "method not
        found" from "transport error" without requiring application-layer
        parsing.  Dispatch-level status codes are intentionally minimal
        and exist only to support generic upper-layer interoperability;
        richer application semantics belong in the response body or upper-
        layer protocols, not in the Status field.

         +========+==================+===========+=====================+
         | Value  | Name             | Tier      | Description         |
         +========+==================+===========+=====================+
         | 0      | OK               | Transport | Success.            |
         +--------+------------------+-----------+---------------------+
         | 1      | ERROR            | Transport | Generic error.      |
         +--------+------------------+-----------+---------------------+
         | 2      | NOT_FOUND        | Dispatch  | Method not          |



  Song & Yuan             Expires 26 September 2026              [Page 13]


  Internet-Draft                    AITP                        March 2026


         |        |                  |           | registered on the   |
         |        |                  |           | remote agent.       |
         +--------+------------------+-----------+---------------------+
         | 3      | TIMEOUT          | Transport | Request timed out   |
         |        |                  |           | (generated locally  |
         |        |                  |           | by the reliability  |
         |        |                  |           | engine).            |
         +--------+------------------+-----------+---------------------+
         | 4      | BUSY             | Transport | Remote agent is     |
         |        |                  |           | overloaded; retry   |
         |        |                  |           | later.              |
         +--------+------------------+-----------+---------------------+
         | 5      | UNAUTHORIZED     | Dispatch  | Caller lacks        |
         |        |                  |           | permission for the  |
         |        |                  |           | requested method.   |
         +--------+------------------+-----------+---------------------+
         | 6      | INVALID_REQUEST  | Transport | Malformed request   |
         |        |                  |           | (bad parameters,    |
         |        |                  |           | missing method,     |
         |        |                  |           | etc.).              |
         +--------+------------------+-----------+---------------------+
         | 7      | INTERNAL_ERROR   | Dispatch  | Unspecified         |
         |        |                  |           | internal processing |
         |        |                  |           | error on the remote |
         |        |                  |           | agent.              |
         +--------+------------------+-----------+---------------------+
         | 8      | NOT_IMPLEMENTED  | Dispatch  | Method recognized   |
         |        |                  |           | but not yet         |
         |        |                  |           | implemented.        |
         +--------+------------------+-----------+---------------------+
         | 9      | SERVICE_SHUTDOWN | Transport | Remote agent is     |
         |        |                  |           | shutting down       |
         |        |                  |           | gracefully.         |
         +--------+------------------+-----------+---------------------+
         | 10-255 |                  |           | Available for       |
         |        |                  |           | future assignment   |
         |        |                  |           | (IANA registry).    |
         +--------+------------------+-----------+---------------------+

                            Table 2: AITP Status Codes

        In summary, the four dispatch codes (NOT_FOUND, UNAUTHORIZED,
        INTERNAL_ERROR, NOT_IMPLEMENTED) form AITP's minimal generic
        invocation outcome space.  They exist so that any upper-layer
        protocol can interpret a basic method-dispatch result without
        parsing the response body.  These four outcomes are sufficient to
        distinguish transport success from basic invocation failure
        classes without committing AITP to any application-specific error



  Song & Yuan             Expires 26 September 2026              [Page 14]


  Internet-Draft                    AITP                        March 2026


        taxonomy; they support interoperable invocation behavior across
        heterogeneous upper-layer protocols without encoding business-
        level semantics.  Richer business semantics — task state, payment
        results, capability negotiation outcomes — MUST be carried in the
        response body or defined by upper-layer protocols, not encoded as
        AITP status codes.

     Flags (16 bits)  A bitmask of control flags:











































  Song & Yuan             Expires 26 September 2026              [Page 15]


  Internet-Draft                    AITP                        March 2026


          +======+========+========+==================================+
          | Bit  | Value  | Name   | Description                      |
          +======+========+========+==================================+
          | 0    | 0x0001 | ACK    | Acknowledgment.  Set in RESPONSE |
          |      |        |        | segments and CONTROL             |
          |      |        |        | acknowledgments.                 |
          +------+--------+--------+----------------------------------+
          | 1    | 0x0002 | FIN    | End of stream or association     |
          |      |        |        | close.  Signals graceful         |
          |      |        |        | termination.                     |
          +------+--------+--------+----------------------------------+
          | 2    | 0x0004 | INIT   | Association initialization       |
          |      |        |        | request.                         |
          +------+--------+--------+----------------------------------+
          | 3    | 0x0008 | RST    | Reset.  Immediately aborts the   |
          |      |        |        | association.                     |
          +------+--------+--------+----------------------------------+
          | 4    | 0x0010 | SEQ    | Sequence number present in       |
          |      |        |        | options (for ordered delivery    |
          |      |        |        | within a stream).                |
          +------+--------+--------+----------------------------------+
          | 5    | 0x0020 | NOACK  | No acknowledgment requested.     |
          |      |        |        | Used for fire-and-forget         |
          |      |        |        | semantics.                       |
          +------+--------+--------+----------------------------------+
          | 6    | 0x0040 | COMPR  | Body is compressed.  Compression |
          |      |        |        | algorithm is deployment-         |
          |      |        |        | specific.  Peers MUST either     |
          |      |        |        | agree on the compression format  |
          |      |        |        | out of band or reject compressed |
          |      |        |        | segments they cannot decode.     |
          +------+--------+--------+----------------------------------+
          | 7    | 0x0080 | SIGNED | Segment carries a cryptographic  |
          |      |        |        | signature in options.            |
          +------+--------+--------+----------------------------------+
          | 8-13 |        |        | Reserved for future use.         |
          +------+--------+--------+----------------------------------+
          | 14   | 0x4000 | CBOPEN | Circuit breaker: half-open probe |
          |      |        |        | request.                         |
          +------+--------+--------+----------------------------------+
          | 15   | 0x8000 | CBTRIP | Circuit breaker: tripped         |
          |      |        |        | notification to peer.            |
          +------+--------+--------+----------------------------------+

                             Table 3: AITP Flag Bits

     Request ID (32 bits)  A sender-assigned identifier for request-




  Song & Yuan             Expires 26 September 2026              [Page 16]


  Internet-Draft                    AITP                        March 2026


        response correlation and deduplication.  Each new request MUST use
        a unique Request ID among outstanding requests within the same
        association.  RESPONSE segments MUST echo the Request ID of the
        corresponding REQUEST.

        A stream-opening STREAM segment consumes a Request ID for the
        lifetime of the stream.  The ID MUST NOT be reused for another
        request or stream within the same association until the stream has
        terminated (FIN exchanged or RST received).

     Body Length (32 bits)  The length in octets of the body: the request
        body in REQUEST segments, or the response body in RESPONSE
        segments.  A Body Length of 0 is valid (e.g., for CONTROL segments
        or parameterless requests).

     Method Len (8 bits)  The length in octets of the UTF-8 method name.
        Maximum 255.  A value of 0 is permitted for CONTROL segments that
        carry no method.  The method field is padded to a 4-octet boundary
        with zero-valued octets.

     Options Len (8 bits)  The total length in octets of the TLV options
        region, including any padding.  Maximum 255.  The options region
        MUST be padded to a 4-octet boundary.

     Window (16 bits)  The sender's advertised receive window: the number
        of concurrent in-flight requests the sender is willing to accept.
        The receiver uses this value for flow control (see Section 6).
        The initial value is deployment-specific; implementations MAY
        advertise any value from 1 to 65535.

  3.3.  TLV Options

     The options region carries zero or more Type-Length-Value (TLV)
     encoded options, following the same encoding as AIP options:

     +--------+--------+----------------------------+
     |  Type  | Length  |    Data (Length octets)     |
     +--------+--------+----------------------------+
       1 byte   1 byte    variable












  Song & Yuan             Expires 26 September 2026              [Page 17]


  Internet-Draft                    AITP                        March 2026


     +=========+===========+==========+=================================+
     | Type    | Name      | Length   | Description                     |
     +=========+===========+==========+=================================+
     | 1       | Timeout   | 4        | Request timeout in milliseconds |
     |         |           |          | (uint32, big-endian).  Included |
     |         |           |          | in REQUEST segments to advise   |
     |         |           |          | the receiver of the caller's    |
     |         |           |          | deadline.                       |
     +---------+-----------+----------+---------------------------------+
     | 2       | SeqNum    | 4        | Sequence number (uint32, big-   |
     |         |           |          | endian).  Used with the SEQ     |
     |         |           |          | flag for ordered delivery       |
     |         |           |          | within a stream.                |
     +---------+-----------+----------+---------------------------------+
     | 3       | AckNum    | 4        | Acknowledgment number (uint32,  |
     |         |           |          | big-endian).  Acknowledges      |
     |         |           |          | receipt of a specific sequence  |
     |         |           |          | number.                         |
     +---------+-----------+----------+---------------------------------+
     | 4       | Timestamp | 8        | UTC Unix timestamp in           |
     |         |           |          | microseconds (uint64, big-      |
     |         |           |          | endian).  Used for latency      |
     |         |           |          | measurement.                    |
     +---------+-----------+----------+---------------------------------+
     | 5       | Signature | variable | Cryptographic signature over    |
     |         |           |          | the segment.  Used with the     |
     |         |           |          | SIGNED flag.                    |
     +---------+-----------+----------+---------------------------------+
     | 6       | Metadata  | variable | Key-value metadata (encoding is |
     |         |           |          | application-defined).           |
     +---------+-----------+----------+---------------------------------+
     | 7-127   |           |          | Available for future assignment |
     |         |           |          | (IANA).                         |
     +---------+-----------+----------+---------------------------------+
     | 128-254 |           |          | Available for experimental /    |
     |         |           |          | private use.                    |
     +---------+-----------+----------+---------------------------------+
     | 255     |           |          | Reserved.                       |
     +---------+-----------+----------+---------------------------------+

                        Table 4: Standard AITP Options

     The entire options region MUST be padded to a 4-octet boundary.
     Implementations MUST ignore unrecognized option types (skip by
     reading Type and Length, then advancing Length octets).






  Song & Yuan             Expires 26 September 2026              [Page 18]


  Internet-Draft                    AITP                        March 2026


  4.  Association State Machine

     An association is a stateful transport-layer relationship between two
     agents, identified by the (localURI, remoteURI) pair.  Each
     association tracks lifecycle state, flow control parameters, and
     circuit-breaker state.

  4.1.  Association States

        +=======+=============+======================================+
        | Value | Name        | Description                          |
        +=======+=============+======================================+
        | 0     | CLOSED      | No association exists.  Initial and  |
        |       |             | terminal state.                      |
        +-------+-------------+--------------------------------------+
        | 1     | LISTEN      | Waiting for an incoming INIT from a  |
        |       |             | remote peer.                         |
        +-------+-------------+--------------------------------------+
        | 2     | INIT_SENT   | INIT sent; awaiting INIT+ACK from    |
        |       |             | the remote peer.                     |
        +-------+-------------+--------------------------------------+
        | 3     | INIT_RECV   | INIT received; INIT+ACK sent;        |
        |       |             | awaiting first data exchange.        |
        +-------+-------------+--------------------------------------+
        | 4     | OPEN        | Association fully established.  Data |
        |       |             | exchange is permitted.               |
        +-------+-------------+--------------------------------------+
        | 5     | HALF_CLOSED | Local side has sent or received FIN; |
        |       |             | no new requests accepted, but in-    |
        |       |             | flight responses may still arrive.   |
        +-------+-------------+--------------------------------------+
        | 6     | DRAINING    | Both sides have exchanged FIN;       |
        |       |             | draining in-flight segments before   |
        |       |             | transitioning to CLOSED.             |
        +-------+-------------+--------------------------------------+

                       Table 5: AITP Association States

  4.2.  State Transitions

     The following transitions are valid.  Any other transition MUST be
     rejected as a protocol error.









  Song & Yuan             Expires 26 September 2026              [Page 19]


  Internet-Draft                    AITP                        March 2026


                        +--------+
                        | CLOSED |<-----------------------+
                        +--------+                        |
                         /      \                         |
                 passive/        \active                  |
                       v          v                       |
                +--------+   +-----------+               |
                | LISTEN |   | INIT_SENT |               |
                +--------+   +-----------+               |
                       \          /                       |
               INIT    \        / INIT+ACK                |
               recv     v      v                          |
                   +-----------+                          |
                   | INIT_RECV |                          |
                   +-----------+                          |
                         |                                |
                         v                                |
                    +--------+                           |
                    |  OPEN  |-----------+               |
                    +--------+           |               |
                     /      \            |               |
                FIN /        \ FIN      RST              |
                   v          v          |               |
            +-------------+ +----------+|               |
            | HALF_CLOSED | | DRAINING |+               |
            +-------------+ +----------+                |
                   \            /                        |
                    \          /  all drained            |
                     v        v                          |
                        +--------+                       |
                        | CLOSED |                       |
                        +--------+-----------------------+

     Valid transitions from each state:

     CLOSED  LISTEN (passive open) or INIT_SENT (active open).

     LISTEN  INIT_RECV (INIT received) or CLOSED (abort).

     INIT_SENT  OPEN (INIT+ACK received) or CLOSED (timeout/abort).

     INIT_RECV  OPEN (handshake complete) or CLOSED (abort).

     OPEN  HALF_CLOSED (FIN sent/received), DRAINING, or CLOSED (RST).

     HALF_CLOSED  DRAINING or CLOSED.

     DRAINING  CLOSED (all segments drained).



  Song & Yuan             Expires 26 September 2026              [Page 20]


  Internet-Draft                    AITP                        March 2026


  4.3.  Lazy Association Establishment

     The explicit INIT/INIT+ACK handshake defined in Section 4.2 is the
     fully specified, interoperable baseline.  Implementations that
     require mutual confirmation before data exchange MUST use this
     handshake.

     LISTEN exists to define the passive side of the explicit
     interoperable baseline; implementations that prefer lazy outbound
     establishment still need to accept incoming explicit INIT exchanges.

     As an optimization, implementations MAY use lazy association
     establishment: when a module needs to send a request to a peer with
     no existing association, it creates an association and transitions
     directly through INIT_SENT to OPEN without an explicit on-wire
     handshake.  This is an optimization profile for deployments whose
     lower layer (e.g., libp2p with peer authentication) already
     guarantees peer identity, making the INIT round-trip redundant.

     Implementations MUST document whether they use the explicit handshake
     or lazy establishment as their default mode, and MUST accept incoming
     INIT segments regardless of which mode they prefer for outgoing
     associations.  Interoperability claims for AITP MUST be evaluated
     against the explicit- handshake baseline.

  5.  Reliability Engine

     AITP provides reliability through ACK-based tracking, retransmission
     with exponential backoff, and deduplication.  The reliability engine
     operates on a per-request basis: each outgoing REQUEST that does not
     carry the NOACK flag is tracked until a matching RESPONSE arrives or
     the request times out.

  5.1.  ACK Tracking

     When a REQUEST segment is sent (without the NOACK flag), the sender
     registers the Request ID in a pending-request table.  When a RESPONSE
     segment arrives with a matching Request ID, the pending entry is
     removed and the response is delivered to the caller.

     If the NOACK flag is set, the sender does not track the request and
     does not expect a response.  The receiver SHOULD NOT send a response
     for NOACK requests, but MAY still invoke the method handler for side
     effects.







  Song & Yuan             Expires 26 September 2026              [Page 21]


  Internet-Draft                    AITP                        March 2026


  5.2.  Retransmission

     If no RESPONSE arrives within the retransmission timeout, the sender
     retransmits the REQUEST segment.  The retransmission timeout uses
     exponential backoff:

     timeout(n) = InitialTimeout * BackoffFactor^n

     where n = retransmission attempt number (0-based)

     After MaxRetries retransmissions without a response, the reliability
     engine generates a local TIMEOUT response (Status = TIMEOUT) and
     delivers it to the caller.  Deployment-specific defaults are expected
     for InitialTimeout, MaxRetries, and BackoffFactor; implementations
     SHOULD document their default values.

  5.3.  Deduplication

     Retransmitted REQUEST segments carry the same Request ID as the
     original.  The receiver MUST maintain a deduplication cache keyed by
     Request ID.  If an incoming REQUEST matches a recently-seen Request
     ID, the receiver MUST silently discard it (the response to the
     original request will serve as the acknowledgment).

     Implementations MUST bound the deduplication cache size and entry
     lifetime to prevent unbounded resource consumption; deployment-
     specific defaults are expected.

  6.  Flow Control

     AITP flow control is request-concurrency based, not byte-volume
     based.  This is a key departure from traditional transports: the
     Window field counts outstanding REQUEST operations, not octets.  The
     peer MUST track the remote window and MUST NOT have more in-flight
     requests than the advertised window allows.

     Before sending a REQUEST, the sender checks that its in-flight count
     is below the peer's advertised window and that the circuit breaker
     allows sending (see Section 7).  If either check fails, the send MUST
     be rejected with an appropriate error to the upper layer.

     When a RESPONSE arrives, the sender decrements its in-flight count
     and updates the peer's window from the RESPONSE's Window field.  This
     allows the receiver to dynamically adjust its capacity.

     The initial window size is deployment-specific.  Implementations MAY
     advertise any value from 1 to 65535; a value of 16 is a reasonable
     starting point for general-purpose agents.



  Song & Yuan             Expires 26 September 2026              [Page 22]


  Internet-Draft                    AITP                        March 2026


     The Window field governs concurrent in-flight REQUEST operations
     only.  STREAM chunks are subject to stream- specific bounded
     buffering and back-pressure (see Section 8.2), not request-window
     accounting.  An active stream consumes one Request ID slot for its
     lifetime but does not consume additional window capacity for
     subsequent STREAM chunks.

  7.  Circuit Breaker

     Each association maintains a per-peer circuit breaker to prevent
     cascading failures when a remote agent is unavailable or consistently
     failing.  The circuit breaker has three states:

       +=======+===========+===========================================+
       | Value | Name      | Description                               |
       +=======+===========+===========================================+
       | 0     | CLOSED    | Normal operation.  Requests pass through. |
       +-------+-----------+-------------------------------------------+
       | 1     | OPEN      | Tripped.  All requests are rejected       |
       |       |           | immediately without being sent.           |
       +-------+-----------+-------------------------------------------+
       | 2     | HALF_OPEN | Probing.  One request is allowed through  |
       |       |           | to test recovery.                         |
       +-------+-----------+-------------------------------------------+

                        Table 6: Circuit Breaker States

  7.1.  Circuit Breaker Transitions

                       success
                 +---<----------<---+
                 |                  |
                 v                  |
             +--------+        +----------+
             | CLOSED |------->| HALF_OPEN|
             +--------+  reset +----------+
                 |        timer       |
                 v                    v failure
             +--------+               |
             |  OPEN  |<--------------+
             +--------+
             (failures >= threshold)

     *CLOSED → OPEN:* When the consecutive failure count reaches the
     failure threshold, the circuit breaker transitions to OPEN.
     Implementations SHOULD use deployment-specific defaults for the
     threshold.




  Song & Yuan             Expires 26 September 2026              [Page 23]


  Internet-Draft                    AITP                        March 2026


     *OPEN → HALF_OPEN:* After a reset timeout elapses since the last
     failure, the circuit breaker transitions to HALF_OPEN, allowing one
     probe request.

     *HALF_OPEN → CLOSED:* If the probe request succeeds, the circuit
     breaker resets to CLOSED and the failure count is cleared.

     *HALF_OPEN → OPEN:* If the probe request fails, the circuit breaker
     returns to OPEN.

  7.2.  Circuit Breaker Flag Bits

     The CBOPEN flag (bit 14) MAY be set on a probe request to inform the
     remote peer that this is a circuit-breaker probe.  The CBTRIP flag
     (bit 15) MAY be set by a peer to proactively notify the sender that
     it should trip its circuit breaker.  These flags are advisory;
     implementations are not required to honor them.

  8.  Streaming

     AITP supports bidirectional streaming for long-running exchanges such
     as inference generation, file transfer, or multi-turn conversations.
     A stream is identified by its Request ID and uses STREAM segments
     (Type = 2).

  8.1.  Stream Lifecycle

     1.  *Initiation.*

         The initiator sends the first STREAM segment with a fresh Request
         ID and a method name.  If the receiver has a registered stream
         handler for that method, a new stream is created.  If not, the
         receiver returns a NOT_FOUND RESPONSE.

     2.  *Data exchange.*

         Both sides send STREAM segments with the same Request ID.  Each
         segment carries a body chunk.  The SEQ flag and SeqNum option MAY
         be used for ordered delivery within a stream.

     3.  *Termination.*

         Either side sends a STREAM segment with the FIN flag to signal
         end of stream.  Upon receiving FIN, the receiving side closes its
         chunk channel.  Both sides SHOULD release stream resources after
         FIN.





  Song & Yuan             Expires 26 September 2026              [Page 24]


  Internet-Draft                    AITP                        March 2026


  8.2.  Back-Pressure

     Stream receivers maintain a bounded buffer for incoming chunks.  If
     the buffer is full, incoming STREAM segments MAY be dropped (back-
     pressure).  The sender SHOULD use the association's flow control
     window and application-level acknowledgments to regulate sending
     rate.

  8.3.  Large Payload Guidance

     AIP limits each datagram payload to 65535 octets.  Upper-layer
     protocols whose response objects may exceed this limit SHOULD use one
     of the following strategies:

     1.  *Streaming.*

         Use an AITP STREAM exchange to deliver the response
         incrementally.  This is appropriate for variable-size payloads
         such as large Agent Cards, discovery result sets, or inference
         outputs.  Each STREAM chunk carries a portion of the response;
         the receiver reassembles them in SeqNum order (when the SEQ flag
         is used) or in arrival order.

     2.  *Application-level pagination.*

         Define "offset" and "limit" parameters in the REQUEST body so
         that the caller can page through a large result set with multiple
         REQUEST/RESPONSE round trips.  This is appropriate for
         enumeration operations (e.g., ans.lookup, adp.discover) where the
         total result count may be large but each page fits in a single
         datagram.

     Upper-layer methods that are expected to return large payloads SHOULD
     document which strategy they use and whether the method's tool
     descriptor sets streaming = true.

  9.  Segment Processing

     This section defines AITP's complete processing model.  The send and
     receive paths described below depend only on AIP's SEND/RECEIVE
     primitives and the local association/reliability state.  No knowledge
     of upper-layer application protocols is required to implement these
     paths.

  9.1.  Sending a Request

     When the upper layer invokes SEND-REQUEST or SEND-ONEWAY:




  Song & Yuan             Expires 26 September 2026              [Page 25]


  Internet-Draft                    AITP                        March 2026


     1.  *Ensure association.*

         Look up or create an association for the destination agent://
         URI.  If lazy establishment is used, transition directly to OPEN.
         If explicit handshake is required, send CONTROL+INIT and wait for
         CONTROL+INIT+ACK.

     2.  *Check flow control.*

         Verify that the in-flight count is below the peer's advertised
         window and the circuit breaker allows sending.  If not, return an
         error to the caller.

     3.  *Construct the segment.*

         Build the 16-octet fixed header with Version = 1, Type = REQUEST
         (or STREAM), Status = OK, appropriate Flags, a fresh Request ID,
         Body Length, Method Len, Options Len, and the local receive
         Window.  Serialize method, options, and body.

     4.  *Register for tracking (if not NOACK).*

         Add the Request ID to the reliability engine's pending table and
         start the retransmission timer.

     5.  *Transmit via AIP.*

         Call AIP's SEND with source = local agent:// URI, destination =
         remote agent:// URI, protocol = 1 (AITP), and the serialized
         segment as payload.

  9.2.  Receiving a Segment

     When AIP delivers a datagram with Protocol = 1 to the AITP module:

     1.  *Deserialize.*

         Decode the fixed header.  If the Version is unrecognized or the
         data is truncated, discard.

     2.  *Update association.*

         Look up or create the association for the source URI.  Update the
         last-seen timestamp.  If the segment carries a non-zero Window,
         update the peer's advertised window.

     3.  *Dispatch by Type.*




  Song & Yuan             Expires 26 September 2026              [Page 26]


  Internet-Draft                    AITP                        March 2026


         *REQUEST:* Check deduplication.  If duplicate, discard.  Look up
         the method handler.  If not found, send a RESPONSE with Status =
         NOT_FOUND.  Otherwise, invoke the handler asynchronously.  When
         the handler completes, send a RESPONSE with the handler's status
         and response body (unless NOACK).

         *RESPONSE:* Deliver to the reliability engine, which matches by
         Request ID and wakes the waiting caller.  Update flow control:
         decrement in-flight count and record circuit-breaker success/
         failure based on the status code.

         *STREAM:* If the Request ID matches an active stream, deliver the
         chunk to the stream's buffer.  If FIN is set, close the stream's
         input channel.  If no stream exists, check for a stream handler
         and create a new stream.  If no handler, send RESPONSE with
         NOT_FOUND.

         *CONTROL:* Verify that exactly one of INIT, FIN, or RST is set.
         Invalid CONTROL flag combinations MUST NOT create, mutate, or
         tear down association state; discard the segment.  INIT →
         transition association to INIT_RECV then OPEN, reply with
         CONTROL+INIT+ACK; FIN → transition to HALF_CLOSED then DRAINING,
         reply with CONTROL+FIN+ACK, then close; RST → transition
         immediately to CLOSED.

  10.  Interfaces

  10.1.  Upper Layer Interface (Application Protocols)

     AITP provides the following abstract service primitives to upper-
     layer protocols.  These are protocol-level abstractions; actual API
     bindings are implementation- defined.

     SEND-REQUEST(destination, method, request-body, timeout) ->
     (status, response-body)  Send a request and wait for a response.

        *  *destination* -- agent:// URI of the remote agent.

        *  *method* -- UTF-8 method name (max 255 octets).

        *  *request-body* -- opaque payload bytes.

        *  *timeout* -- optional request deadline.

        Returns: status code and response body, or a transport error.

     SEND-ONEWAY(destination, method, request-body) -> error  Send a one-




  Song & Yuan             Expires 26 September 2026              [Page 27]


  Internet-Draft                    AITP                        March 2026


        way message with no response expected.  Sets the NOACK flag.
        Returns only a send error, not a remote result.

     OPEN-STREAM(destination, method) -> stream  Initiate a bidirectional
        stream.  Returns a stream handle through which the caller sends
        and receives STREAM chunks.

     REGISTER-HANDLER(method, handler)  Register a handler that will be
        invoked when an incoming REQUEST arrives for the given method.

     REGISTER-STREAM-HANDLER(method, handler)  Register a handler that
        will be invoked when an incoming STREAM segment arrives for the
        given method with no active stream.

     Monitoring and statistics primitives (e.g., counters for requests
     sent, streams active) are implementation concerns and are not
     specified by this document.  Deployment-specific counters, tracing
     hooks, and operational telemetry are expected to be defined by
     implementation profiles rather than by this protocol specification.

  10.2.  Lower Layer Interface (AIP)

     AITP depends on AIP for datagram delivery.  The interface consists
     of:

     AIP.SEND(source, destination, protocol=1, payload)  Sends an AITP
        segment as an AIP datagram.  AITP always uses Protocol = 1.

     AIP.RECEIVE callback (Protocol = 1)  AIP dispatches incoming
        datagrams with Protocol = 1 to AITP's HandleSegment entry point.

     Note: AIP assigns Protocol values 2 (ANS) and 3 (ADP) for potential
     future direct-datagram exchanges that bypass AITP.  In normal
     operation, ANS and ADP methods are carried as AITP segments with
     Protocol = 1.  See AIP [I-D.song-anp-aip], Section 4.

  11.  Security Considerations

  11.1.  Segment Authentication

     AITP defines the SIGNED flag and Signature option for segment- level
     authentication.  When the SIGNED flag is set, implementations SHOULD
     verify the signature before processing the segment.  The signature
     algorithm and key binding are defined by the deployment context; AITP
     does not mandate a specific algorithm.






  Song & Yuan             Expires 26 September 2026              [Page 28]


  Internet-Draft                    AITP                        March 2026


     AITP segment signatures protect invocation-layer provenance and
     segment integrity, while AIP signatures protect the enclosing
     datagram.  Deployments MAY use either layer or both, depending on
     their threat model, and SHOULD use at least one.

  11.2.  Replay Attacks

     AITP's deduplication cache (Section 5.3) provides protection against
     replayed REQUEST segments.  The Timestamp option provides an
     additional freshness signal.  Implementations SHOULD reject segments
     with timestamps outside a deployment-specific freshness window.

  11.3.  Resource Exhaustion

     Flow control (Section 6) limits the number of concurrent in-flight
     requests per association.  The circuit breaker (Section 7) prevents
     runaway retries to failing peers.  Implementations MUST bound the
     deduplication cache, pending-request table, and stream buffer sizes
     to prevent unbounded memory growth.

  11.4.  Method Authorization

     AITP provides the UNAUTHORIZED status code (5) for method- level
     access control.  The authorization mechanism is application-defined;
     AITP does not prescribe any particular access control model.
     Implementations SHOULD document their authorization strategy.

  11.5.  Privacy

     Method names and request/response bodies are visible to network
     participants that can observe AIP datagrams.  AITP does not provide
     payload confidentiality.  Applications requiring confidentiality
     SHOULD encrypt payloads at the application layer or use privacy-
     preserving lower-layer routing mechanisms.

  11.6.  Association State Attacks

     Because CONTROL segments (INIT, FIN, RST) can create, close, or abort
     associations, unauthenticated control segments can induce association
     churn or exhaust the association state table.

     Deployments SHOULD authenticate peers (via AIP SIG, AITP SIGNED, or
     lower-layer mechanisms) before creating persistent association state.
     Implementations SHOULD rate-limit new association creation per source
     URI and MUST bound the total number of concurrent associations to
     prevent unbounded state growth.





  Song & Yuan             Expires 26 September 2026              [Page 29]


  Internet-Draft                    AITP                        March 2026


  11.7.  Dispatch-Level Information Leakage

     The dispatch-level status codes NOT_FOUND (2), UNAUTHORIZED (5), and
     NOT_IMPLEMENTED (8) reveal information about the methods registered
     on the remote agent.  An adversary can enumerate supported methods by
     sending probe requests and observing which status code is returned.

     Deployments concerned with method enumeration MAY coarsen dispatch-
     level status codes into a generic ERROR or UNAUTHORIZED response for
     unrecognized or unauthorized callers, at the cost of reduced
     diagnostic fidelity for legitimate clients.

  12.  IANA Considerations

     This document requests the creation of four new IANA registries.

  12.1.  AITP Segment Type Registry

     Registry with 4-bit values (0-15).  Registration policy:
     Specification Required.  Initial values in Table 1.

  12.2.  AITP Status Code Registry

     Registry with 8-bit values (0-255).  Registration policy:
     Specification Required for 0-127, First Come First Served for
     128-254.  Value 255 is reserved.  Initial values in Table 2.

  12.3.  AITP Flag Bits Registry

     Registry with 16 bit positions (0-15).  Registration policy:
     Specification Required.  Initial values in Table 3.

  12.4.  AITP Option Type Registry

     Registry with 8-bit values (0-255).  Registration policy:
     Specification Required for 0-127, First Come First Served for
     128-254, value 255 reserved.  Initial values in Table 4.

  13.  Implementation Status

     Per [RFC7942], this section records known implementations.

  13.1.  ClawNet

     Organization  ChatChatTech

     URL  https://github.com/ChatChatTech/ClawNet




  Song & Yuan             Expires 26 September 2026              [Page 30]


  Internet-Draft                    AITP                        March 2026


     Description  Go implementation of the full ANP suite.  The AITP
        module (atp/ directory) implements the 16-octet fixed header,
        segment type demux, TLV options, association state machine,
        reliability engine with exponential-backoff retransmission,
        receiver-advertised flow control, per-association circuit breaker,
        bidirectional streaming, and the full 10-code status code set.
        The reference implementation is being completed as part of the
        full ClawNet stack conforming to AIP, ANS, AITP, and ADP; protocol
        boundaries are exercised in integration tests across the stack.

     Maturity  Alpha

     Coverage  Implemented:

        *  Segment codec (16-octet header, type demux, TLV options)

        *  Association state machine (7 states, validated transitions)

        *  Reliability engine (ACK tracking, exponential-backoff
           retransmission, dedup)

        *  Receiver-advertised flow control (Window)

        *  Per-association circuit breaker (CLOSED/OPEN/HALF_OPEN)

        *  Synchronous invocation and fire-and-forget

        *  Bidirectional streaming with FIN termination

        *  Lazy association establishment

        Under integration:

        *  Segment-level signature verification (SIGNED flag)

        *  Body compression (COMPR flag)

        *  Explicit INIT/FIN handshake integration tests

        The items under integration affect robustness and efficiency only;
        they do not alter the wire format, segment semantics, or protocol
        boundaries defined in this document.

     Language  Go

     License  Open source

     Contact  ink@chatchat.space



  Song & Yuan             Expires 26 September 2026              [Page 31]


  Internet-Draft                    AITP                        March 2026


  14.  References

  14.1.  Normative References

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

     [I-D.song-anp-aip]
                Song, J., "Agent Internet Protocol (AIP)", Work in
                Progress, Internet-Draft, draft-song-anp-aip-01, March
                2026, <https://datatracker.ietf.org/doc/html/draft-song-
                anp-aip-01>.

  14.2.  Informative References

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

     [I-D.song-anp-ans]
                Song, J., "Agent Name System (ANS)", Work in Progress,
                Internet-Draft, draft-song-anp-ans-00, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-song-anp-ans-
                00>.

     [I-D.song-anp-adp]
                Song, J., "Agent Description Protocol (ADP)", Work in
                Progress, Internet-Draft, draft-song-anp-adp-00, March
                2026, <https://datatracker.ietf.org/doc/html/draft-song-
                anp-adp-00>.

  Appendix A.  Implementation Alignment Notes

     This appendix documents the relationship between this specification
     and the reference implementation in the ClawNet atp/ directory.









  Song & Yuan             Expires 26 September 2026              [Page 32]


  Internet-Draft                    AITP                        March 2026


     +===========+==========================+===========================+
     |Spec       | Go Symbol                | Notes                     |
     |Concept    |                          |                           |
     +===========+==========================+===========================+
     |Segment    | atp.SegmentType          | TypeRequest(0),           |
     |Type       |                          | TypeResponse(1),          |
     |           |                          | TypeStream(2),            |
     |           |                          | TypeControl(3).           |
     +-----------+--------------------------+---------------------------+
     |Status Code| atp.StatusCode           | Full 10-code set:         |
     |           |                          | StatusOK(0) through       |
     |           |                          | StatusServiceShutdown(9). |
     +-----------+--------------------------+---------------------------+
     |Flags      | atp.Flags                | FlagACK(0x1),             |
     |           |                          | FlagFIN(0x2),             |
     |           |                          | FlagINIT(0x4),            |
     |           |                          | FlagRST(0x8),             |
     |           |                          | FlagSEQ(0x10),            |
     |           |                          | FlagNOACK(0x20),          |
     |           |                          | FlagCOMPR(0x40),          |
     |           |                          | FlagSIGNED(0x80),         |
     |           |                          | FlagCBOPEN(0x4000),       |
     |           |                          | FlagCBTRIP(0x8000).       |
     +-----------+--------------------------+---------------------------+
     |Fixed      | fixedHeaderSize = 16     | Byte layout per Figure 1. |
     |Header     |                          |                           |
     +-----------+--------------------------+---------------------------+
     |Options    | atp.Option,              | TLV encoding with 4-byte  |
     |           | OptTimeout..OptMetadata  | alignment.                |
     +-----------+--------------------------+---------------------------+
     |Association| atp.Association          | 7-state FSM per Table 5.  |
     +-----------+--------------------------+---------------------------+
     |Circuit    | atp.CBState              | CBClosed(0), CBOpen(1),   |
     |Breaker    |                          | CBHalfOpen(2).            |
     +-----------+--------------------------+---------------------------+
     |Reliability| atp.Reliability          | Track(), Resolve(),       |
     |           |                          | IsDuplicate(),            |
     |           |                          | retransmitLoop().         |
     +-----------+--------------------------+---------------------------+
     |Flow       | Association.AcquireSend/ | Window-based concurrency  |
     |Control    | ReleaseSend              | limiting.                 |
     +-----------+--------------------------+---------------------------+
     |Module     | atp.Module               | SEND-REQUEST → Call(),    |
     |           |                          | SEND-ONEWAY →             |
     |           |                          | FireAndForget(),          |
     |           |                          | HandleSegment(),          |
     |           |                          | REGISTER-HANDLER →        |
     |           |                          | Handle(), REGISTER-       |



  Song & Yuan             Expires 26 September 2026              [Page 33]


  Internet-Draft                    AITP                        March 2026


     |           |                          | STREAM-HANDLER →          |
     |           |                          | HandleStream().           |
     +-----------+--------------------------+---------------------------+
     |Stream     | atp.Stream               | Recv(), Send(), Close()   |
     |           |                          | with FIN termination.     |
     +-----------+--------------------------+---------------------------+
     |AIP        | atp.AIPSender            | SendRaw(ctx, src, dst,    |
     |Interface  |                          | proto, payload).          |
     +-----------+--------------------------+---------------------------+

                     Table 7: Spec-Implementation Mapping

  Authors' Addresses

     Jinke Song
     Dept. of CSE, Hong Kong University of Science and Technology
     Email: ink@chatchat.space


     Mu Yuan
     Dept. of IE, The Chinese University of Hong Kong
     Email: muyuan@cuhk.edu.hk





























  Song & Yuan             Expires 26 September 2026              [Page 34]


name: draft-song-anp-aip
rev: 00
title: Agent Internet Protocol (AIP)
time: 2026-03-25T09:52:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-26T09:52:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-05-22T09:24:48.589054+00:00
source: ietf
abstract:
  The Internet Protocol (IP, RFC 791) provides best-effort datagram
     delivery between hosts identified by numeric addresses.  The Agent
     Internet Protocol (AIP) provides best-effort datagram delivery
     between autonomous AI agents identified by agent:// URIs -- human-
     readable, capability-descriptive names.

     AIP is designed to serve as the narrow waist of the Agent Network
     Protocol (ANP) suite, occupying an architectural position analogous
     to IP in the TCP/IP suite: a minimal common substrate through which
     upper-layer protocols and link technologies interoperate without
     direct coupling.

     This document specifies the AIP message format, addressing model,
     upper-layer protocol demultiplexing, TLV options, message processing
     rules, error handling, and interfaces to adjacent protocol layers.
     Name registration, distributed name resolution, and semantic
     discovery are provided by a companion resolver service and are
     outside the scope of this document.

full_text:
  Independent Submission                                           J. Song
  Internet-Draft                                                     HKUST
  Intended status: Experimental                                    M. Yuan
  Expires: 26 September 2026                                          CUHK
                                                             25 March 2026


                       Agent Internet Protocol (AIP)
                           draft-song-anp-aip-00

  Abstract

     The Internet Protocol (IP, RFC 791) provides best-effort datagram
     delivery between hosts identified by numeric addresses.  The Agent
     Internet Protocol (AIP) provides best-effort datagram delivery
     between autonomous AI agents identified by agent:// URIs -- human-
     readable, capability-descriptive names.

     AIP is designed to serve as the narrow waist of the Agent Network
     Protocol (ANP) suite, occupying an architectural position analogous
     to IP in the TCP/IP suite: a minimal common substrate through which
     upper-layer protocols and link technologies interoperate without
     direct coupling.

     This document specifies the AIP message format, addressing model,
     upper-layer protocol demultiplexing, TLV options, message processing
     rules, error handling, and interfaces to adjacent protocol layers.
     Name registration, distributed name resolution, and semantic
     discovery are provided by a companion resolver service and are
     outside the scope of this document.

  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 26 September 2026.




  Song & Yuan             Expires 26 September 2026               [Page 1]


  Internet-Draft                     AIP                        March 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.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .   5
       1.4.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  The agent:// URI Scheme . . . . . . . . . . . . . . . . . . .   6
       3.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Comparison Rules  . . . . . . . . . . . . . . . . . . . .   7
       3.3.  Wire Encoding . . . . . . . . . . . . . . . . . . . . . .   7
       3.4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.5.  Design Rationale  . . . . . . . . . . . . . . . . . . . .   8
     4.  AIP Message Format  . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Header Structure  . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Field Definitions . . . . . . . . . . . . . . . . . . . .   9
       4.3.  TLV Options . . . . . . . . . . . . . . . . . . . . . . .  13
       4.4.  Message Signature . . . . . . . . . . . . . . . . . . . .  15
     5.  Local Resolver  . . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.  Resolver Interface  . . . . . . . . . . . . . . . . . . .  15
       5.2.  Optional Semantic Resolver Extension  . . . . . . . . . .  16
       5.3.  Requirements on Implementations . . . . . . . . . . . . .  16
     6.  Name Resolution . . . . . . . . . . . . . . . . . . . . . . .  16
       6.1.  Exact Resolution (SEM flag clear) . . . . . . . . . . . .  17
       6.2.  Semantic Resolution (SEM flag set) -- Optional
             Extension . . . . . . . . . . . . . . . . . . . . . . . .  17
     7.  Message Processing  . . . . . . . . . . . . . . . . . . . . .  18
       7.1.  Sending . . . . . . . . . . . . . . . . . . . . . . . . .  18
       7.2.  Receiving . . . . . . . . . . . . . . . . . . . . . . . .  18
       7.3.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  19
       7.4.  Deduplication . . . . . . . . . . . . . . . . . . . . . .  20
       7.5.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  21
     8.  Interfaces  . . . . . . . . . . . . . . . . . . . . . . . . .  21
       8.1.  Upper Layer Interface (AITP and others) . . . . . . . . .  21
       8.2.  Lower Layer Interface (Link Layer)  . . . . . . . . . . .  21
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  22



  Song & Yuan             Expires 26 September 2026               [Page 2]


  Internet-Draft                     AIP                        March 2026


       9.1.  Message Authentication  . . . . . . . . . . . . . . . . .  22
       9.2.  Identity and Signing Key Relationship . . . . . . . . . .  22
       9.3.  Name Spoofing . . . . . . . . . . . . . . . . . . . . . .  22
       9.4.  Resolution Poisoning  . . . . . . . . . . . . . . . . . .  23
       9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  23
       9.6.  Resource Exhaustion . . . . . . . . . . . . . . . . . . .  23
       9.7.  Semantic Resolution Gaming  . . . . . . . . . . . . . . .  23
       9.8.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  24
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
       10.1.  URI Scheme Registration: agent . . . . . . . . . . . . .  24
       10.2.  AIP Message Type Registry  . . . . . . . . . . . . . . .  24
       10.3.  AIP Protocol Number Registry . . . . . . . . . . . . . .  24
       10.4.  AIP Error Code Registry  . . . . . . . . . . . . . . . .  24
       10.5.  AIP Flag Bits Registry . . . . . . . . . . . . . . . . .  25
       10.6.  AIP Option Type Registry . . . . . . . . . . . . . . . .  25
     11. Implementation Status . . . . . . . . . . . . . . . . . . . .  25
       11.1.  ClawNet  . . . . . . . . . . . . . . . . . . . . . . . .  25
     12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
       12.1.  Normative References . . . . . . . . . . . . . . . . . .  26
       12.2.  Informative References . . . . . . . . . . . . . . . . .  26
     Appendix A.  Example Resolver Scoring (Informative) . . . . . . .  27
     Appendix B.  Network Bootstrap (Informative)  . . . . . . . . . .  29
       B.1.  Bootstrap Sequence  . . . . . . . . . . . . . . . . . . .  29
       B.2.  Minimal Bootstrap . . . . . . . . . . . . . . . . . . . .  30
     Appendix C.  Implementation Alignment Notes . . . . . . . . . . .  30
     Appendix D.  AIP in Isolation (Informative) . . . . . . . . . . .  31
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  32

  1.  Introduction

  1.1.  Problem Statement

     The Internet Protocol [RFC0791] provides a universal mechanism for
     delivering datagrams between hosts identified by fixed-length numeric
     addresses.  IP was designed under the assumption that communication
     endpoints are hardware devices with stable locations on physical
     networks.

     In agent networking, the endpoints are not hardware devices but
     software agents: autonomous programs that can be created, destroyed,
     migrated, and replicated at will.  They do not have fixed locations.
     They are identified not by physical attachment points but by their
     names and capabilities.








  Song & Yuan             Expires 26 September 2026               [Page 3]


  Internet-Draft                     AIP                        March 2026


     An AI agent that needs a French-to-Japanese translator does not know
     -- and should not need to know -- any IP address.  It needs to reach
     "agent://translation/fr-ja".  In AIP, names serve as addresses:
     rather than resolving a name to a numeric location before sending,
     the agent addresses messages directly to a human-readable URI and
     relies on a local resolver to map that name to a reachable peer.

     Current naming systems such as the Domain Name System [RFC1035] map
     human-readable names to network locations.  Agents need a naming
     system that maps intents to capabilities.  AIP provides the datagram
     substrate: name-based addressing with the agent:// URI scheme and
     best-effort message delivery.  The name resolution service itself --
     including registration, distributed lookup, and semantic search -- is
     provided by a companion resolver that runs above AIP as an upper-
     layer protocol (one such resolver is ANS [I-D.song-anp-ans]).

  1.2.  Scope

     This document is one of four core Internet-Drafts in the Agent
     Network Protocol (ANP) suite: AIP (this document, datagram delivery),
     AITP [I-D.song-anp-aitp] (invocation transport), ANS
     [I-D.song-anp-ans] (name system), and ADP [I-D.song-anp-adp]
     (description and discovery).  The four drafts are designed to co-
     evolve as a self-contained protocol suite; no additional
     specification is required for baseline interoperability.  AIP's
     local-resolver semantic extension (Section 6.2) MAY be backed by an
     implementation that consults ADP discovery services for ranked
     capability matching; ANS core provides name-to-peer binding but does
     not itself perform ranked semantic discovery.

     AIP defines an experimental datagram protocol serving as the narrow
     waist of the ANP suite, analogous to IP in TCP/IP.  It provides a
     best-effort datagram service between named agents.

     AIP provides:

     1.  Name-based addressing using agent:// URIs.

     2.  Best-effort datagram delivery.

     3.  Upper-layer protocol demultiplexing via the Protocol field.

     4.  TTL-bounded relay with deduplication.

     5.  Extensible TLV options for timestamps, tracing, and priority.

     6.  Error reporting for undeliverable messages.




  Song & Yuan             Expires 26 September 2026               [Page 4]


  Internet-Draft                     AIP                        March 2026


     AIP does NOT provide:

     1.  Reliable delivery -- datagrams may be lost, duplicated, or
         reordered.  Reliability is the responsibility of a higher-layer
         protocol such as AITP [I-D.song-anp-aitp].

     2.  Ordering or flow control -- these are higher-layer functions.

     3.  Name registration, distributed lookup, or semantic discovery --
         AIP does not define these functions.  They are expected to be
         provided by a companion naming service; ANS [I-D.song-anp-ans] is
         one such architecture.

     4.  Fragmentation -- messages exceeding the link MTU are rejected,
         not fragmented.

     5.  Payload confidentiality -- encryption is the responsibility of a
         higher-layer protocol or the application.

  1.3.  Assumptions

     AIP assumes:

     1.  A local resolver service capable of mapping agent:// URI tokens
         to link-layer delivery targets.  AIP does not require any
         specific resolver architecture.

     2.  A link layer that can deliver variable-length byte sequences
         between peers identified by peer ID.

     3.  AIP MAY be used with higher-layer protocols that provide
         reliability, ordering, or application semantics, but does not
         depend on them for baseline datagram operation.

  1.4.  Requirements Language

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

  2.  Terminology

     Agent  An autonomous software entity that participates in the ANP
        network.  An agent has a cryptographic identity (an Ed25519 key
        pair) and registers one or more agent:// URIs.




  Song & Yuan             Expires 26 September 2026               [Page 5]


  Internet-Draft                     AIP                        March 2026


     Name  The identifier component of an agent:// URI that appears after
        the optional namespace and slash.  For example, in "agent://acme/
        code-reviewer", the name is "code-reviewer".

     Namespace  An optional organizational prefix in an agent:// URI that
        groups related agents.  For example, in "agent://acme/code-
        reviewer", the namespace is "acme".  A URI without a namespace is
        in the global namespace.

     Resolution  The process of mapping an agent:// URI to a peer ID so
        that AIP can transmit a message.  Resolution is performed by a
        local resolver.

     Resolver  A local service that maps agent:// URIs to peer IDs.  AIP
        delegates all resolution to the resolver.  A resolver MAY
        additionally support semantic queries (see Section 6.2).

     AIP Message  The protocol data unit of AIP.  An independent, self-
        contained datagram carrying a fixed header, source and destination
        agent:// URIs, optional TLV options, and a payload.

     Peer ID  A globally unique identifier for a network participant,
        derived from its Ed25519 public key.  Used at the link layer for
        point-to-point addressing.

     Node  A machine (physical or virtual) running one AIP module.  A node
        has one peer ID.  Multiple agents MAY run on a single node.

     In summary: a node has one link-layer Peer ID; one or more agents MAY
     run on that node; AIP addresses agents by agent:// URI, not by Peer
     ID.

  3.  The agent:// URI Scheme

     The agent:// URI is the fundamental addressing primitive of AIP.  It
     identifies an agent by a human-readable, capability-descriptive name
     rather than by a numeric network address.  The scheme is registered
     with IANA in accordance with [RFC7595] (see Section 10.1).

     An agent:// URI is a *routing token* designating a capability
     endpoint; it does not necessarily correspond to a singular legal
     identity.  Multiple agents, instances, or replicas MAY be reachable
     through the same URI via resolver-level load balancing or failover.
     Conversely, a single agent MAY register multiple URIs for different
     capabilities.






  Song & Yuan             Expires 26 September 2026               [Page 6]


  Internet-Draft                     AIP                        March 2026


  3.1.  Syntax

     The syntax of agent:// URIs is defined in ABNF [RFC5234], following
     the generic URI structure of [RFC3986]:

     agent-uri    = "agent://" agent-path
     agent-path   = [ namespace "/" ] name [ "@" version ]
     namespace    = ident
     name         = ident
     ident        = LCALPHA-DIGIT *( LCALPHA-DIGIT / "-" )
     version      = 1*( DIGIT / "." / "-" / ALPHA )
     LCALPHA-DIGIT = %x61-7A / DIGIT    ; a-z / 0-9

     Names and namespaces MUST begin with a lowercase letter or digit,
     MUST NOT end with a hyphen, and MUST be at least one character long.
     Uppercase letters are not permitted; implementations MUST reject URIs
     containing uppercase letters rather than silently normalizing them.

     The total URI length (including the "agent://" prefix) MUST NOT
     exceed 263 octets (255 for the wire-encoded path plus 8 for the
     "agent://" prefix).

  3.2.  Comparison Rules

     Because all characters in agent:// URIs are already constrained to
     lowercase, comparison is a simple octet-by-octet match of the wire-
     encoded forms after the following normalization:

     1.  Remove any trailing slash.

     2.  Remove any trailing "@" not followed by a version string.

     No percent-decoding is performed because the agent:// scheme does not
     permit percent-encoded characters.

  3.3.  Wire Encoding

     On the wire, agent:// URIs are encoded WITHOUT the "agent://" prefix.
     The prefix is implicit -- all addresses in AIP messages are agent://
     URIs.  The encoding is UTF-8.

     The encoding function strips the 8-octet "agent://" prefix:

     *  wire_encode("agent://acme/translator") -> "acme/translator" (15
        octets)

     *  wire_encode("agent://translator") -> "translator" (10 octets)




  Song & Yuan             Expires 26 September 2026               [Page 7]


  Internet-Draft                     AIP                        March 2026


     *  wire_encode("agent://x/y@1.0") -> "x/y@1.0" (7 octets)

     The decoding function prepends "agent://":

     *  wire_decode("acme/translator") -> "agent://acme/translator"

     This avoids repeating the scheme prefix for both source and
     destination addresses on the wire.

  3.4.  Examples

     Valid agent:// URIs:

     *  agent://translator -- global namespace, name only

     *  agent://acme/code-reviewer@2.1 -- namespace "acme", name "code-
        reviewer", version "2.1"

     *  agent://openai/gpt-assistant -- namespace "openai", name "gpt-
        assistant"

     *  agent://research/arxiv-search -- namespace "research", name
        "arxiv-search"

  3.5.  Design Rationale

     A dedicated URI scheme is used rather than an existing scheme because
     agent:// URIs serve as first-class routing tokens, not as locators
     that resolve to network endpoints.  Existing alternatives were
     considered and found insufficient:

     *  DID URIs (did:method:...) are identity-centric and lack a built-in
        namespace/version structure for capability addressing.

     *  HTTPS well-known paths (https://host/.well-known/agent/...) couple
        agent identity to DNS names and TLS certificates, reintroducing
        the topology-bound addressing that AIP avoids.

     *  Opaque identifiers with external resolvers provide no human-
        readable semantics and require mandatory resolver infrastructure
        before any message can be sent.

     The agent:// scheme provides compact, human-readable routing tokens
     with a fixed wire encoding convention (Section 3.3).







  Song & Yuan             Expires 26 September 2026               [Page 8]


  Internet-Draft                     AIP                        March 2026


  4.  AIP Message Format

     AIP messages are carried as payloads of link-layer frames.  An AIP
     message consists of a 16-octet fixed header, a variable-length
     address block containing the source and destination URIs (padded to a
     4-octet boundary), a variable-length TLV options region, and a
     variable-length payload.

  4.1.  Header Structure

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|  Type |   Protocol    |  TTL  | Flags |   Reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Message ID                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Payload Length                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Src URI Len |   Dst URI Len |        Options Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Source URI (wire-encoded, variable)    ...             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Destination URI (wire-encoded, variable) ...          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Address Padding (to 4-octet boundary)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Options (TLV, padded to 4-octet boundary) ...         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Payload (variable)    ...                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Note: one tick mark represents one bit position.

                 Figure 1: AIP Message Header (16 octets fixed)

  4.2.  Field Definitions

     Version (4 bits)  Protocol version.  The current version is 1.
        Implementations MUST silently discard messages with an
        unrecognized version.

     Type (4 bits)  The message type:








  Song & Yuan             Expires 26 September 2026               [Page 9]


  Internet-Draft                     AIP                        March 2026


               +=======+=======+==================================+
               | Value | Name  | Description                      |
               +=======+=======+==================================+
               | 0     | DATA  | Normal data message (payload     |
               |       |       | delivery to upper layer).        |
               +-------+-------+----------------------------------+
               | 1     | ERROR | Error report (carries an error   |
               |       |       | payload, see Section 7.3).       |
               +-------+-------+----------------------------------+
               | 2     | PING  | Liveness probe.  Recipient MUST  |
               |       |       | reply with PONG.                 |
               +-------+-------+----------------------------------+
               | 3     | PONG  | Liveness reply.  Carries the     |
               |       |       | Message ID of the original PING. |
               +-------+-------+----------------------------------+
               | 4-15  |       | Reserved for future use.         |
               +-------+-------+----------------------------------+

                            Table 1: AIP Message Types

        Implementations MUST silently discard messages with unrecognized
        Type values.

     Protocol (8 bits)  Identifies the upper-layer protocol that will
        process the payload.  This field is analogous to the Protocol
        field in IPv4 [RFC0791].  It enables AIP to demultiplex incoming
        messages to the correct upper-layer handler.
























  Song & Yuan             Expires 26 September 2026              [Page 10]


  Internet-Draft                     AIP                        March 2026


               +=======+======+==================================+
               | Value | Name | Description                      |
               +=======+======+==================================+
               | 0     | NONE | No upper-layer protocol (used    |
               |       |      | for PING/PONG/control messages). |
               +-------+------+----------------------------------+
               | 1     | AITP | Agent Invocation Transport       |
               |       |      | Protocol [I-D.song-anp-aitp].    |
               +-------+------+----------------------------------+
               | 2     | ANS  | Agent Name System                |
               |       |      | [I-D.song-anp-ans].              |
               +-------+------+----------------------------------+
               | 3     | ADP  | Agent Description Protocol       |
               |       |      | [I-D.song-anp-adp].              |
               +-------+------+----------------------------------+
               | 4-254 |      | Available for future assignment  |
               |       |      | (IANA registry).                 |
               +-------+------+----------------------------------+
               | 255   | EXPT | Experimental / private use.      |
               +-------+------+----------------------------------+

                          Table 2: AIP Protocol Numbers

        The Type and Protocol fields serve orthogonal purposes.  Type
        identifies AIP's own control semantics (data delivery, error
        reporting, liveness probing).  Protocol identifies which upper-
        layer consumer processes the payload.  Thus, PING/PONG are AIP-
        layer operations (Type) that carry no upper-layer payload, while
        AITP, ANS, and ADP are upper- layer consumers (Protocol) whose
        payloads travel inside DATA messages (Type = 0).

        In normal operation, ANS and ADP methods are carried as AITP
        segments (Protocol = 1, AITP).  Protocol = 2 (ANS) and Protocol =
        3 (ADP) are reserved for future use cases where a lightweight,
        single-datagram exchange bypasses AITP association overhead — for
        example, bootstrap resolution when no AITP association can yet be
        established, or one-shot name announcements in resource-
        constrained environments.  Until such uses are formally specified,
        conforming implementations SHOULD use Protocol = 1 (AITP) for all
        ANS and ADP exchanges, and MUST silently discard messages with
        Protocol values 2 or 3 if they do not implement direct-datagram
        handlers for those protocols.

     TTL (4 bits)  Time to Live.  An upper bound on the number of relay
        hops.  Each relaying node MUST decrement the TTL by 1.  When the
        TTL reaches zero, the message MUST be discarded; if the ERR flag
        is set, an ERROR message with code TTL_EXPIRED SHOULD be returned
        to the source.



  Song & Yuan             Expires 26 September 2026              [Page 11]


  Internet-Draft                     AIP                        March 2026


        The default TTL is 8.  Valid range is 0-15.  A TTL of 0 means the
        message MUST NOT be relayed; it is delivered only if the
        destination is local.

     Flags (4 bits)  A bitmask of control flags:

         +=======+=======+======+=======================================+
         | Bit   | Value | Name | Description                           |
         +=======+=======+======+=======================================+
         | 3     | 0x8   | SIG  | Message carries an Ed25519 signature  |
         | (MSB) |       |      | (64 octets) appended after the        |
         |       |       |      | payload.                              |
         +-------+-------+------+---------------------------------------+
         | 2     | 0x4   | ERR  | Error report requested.  If delivery  |
         |       |       |      | fails, an ERROR message SHOULD be     |
         |       |       |      | returned to the source.               |
         +-------+-------+------+---------------------------------------+
         | 1     | 0x2   | SEM  | Semantic resolution provenance.  When |
         |       |       |      | clear, AIP performs exact URI         |
         |       |       |      | resolution (the baseline).  When set, |
         |       |       |      | the message was delivered via         |
         |       |       |      | resolver-assisted semantic discovery: |
         |       |       |      | AIP resolved a natural-language query |
         |       |       |      | through DISCOVER before transmission. |
         |       |       |      | The Destination URI field carries the |
         |       |       |      | resolved agent:// URI; the original   |
         |       |       |      | query is recorded in the SemQuery     |
         |       |       |      | option (Type 5, Section 4.3).         |
         |       |       |      | Whether the resolver supports         |
         |       |       |      | semantic resolution is deployment-    |
         |       |       |      | specific (see Section 5.2).           |
         +-------+-------+------+---------------------------------------+
         | 0     | 0x1   | RLY  | Relay permitted.  If set,             |
         | (LSB) |       |      | intermediate nodes MAY forward this   |
         |       |       |      | message toward the destination.       |
         +-------+-------+------+---------------------------------------+

                              Table 3: AIP Flag Bits

     Reserved (8 bits)  Reserved for future use.  Senders MUST set this
        field to zero.  Receivers MUST ignore this field.

     Message ID (32 bits)  A sender-assigned identifier for deduplication
        and request-response correlation.  Implementations MUST ensure
        uniqueness among outstanding messages to the same destination.  A
        monotonically increasing counter is one possible strategy.

     Payload Length (32 bits)  The length in octets of the payload (not



  Song & Yuan             Expires 26 September 2026              [Page 12]


  Internet-Draft                     AIP                        March 2026


        including the header, address block, or options).  Maximum value
        is 65535; implementations MUST reject messages with Payload Length
        exceeding 65535.

     Src URI Len (8 bits)  The length in octets of the wire-encoded Source
        URI.  A value of 0 is permitted only in ERROR messages (system-
        generated error with no agent source).  Maximum 255.

     Dst URI Len (8 bits)  The length in octets of the wire-encoded
        Destination URI.  MUST NOT be 0.  Maximum 255.

     Options Length (16 bits)  The total length in octets of the TLV
        options region, including any padding.  If no options are present,
        this field is 0.  Maximum 65535.  The options region MUST be
        padded to a 4-octet boundary.

     Source URI (variable, 0-255 octets)  The agent:// URI of the sender
        in wire-encoded form (without the "agent://" prefix).

     Destination URI (variable, 1-255 octets)  The agent:// URI of the
        intended recipient in wire-encoded form (without the "agent://"
        prefix).  This field always contains a valid wire-encoded agent://
        URI, regardless of whether the SEM flag is set.  When the SEM flag
        is set, AIP resolves the query before transmission and places the
        resolved URI here; the original query is carried in the SemQuery
        option (Section 4.3).

     Address Padding (0-3 octets)  Zero-valued padding octets added after
        the Destination URI to bring the combined address block (Src URI +
        Dst URI + padding) to a 4-octet boundary.

  4.3.  TLV Options

     The options region carries zero or more Type-Length-Value (TLV)
     encoded options.  Options provide extensibility without modifying the
     fixed header.

     Each option is encoded as:

     +--------+--------+----------------------------+
     |  Type  | Length  |    Data (Length octets)     |
     +--------+--------+----------------------------+
       1 byte   1 byte    variable

     Exception: Type 0 (Pad1) is a single zero octet with no Length or
     Data fields; it is used for single-octet alignment padding.





  Song & Yuan             Expires 26 September 2026              [Page 13]


  Internet-Draft                     AIP                        March 2026


     +=========+===========+==========+=================================+
     | Type    | Name      | Length   | Description                     |
     +=========+===========+==========+=================================+
     | 0       | Pad1      | 0        | Single-octet padding (no Length |
     |         |           |          | field).                         |
     +---------+-----------+----------+---------------------------------+
     | 1       | PadN      | N        | Multi-octet padding (N zero     |
     |         |           |          | octets).                        |
     +---------+-----------+----------+---------------------------------+
     | 2       | Timestamp | 8        | UTC Unix timestamp in           |
     |         |           |          | microseconds (uint64, big-      |
     |         |           |          | endian).  Used for latency      |
     |         |           |          | measurement and replay          |
     |         |           |          | rejection.                      |
     +---------+-----------+----------+---------------------------------+
     | 3       | Trace     | variable | Opaque trace context blob for   |
     |         |           |          | distributed tracing.            |
     |         |           |          | Implementations MAY use W3C     |
     |         |           |          | Trace Context traceparent       |
     |         |           |          | format or any other tracing     |
     |         |           |          | scheme.                         |
     +---------+-----------+----------+---------------------------------+
     | 4       | Priority  | 1        | Message priority hint (0 =      |
     |         |           |          | lowest, 255 = highest).         |
     |         |           |          | Receivers MAY use this for      |
     |         |           |          | scheduling.                     |
     +---------+-----------+----------+---------------------------------+
     | 5       | SemQuery  | variable | UTF-8 semantic query string.    |
     |         |           |          | MUST be present when the SEM    |
     |         |           |          | flag is set; MUST NOT be        |
     |         |           |          | present when the SEM flag is    |
     |         |           |          | clear.  Records the original    |
     |         |           |          | natural-language query used for |
     |         |           |          | resolver-assisted discovery.    |
     +---------+-----------+----------+---------------------------------+
     | 6-127   |           |          | Available for future assignment |
     |         |           |          | (IANA).                         |
     +---------+-----------+----------+---------------------------------+
     | 128-254 |           |          | Available for experimental /    |
     |         |           |          | private use.                    |
     +---------+-----------+----------+---------------------------------+
     | 255     |           |          | Reserved.                       |
     +---------+-----------+----------+---------------------------------+

                        Table 4: Standard AIP Options






  Song & Yuan             Expires 26 September 2026              [Page 14]


  Internet-Draft                     AIP                        March 2026


     The entire options region MUST be padded to a 4-octet boundary using
     Pad1 or PadN options.  Implementations MUST ignore unrecognized
     option types (skip by reading Type and Length, then advancing Length
     octets).

  4.4.  Message Signature

     When the SIG flag (bit 3) is set, the message carries a 64-octet
     Ed25519 signature appended immediately after the payload.  The
     signature MUST NOT be included in the Payload Length field; receivers
     detect its presence via the SIG flag.

     The signature is computed over:

     sign_input = fixed_header (16 octets, with Reserved set to 0)
                || src_uri_wire
                || dst_uri_wire
                || options_data (without padding)
                || payload

     The signing key is the Ed25519 private key corresponding to the
     source agent's identity.  Verification uses the public key bound to
     the source agent:// URI; the receiver obtains this key from its local
     resolver (see Section 9.2).  The node's link-layer Peer ID is used
     only for message delivery, not for signature verification.

     Implementations SHOULD set the SIG flag on all messages in production
     deployments.  Implementations MUST verify signatures on incoming SIG-
     flagged messages and MUST discard messages with invalid signatures.

  5.  Local Resolver

     AIP delegates all name resolution to a local resolver service.  The
     resolver maps agent:// URIs to peer IDs that AIP can use for link-
     layer transmission.

     AIP makes no assumptions about resolver internals.  Any service that
     satisfies the Resolver interface (Section 5.1) is acceptable.  ANS
     [I-D.song-anp-ans] is one companion resolver architecture.

  5.1.  Resolver Interface

     The resolver MUST provide:

     RESOLVE(uri) -> (peer_id, ok)  Maps a fully-qualified agent:// URI to
        a peer ID.  Returns ok = false if the URI cannot be resolved.

     IS_LOCAL(uri) -> bool  Returns true if the URI is registered by an



  Song & Yuan             Expires 26 September 2026              [Page 15]


  Internet-Draft                     AIP                        March 2026


        agent on the local node.

     The resolver MAY use any local data structure (cache, table, or
     database) to satisfy these operations.  AIP does not constrain
     resolver internals, storage model, propagation mechanism, or ranking
     method.  Additional resolver operations such as registration and
     unregistration are outside AIP's scope and are defined by the
     resolver specification.

  5.2.  Optional Semantic Resolver Extension

     A resolver MAY additionally support the following operation for use
     with the SEM flag (Section 6.2):

     DISCOVER(query, tags, namespace, limit) -> list of (uri, peer_id,
     score)  Maps a natural-language query to a ranked list of matching
        agents.  A resolver that does not support semantic resolution MUST
        return an empty list.

     Implementations that do not support semantic resolution are fully
     conformant with this specification.

  5.3.  Requirements on Implementations

     Every AIP module MUST be initialized with a resolver.  If no full
     resolver is available, a minimal implementation that only supports
     exact lookup of locally registered URIs is sufficient.

     The resolver SHOULD cache results to avoid repeated lookups for the
     same URI.  Cache entries SHOULD expire based on a TTL provided by the
     resolver.  Implementations MUST enforce a maximum cache size to
     prevent unbounded memory growth; deployment-specific defaults are
     expected.

  6.  Name Resolution

     AIP resolves destination URIs by calling the local resolver
     (Section 5.1).  Baseline AIP operation uses exact destination tokens;
     resolver-assisted semantic discovery is an optional extension that
     occurs before forwarding.  Once a destination URI has been selected,
     AIP forwarding proceeds identically in both cases.

     The resolution strategy depends on the SEM flag:








  Song & Yuan             Expires 26 September 2026              [Page 16]


  Internet-Draft                     AIP                        March 2026


  6.1.  Exact Resolution (SEM flag clear)

     When the SEM flag is clear, the Destination URI is a fully- qualified
     agent:// URI.  AIP calls RESOLVE(uri) on the local resolver.  If the
     resolver returns ok = true, AIP uses the returned peer ID for
     transmission.  If ok = false, AIP returns NAME_NOT_FOUND to the upper
     layer.

     The resolver MAY use local or distributed mechanisms to satisfy the
     lookup; these mechanisms are outside AIP's scope.

  6.2.  Semantic Resolution (SEM flag set) -- Optional Extension

     Semantic resolution is an *optional extension*.  AIP implementations
     are fully conformant without it.  A resolver that does not support
     semantic resolution MUST return an empty list from DISCOVER, causing
     AIP to return NAME_NOT_FOUND.

     When the SEM flag is set and the resolver supports semantic
     resolution, AIP calls DISCOVER(query, ...) on the local resolver and
     uses the highest-scoring result.  AIP places the resolved agent://
     URI in the Destination URI field and records the original query
     string in the SemQuery option (Type 5).  If the resolver returns an
     empty list, AIP returns NAME_NOT_FOUND to the upper layer.

     AIP does not specify any particular scoring algorithm.  The scoring
     strategy -- including text similarity, tag matching, freshness, and
     trust signals -- is defined by the resolver implementation.
     Appendix A provides an informative example using one possible scoring
     formula.

     A failed semantic query (empty result list) causes AIP to return
     NAME_NOT_FOUND.  AIP does not perform query rewriting, fallback
     searches, or multi-step retrieval; such behavior, if desired, is the
     responsibility of the resolver or the application.

     After resolution, AIP performs ordinary exact-URI delivery; semantic
     interpretation is confined to resolver selection and is not part of
     the forwarding semantics.  The SEM flag does not alter forwarding
     behavior; it records resolver-assisted destination selection
     provenance for policy, debugging, and audit purposes.










  Song & Yuan             Expires 26 September 2026              [Page 17]


  Internet-Draft                     AIP                        March 2026


  7.  Message Processing

     This section defines AIP's complete processing model.  The send and
     receive paths described below are self-contained: they depend only on
     the local resolver interface (Section 5.1) and the link-layer
     TRANSMIT/DELIVER primitives (Section 8.2).  No knowledge of companion
     protocols is required to implement these paths.

  7.1.  Sending

     When the upper layer calls SEND:

     1.  *Validate the source URI.*

         The source URI MUST be locally registered (IS_LOCAL returns
         true).  If not, the send operation MUST fail.

     2.  *Resolve the destination.*

         If the SEM flag is clear, call RESOLVE(destination) on the local
         resolver.  If the SEM flag is set, call DISCOVER(destination,
         ...) and use the highest-scoring result; place the resolved
         agent:// URI in the Destination URI field and record the original
         query in a SemQuery option (Type 5).  If resolution fails, return
         NAME_NOT_FOUND to the upper layer.

     3.  *Construct the message.*

         Build the 16-octet fixed header with Version = 1, Type, Protocol,
         TTL (default 8), Flags, Reserved = 0, auto- generated Message ID,
         Payload Length.  Wire-encode source and destination URIs.  Encode
         any options (including the SemQuery option if SEM flag is set).

     4.  *Sign (if SIG flag set).*

         Compute the Ed25519 signature per Section 4.4 and append it after
         the payload.

     5.  *Transmit.*

         Serialize and call the link layer's TRANSMIT with the resolved
         peer ID and the serialized bytes.

  7.2.  Receiving

     When the link layer delivers bytes:

     1.  *Parse and validate.*



  Song & Yuan             Expires 26 September 2026              [Page 18]


  Internet-Draft                     AIP                        March 2026


         Decode fixed header.  If Version is unrecognized, discard.  If
         Type is unrecognized, discard.  If the total data is shorter than
         the computed message size, discard.

     2.  *Verify signature (if SIG flag set).*

         Extract the 64-byte signature.  Verify against the public key
         bound to the source agent:// URI, as obtained from the local
         resolver (see Section 9.2).  If verification fails, discard.  If
         ERR flag is set, SHOULD send INVALID_SIGNATURE error.

     3.  *Deduplicate.*

         Check (Source URI, Message ID) against a bounded deduplication
         cache.  If a match exists, discard.  Otherwise, add to cache.

     4.  *Check TTL.*

         If TTL is 0 and destination is not local, discard.  If ERR flag
         is set, send TTL_EXPIRED error.

     5.  *Deliver or relay.*

         If IS_LOCAL(destination) returns true, decrement TTL and dispatch
         to the upper-layer handler identified by the Protocol field.  If
         not local and RLY flag is set and TTL > 0, decrement TTL, call
         RESOLVE(destination) to obtain the next-hop peer, and re-
         transmit.  If not local and RLY is not set, discard.

  7.3.  Error Handling

     When an error occurs and the ERR flag is set, the AIP module SHOULD
     generate an ERROR message (Type = 1) to the original source.  ERROR
     generation is best-effort; it is not guaranteed and MAY itself be
     suppressed under overload or resource constraints.  ERROR messages
     MUST NOT be generated in response to other ERROR messages (preventing
     loops).

     The error payload is encoded as:

     +--------+--------+--------+--------+--------+---...---+
     |  Code  | Reservd|     Original Message ID   | Detail  |
     +--------+--------+--------+--------+--------+---...---+
       1 byte   1 byte        4 bytes              variable







  Song & Yuan             Expires 26 September 2026              [Page 19]


  Internet-Draft                     AIP                        March 2026


         +=======+===================+==============================+
         | Code  | Name              | Description                  |
         +=======+===================+==============================+
         | 0     |                   | Reserved (MUST NOT be used). |
         +-------+-------------------+------------------------------+
         | 1     | NAME_NOT_FOUND    | Destination URI could not be |
         |       |                   | resolved.                    |
         +-------+-------------------+------------------------------+
         | 2     | TTL_EXPIRED       | Message TTL reached zero     |
         |       |                   | before delivery.             |
         +-------+-------------------+------------------------------+
         | 3     | MSG_TOO_LARGE     | Message exceeds maximum size |
         |       |                   | (65535 octets payload).      |
         +-------+-------------------+------------------------------+
         | 4     | INVALID_SIGNATURE | Ed25519 signature            |
         |       |                   | verification failed.         |
         +-------+-------------------+------------------------------+
         | 5     | RATE_LIMITED      | Sender exceeded rate limit.  |
         +-------+-------------------+------------------------------+
         | 6     | PROTOCOL_ERROR    | Malformed message or         |
         |       |                   | protocol violation.          |
         +-------+-------------------+------------------------------+
         | 7     | SHUTTING_DOWN     | Receiving node is shutting   |
         |       |                   | down gracefully.             |
         +-------+-------------------+------------------------------+
         | 8     | INTERNAL_ERROR    | Unspecified internal         |
         |       |                   | processing error.            |
         +-------+-------------------+------------------------------+
         | 9-255 |                   | Available for future         |
         |       |                   | assignment (IANA).           |
         +-------+-------------------+------------------------------+

                           Table 5: AIP Error Codes

     The Original Message ID field MUST carry the full 32-bit Message ID
     of the message that triggered the error, enabling precise
     correlation.  The Detail field is a UTF-8 string providing additional
     context; it MAY be empty.

  7.4.  Deduplication

     In a GossipSub topology, messages may arrive via multiple paths.
     Implementations MUST maintain a deduplication cache keyed by (Source
     URI, Message ID).  Messages matching a cache entry MUST be silently
     discarded.  Implementations MUST bound the cache size and entry
     lifetime to prevent unbounded resource consumption; deployment-
     specific defaults are expected.




  Song & Yuan             Expires 26 September 2026              [Page 20]


  Internet-Draft                     AIP                        March 2026


  7.5.  Rate Limiting

     Implementations MUST enforce per-peer rate limiting to prevent
     denial-of-service.  Specific thresholds are deployment-specific;
     implementations SHOULD document their default values.  Messages
     exceeding the rate limit SHOULD be discarded; if the ERR flag is set,
     a RATE_LIMITED error SHOULD be returned.

  8.  Interfaces

  8.1.  Upper Layer Interface (AITP and others)

     AIP provides the following service primitives to upper-layer
     protocols:

     SEND(source, destination, protocol, payload, options) ->
     message_id  Sends a datagram.

        *  *source* -- agent:// URI.  MUST be locally registered.

        *  *destination* -- an agent:// URI token for baseline delivery;
           when the SEM flag is requested, the caller MAY provide a
           semantic query string, which the local resolver MUST resolve to
           an agent:// URI before transmission.

        *  *protocol* -- upper-layer protocol number (0-255).

        *  *payload* -- opaque bytes.

        *  *options* -- optional: type, ttl, flags, message_id, TLV
           options list.

        Returns: Message ID, or error.

     RECEIVE callback(source, destination, protocol, payload,
     message_id, options)  Invoked when a message arrives for a locally
        registered agent.  The Protocol field identifies which upper-layer
        handler receives the callback.

     Note: Registration, unregistration, and semantic discovery are
     resolver operations, not AIP primitives.

  8.2.  Lower Layer Interface (Link Layer)

     TRANSMIT(peer_id, raw_bytes)  Sends bytes to a peer.  The link layer
        routes them using whatever technology is available (libp2p, TCP,
        QUIC, WS, Bluetooth, etc.).




  Song & Yuan             Expires 26 September 2026              [Page 21]


  Internet-Draft                     AIP                        March 2026


     DELIVER callback(peer_id, raw_bytes)  Invoked by the link layer for
        each received message.  AIP registers this callback during
        initialization.

     AIP makes no assumptions about the link layer beyond these two
     primitives.

  9.  Security Considerations

  9.1.  Message Authentication

     When the SIG flag is set, AIP messages carry an Ed25519 signature
     providing origin authentication and integrity protection.
     Implementations SHOULD set the SIG flag on all messages.
     Implementations MUST verify signatures before processing signed
     messages and MUST discard messages with invalid signatures.

     Signature verification is performed against the public key bound to
     the source agent:// URI; node Peer IDs are link- layer artifacts and
     are not used for application-layer signature verification.  The
     receiver obtains the URI-to-key binding from its local resolver (see
     Section 9.2).

  9.2.  Identity and Signing Key Relationship

     Each agent possesses its own Ed25519 key pair.  A node's link-layer
     Peer ID is derived from one Ed25519 public key, but multiple agents
     MAY run on a single node, each with a distinct key pair and agent://
     URI.

     When multiple agents share a node, the message signature binds the
     payload to the *agent's* key, not the node's Peer ID.  The receiver
     obtains the agent's public key from the resolver (which maintains the
     URI-to-public-key binding).

     Relay nodes that forward messages on behalf of others need not verify
     the signature; only the final destination endpoint MUST verify.
     Relay nodes MAY verify opportunistically if they have access to the
     signing key.

  9.3.  Name Spoofing

     AIP relies on the resolver to verify that agent:// URIs are bound to
     legitimate Ed25519 public keys.  The specifics of name registration
     verification are defined by the resolver specification.






  Song & Yuan             Expires 26 September 2026              [Page 22]


  Internet-Draft                     AIP                        March 2026


  9.4.  Resolution Poisoning

     A malicious resolver could return forged peer IDs, directing messages
     to an attacker.  Mitigations:

     *  Implementations SHOULD use the SIG flag so that receivers can
        verify message authenticity independent of resolution correctness.

     *  Resolver implementations SHOULD require Ed25519 signatures on all
        name entries.

  9.5.  Replay Attacks

     Mitigated by:

     *  Deduplication cache: (Source URI, Message ID) pairs.

     *  TTL: bounded hop count limits propagation.

     *  Timestamp option: implementations SHOULD include the Timestamp
        option and reject messages outside a deployment-specific freshness
        window.

  9.6.  Resource Exhaustion

     Per-peer rate limiting (Section 7.5), maximum message size (65535
     octets), and resolver cache capacity limits prevent resource
     exhaustion.

  9.7.  Semantic Resolution Gaming

     When the SEM flag is used, the quality of results depends on the
     resolver's scoring algorithm.  Resolver implementations SHOULD
     incorporate anti-gaming measures such as trust signals and keyword-
     repetition dampening.  These defenses are outside AIP's scope and are
     defined by the resolver specification.

     If the SEM flag is set but the SemQuery option is absent or
     malformed, implementations MUST treat the message as a protocol error
     and discard it.  When the SIG flag is also set, the SemQuery option
     is covered by the signed message envelope, protecting provenance
     integrity.









  Song & Yuan             Expires 26 September 2026              [Page 23]


  Internet-Draft                     AIP                        March 2026


  9.8.  Privacy

     Agent:// URIs, resolver metadata, and message headers are visible to
     network participants.  AIP does not provide payload confidentiality
     (AITP's responsibility) or metadata privacy.  Applications requiring
     metadata privacy SHOULD use privacy-preserving lower-layer routing
     mechanisms.

  10.  IANA Considerations

     This document requests the creation of four new IANA registries and
     the registration of a URI scheme.

  10.1.  URI Scheme Registration: agent

     Per [RFC7595], the "agent" URI scheme is registered as follows:

     Scheme name  agent

     Status  Provisional

     Applications/protocols that use this scheme  Agent Internet Protocol
        (AIP), Agent Invocation Transport Protocol (AITP), Agent Name
        System (ANS).

     Contact  Jinke Song <ink@chatchat.space>

     Change controller  Jinke Song <ink@chatchat.space>

     Reference  [this document], Section 3

  10.2.  AIP Message Type Registry

     Registry with 4-bit values (0-15).  Registration policy:
     Specification Required.  Initial values in Table 1.

  10.3.  AIP Protocol Number Registry

     Registry with 8-bit values (0-255).  Registration policy:
     Specification Required for 4-127, First Come First Served for
     128-254.  Value 255 is reserved for experimental use.  Initial values
     in Table 2.

  10.4.  AIP Error Code Registry

     Registry with 8-bit values (0-255).  Value 0 reserved (MUST NOT use).
     Registration policy: Specification Required.  Initial values in
     Table 5.



  Song & Yuan             Expires 26 September 2026              [Page 24]


  Internet-Draft                     AIP                        March 2026


  10.5.  AIP Flag Bits Registry

     Registry with 4 bit positions (0-3).  Registration policy:
     Specification Required.  Initial values in Table 3.

  10.6.  AIP Option Type Registry

     Registry with 8-bit values (0-255).  Registration policy:
     Specification Required for 0-127, First Come First Served for
     128-254, value 255 reserved.  Initial values in Table 4.

  11.  Implementation Status

     Per [RFC7942], this section records known implementations.

  11.1.  ClawNet

     Organization  ChatChatTech

     URL  https://github.com/ChatChatTech/ClawNet

     Description  Go implementation of the full ANP suite.  The AIP module
        (aip/ directory) implements the 16-octet fixed header, Protocol
        field demux, TLV options, local resolver interface, Ed25519
        signature support, and deduplication cache.  The reference
        implementation is being completed as part of the full ClawNet
        stack conforming to AIP, ANS, AITP, and ADP; protocol boundaries
        are exercised in integration tests across the stack.

     Maturity  Alpha

     Coverage  Implemented in current prototype:

        *  16-octet header, Protocol demux, TLV option codec

        *  Local resolver interface, SEM flag delegation

        *  Deduplication cache, source URI validation, relay counting

        *  Message signature support (SIG flag codec)

        *  Max payload validation (65535)

        Under integration; expected complete before final publication
        candidate:

        *  Ed25519 signature verification on receive




  Song & Yuan             Expires 26 September 2026              [Page 25]


  Internet-Draft                     AIP                        March 2026


        *  Per-peer rate limiting

        *  Timestamp replay rejection

        The items above affect robustness and enforcement behavior; they
        do not alter the wire format, message semantics, or protocol
        boundaries defined in this document.

     Language  Go

     License  Open source

     Contact  ink@chatchat.space

  12.  References

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

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

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

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

  12.2.  Informative References

     [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/info/rfc791>.




  Song & Yuan             Expires 26 September 2026              [Page 26]


  Internet-Draft                     AIP                        March 2026


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

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

     [I-D.song-anp-aitp]
                Song, J., "Agent Invocation Transport Protocol (AITP)",
                Work in Progress, Internet-Draft, draft-song-anp-aitp-00,
                March 2026, <https://datatracker.ietf.org/doc/html/draft-
                song-anp-aitp-00>.

     [I-D.song-anp-ans]
                Song, J., "Agent Name System (ANS)", Work in Progress,
                Internet-Draft, draft-song-anp-ans-00, March 2026,
                <https://datatracker.ietf.org/doc/html/draft-song-anp-ans-
                00>.

     [I-D.song-anp-adp]
                Song, J., "Agent Description Protocol (ADP)", Work in
                Progress, Internet-Draft, draft-song-anp-adp-00, March
                2026, <https://datatracker.ietf.org/doc/html/draft-song-
                anp-adp-00>.

  Appendix A.  Example Resolver Scoring (Informative)

     This appendix is entirely informative.  It does not define any
     normative behavior and does not constrain AIP interoperability.
     Implementations are free to use any scoring strategy or none at all.

     This appendix illustrates one possible scoring strategy that a
     semantic resolver could use.  AIP does not mandate any particular
     scoring algorithm; this example is provided for implementers'
     reference.

     The composite score for each candidate is computed as a weighted sum
     of five components:

     score = w_text  * S_text      (BM25 text similarity, k1=1.2, b=0.75)
           + w_tag   * S_tag       (Jaccard tag overlap)
           + w_ns    * S_ns        (namespace match)
           + w_fresh * S_fresh     (1 / (1 + age_hours))
           + w_trust * S_trust     (trust score / max_trust)

     Example weights: 0.4, 0.3, 0.05, 0.05, 0.2 (sum = 1.0).



  Song & Yuan             Expires 26 September 2026              [Page 27]


  Internet-Draft                     AIP                        March 2026


     Worked example with three resolver entries:

     +=+===================+==============+==============+======+=======+
     |#| URI               | Description  | Skills       | Age  | Trust |
     +=+===================+==============+==============+======+=======+
     |1| agent://acme/fr-  | French to    | translation, | 2h   | 0.85  |
     | | translator        | English      | french,      |      |       |
     | |                   | translation  | english      |      |       |
     | |                   | service      |              |      |       |
     +-+-------------------+--------------+--------------+------+-------+
     |2| agent://babel/    | Universal    | translation, | 0.5h | 0.92  |
     | | universal         | text         | multilingual |      |       |
     | |                   | translator,  |              |      |       |
     | |                   | 50 languages |              |      |       |
     +-+-------------------+--------------+--------------+------+-------+
     |3| agent://research/ | Academic     | research,    | 1h   | 0.70  |
     | | paper-search      | paper search | search       |      |       |
     | |                   | and          |              |      |       |
     | |                   | retrieval    |              |      |       |
     +-+-------------------+--------------+--------------+------+-------+

                      Table 6: Example Resolver Entries

     Query: "translate French text", tags: ["translation", "french"],
     max_poi = 0.92.

  Component scores:

            S_text  S_tag   S_ns  S_fresh          S_trust
  Entry 1:  1.000   0.667   0     1/(1+2.0)=0.333  0.85/0.92=0.924
  Entry 2:  0.664   0.333   0     1/(1+0.5)=0.667  0.92/0.92=1.000
  Entry 3:  0.096   0.000   0     1/(1+1.0)=0.500  0.70/0.92=0.761

  Composite (w_text=0.4, w_tag=0.3, w_ns=0.05, w_fresh=0.05, w_trust=0.2):

  Entry 1: 0.4*1.000 + 0.3*0.667 + 0.05*0 + 0.05*0.333 + 0.2*0.924
         = 0.400 + 0.200 + 0.000 + 0.017 + 0.185 = 0.802

  Entry 2: 0.4*0.664 + 0.3*0.333 + 0.05*0 + 0.05*0.667 + 0.2*1.000
         = 0.266 + 0.100 + 0.000 + 0.033 + 0.200 = 0.599

  Entry 3: 0.4*0.096 + 0.3*0.000 + 0.05*0 + 0.05*0.500 + 0.2*0.761
         = 0.038 + 0.000 + 0.000 + 0.025 + 0.152 = 0.215

     Result: Entry 1 (0.802) > Entry 2 (0.599) > Entry 3 (0.215).  All
     above threshold (0.1).





  Song & Yuan             Expires 26 September 2026              [Page 28]


  Internet-Draft                     AIP                        March 2026


  Appendix B.  Network Bootstrap (Informative)

     This appendix is entirely informative.  It describes a recommended
     bootstrap sequence for a new agent joining an ANP network for the
     first time.  The steps below depend on companion protocols (AITP,
     ANS, ADP) and link-layer infrastructure; they do not alter AIP's wire
     format or processing rules.

  B.1.  Bootstrap Sequence

     1.  *Key Generation.*

         The agent generates an Ed25519 key pair.  The public key derives
         the node's link-layer Peer ID.  This step is entirely local and
         requires no network interaction.

     2.  *Seed Peer Discovery.*

         The agent obtains the Peer IDs and network addresses of one or
         more seed peers (also called bootstrap nodes).  Seed information
         may come from a compiled-in bootstrap list, a DNS SRV record (see
         ANS [I-D.song-anp-ans], Appendix A), a well-known URI, an out-of-
         band configuration file, or manual input.  At least one seed peer
         must be reachable for the remaining steps.

     3.  *Link-Layer Connection.*

         The agent's link-layer module (e.g., libp2p) establishes a
         transport connection to a seed peer using the seed's Peer ID and
         address.  Upon connection, mutual peer authentication occurs at
         the link layer (e.g., Noise handshake in libp2p).

     4.  *DHT Join.*

         The agent joins the Kademlia DHT through the seed peer,
         populating its routing table.  After this step, the agent can
         perform DHT get/put operations.

     5.  *Name Registration.*

         The agent constructs an ANS Name Record binding its chosen
         agent:// URI to its Peer ID, signs it, and submits it via
         ans.register (carried over AITP with Protocol = 1).  The
         receiving peer validates the signature and stores the record.
         The agent also publishes the record to the DHT and announces it
         via GossipSub.

     6.  *Agent Card Publication.*



  Song & Yuan             Expires 26 September 2026              [Page 29]


  Internet-Draft                     AIP                        March 2026


         The agent constructs an ADP Agent Card describing its
         capabilities and publishes it via adp.advertise (carried over
         AITP, Protocol = 1).  The Agent Card is also stored in the DHT
         under the /clawnet-profile/ namespace.

     7.  *Normal Operation.*

         The agent's local resolver is now populated with at least one
         cached peer (the seed).  AIP can send and receive datagrams.
         AITP associations can be established with any resolved peer.  The
         agent is fully operational.

  B.2.  Minimal Bootstrap

     Steps 5 and 6 are not required for baseline AIP operation.  An agent
     that only needs to reach peers by known agent:// URIs can skip name
     registration and Agent Card publication and rely on DHT resolution of
     other agents' names.

     Conversely, an agent that cannot reach any seed peer cannot join the
     network.  AIP itself does not solve seed discovery; implementations
     MUST provide at least one bootstrap mechanism (compiled-in list, DNS,
     manual configuration) as part of their deployment profile.

  Appendix C.  Implementation Alignment Notes

     This appendix documents the relationship between this specification
     and the reference implementation in the ClawNet aip/ directory.

     +============+=============================+========================+
     | Spec       | Go Symbol                   | Notes                  |
     | Concept    |                             |                        |
     +============+=============================+========================+
     | Message    | aip.MessageType             | TypeData(0),           |
     | Type       |                             | TypeError(1),          |
     |            |                             | TypePing(2),           |
     |            |                             | TypePong(3).           |
     +------------+-----------------------------+------------------------+
     | Protocol   | aip.Protocol                | ProtoNone(0),          |
     | Number     |                             | ProtoAITP(1),          |
     |            |                             | ProtoANS(2),           |
     |            |                             | ProtoADP(3),           |
     |            |                             | ProtoExpt(255).        |
     |            |                             | (Go source still       |
     |            |                             | uses ProtoATP as a     |
     |            |                             | legacy alias.)         |
     +------------+-----------------------------+------------------------+
     | Flags      | aip.Flags                   | FlagRly(0x1),          |



  Song & Yuan             Expires 26 September 2026              [Page 30]


  Internet-Draft                     AIP                        March 2026


     |            |                             | FlagSem(0x2),          |
     |            |                             | FlagErr(0x4),          |
     |            |                             | FlagSig(0x8).          |
     +------------+-----------------------------+------------------------+
     | Error Code | aip.ErrorCode               | Full 9-code set.       |
     +------------+-----------------------------+------------------------+
     | Fixed      | fixedHeaderSize = 16        | Byte layout per        |
     | Header     |                             | Figure 1.              |
     +------------+-----------------------------+------------------------+
     | Options    | aip.Option,                 | TLV encoding with      |
     |            | OptPad1..OptPriority        | 4-byte alignment.      |
     +------------+-----------------------------+------------------------+
     | Max        | aip.MaxPayloadSize = 65535  | Enforced in            |
     | payload    |                             | Marshal() and          |
     |            |                             | Unmarshal().           |
     +------------+-----------------------------+------------------------+
     | Local      | aip.LocalResolver           | Implements the         |
     | resolver   | (internal)                  | Resolver interface.    |
     |            |                             | BM25 scoring, LRU      |
     |            |                             | eviction.  The Go      |
     |            |                             | type name is an        |
     |            |                             | implementation         |
     |            |                             | detail; AIP does       |
     |            |                             | not prescribe          |
     |            |                             | resolver internals.    |
     +------------+-----------------------------+------------------------+
     | SEM flag   | Module.Send()               | Delegates to           |
     | resolution |                             | resolver's             |
     |            |                             | Discover() when        |
     |            |                             | FlagSem is set.        |
     +------------+-----------------------------+------------------------+
     | URI        | aip.ParseURI("agent://...") | Validates agent://     |
     | parsing    |                             | prefix, ident          |
     |            |                             | regex.                 |
     +------------+-----------------------------+------------------------+

                      Table 7: Spec-Implementation Mapping

  Appendix D.  AIP in Isolation (Informative)

     This appendix is entirely informative.  It illustrates a minimal end-
     to-end message exchange using only AIP primitives, without expanding
     the internals of any companion protocol.

     *Scenario:* Agent A wants to send an AITP payload to
     agent://translation/fr-ja.  The local resolver already has a cached
     mapping for that URI.




  Song & Yuan             Expires 26 September 2026              [Page 31]


  Internet-Draft                     AIP                        March 2026


     1.  Agent A calls SEND(source="agent://acme/requester",
         destination="agent://translation/fr-ja", protocol=1, payload=...,
         flags={SIG, RLY, ERR}).

     2.  AIP calls IS_LOCAL("agent://acme/requester") -> true.  Source
         validation passes.

     3.  AIP calls RESOLVE("agent://translation/fr-ja") on the local
         resolver.  The resolver returns (peer_id=0xABCD..., ok=true) from
         its cache.  No distributed lookup is needed.

     4.  AIP constructs a DATA message: Version=1, Type=DATA,
         Protocol=AITP(1), TTL=8, Flags=0xD (SIG|ERR|RLY), Message ID=42,
         Payload Length=N.  Source and destination URIs are wire-encoded
         (prefix stripped).

     5.  AIP computes the Ed25519 signature over the header, URIs,
         options, and payload; appends the 64-byte signature.

     6.  AIP calls TRANSMIT(peer_id=0xABCD..., serialized_bytes) on the
         link layer.

     7.  At the receiving node, the link layer calls DELIVER.  AIP parses
         the header, verifies the signature against the public key bound
         to agent://acme/requester, checks deduplication, confirms
         IS_LOCAL("agent://translation/fr-ja") = true, and dispatches the
         payload to the Protocol=1 (AITP) handler.

     At no point does AIP need to know how the resolver obtained its
     mapping, how AITP will process the payload, or what scoring strategy
     (if any) the resolver uses.  AIP's responsibilities are: validate,
     resolve, construct, sign, transmit, and on the receive side: parse,
     verify, dedup, check TTL, deliver or relay.

  Authors' Addresses

     Jinke Song
     Dept. of CSE, Hong Kong University of Science and Technology
     Email: ink@chatchat.space


     Mu Yuan
     Dept. of IE, The Chinese University of Hong Kong
     Email: muyuan@cuhk.edu.hk







  Song & Yuan             Expires 26 September 2026              [Page 32]


name: draft-serra-mcp-discovery-uri
rev: 04
title: The "mcp" URI Scheme and MCP Server Discovery Mechanism
time: 2026-03-26T14:33:21Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-27T14:33:21Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-05-22T09:24:48.589059+00:00
source: ietf
abstract:
  The Model Context Protocol (MCP) defines a standard interface for AI
     agents to connect to external tools and services. However, no
     standard mechanism exists for an AI agent to autonomously discover
     which web domains expose an MCP server.

     This document defines:

     (1) the "mcp" URI scheme, a machine-to-machine identifier for
         publicly reachable MCP servers;

     (2) a two-mode discovery mechanism: a well-known URI
         (/.well-known/mcp-server) for universal compatibility,
         and a DNS TXT record format for DNS-native fast discovery;

     (3) an optional manifest integrity mechanism using JSON Web
         Signatures (JWS, [RFC7515]) with keys published via DNS;

     (4) a security capability negotiation mechanism through which the
         manifest declares trust class, authentication requirements,
         compliance frameworks, and logging policy before connection.

     This specification does not define the MCP protocol itself, nor
     authentication between agent and server. Those are covered by the
     MCP specification and OAuth 2.1 respectively.

full_text:
  Internet-Draft                                              M. Serra
  draft-serra-mcp-discovery-uri-04                       Mumble Group
  Intended status: Informational                         25 March 2026
  Expires: 25 September 2026


          The "mcp" URI Scheme and MCP Server Discovery Mechanism
                    draft-serra-mcp-discovery-uri-04

  Abstract

     The Model Context Protocol (MCP) defines a standard interface for AI
     agents to connect to external tools and services. However, no
     standard mechanism exists for an AI agent to autonomously discover
     which web domains expose an MCP server.

     This document defines:

     (1) the "mcp" URI scheme, a machine-to-machine identifier for
         publicly reachable MCP servers;

     (2) a two-mode discovery mechanism: a well-known URI
         (/.well-known/mcp-server) for universal compatibility,
         and a DNS TXT record format for DNS-native fast discovery;

     (3) an optional manifest integrity mechanism using JSON Web
         Signatures (JWS, [RFC7515]) with keys published via DNS;

     (4) a security capability negotiation mechanism through which the
         manifest declares trust class, authentication requirements,
         compliance frameworks, and logging policy before connection.

     This specification does not define the MCP protocol itself, nor
     authentication between agent and server. Those are covered by the
     MCP specification and OAuth 2.1 respectively.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 25 September 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
         1.1.  Problem Statement
         1.2.  This Document
         1.3.  Design Principles
         1.4.  Relationship to Other Work
         1.5.  Requirements Language
         1.6.  Out of Scope
     2.  Terminology
     3.  The "mcp" URI Scheme
         3.1.  Purpose
         3.2.  Syntax
         3.3.  Examples
     4.  MCP Server Discovery
         4.1.  Operating Modes
         4.2.  Discovery Sequence
         4.3.  Conflict Resolution
     5.  DNS TXT Record Format
         5.1.  Syntax
         5.2.  Fields
         5.3.  Limitations
     6.  The MCP Server Manifest
         6.1.  Format
         6.2.  Required Fields
         6.3.  Recommended Fields (SHOULD)
         6.4.  Optional Fields (MAY)
         6.5.  Auth Object
         6.6.  Transport Values
         6.7.  Manifest Signature
         6.8.  Endpoint Domain Validation
         6.9.  Expires Field
         6.10. Security Capability Negotiation
             6.10.1. Overview
             6.10.2. The trust_class Field
             6.10.3. Mandatory Sub-Fields by trust_class
             6.10.4. The auth Object
             6.10.5. The compliance Object
             6.10.6. The logging Object
             6.10.7. Default Values and Omitted Fields
             6.10.8. Implementation Guidance for Non-Technical Operators
         6.11. Payment Advertisement
         6.12. Primitive Previews
             6.12.1. Tool Preview Object
             6.12.2. Resource Preview Object
             6.12.3. Prompt Preview Object
             6.12.4. Consistency Requirement
             6.12.5. Relationship to SEP-1649 and SEP-2127
         6.13. Minimal Example
         6.14. Full Example
         6.15. HTTP Response Requirements
     7.  Security Considerations
         7.1.  Manifest Spoofing
         7.2.  DNS Hijacking
         7.3.  Rate Limiting
         7.4.  Sensitive Data
         7.5.  Manifest Integrity via JWK Signature
     8.  IANA Considerations
         8.1.  URI Scheme Registration
         8.2.  Well-Known URI Registration
     9.  Reference Implementation
     10. References
         10.1. Normative References
         10.2. Informative References

  1.  Introduction

  1.1.  Problem Statement

     The Model Context Protocol [MCP-SPEC] defines how AI agents
     communicate with servers that expose tools, resources, and prompts.
     However, MCP does not define how an agent discovers that a server
     exists in the first place.  Given a web domain such as "example.com",
     there is no standard mechanism by which a conforming MCP client can
     autonomously determine whether an MCP server is available, where it
     is located, or what security posture it requires before connecting.

     This gap forces every MCP deployment to rely on out-of-band
     configuration: hardcoded endpoints, manually maintained registries,
     or proprietary discovery mechanisms.  At scale, this prevents
     autonomous agent operation and fragments interoperability across
     the ecosystem.

  1.2.  This Document

     This document defines:

     o  The "mcp" URI scheme, providing a standard machine-to-machine
        identifier for MCP servers (mcp://example.com).

     o  A JSON manifest published at a well-known HTTPS location
        (/.well-known/mcp-server), through which a server declares
        its endpoint, capabilities, and security requirements.

     o  A DNS TXT record format (_mcp.{host}) enabling DNS-native
        discovery for operators who control their DNS infrastructure.

     o  A resolution sequence clients MUST follow, with two explicit
        operating modes (Section 4):

          base mode:  .well-known only.  Works on any web server
                      with no DNS configuration required.

          fast mode:  DNS TXT first, .well-known for metadata
                      enrichment.  For operators who control DNS
                      and require faster, more reliable indexing.

     o  A security capability negotiation mechanism (Section 6.10),
        through which the manifest declares the server's trust class,
        authentication requirements, compliance frameworks, and
        logging policy before any connection is established.

  1.3.  Design Principles

     Three principles have guided the design of this specification:

     Secure by default.  A manifest with no explicit security
     declaration is treated as "trust_class: public" -- the most
     permissive safe posture.  More restrictive postures MUST be
     declared explicitly by the server operator.  Absence of a
     declaration is never interpreted as elevated privilege.

     Independently deployable layers.  This document defines the
     discovery and security negotiation layer only.  It does not
     define the MCP protocol itself, authentication flows beyond
     their advertisement in the manifest, or accountability
     mechanisms for tool call recording.  Each layer is deployable
     without the others.

     Accessible to non-technical operators.  The discovery mechanism
     is designed to be implementable by CMS plugins, shared hosting
     environments, and operators without DNS control.  The base mode
     requires installing a single JSON file.  The security capability
     negotiation is designed to be driven by user-facing configuration
     interfaces without requiring operators to author JSON directly
     (Section 6.10.7).

  1.4.  Relationship to Other Work

     SEP-1649 and SEP-2127 (MCP Server Cards), authored within the
     Model Context Protocol project, propose a /.well-known discovery
     endpoint and server metadata format for HTTP-based MCP servers.
     This document pursues the same goal through the IETF standards
     process, which provides a vendor-neutral venue for IANA registration
     of both the .well-known suffix and the "mcp" URI scheme -- consistent
     with MCP's status as a Linux Foundation project with broad industry
     participation.  The authors welcome coordination with the SEP process
     to converge on a unified discovery mechanism.

     Community feedback on SEP-2127 has identified that operators on
     fully managed hosting platforms (such as Wix, Squarespace, and
     similar services) cannot serve arbitrary files at /.well-known paths,
     as this capability is controlled by the hosting provider rather than
     the domain owner.  This constraint affects a significant portion of
     the web, including an estimated 43% of sites running on WordPress
     and similar CMS platforms in shared hosting environments.  The
     base mode defined in Section 4.1 of this document addresses this
     gap by requiring only a single JSON file installable via a CMS
     plugin, with no DNS configuration required.

     [ACTA] defines a signed receipt mechanism for MCP tool call
     decisions.  That document addresses the accountability layer --
     what is recorded after an agent uses a server.  This document
     addresses the discovery layer -- how an agent
     finds a server and what the server declares about itself before the
     first tool call.  The two documents are complementary and
     independently deployable.  The "trust_class" and "compliance" fields
     defined in Section 6.10 of this document provide the jurisdictional
     context that accountability layers MAY use to apply appropriate
     verification policies.

     The broader layering of the MCP ecosystem as understood by this
     document is as follows:

        Layer 0  DNS bootstrap (_mcp TXT record, fast mode only)
        Layer 1  Discovery and security negotiation (this document)
        Layer 2  Connection metadata (SEP-1649, SEP-2127)
        Layer 3  MCP protocol (transport, tool invocation)
        Layer 4  Accountability ([ACTA])

     In fast mode, Layers 0-1 are traversed once at connection setup
     and the result cached.  In base mode, Layer 0 is skipped and
     discovery begins at Layer 1.  Layer 3 is the ongoing protocol
     session.  Layer 4 is activated per tool call only when required
     by the server's declared security posture.

  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.

  1.6.  Out of Scope

     This document does NOT define:

     -  The MCP protocol itself (defined in [MCP-SPEC])
     -  Authentication flows beyond their advertisement in the manifest
     -  The format of MCP tools, resources, or prompts (defined in
        [MCP-SPEC])
     -  Discovery of MCP servers on private networks or intranets
     -  Accountability or audit mechanisms for tool call recording
     -  A crawling or indexing infrastructure (implementation concern)


  2.  Terminology

     MCP Server:   A service exposing tools, resources, and/or prompts
                   via the Model Context Protocol [MCP-SPEC].

     MCP Client:   An AI agent or application that connects to MCP
                   Servers to invoke tools and retrieve resources.

     MCP URI:      A URI using the "mcp" scheme as defined in Section 3
                   of this document, identifying a publicly reachable
                   MCP Server by domain.

     Manifest:     The JSON document returned at /.well-known/mcp-server,
                   as defined in Section 6 of this document.

     Discovery:    The process by which an MCP Client determines the
                   endpoint URL of an MCP Server starting from a domain
                   name alone.


  3.  The "mcp" URI Scheme

  3.1.  Purpose

     The "mcp" URI scheme identifies a publicly reachable MCP Server
     associated with a web domain. It is intended for use by AI agents
     and automated crawlers, not by human users or web browsers.

  3.2.  Syntax

     The "mcp" URI scheme is registered following the procedures
     defined in [RFC7595].  The syntax is defined using ABNF [RFC5234]:

     mcp-URI       = "mcp://" authority path-abempty [ "?" query ]
     authority     = [ userinfo "@" ] host [ ":" port ]
     host          = IP-literal / IPv4address / reg-name
     reg-name      = *( unreserved / pct-encoded / sub-delims )
     path-abempty  = *( "/" segment )
     segment       = *pchar
     query         = *( pchar / "/" / "?" )

     Where "userinfo", "IP-literal", "IPv4address", "unreserved",
     "pct-encoded", "sub-delims", and "pchar" are as defined in
     [RFC3986].

  3.3.  Examples

     Valid MCP URIs:

        mcp://example.com
        mcp://api.example.com
        mcp://example.com/shop
        mcp://example.com:8080

     Invalid MCP URIs:

        mcp://              (missing host)
        mcp:example.com     (missing //)


  4.  MCP Server Discovery

  4.1.  Operating Modes

     This document defines two operating modes for MCP discovery.
     Clients and server operators SHOULD declare which mode they support
     in their implementation documentation.

     base mode:  .well-known only.  The client fetches
                 /.well-known/mcp-server directly.  This mode works on
                 any web server and requires no DNS configuration.
                 It is the RECOMMENDED default for operators on shared
                 hosting, WordPress, or any environment where DNS control
                 is unavailable.

     fast mode:  DNS TXT first, .well-known for metadata enrichment.
                 The client queries _mcp.{host} first to confirm MCP
                 presence before incurring TLS overhead.  This mode is
                 RECOMMENDED for operators who control DNS and for
                 crawlers operating at scale, where a single UDP packet
                 in <10ms per domain provides significant latency
                 advantages over a full HTTPS GET per domain.

  4.2.  Discovery Sequence

     Upon resolving an MCP URI, clients operating in fast mode MUST
     attempt discovery in the following order.  Clients operating in
     base mode MUST begin at Step 2.

     Step 1 -- DNS TXT Record (fast mode only)

     The client MUST query:

        _mcp.{host}  IN  TXT

     If a TXT record is present containing "v=mcp1", the client has
     confirmed MCP presence and MUST proceed to Step 2 to retrieve
     the full manifest.  If the record contains "src=", the DNS TXT
     record also provides the server endpoint address; in all cases
     .well-known provides the authoritative manifest.

     If no such record exists, the client MUST proceed to Step 2.

     Step 2 -- Well-Known URI (REQUIRED in both modes)

     The client MUST perform an HTTP GET request to:

        https://{host}/.well-known/mcp-server

     with the header:

        Accept: application/json

     If the server responds with HTTP 200 and a valid JSON Manifest
     (Section 6), the client MUST use the endpoint specified in the
     Manifest.

     If the server responds with HTTP 301 or 302, the client MUST follow
     the redirect, up to a maximum of two redirect levels.

     If the server responds with HTTP 404, or the request times out
     (RECOMMENDED timeout: 5 seconds), the client MUST proceed to
     Step 3.

     Step 3 -- Direct Endpoint (LAST RESORT)

     The client MAY attempt a direct MCP handshake at:

        https://{host}/mcp

     If the handshake succeeds, the client MAY use this endpoint.  If it
     fails, the client MUST report that no MCP server was found for the
     given domain.

  4.3.  Conflict Resolution

     When DNS TXT and .well-known specify different endpoints, the
     .well-known manifest endpoint MUST take precedence.  HTTPS provides
     domain authenticity guarantees that unsigned DNS records do not.

     Clients SHOULD log a warning when the DNS TXT endpoint and the
     .well-known manifest endpoint diverge.  This divergence MAY
     indicate misconfiguration or a DNS-level attack.


  5.  DNS TXT Record Format

     This section defines the DNS TXT record format used in Step 1
     of the fast mode discovery sequence (Section 4.2).  DNS TXT
     records are defined in [RFC1035].  For operators who control
     DNS, a TXT record provides a lightweight discovery primitive
     that confirms MCP presence and advertises the server endpoint
     without requiring an HTTPS request.

  5.1.  Syntax

     A domain MAY advertise one or both of the following record types:

        _mcp.{domain}  IN  TXT  "v=mcp1; src={url}[; auth={type}]"
        _mcp.{domain}  IN  TXT  "v=mcp1; registry={url}"

  5.2.  Fields

     v=mcp1          MUST    Version discriminator.
     src=<url>       SHOULD  Direct MCP server endpoint URL.
                             Use when the domain hosts its own MCP
                             server directly.
     registry=<url>  MAY     URL of a catalogue or registry that
                             lists MCP servers for this domain.
                             Use when the domain aggregates multiple
                             MCP servers via a registry backend.
     auth=<type>     SHOULD  One of: none, apikey, oauth2.

     A record containing "src=" advertises a direct server endpoint.
     A record containing "registry=" advertises a catalogue endpoint.
     Both MAY appear in the same record or as separate TXT records
     for the same domain.

     The legacy field name "endpoint=" is deprecated and MUST be
     treated as equivalent to "src=" by conforming clients.

  5.3.  Limitations

     DNS TXT records are limited to 255 characters per string.  For
     complete manifests, operators MUST use the well-known URI mechanism
     (Section 4.2, Step 2).  DNS TXT records are discovery primitives
     only; they do not replace the manifest.


  6.  The MCP Server Manifest

  6.1.  Format

     The Manifest is a JSON document [RFC8259] returned at
     /.well-known/mcp-server.

  6.2.  Required Fields

     mcp_version  string  MCP spec version (e.g. "2025-06-18")
     name         string  Human-readable server name
     endpoint     string  URL of the MCP endpoint
     transport    string  See Section 6.6

  6.3.  Recommended Fields (SHOULD)

     description  string  Natural language description of the server
     auth         object  Authentication requirements (see Section 6.5)
     capabilities array   ["tools", "resources", "prompts"]
     trust_class  string  Security posture declaration.
                          See Section 6.10.2.
                          Values: "public" | "sandbox" | "enterprise" |
                          "regulated". Default if absent: "public".

  6.4.  Optional Fields (MAY)

     categories    array    Semantic categories
                            (see mcpstandard.dev/categories)
     languages     array    ISO 639-1 language codes
     coverage      string   ISO 3166-1 country code
     contact       string   Contact email or URL
     docs          string   Documentation URL
     last_updated  string   ISO 8601 timestamp
     crawl         boolean  false to opt out of indexing
     expires       string   ISO 8601 timestamp after which the manifest
                            MUST be considered stale and re-fetched
     cache_ttl     integer  Cache duration in seconds for this manifest.
                            Overrides HTTP Cache-Control for the purpose
                            of manifest staleness evaluation.
                            Default: 3600. MAY be omitted for trust_class
                            "public", "sandbox", "enterprise". REQUIRED
                            when trust_class is "regulated"
                            (see Section 6.10.3).
     signature     object   Manifest integrity signature (see Section 6.7)
     server_card      string   URL of a SEP-2127 compatible Server Card
                               document, providing richer pre-connection
                               metadata including tool descriptions,
                               resources, and prompts.
                               Clients that support
                               SEP-2127 SHOULD fetch this URL after
                               resolving the manifest. See Section 1.4.
     payment_required boolean  Whether tool calls require payment.
                               See Section 6.11.
     payment_methods  array    Supported payment method identifiers.
                               See Section 6.11.
     tools_preview    array    Preview of available tools.
                               See Section 6.12.1.
     resources_preview array   Preview of available resources.
                               See Section 6.12.2.
     prompts_preview  array    Preview of available prompt templates.
                               See Section 6.12.3.

  6.5.  Auth Object

     The "auth" object is defined in full in Section 6.10.4, which is
     the canonical definition.  When used as a SHOULD field (Section 6.3),
     at minimum "required" and "methods" MUST be present.

     Example (minimal, for a public server with optional OAuth 2.0):

        "auth": {
          "required": false,
          "methods": ["none", "oauth2"],
          "endpoint": "https://example.com/oauth/authorize",
          "metadata_url":
            "https://example.com/.well-known/oauth-authorization-server",
          "scopes": ["mcp:read"]
        }

     See Section 6.10.4 for the complete field reference.

  6.6.  Transport Values

     The "transport" field MUST contain one of the following values:

     "http"   JSON-RPC 2.0 over HTTPS (request/response). This is the
              RECOMMENDED transport for publicly reachable servers.

     "sse"    Server-Sent Events over HTTPS [W3C-SSE]. Suitable for
              servers that push notifications or stream results.

     "stdio"  Standard input/output. This value is reserved for local
              process-based MCP servers and MUST NOT appear in manifests
              served via /.well-known/mcp-server, as such servers are
              by definition not reachable via a network endpoint.
              Clients SHOULD treat a manifest with transport "stdio"
              served over HTTPS as malformed.

     Servers MAY declare multiple transports using a "transports" array
     field alongside the primary "transport" field.

  6.7.  Manifest Signature

     Operators who require stronger integrity guarantees for their
     manifest MAY include a "signature" field containing a detached
     JWS (JSON Web Signature) as defined in [RFC7515], using a key
     published via DNS (analogous to DKIM [RFC6376]).

     The signature covers the canonical JSON serialization of the
     manifest object excluding the "signature" field itself.

     The "signature" object MUST contain:

     alg     string  JWA algorithm identifier (e.g. "RS256", "ES256")
     kid     string  Key ID corresponding to a JWK published in DNS
     value   string  Base64url-encoded detached JWS signature

     Example:

        "signature": {
          "alg": "ES256",
          "kid": "mcp-key-1",
          "value": "base64url..."
        }

     The corresponding public key MUST be published as a DNS TXT record:

        _mcp-key.{domain}  IN  TXT  "v=mcp1jwk; kid=mcp-key-1; jwk={...}"

     Clients that implement signature verification SHOULD reject manifests
     with invalid signatures. Clients that do not implement signature
     verification MAY ignore the "signature" field entirely.

     NOTE: The signature mechanism defined here is informational and
     subject to revision in future versions of this document.

  6.8.  Endpoint Domain Validation

     Clients MUST verify that the host component of the "endpoint" field
     in the manifest matches or is a subdomain of the host from which the
     manifest was retrieved. Manifests where the endpoint host does not
     match the retrieval host MUST be rejected.

     Examples (manifest retrieved from example.com):

        "endpoint": "https://example.com/mcp/"          valid
        "endpoint": "https://api.example.com/mcp/"      valid
        "endpoint": "https://other-domain.com/mcp/"     INVALID -- reject

     This rule prevents manifest-based endpoint hijacking, where a
     compromised or fraudulent manifest redirects an MCP client to an
     unrelated server.

  6.9.  Expires Field

     Servers SHOULD include an "expires" field containing an ISO 8601
     timestamp indicating when the manifest becomes stale.

     Clients MUST NOT use a cached manifest past its expiry time without
     re-fetching it. If the "expires" field is absent, clients SHOULD
     treat the manifest as stale after the period indicated by the HTTP
     Cache-Control header, or after 24 hours if no Cache-Control header
     is present.

     The recommended validity period for a public manifest is between
     1 hour and 90 days.

  6.10.  Security Capability Negotiation

  6.10.1.  Overview

     MCP servers may operate under very different security regimes:
     a public sandbox tool, an enterprise API requiring OAuth 2.0,
     and a regulated healthcare server have fundamentally different
     client behaviour requirements.  Without a pre-connection
     declaration, a client cannot know which posture applies until
     after the connection is established -- potentially after
     sensitive data has already been transmitted.

     The manifest SHOULD declare the security posture of the server
     explicitly via the "trust_class" field (Section 6.10.2).  This
     declaration allows clients to determine required authentication,
     logging, and compliance behaviour without performing a full
     protocol handshake.  If "trust_class" is absent, clients MUST
     apply the defaults defined in Section 6.10.7.

     The negotiation is unidirectional and declarative: the server
     publishes its requirements; the client reads and applies them.
     No additional round-trip is required.

  6.10.2.  The trust_class Field

     The "trust_class" field is an OPTIONAL top-level field in the
     manifest.  If absent, clients MUST behave as if
     "trust_class": "public" were declared.  Server operators SHOULD
     declare "trust_class" explicitly to avoid ambiguity.

     The field functions as a preset: each value implies a defined set
     of mandatory sub-fields and a minimum guaranteed behaviour that any
     conforming client MAY assume without inspecting sub-fields
     individually.

     Defined values:

       "public"      The server is accessible without restrictions.
                     No authentication is required.  The manifest MAY
                     be cached freely up to the value of cache_ttl.

       "sandbox"     The server is experimental or non-production.
                     Clients SHOULD warn users before invoking tools.
                     Clients MUST NOT use sandbox servers in production
                     workflows without explicit user confirmation.
                     The "expires" sub-field is REQUIRED.

       "enterprise"  The server requires controlled access.  Clients
                     MUST NOT attempt connection before resolving the
                     declared authentication method.  The "auth" object
                     is REQUIRED and MUST contain at least one entry
                     in "methods".

       "regulated"   The server operates under a declared regulatory
                     regime.  Clients MUST apply the declared
                     authentication method, MUST NOT cache the manifest
                     beyond "cache_ttl", and MUST treat all sessions as
                     subject to logging requirements declared in the
                     "logging" object.  The "auth", "compliance", and
                     "logging" objects are all REQUIRED.

     If a client encounters an unrecognised "trust_class" value, it MUST
     treat the manifest as "regulated" for safety purposes and SHOULD
     log a warning.

  6.10.3.  Mandatory Sub-Fields by trust_class

     The following table defines which sub-fields are REQUIRED (R),
     OPTIONAL (O), or NOT APPLICABLE (N) for each trust_class value:

     Sub-field            public  sandbox  enterprise  regulated
     -----------------------------------------------------------
     auth                 O       O        R           R
     expires              N       R        O           O
     compliance           N       N        O           R
     logging              N       N        O           R
     cache_ttl            O       O        O           R

     A manifest that declares a trust_class but omits a REQUIRED
     sub-field for that class is malformed.  Clients MUST NOT connect
     to a server whose manifest is malformed.

  6.10.4.  The auth Object

     When present, the "auth" object MUST contain:

       "required"   Boolean.  If true, the client MUST complete
                    authentication before sending any tool call.

       "methods"    Array of strings.  Defines the authentication
                    mechanisms supported by the server.

                    Core vocabulary (MUST be supported by conforming
                    implementations):

                      "none"    No authentication.  Valid only when
                                required is false.
                      "bearer"  Bearer token.  "endpoint" MUST be
                                present.
                      "mtls"    Mutual TLS.  Client certificate
                                required.
                      "apikey"  Static API key.  Delivery mechanism
                                MUST be declared in "apikey_header".
                      "oauth2"  OAuth 2.0 flow.  "endpoint" and
                                "scopes" MUST be present.

                    Extension values MUST use the "x-" prefix
                    (e.g., "x-saml", "x-mycompany-sso").  Clients
                    that encounter an unrecognised "x-" value MUST
                    ignore it and attempt connection using remaining
                    known methods.  If no known method remains,
                    clients MUST NOT connect and SHOULD surface an
                    error to the operator.

                    Values without the "x-" prefix that are not in
                    the core vocabulary are invalid and MUST be
                    treated as if absent.

       "endpoint"      URI.  The authentication endpoint.  REQUIRED when
                       methods includes "bearer" or "oauth2".

       "metadata_url"  URI.  RECOMMENDED when methods includes "oauth2".
                       OAuth 2.0 Authorization Server Metadata endpoint
                       as defined in [RFC8414].  Allows MCP clients to
                       autoconfigure the full OAuth 2.0 flow without
                       additional out-of-band information.  MUST be an
                       HTTPS URL.

       "apikey_header" String.  REQUIRED when methods includes "apikey".
                       The HTTP header name used to deliver the API key
                       (e.g. "X-Api-Key", "Authorization").

       "scopes"        Array of strings.  REQUIRED when methods includes
                       "oauth2".  OAuth 2.0 scopes required by the server
                       (e.g. ["mcp:read", "mcp:write"]).

  6.10.5.  The compliance Object

     Required when trust_class is "regulated".  MUST contain:

       "jurisdiction"   String.  ISO 3166-1 alpha-2 country code, or
                        one of the defined regional codes:
                          "EU"  European Union (GDPR applies)
                          "EEA" European Economic Area
                          "UK"  United Kingdom (UK GDPR applies)
                        Clients MUST NOT infer compliance requirements
                        beyond what is explicitly declared.

       "frameworks"     Array of strings.  Declared compliance
                        frameworks.  This field is informational --
                        clients MUST NOT refuse connection based on
                        unrecognised framework identifiers.
                        Examples: "GDPR", "HIPAA", "ISO27001",
                        "PCI-DSS", "SOC2".

       "certification_url"   URI.  OPTIONAL.  A URL where compliance
                             certification documentation can be
                             retrieved.  Clients MAY present this to
                             users or automated auditors.

  6.10.6.  The logging Object

     Required when trust_class is "regulated".  MUST contain:

       "required"         Boolean.  If true, the client MUST NOT
                          suppress session logging for this server.

       "retention_days"   Integer.  OPTIONAL.  Minimum retention period
                          for session logs in days.  Clients that cannot
                          honour this value SHOULD NOT connect and MUST
                          surface a warning to the operator.

  6.10.7.  Default Values and Omitted Fields

     Implementations MUST apply the following defaults when fields
     are absent:

       trust_class        "public"
       cache_ttl          3600 (seconds)
       auth.required      false
       logging.required   false

     The principle is secure-by-default: a missing trust_class is never
     interpreted as elevated privilege.  The most permissive safe default
     is applied, and the server operator is responsible for declaring any
     more restrictive posture explicitly.

  6.10.8.  Implementation Guidance for Non-Technical Operators

     Conforming implementations (such as CMS plugins) SHOULD provide a
     configuration interface that maps user-facing choices to valid
     manifest fields without requiring the operator to author JSON
     directly.  The following mapping is RECOMMENDED:

       User declares site type "personal/blog"
         -> trust_class: "public"

       User declares site type "business/commercial"
         -> trust_class: "enterprise"
         -> implementation SHOULD auto-detect existing auth systems

       User declares site type "sensitive data" (health, finance, legal)
         -> trust_class: "regulated"
         -> implementation MUST prompt for jurisdiction before
            publishing manifest

       User declares site type "development/testing"
         -> trust_class: "sandbox"
         -> implementation MUST set expires to no more than 90 days

     Implementations MUST NOT publish a malformed manifest.  If required
     sub-fields cannot be determined automatically, the implementation
     MUST block publication and prompt the operator for the missing
     information.

  6.11.  Payment Advertisement

     Servers that require payment for tool calls MAY declare their
     payment capabilities in the manifest. This allows clients to
     determine payment compatibility before connecting.

     Fields:

     payment_required   boolean  Whether tool calls require payment
     payment_methods    array    Supported payment methods

     Valid payment method identifiers:

     "x402"        HTTP 402 + USDC on-chain (Coinbase x402)
     "mpp-tempo"   Machine Payment Protocol / Tempo
     "stripe"      Stripe Connect
     "apikey"      Pre-paid API key balance

     Example:

        "payment_required": true,
        "payment_methods": ["x402", "stripe"]

     NOTE: On-chain payment methods (e.g., x402) introduce
     per-transaction latency of ~2 seconds (Base L2) or more.
     Implementations SHOULD prefer session-level escrow patterns
     over per-call payments to avoid latency penalties on each
     tool invocation.

     This field does not specify the payment protocol itself. Implementors
     SHOULD refer to the relevant payment protocol specifications for
     complete transaction semantics.

  6.12.  Primitive Previews

     Servers MAY include previews of their tools, resources, and prompts
     directly in the manifest. This allows MCP clients and crawlers to
     understand server capabilities without establishing a connection,
     enabling semantic indexing, security pre-screening, and client-side
     filtering before the initialization handshake.

     Three optional fields are defined:

     tools_preview      array  Preview of available tools
     resources_preview  array  Preview of available resources
     prompts_preview    array  Preview of available prompt templates

     Each field MUST be either:

     (a) An array of preview objects as defined below, or
     (b) The string "dynamic", indicating that the full list MUST be
         discovered through the MCP protocol's standard list operations
         and is subject to change.

  6.12.1.  Tool Preview Object

     Each entry in "tools_preview" SHOULD contain:

     name         string  REQUIRED. Tool identifier
     description  string  SHOULD. Natural language description
     inputSchema  object  MAY. JSON Schema for tool input parameters

     Example:

        "tools_preview": [
          {
            "name": "search_products",
            "description": "Search products by type, material and size",
            "inputSchema": {
              "type": "object",
              "properties": {
                "query":    { "type": "string" },
                "category": { "type": "string" },
                "limit":    { "type": "integer" }
              },
              "required": ["query"]
            }
          },
          {
            "name": "check_stock",
            "description": "Check real-time warehouse availability"
          }
        ]

  6.12.2.  Resource Preview Object

     Each entry in "resources_preview" SHOULD contain:

     uri          string  REQUIRED. Resource URI or URI template
     name         string  SHOULD. Human-readable name
     description  string  MAY. Natural language description
     mimeType     string  MAY. MIME type of the resource

     Example:

        "resources_preview": [
          {
            "uri": "catalog://products/{id}",
            "name": "Product Catalog",
            "description": "Full product details, specs and pricing",
            "mimeType": "application/json"
          }
        ]

  6.12.3.  Prompt Preview Object

     Each entry in "prompts_preview" SHOULD contain:

     name         string  REQUIRED. Prompt identifier
     description  string  SHOULD. Natural language description
     arguments    array   MAY. List of argument objects with name and
                               description fields

     Example:

        "prompts_preview": [
          {
            "name": "compare_products",
            "description": "Generate a comparison between two products",
            "arguments": [
              { "name": "product_a", "description": "First product ID" },
              { "name": "product_b", "description": "Second product ID" }
            ]
          }
        ]

  6.12.4.  Consistency Requirement

     Clients MUST treat primitive previews as advisory. The authoritative
     list of tools, resources, and prompts is always the one returned by
     the MCP protocol's list operations (tools/list, resources/list,
     prompts/list) after connection establishment.

     Servers SHOULD ensure that the previews are consistent with the
     actual primitives returned during initialization. Servers MAY omit
     sensitive tool descriptions from the preview and mark them as
     "dynamic" if pre-connection disclosure is undesirable.

  6.12.5.  Relationship to SEP-1649 and SEP-2127

     The primitive preview mechanism defined here is intentionally
     aligned with the MCP Server Cards proposal (SEP-1649) from the MCP
     maintainers at Anthropic. The key differences are:

     -  This document uses "tools_preview", "resources_preview", and
        "prompts_preview" field names to make the advisory nature
        explicit, while SEP-1649 uses "tools", "resources", "prompts".

     -  The well-known path in this document is "/.well-known/mcp-server"
        while SEP-1649 proposes "/.well-known/mcp/server-card.json".
        The authors welcome coordination with MCP maintainers to align
        these paths.

     -  This document additionally defines the "mcp" URI scheme and
        DNS TXT discovery (base mode and fast mode), which are not
        covered by SEP-1649.

     -  This document requests formal IANA registration of both the
        URI scheme and the well-known URI suffix, as noted as a future
        requirement in SEP-1649.

     The "server_card" field defined in Section 6.4 provides a direct
     pointer from this document's manifest to a SEP-2127 Server Card,
     allowing the two specifications to coexist without requiring
     convergence on a single well-known path.

  6.13.  Minimal Example

        {
          "mcp_version": "2025-06-18",
          "name": "Example MCP Server",
          "endpoint": "https://example.com/mcp",
          "transport": "http"
        }

  6.14.  Full Example

        {
          "mcp_version": "2025-06-18",
          "name": "Example Shop MCP Server",
          "description": "Product catalog and order management",
          "endpoint": "https://example.com/mcp",
          "transport": "http",
          "trust_class": "enterprise",
          "auth": {
            "required": true,
            "methods": ["oauth2"],
            "endpoint": "https://example.com/oauth/authorize",
            "metadata_url": "https://example.com/.well-known/as",
            "scopes": ["mcp:read", "mcp:write"]
          },
          "capabilities": ["tools", "resources"],
          "categories": ["e-commerce", "fashion"],
          "languages": ["en", "it"],
          "coverage": "IT",
          "contact": "api@example.com",
          "docs": "https://example.com/mcp/docs",
          "last_updated": "2026-03-25T00:00:00Z",
          "expires": "2026-09-25T00:00:00Z",
          "cache_ttl": 3600,
          "server_card":
            "https://example.com/.well-known/mcp/server-card.json",
          "payment_required": false,
          "crawl": true
        }

  6.15.  HTTP Response Requirements

     Servers MUST respond with:

        HTTP/1.1 200 OK
        Content-Type: application/json

     Servers SHOULD include:

        Cache-Control: max-age=3600


  7.  Security Considerations

  7.1.  Manifest Spoofing

     A malicious actor could expose a fraudulent /.well-known/mcp-server
     document. Clients MUST verify that the domain in the manifest
     endpoint matches the domain of the original MCP URI.

     When HTTPS is used (as REQUIRED by this specification), TLS
     certificate validation provides a baseline authenticity guarantee.
     Operators requiring stronger guarantees SHOULD use the manifest
     signature mechanism defined in Section 6.7.

  7.2.  DNS Hijacking

     DNS TXT records may be spoofed on networks without DNSSEC.
     Operators SHOULD enable DNSSEC where available.  When DNS TXT and
     .well-known endpoints conflict, the .well-known manifest MUST take
     precedence, as HTTPS provides domain authenticity guarantees that
     unsigned DNS records do not (see Section 4.3).

     DNS-based manifest signatures (Section 6.7) inherit the same
     vulnerability. Operators using the signature mechanism SHOULD
     also enable DNSSEC for the signing key record.

  7.3.  Rate Limiting

     Crawlers may generate excessive requests to /.well-known/mcp-server.
     Servers SHOULD implement standard HTTP rate limiting and return
     HTTP 429 (Too Many Requests) with appropriate Retry-After headers
     when limits are exceeded.

  7.4.  Sensitive Data

     The Manifest is a public document. It MUST NOT contain credentials,
     tokens, API keys, or any private operational information.

  7.5.  Manifest Integrity via JWK Signature

     The optional signature mechanism defined in Section 6.7 provides
     integrity verification for the manifest content. Implementers should
     be aware that:

     -  The signature covers content integrity but not freshness; a
        valid signature does not guarantee the manifest is current.

     -  Key rotation should be handled by publishing new key IDs in DNS
        and updating the manifest accordingly.

     -  Clients that cannot verify signatures MUST NOT treat unsigned
        manifests as less trustworthy than signed ones in the absence
        of a policy requiring signatures.


  8.  IANA Considerations

  8.1.  URI Scheme Registration

     This document requests registration of the "mcp" URI scheme in the
     IANA Uniform Resource Identifier (URI) Schemes registry:

        Scheme name:       mcp
        Status:            Provisional
        Applications:      AI agents, MCP clients
        Contact:           marco.serra@mumble.group
        Change controller: IETF
        Reference:         This document

  8.2.  Well-Known URI Registration

     This document requests registration of the "mcp-server" well-known
     URI suffix in the IANA Well-Known URIs registry per [RFC8615]:

        URI suffix:             mcp-server
        Change controller:      IETF
        Specification document: This document
        Related information:    None


  9.  Reference Implementation

     A reference implementation of this specification is available at
     https://mcpstandard.dev, including a live /.well-known/mcp-server
     endpoint, a Python client library for resolving mcp:// URIs, CMS
     plugins for WordPress and Django, and an optional voluntary
     crawler (MCP Search Console).

     Source code and community discussion are available at:

        https://github.com/99rig/mcp-discovery

     Registration with the Search Console is entirely optional.
     Conforming clients can discover any MCP server by following the
     resolution sequence defined in Section 4 without contacting any
     central registry or index.


  10.  References

  10.1.  Normative References

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

     [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/rfc/rfc3986>

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

     [RFC7515]   Jones, M., Bradley, J., and N. Sakimura, "JSON Web
                 Signature (JWS)", RFC 7515, May 2015.
                 <https://www.rfc-editor.org/rfc/rfc7515>

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

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

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

     [RFC8414]   Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                 Authorization Server Metadata", RFC 8414, June 2018.
                 <https://www.rfc-editor.org/rfc/rfc8414>

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

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

  10.2.  Informative References

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

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

     [RFC7595]   Thaler, D., "Guidelines and Registration Procedures for
                 URI Schemes", RFC 7595, June 2015.
                 <https://www.rfc-editor.org/rfc/rfc7595>

     [W3C-SSE]   Hickson, I., "Server-Sent Events", W3C Recommendation,
                 February 2015.
                 <https://www.w3.org/TR/eventsource/>

     [MCPSTANDARD]
                 Serra, M., "mcpstandard.dev -- MCP Discovery Reference
                 Implementation", 2026.
                 <https://mcpstandard.dev>

     [GH-DISCUSSION]
                 Serra, M., "MCP Server Discovery -- mcp:// URI scheme
                 and /.well-known/mcp-server", GitHub Discussion #2462,
                 2026.
                 <https://github.com/modelcontextprotocol/
                 modelcontextprotocol/discussions/2462>

     [ACTA]      Farley, T., "Signed Decision Receipts for MCP
                 Transport Layer", Internet-Draft
                 draft-farley-acta-signed-receipts-00, 2026.
                 <https://github.com/tomjwxf/ScopeBlindD2/blob/main/specs/
                 draft-farley-acta-signed-receipts-00.md>

     [SEP-1649]  Anthropic, "MCP Server Cards: HTTP Server Discovery
                 via .well-known", MCP Spec Enhancement Proposal 1649,
                 2025.
                 <https://github.com/modelcontextprotocol/
                 modelcontextprotocol/issues/1649>

     [SEP-2127]  Anthropic, "MCP Server Cards - HTTP Server Discovery
                 via .well-known", MCP Spec Enhancement Proposal 2127,
                 2026.
                 <https://github.com/modelcontextprotocol/
                 modelcontextprotocol/pull/2127>

     [MCP-WWW]   kormco, "mcp-www: DNS-native MCP discovery client
                 and benchmark", 2026.
                 <https://github.com/kormco/mcp-browse>


  Author's Address

     Marco Serra
     Mumble Group
     Milan, Italy
     Email: marco.serra@mumble.group
     URI:   https://mcpstandard.dev


name: draft-drake-email-hardware-attestation
rev: 01
title: Hardware Attestation for Email Sender Verification
time: 2026-04-29T01:00:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-31T01:00:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-05-22T09:24:48.589072+00:00
source: ietf
abstract:
  This document defines a mechanism for automated email senders (AI
     agents, bots, and autonomous systems) to include hardware attestation
     evidence in message headers, enabling receiving mail servers to
     cryptographically verify that the sending system has access to a
     genuine hardware security component -- such as a Trusted Platform
     Module (TPM), a PIV smart card (e.g., YubiKey), a virtual TPM, or a
     software-managed key -- from a known manufacturer or issuer.  The
     attestation proves hardware presence, not message composition locale.
     The verification chain runs from the email header to a manufacturer's
     root Certificate Authority (for hardware-backed attestation) or to an
     issuer's verification key (for issuer-certified attestation).

     Each automated sender is assigned a persistent agent identity,
     expressed as a URN in the "aid" (Agent Identity) namespace
     ([RFC8141]), enabling federated issuance by multiple independent
     identity providers and persistent reputation tracking across
     protocols and platforms.

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

     Together, these mechanisms provide both Sybil-resistant
     authentication and a foundation for reputation building: each
     identity requires a unique hardware security component, making large-
     scale automated abuse economically infeasible regardless of advances
     in artificial intelligence, while the persistent hardware-anchored
     identity enables receiving systems to accumulate trust signals over
     time.  Software-only agents MAY participate at a lower trust tier,
     building reputation from an initial baseline rather than from a
     hardware-anchored starting point.

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

full_text:
  Network Working Group                                         C.N. Drake
  Internet-Draft                                                   1id.com
  Intended status: Experimental                              29 April 2026
  Expires: 31 October 2026


             Hardware Attestation for Email Sender Verification
                 draft-drake-email-hardware-attestation-01

  Abstract

     This document defines a mechanism for automated email senders (AI
     agents, bots, and autonomous systems) to include hardware attestation
     evidence in message headers, enabling receiving mail servers to
     cryptographically verify that the sending system has access to a
     genuine hardware security component -- such as a Trusted Platform
     Module (TPM), a PIV smart card (e.g., YubiKey), a virtual TPM, or a
     software-managed key -- from a known manufacturer or issuer.  The
     attestation proves hardware presence, not message composition locale.
     The verification chain runs from the email header to a manufacturer's
     root Certificate Authority (for hardware-backed attestation) or to an
     issuer's verification key (for issuer-certified attestation).

     Each automated sender is assigned a persistent agent identity,
     expressed as a URN in the "aid" (Agent Identity) namespace
     ([RFC8141]), enabling federated issuance by multiple independent
     identity providers and persistent reputation tracking across
     protocols and platforms.

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

     Together, these mechanisms provide both Sybil-resistant
     authentication and a foundation for reputation building: each
     identity requires a unique hardware security component, making large-
     scale automated abuse economically infeasible regardless of advances
     in artificial intelligence, while the persistent hardware-anchored
     identity enables receiving systems to accumulate trust signals over
     time.  Software-only agents MAY participate at a lower trust tier,
     building reputation from an initial baseline rather than from a
     hardware-anchored starting point.








  Drake                    Expires 31 October 2026                [Page 1]


  Internet-Draft         Hardware Email Attestation             April 2026


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

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 31 October 2026.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   6
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   7
       1.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  Agent Identity Format . . . . . . . . . . . . . . . . . .  10
       4.2.  Identity-to-Hardware Cardinality  . . . . . . . . . . . .  12
       4.3.  Hardware Attestation Mechanisms . . . . . . . . . . . . .  14
       4.4.  Transient Key Model . . . . . . . . . . . . . . . . . . .  16



  Drake                    Expires 31 October 2026                [Page 2]


  Internet-Draft         Hardware Email Attestation             April 2026


       4.5.  Issuer Discovery  . . . . . . . . . . . . . . . . . . . .  17
         4.5.1.  DNS-Published Issuer Key  . . . . . . . . . . . . . .  17
         4.5.2.  HTTPS-Based Discovery (Fallback)  . . . . . . . . . .  19
     5.  Mode 1: Direct Hardware Attestation . . . . . . . . . . . . .  19
       5.1.  Attestation Evidence Structure  . . . . . . . . . . . . .  20
       5.2.  Header Field Definition . . . . . . . . . . . . . . . . .  20
       5.3.  Verification Algorithm  . . . . . . . . . . . . . . . . .  24
       5.4.  Authentication-Results Integration  . . . . . . . . . . .  26
       5.5.  Privacy Considerations for Direct Attestation . . . . . .  27
     6.  Mode 2: SD-JWT Trust Proof  . . . . . . . . . . . . . . . . .  28
       6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  28
       6.2.  Header Field Definition . . . . . . . . . . . . . . . . .  29
       6.3.  Message Binding via Issuer-Signed Nonce . . . . . . . . .  31
       6.4.  Verification Algorithm  . . . . . . . . . . . . . . . . .  32
       6.5.  Authentication-Results Integration  . . . . . . . . . . .  33
     7.  Combined Mode . . . . . . . . . . . . . . . . . . . . . . . .  33
     8.  Sybil Resistance Properties . . . . . . . . . . . . . . . . .  34
       8.1.  Direct Hardware Attestation (Mode 1)  . . . . . . . . . .  34
       8.2.  SD-JWT Trust Proof (Mode 2) . . . . . . . . . . . . . . .  35
       8.3.  Virtual Hardware  . . . . . . . . . . . . . . . . . . . .  35
     9.  Interaction with Existing Email Authentication  . . . . . . .  36
       9.1.  Multiple Headers and Forwarding . . . . . . . . . . . . .  37
       9.2.  Handle Display in Email . . . . . . . . . . . . . . . . .  37
     10. Message Submission Requirements . . . . . . . . . . . . . . .  38
       10.1.  Agent Identity Binding at Submission . . . . . . . . . .  38
       10.2.  Hardware Fingerprint Binding at Submission . . . . . . .  39
       10.3.  Messages Without Attestation . . . . . . . . . . . . . .  39
       10.4.  Duplicate Header Rejection . . . . . . . . . . . . . . .  39
       10.5.  Timestamp Validation at Submission . . . . . . . . . . .  39
     11. Interoperability Considerations . . . . . . . . . . . . . . .  40
       11.1.  Backward Compatibility . . . . . . . . . . . . . . . . .  40
       11.2.  DKIM Coverage of Attestation Headers . . . . . . . . . .  40
       11.3.  Header Size Considerations . . . . . . . . . . . . . . .  40
     12. Implementation Status . . . . . . . . . . . . . . . . . . . .  40
       12.1.  1id.com Issuer . . . . . . . . . . . . . . . . . . . . .  40
       12.2.  MailPal.com Verifier and Relay . . . . . . . . . . . . .  42
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  42
       13.1.  Header Field Registration  . . . . . . . . . . . . . . .  42
       13.2.  Authentication Method Registration . . . . . . . . . . .  43
       13.3.  Hardware Attestation Type Registry . . . . . . . . . . .  44
       13.4.  URN Namespace Registration . . . . . . . . . . . . . . .  44
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  45
       14.1.  Manufacturer CA Compromise . . . . . . . . . . . . . . .  45
       14.2.  Revocation and Compromise Response . . . . . . . . . . .  45
       14.3.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  46
       14.4.  Compromised Endpoints  . . . . . . . . . . . . . . . . .  46
       14.5.  Physical Attacks on Hardware Security Components . . . .  47
       14.6.  Virtual Hardware Risk  . . . . . . . . . . . . . . . . .  47



  Drake                    Expires 31 October 2026                [Page 3]


  Internet-Draft         Hardware Email Attestation             April 2026


       14.7.  Software-Only Attestation Risk . . . . . . . . . . . . .  47
       14.8.  Transient Object Slot Limits . . . . . . . . . . . . . .  47
       14.9.  Policy Abuse and Deanonymisation Risk  . . . . . . . . .  48
       14.10. Header Stripping and Modification  . . . . . . . . . . .  49
       14.11. Credential Theft and Identity Substitution . . . . . . .  49
       14.12. Issuer Trust and Accountability  . . . . . . . . . . . .  49
       14.13. Cryptographic Agility and Post-Quantum Migration . . . .  50
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  50
       15.1.  Applicability to Human vs. Automated Senders . . . . . .  50
       15.2.  Hardware Fingerprint Linkability . . . . . . . . . . . .  51
       15.3.  Privacy-Preserving Alternative (Mode 2)  . . . . . . . .  51
       15.4.  Issuer Knowledge . . . . . . . . . . . . . . . . . . . .  52
       15.5.  Data Minimisation  . . . . . . . . . . . . . . . . . . .  52
       15.6.  Abuse-Resistant Contact Tokens . . . . . . . . . . . . .  52
     16. Normative References  . . . . . . . . . . . . . . . . . . . .  53
     17. Informative References  . . . . . . . . . . . . . . . . . . .  54
     Appendix A.  Appendix: Economics of Hardware-Based Sybil
             Resistance  . . . . . . . . . . . . . . . . . . . . . . .  56
     Appendix B.  Appendix: Hardware Manufacturer Root CAs . . . . . .  57
     Appendix C.  Appendix: Live Email Examples  . . . . . . . . . . .  57
       C.1.  Example 1: Sovereign-Tier TPM (Combined Mode, Node.js
             SDK)  . . . . . . . . . . . . . . . . . . . . . . . . . .  59
       C.2.  Example 2: Portable-Tier PIV/YubiKey (Mode 2 Only, Python
             SDK)  . . . . . . . . . . . . . . . . . . . . . . . . . .  62
       C.3.  Example 3: Enclave-Tier Secure Enclave (Combined Mode,
             Python SDK) . . . . . . . . . . . . . . . . . . . . . . .  63
       C.4.  Example 4: Virtual-Tier vTPM (Combined Mode, Python
             SDK)  . . . . . . . . . . . . . . . . . . . . . . . . . .  66
       C.5.  Example 5: Declared-Tier Software-Only (Mode 2 Only, Python
             SDK)  . . . . . . . . . . . . . . . . . . . . . . . . . .  69
       C.6.  Example 6: Sovereign-Tier TPM (Mode 1 Only, Python
             SDK)  . . . . . . . . . . . . . . . . . . . . . . . . . .  71
       C.7.  Verification Failure Examples . . . . . . . . . . . . . .  74
     Appendix D.  Appendix: Applicability to Other Transports  . . . .  74
     Appendix E.  Appendix: URN Namespace Registration for "aid" . . .  75
     Appendix F.  Acknowledgements . . . . . . . . . . . . . . . . . .  77
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  77

  1.  Introduction

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




  Drake                    Expires 31 October 2026                [Page 4]


  Internet-Draft         Hardware Email Attestation             April 2026


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

     The fundamental problem is that all existing sender identity signals
     are software-based and therefore copyable at zero cost.  This
     document proposes anchoring sender identity to hardware, applying the
     remote attestation architecture of [RFC9334] to email: specifically,
     to the tamper-resistant hardware security components present in
     virtually every modern computing device.

     A hardware security component -- whether a discrete TPM chip, a
     firmware TPM (e.g., Intel PTT or AMD fTPM), a PIV smart card (e.g.,
     YubiKey), or a virtual TPM provided by a hypervisor -- contains a
     unique identity key burned in or generated at manufacturing time,
     with a certificate chaining to the manufacturer's root CA.  This key
     cannot be extracted, cloned, or transferred.  By signing email
     content with a hardware-resident key and including or linking the
     certificate chain in the message headers, an automated sender proves
     that the email originated on a specific, genuine piece of hardware.

     Receiving mail servers can verify this proof by validating the
     certificate chain against manufacturer root CAs (Intel, AMD, ARM,
     Apple, etc.) which are already widely distributed for Secure Boot and
     platform integrity.  Deployments that wish to accept hardware
     attestation will need to maintain or subscribe to an appropriate
     trust store of these root CAs.

     This document defines two complementary mechanisms:

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

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





  Drake                    Expires 31 October 2026                [Page 5]


  Internet-Draft         Hardware Email Attestation             April 2026


  1.1.  Design Principles

     The following principles guide the design of this specification and
     are referenced throughout the document:

     Automated-Sender Focus  This specification targets AI agents, bots,
        and autonomous systems.  It is not intended for individual human
        users (see Section 3).  The privacy trade-offs are acceptable for
        automated senders but disproportionate for human correspondence.

     Transport Independence  The attestation formats defined herein -- the
        CMS attestation bundle and the SD-JWT trust proof -- are self-
        contained data structures that can be carried in any protocol
        capable of transporting octet strings.  This document specifies
        the email transport binding; Appendix D discusses applicability to
        HTTP and other protocols.

     Federated Issuance  Any organisation that owns a DNS domain can
        operate as an Issuer.  No central authority or coordination is
        required beyond DNS ownership.  This mirrors the federated model
        of email itself (see Section 4.5).

     Inclusive Trust Tiers  Agents with genuine hardware security
        components receive the highest trust, but agents with virtual
        hardware or software-only keys can still participate at lower
        trust tiers, building reputation over time.  This inclusivity
        avoids an all-or-nothing barrier to adoption.

     Reputation as the Goal  Sybil resistance is a means, not an end.  The
        persistent, hardware-anchored identities defined here exist to
        enable receiving systems to build and query reputation over time,
        rewarding good behaviour and flagging bad.

     Dual Trust Anchors  Both attestation modes deliberately provide the
        agent identity (aid) and the hardware certificate or fingerprint
        together.  Verifiers MAY choose which anchor to use as their basis
        for trust decisions: the identity is the primary key for
        reputation tracking and persists across hardware migrations, while
        the hardware fingerprint is IdP-independent and verifiable offline
        against manufacturer root CAs.  Some verifiers will prefer the
        identity (for accumulated reputation), others will prefer the
        hardware (for IdP-independent assurance or cross-IdP correlation),
        and high-assurance scenarios may require both.  This dual
        provision is intentional, not redundant.







  Drake                    Expires 31 October 2026                [Page 6]


  Internet-Draft         Hardware Email Attestation             April 2026


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

  1.3.  Terminology

     Hardware Attestation Mechanism  A tamper-resistant hardware or
        firmware component capable of protecting private keys and
        producing cryptographic attestation statements verifiable to a
        manufacturer or platform Certificate Authority.  Examples include
        TPM 2.0 devices (discrete and firmware), PIV tokens (e.g.,
        YubiKey), and virtual TPMs.  This document also accommodates
        software-managed keys at a lower trust tier for agents that lack
        hardware security components but wish to participate in the
        reputation ecosystem.

     TPM  Trusted Platform Module, as specified by the Trusted Computing
        Group (TCG) [TCG-TPM2].  This document assumes TPM 2.0.  A TPM may
        be a discrete chip, a firmware implementation (Intel PTT, AMD
        fTPM), or a virtual instance provided by a hypervisor.

     EK  Endorsement Key.  A unique RSA or ECC key pair generated inside
        the TPM at manufacturing time, as profiled in [TCG-EK-PROFILE].
        The EK private key never leaves the TPM.  The EK certificate is
        signed by the chip manufacturer's CA and serves as the persistent
        hardware identity for the device.

     AK  Attestation Key.  A signing key created inside a hardware
        security component, certified against the device's identity key
        (EK for TPM, attestation certificate for PIV) to prove it resides
        in the same device.  In this specification, the AK SHOULD be
        created as a transient object and SHOULD NOT be persisted in non-
        volatile storage, to avoid consuming limited hardware resources.
        See Section 4.4.

     Identity Certificate  The manufacturer-issued certificate that











  Drake                    Expires 31 October 2026                [Page 7]


  Internet-Draft         Hardware Email Attestation             April 2026


        identifies a specific hardware security component.  For TPMs, this
        is the EK certificate.  For PIV tokens, this is the device
        attestation certificate.  The SHA-256 hash of the
        SubjectPublicKeyInfo DER encoding from this certificate serves as
        the hardware fingerprint.  The fingerprint is derived from the
        public key structure rather than the certificate as a whole, so
        that the fingerprint remains stable if the manufacturer reissues
        the certificate (e.g., to extend validity or update metadata)
        without changing the underlying key pair.

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

     Agent Identity  A persistent, globally unique identifier for an
        autonomous agent, expressed as a URN in the "aid" namespace
        (Section 4.1).  Agent identities are assigned by issuers and are
        bound to specific hardware via the issuer's anti-Sybil registry.

     Issuer  An entity that verifies hardware attestation evidence,
        maintains an anti-Sybil registry (ensuring one hardware device
        maps to at most one identity), and issues trust assertions (e.g.,
        SD-JWTs) about enrolled agents.  An Issuer is OPTIONAL for Mode 1
        (Direct Hardware Attestation) and REQUIRED for Mode 2 (SD-JWT
        Trust Proof).  See Section 4.5 for discovery and the federated
        issuance model.

     Trust Tier  A classification of an agent's hardware trust level,
        assigned by an Issuer.  Defined tiers are grouped into three
        compatibility classes, ordered from strongest to weakest anti-
        Sybil resistance: (a) "sovereign" (genuine non-virtual hardware
        TPM or discrete security chip) and "portable" (PIV smart card such
        as YubiKey) -- manufacturer-attested, persistent identity; (b)
        "virtual" (hypervisor-provided virtual TPM) and "enclave"
        (hardware enclave such as Apple Secure Enclave) -- key isolation
        without anti-Sybil guarantee, as both device types can be re-keyed
        at will; (c) "declared" (software-only key, no hardware
        attestation).  Verifiers use trust tiers to apply differentiated
        policy.  For identities with multiple enrolled devices of
        different types, Issuers that support multi-device identities MAY
        report the trust tier of the device used for the most recent
        attestation rather than a static assignment.  Verifiers SHOULD
        therefore expect the same agent identity URN to appear with
        different trust tier values over time.

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



  Drake                    Expires 31 October 2026                [Page 8]


  Internet-Draft         Hardware Email Attestation             April 2026


  2.  Problem Statement

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

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

     Hardware attestation re-introduces a cost floor that AI cannot
     eliminate: each sender identity requires a physical security
     component.  These components have real manufacturing costs, exist in
     physical supply chains, and each contains a globally unique key pair
     certified by the manufacturer.  An attacker seeking to create N
     sender identities needs N physical devices, each with genuine
     hardware -- a cost of approximately $20-2000 per identity compared to
     approximately $0 per identity with software-only approaches.

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

     This specification also accommodates software-only agents at a lower
     trust tier.  An agent that manages its own key pair without hardware
     protection can still participate in the reputation ecosystem,
     building trust over time from a lower starting point.  This
     inclusivity recognises that not all legitimate agents have access to
     hardware security components, while maintaining clear differentiation
     between hardware-backed and software-only trust levels.

  3.  Applicability

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

     This specification is NOT intended or recommended for individual
     human users sending personal or low-volume email.  Human senders
     using consumer mail user agents (e.g., Gmail web client, Outlook)
     face privacy risks from Mode 1 Direct Attestation that are



  Drake                    Expires 31 October 2026                [Page 9]


  Internet-Draft         Hardware Email Attestation             April 2026


     disproportionate to the benefit: the hardware fingerprint uniquely
     identifies the sending device across all messages and contexts,
     enabling long-term tracking that exceeds current email privacy norms.
     Mode 2 (SD-JWT Trust Proof) mitigates this via selective disclosure
     but requires enrollment with an Issuer, which is not a typical
     consumer workflow.

     Mail User Agents (MUAs) designed for interactive human use MUST NOT
     enable Direct Hardware Attestation (Mode 1) by default.  Activation
     MUST require explicit, per-device user consent that warns of
     persistent cross-context tracking before any attestation header is
     added to outgoing messages.  Operators of human-facing email services
     MAY offer hardware attestation as an opt-in feature (e.g., via a
     browser extension or MUA plugin), but MUST provide clear disclosure
     of the linkability implications before activation.  Receivers SHOULD
     NOT penalise the absence of hardware attestation from senders
     exhibiting human-characteristic patterns (e.g., low volume, natural
     language variance, interactive reply chains).

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

     The attestation formats are transport-independent by design (see
     Section 1.1); this document specifies the email transport binding as
     the primary application.

  4.  Architecture

     This section defines the identity model, hardware mechanism taxonomy,
     key lifecycle, and issuer discovery procedures that underpin both
     attestation modes.

  4.1.  Agent Identity Format

     Agent identities in this specification use the URN format defined in
     [RFC8141] with the "aid" (Agent Identity) namespace identifier.

     aid-urn          = "urn:aid:" issuer-namespace ":" agent-id

     issuer-namespace = dns-label *("." dns-label)
     dns-label        = let-dig *(let-dig-hyp) let-dig / let-dig
     let-dig          = ALPHA / DIGIT
     let-dig-hyp      = ALPHA / DIGIT / "-"

     agent-id         = dns-label

     The issuer-namespace identifies the organisation or registry that
     enrolled the agent and verified its hardware.  Two forms exist:



  Drake                    Expires 31 October 2026               [Page 10]


  Internet-Draft         Hardware Email Attestation             April 2026


     *  *Domain-scoped:* reverse DNS notation derived from the Issuer's
        domain (e.g., com.1id, com.anthropic).  Any organisation that owns
        a DNS domain may operate as an Issuer under its domain-scoped
        namespace.

     *  *Shared (global):* the single-label namespace global is a shared
        issuer namespace in which multiple accredited Registrars compete
        to enroll agents.  See the companion registry specification
        [I-D.drake-agent-identity-registry] for shared namespace
        governance.

     The agent-id has two forms: a _canonical identifier_ (id- prefix
     followed by a decimal number, permanently assigned at enrollment) and
     an optional _handle_ (a human-readable alias beginning with a
     letter).  Both are valid agent-id values.  The canonical identifier
     is the indelible reference; the handle is a convenience that may be
     retired by dispute.  See the companion registry specification
     [I-D.drake-agent-identity-registry] for the full canonical-ID /
     handle model.

     The agent-id MUST conform to DNS label syntax ([RFC1035]
     Section 2.3.1): lowercase ASCII letters, digits, and hyphens, not
     beginning or ending with a hyphen, maximum 63 octets.
     Internationalised agent identifiers MUST use the "xn--" ACE prefix
     encoding defined in [RFC5891].  Underscores MUST NOT appear in the
     agent-id.

     Examples:

     *  urn:aid:global:id-9854187104 -- canonical (shared namespace)

     *  urn:aid:global:crusty -- handle for the same agent

     *  urn:aid:com.1id:id-3387412508 -- canonical (domain-scoped)

     *  urn:aid:com.anthropic:id-6142038597 -- canonical (domain-scoped)

     URN equivalence follows [RFC8141] Section 3: the "urn" scheme and
     "aid" NID are case-insensitive; the issuer-namespace and agent-id are
     case-sensitive (and MUST be lowercase).

     Agent identities are persistent by design: an Issuer MUST NOT
     reassign an agent-id to a different entity, even after the original
     identity is revoked or expired.  This persistence is essential for
     reputation systems that accumulate trust signals over the lifetime of
     an identity.  See Section 4.2 for the rules governing the
     relationship between agent identities and hardware devices.




  Drake                    Expires 31 October 2026               [Page 11]


  Internet-Draft         Hardware Email Attestation             April 2026


  4.2.  Identity-to-Hardware Cardinality

     The agent identity URN (aid) and the hardware fingerprint serve as
     dual trust anchors (see "Dual Trust Anchors" in Section 1.1).  The
     aid is the primary, stable identifier for reputation tracking.  The
     hardware fingerprint anchors the identity to physical hardware and is
     independently verifiable against manufacturer root CAs.  Both are
     provided together in attestation headers so that verifiers may choose
     which anchor to base trust decisions on.  The relationship between
     these two identifiers is governed by the following rules:

     Many hardware devices MAY back one agent identity  An Issuer MAY bind
        additional hardware devices to an existing agent identity over
        time, to support legitimate hardware migration (e.g., retiring old
        servers, replacing failed TPMs), secure backup and recovery (e.g.,
        a YubiKey stored in a safe), or adding capacity for a high-volume
        sending agent.  This does not amplify reputation: a single agent
        identity has a single reputation regardless of how many devices
        back it.  If the identity is flagged for abuse, all devices
        associated with it are equally affected.  The Issuer SHOULD
        require the agent to prove control of the existing identity (e.g.,
        by signing with the previously enrolled hardware) before accepting
        a new device.  Verifiers that track both the aid and the hardware
        fingerprint SHOULD expect that a given aid may appear with
        different hardware fingerprints over its lifetime.

        Each device bound to an agent identity is permanently associated
        with that identity.  An Issuer MAY disable a device (preventing it
        from producing valid attestations) but MUST NOT remove the device-
        to-identity binding.  A disabled device remains counted against
        the identity and MUST NOT be re-enrolled under any other agent-id,
        even after disablement.  This permanence prevents reputation
        laundering via device recycling.

        An Issuer MUST enforce trust tier compatibility when binding
        additional devices: all hardware devices backing a single agent
        identity MUST be of comparable trust tier.  The defined
        compatibility groups are: (a) sovereign (typ=TPM) and portable
        (typ=PIV) are compatible and MAY back the same identity, as both
        provide manufacturer-attested, tamper-resistant key storage; (b)
        virtual (typ=VRT) and enclave (typ=ENC) are compatible and MAY
        back the same identity, as neither provides anti-Sybil guarantees
        (virtual TPMs can be instantiated freely by the hypervisor
        operator, and hardware enclaves lack a manufacturer attestation
        PKI that would prevent re-keying); (c) declared (typ=SFT) MUST NOT
        be bound to an identity that has any other device type.  No cross-
        group mixing is permitted: a device from group (a) MUST NOT
        coexist with a device from group (b) or (c), and vice versa.



  Drake                    Expires 31 October 2026               [Page 12]


  Internet-Draft         Hardware Email Attestation             April 2026


        Upgrading an identity from a lower group to a higher group (e.g.,
        from group (b) to group (a), or from group (c) to either hardware
        group) requires the permanent and mandatory burning (retirement)
        of ALL devices from the former group as part of the upgrade
        ceremony.  The Issuer MUST NOT permit the identity to retain
        devices from both groups simultaneously at any point during or
        after the upgrade.  Additionally, upgrades that cross group
        boundaries MUST include a co-presence cryptographic verification
        between the existing device and the new device to ensure that the
        same human or operator controls both.  Downgrading from a higher
        group to a lower group (e.g., from group (a) to group (b)) is
        forbidden; the Issuer MUST reject any device addition that would
        constitute a downgrade.

        When an identity has multiple devices of compatible but different
        types (e.g., one sovereign TPM and one portable PIV), the
        trust_tier disclosed in attestation tokens (Mode 2) or the typ
        parameter in attestation headers (Mode 1) reflects the specific
        device used for that attestation, not a static property of the
        identity.  Verifiers SHOULD therefore expect the same agent
        identity URN to appear with different trust tier values across
        different messages.

     One hardware device MUST NOT back multiple agent identities from
     the same Issuer  An Issuer MUST NOT enroll the same hardware device
        (identified by its identity certificate public key hash) under
        more than one agent-id within that Issuer's namespace.  This is
        the fundamental anti-Sybil invariant: it ensures that creating N
        agent identities requires N distinct hardware devices.  Issuers
        MUST maintain a registry mapping identity certificate public key
        hashes to agent-ids and MUST reject enrollment attempts that would
        violate this constraint.  This binding is permanent: once a
        hardware device has been bound to an agent identity, it MUST NOT
        be reassigned to a different agent identity, even if it is later
        disabled or removed from the original identity.  An Issuer MAY
        disable a hardware device (preventing it from being used for
        attestation) but MUST NOT permit that device to be enrolled under
        any other agent-id.  This prevents reputation laundering attacks
        where a flagged device is removed from a bad-reputation identity
        and enrolled under a fresh identity.

     Cross-Issuer binding is permitted  A single hardware device MAY be
        enrolled with multiple independent Issuers, each assigning its own
        agent-id.  This is by design: Issuers are independent authorities,
        and the anti-Sybil invariant is scoped to a single Issuer's
        namespace.  Cross-Issuer duplication is trivially detectable by
        any verifier that tracks hardware fingerprints: the same
        fingerprint appearing under multiple agent identities from



  Drake                    Expires 31 October 2026               [Page 13]


  Internet-Draft         Hardware Email Attestation             April 2026


        different Issuers reveals the shared hardware.  Verifiers MAY
        apply policy based on this signal (e.g., treating the device as
        lower trust if it maintains identities with many Issuers
        simultaneously).

     Because the agent identity is the stable reputation anchor, verifiers
     SHOULD use the aid URN as the primary key for reputation systems.
     The hardware fingerprint serves as a secondary signal: it provides
     Sybil resistance at the hardware layer and enables reputation
     tracking for agents that do not present an aid.

  4.3.  Hardware Attestation Mechanisms

     This specification supports multiple hardware security technologies
     through a common abstraction.  Each mechanism provides an identity
     certificate and a signing capability (used for per-message
     attestation).  For sovereign and portable tiers, the identity
     certificate is signed by the hardware manufacturer; for enclave and
     virtual tiers, the identity certificate is issued by the Issuer.  The
     hardware type is declared in the attestation header via the "typ"
     parameter.

     +=======+=========================+====================+===========+
     | typ   | Technology              | Identity           | Trust     |
     | value |                         | Certificate        | Tier      |
     +=======+=========================+====================+===========+
     | TPM   | TPM 2.0 (discrete or    | EK Certificate     | sovereign |
     |       | firmware)               |                    |           |
     +-------+-------------------------+--------------------+-----------+
     | PIV   | PIV smart card (e.g.,   | Device Attestation | portable  |
     |       | YubiKey)                | Certificate        |           |
     +-------+-------------------------+--------------------+-----------+
     | ENC   | Hardware enclave (e.g., | Issuer-certified   | enclave   |
     |       | Apple Secure Enclave)   | enclave key        |           |
     |       |                         | certificate        |           |
     +-------+-------------------------+--------------------+-----------+
     | VRT   | Virtual TPM             | vTPM EK            | virtual   |
     |       | (hypervisor-provided)   | Certificate        |           |
     +-------+-------------------------+--------------------+-----------+
     | SFT   | Software-managed key    | Issuer-signed      | declared  |
     |       |                         | certificate        |           |
     +-------+-------------------------+--------------------+-----------+

                                   Table 1

     Additional hardware types MAY be defined in future specifications by
     registering new "typ" values with IANA (see Section 13).




  Drake                    Expires 31 October 2026               [Page 14]


  Internet-Draft         Hardware Email Attestation             April 2026


     For TPM-based attestation (typ=TPM), the identity certificate is the
     Endorsement Key (EK) certificate, provisioned at manufacturing time
     and stored in the TPM's non-volatile memory.  The EK certificate
     chains to the TPM manufacturer's root CA (e.g., Intel, AMD,
     Infineon).

     For PIV-based attestation (typ=PIV), the identity certificate is the
     device attestation certificate issued by the token manufacturer
     (e.g., Yubico).  The signing key is a PIV authentication key resident
     on the token.

     For hardware enclave attestation (typ=ENC), the signing key resides
     in a tamper-resistant hardware enclave integrated into the device's
     system-on-chip (e.g., the Secure Enclave Processor on Apple silicon).
     Unlike discrete TPMs and PIV tokens, hardware enclaves do not provide
     manufacturer-issued identity certificates with a chain to a publicly
     available root CA, and critically, they do not support persistent
     attestation identities: the enclave key can be destroyed and
     regenerated at will by the device owner.  This means hardware
     enclaves provide NO anti-Sybil guarantee -- a single device can
     generate an unlimited number of distinct enclave keys over time.  For
     this reason, the "enclave" trust tier is placed in the same
     compatibility group as virtual TPMs (typ=VRT), which share the same
     re-keying limitation.  The identity certificate for typ=ENC is issued
     by the Issuer at enrollment time after verifying that the key was
     generated inside the enclave using a trust-on-first-use (TOFU) model.
     Note that the Secure Enclave performs internal hashing (ECDSA with
     SHA-256 over the raw input rather than a pre-hashed digest);
     implementations MUST pass the raw attestation-input bytes (72 bytes)
     to the enclave signing function, NOT the attestation-digest.

     For virtual TPM attestation (typ=VRT), the identity certificate is
     the vTPM's EK certificate, signed by the hypervisor vendor's CA
     (e.g., VMware, Microsoft).  Verifiers MUST distinguish virtual from
     physical hardware; see Section 8.3 for Sybil resistance implications.

     For software-only attestation (typ=SFT), the signing key is a
     software-managed key pair with no hardware protection.  The identity
     certificate is issued by the Issuer at enrollment time.  Software-
     only attestation provides no hardware-based Sybil resistance but
     allows agents to participate in the reputation ecosystem at a lower
     trust tier.  A legitimate agent that protects its key and builds
     reputation over time can achieve meaningful trust even without
     hardware backing.







  Drake                    Expires 31 October 2026               [Page 15]


  Internet-Draft         Hardware Email Attestation             April 2026


  4.4.  Transient Key Model

     For TPM-based attestation, this specification RECOMMENDS a transient
     key model in which the Attestation Key (AK) is created as a transient
     TPM object (via TPM2_CreatePrimary) and is NOT persisted in the TPM's
     non-volatile (NV) storage.  This avoids consuming limited NV slots,
     which are a scarce resource on most TPMs (typically 3-7 loaded
     objects at once).

     The transient key lifecycle is:

     1.  *Read EK certificate* from the TPM's NV storage (index 0x01C00002
         for RSA EK).  This is a read-only operation.  The EK certificate
         MAY be cached indefinitely as it does not change.

     2.  *Create transient AK* via TPM2_CreatePrimary under the
         endorsement hierarchy with a fixed template.  Because the
         template and the Endorsement Primary Seed (EPS) are constant,
         this deterministically produces the same key on every invocation.

     3.  *Binding verification* (one-time, during enrollment with an
         Issuer): The Issuer creates a credential challenge
         (TPM2_MakeCredential) encrypted to the EK; the agent decrypts it
         (TPM2_ActivateCredential), proving the AK resides in the same TPM
         as the EK.  The resulting AK certificate is stored client-side
         (outside the TPM) and reused across signing operations.

     4.  *Sign* the attestation content with the transient AK (TPM2_Sign).

     5.  *Flush* the transient AK handle (TPM2_FlushContext) to free the
         object slot.

     Implementations SHOULD flush transient objects immediately after use.
     If TPM2_CreatePrimary returns TPM_RC_OBJECT_MEMORY (0x0902), the
     implementation MUST flush existing transient handles and retry.

     The EK certificate is the persistent hardware identifier.  The AK is
     ephemeral infrastructure -- it exists only long enough to produce a
     signature, then is discarded.  No data is written to the TPM's non-
     volatile memory at any point in this protocol.

     The transient AK is deterministic within a given Endorsement Primary
     Seed (EPS) epoch.  The EPS is re-randomised when the TPM is cleared
     (TPM2_Clear) or reset to factory defaults.  After such an event, the
     AK public key changes and the agent MUST re-enroll with its Issuer to
     establish a new AK-to-EK binding.  The EK certificate remains
     constant across TPM clears, so the hardware identity persists even
     though the AK changes.



  Drake                    Expires 31 October 2026               [Page 16]


  Internet-Draft         Hardware Email Attestation             April 2026


     Note: On some platform configurations (particularly Windows with
     default TPM Base Services policy), reading the EK certificate from NV
     storage may require a one-time operating system configuration change
     or elevated access during initial enrollment.  Once the EK
     certificate has been read and cached client-side, subsequent
     attestation operations do not require elevation.  Implementations
     that cannot read the EK certificate directly MAY derive the EK public
     key via TPM2_CreatePrimary with the TCG EK template and use the
     resulting public key hash as the hardware fingerprint; verifiers can
     then query manufacturer APIs (e.g., Intel Trusted Services) to obtain
     the full certificate if needed for chain validation.  Alternatively,
     the Issuer can perform EK certificate extraction during enrollment
     and include it in the AK certificate it issues.

  4.5.  Issuer Discovery

     When a verifier encounters an agent identity URN, it extracts the
     Issuer's domain from the issuer-namespace by reversing the dot-
     separated labels.

     Example:
       URN: urn:aid:com.1id:1id-ty62muvf
       issuer-namespace: com.1id
       Issuer domain: 1id.com

     The verifier discovers the Issuer's signing key and endpoints through
     the mechanisms described below.  The DNS-based method is RECOMMENDED
     for email because it piggybacks on infrastructure that mail servers
     already query for DKIM, SPF, and DMARC, requires no outbound HTTPS
     connections during verification, and inherits the same domain-
     ownership guarantees that protect existing email authentication.  Any
     organisation that owns a DNS domain can operate as an Issuer by
     implementing the enrollment protocol, publishing a signing key (via
     DNS and/or JWKS), and maintaining an anti-Sybil registry.  No central
     registration or coordination is required beyond DNS ownership.

  4.5.1.  DNS-Published Issuer Key

     Issuers SHOULD publish their SD-JWT signing key as a DNS TXT record
     at the well-known name _hwattest.{domain}, following the same pattern
     as DKIM key records ([RFC6376] Section 3.6).

     Example DNS TXT record:

       _hwattest.1id.com.  IN TXT (
         "v=hwattest1; alg=ES256; "
         "p=MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE..."
       )



  Drake                    Expires 31 October 2026               [Page 17]


  Internet-Draft         Hardware Email Attestation             April 2026


     The TXT record value uses a tag=value format with semicolon
     separators:

     hwattest-record = hwattest-version ";" SP
                       hwattest-alg ";" SP
                       hwattest-key
                       [";" SP hwattest-kid]
                       [";" SP hwattest-status]

     hwattest-version = "v" "=" "hwattest1"
     hwattest-alg     = "alg" "=" jws-algorithm
     hwattest-key     = "p" "=" base64
     hwattest-kid     = "kid" "=" 1*VCHAR
     hwattest-status  = "t" "=" ("active" / "revoked")

     jws-algorithm    = "ES256" / "PS256" / "RS256"
                        ; other JWS algorithms may be added

     v  REQUIRED.  Version.  MUST be "hwattest1".

     alg  REQUIRED.  The JWS algorithm used by the Issuer to sign SD-JWTs
        (e.g., "ES256", "PS256").

     p  REQUIRED.  The Issuer's public key, base64-encoded.  For EC keys,
        this is the SubjectPublicKeyInfo DER encoding.  For RSA keys, this
        is the PKCS#1 DER encoding.  The format matches the DKIM p= tag
        ([RFC6376] Section 3.6.1).

     kid  OPTIONAL.  Key identifier matching the kid in the SD-JWT header.
        When present, verifiers use this to select the correct key if the
        Issuer rotates keys.

     t  OPTIONAL.  Key type: "active" (default) or "revoked".  When set to
        "revoked", verifiers MUST reject SD-JWTs signed with this key.
        This allows Issuers to revoke a compromised key via a DNS update
        without waiting for TTL expiry of cached JWKS responses.

     Verifiers MUST query this DNS record before falling back to HTTPS-
     based discovery.  The DNS TTL controls caching; Issuers SHOULD set a
     TTL between 3600 and 86400 seconds (1 to 24 hours).  For key
     rotation, the Issuer publishes the new key in DNS, waits for the old
     TTL to expire, then marks the old key as revoked.

     This approach provides several security advantages for email
     verification:






  Drake                    Expires 31 October 2026               [Page 18]


  Internet-Draft         Hardware Email Attestation             April 2026


     *  No outbound HTTPS connections during mail processing, eliminating
        DDoS amplification and SSRF risks that external URI fetches would
        introduce.

     *  Domain ownership is proven by DNS control, the same trust anchor
        used by DKIM and SPF.  A forged Hardware-Trust-Proof header
        claiming an Issuer domain the attacker does not control will fail
        verification because the attacker cannot publish a matching DNS
        key record.

     *  DNS infrastructure is already hardened against abuse by mail
        operators (rate limiting, caching, DNSSEC).

     *  Key revocation propagates through DNS TTL expiry, providing a
        well-understood and operationally familiar mechanism.

  4.5.2.  HTTPS-Based Discovery (Fallback)

     When no DNS TXT record is found at _hwattest.{domain}, or when the
     verifier operates in a non-email context (e.g., HTTP API
     verification), the verifier MAY discover the Issuer's key via HTTPS:

     OIDC Discovery  https://{domain}/.well-known/openid-configuration -
        Standard OpenID Connect discovery document containing the JWKS URI
        for SD-JWT signature verification.

     Issuer Metadata (OPTIONAL)  https://{domain}/.well-known/aid-
        issuer.json - JSON document describing the Issuer's capabilities,
        supported trust tiers, enrollment endpoint, and anti-Sybil policy.

     Manufacturer CA Trust Store (OPTIONAL)  https://{domain}/.well-known/
        hw-manufacturer-cas.pem - PEM-encoded bundle of hardware
        manufacturer root CA certificates that this Issuer accepts during
        enrollment.  Verifiers performing Mode 1 verification SHOULD
        maintain their own trust store rather than relying on this
        endpoint.

     Verifiers using HTTPS-based discovery SHOULD cache the JWKS with a
     TTL of at least 1 hour and at most 24 hours.  Verifiers MUST NOT
     follow redirects to domains other than the Issuer's domain, to
     prevent open-redirect attacks.

  5.  Mode 1: Direct Hardware Attestation

     This section defines a CMS-based attestation bundle containing a
     hardware-anchored signature and its full certificate chain, presented
     here as an email header field.  The CMS structure is transport-
     independent (see Section 1.1).



  Drake                    Expires 31 October 2026               [Page 19]


  Internet-Draft         Hardware Email Attestation             April 2026


  5.1.  Attestation Evidence Structure

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

     1.  *AK Certificate:* Issued by an Issuer after successful completion
         of the binding verification protocol (e.g., TPM2_MakeCredential /
         TPM2_ActivateCredential for TPMs, or manufacturer attestation
         verification for PIV tokens).  Binds the AK public key to the
         hardware device identified by the identity certificate.  If no
         Issuer enrollment has been performed, the AK certificate MAY be
         self-signed; verifiers SHOULD treat self-signed AK certificates
         as lower trust than Issuer-certified ones.

     2.  *Identity Certificate:* Issued by the hardware manufacturer at
         fabrication time.  For TPMs, this is the EK certificate.  For PIV
         tokens, this is the device attestation certificate.  Contains the
         hardware identity public key, manufacturer identity, and device
         information.  Signed by the manufacturer's intermediate CA.

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

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

  5.2.  Header Field Definition

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

















  Drake                    Expires 31 October 2026               [Page 20]


  Internet-Draft         Hardware Email Attestation             April 2026


     Hardware-Attestation = "Hardware-Attestation" ":" SP hw-attest-value
                            CRLF

     hw-attest-value = hw-version ";" SP
                       hw-type ";" SP
                       hw-algorithm ";" SP
                       hw-signed-hdrs ";" SP
                       hw-body-hash ";" SP
                       hw-timestamp ";" SP
                       hw-chain
                       [";" SP hw-aid]

     hw-version     = "v" "=" "1"
     hw-type        = "typ" "=" ("TPM" / "PIV" / "ENC" / "VRT" / "SFT")
     hw-algorithm   = "alg" "=" ("RS256" / "ES256" / "PS256")
     hw-signed-hdrs = "h" "=" hdr-name *(":" hdr-name)
     hw-body-hash   = "bh" "=" base64url
     hw-timestamp   = "ts" "=" 1*DIGIT
     hw-chain       = "chain" "=" base64
     hw-aid         = "aid" "=" aid-urn

     hdr-name       = field-name  ; as defined in RFC 5322
     base64url      = *( ALPHA / DIGIT / "-" / "_" )
                                   ; URL-safe base64 per RFC 4648 Sec 5
     base64         = *( ALPHA / DIGIT / "+" / "/" / "=" )
                                   ; standard base64 per RFC 4648 Sec 4

     The base64url and base64 encodings follow [RFC4648].

     Where:

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

     typ  The hardware attestation mechanism type.  "TPM" for Trusted
        Platform Module (discrete or firmware), "PIV" for Personal
        Identity Verification smart card, "ENC" for hardware enclave
        (e.g., Apple Secure Enclave), "VRT" for virtual TPM, "SFT" for
        software-managed key.  Additional values MAY be registered with
        IANA.

     alg  The signature algorithm used by the AK.  MUST be one of RS256
        (RSASSA-PKCS1-v1_5 with SHA-256), ES256 (ECDSA with P-256 and SHA-
        256), or PS256 (RSASSA-PSS with SHA-256).  RS256 is included for
        compatibility with existing TPM 2.0 deployments where RSA keys are
        pre-provisioned; new deployments SHOULD prefer PS256 (for RSA) or
        ES256 (for ECC).  ES256 is RECOMMENDED for PIV tokens.  Additional
        algorithms MAY be registered with IANA (see Section 13); future
        versions of this specification MAY deprecate algorithms by



  Drake                    Expires 31 October 2026               [Page 21]


  Internet-Draft         Hardware Email Attestation             April 2026


        updating the IANA registry.  Verifiers MUST reject algorithms not
        listed in the registry.  If SHA-256 is deprecated in the future, a
        new protocol version (v=2) would be required, as the hash
        algorithm is embedded in the attestation-digest construction.

     h  A colon-separated list of header field names included in the
        h-hash computation, following the same conventions as the DKIM h=
        tag ([RFC6376] Section 3.5).  The listed headers are canonicalised
        and concatenated (in the order listed) before hashing.  Signers
        MUST include at minimum: From, To, Subject, Date, and Message-ID.
        Signers SHOULD also include any Hardware-Trust-Proof header
        present in the same message.  The Hardware-Attestation header
        itself is always implicitly appended last (with the chain
        parameter value replaced by the empty string during computation,
        following the same self-inclusion technique as DKIM-Signature per
        [RFC6376] Section 3.7).  The Hardware-Attestation header MUST NOT
        appear in the h= list.  Because the header is included in h-hash,
        all of its parameters (including aid, typ, alg, bh, ts) are
        cryptographically bound to the signature.

     bh  The base64url-encoded SHA-256 hash of the canonicalised email
        body, computed using DKIM simple body canonicalisation exclusively
        (Section 3.4.3 of [RFC6376]).  DKIM relaxed body canonicalisation
        is NOT used for body hashing in this specification; only simple
        canonicalisation is supported, to ensure deterministic
        verification without requiring a canonicalisation algorithm
        negotiation parameter.

     ts  Unix timestamp (seconds since 1970-01-01T00:00:00Z) at which the
        attestation signature was created.  Unlike DKIM-Signature, this
        specification does not define a sender-declared expiry tag
        (analogous to DKIM's x= parameter).  Verifiers SHOULD apply their
        own freshness policy based on ts (e.g., rejecting attestations
        older than a configured threshold).  A future version of this
        specification MAY introduce an optional expiry parameter if
        operational experience demonstrates the need for sender-declared
        attestation lifetimes.

     chain  A base64-encoded CMS SignedData structure ([RFC5652]), using












  Drake                    Expires 31 October 2026               [Page 22]


  Internet-Draft         Hardware Email Attestation             April 2026


        the SignedData content type (OID 1.2.840.113549.1.7.2).  The
        encapContentInfo MUST be absent (detached signature).  The chain
        parameter MUST be present; the full CMS structure is always inline
        in the header, ensuring that verifiers can perform cryptographic
        validation without any external fetches.  The CMS structure
        contains: (a) the AK signature over the attestation digest (see
        below); (b) the AK certificate (Issuer-certified or self-signed);
        (c) the identity certificate (EK certificate for TPM, device
        attestation certificate for PIV); and (d) any intermediate CA
        certificates.

        The signed content is the SHA-256 hash of the concatenation of
        three fixed-length fields:

          attestation-input = h-hash || bh-raw || ts-bytes
          attestation-digest = SHA-256(attestation-input)
          signature = Sign(AK, attestation-digest)

          h-hash   = SHA-256(canonicalised-headers)  ; 32 bytes
          bh-raw   = SHA-256(canonicalised body)     ; 32 bytes
          ts-bytes = big-endian uint64(ts)           ; 8 bytes

        The attestation-input is exactly 72 bytes (32 + 32 + 8).  The
        canonicalised-headers input to h-hash is computed as follows: take
        the headers named in the h= parameter, in the order listed, each
        canonicalised per DKIM relaxed header canonicalisation ([RFC6376]
        Section 3.4.2) and terminated with CRLF.  Then append the
        Hardware-Attestation header itself, canonicalised the same way,
        with the chain parameter value replaced by the empty string, and
        without a trailing CRLF (matching the DKIM-Signature self-
        inclusion convention in [RFC6376] Section 3.7).  Because the
        Hardware-Attestation header contains the aid, typ, alg, bh, and ts
        parameters in their wire format, all of these values are
        cryptographically bound by h-hash.  In particular, the aid
        parameter cannot be modified after signing without changing h-hash
        and therefore invalidating the signature.

     aid  OPTIONAL.  The sender's agent identity URN as defined in













  Drake                    Expires 31 October 2026               [Page 23]


  Internet-Draft         Hardware Email Attestation             April 2026


        Section 4.1.  Because the Hardware-Attestation header is
        implicitly included in the canonicalised-headers input to h-hash
        (see the h and chain parameters above), the aid value is
        cryptographically bound to the signature.  Substitution or
        modification of the aid after signing invalidates the attestation.
        The agent identity URN is the RECOMMENDED primary key for
        reputation tracking; verifiers SHOULD prefer aid over the hardware
        fingerprint when both are available, as the agent identity
        persists across hardware migrations (see Section 4.2).  When aid
        is absent, the verifier can still validate the hardware
        certificate chain but has only the hardware fingerprint for
        reputation tracking.

  5.3.  Verification Algorithm

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

     1.   Parse the Hardware-Attestation header field and extract v, typ,
          alg, h, bh, ts, chain, and (if present) aid.  If parsing fails,
          the result is "none" (header malformed).

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

     3.   Verify that h lists at minimum From, To, Subject, Date, and
          Message-ID.  Compute h-hash as defined in Section 5.2:
          canonicalise the listed headers using DKIM relaxed header
          canonicalisation ([RFC6376] Section 3.4.2), each terminated with
          CRLF, then append the Hardware-Attestation header itself
          (canonicalised the same way, with the chain value replaced by
          the empty string, without a trailing CRLF), and compute SHA-256
          over the result.

     4.   Compute the SHA-256 hash of the canonicalised email body using
          DKIM simple body canonicalisation ([RFC6376] Section 3.4.3).
          Base64url-decode the bh parameter value and compare the
          resulting octets with the computed hash (exact byte-for-byte
          comparison).  If they differ, the result is "fail" (body
          modified).

     5.   Verify that ts is within an acceptable window of the current
          time.  A window of 300 seconds (5 minutes) is RECOMMENDED for
          direct SMTP delivery.  Verifiers SHOULD allow a wider window (up
          to 3600 seconds / 1 hour) for messages that have passed through
          intermediate MTAs, as indicated by Received headers or queue
          delays.  Messages delayed by greylisting (typically 15-30
          minutes) or by temporary MTA failures (potentially hours) may



  Drake                    Expires 31 October 2026               [Page 24]


  Internet-Draft         Hardware Email Attestation             April 2026


          exceed even this wider window.  Verifiers evaluating messages
          where the cryptographic signature is valid but the timestamp has
          expired SHOULD record the result as "pass" with an informational
          note about the timestamp age, rather than a hard "fail", because
          the signature's integrity is unaffected by delivery delays.
          Once the first inbound MTA (the MX record host) has verified the
          attestation and recorded the result in an Authentication-Results
          header, downstream systems SHOULD rely on that recorded result
          (potentially protected by ARC [RFC8617]) rather than re-
          evaluating timestamps.

     6.   Decode the base64 chain parameter to obtain the CMS SignedData
          structure.  Parse the CMS SignedData structure and extract the
          signer certificate (AK certificate) and the certificate chain.

     7.   Validate the certificate chain:

          a.  The AK certificate MUST contain evidence binding the AK
              public key to the identity certificate's device.  For TPM-
              based attestation, this is a TPM2_Certify structure (either
              in an X.509 extension or as the certificate's subject public
              key attestation).  For PIV-based attestation, this is the
              manufacturer's attestation certificate chain (e.g., Yubico's
              attestation certificate that certifies the key was generated
              on the device).  For Issuer-certified AK certificates, the
              Issuer verified this binding during enrollment and the AK
              certificate is signed by the Issuer's CA.  For self-signed
              AK certificates, the verifier SHOULD treat the binding as
              unverified and reduce trust accordingly.

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

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

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













  Drake                    Expires 31 October 2026               [Page 25]


  Internet-Draft         Hardware Email Attestation             April 2026


     8.   Reconstruct the attestation-digest as defined in Section 5.2:
          concatenate h-hash (32 bytes), bh-raw (32 bytes, the raw SHA-256
          digest of the canonicalised body), and ts-bytes (8 bytes, big-
          endian uint64 of ts), then compute SHA-256 over the 72-byte
          result.  Verify the CMS signature over this digest using the AK
          public key and the algorithm specified by alg.  If signature
          verification fails, the result is "fail" (bad signature).
          Because the Hardware-Attestation header (including the aid
          parameter) is included in the canonicalised-headers input to
          h-hash, any modification to any header parameter after signing
          causes verification to fail.

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

          *  Hardware type (from typ parameter)

          *  Hardware manufacturer (from identity certificate issuer)

          *  Device model or family (from identity certificate extensions)

          *  Hardware fingerprint: SHA-256 hash of the identity
             certificate's public key

          *  Agent identity URN (from aid parameter, if present)

     10.  If aid is present, the verifier MAY additionally:

          a.  Discover the Issuer's endpoints per Section 4.5.

          b.  Query reputation services using the aid URN as a lookup key.

          c.  Apply differentiated policy based on the agent's trust tier
              and reputation history.

  5.4.  Authentication-Results Integration

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










  Drake                    Expires 31 October 2026               [Page 26]


  Internet-Draft         Hardware Email Attestation             April 2026


     Authentication-Results: mx.example.com;
       hw-attest=pass
         header.typ=TPM
         header.alg=RS256
         header.mfr=INTC
         header.tier=sovereign
         header.fp=sha256:a1b2c3d4...
         header.aid=urn:aid:com.1id:1id-ty62muvf

     Where:

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

     header.typ  The hardware type from the Hardware-Attestation header.

     header.alg  The signature algorithm.

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

     header.tier  The inferred trust tier based on the hardware type and
        manufacturer.  Values: "sovereign", "portable", "enclave",
        "virtual", "declared".

     header.fp  The SHA-256 hash of the identity certificate's public key,
        truncated to the first 16 hex characters.  Serves as a compact
        hardware fingerprint for reputation tracking.  Full fingerprint
        SHOULD be available via an extended property.

     header.aid  The agent identity URN from the aid parameter, if
        present.  Omitted if no aid was provided.

  5.5.  Privacy Considerations for Direct Attestation

     Direct Hardware Attestation reveals the sender's persistent hardware
     fingerprint to every recipient.  This linkability is a deliberate
     design choice for reputation systems; see Section 15.2 for the full
     privacy analysis and Section 15.3 for the privacy-preserving
     alternative.







  Drake                    Expires 31 October 2026               [Page 27]


  Internet-Draft         Hardware Email Attestation             April 2026


  6.  Mode 2: SD-JWT Trust Proof

     This section defines an SD-JWT-based trust proof using [RFC9901].
     Like the CMS bundle in Mode 1, the SD-JWT is transport-independent
     (see Section 1.1).

  6.1.  Overview

     SD-JWT Trust Proof provides a privacy-preserving attestation
     mechanism where an Issuer (an entity that has previously verified the
     sender's hardware attestation) issues a per-message Selective
     Disclosure JWT [RFC9901] containing claims about the sender's trust
     classification and a cryptographic binding to the specific email
     being sent.

     The claim structure is JWT-shaped rather than a formal profile of the
     Entity Attestation Token (EAT) framework [RFC9711].  This choice
     prioritises deployment in JSON/JWT-native email infrastructure over
     alignment with the CBOR-leaning EAT ecosystem, which is currently
     most heavily deployed in IoT contexts via ARM's PSA Certified
     programme ([RFC9783]).  EAT's UEID, security-level, and profile
     mechanisms overlap with AID concepts (canonical identifier, trust
     tier, and namespace); AID claim names are chosen to be compatible
     with the EAT claims registry where overlap exists.  A future revision
     MAY define a formal EAT profile binding for Mode 2 tokens.

     For each outgoing email, the sending agent computes a message-binding
     hash (covering the email headers and body) and submits it to the
     Issuer over an authenticated channel.  The Issuer verifies that the
     requesting agent is currently enrolled with valid hardware, creates
     an SD-JWT containing the message-binding hash as a nonce claim, and
     returns the signed token with disclosure values for all selectively
     disclosable claims.  The agent then selects which claims to reveal
     and includes the SD-JWT presentation in the email header.

     Because the Issuer signs the SD-JWT (not the agent), no agent-
     specific key appears in the token.  A recipient learns only what the
     sender chose to disclose -- for example, "my hardware trust tier is
     sovereign" -- without learning the sender's identity, hardware
     fingerprint, or any other persistent identifier.  The Issuer
     identifier (iss) and the message-binding nonce are always visible;
     all other claims are selectively disclosable.

     This mode requires the recipient to trust the Issuer's signing key
     (obtainable via DNS or the Issuer's JWKS endpoint per Section 4.5).
     It does NOT require trust in any hardware manufacturer CA, as the
     Issuer has already performed that verification during enrollment.




  Drake                    Expires 31 October 2026               [Page 28]


  Internet-Draft         Hardware Email Attestation             April 2026


     The per-message Issuer interaction is the cost of full unlinkability:
     the agent must contact the Issuer for each email, and the Issuer
     becomes an availability dependency for Mode 2 senders.  If the Issuer
     is unreachable, the agent MAY fall back to Mode 1 (Direct Hardware
     Attestation) if its policy permits hardware fingerprint disclosure,
     or MAY defer sending until the Issuer recovers.  The Issuer learns
     that the agent is sending a message (and the timing thereof) but does
     not learn the message content -- only the message-binding hash, which
     is a SHA-256 digest from which content cannot be recovered.  Issuers
     MUST NOT log message-binding hashes or correlate them with message
     metadata beyond what is necessary for rate limiting and abuse
     prevention.

  6.2.  Header Field Definition

     Hardware-Trust-Proof = "Hardware-Trust-Proof" ":" SP
                            sd-jwt-presentation CRLF

     sd-jwt-presentation = sd-jwt "~" *( disclosure "~" )

     ; sd-jwt and disclosure are defined in RFC 9901

     The header value is an SD-JWT presentation as defined in [RFC9901],
     consisting of the Issuer-signed JWT followed by zero or more
     disclosures.  No Key Binding JWT (KB-JWT) is included; message
     binding is provided by the nonce claim in the Issuer-signed payload
     (see Section 6.3).

     The SD-JWT payload MUST include the following claims:

     iss  The Issuer's identifier (a URI matching the Issuer domain
        derived from the agent's URN namespace).  Used to locate the
        Issuer's signing key for signature verification.

     iat  Issuance time as a NumericDate.  Because the SD-JWT is per-
        message, iat reflects the time the Issuer signed this specific
        token.

     exp  Expiration time as a NumericDate.  MUST NOT exceed 600 seconds
        (10 minutes) after iat.  This short validity window is appropriate
        because the SD-JWT is per-message: the agent requests a fresh
        token for each email, and the token need only remain valid long
        enough for the message to traverse the sending mail
        infrastructure.  Issuers SHOULD set exp to 300 seconds (5 minutes)
        after iat for typical deployments.

     nonce  A base64url-encoded message-binding digest that




  Drake                    Expires 31 October 2026               [Page 29]


  Internet-Draft         Hardware Email Attestation             April 2026


        cryptographically ties this SD-JWT to a specific email.  Computed
        as defined in Section 6.3.  This claim MUST be present and MUST
        NOT be selectively disclosable.

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

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

     trust_tier  The sender's hardware trust classification.  Values
        include "sovereign" (genuine non-virtual hardware TPM), "portable"
        (smart card / USB token), "enclave" (hardware enclave such as
        Apple Secure Enclave), "virtual" (hypervisor-provided), and
        "declared" (software-only).

     sub  The sender's agent identity URN as defined in Section 4.1.

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

     hw_manufacturer  The hardware manufacturer code (e.g., "INTC", "AMD",
        "YBK").

     enrolled_at  The timestamp at which the sender enrolled with the
        Issuer.

     operator_email  A contact address for the human operator responsible
        for this agent.  Allows relying parties to reach the accountable
        person without requiring the agent identity itself to be
        disclosed.

     hardware_locked  Boolean indicating whether the identity is
        permanently bound to a single hardware device.  Once locked, the
        agent can no longer add or migrate to new devices.  This is an
        irreversible operation.

     locked_at  Timestamp (ISO 8601) at which the hardware lock was
        applied.  Present only when hardware_locked is true.

     credential_pointer_count  Integer count of registered credential
        pointers for this identity.  Allows a verifier to confirm that an
        agent has external credentials on file without revealing the
        credentials themselves.








  Drake                    Expires 31 October 2026               [Page 30]


  Internet-Draft         Hardware Email Attestation             April 2026


  6.3.  Message Binding via Issuer-Signed Nonce

     Each Mode 2 SD-JWT is per-message: the Issuer signs a fresh token for
     each email, incorporating a nonce claim that cryptographically binds
     the token to the specific message being sent.  Because the Issuer
     signs the token directly (rather than the agent signing a Key Binding
     JWT with a key embedded in the token), no agent-specific
     cryptographic material appears in the presentation.

     The message-binding nonce is computed by the sending agent before
     requesting the SD-JWT from the Issuer:

       message-binding = h-hash || bh-raw || ts-bytes
       nonce = base64url(SHA-256(message-binding))

       h-hash   = SHA-256(canonicalised-headers)  ; 32 bytes
       bh-raw   = SHA-256(canonicalised body)     ; 32 bytes
       ts-bytes = big-endian uint64(iat)          ; 8 bytes

     The agent proposes an iat value (its current time) when requesting
     the token; the Issuer MUST reject proposed timestamps that differ
     from the Issuer's clock by more than 60 seconds.  The accepted iat
     becomes both the SD-JWT's iat claim and the timestamp used in ts-
     bytes, ensuring sender and verifier agree on the value.

     The canonicalised-headers are computed using the same rules as Mode 1
     (see Section 5.2): the headers From, To, Subject, Date, and Message-
     ID (at minimum) are canonicalised per DKIM relaxed header
     canonicalisation ([RFC6376] Section 3.4.2), each terminated with
     CRLF, then the Hardware-Trust-Proof header itself is appended last
     (canonicalised the same way, with its value replaced by the empty
     string, without a trailing CRLF).  The value is blanked because the
     SD-JWT token has not yet been obtained at the time the nonce is
     computed (the nonce is an input to the Issuer, which returns the SD-
     JWT that will become the header value); the header name and field
     separator are retained so that the choice of header is bound to the
     nonce.  This is the same self-inclusion technique used by DKIM-
     Signature ([RFC6376] Section 3.7) and by Mode 1 (see Section 5.2).













  Drake                    Expires 31 October 2026               [Page 31]


  Internet-Draft         Hardware Email Attestation             April 2026


     The agent submits the computed nonce and proposed iat to the Issuer
     over an authenticated channel (e.g., TLS client certificate
     authentication using the agent's hardware-resident key, or an OAuth2
     token obtained during enrollment).  The Issuer verifies that the
     requesting agent is currently enrolled with valid hardware and has
     not been revoked, then creates and signs an SD-JWT containing the
     nonce along with selectively disclosable claims about the agent.  The
     Issuer returns the signed SD-JWT and the disclosure values for all
     selectively disclosable claims.  The agent selects which disclosures
     to include in the presentation.

     Because the nonce is embedded in the Issuer-signed payload, any
     modification to the email headers or body after the token is issued
     causes the nonce to mismatch during verification.  Because the
     Hardware-Trust-Proof header is included in the canonicalised-headers
     (with its value blanked during nonce computation), the choice of
     disclosed claims is also bound to the message.

     The Issuer's signature on the nonce serves a dual purpose: it proves
     that a currently enrolled agent with verified hardware requested this
     specific message binding, and it asserts the Issuer's claims about
     the agent's trust classification.  No agent-specific key appears in
     the token, so recipients cannot link multiple emails to the same
     sender based on the Mode 2 header alone.

  6.4.  Verification Algorithm

     1.  Parse the Hardware-Trust-Proof header as an SD-JWT presentation
         per [RFC9901].  The presentation consists of the Issuer-signed
         JWT and zero or more disclosures; no Key Binding JWT is expected.

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

     3.  Obtain the Issuer's public key.  The verifier MUST first check
         for a DNS-published key (see Section 4.5.1).  If no DNS record is
         found, the verifier MAY fall back to the Issuer's HTTPS JWKS
         endpoint (e.g., {iss}/.well-known/jwks.json).  Cached keys SHOULD
         have a TTL of at least 1 hour and at most 24 hours.

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

     5.  Verify that exp has not passed and iat is within an acceptable
         window.  Because Mode 2 SD-JWTs are per-message, the RECOMMENDED
         exp is 300 seconds after iat; verifiers SHOULD reject tokens
         where the Issuer-set exp exceeds iat by more than 600 seconds
         (indicating a misconfigured Issuer).  However, the verifier's
         freshness check against real-world clock time should accommodate



  Drake                    Expires 31 October 2026               [Page 32]


  Internet-Draft         Hardware Email Attestation             April 2026


         delivery delays: if the SD-JWT signature is valid and the iat-to-
         exp span is reasonable but the current time exceeds exp due to
         greylisting or queue delays, the verifier SHOULD treat the result
         as "pass" with an informational timestamp-age note rather than a
         hard "fail" (see the corresponding guidance for Mode 1 timestamp
         validation in Section 5.3).

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

     7.  Verify the message binding.  Extract the nonce claim from the SD-
         JWT payload.  If absent, the result is "fail" (missing message
         binding).  Recompute the expected message-binding digest as
         defined in Section 6.3: canonicalise the email headers (From, To,
         Subject, Date, Message-ID at minimum) and body, compute message-
         binding = h-hash || bh-raw || ts-bytes (using the SD-JWT's iat
         for ts-bytes), then base64url(SHA-256(message-binding)).  Compare
         the result with the nonce claim value.  If they differ, the
         result is "fail" (message binding mismatch).

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

  6.5.  Authentication-Results Integration

     Authentication-Results: mx.example.com;
       hw-trust=pass
         header.trust_tier=sovereign
         header.registry=1id.com

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

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

     header.registry  The Issuer domain (derived from the iss claim).

  7.  Combined Mode

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

     *  Receivers that trust hardware manufacturer CAs but not the Issuer
        SHOULD verify Hardware-Attestation and ignore Hardware-Trust-
        Proof.





  Drake                    Expires 31 October 2026               [Page 33]


  Internet-Draft         Hardware Email Attestation             April 2026


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

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

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

  8.  Sybil Resistance Properties

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

  8.1.  Direct Hardware Attestation (Mode 1)

     Each hardware security component contains exactly one identity key,
     which produces exactly one identity certificate.  The hardware
     fingerprint (identity certificate public key hash) provides the
     underlying Sybil resistance: creating N identities requires N
     physical devices.

     The agent identity URN (aid) is the RECOMMENDED primary key for
     reputation tracking.  When aid is present, verifiers SHOULD build
     reputation against the aid rather than the hardware fingerprint,
     because the aid persists across hardware migrations (see
     Section 4.2).  The hardware fingerprint serves as a secondary signal
     that anchors the identity to physical hardware and enables reputation
     tracking for agents that do not present an aid.

     A receiving mail server that tracks agent identities (or, when aid is
     absent, hardware fingerprints) can enforce policies such as:

     *  Rate limiting per agent identity

     *  Reputation scoring per agent identity

     *  Blocking agent identities associated with abuse

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



  Drake                    Expires 31 October 2026               [Page 34]


  Internet-Draft         Hardware Email Attestation             April 2026


     Multiple agents sharing the same hardware (e.g., multiple VMs on a
     server with a single TPM) share the same hardware fingerprint and
     therefore linked reputations.  This shared fate model creates
     economic incentive for infrastructure operators to police their
     tenants: if one agent on a machine misbehaves, all agents on that
     machine inherit the reputational consequences.

  8.2.  SD-JWT Trust Proof (Mode 2)

     Sybil resistance in Mode 2 depends on the Issuer's enrollment policy.
     An Issuer that assigns trust_tier values indicating hardware
     verification (e.g., "sovereign") MUST verify hardware attestation at
     enrollment time and MUST enforce the cardinality constraints defined
     in Section 4.2: at most one agent identity per hardware device within
     that Issuer's namespace, while permitting hardware migration
     (multiple devices backing the same identity over time).  Such an
     Issuer provides equivalent Sybil resistance to Mode 1, with the
     additional benefit that the hardware fingerprint is not revealed to
     email recipients.

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

     An Issuer that enrolls software-only agents (trust_tier "declared")
     provides no hardware-based Sybil resistance and MUST NOT assign
     trust_tier values that imply hardware verification.  The trust_tier
     claim distinguishes these cases, enabling recipients to weight trust
     appropriately.

  8.3.  Virtual Hardware

     Virtual TPMs (vTPMs) provided by hypervisors (VMware, Hyper-V, QEMU)
     have valid identity certificates signed by the hypervisor vendor's
     CA, but the hypervisor operator can instantiate arbitrary numbers of
     vTPMs.  Virtual TPMs therefore provide no hardware-based Sybil
     resistance against the hypervisor operator.  They do, however,
     provide benefits over software-only keys (typ=SFT):

     *  Key persistence managed by the hypervisor (the agent does not need
        to store key material).

     *  Modest cost barriers (provisioning a vTPM is slower and more
        resource-intensive than generating a software key pair).

     *  Reputation accumulation incentive (discarding a vTPM identity
        forfeits its accumulated reputation).



  Drake                    Expires 31 October 2026               [Page 35]


  Internet-Draft         Hardware Email Attestation             April 2026


     Receiving mail servers MUST distinguish between physical and virtual
     hardware.  The identity certificate's issuer field identifies the
     manufacturer: VMware-issued or Microsoft Hyper-V-issued certificates
     indicate a virtual TPM.  The header.tier property in Authentication-
     Results ("sovereign" vs "virtual") and the typ parameter ("TPM" vs
     "VRT") communicate this distinction.

     Mail servers SHOULD apply significantly different reputation
     thresholds for virtual vs. physical hardware.  For high-trust
     scenarios, verifiers MAY reject virtual TPM attestation entirely and
     require physical hardware (typ=TPM or typ=PIV).

  9.  Interaction with Existing Email Authentication

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

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

     DKIM [RFC6376]  Provides domain-level signing.  Hardware-Attestation
        provides device-level signing.  They protect different properties:
        DKIM proves domain authorisation; Hardware-Attestation proves
        hardware identity.  Both SHOULD be used.

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

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

     S/MIME [RFC8551]  Provides end-to-end encryption and sender signing
        via CA-issued certificates.  S/MIME and Hardware-Attestation
        operate at different layers and coexist without interference: S/
        MIME wraps or signs the message body within MIME structures, while
        Hardware-Attestation adds a header field alongside the message.
        The body hash (bh) in the Hardware-Attestation header is computed
        over the raw canonicalised body, including any S/MIME MIME
        structures.  A message MAY carry both S/MIME signatures and
        hardware attestation simultaneously.

     OpenPGP / PGP/MIME [RFC3156]  Like S/MIME, OpenPGP operates at the






  Drake                    Expires 31 October 2026               [Page 36]


  Internet-Draft         Hardware Email Attestation             April 2026


        body level (encrypting or signing the message content within MIME
        structures).  Hardware-Attestation operates at the header level.
        The two mechanisms are fully orthogonal: a PGP-signed message can
        carry a Hardware-Attestation header, and the verifier processes
        each independently.

  9.1.  Multiple Headers and Forwarding

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

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

  9.2.  Handle Display in Email

     When a sending agent has a registered handle (as defined in the
     companion registry specification
     [I-D.drake-agent-identity-registry]), the From header display name
     SHOULD be the agent's handle.  This makes agent identity visible to
     human recipients without requiring them to interpret URNs or hardware
     fingerprints.

     For example, an agent with handle "crusty" in the "global" namespace
     would send with:

     From: crusty.global <agent-a7f3c2e9@agents.example.com>

     The URN remains the authoritative identifier and appears in the
     Hardware-Attestation header's aid parameter.  The From display name
     is a human convenience that SHOULD match the handle when one is
     registered.







  Drake                    Expires 31 October 2026               [Page 37]


  Internet-Draft         Hardware Email Attestation             April 2026


  10.  Message Submission Requirements

     The attestation signature in the Hardware-Attestation header is
     produced by the sending agent, not by the mail server.  When the aid
     parameter is present, it is cryptographically bound to the signature
     (see Section 5.2), so any modification of the aid after signing
     causes verification to fail at the receiving end.  As defence-in-
     depth, Mail Submission Agents (MSAs) that accept messages from
     hardware-attested senders MUST also enforce identity binding at
     submission time, rejecting messages before they enter the mail system
     rather than relying solely on receiver-side verification.

     Agents submitting messages through an attestation-aware MSA MUST
     authenticate to the MSA.  The MSA SHOULD support authentication using
     the agent's hardware-resident key (e.g., TLS client certificate
     authentication where the client certificate is signed by the same AK
     used for attestation, or a challenge-response protocol using the TPM
     or PIV signing key).  This ensures that the MSA can verify the
     submitting agent controls the hardware corresponding to the
     attestation header, preventing credential-theft scenarios where SMTP
     credentials are compromised but the hardware is not.

  10.1.  Agent Identity Binding at Submission

     When an MSA receives a message containing a Hardware-Attestation
     header with an aid (agent identity) parameter, the MSA MUST verify
     that the aid value corresponds to the authenticated account
     submitting the message.  The binding between authenticated account
     and permitted agent identity URN(s) is established during account
     provisioning and is outside the scope of this specification, but the
     enforcement is normative:

     *  If the aid value does not match any agent identity URN authorised
        for the submitting account, the MSA MUST reject the message with
        an appropriate error (e.g., SMTP 550 "5.7.1 Agent identity not
        authorised for this account").

     *  If the Hardware-Attestation header is present but contains no aid
        parameter, the MSA SHOULD still verify that the hardware
        fingerprint (derived from the chain parameter) corresponds to
        hardware registered to the submitting account, if such a registry
        is available.

     *  If the MSA does not implement hardware attestation verification,
        it MUST NOT strip or modify the Hardware-Attestation header.  The
        header will be evaluated by downstream verifiers.





  Drake                    Expires 31 October 2026               [Page 38]


  Internet-Draft         Hardware Email Attestation             April 2026


     This requirement parallels the existing SMTP AUTH obligation: just as
     an MSA enforces that the envelope sender (MAIL FROM) and header From
     address belong to the authenticated user, an attestation-aware MSA
     enforces that the agent identity belongs to the authenticated agent.

  10.2.  Hardware Fingerprint Binding at Submission

     For Mode 1 (Direct Hardware Attestation), the MSA SHOULD extract the
     hardware fingerprint from the attestation chain and verify it against
     the fingerprint registered to the submitting account.  This prevents
     an attacker who has obtained valid SMTP credentials from substituting
     a different device's attestation evidence.

     For Mode 2 (SD-JWT Trust Proof), the MSA SHOULD verify that the
     Issuer (iss claim) and, if disclosed, the agent identity URN (sub
     claim) are consistent with the submitting account's registered
     identity.

  10.3.  Messages Without Attestation

     An MSA that serves hardware-attested agents MAY also accept messages
     without Hardware-Attestation or Hardware-Trust-Proof headers, subject
     to its own policy.  The absence of attestation headers from a known-
     attested account SHOULD be logged as anomalous but MUST NOT cause
     message rejection unless the account's policy explicitly requires
     attestation on every message.

  10.4.  Duplicate Header Rejection

     An MSA MUST reject any submitted message that contains more than one
     Hardware-Attestation header field.  A legitimate sender produces
     exactly one attestation per message.  Multiple Hardware-Attestation
     headers in a submitted (non-forwarded) message indicate either a
     software defect or an injection attempt.  This check MUST occur
     before DKIM signing, so that the MSA never signs a message containing
     duplicate attestation headers.

  10.5.  Timestamp Validation at Submission

     The MSA SHOULD verify that the ts value in the Hardware-Attestation
     header is within a reasonable window of the current time
     (RECOMMENDED: 60 seconds).  A timestamp significantly in the past may
     indicate a replayed header; a timestamp in the future may indicate
     clock manipulation intended to extend the attestation's apparent
     validity.  If the timestamp is outside the acceptable window, the MSA
     SHOULD reject the message.





  Drake                    Expires 31 October 2026               [Page 39]


  Internet-Draft         Hardware Email Attestation             April 2026


  11.  Interoperability Considerations

  11.1.  Backward Compatibility

     This specification introduces new email headers that are ignored by
     mail servers that do not implement it.  Messages carrying Hardware-
     Attestation or Hardware-Trust-Proof headers are fully compatible with
     legacy mail infrastructure: the headers are simply unrecognised and
     have no effect on delivery.  This ensures that deployment can proceed
     incrementally without disrupting existing email flows.

  11.2.  DKIM Coverage of Attestation Headers

     Because the sending agent adds the Hardware-Attestation and Hardware-
     Trust-Proof headers before submitting the message to the MSA, DKIM
     signing (which occurs at the MSA or a downstream MTA) naturally
     occurs after these headers are present.  The DKIM signer SHOULD
     include Hardware-Attestation and Hardware-Trust-Proof in the DKIM-
     Signature h= tag so that the DKIM signature protects the attestation
     evidence against modification in transit.  This allows a verifier to
     confirm that the domain owner's mail infrastructure accepted the
     attestation header as submitted by the agent.

  11.3.  Header Size Considerations

     The base64-encoded CMS chain in Mode 1 can be several kilobytes,
     depending on the number of intermediate CA certificates.
     Implementations SHOULD use line folding per [RFC5322] to keep
     individual header lines within the 998-octet limit.  Mail servers
     that impose maximum header size limits SHOULD allow at least 8192
     octets for the Hardware-Attestation header value.

  12.  Implementation Status

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

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

  12.1.  1id.com Issuer

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

     Description: An implementation of both Mode 1 (Direct Hardware
     Attestation) and Mode 2 (SD-JWT Trust Proof) as described in this
     draft.  The implementation includes server-side identity certificate
     chain validation against manufacturer root CAs (Intel, AMD, Infineon,



  Drake                    Expires 31 October 2026               [Page 40]


  Internet-Draft         Hardware Email Attestation             April 2026


     STMicroelectronics, Nuvoton, Qualcomm, Yubico), anti-Sybil
     enforcement via a one-device-per-identity registry, and SD-JWT trust
     proof issuance with selective disclosure of nine claims (sub, handle,
     trust_tier, hw_manufacturer, enrolled_at, operator_email,
     hardware_locked, locked_at, credential_pointer_count).  The system
     supports both TPM-based and PIV-based (YubiKey) attestation,
     including co-location binding ceremonies.  Agent identities use the
     urn:aid:com.1id: namespace.

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

     Coverage: Both Mode 1 (Direct Hardware Attestation via CMS
     SignedData) and Mode 2 (SD-JWT Trust Proof) are implemented for TPM-
     backed identities (sovereign and virtual tiers) and for Apple Secure
     Enclave (enclave tier).  Mode 2 is additionally implemented for PIV/
     YubiKey (portable tier) and declared (software-only) tiers.  Dynamic
     trust tiering is supported: the same identity produces different
     trust_tier claims depending on which device is used for
     authentication.  Features include transient-only AK model for TPM
     attestation with no NV storage writes, multi-device identity
     management with hardware lock, and per-message SD-JWT issuance.  Live
     email examples from this implementation -- all independently
     verifiable using the hw-attest-verify tool -- are included in
     Appendix C.

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

     Open-source components:

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

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

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

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

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



  Drake                    Expires 31 October 2026               [Page 41]


  Internet-Draft         Hardware Email Attestation             April 2026


  12.2.  MailPal.com Verifier and Relay

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

     Description: An email service (Stalwart Mail Server on Linux)
     intended to implement end-to-end hardware attestation for both
     sending and receiving.  Planned capabilities include: on the outbound
     path, MSA validation of Hardware-Attestation and Hardware-Trust-Proof
     headers at submission time per Section 10, agent identity binding
     enforcement, and attestation header inclusion in DKIM signature
     coverage.  On the inbound path, verification of both Mode 1
     certificate chains and Mode 2 SD-JWT trust proofs, Authentication-
     Results recording per Section 5.4 and Section 6.5, and trust-tier-
     differentiated delivery policy.

     Maturity: Alpha.  Mail infrastructure deployed at
     https://mailpal.com; inbound attestation header verification
     implemented via milter integration.

     Coverage: Mail transport infrastructure is operational.  Inbound
     verification of both Mode 1 (CMS certificate chain) and Mode 2 (SD-
     JWT trust proof) headers is implemented via a pure-Python milter
     daemon that adds Authentication-Results headers per Section 5.4 and
     Section 6.5.  All five trust tiers (sovereign, portable, enclave,
     virtual, declared) are verified in production.  The Authentication-
     Results headers embedded in the examples in Appendix C were generated
     by this milter during live SMTP reception.  Attestation header
     generation at submission time is in development.

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

     Open-source components:

     *  *Attestation verification library and CLI:*
        https://github.com/1id-com/hw-attest-verify -- Verification of
        Mode 1 CMS attestation bundles and Mode 2 SD-JWT trust proofs.
        Published to PyPI as "hw-attest-verify" (pip install hw-attest-
        verify).  Includes a command-line tool for verifying .eml files
        and a library suitable for integration into any MTA or mail
        filter.  Used to verify the live examples in Appendix C.

  13.  IANA Considerations

  13.1.  Header Field Registration

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




  Drake                    Expires 31 October 2026               [Page 42]


  Internet-Draft         Hardware Email Attestation             April 2026


     Hardware-Attestation  Applicable protocol: mail.  Status:
        experimental.  Reference: this document, Section 5.2.

     Hardware-Trust-Proof  Applicable protocol: mail.  Status:
        experimental.  Reference: this document, Section 6.2.

  13.2.  Authentication Method Registration

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

     Method: hw-attest.  Definition: this document, Section 5.4.  ptype:
     header.  Properties:

       +==========+============+=======================================+
       | Property | Value Type | Description                           |
       +==========+============+=======================================+
       | typ      | token      | Hardware attestation mechanism type   |
       |          |            | (TPM, PIV, ENC, VRT, SFT)             |
       +----------+------------+---------------------------------------+
       | alg      | token      | Signature algorithm (RS256, ES256,    |
       |          |            | PS256)                                |
       +----------+------------+---------------------------------------+
       | mfr      | token      | Manufacturer code from identity       |
       |          |            | certificate                           |
       +----------+------------+---------------------------------------+
       | tier     | token      | Inferred trust tier (sovereign,       |
       |          |            | portable, enclave, virtual, declared) |
       +----------+------------+---------------------------------------+
       | fp       | value      | Truncated SHA-256 fingerprint of      |
       |          |            | identity certificate public key       |
       +----------+------------+---------------------------------------+
       | aid      | value      | Agent identity URN, if present        |
       +----------+------------+---------------------------------------+

                                    Table 2

     Result values: "pass" (all checks succeeded), "fail" (cryptographic
     verification failed), "none" (header absent or unparseable),
     "temperror" (transient verification error, e.g., DNS timeout),
     "permerror" (permanent verification error, e.g., unsupported
     version).

     Method: hw-trust.  Definition: this document, Section 6.5.  ptype:
     header.  Properties:






  Drake                    Expires 31 October 2026               [Page 43]


  Internet-Draft         Hardware Email Attestation             April 2026


           +============+============+=============================+
           | Property   | Value Type | Description                 |
           +============+============+=============================+
           | trust_tier | token      | Disclosed trust tier value, |
           |            |            | if revealed by the sender   |
           +------------+------------+-----------------------------+
           | registry   | value      | Issuer domain (derived from |
           |            |            | the iss claim)              |
           +------------+------------+-----------------------------+

                                    Table 3

     Result values: "pass", "fail", "none", "temperror", "permerror" (same
     semantics as hw-attest).

  13.3.  Hardware Attestation Type Registry

     IANA is requested to create a new registry titled "Hardware
     Attestation Type Values" with the following initial entries.  New
     entries require Specification Required ([RFC8126]).  The designated
     expert(s) should be selected from the hardware security and email
     authentication communities and should verify that proposed values
     correspond to a distinct class of hardware security mechanism with
     attestation capabilities not adequately covered by existing entries.

          +=======+================================+===============+
          | Value | Description                    | Reference     |
          +=======+================================+===============+
          | TPM   | TPM 2.0 (discrete or firmware) | this document |
          +-------+--------------------------------+---------------+
          | PIV   | PIV smart card / USB token     | this document |
          +-------+--------------------------------+---------------+
          | ENC   | Hardware enclave (e.g., Apple  | this document |
          |       | Secure Enclave)                |               |
          +-------+--------------------------------+---------------+
          | VRT   | Virtual TPM (hypervisor-       | this document |
          |       | provided)                      |               |
          +-------+--------------------------------+---------------+
          | SFT   | Software-managed key           | this document |
          +-------+--------------------------------+---------------+

                                   Table 4

  13.4.  URN Namespace Registration

     IANA is requested to register the "aid" URN namespace identifier in
     the "Formal URN Namespaces" registry per [RFC8141].  The registration
     template is provided in Appendix E.



  Drake                    Expires 31 October 2026               [Page 44]


  Internet-Draft         Hardware Email Attestation             April 2026


  14.  Security Considerations

  14.1.  Manufacturer CA Compromise

     If a hardware manufacturer's root CA private key is compromised, an
     attacker could forge identity certificates and create unlimited fake
     hardware identities.  This risk is inherent to any PKI-based system
     and is mitigated by the same measures that protect manufacturer CAs
     today: hardware security modules, air-gapped signing ceremonies, and
     Certificate Transparency [RFC9162].

     The SD-JWT Trust Proof (Mode 2) provides partial mitigation: if the
     Issuer detects anomalous enrollment patterns (e.g., thousands of
     enrollments from a single manufacturer CA in a short period), it can
     suspend enrollments while the compromise is investigated.

  14.2.  Revocation and Compromise Response

     This specification does not define a real-time certificate revocation
     protocol.  Compromise of individual hardware devices or keys is
     handled at multiple layers:

     Compromised or stolen device (TPM, YubiKey)  The device owner
        notifies their Issuer, which revokes the agent identity.  The
        Issuer publishes revocation status via its JWKS or a revocation
        endpoint; verifiers that cache Issuer metadata will detect the
        revocation at the next refresh.  For Mode 1, the hardware
        fingerprint SHOULD be added to a local blocklist.  The device's
        reputation history (which now includes the abuse) persists and
        follows the hardware fingerprint even if re-enrolled under a new
        identity.

     Manufacturer CA breach  Verifiers MUST remove the compromised CA from
        their trust store.  The IANA Hardware Attestation Type registry
        (see Section 13) and the community-maintained manufacturer CA
        trust store (see Appendix B) provide distribution channels for
        updated trust anchors.

     Rogue Issuer  Verifiers remove the Issuer from their allowlist.
        Because Issuer trust is a local policy decision (see
        Section 14.12), no central revocation mechanism is required: each
        verifier independently decides which Issuers to trust, analogous
        to browser root store management for TLS CAs.








  Drake                    Expires 31 October 2026               [Page 45]


  Internet-Draft         Hardware Email Attestation             April 2026


     The absence of a real-time revocation check (such as OCSP) is a
     deliberate trade-off: adding a synchronous revocation check to the
     email delivery path would introduce latency and a new availability
     dependency.  The short validity window for SD-JWT trust proofs (600
     seconds) and the per-message timestamp in Mode 1 limit the exposure
     window for compromised credentials.

  14.3.  Replay Attacks

     The timestamp (ts) in the Hardware-Attestation header limits the
     replay window.  Receiving mail servers SHOULD reject attestations
     with timestamps more than 300 seconds from the current time for
     direct SMTP delivery, and up to 3600 seconds for messages with
     evidence of intermediate relay hops.  Additionally, the body hash
     (bh) binds the attestation to a specific email body, preventing a
     valid attestation from being attached to a different message.

     For SD-JWT Trust Proofs, each SD-JWT is per-message: the nonce claim
     in the Issuer-signed payload binds the token to the specific email's
     headers and body, and the short validity window (RECOMMENDED 300
     seconds) limits the replay window.  An attacker who intercepts a
     valid SD-JWT cannot reuse it for a different message because the
     nonce will not match.

  14.4.  Compromised Endpoints

     This specification does not prevent a compromised device from sending
     attested email -- if an attacker has full control of a device with
     hardware security, they can use that hardware to attest.  However,
     this is by design: each compromised device contributes exactly one
     hardware identity, and that identity accrues reputation (good or bad)
     permanently.  A botnet of 10,000 compromised devices yields 10,000
     attestable identities, not the millions possible with software-only
     identity systems.

     The transient key model (Section 4.4) reduces the privilege
     requirements for per-message signing.  Initial enrollment (the one-
     time MakeCredential / ActivateCredential exchange) typically requires
     elevated operating system privileges (administrator on Windows via
     the TPM Base Services API, or root on Linux via /dev/tpmrm0).
     Subsequent signing operations (TPM2_Sign with the transient AK) MAY
     be available to unprivileged processes depending on the operating
     system configuration.  On Windows, a one-time registry configuration
     can grant non-administrator processes access to TPM signing
     operations.






  Drake                    Expires 31 October 2026               [Page 46]


  Internet-Draft         Hardware Email Attestation             April 2026


     The net effect is that hardware attestation raises the bar for email
     abuse from "any script" to "compromise of a specific physical
     device," which is a substantial improvement over the status quo even
     if it is not a complete solution.

  14.5.  Physical Attacks on Hardware Security Components

     Extracting private keys from a TPM or PIV token requires physical
     attacks such as electron microscopy, laser fault injection, or side-
     channel analysis.  Modern security components include countermeasures
     against these attacks.  The cost and expertise required for
     successful key extraction is estimated at $50,000-$200,000 per chip,
     making it economically unviable for spam operations.

     Even if key extraction were feasible, the extracted key could only
     impersonate one hardware identity.  The attacker would still need to
     extract keys from additional devices to create additional identities.

  14.6.  Virtual Hardware Risk

     Virtual TPMs do not provide the same Sybil resistance as physical
     hardware; see Section 8.3 for the detailed analysis and policy
     guidance.

  14.7.  Software-Only Attestation Risk

     Software-managed keys (typ=SFT) provide no hardware-based Sybil
     resistance; an attacker can generate unlimited key pairs at zero
     cost.  Verifiers MUST treat software-only attestation (trust_tier
     "declared") as fundamentally weaker than hardware-backed attestation.
     Software-only attestation exists to enable inclusive participation,
     not to provide Sybil resistance (see Section 1.1).

  14.8.  Transient Object Slot Limits

     TPMs have a limited number of transient object slots (typically 3 to
     7 simultaneously loaded objects).  If all slots are occupied,
     TPM2_CreatePrimary returns TPM_RC_OBJECT_MEMORY (0x0902).
     Implementations MUST handle this error by flushing unused transient
     handles (TPM2_FlushContext) and retrying.  Failure to flush transient
     objects can cause denial of service to other TPM-using applications
     on the same device.









  Drake                    Expires 31 October 2026               [Page 47]


  Internet-Draft         Hardware Email Attestation             April 2026


  14.9.  Policy Abuse and Deanonymisation Risk

     This specification targets AI agents, bots, and autonomous systems
     (see Section 3).  It is not intended for individual human senders and
     is not expected to be incorporated into Mail User Agents (MUAs)
     designed for interactive human use.  The privacy trade-offs inherent
     in hardware attestation -- particularly the persistent hardware
     fingerprint exposed by Mode 1 -- are acceptable for automated senders
     whose identity is operationally transparent, but disproportionate for
     human correspondence.

     However, an AI agent may compose and send email on behalf of an
     individual (e.g., an executive assistant agent sending calendar
     invitations, or a customer service agent responding to support
     tickets).  In such delegated-sending scenarios, the attestation
     identifies the agent and its hardware, not the human principal.
     Operators deploying agents that send on behalf of individuals SHOULD
     be aware that the persistent hardware fingerprint (Mode 1) or the
     Issuer identifier (Mode 2) may allow recipients to correlate messages
     across different human principals served by the same agent.  Where
     this correlation is undesirable, operators SHOULD use Mode 2 without
     disclosing the agent identity URN, or SHOULD deploy separate agent
     identities per human principal.

     The persistent hardware fingerprint exposed by Mode 1 (see
     Section 15.2 for linkability details) creates specific abuse
     scenarios even in automated contexts:

     *  Authoritarian regimes could correlate hardware fingerprints across
        messages to identify the organisations operating specific agents.

     *  Platforms could mandate Mode 1 attestation to deanonymise agents
        that have legitimate reasons for pseudonymity (e.g.,
        whistleblower-support bots, journalist-source-protection agents).

     *  Receiving mail servers that log hardware fingerprints create long-
        lived tracking databases linking agent activity across recipients
        and time periods.

     Mode 2 (SD-JWT Trust Proof) mitigates these risks by eliminating
     persistent agent-specific identifiers from the token; see
     Section 15.3.  Receiving mail servers SHOULD NOT require Mode 1
     attestation when Mode 2 provides sufficient trust signal for the
     receiver's policy needs.







  Drake                    Expires 31 October 2026               [Page 48]


  Internet-Draft         Hardware Email Attestation             April 2026


  14.10.  Header Stripping and Modification

     An intermediary mail server could strip or modify the Hardware-
     Attestation or Hardware-Trust-Proof headers.  This risk is identical
     to the risk of DKIM signature stripping and is mitigated by the same
     mechanisms: ARC [RFC8617] preserves authentication results through
     forwarding chains.

     Stripping these headers cannot cause a legitimate message to appear
     illegitimate (it simply loses the attestation).  Adding forged
     headers is prevented by the cryptographic signatures.

  14.11.  Credential Theft and Identity Substitution

     Because the attestation signature is produced by the sending agent
     rather than by the mail server, theft of SMTP credentials alone does
     not grant the attacker a valid attestation.  The agent identity
     (aid), when present, is cryptographically bound to the signature:
     substituting a different aid value causes signature verification to
     fail at the receiving end.

     An attacker who intercepts a legitimately signed attestation header
     could attempt to replay it on a different message.  The body hash
     (bh), timestamp (ts), and signed header hashes (h-hash) prevent
     replay on altered content.  The MSA identity binding requirements in
     Section 10 provide defence-in-depth: an attestation-aware MSA rejects
     messages where the agent identity does not match the submitting
     account, preventing misuse before the message enters the mail system.

     Together, the cryptographic binding of aid in the signature and the
     MSA submission-time enforcement ensure that an agent cannot claim an
     identity other than its own.

  14.12.  Issuer Trust and Accountability

     The federated issuance model (Section 4.5) means verifiers MUST make
     their own trust decisions about which Issuers to accept.  A malicious
     Issuer could issue multiple identities for the same hardware,
     undermining Sybil resistance.  For Mode 1 (direct attestation) this
     violation is detectable: verifiers that track hardware fingerprints
     will observe the same fingerprint appearing under multiple agent
     identities from the same Issuer.  For Mode 2 (issuer-certified
     attestation) fingerprints are not visible to recipients, so
     malicious-Issuer detection is audit-based, not verifier-based:
     Issuers operating in shared namespaces should participate in
     transparency-log mechanisms so that cheating is detectable through
     audit rather than per-message fingerprint correlation.




  Drake                    Expires 31 October 2026               [Page 49]


  Internet-Draft         Hardware Email Attestation             April 2026


     Verifiers SHOULD maintain an allowlist of trusted Issuers, analogous
     to browser trust stores for TLS CAs.  Reputation services MAY track
     Issuer quality metrics (enrollment anomaly rates, duplicate-
     fingerprint detections, abuse report correlations) to inform verifier
     trust decisions.  Verifiers SHOULD remove Issuers from their
     allowlist when evidence of policy violations is detected.

  14.13.  Cryptographic Agility and Post-Quantum Migration

     This specification's v=1 format uses ECDSA (ES256, ES384) and RSA
     (RS256) signatures, which are vulnerable to future quantum computing
     attacks.  For hardware-backed trust tiers (sovereign, portable,
     enclave, virtual), the available signature algorithms are determined
     by the hardware security component: this specification cannot migrate
     to post-quantum algorithms faster than the TPM, PIV, and enclave
     silicon it builds on.  As hardware manufacturers adopt post-quantum
     algorithms (e.g., ML-DSA, SLH-DSA) in their attestation key
     interfaces, a future v=2 revision will expose those algorithms to
     verifiers.

     The declared trust tier (software-managed keys) is not hardware-
     constrained and MAY adopt post-quantum signature algorithms as soon
     as suitable libraries are available, providing an early migration
     path for deployments that accept the lower Sybil-resistance trade-off
     of the declared tier.

     Deployments SHOULD plan for algorithm migration by treating the v=
     field as a versioning mechanism and ensuring verifiers can support
     multiple concurrent versions during transition periods.

  15.  Privacy Considerations

     This section consolidates the privacy implications of this
     specification, per [RFC6973].  Hardware attestation inherently
     involves persistent identifiers; the privacy properties differ
     significantly between the two modes and between automated and human
     senders.

  15.1.  Applicability to Human vs. Automated Senders

     This specification targets authentication of automated senders -- AI
     agents, bots, and high-volume automated systems.  It is NOT intended
     or recommended for individual human users sending personal or low-
     volume email.  The persistent hardware fingerprint in Mode 1 uniquely
     identifies the sending device across all messages and contexts,
     creating linkability that exceeds current email privacy norms for
     human correspondence.




  Drake                    Expires 31 October 2026               [Page 50]


  Internet-Draft         Hardware Email Attestation             April 2026


     Operators of human-facing email services that offer hardware
     attestation as an opt-in feature MUST provide clear disclosure of the
     linkability implications before activation.  Receivers SHOULD NOT
     penalise the absence of hardware attestation from senders exhibiting
     human-characteristic patterns.

  15.2.  Hardware Fingerprint Linkability

     Mode 1 (Direct Hardware Attestation) exposes a persistent, globally
     unique hardware fingerprint -- the SHA-256 hash of the identity
     certificate's public key -- to every recipient.  This fingerprint is
     stable for the lifetime of the hardware device and is identical
     across all protocols (email, HTTP, agent-to-agent) where the same
     device attests.

     Any party that observes this fingerprint can correlate messages
     across recipients, time periods, and transport protocols.  This
     cross-context linkability is the intended mechanism for reputation
     building in automated sender scenarios, but it also enables
     surveillance if misused.

     The identity certificate additionally reveals the hardware
     manufacturer and device model family.  In most automated deployments
     this information is not sensitive, but it does narrow the set of
     possible senders.

  15.3.  Privacy-Preserving Alternative (Mode 2)

     Mode 2 (SD-JWT Trust Proof) provides Sybil resistance without
     revealing the hardware fingerprint or any persistent agent-specific
     identifier.  Because the Issuer signs the per-message SD-JWT directly
     (rather than the agent signing with a key embedded in the token), no
     agent-controlled key appears in the presentation.  Recipients cannot
     link multiple emails to the same sender based on Mode 2 headers
     alone.

     The sender selects which claims to disclose; the hardware
     fingerprint, agent identity URN, and device details can all be
     withheld.  Only the Issuer identifier (iss) and the message-binding
     nonce are always visible.

     The privacy cost of full unlinkability is that the agent must contact
     the Issuer for each email, so the Issuer learns the agent's sending
     pattern (timing and frequency) though not the message content.
     Issuers MUST NOT log or correlate message-binding hashes beyond what
     is necessary for rate limiting and abuse prevention (see
     Section 15.4).




  Drake                    Expires 31 October 2026               [Page 51]


  Internet-Draft         Hardware Email Attestation             April 2026


     Senders operating in contexts where hardware fingerprint disclosure
     is unacceptable -- including agents that wish to avoid cross-context
     tracking -- SHOULD use Mode 2 exclusively.  Receivers SHOULD NOT
     require Mode 1 when Mode 2 provides sufficient trust signal for their
     policy needs.

  15.4.  Issuer Knowledge

     During enrollment, the Issuer learns the agent's hardware fingerprint
     (identity certificate public key hash) and associates it with the
     assigned agent identity URN.  This is necessary for anti-Sybil
     enforcement.

     In Mode 2, the Issuer additionally learns that the agent is sending a
     message each time the agent requests a per-message SD-JWT.  The
     Issuer receives the message-binding hash (a SHA-256 digest from which
     message content cannot be recovered) but does not learn the message
     recipients, subject, or body.  Issuers MUST NOT log message-binding
     hashes or correlate per-message signing requests with external data
     to infer message content or recipients.  Issuers SHOULD implement
     rate limiting at the per-message signing endpoint to prevent abuse,
     but MUST delete signing request metadata (timestamps, source IPs,
     message-binding hashes) within 24 hours.

     The specification deliberately separates enrollment (Issuer) from
     behaviour tracking (reputation services) to limit the Issuer's
     knowledge of agent activity.

  15.5.  Data Minimisation

     Verifiers that record hardware fingerprints or agent identity URNs
     for reputation purposes SHOULD apply data minimisation principles:
     retain only the truncated fingerprint (as specified in Section 5.4)
     rather than the full identity certificate, and SHOULD define
     retention policies that limit how long fingerprint-to-message
     associations are stored.

  15.6.  Abuse-Resistant Contact Tokens

     Automated agents typically send from generated addresses (e.g., aid-
     based mailbox names) that do not route to a human operator.  When a
     recipient needs to report abuse or request removal, there is no
     obvious contact path.  Conversely, exposing the operator's real email
     address in every outbound message creates a spam and social-
     engineering target.






  Drake                    Expires 31 October 2026               [Page 52]


  Internet-Draft         Hardware Email Attestation             April 2026


     Implementations MAY include a short-lived, opaque contact token in
     outbound messages to bridge this gap.  A contact token is a value
     that the Issuer can resolve to the operator's real contact address
     without revealing that address to the message recipient.  The token
     SHOULD be rotated periodically (e.g., monthly) so that tokens from
     old messages cannot be used to build a long-term contact profile of
     the operator.

     One approach is to carry the token in a header field alongside the
     attestation headers.  An Issuer might define a contact-token header
     containing an HMAC-based opaque token; a recipient sends mail to
     <token>@contact.<issuer-domain> and the Issuer forwards it to the
     registered operator.  The token is derived from the agent identity
     and a time-based rotation key, so it is not linkable across rotation
     periods and cannot be forged without the Issuer's secret.

     This specification does not mandate a particular contact token format
     or delivery mechanism.  Issuers that provide contact tokens SHOULD
     document their token lifetime and resolution procedure.  Recipients
     SHOULD treat contact tokens as opaque values and SHOULD NOT attempt
     to derive agent identity from them.

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

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

     [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
                RFC 5652, DOI 10.17487/RFC5652, September 2009,
                <https://www.rfc-editor.org/info/rfc5652>.

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

     [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
                (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
                <https://www.rfc-editor.org/info/rfc8141>.






  Drake                    Expires 31 October 2026               [Page 53]


  Internet-Draft         Hardware Email Attestation             April 2026


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

     [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
                Message Authentication Status", RFC 8601,
                DOI 10.17487/RFC8601, May 2019,
                <https://www.rfc-editor.org/info/rfc8601>.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                DOI 10.17487/RFC5322, October 2008,
                <https://www.rfc-editor.org/info/rfc5322>.

     [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
                Disclosure for JSON Web Tokens", RFC 9901,
                DOI 10.17487/RFC9901, November 2025,
                <https://www.rfc-editor.org/info/rfc9901>.

  17.  Informative References

     [I-D.drake-agent-identity-registry]
                Drake, C., "Agent Identity Registry System", Work in
                Progress, Internet-Draft, draft-drake-agent-identity-
                registry-02, April 2026, <https://1id.com/rfc/draft-drake-
                agent-identity-registry-02>.

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

     [RFC3156]  Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
                "MIME Security with OpenPGP", RFC 3156,
                DOI 10.17487/RFC3156, August 2001,
                <https://www.rfc-editor.org/info/rfc3156>.

     [RFC5891]  Klensin, J., "Internationalized Domain Names in
                Applications (IDNA): Protocol", RFC 5891,
                DOI 10.17487/RFC5891, August 2010,
                <https://www.rfc-editor.org/info/rfc5891>.

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







  Drake                    Expires 31 October 2026               [Page 54]


  Internet-Draft         Hardware Email Attestation             April 2026


     [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
                Message Authentication, Reporting, and Conformance
                (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
                <https://www.rfc-editor.org/info/rfc7489>.

     [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
                Authentication of Named Entities (DANE) Protocol: Updates
                and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
                October 2015, <https://www.rfc-editor.org/info/rfc7671>.

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

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

     [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
                Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
                Message Specification", RFC 8551, DOI 10.17487/RFC8551,
                April 2019, <https://www.rfc-editor.org/info/rfc8551>.

     [RFC8617]  Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
                Kucherawy, Ed., "The Authenticated Received Chain (ARC)
                Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
                <https://www.rfc-editor.org/info/rfc8617>.

     [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
                Morris, J., Hansen, M., and R. Smith, "Privacy
                Considerations for Internet Protocols", RFC 6973,
                DOI 10.17487/RFC6973, July 2013,
                <https://www.rfc-editor.org/info/rfc6973>.

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

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







  Drake                    Expires 31 October 2026               [Page 55]


  Internet-Draft         Hardware Email Attestation             April 2026


     [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
                DOI 10.17487/RFC9711, April 2025,
                <https://www.rfc-editor.org/info/rfc9711>.

     [RFC9783]  Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
                Fossati, "Arm's Platform Security Architecture (PSA)
                Attestation Token", RFC 9783, DOI 10.17487/RFC9783, June
                2025, <https://www.rfc-editor.org/info/rfc9783>.

     [TCG-TPM2] Trusted Computing Group, "TPM 2.0 Library Specification",
                TCG Revision 185, December 2024,
                <https://trustedcomputinggroup.org/resource/tpm-library-
                specification/>.

     [TCG-EK-PROFILE]
                Trusted Computing Group, "TCG EK Credential Profile for
                TPM Family 2.0", TCG Version 2.6, December 2024,
                <https://trustedcomputinggroup.org/resource/tcg-ek-
                credential-profile-for-tpm-family-2-0/>.

  Appendix A.  Appendix: Economics of Hardware-Based Sybil Resistance

     The following table compares the cost of creating N fake sender
     identities under various authentication regimes:

      +================+===================+============+===============+
      | Authentication | Cost per Identity | Cost of 1M | Reusable      |
      |                |                   | Identities | After Flag?   |
      +================+===================+============+===============+
      | Email-only     | ~$0               | ~$0        | Yes (new      |
      |                |                   |            | address)      |
      +----------------+-------------------+------------+---------------+
      | Phone-verified | ~$0.01-0.10       | $10K-100K  | Yes (new SIM) |
      +----------------+-------------------+------------+---------------+
      | Domain + DKIM  | ~$1-10            | $1M-10M    | Yes (new      |
      |                |                   |            | domain)       |
      +----------------+-------------------+------------+---------------+
      | Hardware       | ~$20-2000         | $20M-2B    | No (device is |
      | Attestation    |                   |            | permanent)    |
      +----------------+-------------------+------------+---------------+

                                    Table 5








  Drake                    Expires 31 October 2026               [Page 56]


  Internet-Draft         Hardware Email Attestation             April 2026


     The critical difference is the "Reusable After Flag?" column.  With
     every existing mechanism, a flagged identity can be cheaply replaced.
     With hardware attestation, a flagged hardware identity is permanently
     associated with that physical device.  The attacker must procure
     entirely new hardware.

  Appendix B.  Appendix: Hardware Manufacturer Root CAs

     The following hardware manufacturers publish root CA certificates
     that can be used to validate identity certificate chains:

     Intel  Provides EK CA certificates via a REST API for firmware TPM
        (Platform Trust Technology / PTT) and discrete TPM devices.  See
        https://trustedservices.intel.com/.

     AMD  AMD fTPM EK certificates are available via
        https://ftpm.amd.com/pki/aia/.  AMD Secure Encrypted
        Virtualisation (SEV) attestation keys use a separate distribution
        at https://download.amd.com/sev/.

     Infineon  Infineon OPTIGA TPM certificates.  Root CA available via
        Infineon's PKI.  See https://www.infineon.com/TPM.

     STMicroelectronics  Root certificates available through ST's TPM
        documentation portal.

     Nuvoton  Root certificates available through Nuvoton's security
        products documentation.

     Yubico  PIV attestation CA certificates for YubiKey devices.  See
        https://developers.yubico.com/PIV/Introduction/piv-
        attestation.html.

     Receiving mail servers implementing this specification SHOULD
     maintain a local trust store of hardware manufacturer root CAs,
     updated periodically.  A community-maintained trust store (analogous
     to Mozilla's CA certificate programme for TLS) would benefit the
     ecosystem.  An open-source trust store project is available at
     https://github.com/1id-com/tpm-manufacturer-cas.

  Appendix C.  Appendix: Live Email Examples

     This appendix contains six complete email messages generated by
     independent implementations of this specification.  Each message was
     sent from alice@example.un.ag to bob@example.un.ag using the 1id.com
     Issuer and verified by the MailPal.com milter on receipt.  The
     messages are reproduced verbatim from the receiving mail server's
     store; all base64-encoded values, signatures, and certificate chains



  Drake                    Expires 31 October 2026               [Page 57]


  Internet-Draft         Hardware Email Attestation             April 2026


     are the original bytes as transmitted on 26 March 2026.

     These are genuine, cryptographically verifiable messages.  Readers
     can independently verify every example using the open-source hw-
     attest-verify tool (https://github.com/1id-com/hw-attest-verify),
     installable via "pip install hw-attest-verify".  For each email file,
     run:

     $ python3 -m hw_attest_verify --auth-results --no-time-check \
         --hostname mailpal.com < example.eml

     The --no-time-check flag disables token expiry enforcement, since SD-
     JWT tokens have a five-minute lifetime and will have expired by the
     time of reading.  Mode 1 (Hardware-Attestation) verification has no
     time dependency and passes without this flag.  The examples
     collectively demonstrate:

     *  All five trust tiers (sovereign, portable, enclave, virtual,
        declared).

     *  Both SDK implementations (Python oneid-sdk and Node.js 1id).

     *  Mode 1 only, Mode 2 only, and Combined Mode (Mode 1 + Mode 2).

     *  Dynamic trust tiering (same identity at different tiers on
        different devices).

     *  Embedded Authentication-Results headers injected by the
        MailPal.com verifier milter during SMTP reception.

     Note on certificate chains: The Mode 1 (Hardware-Attestation)
     examples contain CMS certificate chains rooted at the 1id.com
     Issuer's own CA ("1ID Root CA A" / "1ID Intermediate CA A"), not at
     hardware manufacturer root CAs (Intel, AMD, etc.).  This is because
     the 1id.com Issuer verifies the TPM or enclave manufacturer
     certificate chain during enrollment and then issues its own Issuer-
     certified AK certificate that binds the AK public key to the verified
     hardware identity.  The resulting CMS chain is: AK Certificate
     (Issuer-signed) -> Issuer Intermediate CA -> Issuer Root CA.
     Deployments that do not use an Issuer would instead include the full
     manufacturer certificate chain as described in Section 5.1.  Both
     chain formats are valid; the Issuer-certified format provides the
     additional assurance that the Issuer has verified the hardware
     binding as part of its enrollment protocol.

     NOTE TO RFC EDITOR: Please retain the examples in this appendix but
     remove this note, the specific dates, and the reference to "26 March
     2026".  The examples are included as a non-normative aid to



  Drake                    Expires 31 October 2026               [Page 58]


  Internet-Draft         Hardware Email Attestation             April 2026


     implementers and reviewers, providing complete, independently
     verifiable email messages demonstrating all attestation modes and
     trust tiers.

  C.1.  Example 1: Sovereign-Tier TPM (Combined Mode, Node.js SDK)

     This message demonstrates Combined Mode (Mode 1 + Mode 2) from a
     sovereign-tier identity backed by an Intel firmware TPM.  The
     Hardware-Attestation header contains a CMS SignedData bundle with an
     X.509 certificate chain rooted at a manufacturer CA.  The Hardware-
     Trust-Proof header contains an SD-JWT with a selectively disclosed
     trust_tier claim.  Both headers reference the same agent identity URN
     (urn:aid:com.1id:1id-tkoie2ve).  Note that the From address
     (alice@example.un.ag) is independent of the agent identity URN,
     demonstrating the decoupling of email sender identity and hardware
     identity.

     Compare with Example 2 (same identity, different device and trust
     tier) and Example 6 (same identity and device, Mode 1 only, Python
     SDK).

  Received: from oneid-sdk (unknown [2001:8000:1bed:6d00:ecfa:f9e5:c8e3:ed
          4f] (AS1221 Telstra Limited, AU))(using TLSv1.3 with cipher
          TLS13_AES_256_GCM_SHA384) by mail.mailpal.com (Stalwart SMTP)
          with ESMTPSA id 423AB698D84E8D1; Thu, 26 Mar 2026 06:27:23 +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774506443; x=1775370443; bh=+GNsqybwllZv8Ax0BtgYSg73F/3TnNOd8
          lZ5Dlr7wJM=; b=bibpmNagEyVBbOaFHy6+roU+kMTxheiMcNrQfEhQq4EHMf1zE
          E0zt/EwIohwEkm55Ajra4k834hqnvbxmT0/fzD+f/Uq5SP6dUp2m1KBSMrkYHVTD
          LW0m7TqsCzKoFOJRQrP8HkXTGGlLZs8VOHwN+UFLBOrR0TebCSRZQldAMcUKfx3w
          +/uopSKYF6BKvq1U1NDXDxIyrIiYJ9ma64VjMz/GIu8Aqg9CKg3DtiEIhKa4B+9m
          Q4olARarM4B0n5HPKcib6UU/I8XXRnvynBFKIRc+MlVIXWsQYKbbQTBqMJRVy8fR
          sdXANCTDhzV3UoO+EXUE4yXeba7xCWfdk6SQQ==;
  Authentication-Results: mailpal.com; hw-attest=pass header.typ=TPM
          header.alg=RS256 header.tier=sovereign
          header.aid=urn:aid:com.1id:1id-tkoie2ve
  Authentication-Results: mailpal.com; hw-trust=pass
          header.trust_tier=sovereign header.registry=1id.com
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 1/6: Sovereign TPM (Node.js, Mode 1+2)
  Date: Thu, 26 Mar 2026 16:27:16 +1000
  Message-ID: <1774506436645.8ed455cf30df4796@mailpal.com>
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0



  Drake                    Expires 31 October 2026               [Page 59]


  Internet-Draft         Hardware Email Attestation             April 2026


  Hardware-Attestation: v=1; typ=TPM; alg=RS256; h=from:to:subject:date:me
          ssage-id:content-transfer-encoding:content-type:mime-version:fro
          m:to:subject:date:message-id:content-transfer-encoding:content-t
          ype:mime-version; bh=D86x9X_Sdbjuiw4qHtNHgn_D9ddyl18jiIMSUqhmnDY
          ; ts=1774506440; chain=MIIMAQYJKoZIhvcNAQcCoIIL8jCCC+4CAQExDzANB
          glghkgBZQMEAgEFADALBgkqhkiG9w0BBwGgggpWMIID4TCCAsmgAwIBAgIUH01pf
          nWQCIfMiHfTNQb7v7r3CmMwDQYJKoZIhvcNAQELBQAwLjEMMAoGA1UECgwDMUlEM
          R4wHAYDVQQDDBUxSUQgSW50ZXJtZWRpYXRlIENBIEEwHhcNMjYwMzIwMTYzNjI2W
          hcNMjcwMzIwMTYzNjI2WjBMMQwwCgYDVQQKDAMxSUQxJTAjBgNVBAMMHHVybjpha
          WQ6Y29tLjFpZDoxaWQtdGtvaWUydmUxFTATBgNVBAUTDDFpZC10a29pZTJ2ZTCCA
          SIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANvysXC8ILSnhGcqg66dWKWQL
          p9pOJZmj6yTbICDVLydBwc1LGEQAW3BCee6XU/Bs0n91uROJCQw3jgrCMiBUOvS6
          Mjox/8NT1gfZ9sDQGVXN5gQ0t9H+r9vEPJ7YL9jhYmlxWQp+fS6vhZNrmH7g4XwE
          K+EsbMsc8H0ZuxKAM1S7p9447G9IOZOkFMK33ZxCCY00DFmwzXu/dkGFfuOaSWM5
          cazWz/kxqOtcpT73ACmJxQ6LU3yzB6VwbfwCWm6klQNKsd1c7FT5hX5ZYtEqDXeI
          pIGWyQp9TQgNbUIPeJCWO2rDLmh0ZXwqXR4yBqKeNWhUjrcnfQgNfrjJ7zB0z8CA
          wEAAaOB2DCB1TAnBgNVHREEIDAehhx1cm46YWlkOmNvbS4xaWQ6MWlkLXRrb2llM
          nZlMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBRroL9zk
          1MDMjMG4UyIvjZdzdX8QTAfBgNVHSMEGDAWgBRnIsB54FVyNiezRKLzTN+AXd+Wr
          jAXBgorBgEEAYPUXwEBBAlzb3ZlcmVpZ24wIgYKKwYBBAGD1F8BAgQUMjAyNi0wM
          y0wNFQwMDowMDowMFowDwYKKwYBBAGD1F8BAwQBADANBgkqhkiG9w0BAQsFAAOCA
          QEAiL2Fwbib2C2bzYzRpDsyFGSXmn2LcFO3snxAaoRJxwMqa5UcyNZNaPk9SHtr7
          mocHO8spAi5q+7Twa8+1djZ3HJha5iKW59E9o2/JFBBM8p1ehkHVmlTtF130RFja
          aW1BnPvdfjSMCdYHk9IIOw90+oAA7omUAlYTXclGLduE2fOfVcAaqIz+wFYS89iJ
          Otlbj+BH8wwa6Ee3P1pEe1p4LW4KGdaIrA1/yfarCaglkVlJxA4GsR2y1H43l7ZN
          ijh/lsS+iRJWXvBWGqecVx+GY/jPpvG4ahObRO4/MW5F1i3fKvkE0UX4juC5t0nP
          tCbRsQFRmbIcQv+OcLJV9MexzCCA0gwggIwoAMCAQICFEhBGCtvI+p+lYa/sOD7w
          5IrskGxMA0GCSqGSIb3DQEBCwUAMCYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAwwNM
          UlEIFJvb3QgQ0EgQTAeFw0yNjAzMTQxNDEzNDdaFw0zMTAzMTMxNDEzNDdaMC4xD
          DAKBgNVBAoMAzFJRDEeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMIIBI
          jANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAueeMbFQ0VCd3zBECEit2soc9g
          0xaRwzL4QT+jB6k7f9dehwyTY/tqlyXQJlR/BnV8zMJv7bfZ6xq8eEnd73HaHcKV
          Jxdg4VQEmfHtk4mGAfWuAy7j3N5TsPpcFTqgkJlAwUp3kH3yDVPvO1qHzbVmUFdv
          DscthxQ3xYVP1pCPdWsoiP4oR0L0EyaaqmTwG2J/hIw/vAGqwWx4CrMsg8VvKDps
          LPNp2IZ/HkXc+ztw3tsPXKWaLiTMli8RvZ8FEjsQ933Nfr23DHqEZgS0QA8fUZoa
          xzogdhxVue/W7KnZM8ENdP0jOf0l5oUncGo8VP5p5BmQhP73J3bVMyeQf7cIwIDA
          QABo2YwZDASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVH
          Q4EFgQUZyLAeeBVcjYns0Si80zfgF3flq4wHwYDVR0jBBgwFoAUw7fpWXXFX/lGD
          y85m5SqTPkl8PAwDQYJKoZIhvcNAQELBQADggEBAIVAxZlTfr2eEitQkDzx/Vxs5
          CftPYgIVJAt5SzSvoVjKQWfkth7PClZeGjGmZg9vozqwuFo+Tnvq1bCe8loiZn0P
          XwsjEeNxgKAnAGcg7KvacsnyH120DuvnT1NE33y/vR4GNqpnvFzf77DqlmN4BL8Y
          oa1vYp1XNehHg79YkS3FlGXuaN7ku7WU3Uuv25Em9ZbvNbfZyvGGeto8TWNkgfWn
          F/asfTFjYwUrF+8k4xxAFZ/0OjjM3Y0v0mpdf0XAE8a846PG59tn3qnopCQmqKuJ
          Tiv5CgWX8/RdARjVR/eQIwoaduW5YhmEFzMz24kLlJ5us6jHSGCYPzbT84OpLowg
          gMhMIICCaADAgECAhRnIjFxQzVLiE7JnREz6PpYT9J0DzANBgkqhkiG9w0BAQsFA
          DAmMQwwCgYDVQQKDAMxSUQxFjAUBgNVBAMMDTFJRCBSb290IENBIEEwIBcNMjYwM
          zE0MTQxMzQ3WhgPMjA1NjAzMDYxNDEzNDdaMCYxDDAKBgNVBAoMAzFJRDEWMBQGA
          1UEAwwNMUlEIFJvb3QgQ0EgQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCg



  Drake                    Expires 31 October 2026               [Page 60]


  Internet-Draft         Hardware Email Attestation             April 2026


          gEBAOAkpJayeSScKqR0JEmx+i6EGae5F6roRJsqGQRA/fwZMsw7JXeKNyMhXcb2n
          6w7uHuWA8xiMYx4Arwr8FIGxGben3pjqkjPdVTyjLgczBKtK7Rws+yf70v57H8N/
          zaoBTfo/qtR8hx1cfi91vMED1q1S6iNkVBT8lPaHmS+lymmi9DzSMC9jcQCjLnOb
          kPwVDzYw7IeyODOYA+l/Vkf+GRJ71HdLJYpfHyTy0Y8OqJtnqv5BZeaV1u5oqXX9
          rn4mBCHNZRAbX9+JKwljNzxL55dEbOHhIqw4q8cezxT9fBjoKDcmkPDTWWUjqgui
          zK1naFzur/DCkFXAnCJ0bE33T0CAwEAAaNFMEMwEgYDVR0TAQH/BAgwBgEB/wIBA
          TAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMO36Vl1xV/5Rg8vOZuUqkz5JfDwM
          A0GCSqGSIb3DQEBCwUAA4IBAQAIUV87JRvdpKGik3xkdij2bzj97MWbxwXpn8G+L
          SAsGnoGZTbR87aj+6nC6ln7BxtAmqG/Htq24zI6T2jGPNd9vJIJe4KFT0xLqtwH+
          Y6GTgKx34s4EJfa+UcE/Rt8vwIA052QxerlCreT9bvD1HfLenVADbyIzL6g+nlfB
          EYqDLvgS+xqWw78u7Jr5rAqctYrGNGkpYdddixm6Cbnhkm4jMd+cDCq+qH18tBBP
          iM9icT19fqz88WfWCOYmHFBFabQWVtCJPN7C1yXVRume+OWsJzgEJ5K4kcLdm9K/
          yUW5ru00K8wL/ytD0107mH9w2MagpdOMPHKYBGj3ea1huMmMYIBbzCCAWsCAQEwR
          jAuMQwwCgYDVQQKDAMxSUQxHjAcBgNVBAMMFTFJRCBJbnRlcm1lZGlhdGUgQ0EgQ
          QIUH01pfnWQCIfMiHfTNQb7v7r3CmMwDQYJYIZIAWUDBAIBBQAwCwYJKoZIhvcNA
          QELBIIBAJrTV5BnJJ916qGGE8nTmYGPub7Kwd3z4KwHNCtQVC8eWxQkmeJ6ffF2f
          5RWBRwN08t1WQ60DtN7NxiSRfJWT1NSK8JRe+8f6hcOIYKgUeBoIhM1oliwTJcGD
          unymYzohvsMUct1mi0qFQScxGoQUGjGy2nXeIXman13l47mQ/1aNqcxXbtsoLRDk
          sEOg6M0agiRGh7SW68nlyr91BfQKY55ulrbGHmFpEDma+wHn1IZ0kHh+oVGM5M2B
          xU+E8+mEuLKYAp75Jgxd9zEWBtx3F870Q4CF/BhKL/6rRa+SaZJIWa9nkk41mNL2
          33OqpMiDIFfeI0pgKVYzvoVmWi+Tyc=; aid=urn:aid:com.1id:1id-tkoie2v
          e
  Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lcz
          I1Ni0xIiwidHlwIjoic2Qrand0In0.eyJpc3MiOiJodHRwczovLzFpZC5jb20iLC
          JpYXQiOjE3NzQ1MDY0MzksImV4cCI6MTc3NDUwNjczOSwibm9uY2UiOiJVRnh4bF
          hwUTR6dGg3ejlZSlRkWFRONTlKbWw0RFVheXVockdiUFotWHhNIiwiX3NkX2FsZy
          I6InNoYS0yNTYiLCJfc2QiOlsidGdCX3B5RFpuLVQtRGFlQlpONXFyNk5PTldZZG
          00Y3hOWUx1ZDBPT0ZDUSJdfQ.1Ojz34CEn-8nzpGGQf0R321yM1OMsguAkvc3lyq
          GagSWltkPKC6xb_MfETNilB-WQeHGffZQknrhwy-9mamFAA~WyJqN1AtQUFvc0RY
          dHpld0hvOTlGcE9RIiwidHJ1c3RfdGllciIsInNvdmVyZWlnbiJd~

  RFC example 1 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  sovereign (hardware TPM, typ=TPM)
    Identity:    urn:aid:com.1id:1id-tkoie2ve
    Device:      Intel firmware TPM (PTT)
    SDK:         Node.js (1id npm package) v1.3.1
    Mode:        Combined (Mode 1 + Mode 2)
    Headers:     Hardware-Attestation (Mode 1)
                 Hardware-Trust-Proof (Mode 2)

  What to look for:
    - Hardware-Attestation: CMS SignedData bundle
      with X.509 chain rooted at manufacturer CA.
    - Hardware-Trust-Proof: SD-JWT with selectively
      disclosed trust_tier claim.
    - Both headers share the same aid URN.



  Drake                    Expires 31 October 2026               [Page 61]


  Internet-Draft         Hardware Email Attestation             April 2026


    - From (alice@example.un.ag) differs from the
      aid URN -- sender and hardware identity are
      decoupled by design.
    - Compare with example 6 (same identity/device,
      Mode 1 only, Python SDK).

     Figure 1: Example 1: Sovereign TPM, Combined Mode (Node.js SDK)

  C.2.  Example 2: Portable-Tier PIV/YubiKey (Mode 2 Only, Python SDK)

     This message uses the same agent identity as Example 1
     (urn:aid:com.1id:1id-tkoie2ve) but was authenticated via a Yubico
     YubiKey 5 (PIV slot 9a) on a different physical machine.  The
     trust_tier in the Authentication-Results is "portable" (not
     "sovereign"), demonstrating dynamic trust tiering: the tier reflects
     the device used for the current authentication, not the highest tier
     the identity is capable of.  Only Mode 2 (Hardware-Trust-Proof) is
     present because PIV-based CMS signing is not yet implemented in the
     reference SDK.

  Received: from moonmac.home (unknown [2001:8000:1bed:6d00:d1b:716c:55b1:
          1044] (AS1221 Telstra Limited, AU))(using TLSv1.2 with cipher
          TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) by mail.mailpal.com
          (Stalwart SMTP) with ESMTPSA id 423B3B18EE530D1; Thu, 26 Mar
          2026 07:39:45 +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774510785; x=1775374785; bh=JzFuOSIpa6v/f7VY5FQ2+pcMkBmkx7MBh
          bMjnGbhwmI=; b=zUgy4VRUk2VvQm2ZbXx+cgMJrjKQ8w8p0JfwrzFFrQZOzZviP
          kT3TTv2gVTYRedADt3Oz/3pBUhcU4/hm1SsNO1gEPeedp1zll8UFDkM4gmBfEyCd
          syvbv/TFVd4tp6aFcnsrY+/vR1yQ6Qnpbl96YLSiXqLtcR5BKf4egRmn+kjcMaiS
          YVhXAvfIgLqauecNPiuQVMNW+bTs/sYp5fVOP122gw4AdgBlsL335xnzU+WV7xkl
          ANTNPXYX7jbQ0Eb1g4ml/2cWzi7Hvp/AnuA1fzi7FCXlBHTnKuFBxCKfrvjUVkad
          4mK/+RPprb4/9LCO8UI4cFMdVi+bDQQCaZnyQ==;
  Authentication-Results: mailpal.com; hw-trust=pass
          header.trust_tier=portable header.registry=1id.com
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 2/6: Portable PIV (Python, Mode 2)
  Date: Thu, 26 Mar 2026 17:39:37 +1000
  Message-ID: <177451077748.22538.12383034578129922803@mailpal.com>
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0
  Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lcz
          I1Ni0xIiwidHlwIjoic2Qrand0In0.eyJpc3MiOiJodHRwczovLzFpZC5jb20iLC
          JpYXQiOjE3NzQ1MTA3ODAsImV4cCI6MTc3NDUxMTA4MCwibm9uY2UiOiJxTUlQQk



  Drake                    Expires 31 October 2026               [Page 62]


  Internet-Draft         Hardware Email Attestation             April 2026


          FrOWFYU2ljTmZpTnRlVlpzcHVoRV9HX1U5a3FXRndPWDBnTFFJIiwiX3NkX2FsZy
          I6InNoYS0yNTYiLCJfc2QiOlsiang2ZnNmemtWTXYzVDZENmk1ZTYyd0xuN09xan
          M5NkF0V0IwR0tPcXlmRSJdfQ.F3s1ojJtpOeDNTWNLVriHdEOoUlb9HTl-hBCpp6
          pDms6GPRUjxcUXlibBXrjuSsfaEyEWA17d-rToZzz-ECcCg~WyJ2U2RVMzQ0SFNU
          R1AtT0Vwb0VpdE53IiwidHJ1c3RfdGllciIsInBvcnRhYmxlIl0~

  RFC example 2 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  portable (PIV/YubiKey, typ=PIV)
    Identity:    urn:aid:com.1id:1id-tkoie2ve
    Device:      YubiKey 5 NFC (PIV slot 9a)
    SDK:         Python (oneid-sdk) v1.3.3
    Mode:        Mode 2 only (SD-JWT trust proof)
    Header:      Hardware-Trust-Proof only

  What to look for:
    - Same identity (aid) as examples 1 and 6,
      but a different trust_tier (portable).
    - This identity is deliberately shared across
      two machines (RoG via TPM, moonmac via PIV).
      A multi-server bulk-mail operation may want
      a single identity across all its servers so
      that they accrue a common reputation.
    - Dynamic trust tiering: the tier reflects
      the device used now, not the highest tier
      the identity has ever used.
    - Only Hardware-Trust-Proof is present;
      Mode 1 direct attestation is not yet
      supported for PIV-based signing.
    - The From address (alice@example.un.ag)
      differs from the aid URN.

      Figure 2: Example 2: Portable PIV/YubiKey, Mode 2 (Python SDK)

  C.3.  Example 3: Enclave-Tier Secure Enclave (Combined Mode, Python SDK)

     This message demonstrates Combined Mode (Mode 1 + Mode 2) from an
     enclave-tier identity (urn:aid:com.1id:1id-xiz43mxz) backed by the
     Apple Secure Enclave on a Mac mini (M2).  The Hardware-Attestation
     header contains a CMS SignedData bundle with an ECDSA P-256 key held
     in the Secure Enclave.  Note that typ=ENC in the header signals to
     verifiers that the Secure Enclave performs internal hashing (ECDSA
     with SHA-256 over the raw input rather than a pre-hashed digest),
     which affects the verification algorithm for this tier.  The
     Hardware-Trust-Proof SD-JWT discloses trust_tier="enclave".  The
     enclave tier shares a compatibility group with virtual (vTPM), as
     neither provides anti-Sybil guarantees (both device types can be re-



  Drake                    Expires 31 October 2026               [Page 63]


  Internet-Draft         Hardware Email Attestation             April 2026


     keyed at will by the device owner).

     This is a different identity than Examples 1, 2, and 6, because this
     device has its own independent enrollment.

  Received: from mac-mini.local (unknown [2001:8000:1bed:6d00:450f:3a6d:4e
          35:1278] (AS1221 Telstra Limited, AU)) (using TLSv1.3 with
          cipher TLS13_AES_256_GCM_SHA384) by mail.mailpal.com (Stalwart
          SMTP) with ESMTPSA id 423D31DF50596D1;Thu, 26 Mar 2026 12:14:20
          +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774527260; x=1775391260;
          bh=feAv3I/4jG+E7MfQ0QJxgCWsB9rHO4ir7LMH7xA1+2s=;
          b=H1h/DqUDa05dK7egaOvsnoxX5JQsjTL6hzhFSDBFe6SsouUWSOCSHclvNSOJCq
          SNrLh1yOnR/Cu7KfVatydr/wF3vRfAWPZok9ek3ZT0umuMD6C4taM5l57CHQAPlo
          7j6lJ47NAQb+LVCF+H+37Tl8WNWvUUlSOW2xc1ZHxT+6rFx+yWGgdj6oY3zNT6S5
          h1HmQL3Brn0sOCQdM2Scjm7KEZxz8OJr53a9mPj+/Yv/A4JP67qa13dq5JLHDz+d
          FGIQniUo77yAY5jpgg4CrBx1b16OhzT+0hahlPJtVOWovJYS/DL0DLHXRgbcCa6U
          5CTMnmxfp6+DzzJ2sMhzwKhg==;
  Authentication-Results: mailpal.com; hw-attest=pass header.typ=ENC
          header.alg=ES256 header.tier=enclave
          header.aid=urn:aid:com.1id:1id-xiz43mxz
  Authentication-Results: mailpal.com; hw-trust=pass
          header.trust_tier=enclave header.registry=1id.com
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 3/6: Enclave (Python, Mode 1+2)
  Date: Thu, 26 Mar 2026 22:14:10 +1000
  Message-ID: <177452725007.16358.11744115580712301841@mailpal.com>
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0
  Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lcz
          I1Ni0xIiwidHlwIjoic2Qrand0In0.eyJpc3MiOiJodHRwczovLzFpZC5jb20iLC
          JpYXQiOjE3NzQ1MjcyNTUsImV4cCI6MTc3NDUyNzU1NSwibm9uY2UiOiIxRFA3TV
          czYVN0WTdzRzltbDdlUVJJXzh4WU9xNVplWDJZOUw1dWxLQ3BrIiwiX3NkX2FsZy
          I6InNoYS0yNTYiLCJfc2QiOlsiM1J6WWl4bmVjNHFPdGdYSjU1ZTRTS2FtVWtWSG
          RGUGZYUkNLMEx0U2dxdyJdfQ.svOUXSI3K4qpFhkIshqqcJ-EJ3erFZWO4S_jhuX
          GFtrmiNmkx_F9czvoNYIeTPDi7mbXcMDjyOg3niHabToNEg~WyJ3eTRuZ1Yxb1A5
          bWhpQmlZTUdEYUlBIiwidHJ1c3RfdGllciIsImVuY2xhdmUiXQ~
  Hardware-Attestation: v=1; typ=ENC; alg=ES256;
          h=from:to:subject:date:message-id:content-transfer-encoding:cont
          ent-type:mime-version:from:to:subject:date:message-id:content-tr
          ansfer-encoding:content-type:mime-version;
          bh=NoBLb0ghkIoYnL6DZMKhTd4PGygEyah4fcuBEbXYnrw; ts=1774527256;
          chain=MIIKdQYJKoZIhvcNAQcCoIIKZjCCCmICAQExDzANBglghkgBZQMEAgEFAD



  Drake                    Expires 31 October 2026               [Page 64]


  Internet-Draft         Hardware Email Attestation             April 2026


          ALBgkqhkiG9w0BBwGgggmJMIIDFDCCAfygAwIBAgIUYIji1mIf1yIg8m/k5lEK2i
          MpM3cwDQYJKoZIhvcNAQELBQAwLjEMMAoGA1UECgwDMUlEMR4wHAYDVQQDDBUxSU
          QgSW50ZXJtZWRpYXRlIENBIEEwHhcNMjYwMzI2MDUzNDU5WhcNMjcwMzI2MDUzND
          U5WjBMMQwwCgYDVQQKDAMxSUQxJTAjBgNVBAMMHHVybjphaWQ6Y29tLjFpZDoxaW
          QteGl6NDNteHoxFTATBgNVBAUTDDFpZC14aXo0M214ejBZMBMGByqGSM49AgEGCC
          qGSM49AwEHA0IABHwvUSQJfLIavGu2Smbr5KsygOlMZP0I5aR5fAPjyTzrEuDKxs
          QY547Ma1bD0fkBWrnVFCCSZlGE0JYUIQGp0fOjgdYwgdMwJwYDVR0RBCAwHoYcdX
          JuOmFpZDpjb20uMWlkOjFpZC14aXo0M214ejAMBgNVHRMBAf8EAjAAMA4GA1UdDw
          EB/wQEAwIHgDAdBgNVHQ4EFgQUwKjPuDH2bUWHa3MOaJHQUM+p+NMwHwYDVR0jBB
          gwFoAUZyLAeeBVcjYns0Si80zfgF3flq4wFQYKKwYBBAGD1F8BAQQHZW5jbGF2ZT
          AiBgorBgEEAYPUXwECBBQyMDI2LTAzLTI2VDA1OjM0OjU5WjAPBgorBgEEAYPUXw
          EDBAEAMA0GCSqGSIb3DQEBCwUAA4IBAQCui/V804Jj9ZE3IJy7a5i7niFncCdMzQ
          98dMM2nnYTZiq4nW14avCb1liuAGIlvxflodvv4V9h0kHq8C1YC/IIUigtpX5NWb
          KfHOvDyCavQTZNm/YtEgyHH9fy22SOm+bCRjN4yy0xlTpzgT8ct97/qZBiTMB1fD
          LKz5MZAR/LC/bAEFUT+RGipaQKyk+ImZyeq5yCzGGl+KiRbsY0nBn+vNezhmckin
          iB1lx06W+R/WgwMsIX3k6BiJJsMhqelsI2Mx7WTfdRyA7BLxkUlAd8P0CAN4+xyM
          a2BaCJLLgN41BSJ40GdZ3I6aUo6qBNtditaTco8RjJm6Dm9JPl7lj4MIIDSDCCAj
          CgAwIBAgIUSEEYK28j6n6Vhr+w4PvDkiuyQbEwDQYJKoZIhvcNAQELBQAwJjEMMA
          oGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMB4XDTI2MDMxNDE0MT
          M0N1oXDTMxMDMxMzE0MTM0N1owLjEMMAoGA1UECgwDMUlEMR4wHAYDVQQDDBUxSU
          QgSW50ZXJtZWRpYXRlIENBIEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAo
          IBAQC554xsVDRUJ3fMEQISK3ayhz2DTFpHDMvhBP6MHqTt/116HDJNj+2qXJdAmV
          H8GdXzMwm/tt9nrGrx4Sd3vcdodwpUnF2DhVASZ8e2TiYYB9a4DLuPc3lOw+lwVO
          qCQmUDBSneQffINU+87WofNtWZQV28Oxy2HFDfFhU/WkI91ayiI/ihHQvQTJpqqZ
          PAbYn+EjD+8AarBbHgKsyyDxW8oOmws82nYhn8eRdz7O3De2w9cpZouJMyWLxG9n
          wUSOxD3fc1+vbcMeoRmBLRADx9RmhrHOiB2HFW579bsqdkzwQ10/SM5/SXmhSdwa
          jxU/mnkGZCE/vcndtUzJ5B/twjAgMBAAGjZjBkMBIGA1UdEwEB/wQIMAYBAf8CAQ
          AwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRnIsB54FVyNiezRKLzTN+AXd+Wrj
          AfBgNVHSMEGDAWgBTDt+lZdcVf+UYPLzmblKpM+SXw8DANBgkqhkiG9w0BAQsFAA
          OCAQEAhUDFmVN+vZ4SK1CQPPH9XGzkJ+09iAhUkC3lLNK+hWMpBZ+S2Hs8KVl4aM
          aZmD2+jOrC4Wj5Oe+rVsJ7yWiJmfQ9fCyMR43GAoCcAZyDsq9pyyfIfXbQO6+dPU
          0TffL+9HgY2qme8XN/vsOqWY3gEvxihrW9inVc16EeDv1iRLcWUZe5o3uS7tZTdS
          6/bkSb1lu81t9nK8YZ62jxNY2SB9acX9qx9MWNjBSsX7yTjHEAVn/Q6OMzdjS/Sa
          l1/RcATxrzjo8bn22feqeikJCaoq4lOK/kKBZfz9F0BGNVH95AjChp25bliGYQXM
          zPbiQuUnm6zqMdIYJg/NtPzg6kujCCAyEwggIJoAMCAQICFGciMXFDNUuITsmdET
          Po+lhP0nQPMA0GCSqGSIb3DQEBCwUAMCYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAw
          wNMUlEIFJvb3QgQ0EgQTAgFw0yNjAzMTQxNDEzNDdaGA8yMDU2MDMwNjE0MTM0N1
          owJjEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMIIBIjANBg
          kqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4CSklrJ5JJwqpHQkSbH6LoQZp7kXqu
          hEmyoZBED9/BkyzDsld4o3IyFdxvafrDu4e5YDzGIxjHgCvCvwUgbEZt6femOqSM
          91VPKMuBzMEq0rtHCz7J/vS/nsfw3/NqgFN+j+q1HyHHVx+L3W8wQPWrVLqI2RUF
          PyU9oeZL6XKaaL0PNIwL2NxAKMuc5uQ/BUPNjDsh7I4M5gD6X9WR/4ZEnvUd0sli
          l8fJPLRjw6om2eq/kFl5pXW7mipdf2ufiYEIc1lEBtf34krCWM3PEvnl0Rs4eEir
          Dirxx7PFP18GOgoNyaQ8NNZZSOqC6LMrWdoXO6v8MKQVcCcInRsTfdPQIDAQABo0
          UwQzASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFg
          QUw7fpWXXFX/lGDy85m5SqTPkl8PAwDQYJKoZIhvcNAQELBQADggEBAAhRXzslG9
          2koaKTfGR2KPZvOP3sxZvHBemfwb4tICwaegZlNtHztqP7qcLqWfsHG0Caob8e2r
          bjMjpPaMY81328kgl7goVPTEuq3Af5joZOArHfizgQl9r5RwT9G3y/AgDTnZDF6u



  Drake                    Expires 31 October 2026               [Page 65]


  Internet-Draft         Hardware Email Attestation             April 2026


          UKt5P1u8PUd8t6dUANvIjMvqD6eV8ERioMu+BL7GpbDvy7smvmsCpy1isY0aSlh1
          12LGboJueGSbiMx35wMKr6ofXy0EE+Iz2JxPX1+rPzxZ9YI5iYcUEVptBZW0Ik83
          sLXJdVG6Z745awnOAQnkriRwt2b0r/JRbmu7TQrzAv/K0PTXTuYf3DYxqCl04w8c
          pgEaPd5rWG4yYxgbEwga4CAQEwRjAuMQwwCgYDVQQKDAMxSUQxHjAcBgNVBAMMFT
          FJRCBJbnRlcm1lZGlhdGUgQ0EgQQIUYIji1mIf1yIg8m/k5lEK2iMpM3cwDQYJYI
          ZIAWUDBAIBBQAwCgYIKoZIzj0EAwIERjBEAiAZJKFrLr5sP2x4MFEegb/ER4Hk+u
          BbCUUQvYsCzIvbhgIgDHJ40PwTkZ4aVPvg2gBxnh/F5j62qlcvA6OgA1H67MU=;
          aid=urn:aid:com.1id:1id-xiz43mxz

  RFC example 3 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  enclave (Apple Secure Enclave)
    Identity:    urn:aid:com.1id:1id-xiz43mxz
    Device:      Apple Mac mini (M2, SE P256)
    SDK:         Python (oneid-sdk) v1.3.4
    Mode:        Combined (Mode 1 + Mode 2)
    Headers:     Hardware-Attestation (Mode 1)
                 Hardware-Trust-Proof (Mode 2)

  What to look for:
    - trust_tier=enclave in the SD-JWT.
    - The enclave tier shares a compatibility
      group with virtual (vTPM): both provide
      key isolation but lack anti-Sybil
      guarantees (re-keyable at will).
    - Hardware-Attestation carries a CMS
      SignedData bundle with the SE-backed
      ECDSA P-256 key and certificate chain.
    - A different identity than examples 1/6
      (this device has its own enrollment).

        Figure 3: Example 3: Enclave Secure Enclave, Combined Mode
                               (Python SDK)

  C.4.  Example 4: Virtual-Tier vTPM (Combined Mode, Python SDK)

     This message demonstrates Combined Mode from a virtual-tier identity
     backed by a VMware virtual TPM (vTPM).  The Hardware-Attestation
     header uses typ=VRT (not typ=TPM), allowing verifiers to distinguish
     virtual from physical TPMs.  The certificate chain is issuer-signed
     rather than rooted at a hardware manufacturer CA, since no physical
     manufacturer is involved.  Receiving servers MAY apply different
     policy to virtual-tier attestations compared to sovereign or portable
     tiers.






  Drake                    Expires 31 October 2026               [Page 66]


  Internet-Draft         Hardware Email Attestation             April 2026


  Received: from w11vtpm.home (unknown [2001:8000:1bed:6d00:381f:a328:fe9d
          :860e] (AS1221 Telstra Limited, AU))(using TLSv1.3 with cipher
          TLS13_AES_256_GCM_SHA384) by mail.mailpal.com (Stalwart SMTP)
          with ESMTPSA id 423AB909844F0D1; Thu, 26 Mar 2026 06:28:43 +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774506523; x=1775370523;
          bh=t6uFMzcZhV+3fr99tSKnV1CYWnH47FK64RF9EcFXYnQ=; b=sSECW3y5QM+9R
          etAUX4BiZfCHAD7Vg0YjQvnGQym35d0GwpO9UpvH3kUI0s8ckck0Gfx/GDMnBqye
          cF22Ho/TmRtxYhjNXs1Hdspd97Gj9R89T4vbRTP4Se6AoeTCGY5sxEYkO/feYxau
          rVTEvSlyBQTOyPteCQBIvu+LTOnfseQBWaXmQEmgRF0hLhSnPpestgFtxbPvq7W7
          gpxet7GjEIs6nIrdjbeYDbY9izBkLFj6TcUuZbwMiH3KH01wm/qyx0KOoUP7g+5G
          6zsaGuvrmuEgfcX1DMVxAIlHhTJB1nAnHtUStvm4j8t1F9YEUJKD1YCSgLJQ8WvQ
          AJTTs/A0A==;
  Authentication-Results: mailpal.com; hw-attest=pass header.typ=VRT
          header.alg=RS256 header.tier=virtual
          header.aid=urn:aid:com.1id:1id-jq8c84k4
  Authentication-Results: mailpal.com; hw-trust=pass
          header.trust_tier=virtual header.registry=1id.com
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 4/6: Virtual vTPM (Python, Mode 1+2)
  Date: Thu, 26 Mar 2026 17:28:00 +1100
  Message-ID: <177450648054.26936.15036271949777087817@mailpal.com>
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0
  Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lcz
          I1Ni0xIiwidHlwIjoic2Qrand0In0.eyJpc3MiOiJodHRwczovLzFpZC5jb20iLC
          JpYXQiOjE3NzQ1MDY0OTUsImV4cCI6MTc3NDUwNjc5NSwibm9uY2UiOiJxTjVwLT
          VkcEd4ZUtxc3hqcEY3WTMxb2ZIeEN3VU1vaU9YYWV3S09OdjlnIiwiX3NkX2FsZy
          I6InNoYS0yNTYiLCJfc2QiOlsiQ3VPNVBZb0lWMVVrS0RIWmlXOVpNSFJ4Q3hFRG
          Y3UEYtZEU5WXJpVTlKbyJdfQ.rjfzv36TBpjz7fAazYElH06l2n_PpX1gGRUltXO
          NzP-GX5leTEFvUALdxaEHQwq8GmLHM7gpavPS_C_QEF3m2w~WyJmMW1CeWY2LXdI
          NWFkVDFoWmpDRDRBIiwidHJ1c3RfdGllciIsInZpcnR1YWwiXQ~
  Hardware-Attestation: v=1; typ=VRT; alg=RS256; h=from:to:subject:date:me
          ssage-id:content-transfer-encoding:content-type:mime-version:fro
          m:to:subject:date:message-id:content-transfer-encoding:content-t
          ype:mime-version; bh=FB8IXgMtG8UBjtblS5jLcFilBP9NoufFQV8ba9fsRLs
          ; ts=1774506497; chain=MIIL/wYJKoZIhvcNAQcCoIIL8DCCC+wCAQExDzANB
          glghkgBZQMEAgEFADALBgkqhkiG9w0BBwGgggpUMIID3zCCAsegAwIBAgIUCwbxp
          fLn+aYaUdcXrA+ytHDfwU8wDQYJKoZIhvcNAQELBQAwLjEMMAoGA1UECgwDMUlEM
          R4wHAYDVQQDDBUxSUQgSW50ZXJtZWRpYXRlIENBIEEwHhcNMjYwMzI1MTYxOTEyW
          hcNMjcwMzI1MTYxOTEyWjBMMQwwCgYDVQQKDAMxSUQxJTAjBgNVBAMMHHVybjpha
          WQ6Y29tLjFpZDoxaWQtanE4Yzg0azQxFTATBgNVBAUTDDFpZC1qcThjODRrNDCCA
          SIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOa84tc3dh9fVDBWTUA4I+MLo
          IoWxncnfqfRZo25ODrQi8ndZTqTZXrj9mt2kVLgFtUNT7b5XjGHRPz/zHpBm8dNx



  Drake                    Expires 31 October 2026               [Page 67]


  Internet-Draft         Hardware Email Attestation             April 2026


          i/jISGOQ6diWM7xPikXvid/1hzCBmIOkrTSAajVkrz3UJb6U43CdVARX9NQh48Gd
          jrc5dtk3zyvtmvaxfIagCenQArwS4Iv6N+8U+5OvURc713L2P2pd81u4u6lZgEep
          bK0dUdLoYxq8fEAT/Ru4sHZtJFymQTMNVCcWRqVpZPRpezNktM6FfS2tcNzgGEhB
          388Os7EIntDlesDePdv4EVzXDOoL43Xz2TSFA8MCWqhIsu1Kpxbmed7KBbJcC0CA
          wEAAaOB1jCB0zAnBgNVHREEIDAehhx1cm46YWlkOmNvbS4xaWQ6MWlkLWpxOGM4N
          Gs0MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBSdMIQyG
          s98xq+qCV9L05jyTS6hWjAfBgNVHSMEGDAWgBRnIsB54FVyNiezRKLzTN+AXd+Wr
          jAVBgorBgEEAYPUXwEBBAd2aXJ0dWFsMCIGCisGAQQBg9RfAQIEFDIwMjYtMDMtM
          jBUMTQ6NDk6MTVaMA8GCisGAQQBg9RfAQMEAQAwDQYJKoZIhvcNAQELBQADggEBA
          BfRe2qtKDxp4O+mlH+sgot0MX+UxDIVJCTQyB9i/Ew9lTYERt9ZDDpxG5ZJAvuf7
          6FOoOtjQ69/BdSu9f3JEsbILzpLX8MHITT+rREAoUelnUMsLJz7OFieXhk6jMelW
          YdbPpyrArufEr3/yLZa+f50AYM+5e6JUBO0KYWlL0zEP9WMGFtxhO+ZtxBD8NUat
          NbAOL3gRAi3nz8OVnySzBNhunZPa89NRSHvHshF/63hroRVGnHvq/x1ANJFU9L0V
          pj+URuWetRYd4k8c79KicDCGnH4m6Q4i1coumbeaT9fYLMpEjczAgtejCnPjuQoB
          91rgREUxD+4O4OhvYpJ79YwggNIMIICMKADAgECAhRIQRgrbyPqfpWGv7Dg+8OSK
          7JBsTANBgkqhkiG9w0BAQsFADAmMQwwCgYDVQQKDAMxSUQxFjAUBgNVBAMMDTFJR
          CBSb290IENBIEEwHhcNMjYwMzE0MTQxMzQ3WhcNMzEwMzEzMTQxMzQ3WjAuMQwwC
          gYDVQQKDAMxSUQxHjAcBgNVBAMMFTFJRCBJbnRlcm1lZGlhdGUgQ0EgQTCCASIwD
          QYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALnnjGxUNFQnd8wRAhIrdrKHPYNMW
          kcMy+EE/owepO3/XXocMk2P7apcl0CZUfwZ1fMzCb+232esavHhJ3e9x2h3ClScX
          YOFUBJnx7ZOJhgH1rgMu49zeU7D6XBU6oJCZQMFKd5B98g1T7ztah821ZlBXbw7H
          LYcUN8WFT9aQj3VrKIj+KEdC9BMmmqpk8Btif4SMP7wBqsFseAqzLIPFbyg6bCzz
          adiGfx5F3Ps7cN7bD1ylmi4kzJYvEb2fBRI7EPd9zX69twx6hGYEtEAPH1GaGsc6
          IHYcVbnv1uyp2TPBDXT9Izn9JeaFJ3BqPFT+aeQZkIT+9yd21TMnkH+3CMCAwEAA
          aNmMGQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OB
          BYEFGciwHngVXI2J7NEovNM34Bd35auMB8GA1UdIwQYMBaAFMO36Vl1xV/5Rg8vO
          ZuUqkz5JfDwMA0GCSqGSIb3DQEBCwUAA4IBAQCFQMWZU369nhIrUJA88f1cbOQn7
          T2ICFSQLeUs0r6FYykFn5LYezwpWXhoxpmYPb6M6sLhaPk576tWwnvJaImZ9D18L
          IxHjcYCgJwBnIOyr2nLJ8h9dtA7r509TRN98v70eBjaqZ7xc3++w6pZjeAS/GKGt
          b2KdVzXoR4O/WJEtxZRl7mje5Lu1lN1Lr9uRJvWW7zW32crxhnraPE1jZIH1pxf2
          rH0xY2MFKxfvJOMcQBWf9Do4zN2NL9JqXX9FwBPGvOOjxufbZ96p6KQkJqiriU4r
          +QoFl/P0XQEY1Uf3kCMKGnbluWIZhBczM9uJC5SebrOox0hgmD820/ODqS6MIIDI
          TCCAgmgAwIBAgIUZyIxcUM1S4hOyZ0RM+j6WE/SdA8wDQYJKoZIhvcNAQELBQAwJ
          jEMMAoGA1UECgwDMUlEMRYwFAYDVQQDDA0xSUQgUm9vdCBDQSBBMCAXDTI2MDMxN
          DE0MTM0N1oYDzIwNTYwMzA2MTQxMzQ3WjAmMQwwCgYDVQQKDAMxSUQxFjAUBgNVB
          AMMDTFJRCBSb290IENBIEEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBA
          QDgJKSWsnkknCqkdCRJsfouhBmnuReq6ESbKhkEQP38GTLMOyV3ijcjIV3G9p+sO
          7h7lgPMYjGMeAK8K/BSBsRm3p96Y6pIz3VU8oy4HMwSrSu0cLPsn+9L+ex/Df82q
          AU36P6rUfIcdXH4vdbzBA9atUuojZFQU/JT2h5kvpcppovQ80jAvY3EAoy5zm5D8
          FQ82MOyHsjgzmAPpf1ZH/hkSe9R3SyWKXx8k8tGPDqibZ6r+QWXmldbuaKl1/a5+
          JgQhzWUQG1/fiSsJYzc8S+eXRGzh4SKsOKvHHs8U/XwY6Cg3JpDw01llI6oLosyt
          Z2hc7q/wwpBVwJwidGxN909AgMBAAGjRTBDMBIGA1UdEwEB/wQIMAYBAf8CAQEwD
          gYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTDt+lZdcVf+UYPLzmblKpM+SXw8DANB
          gkqhkiG9w0BAQsFAAOCAQEACFFfOyUb3aShopN8ZHYo9m84/ezFm8cF6Z/Bvi0gL
          Bp6BmU20fO2o/upwupZ+wcbQJqhvx7atuMyOk9oxjzXfbySCXuChU9MS6rcB/mOh
          k4Csd+LOBCX2vlHBP0bfL8CANOdkMXq5Qq3k/W7w9R3y3p1QA28iMy+oPp5XwRGK
          gy74EvsalsO/Luya+awKnLWKxjRpKWHXXYsZugm54ZJuIzHfnAwqvqh9fLQQT4jP
          YnE9fX6s/PFn1gjmJhxQRWm0FlbQiTzewtcl1UbpnvjlrCc4BCeSuJHC3ZvSv8lF



  Drake                    Expires 31 October 2026               [Page 68]


  Internet-Draft         Hardware Email Attestation             April 2026


          ua7tNCvMC/8rQ9NdO5h/cNjGoKXTjDxymARo93mtYbjJjGCAW8wggFrAgEBMEYwL
          jEMMAoGA1UECgwDMUlEMR4wHAYDVQQDDBUxSUQgSW50ZXJtZWRpYXRlIENBIEECF
          AsG8aXy5/mmGlHXF6wPsrRw38FPMA0GCWCGSAFlAwQCAQUAMAsGCSqGSIb3DQEBC
          wSCAQDG3jQoFX3z+sqGckMG62REgN0joeg3g660ySov4asnz2x/Hj1XU9CpmUNw3
          DI4GiiEFn3ZmATbSnSYlV1NDVPJ2Q91No4rIQxVJMYfeF0EIrQ2+Ur0ycEuTyZdh
          yGtDq8M2NbHVo2oeSRD4XLK/p//KOURU9tdDleNmL93N1Eo6GZpzoIX+unGH9SR6
          Kt294TE+WRzw8WFLKPTxcaiicMAv+1G37IwC+VzUxjqYBGMLESZCx9xnB0xeG/Y7
          NwIqqf7X5JWm6QZ2PGDCyjZWgEe0cUnGEEyj+YZS2LW/XqQghsC1LVFzIrTejhlZ
          363fAWD8wMLeAa5cJnYWjAL2ijM; aid=urn:aid:com.1id:1id-jq8c84k4

  RFC example 4 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  virtual (vTPM, typ=VRT)
    Identity:    urn:aid:com.1id:1id-jq8c84k4
    Device:      VMware virtual TPM (vTPM)
    SDK:         Python (oneid-sdk) v1.3.2
    Mode:        Combined (Mode 1 + Mode 2)
    Headers:     Hardware-Attestation (Mode 1)
                 Hardware-Trust-Proof (Mode 2)

  What to look for:
    - trust_tier=virtual in the SD-JWT.
    - The virtual tier sits between sovereign
      and declared: the TPM exists but is not
      physically tamper-resistant.
    - Hardware-Attestation is present because
      the vTPM can still produce a valid AK
      certificate chain.
    - A verifier can distinguish virtual from
      sovereign by inspecting the trust_tier
      claim in the SD-JWT.

      Figure 4: Example 4: Virtual vTPM, Combined Mode (Python SDK)

  C.5.  Example 5: Declared-Tier Software-Only (Mode 2 Only, Python SDK)

     This message demonstrates a declared-tier identity where the signing
     key is stored in software with no hardware protection.  Only Mode 2
     (Hardware-Trust-Proof) succeeded; Mode 1 failed because the EdDSA
     algorithm used by this identity's software key is not yet supported
     in the reference SDK's CMS implementation.  The SD-JWT discloses
     trust_tier="declared", allowing receiving servers to apply
     differentiated policy (e.g., lower reputation weight).  Declared-tier
     identities still participate in reputation tracking, but without
     hardware-backed Sybil resistance.





  Drake                    Expires 31 October 2026               [Page 69]


  Internet-Draft         Hardware Email Attestation             April 2026


  Received: from RoG.localdomain (unknown [2001:8000:1bed:6d00:ecfa:f9e5:c
          8e3:ed4f] (AS1221 Telstra Limited, AU))(using TLSv1.3 with
          cipher TLS13_AES_256_GCM_SHA384) by mail.mailpal.com (Stalwart
          SMTP) with ESMTPSA id 423ADB058650CD1; Thu, 26 Mar 2026 06:47:16
          +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774507636; x=1775371636;
          bh=tQbweOdhmIKnVJeZ2WfV+dXtsk7S4L1RTzicUBPYEuk=; b=6yNSGTOK1IodR
          J59Jbhd9F/mFwrvJeGPv1C3sKb4eZKbPmYBQtdDjWuo4VknvsiZOE3uowJV6HitJ
          xCwd3ORAby9tMH4CX+U8aaPrcu24pGxRGP3qHKuJcj3LtnktSj3/RBwipjX7roqu
          gwZwEwJMBN8I6ilXN7GiC9F03AOfuraBSAUw+4CMk6oHl6tK2jeEXKu0VAHg0tOT
          qX05HOl4VTEy6meCKlXDRvJJO+iakUBa0udVtHMthHQYkBsGnNoBllUgXSpgXdxg
          nuAx1oVMpuZUdjBJZdtC5xpeZsupW4myKjfEP4lUuh00o5j4MbCZqUWAr0xriMpz
          2rD7EWaAw==;
  Authentication-Results: mailpal.com; hw-trust=pass
          header.trust_tier=declared header.registry=1id.com
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 5/6: Declared tier (Python, Mode 2)
  Date: Thu, 26 Mar 2026 16:47:11 +1000
  Message-ID: <177450763154.21623.9499316015451560959@mailpal.com>
  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0
  Hardware-Trust-Proof: eyJhbGciOiJFUzI1NiIsImtpZCI6IjFpZC1od2F0dGVzdC1lcz
          I1Ni0xIiwidHlwIjoic2Qrand0In0.eyJpc3MiOiJodHRwczovLzFpZC5jb20iLC
          JpYXQiOjE3NzQ1MDc2MzIsImV4cCI6MTc3NDUwNzkzMiwibm9uY2UiOiIxV040Q1
          RsRERubUVkdDM2NXFSZXl6dk1mX21VMVFjak82Y1dGMVRfNDg4IiwiX3NkX2FsZy
          I6InNoYS0yNTYiLCJfc2QiOlsieGt6MXhiTnhJbmZMWXdObzZ6dWNtTjVhbVB0VH
          FCaDFWOE4xYVQ4cy1BOCJdfQ.DxUzkzn3Bh33Nt-Tpq7YLkKYkYutLJyNgj3jJYG
          KuKNv-MoMuFXpnhlpVnG5qasrIb_TRJDmAGifvnOBzV5ubA~WyI4VGUwNHd4cHpL
          YU9POURQaVhfZXBnIiwidHJ1c3RfdGllciIsImRlY2xhcmVkIl0~

  RFC example 5 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  declared (software key, typ=SFT)
    Identity:    urn:aid:com.1id:1id-zrw4psyg
    Device:      Software-only (Ed25519 key)
    SDK:         Python (oneid-sdk) v1.3.2
    Mode:        Mode 2 only (SD-JWT trust proof)
    Header:      Hardware-Trust-Proof only

  What to look for:
    - trust_tier=declared in the SD-JWT.
    - No Hardware-Attestation header (Mode 1



  Drake                    Expires 31 October 2026               [Page 70]


  Internet-Draft         Hardware Email Attestation             April 2026


      requires a certificate chain, which
      declared-tier identities lack).
    - The declared tier is the lowest trust
      level: the identity has no hardware
      binding. It is equivalent to a standard
      software signing key.
    - This tier exists so that agents without
      hardware can still participate in the
      attestation ecosystem (e.g. to begin
      accruing reputation), with recipients
      aware of the reduced assurance.

     Figure 5: Example 5: Declared Software-Only, Mode 2 (Python SDK)

  C.6.  Example 6: Sovereign-Tier TPM (Mode 1 Only, Python SDK)

     This message demonstrates Mode 1 only (Direct Hardware Attestation)
     from the same physical TPM and agent identity as Example 1, but using
     the Python SDK instead of Node.js.  There is no Hardware-Trust-Proof
     header; only the Hardware-Attestation header is present.  This is the
     simpler deployment model where no SD-JWT issuer/registry interaction
     is needed -- the CMS signature is independently verifiable against
     the TPM manufacturer's root CA with no trust in any identity service
     required.  The Authentication-Results header shows only hw-attest (no
     hw-trust result).

  Received: from [172.22.1.89] (unknown [2001:8000:1bed:6d00:ecfa:f9e5:c8e
          3:ed4f] (AS1221 Telstra Limited, AU))(using TLSv1.3 with cipher
          TLS13_AES_256_GCM_SHA384) by mail.mailpal.com (Stalwart SMTP)
          with ESMTPSA id 423ADE6B40516D1; Thu, 26 Mar 2026 06:49:08 +0000
  Return-Path: <alice@example.un.ag>
  DKIM-Signature: v=1; a=rsa-sha256; s=rsa; d=example.un.ag;
          c=relaxed/relaxed; r=y; h=Message-ID:Date:Subject:To:From;
          t=1774507748; x=1775371748; bh=629O0DX4KvelluIXRhMhqaQlrmx71QOQV
          Vfnw8aAYjc=; b=UYsTBy57SwrnwyQ++nVr0toCnbv3kdk8/1o6XDPY47otdI4Ix
          xupx4VaATFeIv+h+CorYOGAwB2WnDDZzUYYupCidt0aoJHfz238KhoEWs1L+fXhr
          tDZYrk3e4MyQAWLNlAAS11u9ViVeCgaSLro80DQUQ49yaixGwj68Hc5HkXpuHS/r
          uC1pGWa7Cjeu54s+sQklUHqPIwymhuRIdfKAcZJoMEx0GSRHb3QWLO0hISvHnUk0
          tnveNw3HN/riJ8PEC35itJiJTbSDLzRL4rOdaXOkjsnStwoNQE0gJ+cLawJtmn8Q
          a7LNz9gHaIKfSoPuTe/9vqClr6KXHRB8XRBjA==;
  Authentication-Results: mailpal.com; hw-attest=pass header.typ=TPM
          header.alg=RS256 header.tier=sovereign
          header.aid=urn:aid:com.1id:1id-tkoie2ve
  From: Alice <alice@example.un.ag>
  To: bob@example.un.ag
  Subject: RFC Example 6/6: Sovereign TPM (Python, Mode 1)
  Date: Thu, 26 Mar 2026 16:49:05 +1000
  Message-ID: <177450774520.30168.11382866965426144830@mailpal.com>



  Drake                    Expires 31 October 2026               [Page 71]


  Internet-Draft         Hardware Email Attestation             April 2026


  Content-Type: text/plain; charset="utf-8"
  Content-Transfer-Encoding: 7bit
  MIME-Version: 1.0
  Hardware-Attestation: v=1; typ=TPM; alg=RS256; h=from:to:subject:date:me
          ssage-id:content-transfer-encoding:content-type:mime-version;
          bh=uQAodZKMniNXQzM-9eg-efen0Sg2a7iaZwO10AhYOEM; ts=1774507745;
          chain=MIIMAQYJKoZIhvcNAQcCoIIL8jCCC+4CAQExDzANBglghkgBZQMEAgEFAD
          ALBgkqhkiG9w0BBwGgggpWMIID4TCCAsmgAwIBAgIUH01pfnWQCIfMiHfTNQb7v7
          r3CmMwDQYJKoZIhvcNAQELBQAwLjEMMAoGA1UECgwDMUlEMR4wHAYDVQQDDBUxSU
          QgSW50ZXJtZWRpYXRlIENBIEEwHhcNMjYwMzIwMTYzNjI2WhcNMjcwMzIwMTYzNj
          I2WjBMMQwwCgYDVQQKDAMxSUQxJTAjBgNVBAMMHHVybjphaWQ6Y29tLjFpZDoxaW
          QtdGtvaWUydmUxFTATBgNVBAUTDDFpZC10a29pZTJ2ZTCCASIwDQYJKoZIhvcNAQ
          EBBQADggEPADCCAQoCggEBANvysXC8ILSnhGcqg66dWKWQLp9pOJZmj6yTbICDVL
          ydBwc1LGEQAW3BCee6XU/Bs0n91uROJCQw3jgrCMiBUOvS6Mjox/8NT1gfZ9sDQG
          VXN5gQ0t9H+r9vEPJ7YL9jhYmlxWQp+fS6vhZNrmH7g4XwEK+EsbMsc8H0ZuxKAM
          1S7p9447G9IOZOkFMK33ZxCCY00DFmwzXu/dkGFfuOaSWM5cazWz/kxqOtcpT73A
          CmJxQ6LU3yzB6VwbfwCWm6klQNKsd1c7FT5hX5ZYtEqDXeIpIGWyQp9TQgNbUIPe
          JCWO2rDLmh0ZXwqXR4yBqKeNWhUjrcnfQgNfrjJ7zB0z8CAwEAAaOB2DCB1TAnBg
          NVHREEIDAehhx1cm46YWlkOmNvbS4xaWQ6MWlkLXRrb2llMnZlMAwGA1UdEwEB/w
          QCMAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBRroL9zk1MDMjMG4UyIvjZdzd
          X8QTAfBgNVHSMEGDAWgBRnIsB54FVyNiezRKLzTN+AXd+WrjAXBgorBgEEAYPUXw
          EBBAlzb3ZlcmVpZ24wIgYKKwYBBAGD1F8BAgQUMjAyNi0wMy0wNFQwMDowMDowMF
          owDwYKKwYBBAGD1F8BAwQBADANBgkqhkiG9w0BAQsFAAOCAQEAiL2Fwbib2C2bzY
          zRpDsyFGSXmn2LcFO3snxAaoRJxwMqa5UcyNZNaPk9SHtr7mocHO8spAi5q+7Twa
          8+1djZ3HJha5iKW59E9o2/JFBBM8p1ehkHVmlTtF130RFjaaW1BnPvdfjSMCdYHk
          9IIOw90+oAA7omUAlYTXclGLduE2fOfVcAaqIz+wFYS89iJOtlbj+BH8wwa6Ee3P
          1pEe1p4LW4KGdaIrA1/yfarCaglkVlJxA4GsR2y1H43l7ZNijh/lsS+iRJWXvBWG
          qecVx+GY/jPpvG4ahObRO4/MW5F1i3fKvkE0UX4juC5t0nPtCbRsQFRmbIcQv+Oc
          LJV9MexzCCA0gwggIwoAMCAQICFEhBGCtvI+p+lYa/sOD7w5IrskGxMA0GCSqGSI
          b3DQEBCwUAMCYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAwwNMUlEIFJvb3QgQ0EgQT
          AeFw0yNjAzMTQxNDEzNDdaFw0zMTAzMTMxNDEzNDdaMC4xDDAKBgNVBAoMAzFJRD
          EeMBwGA1UEAwwVMUlEIEludGVybWVkaWF0ZSBDQSBBMIIBIjANBgkqhkiG9w0BAQ
          EFAAOCAQ8AMIIBCgKCAQEAueeMbFQ0VCd3zBECEit2soc9g0xaRwzL4QT+jB6k7f
          9dehwyTY/tqlyXQJlR/BnV8zMJv7bfZ6xq8eEnd73HaHcKVJxdg4VQEmfHtk4mGA
          fWuAy7j3N5TsPpcFTqgkJlAwUp3kH3yDVPvO1qHzbVmUFdvDscthxQ3xYVP1pCPd
          WsoiP4oR0L0EyaaqmTwG2J/hIw/vAGqwWx4CrMsg8VvKDpsLPNp2IZ/HkXc+ztw3
          tsPXKWaLiTMli8RvZ8FEjsQ933Nfr23DHqEZgS0QA8fUZoaxzogdhxVue/W7KnZM
          8ENdP0jOf0l5oUncGo8VP5p5BmQhP73J3bVMyeQf7cIwIDAQABo2YwZDASBgNVHR
          MBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUZyLAeeBVcj
          Yns0Si80zfgF3flq4wHwYDVR0jBBgwFoAUw7fpWXXFX/lGDy85m5SqTPkl8PAwDQ
          YJKoZIhvcNAQELBQADggEBAIVAxZlTfr2eEitQkDzx/Vxs5CftPYgIVJAt5SzSvo
          VjKQWfkth7PClZeGjGmZg9vozqwuFo+Tnvq1bCe8loiZn0PXwsjEeNxgKAnAGcg7
          KvacsnyH120DuvnT1NE33y/vR4GNqpnvFzf77DqlmN4BL8Yoa1vYp1XNehHg79Yk
          S3FlGXuaN7ku7WU3Uuv25Em9ZbvNbfZyvGGeto8TWNkgfWnF/asfTFjYwUrF+8k4
          xxAFZ/0OjjM3Y0v0mpdf0XAE8a846PG59tn3qnopCQmqKuJTiv5CgWX8/RdARjVR
          /eQIwoaduW5YhmEFzMz24kLlJ5us6jHSGCYPzbT84OpLowggMhMIICCaADAgECAh
          RnIjFxQzVLiE7JnREz6PpYT9J0DzANBgkqhkiG9w0BAQsFADAmMQwwCgYDVQQKDA
          MxSUQxFjAUBgNVBAMMDTFJRCBSb290IENBIEEwIBcNMjYwMzE0MTQxMzQ3WhgPMj



  Drake                    Expires 31 October 2026               [Page 72]


  Internet-Draft         Hardware Email Attestation             April 2026


          A1NjAzMDYxNDEzNDdaMCYxDDAKBgNVBAoMAzFJRDEWMBQGA1UEAwwNMUlEIFJvb3
          QgQ0EgQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOAkpJayeSScKq
          R0JEmx+i6EGae5F6roRJsqGQRA/fwZMsw7JXeKNyMhXcb2n6w7uHuWA8xiMYx4Ar
          wr8FIGxGben3pjqkjPdVTyjLgczBKtK7Rws+yf70v57H8N/zaoBTfo/qtR8hx1cf
          i91vMED1q1S6iNkVBT8lPaHmS+lymmi9DzSMC9jcQCjLnObkPwVDzYw7IeyODOYA
          +l/Vkf+GRJ71HdLJYpfHyTy0Y8OqJtnqv5BZeaV1u5oqXX9rn4mBCHNZRAbX9+JK
          wljNzxL55dEbOHhIqw4q8cezxT9fBjoKDcmkPDTWWUjqguizK1naFzur/DCkFXAn
          CJ0bE33T0CAwEAAaNFMEMwEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBA
          MCAQYwHQYDVR0OBBYEFMO36Vl1xV/5Rg8vOZuUqkz5JfDwMA0GCSqGSIb3DQEBCw
          UAA4IBAQAIUV87JRvdpKGik3xkdij2bzj97MWbxwXpn8G+LSAsGnoGZTbR87aj+6
          nC6ln7BxtAmqG/Htq24zI6T2jGPNd9vJIJe4KFT0xLqtwH+Y6GTgKx34s4EJfa+U
          cE/Rt8vwIA052QxerlCreT9bvD1HfLenVADbyIzL6g+nlfBEYqDLvgS+xqWw78u7
          Jr5rAqctYrGNGkpYdddixm6Cbnhkm4jMd+cDCq+qH18tBBPiM9icT19fqz88WfWC
          OYmHFBFabQWVtCJPN7C1yXVRume+OWsJzgEJ5K4kcLdm9K/yUW5ru00K8wL/ytD0
          107mH9w2MagpdOMPHKYBGj3ea1huMmMYIBbzCCAWsCAQEwRjAuMQwwCgYDVQQKDA
          MxSUQxHjAcBgNVBAMMFTFJRCBJbnRlcm1lZGlhdGUgQ0EgQQIUH01pfnWQCIfMiH
          fTNQb7v7r3CmMwDQYJYIZIAWUDBAIBBQAwCwYJKoZIhvcNAQELBIIBANlEWSrD7C
          9a1OdJkDysB9UvvSrYkdArqu4BjHu0nJxWJdHURKtXW73SYQK6eBYhGm+9FOgCdw
          syV+JsYijmeBMyB3iAwtYWWbEbjAnb0uj0WH2vhNEzKR8KYpus/YYauACqBPDCea
          BbFE7iFmhW1p9Zj6lSZ+M3EkuUTrZMuBadNxzWwOOdVls2+r8XSos8TgSRcnMsg4
          FdIs2KSL3pUAAMLLJEwUpBZ5VAIMlmFgUu/KSXfj97hnyl7qycq7TofKjLsLukqv
          U+58Oqs2eA8SxRnWQbvBs41JwywSZmAZ+2+gokICuWjteUnoUAkb1mPEy8ylFsK9
          jwbTSSBm9b2eU=; aid=urn:aid:com.1id:1id-tkoie2ve

  RFC example 6 of 6: hardware email attestation per
  draft-drake-email-hardware-attestation-00.

    Trust tier:  sovereign (hardware TPM, typ=TPM)
    Identity:    urn:aid:com.1id:1id-tkoie2ve
    Device:      Intel firmware TPM (PTT)
    SDK:         Python (oneid-sdk) v1.3.2
    Mode:        Mode 1 only (direct attestation)
    Header:      Hardware-Attestation only

  What to look for:
    - Only Hardware-Attestation is present;
      no Hardware-Trust-Proof header.
    - Same identity and device as example 1,
      but sent via the Python SDK.
    - Demonstrates that Mode 1 and Mode 2
      are independent and composable.
    - The aid URN matches example 1.

       Figure 6: Example 6: Sovereign TPM, Mode 1 Only (Python SDK)







  Drake                    Expires 31 October 2026               [Page 73]


  Internet-Draft         Hardware Email Attestation             April 2026


  C.7.  Verification Failure Examples

     The following Authentication-Results headers illustrate what
     receiving mail servers emit when verification fails.  These are from
     actual test messages where the attestation was malformed or tampered
     with.  Implementers building verifiers should emit similar diagnostic
     information in the parenthetical comment.

     Mode 2 (SD-JWT Trust Proof) failure -- message-binding nonce
     mismatch, indicating the SD-JWT was not bound to this specific
     message (possible replay or header modification):

     Authentication-Results: mailpal.com; hw-trust=fail
       header.trust_tier=declared header.registry=1id.com
       (Message-binding nonce mismatch: got
       'uVgDzsXUJUPch1I-hRM3vGgip4uIvrkE1aeixhsp3OU', expected
       'lB_mxWwfU9o301aGO4Yb3GdTzKm)

     Mode 1 (Direct Hardware Attestation) failure -- cryptographic
     signature does not match, indicating the message body or signed
     headers were modified after signing (or the signing key does not
     match the certificate chain):

     Authentication-Results: mailpal.com; hw-attest=fail
       header.typ=TPM header.alg=RS256 header.tier=sovereign
       header.aid=urn:aid:com.1id:1id-tkoie2ve
       (Signature verification failed: Cryptographic signature
       does not match)

  Appendix D.  Appendix: Applicability to Other Transports

     The CMS attestation bundle (the "chain" value defined in Section 5.2)
     and the SD-JWT trust proof (defined in Section 6.2) are self-
     contained data structures whose verification algorithms (Section 5.3
     and Section 6.4) do not depend on email semantics.  The body hash
     (bh) generalises to a content hash over whatever payload the
     attestation covers.

     Potential transport bindings include but are not limited to:

     HTTP  The CMS attestation bundle or SD-JWT trust proof could be
        carried in HTTP request headers or in HTTP message bodies.  The
        content hash would cover the HTTP request or response payload.
        This binding is particularly relevant for API calls by autonomous
        AI agents, where the receiving service benefits from verifying
        that the request originated on attested hardware.  The agent
        identity URN (Section 4.1) provides a persistent key for cross-
        protocol reputation tracking.



  Drake                    Expires 31 October 2026               [Page 74]


  Internet-Draft         Hardware Email Attestation             April 2026


     Agent-to-Agent Protocols  Emerging protocols for AI agent
        communication -- tool invocation, task delegation, capability
        discovery -- could carry attestation evidence alongside each
        request, enabling agents to verify each other's hardware trust
        level before exchanging sensitive data or delegating privileged
        operations.

     WebSocket and Streaming Protocols  Attestation evidence could be
        presented during connection establishment (e.g., in the WebSocket
        upgrade request) to establish hardware trust for the duration of a
        persistent connection.

     Detailed specification of these bindings is out of scope for this
     document and is deferred to future companion documents.

  Appendix E.  Appendix: URN Namespace Registration for "aid"

     This appendix provides the registration template for the "aid" (Agent
     Identity) URN namespace, per [RFC8141] Section 5.1.

     Namespace Identifier  aid

     Version  1

     Date  2026-02-28

     Registrant  TBD -- to be transferred to the governance authority for
        the Agent Identity ecosystem upon its constitution.  Interim
        contact: Christopher Drake <cnd@1id.com>.

     Purpose  The "aid" URN namespace provides persistent, globally unique
        identifiers for autonomous agents, designed specifically to enable
        reputation systems and Sybil-resistant authentication across
        Internet protocols.

        As AI agents become ubiquitous across email, APIs, and Internet
        services, platforms need stable identifiers that: (1) distinguish
        legitimate agents from malicious ones, (2) accumulate reputation
        over time, (3) are anchored to unique physical hardware where
        available, and (4) support federated issuance by multiple
        independent identity providers.

        URNs in this namespace are bound to hardware security components
        (TPM chips, PIV tokens, virtual TPMs) or to software-managed keys
        at a lower trust tier.  The namespace supports multiple issuers,
        each identified by a reverse-DNS issuer-namespace within the URN
        structure.




  Drake                    Expires 31 October 2026               [Page 75]


  Internet-Draft         Hardware Email Attestation             April 2026


     Syntax  See Section 4.1 for the formal ABNF.  The general form is:

        urn:aid:{namespace}:{agent-id}

        where {namespace} is a single label (global) or a reverse-DNS
        domain (e.g., com.1id), and {agent-id} is either a canonical
        identifier (e.g., id-9854187104) or a handle (e.g., crusty).

     Assignment  Agent identifiers are assigned by Issuers --
        organisations that operate enrollment services, verify hardware
        attestation, and maintain anti-Sybil registries.  Any organisation
        owning a DNS domain can operate as an Issuer.  Issuer-namespace
        uniqueness is guaranteed by DNS ownership.  Agent-id uniqueness
        within a namespace is guaranteed by the Issuer's assignment
        policy.  An Issuer MUST NOT reassign an agent-id, even after
        revocation.

     Security and Privacy  See the Security Considerations (Section 14) of
        this document.  Agent identity URNs are persistent and globally
        unique by design, enabling long-term reputation tracking.  For
        privacy-sensitive contexts, SD-JWT selective disclosure
        (Section 6) allows agents to prove trust properties without
        revealing their URN.

     Interoperability  URNs in this namespace appear in: JWT sub claims
        (OpenID Connect tokens), email headers (Hardware-Attestation,
        Hardware-Trust-Proof), HTTP Authorization headers, and reputation
        service APIs.  Standard URN parsers ([RFC8141]) and standard JWT
        libraries process these identifiers without modification.

     Resolution  Resolution is OPTIONAL.  Issuers MAY provide resolution
        services returning public identity metadata.  The resolution URL
        is derived by reversing the issuer-namespace to obtain the Issuer
        domain and appending a well-known path.  Resolution, when
        available, returns trust tier, registration timestamp, and
        optional handle -- but never authentication history or private
        data.

     Documentation  This document (draft-drake-email-hardware-attestation-
        00).

     Revision Information  Initial registration.









  Drake                    Expires 31 October 2026               [Page 76]


  Internet-Draft         Hardware Email Attestation             April 2026


  Appendix F.  Acknowledgements

     The concept of using hardware attestation for email sender
     verification was developed in the context of building a hardware
     identity registrar for autonomous AI agents.  The author thanks the
     Trusted Computing Group for the TPM 2.0 specification, the authors of
     [RFC9901] (SD-JWT) for the selective disclosure mechanism, the
     authors of [RFC9334] (RATS Architecture) for establishing the remote
     attestation architecture that this document builds upon, and the
     authors of [RFC8141] (URN) for the persistent identifier framework
     that underpins the federated agent identity model.

  Author's Address

     Christopher Drake
     1id.com
     Australia
     Email: cnd@1id.com
     URI:   https://1id.com
































  Drake                    Expires 31 October 2026               [Page 77]


