# drafts

name: draft-rosenberg-aiproto-cheq
rev: 00
title: CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)
time: 2025-10-20T02:19:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:19:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Human-agent interaction", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127624+00:00
abstract:
This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP), the Agent-to-Agent
   (A2A) protocol, and the Normalized API for AI Agent Calling Tools
   (N-ACT) protocol.  It makes use of a signed object which can be
   carried in those protocols.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                             C. Jennings
                                                                   Cisco
                                                         19 October 2025


 CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                              Loop (HITL)
                    draft-rosenberg-aiproto-cheq-00

Abstract

   This document proposes Confirmation with Human in the Loop (HITL)
   Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
   decisions and actions proposed by AI Agents prior to those decisions
   being acted upon.  It also allows humans to provide information
   required for tool invocation, without disclosing that information to
   the AI agent, protecting their privacy.  CHEQ aims to guarantee that
   AI Agent hallucinations cannot result in unwanted actions by the
   human on whose behalf they are made.  CHEQ can be integrated into
   protocols like the Model Context Protocol (MCP), the Agent-to-Agent
   (A2A) protocol, and the Normalized API for AI Agent Calling Tools
   (N-ACT) protocol.  It makes use of a signed object which can be
   carried in those protocols.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 22 April 2026.







Rosenberg, et al.         Expires 22 April 2026                 [Page 1]

Internet-Draft                    CHEQ                      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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architectural Framework . . . . . . . . . . . . . . . . . . .   4
   4.  Overview of Operation . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Triggering Confirmation . . . . . . . . . . . . . . . . .   7
     4.2.  Performing Confirmation . . . . . . . . . . . . . . . . .   9
     4.3.  Finalizing  . . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Using CHEQ for Data Privacy . . . . . . . . . . . . . . . . .  12
   6.  Usage with MCP and A2A and N-ACT  . . . . . . . . . . . . . .  13
   7.  Usage with Voice Interfaces . . . . . . . . . . . . . . . . .  13
   8.  Detailed Protocol Specification . . . . . . . . . . . . . . .  13
     8.1.  URI Pack Syntax and Semantics . . . . . . . . . . . . . .  13
     8.2.  CHEQ Object Syntax and Semantics  . . . . . . . . . . . .  13
     8.3.  CHEQ Protocol Details . . . . . . . . . . . . . . . . . .  14
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
   10. Informative References  . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   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.  It
   identifies a critical unmet need in the current protocol landscape -
   human confirmation.

   Consider the following use case: a user is chatting with a travel
   agent AI Agent.  This AI Agent helps users search for travel
   destinations based on preferences, compare flight and hotel costs,
   make bookings and adjust plans.  The user is discussing with the AI



Rosenberg, et al.         Expires 22 April 2026                 [Page 2]

