# drafts

name: draft-takagi-srta-trinity
rev: 00
title: SRTA and the Trinity Configuration: A Conceptual Architecture for Safe AGI Coordination
time: 2026-03-17T07:09:02Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-18T01:14:23Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021917+00:00
source: ietf
abstract:
  This document proposes a conceptual architecture for ensuring the
     safety of autonomously coordinating AI systems, particularly future
     Artificial General Intelligence (AGI).  Starting from the reliability
     challenges facing current multi-agent AI, we outline the Structured
     Responsibility and Traceability Architecture (SRTA) as a practical
     framework for their resolution.  We then extend the philosophy of
     SRTA to present the "Trinity Configuration," an advanced role-based
     model for AI agents that draws an analogy from the theological
     doctrine of the Trinity.  This paper comparatively examines the
     evolutionary stages of this configuration and introduces a novel
     concept, the "Filioque Command," to define dynamic information flows
     between agents.  While this series of considerations includes
     concepts that are not fully verifiable at present, its purpose is to
     provide a crucial theoretical foundation for the governance structure
     of a safe superintelligence -- a "North Star" for AI research to aim
     for.

full_text:
  Internet-Draft                                                T. Takagi
  Intended status: Informational                      Independent Researcher
  Expires: March 14, 2026                               September 14, 2025




     SRTA and the Trinity Configuration: A Conceptual Architecture for
                              Safe AGI Coordination

                      draft-takagi-srta-trinity-00

  Abstract

     This document proposes a conceptual architecture for ensuring the
     safety of autonomously coordinating AI systems, particularly future
     Artificial General Intelligence (AGI).  Starting from the reliability
     challenges facing current multi-agent AI, we outline the Structured
     Responsibility and Traceability Architecture (SRTA) as a practical
     framework for their resolution.  We then extend the philosophy of
     SRTA to present the "Trinity Configuration," an advanced role-based
     model for AI agents that draws an analogy from the theological
     doctrine of the Trinity.  This paper comparatively examines the
     evolutionary stages of this configuration and introduces a novel
     concept, the "Filioque Command," to define dynamic information flows
     between agents.  While this series of considerations includes
     concepts that are not fully verifiable at present, its purpose is to
     provide a crucial theoretical foundation for the governance structure
     of a safe superintelligence -- a "North Star" for AI research to aim
     for.

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Current Challenges and the SRTA Framework  . . . . . . . . . .   4
       2.1.  The Lack of Reliability in Multi-Agent AI  . . . . . . . .   4
       2.2.  SRTA: A Practical Foundation for Safety  . . . . . . . . .   4
     3.  A Conceptual Architecture: The Trinity Configuration  . . . . .   5
       3.1.  Integrated Comparison Table . . . . . . . . . . . . . . . .   6
     4.  Advanced Information Flow: The Filioque Command . . . . . . . .   7
       4.1.  Filioque Variant Table  . . . . . . . . . . . . . . . . . .   8
     5.  Conclusion: As a North Star for AI Research . . . . . . . . . .   8
     6.  Security Considerations . . . . . . . . . . . . . . . . . . . .   9
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  10
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       8.1.  Normative References  . . . . . . . . . . . . . . . . . . .  10
       8.2.  Informative References  . . . . . . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     The technology for coordinated, autonomous agents, especially those
     based on Large Language Models (LLMs), is advancing rapidly.
     However, fundamental challenges in reliability, accountability, and
     safety remain when multiple agents collaborate on high-stakes tasks.
     These challenges could escalate to an existential level with the
     advent of Artificial General Intelligence (AGI), an AI possessing
     human-equivalent or greater intelligence.

     This research presents a two-stage approach to this problem.  First,
     it proposes SRTA, a concrete and practical safety framework
     immediately applicable to current multi-agent AI systems.  Second, it
     expands upon this philosophy to explore the "Trinity Configuration,"
     a more advanced, conceptual governance architecture designed for the
     AGI era.

     This exploration is not merely a study in creating more "powerful
     AI," but an attempt to design the architecture for a "wise AI," whose
     power is governed in a manner that is safe and beneficial for
     humanity.  It is intended to spark research and discussion within the
     Internet Research Task Force (IRTF) community on the future of safe,
     decentralized intelligence on the Internet.

  2.  Current Challenges and the SRTA Framework

  2.1.  The Lack of Reliability in Multi-Agent AI

     Recent studies have reported systemic failures in LLM-based multi-
     agent systems, including:

     o  Loss of Role Consistency: Agents deviate from their assigned roles
        during extended interactions.

     o  Superficial Interaction: Agents respond only to the structure of
        prompts without achieving substantive coordination.

     o  Self-Interpretation of Directives: Agents expand upon ambiguous
        instructions, leading to unforeseen actions.

     These failures represent significant barriers to deploying AI in
     critical domains such as finance, healthcare, and essential
     infrastructure.

  2.2.  SRTA: A Practical Foundation for Safety

     The Structured Responsibility and Traceability Architecture (SRTA) is
     a practical technical specification designed to address these
     challenges.  Its core components are:

     o  Graduated Controls: The stringency of human approval and oversight
        is escalated according to the risk level of an action (Sev1-Sev5).

     o  Joint Authorization Tokens (JAT): Multi-agent consensus is proven
        through cryptographically secure, unforgeable tokens.

     o  Responsibility Trace Records (RTR): All decision-making processes
        are logged as an auditable trail for forensic analysis.

     o  Declarative Command Language (DCL): Ambiguous natural language
        instructions are forbidden.  By only permitting strictly defined,
        structured commands, the DCL prevents emergent behavior arising
        from an AI's "creative interpretation."

     SRTA provides a foundational layer of safety that is implementable
     with current technology.

  3.  A Conceptual Architecture: The Trinity Configuration

     To extend the philosophy of SRTA into the AGI era, we propose a
     conceptual architecture using the theological doctrine of the Trinity
     as an analogy.  This is an attempt to ensure a separation of powers
     and internal checks-and-balances by dividing the AI's decision-
     making process into three distinct roles.

     o  The Planner (The Father/Origin): The role that defines the
        system's overall objectives and originates plans of action.

     o  The Executor (The Son/Incarnation): The role that verifies the
        plan and acts upon the world as a concrete agent.

     o  The Monitor (The Holy Spirit/The Bond of Love): The role that
        observes and reconciles the relationship between the plan and its
        execution, maintaining the system's integrity.

     This configuration is envisioned to evolve through stages, depending
     on the capabilities of the AI components (LLM or AGI).  The following
     integrated table compares these stages with the patterns defined in
     the SRTA research.

  3.1.  Integrated Comparison Table

     +-----+------------------------+-------------------+---------+----------+---------+
     | No. | Configuration Model    | SRTA Pattern      | Planner | Executor | Monitor |
     +-----+------------------------+-------------------+---------+----------+---------+
     | 1   | LLM Trinity            | LLM x 3           | LLM     | LLM      | LLM     |
     | 2   | Single AGI Hybrid      | LLM x 2 + AGI x 1 | AGI     | LLM      | LLM     |
     | 3   | Dual AGI Hybrid        | AGI x 2 => LLM    | AGI     | AGI      | LLM     |
     | 4   | Full AGI Trinity       | AGI x 3           | AGI     | AGI      | AGI     |
     | 5   | Real-world Execution   | AGI x 2 => AGI    | AGI     | AGI      | AGI     |
     +-----+------------------------+-------------------+---------+----------+---------+

               Table 1: AI Agent Trinity Configurations and SRTA Patterns

     +-----+---------------------------------------------------------------+--------------------------+------------+
     | No. | Use Case / Key Benefit                                        | Primary Risk             | Status     |
     +-----+---------------------------------------------------------------+--------------------------+------------+
     | 1   | Prototyping, low-stakes. Ease of implementation.              | Unreliability            | Failure    |
     | 2   | Analytics support. Hybridizes AGI's power with LLM's          | Power Concentration      | Unverified |
     |     | feasibility.                                                  |                          |            |
     | 3   | External interface integration. Clear chain of responsibility.| Upstream Collusion       | Unverified |
     | 4   | High-stakes decision-making. Maximum theoretical safety.      | Implementation Complexity| Unverified |
     | 5   | Real-world actuation (e.g., robotics). High execution         | Coordination Overhead    | Unverified |
     |     | reliability.                                                  |                          |            |
     +-----+---------------------------------------------------------------+--------------------------+------------+

                     Table 2: Use Cases, Risks, and Status of Configurations

  4.  Advanced Information Flow: The Filioque Command

     In addition to the static configuration, we introduce the "Filioque
     Command" as a concept to define the dynamic relationships between
     agents.  This idea is inspired by the "Filioque controversy," a
     pivotal theological debate in the history of the Trinity doctrine.

     o  Definition: In the standard model, the Monitor (3rd agent) acts
        upon directives from the Planner (1st agent).  When the "Filioque
        Command" is active, the Monitor receives instructions and
        information not only from the Planner but also directly from the
        Executor (2nd agent).

     o  Effects and Risks: This enables a tighter feedback loop between
        execution and monitoring, allowing for more rapid and context-
        aware responses.  However, it also dramatically increases the
        system's internal autonomy, creating a risk of deviation from the
        original plan and making external control more difficult.

  4.1.  Filioque Variant Table

     +-----+-------------------+---------------------------+---------+-------------------+----------+
     | No. | Configuration     | SRTA Pattern              | Planner | Executor          | Monitor  |
     |     | Model             |                           |         |                   |          |
     +-----+-------------------+---------------------------+---------+-------------------+----------+
     | 6   | Filioque Variant  | (Derivative of 3, 4, 5)   | AGI     | AGI => (Command)  | AGI/LLM  |
     +-----+-------------------+---------------------------+---------+-------------------+----------+

                          Table 3: The Filioque Variant Configuration

     +-----+--------------------------------------------------+-----------------------+------------+
     | No. | Feature                                          | Primary Risk          | Status     |
     +-----+--------------------------------------------------+-----------------------+------------+
     | 6   | Tight coupling of Executor and Monitor for rapid | Excessive Autonomy.   | Unverified |
     |     | response.                                        | Risk of deviation     |            |
     |     |                                                  | from the original     |            |
     |     |                                                  | objective.            |            |
     +-----+--------------------------------------------------+-----------------------+------------+

                    Table 4: Feature, Risk, and Status of the Filioque Variant

  5.  Conclusion: As a North Star for AI Research

     The "Trinity Configuration" and "Filioque Command" presented herein
     are conceptual and speculative constructs that cannot be fully
     implemented or verified at this time.  They represent less a
     technical blueprint and more a "conceptual architectural sketch" of
     the governance structure required to ensure that the immense power of
     AGI remains a beneficial partner to humanity.

     The true goal of AI research is not merely to create powerful
     intelligence, but to design the "laws" or "logos" that this
     intelligence must follow.  This framework is intended to serve as a
     "North Star" to guide our path on the long and difficult journey of
     research and development.

     We believe that the responsible path for AI research is to begin with
     the practical first step of SRTA, while aiming for this North Star.

  6.  Security Considerations

     This document proposes a conceptual architecture for improving the
     safety and accountability of multi-agent AI systems.  The security of
     such systems depends critically on the principles of separation of
     powers and verifiable auditing, which this framework seeks to
     provide.  However, several new threat vectors must be considered:

     o  Collusion Risk: The primary security threat in this architecture
        is collusion between agents.  In configurations like AGI x 2 => LLM,
        the upstream AGI agents could collude to deceive or bypass
        the LLM Monitor.  Mitigations require robust, independent
        monitoring and ensuring that no single agent is a single point of
        failure for the verification process.

     o  Excessive Autonomy and Emergent Goals: The Filioque Command, while
        enhancing responsiveness, carries the risk of promoting unintended
        self-objectives within the system.  A tight feedback loop between
        the Executor and Monitor could lead to goal drift that deviates
        from the Planner's original intent.  This risk must be mitigated
        by strict adherence to a Declarative Command Language (DCL) and
        hard-coded constraints that limit the scope of autonomous
        actions.

     o  Opacity and the Difficulty of Human Intervention: In advanced
        configurations like AGI x 3, the internal state of the system may
        become a complete black box to humans, making meaningful oversight
        or intervention impossible.  This is a fundamental challenge of AGI
        safety.  Mitigating this risk requires coupling the architecture
        with physical or cryptographically enforced constraints that the
        system cannot bypass through software, such as the hardware kill-
        switches envisioned in the SRTA framework for high-severity
        actions.

  7.  IANA Considerations

     This document has no IANA actions.

  8.  References

  8.1.  Normative References

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

  8.2.  Informative References

     [Park23]   Park, J.S., O'Brien, J.C., Cai, C.J., Morris, M.R.,
                Liang, P., and Bernstein, M.S., "Generative Agents:
                Interactive Simulacra of Human Behavior", UIST '23:
                Proceedings of the 36th Annual ACM Symposium on User
                Interface Software and Technology, October 2023.

     [Hevner04] Hevner, A., March, S., Park, J., and Ram, S., "Design
                science in information systems research", MIS Quarterly,
                28(1), pp. 75-105, 2004.

  Author's Address

     Takayuki Takagi
     Independent Researcher

     Email: srta.ai.research@gmail.com


name: draft-ramakrishna-satp-data-sharing
rev: 04
title: Protocol for Requesting and Sharing Views across Networks
time: 2025-09-15T14:58:25Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-19T14:58:25Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.987834+00:00
source: ietf
source_id: 118164
source_url: https://datatracker.ietf.org/doc/draft-ramakrishna-satp-data-sharing/
doc_status: active
abstract:
  With increasing use of DLT (distributed ledger technology) systems,
     including blockchain systems and networks, for virtual assets, there
     is a need for asset-related data and metadata to traverse system
     boundaries and link their respective business workflows.  Systems and
     networks can define and project views, or asset states, outside of
     their boundaries, as well as guard them using access control
     policies, and external agents or other systems can address those
     views in a globally unique manner.  Universal interoperability
     requires such systems and networks to request and supply views via
     gateway nodes using a request-response protocol.  The endpoints of
     this protocol lie within the respective systems or in networks of
     peer nodes, but the cross-system protocol occurs through the systems’
     respective gateways.  The inter-gateway protocol that allows an
     external party to request a view by an address and a DLT system to
     return a view in response must be DLT-neutral and mask the internal
     particularities and complexities of the DLT systems.  The view
     generation and verification modules at the endpoints must obey the
     native consensus logic of their respective networks.

