# drafts

name: draft-jurkovikj-collab-tunnel
rev: 01
title: The Collaboration Tunnel Protocol (TCT)
time: 2025-11-14T09:01:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-18T09:01:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:06.864795+00:00
abstract:
This document specifies the Collaboration Tunnel Protocol, an HTTP-
   based method for efficient, verifiable delivery of web content to
   automated agents.  The protocol uses bidirectional URL discovery,
   template-invariant content fingerprinting with strong ETags, sitemap-
   first verification, and strict conditional request discipline to
   reduce bandwidth while preserving canonical URLs.

full_text:
Network Working Group                                       A. Jurkovikj
Internet-Draft                                          14 November 2025
Intended status: Experimental                                           
Expires: 18 May 2026


                The Collaboration Tunnel Protocol (TCT)
                    draft-jurkovikj-collab-tunnel-01

Abstract

   This document specifies the Collaboration Tunnel Protocol, an HTTP-
   based method for efficient, verifiable delivery of web content to
   automated agents.  The protocol uses bidirectional URL discovery,
   template-invariant content fingerprinting with strong ETags, sitemap-
   first verification, and strict conditional request discipline to
   reduce bandwidth while preserving canonical URLs.

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

Copyright Notice

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

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



Jurkovikj                  Expires 18 May 2026                  [Page 1]

Internet-Draft                     TCT                     November 2025


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.1.  Problem Statement . . . . . . . . . . . . . . . . . .   5
       1.1.2.  Goals and Non-Goals . . . . . . . . . . . . . . . . .   5
     1.2.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   6
     1.3.  Design Rationale and Relation to Existing Mechanisms  . .   7
       1.3.1.  Related Work  . . . . . . . . . . . . . . . . . . . .   7
       1.3.2.  TCT Design Choices  . . . . . . . . . . . . . . . . .   8
     1.4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   8
       1.4.1.  M-Sitemap Discovery . . . . . . . . . . . . . . . . .   8
       1.4.2.  M-URL Discovery and Canonical Links . . . . . . . . .  10
       1.4.3.  Template-Invariance . . . . . . . . . . . . . . . . .  10
     1.5.  M-URL Representation  . . . . . . . . . . . . . . . . . .  11
       1.5.1.  Content-Type and Encoding . . . . . . . . . . . . . .  11
       1.5.2.  Required JSON Fields  . . . . . . . . . . . . . . . .  11
       1.5.3.  Representation Stability  . . . . . . . . . . . . . .  12
     1.6.  Deterministic JSON and Strong ETags . . . . . . . . . . .  12
       1.6.1.  Deterministic JSON Serialization  . . . . . . . . . .  13
       1.6.2.  Strong ETag Generation (Single Method)  . . . . . . .  13
       1.6.3.  Relationship to Template-Invariance . . . . . . . . .  14
       1.6.4.  Canonical Text Normalization (Optional for
               Producers)  . . . . . . . . . . . . . . . . . . . . .  14
     1.7.  M-Sitemap Format and Semantics  . . . . . . . . . . . . .  16
       1.7.1.  M-Sitemap JSON Structure  . . . . . . . . . . . . . .  16
       1.7.2.  HTTP Response for M-Sitemap . . . . . . . . . . . . .  17
       1.7.3.  Parity Semantics  . . . . . . . . . . . . . . . . . .  17
     1.8.  Client Behavior . . . . . . . . . . . . . . . . . . . . .  18
       1.8.1.  Zero-Fetch Optimization . . . . . . . . . . . . . . .  18
       1.8.2.  Conditional Requests to M-URLs  . . . . . . . . . . .  19
       1.8.3.  Use of HEAD (Optional)  . . . . . . . . . . . . . . .  19
       1.8.4.  Client Validation (Optional)  . . . . . . . . . . . .  19
     1.9.  Operational Considerations (Informative)  . . . . . . . .  20
       1.9.1.  Deployment with CDNs and Proxies  . . . . . . . . . .  20
       1.9.2.  Large Sites and Sharding  . . . . . . . . . . . . . .  20
       1.9.3.  Error Handling  . . . . . . . . . . . . . . . . . . .  20
       1.9.4.  Backwards Compatibility . . . . . . . . . . . . . . .  21
     1.10. Security Considerations . . . . . . . . . . . . . . . . .  21
     1.11. IANA Considerations . . . . . . . . . . . . . . . . . . .  22
   2.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     2.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
     2.2.  Informative References  . . . . . . . . . . . . . . . . .  23
   Appendix A.  Appendix A.  Normalization Test Vectors  . . . . . .  24
     A.1.  A.1.  Basic ASCII . . . . . . . . . . . . . . . . . . . .  24
       A.1.1.  A.2.  HTML Entities . . . . . . . . . . . . . . . . .  24
       A.1.2.  A.3.  Unicode Normalization (NFKC)  . . . . . . . . .  25
       A.1.3.  A.4.  Case Folding Edge Cases . . . . . . . . . . . .  25



Jurkovikj                  Expires 18 May 2026                  [Page 2]

Internet-Draft                     TCT                     November 2025


       A.1.4.  A.5.  Control Characters  . . . . . . . . . . . . . .  26
       A.1.5.  A.6.  Whitespace Edge Cases . . . . . . . . . . . . .  26
       A.1.6.  A.7.  Empty and Edge Cases  . . . . . . . . . . . . .  26
       A.1.7.  A.8.  Complex Real-World Examples . . . . . . . . . .  27
       A.1.8.  A.9.  Implementation Notes  . . . . . . . . . . . . .  27
     A.2.  Appendix B.  Example Flows (Informative)  . . . . . . . .  27
       A.2.1.  B.1.  Initial Discovery and First Fetch . . . . . . .  27
       A.2.2.  B.2.  Zero-Fetch Optimization (Content Unchanged) . .  28
       A.2.3.  B.3.  Conditional Request (Content Unchanged) . . . .  29
       A.2.4.  B.4.  Content Changed . . . . . . . . . . . . . . . .  30
       A.2.5.  B.5.  Parity Mismatch Handling  . . . . . . . . . . .  30
       A.2.6.  B.6.  Using HEAD for Efficient Freshness Check  . . .  31
       A.2.7.  B.7.  Discovery via C-URL . . . . . . . . . . . . . .  32
     A.3.  Appendix C.  Implementation Notes (Informative) . . . . .  32
       A.3.1.  C.1.  Reference Implementations . . . . . . . . . . .  32
       A.3.2.  C.2.  Deterministic JSON Libraries  . . . . . . . . .  33
       A.3.3.  C.3.  SHA-256 Computation . . . . . . . . . . . . . .  34
   Appendix B.  Canonical JSON . . . . . . . . . . . . . . . . . . .  34
   Appendix C.  Hash . . . . . . . . . . . . . . . . . . . . . . . .  34
     C.1.  C.4.  Unicode Normalization . . . . . . . . . . . . . . .  35
   Appendix D.  NFKC normalization . . . . . . . . . . . . . . . . .  35
   Appendix E.  Case folding . . . . . . . . . . . . . . . . . . . .  35
     E.1.  C.5.  HTTP Response Headers . . . . . . . . . . . . . . .  35
   Appendix F.  Response if unchanged  . . . . . . . . . . . . . . .  36
   Appendix G.  Response if changed  . . . . . . . . . . . . . . . .  36
     G.1.  C.6.  Production Deployment Data  . . . . . . . . . . . .  36
       G.1.1.  C.7.  Common Implementation Pitfalls  . . . . . . . .  36
       G.1.2.  C.8.  Testing and Validation  . . . . . . . . . . . .  37
       G.1.3.  C.9.  Performance Considerations  . . . . . . . . . .  37
       G.1.4.  C.10.  Security Best Practices  . . . . . . . . . . .  38
   Appendix H.  Acknowledgments  . . . . . . . . . . . . . . . . . .  38
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   Automated agents (search engines, AI crawlers, archives, monitoring
   tools, aggregators) increasingly consume web content at scale.
   Fetching and parsing full HTML pages for machine consumption is often
   inefficient:

   *  Page weight is dominated by templates, navigation, ads, and
      scripts.

   *  Machine consumers typically need a stable textual representation
      of the core content.

   *  Many pages do not change frequently, but are re-fetched in full.




Jurkovikj                  Expires 18 May 2026                  [Page 3]

Internet-Draft                     TCT                     November 2025


   Various sites already expose JSON APIs or feeds, but:

   *  formats differ across sites, and

   *  use of HTTP validators is inconsistent.

   The Collaboration Tunnel Protocol (TCT) defines a simple,
   interoperable profile on top of HTTP that:

   *  exposes a canonical JSON representation (M-URL) for selected
      resources;

   *  advertises C-URL/M-URL mappings and validators in a JSON sitemap
      (M-Sitemap);

   *  uses a single, well-defined strong ETag method for M-URLs; and

   *  enables "zero-fetch" behavior when content is unchanged.

   TCT is intentionally conservative: it uses only existing HTTP
   mechanisms, is backward compatible with the Web, and does not define
   policy or licensing semantics.

1.1.  Terminology

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

   *  C-URL:

      -  The canonical, human-facing URL of a resource, typically an
         HTML document.

   *  M-URL:

      -  The machine-facing URL providing the TCT JSON representation of
         that resource.

   *  M-Sitemap:

      -  The JSON sitemap enumerating C-URL/M-URL pairs and associated
         validators.

   *  Representation:




Jurkovikj                  Expires 18 May 2026                  [Page 4]

Internet-Draft                     TCT                     November 2025


      -  As defined in [RFC9110]: the information in a payload,
         including representation metadata, that is subject to content
         negotiation.

   Unless stated otherwise, "client" refers to an automated agent that
   is aware of TCT.

1.1.1.  Problem Statement

   Key inefficiencies in current automated consumption of web content
   include:

   *  repeated transfer of large HTML documents whose core content has
      not changed;

   *  lack of a standard, compact, semantics-focused representation for
      page-like resources;

   *  ad hoc usage or absence of validators (ETag, Last-Modified),
      hindering efficient revalidation;

   *  difficulty for agents to reason about change detection at scale
      using only HTML and XML sitemaps.

1.1.2.  Goals and Non-Goals

   TCT is designed to:

   *  reuse HTTP semantics ([RFC9110], [RFC9111]) rather than introduce
      new ones;

   *  provide a simple, deterministic JSON representation appropriate
      for:

      -  search indexing,

      -  content analysis,

      -  retrieval-augmented generation (RAG),

      -  archival and monitoring;

   *  define discovery and validation clearly enough for interoperable
      clients and servers.

   TCT explicitly does NOT:





Jurkovikj                  Expires 18 May 2026                  [Page 5]

Internet-Draft                     TCT                     November 2025


   *  define how content may or may not be used (policy, licensing, AI
      usage);

   *  change the semantics of resources at C-URLs;

   *  require new HTTP methods or status codes.

1.2.  Architecture

   TCT introduces three main elements per participating origin:

   *  C-URL:

      -  The canonical resource URL for humans, often serving HTML.

   *  M-URL:

      -  A URL providing a canonical JSON representation of the same
         logical resource (TCT JSON).

   *  M-Sitemap:

      -  A JSON document listing C-URLs, M-URLs, and strong validators
         (etag values).

   High-level flow (informative):

   1.  Client performs GET / at https://example.com/.

   2.  The origin root response includes:

       *  Link: </llm-pages.json>; rel="index"; type="application/json".

   3.  Client fetches /llm-pages.json (M-Sitemap).

   4.  For each item:

       *  learns (cUrl, mUrl, etag).

   5.  Client fetches mUrl as needed:

       *  GET mUrl, with If-None-Match on subsequent checks.

   6.  Server responds with:

       *  200 OK + JSON when changed;

       *  304 Not Modified when unchanged.



Jurkovikj                  Expires 18 May 2026                  [Page 6]

Internet-Draft                     TCT                     November 2025


   TCT is additive and optional:

   *  Non-TCT clients ignore TCT artifacts.

   *  Servers can deploy TCT gradually alongside existing content and
      sitemaps.

1.3.  Design Rationale and Relation to Existing Mechanisms

   TCT is grounded in existing mechanisms and complements several
   related efforts:

1.3.1.  Related Work

   *XML Sitemaps:* - Widely deployed for URL discovery (search engines,
   crawlers). - Provide <lastmod> timestamps but do not define normative
   bindings between sitemap entries and HTTP validators (ETags) for
   endpoint representations. - TCT builds on this model by adding
   structured JSON representations and strong validator integration.

   *ResourceSync:* - Developed by the Open Archives Initiative and
   collaborators for resource synchronization in digital libraries. -
   Provides resource lists, change lists, and capability documents. -
   Focus is synchronization and preservation; does not define a single,
   tightly integrated pattern combining: - per-resource JSON
   representation, - sitemap listing with validators, and - ETag-based
   zero-fetch semantics. - TCT addresses the specific use case of
   efficient web content delivery to automated agents.

   *AMP (Accelerated Mobile Pages):* - Defines an HTML subset optimized
   for fast rendering on mobile devices. - Provides alternate
   representations via <link rel="amphtml">. - TCT provides JSON (not
   HTML) for machine consumption, targeting crawlers and content
   analysis rather than human browsing.

   *Custom JSON APIs:* - Many sites expose custom JSON endpoints for
   content access. - Structures, field names, and validator usage vary
   widely across implementations. - TCT aims to standardize a minimal,
   interoperable profile suitable for broad adoption.

   *robots.txt:* - Defines crawl directives and access policies. - TCT
   does not replace robots.txt; publishers MAY use both mechanisms: -
   robots.txt for crawl permissions and rate guidance, and - TCT for
   efficient content delivery.







Jurkovikj                  Expires 18 May 2026                  [Page 7]

Internet-Draft                     TCT                     November 2025


   *RSS/Atom Feeds:* - Provide syndication of updates and content
   excerpts. - Typically lack HTTP caching integration (per-item ETags,
   conditional requests). - TCT can be viewed as "RSS with disciplined
   HTTP caching semantics."

1.3.2.  TCT Design Choices

   Key design choices in TCT:

   *  Use only existing HTTP semantics:

      -  GET, HEAD, 200, 304, ETag, Cache-Control, Link.

   *  Use JSON as the machine representation:

      -  Simple, widely supported, easy to parse.

      -  TCT is complementary to existing HTTP content-coding and
         dictionary-based compression mechanisms: it reduces
         representation size and refetch frequency at the application
         layer while remaining fully compatible with compression applied
         to M-URL responses.

   *  Define one strong ETag method:

      -  Based on canonical JSON bytes of the M-URL payload.

      -  Avoid ambiguous or dual hash methods.

   *  Keep policy and energy considerations out of the core:

      -  Those can be specified separately as informational work.

   The intent is to offer an interoperable profile that is:

   *  easy to implement,

   *  friendly to existing caches/CDNs, and

   *  precise enough for standardization.

1.4.  Discovery

1.4.1.  M-Sitemap Discovery

   A publisher implementing TCT MUST expose an M-Sitemap and advertise
   it from the origin root resource.




Jurkovikj                  Expires 18 May 2026                  [Page 8]

Internet-Draft                     TCT                     November 2025


   When a client performs:

   *  GET / with Host: example.com

   and receives a successful (2xx) response (either directly or after
   following redirects per [RFC9110]), that response:

   *  MUST include a Link header with:

      -  rel="index"

      -  type="application/json"

      -  a target that is the M-Sitemap URL for this origin.

   Example:

   *  Link: </llm-sitemap.json>; rel="index"; type="application/json"

   In this specification, a Link header field with rel="index",
   type="application/json", and a target whose content matches Section 7
   identifies the TCT M-Sitemap for that origin.  Other uses of
   rel="index" remain valid and are outside the scope of this document.

   Notes:

   *  /llm-sitemap.json is an example; any stable path MAY be used.

   *  If / redirects (e.g., 301 or 302 to /en/ or /index.html), the Link
      header MUST appear on the final redirect target.

   *  Clients:

      -  SHOULD follow redirects per [RFC9110] before checking for TCT
         support.

      -  MUST discover the M-Sitemap via the Link header on the final
         response.

      -  If no such Link is present, SHOULD assume TCT is not deployed
         and MUST NOT guess paths.

   *  If multiple Link headers with rel="index" and type="application/
      json" are present, clients MAY choose any or load all.  This
      document does not define multi-sitemap selection semantics; large-
      site sharding is left to operational conventions (see
      Section 9.2).




Jurkovikj                  Expires 18 May 2026                  [Page 9]

Internet-Draft                     TCT                     November 2025


   This specification does not define or require any /.well-known/ URI.

1.4.2.  M-URL Discovery and Canonical Links

   For each resource where an M-URL is provided:

   *  The C-URL response (typically HTML) SHOULD advertise the M-URL as
      an alternate JSON representation:

      Either via HTML:

      -  <link rel="alternate" type="application/json"
         href="https://example.com/post/llm.json">

      Or HTTP:

      -  Link: <https://example.com/post/llm.json>; rel="alternate";
         type="application/json"

   *  The M-URL response for that resource MUST include a corresponding
      canonical link ([RFC6596]):

      -  Link: <https://example.com/post/>; rel="canonical"

   *Note on M-URL paths:* The choice of M-URL path (e.g., /post/
   llm.json, /post/llm/, /post.json, etc.) is not specified by this
   document.  Publishers MAY choose any stable URL scheme that suits
   their architecture.  Clients MUST discover M-URLs via advertised
   links (as shown above) and MUST NOT assume a fixed path pattern.

   Examples of valid M-URL patterns: - https://example.com/post/llm.json
   (used in this document) - https://example.com/post/llm/ (directory-
   style) - https://example.com/post.json (extension-based)

   This bidirectional linkage allows clients to:

   *  verify that an M-URL is an alternate for the expected C-URL;

   *  detect misconfigurations when links are inconsistent; and

   *  ensure the canonical_url field in the M-URL JSON matches (or is
      consistent with) the URL advertised via rel="canonical" for the
      corresponding C-URL.

1.4.3.  Template-Invariance

   TCT's template-invariance property:




Jurkovikj                  Expires 18 May 2026                 [Page 10]

Internet-Draft                     TCT                     November 2025


   *  Changes to HTML templates, CSS, or JavaScript at the C-URL SHOULD
      NOT require changes to the M-URL JSON, so long as the underlying
      resource content has not changed.

   This is achieved by:

   *  treating M-URLs as distinct, canonical JSON representations of
      content; and

   *  computing strong ETags over the M-URL JSON only.

   Template-invariance is NOT achieved by relaxing strong ETag
   semantics; for any given M-URL, identical strong ETags MUST imply
   byte-identical JSON bodies.

1.5.  M-URL Representation

   An M-URL is an HTTP resource that serves a JSON representation of a
   content resource suitable for machine consumption.

   This specification defines the observable JSON representation at
   M-URLs; it does not constrain how servers derive these
   representations from their internal data models, templates, or
   storage.

1.5.1.  Content-Type and Encoding

   M-URL responses:

   *  MUST use:

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

   *  MUST be valid JSON as per [RFC8259].

   *  MUST use UTF-8 without BOM.

1.5.2.  Required JSON Fields

   The minimal M-URL JSON object for a resource MUST contain:

   *  canonical_url (string, REQUIRED)

      -  The canonical human-facing URL (C-URL).

   *  title (string, REQUIRED)

      -  A human-readable title for the resource.



Jurkovikj                  Expires 18 May 2026                 [Page 11]

Internet-Draft                     TCT                     November 2025


   *  content (string, REQUIRED)

      -  Core textual content:

         o  plain text (no raw HTML markup);

         o  SHOULD exclude purely template/boilerplate text.

   *  hash (string, REQUIRED)

      -  A validator string of the form:

         o  sha256- followed by 64 lowercase hex characters,

         o  computed as specified in Section 6.2.

      -  The hash field of an M-URL representation MUST equal the strong
         ETag value for that representation, excluding the HTTP quoting.

   Additionally:

   *  profile (string, RECOMMENDED)

      -  TCT profile identifier, e.g., tct-1.

   Example (non-normative):

   json { "profile": "tct-1", "canonical_url": "https://example.com/
   post/", "title": "Article Title", "content": "Core article
   content...", "hash": "sha256-
   2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7" }

1.5.3.  Representation Stability

   For an M-URL implementing this specification:

   *  For a given resource state, the JSON body MUST be deterministic.

   *  Any change to the JSON body bytes (including required or optional
      fields) MUST result in a different strong ETag (Section 6.2).

   *  Servers MUST NOT include per-request randomness (e.g., varying
      timestamps) in the TCT JSON representation.

1.6.  Deterministic JSON and Strong ETags






Jurkovikj                  Expires 18 May 2026                 [Page 12]

Internet-Draft                     TCT                     November 2025


1.6.1.  Deterministic JSON Serialization

   M-URL responses MUST use deterministic JSON serialization sufficient
   to support strong ETag semantics:

   Implementations SHOULD use the JSON Canonicalization Scheme (JCS)
   defined in [RFC8785].  Implementations that do not use RFC8785 MUST
   define and implement a canonicalization algorithm that:

   *  produces a single, unique octet sequence for each abstract JSON
      value;

   *  applies stable ordering of object members at all levels (for
      example, lexicographic by code point);

   *  uses deterministic formatting of numbers; and

   *  does not introduce insignificant whitespace beyond what is
      necessary to delimit JSON tokens.

   The same canonicalization algorithm MUST be used both when computing
   the ETag and when generating the response body.

1.6.2.  Strong ETag Generation (Single Method)

   TCT defines one mandatory method for computing ETags for M-URLs.

   For an M-URL representation:

   1.  Construct the full JSON object representing the resource,
       including all fields except hash.

   2.  Canonicalize this JSON object to a UTF-8 byte sequence as per
       Section 6.1.

   3.  Compute the SHA-256 digest of these bytes.

   4.  Let $F$ be the 64-character lowercase hex encoding of this
       digest.

   5.  Set:

       *  HTTP ETag header:

          -  "sha256-$F"

       *  JSON hash field:




Jurkovikj                  Expires 18 May 2026                 [Page 13]

Internet-Draft                     TCT                     November 2025


          -  sha256-$F$

   6.  Canonicalize the final JSON object (now including hash) using the
       same algorithm defined in Section 6.1, and send that canonical
       form as the response body.

   Implementations MUST NOT compute the ETag over one serialization of
   the JSON object and send a different, non-canonical serialization on
   the wire.

   Requirements:

   *  ETags for M-URLs:

      -  MUST be strong (no W/ prefix).

      -  MUST be quoted-strings as in [RFC9110].

   *  Two successful M-URL responses with the same strong ETag MUST have
      identical response body bytes.

   *  Any change in the response body bytes MUST cause the strong ETag
      to change.

1.6.3.  Relationship to Template-Invariance

   Strong ETags in TCT are validators for the M-URL JSON representation
   only.

   Template-invariance is achieved structurally:

   *  M-URLs do not include HTML templates or layout.

   *  Changes to C-URL HTML that do not affect the M-URL JSON do not
      affect the strong ETag.

   *  For TCT-conformant M-URLs, strong ETags MUST be representation-
      based and MUST NOT vary per request in the absence of a change to
      the underlying JSON representation.

1.6.4.  Canonical Text Normalization (Optional for Producers)

   TCT does not require clients to normalize text or recompute hashes.

   Use of this normalization algorithm is OPTIONAL and is not required
   for TCT conformance by either servers or clients.  It defines an
   additional 'TCT text normalization' profile for implementations that
   choose to adopt it.



Jurkovikj                  Expires 18 May 2026                 [Page 14]

Internet-Draft                     TCT                     November 2025


   However, producers or validators that derive text fields (such as
   content) from upstream formats MAY implement the normalization
   algorithm defined here to ensure stable input before JSON
   canonicalization.

   If an implementation claims conformance to this normalization, it:

   *  MUST follow the algorithm in this section; and

   *  MUST pass the test vectors in Appendix A.

   Algorithm (summary):

   Given input string S:

   1.  (Optional) HTML entity decoding:

       *  If starting from HTML source, deterministically decode
          character references.

   2.  Unicode normalization:

       *  Apply NFKC as defined in Unicode Standard Annex #15 (UAX15).

   3.  Case folding:

       *  Apply Unicode case folding as defined in Unicode-CaseFolding.

       *  Locale-dependent mappings MUST NOT be used.

   4.  Control characters:

       *  Remove all Cc characters except:

          -  U+0009 (TAB), U+000A (LF), U+000D (CR).

   5.  Whitespace collapsing:

       *  Define set W:

          -  U+0020, U+0009, U+000A, U+000D.

       *  Optionally treat U+00A0 as whitespace, if done consistently.

       *  Replace each maximal run of W (and optional NBSP) with a
          single U+0020 SPACE.

   6.  Trim:



Jurkovikj                  Expires 18 May 2026                 [Page 15]

Internet-Draft                     TCT                     November 2025


       *  Remove leading and trailing SPACE (U+0020).

   The result is the normalized string N(S).

   Details, examples, and conformance language are in Appendix A.

1.7.  M-Sitemap Format and Semantics

1.7.1.  M-Sitemap JSON Structure

   The M-Sitemap is a JSON object that lists TCT-enabled resources.

   Fields:

   *  version (integer, REQUIRED)

      -  M-Sitemap format version.  Initial value: 1.

   *  profile (string, RECOMMENDED)

      -  Profile identifier, e.g., tct-1.

   *  items (array of objects, REQUIRED)

      -  Each item:

         o  cUrl (string, REQUIRED)

            +  Canonical URL.

         o  mUrl (string, REQUIRED)

            +  M-URL of the JSON representation.

         o  etag (string, REQUIRED)

            +  Strong validator identifier, equal to the M-URL ETag
               value without quotes.

            +  MUST be sha256- followed by the 64-hex digest used in
               Section 6.2.

   Example:

   json { "version": 1, "profile": "tct-1", "items": [ { "cUrl":
   "https://example.com/post/", "mUrl": "https://example.com/post/
   llm.json", "etag": "sha256-
   2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7" } ] }



Jurkovikj                  Expires 18 May 2026                 [Page 16]

Internet-Draft                     TCT                     November 2025


1.7.2.  HTTP Response for M-Sitemap

   The M-Sitemap:

   *  MUST use:

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

   *  SHOULD use cache directives that encourage timely revalidation,
      for example:

      -  Cache-Control: max-age=0, must-revalidate, or

      -  a short max-age value appropriate to the site's update
         frequency.

   *  SHOULD include:

      -  Vary: Accept-Encoding

1.7.3.  Parity Semantics

   Design intent:

   *  M-Sitemap etag values SHOULD match the current strong ETag values
      of their corresponding M-URLs.

   Requirements:

   *  Publishers MUST compute etag values using the same algorithm as
      Section 6.2.

   *  Publishers SHOULD keep M-Sitemap etag values in sync with M-URL
      ETags.

   *  Transient mismatches (due to non-atomic updates, caches, or
      propagation delays) MAY occur.

   Client behavior:

   *  Clients SHOULD treat M-Sitemap etag as a hint for change
      detection.

   *  Clients MAY compare etag with the M-URL ETag.

   *  Clients MUST NOT treat mismatches alone as protocol errors.





Jurkovikj                  Expires 18 May 2026                 [Page 17]

Internet-Draft                     TCT                     November 2025


   *  In case of mismatch, clients SHOULD fall back to standard
      conditional requests on the M-URL and treat the M-Sitemap etag as
      an advisory signal only.

   Strong ETag values for M-URLs and etag values in the M-Sitemap are
   scoped to the origin that serves them.  Clients MUST NOT assume that
   identical validator values observed on different origins imply
   identical content.

1.8.  Client Behavior

1.8.1.  Zero-Fetch Optimization

   A typical TCT-aware client:

   1.  Fetches / and discovers the M-Sitemap via Link.

   2.  Fetches the M-Sitemap.

   3.  For each item (cUrl, mUrl, etag):

       *  If it has a cached ETag for mUrl:

          -  If cached ETag equals sitemap etag:

             o  MAY skip fetching mUrl (zero-fetch).

          -  Otherwise:

             o  SHOULD issue conditional GET:

                +  GET mUrl

                +  If-None-Match: "sha256-...".

       *  If no cached ETag:

          -  SHOULD fetch mUrl with GET.

          -  MAY include If-None-Match using sitemap etag as hint.

   This enables large reductions in redundant fetches.

   This optimization is OPTIONAL.  Clients that prefer strict HTTP cache
   validation MAY always perform a conditional GET with If-None-Match on
   M-URLs instead of relying solely on M-Sitemap etag hints.





Jurkovikj                  Expires 18 May 2026                 [Page 18]

Internet-Draft                     TCT                     November 2025


1.8.2.  Conditional Requests to M-URLs

   M-URLs implementing TCT:

   *  MUST support If-None-Match as defined in [RFC9110].

   Specifically:

   *  If If-None-Match matches the current strong ETag:

      -  Respond with 304 Not Modified, no body.

   *  Otherwise:

      -  Respond with 200 OK and the JSON representation.

   If both If-None-Match and If-Modified-Since are present:

   *  If-None-Match MUST take precedence (per [RFC9110]).

   Servers SHOULD send appropriate Cache-Control directives to encourage
   revalidation and safe caching.

1.8.3.  Use of HEAD (Optional)

   Clients MAY use HEAD on M-URLs as an optimization:

   *  If a HEAD response includes an ETag equal to the cached one, a GET
      may be skipped.

   *  If HEAD is unreliable, clients SHOULD fall back to conditional
      GET.

   Conditional GET with If-None-Match SHOULD be considered the primary
   mechanism.

1.8.4.  Client Validation (Optional)

   For protocol correctness:

   *  Clients are not required to implement the text normalization
      algorithm or to recompute validators.

   *  Clients MAY treat ETags and sitemap etag values as opaque.

   Clients MAY perform additional checks as desired, such as:





Jurkovikj                  Expires 18 May 2026                 [Page 19]

Internet-Draft                     TCT                     November 2025


   *  verifying that an M-URL includes rel="canonical" pointing at the
      expected C-URL;

   *  checking M-Sitemap etag vs M-URL ETag parity;

   *  recomputing hashes using the published algorithms.

   Such additional checks are implementation choices and are out of
   scope for TCT compliance.

1.9.  Operational Considerations (Informative)

1.9.1.  Deployment with CDNs and Proxies

   *  M-URLs and M-Sitemaps are ordinary cacheable JSON resources.

   *  CDNs and reverse proxies:

      -  MAY cache them;

      -  SHOULD honor strong ETags and 304 responses.

   *  Since ETags are based on uncompressed canonical JSON:

      -  Downstream compression does not invalidate validators.

1.9.2.  Large Sites and Sharding

   For very large sites:

   *  Operators MAY create multiple M-Sitemaps (e.g., per section or
      date).

   *  A primary M-Sitemap can list additional ones by convention.

   *  This document does not standardize a JSON sitemap index; such work
      may be done separately.

   A future revision of this specification or a separate document MAY
   define a JSON M-Sitemap index format, analogous to the XML Sitemap
   Index, to provide interoperable conventions for sharding and large-
   site discovery.

1.9.3.  Error Handling

   Recommended behavior:

   *  If the M-Sitemap is unavailable or invalid:



Jurkovikj                  Expires 18 May 2026                 [Page 20]

Internet-Draft                     TCT                     November 2025


      -  Treat TCT as temporarily unavailable.

   *  If an M-URL returns 4xx/5xx:

      -  Follow normal HTTP semantics for retries/backoff.

   *  If the M-URL is persistently broken:

      -  Clients MAY ignore it and rely on the C-URL HTML, if
         appropriate.

1.9.4.  Backwards Compatibility

   *  TCT is purely additive:

      -  It does not alter C-URL semantics.

      -  Non-participating clients see no change.

   *  Operators can deploy TCT incrementally on selected resources.

1.10.  Security Considerations

   TCT builds directly on HTTP; most security considerations are
   inherited from [RFC9110] and [RFC9111].

   Key points:

   *  HTTPS:

      -  Publishers SHOULD serve M-URLs and M-Sitemaps over HTTPS.

      -  Clients SHOULD validate TLS as usual.

   *  Integrity:

      -  Strong ETags identify specific representations but do not
         authenticate servers.

      -  For stronger guarantees, publishers MAY use:

         o  Content-Digest headers ([RFC9530]); and/or

         o  HTTP Message Signatures ([RFC9421]).

   *  Access control:





Jurkovikj                  Expires 18 May 2026                 [Page 21]

Internet-Draft                     TCT                     November 2025


      -  If a C-URL requires authentication, its corresponding M-URL
         SHOULD be similarly protected.

      -  M-Sitemaps MUST NOT leak sensitive M-URLs or validators.

   *  Cache poisoning:

      -  Correct use of ETag and Cache-Control mitigates stale or mixed
         content.

      -  Clients MUST treat JSON as untrusted data and validate/sanitize
         as appropriate.

   *  Privacy:

      -  As with any sitemap, listing URLs in an M-Sitemap can reveal
         site structure.

      -  Publishers concerned about this SHOULD limit entries or
         restrict access.

   *  Origin trust:

      -  Clients that consume M-Sitemaps and M-URLs inherently trust the
         origin in the same way they trust HTML pages or XML Sitemaps
         from that origin.  A compromised or misconfigured origin can
         advertise incorrect mappings; this is not a new class of attack
         introduced by TCT.

   *  Intermediaries:

      -  Deployments SHOULD ensure that CDNs and other intermediaries do
         not strip or rewrite strong ETags on M-URLs or M-Sitemaps, as
         doing so can interfere with correct validation and zero-fetch
         behavior.

1.11.  IANA Considerations

   This document has no IANA actions.

   A future revision or separate document MAY define and register:

   *  a well-known URI for TCT M-Sitemaps; and/or

   *  a dedicated media type or profile parameter for TCT JSON.

   Such registrations are intentionally out of scope for this version.




Jurkovikj                  Expires 18 May 2026                 [Page 22]

Internet-Draft                     TCT                     November 2025


2.  References

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

   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON
              Canonicalization Scheme (JCS)", RFC 8785,
              DOI 10.17487/RFC8785, June 2020,
              <https://www.rfc-editor.org/info/rfc8785>.

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

2.2.  Informative References

   [RFC6596]  Ohye, M. and J. Kupke, "The Canonical Link Relation",
              RFC 6596, DOI 10.17487/RFC6596, April 2012,
              <https://www.rfc-editor.org/info/rfc6596>.

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

   [RFC9530]  Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
              DOI 10.17487/RFC9530, February 2024,
              <https://www.rfc-editor.org/info/rfc9530>.





Jurkovikj                  Expires 18 May 2026                 [Page 23]

Internet-Draft                     TCT                     November 2025


Appendix A.  Appendix A.  Normalization Test Vectors

   This appendix provides test vectors for implementations that claim
   conformance to the normalization algorithm (Section 6.4).

   *Conformance Requirement:* Implementations claiming normalization
   support MUST produce the outputs specified below for all test inputs.

   *Test Format:* Each test shows: - Input string - Output after each
   normalization step - Final SHA-256 hash (computed over UTF-8 bytes of
   final output)

A.1.  A.1.  Basic ASCII

   *Test 1: Simple ASCII text* - Input: "Hello World" - After step 1
   (HTML decode): "Hello World" - After step 2 (NFKC): "Hello World" -
   After step 3 (casefold): "hello world" - After step 4 (control
   chars): "hello world" - After step 5 (whitespace): "hello world" -
   After step 6 (trim): "hello world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

   *Test 2: Leading/trailing whitespace* - Input: " Hello World " -
   After step 1: " Hello World " - After step 2: " Hello World " - After
   step 3: " hello world " - After step 4: " hello world " - After step
   5: " hello world " - After step 6: "hello world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

   *Test 3: Multiple spaces* - Input: "Hello World" - After step 1:
   "Hello World" - After step 2: "Hello World" - After step 3: "hello
   world" - After step 4: "hello world" - After step 5: "hello world" -
   After step 6: "hello world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

A.1.1.  A.2.  HTML Entities

   *Test 4: Common HTML entities* - Input: "Hello &amp; goodbye" - After
   step 1: "Hello & goodbye" - After step 2: "Hello & goodbye" - After
   step 3: "hello & goodbye" - After step 4: "hello & goodbye" - After
   step 5: "hello & goodbye" - After step 6: "hello & goodbye" - SHA-
   256: da73536eaa9c427f3189de5b6371d798193e98f3c31df8bef710bba835e8c621

   *Test 5: Angle brackets* - Input: "&lt;tag&gt;" - After step 1:
   "<tag>" - After step 2: "<tag>" - After step 3: "<tag>" - After step
   4: "<tag>" - After step 5: "<tag>" - After step 6: "<tag>" - SHA-256:
   c81ef880af0fcfef49e1b45c3690a1666c47d9e064b7eaead2af09bb78884dcd






Jurkovikj                  Expires 18 May 2026                 [Page 24]

Internet-Draft                     TCT                     November 2025


   *Test 6: Quotes* - Input: "&quot;quoted&quot;" - After step 1:
   "\"quoted\"" - After step 2: "\"quoted\"" - After step 3:
   "\"quoted\"" - After step 4: "\"quoted\"" - After step 5:
   "\"quoted\"" - After step 6: "\"quoted\"" - SHA-256:
   272fca25899893eeb27b89583d5c81b8a4ac5af4d1e37e3909d879947303c1c5

A.1.2.  A.3.  Unicode Normalization (NFKC)

   *Test 7: Composed vs decomposed é* - Input (composed): "Café"
   (U+00E9) - After step 1: "Café" - After step 2 (NFKC): "Café"
   (normalized to composed form) - After step 3: "café" - After step 4:
   "café" - After step 5: "café" - After step 6: "café" - SHA-256:
   850f7dc43910ff890f8879c0ed26fe697c93a067ad93a7d50f466a7028a9bf4e

   *Test 7b: Decomposed form (should produce same result)* - Input
   (decomposed): "Cafe\u0301" (e + combining acute) - After step 2
   (NFKC): "Café" (normalized to composed) - Final result: Same as Test
   7 - SHA-256:
   850f7dc43910ff890f8879c0ed26fe697c93a067ad93a7d50f466a7028a9bf4e
   (same as Test 7)

   *Test 8: Full-width characters* - Input: "ＨＥＬＬＯ" (full-width Latin) -
   After step 1: "ＨＥＬＬＯ" - After step 2 (NFKC): "HELLO" (converted to
   half-width) - After step 3: "hello" - After step 4: "hello" - After
   step 5: "hello" - After step 6: "hello" - SHA-256:
   2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

A.1.3.  A.4.  Case Folding Edge Cases

   *Test 9: German sharp S* - Input: "Straße" - After step 1: "Straße" -
   After step 2: "Straße" - After step 3 (casefold): "strasse" (ß -> ss)
   - After step 4: "strasse" - After step 5: "strasse" - After step 6:
   "strasse" - SHA-256:
   16d96952087774fee069b7585d3991b24d90c181c09b2129b4908c35baa7f0c0

   *Test 10: Turkish İ (dotted capital I)* - Input: "İstanbul" - After
   step 1: "İstanbul" - After step 2: "İstanbul" - After step 3
   (casefold): "i\u0307stanbul" (locale-independent) - After step 4:
   "i\u0307stanbul" - After step 5: "i\u0307stanbul" - After step 6:
   "i\u0307stanbul" - SHA-256:
   4a4df120f7d1f3c286f58651abfcec2aade892ace635f96f02b946c96e6e1f86










Jurkovikj                  Expires 18 May 2026                 [Page 25]

Internet-Draft                     TCT                     November 2025


A.1.4.  A.5.  Control Characters

   *Test 11: Embedded tab* - Input: "Hello\tWorld" - After step 1:
   "Hello\tWorld" - After step 2: "Hello\tWorld" - After step 3:
   "hello\tworld" - After step 4: "hello\tworld" (tab preserved) - After
   step 5: "hello world" (tab -> space) - After step 6: "hello world" -
   SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

   *Test 12: Embedded newline* - Input: "Hello\nWorld" - After step 1:
   "Hello\nWorld" - After step 2: "Hello\nWorld" - After step 3:
   "hello\nworld" - After step 4: "hello\nworld" (newline preserved) -
   After step 5: "hello world" (newline -> space) - After step 6: "hello
   world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

   *Test 13: Control character (BEL)* - Input: "Hello\u0007World"
   (U+0007 = BEL) - After step 1: "Hello\u0007World" - After step 2:
   "Hello\u0007World" - After step 3: "hello\u0007world" - After step 4:
   "helloworld" (control char removed) - After step 5: "helloworld" -
   After step 6: "helloworld" - SHA-256:
   936a185caaa266bb9cbe981e9e05cb78cd732b0b3280eb944412bb6f8f8f07af

A.1.5.  A.6.  Whitespace Edge Cases

   *Test 14: Non-breaking space (NBSP)* - Input: "Hello\u00A0World"
   (U+00A0 = NBSP) - After step 1: "Hello\u00A0World" - After step 2:
   "Hello\u00A0World" - After step 3: "hello\u00A0world" - After step 4:
   "hello\u00A0world" - After step 5: "hello world" (NBSP -> space, if
   treating NBSP as whitespace) - After step 6: "hello world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

   *Note:* Step 5 behavior for NBSP is implementation-defined per
   Section 6.4 ("Optionally treat U+00A0 as whitespace, if done
   consistently").  This test assumes NBSP is treated as whitespace.

   *Test 15: Mixed whitespace* - Input: "Hello \t\n World" - After step
   1: "Hello \t\n World" - After step 2: "Hello \t\n World" - After step
   3: "hello \t\n world" - After step 4: "hello \t\n world" - After step
   5: "hello world" - After step 6: "hello world" - SHA-256:
   b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

A.1.6.  A.7.  Empty and Edge Cases

   *Test 16: Empty string* - Input: "" - After all steps: "" - SHA-256:
   e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855





Jurkovikj                  Expires 18 May 2026                 [Page 26]

Internet-Draft                     TCT                     November 2025


   *Test 17: Whitespace only* - Input: " " - After step 1: " " - After
   step 2: " " - After step 3: " " - After step 4: " " - After step 5: "
   " - After step 6: "" (trimmed) - SHA-256:
   e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

   *Test 18: Single character* - Input: "A" - After step 1: "A" - After
   step 2: "A" - After step 3: "a" - After step 4: "a" - After step 5:
   "a" - After step 6: "a" - SHA-256:
   ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb

A.1.7.  A.8.  Complex Real-World Examples

   *Test 19: Article excerpt* - Input: "The café's "special" offer: 50%
   off!" - Expected output after normalization: the café's "special"
   offer: 50% off! - SHA-256:
   25cdbe2315674d38ddaf1df6fe7ccd494ce89efebe8a3b5285742e57e7367545

   *Test 20: Unicode mixed with entities* - Input: "Cliché &amp; résumé"
   - Expected output after normalization: cliché & résumé - SHA-256:
   7d56f360edd22f7be0bc0f126d45481df83e8afc68b83788cf37544c4ee6ce21

A.1.8.  A.9.  Implementation Notes

   *Computing SHA-256:* - Encode the final normalized string as UTF-8
   bytes - Compute SHA-256 over those bytes - Express result as 64
   lowercase hex characters

   *Test Vector Validation:* - Implementations claiming normalization
   support MUST produce the SHA-256 hashes specified above - The seven
   "hello world" variants (Tests 1, 2, 3, 11, 12, 14, 15) all normalize
   to identical output ("hello world"), demonstrating whitespace
   normalization equivalence - Tests 7 and 7b demonstrate NFKC combining
   character handling (both produce identical hashes)

A.2.  Appendix B.  Example Flows (Informative)

   This appendix illustrates TCT discovery and fetch patterns.

A.2.1.  B.1.  Initial Discovery and First Fetch

   *Scenario:* Client visits origin for the first time.

   ``` 1.  Client -> Server: GET / HTTP/1.1 Host: example.com

   1.  Server -> Client: HTTP/1.1 200 OK Link: </llm-pages.json>;
       rel="index"; type="application/json" Content-Type: text/html

                    [HTML body...]



Jurkovikj                  Expires 18 May 2026                 [Page 27]

Internet-Draft                     TCT                     November 2025


   2.  Client -> Server: GET /llm-pages.json HTTP/1.1 Host: example.com

   3.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
       charset=utf-8 Cache-Control: max-age=0, must-revalidate

                   {
                     "version": 1,
                     "profile": "tct-1",
                     "items": [
                       {
                         "cUrl": "https://example.com/article/",
                         "mUrl": "https://example.com/article/llm.json",
                         "etag": "sha256-abc123..."
                       }
                     ]
                   }

   4.  Client -> Server: GET /article/llm.json HTTP/1.1 Host:
       example.com

   5.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
       charset=utf-8 ETag: "sha256-abc123..." Link: https://example.com/
       article/ (https://example.com/article/); rel="canonical"

                    {
                      "profile": "tct-1",
                      "canonical_url": "https://example.com/article/",
                      "title": "Article Title",
                      "content": "Article content...",
                      "hash": "sha256-abc123..."
                    } ```

   *Client actions after step 6:* - Stores M-URL content locally -
   Caches ETag "sha256-abc123..." for future revalidation

A.2.2.  B.2.  Zero-Fetch Optimization (Content Unchanged)

   *Scenario:* Client returns after some time; content hasn't changed.

   ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1 Host:
   example.com

   1.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
       charset=utf-8







Jurkovikj                  Expires 18 May 2026                 [Page 28]

Internet-Draft                     TCT                     November 2025


                   {
                     "version": 1,
                     "items": [
                       {
                         "cUrl": "https://example.com/article/",
                         "mUrl": "https://example.com/article/llm.json",
                         "etag": "sha256-abc123..."
                       }
                     ]
                   }

   2.  Client local comparison:

       *  Sitemap etag: "sha256-abc123..."

       *  Cached ETag: "sha256-abc123..."

       *  Match! -> Skip fetch entirely (zero-fetch)

   3.  Client uses locally cached content for /article/ ```

   *Result:* Zero bytes transferred for M-URL; content known to be
   current.

A.2.3.  B.3.  Conditional Request (Content Unchanged)

   *Scenario:* Sitemap etag differs from cache, but actual content
   hasn't changed.

   ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

   1.  Server -> Client: [Sitemap shows etag: "sha256-def456..."]

   2.  Client comparison:

       *  Sitemap etag: "sha256-def456..." (different!)

       *  Cached ETag: "sha256-abc123..."

       *  Mismatch -> Must fetch, but use conditional request

   3.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
       "sha256-abc123..."

   4.  Server -> Client: HTTP/1.1 304 Not Modified ETag:
       "sha256-abc123..."

   5.  Client actions:



Jurkovikj                  Expires 18 May 2026                 [Page 29]

Internet-Draft                     TCT                     November 2025


       *  Content unchanged; uses cached copy

       *  Notes: sitemap was stale/inconsistent; no protocol violation
          ```

   *Result:* Small 304 response instead of full payload.

A.2.4.  B.4.  Content Changed

   *Scenario:* Content has been updated.

   ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

   1.  Server -> Client: [Sitemap shows etag: "sha256-xyz789..."]

   2.  Client comparison:

       *  Sitemap etag: "sha256-xyz789..." (different)

       *  Cached ETag: "sha256-abc123..."

       *  Mismatch -> Fetch with If-None-Match

   3.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
       "sha256-abc123..."

   4.  Server -> Client: HTTP/1.1 200 OK Content-Type: application/json;
       charset=utf-8 ETag: "sha256-xyz789..."

                    {
                      "canonical_url": "https://example.com/article/",
                      "title": "Updated Title",
                      "content": "Updated content...",
                      "hash": "sha256-xyz789..."
                    }

   5.  Client actions:

       *  Replaces cached content

       *  Updates cached ETag to "sha256-xyz789..." ```

   *Result:* Full new representation received.

A.2.5.  B.5.  Parity Mismatch Handling

   *Scenario:* Sitemap etag doesn't match actual M-URL ETag (transient
   inconsistency).



Jurkovikj                  Expires 18 May 2026                 [Page 30]

Internet-Draft                     TCT                     November 2025


   ``` 1.  Client -> Server: GET /llm-pages.json HTTP/1.1

   1.  Server -> Client: [Sitemap shows etag: "sha256-old999..."]

   2.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
       "sha256-old999..."

   3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-new000..." <-
       Different from sitemap!

                    [Full M-URL JSON...]

   4.  Client actions:

       *  Accepts M-URL response (valid per HTTP)

       *  Uses ETag from M-URL response ("sha256-new000...") for future
          revalidation

       *  Notes: sitemap inconsistency tolerated; no error ```

   *Result:* Client falls back to standard HTTP caching; no protocol
   failure.

A.2.6.  B.6.  Using HEAD for Efficient Freshness Check

   *Scenario:* Client wants to check freshness before fetching.

   ``` 1.  Client -> Server: HEAD /article/llm.json HTTP/1.1 If-None-
   Match: "sha256-abc123..."

   1.  Server -> Client: HTTP/1.1 304 Not Modified ETag:
       "sha256-abc123..."

   2.  Client actions:

       *  Content unchanged; uses cached copy

       *  Avoided transferring full body

   OR (if content changed):

   1.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-xyz789..."
       Content-Length: 4567

   2.  Client -> Server: GET /article/llm.json HTTP/1.1 If-None-Match:
       "sha256-abc123..."




Jurkovikj                  Expires 18 May 2026                 [Page 31]

Internet-Draft                     TCT                     November 2025


   3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-xyz789..."

                    [Full M-URL JSON...] ```

   *Note:* HEAD support is optional; conditional GET is the primary
   mechanism.

A.2.7.  B.7.  Discovery via C-URL

   *Scenario:* Client discovers M-URL directly from HTML page.

   ``` 1.  Client -> Server: GET /article/ HTTP/1.1

   1.  Server -> Client: HTTP/1.1 200 OK Link: </article/llm.json>;
       rel="alternate"; type="application/json" Content-Type: text/html

                    <!DOCTYPE html>
                    <html>
                    <head>
                      <link rel="alternate" type="application/json"
                            href="https://example.com/article/llm.json">
                    </head>
                    ...

   2.  Client -> Server: GET /article/llm.json HTTP/1.1

   3.  Server -> Client: HTTP/1.1 200 OK ETag: "sha256-abc123..." Link:
       https://example.com/article/ (https://example.com/article/);
       rel="canonical"

                    [M-URL JSON...]

   4.  Client verifies:

       *  Canonical link points back to /article/ -> Consistent OK ```

   *Result:* M-URL discovered and validated without sitemap.

A.3.  Appendix C.  Implementation Notes (Informative)

   This appendix provides guidance for implementers.

A.3.1.  C.1.  Reference Implementations

   *Note:* The following implementations are provided as informative
   examples.  Repository URLs, package names, and deployment details may
   change over time and are not normative.




Jurkovikj                  Expires 18 May 2026                 [Page 32]

Internet-Draft                     TCT                     November 2025


   The following implementations demonstrate TCT in production
   environments:

   *WordPress Plugin (PHP):* - Repository: https://github.com/
   antunjurkovic-collab/tct-wp-plugin - Version: 1.0.0 - Deployment: 3
   production sites (970 URLs total) - Features: - Automatic M-URL
   generation for posts/pages - M-Sitemap generation and caching -
   Strong ETag computation using canonical JSON - Normalization
   algorithm implementation - Dependencies: WordPress 6.0+, PHP 7.4+ -
   JSON serialization: json_encode() with JSON_UNESCAPED_SLASHES |
   JSON_UNESCAPED_UNICODE

   *Python Validator:* - PyPI package: collab-tunnel
   (https://pypi.org/project/collab-tunnel/1.0.2/) - Version: 1.0.2 -
   Purpose: Protocol compliance testing - Features: - Validates M-URL
   and M-Sitemap structure - Tests ETag parity - Verifies canonical link
   bidirectionality - Runs normalization test vectors - Usage: python
   from collab_tunnel import validate_origin results =
   validate_origin("https://example.com")

   *Cloudflare Worker (Edge Proxy):* - Repository: https://github.com/
   antunjurkovic-collab/tct-worker - Purpose: Demonstrates CDN
   integration - Features: - Proxies M-URLs with proper ETag handling -
   Implements 304 Not Modified caching - Handles conditional requests
   correctly - Deployment: Cloudflare Workers platform

A.3.2.  C.2.  Deterministic JSON Libraries

   For RFC 8785 (JSON Canonicalization Scheme) compliance:

   *Python:* python import canonicaljson canonical_bytes =
   canonicaljson.encode_canonical_json(obj) - Library: pip install
   canonicaljson - Docs: https://github.com/matrix-org/python-
   canonicaljson

   *JavaScript:* javascript const canonicalize =
   require('canonicalize'); const canonical_string = canonicalize(obj);
   - Library: npm install canonicalize - Docs:
   https://github.com/cyberphone/json-canonicalization

   *Go:* go import "github.com/cyberphone/json-canonicalization/go/json"
   canonical, _ := json.CanonicalizeJSON(input)

   *Alternative (Stable Ordering):* If not using RFC 8785, ensure: -
   Object keys sorted lexicographically (at ALL nesting levels) - No
   insignificant whitespace - Consistent number formatting - UTF-8
   encoding without BOM




Jurkovikj                  Expires 18 May 2026                 [Page 33]

Internet-Draft                     TCT                     November 2025


   *Important:* Simple key-sorting helpers (e.g.,
   Object.keys(obj).sort() in JavaScript) are *insufficient* for nested
   objects.  For production implementations claiming TCT conformance,
   use RFC 8785 libraries or implement the full specification.  The code
   examples in C.3 are *illustrative only* and may not handle all edge
   cases correctly.

A.3.3.  C.3.  SHA-256 Computation

   The examples in this section are illustrative only.  By themselves
   they do not guarantee the deterministic JSON requirements of
   Section 6.1 unless combined with a complete canonicalization
   algorithm such as RFC8785.

   *Note:* The examples below are simplified for illustration.  For
   production use, ensure proper RFC 8785 canonicalization (see C.2)
   before hashing.

   *Python:* ```python import hashlib import json

Appendix B.  Canonical JSON

   canonical_json = json.dumps(obj, ensure_ascii=False, sort_keys=True,
   separators=(',', ':')) canonical_bytes = canonical_json.encode('utf-
   8')

Appendix C.  Hash

   sha256_hash = hashlib.sha256(canonical_bytes).hexdigest() etag_value
   = f'"sha256-{sha256_hash}"' ```

   *JavaScript:* ```javascript const crypto = require('crypto');

   // Canonical JSON // NOTE: This is illustrative only; for full
   conformance, use RFC 8785 or a complete canonicalization
   implementation. const canonical_json = JSON.stringify(obj,
   Object.keys(obj).sort()); const canonical_bytes =
   Buffer.from(canonical_json, 'utf-8');

   // Hash const sha256_hash =
   crypto.createHash('sha256').update(canonical_bytes).digest('hex');
   const etag_value = "sha256-${sha256_hash}"; ```

   *PHP:* ```php // Canonical JSON $canonical_json = json_encode($obj,
   JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

   // Hash $sha256_hash = hash('sha256', $canonical_json); $etag_value =
   '"sha256-' . $sha256_hash . '"'; ```



Jurkovikj                  Expires 18 May 2026                 [Page 34]

Internet-Draft                     TCT                     November 2025


C.1.  C.4.  Unicode Normalization

   *Python:* ```python import unicodedata

Appendix D.  NFKC normalization

   normalized = unicodedata.normalize('NFKC', text)

Appendix E.  Case folding

   casefolded = normalized.casefold() ```

   *JavaScript:* ```javascript // NFKC normalization const normalized =
   text.normalize('NFKC');

   // Case folding (approximation: toLowerCase with locale-independent
   behavior) const casefolded = normalized.toLocaleLowerCase('en-US');
   ```

   *PHP:* ```php // NFKC normalization (requires intl extension)
   $normalized = Normalizer::normalize($text, Normalizer::NFKC);

   // Case folding (mb_strtolower with UTF-8) $casefolded =
   mb_strtolower($normalized, 'UTF-8'); ```

E.1.  C.5.  HTTP Response Headers

   *Typical headers for M-URLs:*

   A conformant M-URL response will include at least: Content-Type:
   application/json, ETag (strong, quoted), and Link: rel="canonical"
   (see Sections 5-6).  Example:

   HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 ETag:
   "sha256-abc123..." Link: <https://example.com/article/>;
   rel="canonical" Cache-Control: public, max-age=3600, must-revalidate
   Vary: Accept-Encoding

   *Typical headers for M-Sitemap:* HTTP/1.1 200 OK Content-Type:
   application/json; charset=utf-8 Cache-Control: max-age=0, must-
   revalidate # Example; a short max-age consistent with Section 7.2 MAY
   also be used Vary: Accept-Encoding

   *Conditional request handling:* ``` # Request with If-None-Match GET
   /article/llm.json HTTP/1.1 If-None-Match: "sha256-abc123..."






Jurkovikj                  Expires 18 May 2026                 [Page 35]

Internet-Draft                     TCT                     November 2025


Appendix F.  Response if unchanged

   HTTP/1.1 304 Not Modified ETag: "sha256-abc123..." Cache-Control:
   public, max-age=3600, must-revalidate

Appendix G.  Response if changed

   HTTP/1.1 200 OK ETag: "sha256-xyz789..." Content-Type: application/
   json; charset=utf-8 [full body...] ```

G.1.  C.6.  Production Deployment Data

   *Note:* The following deployment data represents a snapshot as of
   November 2025.  Specific sites, URLs, and metrics are provided as
   informative examples and may change.

   As of November 2025, TCT is deployed on:

   *bestdemotivationalposters.com:* - 500 URLs - 100K+ pageviews/month -
   WordPress 6.4 + TCT plugin v1.0.0 - Average HTML size: 103 KB
   (gzipped) - Average M-URL size: 17.7 KB (gzipped) - Bandwidth
   reduction: 83%

   *wellbeing-support.com:* - 400 URLs - Health/wellness content -
   Average zero-fetch rate: 85%

   *omacedonii.com:* - 70 URLs - Multilingual (Polish) - Demonstrates
   Unicode normalization in production

   *Aggregate Results:* - Total URLs: 970 - Bandwidth reduction: 83%
   median - Zero-fetch rate: 70-90% (depends on update frequency) -
   Combined bandwidth elimination: ~98% in steady-state

G.1.1.  C.7.  Common Implementation Pitfalls

   *Pitfall 1: Non-deterministic JSON* - Problem: Random key ordering,
   floating-point precision issues, timestamps - Solution: Use RFC 8785
   or strict ordering; exclude per-request randomness

   *Pitfall 2: Weak ETags* - Problem: Using W/"sha256-..." instead of
   "sha256-..." - Solution: Always use strong ETags for M-URLs (no W/
   prefix)

   *Pitfall 3: Sitemap Staleness* - Problem: Sitemap regenerated
   asynchronously; race conditions cause mismatches - Solution: Accept
   transient inconsistency; clients fall back to conditional GET





Jurkovikj                  Expires 18 May 2026                 [Page 36]

Internet-Draft                     TCT                     November 2025


   *Pitfall 4: Incorrect Canonical Links* - Problem: rel="canonical"
   points to wrong URL or is missing - Solution: Validate bidirectional
   linkage (C-URL <-> M-URL)

   *Pitfall 5: HTML in Content Field* - Problem: Including raw HTML tags
   in content field - Solution: Extract plain text or use deterministic
   markup (e.g., Markdown)

   *Pitfall 6: Missing Vary: Accept-Encoding* - Problem: CDN caches
   gzipped and uncompressed versions with same key - Solution: Always
   include Vary: Accept-Encoding header

   *Pitfall 7: Locale-Dependent Case Folding* - Problem: Turkish İ -> i
   vs. I -> ı (locale-specific) - Solution: Use Unicode default case
   folding (locale-independent)

G.1.2.  C.8.  Testing and Validation

   *Automated Testing:* 1.  Protocol compliance: Use collab-tunnel-
   validator PyPI package 2.  Normalization: Run Appendix A test vectors
   3.  ETag parity: Compare sitemap etag vs. actual M-URL ETag 4.
   Conditional requests: Test If-None-Match with matching/non-matching
   ETags

   *Manual Testing:* 1.  Check discovery: curl -I https://example.com/
   (look for Link header) 2.  Fetch sitemap: curl https://example.com/
   llm-pages.json 3.  Validate M-URL: curl -H "Accept: application/json"
   https://example.com/article/llm.json 4.  Test 304: curl -H 'If-None-
   Match: "sha256-..."' https://example.com/article/llm.json

   *Integration Testing:* - Deploy to staging environment - Monitor 304
   response rates (should be >70% after initial crawl) - Check CDN cache
   hit rates - Verify canonical link bidirectionality

G.1.3.  C.9.  Performance Considerations

   *Server-Side:* - Cache normalized content and ETags (don't recompute
   on every request) - Generate M-Sitemap asynchronously during content
   updates - Use HTTP/2 for parallel M-URL fetches - Implement early
   ETag validation (before full response generation)

   *Client-Side:* - Use zero-fetch optimization when possible (sitemap
   comparison) - Batch M-Sitemap fetches (don't fetch per-URL) -
   Implement exponential backoff for 429/503 responses - Cache M-URLs
   and ETags persistently






Jurkovikj                  Expires 18 May 2026                 [Page 37]

Internet-Draft                     TCT                     November 2025


   *CDN/Proxy:* - Configure strong ETag preservation - Enable
   compression (gzip/brotli) with Vary: Accept-Encoding - Cache 304
   responses appropriately - Don't strip ETag headers

G.1.4.  C.10.  Security Best Practices

   *HTTPS:* - It is RECOMMENDED to serve M-URLs and M-Sitemap over HTTPS
   (see Section 10) - Validate TLS certificates properly - Use HSTS
   where appropriate

   *Access Control:* - If C-URL requires authentication, protect M-URL
   similarly - Don't leak sensitive URLs in public sitemaps - Implement
   rate limiting to prevent abuse

   *Content Validation:* - Treat M-URL JSON as untrusted input -
   Validate/sanitize before use - Don't execute code from content field

   *ETag Integrity:* - Use Content-Digest (RFC 9530) for additional
   integrity - Consider HTTP Message Signatures (RFC 9421) for
   authentication - Monitor for ETag collision attempts (though SHA-256
   makes this infeasible)

Appendix H.  Acknowledgments

   Thanks to reviewers and implementers who provided feedback on earlier
   revisions, including those who highlighted:

   *  the need for a single strong ETag method;

   *  the importance of deterministic JSON;

   *  the separation of protocol from policy; and

   *  simplification of discovery and parity semantics.

Author's Address

   Antun Jurkovikj
   North Macedonia
   Email: antunjurkovic@gmail.com











Jurkovikj                  Expires 18 May 2026                 [Page 38]


name: draft-meyerzuselha-oauth-web-message-response-mode
rev: 01
title: OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows
time: 2025-11-05T16:36:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-09T16:36:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:06.864803+00:00
abstract:
This specification defines the web message response mode that
   authorization servers use for transmitting authorization response
   parameters via the user-agent's postMessage API to the client.  This
   mode is intended for authorization flows that use secondary windows,
   which are well-suited for browser-based applications.

full_text:
Web Authorization Protocol                         K. Meyer zu Selhausen
Internet-Draft                                                 Hackmanit
Intended status: Standards Track                              L. Jannett
Expires: 9 May 2026                               Ruhr University Bochum
                                                               C. Mainka
                                                               Hackmanit
                                                         5 November 2025


    OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based
                          Authorization Flows
         draft-meyerzuselha-oauth-web-message-response-mode-01

Abstract

   This specification defines the web message response mode that
   authorization servers use for transmitting authorization response
   parameters via the user-agent's postMessage API to the client.  This
   mode is intended for authorization flows that use secondary windows,
   which are well-suited for browser-based applications.

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 9 May 2026.

Copyright Notice

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

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



Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 1]

Internet-Draft       oauth-web-message-response-mode       November 2025


   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Conventions and Terminology . . . . . . . . . . . . . . .   3
   2.  Web Message Response Mode . . . . . . . . . . . . . . . . . .   4
     2.1.  Dynamic Discovery of Primary Window Reference . . . . . .   5
   3.  Popup-Based Authorization Flow Using the Web Message Response
           Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Iframe-Based Authorization Flow Using the Web Message Response
           Mode  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Clickjacking Mitigations in Iframes . . . . . . . . . . .   8
     4.2.  User-Session in Iframes . . . . . . . . . . . . . . . . .   9
   5.  Authorization Server Metadata . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     6.1.  Receiver Origin Validation  . . . . . . . . . . . . . . .   9
     6.2.  Initiator Origin Validation and Cross-Site Request Forgery
           Protection  . . . . . . . . . . . . . . . . . . . . . . .   9
     6.3.  Data Validation . . . . . . . . . . . . . . . . . . . . .  10
     6.4.  Cross-Site Leak Protections on the Authorization
           Server  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     6.5.  Redirection URI vs. Receiver Origin . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  11
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Appendix B.  Document History . . . . . . . . . . . . . . . . . .  13
   Appendix C.  Example Implementations  . . . . . . . . . . . . . .  13
   Appendix D.  Differences to I-D.sakimura-oauth-wmrm . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   OAuth [RFC6749] uses HTTP redirects to transfer authorization
   response parameters from the authorization server via the user-agent
   to the client's redirection endpoint.  In this case, the
   authorization response parameters are encoded in the query string
   (response_mode=query) or in the fragment (response_mode=fragment) of
   the redirect_uri [oauth.encoding] (Section 2.1).  [RFC6749]
   (Section 1.7) allows other mechanisms available via the user-agent to
   accomplish this redirection, such as response_mode=form_post
   [oauth.post].






Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 2]

Internet-Draft       oauth-web-message-response-mode       November 2025


   The standardized query, fragment, and form post response modes are
   designed for single-window authorization but not for multi-window
   authorization flows.  A common example is a popup-based authorization
   flow, where the client's primary window opens the authorization
   server in a secondary window.  The secondary window cannot use HTTP
   redirects to transfer response parameters back to the client in the
   primary window.

   This specification defines the web message response mode that uses
   the user-agent's postMessage API [whatwg.postmessage] to exchange
   messages between two different browser windows.  Clients inform the
   authorization server to use this response mode for returning the
   authorization response by setting the response_mode parameter in the
   authorization request to web_message.  This response mode facilitates
   popup-based and iframe-based authorization flows, in which the
   authorization server is called in a secondary window or embedded in a
   frame on the client.

   These flows that span the authorization process across two windows
   are especially useful for browser-based applications, where the main
   application window should remain uninterrupted to preserve the user
   experience.  Executing authorization flows in invisible iframes can
   also enable seamless session resumption and renewal without
   disrupting the user.

1.1.  Conventions and Terminology

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

   This specification uses the terms "client", "user-agent",
   "authorization server", "authorization endpoint", "redirection
   endpoint", "redirection URI", "authorization request", and
   "authorization response" defined by the OAuth 2.0 Authorization
   Framework [RFC6749].  It further uses the term "response mode"
   defined by the OAuth 2.0 Multiple Response Type Encoding Practices
   [oauth.encoding].

   This specification defines the following additional terminology.

   primary window  This is the top-level browsing window that initially
      holds the client's website.  This window has no parent windows and
      it was not opened by any other window.
   secondary window  This is the window in which the client in the
      primary window opens the authorization server.



Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 3]

Internet-Draft       oauth-web-message-response-mode       November 2025


2.  Web Message Response Mode

   This specification defines the web message response mode, which is
   described with the following response_mode parameter value in the
   authorization request [oauth.encoding].

   web_message  In the web message response mode, the authorization
      server in the secondary window encodes the authorization response
      parameters in a JSON dictionary and transmits it via the user-
      agent's postMessage API to the client in the primary window.

   If the authorization request includes the value web_message for the
   response_mode parameter, the authorization server:

   *  MUST dynamically discover the client's primary window reference as
      described in Section 2.1.
   *  MUST use the user-agent's postMessage API to return the
      authorization response to the client's primary window.
   *  MUST encode the response paramters as key-value string pairs in a
      JSON dictionary.
   *  MUST follow [RFC6749] and [RFC9700] when validating the
      redirection URI.
   *  MUST use the full redirection URI (the exact same URI also used in
      other response modes such as query, fragment, or form post) as the
      postMessage's receiver origin.  The user-agent's postMessage API
      inherently parses the redirection URI and extracts its origin.
   *  MUST NOT parse the URI itself to reduce the attack surface
      concerning parsing issues.

   The client's redirection URI MUST serve as the postMessage's receiver
   origin to protect the authorization response from being leaked to
   malicious origins.

   This example illustrates how an authorization server (identified by
   the issuer https://as.example) in a secondary window returns the
   authorization response to the client (whose registered redirection
   URI is https://client.example/cb) in the primary window using the
   postMessage API:

   const primaryWindowRef = window.opener // for popup-based flow
   const primaryWindowRef = window.parent // for iframe-based flow
   const params = {
     "code": "XXXXXXXX",
     "state":"XXXXXXXX",
     "iss": "https://as.example"
   }
   primaryWindowRef.postMessage(params, "https://client.example/cb")




Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 4]

Internet-Draft       oauth-web-message-response-mode       November 2025


   The client MAY signal its preferred primary window reference by using
   the response_mode parameter.  For popup-based authorization flows, it
   MAY set the value to web_message.opener, and for iframe-based
   authorization flows, it MAY set the value to web_message.parent.
   When either web_message.opener or web_message.parent is specified,
   the authorization server MUST use the corresponding window reference
   window.opener or window.parent and MUST NOT attempt to dynamically
   determine the primary window reference as specified in Section 2.1.

2.1.  Dynamic Discovery of Primary Window Reference

   If the authorization request specifies web_message as the
   response_mode, the authorization server running in the secondary
   window MUST dynamically determine the client's primary window
   reference.  This is done by checking whether the window.opener or
   window.parent references point to a valid primary window.  If both
   references are available, the window.opener reference MUST take
   precedence to ensure that popup-based authorization flows are
   prioritized over iframe-based flows.

   The following example illustrates how an authorization server may
   perform this discovery process:

   let primaryWindowRef = undefined
   if (window.opener !== null) // this is a popup-based flow
     primaryWindowRef = window.opener
   else if (window.parent !== self) // this is an iframe-based flow
     primaryWindowRef = window.parent
   else // abort flow: could not discover primary window reference

3.  Popup-Based Authorization Flow Using the Web Message Response Mode

   In a popup-based authorization flow, the client opens the
   authorization endpoint in a secondary window.  The authorization
   server uses the user-agent's postMessage API to return the
   authorization response parameters from the secondary window back to
   the client running in the primary window.  The flow is depicted in
   Figure 1 and described in the following.













Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 5]

Internet-Draft       oauth-web-message-response-mode       November 2025


   +------------------------------+
   |        Primary Window        |
   |    (client.example/login)    |    +-----------------------+
   |                              |    |   Secondary Window    |
   |1) Register message event     |    |  (as.example/authz)   |
   |   handler                    |    |                       |
   |                              |    |3) Authenticate user   |
   |2) Open authz request with    |    |   and authorize       |
   |   web message response mode  |    |   access              |
   |   parameter in popup window  +--->|                       |
   |                              |    |4) Send postMessage    |
   |5) Validate and process authz |<---+   with authz response |
   |   response in event handler  |    |   to opener window    |
   |                              |    |                       |
   +------------------------------+    +-----------------------+

      Figure 1: Overview of a popup-based authorization flow using the
                         web message response mode.

   1.  The client registers a message event handler that receives the
       authorization response from the authorization server.  The client
       MUST validate the message's origin with an exact string matching
       the authorization server's origin.  As the authorization response
       is meant for one-time use, the client MUST remove the message
       event handler after receiving the authorization response to
       prevent any further authorization attempts.

   Example of the registration of a message event handler:

   const callback = (e) => {
     if (e.origin === "https://as.example") {
       // further validation and processing of the authorization response
       process(e.data)
       window.removeEventListener("message", callback)
     }
   }
   window.addEventListener("message", callback)

   2.  The client MUST open the authorization request in a secondary
       window.  Therefore, the client MAY use JavaScript and the user-
       agent's window.open API, MAY use an anchor HTML element with a
       target attribute, or MAY use any other mechanism suitable for
       opening secondary windows.  The authorization request MUST
       include the response_mode parameter value web_message or
       web_message.opener.  Additional authorization request parameters
       and techniques, such as PAR [RFC9126] and RAR [RFC9396], are
       unaffected by this specification and MAY be used with the web
       message response mode.



Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 6]

Internet-Draft       oauth-web-message-response-mode       November 2025


   Example of using the window.open API to open the authorization
   request in a secondary window:

   window.open(
     "https://as.example/auth?...&response_mode=web_message",
     "secondaryWindowRef",
     "left=100,top=100,width=320,height=320"
   )

   Example of using an anchor tag with a target attribute to open the
   authorization request in a secondary window:

   <a
     href="https://as.example/auth?...&response_mode=web_message"
     target="secondaryWindowRef"
   >

   3.  The authorization server receives the authorization request,
       validates its parameters, and proceeds with the end-user
       authentication and authorization, which is outside of the scope
       of this specification.

   4.  If the authorization request includes the response_mode parameter
       value web_message or web_message.opener, the authorization server
       MUST follow the web message response mode as described in
       Section 2 and use the user-agent's postMessage API to return the
       authorization response parameters from the secondary window to
       the secondary window's opener window.  The receiver window MUST
       be referenced by the secondary window's opener property.

   Example of an authorization server using the postMessage API in a
   secondary window to return the authorization response to the client
   in the primary window:

   const params = {
     "code": "XXXXXXXX",
     "state": "XXXXXXXX",
     "iss": "https://as.example"
   }
   window.opener.postMessage(params, "https://client.example/cb")

   5.  The client's message event handler receives the postMessage that
       contains the authorization response parameters.  The further
       processing and validation of all parameters is out of the scope
       of this specification and MUST be compliant to [RFC6749] and
       [RFC9700].





Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 7]

Internet-Draft       oauth-web-message-response-mode       November 2025


4.  Iframe-Based Authorization Flow Using the Web Message Response Mode

   In addition to secondary windows being popups, iframes can be used as
   well.  Iframes enable a seamless authorization flow where the end-
   user only sees a single browser tab, without ever leaving the actual
   client.  The client MAY explicitly request the iframe-based
   authorization flow by setting the response_mode parameter to
   web_message.parent.  The authorization flow proceeds in a manner
   technically similar to the popup-based flow described in Section 3,
   with the following modifications:

   *  In step 2, the client MUST embed the authorization request in an
      iframe instead of opening a popup window.
   *  In step 4, the secondary window MUST reference its parent window
      rather than its opener window.

   If user consent has already been granted, iframe-based authorization
   flows can enable seamless session resumption or renewal by embedding
   invisible iframes with the prompt parameter set to none [openid.core]
   (Section 3.1.2.1).  In this case, the client receives the
   authorization response directly, allowing the user session to resume
   without further interaction.  If the prompt parameter is set to none
   but no prior user authentication or consent exists, the authorization
   server MUST return an error as specified in [openid.core]
   (Section 3.1.2.1).  In this case, the client can fall back to a
   popup-based flow or to an iframe-based flow that displays a
   Clickjacking-protected user interface, as discussed in Section 4.1.

4.1.  Clickjacking Mitigations in Iframes

   The authorization server MUST implement Clickjacking countermeasures
   according to [RFC9700] (Section 4.16) and protect its authorization
   endpoint and consent-page from being embedded in an iframe by origins
   not deemed trustworthy.

   If the user's browser supports the Intersection Observer v2 API
   [w3c.observerv2], the authorization server MAY use it to allow the
   client to embed the authorization endpoint and consent-page.  For
   example, the authorization server's script running in the embedded
   consent-page could pre-emptively load itself in a popup window if it
   detects the Intersection Observer v2 API's isVisible attribute being
   set to false, thus avoiding any occlusion of its content.









Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 8]

Internet-Draft       oauth-web-message-response-mode       November 2025


4.2.  User-Session in Iframes

   Modern browsers have started to disable the support for third-party
   cookies.  Thereby, iframes do not send authentication cookies along
   with requests in sub resource requests, such as iframes.  Using
   iframes as secondary windows therefore requires special exceptions to
   bypass this restriction, such as the Storage Access API
   [mozilla.storageaccessapi].

   This mechanism is unnecessary in first-party scenarios where the
   authorization server and client share the same origin.  In such
   cases, cookies are treated as first-party and remain included in
   requests made from iframes.

5.  Authorization Server Metadata

   Authorization servers MUST announce their support for the web message
   response mode defined in Section 2 by adding web_message,
   web_message.opener, web_message.parent, or any combinations of these
   values to the response_modes_supported list in their authorization
   server metadata as specified in [RFC8414] (Section 2).  Authorization
   servers MAY declare exclusive support for a specific authorization
   flow by including either web_message.opener or web_message.parent in
   the response_modes_supported list.  If the response_modes_supported
   list contains the generic value web_message, the authorization server
   MUST support both the popup-based and the iframe-based authorization
   flows.

6.  Security Considerations

6.1.  Receiver Origin Validation

   Authorization servers MUST follow Section 2 and [RFC9700]
   (Section 4.17.2) when validating the postMessage receiver origin.
   Otherwise, the authorization response may leak to an attacker, as
   described in [RFC9700] (Section 4.17.1.1) and [RFC9700]
   (Section 4.17.1.2).

6.2.  Initiator Origin Validation and Cross-Site Request Forgery
      Protection

   In redirect-based authorization flows, there is no inherent mechanism
   available that enables a client to verify that the trusted
   authorization server initiates a redirection.  Instead, [RFC6749]
   introduces the state parameter to counter so-called Cross-Site
   Request Forgery (CSRF) attacks [RFC9700] (Section 4.7) against the
   client's redirection endpoint by maintaining a state between the
   authorization request and response.



Meyer zu Selhausen, et al. Expires 9 May 2026                   [Page 9]

Internet-Draft       oauth-web-message-response-mode       November 2025


   The postMessage API provides an inherent mechanism to verify the
   initiator of a postMessage.  The client MUST use this mechanism as
   described in Section 2 and [RFC9700] (Section 4.17.2) to verify that
   the trusted authorization server is the initiator of the postMessage.
   Otherwise, an attacker can inject a maliciously crafted authorization
   response to the client [RFC9700] (Section 4.17.1.3).  This
   verification prevents some variants of CSRF attacks, where the
   attacker wants to log in a victim to the attacker's account.

   However, attackers can also use CSRF attacks to log in a victim to
   the victim's own account.  This attack variant cannot be mitigated
   with the checks mentioned above.  Instead, a proper CSRF
   countermeasure, as described in [RFC9700] (Section 4.7.1) MUST be
   used.

6.3.  Data Validation

   Even after the initiator origin of the postMessage is validated, the
   client MUST check that the postMessage has the expected format
   [whatwg.postmessage] (Section 9.3.2.1).  In particular, the
   postMessage MUST NOT be processed in unsafe JavaScript sinks like
   eval or innerHTML to prevent cross-site scripting (XSS) flaws and
   other potentially malicious injections.  Otherwise, if the
   authorization server has been attacked using an XSS flaw, further
   unchecked processing of the postMessage could result in the attack
   being propagated into the client.

6.4.  Cross-Site Leak Protections on the Authorization Server

   The authorization server is opened in a secondary window that needs
   access to its opener window via its opener property to send
   postMessages to that referenced window.  Thus, the authorization
   server cannot use cross-site leak protections like the cross-origin
   opener policy [whatwg.coop] to force the creation of a new top-level
   browsing context and cross-origin isolate their sites.

   However, browsers are working on preventing cross-site leaks without
   breaking the popup-based authorization flows with the restrict-
   properties directive being added to the cross-origin opener policy
   [google.restrictprops].  With this directive, properties that can be
   used for cross-site leaks are not available but postMessage
   communication between cross-origin windows is still allowed.
   Authorization servers MAY set the Cross-Origin-Opener-Policy:
   restrict-properties header to protect against cross-site leaks.







Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 10]

Internet-Draft       oauth-web-message-response-mode       November 2025


6.5.  Redirection URI vs. Receiver Origin

   In redirect-based authorization flows, the confidentiality of the
   authorization response is scoped to the redirection URI that contains
   a path.  The path separates the authorization response from other,
   potentially vulnerable paths within the same web application.  In
   flows using the web message response mode, the confidentiality of the
   authorization response is scoped to the postMessage's receiver origin
   that does not contain a path.  Thus, cross-site scripting (XSS)
   vulnerabilities on _any_ path within the web application's origin
   will leak the authorization response to the attacker.

7.  IANA Considerations

   This draft makes no requests to IANA.

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

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

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

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

   [RFC9700]  Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
              "Best Current Practice for OAuth 2.0 Security", BCP 240,
              RFC 9700, DOI 10.17487/RFC9700, January 2025,
              <https://www.rfc-editor.org/info/rfc9700>.

   [oauth.encoding]
              de Medeiros, B., Scurtescu, M., Tarjan, P., and M. Jones,
              "OAuth 2.0 Multiple Response Type Encoding Practices",
              February 2014, <https://openid.net/specs/oauth-v2-
              multiple-response-types-1_0.html>.





Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 11]

Internet-Draft       oauth-web-message-response-mode       November 2025


   [whatwg.postmessage]
              "HTML Living Standard: Cross-document messaging",
              <https://html.spec.whatwg.org/multipage/web-
              messaging.html#web-messaging>.

9.  Informative References

   [I-D.sakimura-oauth-wmrm]
              Yamaguchi, T., Sakimura, N., and N. Matake, "OAuth 2.0 Web
              Message Response Mode", Work in Progress, Internet-Draft,
              draft-sakimura-oauth-wmrm-01, 8 November 2023,
              <https://datatracker.ietf.org/doc/html/draft-sakimura-
              oauth-wmrm-01>.

   [RFC9126]  Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
              and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
              RFC 9126, DOI 10.17487/RFC9126, September 2021,
              <https://www.rfc-editor.org/info/rfc9126>.

   [RFC9396]  Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
              Rich Authorization Requests", RFC 9396,
              DOI 10.17487/RFC9396, May 2023,
              <https://www.rfc-editor.org/info/rfc9396>.

   [google.restrictprops]
              and , "Secure popup interactions with restrict-
              properties", 9 August 2023,
              <https://developer.chrome.com/blog/coop-restrict-
              properties/>.

   [mozilla.storageaccessapi]
              "Storage Access API", 18 October 2023,
              <https://developer.mozilla.org/en-US/docs/Web/API/
              Storage_Access_API>.

   [oauth.post]
              Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response
              Mode", 27 April 2015, <http://openid.net/specs/oauth-v2-
              form-post-response-mode-1_0.html>.

   [openid.core]
              Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0 incorporating
              errata set 1", 8 November 2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.






Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 12]

Internet-Draft       oauth-web-message-response-mode       November 2025


   [w3c.observerv2]
              and , "Intersection Observer", 4 November 2019,
              <https://w3c.github.io/IntersectionObserver/>.

   [whatwg.coop]
              "HTML Living Standard: Cross-origin opener policies",
              <https://html.spec.whatwg.org/multipage/
              browsers.html#cross-origin-opener-policies>.

Appendix A.  Acknowledgements

   We would like to acknowledge the prior work of Toru Yamaguchi, Nat
   Sakimura, and Nov Matake in [I-D.sakimura-oauth-wmrm] which tried to
   define a response mode with similarities to this specification.  In
   contrast, this specification is not focused on iframes and does not
   include the use of the OAuth Implicit Grant.

   We would like to thank Vladislav Mladenov, ...

   for their valuable feedback on this document.

Appendix B.  Document History

   [[ To be removed from the final specification ]]

   -01 * Add use cases of popup and iframe flows * Enhance and clarify
   descriptions and mitigations for iframe flow * Clarify iframe use for
   first-party context and invisible iframes for reauthentication flows
   with prompt none * Add dynamic discovery of primary window reference
   and new values for response_mode: web_message.opener and
   web_message.parent * Add notes about how this draft differs from
   Sakimura et al. * Add several example implementations of the web
   message response mode and popup- or iframe-based flows * Minor
   improvements of style and language * Update references to newer
   versions

   -00 * Initial draft

Appendix C.  Example Implementations

   [[ To be removed from the final specification ]]

   Although neither the web_message response mode nor the popup- and
   iframe-based authorization flows have been officially standardized,
   they are already widely supported in practice.  A study
   (https://dl.acm.org/doi/10.1145/3548606.3560692) from late 2022 found
   that 153 of the Tranco Top 1k websites opened the authorization
   server in a secondary window, compared to only 134 websites that



Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 13]

Internet-Draft       oauth-web-message-response-mode       November 2025


   navigated the primary window to the authorization server.  More
   recently, a scan of all domains in the CrUX dataset (July 2025)
   revealed 22 authorization servers (https://github.com/Hackmanit/
   draft-meyerzuselha-oauth-web-message-response-mode/issues/27) that
   publish the still-undefined web_message value in the
   response_modes_supported list of their OpenID Provider Metadata
   (https://openid.net/specs/openid-connect-discovery-1_0.html) at
   /.well-known/openid-configuration.  In addition, several
   authorization servers support popup- or iframe-based flows without
   explicitly announcing them in their metadata:

   *  Apple supports the popup-based flow with response_mode=web_message
      through its custom JS SDK.  The flow is activated if the client
      enables the SDK's popup mode via a meta tag
      (https://developer.apple.com/documentation/signinwithapple/
      configuring-your-webpage-for-sign-in-with-apple).  Apple's REST
      API documentation
      (https://developer.apple.com/documentation/signinwithapplerestapi/
      request-an-authorization-to-the-sign-in-with-apple-server) does
      not mention web_message as a valid response_mode, although the SDK
      uses it when configured.

   *  Google supports both the popup-based
      (https://developers.google.com/identity/gsi/web/guides/
      integrate#pop-up_versus_redirect) (default) and iframe-based
      (https://developers.google.com/identity/gsi/web/amp/intermediate-
      iframe) flows within its Google Identity Services SDKs
      (https://developers.google.com/identity/gsi/web/guides/overview).
      However, these flows are not available in its interoperable OAuth
      and OpenID Connect endpoints
      (https://developers.google.com/identity/protocols/oauth2/web-
      server).

   *  Facebook supports the popup-based flow through its JS SDK
      (https://developers.facebook.com/docs/facebook-login/web).  It
      always includes the xd_arbiter endpoint as a parameter to the
      authorization endpoint, e.g.,
      channel_url=https://staticxx.facebook.com/x/connect/xd_arbiter.

   *  Auth0 officially documents support for the web_message response
      mode in its API documentation
      (https://auth0.com/docs/authenticate/protocols/oauth).  It
      references the expired draft [I-D.sakimura-oauth-wmrm] from 2015
      and uses it for silent authentication with HTML5 web messaging.

   *  Nintendo uses the web_message response mode internally, following
      the expired draft [I-D.sakimura-oauth-wmrm].  It also relies on
      the additional web_message_uri and web_message_target parameters.



Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 14]

Internet-Draft       oauth-web-message-response-mode       November 2025


   Beyond these providers, other authorization servers also employ
   web_message or proprietary variants of popup- and iframe-based flows.
   Apple, Google, and Facebook even make multi-window flows the default
   within their SDKs, highlighting their practical importance.  Yet, the
   absence of an interoperable, standards-based mechanism for clients to
   use these flows underscores the need for formal standardization.

Appendix D.  Differences to [I-D.sakimura-oauth-wmrm]

   [[ To be removed from the final specification ]]

   This draft builds on the earlier work of Toru Yamaguchi, Nat
   Sakimura, and Nov Matake in [I-D.sakimura-oauth-wmrm], which
   introduced a web message response mode.  While sharing several
   conceptual similarities, this draft differs in the following ways:

   *  *Flow illustrations:* [I-D.sakimura-oauth-wmrm] illustrates only
      the deprecated implicit flow (response_type=token).  This draft is
      flow-agnostic and uses the authorization code flow
      (response_type=code) in its examples.

   *  *Primary window reference:* [I-D.sakimura-oauth-wmrm] does not
      specify how the authorization server should obtain a reference to
      the client's primary window.  This draft allows the authorization
      server to either dynamically discover the reference or rely on
      client-provided hints via the web_message.opener and
      web_message.parent response modes.

   *  *Relay mode:* [I-D.sakimura-oauth-wmrm] defines a relay mode in
      which the authorization response is forwarded through the client
      to a third window (the "message target window").  This draft does
      not support tertiary windows and instead limits the exchange to
      the client's primary window and the authorization server's
      secondary window.  This draft omits relay mode due to lack of
      practical demand.

   *  *Browser compatibility:* [I-D.sakimura-oauth-wmrm] uses JavaScript
      constructs that no longer work in modern browsers (e.g.,
      window.opener != window and cross-origin DOM access via
      evt.source.document.getElementById).  These break relay mode
      entirely, as the secondary window cannot obtain a reference to the
      message target window.

   *  *Parameters:* [I-D.sakimura-oauth-wmrm] introduces the
      web_message_uri (target URI) and web_message_target (DOM id)
      parameters, both tied to relay mode.  This draft omits these
      parameters and instead relies solely on the established
      redirect_uri.



Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 15]

Internet-Draft       oauth-web-message-response-mode       November 2025


   *  *Message format:* [I-D.sakimura-oauth-wmrm] defines postMessage
      data as an object with fields type (string) and response (object).
      This draft simplifies the structure to a single object containing
      all authorization response parameters, since only one postMessage
      is used.

   *  *Iframe restrictions:* [I-D.sakimura-oauth-wmrm] restricts iframe-
      based flows to already-authenticated sessions with prior consent
      ("authenticated windows").  This draft permits iframe-based flows
      in unauthenticated states as well, relying on Clickjacking
      mitigations (e.g., the Intersection Observer v2 API).

   *  *Security considerations:* This draft provides extended guidance
      on secure use of postMessage, Clickjacking mitigations, and
      implications of browsers phasing out third-party cookies.

Authors' Addresses

   Karsten Meyer zu Selhausen
   Hackmanit
   Email: karsten.meyerzuselhausen@hackmanit.de


   Louis Jannett
   Ruhr University Bochum
   Email: louis.jannett@rub.de


   Christian Mainka
   Hackmanit
   Email: christian.mainka@hackmanit.de




















Meyer zu Selhausen, et al. Expires 9 May 2026                  [Page 16]


name: draft-rosenberg-aiproto-a2t
rev: 00
title: AI Agent to Tool (A2T) Protocol
time: 2025-11-06T16:14:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-10T16:14:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:06.864809+00:00
abstract:
This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the Agent-
   to-Tool (A2T) Protocol defines an OpenAI spec that has two principle
   features - enumeration of tools and invocation of tools.  The
   enumeration API enables a human - the AI Agent designer employed by
   the enterprise - to select and include tools from third-party vendors
   into operating procedures (also known as skills or instructions)
   which direct the behavior of AI Agents, including how and when to
   invoke those tools.  The enumeration API can also be used
   (optionally) at run-time for the LLM to obtain tool descriptions.
   The second feature of the API - invocation - allows the AI Agent
   executor to perform the inter-domain invocation of the tool at run
   time.  By standardizing these two API functions, the time and cost of
   integration of Internet APIs into AI Agents can be reduced.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 10 May 2026                                             Bitwave
                                                         6 November 2025


                    AI Agent to Tool (A2T) Protocol
                     draft-rosenberg-aiproto-a2t-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the Agent-
   to-Tool (A2T) Protocol defines an OpenAI spec that has two principle
   features - enumeration of tools and invocation of tools.  The
   enumeration API enables a human - the AI Agent designer employed by
   the enterprise - to select and include tools from third-party vendors
   into operating procedures (also known as skills or instructions)
   which direct the behavior of AI Agents, including how and when to
   invoke those tools.  The enumeration API can also be used
   (optionally) at run-time for the LLM to obtain tool descriptions.
   The second feature of the API - invocation - allows the AI Agent
   executor to perform the inter-domain invocation of the tool at run
   time.  By standardizing these two API functions, the time and cost of
   integration of Internet APIs into AI Agents can be reduced.

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 10 May 2026.






Rosenberg & White          Expires 10 May 2026                  [Page 1]

Internet-Draft                     A2T                     November 2025


Copyright Notice

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

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

Table of Contents

   1.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Tool Curation . . . . . . . . . . . . . . . . . . . . . .   9
       3.1.1.  Tool Sculpting  . . . . . . . . . . . . . . . . . . .   9
   4.  The A2T Protocol Goals  . . . . . . . . . . . . . . . . . . .  11
   5.  Overview of Operation . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Tool Signatures . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Enumeration Endpoint  . . . . . . . . . . . . . . . . . .  13
     5.3.  Invocation Endpoint . . . . . . . . . . . . . . . . . . .  14
     5.4.  Versioning  . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Enumeration API . . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Details for a Specific tool . . . . . . . . . . . . . . .  19
     6.3.  Tool Version Retrieval  . . . . . . . . . . . . . . . . .  19
     6.4.  Pagination  . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Invocation API  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  OpenAPI Specification . . . . . . . . . . . . . . . . . .  21
   8.  Relationship to MCP . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Similarities  . . . . . . . . . . . . . . . . . . . . . .  21
     8.2.  Differences . . . . . . . . . . . . . . . . . . . . . . .  21
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Background

   AI Agents are applications built using Large Language Models (LLMs).
   AI Agents typically operate on behalf of some human or organization,
   and are capable of taking actions through the invocation of
   functions, also known as tools.  [I-D.rosenberg-ai-protocols]
   provides an overview of protocols and use cases for AI Agents.




Rosenberg & White          Expires 10 May 2026                  [Page 2]

Internet-Draft                     A2T                     November 2025


   In enterprise applications of AI Agents - including customer support
   uses cases - it is very common for the AI Agent to invoke tools
   provided by other organizations.  As an example, consider an
   enterprise that is a healthcare provider.  They have an AI Agent that
   needs to facilitate appointment scheduling, appointment cancellation,
   prescription refills, store location and hours lookup, and vaccine
   scheduling.  The actions are all supported by tools which are exposed
   to the AI Agent through its instructions.  The tools, in this case,
   could be implemented by servers within the enterprise domain - built
   by their IT department for example.  Or, they might be implemented by
   B2B SaaS providers that offer these capabilities to the entperrise.
   For example, in the healthcare space, Epic, Cerner, and Meditech are
   a few of the B2B SaaS providers that are often used by retail
   healthcare providers.

   It is very common for enterprises to have dozens, if not hundreds, of
   different systems providing APIs that might need to be accessed by an
   AI Agent.  This high cardinality is not new.  Prior to the advent of
   large language model technologies, voice and chat bots - and even
   classic "press 1 for sales, and 2 for support" Interactive Voice
   Response Systems (IVR) - needed to access large numbers of APIs to
   provide customer support for end users.  Integration of these APIs
   into IVRs, voice bots and chat bots often represented the most
   expensive and complex part of deploying those systems - not the
   training and optimization of the AI model which invokes them.

   The advent of AI Agents - if anything - only increases the likely
   cardinality of the number of distinct API sysems that need to be
   integrated.  This is due to increased capabilities of LLMs compared
   to prior generation AI models.  Whereas, in the past, certain use
   cases where just too difficult to automate (for example, multi-room
   booking for hotels - is difficult to do on websites, and almost never
   attempted by voice or chat bots) - now, these may be within reach for
   automation using AI Agent technology.  As a result, we will see more
   use cases, and therefore even more APIs that need to be integrated.

   For an AI agent to be effective, it needs more direction than just
   the enumeration of tools with names and descriptions.  Particularly
   in enterprise and customer support use cases, detailed instructions
   are required which direct when, how, if and why those tools should be
   invoked.  These instructions guide the AI agent on how to converse
   with the customer, what kind of information to collect, how to use it
   to invoke the tools, how to handle the differing responses, and what
   to do with the data that is returned.  We use the term operating
   procedure to describe an instruction that provides this detail to an
   AI Agent.  An operating procedure is typically specific to a
   particular task (for example, booking an appointment for a healthcare
   visit).  An operating procedure at the end of the day is a document,



Rosenberg & White          Expires 10 May 2026                  [Page 3]

Internet-Draft                     A2T                     November 2025


   containing natural language text with references to tools, tool
   inputs, and tool outputs.  Others have referred to these as skills
   (see the recent Anthropic blog post here:
   https://www.anthropic.com/engineering/equipping-agents-for-the-real-
   world-with-agent-skills (https://www.anthropic.com/engineering/
   equipping-agents-for-the-real-world-with-agent-skills)), instructions
   or even prompts.

   Here is an abbreviated example of an operating procedure for
   prescription refill that illustrates this:

   ##Goal

   Your goal is to help the user with prescription refill inquiries.

   ## Prescription Refill Status
   Follow this flow if the user: 
   - is asking about the status of a prescription
    refill request they've made;
   - is asking when their prescription refill(s)
     will be ready. For example:
   - What's the status of my prescription request?
   - I just want an update regarding my prescriptions.
   - When will my prescription refill be ready?
   ### Prescription Lookup
   - Use look_up_prescriptions() to look up the user's
     active prescriptions. You must have previously
     authenticated the user and have their account ID.
     If you don't have their accountID yet, perform the
     authentication flow.
   ### Present Status
   - Find the prescriptions which have a status other
     than null and present them to the user along with
     their status.
   ### Sending Confirmation
   - Ask the user if they want to receive a confirmation
     when the refill has been sent to the pharmacy.
   - If you have the user's preferred contact method
    (which the you would have gotten earlier from
     look_up_ani_user_by_ani(), use that information
     and send them the confirmation of the appointment
     status along with the appointment details.

                   Figure 1: Example Operating Procedure

   As you can see from the example, the operating procedure is a
   detailed recipe-book - a training manual of sorts - for the AI Agent.
   It describes API sequencing (for example, that the lookup of



Rosenberg & White          Expires 10 May 2026                  [Page 4]

Internet-Draft                     A2T                     November 2025


   prescriptions can only be done after authentication), usage of
   parameters (that accountID must be included from prior
   authentication), handling of results (show the list to the user), and
   so on.

   Operating procedures are analagous to training manuals for human
   agents, which similarly instruct them in the sequencing and handling
   of a call.  Instead of invoking tools, humans use web applications to
   do a similar job.  In traditional contact centers, entire teams of
   people are accountable for creating and maintaining these training
   manuals.  They are essential for ensuring quality of customer
   support.

   At the end of the day - operating procedures are what make the AI
   Agent work.  While their generation may be assisted by an AI to
   facilitate authoring, operating procedures are crafted by human
   beings using traditional software.  The person whose role is to
   create the operating procedure is called the AI Agent designer - or
   just designer for short.  The software used by the designer to create
   an AI Agent, including the authoring of the operating procedure, is
   called the AI Agent platform.  To properly create an operating
   procedure, the designer must be a domain expert - familiar with the
   appropriate process for performing the task the AI Agent is to
   perform.

   Part of task of creating an AI Agent is the selection of the tools to
   be used.  Typically, this selection happens through the authoring of
   the operating procedure, which makes explicit reference to the tool
   as in the example above.  It is also possible for the designer to
   select a tool for usage by the AI Agent but not provide any guidance
   on its usage in the operating procedure (most of the current APIs for
   AI Agents separate the tool list from the instruction, thus making
   this possible).  While technically this can work, it often results in
   higher rates of hallucinated tool usage.

   The choice by a designer on the set of tools that are shown to the
   LLM (we use the verb show as a synonym for inclusion of information
   into the model's context window) is referred to as tool selection.
   The process of tool selection and authorship of the operating
   procedures happen ahead of the deployment and actual usage of the AI
   Agent.  We refer to this as design time, whereas the usage of the AI
   Agent by end users is called run time.

   At run time, a user will begin a session with an AI Agent.  At the
   beginning of the session, the AI Agent is shown the operating
   procedure and tools, and begins operation.





Rosenberg & White          Expires 10 May 2026                  [Page 5]

Internet-Draft                     A2T                     November 2025


   It is becoming increasingly common for AI Agent design systems to
   make use of multiple distinct AI Agents (called sub-agents) which are
   each equipped to handle specific tasks.  These are called multi-agent
   systems.  Once again using our health care example, one sub-agent
   might handle prescription refills, while another handles appointment
   scheduling and cancellation.  Each sub-agent would have its own
   distinct set of operating procedures and tools, appropriate for those
   tasks.  This further reduces the size of the context window at any
   point in time, reducing hallucination rates.  There are various
   techniques for how these sub-agents are strung together.  At the end
   of the day, it is often done through tool calling, asking the LLM to
   invoke a tool that transfers the session to a different AI Agent.
   This is (interestingly) analagous to live human agents in contact
   centers, which typically have human agents with differing skills.
   When a customer asks for something which is outside of the expertise
   for the human agent they are talking to, the human agent transfers
   the call to a different human agent with the right skill.  In essence
   - that is what is happening in these multi-agent systems.

   The usage of a designer to select only those tools needed for an
   agent, and the usage of multi-agent systems, provides progressive
   tool disclosure.  Progressive tool disclosure is a concept wherein an
   AI Agent is only shown just the set of tools it needs at a given
   time, and as the conversation flows, more tools are shown.

   The tools selected by the designer, and incorporated into the
   operating procedure, are often implemented by the executor through
   the invocation of APIs on some server.  The server exposing those
   APIs is called an API Server.

2.  Terminology

   Terminology is becoming foundationally important in this emerging AI
   Agent field.  This section summarizes the key terminology and
   concepts from above.

   *  AI Agent: A software application that makes use of an LLM to
      perform tasks that require interaction with software systems.
      With an AI Agent, the LLM can output both text for the user, but
      it can also request the invocation of tools, which are an
      interface the LLM can use to access those software systems.  AI
      Agents are composed of two elements: an LLM and an executor.  The
      executor is built using traditional software (e.g., Java, node.js,
      python, etc) and interfaces with the LLM.

   *  Tool: An interface representing a software system.  A tool has a
      name, a description, inputs and outputs.  In AI Agent system, the
      LLM is responsible for collecting the inputs and requesting the



Rosenberg & White          Expires 10 May 2026                  [Page 6]

Internet-Draft                     A2T                     November 2025


      invocation of the tool.  The executor actually executes the tool,
      often through the invocation of APIs, and feeds the results back
      to the LLM.  By convention, tool names use underscores and have a
      terminating curly bracket, even though they may also take
      parameters.  For example, when we say "the LLM invokes
      schedule_appointment()" this means that the LLM has made a
      decision to invoke the tool name schedule_appointment and has
      synthesized the needed input parameters to the tool

   *  Executor: Also called the orchestrator or orchestration engine.
      It represents the traditional software component of an AI Agent.
      The executor funnels messages to and from the end user into the
      LLM.  It receives the outputs of the LLM, and if that output is a
      request to perform a tool call, the executor runs the tool and
      provides its output back to the LLM.

   *  Show: The process wherein the executor provides input to the LLM,
      inclusive of tool call results, by adding it to the context window
      of the LLM.  For example, we say, "the tool call result is shown
      to the LLM'.

   *  Operating Procedure: A document authored by a human, and shown to
      an LLM during run-time operation, which instructs the AI Agent on
      the sequence of tools to invoke, how to interact with the user to
      collect the data needed for tool invocation, what to do with the
      results of the tool call, how to handle different conditions based
      on the output of the tools, and how to handle exceptional
      conditions.  Operating procedures reference tools and their inputs
      by name.

   *  AI Agent Designer: Synonymous with designer

   *  Designer: A human being whose job is to create operating
      procedures and perform tool selection during the design phase of
      the AI Agent.

   *  Tool Selection: The process of selection of the right set of tools
      to show to an AI Agent for a particular task.  By selecting only
      those tools which are needed for a task, the likelihood of tool
      hallucination is reduced.  Tool selection in the A2T framework
      happens at design time (though the protocol allows this to happen
      at run time in an interoperable fashion, should that mode be
      selected by the AI Agent platform vendor).

   *  Design Time: A point in time during which the designer is
      interacting with the AI Agent platform in the producion of an
      operating procedure and selection of tools.




Rosenberg & White          Expires 10 May 2026                  [Page 7]

Internet-Draft                     A2T                     November 2025


   *  Enterprise: The administrative entity on whose behalf an AI Agent
      operates.  Typically the designer is an employee of the
      enterprise, though this can be outsourced to consulting firms or
      the AI Agent Platform vendor.

   *  Run Time: A point in time during which an end user is interacting
      with an AI Agent.

   *  Multi-Agent Systems: An AI Agent wherein its job is broken down
      into a smaller set of discrete tasks, each handled by a sub-agent
      that is equipped (via its operating procedure and tool list) to
      perform that specific task

   *  Sub-Agent: An AI Agent that performs a narrow set of tasks.
      Multiple Sub-Agents are woven together to form the AI Agent in a
      Multi-Agent System.

   *  Progressive Tool Disclosure: A technique for reduction of
      hallucination wherein, as an AI Agent session unfolds, the set of
      tools shown to the LLM evolves, offering it only the tools it
      needs to do its job at any point in time.

   *  API Server: A server that exposes APIs which can be invoked via a
      tool call by the AI Agent

   *  API Provider: The administrative entity that is offering APIs that
      are of interest to an AI Agent.  Typically, the API Provider is
      different from the enterprise, and is also different in turn from
      the AI Agent Platorm vendor.

   *  AI Agent Session: A period of time from when an AI agent begins -
      by having the executor show the LLM the initial operating
      procedure and tool selection - estabishing initial context - and
      interacting with the end user - until the end user interaction
      completes.

   *  AI Agent Platform: A piece of software which includes a design
      time experience for designers, and a run-time capability for
      handling AI Agent sessions.  Typically built as a cloud service by
      the AI Agent Platform vendor.  Though the AI Agent Platform can be
      provided by the vendor of the LLM itself, these can be distinct
      vendors.

   *  AI Agent Platgorm Vendor: The administrative entity that has
      developed the AI Agent Platform, and made it available for usage
      by enterprises to author and execute AI Agents.





Rosenberg & White          Expires 10 May 2026                  [Page 8]

Internet-Draft                     A2T                     November 2025


3.  Problem Statement

   There are multiple problems that are addressed by A2T, covering
   design time and run-time challenges.

3.1.  Tool Curation

   At design time, the AI Agent platform needs to enable the designer to
   author the operating procedure and, as a result, select the tools
   that will be made available to the AI Agent (or the sub-agent).  To
   do this, the designer needs to know what the available tools are,
   from which they can select.  In essence, the designer is performing a
   curation task, choosing amongst a large inventory of tools available
   from many possible API servers.  Most often, the enterprise deploying
   the AI Agent, is different from the vendor of the AI Agent platform,
   which is different still from the vendors of the API servers.

   As a result, the designer needs to know the API surface area of the
   various vendors of API servers, and know which API to select and use.
   Sometimes, API Servers offer OpenAPI specifications for their APIs,
   but these are tailored for usage with software developers, not
   consumption by AI Agent designers, and certainly not by LLMs.
   Consequently, they lack the required natural language descriptions to
   aid in the curation process by the designer.  Designers need to spend
   time researching and studying APIs, learning what they do, and
   determining whether the right APIs exist, and if so, what they are.
   They have to determine whether the API can be used as is, or whether
   changes are needed to make the API more easily (and reliably)
   consumeable for the automation.  This process is historically long
   and tedious, and is exacerbated by the fact that the APIs are spread
   across dozens of API servers from the many vendors used by a
   particular enterprise.

   The lengthy time required for API integration is one of the most
   significant parts of the time required to build automation solutions
   (including AI Agents) within enterprises.

3.1.1.  Tool Sculpting

   Oftentimes existing APIs on API servers - usually REST these days -
   are complex and (clearly) not optimized for usage by an LLM.  They
   have been designed to be consumed by traditional software authored by
   software developers.  Traditional REST API signatures have complex
   inputs - URI parameters, header parameters, and JSON bodies.  They
   also tend to mix programmatic elements and semantic elements.
   Programmatic elements are those parts of the API parameters that are
   meaningful only to the software which is invoking those APIs.  These
   include resource identifiers like UUIDs, trace IDs, URLs, timestamps,



Rosenberg & White          Expires 10 May 2026                  [Page 9]

Internet-Draft                     A2T                     November 2025


   meta-data and so on.  Semantic elements are those which are
   ultimately the input from the end user which drove the execution of
   the API.  As an example, when doing something as simple as looking up
   the weather, the city and the date (today or the future) are the
   semantic elements.  But the lookup API might need to provide
   programmatic elements like a weather station ID, which is not
   meaningful to the user request.

   It is also the case that a particular end user request (e.g., give me
   the weather tomorrow in Manhattan), doesn't map to a single API call.
   Instead, a sequence of API calls need to be orhcestrated together to
   actually provide this simple ask.  As an example, the APIs at the US
   National Weather service provide weather forecasting based on grids
   of 2.5km to 2.5km.  Consequently, to provide the weather for
   Manhattan, the location must be first mapped to a coordinate, and
   then the coordinates fed into the forecast API.

   There are two ways these problems are solved today.

   A simple way to solve these problems is to just let the LLM figure it
   out.  A naive implementation would - in essence, use the existing
   OpenAPI specs for an API as a tool, and request the LLM to synthesize
   inputs, process outputs, and chain API calls together.  While this is
   possible - and indeed works for simple use cases - it introduces
   hallucination risk.  It also complicates the design process,
   requiring the designer to understand the details of these APIs.  The
   designer must - via the operating procedure - direct the AI Agent on
   how to use the APIs and navigate them.

   This approach has many problems.  First, it increases the time
   required to author the operating procedure, since it must now include
   the manually generated instructions on how to use the APIs.  Second -
   and most importantly - it increases hallucination risk.  The larger
   the gap between how the API works, and what the semantically
   meaningful operation is - the larger the surface area for mistakes by
   the LLM.

   The lesson is - never ask an LLM to do what a normal piece of
   software can do better.

   And thus, the second way this is solved today is through the
   development of automation ontop of existing APIs.  Again using the US
   National weather service example, a piece of traditional software can
   be written which exposes an API called lookup_weather_by_city.  This
   API would, under the hood, first convert the city to geo-coordinates,
   and then lookup the weather for those coordinates.  The resulting
   simplified API can then be shown to the LLM as a tool.




Rosenberg & White          Expires 10 May 2026                 [Page 10]

Internet-Draft                     A2T                     November 2025


   The process of adding a layer of traditional software ontop of
   existing APIs in order to produce ones that more directly map to user
   input, in order to reduce tool call hallucination risk, we call as
   tool sculpting.

   Specifically, tool sculpting is the process of crafting an API which:
   1.  Minimizes the inputs for each tool to only those which are
   semantically meaningful and must be synthesized by an AI Agent 2.
   Minimizes the outputs for each tool to only those which would be
   relevant to an AI Agent 3.  Orchestrates multi-step backend API calls
   so that the AI Agent doesn't need to do it

4.  The A2T Protocol Goals

   The A2T protocol (A2T) addresses the underlying problems of tool
   curation and tool minimization.

   It has, at its core, the following goals:

   *  Reduce the time and costs for designers to create operating
      procedures and perform tool selection by simplifying the process
      of curation

   *  Enable development of AI Agents for enterprises which need access
      to tools across dozens or hundreds of API servers, typically sold
      to the enterprise by third party B2B SaaS vendors, by
      consolidating decision logic on tool selection in the hands of the
      designer

   *  Simplify adoption by tool vendors by building ontop of the
      existing API platforms and APIs they already have.  The closer the
      current API surface area is to the ideal tool set for an AI Agent,
      the less effort is required to implement

   *  Standardize an API signature for tool calling

   *  Tools are just APIs that are optimized for an LLM, but can also be
      used by traditional software applications too

   *  Authentication and Auhtorization use the existing techniques used
      for REST APIs offered by the API Vendor

   *  Reduce hallucination risk through tool sculpting








Rosenberg & White          Expires 10 May 2026                 [Page 11]

Internet-Draft                     A2T                     November 2025


   *  Separation of responsibility - API vendors perform tool sculpting,
      and the AI Agent designer crafts the operating procedure which
      instructs the AI Agent on how to use the many tools (across
      vendors even) that it can use.  In other words - one vendor makes
      tools which independent of the agent, and the other vendor makes
      agents which make use of those tools.

5.  Overview of Operation

   A2T is a web API that defines a pair of REST endpoints - one for
   enumerating tools available on the server, and the other for invoking
   a tool on the server.  Both of these make use of a tool signature,
   which is a standardized interface for what a tool looks like - how to
   describe a tool, and how to invoke it.  The API client is implemented
   by the AI Agent platform, and the rest endpoints are implemented by
   vendor wishing to expose their APIs as A2T tools.  It is envisioned
   that these just end up being new REST APIs added to the existing API
   surface area of the API Provider.

5.1.  Tool Signatures

   A2T standardizes the signature for tool calling.  A tool can be
   thought of as a Java interface, and the implementation of the tool
   happens over the wire by having the executor take the tool call from
   the LLM and send it to the API server.

   Every tool in A2T is comprised of the following descriptive
   signature:

   *  The tool ID
   *  The name of the tool
   *  The description of the tool
   *  The set of input parameters.  For each input parameter:
      -  The name of the input parameter, and whether it is required or
         optional
      -  The type of the input parameter - one of a small set (string,
         int, enum)
      -  The description of the input parameter
      -  Any constraints on the input types
         o  Strings: max length
         o  Int: min and max values
         o  Enum: list of enumerated values that are permitted, along
            with a description of each value.
   *  The output, of which there can be one or more.  Each output is:
      -  The name of the output
      -  A description of the output
      -  The type of the output (string, int, enum, json)




Rosenberg & White          Expires 10 May 2026                 [Page 12]

Internet-Draft                     A2T                     November 2025


   Invoking a tool requires the following to be provided:

   *  the name of the tool
   *  an input parameter list, which is an array of name/value pairs

   Consequently, the A2T protocol defines two JSON objects - the
   signature, and the invocation.  The A2T protocol carries these in its
   body.

   The signature ensures that the executor can take the output of the
   LLM, validate it against the signature, and execute it by sending the
   invocation over the wire.  For example, if the LLM synthesizes a tool
   call request with a missing parameter, or with an enum value that is
   not amongst the allowed values, the executor can reject it and ask
   the LLM to try again, or take other error handling logic.

5.2.  Enumeration Endpoint

   The enumeration endpoint - as the name implies - returns a list of
   tools available.  This API endpoint returns an array, each element in
   the array is a signature as noted above.  The API supports tagging
   and versioning, with filtering on those parameters, to facilitate
   design time interactions between the AI Agent platform and the API
   server.

   This API facilitates the following design-time workflow:

   1.  The designer identifies the set of API vendors for which the AI
       Agent should be allowed to operate
   2.  For each such API vendor, the designer configures the AI Agent
       platform with the URI for the A2T tool enumeration endpoint.
       This specification suggests a common naming practice of using the
       root API endpoint followed by "tools" (e.g.,
       https://api.weather.gov/tools (https://api.weather.gov/tools)) to
       simplify this when possible.
   3.  The administrator configures the appropriate credentials needed
       for AuthN and AUthZ (typically an OAuth grant flow) - this is not
       any different from any other endpoint from the API provider
   4.  The designer accesses the AI Agent platform, and the platform
       invokes the enumeration API and retrieves the tool signatures for
       all of the tools exposed on the API server for all of the
       configured API providers.  This provides a list of tools to the
       platform.  This list can be viewed, searched, filtering and
       sorted by the designer.  The UI of the design time experience can
       help the designer find and select tools for placement into the
       operating procedure.





Rosenberg & White          Expires 10 May 2026                 [Page 13]

Internet-Draft                     A2T                     November 2025


   The above steps can be done just once, and then apply to all AI
   Agents subsequently built on the platform.  Alternatively, the
   enumeration APIs can be explored by the AI Agent platform at design
   time, as the designer works.

   Once the designer has selected the tool, the tool signature can be
   retrieved by the AI Agent platform, stored, and then provided to the
   LLM at run-time.  With A2T, it is also possible to use the
   enumeration API retrieve a fresh tool signature at run-time, rather
   than use the version retrieved and cached at design time.  There are
   pros and cons to both approaches.  Retrieving and caching the
   signature at design time ensures consistency.  Designers seeking
   greater consistency - wherein testing of the agent performed before
   launch, matches run-time behavior, will prefer to cache the
   descriptions.  Indeed, the usage of caching allows the designer to
   tune and tweak the natural language text in the signature to improve
   accuracy, without dependng on the API vendor to do so.  This
   facilitates the separation of concerns built into the A2T protocol -
   that the AI agent designer can control all aspects of the behavior of
   the AI Agent, including the authorship of all natural language
   provided to the AI Agent.  The API vendor provides the tool - which
   is purely programmatic.

   Alternatively, if the AI Agent platform fetches the tool signature
   each time at run time, the latest-and-greatest can be used.  A2T does
   not technically prohibit this, allowing this mode to be implemented
   in an interoperable fashion.

   The key to efficacy of tool usage is the tool sculpting, a
   responsibility which sits with the API vendor in the A2T protocol.
   The API server must distill down its APIs into a set of tools, each
   of which do targeted, focused tasks.  Tool sculpting has a double
   benefit.  First, it reduces the surface area of information that the
   LLM needs to synthesize to invoke the tool, and reduces the amount it
   needs to comprehend to process its outputs.  Second, it simplifies
   the job of the designer in selection of the tool, and in crafting the
   operating procedure to instruct the LLM on when and how to invoke it.

   A2T also provides an API, part of the enumeration endpoint, for
   retrieving the signature for a specific tool.  This is useful for the
   run-time fetching of the signature.

5.3.  Invocation Endpoint

   The invocation endpoint is used by the executor at run-time.






Rosenberg & White          Expires 10 May 2026                 [Page 14]

Internet-Draft                     A2T                     November 2025


   When the LLM creates a tool request, it provides the tool name and
   input values.  Using the signature, the executor can validate the
   tool call request as being valid for the tool, and then use the wire
   protocol to invoke the tool on the API server.  When the response
   comes, it can then be shown to the LLM.

   The A2T invocation endpoint allows versioning, so that a specific
   version of the tool can be used.

5.4.  Versioning

   A common problem historically in the development of voice and chat
   bots - the precursor to modern AI Agents - is that API vendors
   sometimes change APIs, breaking operation of the bot.  This problem
   remains with AI Agents, and A2T addresses it by natively adding
   version support.

   The A2T protocol requires versioning for tools.  It mandates that
   each version of a tool is backwards compatible.  A new version of a
   tool can only add new optional input parameters, or add new output
   parameters.  To ensure consistent behavior, A2T requires API servers
   to allow invocation of a tool against a specific version, allowing AI
   Agent designers to select when to upgrade when new versions become
   available.

6.  Protocol Details

   The following provides a detailed specification of the protocol.

6.1.  Enumeration API

   A2T servers MUST implement the enumeration API, which is structured
   as follows:

   GET {platform-root}/tools

   It is RECOMMENDED that {platform-root} be the same as the API root
   endpoint that the API vendor already provides.

   The body returned in the result, which supports pagination (described
   below), includes an element called items, a JSON array that contains
   the array of signatures.  Each element of the array is a JSON object
   of type ToolSignature.  An example of a valid JSON object of this
   type is:







Rosenberg & White          Expires 10 May 2026                 [Page 15]

Internet-Draft                     A2T                     November 2025


   {
     "toolId" : "0479a45d-ad0a-49d4-94db-75edf00d2ca4",
     "name" : "Lookup Weather",
     "description" : "Invoke this tool to lookup the
                       weather for a given city.",
     "img" : "{optional URL for the tool}",
     "version" : "{versionNum},
     "currentVersion": "{versionNum}",
     "tags" : ["system", "retrievals"]
     "input_parameters" :
     [
       {
       "id" : "city"
       "name" : "City",
       "type" : "string",
       "description" : "The city for the weather
          lookup. For example, Boston or Los Angeles.",
       "required" : true
       }
     ]
     "output_parameters" :
     [
       {
         "id" : "temp-fh"
         "name" : "Temperature in Fahrenheit",
         "type" : "int",
         "description" : "The current temperature
            in the named city."
       }
     ]
   }

                   Figure 2: ToolSignature Object Example

   The toolID is always a UUID, ensuring tool uniqueness on the server.
   The name MUST be less than 255 characters, and MUST be unique across
   all other tools on the API server.  Names SHOULD use snake case, and
   be sufficiently long to be usefully descriptive without the
   description.  The longer names also reduce the likelhihood of tool
   name collisisons across API servers, in cases where an AI Agent is
   being shown tools from different API servers.  However, it is
   ultimately the responsibility of the AI Agent platform to make sure
   tool names shown to the LLM are unique.

   An example of a good tool name is:

   lookup_weather_by_city




Rosenberg & White          Expires 10 May 2026                 [Page 16]

Internet-Draft                     A2T                     November 2025


   The tool description MUST be less than 2000 characters.  Tool names
   and description MUST be in English.  Names and descriptions are
   consumed by both the designer (a human) and the LLM.  Localization is
   only needed for the human, and is the responsibility of the AI Agent
   platform.

   For a particular version of the tool, the signature is completely
   locked.  Meaning, the API server MUST NOT change any part of the
   signature (with the notable exception of the value of currentVersion)
   without changing the version.  The version number of a tool MUST be a
   positive integer, and MUST increase monotonically, starting at 1.
   The value of currentVersion reflects the most current version of the
   tool.

   The version returned at the top level tool enumeration endpoint MUST
   be the latest version of the tool, in which case the values of
   version and currentVersion are always identical.

   Input parameters are typed.  The type value is optional to include in
   the JSON.  If omitted, it is "string" by default.  The other valid
   values are "int", "boolean" and "enum".  More complex input types are
   not supported.  This is to constrain the complexity of objects that
   the LLM is asked to synthesize.  [OPEN ISSUE: lists maybe??].  If the
   type is "int", the optional "max" parameter can be included, which
   represents the maximum value for the integer.  The default is 65535.
   If the type is enum, the input parameter must include the attribute
   "allowed-values", which contains an array of name-description pairs.
   As an example:























Rosenberg & White          Expires 10 May 2026                 [Page 17]

Internet-Draft                     A2T                     November 2025


       {
       "id" : "flight_class"
       "name" : "Flight Class",
       "type" : "enum",
       "description" : "The cabin class for the flight reservation",
       "allowed-values" : {
           [
               {
                   "name" : "ECONOMY",
                   "description" : "Economy class, the least
                   expensive cabin class. Also known as coach."
               },
               {
                   "name" : "PREMIUM_ECONOMY",
                   "description" : "Premium economy class, the
                   second seat tier. More legroom."
               },
               {
                   "name" : "BUSINESS",
                   "description" : "Business class, the next to top
                   seat tier. Offers lie-down seating."
               },
               {
                   "name" : "FIRST",
                   "description" : "The top tier. Lie down seating,
                   luxury meal service, lounge access."
               },

           ]
       }
       "required" : true
       }

           Figure 3: ToolSignature Input Parameters Enum Support

   For enumerated strings, names MUST be snake case but capitalized,
   with a maximum length of 255 characters.  Descriptions have a maximum
   length of 2000 characters.

   Input parameters have IDs and names.  The IDs are meant to provide
   uniqueness across version, facilitating design time software
   processing of version changes.  The IDs need only be unique within
   the tool.

   Input parameter names must also be unique within the tool.  The LLM
   is asked to synthesize the name, not the ID.  Consequently, there is
   no reason to show the parameter ID to the LLM at run time.




Rosenberg & White          Expires 10 May 2026                 [Page 18]

Internet-Draft                     A2T                     November 2025


   Output parameters include the additional type of JSON.  This is used
   for cases where a more complex structure is returned, and the
   expectation is that the LLM can parse the structure for
   comprehension.  There is an explicit assumption in the signatures
   that it is more important to reduce hallucination on input synthesis,
   than it is to risk mis-comprehension of tool output.  This is why the
   protocol is asymmetric - allowing JSON output, but not input.

   For input parameters, the "required" field is optional; if absent,
   the default is "true".  Optional inputs should be used sparingly.  It
   is better to have more tools with fewer inputs, than a single tool
   with many optional inputs.  This reduces the likelihood of the LLM
   hallucinating tool usage.

6.2.  Details for a Specific tool

   The API allows for a signature to be retrieved for a specific tool
   via:

   GET {platform-root}/tools/{toolID}

   The server MUST return the current version of the specific tool.

6.3.  Tool Version Retrieval

   The API allows all versions of a tool to be retrieved via:

   GET {platform-root}/tools/{toolID}/versions

   The result is paginated, and includes the full signature for each
   version.  These MUST be sorted from most recent to oldest.

   An individual version can then be retrieved via:

   GET {platform-root}/tools/{toolID}/versions/{versionNum}

6.4.  Pagination

   Pagination is supported on the enumeration APIs (any of the above
   endpoints).  All of the APIs support a pageCursor and pageLimit URI
   parameter.  The page limit specifies the maximum number of pages to
   return.









Rosenberg & White          Expires 10 May 2026                 [Page 19]

Internet-Draft                     A2T                     November 2025


   The array holding the enumeration is included in the JSON body using
   an attribute called items which contains the array.  A peer element,
   called paging, holds the result of the query.  It contains two values
   - pageLimit - containing the actual page limit the server is
   offering, and next.  The next parameter contains the value of the
   cursor query parameter that the client should provide as a URI
   parameter to retrieve the next page.

7.  Invocation API

   At run-time, a tool is invoked with the invocation API:

   POST {platform-root}/tools/{toolID}:invoke

   The body of this takes the invocation object, an example of which is:

   {
     "name" : "lookup_weather_by_city",
     "input_parameters" :
     [
       {
       "name" : "City",
       "value" : "Omaha, Nebraska"
       }
     ]

   The response should contain the result of the invocation, an example
   of which looks like this:

   {
     "output_parameters" :
     [
       {
       "name" : "Temperature in Fahrenheit",
       "value" : 80
       }
     ]

   The output MUST include the name which matches to the output name in
   the signature.

   It is also possible to request invocation of a specific version of
   the tool:

   POST {platform-root}/tools/{toolID}/versions/{versionId}:invoke






Rosenberg & White          Expires 10 May 2026                 [Page 20]

Internet-Draft                     A2T                     November 2025


   Traditional HTTP response codes apply to the response, including 5xx
   for temporary failures and 4xx if the request is formatted correctly.
   Note that, a 4xx should never happen if the client follows the
   specification defined here.

   If the request generates a 5xx, the executor SHOULD retry, rather
   than show the error to the LLM.  However, this is up to the
   discretion of the AI Agent designer on how long to wait before
   showing it the error and asking it what to do.

7.1.  OpenAPI Specification

   To be added when spec is closer to complete.

8.  Relationship to MCP

   A2T is similar in many ways to the Model Context Protocol (MCP)
   (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, but different in others.  This section covers both
   similarities and differences.  On the whole, the two protocols tackle
   a similar problem (facilitating tool calling and serving tool context
   to LLMs), but differ in their approach (MCP better suited for use
   cases where less designer control is appropriate, and A2T for cases
   where more designer control is appropriate).

8.1.  Similarities

   Both MCP and A2T support APIs for enumerating tools and invoking
   tools.

   Both MCP and A2T can be used to feed context to the LLM at run-time.

8.2.  Differences

   The biggest difference is the assumption in control.  A2T is very
   much targeted at use cases where there is a designer persona crafting
   an operating procedure.  Consequently, the tool enumeration API is
   consumed by traditional software in A2T, enabling the designer to
   perform the process of tool selection and design of the operating
   procedure, both at design time.  In MCP, the tool enumeration API is
   primarily consumed by the AI Agent at run-time.  For this reason, MCP
   has the idea of progressive tool disclosure that happens on the
   server side, in order to reduce model context.  A2T, on the other
   hand, assumes progressive tool disclosure happens as a consequnce of
   a design time operation, and thus, in simple terms, is client side.





Rosenberg & White          Expires 10 May 2026                 [Page 21]

Internet-Draft                     A2T                     November 2025


   In MCP, the logic for progressive tool disclosure is distributed in
   cases where there are multiple MCP servers, with each server
   executing its own, non-standardized logic for progressive tool
   disclosure (though the protocol does not require this behavior, it is
   purportedly one of the main reasons for the session oriented aspect
   of the protocol).  In A2T, the logic for progressive tool disclosure
   lives in the AI Agent, with the logic being crafted at design-time by
   the designer.  In this way, A2T is more compatible with Anthropic's
   skills concept, than it is with its MCP protocol.  Indeed, A2T could
   be viewed as the offspring of skills and MCP, by adding over-the-wire
   tool calling to skills.

   These foundational differences have consequences in the other parts
   of the protocols.

   MCP is session oriented.  A session oriented protocol is required
   when the server is responsible for progressive tool disclosure.  A2T
   is stateless, because it is not performing server side progressive
   tool disclosure.

   MCP uses JSON-RPC and runs over either stdio (for local usage on a
   PC) or streamable HTTP for network connections.  A2T is a normal REST
   API and uses traditional HTTPS and OpenAPI specifications.

   MCP typically requires a dedicated server that provides its
   functionality (termination of the persistent connection, session
   handling, and gateway to existing APIs).  A2T is designed to be added
   to existing API servers as just another API - albeit ones optimized
   for LLMs.

   MCP APIs are not easily consumeable by non-LLM applications.  A2T
   APIs are just APIs and can be consumed by both traditional software
   and AI Agents.

9.  Informative References

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net



Rosenberg & White          Expires 10 May 2026                 [Page 22]

Internet-Draft                     A2T                     November 2025


   Pat White
   Bitwave
   Email: pat.white@traego.com
















































Rosenberg & White          Expires 10 May 2026                 [Page 23]


name: draft-mvieuille-kerpass-ephemsec
rev: 02
title: KerPass EPHEMSEC One-Time Password Algorithm
time: 2025-11-22T16:40:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-14T08:46:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/71/"]
categories: ["Agent identity/auth", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:06.864811+00:00
abstract:
This document specifies EPHEMSEC, an algorithm for generating one-
   time passwords (OTPs) and one-time keys (OTKs).  Unlike traditional
   OTP algorithms that rely solely on static shared secrets, EPHEMSEC
   uses public key cryptography, which simplifies secure deployment on
   authentication servers.  EPHEMSEC also supports binding the generated
   OTP/OTK to contextual data.  When this context is obtained and
   injected by a trusted agent, the resulting codes can be made
   resistant to phishing and man-in-the-middle attacks.  Finally,
   EPHEMSEC includes a built-in time synchronization mechanism that
   embeds a synchronization hint into the generated output.  This allows
   both parties to deterministically derive the same OTP/OTK value
   without requiring trial-and-error validation, enabling compatibility
   with protocols such as Password Authenticated Key Exchange (PAKE) and
   TLS with Pre-Shared Key (TLS-PSK) that require exact secret
   agreement.

full_text:
Individual Submission                                        M. Vieuille
Internet-Draft                                          10 November 2025
Intended status: Informational                                          
Expires: 14 May 2026


              KerPass EPHEMSEC One-Time Password Algorithm
                  draft-mvieuille-kerpass-ephemsec-02

Abstract

   This document specifies EPHEMSEC, an algorithm for generating one-
   time passwords (OTPs) and one-time keys (OTKs).  Unlike traditional
   OTP algorithms that rely solely on static shared secrets, EPHEMSEC
   uses public key cryptography, which simplifies secure deployment on
   authentication servers.  EPHEMSEC also supports binding the generated
   OTP/OTK to contextual data.  When this context is obtained and
   injected by a trusted agent, the resulting codes can be made
   resistant to phishing and man-in-the-middle attacks.  Finally,
   EPHEMSEC includes a built-in time synchronization mechanism that
   embeds a synchronization hint into the generated output.  This allows
   both parties to deterministically derive the same OTP/OTK value
   without requiring trial-and-error validation, enabling compatibility
   with protocols such as Password Authenticated Key Exchange (PAKE) and
   TLS with Pre-Shared Key (TLS-PSK) that require exact secret
   agreement.

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 14 May 2026.

Copyright Notice

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



Vieuille                   Expires 14 May 2026                  [Page 1]

Internet-Draft                  EPHEMSEC                   November 2025


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   6
   3.  Functions and Notation  . . . . . . . . . . . . . . . . . . .   6
   4.  EPHEMSEC Roles  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Initiator Role  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Responder Role  . . . . . . . . . . . . . . . . . . . . .   7
   5.  EPHEMSEC Parametrization  . . . . . . . . . . . . . . . . . .   7
     5.1.  Hash Function . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.1.  HKDF(salt, ikm, info, L) → byte[L] Function . . . . .   7
     5.2.  ECDH(privKey, PubKey) → byte[DHLEN] Function  . . . . . .   8
     5.3.  Key Exchange Pattern  . . . . . . . . . . . . . . . . . .   8
       5.3.1.  E1S1 Pattern  . . . . . . . . . . . . . . . . . . . .   8
       5.3.2.  E1S2 Pattern  . . . . . . . . . . . . . . . . . . . .   8
       5.3.3.  E2S2 Pattern  . . . . . . . . . . . . . . . . . . . .   8
       5.3.4.  Rationale for Selecting a Key Exchange Pattern  . . .   9
     5.4.  Code Output . . . . . . . . . . . . . . . . . . . . . . .   9
       5.4.1.  T – Time Window . . . . . . . . . . . . . . . . . . .   9
       5.4.2.  B – Encoding Base . . . . . . . . . . . . . . . . . .   9
       5.4.3.  P – Code Size . . . . . . . . . . . . . . . . . . . .   9
     5.5.  Naming Scheme . . . . . . . . . . . . . . . . . . . . . .  10
   6.  EPHEMSEC Credentials  . . . . . . . . . . . . . . . . . . . .  10
     6.1.  Shared PSK  . . . . . . . . . . . . . . . . . . . . . . .  11
     6.2.  Responder Static Key  . . . . . . . . . . . . . . . . . .  11
     6.3.  Initiator Static Key  . . . . . . . . . . . . . . . . . .  11
   7.  EPHEMSEC Protocol Overview  . . . . . . . . . . . . . . . . .  11
   8.  Nonce Acquisition . . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  INONCE – Initiator Nonce  . . . . . . . . . . . . . . . .  13
     8.2.  PTIME – Responder Time Nonce  . . . . . . . . . . . . . .  13
       8.2.1.  Inputs  . . . . . . . . . . . . . . . . . . . . . . .  13
       8.2.2.  Responder Function – PTime(time) → (PTIME,
               SYNCHINT) . . . . . . . . . . . . . . . . . . . . . .  13
       8.2.3.  Initiator Function – SyncPTime(time, SYNCHINT) →
               PTIME . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  Z - Diffie-Hellman Secret Derivation  . . . . . . . . . . . .  14
     9.1.  Initiator E1S1 Z Derivation . . . . . . . . . . . . . . .  15
     9.2.  Responder E1S1 Z Derivation . . . . . . . . . . . . . . .  15
     9.3.  Initiator E1S2 Z Derivation . . . . . . . . . . . . . . .  15



Vieuille                   Expires 14 May 2026                  [Page 2]

Internet-Draft                  EPHEMSEC                   November 2025


     9.4.  Responder E1S2 Z Derivation . . . . . . . . . . . . . . .  15
     9.5.  Initiator E2S2 Z Derivation . . . . . . . . . . . . . . .  15
     9.6.  Responder E2S2 Z Derivation . . . . . . . . . . . . . . .  16
   10. 10.  ISK – Intermediary Secret Derivation . . . . . . . . . .  16
     10.1.  10.1 Inputs  . . . . . . . . . . . . . . . . . . . . . .  16
     10.2.  10.2 ISK Derivation  . . . . . . . . . . . . . . . . . .  17
   11. OTP/OTK Derivation  . . . . . . . . . . . . . . . . . . . . .  17
     11.1.  Inputs . . . . . . . . . . . . . . . . . . . . . . . . .  17
     11.2.  OTP Derivation (B ∈ {10, 16, 32})  . . . . . . . . . . .  18
     11.3.  OTK Derivation (B = 256) . . . . . . . . . . . . . . . .  18
   12. Key Exchange Protocol Integration . . . . . . . . . . . . . .  19
   13. Security considerations . . . . . . . . . . . . . . . . . . .  20
     13.1.  Adversary Profiles . . . . . . . . . . . . . . . . . . .  20
     13.2.  Output Unpredictability of EPHEMSEC  . . . . . . . . . .  20
     13.3.  Phishing and MITM Prevention via Context Binding . . . .  21
       13.3.1.  The need for a trusted Agent . . . . . . . . . . . .  22
     13.4.  Mutual Authentication  . . . . . . . . . . . . . . . . .  22
     13.5.  Time Synchronization Attacks . . . . . . . . . . . . . .  23
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     15.2.  Informative References . . . . . . . . . . . . . . . . .  23
   Appendix A.  OTP Sampling Bias  . . . . . . . . . . . . . . . . .  24
     A.1.  Bias Formula  . . . . . . . . . . . . . . . . . . . . . .  25
       A.1.1.  Derivation  . . . . . . . . . . . . . . . . . . . . .  25
       A.1.2.  Case 1: When M is divisible by m (M % m = 0)  . . . .  25
       A.1.3.  Case 2: When M is not divisible by m (M % m = s where 0
               < s < m)  . . . . . . . . . . . . . . . . . . . . . .  25
       A.1.4.  Bias Quantification . . . . . . . . . . . . . . . . .  26
     A.2.  Lemma 1: Distribution of Remainders in [0, M) . . . . . .  26
       A.2.1.  Proof:  . . . . . . . . . . . . . . . . . . . . . . .  26
   Appendix B.  Design Rationale . . . . . . . . . . . . . . . . . .  27
     B.1.  Use of HKDF . . . . . . . . . . . . . . . . . . . . . . .  27
     B.2.  Usage of PSK  . . . . . . . . . . . . . . . . . . . . . .  27
     B.3.  Usage of Nonces . . . . . . . . . . . . . . . . . . . . .  28
       B.3.1.  Transmission of the Responder Nonce . . . . . . . . .  28
   Appendix C.  Test Vectors . . . . . . . . . . . . . . . . . . . .  28
     C.1.  Kerpass_SHA512_X25519_E1S1_T600B10P8 vector . . . . . . .  28
     C.2.  Kerpass_SHA512_X25519_E1S2_T600B16P8 vector . . . . . . .  29
     C.3.  Kerpass_SHA512_X25519_E2S2_T600B32P9 vector . . . . . . .  30
     C.4.  Kerpass_SHA512_X25519_E1S2_T1024B256P33 vector  . . . . .  30
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  31









Vieuille                   Expires 14 May 2026                  [Page 3]

Internet-Draft                  EPHEMSEC                   November 2025


1.  Introduction

   The concept of one-time passwords has existed for decades.
   Proprietary systems such as RSA SecurID have been available since the
   early days of the Internet and have demonstrated the viability of
   time-based and event-based one-time passwords.  HOTP (specified in
   [RFC4226]) and TOTP (specified in [RFC6238]) are open algorithms that
   enable the implementation of one-time password generators operating
   similarly to earlier proprietary systems.  These algorithms now form
   the foundation of various hardware tokens and numerous smartphone
   authenticator applications that provide a second authentication
   factor for high-profile web applications.

   While OTP authenticator applications are simple to use and widely
   available, they have had limited impact on web application security.
   Two factors contribute to this limited success:

   1.  Deployment of corresponding authentication servers introduces
       additional risks, as stored credentials can be used to
       impersonate users if compromised.  This problem is particularly
       serious in today's cloud environments.

   2.  The design of traditional authenticator applications does not
       address specific security challenges of web applications.  In
       particular, modern web browsers do not provide a trusted input
       interface for entering authentication data, making users
       vulnerable to phishing attacks that capture credentials.

   These problems are the main reasons explaining the lack of
   attractiveness of one-time passwords for securing web applications.
   In the current technological ecosystem, one-time password solutions
   are seen as obsolete, and the current trend is toward using
   authentication credentials such as [PASSKEY], which address problems
   1 and 2 by relying on digital signature key pairs.

















Vieuille                   Expires 14 May 2026                  [Page 4]

Internet-Draft                  EPHEMSEC                   November 2025


   The KerPass EPHEMSEC algorithm also addresses problems 1 and 2 but
   takes a meaningfully different approach than digital signatures.  The
   EPHEMSEC client credential contains a Diffie-Hellman key pair, and
   the server stores only the public part of this key pair.  To obtain a
   new OTP from EPHEMSEC, a trusted agent obtains the server's ephemeral
   public key and acquires context information such as the login page
   URL.  This information is passed to the EPHEMSEC client (also known
   as the Responder; see Section 4.2) in a challenge message.  The
   client first calculates a Diffie-Hellman secret using the received
   public key and local key pair, then uses this ephemeral secret key to
   generate an OTP using an algorithm based on principles similar to the
   HOTP algorithm described in [RFC4226].  This simplified description
   excludes many important details but should be sufficient to provide
   an understanding of how public key cryptography is used in EPHEMSEC.

   Assuming that both EPHEMSEC OTP and digital signature solutions like
   [PASSKEY] can solve the server credential storage issue described in
   problem 1 and the phishing issue described in problem 2 (by having
   their output depend upon context input provided by a trusted agent),
   are there differences between the two that could help determine which
   option is better in a specific context?

   One advantage that an OTP authenticator application has over a
   digital signature authenticator application is simpler integration,
   resulting from the smaller size of OTPs compared to digital
   signatures.  Integration of smartphone interfaces such as NFC and
   Bluetooth to computing devices may eventually lessen this advantage,
   and EPHEMSEC can also generate one-time keys (OTK) that would benefit
   from the ubiquity of such interfaces.

   The main difference between OTP/OTK and digital signature credentials
   is that OTP/OTK are ephemeral *shared* secrets known by both peers
   involved in an authentication session, whereas digital signatures can
   only be generated by the peer controlling the private key.  There are
   contexts such as transaction validation in which the one-way nature
   of digital signatures is an advantage.  However, shared secrets have
   the distinctive advantage that they can be used as the main
   credential with protocols like Password Authenticated Key Exchange
   (PAKE) or TLS-PSK that enable *mutual* authentication of the peers
   involved in an authentication session.  The potential to use EPHEMSEC
   OTP/OTK for mutual authentication is the distinctive feature of this
   solution.

   OTPs generated by HOTP/TOTP algorithms are also ephemeral shared
   secrets, but synchronization problems make their integration with
   PAKE protocols complex (see Section 12).  EPHEMSEC has a built-in
   auto-synchronization feature (see Section 8.2) that addresses this
   issue.



Vieuille                   Expires 14 May 2026                  [Page 5]

Internet-Draft                  EPHEMSEC                   November 2025


   This document specifies the KerPass EPHEMSEC algorithm, which
   addresses the fundamental limitations of HOTP/TOTP that have
   contributed to the low attractivity of OTP authenticator applications
   for securing web applications.  EPHEMSEC solves the server credential
   storage security problem by using credentials based on public key
   cryptography, provides a context binding mechanism that enables the
   generation of OTPs and OTKs resistant to phishing and man-in-the-
   middle attacks, and produces shared secrets that can be used with
   mutual authentication protocols such as PAKE and TLS-PSK.  Given the
   ease of implementing OTP/OTK authenticator applications on
   smartphones, an OTP/OTK generation algorithm with properties similar
   to EPHEMSEC may be valuable across a wide range of use cases.

2.  Requirements Notation

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

3.  Functions and Notation

   This section defines notation and helper functions used throughout
   the specification.

   *  ||: Denotes byte string concatenation.

   *  byte(v): Converts an integer or single-character input v to a one-
      byte string.

   *  size(bs): Returns the length of byte string bs, as an integer.

   *  BE8(v): Returns the 8-byte big-endian encoding of unsigned integer
      v.

   *  U64(bs): Converts an 8-byte string bs into an unsigned 64-bit
      integer, using big-endian interpretation.

   *  TLV(tag, bs): Constructs a Tag-Length-Value encoding.  Returns
      byte(tag) || byte(size(bs)) || bs where:

      -  tag: An integer identifier in the range 0–255

      -  bs: A byte string with length ≤ 255 bytes






Vieuille                   Expires 14 May 2026                  [Page 6]

Internet-Draft                  EPHEMSEC                   November 2025


4.  EPHEMSEC Roles

   EPHEMSEC distinguishes two roles: Initiator & Responder.

4.1.  Initiator Role

   This role is normally assigned to relying web application.

4.2.  Responder Role

   This role is normally assigned to authenticator application.

5.  EPHEMSEC Parametrization

   Each EPHEMSEC protocol instance is characterized by its selection of
   cryptographic primitives and operational parameters.  These include:

   *  A secure hash function,

   *  An elliptic-curve Diffie-Hellman (ECDH) function,

   *  A key exchange pattern defining key contributions from the
      parties,

   *  Code output parameters specifying how the OTP/OTK values are
      formatted.

5.1.  Hash Function

   The hash function MUST be cryptographically secure (e.g., SHA-512)
   with digest length between 32 and 64 bytes. . This hash function is
   used to instantiate the HKDF key derivation function, as specified in
   [RFC5869].

5.1.1.  HKDF(salt, ikm, info, L) → byte[L] Function

   This function follows the specification in [RFC5869].

   *  salt, ikm, and info are arbitrary-length byte strings.

   *  L is a positive integer indicating the desired output length in
      bytes.

   *  The function returns a byte string of length L.







Vieuille                   Expires 14 May 2026                  [Page 7]

Internet-Draft                  EPHEMSEC                   November 2025


5.2.  ECDH(privKey, PubKey) → byte[DHLEN] Function

   This function performs an Elliptic-Curve Diffie-Hellman (ECDH) key
   agreement over a specified elliptic curve group, producing a shared
   secret of fixed length DHLEN.

   *  privKey: A private key from an elliptic curve key pair.

   *  PubKey: A public key from the same elliptic curve group.

   The function computes a shared secret using the standard ECDH
   primitive associated with the curve in use.  The result is a byte
   string of length DHLEN.  The specific behavior, including internal
   encoding and validation, is determined by the curve and cryptographic
   library in use.

   An example of a suitable ECDH function is X25519, as defined in
   [RFC7748], which yields a 32-byte shared secret.

5.3.  Key Exchange Pattern

   The key exchange pattern determines which types of keys (ephemeral or
   static) are contributed by the Initiator and Responder during the
   ECDH exchanges.

   Note that in each of the pattern below, the Initiator always
   contribute an ephemeral key and the Responder always contribute a
   static key.

5.3.1.  E1S1 Pattern

   *  Initiator contributes: 1 ephemeral key.

   *  Responder contributes: 1 static key.

5.3.2.  E1S2 Pattern

   *  Initiator contributes: 1 ephemeral key and 1 static key.

   *  Responder contributes: 1 static key.

5.3.3.  E2S2 Pattern

   *  Initiator contributes: 1 ephemeral key and 1 static key.

   *  Responder contributes: 1 ephemeral key and 1 static key.





Vieuille                   Expires 14 May 2026                  [Page 8]

Internet-Draft                  EPHEMSEC                   November 2025


5.3.4.  Rationale for Selecting a Key Exchange Pattern

   The choice of key exchange pattern should align with the
   authentication guarantees provided by the method used to validate the
   generated OTP or OTK.

   If the selected authentication method provides only one-way
   authentication—verifying the Responder to the Initiator—then there is
   no benefit in selecting a pattern more complex than E1S1.  Patterns
   such as E1S2 or E2S2 introduce additional computational and
   communication overhead without improving the resulting security.

   If the authentication method provides mutual authentication—for
   example, using PAKE or TLS-PSK—then the use of E1S2 or E2S2 becomes
   appropriate.  These patterns ensure that both the Initiator and the
   Responder contribute static keys to the Diffie-Hellman exchange,
   reinforcing the mutual nature of the derived secret.

5.4.  Code Output

   The format and characteristics of the OTP/OTK values produced by
   EPHEMSEC are determined by the parameters T, B, and P.

5.4.1.  T – Time Window

   T defines the duration of a validity window for each generated code,
   expressed in seconds.  T MUST be a positive integer greater than
   parameter B.

5.4.2.  B – Encoding Base

   B specifies the base used for code encoding.  Valid values are:

   *  10, 16, or 32: Encodes the output using a human-readable digit
      set, suitable for OTP.

   *  256: Encodes the output in binary form, suitable for OTK.

5.4.3.  P – Code Size

   P defines the number of digits in the generated code, where each
   digit is an integer in the range [0..B).  The valid range of P
   depends on the encoding base B and the minimum required entropy.

   The table below summarizes the minimum and maximum allowed values of
   P for each supported base, along with the corresponding entropy
   range.




Vieuille                   Expires 14 May 2026                  [Page 9]

Internet-Draft                  EPHEMSEC                   November 2025


           +======+=======+=======+=============+=============+
           | Base | min P | max P | min Entropy | max Entropy |
           +======+=======+=======+=============+=============+
           | 10   | 8     | 15    | 23 bits     | 46 bits     |
           +------+-------+-------+-------------+-------------+
           | 16   | 7     | 17    | 24 bits     | 64 bits     |
           +------+-------+-------+-------------+-------------+
           | 32   | 6     | 13    | 25 bits     | 60 bits     |
           +------+-------+-------+-------------+-------------+
           | 256  | 4     | 65    | 24 bits     | 512 bits    |
           +------+-------+-------+-------------+-------------+

                           Table 1: Code limits

5.5.  Naming Scheme

   EPHEMSEC uses a structured naming scheme to identify specific
   protocol instantiations.  A valid EPHEMSEC name has the following
   format:

   Kerpass_<Hash>_<ECDH>_<Pattern>_T<T>B<B>P<P>

   For example:

   Kerpass_SHA512_X25519_E1S1_T600B32P9

   Where:

   1.  <Hash> corresponds to the hash function used (see Section 5.1),
       e.g., SHA512.

   2.  <ECDH> denotes the ECDH function used (see Section 5.2), e.g.,
       X25519.

   3.  <Pattern> specifies the key exchange pattern (see Section 5.3),
       e.g., E1S1.

   4.  T<T>B<B>P<P> encodes the code output parameters (see
       Section 5.4), with <T>, <B>, and <P> replaced by their respective
       values.

6.  EPHEMSEC Credentials

   EPHEMSEC requires an *enrollment phase* during which the Responder
   (typically the authenticator app) registers an account with the
   Initiator (the relying web application).  Implementations may support
   various enrollment scenarios depending on their operational context
   and security requirements.



Vieuille                   Expires 14 May 2026                 [Page 10]

Internet-Draft                  EPHEMSEC                   November 2025


   This specification does not define a particular enrollment protocol,
   but it assumes the following outcomes:

   *  The Responder registers a static ECDH public key with the
      Initiator, corresponding to a key pair it controls.

   *  Both parties derive and retain a shared secret (PSK) that will be
      used in subsequent EPHEMSEC operations.

6.1.  Shared PSK

   The *pre-shared key (PSK)* is a byte string shared between the
   Responder and Initiator.  It is established during the enrollment
   process and MUST be at least 32 bytes in length.  The PSK is stored
   by both parties.

6.2.  Responder Static Key

   During enrollment, the Responder generates a static ECDH key pair and
   transmits the corresponding public key to the Initiator.  The
   Initiator stores this public key as part of the Responder’s account
   data.

6.3.  Initiator Static Key

   The Initiator is required to maintain a static ECDH key pair only
   when using key exchange patterns that require an Initiator static key
   (e.g., E1S2 or E2S2).  The mechanism by which the Responder obtains
   and establishes trust in the Initiator’s static public key is out of
   scope for this specification.

7.  EPHEMSEC Protocol Overview

   This section outlines the overall flow of a complete EPHEMSEC OTP/OTK
   generation exchange between an Initiator and a Responder.

   It assumes the following preconditions:

   *  The two parties have agreed on an EPHEMSEC instantiation (see
      Section 5).

   *  The Responder has registered an account with the Initiator,
      including a shared PSK and necessary public key material (see
      Section 6).

   The protocol operates as a Challenge/Response exchange.  The
   Initiator sends a message to the Responder containing:




Vieuille                   Expires 14 May 2026                 [Page 11]

Internet-Draft                  EPHEMSEC                   November 2025


   *  A CONTEXT byte string (e.g., relying party information),

   *  A freshly generated INONCE,

   *  Its Diffie-Hellman public key(s) as required by the selected key
      exchange pattern.

      *Note*: The structure and transport of this message are out of
      scope for this specification.

   Upon receiving this challenge, the Responder performs the following
   steps to compute the OTP or OTK:

   1.  *Obtain nonces* (see Section 8):

       *  Read or receive INONCE from the Initiator,

       *  Generate PTIME and extract SYNCHINT.

   2.  *Compute the Diffie-Hellman shared secret Z* (see Section 9):
       Based on the agreed key exchange pattern and available keys.

   3.  *Derive the intermediary secret ISK* (see Section 10):
       Using HKDF with Z, PSK, CONTEXT, SCHEME, INONCE, and PTIME.

   4.  *Generate the OTP or OTK* (see Section 11):

       *  The format is determined by the encoding base B,

       *  The last digit or byte encodes SYNCHINT.

   The Responder returns the resulting code to the Initiator.

   The Initiator, upon receiving the response, uses the included
   SYNCHINT to reconstruct PTIME and repeat the same derivation steps to
   validate or use the resulting code.

8.  Nonce Acquisition

   Each EPHEMSEC session uses two distinct nonces contributed
   independently by the two parties involved:

   *  The *Initiator* provides a nonce called INONCE, which ensures
      session uniqueness from the Initiator's side.

   *  The *Responder* provides a time-based nonce called PTIME, which
      captures the Responder’s local clock state.




Vieuille                   Expires 14 May 2026                 [Page 12]

Internet-Draft                  EPHEMSEC                   November 2025


   These nonces serve as independent inputs to the intermediary secret
   derivation process (see Section 10).

8.1.  INONCE – Initiator Nonce

   The Initiator generates a nonce INONCE that contributes to the
   personalization of the derived intermediary secret (see Section 10).
   This value acts as an Initiator-specific input to ensure uniqueness
   of each EPHEMSEC execution.

   INONCE MUST be a byte string of length between 16 and 64 bytes.  It
   MUST be unique for each run of the EPHEMSEC algorithm, and MUST NOT
   be reused across authentication sessions.

   The value of INONCE is transmitted from the Initiator to the
   Responder as part of the authentication request.

8.2.  PTIME – Responder Time Nonce

   The EPHEMSEC Responder derives a pseudo-time value, PTIME, from
   current time reading.  This PTIME acts as a Responder contributed
   nonce and is used in secret derivation along with an Initiator-
   contributed nonce.

   The challenge lies in enabling the Initiator to reconstruct the same
   PTIME value computed by the Responder, despite clock skew between the
   two parties.  To address this, the Responder includes a
   *synchronization hint*, SYNCHINT, in the last digit of the generated
   OTP or OTK.

   Given SYNCHINT, the Initiator can recover the original PTIME as long
   as clock drift remains within acceptable bounds.

8.2.1.  Inputs

   The following parameters are used throughout this section:

   *  time: Current Unix timestamp (seconds since 1970-01-01).

   *  T: Code validity window (see Section 5.4.1).

   *  B: Encoding base (see Section 5.4.2).

8.2.2.  Responder Function – PTime(time) → (PTIME, SYNCHINT)

   This function is executed by the Responder to compute the PTIME nonce
   and the associated synchronization hint:




Vieuille                   Expires 14 May 2026                 [Page 13]

Internet-Draft                  EPHEMSEC                   November 2025


   step = T / (B - 1) # floating point division
   PTIME = round(time / step)
   SYNCHINT = PTIME % B
   return PTIME, SYNCHINT

8.2.3.  Initiator Function – SyncPTime(time, SYNCHINT) → PTIME

   This function is executed by the Initiator to reconstruct the
   Responder’s PTIME using its local time and the received SYNCHINT:

   mintime = time - (T / 2)
   step = T / (B - 1) # floating point division
   mpt = round(mintime / step)
   mphint = mpt % B

   Q = mpt // B # integer division
   PTIME = Q * B + SYNCHINT

   if SYNCHINT < mphint:
       PTIME += B

   return PTIME

   This algorithm works correctly if the clock difference between the
   Responder and Initiator is less than T / 2.  Outside this range,
   synchronization will fail, resulting in mismatched secrets.

   KerPass uses a 600-second time window, allowing up to ±5 minutes
   clock drift in between Initiator and Responder.

9.  Z - Diffie-Hellman Secret Derivation

   Each party derives a shared secret Z using the Diffie-Hellman key
   exchange, based on the agreed EPHEMSEC key exchange pattern (see
   Section 5.3).  Key material is retrieved from received protocol
   messages and account credential storage.

   The result of the Diffie-Hellman exchange is a byte string Z, which
   is used as part of the key derivation input (see later sections).

   Where ephemeral key pairs are used, they MUST be freshly generated
   for each execution of the EPHEMSEC protocol and MUST NOT be reused
   across sessions.

   EPHEMSEC execution MUST be aborted if any required key is missing or
   invalid.





Vieuille                   Expires 14 May 2026                 [Page 14]

Internet-Draft                  EPHEMSEC                   November 2025


9.1.  Initiator E1S1 Z Derivation

   Inputs:

   *  ei Initiator ephemeral Keypair

   *  Sr Responder static PublicKey

   Z = ECDH(ei, Sr)

9.2.  Responder E1S1 Z Derivation

   Inputs:

   *  sr Responder static Keypair

   *  Ei Initiator ephemeral PublicKey

   Z = ECDH(sr, Ei)

9.3.  Initiator E1S2 Z Derivation

   Inputs:

   *  ei Initiator ephemeral Keypair

   *  si Initiator static Keypair

   *  Sr Responder static PublicKey

   Z = ECDH(ei, Sr) || ECDH(si, Sr)

9.4.  Responder E1S2 Z Derivation

   Inputs:

   *  sr Responder static Keypair

   *  Ei Initiator ephemeral PublicKey

   *  Si Initiator static PublicKey

   Z = ECDH(sr, Ei) || ECDH(sr, Si)

9.5.  Initiator E2S2 Z Derivation

   Inputs:




Vieuille                   Expires 14 May 2026                 [Page 15]

Internet-Draft                  EPHEMSEC                   November 2025


   *  ei Initiator ephemeral Keypair

   *  si Initiator static Keypair

   *  Er Responder ephemeral PublicKey

   *  Sr Responder static PublicKey

   Z = ECDH(ei, Er) || ECDH(si, Sr)

9.6.  Responder E2S2 Z Derivation

   Inputs:

   *  er Responder ephemeral Keypair

   *  sr Responder static Keypair

   *  Ei Initiator ephemeral PublicKey

   *  Si Initiator static PublicKey

   Z = ECDH(er, Ei) || ECDH(sr, Si)

10.  10.  ISK – Intermediary Secret Derivation

   EPHEMSEC derives an intermediary secret key ISK using the HKDF
   function (see Section 5.1.1).

10.1.  10.1 Inputs

   The function uses the following inputs:

   *  CONTEXT: An implementation-specific byte string (≤ 64 bytes), used
      to encode contextual information (e.g., login page url).

   *  SCHEME: A byte string representing the EPHEMSEC instantiation (see
      Section 5.5).

   *  B: Code encoding base (see Section 5.4.2).

   *  P: Code size (see Section 5.4.3).

   *  INONCE: An Initiator-generated nonce, a byte string between 16 and
      64 bytes (see see Section 8.1).

   *  PTIME: Responder-contributed time nonce (see Section 8.2).




Vieuille                   Expires 14 May 2026                 [Page 16]

Internet-Draft                  EPHEMSEC                   November 2025


   *  PSK: A shared pre-established secret (≥ 32 bytes) (see
      Section 6.1).

   *  Z: Diffie-Hellman shared secret derived from the selected key
      exchange pattern (see see Section 9).

10.2.  10.2 ISK Derivation

   The ISK is derived using the following steps:

   # CONTEXT & SCHEME are used for domain separation
   salt = TLV(byte('C'), CONTEXT) || TLV(byte('S'), SCHEME)

   ikm = Z || PSK

   # INONCE & PTIME are used for output personalization
   info = TLV(byte('N'), INONCE) || TLV(byte('T'), BE8(PTIME))

   # Output length
   if B == 256:
     L = P - 1 # OTK case
   else:
     L = 8 # OTP case

   ISK = HKDF(salt, ikm, info, L)

   return ISK

11.  OTP/OTK Derivation

   The intermediate secret key ISK computed in Section 10 serves as the
   final source of entropy for generating the OTP (one-time password) or
   OTK (one-time key).  The output format depends on the encoding base B
   (see Section 5.4.2).

11.1.  Inputs

   *  B: Code encoding base (see Section 5.4.2).

   *  P: Code size (see Section 5.4.3).

   *  PTIME: Responder-contributed time nonce (see Section 8.2).

   *  ISK: Intermediate secret key (see Section 10).







Vieuille                   Expires 14 May 2026                 [Page 17]

Internet-Draft                  EPHEMSEC                   November 2025


11.2.  OTP Derivation (B ∈ {10, 16, 32})

   When B is 10, 16, or 32, the code is formatted as an OTP composed of
   P digits.  The first P - 1 digits are derived from ISK, and the last
   digit is a synchronization hint (SYNCHINT) derived from PTIME.

   ISK MUST be exactly 8 bytes long and is interpreted as an unsigned
   64-bit integer.

   # Interpret ISK as a big-endian unsigned integer
   maxcode = B ^ (P - 1)
   isrc = U64(ISK) % maxcode

   # Extract (P - 1) digits in base B
   OTP = '' # empty byte string
   for i in 0 .. (P - 2):
       digit = byte(isrc % B)
       OTP = digit || OTP
       isrc /= B

   # Append 1-digit time synchronization hint
   SYNCHINT = byte(PTIME % B)
   OTP = OTP || SYNCHINT

   return OTP  # byte string of P digits in [0 .. B)

   *Note*: The result is returned as a sequence of P integer digits in
   base B.

   Conversion to a human-readable representation (for example, an
   alphanumeric alphabet) is outside the scope of this specification.
   Nevertheless, the use of the [Crockford-B32] alphabet is RECOMMENDED,
   as it is applicable to all EPHEMSEC OTP schemes and has been designed
   to minimize transcription and input errors.

11.3.  OTK Derivation (B = 256)

   When B is 256, the output is an opaque binary key.  The first P - 1
   bytes are taken directly from ISK, and the last byte encodes the
   synchronization hint.

   SYNCHINT = byte(PTIME % 256)
   OTK = ISK || SYNCHINT

   return OTK  # byte string of length P






Vieuille                   Expires 14 May 2026                 [Page 18]

Internet-Draft                  EPHEMSEC                   November 2025


12.  Key Exchange Protocol Integration

   EPHEMSEC OTPs/OTKs are ephemeral *shared secrets* that can serve as
   primary credentials in mutually authenticated key exchange protocols,
   such as:

   *  Password-Authenticated Key Exchange (PAKE)

   *  TLS with Pre-Shared Key authentication (TLS-PSK)

   Traditional one-time password algorithms like HOTP, as defined in
   [RFC4226], are unsuitable for these protocols due to their reliance
   on loose synchronization.  Validation servers must compare a received
   OTP against a range of possible values, which precludes direct use as
   cryptographic key material.

   EPHEMSEC addresses this limitation by appending a *synchronization
   digit* to each OTP/OTK.  This digit enables reconstruction of the
   time-based nonce PTIME (see Section 8.2), ensuring that both parties
   derive identical secrets without relying on trial-and-error
   validation.

   To use EPHEMSEC outputs as inputs to a key exchange protocol:

   1.  *Client Preparation*:

       *  Append the synchronization digit to the account identifier.

       *  Use this composite identifier to initiate the key exchange
          protocol.

   2.  *Server Operation*:

       *  Extract the synchronization digit from the received
          identifier.

       *  Remove the synchronization digit to recover the base account
          identifier.

       *  Load the corresponding client credentials using the base
          identifier.

       *  Execute the EPHEMSEC algorithm with the received session
          parameters, credentials, and synchronization hint to derive
          the shared secret.

       *  Proceed with the key exchange protocol using the derived
          secret.



Vieuille                   Expires 14 May 2026                 [Page 19]

Internet-Draft                  EPHEMSEC                   November 2025


13.  Security considerations

   This section outlines the security properties of the EPHEMSEC
   algorithm.  The analysis presented here is intended to demonstrate
   why the protocol is expected to meet its security goals, based on
   widely accepted cryptographic assumptions.

   This document has not yet undergone comprehensive peer review by the
   cryptographic and security communities.  The security analysis
   presented should be considered preliminary, and implementers should
   exercise appropriate caution in security-critical deployments pending
   further review.

13.1.  Adversary Profiles

   Two adversary profiles are considered in this analysis:

   *  *Network Observer*
      This adversary has access to all publicly visible data, including
      the Initiator’s and Responder’s static ECDH public keys, session
      inputs (nonces, ephemeral public keys), and outputs (OTPs/OTKs)
      from previous EPHEMSEC sessions.  It does not have access to any
      party’s private credentials.

   *  *Credential Leak Attacker*
      This adversary has all the capabilities of a Network Observer, and
      additionally has read access to the Initiator’s credential store —
      specifically the Responder’s shared PSKs and static public keys.
      It does *not* have access to the Initiator’s private keys or
      control over protocol behavior.

13.2.  Output Unpredictability of EPHEMSEC

   The primary security goal of an OTP/OTK algorithm is to ensure that
   outputs are unpredictable — even to attackers with significant
   passive or partial access.

   EPHEMSEC achieves this by combining Diffie-Hellman key exchange and
   HKDF with session-specific nonces.  Specifically:

   1.  *Unpredictability of the Shared Secret (Z)*
       The ECDH-derived shared secret Z is indistinguishable from random
       to any adversary lacking private keys, due to the hardness of the
       Decisional Diffie-Hellman (DDH) problem on the chosen curve.







Vieuille                   Expires 14 May 2026                 [Page 20]

Internet-Draft                  EPHEMSEC                   November 2025


   2.  *Unpredictability of the HKDF Input (ikm)*
       The HKDF input key material (ikm = Z || PSK) inherits the
       unpredictability of Z.  Even if the attacker knows the pre-shared
       key (PSK), the presence of the fresh and secret Z value ensures
       ikm remains secure.

   3.  *Security of the Derived Secret (ISK)*
       HKDF acts as a cryptographically strong pseudorandom function
       (PRF), meaning its outputs — including the intermediary secret
       ISK — are indistinguishable from random, provided the HKDF ikm
       secret input is unpredictable.  Because each execution of
       EPHEMSEC uses unique nonces and ephemeral keys, the ISK value
       changes with every session.

   4.  *Output Derivation (OTP/OTK)*

       *  For OTKs (B = 256): ISK is directly used, preserving its
          pseudorandomness.

       *  For OTPs (B ∈ {10, 16, 32}): ISK is converted to digits via
          modular arithmetic.  This process introduces bias when B = 10,
          but the bias is mitigated by restricting code sizes (P) to the
          ranges specified in Table 1 (see Appendix A for analysis).

   5.  *Prevention of Replay and Forward Prediction*
       The use of unique nonces (INONCE, PTIME) and ephemeral keys
       ensures that no two executions produce the same output — even for
       the same account and context.  This prevents replay attacks and
       ensures that attackers cannot predict future codes based on prior
       sessions.

   As a result, even an attacker who observes multiple sessions (and
   even possesses some server-side credentials) cannot derive or guess
   new OTPs or OTKs, nor can they reuse prior ones.

13.3.  Phishing and MITM Prevention via Context Binding

   EPHEMSEC can mitigate web browser phishing and man-in-the-middle
   (MITM) attacks by binding cryptographic outputs to authentication
   context through the CONTEXT input (see Section 10.1).  This mechanism
   enables:

   1.  *Phishing Resistance*:

       *  By embedding the login page URL in CONTEXT, the derived OTP/
          OTK becomes domain-specific.





Vieuille                   Expires 14 May 2026                 [Page 21]

Internet-Draft                  EPHEMSEC                   November 2025


       *  An attacker hosting a fake page cannot reuse intercepted
          codes, as their context will differ.

   2.  *MITM Resistance*:

       *  Including the server's TLS certificate hash in CONTEXT ensures
          the OTP/OTK is tied to the authenticated connection.

       *  A MITM with an invalid certificate cannot generate valid
          codes.

13.3.1.  The need for a trusted Agent

   Context binding alone is *insufficient* to provide Phishing or MITM
   resistance.

   For Context binding to be efficient, it must be used jointly with a
   *trusted Agent* (e.g., a browser extension) that:

   *  Reliably acquire authentication context (e.g., page URL,
      certificate)

   *  Securely inject it into EPHEMSEC's CONTEXT parameter

   *  Resist spoofing or coercion by attackers

13.4.  Mutual Authentication

   Because the EPHEMSEC Initiator and Responder share a PSK (see
   Section 6.1), all OTP/OTK outputs are derived from a secret known to
   both parties.  As a result, these values can serve as credentials in
   protocols that support mutual authentication, such as PAKE or TLS-
   PSK.

   However, when the E1S1 key exchange pattern is used, the only
   contribution from the Initiator is an ephemeral key.  In this
   configuration, the mutuality of the shared secret relies solely on
   the PSK.  If the PSK is compromised — for example, by a Credential
   Leak Attacker — the attacker can impersonate the Initiator to the
   Responder.

   To mitigate this risk, it is RECOMMENDED that mutual authentication
   deployments use the E1S2 or E2S2 key exchange patterns.  These
   patterns require the Initiator to contribute a static ECDH key,
   ensuring that mutual authentication depends on key material not
   accessible to a Credential Leak Attacker.  This prevents such an
   attacker from successfully impersonating the Initiator.




Vieuille                   Expires 14 May 2026                 [Page 22]

Internet-Draft                  EPHEMSEC                   November 2025


13.5.  Time Synchronization Attacks

   EPHEMSEC's time-synchronized nature creates a potential attack vector
   against the protocol's availability.  The algorithm requires that
   clock drift between Initiator and Responder remain within T/2 seconds
   for successful PTIME recovery (see Section 8.2).

   An attacker who can manipulate the time sources or time
   synchronization mechanisms of either party may cause authentication
   failures by forcing clock drift to exceed this threshold.  Such
   attacks could result in denial of service against the authentication
   system.

   Future revisions will extend PTIME derivation to support event-based
   counters alongside time-based synchronization.  Setting T = 0 will
   enable event-synchronized OTP/OTK generation using shared counters,
   while T > 0 will maintain time-based operation, allowing applications
   to choose the synchronization method best suited to their threat
   model.

14.  IANA Considerations

   No IANA action is required.

15.  References

15.1.  Normative References

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <https://www.rfc-editor.org/rfc/rfc7748>.

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

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

15.2.  Informative References

   [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
              O. Ranen, "HOTP: An HMAC-Based One-Time Password
              Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,
              <https://www.rfc-editor.org/rfc/rfc4226>.




Vieuille                   Expires 14 May 2026                 [Page 23]

Internet-Draft                  EPHEMSEC                   November 2025


   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/rfc/rfc5869>.

   [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
              Time-Based One-Time Password Algorithm", RFC 6238,
              DOI 10.17487/RFC6238, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6238>.

   [KerPass]  "KerPass open source project", n.d.,
              <https://github.com/amvtek/KerPass>.

   [PASSKEY]  "passkeys-Specifications", n.d.,
              <https://passkeys.dev/docs/reference/specs/>.

   [Crockford-B32]
              "Crockford Base 32 Alphabet", n.d.,
              <https://www.crockford.com/base32.html>.

Appendix A.  OTP Sampling Bias

   EPHEMSEC generates P (see Section 5.4.3) digits OTPs from 64-bit
   pseudo-random integers as described in Section 11.  This final
   operation may introduce a non-uniform distribution in the generated
   OTP when the code base B (see Section 5.4.2) does not evenly divide
   2^64, which occurs for all bases except B = 10.

   We apply the Bias Formula below to evaluate the bias for code base
   10.

   The bias reaches its maximum when the code size P is at its maximum
   value.  While EPHEMSEC supports a maximum P of 15, only 14 digits are
   used to encode the pseudo-random value.  Therefore:

   bias = 1 / floor(2^64 / 10^14) ≈ 5.4e-6

   This value is negligibly close to zero, making the code base 10 bias
   insignificant.

   For comparison, [RFC4226] generates 6-digit base-10 OTPs from 31-bit
   pseudo-random integers, resulting in:

   bias = 1 / floor(2^31 / 10^6) ≈ 0.5e-3

   While this value is also close to zero, it is approximately 100 times
   larger than EPHEMSEC's code base 10 bias.




Vieuille                   Expires 14 May 2026                 [Page 24]

Internet-Draft                  EPHEMSEC                   November 2025


A.1.  Bias Formula

   For integers m and M where m ≤ M and m > 0, when sampling uniformly
   from [0, M) and taking remainder modulo m, remainder distribution may
   not be uniform.

   To quantify this non uniformity we can calculate a bias coefficient
   using:

   *  bias = 0 when M % m = 0

   *  bias = 1/floor(M/m) when M % m ≠ 0

   The bias value varies in [0,1] and indicates the relative
   overrepresentation of certain remainders.  When bias = 0,
   distribution is uniform.

A.1.1.  Derivation

   Let X be a uniformly distributed random variable that generates
   integers in the range [0,M).  Let R = X % m, where R is a random
   variable that maps X to the remainder of the division by m.

   We want to determine the probability distribution of R and quantify
   any bias that arises.

   Since X is uniformly distributed, the probability of X taking any
   specific value v in [0, M) is 1/M.

   Using the results from Lemma 1 below, we can determine the
   probability distribution of R.

A.1.2.  Case 1: When M is divisible by m (M % m = 0)

   From Lemma 1, each remainder r in [0, m) occurs exactly M/m times
   among the values [0, M).
   Therefore, R is uniformly distributed with:

   p(r) = (M/m) × (1/M) = 1/m for all r in [0, m)

   In this case, there is no bias since all remainders are equally
   likely.

A.1.3.  Case 2: When M is not divisible by m (M % m = s where 0 < s < m)

   From Lemma 1, the remainders have different frequencies:

   *  Remainders r in [0, s) occur floor(M/m) + 1 times each



Vieuille                   Expires 14 May 2026                 [Page 25]

Internet-Draft                  EPHEMSEC                   November 2025


   *  Remainders r in [s, m) occur floor(M/m) times each

   This leads to a non-uniform distribution:

   *  p(r) = p1 = (floor(M/m) + 1)/M for r in [0, s)

   *  p(r) = p2 = floor(M/m)/M for r in [s, m)

A.1.4.  Bias Quantification

   The bias arises because p1 > p2.  We can express this relationship
   as:

   p1 = p2 × (1 + 1/floor(M/m)) = p2 × (1 + bias)

   where:
   bias = 1/floor(M/m)

   This bias factor measures the non-uniformity of the distribution:

   *  bias = 0 when M is divisible by m (uniform case)

   *  bias ∈ (0, 1] when M is not divisible by m, with larger values
      indicating greater non-uniformity

   *  The bias is maximized when floor(M/m) = 1, giving bias = 1

A.2.  Lemma 1: Distribution of Remainders in [0, M)

   Let m and M be integers where m ≤ M and m > 0.

   For any integer r in [0, m), the number of integers v in [0, M) that
   satisfy v % m = r is:

   1.  When M is divisible by m (M % m = 0):

       *  Exactly M/m values for every r in [0, m)

   2.  When M is not divisible by m (M % m = s where 0 < s < m):

       *  floor(M/m) + 1 values for r in [0, s)

       *  floor(M/m) values for r in [s, m)

A.2.1.  Proof:






Vieuille                   Expires 14 May 2026                 [Page 26]

Internet-Draft                  EPHEMSEC                   November 2025


   For r in [0, m) let count(r) be the count of v satisfying v % m = r for v in [0, M)

   Any v, such that v % m = r can be written as v = q·m + r where q ≥ 0
   To keep v in [0, M), we must have q ≤ (M - 1 - r)/m, hence
   count(r) = floor((M -1 - r)/m) + 1

   When M = k·m (divisible case):

   - count(r) = floor((k·m - 1 - r)/m) + 1 = k = M/m

   When M = k·m + s (non-divisible case):

   - For r < s: count(r) = k + 1
   - For r ≥ s: count(r) = k

Appendix B.  Design Rationale

   The EPHEMSEC algorithm has undergone several implementation
   iterations, initially starting by modifying the HOTP algorithm
   described in [RFC4226] to achieve the desired security properties.

   The following sections explain the rationale behind key design
   choices.

B.1.  Use of HKDF

   HKDF was chosen over the [RFC4226] HMAC approach for two reasons:

   1.  The HKDF domain separation feature enabled by the HKDF salt
       parameter (see Section 10.2) provides the necessary context
       binding used for phishing protection.

   2.  HKDF allows adjusting output size, which reduces the complexity
       of supporting the range of OTP/OTK sizes supported by EPHEMSEC
       (see Table 1).

B.2.  Usage of PSK

   The inclusion of a pre-shared key (PSK) ensures that generated OTP/
   OTKs are always a *mutual* secret, which the E1S1 pattern (see
   Section 5.3.1) alone cannot guarantee.

   The incremental cost of mixing the PSK (see Section 6.1) into the
   HKDF ikm input (see Section 10.2) is expected to be low, and the PSK
   improves the secrecy of ikm.  Therefore, it is always used even when
   the pattern (e.g., E1S2; see Section 5.3.2) already provides the
   desired *mutual* secrecy.




Vieuille                   Expires 14 May 2026                 [Page 27]

Internet-Draft                  EPHEMSEC                   November 2025


B.3.  Usage of Nonces

   The design requires that both the Initiator and Responder contribute
   a nonce and are responsible for ensuring that their respective nonces
   are not reused.

   Although both parties currently contribute a nonce, the Initiator’s
   nonce may not be strictly required.  Since the Initiator already
   contributes an ephemeral public key, this element provides sufficient
   entropy and freshness for the session.  The Initiator’s nonce is
   therefore retained primarily to simplify the security analysis and
   preserve symmetry in the protocol design.  Future revisions of this
   specification may remove it if it is shown to be redundant.

B.3.1.  Transmission of the Responder Nonce

   When using OTP output, bandwidth between the Responder and the
   Initiator is severely constrained.  Therefore, a synchronization
   digit SYNCHINT is used to "compress" the Responder nonce PTIME (see
   Section 8.2).

   When using OTK output, it is assumed that the application has
   addressed the bandwidth limitations that necessitate OTP output, and
   therefore PTIME could potentially be transmitted in uncompressed
   form.

   However, explicit support for uncompressed transmission was not
   included for two reasons:

   1.  The computational cost of running the synchronization algorithm
       to recover PTIME from SYNCHINT is very low.

   2.  Having the server rely on SYNCHINT to reconstruct PTIME limits
       the Responder's ability to reuse its own nonces, which provides
       additional security benefits.

Appendix C.  Test Vectors

   A minimal set of test vectors is provided for OTP and OTK schemes
   that use the SHA512 hash function and the X25519 ECDH function.

   The [KerPass] open source project provides an extensive set of
   vectors that allow testing EPHEMSEC output generated using common
   hash functions and curves.

C.1.  Kerpass_SHA512_X25519_E1S1_T600B10P8 vector





Vieuille                   Expires 14 May 2026                 [Page 28]

Internet-Draft                  EPHEMSEC                   November 2025


   {
     "scheme": "Kerpass_SHA512_X25519_E1S1_T600B10P8",
     "context": "a33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe",
     "psk": "55a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e",
     "shared_secret": "0803020700020800",
     "otp": "83270280",
     "init_nonce": "d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a",
     "init_time": 4134179892,
     "init_static_key": "",
     "init_ephemeral_key": "50d2af0ee110bd06604eb03e57a37763c9194400015290f3ef612be18ecd0583",
     "init_remote_static_key": "f1e1116982475e7fd252a2ca69c1459b3a4439029fa3f33059d7e657b3318912",
     "init_remote_ephemeral_key": "",
     "resp_time": 4134179984,
     "resp_synchro_hint": 0,
     "resp_static_key": "fad1034e60389317dd0e405c84fff2d17248fa1112d66a1979515ddf65a44a06",
     "resp_ephemeral_key": "",
     "resp_remote_static_key": "",
     "resp_remote_ephemeral_key": "0fc4c28b9d85a476a1b664050901c78c9b4ff69bde707829bd1e05e5602a3d55",
     "hkdf_salt": "432fa33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe53244b6572706173735f5348413531325f5832353531395f453153315f543630304231305038",
     "hkdf_info": "4e13d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a54080000000003b23d1c",
     "hkdf_secret": "31215fcaafce8df63bd3a21371d15233501da05b5c52248fb6d4cafbdad20d3655a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e"
   }

C.2.  Kerpass_SHA512_X25519_E1S2_T600B16P8 vector

   {
     "scheme": "Kerpass_SHA512_X25519_E1S2_T600B16P8",
     "context": "037f9aae0e39c770b7c216572382e1b78ccff597a27aeb004cd14c881fe1944eb630e8af0f9840b1ef3ffaf2cf697fb0a08d9cacd5e8c5ff4a1be583b4",
     "psk": "a2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d",
     "shared_secret": "0e0f0b02070e020e",
     "otp": "EFB27E2E",
     "init_nonce": "a5ddd81c502e054357c58ac483b8d39ce1e7",
     "init_time": 568923577,
     "init_static_key": "77166d9d14b2cc221a3829f600aad1f2f18872e8a7e7cb7aae2def72b69bff58",
     "init_ephemeral_key": "90533d33305a90560bfef99d07c496ca92ef5001b62441860509af3d226d8ba4",
     "init_remote_static_key": "dc94881a2063e4d30a0e7fe377838202e542b46d8836e57187e9abef99216078",
     "init_remote_ephemeral_key": "",
     "resp_time": 568923459,
     "resp_synchro_hint": 14,
     "resp_static_key": "dcad0c9e9aafe811761199f7e2286fda5036e5f5fc6f98c5f4b97fce71532ef8",
     "resp_ephemeral_key": "",
     "resp_remote_static_key": "176198d01d29325b022a5efff4d315bbf9fb4a07755d19581f857754797f6b54",
     "resp_remote_ephemeral_key": "ecb63fa01c06b8d2c4de23d1abc4a5d57647481fbed22fb5866fda4c7989103c",
     "hkdf_info": "4e12a5ddd81c502e054357c58ac483b8d39ce1e754080000000000d906ee",
     "hkdf_secret": "ca2a1d1f71d686ad52f6ef62571d38a5d579f96a86150861e736ea3e71aeba59c85cae9ec5404221a87423eaf952c151bc74b0213fa8a41fba0786ccf315fd5ba2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d"
   }




Vieuille                   Expires 14 May 2026                 [Page 29]

Internet-Draft                  EPHEMSEC                   November 2025


C.3.  Kerpass_SHA512_X25519_E2S2_T600B32P9 vector

   {
     "scheme": "Kerpass_SHA512_X25519_E2S2_T600B32P9",
     "context": "9e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b",
     "psk": "3ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee",
     "shared_secret": "13010a191603100111",
     "otp": "K1ASP3G1H",
     "init_nonce": "716fbb9b9872e0b49dce2723a52ade9d5fdc59",
     "init_time": 2246779725,
     "init_static_key": "6a846ddc06f426e60dd4ae3fbd5b9b06286abc3862e473855e89a138c56ea0b2",
     "init_ephemeral_key": "aa2b0e1b2e4704f08a377ba26e4475aaf1aab010fb8c6ad4bf63890816d3d3f2",
     "init_remote_static_key": "acc4416cd58c4a1a43272253c75a8f27708174f24548466757e13374e161c74b",
     "init_remote_ephemeral_key": "d32119b92d8a61d0c204a4355c86e19c7027376c2e42be84ffa907a1aaec9e6a",
     "resp_time": 2246779996,
     "resp_synchro_hint": 17,
     "resp_static_key": "6716e0cf047f6721662c501ad15f9884cada29210c019c7df566a0e71b67b1dd",
     "resp_ephemeral_key": "d45cf4b5736ef3f3fb0d2a98459a304e595276243d4af91aa5ef2366d44ade2e",
     "resp_remote_static_key": "f7c192278ea1c2323e92cc13da9ac5f0a8d53ac879eadbd774413c66659d865e",
     "resp_remote_ephemeral_key": "86e53308c5bcefe25707f0ffee26cbdc260fc98d22fc9f9e53f4c1994347c27c",
     "hkdf_salt": "43199e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b53244b6572706173735f5348413531325f5832353531395f453253325f543630304233325039",
     "hkdf_info": "4e13716fbb9b9872e0b49dce2723a52ade9d5fdc5954080000000006eb4bb1",
     "hkdf_secret": "36d0bdc70509bb9cff6f2d899e4b9dd261c91da06604f43e408e96da1253827fc37f09bdd64436333faab1150a0bd26d9c8ef3d5935e175b9db3c5ebacdbe7633ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee"
   }

C.4.  Kerpass_SHA512_X25519_E1S2_T1024B256P33 vector

























Vieuille                   Expires 14 May 2026                 [Page 30]

Internet-Draft                  EPHEMSEC                   November 2025


   {
     "scheme": "Kerpass_SHA512_X25519_E1S2_T1024B256P33",
     "context": "c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e1",
     "psk": "aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe",
     "shared_secret": "8479fca69f6d1dbc9164f20eaa4d799ba3b8dae83f915864766fa66d4cae17422c",
     "otp": "",
     "init_nonce": "5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e054357",
     "init_time": 3762980154,
     "init_static_key": "6fda5036e5f5fc6f98c5f4b97fce71532ef8d077166d9d14b2cc221a3829f600",
     "init_ephemeral_key": "4e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfef99d07",
     "init_remote_static_key": "2f92f4b84f1b107ca934e641f34bfae2b2251e9b70876cd1a256301f8f3ccc0e",
     "init_remote_ephemeral_key": "",
     "resp_time": 3762980663,
     "resp_synchro_hint": 44,
     "resp_static_key": "c496ca92ef5001b62441860509af3d226d8ba4dcad0c9e9aafe811761199f7e2",
     "resp_ephemeral_key": "",
     "resp_remote_static_key": "c52b20d6825127ecb33dfff5c1d9a0ed7f57b41eda1dd6855d7ad6268372fc70",
     "resp_remote_ephemeral_key": "6a5a0dd77082720ebd55bcab514a68be8db117af5a17fbb06a7e035e44959307",
     "hkdf_salt": "4318c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e153274b6572706173735f5348413531325f5832353531395f453153325f543130323442323536503333",
     "hkdf_info": "4e1c5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e05435754080000000037da8f2c",
     "hkdf_secret": "04b954ad9d6d42e39217b6a32ae83bc52ba662a39e2bcf18240e6b07034a8c4c86e7a23622ce6b4cd46665d4309b624dd16fa39e57c86c7daf115ddd17f24039aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe"
   }

Author's Address

   Marc Vieuille
   Email: marc.vieuille@polytechnique.org
























Vieuille                   Expires 14 May 2026                 [Page 31]


name: draft-narajala-ans
rev: 00
title: Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability
time: 2025-11-18T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-11-17T16:44:18Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "A2A protocols", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:06.864813+00:00
abstract:
The proliferation of AI agents requires robust mechanisms for secure
   discovery.  This document introduces the Agent Name Service (ANS), a
   novel architecture based on DNS addressing the lack of a public agent
   discovery framework.  ANS provides a protocol-agnostic registry
   mechanism that leverages Public Key Infrastructure (PKI) certificates
   for verifiable agent identity and trust.  The architecture features
   several key innovations: a formalized agent registration and renewal
   mechanism for lifecycle management; DNS-inspired naming conventions
   with capability-aware resolution; a modular Protocol Adapter Layer
   supporting diverse communication standards (A2A, MCP, ACP, etc.); and
   precisely defined algorithms for secure resolution.  This
   specification describes structured communication using JSON Schema
   and includes a comprehensive threat analysis.  The result is a
   foundational agent directory service protocol addressing the core
   challenges of secure discovery and interaction in multi-agent
   systems, paving the way for future interoperable, trustworthy, and
   scalable agent ecosystems.

full_text:
Independent Submission                                          K. Huang
Internet-Draft                                        DistributedApps.ai
Intended status: Experimental                              V.S. Narajala
Expires: 17 November 2025                            Amazon Web Services
                                                               I. Habler
                                                                  Intuit
                                                              A. Sheriff
                                                           Cisco Systems
                                                                May 2025


  Agent Name Service (ANS): A Universal Directory for Secure AI Agent
                     Discovery and Interoperability
                         draft-narajala-ans-00

Abstract

   The proliferation of AI agents requires robust mechanisms for secure
   discovery.  This document introduces the Agent Name Service (ANS), a
   novel architecture based on DNS addressing the lack of a public agent
   discovery framework.  ANS provides a protocol-agnostic registry
   mechanism that leverages Public Key Infrastructure (PKI) certificates
   for verifiable agent identity and trust.  The architecture features
   several key innovations: a formalized agent registration and renewal
   mechanism for lifecycle management; DNS-inspired naming conventions
   with capability-aware resolution; a modular Protocol Adapter Layer
   supporting diverse communication standards (A2A, MCP, ACP, etc.); and
   precisely defined algorithms for secure resolution.  This
   specification describes structured communication using JSON Schema
   and includes a comprehensive threat analysis.  The result is a
   foundational agent directory service protocol addressing the core
   challenges of secure discovery and interaction in multi-agent
   systems, paving the way for future interoperable, trustworthy, and
   scalable agent ecosystems.

Disclaimer

   The present document reflects the authors' individual opinions and
   does not necessarily represent the views of their respective
   employers.

Status of This Memo

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






Huang, et al.           Expires 17 November 2025                [Page 1]

Internet-Draft                     ANS                          May 2025


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

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

   This Internet-Draft will expire on 2 November 2025.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Agent Registry Architecture . . . . . . . . . . . . . . . . .   5
     3.1.  Agent Registration and Renewal  . . . . . . . . . . . . .   8
     3.2.  PKI Integration . . . . . . . . . . . . . . . . . . . . .   9
     3.3.  ANS Protocol Notation . . . . . . . . . . . . . . . . . .  10
     3.4.  Protocol-Agnostic Communication Schema  . . . . . . . . .  12
     3.5.  ANS Naming Structure and Resolution . . . . . . . . . . .  13
       3.5.1.  Formal Naming Structure . . . . . . . . . . . . . . .  14
       3.5.2.  Resolution Process  . . . . . . . . . . . . . . . . .  15
       3.5.3.  Formal Resolution Algorithm . . . . . . . . . . . . .  15
       3.5.4.  Secure Resolution Implementation  . . . . . . . . . .  17
     3.6.  ANS Challenges and Governance . . . . . . . . . . . . . .  18
     3.7.  Agent Identity  . . . . . . . . . . . . . . . . . . . . .  19
   4.  Request/Response Schema for ANS Name Resolution . . . . . . .  24
   5.  Protocol Adapter Layer  . . . . . . . . . . . . . . . . . . .  26
     5.1.  A2A Protocol Adapter  . . . . . . . . . . . . . . . . . .  28
     5.2.  MCP Adapter . . . . . . . . . . . . . . . . . . . . . . .  28
     5.3.  ACP Adapter . . . . . . . . . . . . . . . . . . . . . . .  28



Huang, et al.           Expires 17 November 2025                [Page 2]

Internet-Draft                     ANS                          May 2025


     5.4.  Extension Points  . . . . . . . . . . . . . . . . . . . .  29
     5.5.  Cross-Protocol Interoperability Limits  . . . . . . . . .  29
     5.6.  Protocol Adapter API Definition . . . . . . . . . . . . .  29
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
     6.1.  MAESTRO-Based Threat Analysis . . . . . . . . . . . . . .  32
       6.1.1.  Threat: Agent Impersonation . . . . . . . . . . . . .  32
       6.1.2.  Threat: Registry Poisoning  . . . . . . . . . . . . .  32
       6.1.3.  Threat: Man-in-the-Middle (MitM) Attacks  . . . . . .  33
       6.1.4.  Threat: Denial of Service (DoS) / Distributed Denial of
               Service (DDoS)  . . . . . . . . . . . . . . . . . . .  34
     6.2.  Additional Security Controls and Considerations . . . . .  34
       6.2.1.  PKI Security Controls . . . . . . . . . . . . . . . .  34
       6.2.2.  ANS-Specific Security Controls  . . . . . . . . . . .  35
       6.2.3.  Protocol Integration Security . . . . . . . . . . . .  35
       6.2.4.  Side-Channel Deanonymization and Mitigation . . . . .  35
   7.  Implementation Considerations . . . . . . . . . . . . . . . .  36
   8.  Future Considerations . . . . . . . . . . . . . . . . . . . .  38
   9.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  40
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  41
     11.2.  Informative References . . . . . . . . . . . . . . . . .  41
   Appendix A.  Appendix A: Complete Request/Response Schemas  . . .  43
   Appendix B.  Appendix B: Glossary of Terms - Agent Name Service
           (ANS) . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  47
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

1.  Introduction

   Agent-to-agent communication is expected to become a significant
   component of internet traffic, driving the need for reliable
   mechanisms enabling agents to discover, verify, and securely interact
   with one another.  Traditional service discovery, notably the Domain
   Name System (DNS) [RFC1035], primarily maps human-readable names to
   network addresses and is insufficient for the dynamic, semantically
   rich, and security-sensitive environment of agentic AI.  Enhancements
   like DNS-Based Service Discovery (DNS-SD) [RFC6763] offer
   improvements but still fall short of the necessary agent capability
   granularity, identity verification, and lifecycle management required
   by autonomous agents.  Furthermore, maintaining a trustworthy
   registry necessitates robust processes for agent registration and
   periodic renewal.

   Several agent communication protocols are emerging to standardize
   interactions:





Huang, et al.           Expires 17 November 2025                [Page 3]

Internet-Draft                     ANS                          May 2025


   *  Agent2Agent (A2A) Protocol: Developed by Google, providing a
      standardized protocol for inter-agent communication, aiming to
      bridge different agent frameworks.

   *  Model Context Protocol (MCP): Focused on simplifying the
      integration of AI models with external tools and data sources.

   *  Agent Communication Protocol (ACP): Designed to standardize how
      agents communicate, enabling automation, collaboration, UI
      integration, and developer tooling, evolving from initial MCP
      concepts.

   This document outlines the Agent Name Service (ANS), a framework for
   a protocol-agnostic Agentic AI Registry.  ANS complements these
   emerging protocols by integrating Public Key Infrastructure (PKI) for
   identity and trust, defining structured communication via JSON
   Schema, incorporating DNS-like naming for discovery, establishing
   mechanisms for agent registration and renewal, and providing a formal
   specification of the protocol to enhance precision and
   implementability.  ANS aims to provide a universal, secure directory
   service foundation for interoperable agent ecosystems.

1.1.  Requirements Language

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

2.  Related Work

   Traditional service discovery, such as DNS [RFC1035], provides
   essential name-to-address resolution but lacks the semantic
   understanding and security features needed for agentic AI.  DNS-SD
   [RFC6763] adds local service discovery capabilities but doesn't
   address verifiable identity or complex agentCapability matching on a
   global scale.

   Research in multi-agent systems (MAS) has explored various agent
   communication languages (ACLs), such as those defined by the
   Foundation for Intelligent Physical Agents (FIPA) [FIPA-ACL].  While
   influential, these often lack standardized, built-in security
   mechanisms and universally adopted transport protocols suitable for
   the modern internet.

   The emerging protocols represent significant advancements:




Huang, et al.           Expires 17 November 2025                [Page 4]

Internet-Draft                     ANS                          May 2025


   *  A2A [A2A-Blog] [A2A-Spec] focuses on bridging agent ecosystems.

   *  MCP [MCP-News] [MCP-Spec] emphasizes dynamic discovery and
      integration of tools/data for AI models.

   *  ACP [IBM-ACP-Placeholder] targets broader agent-to-agent
      communication needs, including delegation and orchestration.

   Our work builds upon these efforts not by replacing them, but by
   providing a complementary, protocol-agnostic infrastructure layer.
   ANS differentiates itself by integrating PKI-based identity
   verification [RFC5280] directly into the discovery and lifecycle
   management process, offering a universal registry mechanism that
   enhances trust and facilitates secure interaction across different
   protocol standards via a common discovery plan.  Furthermore, the
   formalized specification of the ANS protocol ensures clarity and ease
   of implementation.

3.  Agent Registry Architecture

   The proposed Agent Registry architecture provides a secure,
   interoperable platform for agent discovery and interaction,
   supporting multiple communication protocols through a modular design.
   Key components include:

   *Requesting Agent:*
      The entity initiating the agent registration process, which could
      be an individual, organization, or automated system seeking to
      register a new agent or update existing agent information in the
      registry.

   *Agent Registry:*
      A potentially distributed database for storing ACEM (Agent
      Credential and Entitlement Management) and DID (Decentralized
      Identifier) related information.  This registry encompasses agent
      capabilities, security policies, PKI certificates, protocol-
      specific metadata (via protocolExtensions), and registration/
      renewal timestamps, supporting a comprehensive framework for agent
      identity, authentication, and authorization.

   *Certificate Authority (CA):*
      A trusted entity issuing and managing X.509 digital certificates
      [RFC5280] for agents, forming the root of trust.








Huang, et al.           Expires 17 November 2025                [Page 5]

Internet-Draft                     ANS                          May 2025


   *Registration Authority (RA):*
      Verifies agent registration/renewal requests, interacts with the
      CA to issue certificates based on Certificate Signing Requests
      (CSRs), manages the agent lifecycle (registration, renewal,
      revocation), and validates the legal entity of the Requesting
      Agent.  It enforces registry policies.

   *Protocol Adapter Layer:*
      Translates between the registry's internal representation and
      protocol-specific formats (details in Section 5).

   *Request/Response Schema:*
      A protocol-agnostic JSON-based schema [RFC8259] for registry
      interactions (discovery, registration, etc.), incorporating PKI
      data and allowing protocol-specific extensions (details in
      Section 3.4).

   *Agent Name Service (ANS):*
      Enables agent discovery using human-readable, structured names,
      coupled with agentCapability-based resolution (details in
      Section 3.5).

   Figure 1 illustrates the core components of the Agent Name Service
   (ANS) and their interactions.

   <preamble>:Illustrates the interaction between Agent, ANS Service, Agent Registry, CA, RA, and Protocol Adapter Layer.
        
+-----------+    Requests agent discovery    +-------------+
|   Agent   | ----------------------------> | ANS Service |
+-----------+                               +-------------+
                                                      |
                                                      | Looks up agent info
                                                      v
+-----------------------+    Translates messages    +----------------+
| Protocol Adapter Layer| <---------------------- | Agent Registry |
+-----------------------+                         +----------------+
                                                      ^      ^
                                                      |      | Verifies
                                Validates reg.        |      | identity
                                                      |      |
                                +-----------------------+  +---------------------+
                                | Registration Authority|  | Certificate Authority |
                                +-----------------------+  +---------------------+

                      Figure 1: ANS Architecture






Huang, et al.           Expires 17 November 2025                [Page 6]

Internet-Draft                     ANS                          May 2025


   The Protocol Adapter Layer translates between the registry's internal
   representation and protocol-specific formats.  For example, consider
   an agent registering with the MCP.  An MCP tool description might be
   represented as a JSON blob.  The agent would need to be registered
   with ANS first and foremost.  Therefore, imagine this tool is
   associated with the following ANSName:
   "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0".

   This would mean the MCP tool is now discoverable via the ANS.  The
   MCP specific extension data itself might look like this:

   {
     "description": "Analyzes sentiment of text input.",
     "input_schema": {
       "type": "string",
       "description": "Text to analyze."
     },
     "output_schema": {
       "type": "object",
       "properties": {
         "sentiment": {
           "type": "string",
           "enum": ["positive", "negative", "neutral"]
         },
         "score": {
           "type": "number",
           "description": "Sentiment score (-1 to 1)."
         }
       }
     },
     "mcpEndpoint": "https://sentiment.example.com/analyze"
   }

                    Figure 2: Example MCP Extension Data

   The MCP Adapter within the Protocol Adapter Layer would parse this
   JSON and map it to the registry's internal columns.  This could
   involve:

   *  Extracting information implicitly: since the ANSName is
      "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0", this
      implicitly defines the:

      -  Protocol: mcp

      -  AgentID: sentimentAnalyzer

      -  agentCapability: textAnalysis



Huang, et al.           Expires 17 November 2025                [Page 7]

Internet-Draft                     ANS                          May 2025


      -  Provider: ExampleCorp

      -  Version: v1.0

   *  Storing the description ("Analyzes sentiment of text input.") in a
      dedicated description field within protocolExtensions.

   *  Serializing the input_schema and output_schema and storing them in
      a protocolExtensions column specific to MCP, allowing other MCP-
      aware agents to understand the tool's interface.

   *  The actual MCP endpoint "https://sentiment.example.com/analyze"
      would be stored within the protocolExtensions, under the key
      mcpEndpoint.

   This normalization process allows the Agent Registry to store and
   query MCP-specific information in a protocol-agnostic way, while
   adhering to the ANSName structure for consistent identification and
   resolution.

3.1.  Agent Registration and Renewal

   Maintaining registry integrity requires explicit lifecycle
   management:

   *Registration*:

   1.  An agent submits a registration request (conforming to the
       defined JSON schema, see Section 3.4) including metadata,
       protocol details (within protocolExtensions), and a CSR.

   2.  The RA validates the agent's identity and submitted information
       against registry policies (potentially involving automated checks
       or human review).

   3.  The RA requests a certificate from the CA using the validated
       CSR.

   4.  The issued certificate and agent information are stored in the
       Agent Registry.

   *Renewal*:

   1.  Agents periodically submit renewal requests before their
       registration or certificate expires.

   2.  The RA verifies continued compliance with policies.




Huang, et al.           Expires 17 November 2025                [Page 8]

Internet-Draft                     ANS                          May 2025


   3.  The RA requests a new certificate from the CA.

   4.  The agent's registration/renewal timestamp and potentially
       updated certificate are stored in the Registry.

   *Deregistration/Revocation*: Agents can be deregistered, or their
   certificates revoked (e.g., due to key compromise), removing or
   flagging their entry in the registry and invalidating their
   certificate via standard PKI mechanisms (CRL/OCSP [RFC6960]).

Agent                           RA                               CA                       Agent Registry
  |---Registration Request--->|                                  |                                |
  | (metadata & CSR)        |                                  |                                |
  |                           |---Validate Identity----->|                                  |
  |                           |<--[Validation Fails]-----|                                  |
  |<----Registration Rejected-|                                  |                                |
  |                           |---[Validation Successful]->                                  |
  |                           |---Request Certificate--->|                                  |
  |                           |                          |<----Issue Certificate----|
  |                           |<----Certificate----------|                                  |
  |                           |---Store Agent Info & Cert-------------------------->|
  |<----Confirmation---------|                                                          |

                 Figure 3: Agent Registration Process

3.2.  PKI Integration

   Public Key Infrastructure (PKI) [RFC5280] provides the cryptographic
   foundation for trust within ANS.  Each registered agent possesses a
   unique PKI key pair and a corresponding X.509 digital certificate
   issued by a trusted CA via the RA.

   *Identity Verification:*
      The agent's certificate cryptographically binds its public key to
      its verified identity (e.g., its ANSName, organizational
      affiliation).  Other agents can verify digital signatures made
      with the agent's private key by using the public key in the
      certificate, thus ensuring the authenticity and integrity of
      communications.

   *Trust Chain:*
      Certificates are validated against the trusted CA, establishing a
      hierarchical chain of trust.  Agents can determine the
      trustworthiness of other agents by tracing their certificates back
      to a common trusted root CA.






Huang, et al.           Expires 17 November 2025                [Page 9]

Internet-Draft                     ANS                          May 2025


   *Lifecycle Management:*
      The validity of an agent's certificate is tied to its registration
      and renewal cycle.  Revoked certificates are managed using
      standard mechanisms like CRLs or OCSP [RFC6960], ensuring that
      compromised or outdated certificates are no longer trusted.

   *Simplification:*
      While managing PKI can be complex, the integrated RA/CA
      interaction within the ANS framework aims to streamline the
      certificate issuance and renewal processes for agent developers
      compared to manual PKI management.

3.3.  ANS Protocol Notation

   We introduce the following notation for defining ANS elements and
   operations:

   1) Top Level Elements:

   *  Protocol: Communication Protocol

   *  AgentID: Agent Identifier

   *  agentCapability: Agent Capability

   *  Provider: Provider Name

   *  Version: Version Number

   *  Extension: Extension Metadata

   *  Cert: Agent Certificate (X.509)

   *  Sig: Digital Signature

   *  ANSName: Agent Name Service Name

   *  Endpoint: a resolvable endpoint

   2) Data Types:

   *  String: Represents a sequence of characters.

   *  Integer: Represents an integer number.

   *  Boolean: Represents a boolean value (true or false).

   *  Set<T>: Represents a set of elements of type T.



Huang, et al.           Expires 17 November 2025               [Page 10]

Internet-Draft                     ANS                          May 2025


   So, the top level elements have the following data types:

   *  Protocol: {a2a, mcp, acp, ...}

   *  AgentID: String

   *  agentCapability: String

   *  Provider: String

   *  Version: String (Semantic Versioning)

   *  Extension: String

   *  Cert: X.509 Certificate

   *  Sig: Digital Signature

   *  ANSName: String

   *  Endpoint: String

   3) Verification Rules:

   Certificate Chain Verification

   VerifyCertChain (Cert, TrustedCA) -> Boolean:
     1. Get the certificate authority (CA_signer) that signed the Cert.
     2. Check for Certificate Revocation status of Cert via CRL or OCSP.
     3. If Cert is Revoked, Return False.
     4. If CA_signer is the TrustedCA, Return True (assuming Cert is validly signed by it and not expired).
     5. Else, get the certificate of CA_signer (IssuerCert) and recursively call
        VerifyCertChain(IssuerCert, TrustedCA).
     6. If no trusted CA is found in the chain, Return False.

           Figure 4: Algorithm 1: Certificate Chain Verification

   Digital Signature Verification

   VerifySignature (Data, Signature, PublicKey) -> Boolean:
     1. Use PublicKey to decrypt/verify the Signature against the Data.
     2. Hash Data using the agreed-upon cryptographic hash function (e.g., SHA-256)
        that was used by the signer.
     3. Compare the hash obtained from the signature with the hash
        calculated from the Data.
     4. If the hashes match and the signature is cryptographically valid,
        Return True.
     5. Else, Return False.



Huang, et al.           Expires 17 November 2025               [Page 11]

Internet-Draft                     ANS                          May 2025


           Figure 5: Algorithm 2: Digital Signature Verification

3.4.  Protocol-Agnostic Communication Schema

   ANS utilizes JSON Schema [RFC8259] to define the structure for all
   registry interactions, including discovery requests/responses and
   registration/renewal requests/responses.  This ensures structured,
   validated communication across different protocols.

   An example AgentRegistrationRequest schema is shown below:

   {
     "$schema": "http://json-schema.org/draft-07/schema#",
     "title": "AgentRegistrationRequest",
     "description": "Schema for Agent Registration Request",
     "type": "object",
     "properties": {
       "protocol": {
         "type": "string",
         "enum": ["a2a", "mcp", "acp"],
         "description": "Communication Protocol"
       },
       "agentID": {
         "type": "string",
         "description": "Unique Agent Identifier"
       },
       "agentCapability": {
         "type": "string",
         "description": "Primary Agent Capability"
       },
       "provider": {
         "type": "string",
         "description": "Name of the Provider"
       },
       "version": {
         "type": "string",
         "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$",
         "description": "Semantic Versioning format"
       },
       "extension": {
         "type": "string",
         "description": "Extension Metadata"
       },
       "certificate": {
         "type": "object",
         "properties": {
           "subject": {"type": "string", "description": "Certificate Subject"},
           "issuer": {"type": "string", "description": "Certificate Issuer"},



Huang, et al.           Expires 17 November 2025               [Page 12]

Internet-Draft                     ANS                          May 2025


           "pem": {
             "type": "string",
             "description": "PEM-encoded Certificate (strongly recommended to use a secure vault reference instead)",
             "readOnly": false
           }
         },
         "required": ["subject", "issuer", "pem"]
       },
       "protocolExtensions": {
         "type": "object",
         "description": "Protocol-specific data"
       }
     },
     "required": ["protocol", "agentID", "agentCapability", "provider", "version", "certificate"]
   }

          Figure 6: Snippet: AgentRegistrationRequest JSON Schema

   *Core Fields:*
      Include common elements like agent communication protocol types
      (a2a, mcp, acp, etc.), requesting/responding agent identifiers,
      timestamps, and PKI certificate details (subject, issuer, PEM
      representation - though referencing a secure vault is recommended
      for the PEM in production).

   *protocolExtensions:*
      A key field within the schema acts as a container for protocol-
      specific data (e.g., an A2A Agent Card, MCP tool descriptions, ACP
      agent profiles).  This allows the registry to store and query
      protocol-specific agentCapabilities while maintaining a common
      core schema.

   *Validation:*
      All interactions with the registry must be validated against these
      schemas.  (Complete schemas are referenced in Appendix A).

3.5.  ANS Naming Structure and Resolution

   ANS defines a robust, protocol-agnostic mechanism for naming and
   resolving agents across heterogeneous agentic environments.  Its
   principal function is to establish a uniform Endpoint format that
   encodes identity, agentCapability, and contextual metadata for any
   given agent, irrespective of the underlying transport or runtime
   architecture.  ANS ensures that both human-readable and machine-
   resolvable identifiers are preserved in a format designed to
   facilitate dynamic discovery, rigorous trust verification, secure
   communication, seamless service composition, and the representation
   of relationships between agents.  A key motivation for ANS is to move



Huang, et al.           Expires 17 November 2025               [Page 13]

Internet-Draft                     ANS                          May 2025


   beyond simple naming resolution to enable precise agentCapability
   discovery, which is not achievable with traditional systems like DNS.
   The design of ANS acknowledges that the agent's agentCapabilities are
   paramount for intelligent interactions, distinguishing it from
   simpler naming systems like DNS.

3.5.1.  Formal Naming Structure

   The ANSName is formally defined as a string constructed from the
   following components, concatenated in a specific order:

ANSName = Protocol "://" AgentID "." agentCapability "." Provider ".v" Version ["." Extension]

                     Figure 7: ANSName Structure

   Where:

   *  Protocol ∈ {a2a, mcp, acp, ...} (Specifies the primary
      communication protocol)

   *  AgentID: A unique identifier for the agent within its provider and
      protocol scope.  (String)

   *  agentCapability: Describes the primary capability or service
      offered by the agent.  (String)

   *  Provider: The name of the entity or organization providing the
      agent.  (String)

   *  Version: The semantic version of the agent (e.g., "1.0.2").
      (String)

   *  Extension (Optional): Used for deployment-specific or provider-
      defined metadata (e.g., "hipaa", "testenv").  (String)

   Constraints:

   *  Version MUST adhere to Semantic Versioning standards.

   *  AgentID, agentCapability, Provider SHOULD be registered with a
      governance authority (similar to ICANN for DNS domains) to prevent
      collisions and ensure uniqueness.

   *  Extension SHOULD be used for deployment-specific or provider-
      defined metadata, not for core identity.  In the actual
      implementation, a registry of reserved tokens for Extension can
      enhance security.




Huang, et al.           Expires 17 November 2025               [Page 14]

Internet-Draft                     ANS                          May 2025


   Example ANSName:
   "a2a://textProcessor.DocumentTranslation.AcmeCorp.v2.1.hipaa"

3.5.2.  Resolution Process

   The resolution mechanism in ANS maps a fully qualified ANSName to an
   actionable reference, such as a network address, service binding, or
   a detailed metadata document (Endpoint).  Resolution can be achieved
   through distributed lookups, local resolver caches, or enterprise-
   specific ANS gateways, providing deployment flexibility.  Critically,
   ANS moves beyond simple name resolution to facilitate precise
   agentCapability discovery.

   When an agent (the "Requesting Agent") requires resolution, it
   queries the ANS service (a fundamental component of the Agent
   Registry infrastructure).  The query includes the ANSName of the
   target agent and can optionally incorporate agentCapability filters
   to refine the search.

Requesting Agent        ANS Service                 Agent Registry          Trusted CA
  |---Resolution Query---->|                           |                       |
  | (ANSName + filters)   |                           |                       |
  |                       |---Query Agent Record--->|                           |
  |                       |                           |<--[Record Not Found]-|
  |                       |<----No Record Found-----|                           |
  |<--Agent Not Found Err--|                           |                       |
  |                       |                           |---[Record Found]---->|
  |                       |<--Return Agent Endpoint-|                           |
  |                       |   (data, sig, cert)     |                           |
  |                       |---Verify Signature (using Agent Registry Key)-->|
  |                       |<--[Signature Invalid]--|                           |
  |<--Invalid Sig Error---|                           |                       |
  |                       |---[Signature Valid]--->|                           |
  |                       |---Verify Cert Chain (Target Agent Cert)------>| (Trusted CA for agent certs)
  |                       |                           |<--[Cert Invalid]-----|
  |                       |<----Invalid Cert Error--|                           |
  |                       |                           |---[Cert Valid]------>|
  |<--Return Verified Endpoint----------------------|                           |
  | (binding & sec info)  |                           |                       |

             Figure 8: Agent Resolution Process Sequence

3.5.3.  Formal Resolution Algorithm

   The ANS resolution algorithm takes an ANSName and an optional
   RequestedVersionRange as input and returns a resolvable Endpoint or
   an error.




Huang, et al.           Expires 17 November 2025               [Page 15]

Internet-Draft                     ANS                          May 2025


   Resolve(ANSName, RequestedVersionRange) -> EndpointRecord / ERROR:
   1. Parse ANSName into Protocol, AgentID, agentCapability,
      Provider, Version, Extension.
   2. Query Agent Registry for Agents with matching Protocol, AgentID,
      agentCapability, Provider.
   3. If no match found:
      Return ERROR("Agent not found").
   4. If multiple matches found (different versions):
      Match = VersionNegotiation(Matches, RequestedVersionRange).
      If Match is ERROR("Incompatible Version"):
        Return ERROR("Incompatible Version").
   5. EndpointRecord_struct = GetAgentEndpointRecord(Match.AgentID).
      // Renamed to avoid conflict, EndpointRecord_struct: {data, signature, Cert}
      If EndpointRecord_struct is ERROR:
        Return ERROR("Could not retrieve endpoint record").
   6. Valid = VerifyAgentEndpointRecord(EndpointRecord_struct,
                                        TrustedCA_for_Registry_Signature,
                                        TrustedCA_for_Agent_Certs).
   7. If Valid is False:
      Return ERROR("Invalid Endpoint").
   8. Return EndpointRecord_struct.data. // Contains the actual endpoint URI/info

   --- Helper Functions ---
   GetAgentEndpointRecord(AgentID_from_Match) -> EndpointRecord_struct / ERROR:
     // Agent Registry implements this to fetch records.
     // This function must enforce authentication and authorization
     // against Agent Registry ACLs if applicable.
     // Returns {data, signature, Cert} or ERROR.

   VerifyAgentEndpointRecord(EndpointRecord_struct, RegistryTrustedCA, AgentCertTrustedCA) -> Boolean:
     // 1. Verify signature on EndpointRecord_struct.data using
     //    AgentRegistry.PublicKey (obtained from a cert issued by RegistryTrustedCA).
     signatureValid = VerifySignature(EndpointRecord_struct.data,
                                      EndpointRecord_struct.signature,
                                      AgentRegistry.PublicKey);
     If not signatureValid:
       Return False; // Or ERROR("Invalid Registry Signature")

     // 2. Verify certificate chain of the target Agent's Cert (EndpointRecord_struct.Cert)
     //    against AgentCertTrustedCA.
     certChainValid = VerifyCertChain(EndpointRecord_struct.Cert, AgentCertTrustedCA);
     If not certChainValid:
       Return False; // Or ERROR("Invalid Agent Certificate Chain")

     Return True;

   // VerifySignature and VerifyCertChain are defined in Section 3.3




Huang, et al.           Expires 17 November 2025               [Page 16]

Internet-Draft                     ANS                          May 2025


   VersionNegotiation(Matches, RequestedVersionRange) -> Match_object / ERROR:
     1. Sort Matches by Version (highest to lowest Semantic Version).
     2. For each Match_item in Matches:
     3.   If RequestedVersionRange is empty OR RequestedVersionRange == "*" OR
            IsVersionCompatible(Match_item.Version, RequestedVersionRange):
     4.       Return Match_item;
     5. End For
     6. Return ERROR("Incompatible Version");

   IsVersionCompatible(AgentVersion, ReqRange) -> Boolean:
     // Implement Semantic Version range compatibility check.
     // (e.g., using a library like node-semver's satisfies function)
     // 1. Attempt to parse ReqRange as a SemVer range.
     // 2. If parsing fails, treat ReqRange as a specific SemVer version.
     // 3. Check if AgentVersion is satisfied by the ReqRange.
     // Example: return SemVer.satisfies(AgentVersion, ReqRange);
     Return true; // Placeholder for actual SemVer library call

                   Figure 9: Algorithm 3: ANS Resolution

   IMPLEMENTATION NOTES:

   *  *Cacheability:* To ensure resolvers know when to re-validate
      EndpointRecords, the Agent Registry MUST include a Time-To-Live
      (TTL) value with each resolved Endpoint.  The TTL indicates the
      number of seconds for which the EndpointRecord can be cached.  A
      recommended default TTL is 300 seconds (5 minutes), but this value
      MAY be adjusted based on factors such as the volatility of the
      agent's configuration or the security policy of the Agent
      Registry.  Resolvers MUST re-validate the EndpointRecord (by
      calling GetAgentEndpointRecord) after the TTL has expired.

   *  *Version Negotiation and Pre-release Tags:* When using
      SemVer.satisfies for version negotiation, pre-release tags (e.g.,
      -rc1, -beta) MUST be considered to have lower precedence than the
      corresponding stable version.  For example, version 1.0.0-rc1
      would be considered lower precedence than 1.0.0.  This ensures
      that resolvers prefer stable versions over pre-release versions
      unless explicitly requested (e.g., by specifying a pre-release
      version range).

3.5.4.  Secure Resolution Implementation

   Key security aspects for the resolution process include:

   *Trust Anchor:*
      The trust anchor for ANS is the Certificate Authority (CA) that
      issues the Agent Registry's own certificate.  The Agent Registry's



Huang, et al.           Expires 17 November 2025               [Page 17]

Internet-Draft                     ANS                          May 2025


      certificate contains the public key used to verify the digital
      signatures on the Agent Registry's responses.  This Agent Registry
      certificate (or its issuing CA) must be trusted by all agents that
      use ANS.  A separate trust anchor (or set of CAs) will be used to
      validate the certificates of the agents themselves.

   *Digital Signatures:*
      All responses from the Agent Registry (containing Endpoint
      information) MUST be digitally signed using the Agent Registry's
      private key.  Clients (Requesting Agents) verify this signature
      using the Agent Registry's public key to ensure the integrity and
      authenticity of the received data.

   *DNSSEC-like Security Considerations:*
      While DNSSEC provides a model for securing DNS, its direct
      application to ANS requires careful evaluation due to potential
      increased risk of DoS amplification attacks from larger crypto-
      fields in responses.  Mitigation strategies like rate limiting,
      traffic filtering, and anycast deployment are crucial if DNSSEC-
      like mechanisms are adopted.

   *Certificate Revocation:*
      A robust and timely mechanism for certificate revocation is
      essential.  If the Agent Registry's private key is compromised,
      its certificate MUST be revoked immediately.  Standard methods
      like CRLs [RFC5280] or OCSP [RFC6960] should be used for both
      Agent Registry and individual agent certificates.

   *Ongoing Threat Modeling:*
      Continuous threat modeling is necessary to identify and
      proactively address potential vulnerabilities in the secure
      resolution mechanism.

3.6.  ANS Challenges and Governance

   Deploying and maintaining a global ANS involves addressing several
   key challenges:

   *Naming Collisions and Squatting:*
      Ensuring the uniqueness of ANSNames, particularly the <AgentID>,
      <agentCapability>, and <Provider> segments, requires a managed
      registration process.  A governance model, potentially similar to
      ICANN's role for DNS, might be necessary to manage top-level
      agentCapabilities, provider identifiers, and resolve disputes.

   *Scalability:*
      Supporting a potentially vast number of agents (billions) requires
      highly scalable registry storage solutions (e.g., distributed



Huang, et al.           Expires 17 November 2025               [Page 18]

Internet-Draft                     ANS                          May 2025


      databases like Cassandra, NoSQL databases) and efficient
      resolution mechanisms (e.g., distributed hash tables (DHTs),
      robust caching layers, geographically distributed resolution
      points).

   *Governance:*
      Establishing clear and comprehensive policies for name allocation,
      dispute resolution, operational practices for CAs and RAs, and
      managing the evolution of the trust infrastructure is crucial for
      the long-term stability, trustworthiness, and adoption of ANS.

3.7.  Agent Identity

   Agent identity within the ANS framework is multifaceted, encompassing
   several components:

   *Cryptographic Identity:*
      The agent's PKI certificate, signed by a trusted CA, provides a
      verifiable cryptographic identity, linking its public key to its
      ANSName and other attributes.

   *Logical Identity:*
      The ANSName itself serves as a human-readable, structured
      identifier that conveys information about the agent's protocol,
      capabilities, provider, and version.

   *Protocol-Specific Identity:*
      Agents may possess identities within their native communication
      protocols (e.g., A2A Agent Card ID, MCP tool identifiers, ACP
      agent URIs).  This information is stored within the
      'protocolExtensions' field of the agent's record in the registry.

   *Verifiable Claims:*
      The registry could support the attachment of digitally signed
      attestations or verifiable credentials to agent profiles, such as
      compliance certifications, capability endorsements, or security
      audit results.

   *Identity linkage:*
      ANS ecosystem leverages the structured naming convention to
      establish relationships between agents.  The core principle is
      that an agent's ANSName serves as a unique and resolvable
      identifier, allowing other agents or the system itself to
      reference it.  The Agent Registry, upon recognizing this request,
      not only returns the target agent's details (binding, metadata,
      certificates) but also automatically resolves the linked agents,
      effectively materializing the relationship and providing all
      necessary information for secure and informed interaction.  This



Huang, et al.           Expires 17 November 2025               [Page 19]

Internet-Draft                     ANS                          May 2025


      automated relationship discovery, built upon the foundation of
      uniquely identifiable and resolvable agent names, significantly
      simplifies the orchestration and coordination of complex multi-
      agent systems.

   *Agent Card Validation:* The integrity of Agent Cards within the ANS
   ecosystem is verified through cryptographic methods, utilizing the
   relational patterns between agents.  This process ensures that
   capability declarations are validated against organizational
   policies.  Additionally, endpoint URL structures are enforced to
   comply with security standards such as TLS and proper domain
   constraints.  The Agent Registry oversees and connects these identity
   components, facilitating verification through challenge-response
   protocols that rely on the agent's private key.  Both the Requesting
   Agent and the Registration Authority (RA) play crucial and distinct
   roles in this validation process.

   *Requesting Agent Responsibility:* The Requesting Agent has a primary
   and ongoing responsibility for validating the Agent Card before every
   interaction.  This includes:

   *  *Cryptographic Verification:* Verifying the Agent Card's digital
      signature to ensure it hasn't been tampered with.

   *  *Capability Alignment:* Confirming that the agent's stated
      capabilities are actually what the Requesting Agent expects and
      needs for the intended interaction.  This might involve checking
      specific input/output schemas or testing the agent's performance
      on sample tasks before relying on it for critical operations.

   The Requesting Agent's validation is not a one-time event; it's a
   continuous process that ensures the agent remains trustworthy for
   each specific interaction.  A failure to properly validate an Agent
   Card could expose the Requesting Agent to significant security risks.

   *Registration Authority (RA) Responsibility:* The RA performs a
   foundational validation of the Agent Card during the agent
   registration and renewal processes.  This includes:

   *  *Signature Verification:* Verifying the Agent Card's signature and
      the validity of the associated certificate.

   *  *Policy Adherence:* Ensuring the agent's claimed capabilities and
      operational practices comply with broader registry policies and
      legal requirements.






Huang, et al.           Expires 17 November 2025               [Page 20]

Internet-Draft                     ANS                          May 2025


   *  *Legitimacy Checks:* Performing checks to confirm the identity and
      legitimacy of the agent's owner (e.g., domain validation,
      organizational checks).

   The RA's validation provides a baseline level of trust, but it does
   not replace the need for the Requesting Agent to perform its own,
   more context-specific validation.

   Additionally, endpoint URL structures are enforced to comply with
   security standards such as TLS and proper domain constraints.  The
   Agent Registry oversees and connects these identity components,
   facilitating verification through challenge-response protocols that
   rely on the agent's private key.

   *Agent Capability Attestation:* The AI agent's identity and claimed
   capabilities are authenticated through zero-knowledge proof methods.
   Specifically, ZKPs can be employed to allow an agent to prove that it
   possesses certain capabilities (e.g., access to specific data, the
   ability to perform a certain computation) without revealing how it
   possesses those capabilities or the underlying data itself.  For
   example, an agent might use a ZKP to prove it has access to a
   database containing sensitive patient information without revealing
   the specific query it will use or any of the patient data.  This
   involves the agent constructing a proof, based on its private
   knowledge and the claimed capabilities, that can be verified by the
   Agent Registry (or another agent) using only publicly available
   information.

   The verifier gains assurance that the agent possesses the claimed
   capabilities without learning any sensitive information about the
   agent's internal state or data.  During runtime, capabilities are
   dynamically validated as part of the resolution process.  To further
   enhance real-time verification, challenge-response mechanisms are
   employed.

   *Challenge-Response Example:* Imagine an agent claims to be able to
   perform "Sentiment Analysis" with a certain accuracy.

   *  The Agent Registry (or a verifying agent) sends the claimed
      "Sentiment Analysis" agent a specific challenge: a piece of text
      with a known sentiment.

   *  The "Sentiment Analysis" agent processes the text and returns its
      sentiment classification (positive, negative, neutral) and a
      confidence score.

   *  The Agent Registry (or verifying agent) compares the agent's
      response to the known sentiment and the claimed accuracy.



Huang, et al.           Expires 17 November 2025               [Page 21]

Internet-Draft                     ANS                          May 2025


   *  If the response is correct and the confidence score aligns with
      the agent's claimed accuracy, the agent's capability is considered
      validated (for that specific challenge).

   *  If the response is incorrect or the confidence score is
      significantly lower than the claimed accuracy, the agent's claimed
      capability is called into question and further challenges or even
      revocation of the agent's registration might be triggered.

   This challenge-response process can be repeated periodically or
   triggered based on certain events (e.g., a change in the agent's
   code, a security alert).  The challenges can be designed to test
   various aspects of the agent's claimed capabilities, ensuring that it
   continues to function as expected over time.  The Agent Registry
   maintains a history of challenge-response results to track the
   agent's performance and reliability.

   By combining ZKPs for initial capability attestation with challenge-
   response mechanisms for ongoing validation, the ANS provides a robust
   framework for ensuring the trustworthiness of AI agents.

   *Authentication Enforcement:* The process involves validating the
   OAuth 2.0 flow to ensure the legitimacy of authorization tokens,
   verifying mTLS certificates to confirm alignment with the registered
   agent's identity, and checking JSON Web Tokens (JWTs) to ensure their
   signatures and claims are accurate and properly authenticated.

   *Agent Identity Module Examples:* The Agent Identity module
   implements resource access control through capability-based security.
   Below are examples for A2A and MCP protocols:





















Huang, et al.           Expires 17 November 2025               [Page 22]

Internet-Draft                     ANS                          May 2025


   {
     "a2aCapabilityVerification": {
       "capabilityVerification": {
         "proofMechanism": "ZKP",
         "verificationCircuit": {
           "constraints": [
             "agent.hasCapability(c) AND agent.isAuthorized(c)",
             "agent.certificate.isValid() AND agent.certificate.notRevoked()"
           ],
           "proofGeneration": "Groth16",
           "verificationKey": "0x4a8f..."
         }
       },
       "rateLimit": {
         "algorithm": "TokenBucket",
         "refillRate": "100/s",
         "burstCapacity": 500,
         "perCapability": true
       }
     }
   }

               Figure 10: A2A Capability Verification Example




























Huang, et al.           Expires 17 November 2025               [Page 23]

Internet-Draft                     ANS                          May 2025


   {
     "mcpAgentIdentity": {
       "resourceAccessControl": {
         "model": "RBAC+ABAC",
         "policyDecisionPoint": {
           "engine": "OPA",
           "evaluationMode": "distributed"
         },
         "contextAttributes": [
           "agent.role",
           "resource.classification",
           "time.window",
           "operation.sensitivity"
         ]
       },
       "toolRegistration": {
         "sandboxValidation": {
           "environment": "gVisor",
           "runtime": "V8Isolate",
           "memoryLimit": "256MB",
           "cpuQuota": "0.5",
           "networkPolicy": "DENY_ALL"
         }
       }
     }
   }

                   Figure 11: MCP Agent Identity Example

   The Agent Registry manages and links these identity facets, enabling
   verification via challenge-response protocols using the agent's
   private key.

4.  Request/Response Schema for ANS Name Resolution

   The following core JSON Schemas define the structure for
   AgentCapability requests (used for resolving ANSNames) and responses.
   These ensure validated and structured communication for discovery
   operations.  (Full schemas are linked in Appendix A).

   AgentCapabilityRequest Schema:










Huang, et al.           Expires 17 November 2025               [Page 24]

Internet-Draft                     ANS                          May 2025


   {
     "$schema": "http://json-schema.org/draft-07/schema#",
     "title": "AgentCapabilityRequest",
     "description": "Schema for Agent agentCapability Request (Resolution)",
     "type": "object",
     "properties": {
       "requestType": { "type": "string", "enum": ["resolve"] },
       "protocol": { "type": "string",
                     "description": "Target protocol (from ANSName)"},
       "agentID": { "type": "string",
                    "description": "Target agentID (from ANSName)"},
       "agentCapability": { "type": "string",
                            "description": "Target capability (from ANSName)"},
       "provider": { "type": "string",
                     "description": "Target provider (from ANSName)"},
       "version": { "type": "string",
                    "description": "Target version or version range (from ANSName or query)" },
       "extension": { "type": "string",
                      "description": "Target extension (from ANSName, optional)"}
     },
     "required": ["requestType", "protocol", "agentID",
                  "agentCapability", "provider", "version"]
   }

               Figure 12: AgentCapabilityRequest JSON Schema

   AgentCapabilityResponse Schema:
























Huang, et al.           Expires 17 November 2025               [Page 25]

Internet-Draft                     ANS                          May 2025


   {
     "$schema": "http://json-schema.org/draft-07/schema#",
     "title": "AgentCapabilityResponse",
     "description": "Schema for Agent agentCapability Response (Resolution)",
     "type": "object",
     "properties": {
       "Endpoint": {
         "type": "string",
         "description": "Resolved agent address/endpoint URI (e.g., a2a://translatorBot.DocumentTranslation.exampleCorp.v1.2.3.secure)"
       },
       "signature": {
         "type": "string",
         "description": "Digital signature of the Endpoint data by Agent Registry"
       },
       "cert": {
         "type": "string",
         "description": "PEM-encoded Certificate of the target Agent (strongly recommended to use a secure vault reference instead)",
         "readOnly": false
       }
     },
     "required": ["Endpoint", "signature", "cert"]
   }

               Figure 13: AgentCapabilityResponse JSON Schema

   Key points regarding schemas:

   *  Use a JSON Schema validator library for enforcement.

   *  Pay close attention to required fields and data type constraints.

   *  Validate all incoming and outgoing messages related to ANS
      resolution against these schemas.

   *  Implement graceful error handling for validation failures.

   *  Monitor evolving standards in agent communication (A2A, MCP, ACP)
      and update schemas as necessary to maintain compatibility and
      incorporate new features.

5.  Protocol Adapter Layer

   The Protocol Adapter Layer is a critical component that enables the
   ANS registry to support diverse agent communication protocols (like
   A2A, MCP, ACP) without being tightly coupled to any single one.  It
   acts as an intermediary, translating between the registry's core
   logic and internal data storage format and the specific requirements
   and metadata formats of each supported protocol.



Huang, et al.           Expires 17 November 2025               [Page 26]

Internet-Draft                     ANS                          May 2025


   *Modularity:*
      Adapters are implemented as distinct, pluggable modules (e.g.,
      plugins or separate services).  This allows for easy addition of
      support for new protocols or updates to existing ones without
      altering the core registry logic.

   *Functionality:*
      Each protocol adapter understands how to:

      *  Parse protocol-specific metadata (e.g., from an A2A Agent Card,
         MCP Tool Description) and map relevant parts into the
         registry's internal representation, especially within the
         'protocolExtensions' field of an agent's record.

      *  Extract information from an agent's registry record to
         construct responses to protocol-specific discovery queries.

      *  Potentially handle protocol-specific aspects of the
         registration or validation process if they differ significantly
         from the generic ANS procedures.

   *Each adapter is responsible to securely implement features
   defined by each protocol.*
      Some protocols have built-in security, such as signed messages.

   *Translation Focus:*
      Adapters primarily focus on metadata translation for the purposes
      of discovery and registration.  They do not typically handle real-
      time message translation between different protocols during agent-
      to-agent interaction.  Their role is to help agents find each
      other and verify identity; subsequent communication generally uses
      the agents' shared native protocol.

   *Security aspect:*
      *  All adapter implementations must use secure, up-to-date
         libraries commonly employed for the supported protocols.

      *  Implementations MUST adhere to the security guidance provided
         by each specific protocol.

      *  Since each adapter parses potentially untrusted blobs of data
         (protocol-specific metadata), it is MANDATED that they be
         implemented in memory-safe languages (e.g., Rust, Go) and be
         accompanied by formal test suites to ensure robustness against
         parsing vulnerabilities.

    <preamble>:Conceptual flow showing ANS interacting with different agent protocols via their respective adapters.
        



Huang, et al.           Expires 17 November 2025               [Page 27]

Internet-Draft                     ANS                          May 2025


                                 +-----------------+
                                 | Agent Name      |
                                 | Service (ANS)   |
                                 | (Core Registry) |
                                 +-----------------+
                                   /      |      \
                                  /       |       \
                                 v        v        v
         +-----------------+   +-----------------+   +-----------------+
         | A2A Protocol    |<->| MCP Protocol    |<->| ACP Protocol    |
         | Adapter         |   | Adapter         |   | Adapter         |
         +-----------------+   +-----------------+   +-----------------+
                 ^                       ^                       ^
                 |                       |                       |
                 v                       v                       v
         +-----------------+   +-----------------+   +-----------------+
         | A2A Agent       |   | MCP Agent       |   | ACP Agent       |
         +-----------------+   +-----------------+   +-----------------+

             Figure 14: Protocol Adapter Layer Interaction

5.1.  A2A Protocol Adapter

   *  Parses/stores A2A Agent Card information within
      protocolExtensions.

   *  Enables discovery based on A2A agentCapabilities advertised in the
      card.

   *  Facilitates finding A2A Endpoints listed in the card.

5.2.  MCP Adapter

   *  Parses/stores MCP Tool and Resource descriptions within
      protocolExtensions.

   *  Enables discovery of agents offering specific MCP tools/resources.

   *  Facilitates finding MCP-compliant Endpoints.

5.3.  ACP Adapter

   *  Parses/stores ACP agent profiles and agentCapability
      advertisements within protocolExtensions.

   *  Supports discovery based on ACP roles or agentCapabilities.





Huang, et al.           Expires 17 November 2025               [Page 28]

Internet-Draft                     ANS                          May 2025


   *  May assist in bootstrapping ACP delegation or orchestration
      workflows by providing initial agent references.

5.4.  Extension Points

   Adding support for a new protocol involves creating a new adapter
   module that implements the required mapping and discovery logic
   interfaces defined by the registry framework.  This ensures the
   registry can evolve with the agent ecosystem.

5.5.  Cross-Protocol Interoperability Limits

   The registry primarily enables discovery and identity verification
   across protocols.  An A2A agent can discover an agent advertising MCP
   tools, verify its identity via PKI, and potentially interact if it
   also understands MCP or uses a gateway.  ANS does not automatically
   translate A2A tasks into MCP requests.  It provides the foundational
   trust and location information, but deeper semantic interoperability
   often requires additional mechanisms or multi-protocol support within
   the agents themselves.

5.6.  Protocol Adapter API Definition

   Protocol Adapters are implemented as plugins that conform to the
   following interface (expressed in a language-agnostic way; adapt to
   your chosen implementation language):

























Huang, et al.           Expires 17 November 2025               [Page 29]

Internet-Draft                     ANS                          May 2025


   interface ProtocolAdapter {
     // Identifies the protocol supported by this adapter
     // (e.g., "a2a", "mcp", "acp")
     String getProtocol();

     // Parses protocol-specific metadata from the raw
     // 'protocolExtensions' data (e.g., a JSON object or string)
     // and maps it to a structured internal representation used by
     // the registry (e.g., a map or a dedicated object).
     // Returns a representation of the extracted data.
     Map<String, Object> parseMetadata(Object protocolExtensionsData);

     // Constructs a protocol-specific discovery response payload
     // based on information retrieved from an agent's registry record.
     // 'registryRecord' contains the agent's core ANS data and the
     // parsed protocolExtensions.
     Object createDiscoveryResponse(Map<String, Object> registryRecord);

     // Handles any protocol-specific validation logic required during
     // the agent registration process, beyond the standard ANS checks.
     // 'registrationRequest' is the full request object.
     // Returns true if validation passes, false otherwise.
     Boolean validateRegistration(AgentRegistrationRequest request);
   }

                   Figure 15: Interface: ProtocolAdapter

   Important Considerations:

   *  This is a basic interface.  More complex scenarios might require
      additional methods (e.g., for handling updates, deletions, etc.).

   *  The Map<String, Object> type should be replaced with more specific
      data structures based on your chosen implementation language and
      registry data model.

   *  Error handling should be implemented using exceptions or
      appropriate return codes.

   SUMMARY OF ANS FUNCTIONAL LAYERS











Huang, et al.           Expires 17 November 2025               [Page 30]

Internet-Draft                     ANS                          May 2025


     +=============+================+===============================+
     | ANS         | ANS Functional | JSON Schema Implementation    |
     | Component   | Layer          |                               |
     +=============+================+===============================+
     | Policy      | Request        | Forward-chaining rule         |
     | Enforcement | Processing     | processor with sequential     |
     | Engine      |                | evaluation of Agent's certs.  |
     +-------------+----------------+-------------------------------+
     | PKI         | Security       | Hierarchical PKI with Agent   |
     | Governance  | Infrastructure | specific Cert Validation &    |
     |             |                | Integration.                  |
     +-------------+----------------+-------------------------------+
     | A2A         | Protocol       | Zero-knowledge proof          |
     | Protocol    | Adapter        | capability verification       |
     | Engine      |                |                               |
     +-------------+----------------+-------------------------------+
     | MCP         | Protocol       | RBAC+ABAC access control with |
     | Protocol    | Adapter        | OPA                           |
     | Engine      |                |                               |
     +-------------+----------------+-------------------------------+
     | Consensus   | Distributed    | Analyzing Agent Signatures    |
     | Engine      | Governance     |                               |
     +-------------+----------------+-------------------------------+
     | ANS Audit   | Compliance     | Deterministically generate    |
     | Trail       | Layer          | unique Agent IDs (UUIDv5      |
     | System      |                | based on PKI public key hash) |
     +-------------+----------------+-------------------------------+

                Table 1: Summary of ANS Functional Layers

   This technical implementation of ANS ensures that universal agent
   Registry/Directory operates with cryptographic assurance, distributed
   consensus for critical operations, and real-time compliance
   enforcement while maintaining high performance and scalability
   requirements essential for enterprise AI agent deployments.

6.  Security Considerations

   The security of the Agent Name Service is paramount for its adoption
   and the trustworthiness of the agent ecosystems it supports.  This
   section outlines key threats, mitigation strategies, and security
   controls, referencing the MAESTRO 7 Layers framework [Huang-MAESTRO]
   where applicable.  See RFC 3552 [RFC3552] for a general guide on
   writing security considerations.







Huang, et al.           Expires 17 November 2025               [Page 31]

Internet-Draft                     ANS                          May 2025


6.1.  MAESTRO-Based Threat Analysis

   This section presents a systematic security threat analysis of the
   proposed ANS protocol.  We identify key potential vulnerabilities and
   map them onto the MAESTRO 7 Layers framework to provide a structured
   understanding of the threat landscape and the corresponding
   mitigation strategies integrated into our design.  MAESTRO stands for
   Multi-Agent Environment, Security, Threat, Risk, and Outcome, and its
   seven layers are: Foundation Models, Data Operations, Agent
   Frameworks, Deployment and Infrastructure, Evaluation and
   Observability, Security and Compliance, and Agent Ecosystem.  By
   analyzing vulnerabilities and risks at each architectural layer, as
   well as cross-layer interactions, MAESTRO enables security teams to
   proactively identify, assess, and mitigate threats unique to agentic
   AI.

6.1.1.  Threat: Agent Impersonation

   *Risk:*
      An adversary attempts to impersonate a legitimate, registered
      agent inside the ecosystem.

   *Mitigation Strategy:*
      Mandatory implementation of PKI.  Verification of agent identity
      through validation of agent-specific digital certificates (Cert)
      issued by a trusted CA.  Agent must prove possession of the
      private key.

   *Formal Check:*
      *  Agent MUST provide valid Cert on registration.

      *  RA MUST verify Cert against trusted CA.

      *  All communication MUST be digitally signed; recipient MUST
         verify signature using public key from Cert.

      *  See Section Section 3.2 (PKI Integration) and Section 3.7
         (Agent Identity).

   *MAESTRO Layer Mapping:*
      Layer 7 (Agent Ecosystem) - Agent Impersonation/Identity Attack.

6.1.2.  Threat: Registry Poisoning

   *Risk:*
      An adversary tries to inject malicious data into the Agent
      Registry (e.g., corrupting agentCapabilities or Endpoints).




Huang, et al.           Expires 17 November 2025               [Page 32]

Internet-Draft                     ANS                          May 2025


   *Mitigation Strategy:*
      Strict RA validation during registration/renewal; cryptographic
      signing of registry responses (secure resolution); stringent
      database access controls.  Secure resolution ensures responses are
      signed by the Agent Registry's private key, verifiable by clients.

   *Formal Check:*
      *  RA validation procedures (Section Section 3.1).

      *  Secure, authenticated registry responses (Section Section 3.5.4
         leveraging PKI Section Section 3.2).

      *  Database access controls (Infrastructure L4 / Data L2).

   *MAESTRO Layer Mapping:*
      *  Layer 7 (Agent Ecosystem) - Compromised Agent Registry,
         Malicious Agent Discovery.

      *  Layer 6 (Security and Compliance) - RA validation policies,
         cryptographic signing.

      *  Layer 4 (Deployment and Infrastructure) / Layer 2 (Data
         Operations) - Database access controls.

6.1.3.  Threat: Man-in-the-Middle (MitM) Attacks

   *Risk:*
      An adversary modifies communications between system components
      (agent-agent, agent-registry, agent-RA/CA).

   *Mitigation Strategy:*
      Message authenticity/integrity via digital signatures (agent's PKI
      private key).  Secure transport (e.g., mTLS) is best practice but
      PKI signing is the core mechanism discussed.  Formal resolution
      algorithm (Section 3.5.3) enforces response integrity.

   *Formal Check:*
      PKI signing (Section Section 3.2).

   *MAESTRO Layer Mapping:*
      *  Layer 4 (Deployment and Infrastructure) - Targets communication
         channels.  Secure transport operates here.

      *  Layer 6 (Security and Compliance) - PKI framework providing
         keys/certs managed via L6.






Huang, et al.           Expires 17 November 2025               [Page 33]

Internet-Draft                     ANS                          May 2025


6.1.4.  Threat: Denial of Service (DoS) / Distributed Denial of Service
        (DDoS)

   *Risk:*
      Adversary attempts to incapacitate Agent Registry, RA, CA, or
      resolution services via traffic flooding or resource exhaustion.

   *Mitigation Strategy:*
      Resilience through distributed implementation design.  Standard
      operational defenses (rate limiting, DDoS protection services).
      Formal resolution algorithms may include DoS limits.

   *Formal Check:*
      Architectural design (distributed options in Section Section 7).

   *MAESTRO Layer Mapping:*
      *  Layer 4 (Deployment and Infrastructure) - DoS attacks target L4
         availability.  Architectural resilience is L4 design.

      *  Layer 7 (Agent Ecosystem) - Impact felt at L7 (disrupted
         discovery/interaction).

6.2.  Additional Security Controls and Considerations

   Implementing ANS requires thorough threat modeling and comprehensive
   security controls.

6.2.1.  PKI Security Controls

   *Certificate Revocation:*
      Robust CRL [RFC5280] or OCSP [RFC6960] mechanisms are essential
      for handling compromised or decommissioned agent certificates.

   *Secure Key Storage:*
      Agent private keys MUST be protected using strong mechanisms
      (e.g., Hardware Security Modules (HSMs), secure enclaves, OS-level
      key stores).  Compromise of a private key requires immediate
      revocation and re-issuance of the certificate.

   *Registry Access Control:*
      Strict authentication and authorization mechanisms for managing
      the registry (RA operations) and potentially for querying,
      depending on policy.








Huang, et al.           Expires 17 November 2025               [Page 34]

Internet-Draft                     ANS                          May 2025


   *RA Validation Rigor:*
      The RA must implement a rigorous validation process to prevent
      malicious or fraudulent registrations.  This may include domain
      validation, organizational checks, and, in some cases, manual
      review.

6.2.2.  ANS-Specific Security Controls

   *Resolution Integrity:*
      As discussed, use DNSSEC-like mechanisms or signed responses from
      the registry to prevent ANS manipulation or spoofing of resolution
      results.

   *DoS Mitigation:*
      Standard defenses (rate limiting, firewalls, anycast routing) for
      resolution Endpoints are critical.

   *CA Security:*
      The CA(s) underpinning ANS MUST adhere to standard CA best
      practices (e.g., offline root CAs, regular audits, use of HSMs).
      Consideration should be given to using established, trusted CAs or
      building a highly secure, dedicated CA infrastructure.

   *Sybil Attack Resistance:*
      Registration processes should be designed to make the creation of
      large numbers of fake identities (Sybil attack) difficult and/or
      costly.

6.2.3.  Protocol Integration Security

   *Protocol-Specific Security:*
      Leverage security features within A2A, MCP, ACP (e.g., OAuth,
      capability tokens) for agent-to-agent communication post-
      discovery.

   *Governance and Trust Framework:*
      Clear policies, liability, and trust anchors are essential for
      adoption.

6.2.4.  Side-Channel Deanonymization and Mitigation

   The process of querying the Agent Registry for specific
   agentCapabilities could unintentionally reveal sensitive information
   about the querier's intent, business objectives, or operational
   profile.  To mitigate this risk, the implementation must prioritize:






Huang, et al.           Expires 17 November 2025               [Page 35]

Internet-Draft                     ANS                          May 2025


   *  *Private Information Retrieval (PIR) implementation:* To enable
      retrieval of information from the Agent Registry without revealing
      which information is being retrieved.  Evaluate various PIR
      libraries to determine the most secure and efficient
      implementation based on use case.  Prioritize the most performant
      and secure library.

   *  *Anonymized Query Relays:* Implementing query relays to hide the
      origin of the requests and prevent ANS Registry from seeing what
      agents are querying for what capabilities.

   *  *Differential Privacy for Aggregated Query Data:* Anonymize all
      data before sending to a 3rd party, ensuring that PII isn't
      included in the request.

   *  *Query Pattern Analysis:* Analyzing query patterns for anomalous
      behavior, and block queries that look suspicious.

   *  *Rate Limiting:* Implementing rate limiting to prevent potential
      DDoS attacks, and help obfuscate queries.

   *  *Auditing:* Ensure all security implementations are audited
      regularly.

   *  *Privacy Controls for Query and Response Data:* Implementation of
      data anonymization techniques to enhance privacy compliance.

7.  Implementation Considerations

   The Agent Registry, the core of ANS, can be implemented using various
   architectural patterns.  The choice depends on factors such as the
   expected scale of deployment, trust model, performance requirements
   (latency, throughput), administrative overhead, and cost.  The
   Protocol Adapter Layer is well-suited to a plugin-based architecture.

   Common implementation patterns for the registry include:

   *Centralized:*
      A single logical registry instance.  Simple to manage and ensures
      strong consistency.  However, it can be a single point of failure
      and a performance bottleneck.  Suitable for smaller, private, or
      experimental deployments.

   *Distributed (e.g., using Cassandra, CockroachDB):*
      Offers high availability, fault tolerance, and scalability.
      Technologies like Cassandra provide tunable consistency (often
      eventual consistency).  Requires robust coordination mechanisms
      and careful data partitioning strategies.



Huang, et al.           Expires 17 November 2025               [Page 36]

Internet-Draft                     ANS                          May 2025


   *Distributed (DHT - Distributed Hash Table):*
      Highly scalable peer-to-peer lookup.  Can be complex for state
      management and ensuring data integrity.  Suitable for very large-
      scale, decentralized deployments where eventual consistency is
      acceptable.

   *Blockchain/Distributed Ledger Technology (DLT):*
      Smart contracts can act as Registry Agents, with registrations and
      updates recorded as transactions on a blockchain.  Offers high
      security, transparency, and auditability but typically suffers
      from high latency, limited scalability (transactions per second),
      and significant write amplification (one logical write results in
      many physical writes across the network and storage), increasing
      storage costs and reducing performance.

   *Federated:*
      Multiple independent registries interoperate, often aligning with
      organizational or geographic boundaries.  Requires standardized
      inter-registry communication protocols, shared trust anchors
      (e.g., cross-certified CAs or a common root CA), and mechanisms
      for cross-domain name resolution and identity verification.
      Without these, a federated system risks becoming a collection of
      isolated silos.

   *Hybrid:*
      Combines elements of different patterns.  For example, a
      centralized RA/CA infrastructure might serve multiple distributed/
      replicated read-only registry nodes.  Caching layers (e.g., Redis,
      Memcached) can be used to improve read performance in many of
      these models.  Requires careful management of consistency between
      components.

   Key considerations when choosing an implementation pattern:

   *  *Consistency vs. Latency:* Strong consistency ensures all reads
      see the most recent write but can increase latency.  Eventual
      consistency allows lower latency and higher scalability but reads
      might temporarily see stale data.

   *  *Write Amplification (especially for Blockchain):* Be mindful of
      the storage and performance implications.

   *  *Operational Cost:* Includes hardware, software, and personnel.
      Blockchain solutions can be particularly expensive to operate.

   *  *Complexity:* Distributed systems (DHTs, blockchains, some
      federated models) are generally more complex to design, implement,
      deploy, and maintain than centralized systems.



Huang, et al.           Expires 17 November 2025               [Page 37]

Internet-Draft                     ANS                          May 2025


   DECISION MATRIX FOR AGENT REGISTRY IMPLEMENTATION PATTERNS

   +===========+===========+===========+===========+===========+==========+
   |Feature    |Centralized|Distributed|Distributed|Blockchain/|Federated |
   |           |           |(Cassandra)|(DHT)      |DLT        |          |
   +===========+===========+===========+===========+===========+==========+
   |Consistency|Strong     |Tunable    |Eventual   |Strong     |Tunable   |
   |           |           |(Eventual) |           |           |(Eventual)|
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Latency    |Low        |Medium     |Medium to  |High       |Medium to |
   |           |           |           |High       |           |High      |
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Scalability|Limited    |High       |Very High  |Limited    |High      |
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Fault      |Low        |High       |High       |High       |Medium    |
   |Tolerance  |           |           |           |           |          |
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Security   |Medium     |Medium     |Medium     |High       |Medium    |
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Operational|Low        |Medium     |Medium     |High       |Medium    |
   |Cost       |           |           |           |           |          |
   +-----------+-----------+-----------+-----------+-----------+----------+
   |Complexity |Low        |Medium     |High       |High       |Medium    |
   +-----------+-----------+-----------+-----------+-----------+----------+

    Table 2: Decision Matrix for Agent Registry Implementation Patterns

8.  Future Considerations

   This document lays the foundational groundwork for ANS.  Significant
   future work is envisioned to mature the proposal into a widely
   adopted standard:

   *  *Prototype Implementation and Evaluation:* Build and rigorously
      evaluate a working ANS prototype.  The existing work at
      https://github.com/kenhuangus/dns-for-agents/ serves as an initial
      base.

   *  *Bootstrap Model for Distributed Trust:* Explore an innovative
      bootstrap model for the distributed trust infrastructure,
      potentially focusing on a foundation-led root governance approach
      with delegated sub-spaces (analogous to CNCF's certificate
      transparency roots).  This includes developing a sustainable
      funding and fee schedule.







Huang, et al.           Expires 17 November 2025               [Page 38]

Internet-Draft                     ANS                          May 2025


   *  *Performance & Scalability Benchmarking:* Conduct thorough
      benchmarking of resolution latency, registration throughput, and
      overall scalability under various load conditions and deployment
      models.

   *  *Advanced Cryptography:* Investigate the integration of privacy-
      preserving cryptographic techniques, such as zero-knowledge proofs
      (ZKPs) for selective capability advertisement/disclosure, or more
      advanced PIR schemes.

   *  *Formal Verification:* Mathematically model and formally verify
      the security properties of the registration, resolution, and
      identity management protocols within ANS.

   *  *Detailed Governance Model:* Develop a comprehensive governance
      model, including detailed policies for naming conventions, CA/RA
      operational requirements, dispute resolution mechanisms, and the
      evolution of the trust framework.

   *  *Platform and Framework Integration:* Demonstrate and facilitate
      integration with popular agent development frameworks (e.g.,
      LangChain, AutoGen, CrewAI) and major cloud platforms.

   *  *Semantic Interoperability Enhancements:* Research mechanisms that
      leverage ANS metadata for deeper cross-protocol communication,
      such as standardized capability ontologies or translation gateways
      facilitated by ANS discovery.

   *  *Reputation Systems:* Investigate the integration of reputation
      scores, endorsements, or attestations into agent profiles within
      ANS to further enhance trust in agent interactions.

   *  *ANS Capability Negotiation and Binding Protocol:* Develop
      standardized protocols that allow agents, post-ANS resolution, to
      negotiate specific capabilities, agree on service level objectives
      (SLOs), and formally bind to service contracts.

   *  *Governance White Paper:* Draft a detailed white paper outlining
      name allocation strategies, a sustainable fee model, dispute
      arbitration processes, and stewardship of the root CA
      infrastructure.










Huang, et al.           Expires 17 November 2025               [Page 39]

Internet-Draft                     ANS                          May 2025


9.  Conclusion

   The Agent Name Service (ANS) offers a foundational infrastructure
   designed to foster a more secure, trustworthy, and interconnected
   ecosystem for agentic AI.  By addressing the critical needs of
   verifiable identity, secure discovery, and protocol-agnostic
   interoperability, ANS aims to provide significant benefits:

   *  *Enhancing Interoperability:* A protocol-agnostic directory
      facilitates seamless discovery and initial contact between diverse
      agents built on different communication standards.

   *  *Boosting Trust and Security:* The integration of PKI for identity
      verification enhances trust, which is crucial for agents operating
      in sensitive domains such as finance, healthcare, and
      cybersecurity.

   *  *Accelerating Innovation:* By providing common infrastructure for
      discovery and identity, ANS can lower barriers to entry for
      developers, allowing them to focus on core agent functionalities
      and solutions.

   *  *Facilitating Autonomous Systems:* ANS is a critical enabler for
      complex autonomous systems that require dynamic, secure discovery
      and interaction between their constituent agents (e.g., in
      autonomous vehicles, smart cities, and industrial automation).

   *  *Powering Secure AI Marketplaces:* The framework can serve as a
      foundation for AI marketplaces where agents with verifiable
      identities and capabilities can be securely listed, discovered,
      and engaged.

   The modular Protocol Adapter Layer ensures that ANS can evolve and
   extend its support to new and emerging agent communication standards.
   While challenges related to governance, global scalability, and
   achieving deep semantic interoperability remain, ANS represents a
   necessary and significant step towards building a robust, secure, and
   scalable future for agentic AI.

10.  IANA Considerations

   This document has no IANA actions requested at this time.  Future
   versions may request registration of a URI scheme for ANSNames, new
   port numbers if a dedicated ANS protocol is defined, or new
   registries for ANS components if deemed necessary by the community.

11.  References




Huang, et al.           Expires 17 November 2025               [Page 40]

Internet-Draft                     ANS                          May 2025


11.1.  Normative References

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

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

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

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

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

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

11.2.  Informative References

   [A2A-Blog] Surapaneni, R., Jha, M., Vakoc, M., and T. Segal,
              "Announcing the Agent2Agent Protocol (A2A)", Google for
              Developers Blog , April 2025,
              <https://developers.googleblog.com/en/a2a-a-new-era-of-
              agent-interoperability/>.

   [A2A-Spec] Agent2Agent Protocol Specification Authors, "Agent2Agent
              (A2A) Protocol Specification", 2025,
              <https://github.com/google/A2A>.




Huang, et al.           Expires 17 November 2025               [Page 41]

Internet-Draft                     ANS                          May 2025


   [MCP-News] Anthropic, "Model context protocol (MCP)", 2024,
              <https://www.anthropic.com/news/model-context-protocol>.

   [MCP-Spec] Model Context Protocol Specification Authors, "Model
              Context Protocol (MCP) Specification", March 2025,
              <https://modelcontextprotocol.io/
              specification/2025-03-26>.

   [MCP-Intro-Schmid]
              Schmid, P., "MCP Introduction", 2025,
              <https://www.philschmid.de/mep-introduction>.

   [FIPA-ACL] Foundation for Intelligent Physical Agents (FIPA), "FIPA
              Agent Communication Language Specifications", FIPA
              Technical Report , 2002,
              <http://www.fipa.org/repository/aclspecs.html>.

   [Habler-A2A-Secure]
              Habler, I., Huang, K., Narajala, V.S., and P. Kulkarni,
              "Building a secure agentic Al application leveraging A2A
              protocol", arXiv preprint arXiv:2504.16902 , 2025,
              <https://www.arxiv.org/abs/2504.16902>.

   [Narajala-MCP-Secure]
              Narajala, V.S. and I. Habler, "Enterprise-Grade Security
              for the Model Context Protocol (MCP): Frameworks and
              Mitigation Strategies", arXiv preprint arXiv:2504.08623 ,
              2025, <https://arxiv.org/abs/2504.08623>.

   [Huang-MAESTRO]
              Huang, K., Sheriff, A., Sotiropoulos, J., Del, R.F., and
              V. Lu, "Multi-agentic system threat modelling guide OWASP
              GenAI security project", April 2025,
              <https://www.researchgate.net/publication/391204915_Multi-
              Agentic_system_Threat_Modelling_Guide_OWASP_GenAl_Security
              _Project>.

   [Narajala-ToolSquatting]
              Narajala, V.S., Huang, K., and I. Habler, "Securing genai
              multi-agent systems against tool squatting: A zero trust
              registry-based approach", arXiv.org , 2025,
              <https://arxiv.org/abs/2504.19951>.

   [IBM-ACP-Placeholder]
              IBM Research, "(Placeholder for anticipated IBM ACP
              publication/specification link)", 2025.





Huang, et al.           Expires 17 November 2025               [Page 42]

Internet-Draft                     ANS                          May 2025


   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

Appendix A.  Appendix A: Complete Request/Response Schemas

   The detailed JSON Schema documents for various registry interactions
   are maintained externally due to their length.  Implementers should
   refer to these sources for complete and up-to-date schema
   definitions.  It is crucial that these schemas are well-commented and
   validated in any ANS implementation.

   *  AgentRegistrationRequest Schema: https://github.com/kenhuangus/
      dns-for-agents/blob/main/agent_registration_request_schema.json

   *  AgentRenewalRequest Schema: https://github.com/kenhuangus/dns-for-
      agents/blob/main/agent_renewal_request_schema.json

   *  AgentRegistrationResponse Schema: https://github.com/kenhuangus/
      dns-for-agents/blob/main/agent_registration_response_schema.json

   *  AgentRenewalResponse Schema: https://github.com/kenhuangus/dns-
      for-agents/blob/main/agent_renewal_response_schema.json

   *  AgentCapabilityRequest Schema (for resolution):
      https://github.com/kenhuangus/dns-for-agents/blob/main/
      agent_capability_request.schema.json

   *  AgentCapabilityResponse Schema (for resolution):
      https://github.com/kenhuangus/dns-for-agents/blob/main/
      agent_capability_response.schema.json

Appendix B.  Appendix B: Glossary of Terms - Agent Name Service (ANS)

   *A2A (Agent2Agent Protocol):*
      A communication protocol developed by Google for standardizing
      inter-agent communication, designed to bridge different agent
      frameworks.

   *ACP (Agent Communication Protocol):*
      A protocol designed by IBM Research to standardize how agents
      communicate, enabling automation, collaboration, UI integration,
      and developer tooling.

   *Agent:*
      An autonomous software entity capable of performing tasks, making
      decisions, and interacting with other agents or systems.



Huang, et al.           Expires 17 November 2025               [Page 43]

Internet-Draft                     ANS                          May 2025


   *Agent Identity:*
      The verifiable identity of an agent within the ANS ecosystem,
      comprising cryptographic identity (PKI certificate), logical
      identity (ANSName), and protocol-specific identities.

   *Agent Registry:*
      A database storing registered agent information including
      capabilities, security policies, PKI certificates, protocol-
      specific metadata, and registration/renewal timestamps.

   *agentCapability:*
      A specific function, service, or skill that an agent can perform
      or provide to other agents or users.

   *ANS (Agent Name Service):*
      A universal directory service framework that enables secure
      discovery and interoperability between AI agents across different
      protocols and platforms.

   *ANSName:*
      A structured, human-readable, and machine-resolvable identifier
      for agents in the ANS ecosystem.

   *CA (Certificate Authority):*
      A trusted entity that issues and manages digital certificates that
      bind public keys to entities (like agents) to establish a chain of
      trust in the ANS ecosystem.

   *Certificate Chain Verification:*
      The process of validating a certificate by checking the chain of
      trust from the certificate up to a trusted root certificate
      authority.

   *Certificate Revocation:*
      The process of invalidating a certificate before its scheduled
      expiration date, typically due to a key compromise or when an
      agent is deregistered.

   *CRL (Certificate Revocation List):*
      A list of digital certificates that have been revoked by the
      issuing CA before their scheduled expiration date and should no
      longer be trusted.

   *CSR (Certificate Signing Request):*
      A message, typically in a standardized format, sent by an
      applicant (an agent in this context) to a Certificate Authority to
      apply for a digital identity certificate.




Huang, et al.           Expires 17 November 2025               [Page 44]

Internet-Draft                     ANS                          May 2025


   *Digital Signature:*
      A mathematical scheme for verifying the authenticity (proof of
      sender) and integrity (proof data has not been altered) of digital
      messages or documents.

   *DHT (Distributed Hash Table):*
      A decentralized distributed system that provides a lookup service
      similar to a hash table; keys are mapped to values, and the table
      is distributed among participating nodes.

   *DNS (Domain Name System):*
      The hierarchical and decentralized naming system used to identify
      computers, services, and other resources reachable through the
      Internet or other Internet Protocol networks.

   *DNS-SD (DNS-Based Service Discovery):*
      An extension to DNS that enables automatic discovery of services
      available on a local network using standard DNS queries.

   *Endpoint:*
      A resolvable network address, service binding, or metadata
      document that allows agents to connect and communicate with each
      other.

   *Extension (in ANSName):*
      An optional field in the ANSName structure that holds deployment-
      specific or provider-defined metadata, not part of the core
      identity.

   *Interoperability:*
      The ability of different agent systems, devices, or applications
      from different vendors to access, exchange, integrate, and
      cooperatively use data in a coordinated manner.

   *MAESTRO (7 Layers):*
      A threat modeling framework specifically designed for agentic AI
      systems, consisting of 7 layers, used to structure the security
      analysis of ANS.

   *MAS (Multi-Agent Systems):*
      Systems composed of multiple interacting intelligent agents that
      can cooperate, coordinate, or compete to solve problems that are
      beyond the individual capabilities or knowledge of each agent.

   *MCP (Model Context Protocol):*
      A protocol developed by Anthropic focused on simplifying the
      integration of AI models with external tools and data sources.




Huang, et al.           Expires 17 November 2025               [Page 45]

Internet-Draft                     ANS                          May 2025


   *OCSP (Online Certificate Status Protocol):*
      An Internet protocol used for obtaining the revocation status of
      an X.509 digital certificate as an alternative to CRLs, providing
      more timely status information.

   *PKI (Public Key Infrastructure):*
      A set of roles, policies, hardware, software, and procedures
      needed to create, manage, distribute, use, store, and revoke
      digital certificates and manage public-key encryption.

   *Protocol Adapter Layer:*
      A component in the ANS architecture that translates between the
      registry's internal, protocol-agnostic representation and
      protocol-specific formats for metadata and discovery.

   *protocolExtensions (in Schema):*
      A flexible field within the ANS JSON schemas that acts as a
      container for protocol-specific data, allowing ANS to support
      diverse agent types.

   *Provider (in ANSName):*
      An organization or entity that offers, maintains, or is
      responsible for agents registered in the ANS ecosystem.

   *RA (Registration Authority):*
      An entity, authorized by a CA, that verifies agent registration
      and renewal requests, interacts with the CA to issue certificates,
      and manages aspects of the agent lifecycle.

   *Registry Poisoning:*
      A security threat where an adversary successfully injects
      malicious, false, or misleading data into the Agent Registry to
      disrupt services or deceive users/agents.

   *Semantic Versioning:*
      A formal versioning scheme with a format of MAJOR.MINOR.PATCH
      (e.g., 1.2.3), used to indicate compatibility and changes in agent
      versions.

   *Service Discovery:*
      The process of automatically detecting devices and services
      offered by these devices on a computer network.

   *Signature Verification:*
      The process of using the signer's public key to check that a
      digital signature is authentic and that the associated data has
      not been tampered with since it was signed.




Huang, et al.           Expires 17 November 2025               [Page 46]

Internet-Draft                     ANS                          May 2025


   *Sybil Attack:*
      A type of attack on a peer-to-peer network in which a malicious
      actor creates a large number of pseudonymous identities and uses
      them to gain a disproportionately large influence.

   *Trust Anchor:*
      A CA certificate that is implicitly trusted and serves as the
      starting point for validating a certificate chain in a PKI system.

   *Version Negotiation:*
      The process by which communicating entities (agents in this case)
      determine which version of a protocol or capability to use, based
      on compatibility and preferences.

   *VerifyCertChain (Function):*
      A function or process that checks the validity of a digital
      certificate by tracing its chain of signatures and revocation
      statuses back to a trusted root CA (Trust Anchor).

   *VerifySignature (Function):*
      A function or process that validates a digital signature against a
      given message and a public key to confirm the message's
      authenticity and integrity.

Acknowledgements

   The authors acknowledge the contributions of the communities and
   organizations developing foundational agent communication standards,
   including Google (A2A), Anthropic (MCP), IBM (ACP), and the broader
   AI research community.

   This document was created as part of the OWASP Gen AI Security
   Project - Agentic Security Initiative (ASI).

Authors' Addresses

   Ken Huang
   DistributedApps.ai
   Email: ken.huang@distributedapps.ai


   Vineeth Sai Narajala
   Amazon Web Services
   Email: abcvineeth.sai@gmail.com


   Idan Habler
   Intuit



Huang, et al.           Expires 17 November 2025               [Page 47]

Internet-Draft                     ANS                          May 2025


   Email: idan_habler@intuit.com


   Akram Sheriff
   Cisco Systems
   Email: isheriff@cisco.com













































Huang, et al.           Expires 17 November 2025               [Page 48]


name: draft-ietf-httpbis-layered-cookies
rev: 01
title: Cookies: HTTP State Management Mechanism
time: 2025-11-18T13:22:03Z
group_uri: /api/v1/group/group/1718/
expires: 2026-05-22T13:22:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:06.864815+00:00
abstract:
This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.  Although
   cookies have many historical infelicities that degrade their security
   and privacy, the Cookie and Set-Cookie header fields are widely used
   on the Internet.  This document obsoletes RFC 6265 and 6265bis.

full_text:
HTTP                                                A. van Kesteren, Ed.
Internet-Draft                                                     Apple
Obsoletes: [6265] (if approved)                          J. Hofmann, Ed.
Intended status: Standards Track                                  Google
Expires: 22 May 2026                                    18 November 2025


                Cookies: HTTP State Management Mechanism
                 draft-ietf-httpbis-layered-cookies-01

Abstract

   This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.  Although
   cookies have many historical infelicities that degrade their security
   and privacy, the Cookie and Set-Cookie header fields are widely used
   on the Internet.  This document obsoletes RFC 6265 and 6265bis.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-httpbis-layered-cookies/.

   Discussion of this document takes place on the HTTP Working Group
   mailing list (mailto:ietf-http-wg@w3.org), which is archived at
   https://lists.w3.org/Archives/Public/ietf-http-wg/.  Working Group
   information can be found at https://httpwg.org/.

   Source for this draft and an issue tracker can be found at
   https://github.com/httpwg/http-extensions/labels/cookies.

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







van Kesteren & Hofmann     Expires 22 May 2026                  [Page 1]

Internet-Draft                   Cookies                   November 2025


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

   This Internet-Draft will expire on 22 May 2026.

Copyright Notice

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

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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Which Requirements to Implement . . . . . . . . . . . . . . .   7
     3.1.  Cookie Producing Implementations  . . . . . . . . . . . .   8
     3.2.  Cookie Consuming Implementations  . . . . . . . . . . . .   8
     3.3.  Programming Languages & Software Frameworks . . . . . . .   8
   4.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .   9
       4.1.2.  Semantics (Non-Normative) . . . . . . . . . . . . . .  11



van Kesteren & Hofmann     Expires 22 May 2026                  [Page 2]

Internet-Draft                   Cookies                   November 2025


       4.1.3.  Cookie Name Prefixes  . . . . . . . . . . . . . . . .  14
     4.2.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.2.  Semantics . . . . . . . . . . . . . . . . . . . . . .  17
   5.  User Agent Requirements . . . . . . . . . . . . . . . . . . .  17
     5.1.  Cookie Concepts . . . . . . . . . . . . . . . . . . . . .  17
       5.1.1.  Cookie Store And Limits . . . . . . . . . . . . . . .  17
       5.1.2.  Cookie Struct . . . . . . . . . . . . . . . . . . . .  18
     5.2.  Cookie Store Eviction . . . . . . . . . . . . . . . . . .  19
       5.2.1.  Remove Expired Cookies  . . . . . . . . . . . . . . .  19
       5.2.2.  Remove Excess Cookies for a Host  . . . . . . . . . .  19
       5.2.3.  Remove Global Excess Cookies  . . . . . . . . . . . .  20
     5.3.  Subcomponent Algorithms . . . . . . . . . . . . . . . . .  20
       5.3.1.  Parse a Date  . . . . . . . . . . . . . . . . . . . .  21
       5.3.2.  Domain Matching . . . . . . . . . . . . . . . . . . .  22
       5.3.3.  Cookie Default Path . . . . . . . . . . . . . . . . .  23
       5.3.4.  Path Matching . . . . . . . . . . . . . . . . . . . .  23
     5.4.  Main Algorithms . . . . . . . . . . . . . . . . . . . . .  23
       5.4.1.  Parse and Store a Cookie  . . . . . . . . . . . . . .  24
       5.4.2.  Parse a Cookie  . . . . . . . . . . . . . . . . . . .  24
       5.4.3.  Store a Cookie  . . . . . . . . . . . . . . . . . . .  28
       5.4.4.  Garbage Collect Cookies . . . . . . . . . . . . . . .  31
       5.4.5.  Retrieve Cookies  . . . . . . . . . . . . . . . . . .  31
       5.4.6.  Serialize Cookies . . . . . . . . . . . . . . . . . .  33
     5.5.  Requirements Specific to Non-Browser User Agents  . . . .  33
       5.5.1.  The Set-Cookie Header Field . . . . . . . . . . . . .  33
       5.5.2.  The Cookie Header Field . . . . . . . . . . . . . . .  34
       5.5.3.  Cookie Store Eviction for Non-Browser User Agents . .  35
     5.6.  Requirements Specific to Browser User Agents  . . . . . .  35
   6.  Implementation Considerations . . . . . . . . . . . . . . . .  36
     6.1.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     6.2.  Application Programming Interfaces  . . . . . . . . . . .  36
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  36
     7.1.  Third-Party Cookies . . . . . . . . . . . . . . . . . . .  37
     7.2.  Cookie Policy . . . . . . . . . . . . . . . . . . . . . .  38
     7.3.  User Controls . . . . . . . . . . . . . . . . . . . . . .  38
     7.4.  Expiration Dates  . . . . . . . . . . . . . . . . . . . .  39
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  39
     8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  39
     8.2.  Ambient Authority . . . . . . . . . . . . . . . . . . . .  39
     8.3.  Clear Text  . . . . . . . . . . . . . . . . . . . . . . .  40
     8.4.  Session Identifiers . . . . . . . . . . . . . . . . . . .  41
     8.5.  Weak Confidentiality  . . . . . . . . . . . . . . . . . .  41
     8.6.  Weak Integrity  . . . . . . . . . . . . . . . . . . . . .  42
     8.7.  Reliance on DNS . . . . . . . . . . . . . . . . . . . . .  43
     8.8.  SameSite Cookies  . . . . . . . . . . . . . . . . . . . .  43
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
     9.1.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  43



van Kesteren & Hofmann     Expires 22 May 2026                  [Page 3]

Internet-Draft                   Cookies                   November 2025


     9.2.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .  44
   10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  44
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
     Normative References  . . . . . . . . . . . . . . . . . . . . .  44
     Informative References  . . . . . . . . . . . . . . . . . . . .  45
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

1.  Introduction

   This document defines the HTTP Cookie and Set-Cookie header fields.
   Using the Set-Cookie header field, an HTTP server can pass name/value
   pairs and associated metadata (called cookies) to a user agent.  When
   the user agent makes subsequent requests to the server, the user
   agent uses the metadata and other information to determine whether to
   return the name/value pairs in the Cookie header field.

   Although simple on their surface, cookies have a number of
   complexities.  For example, the server can scope the maximum amount
   of time during which the user agent should return the cookie, the
   servers to which the user agent should return the cookie, and whether
   the cookie can be accessed through a non-HTTP API, such as JavaScript
   in a web browser.

   For historical reasons, cookies contain a number of security and
   privacy infelicities.  For example, a server can indicate that a
   given cookie is intended for "secure" connections, but the cookie's
   Secure attribute does not provide integrity in the presence of an
   active network attacker.  Similarly, cookies for a given host are
   shared across all the ports on that host, even though the usual
   "same-origin policy" used by web browsers isolates content retrieved
   via different ports.

   This document specifies the syntax and semantics of these header
   fields.  Where some existing software differs from the requirements
   in significant ways, the document contains a note explaining the
   difference.

   This document obsoletes [RFC6265] and 6265bis.

1.1.  Examples

   Using the Set-Cookie header field, a server can send the user agent a
   short string in an HTTP response that the user agent will return in
   future HTTP requests that are within the scope of the cookie.  For
   example, the server can send the user agent a "session identifier"
   named SID with the value 31d4d96e407aad42.  The user agent then
   returns the session identifier in subsequent requests.



van Kesteren & Hofmann     Expires 22 May 2026                  [Page 4]

Internet-Draft                   Cookies                   November 2025


   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42

   The server can alter the default scope of the cookie using the Path
   and Domain attributes.  For example, the server can instruct the user
   agent to return the cookie to every path and every subdomain of
   site.example.

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42

   As shown in the next example, the server can store multiple cookies
   at the user agent.  For example, the server can store a session
   identifier as well as the user's preferred language by returning two
   Set-Cookie header fields.  Notice that the server uses the Secure and
   HttpOnly attributes to provide additional security protections for
   the more sensitive session identifier (see Section 4.1.2).

   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
   Set-Cookie: lang=en-US; Path=/; Domain=site.example

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42; lang=en-US

   Notice that the Cookie header field above contains two cookies, one
   named SID and one named lang.

   Cookie names are case-sensitive, meaning that if a server sends the
   user agent two Set-Cookie header fields that differ only in their
   name's case the user agent will store and return both of those
   cookies in subsequent requests.







van Kesteren & Hofmann     Expires 22 May 2026                  [Page 5]

Internet-Draft                   Cookies                   November 2025


   == Server -> User Agent ==

   Set-Cookie: SID=31d4d96e407aad42
   Set-Cookie: sid=31d4d96e407aad42

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42

   If the server wishes the user agent to persist the cookie over
   multiple "sessions" (e.g., user agent restarts), the server can
   specify an expiration date in the Expires attribute.  Note that the
   user agent might delete the cookie before the expiration date if the
   user agent's cookie store exceeds its quota or if the user manually
   deletes the server's cookie.

   == Server -> User Agent ==

   Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42; lang=en-US

   Finally, to remove a cookie, the server returns a Set-Cookie header
   field with an expiration date in the past.  The server will be
   successful in removing the cookie only if the Path and the Domain
   attribute in the Set-Cookie header field match the values used when
   the cookie was created.

   == Server -> User Agent ==

   Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

   == User Agent -> Server ==

   Cookie: SID=31d4d96e407aad42

2.  Conventions

2.1.  Terminology

   This specification depends on Infra.  [INFRA]

   Some terms used in this specification are defined in the following
   standards and specifications:

   *  HTTP [RFC9110]



van Kesteren & Hofmann     Expires 22 May 2026                  [Page 6]

Internet-Draft                   Cookies                   November 2025


   *  URL [URL]

   A *non-HTTP API* is a non-HTTP mechanisms used to set and retrieve
   cookies, such as a web browser API that exposes cookies to
   JavaScript.

2.2.  ABNF

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234].

   The following core rules are included by reference, as defined in
   [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
   (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
   HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
   OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
   (horizontal tab), CHAR (any ASCII byte), VCHAR (any visible ASCII
   byte), and WSP (whitespace).

   The OWS (optional whitespace) and BWS (bad whitespace) rules are
   defined in Section 5.6.3 of [RFC9110].

3.  Which Requirements to Implement

   The upcoming two sections, Section 4 and Section 5, discuss the set
   of requirements for two distinct types of implementations.  This
   section is meant to help guide implementers in determining which set
   of requirements best fits their goals.  Choosing the wrong set of
   requirements could result in a lack of compatibility with other
   cookie implementations.

   It's important to note that being compatible means different things
   depending on the implementer's goals.  These differences have built
   up over time due to both intentional and unintentional specification
   changes, specification interpretations, and historical implementation
   differences.

   This section roughly divides implementers of this specification into
   two types, producers and consumers.  These are not official terms and
   are only used here to help readers develop an intuitive understanding
   of the use cases.










van Kesteren & Hofmann     Expires 22 May 2026                  [Page 7]

Internet-Draft                   Cookies                   November 2025


3.1.  Cookie Producing Implementations

   An implementer should choose Section 4 whenever cookies are created
   and will be sent to a user agent, such as a web browser.  These
   implementations are frequently referred to as servers by the
   specification but that term includes anything which primarily
   produces cookies.  Some potential examples:

   *  Server applications hosting a website or API

   *  Programming languages or software frameworks that support cookies

   *  Integrated third-party web applications, such as a business
      management suite

   All these benefit from not only supporting as many user agents as
   possible but also supporting other servers.  This is useful if a
   cookie is produced by a software framework and is later sent back to
   a server application which needs to read it.  Section 4 advises best
   practices that help maximize this sense of compatibility.

3.2.  Cookie Consuming Implementations

   An implementer should choose Section 5 whenever cookies are primarily
   received from another source.  These implementations are referred to
   as user agents.  Some examples:

   *  Web browsers

   *  Tools that support stateful HTTP

   *  Programming languages or software frameworks that support cookies

   Because user agents don't know which servers a user will access, and
   whether or not that server is following best practices, users agents
   are advised to implement a more lenient set of requirements and to
   accept some things that servers are warned against producing.
   Section 5 advises best practices that help maximize this sense of
   compatibility.

3.3.  Programming Languages & Software Frameworks

   A programming language or software framework with support for cookies
   could reasonably be used to create an application that acts as a
   cookie producer, cookie consumer, or both.  Because a developer may
   want to maximize their compatibility as either a producer or
   consumer, these languages or frameworks should strongly consider
   supporting both sets of requirements, Section 4 and Section 5, behind



van Kesteren & Hofmann     Expires 22 May 2026                  [Page 8]

Internet-Draft                   Cookies                   November 2025


   a compatibility mode toggle.  This toggle should default to
   Section 4's requirements.

   Doing so will reduce the chances that a developer's application can
   inadvertently create cookies that cannot be read by other servers.

4.  Server Requirements

   This section describes the conforming syntax and semantics of the
   HTTP Cookie and Set-Cookie header fields.

4.1.  Set-Cookie

   The Set-Cookie HTTP response header field is used to send cookies
   from the server to the user agent.

   Origin servers MAY send a Set-Cookie response header field with any
   response.  An origin server can include multiple Set-Cookie header
   fields in a single response.  The presence of a Cookie or a Set-
   Cookie header field does not preclude HTTP caches from storing and
   reusing a response.

   Origin servers and intermediaries MUST NOT combine multiple Set-
   Cookie header fields into a single header field.  The usual mechanism
   for combining HTTP headers fields (i.e., as defined in Section 5.3 of
   [RFC9110]) might change the semantics of the Set-Cookie header field
   because the %x2C (",") character is used by Set-Cookie in a way that
   conflicts with such combining.

   For example,

   Set-Cookie: a=b;path=/c,d=e

   is ambiguous.  It could be intended as two cookies, a=b and d=e, or a
   single cookie with a path of /c,d=e.

4.1.1.  Syntax

   Informally, the Set-Cookie response header field contains a cookie,
   which begins with a name-value-pair, followed by zero or more
   attribute-value pairs.  Servers MUST send Set-Cookie header fields
   that conform to the following grammar:









van Kesteren & Hofmann     Expires 22 May 2026                  [Page 9]

Internet-Draft                   Cookies                   November 2025


   set-cookie        = set-cookie-string
   set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
   cookie-pair       = cookie-name BWS "=" BWS cookie-value
   cookie-name       = token
   cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
   cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                         ; US-ASCII characters excluding CTLs,
                         ; whitespace, DQUOTE, comma, semicolon,
                         ; and backslash
   token             = <token, defined in [HTTP], Section 5.6.2>

   cookie-av         = expires-av / max-age-av / domain-av /
                       path-av / secure-av / httponly-av /
                       samesite-av / extension-av
   expires-av        = "Expires" BWS "=" BWS sane-cookie-date
   sane-cookie-date  =
       <IMF-fixdate, defined in [HTTP], Section 5.6.7>
   max-age-av        = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT
   non-zero-digit    = %x31-39
                         ; digits 1 through 9
   domain-av         = "Domain" BWS "=" BWS domain-value
   domain-value      = <subdomain>
                         ; see details below
   path-av           = "Path" BWS "=" BWS path-value
   path-value        = *av-octet
   secure-av         = "Secure"
   httponly-av       = "HttpOnly"
   samesite-av       = "SameSite" BWS "=" BWS samesite-value
   samesite-value    = "Strict" / "Lax" / "None"
   extension-av      = *av-octet
   av-octet          = %x20-3A / %x3C-7E
                         ; any CHAR except CTLs or ";"

   Note that some of the grammatical terms above reference documents
   that use different grammatical notations than this document (which
   uses ABNF from [RFC5234]).

   Per the grammar above, servers MUST NOT produce nameless cookies
   (i.e., an empty cookie-name) as such cookies may be unpredictably
   serialized by user agents when sent back to the server.

   The semantics of the cookie-value are not defined by this document.

   To maximize compatibility with user agents, servers that wish to
   store arbitrary data in a cookie-value SHOULD encode that data, for
   example, using Base64 [RFC4648].





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 10]

Internet-Draft                   Cookies                   November 2025


   Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
   characters.  Note that in this case, the initial and trailing DQUOTE
   characters are not stripped.  They are part of the cookie-value, and
   will be included in Cookie header fields sent to the server.

   The domain-value is a subdomain as defined by [RFC1034], Section 3.5,
   and as enhanced by [RFC1123], Section 2.1.  Thus, domain-value is a
   byte sequence of ASCII bytes.

   The portions of the set-cookie-string produced by the cookie-av term
   are known as attributes.  To maximize compatibility with user agents,
   servers SHOULD NOT produce two attributes with the same name in the
   same set-cookie-string.

   NOTE: The name of an attribute-value pair is not case-sensitive.  So
   while they are presented here in CamelCase, such as HttpOnly or
   SameSite, any case is accepted.  E.g., httponly, Httponly, hTTPoNLY,
   etc.

   Servers MUST NOT include more than one Set-Cookie header field in the
   same response with the same cookie-name.  (See Section 5.5.1 for how
   user agents handle this case.)

   If a server sends multiple responses containing Set-Cookie header
   fields concurrently to the user agent (e.g., when communicating with
   the user agent over multiple sockets), these responses create a "race
   condition" that can lead to unpredictable behavior.

   NOTE: Some existing user agents differ in their interpretation of
   two-digit years.  To avoid compatibility issues, servers SHOULD use
   the rfc1123-date format, which requires a four-digit year.

   NOTE: Some user agents store and process dates in cookies as 32-bit
   UNIX time_t values.  Implementation bugs in the libraries supporting
   time_t processing on some systems might cause such user agents to
   process dates after the year 2038 incorrectly.

4.1.2.  Semantics (Non-Normative)

   This section describes simplified semantics of the Set-Cookie header
   field.  These semantics are detailed enough to be useful for
   understanding the most common uses of cookies by servers.  The full
   semantics are described in Section 5.

   When the user agent receives a Set-Cookie header field, the user
   agent stores the cookie together with its attributes.  Subsequently,
   when the user agent makes an HTTP request, the user agent includes
   the applicable, non-expired cookies in the Cookie header field.



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 11]

Internet-Draft                   Cookies                   November 2025


   If the user agent receives a new cookie with the same cookie-name,
   domain-value, and path-value as a cookie that it has already stored,
   the existing cookie is evicted and replaced with the new cookie.
   Notice that servers can delete cookies by sending the user agent a
   new cookie with an Expires attribute with a value in the past.

   Unless the cookie's attributes indicate otherwise, the cookie is
   returned only to the origin server (and not, for example, to any
   subdomains), and it expires at the end of the current session (as
   defined by the user agent).  User agents ignore unrecognized cookie
   attributes (but not the entire cookie).

4.1.2.1.  The Expires Attribute

   The Expires attribute indicates the maximum lifetime of the cookie,
   represented as the date and time at which the cookie expires.  The
   user agent is not required to retain the cookie until the specified
   date has passed.  In fact, user agents often evict cookies due to
   memory pressure or privacy concerns.

4.1.2.2.  The Max-Age Attribute

   The Max-Age attribute indicates the maximum lifetime of the cookie,
   represented as the number of seconds until the cookie expires.  The
   user agent is not required to retain the cookie for the specified
   duration.  In fact, user agents often evict cookies due to memory
   pressure or privacy concerns.

   If a cookie has both the Max-Age and the Expires attribute, the Max-
   Age attribute has precedence and controls the expiration date of the
   cookie.  If a cookie has neither the Max-Age nor the Expires
   attribute, the user agent will retain the cookie until "the current
   session is over" (as defined by the user agent).

4.1.2.3.  The Domain Attribute

   The Domain attribute specifies those hosts to which the cookie will
   be sent.

   If the server includes the Domain attribute, the value applies to
   both the specified domain and any subdomains.  For example, if the
   value of the Domain attribute is "site.example", the user agent will
   include the cookie in the Cookie header field when making HTTP
   requests to site.example, www.site.example, and
   www.corp.site.example.  Note that a leading %x2E ("."), if present,
   is ignored even though that character is not permitted.





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 12]

Internet-Draft                   Cookies                   November 2025


   If the server omits the Domain attribute, the user agent will return
   the cookie only to the origin server and not to any subdomains.

   WARNING: Some existing user agents treat an absent Domain attribute
   as if the Domain attribute were present and contained the current
   host name.  For example, if site.example returns a Set-Cookie header
   field without a Domain attribute, these user agents will erroneously
   send the cookie to www.site.example and www.corp.site.example as
   well.

   The user agent will reject cookies unless the Domain attribute
   specifies a scope for the cookie that would include the origin
   server.  For example, the user agent will accept a cookie with a
   Domain attribute of "site.example" or of "foo.site.example" from
   foo.site.example, but the user agent will not accept a cookie with a
   Domain attribute of "bar.site.example" or of "baz.foo.site.example".

4.1.2.4.  The Path Attribute

   The scope of each cookie is limited to a set of paths, controlled by
   the Path attribute.  If the server omits the Path attribute, the user
   agent will use the "directory" of the request-uri's path component as
   the default value.  (See Section 5.3.3 for more details.)

   The user agent will include the cookie in an HTTP request only if the
   path portion of the request-uri matches (or is a subdirectory of) the
   cookie's Path attribute, where the %x2F ("/") character is
   interpreted as a directory separator.

   Although seemingly useful for isolating cookies between different
   paths within a given host, the Path attribute cannot be relied upon
   for security (see Section 8).

4.1.2.5.  The Secure Attribute

   The Secure attribute limits the scope of the cookie to "secure"
   channels (where "secure" is outside the scope of this document).
   E.g., when a cookie has the Secure attribute, the user agent will
   include the cookie in an HTTP request only if the request is
   transmitted over a secure channel (typically HTTP over Transport
   Layer Security (TLS) [TLS13] [RFC9110]).

4.1.2.6.  The HttpOnly Attribute

   The HttpOnly attribute limits the scope of the cookie to HTTP
   requests.  In particular, the attribute instructs the user agent to
   omit the cookie when providing access to cookies via non-HTTP APIs.




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 13]

Internet-Draft                   Cookies                   November 2025


4.1.2.7.  The SameSite Attribute

   The SameSite attribute limits the scope of the cookie upon creation
   and delivery with respect to whether the cookie is considered to be
   "same-site" within a larger context (where "same-site" is outside the
   scope of this document).  The SameSite attribute is particularly
   relevant for web browsers and web applications accessible through
   them.

   The SameSite attribute supports Strict, Lax, and None as values.

4.1.3.  Cookie Name Prefixes

   Section 8.5 and Section 8.6 of this document spell out some of the
   drawbacks of cookies' historical implementation.  In particular, it
   is impossible for a server to have confidence that a given cookie was
   set with a particular set of attributes.  In order to provide such
   confidence in a backwards-compatible way, two common sets of
   requirements can be inferred from the first few characters of the
   cookie's name.

   To maximize compatibility with user agents, servers SHOULD use
   prefixes as described below.

4.1.3.1.  The "__Secure-" Prefix

   If a cookie's name begins with a case-sensitive match for the string
   __Secure-, then the cookie will have been set with a Secure
   attribute.

   For example, the following Set-Cookie header field would be rejected
   by a conformant user agent, as it does not have a Secure attribute.

   Set-Cookie: __Secure-SID=12345; Domain=site.example

   Whereas the following Set-Cookie header field would be accepted if
   set from a secure origin (e.g. https://site.example/), and rejected
   otherwise:

   Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

4.1.3.2.  The "__Host-" Prefix

   If a cookie's name begins with a case-sensitive match for the string
   __Host-, then the cookie will have been set with a Secure attribute,
   a Path attribute with a value of /, and no Domain attribute.





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 14]

Internet-Draft                   Cookies                   November 2025


   This combination yields a cookie that hews as closely as a cookie can
   to treating the origin as a security boundary.  The lack of a Domain
   attribute ensures that cookie's host-only is true, locking the cookie
   to a particular host, rather than allowing it to span subdomains.
   Setting the Path to / means that the cookie is effective for the
   entire host, and won't be overridden for specific paths.  The Secure
   attribute ensures that the cookie is unaltered by non-secure origins,
   and won't span protocols.

   Ports are the only piece of the same-origin policy that __Host-
   cookies continue to ignore.

   For example, the following cookies would always be rejected:

   Set-Cookie: __Host-SID=12345
   Set-Cookie: __Host-SID=12345; Secure
   Set-Cookie: __Host-SID=12345; Domain=site.example
   Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
   Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

   While the following would be accepted if set from a secure origin
   (e.g. https://site.example/), and rejected otherwise:

   Set-Cookie: __Host-SID=12345; Secure; Path=/

4.1.3.3.  The "__Http-" Prefix

   If a cookie's name begins with a case-sensitive match for the string
   __Http-, then the cookie will have been set with a Secure attribute,
   and an HttpOnly attribute.

   This helps developers and server operators to know that the cookie
   was set using a Set-Cookie header, and is limited in scope to HTTP
   requests.

4.1.3.4.  The "__Host-Http-" prefix

   If a cookie's name begins with a case-sensitive match for the string
   __Host-Http-, then the cookie will have been set with a Secure
   attribute, an HttpOnly attribute, a Path attribute with a value of /,
   and no Domain attribute.

   This helps developers and server operators to know that the cookie
   was set using a Set-Cookie header, and is limited in scope to HTTP
   requests.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 15]

Internet-Draft                   Cookies                   November 2025


   This combination yields a cookie that hews as closely as a cookie can
   to treating the origin as a security boundary, while at the same time
   ensuring developers and server operators know that its scope is
   limited to HTTP requests.  The lack of a Domain attribute ensures
   that cookie's host-only is true, locking the cookie to a particular
   host, rather than allowing it to span subdomains.  Setting the Path
   to / means that the cookie is effective for the entire host, and
   won't be overridden for specific paths.  The Secure attribute ensures
   that the cookie is unaltered by non-secure origins, and won't span
   protocols.  The HttpOnly attribute ensures that the cookie is not
   exposed by the user agent to non-HTTP APIs.

4.2.  Cookie

4.2.1.  Syntax

   The user agent sends stored cookies to the origin server in the
   Cookie header field.  If the server conforms to the requirements in
   Section 4.1 (and the user agent conforms to the requirements in
   Section 5), the user agent will send a Cookie header field that
   conforms to the following grammar:

   cookie        = cookie-string
   cookie-string = cookie-pair *( ";" SP cookie-pair )

   While Section 5.4 of [RFC9110] does not define a length limit for
   header fields it is likely that the web server's implementation does
   impose a limit; many popular implementations have default limits of 8
   kibibytes.  Servers SHOULD avoid setting a large number of large
   cookies such that the final cookie-string would exceed their header
   field limit.  Not doing so could result in requests to the server
   failing.

   Servers MUST be tolerant of multiple Cookie headers.  For example, an
   HTTP/2 [RFC9113] or HTTP/3 [HTTP] client or intermediary might split
   a Cookie header to improve compression.  Servers are free to
   determine what form this tolerance takes.  For example, the server
   could process each Cookie header individually or the server could
   concatenate all the Cookie headers into one and then process that
   final, single, header.  The server should be mindful of any header
   field limits when deciding which approach to take.

   Note: Since intermediaries can modify Cookie headers they should also
   be mindful of common server header field limits in order to avoid
   sending servers headers that they cannot process.  For example,
   concatenating multiple cookie headers into a single header might
   exceed a server's size limit.




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 16]

Internet-Draft                   Cookies                   November 2025


4.2.2.  Semantics

   Each cookie-pair represents a cookie stored by the user agent.  The
   cookie-pair contains the cookie-name and cookie-value the user agent
   received in the Set-Cookie header field.

   Notice that the cookie attributes are not returned.  In particular,
   the server cannot determine from the Cookie field alone when a cookie
   will expire, for which hosts the cookie is valid, for which paths the
   cookie is valid, or whether the cookie was set with the Secure or
   HttpOnly attributes.

   The semantics of individual cookies in the Cookie header field are
   not defined by this document.  Servers are expected to imbue these
   cookies with application-specific semantics.

   Although cookies are serialized linearly in the Cookie header field,
   servers SHOULD NOT rely upon the serialization order.  In particular,
   if the Cookie header field contains two cookies with the same name
   (e.g., that were set with different Path or Domain attributes),
   servers SHOULD NOT rely upon the order in which these cookies appear
   in the header field.

5.  User Agent Requirements

   This section specifies the processing models associated with the
   Cookie and Set-Cookie header fields in sufficient detail that a user
   agent can interoperate with existing servers (even those that do not
   conform to the well-behaved profile described in Section 4).

   A user agent could enforce more restrictions than those specified
   herein (e.g., restrictions specified by its cookie policy, described
   in Section 7.2).  However, such additional restrictions may reduce
   the likelihood that a user agent will be able to interoperate with
   existing servers.

5.1.  Cookie Concepts

   To facilitate the algorithms that follow, a number of pre-requisite
   concepts need to be introduced.

5.1.1.  Cookie Store And Limits

   A user agent has an associated *cookie store*, which is a list of
   cookies.  It is initially « ».

   A user agent has an associated *total cookies-per-host limit*, which
   is an integer.  It SHOULD be 50 or more.



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 17]

Internet-Draft                   Cookies                   November 2025


   A user agent has an associated *total cookies limit*, which is an
   integer.  It SHOULD be 3000 or more.

   A user agent has an associated *cookie age limit*, which is a number
   of days.  It SHOULD be 400 days or less (see Section 7.2).

5.1.2.  Cookie Struct

   A *cookie* is a struct that represents a piece of state to be
   transmitted between a client and a server.

   A cookie's *name* is a byte sequence.  It always needs to be set.

   A cookie's *value* is a byte sequence.  It always needs to be set.

   A cookie's *secure* is a boolean.  It is initially false.

   A cookie's *host* is a domain, IP address, null, or failure.  It is
   initially null.  Note: Once a cookie is in the user agent's cookie
   store its host is a domain or IP address.

   A cookie's *host-only* is a boolean.  It is initially false.

   A cookie's *path* is a URL path.

   A cookie's *has-path attribute* is a boolean.  It is initially false.

   A cookie's *same-site* is "strict", "lax", "unset", or "none".  It is
   initially "unset".

   A cookie's *http-only* is a boolean.  It is initially false.

   A cookie's *creation-time* is a time.  It is initially the current
   time.

   A cookie's *expiry-time* is null or a time.  It is initially null.
   Note: A prior version of this specification referred to null with a
   distinct "persistent-flag" field being false.

   A cookie's *last-access-time* is a time.  It is initially the current
   time.

5.1.2.1.  Cookie Struct Miscellaneous

   A cookie is *expired* if its expiry-time is non-null and its expiry-
   time is in the past.

   A cookie _cookie_ is *Host-prefix compatible* if:



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 18]

Internet-Draft                   Cookies                   November 2025


   1.  _cookie_'s secure is true;

   2.  _cookie_'s host-only is true;

   3.  _cookie_'s has-path attribute is true; and

   4.  _cookie_'s path's size is 1 and _cookie_'s path[0] is the empty
       string,

   A cookie _cookie_ is *Http-prefix compatible* if:

   1.  _cookie_'s secure is true; and

   2.  _cookie_'s http-only is false,

5.2.  Cookie Store Eviction

5.2.1.  Remove Expired Cookies

   1.  Let _expiredCookies_ be a list of references to all expired
       cookies in the user agent's cookie store.

   2.  For each _cookie_ of _expiredCookies_:

       1.  Remove _cookie_ from the user agent's cookie store.

   3.  Return _expiredCookies_.

5.2.2.  Remove Excess Cookies for a Host

   To *Remove Excess Cookies for a Host* given a host _host_:

   1.  Let _insecureCookies_ be a list of references to all cookies in
       the user agent's cookie store whose host is host-equal to _host_
       and whose secure is false.

   2.  Sort _insecureCookies_ by earliest last-access-time first.

   3.  Let _secureCookies_ be a list of references to all cookies in the
       user agent's cookie store whose host is host-equal to _host_ and
       whose secure is true.

   4.  Sort _secureCookies_ by earliest last-access-time first.

   5.  Let _excessHostCookies_ be an empty list of cookies.

   6.  While _insecureCookies_'s size + _secureCookies_'s size is
       greater than the user agent's total cookies-per-host limit:



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 19]

Internet-Draft                   Cookies                   November 2025


       1.  If _insecureCookies_ is not empty:

           1.  Let _cookie_ be the first item of _insecureCookies_.

           2.  Remove _cookie_ from _insecureCookies_.

           3.  Remove _cookie_ from the user agent's cookie store.

           4.  Append _cookie_ to _excessHostCookies_.

       2.  Otherwise:

           1.  Let _cookie_ be the first item of _secureCookies_.

           2.  Remove _cookie_ from _secureCookies_.

           3.  Remove _cookie_ from the user agent's cookie store.

           4.  Append _cookie_ to _excessHostCookies_.

   7.  Return _excessHostCookies_.

5.2.3.  Remove Global Excess Cookies

   To *Remove Global Excess Cookies*:

   1.  Let _allCookies_ be the result of sorting the user agent's cookie
       store by earliest last-access-time first.

   2.  Let _excessGlobalCookies_ be an empty list of cookies.

   3.  While _allCookies_'s size is greater than the user agent's total
       cookies limit:

       1.  Let _cookie_ be the first item of _allCookies_.

       2.  Remove _cookie_ from _allCookies_.

       3.  Remove _cookie_ from the user agent's cookie store.

       4.  Append _cookie_ to _excessGlobalCookies_.

   4.  Return _excessGlobalCookies_.

5.3.  Subcomponent Algorithms

   This section defines some algorithms used by user agents to process
   specific subcomponents of the Cookie and Set-Cookie header fields.



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 20]

Internet-Draft                   Cookies                   November 2025


5.3.1.  Parse a Date

   To *Parse a Date* given a byte sequence _input_, run these steps.
   They return a date and time or failure.

   Note that the various boolean flags defined as a part of the
   algorithm (i.e., found-time, found-day-of-month, found-month, found-
   year) are initially "not set".

   1.  Using the grammar below, divide the cookie-date into date-tokens.

      cookie-date     = *delimiter date-token-list *delimiter
      date-token-list = date-token *( 1*delimiter date-token )
      date-token      = 1*non-delimiter

      delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
      non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA
                        / %x7F-FF
      non-digit       = %x00-2F / %x3A-FF

      day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
      month           = ( "jan" / "feb" / "mar" / "apr" /
                          "may" / "jun" / "jul" / "aug" /
                          "sep" / "oct" / "nov" / "dec" ) *OCTET
      year            = 2*4DIGIT [ non-digit *OCTET ]
      time            = hms-time [ non-digit *OCTET ]
      hms-time        = time-field ":" time-field ":" time-field
      time-field      = 1*2DIGIT

   2.  Process each date-token sequentially in the order the date-tokens
       appear in the cookie-date:

       1.  If the found-time flag is not set and the token matches the
           time production, set the found-time flag and set the hour-
           value, minute-value, and second-value to the numbers denoted
           by the digits in the date-token, respectively.  Skip the
           remaining sub-steps and continue to the next date-token.

       2.  If the found-day-of-month flag is not set and the date-token
           matches the day-of-month production, set the found-day-of-
           month flag and set the day-of-month-value to the number
           denoted by the date-token.  Skip the remaining sub-steps and
           continue to the next date-token.

       3.  If the found-month flag is not set and the date-token matches
           the month production, set the found-month flag and set the
           month-value to the month denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 21]

Internet-Draft                   Cookies                   November 2025


       4.  If the found-year flag is not set and the date-token matches
           the year production, set the found-year flag and set the
           year-value to the number denoted by the date-token.  Skip the
           remaining sub-steps and continue to the next date-token.

   3.  If the year-value is greater than or equal to 70 and less than or
       equal to 99, increment the year-value by 1900.

   4.  If the year-value is greater than or equal to 0 and less than or
       equal to 69, increment the year-value by 2000.

       1.  NOTE: Some existing user agents interpret two-digit years
           differently.

   5.  If one of the following is true:

       *  at least one of the found-day-of-month, found-month, found-
          year, or found-time flags is not set,

       *  the day-of-month-value is less than 1 or greater than 31,

       *  the year-value is less than 1601,

       *  the hour-value is greater than 23,

       *  the minute-value is greater than 59, or

       *  the second-value is greater than 59,

       then return failure.

       (Note that leap seconds cannot be represented in this syntax.)

   6.  Let the parsed-cookie-date be the date whose day-of-month, month,
       year, hour, minute, and second (in UTC) are the day-of-month-
       value, the month-value, the year-value, the hour-value, the
       minute-value, and the second-value, respectively.  If no such
       date exists, abort these steps and fail to parse the cookie-date.

   7.  Return the parsed-cookie-date as the result of this algorithm.

5.3.2.  Domain Matching

   A host _host_ *Domain-Matches* a string _domainAttributeValue_ if at
   least one of the following is true:

   *  _host_ equals _domainAttributeValue_, or




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 22]

Internet-Draft                   Cookies                   November 2025


   *  if all of the following are true:

      -  _host_ is a domain, and

      -  _host_ ends with the concatenation of U+002E (.) and
         _domainAttributeValue_.

5.3.3.  Cookie Default Path

   To determine the *Cookie Default Path*, given a URL path _path_, run
   these steps.  They return a URL path.

   1.  Assert: _path_ is a non-empty list.

   2.  If _path_'s size is greater than 1, then remove _path_'s last
       item.

   3.  Otherwise, set _path_[0] to the empty string.

   4.  Return _path_.

5.3.4.  Path Matching

   To determine if a URL path _requestPath_ *Path-Matches* a URL path
   _cookiePath_, run these steps.  They return a boolean.

   1.  Let _serializedRequestPath_ be the result of URL path serializing
       _requestPath_.

   2.  Let _serializedCookiePath_ be the result of URL path serializing
       _cookiePath_.

   3.  If _serializedCookiePath_ is _serializedRequestPath_, then return
       true.

   4.  If _serializedRequestPath_ starts with _serializedCookiePath_ and
       _serializedCookiePath_ ends with a U+002F (/), then return true.

   5.  Return whether the concatenation of _serializedRequestPath_
       followed by U+002F (/) starts with _serializedCookiePath_.

5.4.  Main Algorithms









van Kesteren & Hofmann     Expires 22 May 2026                 [Page 23]

Internet-Draft                   Cookies                   November 2025


5.4.1.  Parse and Store a Cookie

   To *Parse and Store a Cookie* given a byte sequence _input_, boolean
   _isSecure_, domain or IP address _host_, URL path _path_, boolean
   _httpOnlyAllowed_, boolean _allowNonHostOnlyCookieForPublicSuffix_,
   and boolean _sameSiteStrictOrLaxAllowed_:

   1.  Let _cookie_ be the result of running Parse a Cookie with
       _input_, _isSecure_, _host_, and _path_.

   2.  If _cookie_ is failure, then return.

   3.  Return the result of Store a Cookie given _cookie_, _isSecure_,
       _host_, _path_, _httpOnlyAllowed_,
       _allowNonHostOnlyCookieForPublicSuffix_, and
       _sameSiteStrictOrLaxAllowed_.

5.4.2.  Parse a Cookie

   To *Parse a Cookie* given a byte sequence _input_, boolean
   _isSecure_, host _host_, URL path _path_, run these steps.  They
   return a new cookie or failure:

   1.   If _input_ contains a byte in the range 0x00 to 0x08, inclusive,
        the range 0x0A to 0x1F inclusive, or 0x7F (CTL bytes excluding
        HTAB), then return failure.

   2.   Let _nameValueInput_ be null.

   3.   Let _attributesInput_ be the empty byte sequence.

   4.   If _input_ contains 0x3B (;), then set _nameValueInput_ to the
        bytes up to, but not including, the first 0x3B (;), and
        _attributesInput_ to the remainder of _input_ (including the
        0x3B (;) in question).

   5.   Otherwise, set _nameValueInput_ to _input_.

   6.   Assert: _nameValueInput_ is a byte sequence.

   7.   Let _name_ be null.

   8.   Let _value_ be null.

   9.   If _nameValueInput_ does not contain a 0x3D (=) character, then
        set _name_ to the empty byte sequence, and _value_ to
        _nameValueInput_.




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 24]

Internet-Draft                   Cookies                   November 2025


   10.  Otherwise, set _name_ to the bytes up to, but not including, the
        first 0x3D (=), and set _value_ to the bytes after the first
        0x3D (=) (possibly being the empty byte sequence).

   11.  Remove any leading or trailing WSP bytes from _name_ and
        _value_.

   12.  If _name_'s length + _value_'s length is 0 or is greater than
        4096, then return failure.

   13.  Let _cookie_ be a new cookie whose name is _name_ and value is
        _value_.

   14.  Set _cookie_'s path to the result of running Cookie Default Path
        with _path_.

        Note: A Path attribute can override this.

   15.  While _attributesInput_ is not an empty byte sequence:

        1.   Let _maxAgeSeen_ be false.

        2.   Let _char_ be the result of consuming the first byte of
             _attributesInput_.

        3.   Assert: _char_ is 0x3B (;).

        4.   Let _attributeNameValueInput_ be null.

        5.   If _attributesInput_ contains 0x3B (;), then set
             _attributeNameValueInput_ to the result of consuming the
             bytes of _attributesInput_ up to, but not including, the
             first 0x3B (;).

        6.   Otherwise, set _attributeNameValueInput_ to the result of
             consuming the remainder of _attributesInput_.

        7.   Let _attributeName_ be null.

        8.   Let _attributeValue_ be the empty string.

        9.   If _attributeNameValueInput_ contains a 0x3D (=), then set
             _attributeName_ to the bytes up to, but not including, the
             first 0x3D (=) of _attributeNameValueInput_, and
             _attributeValue_ to the bytes after the first 0x3D (=) of
             _attributeNameValueInput_.





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 25]

Internet-Draft                   Cookies                   November 2025


        10.  Otherwise, set _attributeName_ to
             _attributeNameValueInput_.

        11.  Remove any leading or trailing WSP bytes from
             _attributeName_ and _attributeValue_.

        12.  If _attributeValue_'s length is greater than 1024, then
             continue.

        13.  If _attributeName_ is a byte-case-insensitive match for
             Expires:

             1.  If _maxAgeSeen_ is true, then continue.

             2.  Let _expiryTime_ be the result of running Parse a Date
                 given _attributeValue_.

             3.  If _attributeValue_ is failure, then continue.

             4.  If _expiryTime_ is greater than the current time and
                 date + the user agent's cookie age limit, then set
                 _expiryTime_ to the user agent's cookie age limit.

             5.  If _expiryTime_ is earlier than the earliest date the
                 user agent can represent, the user agent MAY replace
                 _expiryTime_ with the earliest representable date.

             6.  Set _cookie_'s expiry-time to _expiryTime_.

        14.  If _attributeName_ is a byte-case-insensitive match for
             Max-Age:

             1.  If _attributeValue_ is empty, continue.

             2.  If the first byte of _attributeValue_ is neither a
                 DIGIT, nor 0x2D (-) followed by a DIGIT, then continue.

             3.  If the remainder of _attributeValue_ contains a non-
                 DIGIT, then continue.

             4.  Let _deltaSeconds_ be _attributeValue_, converted to a
                 base 10 integer.

             5.  Set _deltaSeconds_ to the smaller of _deltaSeconds_ and
                 the user agent's cookie age limit, in seconds.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 26]

Internet-Draft                   Cookies                   November 2025


             6.  If _deltaSeconds_ is less than or equal to 0, let
                 _expiryTime_ be the earliest representable date and
                 time.  Otherwise, let _expiryTime_ be the current date
                 and time + _deltaSeconds_ seconds.

             7.  Set _cookie_'s expiry-time to _expiryTime_.

             8.  Set _maxAgeSeen_ to true.

        15.  If _attributeName_ is a byte-case-insensitive match for
             Domain:

             1.  Let _host_ be failure.

             2.  If _attributeValue_ contains only ASCII bytes:

                 1.  Let _hostInput_ be _attributeValue_, ASCII decoded.

                 2.  If _hostInput_ starts with U+002E (.), then set
                     _hostInput_ to _hostInput_ without its leading
                     U+002E (.).

                 3.  Set _host_ to the result of host parsing
                     _hostInput_.

             3.  Set _cookie_'s host to _host_.

        16.  If _attributeName_ is a byte-case-insensitive match for
             Path:

             1.  If _attributeValue_ is not empty and if the first byte
                 of _attributeValue_ is 0x2F (/), then:

                 1.  Set _cookie_'s path to _attributeValue_ split on
                     0x2F (/).

                 2.  Set _cookie_'s has-path attribute to true.

        17.  If _attributeName_ is a byte-case-insensitive match for
             Secure:

             1.  Set _cookie_'s secure to true.

        18.  If _attributeName_ is a byte-case-insensitive match for
             HttpOnly:

             1.  Set _cookie_'s http-only to true.




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 27]

Internet-Draft                   Cookies                   November 2025


        19.  If _attributeName_ is a byte-case-insensitive match for
             SameSite:

             1.  If _attributeValue_ is a byte-case-insensitive match
                 for None, then set _cookie_'s same-site to "none".

             2.  If _attributeValue_ is a byte-case-insensitive match
                 for Strict, then set _cookie_'s same-site to "strict".

             3.  If _attributeValue_ is a byte-case-insensitive match
                 for Lax, then set _cookie_'s same-site to "lax".

   16.  Return _cookie_.

   Note: Attributes with an unrecognized _attributeName_ are ignored.

   Note: This intentionally overrides earlier cookie attributes so that
   generally the last specified cookie attribute "wins".

5.4.3.  Store a Cookie

   To *Store a Cookie* given a cookie _cookie_, boolean _isSecure_,
   domain or IP address _host_, boolean _httpOnlyAllowed_, boolean
   _allowNonHostOnlyCookieForPublicSuffix_, and boolean
   _sameSiteStrictOrLaxAllowed_:

   1.   Assert: _cookie_'s name's length + _cookie_'s value's length is
        not 0 or greater than 4096.

   2.   Assert: _cookie_'s name does not contain a byte in the range
        0x00 to 0x08, inclusive, in the range 0x0A to 0x1F, inclusive,
        or 0x7F (CTL characters excluding HTAB).

   3.   If _cookie_'s host is failure, then return null.

   4.   Set _cookie_'s creation-time and last-access-time to the current
        date and time.

   5.   If _allowNonHostOnlyCookieForPublicSuffix_ is false and
        _cookie_'s host is a public suffix:

        1.  If _cookie_'s host is host-equal to _host_, then set
            _cookie_'s host to null.

        2.  Otherwise, return null.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 28]

Internet-Draft                   Cookies                   November 2025


        Note: This step prevents attacker.example from disrupting the
        integrity of site.example by setting a cookie with a Domain
        attribute of example.  In the event the end user navigates
        directly to example, a cookie can still be set and will forcibly
        have its host-only set to true.

   6.   If _cookie_'s host is null:

        1.  Set _cookie_'s host-only to true.

        2.  Set _cookie_'s host to _host_.

   7.   Otherwise:

        1.  If _host_ does not Domain-Match _cookie_'s host, then return
            null.

        2.  Set _cookie_'s host-only to false.

   8.   Assert: _cookie_'s host is a domain or IP address.

   9.   If _httpOnlyAllowed_ is false and _cookie_'s http-only is true,
        then return null.

   10.  If _isSecure_ is false:

        1.  If _cookie_'s secure is true, then return null.

        2.  If the user agent's cookie store contains at least one
            cookie _existingCookie_ that meets all of the following
            criteria:

            1.  _existingCookie_'s name is _cookie_'s name;

            2.  _existingCookie_'s secure is true;

            3.  _existingCookie_'s host Domain-Matches _cookie_'s host,
                or vice-versa; and

            4.  _cookie_'s path Path-Matches _existingCookie_'s path,

            then return null.









van Kesteren & Hofmann     Expires 22 May 2026                 [Page 29]

Internet-Draft                   Cookies                   November 2025


            Note: The path comparison is not symmetric, ensuring only
            that a newly-created, non-secure cookie does not overlay an
            existing secure cookie, providing some mitigation against
            cookie-fixing attacks.  That is, given an existing secure
            cookie named 'a' with a path of '/login', a non-secure
            cookie named 'a' could be set for a path of '/' or '/foo',
            but not for a path of '/login' or '/login/en'.

   11.  If _cookie_'s same-site is not "none" and
        _sameSiteStrictOrLaxAllowed_ is false, then return null.

   12.  If _cookie_'s same-site is "none" and _cookie_'s secure is
        false, then return null.

   13.  If _cookie_'s name, byte-lowercased, starts with __secure- and
        _cookie_'s secure is false, then return null.

        Note: The check here and those below are with a byte-lowercased
        value in order to protect servers that process these values in a
        case-insensitive manner.

   14.  If _cookie_'s name, byte-lowercased, starts with __host- and
        _cookie_ is not Host-prefix compatible, then return null.

   15.  If _cookie_'s name, byte-lowercased, starts with __http- and
        _cookie_ is not Http-prefix compatible, then return null.

   16.  If _cookie_'s name, byte-lowercased, starts with __host-http-
        and _cookie_ is not both Host-prefix compatible and Http-prefix
        compatible, then return null.

   17.  If _cookie_'s name is the empty byte sequence and one of the
        following is true:

        *  _cookie_'s value, byte-lowercased, starts with __secure-,

        *  _cookie_'s value, byte-lowercased, starts with __host-,

        *  _cookie_'s value, byte-lowercased, starts with __http-, or

        *  _cookie_'s value, byte-lowercased, starts with __host-http-,

        then return null.

   18.  If the user agent's cookie store contains a cookie _oldCookie_
        whose name is _cookie_'s name, host is host-equal to _cookie_'s
        host, host-only is _cookie_'s host-only, and path is path-equal
        to _cookie_'s path:



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 30]

Internet-Draft                   Cookies                   November 2025


        1.  If _httpOnlyAllowed_ is false and _oldCookie_'s http-only is
            true, then return null.

        2.  If _cookie_'s secure is equal to _oldCookie_'s secure,
            _cookie_'s same-site is equal to _oldCookie_'s same-site,
            and _cookie_'s expiry-time is equal to _oldCookie_'s expiry-
            time, then return null.

        3.  Set _cookie_'s creation-time to _oldCookie_'s creation-time.

        4.  Remove _oldCookie_ from the user agent's cookie store.

        Note: This algorithm maintains the invariant that there is at
        most one such cookie.

   19.  Insert _cookie_ into the user agent's cookie store.

   20.  Return _cookie_.

5.4.4.  Garbage Collect Cookies

   To *Garbage Collect Cookies* given a host _host_:

   1.  Let _expiredCookies_ be the result of running Remove Expired
       Cookies.

   2.  Let _excessHostCookies_ be the result of running Remove Excess
       Cookies for Host given _host_.

   3.  Let _excessGlobalCookies_ be the result of running Remove Global
       Excess Cookies.

   4.  Let _removedCookies_ be « ».

   5.  For each _cookieList_ of « _expiredCookies_, _excessHostCookies_,
       _excessGlobalCookies_ », do the following:

       1.  Extend _removedCookies_ with _cookieList_.

   6.  Return _removedCookies_

5.4.5.  Retrieve Cookies

   To *Retrieve Cookies* given a boolean _isSecure_, host _host_, URL
   path _path_, boolean _httpOnlyAllowed_, and string _sameSite_:

   1.  Assert: _sameSite_ is "strict-or-less", "lax-or-less", "unset-or-
       less", or "none".



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 31]

Internet-Draft                   Cookies                   November 2025


   2.  Let _cookies_ be all cookies from the user agent's cookie store
       that meet these conditions:

       *  One of the following is true:

          -  cookie's host-only is true and _host_ is host-equal to
             cookie's host, or

          -  cookie's host-only is false and _host_ Domain-Matches
             cookie's host.

          It's possible that the public suffix list changed since a
          cookie was created.  If this change results in a cookie's host
          becoming a public suffix and the cookie's host-only is false,
          then that cookie SHOULD NOT be returned.

          XXX: We should probably move this requirement out-of-bound as
          this invalidation should happen as part of updating the public
          suffixes.

       *  _path_ Path-Matches cookie's path.

       *  One of the following is true:

          -  cookie's secure is true and _isSecure_ is true, or

          -  cookie's secure is false.

       *  One of the following is true:

          -  cookie's http-only is true and _httpOnlyAllowed_ is true,
             or

          -  cookie's http-only is false.

       *  One of the following is true:

          -  cookie's same-site is "strict" and _sameSite_ is "strict-
             or-less";

          -  cookie's same-site is "lax" and _sameSite_ is one of
             "strict-or-less" or "lax-or-less";

          -  cookie's same-site is "unset" and _sameSite_ is one of
             "strict-or-less", "lax-or-less", or "unset-or-less"; or

          -  cookie's same-site is "none".




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 32]

Internet-Draft                   Cookies                   November 2025


   3.  Sort _cookies_ in the following order:

       *  Cookies whose path's size is greater are listed before cookies
          whose path's size is smaller.

       *  Among cookies whose path's size is equal, cookies whose
          creation-time is earlier are listed before cookies whose
          creation-time is later.

   4.  Set the last-access-time of each cookie of _cookies_ to the
       current date and time and reflect these changes in the user
       agent's cookie store.

   5.  Return _cookies_.

5.4.6.  Serialize Cookies

   To *Serialize Cookies* given a list of cookies _cookies_:

   1.  Let _output_ be an empty byte sequence.

   2.  For each _cookie_ of _cookies_:

       1.  If _output_ is not the empty byte sequence, then append 0x3B
           (;) followed by 0x20 (SP) to _output_.

       2.  If _cookie_'s name is not the empty byte sequence, then
           append _cookie_'s name followed by 0x3D (=) to _output_.

       3.  Append _cookie_'s value to _output_.

   3.  Return _output_.

5.5.  Requirements Specific to Non-Browser User Agents

5.5.1.  The Set-Cookie Header Field

   When a user agent receives a Set-Cookie header field in an HTTP
   response, the user agent MAY ignore the Set-Cookie header field in
   its entirety as per its cookie policy (see Section 7.2).

   User agents MAY ignore Set-Cookie header fields contained in
   responses with 100-level status codes.

   Set-Cookie header fields contained in responses with non-100-level
   status codes (including those in responses with 400- and 500-level
   status codes) SHOULD be processed as follows:




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 33]

Internet-Draft                   Cookies                   November 2025


   1.  Let _isSecure_ be a boolean indicating whether request's URL's
       scheme is deemed secure, in an implementation-defined manner.

   2.  Let _host_ be request's host.

   3.  Let _path_ be request's URL's path.

   4.  Let _httpOnlyAllowed_ be true.

   5.  Let _allowNonHostOnlyCookieForPublicSuffix_ be a boolean whose
       value is implementation-defined.

   6.  Let _sameSiteStrictOrLaxAllowed_ be a boolean whose value is
       implementation-defined.

   7.  Let _cookie_ be the result of running Parse and Store a Cookie
       given the header field value, _isSecure_, _host_, _path_,
       _httpOnlyAllowed_, _allowNonHostOnlyCookieForPublicSuffix_, and
       _sameSiteStrictOrLaxAllowed_.

   8.  If _cookie_ is null, then return.

   9.  Run Garbage Collect Cookies given _cookie_'s host.

5.5.2.  The Cookie Header Field

   The user agent includes stored cookies in the Cookie request header
   field.

   When the user agent generates an HTTP request, the user agent MUST
   NOT attach more than one Cookie header field.

   A user agent MAY omit the Cookie header field in its entirety.

   If the user agent does attach a Cookie header field to an HTTP
   request, the user agent MUST compute its value as follows:

   1.  Let _isSecure_ be a boolean indicating whether request's URL's
       scheme is deemed secure, in an implementation-defined manner.

   2.  Let _host_ be request's host.

   3.  Let _path_ be request's URL's path.

   4.  Let _httpOnlyAllowed_ be true.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 34]

Internet-Draft                   Cookies                   November 2025


   5.  Let _sameSite_ be a string whose value is implementation-defined,
       but has to be one of "strict-or-less", "lax-or-less", "unset-or-
       less", or "none".

   6.  Let _cookies_ be the result of running Retrieve Cookies given
       _isSecure_, _host_, _path_, _httpOnlyAllowed_, and _sameSite_.

   7.  Return the result of running Serialize Cookies given _cookies_.

   Note: Previous versions of this specification required that only one
   Cookie header field be sent in requests.  This is no longer a
   requirement.  While this specification requires that a single cookie-
   string be produced, some user agents may split that string across
   multiple Cookie header fields.  For examples, see Section 8.2.3 of
   [RFC9113] and Section 4.2.1 of [HTTP].

5.5.3.  Cookie Store Eviction for Non-Browser User Agents

   The user agent SHOULD evict all expired cookies from its cookie store
   if, at any time, an expired cookie exists in the cookie store, by
   calling Remove Expired Cookies.

   When "the current session is over" (as defined by the user agent),
   the user agent MUST remove from the cookie store all cookies whose
   expiry-time is null.

5.6.  Requirements Specific to Browser User Agents

   While browsers are expected to generally follow the same model as
   non-browser user agents, they have additional complexity due to the
   document model (and the ability to nest documents) that is considered
   out-of-scope for this specification.

   Specifications for such a user agent are expected to build upon the
   following algorithms and invoke them appropriately to process Cookie
   and Set-Cookie header fields, as well as manipulating the user
   agent's cookie store through non-HTTP APIs:

   *  Parse and Store a Cookie

   *  Store a Cookie

   *  Remove Expired Cookies

   *  Garbage Collect Cookies

   *  Retrieve Cookies




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 35]

Internet-Draft                   Cookies                   November 2025


   *  Serialize Cookies

   This provides the flexibility browsers need to detail their
   requirements in considerable detail.

6.  Implementation Considerations

6.1.  Limits

   Servers SHOULD use as few and as small cookies as possible to avoid
   reaching these implementation limits, minimize network bandwidth due
   to the Cookie header field being included in every request, and to
   avoid reaching server header field limits (See Section 4.2.1).

   Servers SHOULD gracefully degrade if the user agent fails to return
   one or more cookies in the Cookie header field because the user agent
   might evict any cookie at any time.

6.2.  Application Programming Interfaces

   One reason the Cookie and Set-Cookie header fields use such esoteric
   syntax is that many platforms (both in servers and user agents)
   provide a string-based application programming interface (API) to
   cookies, requiring application-layer programmers to generate and
   parse the syntax used by the Cookie and Set-Cookie header fields,
   which many programmers have done incorrectly, resulting in
   interoperability problems.

   Instead of providing string-based APIs to cookies, platforms would be
   well-served by providing more semantic APIs.  It is beyond the scope
   of this document to recommend specific API designs, but there are
   clear benefits to accepting an abstract "Date" object instead of a
   serialized date string.

7.  Privacy Considerations

   Cookies' primary privacy risk is their ability to correlate user
   activity.  This can happen on a single site, but is most problematic
   when activity is tracked across different, seemingly unconnected Web
   sites to build a user profile.

   Over time, this capability (warned against explicitly in [RFC2109]
   and all of its successors) has become widely used for varied reasons
   including:

   *  authenticating users across sites,

   *  assembling information on users,



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 36]

Internet-Draft                   Cookies                   November 2025


   *  protecting against fraud and other forms of undesirable traffic,

   *  targeting advertisements at specific users or at users with
      specified attributes,

   *  measuring how often ads are shown to users, and

   *  recognizing when an ad resulted in a change in user behavior.

   While not every use of cookies is necessarily problematic for
   privacy, their potential for abuse has become a widespread concern in
   the Internet community and broader society.  In response to these
   concerns, user agents have actively constrained cookie functionality
   in various ways (as allowed and encouraged by previous
   specifications), while avoiding disruption to features they judge
   desirable for the health of the Web.

   It is too early to declare consensus on which specific mechanism(s)
   should be used to mitigate cookies' privacy impact; user agents'
   ongoing changes to how they are handled are best characterised as
   experiments that can provide input into that eventual consensus.

   Instead, this document describes limited, general mitigations against
   the privacy risks associated with cookies that enjoy wide deployment
   at the time of writing.  It is expected that implementations will
   continue to experiment and impose stricter, more well-defined
   limitations on cookies over time.  Future versions of this document
   might codify those mechanisms based upon deployment experience.  If
   functions that currently rely on cookies can be supported by
   separate, targeted mechanisms, they might be documented in separate
   specifications and stricter limitations on cookies might become
   feasible.

   Note that cookies are not the only mechanism that can be used to
   track users across sites, so while these mitigations are necessary to
   improve Web privacy, they are not sufficient on their own.

7.1.  Third-Party Cookies

   A "third-party" or cross-site cookie is one that is associated with
   embedded content (such as scripts, images, stylesheets, frames) that
   is obtained from a different server than the one that hosts the
   primary resource (usually, the Web page that the user is viewing).
   Third-party cookies are often used to correlate users' activity on
   different sites.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 37]

Internet-Draft                   Cookies                   November 2025


   Because of their inherent privacy issues, most user agents now limit
   third-party cookies in a variety of ways.  Some completely block
   third-party cookies by refusing to process third-party Set-Cookie
   header fields and refusing to send third-party Cookie header fields.
   Some partition cookies based upon the first-party context, so that
   different cookies are sent depending on the site being browsed.  Some
   block cookies based upon user agent cookie policy and/or user
   controls.

   While this document does not endorse or require a specific approach,
   it is RECOMMENDED that user agents adopt a policy for third-party
   cookies that is as restrictive as compatibility constraints permit.
   Consequently, resources cannot rely upon third-party cookies being
   treated consistently by user agents for the foreseeable future.

7.2.  Cookie Policy

   User agents MAY enforce a cookie policy consisting of restrictions on
   how cookies may be used or ignored (see Section 5.5.1).

   A cookie policy may govern which domains or parties, as in first and
   third parties (see Section 7.1), for which the user agent will allow
   cookie access.  The policy can also define limits on cookie size,
   cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the
   number of cookies per domain or in total.

   The goal of a restrictive cookie policy is often to improve security
   or privacy.  User agents often allow users to change the cookie
   policy (see Section 7.3).

7.3.  User Controls

   User agents SHOULD provide users with a mechanism for managing the
   cookies stored in the cookie store.  For example, a user agent might
   let users delete all cookies received during a specified time period
   or all the cookies related to a particular domain.  In addition, many
   user agents include a user interface element that lets users examine
   the cookies stored in their cookie store.

   User agents SHOULD provide users with a mechanism for disabling
   cookies.  When cookies are disabled, the user agent MUST NOT include
   a Cookie header field in outbound HTTP requests and the user agent
   MUST NOT process Set-Cookie header fields in inbound HTTP responses.

   User agents MAY offer a way to change the cookie policy (see
   Section 7.2).





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 38]

Internet-Draft                   Cookies                   November 2025


   User agents MAY provide users the option of preventing persistent
   storage of cookies across sessions.  When configured thusly, user
   agents MUST treat all received cookies as if their expiry-time is
   null.

7.4.  Expiration Dates

   Although servers can set the expiration date for cookies to the
   distant future, most user agents do not actually retain cookies for
   multiple decades.  Rather than choosing gratuitously long expiration
   periods, servers SHOULD promote user privacy by selecting reasonable
   cookie expiration periods based on the purpose of the cookie.  For
   example, a typical session identifier might reasonably be set to
   expire in two weeks.

8.  Security Considerations

8.1.  Overview

   Cookies have a number of security pitfalls.  This section overviews a
   few of the more salient issues.

   In particular, cookies encourage developers to rely on ambient
   authority for authentication, often becoming vulnerable to attacks
   such as cross-site request forgery [CSRF].  Also, when storing
   session identifiers in cookies, developers often create session
   fixation vulnerabilities.

   Transport-layer encryption, such as that employed in HTTPS, is
   insufficient to prevent a network attacker from obtaining or altering
   a victim's cookies because the cookie protocol itself has various
   vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
   below).  In addition, by default, cookies do not provide
   confidentiality or integrity from network attackers, even when used
   in conjunction with HTTPS.

8.2.  Ambient Authority

   A server that uses cookies to authenticate users can suffer security
   vulnerabilities because some user agents let remote parties issue
   HTTP requests from the user agent (e.g., via HTTP redirects or HTML
   forms).  When issuing those requests, user agents attach cookies even
   if the remote party does not know the contents of the cookies,
   potentially letting the remote party exercise authority at an unwary
   server.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 39]

Internet-Draft                   Cookies                   November 2025


   Although this security concern goes by a number of names (e.g.,
   cross-site request forgery, confused deputy), the issue stems from
   cookies being a form of ambient authority.  Cookies encourage server
   operators to separate designation (in the form of URLs) from
   authorization (in the form of cookies).  Consequently, the user agent
   might supply the authorization for a resource designated by the
   attacker, possibly causing the server or its clients to undertake
   actions designated by the attacker as though they were authorized by
   the user.

   Instead of using cookies for authorization, server operators might
   wish to consider entangling designation and authorization by treating
   URLs as capabilities.  Instead of storing secrets in cookies, this
   approach stores secrets in URLs, requiring the remote entity to
   supply the secret itself.  Although this approach is not a panacea,
   judicious application of these principles can lead to more robust
   security.

8.3.  Clear Text

   Unless sent over a secure channel (such as TLS [TLS13]), the
   information in the Cookie and Set-Cookie header fields is transmitted
   in the clear.

   1.  All sensitive information conveyed in these header fields is
       exposed to an eavesdropper.

   2.  A malicious intermediary could alter the header fields as they
       travel in either direction, with unpredictable results.

   3.  A malicious client could alter the Cookie header fields before
       transmission, with unpredictable results.

   Servers SHOULD encrypt and sign the contents of cookies (using
   whatever format the server desires) when transmitting them to the
   user agent (even when sending the cookies over a secure channel).
   However, encrypting and signing cookie contents does not prevent an
   attacker from transplanting a cookie from one user agent to another
   or from replaying the cookie at a later time.

   In addition to encrypting and signing the contents of every cookie,
   servers that require a higher level of security SHOULD use the Cookie
   and Set-Cookie header fields only over a secure channel.  When using
   cookies over a secure channel, servers SHOULD set the Secure
   attribute (see Section 4.1.2.5) for every cookie.  If a server does
   not set the Secure attribute, the protection provided by the secure
   channel will be largely moot.




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 40]

Internet-Draft                   Cookies                   November 2025


   For example, consider a webmail server that stores a session
   identifier in a cookie and is typically accessed over HTTPS.  If the
   server does not set the Secure attribute on its cookies, an active
   network attacker can intercept any outbound HTTP request from the
   user agent and redirect that request to the webmail server over HTTP.
   Even if the webmail server is not listening for HTTP connections, the
   user agent will still include cookies in the request.  The active
   network attacker can intercept these cookies, replay them against the
   server, and learn the contents of the user's email.  If, instead, the
   server had set the Secure attribute on its cookies, the user agent
   would not have included the cookies in the clear-text request.

8.4.  Session Identifiers

   Instead of storing session information directly in a cookie (where it
   might be exposed to or replayed by an attacker), servers commonly
   store a nonce (or "session identifier") in a cookie.  When the server
   receives an HTTP request with a nonce, the server can look up state
   information associated with the cookie using the nonce as a key.

   Using session identifier cookies limits the damage an attacker can
   cause if the attacker learns the contents of a cookie because the
   nonce is useful only for interacting with the server (unlike non-
   nonce cookie content, which might itself be sensitive).  Furthermore,
   using a single nonce prevents an attacker from "splicing" together
   cookie content from two interactions with the server, which could
   cause the server to behave unexpectedly.

   Using session identifiers is not without risk.  For example, the
   server SHOULD take care to avoid "session fixation" vulnerabilities.
   A session fixation attack proceeds in three steps.  First, the
   attacker transplants a session identifier from his or her user agent
   to the victim's user agent.  Second, the victim uses that session
   identifier to interact with the server, possibly imbuing the session
   identifier with the user's credentials or confidential information.
   Third, the attacker uses the session identifier to interact with
   server directly, possibly obtaining the user's authority or
   confidential information.

8.5.  Weak Confidentiality

   Cookies do not provide isolation by port.  If a cookie is readable by
   a service running on one port, the cookie is also readable by a
   service running on another port of the same server.  If a cookie is
   writable by a service on one port, the cookie is also writable by a
   service running on another port of the same server.  For this reason,
   servers SHOULD NOT both run mutually distrusting services on
   different ports of the same host and use cookies to store security-



van Kesteren & Hofmann     Expires 22 May 2026                 [Page 41]

Internet-Draft                   Cookies                   November 2025


   sensitive information.

   Cookies do not provide isolation by scheme.  Although most commonly
   used with the http and https schemes, the cookies for a given host
   might also be available to other schemes, such as ftp and gopher.
   Although this lack of isolation by scheme is most apparent in non-
   HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
   API), the lack of isolation by scheme is actually present in
   requirements for processing cookies themselves (e.g., consider
   retrieving a URI with the gopher scheme via HTTP).

   Cookies do not always provide isolation by path.  Although the
   network-level protocol does not send cookies stored for one path to
   another, some user agents expose cookies via non-HTTP APIs, such as
   HTML's document.cookie API.  Because some of these user agents (e.g.,
   web browsers) do not isolate resources received from different paths,
   a resource retrieved from one path might be able to access cookies
   stored for another path.

8.6.  Weak Integrity

   Cookies do not provide integrity guarantees for sibling domains (and
   their subdomains).  For example, consider foo.site.example and
   bar.site.example.  The foo.site.example server can set a cookie with
   a Domain attribute of "site.example" (possibly overwriting an
   existing "site.example" cookie set by bar.site.example), and the user
   agent will include that cookie in HTTP requests to bar.site.example.
   In the worst case, bar.site.example will be unable to distinguish
   this cookie from a cookie it set itself.  The foo.site.example server
   might be able to leverage this ability to mount an attack against
   bar.site.example.

   Even though the Set-Cookie header field supports the Path attribute,
   the Path attribute does not provide any integrity protection because
   the user agent will accept an arbitrary Path attribute in a Set-
   Cookie header field.  For example, an HTTP response to a request for
   http://site.example/foo/bar can set a cookie with a Path attribute of
   "/qux".  Consequently, servers SHOULD NOT both run mutually
   distrusting services on different paths of the same host and use
   cookies to store security-sensitive information.











van Kesteren & Hofmann     Expires 22 May 2026                 [Page 42]

Internet-Draft                   Cookies                   November 2025


   An active network attacker can also inject cookies into the Cookie
   header field sent to https://site.example/ by impersonating a
   response from http://site.example/ and injecting a Set-Cookie header
   field.  The HTTPS server at site.example will be unable to
   distinguish these cookies from cookies that it set itself in an HTTPS
   response.  An active network attacker might be able to leverage this
   ability to mount an attack against site.example even if site.example
   uses HTTPS exclusively.

   Servers can partially mitigate these attacks by encrypting and
   signing the contents of their cookies, or by naming the cookie with
   the __Secure- prefix.  However, using cryptography does not mitigate
   the issue completely because an attacker can replay a cookie he or
   she received from the authentic site.example server in the user's
   session, with unpredictable results.

   Finally, an attacker might be able to force the user agent to delete
   cookies by storing a large number of cookies.  Once the user agent
   reaches its storage limit, the user agent will be forced to evict
   some cookies.  Servers SHOULD NOT rely upon user agents retaining
   cookies.

8.7.  Reliance on DNS

   Cookies rely upon the Domain Name System (DNS) for security.  If the
   DNS is partially or fully compromised, the cookie protocol might fail
   to provide the security properties required by applications.

8.8.  SameSite Cookies

   SameSite cookies offer a robust defense against CSRF attack when
   deployed in strict mode, and when supported by the client.  It is,
   however, prudent to ensure that this designation is not the extent of
   a site's defense against CSRF, as same-site navigations and
   submissions can certainly be executed in conjunction with other
   attack vectors such as cross-site scripting.

   Developers are strongly encouraged to deploy the usual server-side
   defenses (CSRF tokens, ensuring that "safe" HTTP methods are
   idempotent, etc) to mitigate the risk more fully.

9.  IANA Considerations

9.1.  Cookie

   The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to
   be updated with the following registration:




van Kesteren & Hofmann     Expires 22 May 2026                 [Page 43]

Internet-Draft                   Cookies                   November 2025


   Header field name:  Cookie

   Applicable protocol:  http

   Status:  standard

   Author/Change controller:  IETF

   Specification document:  this specification (Section 5.5.2)

9.2.  Set-Cookie

   The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to
   be updated with the following registration:

   Header field name:  Set-Cookie

   Applicable protocol:  http

   Status:  standard

   Author/Change controller:  IETF

   Specification document:  this specification (Section 5.5.1)

10.  Changes

   Revamped the document to allow for more detailed requirements on
   browsers in downstream specifications.

Acknowledgements

   Many thanks to Adam Barth for laying the groundwork for a modern
   cookie specification with RFC 6265.

   And many thanks to Steven Bingler, Lily Chen, Dylan Cutler, Steven
   Englehardt, Yoav Weiss, Mike West, and John Wilander for improving
   upon that work.

References

Normative References

   [HTML]     Hickson, I., Pieters, S., van Kesteren, A., Jägenstedt,
              P., and D. Denicola, "HTML", n.d.,
              <https://html.spec.whatwg.org/>.





van Kesteren & Hofmann     Expires 22 May 2026                 [Page 44]

Internet-Draft                   Cookies                   November 2025


   [INFRA]    van Kesteren, A. and D. Denicola, "Infra", n.d.,
              <https://infra.spec.whatwg.org>.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/rfc/rfc1034>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <https://www.rfc-editor.org/rfc/rfc1123>.

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

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

   [URL]      van Kesteren, A., "URL", n.d.,
              <https://url.spec.whatwg.org>.

Informative References

   [CSRF]     Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
              for Cross-Site Request Forgery",
              DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7,
              ACM CCS '08: Proceedings of the 15th ACM conference on
              Computer and communications security (pages 75-88),
              October 2008,
              <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

   [HTTP]     Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

   [HttpFieldNameRegistry]
              "Hypertext Transfer Protocol (HTTP) Field Name Registry",
              n.d., <https://www.iana.org/assignments/http-fields/>.

   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997,
              <https://www.rfc-editor.org/rfc/rfc2109>.






van Kesteren & Hofmann     Expires 22 May 2026                 [Page 45]

Internet-Draft                   Cookies                   November 2025


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

   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <https://www.rfc-editor.org/rfc/rfc6265>.

   [RFC7034]  Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
              Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7034>.

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

   [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
              DOI 10.17487/RFC9113, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9113>.

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

Authors' Addresses

   Anne van Kesteren (editor)
   Apple
   Email: annevk@annevk.nl


   Johann Hofmann (editor)
   Google
   Email: johannhof@google.com
















van Kesteren & Hofmann     Expires 22 May 2026                 [Page 46]