Internet-Draft                    CHEQ                      October 2025


   Agent whether to take business or coach.  There is a long back and
   forth conversation about this.  Finally the user says, "go ahead and
   book it".  The AI Agent misinterprets the conversation, and chooses
   business class, despite the user's desire for coach.  It invokes a
   tool call on the flight system, acting on behalf of the user, and
   books the expensive flight that the user cannot afford.

   A more troubling use case is when a user interacts with a banking AI
   Agent, and requests transfer of funds.  To facilitate the tranfer,
   the user provides the AI agent with their account information.  The
   LLM hallucinates the account number, and results in funds being
   deposited into the wrong account.  This use case is doubly
   troublesome - not only has the user lost money, but they have leaked
   sensitive information (their account number) to an LLM.

   This document proposes a new protocol, called "Confirmation with
   Human in the Loop (HITL) Exchange of Quotations" - or CHEQ for short.
   The CHEQ protocol defines an object - the CHEQ - which memorializes a
   decision made by a human, and provides a cryptographic signature of
   it by an identity provides which authenticates the user.  It also
   defines a new protocol that allows for an API server to request
   information collection and/or confirmation outside of the scope of
   the LLM.

   Since CHEQ primarily involves the exchange of URLs within existing
   protocols, it is relatively easily embedded into emerging AI
   protocols, include the Model Context Protocol (MCP)
   (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, the Agent2Agent (A2A) Protocol, driven by Google
   (https://google.github.io/A2A/#/documentation?id=agent2agent-
   protocol-a2a (https://google.github.io/
   A2A/#/documentation?id=agent2agent-protocol-a2a)) and now under
   governance of the Linux Foundation, or the Normalized API for AI
   Agent Calling Tools (N-ACT) [I-D.rosenberg-aiproto-nact].  CHEQ is
   specifically designed to fit into the elicitation model under
   consideration with MCP.

2.  Requirements

   The requirements driving this protocol are as follows:

   *  The protocol must enable a human being to provide confirmation of
      an action that an AI Agent wishes to take

   *  The protocol must not depend on the LLM itself, so that it is not
      subject to LLM accuracy for proper operation




Rosenberg, et al.         Expires 22 April 2026                 [Page 3]

Internet-Draft                    CHEQ                      October 2025


   *  The protocol must provide cryptographic assurances that the human
      being approves the action

   *  The protocol must support a wide variety of actions, such as API
      invocations, workflows, batch operations, and so on.  It must not
      be specific to any particular API or API function

   *  The protocol must work with existing user authentication
      techniques

   *  The protocol must protect against AI agents replaying past
      confirmations

   *  The protocol must enable non-repudiation of confirmations made by
      a human being, so that a resource server has evidence that a user
      provided confirmation

   *  The protocol must enable resource servers to collect information
      from users needed to complete a tool call, without disclosing that
      information to an LLM (privacy)

   *  It must be possible to memorialize confirmations into an object,
      so that they can be exchanged between systems, along with the
      cryptographic content needed to validate user confirmation.  This
      is essential for non-repudiation

   *  It must be possible for the end user to clearly know that the
      confirmation step is outside of the scope of the LLM, to provide
      confidence to them that they are in fact performing confirmation
      that is not subject to LLM hallucination

   *  It must be possible for the user confirmation to be performed by
      trusted third parties, separate from the organization owning the
      resource server.  This is a potentially controversial requirement.
      It stems from the desire to put control in the hands of end users
      in selecting a provider that they trust to confirm actions that AI
      Agents are taking on their behalf.

   *  The protocol must be easily integrated with MCP, A2A, N-ACT and
      similar tool call protocols

3.  Architectural Framework









Rosenberg, et al.         Expires 22 April 2026                 [Page 4]

Internet-Draft                    CHEQ                      October 2025


          +---------------------------------------+
          |                                       |
          |                                       |
   +------+-------+      +----------+       +-----v----+
   |              |      |          |       |          |
   | Confirmation |      | AI Agent +------>| Resource |
   | Server       |      |          |       | Server   |
   |              |      +----------+       |          |
   +--------------+           ^             +----------+
          ^                   |
          |              +----+-----+
          |              |          |
          +--------------+ User     |
                         | App      |
                         +----------+
                              ^
                              |
                         +----+-----+
                         |          |
                         | User     |
                         |          |
                         +----------+

                   Figure 1: CHEQ Architecture Framework

   The end user engages with an AI Agent via a User App. Often the user
   app is a browser application.  It could also be a thick desktop
   application.  The AI Agent typically runs on a server, though it
   could be running inside of the user app.  The AI agent includes an
   LLM along with an executor.  The executor formulates the inputs to
   the LLM, and processes its output.  The executor invokes APIs at the
   request of the LLM.  It does that by invoking the API on a resource
   server.  Such invocation could be via MCP, or could be direct API
   invocation.

   CHEQ introduces a new server, the Confirmation Server.  The
   Confirmation Server is responsible for rendering the information to
   be confirmed to the user, collecting their confirmation, and
   memorializing it by signing an object (the CHEQ object, which can
   then be passed back to the resource server.

   The confirmation server is a highly trusted entity in this system.
   The user trusts it to perform the confirmation operation.  We
   anticipate that users may desire to have this function centralized
   across many different API services, so that users have a single point
   of accountability and audit of decisions that have been confirmed.
   As an example, a trusted third party - something like Lets Encrypt -
   might run such a service, which users could adopt.



Rosenberg, et al.         Expires 22 April 2026                 [Page 5]

Internet-Draft                    CHEQ                      October 2025


   We also anticipate a common deployment model is that each resource
   provider has the confirmation server for its services, integrated
   into the resource server.

   CHEQ makes several key assumptions about the trust relationships in
   the system:

   1.  The user is known to both the resource service, and to the
       confirmtion service.

   2.  The user is capable of directly authenticating itself to the
       confirmation service, and therefore has a relationship with it,
       having an account of some sorts on it.

   3.  The resource service knows of, and trusts the confirmation
       service to perform confirmation.  The resource service can obtain
       an OAuth token, most likely via a client credential grant, on the
       resource service, in order to use the CHEQ protocol.

   The CHEQ protocol is relatively simple, with two parts.  The first is
   a means to convey the URIs from the API server to the AI agent and
   User application.  The second is protocol for the confirmation server
   to talk to the API server.  This second part is not needed when they
   are the same.

4.  Overview of Operation

   The sequence diagram for the protocol is shown here:























Rosenberg, et al.         Expires 22 April 2026                 [Page 6]

Internet-Draft                    CHEQ                      October 2025


participant user as "End User"
participant exec as "AI Agent - Executor"
participant llm as "AI Agent - LLM"
participant confirm as "Confirmation Server"
participant api as "API Server"

user->exec: "please book flight "
exec->llm: add user msg to context\nrun inference
llm->exec: tool call\nAPI=book\nflight=UA1234\ndate=8 August 2025, 12:20 EDT
exec->api: POST airline/book?{details}
api->exec: 202 Accepted\nJSON w. resource URI, confirmation URI, result URI
note right of exec: remember result URI
exec->user: pass URIs to browser
user->confirm: POST confirmation URI?resource URI
user->confirm: login
confirm->api: retrieve CHEQ object
api->confirm: CHEQ object
confirm->user: render information to confirm
user->confirm: click confirmation button
note right of confirm: sign cheq
confirm->api: send signed cheq
api->confirm: success
confirm->user: confirmed

note right of exec: polling
exec->api: retrieve result from result URI
api->exec: final result
exec->llm: add result to context
llm->exec: send msg\n"congrats your flight is booked"

                 Figure 2: Sequence Diagram for CHEQ

   There are three parts of the flow: trigger confirmation, performing
   confirmation, and finalizing.

4.1.  Triggering Confirmation

   When an AI Agent makes a decision to perform a tool call of some
   sort, it uses MCP, N-ACT, or directly invokes the API on the server
   that provides the tool (which is what is shown in the diagram for
   ease of understanding).  For example, it might invoke a REST API for
   performing a flight booking on an airline.  The AI Agent will have
   some form of OAuth [I-D.ietf-oauth-v2-1] token, either granted by the
   user or perhaps associated with a service account.

   The server recognizes the invocation as being associated with an AI
   Agent.  It can do this using a number of different techniques,
   including the client ID associated with the access token, the source



Rosenberg, et al.         Expires 22 April 2026                 [Page 7]

Internet-Draft                    CHEQ                      October 2025


   IP address, or the service account used by the AI Agent.  Future
   solutions that formalize the authentication and identification of AI
   Agents, such as [I-D.meunier-web-bot-auth-architecture], can provide
   more robust ways to identify that the request is an AI Agent
   operating on a user's behalf.

   The resource server - the airline here - would be configured with
   policies that specify which API requests, when invoked by an AI
   Agent, require human confirmation.  That configuration could be
   provided ahead of time by the end user through the web site of the
   resource owner, or through policies defined by the provider
   themselves.  For example, the airline website might serve a UI which
   has radio buttons indicating that flight booking for flights over
   $100 require confirmation.  There are no new protocols required to do
   this.  CHEQ only requires that such policies have been configured
   ahead of time.

   The resource server would also be configured - by the end user or
   through its own administration - on what confirmation server it uses.
   This could be itself, or it could be a third party server.

   If the policy indicates that the resource server requires human
   confirmation, and the request is being made by an AI Agent, it
   responds with a 202 Accepted response.  This indicates that the
   server requires confirmation to complete the request.  The response
   includes a body, which we call the URI package, defined by this
   specification.  It includes three URIs which need to be conveyed
   between components.  The URIs are:

   1.  The confirmation server URI.  This is a raw URI, without any
       parameters.  The confirmation server must be one that the end
       user has a relationship with.  For example, if LetsEncrypt were
       to run a confirmation server, this might be
       https://confirmation.letsencrypt.org
       (https://confirmation.letsencrypt.org).  This is the URI that the
       user application will invoke in a browser to request user
       confirmation.

   2.  The resource URI.  This URI is minted by the resource server.
       This URI is used for the CHEQ protocol communication from the
       confirmation server to the resource server, as defined by this
       protocol.  The URI should reference the specific transaction
       which is being confirmed.  The resource server can embed that
       information into the URI however it likes.







Rosenberg, et al.         Expires 22 April 2026                 [Page 8]

Internet-Draft                    CHEQ                      October 2025


   3.  The result URI.  This URI is also minted by the resource server.
       It is used by the AI agent to obtain the final results of the API
       transaction.  It would also embed a transaction identifier so the
       resource server knows how to return the right response.

   The URI pack looks like this:

{
   "confirmation uri" : "https://confirmation.letsencrypt.org",
   "resource uri" : "https://api.airline.com/confirmations/8asdjd8g9g0as",
   "result uri" : "https://api.airline.com/results/nn88kak0s0d8jj39sla"

}

                      Figure 3: URI Pack Example

   The URI pack is passed to the AI agent (which extracts the result URI
   in particular) and then to the user application.  The means for such
   conveyance are flexible, and not constrained by this spec.  If there
   is an MCP server between the resource server and the AI Agent, the
   MCP server might perform a special form of elicitation, passing these
   parameters.  This would perhaps require an MCP extension.
   Alternatively, it can be added to N-ACT via an extension to that
   protocol.

4.2.  Performing Confirmation

   Once the URI pack arrives at the user application, the user
   application extracts the confirmation URI, and performs a POST to the
   confirmation server, passing the resource URI as a parameter afer
   URI-encoding it.  The confirmation server needs this URI.

   The confirmation server first ensures that the end user is
   authenticated.

   The CHEQ protocol assumes that the confirmation server has a security
   relationship with the end user, such that the user is able to
   authenticate itself to the server.  The means for such authentication
   is outside of the scope of CHEQ, and any existing technqiues will
   suffice.  FUrthermore, CHEQ does not attempt to verify that the user
   is actually a human being.  It assumes that the authentication
   process is sufficient to demonstrate that the user is who they say
   they are.  If the user is not logged in, the confirmation server
   would request a login process.  The confirmation server does not need
   to be the login server.






Rosenberg, et al.         Expires 22 April 2026                 [Page 9]

Internet-Draft                    CHEQ                      October 2025


   The confirmation server will receive the resource URI in the POST
   from the user application.  It will use that URI, which points to the
   resource server, and invoke the retrieve cheq function on the
   resource server:

   GET {resource-server}/cheq

   It will authenticate using whatever service account it has with the
   resource provider.  The response comes back, and it contains a CHEQ
   object.  This object contains the information to be verified with the
   user.  The CHEQ object is signed by the resource provider, so it
   cannot be tampered with.

   The CHEQ includes the API being invoked (e.g., book flight), the
   input parameters (eg., the flight number and date), facts (e.g., the
   price of the flight) and explanatory information meant for human
   consumption (e.g "this is the overnight flight from Newark to
   Madrid").

   The following is an example of what the CHEQ looks like:

{
   "version" : 1.0,
   "operation" : "https://airline.com/api/v1/book-flight",
   "operation name" : "Book airline",

   "inputs" : {
      "parameters" : [
         {
            "parameter name" : "flight number",
            "parameter description" : "The overnight flight from EWR to MAD",
            "parameter value" : "UA23"
         },
         {
            "parameter name" : "flight date",
            "parameter value" : "8 August 2025, 12:20 EDT"
         },
         {
            "parameter name" : "flight cost",
            "parameter value" : "$1200 USD"
         },

      ]

   },

   "date" : "July 23, 2025, 11:59 UTC",
}



Rosenberg, et al.         Expires 22 April 2026                [Page 10]

Internet-Draft                    CHEQ                      October 2025


                        Figure 4: CHEQ Object

   In the CHEQ object, the parameter values are the actual values which
   will show up in the API invocations.  The names and descriptions are
   used to provide information to the end user.  THey represent
   important information that helps the user decide whether to confirm
   or not, and because they factor into decision making, also need to be
   memorialized into the object and its signatures.

   The names and descriptions need to be provided in the language
   preferred by the end user.  Because the resource server knows the end
   user, it can use whatever its default language is for that user.

   The confirmation server renders a confirmation UI to the user.  The
   user can decide to accept or reject it.  If the user accepts, the
   confirmation server adds its own signature (signature details and
   multi-signature syntax TBD).  Else, the user rejects it.

   Based on the user decision, the confirmation server does one of two
   things.  If the user accepted, the newly signed CHEQ is posted to the
   resource server:

   POST {resource URI}?accept {body contains signed CHEQ}

   Else, if the user rejected it:

   POST {resource URI}?reject

   The resource server then updates the state of the resource
   accordingly.

4.3.  Finalizing

   The final step of the process is conveyance of the final result to
   the AI agent.

   The AI Agent will poll the resource server for updates.
   Alternatively, if MCP is used, the MCP server will poll for updates,
   and then provide an update to the AI Agent once the finalized result
   is obtained.  If N-ACT is being used, it can be extended to add
   support for this API.

   Once the resource server has receive the acceptance (or rejection),
   it can respond to request from the AI Agent with the result, and the
   AI agent can proceed.






Rosenberg, et al.         Expires 22 April 2026                [Page 11]

Internet-Draft                    CHEQ                      October 2025


5.  Using CHEQ for Data Privacy

   The CHEQ protocol has an important property that the confirmation
   process happens outside of the scope of the LLM.  This enables CHEQ
   to be used in cases where the user does not wish to provide sensitive
   information to the AI Agent.

   In these cases, the confirmation server function is subsumed into the
   resource server.

   Consider the following example.  Instead of a flight booking, the
   user is using an AI Agent to transfer funds between bank accounts.
   This requires highly sensitive information - most notably the origin
   and destination account numbers.  The user does not wish to expose
   this information to the AI Agent, and specificaly, to the underlying
   LLM.

   To address this, the banking service can implement an API for
   transferrig funds, which is meant specifically for usage with CHEQ.
   This API would not take the parameters normally required for a
   transfer - no account numbers, no dollar amounts.  Instead, the API
   is just "transfer funds".  This API can be turned into a tool by the
   MCP server, which the AI Agent can decide to invoke.  When it is
   invoked, the banking server immediately responds with the 202 and
   passes the URI package.  In this use case, the confirmation server is
   the same as the resource server.  When the user application connects
   to the resource server to perform the confirmation, the resulting UI
   can be used for the actual data collection.  Once the data is
   collected, the AI Agent gets the results - merely that the data was
   transferred.  In this application of the CHEQ protocol, only the URI
   pack is ever sent on the wire.  The CHEQ object never needs to be
   generated, because the resource and confirmation server are the same.
   Indeed, the CHEQ would have contained sensitive information (the
   account numbers).

   In this case, we have enabled AI agents to work with users on complex
   tasks which require data collection that can be hidden from the AI
   Agent, achieving data privacy.

   The decision on which APIs require private data, and require CHEQ to
   be used, is made by the resource service.










Rosenberg, et al.         Expires 22 April 2026                [Page 12]

Internet-Draft                    CHEQ                      October 2025


6.  Usage with MCP and A2A and N-ACT

   CHEQ can easily be integrated into MCP, so that an MCP server sits
   between the AI Agent and the resource server in the diagram above.
   It requires an extension to the elicitation specifications, enabling
   the URI pack to be transferred from the resource server, through MCP,
   to the AI Agent.

   In a similar way, CHEQ can be integrated into A2A.  If Agent 1
   connects to Agent 2, and Agent 2 wishes to request user confirmation,
   Agent 2 can take the URI pack, pass it backwards through A2A to agent
   1, which passes it to its user.

   CHEQ can also easily be added to N-ACT, by adding it directly to that
   protocol.

7.  Usage with Voice Interfaces

   Modern AI Agents can also make use of voice interfaces towards the
   user.  The CHEQ protocol works equally well in this case, with a
   slightly different flow.

   Consider the User Application in this case as a voice gateway,
   receiving the voice traffic from the user and integrating it into the
   AI Agent.  This function may be co-located with the AI Agent, or it
   could be a separate component that (for example) is doing speech to
   text and speech synthesis in front of a text-based AI Agent.

   In either case, when the user application receives the URI pack,
   instead of passing this onto the user's web browser, it would connect
   to the confirmation server and retrieve a "raw" version of the CHEQ,
   read it out over voice, gain user appoval via voice, and then post
   that to the confirmation server.  This does require the confirmation
   server to support a flow which is amenable to rendering as voice, not
   HTML.

8.  Detailed Protocol Specification

8.1.  URI Pack Syntax and Semantics

   Details to be filled in.

8.2.  CHEQ Object Syntax and Semantics

   Details to be filled in






Rosenberg, et al.         Expires 22 April 2026                [Page 13]

Internet-Draft                    CHEQ                      October 2025


8.3.  CHEQ Protocol Details

   Details to be filled in

9.  Conclusions

   The CHEQ protocol provides a way for end users to confirm actions
   taken by AI Agents.  It does so outside of the LLM and AI Agent
   itself, eliminating any risk of the LLM hallucinating a tool call
   that the user does not desire.  The usage of out-of-band UI also
   provides a technique for data privacy, enabling AI agents to perform
   sensitive operations (like banking transfers) where the user does not
   wish to provide the sensitive information to the AI Agent.

10.  Informative References

   [I-D.ietf-oauth-v2-1]
              Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
              Authorization Framework", Work in Progress, Internet-
              Draft, draft-ietf-oauth-v2-1-14, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              v2-1-14>.

   [I-D.meunier-web-bot-auth-architecture]
              Meunier, T., "HTTP Message Signatures for automated
              traffic Architecture", Work in Progress, Internet-Draft,
              draft-meunier-web-bot-auth-architecture-03, 29 August
              2025, <https://datatracker.ietf.org/doc/html/draft-
              meunier-web-bot-auth-architecture-03>.

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

   [I-D.rosenberg-aiproto-nact]
              Rosenberg, J. and P. White, "Normalized API for AI Agents
              Calling Tools (N-ACT)", Work in Progress, Internet-Draft,
              draft-rosenberg-aiproto-nact-00, 19 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-rosenberg-
              aiproto-nact-00>.

Authors' Addresses

   Jonathan Rosenberg
   Five9



Rosenberg, et al.         Expires 22 April 2026                [Page 14]

Internet-Draft                    CHEQ                      October 2025


   Email: jdrosen@jdrosen.net


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


   Cullen Jennings
   Cisco
   Email: fluffy@cisco.com








































Rosenberg, et al.         Expires 22 April 2026                [Page 15]


name: draft-ietf-dnsop-ds-automation
rev: 04
title: Operational Recommendations for DS Automation
time: 2026-02-27T11:48:18Z
group_uri: /api/v1/group/group/1452/
expires: 2026-08-17T12:02:44Z
shepherd: /api/v1/person/email/shuque@gmail.com/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/43/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:05.127628+00:00
abstract:
Enabling support for automatic acceptance of DS parameters from the
   Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
   agent, often a registry or registrar, to make a number of technical
   decisions around acceptance checks, error and sucess reporting, and
   multi-party issues such as concurrent updates.  This document
   describes how these points are best addressed in practice.

full_text:
DNSOP Working Group                                             S. Sheng
Internet-Draft                                                          
Intended status: Best Current Practice                      P. Thomassen
Expires: 17 August 2026                                            deSEC
                                                        13 February 2026


             Operational Recommendations for DS Automation
                   draft-ietf-dnsop-ds-automation-04

Abstract

   Enabling support for automatic acceptance of DS parameters from the
   Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
   agent, often a registry or registrar, to make a number of technical
   decisions around acceptance checks, error and sucess reporting, and
   multi-party issues such as concurrent updates.  This document
   describes how these points are best addressed in practice.

Discussion Venues

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

   Discussion of this document takes place on the Domain Name System
   Operations Working Group mailing list (dnsop@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/dnsop/.

   Source for this draft and an issue tracker can be found at
   https://github.com/peterthomassen/draft-shetho-dnsop-ds-automation.

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





Sheng & Thomassen        Expires 17 August 2026                 [Page 1]

Internet-Draft                DS Automation                February 2026


Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
   2.  Acceptance Checks and Safety Measures . . . . . . . . . . . .   4
     2.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Continuity of Resolution  . . . . . . . . . . . . . .   5
       2.2.2.  TTLs and Caching  . . . . . . . . . . . . . . . . . .   6
       2.2.3.  CDS vs. CDNSKEY . . . . . . . . . . . . . . . . . . .   6
   3.  Reporting and Transparency  . . . . . . . . . . . . . . . . .   7
     3.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Registration Locks  . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .  10
     4.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.2.1.  Registrar vs. Registry Lock . . . . . . . . . . . . .  11
       4.2.2.  Detailed Rationale  . . . . . . . . . . . . . . . . .  12
   5.  Multiple Submitting Parties . . . . . . . . . . . . . . . . .  13
     5.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  14
       5.2.1.  Necessity of Non-automatic Updates  . . . . . . . . .  14
       5.2.2.  Impact of Non-automatic Updates: When to Suspend
               Automation  . . . . . . . . . . . . . . . . . . . . .  15
       5.2.3.  Concurrent Automatic Updates  . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Appendix A.  Terminology  . . . . . . . . . . . . . . . . . . . .  20
   Appendix B.  Recommendations Overview . . . . . . . . . . . . . .  21
     B.1.  Acceptance Checks and Safety Measures . . . . . . . . . .  21



Sheng & Thomassen        Expires 17 August 2026                 [Page 2]

Internet-Draft                DS Automation                February 2026


     B.2.  Reporting and Transparency  . . . . . . . . . . . . . . .  22
     B.3.  Registration Locks  . . . . . . . . . . . . . . . . . . .  22
     B.4.  Multiple Submitting Parties . . . . . . . . . . . . . . .  22
   Appendix C.  Change History (to be removed before publication)  .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   [RFC7344], [RFC8078], [RFC9615] automate DNSSEC delegation trust
   maintenance by having the child publish CDS and/or CDNSKEY records
   which indicate the delegation's desired DNSSEC parameters ("DS
   automation").

   Parental Agents using these protocols have to make a number of
   technical decisions relating to issues of acceptance checks, timing,
   error reporting, locks, etc.  Additionally, when using the RRR model
   (as is common amongst top-level domains), both the registrar and the
   registry can effect parent-side changes to the delegation.  In such a
   situation, additional opportunities for implementation differences
   arise.

   Not all existing DS automation deployments have made the same choices
   with respect to these questions, leading to somewhat inconsistent
   behavior.  From the perspective of a domain holder with domain names
   under various TLDs, this may be unexpected and confusing.

   New deployments of DS automation therefore SHOULD follow the
   recommendations set out in this document, both to achieve a more
   uniform treatment across suffixes — minimizing user surprise — and to
   prevent disruption of DNS and DNSSEC functionality.  The
   recommendations are intended to provide baseline safety and
   uniformity of behavior across parents.  Registries with additional
   requirements on DS update checks MAY implement any additional checks
   in line with local policy.

   In the following sections, operational questions are first raised and
   answered with the corresponding recommendations.  Each section is
   concluded with an analysis of its recommendations, and related
   considerations.  A combined view of the recommendations from all
   sections is given in Appendix B.

   Readers are expected to be familiar with DNSSEC
   [RFC9364][RFC9615][RFC9859].  For terminology, see Appendix A.








Sheng & Thomassen        Expires 17 August 2026                 [Page 3]

Internet-Draft                DS Automation                February 2026


1.1.  Requirements Notation

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

2.  Acceptance Checks and Safety Measures

   This section provides recommendations to address the following
   questions:

   *  What kind of acceptance checks should be performed on DS
      parameters?

   *  Should these checks be performed upon acceptance, or also
      continually when in place?

   *  How do TTLs and caching impact DS provisioning?  How important is
      timing in a child key change?

   *  Are parameters for DS automation best conveyed as CDNSKEY or CDS
      records, or both?

2.1.  Recommendations

   1.  Entities performing automated DS maintenance SHOULD verify

       a.  the unambigious intent of each DS update request as per
           [I-D.ietf-dnsop-cds-consistency], by checking its consistency
           both

           *  between any published CDS and CDNSKEY records, and

           *  across all authoritative nameservers in the delegation,

           and

       b.  that the resulting DS record set would allow continued DNSSEC
           validation if deployed,

       and cancel the update if the verifications do not succeed.








Sheng & Thomassen        Expires 17 August 2026                 [Page 4]

Internet-Draft                DS Automation                February 2026


   2.  Parent-side entities (such as registries) SHOULD reduce a DS
       record set's TTL to a value between 5–15 minutes when the set of
       records is changed, and restore the normal TTL value at a later
       occasion (but not before the previous DS RRset's TTL has
       expired).

   3.  DNS operators SHOULD publish both CDNSKEY records as well as CDS
       records, and follow best practice for the choice of hash digest
       type [DS-IANA].

2.2.  Analysis

2.2.1.  Continuity of Resolution

   To maintain the basic resolution function, it is important to avoid
   the deployment of flawed DS record sets in the parent zone.  It is
   therefore desirable for the Parent to verify that the DS record set
   resulting from an automated (or even manual) update does not break
   DNSSEC validation if deployed, and otherwise cancel the update.

   This is best done by

   1.  verifying that consistent CDS/CDNSKEY responses are served by all
       of the delegation's nameservers [I-D.ietf-dnsop-cds-consistency];

   2.  verifying that the resulting DS RRset does not break the
       delegation if applied ([RFC7344], Section 4.1), i.e., that it
       provides at least one valid path for validators to use
       ([RFC6840], Section 5.11).  This is the case if the child's
       DNSKEY RRset has a valid RRSIG signature from a key that is
       referenced by at least one DS record, with the digest type and
       signing algorithm values designated as "RECOMMENDED" or "MUST" in
       the "Use for DNSSEC Validation" columns of the relevant IANA
       registries ([DS-IANA] and [DNSKEY-IANA]).  (These checks need not
       be enforced when provisioning DS records manually in order to
       enable the use other digest types or algorithms for potentially
       non-interoperable purposes.)

   Even without an update being requested, Parents MAY occasionally
   check whether the current DS contents would still be acceptable if
   they were newly submitted in CDS/CDNSKEY form (see Section 2).  Any
   failures — such as a missing DNSKEY due to improper rollover timing
   ([RFC6781], Section 4.1), or changed algorithm requirements — MAY be
   communicated in line with Section 3.  The existing DS record set MUST
   NOT be altered or removed as a result of such checks.






Sheng & Thomassen        Expires 17 August 2026                 [Page 5]

Internet-Draft                DS Automation                February 2026


2.2.2.  TTLs and Caching

   To further reduce the impact of any misconfigured DS record set — be
   it from automated or from manual provisioning — the option to quickly
   roll back the delegation's DNSSEC parameters is of great importance.
   This is achieved by setting a comparatively low TTL on the DS record
   set in the parent domain, at the cost of reduced resiliency against
   nameserver unreachability due to the earlier expiration of cached
   records.  The availability risk can be mitigated by limiting such
   TTLs to a brief time period after a change to the DS configuration,
   during which rollbacks are most likely to occur.

   Registries therefore should significantly lower the DS RRset's TTL
   for some time following an update.  Pragmatic values for the reduced
   TTL value range between 5–15 minutes.  Such low TTLs might be
   expected to cause increased load on the corresponding authoritative
   nameservers; however, recent research has demonstrated them to have
   negligible impact on the overall load of a registry's authoritative
   nameserver infrastructure [LowTTL].

   The reduction should be in effect at least for a couple of days and
   until the previous DS record set has expired from caches, that is,
   the period during which the low-TTL is applied typically will
   significantly exceed the normal TTL value.  When using EPP, the
   server MAY advertise its TTL policy via the domain <info> command
   described in [RFC9803], Section 2.1.1.2.

   While this approach enables quick rollbacks, timing of the desired DS
   update process itself is largely governed by the previous DS RRset's
   TTL, and therefore does not generally benefit from an overall speed-
   up.  Note also that nothing is gained from first lowering the TTL of
   the old DS RRset: such an additional step would, in fact, require
   another wait period while resolver caches adjust.  For the sake of
   completeless, there likewise is no point to increasing any DS TTL
   values beyond their normal value.

2.2.3.  CDS vs. CDNSKEY

   DS records can be generated from information provided either in DS
   format (CDS) or in DNSKEY format (CDNSKEY).  While the format of CDS
   records is identical to that of DS records (so the record data be
   taken verbatim), generation of a DS record from CDNSKEY information
   involves computing a hash.

   Whether a Parent processes CDS or CDNSKEY records depends on their
   preference:





Sheng & Thomassen        Expires 17 August 2026                 [Page 6]

Internet-Draft                DS Automation                February 2026


   *  Processing (and storing) CDNSKEY information allows the Parent to
      control the choice of hash algorithms.  The Parent may then
      unilaterally regenerate DS records with a different choice of hash
      algorithm(s) whenever deemed appropriate.

   *  Processing CDS information allows the Child DNS operator to
      control the hash digest type used in DS records, enabling the
      Child DNS operator to deploy (for example) experimental hash
      digests and removing the need for registry-side changes when
      additional digest types become available.

   The need to make a choice in the face of this dichotomy is not
   specific to DS automation: even when DNSSEC parameters are relayed to
   the Parent through conventional channels, the Parent has to make some
   choice about which format(s) to accept.

   As there exists no protocol for Child DNS Operators to discover a
   Parent's input format preference, it seems best for interoperability
   to publish both CDNSKEY as well as CDS records, in line with
   [RFC7344], Section 5.  The choice of hash digest type should follow
   current best practice [DS-IANA].

   Publishing the same information in two different formats is not
   ideal.  Still, it is much less complex and costly than burdening the
   Child DNS operator with discovering each Parent's current policy;
   also, it is very easily automated.  Operators should ensure that
   published RRsets are consistent with each other.

   If both RRsets are published, Parents are expected to verify
   consistency between them [I-D.ietf-dnsop-cds-consistency], as
   determined by matching CDS and CDNSKEY records using hash digest
   algorithms whose support is mandatory [DS-IANA].  (Consistency of CDS
   records with optional or unsupported hash digest types need not be
   enforced.)

   By rejecting the DS update if RRsets are found to be inconsistent,
   Child DNS operators are held responsible when publishing
   contradictory information.  Note that this does not imply a
   restriction to the hash digest types found in the CDS RRset: if no
   inconsistencies are found, the parent can publish DS records with
   whatever digest type(s) it prefers.

3.  Reporting and Transparency

   This section provides recommendations to address the following
   question:





Sheng & Thomassen        Expires 17 August 2026                 [Page 7]

Internet-Draft                DS Automation                February 2026


   *  Should a failed (or even successful) DS update trigger a
      notification to anyone?

3.1.  Recommendations

   1.  For certain DS updates (see analysis (Section 3.2)) and for DS
       deactivation, relevant points of contact known to the zone
       operator SHOULD be notified.

   2.  For error conditions, the child DNS operator and the domain's
       technical contact (if applicable) SHOULD be notified first.  The
       registrant SHOULD NOT be notified unless the problem persists for
       a prolonged amount of time (e.g., three days).

   3.  Child DNS operators SHOULD be notified using a report query
       [RFC9567] to the agent domain as described in ([RFC9859],
       Section 4).  Notifications to humans (domain holder) will be
       performed in accordance with the communication preferences
       established with the parent-side entity (registry or registrar).
       The same condition SHOULD NOT be reported unnecessarily
       frequently to the same recipient.

   4.  In the RRR model, registries performing DS automation SHOULD
       inform the registrar of any DS record changes via the EPP Change
       Poll Extension [RFC8590] or a similar channel.

   5.  The currently active DS configuration SHOULD be made accessible
       to the registrant (or their designated party) through the
       customer portal available for domain management.  The DS update
       history MAY be made available in the same way.

3.2.  Analysis

   When accepting or rejecting a DS update, it cannot be assumed that
   relevant parties are aware of what's happening.  For example, a
   registrar may not know when an automatic DS update is performed by
   the registry.  Similarly, a Child DNS operator may not be aware when
   their CDS/CDNSKEY RRsets are out of sync across nameservers, thus
   being ignored.

   To help involved parties act appropriately and in a timely manner,
   entities performing automated DS maintenance should report on
   conditions they encounter.  The following success situations may be
   of particular interest:

   1.  A DS RRset has been provisioned

       a.  manually;



Sheng & Thomassen        Expires 17 August 2026                 [Page 8]

Internet-Draft                DS Automation                February 2026


       b.  due to commencing DS automation (either via DNSSEC
           bootstrapping, or for the first time after a manual change;
           see Section 5);

       c.  automatically, as an update to an existing DS RRset that had
           itself been automatically provisioned.

   2.  The DS RRset has been removed

       a.  manually;

       b.  automatically, using a delete signal ([RFC8078], Section 4).

   In addition, there are error conditions worthy of being reported:

   3.  A pending DS update cannot be applied due to an error condition.
       There are various scenarios where an automated DS update might
       have been requested, but can't be fulfilled.  These include:

       a.  The new DS record set would break validation/resolution or is
           not acceptable to the Parent for some other reason (see
           Section 2).

       b.  A lock prevents DS automation (see Section 4).

   4.  No DS update is due, but it was determined that the Child zone is
       no longer compatible with the existing DS record set (e.g., DS
       RRset only references non-existing keys).

   For these reportworthy cases, the entity performing DS automation
   would be justified to attempt communicating the situation.  Potential
   recipients are:

   *  Child DNS operator, preferably by making a report query [RFC9567]
      to the agent domain listed in the EDNS0 Report-Channel option of
      the DS update notification that triggered the DS update
      ([RFC9859], Section 4), or else via email to the address contained
      in the child zone's SOA RNAME field (see Sections 3.3.13 and 8 of
      [RFC1035]);

   *  Registrar (if DS automation is performed by the registry);

   *  Registrant (domain holder; in non-technical language, such as
      "DNSSEC security for your domain has been enabled and will be
      maintained automatically") or technical contact, in accordance
      with the communication preferences established with the parent-
      side entity.




Sheng & Thomassen        Expires 17 August 2026                 [Page 9]

Internet-Draft                DS Automation                February 2026


   For manual updates (case 1a), commencing DS automation (case 1b), and
   deactivating DNSSEC (case 2), it seems worthwhile to notify both the
   domain's technical contact (if applicable) and the registrant.  This
   will typically lead to one notification during normal operation of a
   domain.  (Case 1c, the regular operation of automation, is not an
   interesting condition to report to a human.)

   For error conditions (cases 3 and 4), the registrant need not always
   be involved.  It seems advisable to first notify the domain's
   technical contact and the DNS operator serving the affected Child
   zone, and only if the problem persists for a prolonged amount of time
   (e.g., three days), notify the registrant.

   When the RRR model is used and the registry performs DS automation,
   the registrar should always stay informed of any DS record changes,
   e.g., via the EPP Change Poll Extension [RFC8590].

   The same condition SHOULD NOT be reported unnecessarily frequently to
   the same recipient (e.g., no more than twice in a row).  For example,
   when CDS and CDNSKEY records are inconsistent and prevent DS
   initialization, the registrant may be notified twice.  Additional
   notifications may be sent with some back-off mechanism (in increasing
   intervals).

   The current DS configuration SHOULD be made accessible to the
   registrant (or their designated party) through the customer portal
   available for domain management.  Ideally, the history of DS updates
   would also be available.  However, due to the associated state
   requirements and the lack of direct operational impact,
   implementation of this is OPTIONAL.

4.  Registration Locks

   This section provides recommendations to address the following
   question:

   *  How does DS automation interact with other registration state
      parameters, such as registration locks?

4.1.  Recommendations

   1.  To secure ongoing operations, automated DS maintenance SHOULD NOT
       be suspended based on a registrar update lock alone (such as EPP
       status clientUpdateProhibited).

   2.  When performed by the registry, automated DS maintenance SHOULD
       NOT be suspended based on a registry update lock alone (such as
       EPP status serverUpdateProhibited).



Sheng & Thomassen        Expires 17 August 2026                [Page 10]

Internet-Draft                DS Automation                February 2026


4.2.  Analysis

   Registries and registrars can set various types of locks for domain
   registrations, usually upon the registrant's request.  An overview of
   standardized locks using EPP, for example, is given in Section 2.3 of
   [RFC5731].  Some registries may offer additional (or other) types of
   locks whose meaning and set/unset mechanisms are defined according to
   a proprietary policy.

   While some locks clearly should have no impact on DS automation (such
   as transfer or deletion locks), other types of locks, in particular
   "update locks", deserve a closer analysis.

4.2.1.  Registrar vs. Registry Lock

   A registrar-side update lock (such as clientUpdateProhibited in EPP)
   protects against various types of accidental or malicious change
   (like unintended changes through the registrar's customer portal).
   Its security model does not prevent the registrar's (nor the
   registry's) actions.  This is because a registrar-side lock can be
   removed by the registrar without an out-of-band interaction.

   Under such a security model, no tangible security benefit is gained
   by preventing automated DS maintenance based on a registrar lock
   alone, while preventing it would make maintenance needlessly
   difficult.  It therefore seems reasonable not to suspend automation
   when such a lock is present.

   When a registry-side update lock is in place, the registrar cannot
   apply any changes (for security or delinquency or other reasons).
   However, it does not protect against changes made by the registry
   itself.  This is exemplified by the serverUpdateProhibited EPP
   status, which demands only that the registrar's "[r]equests to update
   the object [...] MUST be rejected" ([RFC5731], Section 2.3).  This
   type of lock therefore precludes DS automation by the registrar,
   while registry-side automation may continue.

   DS automation by the registry further is consistent with [RFC5731],
   Section 2.3, which explicitly notes that an EPP server (registry) may
   override status values set by an EPP client (registrar), subject to
   local server policies.  The risk that DS changes from registry-side
   DS automation might go unnoticed by the registrar is mitigated by
   sending change notifications to the registrar; see Recommendation 4
   of Section 3.







Sheng & Thomassen        Expires 17 August 2026                [Page 11]

Internet-Draft                DS Automation                February 2026


4.2.2.  Detailed Rationale

   Pre-DNSSEC, it was possible for a registration to be set up once,
   then locked and left alone (no maintenance required).  With DNSSEC
   comes a change to this operational model: the configuration may have
   to be maintained in order to remain secure and operational.  For
   example, the Child DNS operator may switch to another signing
   algorithm if the previous one is no longer deemed appropriate, or
   roll its SEP key for other reasons.  Such changes entail updating the
   delegation's DS records.

   If authenticated, these operations do not qualify as accidental or
   malicious change, but as legitimate and normal activity for securing
   ongoing operation.  The CDS/CDNSKEY method provides an automatic,
   authenticated means to convey DS update requests.  The resulting DS
   update is subject to the parent's acceptance checks; in particular,
   it is not applied when it would break the delegation (see Section 2).

   Given that registrar locks protect against unintended changes (such
   as through the customer portal) while not preventing actions done by
   the registrar (or the registry) themself, such a lock is not suitable
   for defending against actions performed illegitimately by the
   registrar or registry (e.g., due to compromise).  Any attack on the
   registration data that is feasible in the presence of a registrar
   lock is also feasible regardless of whether DS maintenance is done
   automatically; in other words, DS automation is orthogonal to the
   attack vector that a registrar lock protects against.

   Considering that automated DS updates are required to be
   authenticated and validated for correctness, it thus appears that
   honoring such requests, while in the registrant's interest, comes
   with no additional associated risk.  Suspending automated DS
   maintenance therefore does not seem justified.

   Following this line of thought, some registries (e.g., .ch/.cz/.li)
   today perform automated DS maintenance even when an "update lock" is
   in place.  Registries offering proprietary locks should carefully
   consider for each lock whether its scope warrants suspension.

   In case of a domain not yet secured with DNSSEC, automatic DS
   initialization is not required to maintain ongoing operation;
   however, authenticated DNSSEC bootstrapping [RFC9615] might be
   requested.  Besides being in the interest of security, the fact that
   a Child is requesting DS initialization through an authenticated
   method expresses the registrant's intent to have the delegation
   secured.





Sheng & Thomassen        Expires 17 August 2026                [Page 12]

Internet-Draft                DS Automation                February 2026


   Further, some domains are equipped with an update lock by default.
   Not honoring DNSSEC bootstrapping requests then imposes an additional
   burden on the registrant, who has to unlock and relock the domain in
   order to facilitate DS provisioning after registration.  This is a
   needless cost especially for large domain portfolios.  It is also
   unexpected, as the registrant already has arranged for the necessary
   CDS/CDNSKEY records to be published.  It therefore appears that DS
   initialization and rollovers should be treated the same way with
   respect to locks.

5.  Multiple Submitting Parties

   This section provides recommendations to address the following
   questions:

   *  How are conflicts resolved when DS parameters are accepted through
      multiple channels (e.g. via a conventional channel and via
      automation)?

   *  In case both the registry and the registrar are automating DS
      updates, how to resolve potential collisions?

5.1.  Recommendations

   1.  Registries and registrars SHOULD provide another (e.g., manual)
       channel for DS maintenance in order to enable recovery when the
       Child has lost access to its signing key(s).  This out-of-band
       channel is also needed when a DNS operator does not support DS
       automation or refuses to cooperate.

   2.  DS update requests SHOULD be executed immediately after
       verification of their authenticity, regardless of whether they
       are received in-band or via an out-of-band channel.

   3.  When processing a CDS/CDNSKEY "delete" signal to remove the
       entire DS record set ([RFC8078], Section 4), DS automation SHOULD
       NOT be suspended.  For all other removal requests (such as when
       received via EPP or a web form), DS automation SHOULD be
       suspended until a new DS record set has been provisioned, in
       order to prevent accidental re-initialization when the registrant
       intended to disable DNSSEC.

   4.  Whenever a non-empty DS record set is provisioned, through
       whichever channel, DS automation SHOULD NOT (or no longer) be
       suspended (including after an earlier removal).






Sheng & Thomassen        Expires 17 August 2026                [Page 13]

Internet-Draft                DS Automation                February 2026


   5.  In the RRR model, a registry SHOULD NOT automatically initialize
       DS records when it is known that the registrar does not provide a
       way for the domain holder to later disable DNSSEC.  If the
       registrar has declared to be performing automated DS maintenance,
       the registry SHOULD publish the registrar's [RFC9859]
       notification endpoint (if applicable) and refrain from registry-
       side DS automation.

5.2.  Analysis

   In the RRR model, there are multiple channels through which DS
   parameters can be accepted:

   *  The registry can retrieve information about an intended DS update
      automatically from the Child DNS Operator and apply the update
      directly;

   *  The registrar can retrieve the same and relay it to the registry;

   *  The registrar can obtain the information from the registrant
      through another channel (such as a non-automated "manual update"
      via webform submission), and relay it to the registry.

   There are several considerations in this context, as follows.

5.2.1.  Necessity of Non-automatic Updates

   Under special circumstances, it may be necessary to perform a non-
   automatic DS update.  One important example is when the key used by
   for authentication of DS updates is destroyed: in this case, an
   automatic key rollover is impossible as the Child DNS operator can no
   longer authenticate the associated information.  Another example is
   when several providers are involved, but one no longer cooperates
   (e.g., when removing a provider from a multi-provider setup).
   Disabling manual DS management interfaces is therefore strongly
   discouraged.

   Similarly, when the registrar is known to not support DNSSEC (or to
   lack a DS provisioning interface), it seems adequate for registries
   to not perform automated DS maintenance, in order to prevent
   situations in which a misconfigured delegation cannot be repaired by
   the registrant.









Sheng & Thomassen        Expires 17 August 2026                [Page 14]

Internet-Draft                DS Automation                February 2026


5.2.2.  Impact of Non-automatic Updates: When to Suspend Automation

   When an out-of-band (e.g., manual) DS update is performed while CDS/
   CDNSKEY records referencing the previous DS RRset's keys are present,
   the delegation's DS records may be reset to their previous state at
   the next run of the automation process.  This section discusses in
   which situations it is appropriate to suspend DS automation after
   such a non-automatic update.

   One option is to suspend DS automation after a manual DS update, but
   only until a resumption signal is observed.  In the past, it was
   proposed that seeing an updated SOA serial in the child zone may
   serve as a resumption signal.  However, as any arbitrary modification
   of zone contents — including the regular updating of DNSSEC signature
   validity timestamps — typically causes a change in SOA serial,
   resumption of DS automation after a serial change comes with a high
   risk of surprise.  Additional issues arise if nameservers have
   different serial offsets (e.g., in a multi-provider setup).  It is
   therefore advised to not follow this practice.

   Note also that "automatic rollback" due to old CDS/CDNSKEY RRsets can
   only occur if they are signed with a key authorized by one of new DS
   records.  Acceptance checks described in Section 2 further ensure
   that updates do not break validation.

   Removal of a DS record set is triggered either through a CDS/CDNSKEY
   "delete" signal observed by the party performing the automation
   ([RFC8078], Section 4), or by receiving a removal request out-of-band
   (e.g., via EPP or a web form).  In the first case, it is useful to
   keep automation active for the delegation in question, to facilitate
   later DS bootstrapping.  In the second case, it is likely that the
   registrant intends to disable DNSSEC for the domain, and DS
   automation is best suspended (until a new DS record is provisioned
   somehow).

   One may ask how a registry can know whether a removal request
   received via EPP was the result of the registrar observing a CDS/
   CDNSKEY "delete" signal.  It turns out that the registry does not
   need to know that; in fact, the advice works out nicely regardless of
   who does the automation:

   a.  Only registry: If the registry performs automation, then the
       registry will consider any request received from the registrar as
       out-of-band (in the context of this automation).  When such
       requests demand removal of the entire DS record set, the registry
       therefore should suspend automation.





Sheng & Thomassen        Expires 17 August 2026                [Page 15]

Internet-Draft                DS Automation                February 2026


   b.  Only registrar: The registrar can always distinguish between
       removal requests obtained from a CDS/CDNSKEY "delete" signal and
       other registrant requests, and suspend automation as appropriate.

   c.  In the (undesirable) case that both parties automate, there are
       two cases:

       *  If the registrant submits a manual removal request to the
          registrar, it is out-of-band from the registrar perspective
          (e.g., web form), and also for the registry (e.g., EPP).  As a
          consequence, both will suspend automation (which is the
          correct result).

       *  If a CDS/CDNSKEY "delete" signal causes the registrar to
          request DS removal from the registry, then the registry will
          suspend automation (because the removal request is received
          out-of-band, such as via EPP).  This is independent of whether
          the registry's automation has already seen the signal.  The
          registrar, however, will be aware of the in-band nature of the
          request and not suspend automation (which is also the correct
          result).

       As a side effect, this works towards avoiding redundant
       automation at the registry.

   All in all:

   *  It appears advisable to generally not suspend in-band DS
      automation when an out-of-band DS update has occurred.

   *  An exception from this rule is when the entire DS record set was
      removed through an out-of-band request, in which case the
      registrant likely wants to disable DNSSEC for the domain.  DS
      automation should then be suspended so that automatic re-
      initialization (bootstrapping) does not occur.

   *  In all other cases, any properly authenticated DS updates
      received, including through an automated method, are to be
      considered as the current intent of the domain holder.

5.2.3.  Concurrent Automatic Updates

   When the RRR model is used, there is a potential for collision if
   both the registry and the registrar are automating DS provisioning by
   scanning the child for CDS/CDNSKEY records.  No disruptive
   consequences are expected if both parties perform DS automation.  An
   exception is when during a key rollover, registry and registrar see
   different versions of the Child's DS update requests, such as when



Sheng & Thomassen        Expires 17 August 2026                [Page 16]

Internet-Draft                DS Automation                February 2026


   CDS/CDNSKEY records are retrieved from different vantage points.
   Although unlikely due to Recommendation 1a of Section 2, this may
   lead to flapping of DS updates; however, it is not expected to be
   harmful as either DS RRset will allow for the validation function to
   continue to work, as ensured by Recommendation 1b of Section 2.  The
   effect subsides as the Child's state eventually becomes consistent
   (roughly, within the child's replication delay); any flapping until
   then will be a minor nuisance only.

   The issue disappears entirely when scanning is replaced by
   notifications that trigger DS maintenance through one party's
   designated endpoint [RFC9859], and can otherwise be mitigated if the
   registry and registrar agree that only one of them will perform
   scanning.

   As a standard aspect of key rollovers [RFC6781], the Child DNS
   operator is expected to monitor propagation of Child zone updates to
   all authoritative nameserver instances, and only proceed to the next
   step once replication has succeeded everywhere and the DS record set
   was subsequently updated (and in no case before the DS RRset's TTL
   has passed).  Any breakage resulting from improper timing on the
   Child side is outside of the Parent's sphere of influence, and thus
   cannot be handled with only parent-side changes.

6.  IANA Considerations

   This document has no IANA actions.

7.  Security Considerations

   This document considers security aspects throughout, and has no
   separate considerations.

8.  Acknowledgments

   The authors would like to thank the SSAC members who wrote the
   [SAC126] report on which this document is based.

   In order of first contribution or review: Barbara Jantzen, Matt
   Pounsett, Matthijs Mekking, Ondřej Caletka, Oli Schacher, Kim Davies,
   Jim Reid, Q Misell, Scott Hollenbeck, Tamás Csillag, Philip Homburg,
   Shumon Huque, Libor Peltan, Josh Simpson, Johan Stenstam, Stefan
   Ubbink, Viktor Dukhovni, Hugo Salgado, Wes Hardaker

9.  References

9.1.  Normative References




Sheng & Thomassen        Expires 17 August 2026                [Page 17]

Internet-Draft                DS Automation                February 2026


   [DNSKEY-IANA]
              IANA, "DNS Security Algorithm Numbers", n.d.,
              <https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
              sec-alg-numbers.xml#dns-sec-alg-numbers-1>.

   [DS-IANA]  IANA, "Delegation Signer (DS) Resource Record (RR) Type
              Digest Algorithms", n.d.,
              <http://www.iana.org/assignments/ds-rr-types>.

   [I-D.ietf-dnsop-cds-consistency]
              Thomassen, P., "Clarifications on CDS/CDNSKEY and CSYNC
              Consistency", Work in Progress, Internet-Draft, draft-
              ietf-dnsop-cds-consistency-11, 11 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              cds-consistency-11>.

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

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

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

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

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

   [RFC8590]  Gould, J. and K. Feher, "Change Poll Extension for the
              Extensible Provisioning Protocol (EPP)", RFC 8590,
              DOI 10.17487/RFC8590, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8590>.

   [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
              RFC 9364, DOI 10.17487/RFC9364, February 2023,
              <https://www.rfc-editor.org/rfc/rfc9364>.




Sheng & Thomassen        Expires 17 August 2026                [Page 18]

Internet-Draft                DS Automation                February 2026


   [RFC9567]  Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567,
              DOI 10.17487/RFC9567, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9567>.

   [RFC9615]  Thomassen, P. and N. Wisiol, "Automatic DNSSEC
              Bootstrapping Using Authenticated Signals from the Zone's
              Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
              <https://www.rfc-editor.org/rfc/rfc9615>.

   [RFC9859]  Stenstam, J., Thomassen, P., and J. Levine, "Generalized
              DNS Notifications", RFC 9859, DOI 10.17487/RFC9859,
              September 2025, <https://www.rfc-editor.org/rfc/rfc9859>.

9.2.  Informative References

   [LowTTL]   Špaček, P., "DS and DNSKEY low TTL experiments", at DNS
              OARC 41, 6 September 2023, <https://indico.dns-
              oarc.net/event/47/contributions/1010/attachments/958/1811/
              DS%20and%20DNSKEY%20TTL%20experiment.pdf>.

   [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
              <https://www.rfc-editor.org/rfc/rfc5730>.

   [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Domain Name Mapping", STD 69, RFC 5731,
              DOI 10.17487/RFC5731, August 2009,
              <https://www.rfc-editor.org/rfc/rfc5731>.

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

   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
              DOI 10.17487/RFC6840, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6840>.

   [RFC9803]  Brown, G., "Extensible Provisioning Protocol (EPP) Mapping
              for DNS Time-to-Live (TTL) Values", RFC 9803,
              DOI 10.17487/RFC9803, June 2025,
              <https://www.rfc-editor.org/rfc/rfc9803>.








Sheng & Thomassen        Expires 17 August 2026                [Page 19]

Internet-Draft                DS Automation                February 2026


   [SAC126]   (SSAC), I. S. and S. A. C., "SAC126: DNSSEC Delegation
              Signer (DS) Record Automation", 12 August 2024,
              <https://itp.cdn.icann.org/en/files/security-and-
              stability-advisory-committee-ssac-reports/sac-
              126-16-08-2024-en.pdf>.

Appendix A.  Terminology

   Unless defined in this section, the terminology in this document is
   as defined in [RFC7344].

   Child zone:  DNS zone whose delegation is in the Parent zone.

   Child (DNS operator):  DNS operator responsible for a Child zone.

   DNS operator:  The entity holding the zone's primary copy before it
      is signed.  Typically a DNS hosting provider in the domain
      holder's name, it controls the authoritative contents and
      delegations in the zone, and is thus operationally responsible for
      maintaining the "purposeful" records in the zone file (such as IP
      address, MX, or CDS/CDNSKEY records).  The parties involved in
      other functions for the zone, like signing and serving, are not
      relevant for this definition.

   Parent zone:  DNS zone that holds a delegation for a Child zone.

   Parent (DNS operator):  The DNS operator responsible for a Parent
      zone, and thus involved with the maintenance of the delegation's
      DNSSEC parameters (in particular, the acceptance of these
      parameters and the publication of corresponding DS records).

   Registrant:  The entity responsible for records associated with a
      particular domain name in a domain name registry (typically under
      a TLD such as .com or an SLD such as co.uk).  When the RRR model
      is used, the registrant maintains these records through a
      registrar who acts as an intermediary for both the registry and
      the registrant.

   Registrar:  An entity through which registrants register domain
      names; the registrar performs this service by interacting directly
      with the registry in charge of the domain's suffix.  A registrar
      may also provide other services such as DNS service or web hosting
      for the registrant.  In some cases, the registry directly offers
      registration services to the public, that is, the registry may
      also perform the registrar function.

   Registry:  The entity that controls the registry database and




Sheng & Thomassen        Expires 17 August 2026                [Page 20]

Internet-Draft                DS Automation                February 2026


      authoritative DNS service of domain names registered under a
      particular suffix, for example a top-level domain (TLD).  A
      registry receives requests through an interface (usually EPP
      [RFC5730]) from registrars to read, add, delete, or modify domain
      name registrations, and then makes the requested changes in the
      registry database and associated DNS zone.

   RRR Model:  The registrant-registrar-registry interaction framework,
      where registrants interact with a registrar to register and manage
      domain names, and registrars interact with the domain's registry
      for the provision and management of domain names on the
      registrant's behalf.  This model is common amongst top-level
      domains.

Appendix B.  Recommendations Overview

   For ease of review, the recommendations from this document are
   reproduced here without further comment.  For background and
   analysis, see Sections 2–5.

B.1.  Acceptance Checks and Safety Measures

   1.  Entities performing automated DS maintenance SHOULD verify

       a.  the unambigious intent of each DS update request as per
           [I-D.ietf-dnsop-cds-consistency], by checking its consistency
           both

           *  between any published CDS and CDNSKEY records, and

           *  across all authoritative nameservers in the delegation,

           and

       b.  that the resulting DS record set would allow continued DNSSEC
           validation if deployed,

       and cancel the update if the verifications do not succeed.

   2.  Parent-side entities (such as registries) SHOULD reduce a DS
       record set's TTL to a value between 5–15 minutes when the set of
       records is changed, and restore the normal TTL value at a later
       occasion (but not before the previous DS RRset's TTL has
       expired).

   3.  DNS operators SHOULD publish both CDNSKEY records as well as CDS
       records, and follow best practice for the choice of hash digest
       type [DS-IANA].



Sheng & Thomassen        Expires 17 August 2026                [Page 21]

Internet-Draft                DS Automation                February 2026


B.2.  Reporting and Transparency

   1.  For certain DS updates (see analysis (Section 3.2)) and for DS
       deactivation, relevant points of contact known to the zone
       operator SHOULD be notified.

   2.  For error conditions, the child DNS operator and the domain's
       technical contact (if applicable) SHOULD be notified first.  The
       registrant SHOULD NOT be notified unless the problem persists for
       a prolonged amount of time (e.g., three days).

   3.  Child DNS operators SHOULD be notified using a report query
       [RFC9567] to the agent domain as described in ([RFC9859],
       Section 4).  Notifications to humans (domain holder) will be
       performed in accordance with the communication preferences
       established with the parent-side entity (registry or registrar).
       The same condition SHOULD NOT be reported unnecessarily
       frequently to the same recipient.

   4.  In the RRR model, registries performing DS automation SHOULD
       inform the registrar of any DS record changes via the EPP Change
       Poll Extension [RFC8590] or a similar channel.

   5.  The currently active DS configuration SHOULD be made accessible
       to the registrant (or their designated party) through the
       customer portal available for domain management.  The DS update
       history MAY be made available in the same way.

B.3.  Registration Locks

   1.  To secure ongoing operations, automated DS maintenance SHOULD NOT
       be suspended based on a registrar update lock alone (such as EPP
       status clientUpdateProhibited).

   2.  When performed by the registry, automated DS maintenance SHOULD
       NOT be suspended based on a registry update lock alone (such as
       EPP status serverUpdateProhibited).

B.4.  Multiple Submitting Parties

   1.  Registries and registrars SHOULD provide another (e.g., manual)
       channel for DS maintenance in order to enable recovery when the
       Child has lost access to its signing key(s).  This out-of-band
       channel is also needed when a DNS operator does not support DS
       automation or refuses to cooperate.






Sheng & Thomassen        Expires 17 August 2026                [Page 22]

Internet-Draft                DS Automation                February 2026


   2.  DS update requests SHOULD be executed immediately after
       verification of their authenticity, regardless of whether they
       are received in-band or via an out-of-band channel.

   3.  When processing a CDS/CDNSKEY "delete" signal to remove the
       entire DS record set ([RFC8078], Section 4), DS automation SHOULD
       NOT be suspended.  For all other removal requests (such as when
       received via EPP or a web form), DS automation SHOULD be
       suspended until a new DS record set has been provisioned, in
       order to prevent accidental re-initialization when the registrant
       intended to disable DNSSEC.

   4.  Whenever a non-empty DS record set is provisioned, through
       whichever channel, DS automation SHOULD NOT (or no longer) be
       suspended (including after an earlier removal).

   5.  In the RRR model, a registry SHOULD NOT automatically initialize
       DS records when it is known that the registrar does not provide a
       way for the domain holder to later disable DNSSEC.  If the
       registrar has declared to be performing automated DS maintenance,
       the registry SHOULD publish the registrar's [RFC9859]
       notification endpoint (if applicable) and refrain from registry-
       side DS automation.

Appendix C.  Change History (to be removed before publication)

   *  draft-ietf-dnsop-ds-automation-04

      Editorial changes

   *  draft-ietf-dnsop-ds-automation-03

      Editorial changes

   *  draft-ietf-dnsop-ds-automation-02

      Add Appendix with recommendations overview

      Editorial changes

      Change type to BCP

      Fold CDS/CDNSKEY consistency requirements (Section 6) into
      Section 2 (on acceptance checks)

      Clarify continuity of validation





Sheng & Thomassen        Expires 17 August 2026                [Page 23]

Internet-Draft                DS Automation                February 2026


      In RRR, clarify that registries should not bootstrap if registrar
      has no deactivation interface (or if registrar does the
      automation)

      Remove Appendix C ("Approaches not pursued")

   *  draft-ietf-dnsop-ds-automation-01

      Remove Recommendation 6.1.2 which had told parents to require
      publication of both CDS and CDNSKEY

      Clarify Recommendation 5.1.3 (on suspension of automation after DS
      RRset removal) and provide extra analysis

      Providing access to DS update history is now optional

      Humans (domains holders) should be notified according to
      preferences established with registry/registrar (not necessarily
      via email)

      Remove redundant Recommendation 5.1.5 (same as 3.1.4)

      Editorial changes

   *  draft-ietf-dnsop-ds-automation-00

      Rename after adoption

   *  draft-shetho-dnsop-ds-automation-02

      Allow DS automation during registry update lock

      Editorial changes

   *  draft-shetho-dnsop-ds-automation-01

      Incorporated various review feedback (editorial + adding TODOs)

   *  draft-shetho-dnsop-ds-automation-00

      Initial public draft.

Authors' Addresses

   Steve Sheng
   Email: steve.sheng@gmail.com





Sheng & Thomassen        Expires 17 August 2026                [Page 24]

Internet-Draft                DS Automation                February 2026


   Peter Thomassen
   deSEC
   Email: peter@desec.io
















































Sheng & Thomassen        Expires 17 August 2026                [Page 25]


name: draft-ramakrishna-satp-views-addresses
rev: 06
title: Views and View Addresses for Secure Asset Transfer
time: 2025-09-15T14:01:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-19T14:01:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:05.127634+00:00
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.  Core
   requirements for such interoperation between systems are the
   abilities of these systems to project views of their assets to
   external parties, either individual agents or other systems, and the
   abilities of those external parties to locate and address the views
   they are interested in.  A view denotes the complete or partial state
   of a virtual asset, or the output of a function computed over the
   states of one or more assets, or locks or pledges made over assets
   for internal or external parties.  Systems projecting these views
   must be able to guard them using custom access control policies, and
   external parties consuming them must be able to verify them
   independently for authenticity, finality, and freshness.  The end-to-
   end 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 interior 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
   systems.

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
                                                            K. Narayanam
                                                            IBM Research
                                                       15 September 2025


           Views and View Addresses for Secure Asset Transfer
               draft-ramakrishna-satp-views-addresses-06

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.  Core
   requirements for such interoperation between systems are the
   abilities of these systems to project views of their assets to
   external parties, either individual agents or other systems, and the
   abilities of those external parties to locate and address the views
   they are interested in.  A view denotes the complete or partial state
   of a virtual asset, or the output of a function computed over the
   states of one or more assets, or locks or pledges made over assets
   for internal or external parties.  Systems projecting these views
   must be able to guard them using custom access control policies, and
   external parties consuming them must be able to verify them
   independently for authenticity, finality, and freshness.  The end-to-
   end 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 interior 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
   systems.

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-views-addresses/draft-
   ramakrishna-satp-views-addresses.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   ramakrishna-satp-views-addresses/.




Ramakrishna, et al.       Expires 19 March 2026                 [Page 1]

Internet-Draft        SAT Views and View Addresses        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-views-addresses.

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  . . . . . . . . . . . . . . . . .   7
   4.  Ledger State Views and Proofs . . . . . . . . . . . . . . . .   7
     4.1.  Abstraction of Distributed Ledger States  . . . . . . . .   8
     4.2.  Distributed Ledger System Views . . . . . . . . . . . . .   9
     4.3.  Simple Views  . . . . . . . . . . . . . . . . . . . . . .  11



Ramakrishna, et al.       Expires 19 March 2026                 [Page 2]

Internet-Draft        SAT Views and View Addresses        September 2025


     4.4.  Aggregate Views . . . . . . . . . . . . . . . . . . . . .  12
     4.5.  Complex or Processed Views  . . . . . . . . . . . . . . .  12
     4.6.  View Proofs . . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Ledger State View Addresses . . . . . . . . . . . . . . . . .  13
   6.  Ledger State View Verification Policies . . . . . . . . . . .  17
   7.  Ledger State View Request . . . . . . . . . . . . . . . . . .  18
   8.  Ledger State View Access Control Policies . . . . . . . . . .  18
   9.  Related Open Issues . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Forms of proof  . . . . . . . . . . . . . . . . . . . . .  19
     9.2.  Temporal guarantees of view authenticity  . . . . . . . .  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     10.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

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.

   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 formats for views and view addresses on
   distributed ledgers.  Similar to the notion of database views,
   distributed ledger views reflect what a given network wishes to
   expose to external parties, typically through scripts, as well as
   access control considerations.  In contrast to conventional
   databases, exposure and access control considerations must be decided
   through decentralized consensus.  Also, in contrast to a conventional
   database, the consumer of the view, who may be a DLT system, must be



Ramakrishna, et al.       Expires 19 March 2026                 [Page 3]

Internet-Draft        SAT Views and View Addresses        September 2025


   able to independently validate it as the consensus view of the
   providing network.  Hence, a view incorporates the notion of a proof
   made against a claim.  The view address must encapsulate the view
   request, and optionally carry a policy that circumscribes the
   construction of proof.

   The protocol to communicate view requests and responses is beyond the
   scope of this draft and will be specified in a separate draft.

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.

   *  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



Ramakrishna, et al.       Expires 19 March 2026                 [Page 4]

Internet-Draft        SAT Views and View Addresses        September 2025


      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.

   *  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



Ramakrishna, et al.       Expires 19 March 2026                 [Page 5]

Internet-Draft        SAT Views and View Addresses        September 2025


      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.

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







Ramakrishna, et al.       Expires 19 March 2026                 [Page 6]

Internet-Draft        SAT Views and View Addresses        September 2025


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

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

   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 addressing of a DLT system’s assets and asset-related data as
   well as the exposure of such data to a foreign DLT system assumes the
   presence of one or more gateways that are either part of the system
   or working on behalf of it.  These gateways are ultimately
   responsible for generating and interpreting both addresses and data,
   hiding any DLT- or network-specific protocol considerations from each
   other.  All DLT- and network-specific software artifacts that are
   exchanged among gateways will be encapsulated in generic (or DLT-
   neutral) software artifacts.  The gateways are assumed to be
   interoperable using a protocol that corresponds to the design
   principles of the Internet architecture.  The specification of this
   protocol is beyond the scope of this draft and will be described in a
   separate draft.

4.  Ledger State Views and Proofs




Ramakrishna, et al.       Expires 19 March 2026                 [Page 7]

Internet-Draft        SAT Views and View Addresses        September 2025


4.1.  Abstraction of Distributed Ledger States

   A distributed ledger system maintains a set of ledgers, akin to
   databases.  Each such ledger is organized and addressable in a
   hierarchical namespace with the identifier of the distributed ledger
   system being the root.  A ledger is shared among a subset of members
   of the network that the system, which maintains the distributed
   ledger, is built on.  These subsets of members may overlap or be
   mutually exclusive, depending on the precepts of the given DLT, but
   for the purpose of this document, the distinction is not relevant.
   For example, the Hyperledger Fabric blockchain platform maintains a
   set of channels, where each channel is shared exclusively by a subset
   of members [Andr18].  In contrast, the Corda platform allows each
   data item to be shared by an arbitrary subset of members, in effect
   creating databases privy to mutually overlapping member sets
   [Hear19].  The Ethereum Mainnet has a dynamic group of members
   maintaining a single global ledger with open, or public, access.

   Each shared ledger within a system maintains a snapshot of the
   latest, or current, state, determined through consensus (or
   agreement) by the members sharing it.  In addition, a tamper-evident
   history of the current state, which can be a blockchain or any other
   form of a transaction log, is also maintained by the members sharing
   that database.  The state of the distributed ledger system as a whole
   is the union of states of the ledgers it comprises of.

   Finally, any data item within a ledger can be retrieved, or any
   processed data extracted, using its native logic and interfaces.  As
   a ledger is a traditional database in most respects, it supports
   extraction and processing the same way a database does.  For example,
   data in a SQL database can be extracted using record keys and schema
   attributes, whereas in a No-SQL database, data is extracted using
   knowledge of key value pairs and overlaid schema.  Just as views and
   stored procedures are used to extract information from a database,
   UTXO scripts (in Bitcoin [Naka08]) or smart contracts (in Ethereum
   [Ethe22], and several permissioned DLTs like Hyperledger Fabric and
   Corda) are used to extract information from a ledger.  An interface
   is provided to give the user the ability to query or update ledger
   data.  As UTXO scripts are just simple forms of smart contracts, we
   will assume in our abstraction that each ledger within a DLT system
   possesses a smart contract interface.










Ramakrishna, et al.       Expires 19 March 2026                 [Page 8]

Internet-Draft        SAT Views and View Addresses        September 2025


4.2.  Distributed Ledger System Views

   A view into a distributed ledger system state is similar in concept
   to a traditional database view but has certain additional features
   because the backing state is maintained in a different way than state
   in a traditional database is.  Fundamentally, a DLT system view is
   information that is derived from that system's ledger.  We define it
   as an abstract representation of state projected from a ledger that
   is consumable by entities, who may or may not belong to the network
   or possess credentials to access raw ledger state.  Views are
   uniquely addressable within a DLT system.  A view can be static,
   i.e., referring to information derived from a point-in-time (or
   historical) state, or dynamic, i.e., referring to information derived
   from the current state.

   Semantically, a view represents the what and not the how, i.e., it
   projects information from a ledger but not the details of the process
   through which that information came into being.  This process has
   multiple facets, from the consensus and commitment protocols through
   which raw data was recorded on the ledger to the smart contract
   procedure through which information was extracted from the raw ledger
   data.  These procedures are specific to DLT implementations, which we
   wish to keep opaque from the cross-system communication
   infrastructure, specifically the systems' gateways.  This will allow
   the communication infrastructure to ignore details of ledger
   implementations while managing state when a view is communicated from
   a system to an external entity.  Therefore, we specify the view as a
   package with a generic structure, independent of a specific DLT
   implementation.  Internally, a view will contain data that has a DLT-
   specific representation, but we will leave the interpretation of this
   to modules internal to the systems.  In this document, we will
   specify the formats of the DLT-independent portions of a view that
   will be handled by the communication infrastructure and provide
   suggestive sample view contents for prominent DLTs.

   There is a caveat to the above definition, arising from a fundamental
   difference between a traditional database and a DLT system.  This is
   the fact that state in the former is maintained by a single authority
   whereas state in the latter is maintained collectively, and held in
   agreement, by a peer group of entities, each of which can fail or be
   malicious.  Therefore, a DLT system view is incomplete without an
   associated proof of it being derived from state agreed to by the
   group as a whole.  In practice, this does not require unanimity but
   rather enough representation from group members to overcome failure
   of individual peers' failures and to assure an external client that
   the system as a whole will not repudiate that view, in accordance
   with the consensus rules of the source ledger, at a later time.
   Theoretically, we can quantify the nature of this proof under certain



Ramakrishna, et al.       Expires 19 March 2026                 [Page 9]

Internet-Draft        SAT Views and View Addresses        September 2025


   models.  If peers are susceptible only to crash failures, an
   agreement over state from more than 50% of the peers will qualify as
   sufficient proof.  If peers can be malicious, i.e., fail in Byzantine
   ways, a consistent state view is required from more than 2/3 of the
   peers.  More generally, the nature of proof, or determining what is
   sufficient, can be derived from the consensus mechanism used by the
   system.

   The proof associated with a view represents two things.  One is an
   assurance that the view is a group, or consensus, view of the ledger
   held by the DLT system as a whole.  The other is evidence of
   authenticity of the state projection that the view represents.  And
   though the construction of a proof is very DLT-specific, the notion
   that a proof may be supplied with a view can be embodied in a DLT-
   independent specification, thereby adhering to the principle of DLT
   opacity to the communication infrastructure.  Finally, proofs are
   also consistent with the "what, not how" principle because they
   certify that a view represents state at a given point in time and not
   the history of events that led to that state.

   Now we can look at the structure of a view in more detail.  At a high
   level, a view consists of the following:

   *  Request Id: a unique value corresponding to the request for a view
      made by an external entity to the DLT system.

   *  Data: ledger state projection, or derived information, with proof.

   *  Metadata: attributes of the payload used to unpack and interpret
      it.

   Data consists of the following:

   *  View Address: this is supplied by an external entity, and is the
      equivalent of a "getter function" that can be used to uniquely
      identify (or derive) projection into a DLT system state.

   *  Information: this is the actual ledger state projection.

   *  Schema: this described the Information data structure and can be
      used to unpack (or unmarshal) it.  It is optional if the ledger
      schema is well-known.

   *  Proof: This is a structure that validates the Information.  It is
      optional, though recommended for DLT system views.

   *  Proof Schema: this describes the Proof data structure.  It is
      optional if the proof schema is well-known.



Ramakrishna, et al.       Expires 19 March 2026                [Page 10]

Internet-Draft        SAT Views and View Addresses        September 2025


   Metadata consists of the following:

   *  View Type: this tells us whether the view is a singleton data
      item, a collection of data items, or a computation over data items
      that are part of the DLT system state.

   *  Protocol Type: this denotes a unique value associated with a given
      DLT protocol; e.g., Bitcoin, Ethereum, Hyperledger Fabric, Corda,
      Solana.

   *  Timestamp: this denotes the time at which the view was produced.

   *  Proof Type: this denotes the type, or category, of proof being
      supplied, e.g., Notarizations/certifications (also called proof of
      authority), Simplified Payment Verifications, Zero Knowledge
      Proof, Proof of Proof-of-Work.

   *  Serialization Format: this denotes the format used to serialize
      the view data, e.g., XML, JSON, protocol buffer.

   *  Commitments: these are commitments made on the view by authorities
      or infrastructure (e.g., the Ethereum Mainnet) external to the DLT
      system.

4.3.  Simple Views

   A simple DLT view is any unit of a database within a DLT system that
   is exposable through interfaces programmed over that database.  More
   concretely, any blockchain or smart contract system provides the
   ability to write scripts or procedures that can act on the raw ledger
   (database) data, accompanied by interfaces to trigger those scripts
   or procedures to query or update ledger state.  In such a system, a
   simple view is any information that can be obtained directly through
   an invocation of this interface, e.g., any transaction exposed by a
   smart contract deployed on a ledger within the system.

   In the DLT view structure specified earlier, the View Type within
   Metadata will be set to SIMPLE if such a view is requested by an
   external entity.  The content of the view address (described later in
   this draft) can be interpreted to know if the external entity is
   requesting a simple view.










Ramakrishna, et al.       Expires 19 March 2026                [Page 11]

Internet-Draft        SAT Views and View Addresses        September 2025


4.4.  Aggregate Views

   An aggregate DLT view is a collection of addressable units of
   databases within a DLT system.  In effect, it is an array of simple
   views, which can be derived through multiple invocations of different
   scripts or smart contract transactions acting on raw ledger data.  In
   the DLT view structure specified earlier, the View Type within
   Metadata will be set to AGGREGATE if such a view is requested by an
   external entity.  The content of the view address (described later in
   this draft) can be interpreted to know if the external entity is
   requesting an aggregate view.

4.5.  Complex or Processed Views

   A complex or processed DLT view is the output of a function computed
   over a set of addressable units of databases within a DLT system.  In
   effect, it is a function computed over an aggregate view.  In the DLT
   view structure specified earlier, the View Type within Metadata will
   be set to AGGREGATE if such a view is requested by an external
   entity.  The content of the view address (described later in this
   draft) can be interpreted to know if the external entity is
   requesting a complex view, and the function to be computed will also
   be specified in the view address.

4.6.  View Proofs

   Proof within a view must ratify the view’s contents as the consensus
   over a projection of ledger state by members of the DLT system.
   Because the projection of state is itself DLT-specific, though it can
   be wrapped in DLT-neutral structures as we have described earlier,
   the proof also takes DLT-specific shapes.  But we can list the set of
   attributes any proof must contain in abstract terms as follows:

   *  Association of response with request: a connection (ideally,
      cryptographically secure) between the request supplied in the view
      address with the ledger state projection as inferred by the source
      system.  For instance, this can take the form of a signature over
      a common structure consisting of both the request and the
      response.

   *  Authenticity of response: a connection (ideally, cryptographically
      secure) between a member generating a ledger state projection and
      its DLT system.  For instance, this can take the form of a
      certificate chain associating the signer with the DLT system’s
      membership authorities.  This is necessary for a permissioned DLT
      system and is optional for open (or permissionless) DLT systems.





Ramakrishna, et al.       Expires 19 March 2026                [Page 12]

Internet-Draft        SAT Views and View Addresses        September 2025


   *  Evidence of consensus: information showing that the view contents
      are agreed upon by the network as a whole.  For a permissioned DLT
      system, this typically implies that an identical and authentic
      ledger state projection must be provided by a large enough quorum
      of its members so that the view cannot be repudiated in the
      future.  In an open (or permissionless) system, this can simply be
      the portion of a mined block that shows why it belongs to the
      longest chain; i.e., proof-of work or succinct versions of it
      (like Proof-of-Proof-of-Work [Naka08], or PoPoW [Kiay16][Kiay17]).
      In any DLT system, such evidence can optionally pass a policy
      check, where the policy rule is supplied by the view requestor and
      typically embodies the consensus logic that led to the commitment
      of the ledger state projection being requested.

5.  Ledger State View Addresses

   To request a view from a DLT system, an external entity must be able
   to unambiguously specify the information it seeks in the form of a
   view address.  The use of the term “address” follows from the
   abstraction of a DLT system as a repository of data resources that
   can be retrieved and computed on.  A view address in blockchain or
   distributed ledger systems is equivalent to URLs [RFC1630] (for
   example, specified as an HTTP address [RFC2616]), which are used to
   address resources offered by Internet and World Wide Web servers
   [RFC1738].

   From a functional perspective, a view address can also be thought of
   as an interface over a “getter”, which is a standard software pattern
   used to fetch data values in a computer program.  The schematic
   representation of a getter is dependent on the protocol followed by
   the underlying distributed ledger system, but is conceptually
   abstracted away by the view address.  An external entity can create
   and manipulate a view address without understanding its semantics and
   usage, which are hidden by the DLT system.  This allows the system to
   use alternate representations for getters internally without
   requiring external entities to understand the implementations of
   these operators.  The view address states the “what” and not the
   “how”.

   A view address must be a globally unique identifier of a view on a
   distributed ledger system, because global interoperability is our
   goal.  Therefore, as with DNS addresses for Internet servers and URLs
   for World Wide Web resources, a view address is a hierarchical
   address, with different segments identifying units of decreasing size
   and increasing specificity in sequence.  The syntax is as follows:






Ramakrishna, et al.       Expires 19 March 2026                [Page 13]

Internet-Draft        SAT Views and View Addresses        September 2025


     address  = location-segment "/"
                ledger-segment "/"
                view-segment
                ; distributed-ledger-system/ledger/data-projection

   The location-segment provides identification and reachability
   information for the distributed ledger system.  The ledger-segment
   identifies a unique ledger within this system, and the view-segment
   identifies a view or state projection from that ledger.

   Decentralized ledger systems don’t have a single location as they are
   built on networks of peer nodes.  Maintainers of these systems may
   expose one or more endpoints for external entities to access views,
   which can be hosted on the network nodes themselves or on designated
   gateways.  Gateways form the communication infrastructure for cross-
   system interactions and can be deployed in different configurations:
   a single system may possess multiple gateways, or a single gateway
   may serve multiple systems.  Therefore, to formulate a view address,
   one needs to know the set of endpoints that lead to a given
   distributed ledger system and a unique identifier for the network
   that hosts that system.  In certain systems and gateways, an
   identifier that represents a set of endpoints can be used instead of
   explicitly enumerating those endpoints.  Also, if the specified set
   of endpoints is known to serve a single system, the network
   identifier can be omitted.  The syntax of the location-segment is as
   follows:

     location-segment  = gateway ["/" network-id]
     gateway           = endpoint *(";" endpoint) / name
     endpoint          = host [":" port]
     host              = hostname / IP-address
     port              = 1*DIGIT
     network-id        = name
     hostname          = name 1*("." name)
     name              = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-")
     IP-address        = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

   A single gateway serving a given distributed ledger system (network)
   can be represented as follows:

     location-segment  = gateway.trade.com:7542/trade-network
                         \____________________/ \___________/
                                    |                 |
                                 endpoint          network

   Multiple gateways serving a network can be represented as follows:





Ramakrishna, et al.       Expires 19 March 2026                [Page 14]

Internet-Draft        SAT Views and View Addresses        September 2025


   location-segment  = gateway1.trade.com:7542;   \
                       gateway2.trade.com:7542;   |--gateway (endpoints)
                       gateway3.trade.com:7542    /
                       /trade-network
                        \___________/
                              |
                           network

   Gateways serving a single well-known network can be represented as
   follows:

     location-segment  = gateway1.trade.com:7542;gateway2.trade.com:7542
                         \_____________________________________________/
                                                |
                                       gateway (endpoints)

   The ledger-segment names either the ledger, if that ledger has a
   distinct identifier within the system, or a procedure to access a
   ledger, which represents a common set of facts shared by a subset of
   members of the network that maintains the distributed ledger.  These
   subsets may overlap; i.e., certain nodes may maintain more than one
   ledger in the system.  The procedure name can take the form of an
   identifier that represents, say, a decentralized application spanning
   certain nodes, or an explicit enumeration of the identifiers of the
   nodes themselves.  The ledger segment syntax is as follows:

     ledger-segment = *1(
                         (ALPHA / "_")
                         1*(ALPHA / DIGIT / "_" / "-" / ";" / “:”)
                        )

   The ledger-segment can be blank if the distributed ledger system has
   a single ledger.  This is the norm in open blockchain systems like
   Bitcoin or the Ethereum Mainnet, and in private Ethereum-based
   systems like Quorum and Hyperledger Besu.

   Examples are as follows:














Ramakrishna, et al.       Expires 19 March 2026                [Page 15]

Internet-Draft        SAT Views and View Addresses        September 2025


     ledger-segment = trade-channel
                      \___________/
                            |
                       ledger name

     ledger-segment = paymentsDapp
                      \___________/
                            |
                    procedure/app name

     ledger-segment = paymentsDappNode1:9005;paymentsDappNode2:9005
                      \____________________/ \____________________/
                                 |                      |
                        procedure/app node     procedure/app node

   The view-segment uniquely identifies a view within a ledger.
   Features particular to a distributed ledger technology will determine
   how to encode this segment, but we can draw out common abstractions
   across DLTs to create a generic specification.  All such technologies
   offer a procedural interface to access and manipulate data, typically
   (but not always) in the form of a smart contract.  The exposed
   interface offers multiple functions to generate views based on the
   provided input.  Hence, we can specify the view-segment as being
   composed of a contract, a function, and a list of input arguments.
   In the most general case, a default contract may be assumed, and
   arguments may be unnecessary, and so these can be omitted.  The
   function, which can either be a procedural identifier, or a direct
   reference to a data item or collection of data items, or a
   programming instruction, must be specified.  The view-segment syntax
   is as follows:

     view-segment   = [contract-id] ":"
                      function-spec *(":" input-argument)
     contract-id    = (ALPHA / "_") 1*(ALPHA / DIGIT / "_")
     function-spec  = name
     input-argument = name
     name           = *HEXDIGIT ; hex-encoded ASCII string

   An example of a view-segment for a Hyperledger Fabric ledger is:

     view-segment   = trade-chaincode:getBillOfLading:bill-10012
                      \_____________/ \_____________/ \________/
                              |               |            |
                          contract         function     argument

   An example for a Corda ledger is:





Ramakrishna, et al.       Expires 19 March 2026                [Page 16]

Internet-Draft        SAT Views and View Addresses        September 2025


    view-segment   = :com.trade.dapp.flows.GetDocumentByTypeAndId:C:5
                      \_________________________________________/ \_/
                                           |                       |
                                        function               arguments

   An example of a complete view address is as follows:

     gw.trade.com:7542/traden/tradel/tradec:getBill:bill-10012
     \______________________/ \____/ \_______________________/
                 |               |                |
         location-segment  ledger-segment    view-segment

6.  Ledger State View Verification Policies

   A verification policy for a ledger state view is a set of rules that
   the proof within the view can be validated against (or filtered
   through).  The condition embedded within a rule can be arbitrary,
   though in practice, it should embody the process by which that
   ledger’s state was updated and consented to in a decentralized manner
   by the network of peers maintaining it.  In permissioned networks
   built on DLTs like Hyperledger Fabric or Corda, a policy typically
   requires evidence of attestations made by a sufficiently large, or
   representative, portion of the peer network maintaining the ledger.
   This takes the form of a set of signatures and is crucial to
   validating views generated by networks built on DLTs like Hyperledger
   Fabric and Corda.  In open networks, we can envision policies that
   require validation of the view data being derived from a block in the
   longest chain, for example.  But in this specification, we will
   consider only attestation-based policies and leave more general
   policies to future drafts.

   The structure of a verification policy is as follows:

   *  Security Domain: a unique identifier for the distributed ledger
      system (or network maintaining it) projecting the ledger state
      view.

   *  Rules: a set of rules, each governing the validation of artifacts
      exposed through a particular category of views within the Security
      Domain.

   Each Rule consists of the following:

   *  View Pattern: a regular expression that can match a set of views.

   *  Policy: a policy rule/filter governing all views that match View
      Pattern.




Ramakrishna, et al.       Expires 19 March 2026                [Page 17]

Internet-Draft        SAT Views and View Addresses        September 2025


   Each Policy consists of the following:

   *  Type: an identifier or flag denoting the type of this policy rule.
      For attestation-based policies, this should be set to “Signature”,
      and other identifiers can be created for other policy types in
      future drafts.

   *  Criteria: a Boolean expression with ANDs and ORs, where the
      principals consist of (1) the name of a DLT system unit/
      stakeholder (typically corresponding to a subset of nodes in the
      peer network), and (2) the number of signatures requires from this
      unit.

7.  Ledger State View Request

   A view request is a message sent to a distributed ledger system by
   any external entity.  It consists of the following:

   *  View Address: uniquely identifies the data sought by the
      requester.

   *  Verification Policy: indicates the proof criteria for the
      requested view.

8.  Ledger State View Access Control Policies

   An access control policy for a ledger state view is a set of rules
   governing the exposure of the view to an external entity.  Each rule
   maps a set of principals to a set of views.  The structure of an
   access control policy is as follows:

   *  Security Domain: a unique identifier for the entity (which can be
      a distributed ledger system itself) requesting a ledger state
      view.

   *  Rules: a set of rules, each governing access from some entity
      within Security Domain to artifacts exposed through a particular
      category of views.

   Each Rule consists of the following:

   *  Principal: a string that can match a set of subjects or
      principals, which can represents an individuals or an organization
      or a subgroup within an organization identified by role or
      attribute set (profile).

   *  Principal Type: a keyword that denotes the nature of the
      principal.  This can be one of the following:



Ramakrishna, et al.       Expires 19 March 2026                [Page 18]

Internet-Draft        SAT Views and View Addresses        September 2025


      -  PUBLIC-KEY: indicates that the principal is a public key
         associated with an individual member of the Security Domain.

      -  CA: indicates that the principal is a certification authority
         for an organization within the Security Domain.

      -  ROLE: indicates that the principal identifies a role within the
         Security Domain.

      -  ATTRIBUTE: indicates that the principal identifies a set of
         attributes, or a profile for a member, within the Security
         Domain.

      -  ‘*’: indicates that the principal can be any member of the
         Security Domain.  The Principal can be left blank in this case.

   *  Resource: a regular expression that can match a set of views,
      which identifies the objects governed by this rule.

   *  Read: a Boolean flag indicating whether this rule is currently
      active.

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

9.1.  Forms of proof

   Though we have tried to be agnostic of the nature of the proof
   associated with a view in this draft, the data sharing protocol
   implicitly assumes that the proof takes the form of a quorum of
   digital signatures from parties belonging to a permissioned
   distributed ledger system.  But several other proof types can exist,
   each suitable to the type of system that is exporting a view and the
   technology stack and consensus mechanism it is built on
   [Naka08][Kiay16][Kiay17][PoS][PoET][PoA].









Ramakrishna, et al.       Expires 19 March 2026                [Page 19]

Internet-Draft        SAT Views and View Addresses        September 2025


9.2.  Temporal guarantees of view authenticity

   The view address as specified in this draft has no temporal
   component, implicitly conveying a request for the latest or
   “freshest” state projection from a shared ledger.  Even apart from
   expanding the specification of the view address to include, for
   example, an absolute or relative timestamp, we will need to augment
   the data sharing protocol with a mechanism to convey proof of
   temporal veracity of a view.  Work done on verifiable observation of
   shared ledgers using a public bulletin board [Abebe21] can be taken
   as the starting point for such a specification.

10.  References

10.1.  Normative References

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

   [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
              Unifying Syntax for the Expression of Names and Addresses
              of Objects on the Network as used in the World-Wide Web",
              RFC 1630, DOI 10.17487/RFC1630, June 1994,
              <https://www.rfc-editor.org/rfc/rfc1630>.

   [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
              Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
              December 1994, <https://www.rfc-editor.org/rfc/rfc1738>.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616,
              DOI 10.17487/RFC2616, June 1999,
              <https://www.rfc-editor.org/rfc/rfc2616>.





Ramakrishna, et al.       Expires 19 March 2026                [Page 20]

Internet-Draft        SAT Views and View Addresses        September 2025


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

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

10.2.  Informative References

   [Abebe21]  Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit,
              V., Ramakrishna, V., and J. Yu, "Verifiable Observation of
              Permissioned Ledgers (ICBC 2021)", May 2021,
              <https://arxiv.org/abs/2012.07339>.

   [Andr18]   Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,
              Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,
              Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C.,
              Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti,
              A., Stathakopoulou, C., Vukolic, M., Weed Cocco, S., and
              J. Yellick, "Hyperledger Fabric: A Distributed Operating
              System for Permissioned Blockchains, EuroSys", January
              2018, <https://arxiv.org/abs/1801.10228>.

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

   [Hear19]   Hearn, M. and R. G. Brown, "Corda: A Distributed Ledger",
              August 2019, <https://docs.r3.com/en/pdf/corda-technical-
              whitepaper.pdf>.




Ramakrishna, et al.       Expires 19 March 2026                [Page 21]

Internet-Draft        SAT Views and View Addresses        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>.

   [Kiay16]   Kiayias, A., Lamprou, N., and A. Stouka, "Proofs of proofs
              of work with sublinear complexity, International
              Conference on Financial Cryptography and Data Security,
              pages 61–78, Springer", 2016.

   [Kiay17]   Kiayias, A., Miller, A., and D. Zindros, "Non-Interactive
              Proofs of Proof-of-Work, Cryptology ePrint Archive, Paper
              2017/963", September 2017,
              <https://eprint.iacr.org/2017/963>.

   [Naka08]   Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
              System, Decentralized Business Review", October 2008,
              <https://bitcoin.org/bitcoin.pdf>.

   [PoA]      Antolin, M., "What Is Proof-of-Authority? Understanding
              PoA Consensus Mechanisms, CoinDesk", June 2022,
              <https://www.coindesk.com/learn/what-is-proof-of-
              authority/>.

   [PoET]     Bowman, M., Das, D., Mandal, A., and H. Montgomery, "On
              Elapsed Time Consensus Protocols, Cryptology ePrint
              Archive, Paper 2021/086", 2021,
              <https://eprint.iacr.org/2021/086>.

   [PoS]      "Proof-of-Stake (PoS) | ethereum.org", September 2022,
              <https://ethereum.org/en/developers/docs/consensus-
              mechanisms/pos/>.

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




Ramakrishna, et al.       Expires 19 March 2026                [Page 22]

Internet-Draft        SAT Views and View Addresses        September 2025


Authors' Addresses

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


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


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


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


   Krishnasuri Narayanam
   IBM Research
   Email: knaraya3@in.ibm.com


























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


name: draft-takagi-srta-trinity
rev: 00
title: SRTA and the Trinity Configuration: A Conceptual Architecture for Safe AGI Coordination
time: 2025-09-14T01:14:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-18T01:14:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["AI safety/alignment", "Policy/governance", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127638+00: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.

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: ["Data formats/interop", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127642+00:00
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: 2025-10-20T12:43:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T12:43:07Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127645+00: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.

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: 01
title: Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA)
time: 2025-11-02T07:41:36Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T07:41:36Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:05.127658+00:00
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: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:05.127661+00:00
abstract:
This document defines the HTTP Cookie and Set-Cookie header fields.
   These header fields can be used by HTTP servers to store state
   (called cookies) at HTTP user agents, letting the servers maintain a
   stateful session over the mostly stateless HTTP protocol.  Although
   cookies have many historical 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: ["Policy/governance", "Human-agent interaction", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127668+00: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.

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]