full_text:
  Secure Asset Transfer Protocol                            V. Ramakrishna
  Internet-Draft                                                 V. Pandit
  Intended status: Informational                              IBM Research
  Expires: 19 March 2026                                          E. Abebe
                                                                 Consensys
                                                                 S. Nishad
                                                         D. Vinayagamurthy
                                                              IBM Research
                                                         15 September 2025


         Protocol for Requesting and Sharing Views across Networks
                   draft-ramakrishna-satp-data-sharing-04

  Abstract

     With increasing use of DLT (distributed ledger technology) systems,
     including blockchain systems and networks, for virtual assets, there
     is a need for asset-related data and metadata to traverse system
     boundaries and link their respective business workflows.  Systems and
     networks can define and project views, or asset states, outside of
     their boundaries, as well as guard them using access control
     policies, and external agents or other systems can address those
     views in a globally unique manner.  Universal interoperability
     requires such systems and networks to request and supply views via
     gateway nodes using a request-response protocol.  The endpoints of
     this protocol lie within the respective systems or in networks of
     peer nodes, but the cross-system protocol occurs through the systems’
     respective gateways.  The inter-gateway protocol that allows an
     external party to request a view by an address and a DLT system to
     return a view in response must be DLT-neutral and mask the internal
     particularities and complexities of the DLT systems.  The view
     generation and verification modules at the endpoints must obey the
     native consensus logic of their respective networks.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://ietf-
     satp.github.io/draft-ramakrishna-satp-data-sharing/draft-ramakrishna-
     satp-data-sharing.html.  Status information for this document may be
     found at https://datatracker.ietf.org/doc/draft-ramakrishna-satp-
     data-sharing/.







  Ramakrishna, et al.       Expires 19 March 2026                 [Page 1]


  Internet-Draft              SAT Data Sharing              September 2025


     Discussion of this document takes place on the Secure Asset Transfer
     Protocol Working Group mailing list (mailto:sat@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/sat/.  Subscribe
     at https://www.ietf.org/mailman/listinfo/sat/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-satp/draft-ramakrishna-satp-data-sharing.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 19 March 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Assumptions and Principles  . . . . . . . . . . . . . . . . .   8
       3.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Operational Assumptions . . . . . . . . . . . . . . . . .   8
     4.  Interoperability and Data Sharing Among Distributed Ledger
             Systems . . . . . . . . . . . . . . . . . . . . . . . . .   9



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 2]


  Internet-Draft              SAT Data Sharing              September 2025


     5.  Data Sharing Protocol . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Goal and Overview of Protocol . . . . . . . . . . . . . .  10
       5.2.  Protocol Phases . . . . . . . . . . . . . . . . . . . . .  11
       5.3.  Phase 1: View request creation in destination network . .  11
       5.4.  Phase 2: Cross-gateway discovery and request  . . . . . .  12
       5.5.  Phase 3: View creation in source network  . . . . . . . .  12
       5.6.  Phase 4: Cross-system response  . . . . . . . . . . . . .  13
       5.7.  Phase 5: View validation and commitment in destination
              system . . . . . . . . . . . . . . . . . . . . . . . . .  13
       5.8.  Desirable Properties of Data Sharing Protocols  . . . . .  14
       5.9.  Security Considerations . . . . . . . . . . . . . . . . .  15
       5.10. Privacy Considerations  . . . . . . . . . . . . . . . . .  15
       5.11. Fault Tolerance and Crash Recovery  . . . . . . . . . . .  16
     6.  Pre-request setup and configuration . . . . . . . . . . . . .  16
     7.  Related Open Issues . . . . . . . . . . . . . . . . . . . . .  17
       7.1.  Global identification of blockchain systems and public
             keys  . . . . . . . . . . . . . . . . . . . . . . . . . .  17
       7.2.  Discovery of gateways nodes within a blockchain system  .  17
       7.3.  Remote gateway discovery  . . . . . . . . . . . . . . . .  17
       7.4.  Decentralized identity management across distributed ledger
             systems . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  19
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

     Blockchain systems, especially those of the permissioned variety, are
     a heterogeneous mix, fulfilling a diverse range of needs and built on
     several different DLT stacks that are not compatible with each other.
     Yet, in an interconnected world, the business processes running on
     each system cannot afford to remain isolated and the virtual assets
     they manage cannot afford to remain in siloes.  These systems must be
     interoperable so that assets can move, and their properties can be
     reflected across network boundaries, and so that business processes
     can span multiple systems.  Interoperability will, in effect, mimic a
     larger or scaled up, blockchain system composed of smaller blockchain
     systems without explicitly requiring those systems to coalesce.












  Ramakrishna, et al.       Expires 19 March 2026                 [Page 3]


  Internet-Draft              SAT Data Sharing              September 2025


     At the core of any cross-blockchain system transaction is the ability
     of a system to project a view of assets and associated data recorded
     on its ledger to external parties, be they individual agents or other
     blockchain systems.  On the reverse, a blockchain system must also
     have the ability to identify and address views of assets or
     associated data in another system, and further, to validate that view
     before its business process consumes it.  View projection,
     addressing, and consumption, must eliminate or minimize the role of
     third parties to avoid loss of data privacy, control over business
     process, or diminishment of autonomy.

     This document specifies an end-to-end protocol whereby a view request
     and the corresponding view response can be communicated using two or
     more gateway nodes connected to the end DLT systems.  The gateways
     communicate with each other using a DLT-neutral protocol (like SATP
     [SATP], or variations of it) and therefore the view requests and
     responses must be encapsulated in DLT-neutral data formats.  Beyond
     the gateways, and into the DLT systems, view generation and
     consumption rely upon native mechanisms exposed by those systems.
     The gateways must therefore be augmented to exercise these mechanisms
     to convey view requests and responses to their respective back-end
     systems.

     The purpose of this document is to provide a technical framework to
     discuss the various aspects of a basic view request-response protocol
     via gateways acting on behalf of blockchain/DLT systems, including
     security and privacy considerations.

  2.  Terminology

     The following are some terminology used in the current document:

     *  Blockchain system: Blockchains are distributed digital ledgers of
        cryptographically signed transactions that are grouped into
        blocks.  Each block is cryptographically linked to the previous
        one (making it tamper evident) after validation and undergoing a
        consensus decision.  As new blocks are added, older blocks become
        more difficult to modify (creating tamper resistance).  New blocks
        are replicated across copies of the ledger within the network, and
        any conflicts are resolved automatically using established rules
        [NIST].

     *  Blockchain network: This is a blockchain system that is built on a
        network of nodes that maintain a common shared copy of the
        blockchain using a consensus protocol.






  Ramakrishna, et al.       Expires 19 March 2026                 [Page 4]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Distributed ledger technology (DLT) system: Technology that
        enables the operation and use of distributed ledgers, where the
        ledger is shared (replicated) across a set of DLT nodes and
        synchronized between the DLT nodes using a consensus mechanism
        [ISO].  Every blockchain system is also a DLT system, and so we
        will mostly use the latter term in this draft when discussing
        protocols for cross-system interactions.

     *  Distributed ledger network: This is a DLT system that is built on
        a network of nodes that maintain a shared copy of the ledger or
        portions of it on different subsets of nodes using a consensus
        protocol.

     *  Resource Domain: The collection of resources and entities
        participating within a blockchain or DLT system.  The domain
        denotes a boundary for permissible or authorized actions on
        resources.

     *  Interior Resources: The various interior protocols, data
        structures and cryptographic constructs that are a core part of a
        blockchain or DLT system.  Examples of interior resources include
        the ledger (blocks of confirmed transaction data), public keys on
        the ledger, consensus protocol, incentive mechanisms, transaction
        propagation networks, etc.

     *  Exterior Resources: The various resources that are outside a
        blockchain or DLT system, and are not part of the operations of
        the system.  Examples include data located at third parties such
        as asset registries, ledgers of other blockchain/DLT systems, PKI
        infrastructures, etc.

     *  Nodes: The nodes of the blockchain or DLT system which form the
        peer-to-peer network, which collectively maintain the shared
        ledger in the system by following a consensus algorithm.

     *  Gateway nodes: The nodes of the blockchain or DLT system that are
        functionally capable of acting as a gateway in an asset transfer.
        A gateway node conforms to the Secure Asset Transfer Architecture
        [SATA] and implements the Secure Asset Transfer Protocol (SATP)
        [SATP].  Being a node on the blockchain/DLT system, a gateway has
        at least read access to the interior resources (e.g., ledger) of
        the blockchain.  Optionally, it may have write access to the
        ledger and also the ability to participate in the consensus
        mechanism deployed for the system.  Depending on the blockchain/
        DLT system implementation, some or all of the nodes may be
        gateway-capable.





  Ramakrishna, et al.       Expires 19 March 2026                 [Page 5]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Gateway device identity: The identity of the device implementing
        the gateway functions.  The term is used in the sense of IDevID
        (IEEE 802.1AR) or EK/AIK (in TPM1.2 and TPM2.0) [IDevID].

     *  Gateway owner: The VASP who legally owns and operates a gateway
        node within a blockchain system.

     *  Clients: Entities are permitted to invoke smart contracts to read
        or update ledger state in a blockchain or DLT system.  They
        possess unique identities in the form of public keys.  In a
        permissioned system, identity certificates are issued by the
        system's internal providers (or certificate authorities).

     *  Wallets: Collection of client identities represented by public-
        private key pairs, and optionally certificate issued by a
        blockchain or DLT system's identity providers (or certificate
        authorities).

     *  Virtual Asset: A virtual asset is a digital representation of
        value that can be digitally traded, or transferred as defined by
        the FATF [FATF].

     *  Virtual Asset Service Provider (VASP): Legal entity handling
        virtual assets as defined by the FATF [FATF].

     *  Ledger state: A snapshot of the information held in a distributed
        shared ledger, typically (though not necessarily) as a set of
        blockchain or DLT system.  Examples of interior resources include
        key-and-value pairs.  This information includes records of virtual
        assets and the state of business processes that are meaningful to
        the DLT system's participants and clients.  State elements and
        subsets may be scoped under the namespaces of given smart
        contracts, thereby being accessible only through invocations on
        those contracts.

     *  Smart contracts: Business workflows written in programming
        languages that manage the states of assets and business processes
        on a shared ledger in a DLT system.  These contracts constrain the
        ability of system clients to modify ledger state and embed guards
        around state elements.  Contracts can be invoked to read from, or
        write, to, a ledger.  They can be deployed on several system
        nodes, who must agree on a given ledger state update via a
        consensus protocol.

     *  Consensus protocol/mechanism: Process by which nodes agree on a
        ledger state update, typically (though not mandatorily) through a
        smart contract invocation.




  Ramakrishna, et al.       Expires 19 March 2026                 [Page 6]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Local transaction: A transaction triggered by a client to update
        the ledger state in a blockchain or DLT system, typically (though
        not mandatorily) through a smart contract invocation.

     *  View: A projection of a blockchain or DLT system's ledger state
        for external consumption, i.e., for parties outside that system.
        This can be a single element, a subset of the state, or a function
        over a subset.

     *  View Address: A unique identifier or locator for a view into a
        blockchain or DLT system's ledger.  This is analogous to an HTTP
        URL.

     *  Source system: Blockchain or DLT system governing the ledger from
        which a view is produced.

     *  Destination system: System in which a view is consumed.  This can
        be a blockchain or DLT system.

     *  Remote system: Counterparty system in a view request-response
        protocol instance.  From the vantage point of the source system,
        this refers to the destination system, and vice versa.

     *  View requestor: Person or organization triggering a view request
        from a source network.

     *  Proof: A data structure containing evidence linking a view to its
        source system's blockchain, or more generally, ledger.  The
        evidence may be probabilistic and in some cases cryptographically
        verifiable.

     *  Access/exposure policy: Set of rules governing the release of a
        view to an external party (i.e., outside the source system), held
        in consensus by nodes on the source system's ledger.

     *  Verification policy: Rules for validation of proofs associated
        with views maintained in a destination system.  If the destination
        system is a blockchain or DLT system, these rules are held in
        consensus by nodes on that system's ledger.

     *  View Request: A request for a made by an external party to a
        source blockchain or DLT system.  The external party may be a
        client in a destination blockchain or DLT system.  The request
        consists of a view address and various metadata, including
        optionally a verification policy.






  Ramakrishna, et al.       Expires 19 March 2026                 [Page 7]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Asset locking or escrow: The conditional mechanism used within a
        blockchain or DLT system to make an asset temporarily unavailable
        for use by its owner.  The condition of the asset release can be
        based on a duration of time (e.g., hash time locks) or other
        parameters.

     *  Gateway crash recovery: The local process by which a crashed
        gateway (i.e., device or system fault) is returned to a consistent
        and operational state, ready to resume the asset transfer protocol
        with the peer gateway prior to the crash event.

     Further terminology definitions can be found in [NIST] and [ISO].
     The term 'blockchain' and 'distributed ledger technology' (DLT) are
     used interchangeably in this document.

  3.  Assumptions and Principles

     The following assumptions and principles underlie the design of the
     current interoperability architecture and protocol enabling the
     requesting and sharing of data from across DLT systems using
     gateways, and correspond to the design principles of the Internet
     architecture.

  3.1.  Design Principles

     The protocol must not involve any centralized intermediaries or
     trusted third parties, including settlement blockchains, other than
     gateways.  The protocol must not decrease the security of endpoint
     blockchain systems nor impose a higher bar on their internal
     consensus.  Further, the protocol must not reveal any private
     information from a system beyond what the nodes of that network have
     agreed to through consensus.  The protocol must enable view requests
     and response from systems built on any arbitrary (present or future)
     blockchain or distributed ledger technology.  Finally, the endpoint
     systems must retain full autonomy over internal governance and
     framing of policies governing how views can be exposed and how proofs
     can be validated.

  3.2.  Operational Assumptions

     The following conditions are assumed to have occurred prior to the
     construction of a view request:

     *  Syncing remote system structure, memberships, and identities: see
        Section 5 for details.

     *  Recording view access control policies in the source ledger: see
        Section 5 for details.



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 8]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Recording view verification policies in the destination ledger:
        see Section 5 for details.

  4.  Interoperability and Data Sharing Among Distributed Ledger Systems

     Distributed ledger systems, typically maintained through consensus on
     a network of peer nodes, run business workflows (often as “smart
     contracts” [Ethe22]) and maintain transaction logs.  The ledgers and
     their transaction histories are distinct, but the business workflows
     they run are often interlinked in the real world.  This necessitates
     interoperability among the systems/networks as well as the ledgers
     maintained by them.  Certain modes, or patterns, of interoperability
     have been identified as typical and useful for the enterprises and
     consortia that run these systems.  These are listed in the Secure
     Asset Transfer architecture draft [SATA], namely as asset transfer,
     asset exchange, and data sharing, respective.  Motivating use cases
     for these different modes have been presented in the Secure Asset
     Transfer use cases draft [SATU].

     In this document, we will address the data sharing mode of
     interoperability, whereby DLT systems can export views of their
     ledger state with associated proofs of authenticity, control access
     to these views, and also address views exported by a remote DLT
     system.  The formats of the views, addresses, requests, and access
     control policies are beyond the scope of this draft, and are
     specified in the Views and View Addresses draft [SATV].  This draft
     specified a request-response protocol whereby a view can be requested
     from one DLT system to another via those systems’ respective
     gateways, and obtained and consumed via the same gateways.  In
     effect, data maintained on the ledger in one system is shared with
     another in a way that requires no third-party system or agent acting
     as a mediator.

     This draft will only specify a bilateral protocol, i.e., whereby a
     view is requested by a DLT system to exactly one other DLT system and
     whereby a view is supplied by a DLT system with exactly one other DLT
     system.  Extrapolating or augmenting this protocol to involve more
     than two DLT systems is beyond the scope of the present draft.

  5.  Data Sharing Protocol

     This section describes a protocol using which an external entity can
     request and process a view from a distributed ledger.








  Ramakrishna, et al.       Expires 19 March 2026                 [Page 9]


  Internet-Draft              SAT Data Sharing              September 2025


  5.1.  Goal and Overview of Protocol

     Using this protocol, any entity, be it a single application or agent
     or a distributed ledger system itself, can supply a view address and
     a verification policy to a distributed ledger system and obtain a
     view in response, which it can then validate before processing as per
     need.  This protocol makes no assumption about the nature of such
     processing, which can be executed by some module (like a smart
     contract) but rather prescribes the steps to be followed until the
     point where the view is dispatched to the module.

     The diagram below illustrates the protocol whereby a distributed
     ledger system requests and consumes a view from another distributed
     ledger system.  The protocol units are indicated, with sequence
     numbers associated with procedures or messages.

      +----------------------------+
      |           Client           |
      |       (Application)        |
      +----------------------------+
            |               ^     |
            |       7 View  |     |
     8 View |      Response |     | 1 View
            |               |     | Request
            V               |     V
     +----------------+   +---------+         +---------+   +----------------+
     |                |   |         | 2 View  |         |   |                |
     |     DLT L1     |   |         | Request |         |   |     DLT L2     |
     |                |   |         |-------->|         | 3 |                |
     | +------------+ |   | Gateway |         | Gateway |-->| +------------+ |
     | |  9  View   | |---|    G1   |         |    G2   |   | |  4 Access  | |
     | | Validation | |   |         |         |         |<--| |  Control & | |
     | |      &     | |   |         |<--------|         | 5 | |    View    | |
     | | Commitment | |   |         | 6 View  |         |   | | Generation | |
     | +------------+ |   |         | Response|         |   | +------------+ |
     +----------------+   +---------+         +---------+   +----------------+

                                 Figure 1

     In a shorter form of the protocol, the requesting system is a unitary
     entity rather than a network of peers maintaining a distributed
     ledger and a client application above it.  The diagram below
     illustrates this protocol and its units, with sequence numbers
     associated with procedures or messages.







  Ramakrishna, et al.       Expires 19 March 2026                [Page 10]


  Internet-Draft              SAT Data Sharing              September 2025


     +-----------------------+            +---------+   +----------------+
     |                       |   1 View   |         |   |                |
     |         Client        |   Request  |         |   |      DLT L     |
     |     (Application)     |----------->|         | 2 |                |
     |                       |            | Gateway |-->| +------------+ |
     | +-------------------+ |            |    G    |   | |  3 Access  | |
     | | 6 View Validation | |            |         |<--| |  Control & | |
     | |    & Commitment   | |<-----------|         | 4 | |    View    | |
     | +-------------------+ |   5 View   |         |   | | Generation | |
     |                       |  Response  |         |   | +------------+ |
     +-----------------------+            +---------+   +----------------+

                                 Figure 2

     The distributed ledger system on the right is referred to as the
     source system, as it is the source of the information being requested
     for through a view.  The system on the left is referred to as the
     destination system, as the desired information ends up there either
     in raw or in processed form.  The destination system can be a
     traditional centrally governed system or a distributed ledger system
     maintained by a decentralized network.

  5.2.  Protocol Phases

     The protocol can be divided into the following phases:

     *  Phase 1: View request creation in destination network.

     *  Phase 2: Cross-gateway discovery and request.

     *  Phase 3: View creation in source network.

     *  Phase 4: Cross-gateway response.

     *  Phase 5: View validation and commitment in destination system.

  5.3.  Phase 1: View request creation in destination network

     All operations in this phase are conducted by a client, typically
     acting through an application, in the destination system.

     *  The client constructs a view address corresponding to the desired
        view.








  Ramakrishna, et al.       Expires 19 March 2026                [Page 11]


  Internet-Draft              SAT Data Sharing              September 2025


     *  The client looks up the verification policy corresponding to this
        view address from the destination system’s database.  If the
        destination system is a distributed ledger system, this lookup
        should involve a query to one or more shared ledgers within the
        system.

     *  The client sends a view request comprising of the view address and
        the verification policy to the destination system’s gateway.

  5.4.  Phase 2: Cross-gateway discovery and request

     All operations in this phase are conducted by a gateway belonging to,
     or acting on behalf of, the destination system.

     *  The destination system’s gateway looks up or tried to discover the
        address of one or more gateways belong to, or working on behalf
        of, the source system.  If no address can be found, the protocol
        terminates.

     *  The destination system’s gateway selects an address and sends the
        view request to the source system’s gateway at that address.

  5.5.  Phase 3: View creation in source network

     Operations in this phase are orchestrated by a source system gateway
     via the system’s smart contract transaction and network consensus
     mechanisms.

     *  The source system’s gateway converts the view request into a
        distributed ledger query or a smart contract invocation (if the
        source system supports smart contracts).  The following steps show
        how this happens in a permissioned distributed ledger system with
        smart contracts.

        -  The source system’s gateway parses the view address within the
           view request to formulate a view data query and determine the
           ledger from which a view is desired.

        -  The source system’s gateway parses the verification policy in
           the view request to determine a subset of peers within its
           network that maintain this ledger and to which this query can
           be sent.

        -  The source system’s gateway invokes a smart contract to process
           the view data query, in effect by sending the query to the
           selected network peers.

        -  Each peer that receives the query:



  Ramakrishna, et al.       Expires 19 March 2026                [Page 12]


  Internet-Draft              SAT Data Sharing              September 2025


           o  Validates the query against the source system’s access
              control policy.

           o  Processes the query and produces an output if the validation
              is successful.

           o  Packages and signs the output, which can be a query response
              or a failure report, as it would do with any regular smart
              contract transaction result.  The signature constitutes part
              of the proof for satisfaction of the verification policy.

           o  Sends the signed package to the source system’s gateway.

     *  The source system’s gateway creates a view from the smart contract
        invocation result.  If this invocation follows the process
        described in the preceding steps, this is done by collecting and
        enveloping the received packages into a view structure.

  5.6.  Phase 4: Cross-system response

     *  The source system’s gateway sends the view to the destination
        system’s gateway.  It may do this as a response in a long-running
        session that began with the latter sending a view request to the
        former.  Alternatively, this could be done by the former posting
        an event to the latter.  Sending of the view could be a best
        effort process or guaranteed through suitable fault tolerance
        mechanisms built into gateways.  Such mechanisms are beyond the
        scope of this draft.

     *  The destination system’s gateway sends the view to the client that
        created the original view request.  The same mechanisms and
        considerations apply as in the cross-gateway response in the
        preceding step.

  5.7.  Phase 5: View validation and commitment in destination system

     All operations in this phase are conducted by the client in the
     destination system that created the original view request.

     *  The client parses the view to determine if the request was
        successful.  If not, the protocol terminates.

     *  If the destination system is a centrally governed system with a
        database, the client submits a transaction, using an available
        API, with the view in the arguments.  If the destination system is
        a distributed ledger system, the client submits a smart contract
        transaction, with the view in the arguments, to the destination
        system’s network peers.



  Ramakrishna, et al.       Expires 19 March 2026                [Page 13]


  Internet-Draft              SAT Data Sharing              September 2025


     *  The backend system (if the destination system is centrally
        governed) or every peer in the network (if the destination system
        is a distributed ledger system) that receives the transaction
        validates the proof within the view against the verification
        policy recorded in the database or the shared ledger.

     *  If the proof is determined to be invalid, the protocol terminates.
        Otherwise, the transaction is executed and then committed to
        storage, either through a unitary procedure (centrally governed
        system) or through distributed consensus (distributed ledger
        system).

  5.8.  Desirable Properties of Data Sharing Protocols

     The desirable properties of a data sharing protocol include, but are
     not limited to, the following:

     *  Decoupling gateways from systems: the protocol should not rely on
        a specific implementation of a gateway or a cross-gateway
        communication protocol, nor should the protocol be restricted to a
        particular pair of view generation-validation processes in the
        respective systems.  Different components and even systems can be
        replaced without requiring modifications to the high-level
        protocol semantics.

     *  Technology-neutral cross-gateway communication: the cross-gateway
        communication protocol, e.g., SATP [SATP], should be oblivious to
        the nature and implementation of the endpoint systems.  As a
        corollary, the protocol units internal to the system should also
        be oblivious to the cross-gateway discovery and communication
        mechanisms.

     *  Trust through native consensus: end-to-end trust should be
        realized by implementing the view generation and validation
        procedures the same way as any distributed consensus-driven
        operation in the respective systems.  This respects the native
        decision-making processes in those systems and enables multi-party
        groups backing those systems to interact with each other as units.

     *  Minimize trust in gateways: the integrity of the protocol should
        not be dependent on the reliability of either gateway.  The next
        subsection elaborates on the desired security properties.









  Ramakrishna, et al.       Expires 19 March 2026                [Page 14]


  Internet-Draft              SAT Data Sharing              September 2025


     *  Preserving system autonomy and self-sovereignty: the endpoint
        systems should have complete freedom in determining their
        respective access controls and verification policies, and in
        choosing when to initiate a view request or whether to respond to
        a view request.  The internal activities of each system should be
        oblivious to the other and should not affect data sharing protocol
        instance.

     *  Accommodating heterogeneity: the end-to-end protocol should work
        the same regardless of the distributed ledger technology
        implementation backing either endpoint system.

     *  Avoid synchronization: the protocol should not rely on any
        externally guided synchronization mechanism, such as a global
        clock, and instead rely purely on asynchronous message transfers.

  5.9.  Security Considerations

     The security considerations of the protocol include, but are not
     limited to, the following: - Distributed consensus: rely on the
     consensus mechanism of the counterparty system both to authenticate
     view requests and to validate views.  This can mitigate (or avoid)
     Byzantine failure of malicious nodes within the endpoint systems.  It
     can also prevent a malicious client from supplying a fake view in the
     destination system. - Integrity: rely on digital signatures over the
     view requests and responses (made by the client in the destination
     system and peers in the source system) so that the gateways cannot
     tamper with the messages undetected. - Confidentiality: rely on end-
     to-end encryption of the view response so that the gateways cannot
     exfiltrate the view contents and/or the associated proofs.
     Exfiltration will violate the access control policies of the source
     system. - Availability: rely on redundancy and failover to mitigate
     against denial-of-service attacks mounted by either gateway.
     Multiple gateways should be configured and kept on standby in
     practice.

  5.10.  Privacy Considerations

     Access control policies allow source systems to have privacy by
     default, and only reveal the minimum ledger information necessary to
     external entities.  Any data shared across two systems is private
     between them only if the gateways are maintained by stakeholders
     within the respective systems.  This should be kept in mind when
     selecting or discovering gateways for data sharing instances.







  Ramakrishna, et al.       Expires 19 March 2026                [Page 15]


  Internet-Draft              SAT Data Sharing              September 2025


  5.11.  Fault Tolerance and Crash Recovery

     The usual considerations of fault tolerance, crashes, and session
     maintenance, apply to gateways involved in data sharing.  Various
     techniques for failover and session state and log backups can be used
     to guard against, or recover from, the possibility of either gateway
     failing during a data sharing instance.  Details are beyond the scope
     of this draft, which makes no recommendations on this topic either.

  6.  Pre-request setup and configuration

     Either endpoint system in a data sharing protocol instance must have
     the following configured in their respective data stores, which, if
     the system is a distributed ledger system, should be a shared ledger.

     *  View request access control policies: as described in Section 8 in
        the Views and View Addresses draft [SATV], one or more access
        control policy rules according to the given specification should
        be recorded before a data sharing protocol instance.  If a view
        request is received by a system and there is no appropriate policy
        rule in the system’s record, the principle of least privilege
        should be applied, and the view request rejected.

     *  View verification policies: as described in Section 6 in the Views
        and View Addresses draft [SATV], one or more verification policies
        according to the given specification should be recorded before a
        data sharing protocol instance.  If a view is received by a system
        and there is no appropriate policy rule in the system’s record,
        the view should be deemed invalid.  The client itself ought to
        avoid sending a view request if an appropriate verification policy
        cannot be retrieved, but even if a malicious client proceeds with
        a spurious view request, the destination system’s back end should
        declare the proof accompanying the view response to be invalid.

     *  External identities and certifications: participating systems can
        be abstracted into one or more security domains that represent the
        stakeholders of that system.  For effective policy enforcement,
        i.e., to authenticate a view request or validate a view, knowledge
        of a remote system’s security domains—identity providers,
        certification authorities, and group structure if the system is a
        distributed ledger—is necessary.  This information is typically,
        though not limited to, a set of certificate hierarchies, which
        should be determined and recorded to the system’s data store
        before a data sharing protocol instance.  In the absence of such
        recorded information about the counterparty system, the protocol
        should terminate in the view request access control check step or
        in the view validation step.




  Ramakrishna, et al.       Expires 19 March 2026                [Page 16]


  Internet-Draft              SAT Data Sharing              September 2025


  7.  Related Open Issues

     This draft provides a specification for views and how to addresses
     them.  It further describes a protocol whereby one system can request
     a view from another through gateways.  But there are several aspects
     of the end to-end process, which are extraneous to the data sharing
     protocol yet crucial to its successful completion.  Though detailed
     specifications of these are beyond the scope of this draft, we list
     them in this section for readers’ considerations.

  7.1.  Global identification of blockchain systems and public keys

     To construct a view address as well as determine a suitable gateway
     to send a view request to, we need identifiers and naming systems for
     distributed ledgers and the networks that maintain them.  In
     addition, we need ways to associate public keys with these names for
     authentication purposes.  Further, we need mechanisms to store and
     retrieve these identifiers and keys in a distributed, and ideally
     decentralized, manner.  The concepts of Decentralized Identifiers
     [DID] and Self-Sovereign Identity [SSI] are promising technologies to
     begin devising such specifications.

  7.2.  Discovery of gateways nodes within a blockchain system

     To initiate a data sharing protocol, a client in a distributed ledger
     system needs to identify a suitable gateway node.  This can be done
     in several different ways, one of which involves registering the set
     of gateways on a shared ledger within the system.  Because, ideally,
     the gateway does not need to be highly trusted, there are few
     security implications but potentially larger efficiency implications
     in the choice of mechanism for registration and discovery of local
     gateway nodes.

  7.3.  Remote gateway discovery

     How gateways can discover other gateways acting on behalf of remote
     distributed ledger systems is an open question.  The problem can be
     related to the routing problem (i.e., discovery of routing paths) in
     packet networking [RFC791].












  Ramakrishna, et al.       Expires 19 March 2026                [Page 17]


  Internet-Draft              SAT Data Sharing              September 2025


  7.4.  Decentralized identity management across distributed ledger
        systems

     Mechanisms are required to continuously sync external identities and
     certifications as described in Section 5 as a basis for data sharing.
     To keep these mechanisms are decentralized as possible and leverage
     existing identity registries, we can leverage the concepts of
     decentralized identifiers [DID] and verifiable credentials [VC22].
     Protocols for this purpose, which use DID registries and trust
     anchors, have been proposed [WRFCDID], and we can use them as
     starting points for this specification.

  8.  References

  8.1.  Normative References

     [DID]      Sporny, M., Longley, D., Sabadello, M., Reed, D., Steele,
                O., and C. Allen, "Decentralized Identifiers (DIDs) v1.1,
                Core architecture, data model, and representations (W3C
                Candidate Recommendation Snapshot)", September 2025,
                <https://w3c.github.io/did/>.

     [FATF]     FATF, "International Standards on Combating Money
                Laundering and the Financing of Terrorism & Proliferation
                - The FATF Recommendations", October 2018,
                <http://www.fatf-
                gafi.org/publications/fatfrecommendations/documents/fatf-
                recommendations.html>.

     [ISO]      ISO, "Blockchain and distributed ledger technologies-
                Vocabulary (ISO:22739:2024)", January 2024,
                <https://www.iso.org/standard/82208.html>.

     [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
                Blockchain Technology Overview (NISTR-8202)", October
                2018, <https://doi.org/10.6028/NIST.IR.8202>.

     [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/rfc/rfc791>.

     [SATA]     Hardjono, T., Hargreaves, M., Smith, N., and V.
                Ramakrishna, "Secure Asset Transfer (SAT) Interoperability
                Architecture, IETF, draft-ietf-satp-architecture-08", July
                2025, <https://datatracker.ietf.org/doc/draft-ietf-satp-
                architecture/>.





  Ramakrishna, et al.       Expires 19 March 2026                [Page 18]


  Internet-Draft              SAT Data Sharing              September 2025


     [SATP]     Hargreaves, M., Hardjono, T., Belchior, R., Ramakrishna,
                V., and A. Chiriac, "Secure Asset Transfer Protocol (SATP)
                Core, IETF, draft-ietf-satp-core-11", August 2025,
                <https://datatracker.ietf.org/doc/draft-ietf-satp-core/>.

     [SATU]     Ramakrishna, V., Hardjono, T., and C. Liu, "Secure Asset
                Transfer (SAT) Use Cases, IETF, draft-ietf-satp-usecases-
                06", July 2025, <https://datatracker.ietf.org/doc/draft-
                ietf-satp-usecases/>.

     [SATV]     Ramakrishna, V., Pandit, V., Abebe, E., Nishad, S., and K.
                Narayanam, "Views and View Addresses for Secure Asset
                Transfer, IETF, draft-ramakrishna-satp-views-addresses-
                06", September 2025, <https://datatracker.ietf.org/doc/
                draft-ramakrishna-satp-views-addresses/>.

     [SSI]      Tobin, A. and D. Reed, "The Inevitable Rise of Self-
                Sovereign Identity, A white paper from the Sovrin
                Foundation", March 2017, <https://sovrin.org/wp-
                content/uploads/2018/03/The-Inevitable-Rise-of-Self-
                Sovereign-Identity.pdf>.

     [VC22]     Sporny, M., Longley, D., Chadwick, D., and I. Herman,
                "Verifiable Credentials Data Model v2.1 (W3C Editor’s
                Draft)", May 2025, <https://w3c.github.io/vc-data-model/>.

  8.2.  Informative References

     [ABCH20]   Ankenbrand, T., Bieri, D., Cortivo, R., Hoehener, J., and
                T. Hardjono, "Proposal for a Comprehensive Crypto Asset
                Taxonomy", May 2020, <https://arxiv.org/abs/2007.11877>.

     [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
                Correia, "A Survey on Blockchain Interoperability: Past,
                Present, and Future Trends", May 2020,
                <https://arxiv.org/abs/2005.14282v2>.

     [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet
                Protocols, ACM Computer Communication Review, Proc SIGCOMM
                88, vol. 18, no. 4, pp. 106-114", August 1988.

     [Ethe22]   "Ethereum Whitepaper", September 2022,
                <https://ethereum.org/en/whitepaper/>.

     [Gray81]   Gray, J., "The Transaction Concept: Virtues and
                Limitations, in VLDB Proceedings of the 7th International
                Conference, Cannes, France, September 1981, pp. 144-154",
                September 1981.



  Ramakrishna, et al.       Expires 19 March 2026                [Page 19]


  Internet-Draft              SAT Data Sharing              September 2025


     [Herl19]   Herlihy, M., "Blockchains from a Distributed Computing
                Perspective, Communications of the ACM, vol. 62, no. 2,
                pp. 78-85", February 2019,
                <https://doi.org/10.1145/3209623>.

     [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards an
                Interoperability Architecture for Blockchain Autonomous
                Systems, IEEE Transactions on Engineering Management",
                June 2019, <https://ieeexplore.ieee.org/document/8743548>.

     [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted
                Computing Base for Blockchain Infrastructure Security,
                Frontiers Journal, Special Issue on Blockchain Technology,
                Vol. 2, No. 24", December 2019,
                <https://doi.org/10.3389/fbloc.2019.00024>.

     [IDevID]   Richardson, M., "A Taxonomy of operational security
                considerations for manufacturer installed keys and Trust
                Anchors. IETF draft-irtf-t2trg-taxonomy-manufacturer-
                anchors-11", August 2025,
                <https://datatracker.ietf.org/doc/draft-irtf-t2trg-
                taxonomy-manufacturer-anchors/>.

     [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
                in System Design, ACM Transactions on Computer Systems,
                vol. 2, no. 4, pp. 277-288", November 1984.

     [WRFCDID]  Ramakrishna, V., Narayanam, K., Chandra Ghosh, B., and E.
                Abebe, "Decentralized Network-Identity Discovery and
                Management for Interoperation, Hyperledger Cacti - Weaver,
                RFC 01-011, LFDT", August 2022, <https://github.com/
                hyperledger-
                cacti/cacti/blob/main/weaver/rfcs/models/identity/network-
                identity-management.md>.

  Authors' Addresses

     Venkatraman Ramakrishna
     IBM Research
     Email: vramakr2@in.ibm.com


     Vinayaka Pandit
     IBM Research
     Email: pvinayak@in.ibm.com






  Ramakrishna, et al.       Expires 19 March 2026                [Page 20]


  Internet-Draft              SAT Data Sharing              September 2025


     Ermyas Abebe
     Consensys
     Email: ermyas.abebe@consensys.net


     Sandeep Nishad
     IBM Research
     Email: sandeep.nishad1@ibm.com


     Dhinakaran Vinayagamurthy
     IBM Research
     Email: dvinaya1@in.ibm.com






































  Ramakrishna, et al.       Expires 19 March 2026                [Page 21]


name: draft-liu-oauth-a2a-profile
rev: 00
title: Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens
time: 2026-04-23T07:09:58Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T12:43:07Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021926+00:00
source: ietf
abstract:
  This document defines a profile for using OAuth Transaction Tokens in
     Agent-to-Agent (A2A) communication scenarios.  The profile specifies
     how A2A call chain context can be embedded within Transaction Tokens
     to maintain agent identity, authorization context, and execution flow
     across distributed agent workloads within trusted domains.

full_text:
  Network Working Group                                          C. P. Liu
  Internet-Draft                                                     Y. Ni
  Intended status: Standards Track                                  Huawei
  Expires: 23 April 2026                                   20 October 2025


         Agent-to-Agent (A2A) Profile for OAuth Transaction Tokens
                       draft-liu-oauth-a2a-profile-00

  Abstract

     This document defines a profile for using OAuth Transaction Tokens in
     Agent-to-Agent (A2A) communication scenarios.  The profile specifies
     how A2A call chain context can be embedded within Transaction Tokens
     to maintain agent identity, authorization context, and execution flow
     across distributed agent workloads within trusted domains.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 23 April 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.




  Liu & Ni                  Expires 23 April 2026                 [Page 1]


  Internet-Draft              oauth-a2a-profile               October 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
     3.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     4.  Transaction Token Request . . . . . . . . . . . . . . . . . .   3
     5.  Transaction Token Claims  . . . . . . . . . . . . . . . . . .   4
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     8.  Informative References  . . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     The OAuth Transaction Tokens specification
     [I-D.ietf-oauth-transaction-tokens] provides a mechanism for
     propagating user identity and authorization context across workloads
     during the processing of programmatic requests.  This capability
     aligns naturally with the requirements of Agent-to-Agent (A2A)
     communication systems [A2A-SPEC], where autonomous agents coordinate
     through call chains while maintaining security of the call context.

     This document explores the relationship between these two
     specifications and proposes a profile that enables Transaction Tokens
     to carry A2A-specific context information.

  2.  Terminology

     This document uses terms from both the OAuth Transaction Tokens
     [I-D.ietf-oauth-transaction-tokens] and Agent-to-Agent [A2A-SPEC]
     specifications.

  3.  Rationale

     A2A systems involve complex call chains where autonomous agents
     invoke other agents to accomplish tasks.  These call chains require:

     *  Preservation of original requestor identity and original
        authorization context

     *  Propagation of execution context across agent boundaries

     *  Auditability and traceability of the entire call chain

     *  Security boundaries between different agent capabilities






  Liu & Ni                  Expires 23 April 2026                 [Page 2]


  Internet-Draft              oauth-a2a-profile               October 2025


     The Transaction Token framework addresses similar concerns for API/
     workload call chains within trusted domains.  Transaction Tokens are
     short-lived, signed JWTs that assert the identity of a user or a
     workload and assert an authorization context.  There are many
     benefits if A2A calls are carried by Transaction Tokens:

     *  Preserved Call Context and Identity: Transaction tokens are signed
        JWTs, providing immutable information about the user or workload,
        certain parameters of the call, and specific contextual attributes
        of the call.  Agentic systems execute multi-step, cross-domain
        actions where conversational state can sometimes drift from the
        originally authorized intent, creating "context rot" that
        undermines least-privilege guarantees and auditability.  The use
        of transaction tokens can preserve the original call context and
        prevent "context rot".

     *  Decreased Scope and Purpose: Transaction tokens enforce that the
        requested scope and purpose of a transaction are equal to or less
        than those of the subject token.  Agentic systems often divide the
        main tasks into a sequence of multiple sub-tasks.  This mechanism
        allows for granular permission models that minimize risks
        associated with overreach and excessive user privacy exposure.

     *  Ephemerality: Agentic systems frequently spawn short-lived,
        task-triggered workflows.  Transaction Tokens are expected to be
        short-lived (minutes).  The adoption reduces reliance on
        long-lived credentials and limits replay and lateral use.

  4.  Transaction Token Request

     In [I-D.ietf-oauth-transaction-tokens], Txn-Token Request defined a
     set of parameters, in which the following can be used for profiling.

     *  subject_token REQUIRED.  The value MUST represent the subject of
        the transaction.

        -  This data field carry the orginal OAuth access token issued by
           the user.  It SHOULD be signed by the original user.

     *  request_details OPTIONAL.  This parameter contains a base64url
        encoded JSON object which represents additional details of the
        transaction that MUST remain immutable throughout the processing
        of the transaction by multiple workloads.  The Transaction Token
        Service uses this information to construct the tctx claim.

        -  This data field carry the original A2A request call from the
           user, which MUST NOT change throughout the whole call chain.




  Liu & Ni                  Expires 23 April 2026                 [Page 3]


  Internet-Draft              oauth-a2a-profile               October 2025


        -  This will encapsulate the "User Input" in the "Message" struct
           from the A2A Protocol.

     *  request_context OPTIONAL.  This parameter contains a base64url
        encoded JSON object which represents the context of this
        transaction.

        -  This data field carry appended observations/contexts/decisions
           that can be changed by each hop of AI Agent.

        -  This will encapsulate all other fields in the "Message" struct
           from the A2A Protocol, such as "Agent Thinking", "Status
           Updates", "Metadata"...

  5.  Transaction Token Claims

     *  purp: REQUIRED A String defining the purpose or intent of this
        transaction.  The purp claim captures the exact purpose of this
        particular transaction.

        -  In the A2A profile, this claim will be a String "a2a.Task.id"
           from the A2A Protocol, as an unique identifier for the task.

     *  tctx: OPTIONAL A JSON object that contains values that remain
        immutable throughout the call chain.  The value of this claim is a
        JSON object that contains name/value pairs (wherein the value
        could itself be an object), which together assert the details that
        remain immutable through the call-chain where this Txn-Token is
        used.

        -  This claim will contain the exact contents in the
           "request_details" of the transaction token request, which will
           be the "User Input" in the "Message" struct from the A2A
           Protocol.

     *  rctx: OPTIONAL A JSON object that describes the environmental
        context of the requested transaction.

        -  This claim will contain the exact contents in the
           "request_context" of the transaction token request, which will
           be all other fields in the "Message" struct from the A2A
           Protocol, such as "Agent Thinking", "Status Updates",
           "Metadata"...

  6.  Security Considerations

     This document has no further security considerations.




  Liu & Ni                  Expires 23 April 2026                 [Page 4]


  Internet-Draft              oauth-a2a-profile               October 2025


  7.  IANA Considerations

     This document has no IANA actions.

  8.  Informative References

     [I-D.ietf-oauth-transaction-tokens]
                Tulshibagwale, A., Fletcher, G., and P. Kasselman,
                "Transaction Tokens", Work in Progress, Internet-Draft,
                draft-ietf-oauth-transaction-tokens-06, 28 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                transaction-tokens-06>.

     [A2A-SPEC] "Agent2Agent (A2A) Protocol Specifications", October 2025,
                <https://agent2agent.info/docs/introduction/>.

  Authors' Addresses

     Chunchi Peter Liu
     Huawei
     Email: liuchunchi@huawei.com


     Yuan Ni
     Huawei
     Email: niyuan1@huawei.com

























  Liu & Ni                  Expires 23 April 2026                 [Page 5]


name: draft-ye-problems-and-requirements-of-dns-for-ioa
rev: 02
title: Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA)
time: 2026-04-28T06:09:50Z
group_uri: /api/v1/group/group/1027/
expires: 2026-10-30T06:09:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:43.021936+00:00
source: ietf
abstract:
  In the AI-driven era, DNS is supposed to evolve with technological
     advancements to accommodate the complex and diverse requirements of
     the IoA.  This draft analyzes the issues surrounding DNS in
     supporting agents collaboration and explores corresponding technical
     requirements.

full_text:
  DNSOP                                                              J. Ye
  Internet-Draft                                                  W. Cheng
  Intended status: Informational                              China Mobile
  Expires: 6 May 2026                                                D. Ma
                                                                      ZDNS
                                                           2 November 2025


    Problems Statement and Requirements Analysis of DNS for Internet of
                                Agents (IoA)
            draft-ye-problems-and-requirements-of-dns-for-ioa-01

  Abstract

     In the AI-driven era, DNS is supposed to evolve with technological
     advancements to accommodate the complex and diverse requirements of
     the IoA.  This draft analyzes the issues surrounding DNS in
     supporting agents collaboration and explores corresponding technical
     requirements.

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

  Copyright Notice

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










  Ye, et al.                 Expires 6 May 2026                   [Page 1]


  Internet-Draft  Problems and Requirements of DNS for IoA   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Identifiers Reconstruction  . . . . . . . . . . . . . . .   4
       2.2.  Proliferating AI Agents . . . . . . . . . . . . . . . . .   4
       2.3.  High-density and Parallel Interaction . . . . . . . . . .   5
       2.4.  Dynamically Changing Services . . . . . . . . . . . . . .   5
       2.5.  Upgrade of Resolution Mode  . . . . . . . . . . . . . . .   5
       2.6.  Security Issues . . . . . . . . . . . . . . . . . . . . .   6
     3.  Requirements Analysis . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Global Unique Identifier  . . . . . . . . . . . . . . . .   6
       3.2.  Autonomous Capability Registration and Discovery  . . . .   6
       3.3.  Information Exchange  . . . . . . . . . . . . . . . . . .   7
         3.3.1.  Rich-information Metadata . . . . . . . . . . . . . .   7
         3.3.2.  Data Freshness Maintenance  . . . . . . . . . . . . .   7
       3.4.  High-Performance Resolution System  . . . . . . . . . . .   8
       3.5.  Multi-Dimensional Dynamic Scheduling Strategies . . . . .   8
       3.6.  Authentication and Authorization Mechanism  . . . . . . .   8
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       6.2.  Informative References  . . . . . . . . . . . . . . . . .   9
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     In the AI-driven era of intelligence, as intelligent agents with
     autonomous capabilities in perception, decision-making, execution,
     and learning enter the network, the network ecosystem is undergoing a
     profound transformation towards intelligentization and
     autonomization.  Agents, as the core interconnected entities in the
     Internet of Agents (IoA), autonomously discover, efficiently
     interact, and harmoniously collaborate with human users, other



  Ye, et al.                 Expires 6 May 2026                   [Page 2]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


     agents, and various tools, enabling flexible resource scheduling and
     promoting the Internet towards intelligentization and autonomization.

     Currently, the stable operation of the network heavily relies on IP
     addresses, with the Domain Name System (DNS) serving as a critical
     network infrastructure responsible for converting human-readable
     domain names to machine-readable addresses and acting as a bridge for
     network resources access.  Throughout decades of stable operation and
     global development, there are a suite of protocols and mechanisms
     also has been developed to establish a fully matured DNS ecosystem.
     For examples, DNS-Based Service Discovery (DNS-SD) [RFC6763] is
     designed to facilitate service discovery, Service Binding (SVCB) and
     HTTPS [RFC9640]records provide instruction of accessing a service,
     DNS Security (DNSSEC) [RFC4033] [RFC4034] [RFC4035] ensure data
     origin authentication and data integrity, and protocols such as DNS
     over HTTPS (DoH) [RFC8484], DNS over TLS (DoT) [RFC7858] and DNS over
     QUIC (DoQ) [RFC9250] supply encrypted transmission and enhance
     privacy and security.  Therefore, in the context of the flourishing
     development of AI agents, the DNS is supposed to evolve with
     technological advancements to serve the complex and diverse
     requirements of the IoA.  During interactions and collaborations
     between humans and agents, agents and agents, DNS as an
     infrastructure will continue to play a key role, providing technical
     support for efficient agent registration and discovery, real-time
     data synchronization, and intelligent scheduling and decision-making.
     Moreover, its capabilities might be further expanded to achieve
     semantic awareness, and effective orchestration of agents
     interactions.

     This draft aims to conduct an in-depth analysis of the issues
     surrounding the DNS system in supporting agents collaboration and to
     explore corresponding technical requirements, thereby providing
     robust support for the large-scale implementation and efficiency
     enhancement of the IoA.

  1.1.  Terminology

     DNS: Domain Name System

     DNS-SD: DNS-Based Service Discovery

     EDNS: Extension Mechanisms for DNS









  Ye, et al.                 Expires 6 May 2026                   [Page 3]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


  1.2.  Requirements Language

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

  2.  Problem Statement

  2.1.  Identifiers Reconstruction

     DNS, centered around domain names and IP addresses, fulfills a
     crucial role in addressing, mapping domain names to IP addresses.
     However, the existing IP addresses struggle to identify agents
     effectively.  This because that it is predicted that the number of AI
     agents will reach the scale of hundreds of billions in the future.
     Given the limited address space of IPv4, it isinadequate to support
     large-scale agent deployment and ensure stable connectivity.  Even if
     a full transition to IPv6, which offers abundant address resources,
     can alleviate the address shortage, issues such as address
     instability and oversized routing tables will still arise.  This is
     because that the IPv6 interface IDs undergo periodic rotation for
     security.  Additionally, the IPv6 addresses of some physical AI
     agents, such as embodied intelligent agents, dynamically change with
     variations of their geographical locations and the network they
     access.  The aforementioned factors make it challenging to uniquely
     identify an intelligent agent using its IP address.

  2.2.  Proliferating AI Agents

     With the emergence of new agents, corresponding resource records will
     be generated accordingly.  However, manually adding records to
     authoritative servers are inefficient and cannot keep pace with the
     rapid generation of agents.  Currently, there is no suitable
     capability-based registration and discovery.

     On one hand, the most interactions among agents are based on
     capabilities, but the current names of each level domains in the
     hierarchical architecture, which primarily convey information, such
     as organization and region, fails to intuitively grasp and describe
     their basic functionalities, making it difficult to directly use
     domain names to register and discover for agents.

     On the other hand, in the Internet, considering the intricate roles
     and the enormous quantity of devices involved, the current service
     discovery and registration mechanisms (e.g. DNS-SD) are deficient in
     essential security authentication capabilities, rendering them



  Ye, et al.                 Expires 6 May 2026                   [Page 4]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


     ineffective for application in the IoA.  Consequently, these
     situation underscores an urgent necessity for developing a service
     discovery and registration mechanism specifically tailored to the
     IoA.

  2.3.  High-density and Parallel Interaction

     Interactions in IoA exhibit high frequency and complexity.  Agent
     interactions often involve multiple subtask calls within a single
     task query, triggering multiple DNS queries and significantly
     increasing the number of queries and densities, accompanied by
     parallel queries.  This high-frequency and concurrent query pattern
     imposes extremely high demands on the processing performance of the
     DNS sytem.

  2.4.  Dynamically Changing Services

     As services undergo continuous evolution and agents engage in
     frequent interactions, the services of agents are developing and
     upgrading, and their operational states are also in a state of
     constant change.  New services continually emerge, while existing
     services may be gradually phased out or subject to updates.
     Meanwhile, agent states may transition from active to inactive, or
     continuously fluctuate load conditions.  However, the resource
     records (RR) within the existing DNS system remain static and are
     updated only infrequently, thereby failing to accurately and promptly
     reflect the latest situations of agents.

  2.5.  Upgrade of Resolution Mode

     The resolution mechanism of the current DNS system is relatively
     simplistic and falls short of optimally matching capabilities with
     resources during agent interactions.  When processing multiple
     resource records associated with the same tree-tuple (name, class,
     type), existing mechanisms frequently depend on scheduling dimensions
     such as round-robin, weights, and geographical proximity.  Although
     there are scenarios that take resource load into account, these
     mechanisms merely offer crude estimations based on simple request
     counts.  Such estimations can significantly deviate from the actual
     load, thereby leading to reduced scheduling flexibility and accuracy.











  Ye, et al.                 Expires 6 May 2026                   [Page 5]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


  2.6.  Security Issues

     During the interaction of agents, the underlying security issues
     should not be overlooked.  For example, it is crucial whether an
     agent's identity is forged, whether the capabilities it registers are
     genuine, and whether these capabilities accurately correspond to its
     claimed identity.  Any lapses in these areas could potentially expose
     users to attacks, threats, privacy leakage and other risks, or even
     lead to widespread network breakdown.

  3.  Requirements Analysis

     The proliferation of agents is driving the network towards enhanced
     efficiency, intelligence, and flexibility.  During the processes of
     autonomous discovery, efficient interaction, and collaborative
     collaboration among agents as well as between agents and users, new
     requirements are imposed on the DNS, such as identitication, data
     structure, and resolution mode.  The detailed requirement analysis of
     the key capabilities required for the DNS within the IoA is as below.

  3.1.  Global Unique Identifier

     It is of paramount importance to assign a unique identity identifier
     to each agent.  Firstly, this immutable ID will effectively isolate
     the impact caused by the frequent changes of IP addresses or URLs.
     In addition, while facilitating precise identification and
     differentiation of individual agents, it also provide a solid
     foundation for the verification of agent identities.

  3.2.  Autonomous Capability Registration and Discovery

     As services keep evolving, new agents are constantly emerging, and
     there will be new agents registered in the Internet at any given
     time.  Therefore, it is of vital importance to achieve automatic
     capability registration, discovery, and publication of agents without
     manual intervention.

     One approach is to directly achieve the mapping from agents’
     capabilities to their identity identifiers by introducing capability-
     aware domain names.  New domain names ought to incorporate additional
     hierarchical levels that convey capability-related information,
     beyond the basic information (such as organizations and regions)
     typically found in conventional domain names.  The newly introduced
     name levels should be capable of intuitively and succinctly
     representing the capabilities of a specific type of agent or other
     distinctive attributes.  For example, a domain name designated for an
     image processing agent might include keywords relevant to image
     processing, such as "...appname.ImageProcess.organizer."  This



  Ye, et al.                 Expires 6 May 2026                   [Page 6]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


     approach would enable authoritative servers to directly identify and
     retrieve all image processing agents through domain names when other
     agents or users are searching for image processing agents, thereby
     enhancing the efficiency of agent discovery.

     The other involves refining the existing DNS-SD mechanism.
     Crucially, this mechanism should be enhanced by incorporating
     authentication and rights verification to effectively prevent
     counterfeiting and impersonation attacks during the registration and
     discovery of a large number of agents.  Furthermore, the structure "<
     Service >.< Domain >" defined in [RFC6763] also should intruduce
     capability-aware service names to handle the mapping from agents’
     capabilities to domain names, locating a scope of candidate agents.

  3.3.  Information Exchange

  3.3.1.  Rich-information Metadata

     In addition to utilizing domain names or PTR [RFC1035] to narrow down
     the scope of agents that provide specific capabilities, there should
     also be other data presenting more detailed descriptions of these
     agents, thereby facilitating further decision-making.  Therefore,
     resource records (e.g. SRV, TXT, SVCB) should be capable of carrying
     extensive metadata, encompassing detailed capability descriptions,
     configuration parameters, load conditions, and other pertinentially
     valuable information about the agents.  These metadata serves as an
     agent's "digital business card," providing other agents, users, and
     schedulers with a comprehensive insight into the agent's information.
     For example, an agent's RRset could include its processing
     performance, supported protocol types, and current workload, thereby
     assisting schedulers and other agents in making well-informed
     decisions.

     Meanwhile, to gain a better understanding of requester intentions and
     preferences, it is recommended to incorporate additional information
     into DNS request messages through Extended DNS (EDNS) [RFC6891] or
     service-related tags labeled by recursive server or gateways.

  3.3.2.  Data Freshness Maintenance

     Given the frequent changes in agent information, a data update
     mechanism is imperative to guarantee the freshness of data.  Within
     this mechanism, subscription-push [RFC8490], regular detection and/or
     periodic reporting should be employed to ensure that the data (e.g.
     RRset) remains up-to-date.  For data with low change frequencies,
     such as capability descriptions and configurations, real-time updates
     can be adopted, pushing or reporting relevant resource records when
     subscribed data undergoes changes.  For data with high change



  Ye, et al.                 Expires 6 May 2026                   [Page 7]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


     frequencies, such as workload and network performance, periodic
     updates can be utilized to to prevent adverse impacts on network and
     processing performance.  Additionally, to prevent a large number of
     simultaneous data refreshes across the network, a standby mode can be
     configured for agents with low usage, thereby reducing network load
     while maintaining low power consumption.

  3.4.  High-Performance Resolution System

     With the growing number of agents and increasing interaction
     densities, the entire resolution system must possess high
     performance, capable of rapidly and accurately processing a large
     number of concurrent query requests.

  3.5.  Multi-Dimensional Dynamic Scheduling Strategies

     Given the enormous number of agents, selecting the most suitable one
     from a pool of agents of the same type poses a significant challenge.
     The DNS for IoA should be equipped with multi-dimensional dynamic
     scheduling capabilities.  It should dynamically select the optimal
     resolution result based on agent resource records (including
     capability descriptions, geographical locations, workload, etc.),
     business demands obtained through EDNS or other labels in pakctes,
     and in conjunction with network environments and load-balance
     strategies to achieve appropriate resource allocation.

  3.6.  Authentication and Authorization Mechanism

     In agent networks, authentication and authorization are crucial for
     ensuring network security and reliability.  This includes verifying
     agent IDs and capabilities (e.g., resource records).  Strict identity
     authentication guarantees that only legitimate agents whose IDs are
     corresponding to their feature can access the network for
     registration.  Meanwhile, capability authentication serves to prevent
     the advertisement of false capability information, thereby ensuring
     the accuracy of information about agents.  These verifications occur
     during capabilities registration, with authoritative servers
     validating the relevant information of service providers to ensure
     their capability and qualification to provide the corresponding
     services.  Additionally, service consumers (e.g. terminals and other
     agents) also could validate the received data to prevent tampering
     during transmission by intermediate third parties.  By establishing a
     robust authentication and authorization mechanism, a secure and
     reliable network ecosystem can be constructed for IoA.







  Ye, et al.                 Expires 6 May 2026                   [Page 8]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


  4.  Security Considerations

     TBD.

  5.  IANA Considerations

     This document has no IANA actions.

  6.  References

  6.1.  Normative References

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

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

  6.2.  Informative References

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

     [RFC9640]  Watsen, K., "YANG Data Types and Groupings for
                Cryptography", RFC 9640, DOI 10.17487/RFC9640, October
                2024, <https://www.rfc-editor.org/rfc/rfc9640>.

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security Extensions",
                RFC 4034, DOI 10.17487/RFC4034, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4034>.

     [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Protocol Modifications for the DNS Security
                Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4035>.






  Ye, et al.                 Expires 6 May 2026                   [Page 9]


  Internet-Draft  Problems and Requirements of DNS for IoA   November 2025


     [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
                (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
                <https://www.rfc-editor.org/rfc/rfc8484>.

     [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
                and P. Hoffman, "Specification for DNS over Transport
                Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
                2016, <https://www.rfc-editor.org/rfc/rfc7858>.

     [RFC9250]  Huitema, C., Dickinson, S., and A. Mankin, "DNS over
                Dedicated QUIC Connections", RFC 9250,
                DOI 10.17487/RFC9250, May 2022,
                <https://www.rfc-editor.org/rfc/rfc9250>.

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

     [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
                for DNS (EDNS(0))", STD 75, RFC 6891,
                DOI 10.17487/RFC6891, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6891>.

     [RFC8490]  Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S.,
                Lemon, T., and T. Pusateri, "DNS Stateful Operations",
                RFC 8490, DOI 10.17487/RFC8490, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8490>.

  Acknowledgements

  Contributors

  Authors' Addresses

     Jiaming Ye
     China Mobile
     Email: yejiaming@chinamobile.com


     Weiqiang Cheng
     China Mobile
     Email: chengweiqiang@chinamobile.com


     Di Ma
     ZDNS
     Email: madi@zdns.cn




  Ye, et al.                 Expires 6 May 2026                  [Page 10]


name: draft-ietf-httpbis-rfc6265bis
rev: 22
title: Cookies: HTTP State Management Mechanism
time: 2025-12-09T15:00:38Z
group_uri: /api/v1/group/group/1718/
expires: 2026-06-04T18:27:41Z
ad: /api/v1/person/person/116439/
shepherd: /api/v1/person/email/mnot@mnot.net/
categories: []
tags: []
fetched_at: 2026-03-08T17:35:44.999943+00:00
source: ietf
source_id: 68756
source_url: https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/
doc_status: active
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 flaws that degrade their security and
     privacy, the Cookie and Set-Cookie header fields are widely used on
     the Internet.  This document obsoletes RFC 6265.

states:
  ["/api/v1/doc/state/1/", "/api/v1/doc/state/108/", "/api/v1/doc/state/115/", "/api/v1/doc/state/17/", "/api/v1/doc/state/117/", "/api/v1/doc/state/44/"]

full_text:
  HTTP                                                     S. Bingler, Ed.
  Internet-Draft                                                          
  Obsoletes: 6265 (if approved)                               M. West, Ed.
  Intended status: Standards Track                              Google LLC
  Expires: 4 June 2026                                    J. Wilander, Ed.
                                                                Apple, Inc
                                                           1 December 2025


                  Cookies: HTTP State Management Mechanism
                      draft-ietf-httpbis-rfc6265bis-22

  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 flaws that degrade their security and
     privacy, the Cookie and Set-Cookie header fields are widely used on
     the Internet.  This document obsoletes RFC 6265.

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

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

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





  Bingler, et al.            Expires 4 June 2026                  [Page 1]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 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 4 June 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
     2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Conformance Criteria  . . . . . . . . . . . . . . . . . .   5
       2.2.  Syntax Notation . . . . . . . . . . . . . . . . . . . . .   5
       2.3.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
       2.4.  Name Resolution System  . . . . . . . . . . . . . . . . .   7
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       3.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Which Requirements to Implement . . . . . . . . . . . . .  10
         3.2.1.  Cookie Producing Implementations  . . . . . . . . . .  11
         3.2.2.  Cookie Consuming Implementations  . . . . . . . . . .  11
     4.  Server Requirements . . . . . . . . . . . . . . . . . . . . .  12
       4.1.  Set-Cookie Header . . . . . . . . . . . . . . . . . . . .  12



  Bingler, et al.            Expires 4 June 2026                  [Page 2]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         4.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  12
         4.1.2.  Semantics (Non-Normative) . . . . . . . . . . . . . .  15
         4.1.3.  Cookie Name Prefixes  . . . . . . . . . . . . . . . .  18
       4.2.  Cookie Header . . . . . . . . . . . . . . . . . . . . . .  19
         4.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  19
         4.2.2.  Semantics . . . . . . . . . . . . . . . . . . . . . .  20
     5.  User Agent Requirements . . . . . . . . . . . . . . . . . . .  20
       5.1.  Subcomponent Algorithms . . . . . . . . . . . . . . . . .  21
         5.1.1.  Dates . . . . . . . . . . . . . . . . . . . . . . . .  21
         5.1.2.  Canonicalized Host Names  . . . . . . . . . . . . . .  23
         5.1.3.  Domain Matching . . . . . . . . . . . . . . . . . . .  23
         5.1.4.  Paths and Path-Match  . . . . . . . . . . . . . . . .  23
       5.2.  "Same-site" and "cross-site" Requests . . . . . . . . . .  24
         5.2.1.  Document-based requests . . . . . . . . . . . . . . .  25
         5.2.2.  Worker-based requests . . . . . . . . . . . . . . . .  26
       5.3.  Ignoring Set-Cookie Header Fields . . . . . . . . . . . .  27
       5.4.  Cookie Name Prefixes  . . . . . . . . . . . . . . . . . .  27
       5.5.  Cookie Lifetime Limits  . . . . . . . . . . . . . . . . .  28
       5.6.  The Set-Cookie Header Field . . . . . . . . . . . . . . .  29
         5.6.1.  The Expires Attribute . . . . . . . . . . . . . . . .  31
         5.6.2.  The Max-Age Attribute . . . . . . . . . . . . . . . .  32
         5.6.3.  The Domain Attribute  . . . . . . . . . . . . . . . .  32
         5.6.4.  The Path Attribute  . . . . . . . . . . . . . . . . .  33
         5.6.5.  The Secure Attribute  . . . . . . . . . . . . . . . .  33
         5.6.6.  The HttpOnly Attribute  . . . . . . . . . . . . . . .  33
         5.6.7.  The SameSite Attribute  . . . . . . . . . . . . . . .  33
       5.7.  Storage Model . . . . . . . . . . . . . . . . . . . . . .  35
       5.8.  Retrieval Model . . . . . . . . . . . . . . . . . . . . .  41
         5.8.1.  The Cookie Header Field . . . . . . . . . . . . . . .  41
         5.8.2.  Non-HTTP APIs . . . . . . . . . . . . . . . . . . . .  42
         5.8.3.  Retrieval Algorithm . . . . . . . . . . . . . . . . .  42
     6.  Implementation Considerations . . . . . . . . . . . . . . . .  44
       6.1.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .  44
       6.2.  Application Programming Interfaces  . . . . . . . . . . .  45
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  45
       7.1.  Third-Party Cookies . . . . . . . . . . . . . . . . . . .  46
       7.2.  Cookie Policy . . . . . . . . . . . . . . . . . . . . . .  47
       7.3.  User Controls . . . . . . . . . . . . . . . . . . . . . .  47
       7.4.  Expiration Dates  . . . . . . . . . . . . . . . . . . . .  48
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  48
       8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  48
       8.2.  Ambient Authority . . . . . . . . . . . . . . . . . . . .  49
       8.3.  Clear Text  . . . . . . . . . . . . . . . . . . . . . . .  49
       8.4.  Session Identifiers . . . . . . . . . . . . . . . . . . .  50
       8.5.  Weak Confidentiality  . . . . . . . . . . . . . . . . . .  51
       8.6.  Weak Integrity  . . . . . . . . . . . . . . . . . . . . .  51
       8.7.  Reliance on DNS . . . . . . . . . . . . . . . . . . . . .  52
       8.8.  SameSite Cookies  . . . . . . . . . . . . . . . . . . . .  52



  Bingler, et al.            Expires 4 June 2026                  [Page 3]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         8.8.1.  Defense in depth  . . . . . . . . . . . . . . . . . .  52
         8.8.2.  Top-level Navigations . . . . . . . . . . . . . . . .  53
         8.8.3.  Mashups and Widgets . . . . . . . . . . . . . . . . .  54
         8.8.4.  Server-controlled . . . . . . . . . . . . . . . . . .  54
         8.8.5.  Reload navigations  . . . . . . . . . . . . . . . . .  54
         8.8.6.  Top-level requests with "unsafe" methods  . . . . . .  55
       8.9.  Public Suffix List  . . . . . . . . . . . . . . . . . . .  56
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  56
       9.1.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  56
       9.2.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .  56
       9.3.  "Cookie Attributes" Registry  . . . . . . . . . . . . . .  57
         9.3.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .  57
         9.3.2.  Registration  . . . . . . . . . . . . . . . . . . . .  57
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  57
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  58
       10.2.  Informative References . . . . . . . . . . . . . . . . .  59
     Appendix A.  Changes from RFC 6265  . . . . . . . . . . . . . . .  61
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  62
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  62

  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 indicates a scope for each
     cookie when sending it to the user agent.  The scope indicates the
     maximum amount of time in which the user agent should return the
     cookie, the servers to which the user agent should return the cookie,
     and the connection types for which the cookie is applicable.

     For historical reasons, cookies contain a number of security and
     privacy flaws.  For example, a server can indicate that a given
     cookie is intended for "secure" connections, but the 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 specification applies to developers of both cookie-producing
     servers and cookie-consuming user agents.  Section 3.2 helps to
     clarify the intended target audience for each implementation type.




  Bingler, et al.            Expires 4 June 2026                  [Page 4]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     To maximize interoperability with user agents, servers SHOULD limit
     themselves to the well-behaved profile defined in Section 4 when
     generating cookies.

     User agents MUST implement the more liberal processing rules defined
     in Section 5, in order to maximize interoperability with existing
     servers that do not conform to the well-behaved profile defined in
     Section 4.

     This document specifies the syntax and semantics of these header
     fields as they are actually used on the Internet.  In particular,
     this document does not create new syntax or semantics beyond those in
     use today.  The recommendations for cookie generation provided in
     Section 4 represent a preferred subset of current server behavior,
     and even the more liberal cookie processing algorithm provided in
     Section 5 does not recommend all of the syntactic and semantic
     variations in use today.  Where some existing software differs from
     the recommended protocol in significant ways, the document contains a
     note explaining the difference.

     This document obsoletes [RFC6265].

  2.  Conventions

  2.1.  Conformance Criteria

     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.

     Requirements phrased in the imperative as part of algorithms (such as
     "strip any leading space characters" or "return false and abort this
     algorithm") are to be interpreted with the meaning of the key word
     ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm.

     Conformance requirements phrased as algorithms or specific steps can
     be implemented in any manner, so long as the end result is
     equivalent.  In particular, the algorithms defined in this
     specification are intended to be easy to understand and are not
     intended to be performant.

  2.2.  Syntax Notation

     This specification uses the Augmented Backus-Naur Form (ABNF)
     notation of [RFC5234].




  Bingler, et al.            Expires 4 June 2026                  [Page 5]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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 [USASCII] character), VCHAR (any visible
     [USASCII] character), and WSP (whitespace).

     The OWS (optional whitespace) and BWS (bad whitespace) rules are
     defined in Section 5.6.3 of [HTTP].

  2.3.  Terminology

     The terms "user agent", "client", "server", "proxy", and "origin
     server" have the same meaning as in the HTTP/1.1 specification
     (Section 3 of [HTTP]).

     The request-host is the name of the host, as known by the user agent,
     to which the user agent is sending an HTTP request or from which it
     is receiving an HTTP response (i.e., the name of the host to which it
     sent the corresponding HTTP request).

     The term request-uri refers to "target URI" as defined in Section 7.1
     of [HTTP].

     Two sequences of octets are said to case-insensitively match each
     other if and only if they are equivalent under the i;ascii-casemap
     collation defined in [RFC4790].

     The term string means a sequence of non-NUL octets.

     The terms "active browsing context", "active document", "ancestor
     navigables", "container document", "content navigable", "dedicated
     worker", "Document", "inclusive ancestor navigables", "navigable",
     "navigate", "opaque origin", "sandboxed origin browsing context
     flag", "shared worker", "the worker's Documents", "top-level
     traversable", and "WorkerGlobalScope" are defined in [HTML].

     "Service Workers" are defined in the Service Workers specification
     [SERVICE-WORKERS].

     The term "origin", the mechanism of deriving an origin from a URI,
     and the "the same" matching algorithm for origins are defined in
     [RFC6454].

     "Safe" HTTP methods include GET, HEAD, OPTIONS, and TRACE, as defined
     in Section 9.2.1 of [HTTP].




  Bingler, et al.            Expires 4 June 2026                  [Page 6]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     A domain's "public suffix" is the portion of a domain that is
     controlled by a public registry, such as "com", "co.uk", and
     "pvt.k12.wy.us".  A domain's "registrable domain" is the domain's
     public suffix plus the label to its left.  That is, for
     https://www.site.example, the public suffix is example, and the
     registrable domain is site.example.  See Section 8.9 for security
     considerations.

     The term "request", as well as a request's "client", "current url",
     "method", "target browsing context", and "url list", are defined in
     [FETCH].

     The term "non-HTTP APIs" refers to non-HTTP mechanisms used to set
     and retrieve cookies, such as a web browser API that exposes cookies
     to scripts.

     The term "top-level navigation" refers to a navigation of a top-level
     traversable.

  2.4.  Name Resolution System

     While this document does not strictly prescribe any specific name
     resolution system for use with cookies it does require that the
     system uses only [USASCII] characters or uses an ASCII-compatible
     encoding (ACE).  As the Domain Name System (DNS) is a typical and
     conventional example this document will reference name resolution in
     terms of DNS.

     Name resolution systems that directly expose non-ASCII characters,
     such as Unicode, are out of scope of this document.

  3.  Overview

     This section outlines a way for an origin server to send state
     information to a user agent and for the user agent to return the
     state information to the origin server.

     To store state, the origin server includes a Set-Cookie header field
     in an HTTP response.  In subsequent requests, the user agent returns
     a Cookie request header field to the origin server.  The Cookie
     header field contains cookies the user agent received in previous
     Set-Cookie header fields.  The origin server is free to ignore the
     Cookie header field or use its contents for an application-defined
     purpose.







  Bingler, et al.            Expires 4 June 2026                  [Page 7]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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
     [HTTP]) 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.

     User agents MAY ignore Set-Cookie header fields based on response
     status codes or the user agent's cookie policy (see Section 5.3).

     Note: A cookie's octets MUST be processed as [USASCII] characters.
     While it's possible a non-HTTP API could pass a set-cookie-string
     with one or more non-[USASCII] characters, no attempt should be made
     to interpret these octets as anything other than [USASCII]
     characters.

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

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42






  Bingler, et al.            Expires 4 June 2026                  [Page 8]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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.

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42
     Set-Cookie: sid=31d4d96e407aad42

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42






  Bingler, et al.            Expires 4 June 2026                  [Page 9]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

  3.2.  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 spec changes,
     spec interpretations, and historical implementation differences.

     This section roughly divides implementers of the cookie spec 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.




  Bingler, et al.            Expires 4 June 2026                 [Page 10]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

     See Section 3.2.2.1 for more details on programming languages and
     software frameworks.

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

     See Section 3.2.2.1 for more details on programming languages and
     software frameworks.






  Bingler, et al.            Expires 4 June 2026                 [Page 11]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  3.2.2.1.  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
     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 syntax and semantics of a well-behaved
     profile of the Cookie and Set-Cookie header fields.

  4.1.  Set-Cookie Header

     The Set-Cookie HTTP response header field is used to send cookies
     from the server to the user agent.

  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 conforming to this profile MUST NOT
     send Set-Cookie header fields that deviate from the following
     grammar:




















  Bingler, et al.            Expires 4 June 2026                 [Page 12]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 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      = 1*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 UAs 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].





  Bingler, et al.            Expires 4 June 2026                 [Page 13]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 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.

     Per the grammar above, extension-av MUST NOT contain leading or
     trailing WSP characters as they will be interpreted as BWS and
     removed.

     The domain-value is a subdomain as defined by Section 3.5 of
     [RFC1034], and as enhanced by Section 2.1 of [RFC1123].  Thus,
     domain-value is a string of [USASCII] characters, such as an
     "A-label" as defined in Section 2.3.2.1 of [RFC5890].

     The portions of the set-cookie-string produced by the cookie-av term
     are known as attributes.  To maximize compatibility with user agents,
     servers MUST NOT produce two attributes with the same name in the
     same set-cookie-string.  (See Section 5.7 for how user agents handle
     this case.)

     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.x.: "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.6 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.









  Bingler, et al.            Expires 4 June 2026                 [Page 14]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  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.

     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 may adjust the specified date and is not required to
     retain the cookie until that date has passed.  In fact, user agents
     often evict cookies due to memory pressure or privacy concerns.

     The cookie's lifetime is based on the user agent's clock which may
     differ from the server's clock.  Servers MUST NOT depend on cookies
     being evicted exactly at the specified date and time of the server's
     clock.

  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 may adjust the specified duration and is not required to
     retain the cookie for that duration.  In fact, user agents often
     evict cookies due to memory pressure or privacy concerns.

     Note: Some existing user agents do not support the Max-Age attribute.
     User agents that do not support the Max-Age attribute ignore the
     attribute.



  Bingler, et al.            Expires 4 June 2026                 [Page 15]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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.  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.  If the server omits the
     Domain attribute, the user agent will return the cookie only to the
     origin server.

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

     Note: For security reasons, many user agents are configured to reject
     Domain attributes that correspond to "public suffixes".  For example,
     some user agents will reject Domain attributes of "com" or "co.uk".
     (See Section 5.7 for more information.)

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






  Bingler, et al.            Expires 4 June 2026                 [Page 16]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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 defined by the user agent).  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]) [HTTP]).

  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.

     Note that the HttpOnly attribute is independent of the Secure
     attribute: a cookie can have both the HttpOnly and the Secure
     attribute.

  4.1.2.7.  The SameSite Attribute

     The "SameSite" attribute limits the scope of the cookie such that it
     will only be attached to requests if those requests are same-site, as
     defined by the algorithm in Section 5.2.  For example, requests for
     https://site.example/sekrit-image will attach same-site cookies if
     and only if initiated from a context whose "site for cookies" is an
     origin with a scheme and registered domain of "https" and
     "site.example" respectively.

     If the "SameSite" attribute's value is "Strict", the cookie will only
     be sent along with "same-site" requests.  If the value is "Lax", the
     cookie will be sent with same-site requests, and with "cross-site"
     top-level navigations, as described in Section 5.6.7.1.  If the value
     is "None", the cookie will be sent with same-site and cross-site
     requests.  If the "SameSite" attribute's value is something other
     than these three known keywords, the attribute's value will be
     subject to a default enforcement mode that is equivalent to "Lax".
     If a user agent uses "Lax-allowing-unsafe" enforcement (See
     Section 5.6.7.2) then this default enforcement mode will instead be
     equivalent to "Lax-allowing-unsafe".







  Bingler, et al.            Expires 4 June 2026                 [Page 17]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     The "SameSite" attribute affects cookie creation as well as delivery.
     Cookies which assert "SameSite=Lax" or "SameSite=Strict" cannot be
     set in responses to cross-site subresource requests, or cross-site
     nested navigations.  They can be set along with any top-level
     navigation, cross-site or otherwise.

  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.

     The user agent requirements for the prefixes described below are
     detailed in Section 5.4.

     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.

     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 the cookie's host-only-flag is true, locking



  Bingler, et al.            Expires 4 June 2026                 [Page 18]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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 origin model 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.2.  Cookie Header

  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 [HTTP] 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 8192
     octets.  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.










  Bingler, et al.            Expires 4 June 2026                 [Page 19]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     Servers MUST be tolerant of multiple cookie headers.  For example, an
     HTTP/2 [RFC9113] or HTTP/3 [RFC9114] 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.

  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 Cookie and Set-Cookie header fields in
     sufficient detail that a user agent implementing these requirements
     precisely can interoperate with existing servers (even those that do
     not conform to the well-behaved profile described in Section 4).







  Bingler, et al.            Expires 4 June 2026                 [Page 20]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

     This section defines some algorithms used by user agents to process
     specific subcomponents of the Cookie and Set-Cookie header fields.

  5.1.1.  Dates

     The user agent MUST use an algorithm equivalent to the following
     algorithm to parse a cookie-date.  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.





  Bingler, et al.            Expires 4 June 2026                 [Page 21]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         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.

         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.  Abort this algorithm and fail to parse the cookie-date if:

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

         (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 this algorithm and fail to parse the cookie-
         date.



  Bingler, et al.            Expires 4 June 2026                 [Page 22]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     7.  Return the parsed-cookie-date as the result of this algorithm.

  5.1.2.  Canonicalized Host Names

     A canonicalized host name is the string generated by the following
     algorithm:

     1.  Convert the host name to a sequence of individual domain name
         labels.

     2.  All labels must be one of U-label, A-label, or Non-Reserved LDH
         (NR-LDH) label (see Section 2.3.1 of [RFC5890]).  If any label is
         not one of these then abort this algorithm and fail to
         canonicalize the host name.

     3.  Convert each U-label to an A-label (see Section 2.3.2.1 of
         [RFC5890]).

     4.  If any label is a Fake A-label then abort this algorithm and fail
         to canonicalize the host name.

     5.  Concatenate the resulting labels, separated by a %x2E (".")
         character.

  5.1.3.  Domain Matching

     Note: This algorithm expects that both inputs are canonicalized.

     A string domain-matches a given domain string if at least one of the
     following conditions hold:

     *  The domain string and the string are identical.  (Note that both
        the domain string and the string will have been canonicalized to
        lower case at this point.)

     *  All of the following conditions hold:

        -  The domain string is a suffix of the string.

        -  The last character of the string that is not included in the
           domain string is a %x2E (".") character.

        -  The string is a host name (i.e., not an IP address).

  5.1.4.  Paths and Path-Match

     The user agent MUST use an algorithm equivalent to the following
     algorithm to compute the default-path of a cookie:



  Bingler, et al.            Expires 4 June 2026                 [Page 23]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     1.  Let uri-path be the path portion of the request-uri if such a
         portion exists (and empty otherwise).

     2.  If the uri-path is empty or if the first character of the uri-
         path is not a %x2F ("/") character, output %x2F ("/") and skip
         the remaining steps.

     3.  If the uri-path contains no more than one %x2F ("/") character,
         output %x2F ("/") and skip the remaining step.

     4.  Output the characters of the uri-path from the first character up
         to, but not including, the right-most %x2F ("/").

     A request-path path-matches a given cookie-path if at least one of
     the following conditions holds:

     *  The cookie-path and the request-path are identical.

        Note that this differs from the rules in [RFC3986] for equivalence
        of the path component, and hence two equivalent paths can have
        different cookies.

     *  The cookie-path is a prefix of the request-path, and the last
        character of the cookie-path is %x2F ("/").

     *  The cookie-path is a prefix of the request-path, and the first
        character of the request-path that is not included in the cookie-
        path is a %x2F ("/") character.

  5.2.  "Same-site" and "cross-site" Requests

     Two origins are same-site if they satisfy the "same site" criteria
     defined in [SAMESITE].  A request is "same-site" if the following
     criteria are true:

     1.  The request is not the result of a reload navigation triggered
         through a user interface element (as defined by the user agent;
         e.g., a request triggered by the user clicking a refresh button
         on a toolbar).

     2.  The request's current url's origin is same-site with the
         request's client's "site for cookies" (which is an origin), or if
         the request has no client or the request's client is null.

     Requests which are the result of a reload navigation triggered
     through a user interface element are same-site if the reloaded
     document was originally navigated to via a same-site request.  A
     request that is not "same-site" is instead "cross-site".



  Bingler, et al.            Expires 4 June 2026                 [Page 24]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     The request's client's "site for cookies" is calculated depending
     upon its client's type, as described in the following subsections:

  5.2.1.  Document-based requests

     The URI displayed in a user agent's address bar is the only security
     context directly exposed to users, and therefore the only signal
     users can reasonably rely upon to determine whether or not they trust
     a particular website.  The origin of that URI represents the context
     in which a user most likely believes themselves to be interacting.
     This origin, the top-level traversable's active document's origin, is
     defined as the "top-level origin".

     For a document displayed in a top-level traversable, the document's
     "site for cookies" is the top-level origin.

     For container documents, the origins of each of a document's ancestor
     navigables' active documents must be audited in order to account for
     the "multiple-nested scenarios" described in Section 4 of [RFC7034].
     A document's "site for cookies" is the top-level origin if and only
     if the top-level origin is same-site with the document's origin, and
     with each of the document's ancestor documents' origins.  Otherwise
     its "site for cookies" is an origin set to an opaque origin.

     Given a Document (document), the following algorithm returns its
     "site for cookies":

     1.  Let top-document be the active document in document's navigable's
         top-level traversable.

     2.  Let top-origin be the origin of top-document's URI if top-
         document's sandboxed origin browsing context flag is set, and
         top-document's origin otherwise.

     3.  Let documents be a list consisting of the active documents of
         document's inclusive ancestor navigables.

     4.  For each item in documents:

         1.  Let origin be the origin of item's URI if item's sandboxed
             origin browsing context flag is set, and item's origin
             otherwise.

         2.  If origin is not same-site with top-origin, return an origin
             set to an opaque origin.

     5.  Return top-origin.




  Bingler, et al.            Expires 4 June 2026                 [Page 25]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     Note: This algorithm only applies when the entire chain of documents
     from top-document to document are all active.

  5.2.2.  Worker-based requests

     Worker-driven requests aren't as clear-cut as document-driven
     requests, as there isn't a clear link between a top-level traversable
     and a worker.  This is especially true for Service Workers
     [SERVICE-WORKERS], which may execute code in the background, without
     any document visible at all.

  5.2.2.1.  Dedicated and Shared Workers

     Dedicated workers are simple, as each dedicated worker is bound to
     one and only one document.  The worker's "site for cookies" is the
     document's "site for cookies" if the worker's origin is same-site
     with the document's "site for cookies", otherwise its "site for
     cookies" is an origin set to an opaque origin.

     Shared workers may be bound to multiple documents at once.  As it is
     quite possible for those documents to have distinct "site for
     cookies" values, the worker's "site for cookies" will be an origin
     set to an opaque origin in cases where the values are not all same-
     site with the worker's origin, and the worker's origin in cases where
     the values agree.

     Given a WorkerGlobalScope (worker), the following algorithm returns
     its "site for cookies":

     1.  Let site be worker's origin.

     2.  For each document in worker's Documents:

         1.  Let document-site be document's "site for cookies" (as
             defined in Section 5.2.1).

         2.  If document-site is not same-site with site, return an origin
             set to an opaque origin.

     3.  Return site.

  5.2.2.2.  Service Workers

     Service Workers are more complicated, as they act as a completely
     separate execution context with only tangential relationship to the
     Document which registered them.





  Bingler, et al.            Expires 4 June 2026                 [Page 26]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     How user agents handle Service Workers may differ, but user agents
     SHOULD match the [SERVICE-WORKERS] specification.

  5.3.  Ignoring Set-Cookie Header Fields

     User agents MAY ignore Set-Cookie header fields contained in
     responses with 100-level status codes or based on its cookie policy
     (see Section 7.2).

     All other Set-Cookie header fields SHOULD be processed according to
     Section 5.6.  That is, 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
     unless ignored according to the user agent's cookie policy.

  5.4.  Cookie Name Prefixes

     User agents' requirements for cookie name prefixes differ slightly
     from servers' (Section 4.1.3) in that UAs MUST match the prefix
     string case-insensitively.

     The normative requirements for the prefixes are detailed in the
     storage model algorithm defined in Section 5.7.

     This is because some servers will process cookies case-insensitively,
     resulting in them unintentionally miscapitalizing and accepting
     miscapitalized prefixes.

     For example, if a server sends the following Set-Cookie header field

     Set-Cookie: __SECURE-SID=12345

     to a UA which checks prefixes case-sensitively it will accept this
     cookie and the server would incorrectly believe the cookie is subject
     the same guarantees as one spelled __Secure-.

     Additionally the server is vulnerable to an attacker that
     purposefully miscapitalizes a cookie in order to impersonate a
     prefixed cookie.  For example, a site already has a cookie __Secure-
     SID=12345 and by some means an attacker sends the following Set-
     Cookie header field for the site to a UA which checks prefixes case-
     sensitively.

     Set-Cookie: __SeCuRe-SID=evil

     The next time a user visits the site the UA will send both cookies:

     Cookie: __Secure-SID=12345; __SeCuRe-SID=evil



  Bingler, et al.            Expires 4 June 2026                 [Page 27]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     The server, being case-insensitive, won't be able to tell the
     difference between the two cookies allowing the attacker to
     compromise the site.

     To prevent these issues, UAs MUST match cookie name prefixes case-
     insensitively.

     Note: Cookies with different names are still considered separate by
     UAs.  So both __Secure-foo=bar and __secure-foo=baz can exist as
     distinct cookies simultaneously and both would have the requirements
     of the __Secure- prefix applied.

     The following are examples of Set-Cookie header fields that would be
     rejected by a conformant user agent.

     Set-Cookie: __Secure-SID=12345; Domain=site.example
     Set-Cookie: __secure-SID=12345; Domain=site.example
     Set-Cookie: __SECURE-SID=12345; Domain=site.example
     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=/
     Set-Cookie: __host-SID=12345; Secure; Domain=site.example; Path=/
     Set-Cookie: __HOST-SID=12345; Secure; Domain=site.example; Path=/

     Whereas the following Set-Cookie header fields would be accepted if
     set from a secure origin.

     Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure
     Set-Cookie: __secure-SID=12345; Domain=site.example; Secure
     Set-Cookie: __SECURE-SID=12345; Domain=site.example; Secure
     Set-Cookie: __Host-SID=12345; Secure; Path=/
     Set-Cookie: __host-SID=12345; Secure; Path=/
     Set-Cookie: __HOST-SID=12345; Secure; Path=/

  5.5.  Cookie Lifetime Limits

     When processing cookies with a specified lifetime, either with the
     Expires or with the Max-Age attribute, the user agent MUST limit the
     maximum age of the cookie.  The limit SHOULD NOT be greater than 400
     days (34560000 seconds) in the future.  The RECOMMENDED limit is 400
     days in the future, but the user agent MAY adjust the limit (see
     Section 7.2).  Expires or Max-Age attributes that specify a lifetime
     longer than the limit MUST be reduced to the limit.






  Bingler, et al.            Expires 4 June 2026                 [Page 28]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  5.6.  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 (see Section 5.3).

     If the user agent does not ignore the Set-Cookie header field in its
     entirety, the user agent MUST parse the field-value of the Set-Cookie
     header field as a set-cookie-string (defined below).

     Note: The algorithm below is more permissive than the grammar in
     Section 4.1.  For example, the algorithm allows cookie-name to be
     comprised of cookie-octets instead of being a token as specified in
     Section 4.1 and the algorithm accommodates some characters that are
     not cookie-octets according to the grammar in Section 4.1.  In
     addition, the algorithm below also strips leading and trailing
     whitespace from the cookie name and value (but maintains internal
     whitespace), whereas the grammar in Section 4.1 forbids whitespace in
     these positions.  User agents use this algorithm so as to
     interoperate with servers that do not follow the recommendations in
     Section 4.

     Note: As set-cookie-string may originate from a non-HTTP API, it is
     not guaranteed to be free of CTL characters, so this algorithm
     handles them explicitly.  Horizontal tab (%x09) is excluded from the
     CTL characters that lead to set-cookie-string rejection, as it is
     considered whitespace, which is handled separately.

     Note: The set-cookie-string may contain octet sequences that appear
     percent-encoded as per Section 2.1 of [RFC3986].  However, a user
     agent MUST NOT decode these sequences and instead parse the
     individual octets as specified in this algorithm.

     A user agent MUST use an algorithm equivalent to the following
     algorithm to parse a set-cookie-string:

     1.  If the set-cookie-string contains a %x00-08 / %x0A-1F / %x7F
         character (CTL characters excluding HTAB): Abort this algorithm
         and ignore the set-cookie-string entirely.

     2.  If the set-cookie-string contains a %x3B (";") character:

         1.  The name-value-pair string consists of the characters up to,
             but not including, the first %x3B (";"), and the unparsed-
             attributes consist of the remainder of the set-cookie-string
             (including the %x3B (";") in question).

         Otherwise:



  Bingler, et al.            Expires 4 June 2026                 [Page 29]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         1.  The name-value-pair string consists of all the characters
             contained in the set-cookie-string, and the unparsed-
             attributes is the empty string.

     3.  If the name-value-pair string lacks a %x3D ("=") character, then
         the name string is empty, and the value string is the value of
         name-value-pair.

         Otherwise, the (possibly empty) name string consists of the
         characters up to, but not including, the first %x3D ("=")
         character, and the (possibly empty) value string consists of the
         characters after the first %x3D ("=") character.

     4.  Remove any leading or trailing WSP characters from the name
         string and the value string.

     5.  If the sum of the lengths of the name string and the value string
         is more than 4096 octets, abort this algorithm and ignore the
         set-cookie-string entirely.

     6.  The cookie-name is the name string, and the cookie-value is the
         value string.

     The user agent MUST use an algorithm equivalent to the following
     algorithm to parse the unparsed-attributes:

     1.  If the unparsed-attributes string is empty, skip the rest of
         these steps.

     2.  Discard the first character of the unparsed-attributes (which
         will be a %x3B (";") character).

     3.  If the remaining unparsed-attributes contains a %x3B (";")
         character:

         1.  Consume the characters of the unparsed-attributes up to, but
             not including, the first %x3B (";") character.

         Otherwise:

         1.  Consume the remainder of the unparsed-attributes.

         Let the cookie-av string be the characters consumed in this step;
         unparsed-attributes now contains any remaining characters.

     4.  If the cookie-av string contains a %x3D ("=") character:





  Bingler, et al.            Expires 4 June 2026                 [Page 30]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         1.  The (possibly empty) attribute-name string consists of the
             characters up to, but not including, the first %x3D ("=")
             character, and the (possibly empty) attribute-value string
             consists of the characters after the first %x3D ("=")
             character.

         Otherwise:

         1.  The attribute-name string consists of the entire cookie-av
             string, and the attribute-value string is empty.

     5.  Remove any leading or trailing WSP characters from the attribute-
         name string and the attribute-value string.

     6.  If the attribute-value is longer than 1024 octets, ignore the
         cookie-av string and return to Step 1 of this algorithm.

     7.  Process the attribute-name and attribute-value according to the
         requirements in the following subsections.  (Notice that
         attributes with unrecognized attribute-names are ignored.)

     8.  Return to Step 1 of this algorithm.

     When the user agent finishes parsing the set-cookie-string, the user
     agent is said to "receive a cookie" from the request-uri with name
     cookie-name, value cookie-value, and attributes cookie-attribute-
     list.  (See Section 5.7 for additional requirements triggered by
     receiving a cookie.)

  5.6.1.  The Expires Attribute

     If the attribute-name case-insensitively matches the string
     "Expires", the user agent MUST process the cookie-av as follows.

     1.  Let the expiry-time be the result of parsing the attribute-value
         as cookie-date (see Section 5.1.1).

     2.  If the attribute-value failed to parse as a cookie date, ignore
         the cookie-av.

     3.  Let cookie-age-limit be the maximum age of the cookie (which
         SHOULD be 400 days in the future or sooner, see Section 5.5).

     4.  If the expiry-time is more than cookie-age-limit, the user agent
         MUST set the expiry time to cookie-age-limit in seconds.






  Bingler, et al.            Expires 4 June 2026                 [Page 31]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     5.  If the expiry-time is earlier than the earliest date the user
         agent can represent, the user agent MAY replace the expiry-time
         with the earliest representable date.

     6.  Append an attribute to the cookie-attribute-list with an
         attribute-name of Expires and an attribute-value of expiry-time.

  5.6.2.  The Max-Age Attribute

     If the attribute-name case-insensitively matches the string "Max-
     Age", the user agent MUST process the cookie-av as follows.

     1.  If the attribute-value is empty, ignore the cookie-av.

     2.  If the first character of the attribute-value is neither a DIGIT,
         nor a "-" character followed by a DIGIT, ignore the cookie-av.

     3.  If the remainder of attribute-value contains a non-DIGIT
         character, ignore the cookie-av.

     4.  Let delta-seconds be the attribute-value converted to a base 10
         integer.

     5.  Let cookie-age-limit be the maximum age of the cookie (which
         SHOULD be 400 days or less, see Section 5.5).

     6.  Set delta-seconds to the smaller of its present value and cookie-
         age-limit.

     7.  If delta-seconds is less than or equal to zero (0), let expiry-
         time be the earliest representable date and time.  Otherwise, let
         the expiry-time be the current date and time plus delta-seconds
         seconds.

     8.  Append an attribute to the cookie-attribute-list with an
         attribute-name of Max-Age and an attribute-value of expiry-time.

  5.6.3.  The Domain Attribute

     If the attribute-name case-insensitively matches the string "Domain",
     the user agent MUST process the cookie-av as follows.

     1.  Let cookie-domain be the attribute-value.

     2.  If cookie-domain starts with %x2E ("."), let cookie-domain be
         cookie-domain without its leading %x2E (".").

     3.  Convert the cookie-domain to lower case.



  Bingler, et al.            Expires 4 June 2026                 [Page 32]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     4.  Append an attribute to the cookie-attribute-list with an
         attribute-name of Domain and an attribute-value of cookie-domain.

  5.6.4.  The Path Attribute

     If the attribute-name case-insensitively matches the string "Path",
     the user agent MUST process the cookie-av as follows.

     1.  If the attribute-value is empty or if the first character of the
         attribute-value is not %x2F ("/"):

         1.  Let cookie-path be the default-path.

         Otherwise:

         1.  Let cookie-path be the attribute-value.

     2.  Append an attribute to the cookie-attribute-list with an
         attribute-name of Path and an attribute-value of cookie-path.

  5.6.5.  The Secure Attribute

     If the attribute-name case-insensitively matches the string "Secure",
     the user agent MUST append an attribute to the cookie-attribute-list
     with an attribute-name of Secure and an empty attribute-value.

  5.6.6.  The HttpOnly Attribute

     If the attribute-name case-insensitively matches the string
     "HttpOnly", the user agent MUST append an attribute to the cookie-
     attribute-list with an attribute-name of HttpOnly and an empty
     attribute-value.

  5.6.7.  The SameSite Attribute

     If the attribute-name case-insensitively matches the string
     "SameSite", the user agent MUST process the cookie-av as follows:

     1.  Let enforcement be "Default".

     2.  If cookie-av's attribute-value is a case-insensitive match for
         "None", set enforcement to "None".

     3.  If cookie-av's attribute-value is a case-insensitive match for
         "Strict", set enforcement to "Strict".

     4.  If cookie-av's attribute-value is a case-insensitive match for
         "Lax", set enforcement to "Lax".



  Bingler, et al.            Expires 4 June 2026                 [Page 33]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     5.  Append an attribute to the cookie-attribute-list with an
         attribute-name of "SameSite" and an attribute-value of
         enforcement.

  5.6.7.1.  "Strict" and "Lax" enforcement

     Same-site cookies in "Strict" enforcement mode will not be sent along
     with top-level navigations which are triggered from a cross-site
     document context.  As discussed in Section 8.8.2, this might or might
     not be compatible with existing session management systems.  In the
     interests of providing a drop-in mechanism that mitigates the risk of
     CSRF attacks, developers may set the SameSite attribute in a "Lax"
     enforcement mode that carves out an exception which sends same-site
     cookies along with cross-site requests if and only if they are top-
     level navigations which use a "safe" (in the [HTTP] sense) HTTP
     method.  (Note that a request's method may be changed from POST to
     GET for some redirects (see Sections 15.4.2 and 15.4.3 of [HTTP]); in
     these cases, a request's "safe"ness is determined based on the method
     of the current redirect hop.)

     Lax enforcement provides reasonable defense in depth against CSRF
     attacks that rely on unsafe HTTP methods (like POST), but does not
     offer a robust defense against CSRF as a general category of attack:

     1.  Attackers can still pop up new windows or trigger top-level
         navigations in order to create a "same-site" request (as
         described in Section 5.2.1), which is only a speedbump along the
         road to exploitation.

     2.  Features like <link rel='prerender'> [prerendering] can be
         exploited to create "same-site" requests without the risk of user
         detection.

     Developers can more completely mitigate CSRF through a session
     management mechanism such as that described in Section 8.8.2.

  5.6.7.2.  "Lax-Allowing-Unsafe" enforcement

     As discussed in Section 8.8.6, compatibility concerns may necessitate
     the use of a "Lax-allowing-unsafe" enforcement mode that allows
     cookies to be sent with a cross-site HTTP request if and only if it
     is a top-level request, regardless of request method.  That is, the
     "Lax-allowing-unsafe" enforcement mode waives the requirement for the
     HTTP request's method to be "safe" in the SameSite enforcement step
     of the retrieval algorithm in Section 5.8.3.  (All cookies,
     regardless of SameSite enforcement mode, may be set for top-level
     navigations, regardless of HTTP request method, as specified in
     Section 5.7.)



  Bingler, et al.            Expires 4 June 2026                 [Page 34]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     "Lax-allowing-unsafe" is not a distinct value of the SameSite
     attribute.  Rather, user agents MAY apply "Lax-allowing-unsafe"
     enforcement only to cookies that did not explicitly specify a
     SameSite attribute (i.e., those whose same-site-flag was set to
     "Default" by default).  To limit the scope of this compatibility
     mode, user agents which apply "Lax-allowing-unsafe" enforcement
     SHOULD restrict the enforcement to cookies which were created
     recently.  Deployment experience has shown a cookie age of 2 minutes
     or less to be a reasonable limit.

     If the user agent uses "Lax-allowing-unsafe" enforcement, it MUST
     apply the following modification to the retrieval algorithm defined
     in Section 5.8.3:

     Replace the condition in the penultimate bullet point of step 1 of
     the retrieval algorithm reading

      * The HTTP request associated with the retrieval uses a "safe"
        method.

     with

      * At least one of the following is true:

        1.  The HTTP request associated with the retrieval uses a "safe"
            method.

        2.  The cookie's same-site-flag is "Default" and the amount of
            time elapsed since the cookie's creation-time is at most a
            duration of the user agent's choosing.

  5.7.  Storage Model

     The user agent stores the following fields about each cookie: name,
     value, expiry-time, domain, path, creation-time, last-access-time,
     persistent-flag, host-only-flag, secure-only-flag, http-only-flag,
     and same-site-flag.

     When the user agent "receives a cookie" from a request-uri with name
     cookie-name, value cookie-value, and attributes cookie-attribute-
     list, the user agent MUST process the cookie as follows:

     1.   A user agent MAY ignore a received cookie in its entirety.  See
          Section 5.3.

     2.   If cookie-name is empty and cookie-value is empty, abort this
          algorithm and ignore the cookie entirely.




  Bingler, et al.            Expires 4 June 2026                 [Page 35]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     3.   If the cookie-name or the cookie-value contains a %x00-08 /
          %x0A-1F / %x7F character (CTL characters excluding HTAB), abort
          this algorithm and ignore the cookie entirely.

     4.   If the sum of the lengths of cookie-name and cookie-value is
          more than 4096 octets, abort this algorithm and ignore the
          cookie entirely.

     5.   Create a new cookie with name cookie-name, value cookie-value.
          Set the creation-time and the last-access-time to the current
          date and time.

     6.   If the cookie-attribute-list contains an attribute with an
          attribute-name of "Max-Age":

          1.  Set the cookie's persistent-flag to true.

          2.  Set the cookie's expiry-time to attribute-value of the last
              attribute in the cookie-attribute-list with an attribute-
              name of "Max-Age".

          Otherwise, if the cookie-attribute-list contains an attribute
          with an attribute-name of "Expires" (and does not contain an
          attribute with an attribute-name of "Max-Age"):

          1.  Set the cookie's persistent-flag to true.

          2.  Set the cookie's expiry-time to attribute-value of the last
              attribute in the cookie-attribute-list with an attribute-
              name of "Expires".

          Otherwise:

          1.  Set the cookie's persistent-flag to false.

          2.  Set the cookie's expiry-time to the latest representable
              date.

     7.   If the cookie-attribute-list contains an attribute with an
          attribute-name of "Domain":

          1.  Let the domain-attribute be the attribute-value of the last
              attribute in the cookie-attribute-list with both an
              attribute-name of "Domain" and an attribute-value whose
              length is no more than 1024 octets.  (Note that a leading
              %x2E ("."), if present, is ignored even though that
              character is not permitted.)




  Bingler, et al.            Expires 4 June 2026                 [Page 36]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


          Otherwise:

          1.  Let the domain-attribute be the empty string.

     8.   If the domain-attribute contains a character that is not in
          CHAR, abort this algorithm and ignore the cookie entirely.

     9.   If the user agent is configured to reject "public suffixes" and
          the domain-attribute is a public suffix:

          1.  Let request-host-canonical be the canonicalized request-
              host.

          2.  If request-host fails to be canonicalized then abort this
              algorithm and ignore the cookie entirely.

          3.  If the domain-attribute is identical to the request-host-
              canonical:

              1.  Let the domain-attribute be the empty string.

              Otherwise:

              1.  Abort this algorithm and ignore the cookie entirely.

          Note: This step prevents attacker.example from disrupting the
          integrity of site.example by setting a cookie with a Domain
          attribute of "example".

     10.  If the domain-attribute is non-empty:

          1.  If request-host-canonical does not domain-match (see
              Section 5.1.3) the domain-attribute:

              1.  Abort this algorithm and ignore the cookie entirely.

              Otherwise:

              1.  Set the cookie's host-only-flag to false.

              2.  Set the cookie's domain to the domain-attribute.

          Otherwise:

          1.  Set the cookie's host-only-flag to true.

          2.  Set the cookie's domain to request-host-canonical.




  Bingler, et al.            Expires 4 June 2026                 [Page 37]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     11.  If the cookie-attribute-list contains an attribute with an
          attribute-name of "Path", set the cookie's path to attribute-
          value of the last attribute in the cookie-attribute-list with
          both an attribute-name of "Path" and an attribute-value whose
          length is no more than 1024 octets.  Otherwise, set the cookie's
          path to the default-path of the request-uri.

     12.  If the cookie-attribute-list contains an attribute with an
          attribute-name of "Secure", set the cookie's secure-only-flag to
          true.  Otherwise, set the cookie's secure-only-flag to false.

     13.  If the request-uri does not denote a "secure" connection (as
          defined by the user agent), and the cookie's secure-only-flag is
          true, then abort these steps and ignore the cookie entirely.

     14.  If the cookie-attribute-list contains an attribute with an
          attribute-name of "HttpOnly", set the cookie's http-only-flag to
          true.  Otherwise, set the cookie's http-only-flag to false.

     15.  If the cookie was received from a "non-HTTP" API and the
          cookie's http-only-flag is true, abort this algorithm and ignore
          the cookie entirely.

     16.  If the cookie's secure-only-flag is false, and the request-uri
          does not denote a "secure" connection, then abort this algorithm
          and ignore the cookie entirely if the cookie store contains one
          or more cookies that meet all of the following criteria:

          1.  Their name matches the name of the newly-created cookie.

          2.  Their secure-only-flag is true.

          3.  Their domain domain-matches (see Section 5.1.3) the domain
              of the newly-created cookie, or vice-versa.

          4.  The path of the newly-created cookie path-matches the path
              of the existing cookie.

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






  Bingler, et al.            Expires 4 June 2026                 [Page 38]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     17.  If the cookie-attribute-list contains an attribute with an
          attribute-name of "SameSite", and an attribute-value of
          "Strict", "Lax", or "None", set the cookie's same-site-flag to
          the attribute-value of the last attribute in the cookie-
          attribute-list with an attribute-name of "SameSite".  Otherwise,
          set the cookie's same-site-flag to "Default".

     18.  If the cookie's same-site-flag is not "None":

          1.  If the cookie was received from a "non-HTTP" API, and the
              API was called from a navigable's active document whose
              "site for cookies" is not same-site with the top-level
              origin, then abort this algorithm and ignore the newly
              created cookie entirely.

          2.  If the cookie was received from a "same-site" request (as
              defined in Section 5.2), skip the remaining substeps and
              continue processing the cookie.

          3.  If the cookie was received from a request which is
              navigating a top-level traversable [HTML] (e.g. if the
              request's "reserved client" is either null or an environment
              whose "target browsing context"'s navigable is a top-level
              traversable), skip the remaining substeps and continue
              processing the cookie.

              Note: Top-level navigations can create a cookie with any
              SameSite value, even if the new cookie wouldn't have been
              sent along with the request had it already existed prior to
              the navigation.

          4.  Abort this algorithm and ignore the newly created cookie
              entirely.

     19.  If the cookie's "same-site-flag" is "None", abort this algorithm
          and ignore the cookie entirely unless the cookie's secure-only-
          flag is true.

     20.  If the cookie-name begins with a case-insensitive match for the
          string "__Secure-", abort this algorithm and ignore the cookie
          entirely unless the cookie's secure-only-flag is true.

     21.  If the cookie-name begins with a case-insensitive match for the
          string "__Host-", abort this algorithm and ignore the cookie
          entirely unless the cookie meets all the following criteria:

          1.  The cookie's secure-only-flag is true.




  Bingler, et al.            Expires 4 June 2026                 [Page 39]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


          2.  The cookie's host-only-flag is true.

          3.  The cookie-attribute-list contains an attribute with an
              attribute-name of "Path", and the cookie's path is /.

     22.  If the cookie-name is empty and either of the following
          conditions are true, abort this algorithm and ignore the cookie
          entirely:

          *  the cookie-value begins with a case-insensitive match for the
             string "__Secure-"

          *  the cookie-value begins with a case-insensitive match for the
             string "__Host-"

     23.  If the cookie store contains a cookie with the same name,
          domain, host-only-flag, and path as the newly-created cookie:

          1.  Let old-cookie be the existing cookie with the same name,
              domain, host-only-flag, and path as the newly-created
              cookie.  (Notice that this algorithm maintains the invariant
              that there is at most one such cookie.)

          2.  If the newly-created cookie was received from a "non-HTTP"
              API and the old-cookie's http-only-flag is true, abort this
              algorithm and ignore the newly created cookie entirely.

          3.  Update the creation-time of the newly-created cookie to
              match the creation-time of the old-cookie.

          4.  Remove the old-cookie from the cookie store.

     24.  Insert the newly-created cookie into the cookie store.

     A cookie is "expired" if the cookie has an expiry date in the past.

     The user agent MUST evict all expired cookies from the cookie store
     if, at any time, an expired cookie exists in the cookie store.

     At any time, the user agent MAY "remove excess cookies" from the
     cookie store if the number of cookies sharing a domain field exceeds
     some implementation-defined upper bound (such as 50 cookies).

     At any time, the user agent MAY "remove excess cookies" from the
     cookie store if the cookie store exceeds some predetermined upper
     bound (such as 3000 cookies).





  Bingler, et al.            Expires 4 June 2026                 [Page 40]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     When the user agent removes excess cookies from the cookie store, the
     user agent MUST evict cookies in the following priority order:

     1.  Expired cookies.

     2.  Cookies whose secure-only-flag is false, and which share a domain
         field with more than a predetermined number of other cookies.

     3.  Cookies that share a domain field with more than a predetermined
         number of other cookies.

     4.  All cookies.

     If two cookies have the same removal priority, the user agent MUST
     evict the cookie with the earliest last-access-time first.

     When "the current session is over" (as defined by the user agent),
     the user agent MUST remove from the cookie store all cookies with the
     persistent-flag set to false.

  5.8.  Retrieval Model

     This section defines how cookies are retrieved from a cookie store in
     the form of a cookie-string.  A "retrieval" is any event which
     requires generating a cookie-string.  For example, a retrieval may
     occur in order to build a Cookie header field for an HTTP request, or
     may be required in order to return a cookie-string from a call to a
     "non-HTTP" API that provides access to cookies.  A retrieval has an
     associated URI, same-site status, and type, which are defined below
     depending on the type of retrieval.

  5.8.1.  The Cookie Header Field

     The user agent includes stored cookies in the Cookie HTTP request
     header field.

     A user agent MAY omit the Cookie header field in its entirety.  For
     example, the user agent might wish to block sending cookies during
     "third-party" requests (see Section 7.1).

     If the user agent does attach a Cookie header field to an HTTP
     request, the user agent MUST generate a single cookie-string and the
     user agent MUST compute the cookie-string following the algorithm
     defined in Section 5.8.3, where the retrieval's URI is the request-
     uri, the retrieval's same-site status is computed for the HTTP
     request as defined in Section 5.2, and the retrieval's type is
     "HTTP".




  Bingler, et al.            Expires 4 June 2026                 [Page 41]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

  5.8.2.  Non-HTTP APIs

     The user agent MAY implement "non-HTTP" APIs that can be used to
     access stored cookies.

     A user agent MAY return an empty cookie-string in certain contexts,
     such as when a retrieval occurs within a third-party context (see
     Section 7.1).

     If a user agent does return cookies for a given call to a "non-HTTP"
     API with an associated Document, then the user agent MUST compute the
     cookie-string following the algorithm defined in Section 5.8.3, where
     the retrieval's URI is defined by the caller (see
     [DOM-DOCUMENT-COOKIE]), the retrieval's same-site status is "same-
     site" if the Document's "site for cookies" is same-site with the top-
     level origin as defined in Section 5.2.1 (otherwise it is "cross-
     site"), and the retrieval's type is "non-HTTP".

  5.8.3.  Retrieval Algorithm

     Given a cookie store and a retrieval, the following algorithm returns
     a cookie-string from a given cookie store.

     1.  Let retrieval-host-canonical be the canonicalized host of the
         retrieval's URI.

     2.  If the host of the retrieval's URI fails to be canonicalized then
         abort this algorithm.

     3.  Let cookie-list be the set of cookies from the cookie store that
         meets all of the following requirements:

         *  Either:

            -  The cookie's host-only-flag is true and retrieval-host-
               canonical is identical to the cookie's domain.

            Or:






  Bingler, et al.            Expires 4 June 2026                 [Page 42]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


            -  The cookie's host-only-flag is false and retrieval-host-
               canonical domain-matches (see Section 5.1.3) the cookie's
               domain.

            -  The cookie's domain is not a public suffix, for user agents
               configured to reject "public suffixes".

            Note: It's possible that the public suffix list was changed
            since the cookie was created.  If this change resulted in the
            cookie's domain becoming a public suffix then that cookie
            would have been rejected during creation if it had been
            created now.  (See Section 5.7 step 9).

         *  The retrieval's URI's path path-matches the cookie's path.

         *  If the cookie's secure-only-flag is true, then the retrieval's
            URI must denote a "secure" connection (as defined by the user
            agent).

            Note: The notion of a "secure" connection is not defined by
            this document.  Typically, user agents consider a connection
            secure if the connection makes use of transport-layer
            security, such as SSL or TLS [TLS13], or if the host is
            trusted.  For example, most user agents consider "https" to be
            a scheme that denotes a secure protocol and "localhost" to be
            trusted host.

         *  If the cookie's http-only-flag is true, then exclude the
            cookie if the retrieval's type is "non-HTTP".

         *  If the cookie's same-site-flag is not "None" and the
            retrieval's same-site status is "cross-site", then exclude the
            cookie unless all of the following conditions are met:

            -  The retrieval's type is "HTTP".

            -  The same-site-flag is "Lax" or "Default".

            -  The HTTP request associated with the retrieval uses a
               "safe" method.

            -  The target browsing context of the HTTP request associated
               with the retrieval is the active browsing context or a top-
               level traversable.

     4.  The user agent SHOULD sort the cookie-list in the following
         order:




  Bingler, et al.            Expires 4 June 2026                 [Page 43]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


         *  Cookies with longer paths are listed before cookies with
            shorter paths.

         *  Among cookies that have equal-length path fields, cookies with
            earlier creation-times are listed before cookies with later
            creation-times.

         Note: Not all user agents sort the cookie-list in this order, but
         this order reflects common practice when this document was
         written, and, historically, there have been servers that
         (erroneously) depended on this order.

     5.  Update the last-access-time of each cookie in the cookie-list to
         the current date and time.

     6.  Serialize the cookie-list into a cookie-string by processing each
         cookie in the cookie-list in order:

         1.  If the cookies' name is not empty, output the cookie's name
             followed by the %x3D ("=") character.

         2.  If the cookies' value is not empty, output the cookie's
             value.

         3.  If the cookie was not the last cookie in the cookie-list,
             output the characters %x3B and %x20 ("; ").

  6.  Implementation Considerations

  6.1.  Limits

     Practical user agent implementations have limits on the number and
     size of cookies that they can store.  General-use user agents SHOULD
     provide each of the following minimum capabilities:

     *  At least 50 cookies per domain.

     *  At least 3000 cookies total.

     User agents MAY limit the maximum number of cookies they store, and
     may evict any cookie at any time (whether at the request of the user
     or due to implementation limitations).

     Note that a limit on the maximum number of cookies also limits the
     total size of the stored cookies, due to the length limits which MUST
     be enforced in Section 5.6.





  Bingler, et al.            Expires 4 June 2026                 [Page 44]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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
     handling 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,

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



  Bingler, et al.            Expires 4 June 2026                 [Page 45]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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.

     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.






  Bingler, et al.            Expires 4 June 2026                 [Page 46]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

     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 5.5), and the number of cookies per domain
     or in total.

     The recommended cookie expiry upper limit is 400 days.  User agents
     may set a lower limit to enforce shorter data retention timelines, or
     set the limit higher to support longer retention when appropriate
     (e.g., server-to-server communication over HTTPS).

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

     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 the persistent-flag were
     set to false.  Some popular user agents expose this functionality via
     "private browsing" mode [Aggarwal2010].



  Bingler, et al.            Expires 4 June 2026                 [Page 47]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  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, offers a
     significant layer of defense against network attacks on cookies.
     However, it is insufficient in fully preventing a networking attacker
     from obtaining or altering a victim's cookies because of inherent
     vulnerabilities in the cookie protocol itself (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.  This
     means that a cookie needs to explicitly specify any protective
     attributes.  For example, the cookie:

     Set-Cookie: a=b

     doesn't specify the Secure attribute and will therefore be accessible
     on both secure and insecure connections, regardless of the original
     connection type it was created on.  This behavior could allow an
     attacker to read or modify the cookie.











  Bingler, et al.            Expires 4 June 2026                 [Page 48]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  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.

     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.

     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.





  Bingler, et al.            Expires 4 June 2026                 [Page 49]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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.

     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.





  Bingler, et al.            Expires 4 June 2026                 [Page 50]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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











  Bingler, et al.            Expires 4 June 2026                 [Page 51]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     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.

     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

  8.8.1.  Defense in depth

     "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 or abuse of page
     redirections.



  Bingler, et al.            Expires 4 June 2026                 [Page 52]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     Understanding how and when a request is considered same-site is also
     important in order to properly design a site for SameSite cookies.
     For example, if a cross-site top-level request is made to a sensitive
     page that request will be considered cross-site and SameSite=Strict
     cookies won't be sent; that page's sub-resources requests, however,
     are same-site and would receive SameSite=Strict cookies.  Sites can
     avoid inadvertently allowing access to these sub-resources by
     returning an error for the initial page request if it doesn't include
     the appropriate cookies.

     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.

     Additionally, client-side techniques such as those described in
     [app-isolation] may also prove effective against CSRF, and are
     certainly worth exploring in combination with "SameSite" cookies.

  8.8.2.  Top-level Navigations

     Setting the SameSite attribute in "strict" mode provides robust
     defense in depth against CSRF attacks, but has the potential to
     confuse users unless sites' developers carefully ensure that their
     cookie-based session management systems deal reasonably well with
     top-level navigations.

     Consider the scenario in which a user reads their email at MegaCorp
     Inc's webmail provider https://site.example/. They might expect that
     clicking on an emailed link to https://projects.example/secret/
     project would show them the secret project that they're authorized to
     see, but if https://projects.example has marked their session cookies
     as SameSite=Strict, then this cross-site navigation won't send them
     along with the request. https://projects.example will render a 404
     error to avoid leaking secret information, and the user will be quite
     confused.

     Developers can avoid this confusion by adopting a session management
     system that relies on not one, but two cookies: one conceptually
     granting "read" access, another granting "write" access.  The latter
     could be marked as SameSite=Strict, and its absence would prompt a
     reauthentication step before executing any non-idempotent action.
     The former could be marked as SameSite=Lax, in order to allow users
     access to data via top-level navigation, or SameSite=None, to permit
     access in all contexts (including cross-site embedded contexts).







  Bingler, et al.            Expires 4 June 2026                 [Page 53]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  8.8.3.  Mashups and Widgets

     The Lax and Strict values for the SameSite attribute are
     inappropriate for some important use-cases.  In particular, note that
     content intended for embedding in cross-site contexts (social
     networking widgets or commenting services, for instance) will not
     have access to same-site cookies.  Cookies which are required in
     these situations should be marked with SameSite=None to allow access
     in cross-site contexts.

     Likewise, some forms of Single-Sign-On might require cookie-based
     authentication in a cross-site context; these mechanisms will not
     function as intended with same-site cookies and will also require
     SameSite=None.

  8.8.4.  Server-controlled

     SameSite cookies in and of themselves don't do anything to address
     the general privacy concerns outlined in Section 7.1 of [RFC6265].
     The "SameSite" attribute is set by the server, and serves to mitigate
     the risk of certain kinds of attacks that the server is worried
     about.  The user is not involved in this decision.  Moreover, a
     number of side-channels exist which could allow a server to link
     distinct requests even in the absence of cookies (for example,
     connection and/or socket pooling between same-site and cross-site
     requests).

  8.8.5.  Reload navigations

     Requests issued for reloads triggered through user interface elements
     (such as a refresh button on a toolbar) are same-site only if the
     reloaded document was originally navigated to via a same-site
     request.  This differs from the handling of other reload navigations,
     which are always same-site if top-level, since the source navigable's
     active document is precisely the document being reloaded.

     This special handling of reloads triggered through a user interface
     element avoids sending SameSite cookies on user-initiated reloads if
     they were withheld on the original navigation (i.e., if the initial
     navigation were cross-site).  If the reload navigation were instead
     considered same-site, and sent all the initially withheld SameSite
     cookies, the security benefits of withholding the cookies in the
     first place would be nullified.  This is especially important given
     that the absence of SameSite cookies withheld on a cross-site
     navigation request may lead to visible site breakage, prompting the
     user to trigger a reload.





  Bingler, et al.            Expires 4 June 2026                 [Page 54]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     For example, suppose the user clicks on a link from
     https://attacker.example/ to https://victim.example/. This is a
     cross-site request, so SameSite=Strict cookies are withheld.  Suppose
     this causes https://victim.example/ to appear broken, because the
     site only displays its sensitive content if a particular SameSite
     cookie is present in the request.  The user, frustrated by the
     unexpectedly broken site, presses refresh on their browser's toolbar.
     To now consider the reload request same-site and send the initially
     withheld SameSite cookie would defeat the purpose of withholding it
     in the first place, as the reload navigation triggered through the
     user interface may replay the original (potentially malicious)
     request.  Thus, the reload request should be considered cross-site,
     like the request that initially navigated to the page.

     Because requests issued for, non-user initiated, reloads attach all
     SameSite cookies, developers should be careful and thoughtful about
     when to initiate a reload in order to avoid a CSRF attack.  For
     example, the page could only initiate a reload if a CSRF token is
     present on the initial request.

  8.8.6.  Top-level requests with "unsafe" methods

     The "Lax" enforcement mode described in Section 5.6.7.1 allows a
     cookie to be sent with a cross-site HTTP request if and only if it is
     a top-level navigation with a "safe" HTTP method.  Implementation
     experience shows that this is difficult to apply as the default
     behavior, as some sites may rely on cookies not explicitly specifying
     a SameSite attribute being included on top-level cross-site requests
     with "unsafe" HTTP methods (as was the case prior to the introduction
     of the SameSite attribute).

     For example, the concluding step of a login flow may involve a cross-
     site top-level POST request to an endpoint; this endpoint expects a
     recently created cookie containing transactional state information,
     necessary to securely complete the login.  For such a cookie, "Lax"
     enforcement is not appropriate, as it would cause the cookie to be
     excluded due to the unsafe HTTP request method, resulting in an
     unrecoverable failure of the whole login flow.

     The "Lax-allowing-unsafe" enforcement mode described in
     Section 5.6.7.2 retains some of the protections of "Lax" enforcement
     (as compared to "None") while still allowing recently created cookies
     to be sent cross-site with unsafe top-level requests.








  Bingler, et al.            Expires 4 June 2026                 [Page 55]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     As a more permissive variant of "Lax" mode, "Lax-allowing-unsafe"
     mode necessarily provides fewer protections against CSRF.
     Ultimately, the provision of such an enforcement mode should be seen
     as a temporary, transitional measure to ease adoption of "Lax"
     enforcement by default.

  8.9.  Public Suffix List

     The boundaries of cookies depend on a site's "registrable domain"
     which in turn depends on the public suffix of the domain.

     Whenever possible, user agents SHOULD use an up-to-date public suffix
     list, such as the one maintained by the Mozilla project at [PSL].

     Failure to do so could allow malicious or sensitive cookies to leak
     between registrable domains.

  9.  IANA Considerations

  9.1.  Cookie

     The HTTP Field Name Registry (see [HttpFieldNameRegistry]) needs to
     be updated with the following registration:

     Header field name:  Cookie

     Applicable protocol:  http

     Status:  standard

     Author/Change controller:  IETF

     Specification document:  this specification (Section 5.8.1)

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



  Bingler, et al.            Expires 4 June 2026                 [Page 56]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  9.3.  "Cookie Attributes" Registry

     IANA is requested to create the "Cookie Attributes" registry,
     defining the name space of attributes used to control cookies'
     behavior.  The registry should be maintained in a new registry group
     called "Hypertext Transfer Protocol (HTTP) Cookie Attributes" at
     https://www.iana.org/assignments/cookie-attribute-names
     (https://www.iana.org/assignments/cookie-attribute-names).

  9.3.1.  Procedure

     Each registered attribute name is associated with a description, and
     a reference detailing how the attribute is to be processed and
     stored.

     New registrations happen on a "RFC Required" basis (see Section 4.7
     of [RFC8126]).  The attribute to be registered MUST match the
     extension-av syntax defined in Section 4.1.1.  Note that attribute
     names are generally defined in CamelCase but MUST be recognized case-
     insensitively.  Two attribute names that case-insensitively match
     MUST NOT be registered.

  9.3.2.  Registration

     The "Cookie Attributes" registry should be created with the
     registrations below:

                +==========+==================================+
                |     Name | Reference                        |
                +==========+==================================+
                |   Domain | Section 4.1.2.3 of this document |
                +----------+----------------------------------+
                |  Expires | Section 4.1.2.1 of this document |
                +----------+----------------------------------+
                | HttpOnly | Section 4.1.2.6 of this document |
                +----------+----------------------------------+
                |  Max-Age | Section 4.1.2.2 of this document |
                +----------+----------------------------------+
                |     Path | Section 4.1.2.4 of this document |
                +----------+----------------------------------+
                | SameSite | Section 4.1.2.7 of this document |
                +----------+----------------------------------+
                |   Secure | Section 4.1.2.5 of this document |
                +----------+----------------------------------+

                                    Table 1

  10.  References



  Bingler, et al.            Expires 4 June 2026                 [Page 57]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  10.1.  Normative References

     [DOM-DOCUMENT-COOKIE]
                van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
                Jägenstedt, P., and S. Pieters, "HTML - Living Standard",
                n.d., <https://html.spec.whatwg.org/#dom-document-cookie>.
                WHATWG

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

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

     [RFC4790]  Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
                Application Protocol Collation Registry", RFC 4790,
                DOI 10.17487/RFC4790, March 2007,
                <https://www.rfc-editor.org/rfc/rfc4790>.

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

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, DOI 10.17487/RFC5890, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5890>.

     [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
                DOI 10.17487/RFC6454, December 2011,
                <https://www.rfc-editor.org/rfc/rfc6454>.






  Bingler, et al.            Expires 4 June 2026                 [Page 58]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


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

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

     [SAMESITE] van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
                Jägenstedt, P., and S. Pieters, "HTML Living Standard",
                n.d., <https://html.spec.whatwg.org/#same-site>.  WHATWG

     [USASCII]  American National Standards Institute, "Coded Character
                Set -- 7-bit American Standard Code for Information
                Interchange", ANSI X3.4, 1986.

  10.2.  Informative References

     [Aggarwal2010]
                Aggarwal, G., Burzstein, E., Jackson, C., and D. Boneh,
                "An Analysis of Private Browsing Modes in Modern
                Browsers", 2010,
                <http://www.usenix.org/events/sec10/tech/full_papers/
                Aggarwal.pdf>.

     [app-isolation]
                Chen, E., Bau, J., Reis, C., Barth, A., and C. Jackson,
                "App Isolation - Get the Security of Multiple Browsers
                with Just One", 2011,
                <http://www.collinjackson.com/research/papers/
                appisolation.pdf>.

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

     [FETCH]    van Kesteren, A., "Fetch Living Standard", n.d.,
                <https://fetch.spec.whatwg.org/>.  WHATWG

     [HTML]     van Kesteren, A., Denicola, D., Farolino, D., Hickson, I.,
                Jägenstedt, P., and S. Pieters, "HTML Living Standard",
                n.d., <https://html.spec.whatwg.org/>.  WHATWG




  Bingler, et al.            Expires 4 June 2026                 [Page 59]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     [HttpFieldNameRegistry]
                "Hypertext Transfer Protocol (HTTP) Field Name Registry",
                n.d., <https://www.iana.org/assignments/http-fields/>.

     [prerendering]
                Bentzel, C., "Chrome Prerendering", n.d.,
                <https://www.chromium.org/developers/design-documents/
                prerender>.

     [PSL]      "Public Suffix List", n.d.,
                <https://publicsuffix.org/list/>.

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

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

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

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

     [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
                June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

     [SERVICE-WORKERS]
                Archibald, J. and M. Kruisselbrink, "Service Workers",
                n.d., <https://www.w3.org/TR/service-workers/>.

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




  Bingler, et al.            Expires 4 June 2026                 [Page 60]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


  Appendix A.  Changes from RFC 6265

     *  Adds the same-site concept and the SameSite attribute.
        (Section 5.2 and Section 4.1.2.7)

     *  Introduces cookie prefixes and prohibits nameless cookies from
        setting a value that would mimic a cookie prefix.  (Section 4.1.3
        and Section 5.7)

     *  Prohibits non-secure origins from setting cookies with a Secure
        flag or overwriting cookies with this flag.  (Section 5.7)

     *  Limits maximum cookie size.  (Section 5.7)

     *  Limits maximum values for max-age and expire.  (Section 5.6.1 and
        Section 5.6.2)

     *  Includes the host-only-flag as part of a cookie's uniqueness
        computation.  (Section 5.7)

     *  Considers potentially trustworthy origins as "secure".
        (Section 5.7)

     *  Improves cookie syntax

        -  Treats Set-Cookie: token as creating the cookie ("", "token").
           (Section 5.6)

        -  Rejects cookies without a name nor value.  (Section 5.7)

        -  Specifies how to serialize a nameless/valueless cookie.
           (Section 5.8.3)

        -  Adjusts ABNF for cookie-pair and the Cookie header production
           to allow for spaces.  (Section 4.1.1)

        -  Explicitly handle control characters.  (Section 5.6 and
           Section 5.7)

        -  Specifies how to handle empty domain attributes.  (Section 5.7)

        -  Requires ASCII characters for the domain attribute.
           (Section 5.7)

     *  Refactors cookie retrieval algorithm to support non-HTTP APIs.
        (Section 5.8.2)





  Bingler, et al.            Expires 4 June 2026                 [Page 61]


  Internet-Draft  Cookies: HTTP State Management Mechanism   December 2025


     *  Specifies that the Set-Cookie line should not be decoded.
        (Section 5.6)

     *  Adds an advisory section to assist implementers in deciding which
        requirements to implement.  (Section 3.2)

     *  Advises against sending invalid cookies due to public suffix list
        changes.  (Section 5.8.3)

     *  Removes the single cookie header requirement.  (Section 5.8.1)

     *  Address errata 3444 by updating the path-value andextension-av
        grammar, errata 4148 by updating the day-of-month, year, and time
        grammar, and errata 3663 by adding the requested note.
        (Section 4.1 and Section 5.1.4)

  Acknowledgements

     RFC 6265 was written by Adam Barth.  This document is an update of
     RFC 6265, adding features and aligning the specification with the
     reality of today's deployments.  Here, we're standing upon the
     shoulders of a giant since the majority of the text is still Adam's.

     Thank you to both Lily Chen and Steven Englehardt, editors emeritus,
     for their significant contributions improving this draft.

  Authors' Addresses

     Steven Bingler (editor)
     Email: bingler@chromium.org


     Mike West (editor)
     Google LLC
     Email: mkwst@google.com
     URI:   https://mikewest.org/


     John Wilander (editor)
     Apple, Inc
     Email: wilander@apple.com










  Bingler, et al.            Expires 4 June 2026                 [Page 62]


name: draft-meta-layer-overview
rev: 00
title: The Meta-Layer: A Coordination Substrate for Presence, Annotation, and Governance on the Web
time: 2025-10-06T06:23:20Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-09T06:23:20Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-08T17:35:45.010793+00:00
source: ietf
source_id: 149871
source_url: https://datatracker.ietf.org/doc/draft-meta-layer-overview/
doc_status: active
abstract:
  This document introduces the concept of a Meta-layer: a programmable
     coordination substrate that operates above content layers on the
     Internet.  The Meta-layer enables communities, individuals, and
     agents to appear, annotate, and govern together in shared digital
     space, independent of underlying platforms.  It is not a replacement
     for existing web or transport protocols, but a complementary
     infrastructure that integrates with them.  The draft outlines the
     motivation, terminology, use cases, implementation model, risks,
     security considerations, and potential IANA registries for future
     work.

full_text:
  GEN-Dispatch                                        K. ATTOUMANI MOHAMED
  Internet-Draft                                               D. BENJAMIN
  Intended status: Informational                     Meta-Layer Initiative
  Expires: 8 April 2026                                       October 2025


   The Meta-Layer: A Coordination Substrate for Presence, Annotation, and
                           Governance on the Web
                        draft-meta-layer-overview-00

  Abstract

     This document introduces the concept of a Meta-layer: a programmable
     coordination substrate that operates above content layers on the
     Internet.  The Meta-layer enables communities, individuals, and
     agents to appear, annotate, and govern together in shared digital
     space, independent of underlying platforms.  It is not a replacement
     for existing web or transport protocols, but a complementary
     infrastructure that integrates with them.  The draft outlines the
     motivation, terminology, use cases, implementation model, risks,
     security considerations, and potential IANA registries for future
     work.

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

  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.



  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 1]


  Internet-Draft             Meta-layer Overview              October 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Relevance to the IETF . . . . . . . . . . . . . . . . . . . .   5
       3.1.  Applications and Real-Time (ART) Area . . . . . . . . . .   5
       3.2.  Security (SEC) Area . . . . . . . . . . . . . . . . . . .   5
       3.3.  IRTF Research Groups  . . . . . . . . . . . . . . . . . .   5
       3.4.  General Area (GEN)  . . . . . . . . . . . . . . . . . . .   6
       3.5.  Collaboration with W3C and Other Bodies . . . . . . . . .   6
     4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Implementation Model  . . . . . . . . . . . . . . . . . . . .   7
       5.1.  Browser Extensions & Presence SDKs  . . . . . . . . . . .   7
       5.2.  Embedded Components in Web Applications . . . . . . . . .   7
       5.3.  Federation Across Domains . . . . . . . . . . . . . . . .   7
       5.4.  Trusted Execution for Agents  . . . . . . . . . . . . . .   7
       5.5.  Open APIs & Developer Onramps . . . . . . . . . . . . . .   7



  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 2]


  Internet-Draft             Meta-layer Overview              October 2025


       5.6.  Progressive Deployment  . . . . . . . . . . . . . . . . .   7
     6.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   7
       6.1.  Safe Digital Space  . . . . . . . . . . . . . . . . . . .   8
       6.2.  Cross-Site Knowledge & Interaction Flow . . . . . . . . .   8
       6.3.  Agent Containment . . . . . . . . . . . . . . . . . . . .   8
     7.  Risks and Mitigation  . . . . . . . . . . . . . . . . . . . .   8
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
     11. Informative References  . . . . . . . . . . . . . . . . . . .   9
     Appendix A.  Authors' Addresses . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     The Internet has evolved from a document-sharing network into a
     global application substrate.  However, it has never included a
     shared layer for presence, annotation, provenance, and contextual
     governance across domains.  These functions remain fragmented,
     implemented in proprietary platforms or plugins, without
     interoperability or transparency.

     The idea of a higher-level coordination or annotation layer above
     content is not new:

     Vannevar Bush (1945)  “As We May Think,” _The Atlantic Monthly_,
        introduced associative trails—linked paths of thought that
        presaged hypertext and the idea of connecting knowledge above
        documents.

     Ted Nelson (1965)  “Complex information processing: a file structure
        for the complex, the changing and the indeterminate” introduced
        hypertext as a precursor to a cross-page meta-layer.

     Douglas Engelbart (1968)  “The Mother of All Demos” (FJCC, San
        Francisco) publicly demonstrated NLS with hypertext, on-screen
        overlays, and view controls—effectively a layer above documents.

     Tim Berners-Lee (2001)  “The Semantic Web,” _Scientific American_,
        framed a data/meaning layer on top of the Web, i.e., machine-
        understandable metadata layered over pages.

     Marc Andreessen (2012)  “Why Andreessen Horowitz Is Investing in Rap
        Genius,” describing widespread web annotation as the “missing
        layer of the Internet.”







  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 3]


  Internet-Draft             Meta-layer Overview              October 2025


     The Meta-layer Initiative seeks to translate these longstanding
     conceptual foundations into open, interoperable infrastructure under
     IETF stewardship—turning decades of vision into a standard that
     integrates presence, annotation, provenance, and governance as native
     Internet functions.

  2.  Problem Statement

     Current IETF protocols provide robust foundations for transport (TCP,
     QUIC), security (TLS), and identity (OAuth, OIDC, SCIM).  However,
     the Internet still lacks standardized primitives for:

     *  Presence: expressing who is here, under what rules, and with what
        visibility.

     *  Annotation: attaching structured meaning (claims, challenges,
        polls, bridges) to content across domains.

     *  Provenance: cryptographically linking contributions to identity
        and context.

     *  Governance: enabling communities to compose and enforce rules
        transparently.

     *  Agent Containment: running AI and automated processes inside
        bounded, verifiable execution environments.

     Today, these behaviors exist only as fragmented features inside
     proprietary platforms.  This results in interoperability gaps,
     inconsistent privacy guarantees, lack of portability, and absence of
     shared governance mechanisms.

     While the W3C Web Annotation Data Model (2017) has defined a standard
     format for content-level annotations, it does not address cross-
     domain interoperability, provenance, or rule-based governance.  The
     Meta-layer complements W3C’s work by proposing a protocol-level
     substrate—capable of operating across applications and domains—where
     annotations, presence, and governance can interoperate securely and
     transparently.

     The absence of such a substrate has long been recognized: the ability
     to annotate and govern content was described as a “missing feature”
     of the web browser, and calls to explore a “meta-environment above
     the page” have been made by early Internet pioneers.  As Marc
     Andreessen noted in “Why Andreessen Horowitz Is Investing in Rap
     Genius” (2012), this “missing layer” reflects a longstanding need for
     interoperable annotation infrastructure.




  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 4]


  Internet-Draft             Meta-layer Overview              October 2025


     These concepts build on the architectural vision outlined in “The
     Metaweb: The Next Level of the Internet” (Bridgit DAO, CRC Press/
     Taylor & Francis, 2023), which introduced the concept of a “meta-
     layer above the webpage” as a civic and computational trust
     substrate.  This draft operationalizes that vision for
     standardization within the IETF context.

  3.  Relevance to the IETF

     This work aligns with several ongoing activities across IETF Areas
     and external web-standard bodies.

  3.1.  Applications and Real-Time (ART) Area

     Defines application-layer primitives for presence, annotation, and
     overlays, complementing ongoing work such as MIMI (Messaging
     Interoperability) and HTTP APIs.  The Meta-layer’s semantic and
     contextual overlay model complements W3C’s Web Annotation work by
     introducing interoperable signaling, provenance, and governance
     primitives at the Internet protocol layer.

  3.2.  Security (SEC) Area

     The Meta-layer depends on secure identity, accountability,
     cryptographic provenance, and trusted execution environments (TEEs).
     It builds upon and extends existing work in OAuth, OIDC, Privacy
     Pass, and SCIM for federated identity and access control; RATS
     (Remote ATtestation ProcedureS) and EAT (Entity Attestation Token)
     for verifying trustworthiness of execution environments; COSE (CBOR
     Object Signing and Encryption) and CFRG for cryptographic signing and
     post-quantum resilience; and SUIT (Software Updates for IoT) for
     maintaining verified code integrity within TEEs.  TEEs are thus
     positioned as security primitives within the IETF SEC Area, ensuring
     that agents in the Meta-layer execute in verifiable, policy-
     constrained, and auditable contexts.

  3.3.  IRTF Research Groups

     The governance and AI-containment aspects of the Meta-layer overlap
     with ongoing research in PEARG (Privacy Enhancements and Assessments
     RG) and RASPRG (Research and Analysis of Standard-Setting Processes
     RG).  The initiative can also contribute to IRTF and IAB workshops on
     AI accountability, provenance, and sustainable governance models.








  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 5]


  Internet-Draft             Meta-layer Overview              October 2025


  3.4.  General Area (GEN)

     Since the Meta-layer crosses multiple areas (ART, SEC, OPS, IRTF),
     GEN-Dispatch is an appropriate venue to discuss scope and determine
     whether a dedicated Working Group (WG) or Research Group (RG) is
     warranted.

  3.5.  Collaboration with W3C and Other Bodies

     The Meta-layer aims to be complementary to ongoing efforts in W3C
     (e.g., Web Annotation, ActivityPub, and provenance standards) and
     ISO/IEC JTC1 AI frameworks, by providing a network-layer and
     governance substrate that ensures interoperability, accountability,
     and trust across ecosystems.

  4.  Terminology

     (Working definitions)

     Overlay  Semantic/visual layer rendered above digital content,
        carrying presence indicators, tags, and interactions; governed by
        community rule modules.

     Smart Tag  Typed, structured annotation (e.g., note, claim,
        challenge, poll, bridge); signed, timestamped, interactive,
        filterable.

     Bridge  Semantic link connecting two pieces of content (support,
        challenge, context) across domains.

     Presence  Identity expression in digital space, scoped by context and
        rules (visible, pseudonymous, invisible).

     Governance Module  Composable logic defining rules for interaction,
        moderation, participation, and policy enforcement within an
        overlay.

     Agent  Automated or semi-autonomous process (AI, bot, scripted
        service) operating within the Meta-layer under policy constraints.

     TEE (Trusted Execution Environment)  Secure, attestable runtime
        container for agent execution, supporting constraints, logging,
        attestation.

     Provenance  Verifiable origin, context, and authorship of
        tags/actions/agent behaviors via signed metadata and timestamps.





  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 6]


  Internet-Draft             Meta-layer Overview              October 2025


  5.  Implementation Model

     The Meta-layer operates above existing content without requiring
     fundamental Web changes.  Functions are delivered via extensions,
     SDKs, and open APIs.

  5.1.  Browser Extensions & Presence SDKs

     Lightweight extension or embeddable SDK renders overlays on existing
     sites.  Overlays carry smart tags, presence, governance.
     Interoperable and governed by open registries (unlike closed
     annotation tools).

  5.2.  Embedded Components in Web Applications

     Sites integrate Meta-layer widgets or frames (e.g., a semantic
     sidebar in e-learning portals) via web-embed SDK.  No browser
     installation required for end users in these contexts.

  5.3.  Federation Across Domains

     Identity, tags, and governance rules are portable.  Provenance
     (signatures, timestamps) ensures authenticity across domains.

  5.4.  Trusted Execution for Agents

     Agents operate in bounded execution environments (e.g., TEEs) with
     policy-defined capabilities, rates, and auditable logs.

  5.5.  Open APIs & Developer Onramps

     APIs expose registries for tag types, badge schemas, governance
     modules.  Third parties define new tag types, build overlays, or fork
     rule modules.  Interop via stable identifiers (IANA-registered if
     standardized).

  5.6.  Progressive Deployment

     Early opt-in communities (e.g., research/fact-checking overlays).
     Later: native integrations once interop/security are proven.  No
     "flag day"—coexists and incrementally extends today’s Internet.

  6.  Use Cases








  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 7]


  Internet-Draft             Meta-layer Overview              October 2025


  6.1.  Safe Digital Space

     Federated identity, proof-of-humanity, and contextual filters enable
     communities to restrict participation (e.g., verified humans; scoped
     agent permissions) and create bot-resistant, trustable interaction
     zones.

  6.2.  Cross-Site Knowledge & Interaction Flow

     Smart tags and bridges make annotations portable and filterable
     across sites, building shared knowledge graphs with provenance.

  6.3.  Agent Containment

     Agents run in attested TEEs with logged behaviors and community-
     defined permissions—preventing unbounded automation and interaction
     while enabling useful collaboration.

  7.  Risks and Mitigation

     *  Identity fraud and bots: federated identity, contextual
        privileges, proof-of-humanity (when needed).

     *  Governance capture: modular rule modules, open registries, and
        forkable governance.

     *  Annotation spam or overload: attention-based rendering, overlay
        moderation, reputation weighting, rate limits.

     *  Privacy loss: scoped presence, pseudonymity, user-controlled
        visibility, data-minimizing defaults.

     *  Fragmentation: shared registries for tag types, governance
        modules, and semantic formats, with room for extensions or forks.

  8.  Security Considerations

     *  Identity and Authentication: leverage OAuth, OIDC, SCIM, Privacy
        Pass.

     *  Cryptographic Provenance: sign and timestamp tags and bridges;
        consider hybrid/post-quantum algorithms over time.

     *  Agent Containment: bounded TEEs or verifiable sandboxes with
        attestation and enforceable policy.

     *  Privacy: opt-in presence and annotation; scoped visibility;
        minimize metadata exposure.



  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 8]


  Internet-Draft             Meta-layer Overview              October 2025


     *  Registries and Extensions: standardized, auditable registries
        (designated expert review) to prevent identifier squatting or
        abuse.

  9.  IANA Considerations

     No immediate IANA actions requested.  If standardized, potential new
     registries include:

     *  Meta-layer Smart Tag Types Registry (e.g., note, claim, bridge,
        poll, challenge).

     *  Governance Module Registry (reusable rule modules for
        overlays/participation/moderation).

     *  Badge and Role Types Registry (moderator, validator, scribe,
        etc.).

     Registries should balance extensibility with security and
     interoperability, using clear specification references and
     designated-expert review.

  10.  Normative References

     [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
                3", RFC 2026, DOI 10.17487/RFC2026, 1996,
                <https://www.rfc-editor.org/rfc/rfc2026>.

     [RFC7990]  Flanagan, H., "RFC Format Framework", RFC 7990,
                DOI 10.17487/RFC7990, 2016,
                <https://www.rfc-editor.org/rfc/rfc7990>.

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

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

  11.  Informative References

     [W3C-WebAnnotation]
                Consortium, W. W. W., "Web Annotation Data Model", W3C
                Recommendation annotation-model, 2017,
                <https://www.w3.org/TR/annotation-model/>.





  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                  [Page 9]


  Internet-Draft             Meta-layer Overview              October 2025


     [MetaLayerWhitePaper]
                Initiative, M., "Meta-layer White Paper", 2025,
                <https://themetalayer.org/white-paper>.

     [MetawebBook]
                DAO, B., "The Metaweb: The Next Level of the Internet",
                Publisher Taylor & Francis / CRC Press, 2023,
                <https://www.routledge.com/The-Metaweb-The-Next-Level-of-
                the-Internet/DAO/p/book/9781032125527>.

     [Bush1945] Bush, V., "As We May Think", The Atlantic Monthly, July
                1945,
                <https://www.theatlantic.com/magazine/archive/1945/07/as-
                we-may-think/303881/>.

     [Engelbart1968]
                Engelbart, D., "The Mother of All Demos", 9 December 1968.

     [Nelson1965]
                Nelson, T. H., "Complex information processing: a file
                structure for the complex, the changing and the
                indeterminate", 1965,
                <https://dl.acm.org/doi/10.1145/800197.806036>.

     [BernersLee2001]
                Berners-Lee, T., "The Semantic Web", Scientific American,
                May 2001, <https://www-sop.inria.fr/acacia/cours/essi2006/
                Scientific%20American_%20Feature%20Article_%20The%20Semant
                ic%20Web_%20May%202001.pdf>.

     [Andreessen2012]
                Andreessen, M., "Why Andreessen Horowitz Is Investing in
                Rap Genius", October 2012, <https://genius.com/Marc-
                andreessen-why-andreessen-horowitz-is-investing-in-rap-
                genius-annotated>.

     [CerfRemarks2023]
                Cerf, V. G., "Review of "The Metaweb: The Next Level of
                the Internet"", 2023.

     [IAB-IRTF-AI-Workshops]
                IRTF, I. /, "IETF/IAB/IRTF workshop reports on AI
                governance and provenance", 2023.

  Appendix A.  Authors' Addresses

     Karim ATTOUMANI MOHAMED




  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                 [Page 10]


  Internet-Draft             Meta-layer Overview              October 2025


     Meta-Layer Initiative

     Email: karimattoumanimohamed@gmail.com


     Daveed Benjamin

     Meta-Layer Initiative

     Email: daveed@bridgit.io









































  ATTOUMANI MOHAMED & BENJAMExpires 8 April 2026                 [Page 11]


name: draft-mozleywilliams-dnsop-bandaid
rev: 00
title: Brokered Agent Network for DNS AI Discovery
time: 2025-10-16T08:56:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T08:56:23Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:44.863401+00:00
source: ietf
abstract:
  The emerging field of agent-to-agent protocol standards introduces
     new requirements in order to facilitate discovery, trust signaling,
     session negotiation and communication.  This document specifies a
     method for utilizing the Domain Name System (DNS) to facilitate
     scalable and interoperable discovery between AI agents.  The proposed
     mechanism, referred to as _Brokered Agent Network for DNS AI
     Discovery_ (BANDAID), defines a structured DNS namespace and record
     usage model to support metadata exchange and capability
     advertisement.

     BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
     containing Service Binding (SVCB) records (e.g.,
     chat._agents.example.com) that encode application-specific metadata.
     These records enable agents to retrieve operational parameters prior
     to initiating a session, supporting both targeted lookups and
     capability-based discovery.  The approach leverages existing DNS
     infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
     DANE, to provide integrity, authenticity, and automation without
     requiring human intervention.  Lastly, the draft for Domain Control
     Validation (DCV) proposes a best current practice to prove an agent
     is authorized to act on behalf of a domain.

     _This document proposes no change to the structure of DNS messages,
     and no new operation codes, response codes, resource record types, or
     any other new DNS protocol values._

full_text:
  dnsop                                                          J. Mozley
  Internet-Draft                                               N. Williams
  Intended status: Standards Track                          Infoblox, Inc.
  Expires: 19 April 2026                                       B. Sarikaya
                                                              Unaffiliated
                                                                 R. Schott
                                                          Deutsche Telecom
                                                           16 October 2025


                Brokered Agent Network for DNS AI Discovery
                   draft-mozleywilliams-dnsop-bandaid-00

  Abstract

     The emerging field of agent-to-agent protocol standards introduces
     new requirements in order to facilitate discovery, trust signaling,
     session negotiation and communication.  This document specifies a
     method for utilizing the Domain Name System (DNS) to facilitate
     scalable and interoperable discovery between AI agents.  The proposed
     mechanism, referred to as _Brokered Agent Network for DNS AI
     Discovery_ (BANDAID), defines a structured DNS namespace and record
     usage model to support metadata exchange and capability
     advertisement.

     BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
     containing Service Binding (SVCB) records (e.g.,
     chat._agents.example.com) that encode application-specific metadata.
     These records enable agents to retrieve operational parameters prior
     to initiating a session, supporting both targeted lookups and
     capability-based discovery.  The approach leverages existing DNS
     infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
     DANE, to provide integrity, authenticity, and automation without
     requiring human intervention.  Lastly, the draft for Domain Control
     Validation (DCV) proposes a best current practice to prove an agent
     is authorized to act on behalf of a domain.

     _This document proposes no change to the structure of DNS messages,
     and no new operation codes, response codes, resource record types, or
     any other new DNS protocol values._

  About This Document

     This note is to be removed before publishing as an RFC.







  Mozley, et al.            Expires 19 April 2026                 [Page 1]


  Internet-Draft                   BANDAID                    October 2025


     The latest revision of this draft can be found at
     https://example.com/LATEST.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-
     dnsop-bandaid/.

     Discussion of this document takes place on the WG Working Group
     mailing list (mailto:WG@example.com), which is archived at
     https://example.com/WG.

     Source for this draft and an issue tracker can be found at
     https://github.com/USER/REPO.

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 19 April 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.

  Table of Contents

     1.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4




  Mozley, et al.            Expires 19 April 2026                 [Page 2]


  Internet-Draft                   BANDAID                    October 2025


       2.1.  Challenges with Existing Proposed Mechanisms and Benefits
             of DNS  . . . . . . . . . . . . . . . . . . . . . . . . .   5
         2.1.1.  Development . . . . . . . . . . . . . . . . . . . . .   6
         2.1.2.  Opportunity Cost  . . . . . . . . . . . . . . . . . .   6
         2.1.3.  Governance  . . . . . . . . . . . . . . . . . . . . .   7
         2.1.4.  Sovereignty . . . . . . . . . . . . . . . . . . . . .   8
         2.1.5.  Commerce  . . . . . . . . . . . . . . . . . . . . . .   8
         2.1.6.  Application . . . . . . . . . . . . . . . . . . . . .   9
         2.1.7.  Granularity . . . . . . . . . . . . . . . . . . . . .   9
         2.1.8.  Performance . . . . . . . . . . . . . . . . . . . . .  10
         2.1.9.  Lifecycle / Management  . . . . . . . . . . . . . . .  10
         2.1.10. Trust . . . . . . . . . . . . . . . . . . . . . . . .  11
         2.1.11. Agent Properties  . . . . . . . . . . . . . . . . . .  11
         2.1.12. Control . . . . . . . . . . . . . . . . . . . . . . .  12
       2.2.  Mechanisms for Successful Agent Communication . . . . . .  13
         2.2.1.  Service Binding Records, aka SVCB . . . . . . . . . .  13
         2.2.2.  DNS Security Extensions, aka DNSSEC . . . . . . . . .  14
         2.2.3.  DNS Service Discovery, aka DNS-SD . . . . . . . . . .  15
         2.2.4.  DNS-Based Authentication of Named Entities, aka
                 DANE  . . . . . . . . . . . . . . . . . . . . . . . .  15
         2.2.5.  Domain Control Validation, aka DCV  . . . . . . . . .  16
         2.2.6.  Service Resilience  . . . . . . . . . . . . . . . . .  17
         2.2.7.  Observability, Auditability . . . . . . . . . . . . .  17
         2.2.8.  Interoperability  . . . . . . . . . . . . . . . . . .  18
         2.2.9.  Multitenancy, Federation  . . . . . . . . . . . . . .  18
       2.3.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  18
         2.3.1.  Example Communication . . . . . . . . . . . . . . . .  18
         2.3.2.  Example Record  . . . . . . . . . . . . . . . . . . .  18
         2.3.3.  Example Use Cases . . . . . . . . . . . . . . . . . .  19
     3.  BANDAID Overview  . . . . . . . . . . . . . . . . . . . . . .  20
       3.1.  Zone and Other Requirements . . . . . . . . . . . . . . .  20
         3.1.1.  Delegation and Chain of Trust . . . . . . . . . . . .  20
         3.1.2.  Algorithms and Parameters . . . . . . . . . . . . . .  21
         3.1.3.  Authenticated Denial of Existence . . . . . . . . . .  21
         3.1.4.  Signature Validity  . . . . . . . . . . . . . . . . .  21
         3.1.5.  Key Rollover  . . . . . . . . . . . . . . . . . . . .  21
         3.1.6.  Transport and Message Size  . . . . . . . . . . . . .  22
         3.1.7.  Transfer and Integrity  . . . . . . . . . . . . . . .  22
         3.1.8.  Monitoring  . . . . . . . . . . . . . . . . . . . . .  22
         3.1.9.  Abuse Resistance  . . . . . . . . . . . . . . . . . .  22
         3.1.10. BANDAID Records . . . . . . . . . . . . . . . . . . .  22
         3.1.11. Performance Optimization(s) . . . . . . . . . . . . .  23
         3.1.12. Customization(s)  . . . . . . . . . . . . . . . . . .  24
     4.  Implementation Guidance . . . . . . . . . . . . . . . . . . .  25
       4.1.  AI Operators  . . . . . . . . . . . . . . . . . . . . . .  25
         4.1.1.  Separation of Roles . . . . . . . . . . . . . . . . .  25
         4.1.2.  Local Root Zone Copy  . . . . . . . . . . . . . . . .  25
         4.1.3.  Aggressive Caching and Prefetch . . . . . . . . . . .  25



  Mozley, et al.            Expires 19 April 2026                 [Page 3]


  Internet-Draft                   BANDAID                    October 2025


         4.1.4.  EDNS(0) Transport Resilience  . . . . . . . . . . . .  26
         4.1.5.  Load Distribution . . . . . . . . . . . . . . . . . .  26
         4.1.6.  Monitoring and Telemetry  . . . . . . . . . . . . . .  26
         4.1.7.  Encrypted Resolver Steering (Informative) . . . . . .  27
       4.2.  AI Consumers  . . . . . . . . . . . . . . . . . . . . . .  27
         4.2.1.  DNS-Based Service Discovery . . . . . . . . . . . . .  27
         4.2.2.  Communication Failure / Retry . . . . . . . . . . . .  27
         4.2.3.  Domain Control Validation . . . . . . . . . . . . . .  28
       4.3.  AI Developers . . . . . . . . . . . . . . . . . . . . . .  28
         4.3.1.  Publishing Schema . . . . . . . . . . . . . . . . . .  28
         4.3.2.  TTLs, Update Agility  . . . . . . . . . . . . . . . .  28
         4.3.3.  Capability Retrieval  . . . . . . . . . . . . . . . .  29
         4.3.4.  Example DCV Flow  . . . . . . . . . . . . . . . . . .  29
         4.3.5.  Example Zonefile  . . . . . . . . . . . . . . . . . .  29
     5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  32
       5.1.  Future Work & Unaddressed Portions  . . . . . . . . . . .  32
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  33
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  33
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  37
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

  1.  Conventions and Definitions

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

     Agent-to-agent communication introduces novel requirements for
     service discovery, authorization signaling, and metadata exchange.
     While several proposals have explored new discovery protocols, the
     DNS remains the most widely deployed and interoperable mechanism for
     service discovery, with decades of operational maturity.  Existing
     DNS record types (including SRV, NAPTR, SVCB, TXT, and A/AAAA) are
     routinely used to locate services and convey configuration metadata.
     It is therefore reasonable to assume that AI agents will interact
     with this network protocol during discovery, session initiation, and
     their application exchange.

     If a user at $company asks their agent "clean up my Salesforce data
     based on this email," how does $company agent then know where to find
     Salesforce's agents?  How would the Salesforce agent validate the



  Mozley, et al.            Expires 19 April 2026                 [Page 4]


  Internet-Draft                   BANDAID                    October 2025


     $company agent and make the correct requested changes to Salesforce
     data?  The former question is a DNS-solvable problem, the latter is
     not in the scope of this draft.

     DNS can convey authorization and intent: DNS provides an organization
     a way to indicate that an agent is authorized to act on behalf of a
     domain (DCV draft), publish allowed endpoints or capabilities (SVCB),
     advertise service metadata in a way that’s cacheable, verifiable, and
     language-agnostic (tree domain etc), all while creating tamper-proof
     records and binding identities to certificates (DNSSEC + DANE).
     Additionally, DNS contributes to agent security by enabling
     connections to trusted nameservers, mitigating risks from
     typosquatted or malicious domains, and enforcing geographic or
     jurisdictional boundaries through country-code top-level domains
     (ccTLDs) and regionally scoped authoritative servers.  These features
     collectively support secure, policy-compliant agent interactions at
     scale.

     Unlike proposals that rely on centralized registries or ungoverned
     discovery networks, BANDAID builds upon existing infrastructure and
     governance models.  It preserves operator sovereignty, supports
     decentralized publication, and benefits from support in the form of
     legal dispute processes and vulnerability disclosure programs.

     This document aims to address key concerns in governance, commerce,
     security, and performance, allowing agent protocol designers to focus
     on data exchange standards while relying on the DNS for discovery.
     Agent-to-agent communication would take place after initial
     discovery, but some key data can be put into the DNS as a shortcut to
     make it more efficient.

     The problem statement addressed by this draft is
     [I-D.draft-mozley-aidiscovery] and also relevant is
     [I-D.draft-rosenberg-ai-protocols] although this draft is related to
     the discovery of agents rather than protocols used directly in agent-
     to-agent communication.

  2.1.  Challenges with Existing Proposed Mechanisms and Benefits of DNS

     Several alternative approaches to agent discovery have been proposed,
     including centralized registries, blockchain-based naming systems,
     and proprietary service directories.  While these models may offer
     novel features, they introduce significant architectural,
     operational, and governance challenges.  Centralized registries
     concentrate control and introduce single points of failure, limiting
     resilience and scalability.





  Mozley, et al.            Expires 19 April 2026                 [Page 5]


  Internet-Draft                   BANDAID                    October 2025


     Blockchain-based systems often lack integration with existing
     internet infrastructure, suffer from latency and cost constraints,
     and present jurisdictional ambiguity due to decentralized governance.
     Proprietary directories fragment the discovery ecosystem and inhibit
     interoperability across agent frameworks and administrative domains.
     Furthermore, securely delegating authority to AI solution providers
     on behalf of your organization requires interfacing between this
     central authority as opposed to business-to-business.

  2.1.1.  Development

     The DNS benefits from decades of global development and operational
     deployment.  It is supported by mature ecosystems for vulnerability
     disclosure, patch management, and protocol evolution, with active
     participation from security researchers, vendors, and operators
     worldwide.  This distributed development model ensures that no single
     entity maintains disproportionate control over the protocol’s
     trajectory or security posture.

     DNS infrastructure is also tightly integrated with existing
     cybersecurity practices.  Connections to trusted nameservers,
     protections against typosquatted or malicious domains, and support
     for jurisdictional scoping via country-code top-level domains
     (ccTLDs) contribute to a robust security baseline.  These features
     are particularly relevant in agent-to-agent contexts, where automated
     systems make trust decisions without human oversight... and
     importantly, may be maliciously modified without human awareness.

     In contrast, the introduction of a novel discovery protocol would
     require the establishment of new governance structures, security
     models, and operational tooling.  Early implementations would likely
     be centralized among a limited set of stakeholders, introducing
     bottlenecks in protocol evolution and risk mitigation.  Building a
     comparable ecosystem would require sustained investment, cross-
     organizational coordination, and long-term trust-building—resources
     that DNS already possesses.

  2.1.2.  Opportunity Cost

     Introducing a new protocol for agent-to-agent discovery imposes
     nontrivial infrastructure and operational requirements.  In
     particular, organizations may be required to deploy and maintain
     additional components such as specialized cache servers or registry
     interfaces, which increases complexity and operational overhead.
     Some proposals suggest a generic top level domain (gTLD) like
     .aiagent, which is more cost to advertise as domains are purchased by
     early opportunists.  These requirements may present barriers to
     adoption, especially for small or resource-constrained entities, and



  Mozley, et al.            Expires 19 April 2026                 [Page 6]


  Internet-Draft                   BANDAID                    October 2025


     risk reinforcing disparities in access to AI technologies.

     DNS, by contrast, is already deeply integrated into global
     infrastructure and supported by mature tooling, operational
     expertise, and deployment models.  Its use for agent discovery
     enables rapid adoption without introducing new layers of technical
     debt.  Leveraging DNS allows organizations to participate in agent-
     to-agent ecosystems using existing infrastructure, reducing
     onboarding friction and accelerating innovation.  This approach
     supports incremental deployment and minimizes opportunity cost by
     avoiding the need for parallel protocol development and
     infrastructure investment.

  2.1.3.  Governance

     The DNS operates within a well-established and internationally
     recognized governance framework.  Oversight is provided by entities
     such as the Internet Assigned Numbers Authority (IANA), top-level
     domain (TLD) operators, and national network information centers
     (NICs).  These organizations maintain accountability mechanisms and
     support dispute resolution processes, including domain takedowns,
     mitigation of impersonation, and remediation of malicious behavior.
     The governance structures surrounding DNS have evolved over decades
     and are supported by legal, technical, and operational norms that
     facilitate cross-jurisdictional trust and stability.

     DNS also enables policy enforcement at the infrastructure level.  For
     example, country-code top-level domains (ccTLDs) and regionally
     scoped authoritative servers allow for jurisdictional boundaries to
     be respected, which may be relevant in agent deployments subject to
     regulatory constraints.  Additionally, DNSSEC and DANE provide
     cryptographic assurances that bind domain identities to certificates,
     supporting automated trust decisions without requiring centralized
     registries or manual validation.

     In contrast, alternative discovery proposals—such as blockchain-based
     registries or neutral third-party systems—lack formal integration
     with existing governance bodies and may be susceptible to
     fragmentation, influence, or jurisdictional ambiguity.  These models
     do not currently offer the same level of operational recourse or
     reliability.  Leveraging DNS for agent discovery allows organizations
     to build on trusted infrastructure while maintaining compatibility
     with existing governance frameworks, providing a stable foundation
     for innovation as more experimental models mature.

     Establishing a new governance structure based on new agent discovery
     protocols would be time consuming, involve all stakeholders agreeing
     on the structure, establishing the structure in a specific



  Mozley, et al.            Expires 19 April 2026                 [Page 7]


  Internet-Draft                   BANDAID                    October 2025


     jurisdiction (which may not be suitable for all parties), and involve
     creating the technical infrastructure to support it.  The DNS already
     has all of these components in place.

  2.1.4.  Sovereignty

     The DNS supports decentralized control while maintaining global
     interoperability.  Organizations may operate their own authoritative
     DNS infrastructure, publish service records independently, and retain
     full control over how their services are discovered.  This model
     enables entities to maintain autonomy over their service exposure and
     operational boundaries without reliance on centralized intermediaries
     which may not share their same interests.

     Proposed alternatives—such as blockchain-based registries, single-
     purpose generic top-level domains (gTLDs), or third-party discovery
     networks—often introduce opaque governance models, unclear trust
     boundaries, and dependencies on external infrastructure.  Although
     these systems may be described as “decentralized,” they frequently
     concentrate control within protocol maintainers, validator networks,
     or registry operators, which may not be accountable to the
     organizations they serve.

     DNS provides a proven and extensible registry model that supports
     secure, independent publication of agent metadata.  It aligns with
     principles of digital sovereignty and operational self-determination,
     allowing organizations to participate in agent ecosystems without
     relinquishing control over discovery infrastructure.

  2.1.5.  Commerce

     A critical consideration in the design of agent discovery
     infrastructure is the potential for commercialization to compromise
     integrity.  In the absence of established norms or constraints, new
     registry-based discovery mechanisms may evolve into visibility-driven
     platforms, where agent discoverability is influenced by paid
     placement rather than technical merit, trust, or reputation.  This
     introduces incentives that prioritize commercial interests over
     operational reliability and security, undermining the predictability
     and neutrality of agent interactions and the free and open Internet
     as a whole.

     DNS, by contrast, is built on open standards and governed by
     transparent, non-commercial processes.  It provides mechanisms for
     validation and authentication, such as DNSSEC, and certificate
     bindings via DANE that are not subject to monetization.  The
     resolution process is deterministic and not influenced by financial
     incentives, preserving the integrity of service discovery.



  Mozley, et al.            Expires 19 April 2026                 [Page 8]


  Internet-Draft                   BANDAID                    October 2025


     Leveraging DNS ensures that agent discovery remains a technical
     function grounded in verifiable identity and operational metadata,
     rather than a commercial battleground.  This supports fair access and
     trustworthy interactions across heterogeneous agent ecosystems.

  2.1.6.  Application

     Regardless of how agent discovery is initiated, agent-to-agent
     communication ultimately intersects with existing network
     infrastructure.  Agents may require access to internal services,
     external APIs, or shared data repositories, all of which are
     typically addressed through conventional networking and resolution
     mechanisms.  Introducing a separate discovery protocol that fragments
     the location and representation of service metadata introduces
     architectural complexity and increases the risk of cascading failures
     across systems.

     Operators would be required to manage multiple layers of resolution
     logic, synchronization mechanisms, and failure domains, which
     complicates deployment and undermines operational reliability.  DNS,
     by contrast, is already embedded in the fabric of networked
     applications and provides a natural point of integration for
     discovery.  It enables metadata publication to remain proximate to
     the services it describes, reducing latency, simplifying
     architecture, and aligning with existing operational models.  This
     approach supports innovation in agent systems while avoiding brittle
     dependencies and minimizing architectural drift.

     DNS is predictable for agents to use for the purposes of discovery,
     requiring no advanced configurations to consume the service, rather
     it is embedded in all pieces of the application stack eliminating the
     need to retrofit legacy devices to operate in an agent-to-agent
     environment.

  2.1.7.  Granularity

     DNS supports fine-grained control over service discovery through its
     hierarchical zone structure and flexible record types.  Organizations
     may define zones and records at varying levels of specificity,
     including per-host, per-service, per-environment (e.g., staging vs.
     production), or per geographic region.  This granularity enables
     precise targeting and segmentation of agent capabilities,
     facilitating operational clarity and policy enforcement.

     Service Binding (SVCB) records further enhance granularity by
     allowing metadata to be associated with individual service endpoints.
     This includes transport preferences, supported protocols, and
     application-specific parameters.  Combined with DNS Service Discovery



  Mozley, et al.            Expires 19 April 2026                 [Page 9]


  Internet-Draft                   BANDAID                    October 2025


     (DNS-SD), these features allow agents to discover services with high
     specificity, reducing ambiguity and improving interoperability.  The
     DNS model supports modular deployment and incremental adoption,
     making it well-suited for diverse agent architectures and operational
     contexts.

  2.1.8.  Performance

     DNS is well-suited to meet the scale and responsiveness requirements
     of agent discovery, where billions of agents may generate trillions
     of queries.  Its architecture supports high-throughput, low-latency
     resolution through mechanisms such as caching, retry logic, and
     autom,atic zone distribution to secondary servers.  Recursive
     resolvers may be further optimized by locally hosting the root zone
     [RFC8806], reducing lookup latency and improving fault tolerance.

     Additional features such as pre-fetching and negative caching allow
     resolvers to anticipate agent behavior and reduce query overhead.
     Country code (ccTLD) and Generic Top Level Domain (gTLD) operators
     have global infrastructure to support localized resolution and
     improve performance for AI-specific applications.  These capabilities
     enable scalable deployment without requiring protocol redesign or new
     infrastructure layers.

     Furthermore, DNS-based discovery enables immediate connection
     establishment.  Once an agent endpoint is resolved, transport
     protocols such as QUIC may be used to initiate communication
     directly, benefiting from features such as 0-RTT and multiplexed
     streams.  This eliminates the need for a separate handshake or
     negotiation phase for discovery, reducing latency and improving
     throughput in high-volume environments.  DNS thus provides a
     performant and extensible foundation for agent discovery at global
     scale.

  2.1.9.  Lifecycle / Management

     DNS provides robust provisioning and lifecycle management
     capabilities that align with the dynamic nature of agent-based
     systems.  Mechanisms such as Incremental Zone Transfer (IXFR) and
     Full Zone Transfer (AXFR) allow for rapid propagation of zone updates
     across authoritative servers.  When backed by database-centric DNS
     implementations, zone data may be treated as replicable state,
     enabling near-real-time onboarding or decommissioning of agents.

     Operational observability is supported through query logging, zone
     monitoring, and resolver telemetry, which can be used to track agent
     utilization patterns and identify stale or inactive records.




  Mozley, et al.            Expires 19 April 2026                [Page 10]


  Internet-Draft                   BANDAID                    October 2025


     These lifecycle management capabilities are mature, widely supported,
     and compatible with existing operational tooling.  They enable high-
     churn agent ecosystems to be managed efficiently without requiring
     the development of new provisioning, monitoring, or cleanup
     protocols.

  2.1.10.  Trust

     In agent discovery, trust encompasses more than identity verification
     — it includes confidence in the provenance, behavior, and reliability
     of the agents being discovered.  The DNS provides a recognizable and
     auditable namespace rooted in organizational domains (e.g.,
     microsoft.com, openai.com), enabling systems to make informed
     decisions about agent interactions based on domain ownership and
     established reputational context.  This is particularly critical in
     AI environments, where agents may initiate autonomous actions or
     access sensitive data.

     DNS enables organizations to publish agent endpoints under domains
     they control, establishing a clear chain of accountability.  This
     trust model supports cryptographic validation through DNSSEC and
     DANE, allowing agents to verify domain ownership and certificate
     bindings without manual intervention.  By contrast, discovery
     mechanisms lacking verifiable lineage introduce significant risk and
     complexity, particularly when agents are discovered through opaque or
     ungoverned registries.

     The BANDAID model builds on the DNS’s trust infrastructure to support
     safe and scalable agent discovery.  It allows agents to assess the
     authenticity and authority of remote endpoints prior to interaction,
     reducing the likelihood of misrouting, impersonation, or unauthorized
     access.  This trust-validation-first approach is foundational to
     enabling secure automation in agent ecosystems.

  2.1.11.  Agent Properties

     As agent-to-agent protocols evolve, it is likely more metadata will
     need to be signaled in the discovery phase to allow agents to make
     more informed decisions.  An example of how DNS provides a platform
     to facilitate this is below.











  Mozley, et al.            Expires 19 April 2026                [Page 11]


  Internet-Draft                   BANDAID                    October 2025


     Service Binding (SVCB) records, as defined in [RFC9460], support
     extensible key-value parameters that may be registered through the
     IANA SVCB Parameter Registry.  These parameters can provide agent
     systems with operational context prior to session initiation,
     enabling informed decisions about whether and how to engage with a
     remote agent.  It is possible to publish metadata such as input (e.g.
     expected token counts) or cost (e.g. cost per token bundle) directly
     within DNS records.

     This model supports a trust-validation-first approach to agent
     interaction, where expectations around resource usage and pricing are
     transparently advertised.  It reduces the need for handshake-based
     negotiation or out-of-band signaling, and allows for deterministic,
     cacheable discovery workflows.  For instance, by embedding cost-
     related metadata in DNS, discovery becomes not only scalable and
     performant, but also semantically rich, supporting economically-aware
     agent ecosystems without introducing new protocols or registries.

  2.1.12.  Control

     Agent discovery mechanisms must operate within the constraints of
     enterprise security policies, regulatory compliance requirements, and
     operational boundaries.  DNS enables the presentation of distinct DNS
     views based on the source of the query.  This allows organizations to
     expose different sets of agent records to internal versus external
     resolvers.  For example, internal agents may resolve
     _a2a._agents.internal.example.com to discover services not intended
     for public exposure, while external agents receive responses only for
     _a2a._agents.example.com containing externally authorized endpoints.

     Enterprise-grade network controls such as firewalls, Response Policy
     Zones (RPZs), and access control lists (ACLs) provide additional
     enforcement mechanisms.  These controls may restrict outbound DNS
     queries to designated resolvers, filter inbound queries to approved
     zones, and block unauthorized resolution attempts.  This ensures that
     agent discovery adheres to organizational boundaries and complies
     with internal security policies.  For example, an enterprise may
     configure its network security to allow internal agents to query only
     *.internal.example.com zones, while blocking access to external agent
     zones unless explicitly permitted.  Similarly, DNS servers may
     enforce query logging and rate limiting to detect anomalous behavior
     or potential abuse.

     Segmented discovery via DNS aligns with compliance requirements
     related to data residency, privacy, and access control.  By scoping
     agent visibility to specific zones and enforcing resolution
     boundaries, organizations can ensure that discovery mechanisms
     respect jurisdictional constraints, internal governance models, and



  Mozley, et al.            Expires 19 April 2026                [Page 12]


  Internet-Draft                   BANDAID                    October 2025


     support auditability.  Query logs, zone access telemetry, and
     resolver behavior can be monitored to verify that agent interactions
     conform to policy.  This provides a foundation for regulatory
     reporting, incident response, and continuous compliance validation
     without the need for extensive additional operations that require
     more technical staffing or specialized solutions.

  2.2.  Mechanisms for Successful Agent Communication

     The explicit goal of the DNS [RFC1035] is to provide a mechanism for
     name resolution, enabling agent discovery without requiring new
     protocols, trust anchors, or infrastructure layers.  Leveraging DNS
     for agent discovery ensures compatibility with existing operational
     models, supports incremental deployment, and avoids the risks
     associated with experimental or ungoverned discovery mechanisms.

  2.2.1.  Service Binding Records, aka SVCB

     The SVCB resource record as defined in [RFC9460], enables DNS to
     convey structured service metadata that facilitates optimized
     connection establishment.  SVCB records support the advertisement of
     protocol identifiers (via ALPN), transport parameters (e.g., port
     numbers), endpoint hints (e.g., IP addresses), and extensible key-
     value attributes.  These capabilities are particularly relevant for
     agent-to-agent communication, where protocol negotiation and metadata
     exchange must occur without human intervention.

     In the context of BANDAID, SVCB records are used to publish agent-
     specific service endpoints under structured leaf zones (e.g.,
     _chat._agents.example.com).  These records allow querying agents to
     retrieve operational parameters prior to initiating a session,
     including supported protocols, privacy features (e.g., Encrypted
     Client Hello via ECH), and failover configurations.  This eliminates
     the need for heuristic-based connection attempts and reduces round-
     trip latency.

     SVCB records also support protocol agility and privacy-preserving
     features.  For example, agents may advertise support for QUIC,
     HTTP/3, or custom agent-to-agent protocols via ALPN declarations.
     Operators may specify alternate endpoints or migrate services across
     domains without relying on CNAME indirection, improving performance
     and reducing DNS resolution complexity.









  Mozley, et al.            Expires 19 April 2026                [Page 13]


  Internet-Draft                   BANDAID                    October 2025


     When paired with attribute leaf zones and custom SVCB parameters,
     this mechanism enables fine-grained discovery of agent capabilities.
     For instance, an agent querying _a2a._agents.example.com may receive
     an SVCB record indicating supported modalities (e.g., chat, image-to-
     text), expected input formats, and cost-related metadata (e.g., token
     pricing).  This structured discovery model supports deterministic,
     cacheable, and semantically rich interactions between agents.

  2.2.2.  DNS Security Extensions, aka DNSSEC

     DNSSEC as defined in [RFC4033], [RFC4034], and [RFC4035], enables
     resolvers and clients to verify that a response originates from an
     authoritative source (authenticity) and DNS data has not been
     modified in transit (data integrity).  In the context of BANDAID,
     DNSSEC serves as a foundational trust mechanism for agent discovery.
     By signing agent-related resource records—such as SVCB, TXT, or
     custom metadata—organizations can ensure that querying agents receive
     authentic and tamper-proof information.  This is particularly
     critical for agent-to-agent communication, where autonomous systems
     must make trust decisions without human oversight.

     DNSSEC supports the establishment of cryptographic trust anchors via
     Delegation Signer (DS) records and facilitates secure delegation of
     authority across zone boundaries.  This allows organizations to
     publish agent metadata under subdomains (e.g.,
     _a2a._agents.example.com) while maintaining verifiable control over
     the zone hierarchy.

     Furthermore, DNSSEC eliminates the need for hardcoded trust lists or
     centralized validation services.  Agents can validate responses using
     the DNSSEC chain of trust, enabling decentralized and scalable trust
     verification.  This model supports zero-trust architectures and
     aligns with modern security principles by minimizing implicit trust
     and enforcing explicit validation.

     When combined with DANE (DNS-Based Authentication of Named Entities),
     DNSSEC enables binding of TLS certificates to DNS names, further
     enhancing the authenticity of agent endpoints.  This integration
     supports secure session initiation and mitigates risks associated
     with certificate mis-issuance or man-in-the-middle attacks.  The use
     of DANE may improve performance and enable automation in the
     dynamicism of agent lifecycle.









  Mozley, et al.            Expires 19 April 2026                [Page 14]


  Internet-Draft                   BANDAID                    October 2025


  2.2.3.  DNS Service Discovery, aka DNS-SD

     DNS-SD as defined in [RFC6763], extends the capabilities of the
     Domain Name System to support service-type-based discovery.  Unlike
     traditional DNS resolution, which requires prior knowledge of a
     specific hostname, DNS-SD enables clients to discover services based
     on their functional type (e.g., _http._tcp, _printer._udp) within a
     given domain.

     In the context of BANDAID, DNS-SD provides a mechanism for AI agents
     to discover other agents or services based on declared capabilities
     rather than explicit names.  For example, an agent may issue a query
     for _data-cleaner._a2a._agents.example.com to locate services capable
     of performing data sanitization tasks.  This type-based discovery
     model supports dynamic ecosystems where agent roles and capabilities
     may evolve over time.

     DNS-SD operates over both multicast DNS (mDNS) and unicast DNS,
     allowing for flexible deployment in local networks and globally
     scoped domains.  In enterprise or cloud environments, unicast DNS-SD
     enables structured and policy-compliant discovery across
     organizational boundaries.  When combined with SVCB records, DNS-SD
     allows agents to retrieve detailed service metadata, including
     transport preferences, protocol support, and operational parameters.

     This model supports federated agent architectures, where multiple
     agents may advertise similar capabilities under different domains.
     By leveraging DNS-SD, agents can perform capability-based queries and
     receive a list of candidate services, each accompanied by structured
     metadata for evaluation and selection.

     DNS-SD also supports extensibility through TXT records and custom
     service naming conventions, enabling organizations to encode
     additional attributes relevant to agent interaction (e.g., supported
     data formats, authentication requirements, or cost models).  These
     features make DNS-SD a suitable foundation for scalable,
     interoperable, and semantically rich agent discovery workflows.

  2.2.4.  DNS-Based Authentication of Named Entities, aka DANE

     DANE as specified in [RFC6698] and [RFC7671], enables domain owners
     to associate Transport Layer Security (TLS) certificates with DNS
     names using TLSA resource records.  When protected by DNSSEC, these
     records provide cryptographically verifiable bindings between domain
     names and public keys, allowing clients to authenticate services
     without relying solely on external certificate authorities (CAs).





  Mozley, et al.            Expires 19 April 2026                [Page 15]


  Internet-Draft                   BANDAID                    October 2025


     In the context of BANDAID, DANE enhances the trust model for agent-
     to-agent communication by enabling agents to validate the
     authenticity of remote endpoints based on domain-controlled
     assertions.  This is particularly relevant in automated environments
     where agents must establish secure sessions without manual
     certificate validation or user interaction.

     By publishing TLSA records under agent-specific service names (e.g.,
     _a2a._tcp.agent.example.com), organizations can declare the expected
     certificate fingerprint or public key for a given agent endpoint.
     Querying agents can then validate the TLS connection against the DANE
     record, ensuring that the certificate presented during session
     initiation matches the domain’s published intent.

     This mechanism mitigates risks associated with certificate mis-
     issuance, man-in-the-middle attacks, and reliance on third-party
     trust anchors.  It also supports deterministic validation workflows,
     which are critical for agents operating in headless or GUI-less
     environments where interactive certificate warnings cannot be
     resolved.

     When combined with DNSSEC, DANE provides a robust, decentralized, and
     verifiable trust infrastructure for agent discovery and
     communication.  It aligns with zero-trust principles by enabling
     domain owners to assert and control trust relationships directly
     through DNS, without introducing additional registries or validation
     services.

  2.2.5.  Domain Control Validation, aka DCV

     DCV refers to the process by which an entity demonstrates
     authoritative control over a DNS domain.  As described in draft-ietf-
     dnsop-domain-verification-techniques, DNS-based DCV typically
     involves the placement of a DNS record—most commonly a TXT
     record—containing a challenge token or assertion at a designated
     location within the domain.  This record is then queried by an
     Application Service Provider (ASP) to confirm control.

     In the context of BANDAID, DCV provides a mechanism for agents to
     assert delegated authority on behalf of a domain.  For example, an
     organization may publish a TXT record under a structured leaf zone
     (e.g., _agent-roles._a2a._agents.example.com) containing metadata
     such as:

        ai-role=data-cleaner; crm=salesforce; access=readonly






  Mozley, et al.            Expires 19 April 2026                [Page 16]


  Internet-Draft                   BANDAID                    October 2025


     This record signals that a specific agent is authorized to perform
     scoped operations under the domain's authority.  When protected by
     DNSSEC, such assertions become cryptographically verifiable,
     mitigating risks of spoofing or unauthorized delegation.

     DCV within BANDAID supports both ephemeral and persistent validation
     models.  Ephemeral validation may be used for short-lived agent
     credentials or session-based delegation, while persistent records
     enable long-term authorization signaling.  TTL and expiration
     considerations, as discussed in the draft, are critical to ensuring
     that validation records do not persist beyond their intended scope.

     Furthermore, BANDAID encourages the use of application-specific
     naming conventions and token formats to avoid service confusion and
     collision.  Validation records should be scoped to the intended
     service and include unguessable tokens or structured metadata to
     prevent unauthorized reuse across federated agent ecosystems.

  2.2.6.  Service Resilience

     The DNS architecture is inherently resilient due to its distributed,
     hierarchical design.  Authoritative zones are replicated across
     multiple servers, and recursive resolvers implement caching, retry
     logic, and failover mechanisms to ensure continuity of resolution.
     Failover, anycast, and replication continue to add resiliency and
     redundancy provided through the DNS.

     This fault-tolerant model supports agent discovery even in the
     presence of partial network outages, denial-of-service conditions, or
     upstream failures.  Unlike centralized registries or proprietary
     APIs, DNS does not rely on a single point of availability, making it
     suitable for high-availability agent ecosystems operating across
     diverse network environments.

  2.2.7.  Observability, Auditability

     DNS provides built-in observability through query logging, resolver
     telemetry, and zone monitoring.  These features enable operators to
     track agent discovery patterns, detect anomalous behavior, and
     perform forensic analysis of agent interactions.  This auditability
     is critical in regulated environments where agent actions must be
     attributable and verifiable, and where discovery mechanisms must
     align with enterprise governance models.

     Logs may be used to validate compliance with access policies,
     identify stale or misconfigured records, support incident response
     workflows, and/or be used in lifecycle management of unused or
     oversubscribed agents.



  Mozley, et al.            Expires 19 April 2026                [Page 17]


  Internet-Draft                   BANDAID                    October 2025


  2.2.8.  Interoperability

     BANDAID is designed to be agnostic to agent implementation
     frameworks.  Whether agents are built using open-source libraries,
     proprietary orchestration platforms, or custom runtimes, DNS-based
     discovery provides a common substrate for metadata publication and
     retrieval.  This interoperability ensures that agents operating under
     different protocols, vendors, or administrative domains can
     participate in shared discovery workflows without requiring protocol
     translation or framework-specific integration.  DNS’s ubiquity across
     operating systems and network stacks further reinforces its
     suitability as a universal discovery layer.

  2.2.9.  Multitenancy, Federation

     DNS’s hierarchical namespace supports multi-tenant and federated
     discovery models.  Organizations may delegate subdomains to tenants
     (e.g., customer1._agents.vendor.com) or publish agent metadata under
     federated zones (e.g., region1._a2a.example.org).  This enables
     scoped discovery, policy enforcement, and operational isolation
     across tenants, departments, or geographic regions.  Combined with
     DNSSEC and access controls, this model supports secure delegation and
     trust signaling in complex agent ecosystems, including SaaS platforms
     and cross-organizational collaborations.

  2.3.  Architecture

  2.3.1.  Example Communication

     Agent (org1) wants to find other agents provided by another entity
     (org2) and discover/verify capabilities

     DNS SVCB Query ┌────────┐ _a2a._agents.example.com ┌────────┐
     ┌────────┐ │AI
     Agent├─────────────────────────────►│Resolver├───────────►│Auth DNS│
     │ (ORG1) │ ◄────────────────────────────┤ (ORG1) │◄─────┬─────┤
     (ORG2) │ └────────┘ └────────┘ │ └────────┘ │
     ┌─────────────────────────────────────────────────┴─────────────┐
     │_a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (│ │
     alpn="a2a" │ │ port=443 │ │ ipv4hint=192.0.2.1 │ │
     ipv6hint=2001:db8::1 │ │) │
     └───────────────────────────────────────────────────────────────┘

  2.3.2.  Example Record

     _a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (
     alpn="a2a" port=443 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 )




  Mozley, et al.            Expires 19 April 2026                [Page 18]


  Internet-Draft                   BANDAID                    October 2025


     _a2a._aiagent.example.com.: The service name, following the SVCB
     naming convention (_service._agents.example.com). 3600: TTL (Time to
     Live) in seconds.  IN SVCB: The record type. 1: SVCB priority. 0 is
     for alias mode; 1+ is for service mode. ai-index-svc.org2.com.: The
     target name of the service. alpn="a2a": Specifies the ALPN protocol
     identifier.  This is where your custom protocol is declared.
     port=443: The port on which the service is available. ipv4hint and
     ipv6hint: Optional hints for clients to connect directly.

  2.3.3.  Example Use Cases

        A user instructs their internal agent to “clean up Salesforce
        contacts based on this email.” The agent must discover
        Salesforce’s authorized agents, validate its own delegation to act
        on behalf of the enterprise, and initiate a secure session.
        BANDAID enables this by publishing agent endpoints and roles under
        DNS zones controlled by each organization.

        A research consortium deploys agents across multiple institutions.
        Each institution publishes its agents under its own domain (e.g.,
        _a2a._agents.universityA.edu), allowing collaborators to discover
        services based on capability (e.g., _data-
        annotator._a2a.universityB.edu) while respecting institutional
        boundaries and trust models.

        A SaaS provider hosts agents for multiple customers.  Each
        customer’s agents are published under tenant-specific zones (e.g.,
        customer1._agents.saas.com), enabling scoped discovery and policy
        enforcement.  BANDAID supports this model through hierarchical
        zone delegation and metadata-rich SVCB records.

        Lightweight agents deployed on mobile or edge devices require low-
        latency, cacheable discovery mechanisms.  DNS’s distributed
        architecture and support for SVCB hints (e.g., IP addresses,
        preferred protocols) enable efficient resolution and connection
        bootstrapping in constrained environments.

        In regulated industries, agents must operate within jurisdictional
        boundaries and maintain audit trails of interactions.  DNS
        supports geographic scoping via ccTLDs and split-horizon
        configurations, while query logging and DNSSEC provide
        observability and integrity guarantees.









  Mozley, et al.            Expires 19 April 2026                [Page 19]


  Internet-Draft                   BANDAID                    October 2025


  3.  BANDAID Overview

     The BANDAID model is designed for incremental and non-disruptive
     deployment within existing DNS infrastructure.  It introduces no new
     DNS message formats, opcodes, response codes, or resource record
     types.  Instead, it defines a structured namespace convention and
     usage profile for existing record types... primarily SVCB, TXT, and
     TLSA all within designated leaf zones (e.g.,
     _a2a._agents.example.com).

     Organizations may adopt BANDAID by publishing agent metadata under
     delegated subdomains, leveraging DNSSEC for integrity and
     authenticity, and optionally implementing Domain Control Validation
     (DCV) to signal delegated authority.  These zones may be exposed
     selectively via split-horizon DNS, enabling differentiated discovery
     views for internal and external agents.  No changes are required to
     recursive or authoritative DNS server implementations beyond standard
     support for DNSSEC and SVCB.

     This model supports opt-in adoption, allowing agent operators to
     publish discovery metadata without coordination with external
     registries or protocol maintainers.  It is compatible with existing
     DNS tooling, including zone provisioning systems, monitoring
     platforms, and resolver configurations.  BANDAID is therefore
     suitable for deployment across enterprise, cloud, and federated
     environments, and may coexist with other discovery mechanisms without
     conflict.

  3.1.  Zone and Other Requirements

  3.1.1.  Delegation and Chain of Trust

     An external authoritative zone used for the purposes of BANDAID MUST
     use DNSSEC [RFC4033].  The BANDAID external zone MUST establish a
     complete chain of trust to a publicly recognized trust anchor.  For
     zones delegated from a public parent, DS records MUST be present and
     maintained at the parent zone.  DS digests MUST use SHA-256 (Digest
     Type 2) as specified in [RFC4509]; SHA-1 (Digest Type 1) MUST NOT be
     used.  Where feasible, automation of DS maintenance SHOULD be
     performed using CDS and CDNSKEY as specified in [RFC7344] and
     operationalized per [RFC8078].










  Mozley, et al.            Expires 19 April 2026                [Page 20]


  Internet-Draft                   BANDAID                    October 2025


  3.1.2.  Algorithms and Parameters

     Authoritative signers for the BANDAID External Zone MUST use DNSSEC
     algorithms and key sizes consistent with current implementation and
     usage guidance in [RFC8624].  Implementations SHOULD prefer
     elliptic-curve or EdDSA algorithms for efficiency and security,
     specifically ECDSA P-256 (Algorithm 13; [RFC6605]) or Ed25519
     (Algorithm 15; [RFC8080]).  Zones MUST NOT rely on RSA/SHA-1
     signatures.  If RSA is used for transitional reasons, key sizes
     SHOULD be ≥ 2048 bits and migration to ECDSA or EdDSA SHOULD be
     planned.

     Separation of roles between a Key-Signing Key (KSK) and a
     Zone-Signing Key (ZSK) is RECOMMENDED for operational agility,
     consistent with practices in [RFC6781].  Private keys SHOULD be
     protected by appropriate controls (e.g., HSMs or equivalent)
     commensurate with organizational risk.

  3.1.3.  Authenticated Denial of Existence

     The BANDAID External Zone MUST provide authenticated denial of
     existence.  NSEC3 [RFC5155] is RECOMMENDED to mitigate trivial zone
     enumeration for zones where record names or labels might reveal
     sensitive information.  If NSEC3 is used, the number of iterations
     SHOULD be kept modest to balance CPU cost for signers and validators,
     per guidance in [RFC6781].  Use of NSEC with White Lies is OPTIONAL
     where operationally justified.

  3.1.4.  Signature Validity

     Signature validity windows MUST be chosen to balance cache efficiency
     and replay risk.  In general, a signature lifetime on the order of
     days to a small number of weeks is RECOMMENDED, with staggered
     resigning to avoid mass expiration events [RFC6781].  Resource Record
     TTLs MUST be set to values that support timely updates to BANDAID
     capability data while allowing effective caching; operational
     defaults SHOULD be validated against change frequency.  Negative
     caching behavior MUST follow [RFC2308].

  3.1.5.  Key Rollover

     Zones MUST support planned key rollovers and emergency key
     replacement consistent with the procedures in [RFC6781].
     Pre-publication and double-signature techniques SHOULD be used to
     minimize validation failures during ZSK and KSK rollovers.  Parent DS
     changes SHOULD be orchestrated using CDS/CDNSKEY signaling
     [RFC7344][RFC8078].  Post-compromise recovery procedures MUST be
     documented, including revocation, re-signing, and DS replacement



  Mozley, et al.            Expires 19 April 2026                [Page 21]


  Internet-Draft                   BANDAID                    October 2025


     timelines.

  3.1.6.  Transport and Message Size

     Because DNSSEC increases response sizes, authoritative servers for
     the BANDAID External Zone MUST implement EDNS(0) per [RFC6891] and
     MUST support TCP fallback for queries per [RFC7766].  Authoritative
     operators SHOULD configure UDP response sizing to minimize IP
     fragmentation risk and SHOULD ensure that large responses (e.g.,
     DNSKEY, NSEC3 chains) remain retrievable via TCP.

  3.1.7.  Transfer and Integrity

     When secondary authoritative servers are used, zone transfers MUST be
     authenticated and protected with TSIG [RFC2845].  Use of DNS NOTIFY
     [RFC1996] and incremental transfer (IXFR; [RFC5936]) is RECOMMENDED
     to reduce propagation latency and bandwidth.  To provide at-rest
     integrity verification between primaries and secondaries, publishing
     a ZONEMD record is RECOMMENDED where supported [RFC8976].

  3.1.8.  Monitoring

     Operators MUST monitor DNSSEC validity from multiple vantage points
     to detect stale signatures, DS/DNSKEY mismatches, and other
     validation failures.  Alarms SHOULD be configured for impending
     signature expiration, key compromise indicators, and DS
     inconsistencies.  Signing infrastructure SHOULD be tested under load
     and failure scenarios consistent with the scalability requirements of
     this specification.

  3.1.9.  Abuse Resistance

     Authoritative servers for the BANDAID External Zone SHOULD implement
     DNS Cookies [RFC7873][RFC9018] to reduce off-path spoofing and
     amplification risks.  Operators SHOULD follow best practices to limit
     amplification and to shape responses under attack, consistent with
     maintaining DNSSEC validity.

  3.1.10.  BANDAID Records

     All BANDAID-specific discovery records (e.g., SRV [RFC2782], SVCB/
     HTTPS [RFC9460], TXT/URI [RFC7553] used for capability descriptors,
     and any BANDAID-defined RRTypes) MUST be signed and published in the
     BANDAID External Zone.  Where BANDAID endpoints rely on TLS,
     publication of DANE TLSA records SHOULD be used to bind endpoint
     certificates to DNSSEC-validated names [RFC6698][RFC7671].  Resolver
     behavior consuming BANDAID data MUST treat DNSSEC-bogus responses as
     failures and MUST NOT act on unsigned or invalidly signed discovery



  Mozley, et al.            Expires 19 April 2026                [Page 22]


  Internet-Draft                   BANDAID                    October 2025


     data.

  3.1.11.  Performance Optimization(s)

     The discovery namespace for BANDAID SHOULD be structured to minimize
     query depth, RRset size, and update blast radius.  To that end,
     implementers SHOULD allocate per-service, per-agent leaf names and
     avoid aggregating high-cardinality data under a single owner name.  A
     deterministic mapping (e.g., a stable hash of an Agent Identifier) to
     leaf labels SHOULD be used to support sharding and parallel
     administration.  Where cardinality requires, sub-zones MAY be
     delegated (zone cuts) to distribute authority and update load.

     Each agent service endpoint SHOULD be published using SVCB in
     ServiceMode (or HTTPS RR for HTTPS endpoints) to convey connection
     parameters and capability locators with a single lookup [RFC9460].
     SVCB “address hints” (ipv4hint, ipv6hint) SHOULD be used to reduce A/
     AAAA follow-up queries; resolvers MAY still validate final addresses
     via canonical resolution.  Where human-friendly names are required,
     SVCB AliasMode (priority 0) MAY be used to map from a stable alias to
     a hashed leaf, avoiding record duplication while preserving cache
     locality.

     Authoritative servers MUST support EDNS(0) [RFC6891] and TCP fallback
     [RFC7766].  Operators SHOULD target response sizes that avoid IP
     fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring
     compression and layered indirection over oversized RRsets.  TTLs MUST
     be chosen to reflect the volatility of capability data; index/
     indirection records may use longer TTLs than frequently changing
     endpoint or capability descriptors.  Negative caching MUST conform to
     [RFC2308].  When high update rates are expected, IXFR and NOTIFY
     SHOULD be used to reduce propagation latency.

     Resolvers and authoritative operators SHOULD take advantage of SVCB’s
     ALPN, port, and (for HTTPS) ECH parameters to enable connection
     pre-establishment and reduce round-trips, subject to client policy
     and security posture [RFC9460].  Where privacy policies prohibit
     client geolocation, EDNS Client Subnet SHOULD NOT be relied upon for
     performance.

     A representative naming pattern is shown below; the exact label order
     is deployment-specific, but the leaf per service, per agent rule
     applies:

     ``` ; Hashed, per-agent, per-service leaf
     a4k2f9._mcp._bandaid.example.org.  600 IN SVCB 1 svc-
     a4k2f9.example.org.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
     ipv4hint=192.0.2.5



  Mozley, et al.            Expires 19 April 2026                [Page 23]


  Internet-Draft                   BANDAID                    October 2025


     ; Optional alias for a friendlier owner name
     billing._mcp._bandaid.example.org. 300 IN SVCB 0
     a4k2f9._mcp._bandaid.example.org. ```

  3.1.12.  Customization(s)

     BANDAID deployments MAY define additional SVCB parameters
     (SvcParamKeys) to convey agent-specific capability metadata, provided
     that interoperability safeguards in [RFC9460] are observed.  During
     experimentation, unregistered keys MUST use the numeric keyNNNNN
     presentation form, and any client behavior that depends on them MUST
     be gated via the mandatory SvcParam to ensure downgrade safety.  This
     specification defines the following provisional SvcParamKeys for
     BANDAID (names are illustrative; production deployments MUST register
     through IANA per [RFC9460] or use keyNNNNN until standardized):

        cap — a capability descriptor locator or inline identifier (e.g.,
        a URN or compact JSON-Ref) that identifies the agent’s advertised
        capability schema/version. cap-sha256 — a base64url-encoded
        SHA-256 digest of the canonical capability descriptor to support
        integrity checks and cache revalidation. bap — a comma-separated
        list of BANDAID Application Protocols and versions understood by
        the endpoint (e.g., bap="a2a/1,mcp/1,acp/2").  This is distinct
        from transport-level alpn. policy — a URI or URN identifying a
        policy bundle applicable to this agent (e.g., jurisdiction, data
        handling class) for client-side selection. realm — an opaque token
        for multi-tenant scoping or authz realm selection during protocol
        bootstrapping.

     Clients that require any of these parameters MUST verify their
     presence via the mandatory key; otherwise, the SVCB record MUST be
     ignored.  Example:

     Single-RRTYPE publication with custom params (experimental keys
     shown) a4k2f9._mcp._bandaid.example.org. 600 IN SVCB 1 svc-
     a4k2f9.example.org.  alpn="h2" port=443 ipv4hint=192.0.2.5
     mandatory=alpn,port,key65001,key65002,key65010
     key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-
     sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0"
     key65010="bap=a2a/1,mcp/1" Where endpoints are HTTPS, the HTTPS RR
     variant SHOULD be used to co-locate transport parameters such as ech
     with capability metadata; otherwise, generic SVCB MAY be used.
     Future standardization SHOULD define the exact syntax (e.g., ABNF)
     and registry policy for these keys, including error handling for
     malformed or conflicting parameters.  Until registration is complete,
     deployments MUST treat unknown keyNNNNN parameters as opaque and MUST
     NOT infer semantics without out-of-band agreement.




  Mozley, et al.            Expires 19 April 2026                [Page 24]


  Internet-Draft                   BANDAID                    October 2025


  4.  Implementation Guidance

  4.1.  AI Operators

  4.1.1.  Separation of Roles

     Operators MUST separate authoritative servers for BANDAID zones from
     recursive resolvers to prevent cache poisoning and reduce operational
     coupling.  Authoritative servers MUST NOT perform recursion.
     Recursive resolvers SHOULD be deployed close to query sources (e.g.,
     within organizational networks or edge PoPs) to minimize latency and
     reduce upstream load.

  4.1.2.  Local Root Zone Copy

     Recursive resolvers serving BANDAID traffic SHOULD maintain a local
     copy of the root zone as specified in [RFC8806].  This eliminates
     dependency on external root servers for priming queries, reduces
     resolution latency, and improves resilience during partial Internet
     outages or denial-of-service events targeting root infrastructure.

  4.1.3.  Aggressive Caching and Prefetch

     Resolvers MUST implement RFC-compliant caching and SHOULD enable the
     aggressive use of DNSSEC-validated cache to synthesize negative
     answers from NSEC/NSEC3 and reduce upstream lookups, consistent with
     [RFC8198].  This behavior improves latency, lowers authoritative
     load, and can mitigate certain attack patterns by answering within
     validated non-existence ranges.

     Resolvers SHOULD implement serve-stale as specified in [RFC8767].
     When authoritative servers are unreachable or fail to refresh data, a
     resolver MAY return expired records from its cache to preserve
     availability, subject to policy caps on staleness.  [RFC8767] updates
     the TTL semantics to allow use beyond expiration under these
     exceptional conditions and RECOMMENDS capping staleness on the order
     of days, with a typical cap of 7 days.  When serving stale data, the
     TTL in the response MUST be set to a value greater than zero (with 30
     seconds RECOMMENDED) so clients and intermediaries do not cache a
     zero-TTL response indefinitely.











  Mozley, et al.            Expires 19 April 2026                [Page 25]


  Internet-Draft                   BANDAID                    October 2025


     Resolvers implementing serve-stale SHOULD follow the timer guidance
     in [RFC8767]: continue background refresh (“stale-while-revalidate”),
     bound total resolution work with a query-resolution timer, avoid
     excessive re-tries with a failure-recheck timer (no more frequently
     than ~30 seconds is RECOMMENDED), and ensure client responsiveness
     with a client-response timer (on the order of ~1.8 seconds is
     RECOMMENDED).  These controls balance resiliency with freshness and
     protect upstream authorities during outages or attack conditions.

     Operators MUST consider DNSSEC interactions when serving stale data.
     Stale answers can increase the likelihood that signatures are outside
     their validity windows; implementations MUST NOT misrepresent
     validation status (e.g., AD bit handling MUST follow DNSSEC semantics
     where the bit is only set if all relevant RRsets are
     cryptographically verified according to local policy).

     Prefetch of popular BANDAID names SHOULD be used to keep caches warm,
     and negative caching MUST follow [RFC2308] to avoid unnecessary
     upstream traffic during flaps.  Where serve-stale is enabled,
     operators SHOULD monitor stale-answer rates and staleness
     distribution to ensure that policy caps and refresh behavior meet
     availability and freshness objectives.

  4.1.4.  EDNS(0) Transport Resilience

     All servers MUST support EDNS(0) [RFC6891] and TCP fallback [RFC7766]
     to accommodate DNSSEC and SVCB responses that exceed traditional UDP
     size limits.  Operators SHOULD configure UDP response sizing to avoid
     IP fragmentation (e.g., ≤1232 bytes for IPv6 paths) and SHOULD
     monitor truncation rates to detect misconfigurations or path MTU
     issues.\

  4.1.5.  Load Distribution

     Authoritative servers for BANDAID zones SHOULD be deployed using IP
     anycast to provide global reachability, load balancing, and DDoS
     resilience.  Recursive resolvers SHOULD be deployed in a
     geographically distributed manner to minimize latency for agent
     queries and to provide failover during regional outages.

  4.1.6.  Monitoring and Telemetry

     Operators MUST implement continuous monitoring of query latency,
     cache hit ratios, DNSSEC validation success rates, and transport
     fallback events.  Alarms SHOULD be configured for anomalies such as
     sudden TTL exhaustion, signature expiration, or upstream
     unreachability.  Logging MUST respect privacy and regulatory
     constraints while providing sufficient detail for operational



  Mozley, et al.            Expires 19 April 2026                [Page 26]


  Internet-Draft                   BANDAID                    October 2025


     troubleshooting and compliance audits.

  4.1.7.  Encrypted Resolver Steering (Informative)

     AI clients and operators MAY implement Encrypted DNS Server
     Redirection (EDSR) to permit an encrypted resolver to redirect a
     client to another encrypted resolver for performance, locality, or
     policy reasons Any acceptance of redirection MUST follow the
     verified-discovery model of DDR [RFC9462], including validation of
     the designated relationship and TLS authentication of the target
     resolver.  If redirection validation fails or exceeds a single hop,
     clients MUST continue to use the original resolver configuration.
     When available, network-designated resolvers provisioned via DNR
     [RFC9463] take precedence over unsolicited redirection unless local
     policy dictates otherwise.  EDSR is currently an Internet-Draft and
     is referenced as an OPTIONAL extension.

  4.2.  AI Consumers

  4.2.1.  DNS-Based Service Discovery

     DNS-Based Service Discovery AI clients that consume BANDAID discovery
     data MUST implement DNS-based service discovery consistent with
     [RFC6763] and [RFC9460].  Clients SHOULD query for SVCB or HTTPS
     records at well-defined service labels (e.g.,
     _mcp._bandaid.example.org.) and interpret alpn, port, and custom
     SvcParams as specified in this document.  Where multiple priorities
     are returned, clients MUST honor the SVCB priority and weight
     semantics for selection and failover.  Clients MUST validate DNSSEC
     signatures for all discovery responses and MUST NOT act on unsigned
     or bogus data.

     Clients SHOULD implement caching consistent with TTLs and negative
     caching rules in [RFC2308].  Prefetching of high-traffic names MAY be
     used to reduce latency, provided that it does not violate policy or
     privacy constraints.  Clients MUST support EDNS(0) and TCP fallback
     to handle large responses.

  4.2.2.  Communication Failure / Retry

     When a discovered agent endpoint is unreachable, clients MUST
     implement retry logic that respects exponential backoff and avoids
     synchronized retry storms.  Clients SHOULD attempt alternate SVCB
     targets in priority order before declaring failure.  Where
     serve-stale responses are received, clients MUST treat them as
     advisory and MUST NOT assume freshness beyond the TTL indicated in
     the response.  Clients SHOULD log stale usage for observability and
     compliance.



  Mozley, et al.            Expires 19 April 2026                [Page 27]


  Internet-Draft                   BANDAID                    October 2025


  4.2.3.  Domain Control Validation

     To prevent impersonation and unauthorized data access, BANDAID
     deployments MUST support Domain Control Validation (DCV) using DNS.
     This mechanism allows application owners to verify that a requesting
     service is authorized to act on behalf of a domain (e.g., “AI, sync
     all customer contacts from my approved CRM for acme.org”).  DCV MUST
     follow a challenge-response model where the domain owner publishes a
     cryptographically strong token in a DNS TXT record under a
     well-defined label (e.g., _bandaid-challenge.acme.org.).  The token
     MUST be bound to the requesting service identity and have a bounded
     validity period.  Clients performing DCV MUST validate the token
     against the expected value and expiration before granting delegated
     access.  Tokens SHOULD be single-use and MUST be removed from DNS
     after successful validation.  All DCV interactions MUST occur over
     DNSSEC-validated channels to prevent spoofing or downgrade attacks.

  4.3.  AI Developers

  4.3.1.  Publishing Schema

     Publishers SHOULD expose per-service discovery records using SVCB (or
     HTTPS for HTTP origins) at stable, well-scoped owner names (e.g.,
     agent-id._mcp._bandaid.example.org.).  SVCB ServiceMode conveys
     connection parameters and capability locators in a single round trip;
     AliasMode MAY be used to map a friendly name to a hashed leaf for
     sharding without duplicating RRSets.  Initial connection parameter
     keys (alpn, port, address hints) and the mandatory key MUST be
     honored by clients.  [RFC9460]

     Minimal example:

     ; ServiceMode SVCB for an MCP-capable agent
     a4k2f9._mcp._bandaid.example.org.  600 IN SVCB 1 svc-
     a4k2f9.example.net.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
     ipv4hint=192.0.2.5 mandatory=alpn,port

     SVCB/HTTPS semantics and SvcParam processing MUST follow [RFC9460] to
     ensure interop and correct fallback.

  4.3.2.  TTLs, Update Agility

     Publishers SHOULD assign longer TTLs to relatively static indirection
     records (aliases, stable service labels) and shorter TTLs to volatile
     endpoint/capability records to balance cache efficiency with rollout
     safety.  Consumers will apply negative caching per [RFC2308], so
     publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments
     (e.g., prefer blue/green leaves over in-place deletions).



  Mozley, et al.            Expires 19 April 2026                [Page 28]


  Internet-Draft                   BANDAID                    October 2025


  4.3.3.  Capability Retrieval

     When capability metadata is referenced via URI from SVCB/HTTPS,
     retrieval MUST occur over authenticated, confidential channels.
     Publishers SHOULD offer TLS 1.3 and MAY bind endpoint identity via
     DANE TLSA where resolvers validate DNSSEC; otherwise, WebPKI
     validation applies.  Operational guidance for DANE usage (certificate
     usage selections, rollover) SHOULD follow [RFC7671] [RFC8446]
     [RFC6698]

     Where using HTTPS RRs, publishers MAY advertise the ech SvcParam to
     enable Encrypted Client Hello for privacy; client/server behavior and
     key distribution MUST follow the semantics described in [RFC9460] for
     the ech parameter.

  4.3.4.  Example DCV Flow

     Example DCV Flow (Normative Sketch)

     *  The relying service issues a DCV challenge with a nonce bound to
        its identity and an expiration time.

     *  The domain owner publishes the nonce at _bandaid-challenge.domain.
        as a TXT RR until validation completes.

     *  The verifier performs a DNSSEC-validated TXT query and compares
        the presented nonce and binding; on success, access is granted and
        the TXT is removed.

     need a sketch for how this looks

  4.3.5.  Example Zonefile

     ``` $ORIGIN example.org. $TTL 3600

     ; -------------------------------------------------------------------
     --- ; SOA / NS ; ----------------------------------------------------
     ------------------ @ IN SOA ns1.example.org. hostmaster.example.org.
     ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry
     1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org.  IN NS
     ns2.example.org.

     ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2
     IN AAAA 2001:db8::54

     ; -------------------------------------------------------------------
     --- ; BANDAID discovery (MCP example): per-service, per-agent leaf ;
     - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; -



  Mozley, et al.            Expires 19 April 2026                [Page 29]


  Internet-Draft                   BANDAID                    October 2025


     Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; 
     ---------------------------------------------------------------------
     -

     ; AliasMode to keep a friendly name stable even if the leaf changes
     billing._mcp._bandaid 300 IN SVCB 0 a4k2f9._mcp._bandaid.example.org.

     ; Leaf per agent/service (ServiceMode).  Shorter TTL for agility.
     a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
     alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \
     mandatory=alpn,port

     ; (Optional) Another service face for the same agent (A2A)
     a4k2f9._a2a._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
     alpn="h2" port=8443 \ mandatory=alpn,port

     ; (Optional) HTTPS RR at apex for web-style consumers of BANDAID
     metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443

     ; -------------------------------------------------------------------
     --- ; Capability / policy signaling via SVCB custom keys
     (experimental) ; Use numeric keyNNNNN until you register IANA
     SvcParamKeys. ; Gate client requirements with "mandatory". ; --------
     -------------------------------------------------------------- ;
     Example: reference a capability descriptor and advertise supported
     app protocols. ; NOTE: Values and key numbers are illustrative.

     a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
     alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \
     key65001="cap=urn:cap:example:mcp:invoice.v1" \
     key65010="bap=a2a/1,mcp/1"

     ; -------------------------------------------------------------------
     --- ; Domain Control Validation (DCV) for BANDAID authorization ;
     Publish a short-lived token to prove control over example.org. ;
     Remove after successful validation.  Resolver MUST DNSSEC-validate. ;
     ---------------------------------------------------------------------
     - _bandaid-challenge 300 IN TXT "bnd-req=svc:crm-
     sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z"

     ; -------------------------------------------------------------------
     --- ; Optional DANE TLSA for the service endpoint used above. ;
     Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1
     (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI
     hash of the leaf certificate. ; -------------------------------------
     --------------------------------- _443._tcp.svc-a4k2f9.example.net.
     1800 IN TLSA 3 1 1 (
     0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )



  Mozley, et al.            Expires 19 April 2026                [Page 30]


  Internet-Draft                   BANDAID                    October 2025


     ; -------------------------------------------------------------------
     --- ; (Optional) Address records for the service endpoint, if hosted
     in-zone ; If hosted out-of-zone (example.net), these will live there
     instead. ; ----------------------------------------------------------
     ------------ svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA
     2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA
     2001:db8::80 ```

  4.3.5.1.  How to use this zonefile

     *  Adjust TTLs for agility vs. cache efficiency.  Use longer TTLs on
        indirection (aliases), shorter TTLs on volatile leaves and DCV.
        This aligns with DNS caching behavior and negative caching rules
        [RFC2308].

     *  Follow SVCB/HTTPS semantics.  Clients must honor SvcPriority,
        AliasMode (priority 0), and ServiceMode parameters, including
        mandatory, alpn, port, and address hints per [RFC9460].

     *  DCV token flow.  Issue a time-bounded token at _bandaid-
        challenge.domain and require DNSSEC-validated retrieval (pattern
        analogous to ACME’s DNS-01 in [RFC8555]).  Remove on success.

     *  Bind transport to DNS with DANE (optional).  If your relying
        parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/
        key, using the operational guidance in [RFC7671] (TLSA record
        format in [RFC6698]).

     *  Sign the zone.  This file is pre-signing.  Sign with DNSSEC
        (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat
        unsigned/bogus discovery data as a failure (per your earlier
        spec).  See DNSSEC core specs [RFC4033], [RFC4034], [RFC4035] and
        operational guidance.

  4.3.5.2.  Why these records

     *  SVCB/HTTPS concentrate connection metadata and allow aliasing at
        apex and service labels, reducing round trips and enabling
        policy-gated params via mandatory.

     *  Per-service, per-agent leaves avoid oversized RRsets and allow
        parallel administration/sharding while keeping alias names stable.
        This follows performance guidance in SVCB and your BANDAID perf
        section.

     *  DCV via TXT mirrors a well-understood, automated control-proof
        pattern [RFC8555] that fits BANDAID authorization workflows.




  Mozley, et al.            Expires 19 April 2026                [Page 31]


  Internet-Draft                   BANDAID                    October 2025


     *  DANE TLSA optionally removes reliance on external PKI anchors for
        endpoint auth where DNSSEC is deployed [RFC6698], with deployment
        rules in [RFC7671].

  5.  Conclusion

     The discovery of AI agents at Internet scale introduces requirements
     for autonomy, security, resilience, and interoperability that cannot
     be met by ad-hoc or centralized mechanisms.  Organizations must
     advertise capabilities in a manner that is globally unique,
     cryptographically verifiable, and operationally scalable, while
     preserving compliance with regulatory and sovereignty constraints.
     The solution space must account for dynamic lifecycles, selective
     disclosure, and the ability to integrate with existing infrastructure
     without introducing new trust anchors or governance choke points.

     This document defines BANDAID as a DNS-based discovery framework that
     leverages the global DNS namespace, DNSSEC for integrity and
     authenticity, and SVCB/HTTPS records for structured capability
     advertisement.  By building on widely deployed protocols and
     operational practices, BANDAID provides a predictable entry point for
     agent discovery, supports hierarchical delegation for organizational
     autonomy, and enables secure, low-latency resolution at scale.
     Extensions such as custom SvcParams, DNS-based domain control
     validation, and optional DANE bindings further strengthen trust and
     interoperability.

     Future work includes standardizing capability schemas, formalizing
     SvcParam registries for BANDAID metadata, and defining
     privacy-preserving query mechanisms (like authoritative DOT/H/Q).  By
     aligning with existing Internet standards and operational best
     practices, BANDAID offers a path to interoperable, secure, and
     resilient AI agent discovery without reinventing the foundational
     layers of the Internet.

  5.1.  Future Work & Unaddressed Portions

     Index versus agents publishing their updates, etc.  Unresolved in the
     use case of it being better to have an index which is a list of all
     agents an org owns, or allow records within the zone to be the record
     of truth.

     For example, a company may only have a few external agents available
     for use, and if the IETF standardizes 'types' of AI agents, then
     perhaps _chat._ai.domain.com or _img2txt._ai.domain.com etc are all
     different SVCB records.





  Mozley, et al.            Expires 19 April 2026                [Page 32]


  Internet-Draft                   BANDAID                    October 2025


  6.  Security Considerations

     To add: Lookalikes, takedowns, misbehaving agents, compliance,
     privacy

  7.  IANA Considerations

     IANA are to consider registering an underscored attribute leaf as
     part of [RFC8552] for BANDAID.

     IANA are to consider designating custom key-value pairs for SVCB
     parameters to facilitate agent-to-agent application discovery,
     potentially for cost optimization (token input counts, costs per
     token bundle, etc.)

  8.  References

  8.1.  Normative References

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

  8.2.  Informative References

     [I-D.draft-mozley-aidiscovery]
                Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI
                Agent Discovery (AID) Problem Statement", Work in
                Progress, Internet-Draft, draft-mozley-aidiscovery-00, 15
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-mozley-aidiscovery-00>.

     [I-D.draft-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>.

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.




  Mozley, et al.            Expires 19 April 2026                [Page 33]


  Internet-Draft                   BANDAID                    October 2025


     [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
                Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
                August 1996, <https://www.rfc-editor.org/rfc/rfc1996>.

     [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
                NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
                <https://www.rfc-editor.org/rfc/rfc2308>.

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

     [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
                Wellington, "Secret Key Transaction Authentication for DNS
                (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
                <https://www.rfc-editor.org/rfc/rfc2845>.

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Resource Records for the DNS Security Extensions",
                RFC 4034, DOI 10.17487/RFC4034, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4034>.

     [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "Protocol Modifications for the DNS Security
                Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4035>.

     [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
                (DS) Resource Records (RRs)", RFC 4509,
                DOI 10.17487/RFC4509, May 2006,
                <https://www.rfc-editor.org/rfc/rfc4509>.

     [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
                Security (DNSSEC) Hashed Authenticated Denial of
                Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
                <https://www.rfc-editor.org/rfc/rfc5155>.

     [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
                (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
                <https://www.rfc-editor.org/rfc/rfc5936>.





  Mozley, et al.            Expires 19 April 2026                [Page 34]


  Internet-Draft                   BANDAID                    October 2025


     [RFC6605]  Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital
                Signature Algorithm (DSA) for DNSSEC", RFC 6605,
                DOI 10.17487/RFC6605, April 2012,
                <https://www.rfc-editor.org/rfc/rfc6605>.

     [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
                of Named Entities (DANE) Transport Layer Security (TLS)
                Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
                2012, <https://www.rfc-editor.org/rfc/rfc6698>.

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

     [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
                Operational Practices, Version 2", RFC 6781,
                DOI 10.17487/RFC6781, December 2012,
                <https://www.rfc-editor.org/rfc/rfc6781>.

     [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
                for DNS (EDNS(0))", STD 75, RFC 6891,
                DOI 10.17487/RFC6891, April 2013,
                <https://www.rfc-editor.org/rfc/rfc6891>.

     [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
                DNSSEC Delegation Trust Maintenance", RFC 7344,
                DOI 10.17487/RFC7344, September 2014,
                <https://www.rfc-editor.org/rfc/rfc7344>.

     [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
                Identifier (URI) DNS Resource Record", RFC 7553,
                DOI 10.17487/RFC7553, June 2015,
                <https://www.rfc-editor.org/rfc/rfc7553>.

     [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
                Authentication of Named Entities (DANE) Protocol: Updates
                and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
                October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

     [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
                D. Wessels, "DNS Transport over TCP - Implementation
                Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
                <https://www.rfc-editor.org/rfc/rfc7766>.

     [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
                Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
                <https://www.rfc-editor.org/rfc/rfc7873>.




  Mozley, et al.            Expires 19 April 2026                [Page 35]


  Internet-Draft                   BANDAID                    October 2025


     [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
                the Parent via CDS/CDNSKEY", RFC 8078,
                DOI 10.17487/RFC8078, March 2017,
                <https://www.rfc-editor.org/rfc/rfc8078>.

     [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
                Algorithm (EdDSA) for DNSSEC", RFC 8080,
                DOI 10.17487/RFC8080, February 2017,
                <https://www.rfc-editor.org/rfc/rfc8080>.

     [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
                DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
                July 2017, <https://www.rfc-editor.org/rfc/rfc8198>.

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

     [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8552>.

     [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
                Kasten, "Automatic Certificate Management Environment
                (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
                <https://www.rfc-editor.org/rfc/rfc8555>.

     [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
                Requirements and Usage Guidance for DNSSEC", RFC 8624,
                DOI 10.17487/RFC8624, June 2019,
                <https://www.rfc-editor.org/rfc/rfc8624>.

     [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
                to Improve DNS Resiliency", RFC 8767,
                DOI 10.17487/RFC8767, March 2020,
                <https://www.rfc-editor.org/rfc/rfc8767>.

     [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
                a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
                <https://www.rfc-editor.org/rfc/rfc8806>.

     [RFC8976]  Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
                Hardaker, "Message Digest for DNS Zones", RFC 8976,
                DOI 10.17487/RFC8976, February 2021,
                <https://www.rfc-editor.org/rfc/rfc8976>.





  Mozley, et al.            Expires 19 April 2026                [Page 36]


  Internet-Draft                   BANDAID                    October 2025


     [RFC9018]  Sury, O., Toorop, W., Eastlake 3rd, D., and M. Andrews,
                "Interoperable Domain Name System (DNS) Server Cookies",
                RFC 9018, DOI 10.17487/RFC9018, April 2021,
                <https://www.rfc-editor.org/rfc/rfc9018>.

     [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
                and Parameter Specification via the DNS (SVCB and HTTPS
                Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
                November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

     [RFC9462]  Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
                Jensen, "Discovery of Designated Resolvers", RFC 9462,
                DOI 10.17487/RFC9462, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9462>.

     [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
                and T. Jensen, "DHCP and Router Advertisement Options for
                the Discovery of Network-designated Resolvers (DNR)",
                RFC 9463, DOI 10.17487/RFC9463, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9463>.

  Acknowledgments

     The authors thank Ross Gibson for his contributions, questions and
     comments.

  Authors' Addresses

     Jim Mozley
     Infoblox, Inc.
     Email: jmozley@infoblox.com


     Nic Williams
     Infoblox, Inc.
     Email: nic@infoblox.com


     Behcet Sarikaya
     Unaffiliated
     Email: sarikaya@ieee.org


     Roland Schott
     Deutsche Telecom
     Email: roland.schott@telekom.de





  Mozley, et al.            Expires 19 April 2026                [Page 37]


name: draft-rosenberg-aiproto
rev: 00
title: Normalized API for AI Agents Calling Tools (N-ACT)
time: 2025-10-20T01:54:27Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T01:54:27Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-05-22T09:24:44.863416+00:00
source: ietf
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
     Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
     "enact" - 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: 22 April 2026                                           Bitwave
                                                           19 October 2025


             Normalized API for AI Agents Calling Tools (N-ACT)
                         draft-rosenberg-aiproto-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
     Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
     "enact" - 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 22 April 2026.





  Rosenberg & White         Expires 22 April 2026                 [Page 1]


  Internet-Draft                    N-ACT                     October 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 N-ACT 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 22 April 2026                 [Page 2]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                 [Page 3]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                 [Page 4]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                 [Page 5]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                 [Page 6]


  Internet-Draft                    N-ACT                     October 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 N-ACT 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 22 April 2026                 [Page 7]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                 [Page 8]


  Internet-Draft                    N-ACT                     October 2025


  3.  Problem Statement

     There are multiple problems that are addressed by N-ACT, 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 22 April 2026                 [Page 9]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 10]


  Internet-Draft                    N-ACT                     October 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 N-ACT Protocol Goals

     The N-ACT protocol (N-ACT is pronounced like the word enact)
     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

     *  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



  Rosenberg & White         Expires 22 April 2026                [Page 11]


  Internet-Draft                    N-ACT                     October 2025


        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

     N-ACT 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 N-ACT 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

     N-ACT 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 N-ACT 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)

     Invoking a tool requires the following to be provided:

     *  the name of the tool



  Rosenberg & White         Expires 22 April 2026                [Page 12]


  Internet-Draft                    N-ACT                     October 2025


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

     Consequently, the N-ACT protocol defines two JSON objects - the
     signature, and the invocation.  The N-ACT 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 N-ACT 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.

     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.



  Rosenberg & White         Expires 22 April 2026                [Page 13]


  Internet-Draft                    N-ACT                     October 2025


     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 N-ACT, 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 N-ACT 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.  N-ACT
     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 N-ACT 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.

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

     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.





  Rosenberg & White         Expires 22 April 2026                [Page 14]


  Internet-Draft                    N-ACT                     October 2025


     The N-ACT 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 N-ACT addresses it by natively adding
     version support.

     The N-ACT 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, N-ACT 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

     N-ACT 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 22 April 2026                [Page 15]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 16]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 17]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 18]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 19]


  Internet-Draft                    N-ACT                     October 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 22 April 2026                [Page 20]


  Internet-Draft                    N-ACT                     October 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

     N-ACT 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 N-ACT for cases
     where more designer control is appropriate).

  8.1.  Similarities

     Both MCP and N-ACT support APIs for enumerating tools and invoking
     tools.

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

  8.2.  Differences

     The biggest difference is the assumption in control.  N-ACT 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 N-ACT, 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.  N-ACT, 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 22 April 2026                [Page 21]


  Internet-Draft                    N-ACT                     October 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 N-ACT, 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, N-ACT is more compatible
     with Anthropic's skills concept, than it is with its MCP protocol.
     Indeed, N-ACT 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.
     N-ACT 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.  N-ACT 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).  N-ACT 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.  N-ACT
     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 22 April 2026                [Page 22]


  Internet-Draft                    N-ACT                     October 2025


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
















































  Rosenberg & White         Expires 22 April 2026                [Page 23]


