# drafts

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

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


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

  Abstract

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

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 10 May 2026.






  Rosenberg & White          Expires 10 May 2026                  [Page 1]


  Internet-Draft                     A2T                     November 2025


  Copyright Notice

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

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

  Table of Contents

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

  1.  Background

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




  Rosenberg & White          Expires 10 May 2026                  [Page 2]


  Internet-Draft                     A2T                     November 2025


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

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

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

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



  Rosenberg & White          Expires 10 May 2026                  [Page 3]


  Internet-Draft                     A2T                     November 2025


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

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

     ##Goal

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

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

                     Figure 1: Example Operating Procedure

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



  Rosenberg & White          Expires 10 May 2026                  [Page 4]


  Internet-Draft                     A2T                     November 2025


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

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

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

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

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

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





  Rosenberg & White          Expires 10 May 2026                  [Page 5]


  Internet-Draft                     A2T                     November 2025


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

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

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

  2.  Terminology

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

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

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



  Rosenberg & White          Expires 10 May 2026                  [Page 6]


  Internet-Draft                     A2T                     November 2025


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

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

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

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

     *  AI Agent Designer: Synonymous with designer

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

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

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




  Rosenberg & White          Expires 10 May 2026                  [Page 7]


  Internet-Draft                     A2T                     November 2025


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

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

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

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

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

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

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

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

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

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





  Rosenberg & White          Expires 10 May 2026                  [Page 8]


  Internet-Draft                     A2T                     November 2025


  3.  Problem Statement

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

  3.1.  Tool Curation

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

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

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

  3.1.1.  Tool Sculpting

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



  Rosenberg & White          Expires 10 May 2026                  [Page 9]


  Internet-Draft                     A2T                     November 2025


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

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

     There are two ways these problems are solved today.

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

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

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

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




  Rosenberg & White          Expires 10 May 2026                 [Page 10]


  Internet-Draft                     A2T                     November 2025


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

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

  4.  The A2T Protocol Goals

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

     It has, at its core, the following goals:

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

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

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

     *  Standardize an API signature for tool calling

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

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

     *  Reduce hallucination risk through tool sculpting








  Rosenberg & White          Expires 10 May 2026                 [Page 11]


  Internet-Draft                     A2T                     November 2025


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

  5.  Overview of Operation

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

  5.1.  Tool Signatures

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

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

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




  Rosenberg & White          Expires 10 May 2026                 [Page 12]


  Internet-Draft                     A2T                     November 2025


     Invoking a tool requires the following to be provided:

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

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

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

  5.2.  Enumeration Endpoint

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

     This API facilitates the following design-time workflow:

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





  Rosenberg & White          Expires 10 May 2026                 [Page 13]


  Internet-Draft                     A2T                     November 2025


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

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

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

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

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

  5.3.  Invocation Endpoint

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






  Rosenberg & White          Expires 10 May 2026                 [Page 14]


  Internet-Draft                     A2T                     November 2025


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

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

  5.4.  Versioning

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

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

  6.  Protocol Details

     The following provides a detailed specification of the protocol.

  6.1.  Enumeration API

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

     GET {platform-root}/tools

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

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







  Rosenberg & White          Expires 10 May 2026                 [Page 15]


  Internet-Draft                     A2T                     November 2025


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

                     Figure 2: ToolSignature Object Example

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

     An example of a good tool name is:

     lookup_weather_by_city




  Rosenberg & White          Expires 10 May 2026                 [Page 16]


  Internet-Draft                     A2T                     November 2025


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

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

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

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























  Rosenberg & White          Expires 10 May 2026                 [Page 17]


  Internet-Draft                     A2T                     November 2025


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

             ]
         }
         "required" : true
         }

             Figure 3: ToolSignature Input Parameters Enum Support

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

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

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




  Rosenberg & White          Expires 10 May 2026                 [Page 18]


  Internet-Draft                     A2T                     November 2025


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

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

  6.2.  Details for a Specific tool

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

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

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

  6.3.  Tool Version Retrieval

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

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

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

     An individual version can then be retrieved via:

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

  6.4.  Pagination

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









  Rosenberg & White          Expires 10 May 2026                 [Page 19]


  Internet-Draft                     A2T                     November 2025


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

  7.  Invocation API

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

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

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

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

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

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

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

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

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






  Rosenberg & White          Expires 10 May 2026                 [Page 20]


  Internet-Draft                     A2T                     November 2025


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

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

  7.1.  OpenAPI Specification

     To be added when spec is closer to complete.

  8.  Relationship to MCP

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

  8.1.  Similarities

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

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

  8.2.  Differences

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





  Rosenberg & White          Expires 10 May 2026                 [Page 21]


  Internet-Draft                     A2T                     November 2025


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

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

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

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

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

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

  9.  Informative References

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

  Authors' Addresses

     Jonathan Rosenberg
     Five9
     Email: jdrosen@jdrosen.net



  Rosenberg & White          Expires 10 May 2026                 [Page 22]


  Internet-Draft                     A2T                     November 2025


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
















































  Rosenberg & White          Expires 10 May 2026                 [Page 23]


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

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


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

  Abstract

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

  Status of This Memo

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

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

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

     This Internet-Draft will expire on 14 May 2026.

  Copyright Notice

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



  Vieuille                   Expires 14 May 2026                  [Page 1]


  Internet-Draft                  EPHEMSEC                   November 2025


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

  Table of Contents

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



  Vieuille                   Expires 14 May 2026                  [Page 2]


  Internet-Draft                  EPHEMSEC                   November 2025


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









  Vieuille                   Expires 14 May 2026                  [Page 3]


  Internet-Draft                  EPHEMSEC                   November 2025


  1.  Introduction

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

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

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

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

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

















  Vieuille                   Expires 14 May 2026                  [Page 4]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

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

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

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



  Vieuille                   Expires 14 May 2026                  [Page 5]


  Internet-Draft                  EPHEMSEC                   November 2025


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

  2.  Requirements Notation

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

  3.  Functions and Notation

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

     *  ||: Denotes byte string concatenation.

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

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

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

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

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

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

        -  bs: A byte string with length ≤ 255 bytes






  Vieuille                   Expires 14 May 2026                  [Page 6]


  Internet-Draft                  EPHEMSEC                   November 2025


  4.  EPHEMSEC Roles

     EPHEMSEC distinguishes two roles: Initiator & Responder.

  4.1.  Initiator Role

     This role is normally assigned to relying web application.

  4.2.  Responder Role

     This role is normally assigned to authenticator application.

  5.  EPHEMSEC Parametrization

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

     *  A secure hash function,

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

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

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

  5.1.  Hash Function

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

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

     This function follows the specification in [RFC5869].

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

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

     *  The function returns a byte string of length L.







  Vieuille                   Expires 14 May 2026                  [Page 7]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

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

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

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

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

  5.3.  Key Exchange Pattern

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

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

  5.3.1.  E1S1 Pattern

     *  Initiator contributes: 1 ephemeral key.

     *  Responder contributes: 1 static key.

  5.3.2.  E1S2 Pattern

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

     *  Responder contributes: 1 static key.

  5.3.3.  E2S2 Pattern

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

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





  Vieuille                   Expires 14 May 2026                  [Page 8]


  Internet-Draft                  EPHEMSEC                   November 2025


  5.3.4.  Rationale for Selecting a Key Exchange Pattern

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

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

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

  5.4.  Code Output

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

  5.4.1.  T – Time Window

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

  5.4.2.  B – Encoding Base

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

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

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

  5.4.3.  P – Code Size

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

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




  Vieuille                   Expires 14 May 2026                  [Page 9]


  Internet-Draft                  EPHEMSEC                   November 2025


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

                             Table 1: Code limits

  5.5.  Naming Scheme

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

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

     For example:

     Kerpass_SHA512_X25519_E1S1_T600B32P9

     Where:

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

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

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

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

  6.  EPHEMSEC Credentials

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



  Vieuille                   Expires 14 May 2026                 [Page 10]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

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

  6.1.  Shared PSK

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

  6.2.  Responder Static Key

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

  6.3.  Initiator Static Key

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

  7.  EPHEMSEC Protocol Overview

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

     It assumes the following preconditions:

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

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

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




  Vieuille                   Expires 14 May 2026                 [Page 11]


  Internet-Draft                  EPHEMSEC                   November 2025


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

     *  A freshly generated INONCE,

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

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

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

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

         *  Read or receive INONCE from the Initiator,

         *  Generate PTIME and extract SYNCHINT.

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

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

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

         *  The format is determined by the encoding base B,

         *  The last digit or byte encodes SYNCHINT.

     The Responder returns the resulting code to the Initiator.

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

  8.  Nonce Acquisition

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

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

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




  Vieuille                   Expires 14 May 2026                 [Page 12]


  Internet-Draft                  EPHEMSEC                   November 2025


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

  8.1.  INONCE – Initiator Nonce

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

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

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

  8.2.  PTIME – Responder Time Nonce

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

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

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

  8.2.1.  Inputs

     The following parameters are used throughout this section:

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

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

     *  B: Encoding base (see Section 5.4.2).

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

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




  Vieuille                   Expires 14 May 2026                 [Page 13]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

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

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

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

     if SYNCHINT < mphint:
         PTIME += B

     return PTIME

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

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

  9.  Z - Diffie-Hellman Secret Derivation

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

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

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

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





  Vieuille                   Expires 14 May 2026                 [Page 14]


  Internet-Draft                  EPHEMSEC                   November 2025


  9.1.  Initiator E1S1 Z Derivation

     Inputs:

     *  ei Initiator ephemeral Keypair

     *  Sr Responder static PublicKey

     Z = ECDH(ei, Sr)

  9.2.  Responder E1S1 Z Derivation

     Inputs:

     *  sr Responder static Keypair

     *  Ei Initiator ephemeral PublicKey

     Z = ECDH(sr, Ei)

  9.3.  Initiator E1S2 Z Derivation

     Inputs:

     *  ei Initiator ephemeral Keypair

     *  si Initiator static Keypair

     *  Sr Responder static PublicKey

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

  9.4.  Responder E1S2 Z Derivation

     Inputs:

     *  sr Responder static Keypair

     *  Ei Initiator ephemeral PublicKey

     *  Si Initiator static PublicKey

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

  9.5.  Initiator E2S2 Z Derivation

     Inputs:




  Vieuille                   Expires 14 May 2026                 [Page 15]


  Internet-Draft                  EPHEMSEC                   November 2025


     *  ei Initiator ephemeral Keypair

     *  si Initiator static Keypair

     *  Er Responder ephemeral PublicKey

     *  Sr Responder static PublicKey

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

  9.6.  Responder E2S2 Z Derivation

     Inputs:

     *  er Responder ephemeral Keypair

     *  sr Responder static Keypair

     *  Ei Initiator ephemeral PublicKey

     *  Si Initiator static PublicKey

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

  10.  10.  ISK – Intermediary Secret Derivation

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

  10.1.  10.1 Inputs

     The function uses the following inputs:

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

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

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

     *  P: Code size (see Section 5.4.3).

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

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




  Vieuille                   Expires 14 May 2026                 [Page 16]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

  10.2.  10.2 ISK Derivation

     The ISK is derived using the following steps:

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

     ikm = Z || PSK

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

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

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

     return ISK

  11.  OTP/OTK Derivation

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

  11.1.  Inputs

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

     *  P: Code size (see Section 5.4.3).

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

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







  Vieuille                   Expires 14 May 2026                 [Page 17]


  Internet-Draft                  EPHEMSEC                   November 2025


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

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

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

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

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

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

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

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

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

  11.3.  OTK Derivation (B = 256)

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

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

     return OTK  # byte string of length P






  Vieuille                   Expires 14 May 2026                 [Page 18]


  Internet-Draft                  EPHEMSEC                   November 2025


  12.  Key Exchange Protocol Integration

     EPHEMSEC OTPs/OTKs are ephemeral *shared secrets* that can serve as
     primary credentials in mutually authenticated key exchange protocols,
     such as:

     *  Password-Authenticated Key Exchange (PAKE)

     *  TLS with Pre-Shared Key authentication (TLS-PSK)

     Traditional one-time password algorithms like HOTP, as defined in
     [RFC4226], are unsuitable for these protocols due to their reliance
     on loose synchronization.  Validation servers must compare a received
     OTP against a range of possible values, which precludes direct use as
     cryptographic key material.

     EPHEMSEC addresses this limitation by appending a *synchronization
     digit* to each OTP/OTK.  This digit enables reconstruction of the
     time-based nonce PTIME (see Section 8.2), ensuring that both parties
     derive identical secrets without relying on trial-and-error
     validation.

     To use EPHEMSEC outputs as inputs to a key exchange protocol:

     1.  *Client Preparation*:

         *  Append the synchronization digit to the account identifier.

         *  Use this composite identifier to initiate the key exchange
            protocol.

     2.  *Server Operation*:

         *  Extract the synchronization digit from the received
            identifier.

         *  Remove the synchronization digit to recover the base account
            identifier.

         *  Load the corresponding client credentials using the base
            identifier.

         *  Execute the EPHEMSEC algorithm with the received session
            parameters, credentials, and synchronization hint to derive
            the shared secret.

         *  Proceed with the key exchange protocol using the derived
            secret.



  Vieuille                   Expires 14 May 2026                 [Page 19]


  Internet-Draft                  EPHEMSEC                   November 2025


  13.  Security considerations

     This section outlines the security properties of the EPHEMSEC
     algorithm.  The analysis presented here is intended to demonstrate
     why the protocol is expected to meet its security goals, based on
     widely accepted cryptographic assumptions.

     This document has not yet undergone comprehensive peer review by the
     cryptographic and security communities.  The security analysis
     presented should be considered preliminary, and implementers should
     exercise appropriate caution in security-critical deployments pending
     further review.

  13.1.  Adversary Profiles

     Two adversary profiles are considered in this analysis:

     *  *Network Observer*
        This adversary has access to all publicly visible data, including
        the Initiator’s and Responder’s static ECDH public keys, session
        inputs (nonces, ephemeral public keys), and outputs (OTPs/OTKs)
        from previous EPHEMSEC sessions.  It does not have access to any
        party’s private credentials.

     *  *Credential Leak Attacker*
        This adversary has all the capabilities of a Network Observer, and
        additionally has read access to the Initiator’s credential store —
        specifically the Responder’s shared PSKs and static public keys.
        It does *not* have access to the Initiator’s private keys or
        control over protocol behavior.

  13.2.  Output Unpredictability of EPHEMSEC

     The primary security goal of an OTP/OTK algorithm is to ensure that
     outputs are unpredictable — even to attackers with significant
     passive or partial access.

     EPHEMSEC achieves this by combining Diffie-Hellman key exchange and
     HKDF with session-specific nonces.  Specifically:

     1.  *Unpredictability of the Shared Secret (Z)*
         The ECDH-derived shared secret Z is indistinguishable from random
         to any adversary lacking private keys, due to the hardness of the
         Decisional Diffie-Hellman (DDH) problem on the chosen curve.







  Vieuille                   Expires 14 May 2026                 [Page 20]


  Internet-Draft                  EPHEMSEC                   November 2025


     2.  *Unpredictability of the HKDF Input (ikm)*
         The HKDF input key material (ikm = Z || PSK) inherits the
         unpredictability of Z.  Even if the attacker knows the pre-shared
         key (PSK), the presence of the fresh and secret Z value ensures
         ikm remains secure.

     3.  *Security of the Derived Secret (ISK)*
         HKDF acts as a cryptographically strong pseudorandom function
         (PRF), meaning its outputs — including the intermediary secret
         ISK — are indistinguishable from random, provided the HKDF ikm
         secret input is unpredictable.  Because each execution of
         EPHEMSEC uses unique nonces and ephemeral keys, the ISK value
         changes with every session.

     4.  *Output Derivation (OTP/OTK)*

         *  For OTKs (B = 256): ISK is directly used, preserving its
            pseudorandomness.

         *  For OTPs (B ∈ {10, 16, 32}): ISK is converted to digits via
            modular arithmetic.  This process introduces bias when B = 10,
            but the bias is mitigated by restricting code sizes (P) to the
            ranges specified in Table 1 (see Appendix A for analysis).

     5.  *Prevention of Replay and Forward Prediction*
         The use of unique nonces (INONCE, PTIME) and ephemeral keys
         ensures that no two executions produce the same output — even for
         the same account and context.  This prevents replay attacks and
         ensures that attackers cannot predict future codes based on prior
         sessions.

     As a result, even an attacker who observes multiple sessions (and
     even possesses some server-side credentials) cannot derive or guess
     new OTPs or OTKs, nor can they reuse prior ones.

  13.3.  Phishing and MITM Prevention via Context Binding

     EPHEMSEC can mitigate web browser phishing and man-in-the-middle
     (MITM) attacks by binding cryptographic outputs to authentication
     context through the CONTEXT input (see Section 10.1).  This mechanism
     enables:

     1.  *Phishing Resistance*:

         *  By embedding the login page URL in CONTEXT, the derived OTP/
            OTK becomes domain-specific.





  Vieuille                   Expires 14 May 2026                 [Page 21]


  Internet-Draft                  EPHEMSEC                   November 2025


         *  An attacker hosting a fake page cannot reuse intercepted
            codes, as their context will differ.

     2.  *MITM Resistance*:

         *  Including the server's TLS certificate hash in CONTEXT ensures
            the OTP/OTK is tied to the authenticated connection.

         *  A MITM with an invalid certificate cannot generate valid
            codes.

  13.3.1.  The need for a trusted Agent

     Context binding alone is *insufficient* to provide Phishing or MITM
     resistance.

     For Context binding to be efficient, it must be used jointly with a
     *trusted Agent* (e.g., a browser extension) that:

     *  Reliably acquire authentication context (e.g., page URL,
        certificate)

     *  Securely inject it into EPHEMSEC's CONTEXT parameter

     *  Resist spoofing or coercion by attackers

  13.4.  Mutual Authentication

     Because the EPHEMSEC Initiator and Responder share a PSK (see
     Section 6.1), all OTP/OTK outputs are derived from a secret known to
     both parties.  As a result, these values can serve as credentials in
     protocols that support mutual authentication, such as PAKE or TLS-
     PSK.

     However, when the E1S1 key exchange pattern is used, the only
     contribution from the Initiator is an ephemeral key.  In this
     configuration, the mutuality of the shared secret relies solely on
     the PSK.  If the PSK is compromised — for example, by a Credential
     Leak Attacker — the attacker can impersonate the Initiator to the
     Responder.

     To mitigate this risk, it is RECOMMENDED that mutual authentication
     deployments use the E1S2 or E2S2 key exchange patterns.  These
     patterns require the Initiator to contribute a static ECDH key,
     ensuring that mutual authentication depends on key material not
     accessible to a Credential Leak Attacker.  This prevents such an
     attacker from successfully impersonating the Initiator.




  Vieuille                   Expires 14 May 2026                 [Page 22]


  Internet-Draft                  EPHEMSEC                   November 2025


  13.5.  Time Synchronization Attacks

     EPHEMSEC's time-synchronized nature creates a potential attack vector
     against the protocol's availability.  The algorithm requires that
     clock drift between Initiator and Responder remain within T/2 seconds
     for successful PTIME recovery (see Section 8.2).

     An attacker who can manipulate the time sources or time
     synchronization mechanisms of either party may cause authentication
     failures by forcing clock drift to exceed this threshold.  Such
     attacks could result in denial of service against the authentication
     system.

     Future revisions will extend PTIME derivation to support event-based
     counters alongside time-based synchronization.  Setting T = 0 will
     enable event-synchronized OTP/OTK generation using shared counters,
     while T > 0 will maintain time-based operation, allowing applications
     to choose the synchronization method best suited to their threat
     model.

  14.  IANA Considerations

     No IANA action is required.

  15.  References

  15.1.  Normative References

     [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
                for Security", RFC 7748, DOI 10.17487/RFC7748, January
                2016, <https://www.rfc-editor.org/rfc/rfc7748>.

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

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

  15.2.  Informative References

     [RFC4226]  M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
                O. Ranen, "HOTP: An HMAC-Based One-Time Password
                Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,
                <https://www.rfc-editor.org/rfc/rfc4226>.




  Vieuille                   Expires 14 May 2026                 [Page 23]


  Internet-Draft                  EPHEMSEC                   November 2025


     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
                Key Derivation Function (HKDF)", RFC 5869,
                DOI 10.17487/RFC5869, May 2010,
                <https://www.rfc-editor.org/rfc/rfc5869>.

     [RFC6238]  M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
                Time-Based One-Time Password Algorithm", RFC 6238,
                DOI 10.17487/RFC6238, May 2011,
                <https://www.rfc-editor.org/rfc/rfc6238>.

     [KerPass]  "KerPass open source project", n.d.,
                <https://github.com/amvtek/KerPass>.

     [PASSKEY]  "passkeys-Specifications", n.d.,
                <https://passkeys.dev/docs/reference/specs/>.

     [Crockford-B32]
                "Crockford Base 32 Alphabet", n.d.,
                <https://www.crockford.com/base32.html>.

  Appendix A.  OTP Sampling Bias

     EPHEMSEC generates P (see Section 5.4.3) digits OTPs from 64-bit
     pseudo-random integers as described in Section 11.  This final
     operation may introduce a non-uniform distribution in the generated
     OTP when the code base B (see Section 5.4.2) does not evenly divide
     2^64, which occurs for all bases except B = 10.

     We apply the Bias Formula below to evaluate the bias for code base
     10.

     The bias reaches its maximum when the code size P is at its maximum
     value.  While EPHEMSEC supports a maximum P of 15, only 14 digits are
     used to encode the pseudo-random value.  Therefore:

     bias = 1 / floor(2^64 / 10^14) ≈ 5.4e-6

     This value is negligibly close to zero, making the code base 10 bias
     insignificant.

     For comparison, [RFC4226] generates 6-digit base-10 OTPs from 31-bit
     pseudo-random integers, resulting in:

     bias = 1 / floor(2^31 / 10^6) ≈ 0.5e-3

     While this value is also close to zero, it is approximately 100 times
     larger than EPHEMSEC's code base 10 bias.




  Vieuille                   Expires 14 May 2026                 [Page 24]


  Internet-Draft                  EPHEMSEC                   November 2025


  A.1.  Bias Formula

     For integers m and M where m ≤ M and m > 0, when sampling uniformly
     from [0, M) and taking remainder modulo m, remainder distribution may
     not be uniform.

     To quantify this non uniformity we can calculate a bias coefficient
     using:

     *  bias = 0 when M % m = 0

     *  bias = 1/floor(M/m) when M % m ≠ 0

     The bias value varies in [0,1] and indicates the relative
     overrepresentation of certain remainders.  When bias = 0,
     distribution is uniform.

  A.1.1.  Derivation

     Let X be a uniformly distributed random variable that generates
     integers in the range [0,M).  Let R = X % m, where R is a random
     variable that maps X to the remainder of the division by m.

     We want to determine the probability distribution of R and quantify
     any bias that arises.

     Since X is uniformly distributed, the probability of X taking any
     specific value v in [0, M) is 1/M.

     Using the results from Lemma 1 below, we can determine the
     probability distribution of R.

  A.1.2.  Case 1: When M is divisible by m (M % m = 0)

     From Lemma 1, each remainder r in [0, m) occurs exactly M/m times
     among the values [0, M).
     Therefore, R is uniformly distributed with:

     p(r) = (M/m) × (1/M) = 1/m for all r in [0, m)

     In this case, there is no bias since all remainders are equally
     likely.

  A.1.3.  Case 2: When M is not divisible by m (M % m = s where 0 < s < m)

     From Lemma 1, the remainders have different frequencies:

     *  Remainders r in [0, s) occur floor(M/m) + 1 times each



  Vieuille                   Expires 14 May 2026                 [Page 25]


  Internet-Draft                  EPHEMSEC                   November 2025


     *  Remainders r in [s, m) occur floor(M/m) times each

     This leads to a non-uniform distribution:

     *  p(r) = p1 = (floor(M/m) + 1)/M for r in [0, s)

     *  p(r) = p2 = floor(M/m)/M for r in [s, m)

  A.1.4.  Bias Quantification

     The bias arises because p1 > p2.  We can express this relationship
     as:

     p1 = p2 × (1 + 1/floor(M/m)) = p2 × (1 + bias)

     where:
     bias = 1/floor(M/m)

     This bias factor measures the non-uniformity of the distribution:

     *  bias = 0 when M is divisible by m (uniform case)

     *  bias ∈ (0, 1] when M is not divisible by m, with larger values
        indicating greater non-uniformity

     *  The bias is maximized when floor(M/m) = 1, giving bias = 1

  A.2.  Lemma 1: Distribution of Remainders in [0, M)

     Let m and M be integers where m ≤ M and m > 0.

     For any integer r in [0, m), the number of integers v in [0, M) that
     satisfy v % m = r is:

     1.  When M is divisible by m (M % m = 0):

         *  Exactly M/m values for every r in [0, m)

     2.  When M is not divisible by m (M % m = s where 0 < s < m):

         *  floor(M/m) + 1 values for r in [0, s)

         *  floor(M/m) values for r in [s, m)

  A.2.1.  Proof:






  Vieuille                   Expires 14 May 2026                 [Page 26]


  Internet-Draft                  EPHEMSEC                   November 2025


     For r in [0, m) let count(r) be the count of v satisfying v % m = r for v in [0, M)

     Any v, such that v % m = r can be written as v = q·m + r where q ≥ 0
     To keep v in [0, M), we must have q ≤ (M - 1 - r)/m, hence
     count(r) = floor((M -1 - r)/m) + 1

     When M = k·m (divisible case):

     - count(r) = floor((k·m - 1 - r)/m) + 1 = k = M/m

     When M = k·m + s (non-divisible case):

     - For r < s: count(r) = k + 1
     - For r ≥ s: count(r) = k

  Appendix B.  Design Rationale

     The EPHEMSEC algorithm has undergone several implementation
     iterations, initially starting by modifying the HOTP algorithm
     described in [RFC4226] to achieve the desired security properties.

     The following sections explain the rationale behind key design
     choices.

  B.1.  Use of HKDF

     HKDF was chosen over the [RFC4226] HMAC approach for two reasons:

     1.  The HKDF domain separation feature enabled by the HKDF salt
         parameter (see Section 10.2) provides the necessary context
         binding used for phishing protection.

     2.  HKDF allows adjusting output size, which reduces the complexity
         of supporting the range of OTP/OTK sizes supported by EPHEMSEC
         (see Table 1).

  B.2.  Usage of PSK

     The inclusion of a pre-shared key (PSK) ensures that generated OTP/
     OTKs are always a *mutual* secret, which the E1S1 pattern (see
     Section 5.3.1) alone cannot guarantee.

     The incremental cost of mixing the PSK (see Section 6.1) into the
     HKDF ikm input (see Section 10.2) is expected to be low, and the PSK
     improves the secrecy of ikm.  Therefore, it is always used even when
     the pattern (e.g., E1S2; see Section 5.3.2) already provides the
     desired *mutual* secrecy.




  Vieuille                   Expires 14 May 2026                 [Page 27]


  Internet-Draft                  EPHEMSEC                   November 2025


  B.3.  Usage of Nonces

     The design requires that both the Initiator and Responder contribute
     a nonce and are responsible for ensuring that their respective nonces
     are not reused.

     Although both parties currently contribute a nonce, the Initiator’s
     nonce may not be strictly required.  Since the Initiator already
     contributes an ephemeral public key, this element provides sufficient
     entropy and freshness for the session.  The Initiator’s nonce is
     therefore retained primarily to simplify the security analysis and
     preserve symmetry in the protocol design.  Future revisions of this
     specification may remove it if it is shown to be redundant.

  B.3.1.  Transmission of the Responder Nonce

     When using OTP output, bandwidth between the Responder and the
     Initiator is severely constrained.  Therefore, a synchronization
     digit SYNCHINT is used to "compress" the Responder nonce PTIME (see
     Section 8.2).

     When using OTK output, it is assumed that the application has
     addressed the bandwidth limitations that necessitate OTP output, and
     therefore PTIME could potentially be transmitted in uncompressed
     form.

     However, explicit support for uncompressed transmission was not
     included for two reasons:

     1.  The computational cost of running the synchronization algorithm
         to recover PTIME from SYNCHINT is very low.

     2.  Having the server rely on SYNCHINT to reconstruct PTIME limits
         the Responder's ability to reuse its own nonces, which provides
         additional security benefits.

  Appendix C.  Test Vectors

     A minimal set of test vectors is provided for OTP and OTK schemes
     that use the SHA512 hash function and the X25519 ECDH function.

     The [KerPass] open source project provides an extensive set of
     vectors that allow testing EPHEMSEC output generated using common
     hash functions and curves.

  C.1.  Kerpass_SHA512_X25519_E1S1_T600B10P8 vector





  Vieuille                   Expires 14 May 2026                 [Page 28]


  Internet-Draft                  EPHEMSEC                   November 2025


     {
       "scheme": "Kerpass_SHA512_X25519_E1S1_T600B10P8",
       "context": "a33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe",
       "psk": "55a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e",
       "shared_secret": "0803020700020800",
       "otp": "83270280",
       "init_nonce": "d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a",
       "init_time": 4134179892,
       "init_static_key": "",
       "init_ephemeral_key": "50d2af0ee110bd06604eb03e57a37763c9194400015290f3ef612be18ecd0583",
       "init_remote_static_key": "f1e1116982475e7fd252a2ca69c1459b3a4439029fa3f33059d7e657b3318912",
       "init_remote_ephemeral_key": "",
       "resp_time": 4134179984,
       "resp_synchro_hint": 0,
       "resp_static_key": "fad1034e60389317dd0e405c84fff2d17248fa1112d66a1979515ddf65a44a06",
       "resp_ephemeral_key": "",
       "resp_remote_static_key": "",
       "resp_remote_ephemeral_key": "0fc4c28b9d85a476a1b664050901c78c9b4ff69bde707829bd1e05e5602a3d55",
       "hkdf_salt": "432fa33698e33f8ac3aae8c3b1527cc019e5b3e34e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfe53244b6572706173735f5348413531325f5832353531395f453153315f543630304231305038",
       "hkdf_info": "4e13d8421a5a86f2caf8d45e6ef5c62d3b5421ba7a54080000000003b23d1c",
       "hkdf_secret": "31215fcaafce8df63bd3a21371d15233501da05b5c52248fb6d4cafbdad20d3655a439e62aefd92eebb7f4bc7e5f1626ef4545fa499252dd8658b61547f9df0e"
     }

  C.2.  Kerpass_SHA512_X25519_E1S2_T600B16P8 vector

     {
       "scheme": "Kerpass_SHA512_X25519_E1S2_T600B16P8",
       "context": "037f9aae0e39c770b7c216572382e1b78ccff597a27aeb004cd14c881fe1944eb630e8af0f9840b1ef3ffaf2cf697fb0a08d9cacd5e8c5ff4a1be583b4",
       "psk": "a2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d",
       "shared_secret": "0e0f0b02070e020e",
       "otp": "EFB27E2E",
       "init_nonce": "a5ddd81c502e054357c58ac483b8d39ce1e7",
       "init_time": 568923577,
       "init_static_key": "77166d9d14b2cc221a3829f600aad1f2f18872e8a7e7cb7aae2def72b69bff58",
       "init_ephemeral_key": "90533d33305a90560bfef99d07c496ca92ef5001b62441860509af3d226d8ba4",
       "init_remote_static_key": "dc94881a2063e4d30a0e7fe377838202e542b46d8836e57187e9abef99216078",
       "init_remote_ephemeral_key": "",
       "resp_time": 568923459,
       "resp_synchro_hint": 14,
       "resp_static_key": "dcad0c9e9aafe811761199f7e2286fda5036e5f5fc6f98c5f4b97fce71532ef8",
       "resp_ephemeral_key": "",
       "resp_remote_static_key": "176198d01d29325b022a5efff4d315bbf9fb4a07755d19581f857754797f6b54",
       "resp_remote_ephemeral_key": "ecb63fa01c06b8d2c4de23d1abc4a5d57647481fbed22fb5866fda4c7989103c",
       "hkdf_salt": "433d037f9aae0e39c770b7c216572382e1b78ccff597a27aeb004cd14c881fe1944eb630e8af0f9840b1ef3ffaf2cf697fb0a08d9cacd5e8c5ff4a1be583b453244b6572706173735f5348413531325f5832353531395f453153325f543630304231365038",
       "hkdf_info": "4e12a5ddd81c502e054357c58ac483b8d39ce1e754080000000000d906ee",
       "hkdf_secret": "ca2a1d1f71d686ad52f6ef62571d38a5d579f96a86150861e736ea3e71aeba59c85cae9ec5404221a87423eaf952c151bc74b0213fa8a41fba0786ccf315fd5ba2096639c4a3b6de9bb4d76bfe5b047545eaa3ccb8b67839c55e580ba54feb0d"
     }




  Vieuille                   Expires 14 May 2026                 [Page 29]


  Internet-Draft                  EPHEMSEC                   November 2025


  C.3.  Kerpass_SHA512_X25519_E2S2_T600B32P9 vector

     {
       "scheme": "Kerpass_SHA512_X25519_E2S2_T600B32P9",
       "context": "9e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b",
       "psk": "3ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee",
       "shared_secret": "13010a191603100111",
       "otp": "K1ASP3G1H",
       "init_nonce": "716fbb9b9872e0b49dce2723a52ade9d5fdc59",
       "init_time": 2246779725,
       "init_static_key": "6a846ddc06f426e60dd4ae3fbd5b9b06286abc3862e473855e89a138c56ea0b2",
       "init_ephemeral_key": "aa2b0e1b2e4704f08a377ba26e4475aaf1aab010fb8c6ad4bf63890816d3d3f2",
       "init_remote_static_key": "acc4416cd58c4a1a43272253c75a8f27708174f24548466757e13374e161c74b",
       "init_remote_ephemeral_key": "d32119b92d8a61d0c204a4355c86e19c7027376c2e42be84ffa907a1aaec9e6a",
       "resp_time": 2246779996,
       "resp_synchro_hint": 17,
       "resp_static_key": "6716e0cf047f6721662c501ad15f9884cada29210c019c7df566a0e71b67b1dd",
       "resp_ephemeral_key": "d45cf4b5736ef3f3fb0d2a98459a304e595276243d4af91aa5ef2366d44ade2e",
       "resp_remote_static_key": "f7c192278ea1c2323e92cc13da9ac5f0a8d53ac879eadbd774413c66659d865e",
       "resp_remote_ephemeral_key": "86e53308c5bcefe25707f0ffee26cbdc260fc98d22fc9f9e53f4c1994347c27c",
       "hkdf_salt": "43199e2d582a0afac79709941506151e9e6ce20cef6da6c3aa457b53244b6572706173735f5348413531325f5832353531395f453253325f543630304233325039",
       "hkdf_info": "4e13716fbb9b9872e0b49dce2723a52ade9d5fdc5954080000000006eb4bb1",
       "hkdf_secret": "36d0bdc70509bb9cff6f2d899e4b9dd261c91da06604f43e408e96da1253827fc37f09bdd64436333faab1150a0bd26d9c8ef3d5935e175b9db3c5ebacdbe7633ec69559723db8a20cdace8bee0bf6534a1de8902786fc3b3626e4897f261dee"
     }

  C.4.  Kerpass_SHA512_X25519_E1S2_T1024B256P33 vector

























  Vieuille                   Expires 14 May 2026                 [Page 30]


  Internet-Draft                  EPHEMSEC                   November 2025


     {
       "scheme": "Kerpass_SHA512_X25519_E1S2_T1024B256P33",
       "context": "c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e1",
       "psk": "aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe",
       "shared_secret": "8479fca69f6d1dbc9164f20eaa4d799ba3b8dae83f915864766fa66d4cae17422c",
       "otp": "",
       "init_nonce": "5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e054357",
       "init_time": 3762980154,
       "init_static_key": "6fda5036e5f5fc6f98c5f4b97fce71532ef8d077166d9d14b2cc221a3829f600",
       "init_ephemeral_key": "4e5569883283b1a75fbfbe8f3d7d1d5c17d10d90533d33305a90560bfef99d07",
       "init_remote_static_key": "2f92f4b84f1b107ca934e641f34bfae2b2251e9b70876cd1a256301f8f3ccc0e",
       "init_remote_ephemeral_key": "",
       "resp_time": 3762980663,
       "resp_synchro_hint": 44,
       "resp_static_key": "c496ca92ef5001b62441860509af3d226d8ba4dcad0c9e9aafe811761199f7e2",
       "resp_ephemeral_key": "",
       "resp_remote_static_key": "c52b20d6825127ecb33dfff5c1d9a0ed7f57b41eda1dd6855d7ad6268372fc70",
       "resp_remote_ephemeral_key": "6a5a0dd77082720ebd55bcab514a68be8db117af5a17fbb06a7e035e44959307",
       "hkdf_salt": "4318c58ac483b8d39ce1e7037f9aae0e39c770b7c216572382e153274b6572706173735f5348413531325f5832353531395f453153325f543130323442323536503333",
       "hkdf_info": "4e1c5b047545eaa3ccb8b67839c55e580ba54feb0da5ddd81c502e05435754080000000037da8f2c",
       "hkdf_secret": "04b954ad9d6d42e39217b6a32ae83bc52ba662a39e2bcf18240e6b07034a8c4c86e7a23622ce6b4cd46665d4309b624dd16fa39e57c86c7daf115ddd17f24039aad1f2f18872e8a7e7cb7aae2def72b69bff58a2096639c4a3b6de9bb4d76bfe"
     }

  Author's Address

     Marc Vieuille
     Email: marc.vieuille@polytechnique.org
























  Vieuille                   Expires 14 May 2026                 [Page 31]


name: draft-narajala-ans
rev: 00
title: Agent Name Service (ANS): A Universal Directory for Secure AI Agent Discovery and Interoperability
time: 2025-11-18T07:09:00Z
group_uri: /api/v1/group/group/1027/
expires: 2025-11-17T16:44:18Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.389742+00:00
source: ietf
abstract:
  The proliferation of AI agents requires robust mechanisms for secure
     discovery.  This document introduces the Agent Name Service (ANS), a
     novel architecture based on DNS addressing the lack of a public agent
     discovery framework.  ANS provides a protocol-agnostic registry
     mechanism that leverages Public Key Infrastructure (PKI) certificates
     for verifiable agent identity and trust.  The architecture features
     several key innovations: a formalized agent registration and renewal
     mechanism for lifecycle management; DNS-inspired naming conventions
     with capability-aware resolution; a modular Protocol Adapter Layer
     supporting diverse communication standards (A2A, MCP, ACP, etc.); and
     precisely defined algorithms for secure resolution.  This
     specification describes structured communication using JSON Schema
     and includes a comprehensive threat analysis.  The result is a
     foundational agent directory service protocol addressing the core
     challenges of secure discovery and interaction in multi-agent
     systems, paving the way for future interoperable, trustworthy, and
     scalable agent ecosystems.

full_text:
  Independent Submission                                          K. Huang
  Internet-Draft                                        DistributedApps.ai
  Intended status: Experimental                              V.S. Narajala
  Expires: 17 November 2025                            Amazon Web Services
                                                                 I. Habler
                                                                    Intuit
                                                                A. Sheriff
                                                             Cisco Systems
                                                                  May 2025


    Agent Name Service (ANS): A Universal Directory for Secure AI Agent
                       Discovery and Interoperability
                           draft-narajala-ans-00

  Abstract

     The proliferation of AI agents requires robust mechanisms for secure
     discovery.  This document introduces the Agent Name Service (ANS), a
     novel architecture based on DNS addressing the lack of a public agent
     discovery framework.  ANS provides a protocol-agnostic registry
     mechanism that leverages Public Key Infrastructure (PKI) certificates
     for verifiable agent identity and trust.  The architecture features
     several key innovations: a formalized agent registration and renewal
     mechanism for lifecycle management; DNS-inspired naming conventions
     with capability-aware resolution; a modular Protocol Adapter Layer
     supporting diverse communication standards (A2A, MCP, ACP, etc.); and
     precisely defined algorithms for secure resolution.  This
     specification describes structured communication using JSON Schema
     and includes a comprehensive threat analysis.  The result is a
     foundational agent directory service protocol addressing the core
     challenges of secure discovery and interaction in multi-agent
     systems, paving the way for future interoperable, trustworthy, and
     scalable agent ecosystems.

  Disclaimer

     The present document reflects the authors' individual opinions and
     does not necessarily represent the views of their respective
     employers.

  Status of This Memo

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






  Huang, et al.           Expires 17 November 2025                [Page 1]


  Internet-Draft                     ANS                          May 2025


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

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

     This Internet-Draft will expire on 2 November 2025.

  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Related Work  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Agent Registry Architecture . . . . . . . . . . . . . . . . .   5
       3.1.  Agent Registration and Renewal  . . . . . . . . . . . . .   8
       3.2.  PKI Integration . . . . . . . . . . . . . . . . . . . . .   9
       3.3.  ANS Protocol Notation . . . . . . . . . . . . . . . . . .  10
       3.4.  Protocol-Agnostic Communication Schema  . . . . . . . . .  12
       3.5.  ANS Naming Structure and Resolution . . . . . . . . . . .  13
         3.5.1.  Formal Naming Structure . . . . . . . . . . . . . . .  14
         3.5.2.  Resolution Process  . . . . . . . . . . . . . . . . .  15
         3.5.3.  Formal Resolution Algorithm . . . . . . . . . . . . .  15
         3.5.4.  Secure Resolution Implementation  . . . . . . . . . .  17
       3.6.  ANS Challenges and Governance . . . . . . . . . . . . . .  18
       3.7.  Agent Identity  . . . . . . . . . . . . . . . . . . . . .  19
     4.  Request/Response Schema for ANS Name Resolution . . . . . . .  24
     5.  Protocol Adapter Layer  . . . . . . . . . . . . . . . . . . .  26
       5.1.  A2A Protocol Adapter  . . . . . . . . . . . . . . . . . .  28
       5.2.  MCP Adapter . . . . . . . . . . . . . . . . . . . . . . .  28
       5.3.  ACP Adapter . . . . . . . . . . . . . . . . . . . . . . .  28



  Huang, et al.           Expires 17 November 2025                [Page 2]


  Internet-Draft                     ANS                          May 2025


       5.4.  Extension Points  . . . . . . . . . . . . . . . . . . . .  29
       5.5.  Cross-Protocol Interoperability Limits  . . . . . . . . .  29
       5.6.  Protocol Adapter API Definition . . . . . . . . . . . . .  29
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  31
       6.1.  MAESTRO-Based Threat Analysis . . . . . . . . . . . . . .  32
         6.1.1.  Threat: Agent Impersonation . . . . . . . . . . . . .  32
         6.1.2.  Threat: Registry Poisoning  . . . . . . . . . . . . .  32
         6.1.3.  Threat: Man-in-the-Middle (MitM) Attacks  . . . . . .  33
         6.1.4.  Threat: Denial of Service (DoS) / Distributed Denial of
                 Service (DDoS)  . . . . . . . . . . . . . . . . . . .  34
       6.2.  Additional Security Controls and Considerations . . . . .  34
         6.2.1.  PKI Security Controls . . . . . . . . . . . . . . . .  34
         6.2.2.  ANS-Specific Security Controls  . . . . . . . . . . .  35
         6.2.3.  Protocol Integration Security . . . . . . . . . . . .  35
         6.2.4.  Side-Channel Deanonymization and Mitigation . . . . .  35
     7.  Implementation Considerations . . . . . . . . . . . . . . . .  36
     8.  Future Considerations . . . . . . . . . . . . . . . . . . . .  38
     9.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  40
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  40
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  41
       11.2.  Informative References . . . . . . . . . . . . . . . . .  41
     Appendix A.  Appendix A: Complete Request/Response Schemas  . . .  43
     Appendix B.  Appendix B: Glossary of Terms - Agent Name Service
             (ANS) . . . . . . . . . . . . . . . . . . . . . . . . . .  43
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  47
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  47

  1.  Introduction

     Agent-to-agent communication is expected to become a significant
     component of internet traffic, driving the need for reliable
     mechanisms enabling agents to discover, verify, and securely interact
     with one another.  Traditional service discovery, notably the Domain
     Name System (DNS) [RFC1035], primarily maps human-readable names to
     network addresses and is insufficient for the dynamic, semantically
     rich, and security-sensitive environment of agentic AI.  Enhancements
     like DNS-Based Service Discovery (DNS-SD) [RFC6763] offer
     improvements but still fall short of the necessary agent capability
     granularity, identity verification, and lifecycle management required
     by autonomous agents.  Furthermore, maintaining a trustworthy
     registry necessitates robust processes for agent registration and
     periodic renewal.

     Several agent communication protocols are emerging to standardize
     interactions:





  Huang, et al.           Expires 17 November 2025                [Page 3]


  Internet-Draft                     ANS                          May 2025


     *  Agent2Agent (A2A) Protocol: Developed by Google, providing a
        standardized protocol for inter-agent communication, aiming to
        bridge different agent frameworks.

     *  Model Context Protocol (MCP): Focused on simplifying the
        integration of AI models with external tools and data sources.

     *  Agent Communication Protocol (ACP): Designed to standardize how
        agents communicate, enabling automation, collaboration, UI
        integration, and developer tooling, evolving from initial MCP
        concepts.

     This document outlines the Agent Name Service (ANS), a framework for
     a protocol-agnostic Agentic AI Registry.  ANS complements these
     emerging protocols by integrating Public Key Infrastructure (PKI) for
     identity and trust, defining structured communication via JSON
     Schema, incorporating DNS-like naming for discovery, establishing
     mechanisms for agent registration and renewal, and providing a formal
     specification of the protocol to enhance precision and
     implementability.  ANS aims to provide a universal, secure directory
     service foundation for interoperable agent ecosystems.

  1.1.  Requirements Language

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

  2.  Related Work

     Traditional service discovery, such as DNS [RFC1035], provides
     essential name-to-address resolution but lacks the semantic
     understanding and security features needed for agentic AI.  DNS-SD
     [RFC6763] adds local service discovery capabilities but doesn't
     address verifiable identity or complex agentCapability matching on a
     global scale.

     Research in multi-agent systems (MAS) has explored various agent
     communication languages (ACLs), such as those defined by the
     Foundation for Intelligent Physical Agents (FIPA) [FIPA-ACL].  While
     influential, these often lack standardized, built-in security
     mechanisms and universally adopted transport protocols suitable for
     the modern internet.

     The emerging protocols represent significant advancements:




  Huang, et al.           Expires 17 November 2025                [Page 4]


  Internet-Draft                     ANS                          May 2025


     *  A2A [A2A-Blog] [A2A-Spec] focuses on bridging agent ecosystems.

     *  MCP [MCP-News] [MCP-Spec] emphasizes dynamic discovery and
        integration of tools/data for AI models.

     *  ACP [IBM-ACP-Placeholder] targets broader agent-to-agent
        communication needs, including delegation and orchestration.

     Our work builds upon these efforts not by replacing them, but by
     providing a complementary, protocol-agnostic infrastructure layer.
     ANS differentiates itself by integrating PKI-based identity
     verification [RFC5280] directly into the discovery and lifecycle
     management process, offering a universal registry mechanism that
     enhances trust and facilitates secure interaction across different
     protocol standards via a common discovery plan.  Furthermore, the
     formalized specification of the ANS protocol ensures clarity and ease
     of implementation.

  3.  Agent Registry Architecture

     The proposed Agent Registry architecture provides a secure,
     interoperable platform for agent discovery and interaction,
     supporting multiple communication protocols through a modular design.
     Key components include:

     *Requesting Agent:*
        The entity initiating the agent registration process, which could
        be an individual, organization, or automated system seeking to
        register a new agent or update existing agent information in the
        registry.

     *Agent Registry:*
        A potentially distributed database for storing ACEM (Agent
        Credential and Entitlement Management) and DID (Decentralized
        Identifier) related information.  This registry encompasses agent
        capabilities, security policies, PKI certificates, protocol-
        specific metadata (via protocolExtensions), and registration/
        renewal timestamps, supporting a comprehensive framework for agent
        identity, authentication, and authorization.

     *Certificate Authority (CA):*
        A trusted entity issuing and managing X.509 digital certificates
        [RFC5280] for agents, forming the root of trust.








  Huang, et al.           Expires 17 November 2025                [Page 5]


  Internet-Draft                     ANS                          May 2025


     *Registration Authority (RA):*
        Verifies agent registration/renewal requests, interacts with the
        CA to issue certificates based on Certificate Signing Requests
        (CSRs), manages the agent lifecycle (registration, renewal,
        revocation), and validates the legal entity of the Requesting
        Agent.  It enforces registry policies.

     *Protocol Adapter Layer:*
        Translates between the registry's internal representation and
        protocol-specific formats (details in Section 5).

     *Request/Response Schema:*
        A protocol-agnostic JSON-based schema [RFC8259] for registry
        interactions (discovery, registration, etc.), incorporating PKI
        data and allowing protocol-specific extensions (details in
        Section 3.4).

     *Agent Name Service (ANS):*
        Enables agent discovery using human-readable, structured names,
        coupled with agentCapability-based resolution (details in
        Section 3.5).

     Figure 1 illustrates the core components of the Agent Name Service
     (ANS) and their interactions.

     <preamble>:Illustrates the interaction between Agent, ANS Service, Agent Registry, CA, RA, and Protocol Adapter Layer.
          
  +-----------+    Requests agent discovery    +-------------+
  |   Agent   | ----------------------------> | ANS Service |
  +-----------+                               +-------------+
                                                        |
                                                        | Looks up agent info
                                                        v
  +-----------------------+    Translates messages    +----------------+
  | Protocol Adapter Layer| <---------------------- | Agent Registry |
  +-----------------------+                         +----------------+
                                                        ^      ^
                                                        |      | Verifies
                                  Validates reg.        |      | identity
                                                        |      |
                                  +-----------------------+  +---------------------+
                                  | Registration Authority|  | Certificate Authority |
                                  +-----------------------+  +---------------------+

                        Figure 1: ANS Architecture






  Huang, et al.           Expires 17 November 2025                [Page 6]


  Internet-Draft                     ANS                          May 2025


     The Protocol Adapter Layer translates between the registry's internal
     representation and protocol-specific formats.  For example, consider
     an agent registering with the MCP.  An MCP tool description might be
     represented as a JSON blob.  The agent would need to be registered
     with ANS first and foremost.  Therefore, imagine this tool is
     associated with the following ANSName:
     "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0".

     This would mean the MCP tool is now discoverable via the ANS.  The
     MCP specific extension data itself might look like this:

     {
       "description": "Analyzes sentiment of text input.",
       "input_schema": {
         "type": "string",
         "description": "Text to analyze."
       },
       "output_schema": {
         "type": "object",
         "properties": {
           "sentiment": {
             "type": "string",
             "enum": ["positive", "negative", "neutral"]
           },
           "score": {
             "type": "number",
             "description": "Sentiment score (-1 to 1)."
           }
         }
       },
       "mcpEndpoint": "https://sentiment.example.com/analyze"
     }

                      Figure 2: Example MCP Extension Data

     The MCP Adapter within the Protocol Adapter Layer would parse this
     JSON and map it to the registry's internal columns.  This could
     involve:

     *  Extracting information implicitly: since the ANSName is
        "mcp://sentimentAnalyzer.textAnalysis.ExampleCorp.v1.0", this
        implicitly defines the:

        -  Protocol: mcp

        -  AgentID: sentimentAnalyzer

        -  agentCapability: textAnalysis



  Huang, et al.           Expires 17 November 2025                [Page 7]


  Internet-Draft                     ANS                          May 2025


        -  Provider: ExampleCorp

        -  Version: v1.0

     *  Storing the description ("Analyzes sentiment of text input.") in a
        dedicated description field within protocolExtensions.

     *  Serializing the input_schema and output_schema and storing them in
        a protocolExtensions column specific to MCP, allowing other MCP-
        aware agents to understand the tool's interface.

     *  The actual MCP endpoint "https://sentiment.example.com/analyze"
        would be stored within the protocolExtensions, under the key
        mcpEndpoint.

     This normalization process allows the Agent Registry to store and
     query MCP-specific information in a protocol-agnostic way, while
     adhering to the ANSName structure for consistent identification and
     resolution.

  3.1.  Agent Registration and Renewal

     Maintaining registry integrity requires explicit lifecycle
     management:

     *Registration*:

     1.  An agent submits a registration request (conforming to the
         defined JSON schema, see Section 3.4) including metadata,
         protocol details (within protocolExtensions), and a CSR.

     2.  The RA validates the agent's identity and submitted information
         against registry policies (potentially involving automated checks
         or human review).

     3.  The RA requests a certificate from the CA using the validated
         CSR.

     4.  The issued certificate and agent information are stored in the
         Agent Registry.

     *Renewal*:

     1.  Agents periodically submit renewal requests before their
         registration or certificate expires.

     2.  The RA verifies continued compliance with policies.




  Huang, et al.           Expires 17 November 2025                [Page 8]


  Internet-Draft                     ANS                          May 2025


     3.  The RA requests a new certificate from the CA.

     4.  The agent's registration/renewal timestamp and potentially
         updated certificate are stored in the Registry.

     *Deregistration/Revocation*: Agents can be deregistered, or their
     certificates revoked (e.g., due to key compromise), removing or
     flagging their entry in the registry and invalidating their
     certificate via standard PKI mechanisms (CRL/OCSP [RFC6960]).

  Agent                           RA                               CA                       Agent Registry
    |---Registration Request--->|                                  |                                |
    | (metadata & CSR)        |                                  |                                |
    |                           |---Validate Identity----->|                                  |
    |                           |<--[Validation Fails]-----|                                  |
    |<----Registration Rejected-|                                  |                                |
    |                           |---[Validation Successful]->                                  |
    |                           |---Request Certificate--->|                                  |
    |                           |                          |<----Issue Certificate----|
    |                           |<----Certificate----------|                                  |
    |                           |---Store Agent Info & Cert-------------------------->|
    |<----Confirmation---------|                                                          |

                   Figure 3: Agent Registration Process

  3.2.  PKI Integration

     Public Key Infrastructure (PKI) [RFC5280] provides the cryptographic
     foundation for trust within ANS.  Each registered agent possesses a
     unique PKI key pair and a corresponding X.509 digital certificate
     issued by a trusted CA via the RA.

     *Identity Verification:*
        The agent's certificate cryptographically binds its public key to
        its verified identity (e.g., its ANSName, organizational
        affiliation).  Other agents can verify digital signatures made
        with the agent's private key by using the public key in the
        certificate, thus ensuring the authenticity and integrity of
        communications.

     *Trust Chain:*
        Certificates are validated against the trusted CA, establishing a
        hierarchical chain of trust.  Agents can determine the
        trustworthiness of other agents by tracing their certificates back
        to a common trusted root CA.






  Huang, et al.           Expires 17 November 2025                [Page 9]


  Internet-Draft                     ANS                          May 2025


     *Lifecycle Management:*
        The validity of an agent's certificate is tied to its registration
        and renewal cycle.  Revoked certificates are managed using
        standard mechanisms like CRLs or OCSP [RFC6960], ensuring that
        compromised or outdated certificates are no longer trusted.

     *Simplification:*
        While managing PKI can be complex, the integrated RA/CA
        interaction within the ANS framework aims to streamline the
        certificate issuance and renewal processes for agent developers
        compared to manual PKI management.

  3.3.  ANS Protocol Notation

     We introduce the following notation for defining ANS elements and
     operations:

     1) Top Level Elements:

     *  Protocol: Communication Protocol

     *  AgentID: Agent Identifier

     *  agentCapability: Agent Capability

     *  Provider: Provider Name

     *  Version: Version Number

     *  Extension: Extension Metadata

     *  Cert: Agent Certificate (X.509)

     *  Sig: Digital Signature

     *  ANSName: Agent Name Service Name

     *  Endpoint: a resolvable endpoint

     2) Data Types:

     *  String: Represents a sequence of characters.

     *  Integer: Represents an integer number.

     *  Boolean: Represents a boolean value (true or false).

     *  Set<T>: Represents a set of elements of type T.



  Huang, et al.           Expires 17 November 2025               [Page 10]


  Internet-Draft                     ANS                          May 2025


     So, the top level elements have the following data types:

     *  Protocol: {a2a, mcp, acp, ...}

     *  AgentID: String

     *  agentCapability: String

     *  Provider: String

     *  Version: String (Semantic Versioning)

     *  Extension: String

     *  Cert: X.509 Certificate

     *  Sig: Digital Signature

     *  ANSName: String

     *  Endpoint: String

     3) Verification Rules:

     Certificate Chain Verification

     VerifyCertChain (Cert, TrustedCA) -> Boolean:
       1. Get the certificate authority (CA_signer) that signed the Cert.
       2. Check for Certificate Revocation status of Cert via CRL or OCSP.
       3. If Cert is Revoked, Return False.
       4. If CA_signer is the TrustedCA, Return True (assuming Cert is validly signed by it and not expired).
       5. Else, get the certificate of CA_signer (IssuerCert) and recursively call
          VerifyCertChain(IssuerCert, TrustedCA).
       6. If no trusted CA is found in the chain, Return False.

             Figure 4: Algorithm 1: Certificate Chain Verification

     Digital Signature Verification

     VerifySignature (Data, Signature, PublicKey) -> Boolean:
       1. Use PublicKey to decrypt/verify the Signature against the Data.
       2. Hash Data using the agreed-upon cryptographic hash function (e.g., SHA-256)
          that was used by the signer.
       3. Compare the hash obtained from the signature with the hash
          calculated from the Data.
       4. If the hashes match and the signature is cryptographically valid,
          Return True.
       5. Else, Return False.



  Huang, et al.           Expires 17 November 2025               [Page 11]


  Internet-Draft                     ANS                          May 2025


             Figure 5: Algorithm 2: Digital Signature Verification

  3.4.  Protocol-Agnostic Communication Schema

     ANS utilizes JSON Schema [RFC8259] to define the structure for all
     registry interactions, including discovery requests/responses and
     registration/renewal requests/responses.  This ensures structured,
     validated communication across different protocols.

     An example AgentRegistrationRequest schema is shown below:

     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "title": "AgentRegistrationRequest",
       "description": "Schema for Agent Registration Request",
       "type": "object",
       "properties": {
         "protocol": {
           "type": "string",
           "enum": ["a2a", "mcp", "acp"],
           "description": "Communication Protocol"
         },
         "agentID": {
           "type": "string",
           "description": "Unique Agent Identifier"
         },
         "agentCapability": {
           "type": "string",
           "description": "Primary Agent Capability"
         },
         "provider": {
           "type": "string",
           "description": "Name of the Provider"
         },
         "version": {
           "type": "string",
           "pattern": "^(0|[1-9]\\d*)\\.(0|[1-9]\\d*)\\.(0|[1-9]\\d*)(?:-((?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\\.(?:0|[1-9]\\d*|\\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\\+([0-9a-zA-Z-]+(?:\\.[0-9a-zA-Z-]+)*))?$",
           "description": "Semantic Versioning format"
         },
         "extension": {
           "type": "string",
           "description": "Extension Metadata"
         },
         "certificate": {
           "type": "object",
           "properties": {
             "subject": {"type": "string", "description": "Certificate Subject"},
             "issuer": {"type": "string", "description": "Certificate Issuer"},



  Huang, et al.           Expires 17 November 2025               [Page 12]


  Internet-Draft                     ANS                          May 2025


             "pem": {
               "type": "string",
               "description": "PEM-encoded Certificate (strongly recommended to use a secure vault reference instead)",
               "readOnly": false
             }
           },
           "required": ["subject", "issuer", "pem"]
         },
         "protocolExtensions": {
           "type": "object",
           "description": "Protocol-specific data"
         }
       },
       "required": ["protocol", "agentID", "agentCapability", "provider", "version", "certificate"]
     }

            Figure 6: Snippet: AgentRegistrationRequest JSON Schema

     *Core Fields:*
        Include common elements like agent communication protocol types
        (a2a, mcp, acp, etc.), requesting/responding agent identifiers,
        timestamps, and PKI certificate details (subject, issuer, PEM
        representation - though referencing a secure vault is recommended
        for the PEM in production).

     *protocolExtensions:*
        A key field within the schema acts as a container for protocol-
        specific data (e.g., an A2A Agent Card, MCP tool descriptions, ACP
        agent profiles).  This allows the registry to store and query
        protocol-specific agentCapabilities while maintaining a common
        core schema.

     *Validation:*
        All interactions with the registry must be validated against these
        schemas.  (Complete schemas are referenced in Appendix A).

  3.5.  ANS Naming Structure and Resolution

     ANS defines a robust, protocol-agnostic mechanism for naming and
     resolving agents across heterogeneous agentic environments.  Its
     principal function is to establish a uniform Endpoint format that
     encodes identity, agentCapability, and contextual metadata for any
     given agent, irrespective of the underlying transport or runtime
     architecture.  ANS ensures that both human-readable and machine-
     resolvable identifiers are preserved in a format designed to
     facilitate dynamic discovery, rigorous trust verification, secure
     communication, seamless service composition, and the representation
     of relationships between agents.  A key motivation for ANS is to move



  Huang, et al.           Expires 17 November 2025               [Page 13]


  Internet-Draft                     ANS                          May 2025


     beyond simple naming resolution to enable precise agentCapability
     discovery, which is not achievable with traditional systems like DNS.
     The design of ANS acknowledges that the agent's agentCapabilities are
     paramount for intelligent interactions, distinguishing it from
     simpler naming systems like DNS.

  3.5.1.  Formal Naming Structure

     The ANSName is formally defined as a string constructed from the
     following components, concatenated in a specific order:

  ANSName = Protocol "://" AgentID "." agentCapability "." Provider ".v" Version ["." Extension]

                       Figure 7: ANSName Structure

     Where:

     *  Protocol ∈ {a2a, mcp, acp, ...} (Specifies the primary
        communication protocol)

     *  AgentID: A unique identifier for the agent within its provider and
        protocol scope.  (String)

     *  agentCapability: Describes the primary capability or service
        offered by the agent.  (String)

     *  Provider: The name of the entity or organization providing the
        agent.  (String)

     *  Version: The semantic version of the agent (e.g., "1.0.2").
        (String)

     *  Extension (Optional): Used for deployment-specific or provider-
        defined metadata (e.g., "hipaa", "testenv").  (String)

     Constraints:

     *  Version MUST adhere to Semantic Versioning standards.

     *  AgentID, agentCapability, Provider SHOULD be registered with a
        governance authority (similar to ICANN for DNS domains) to prevent
        collisions and ensure uniqueness.

     *  Extension SHOULD be used for deployment-specific or provider-
        defined metadata, not for core identity.  In the actual
        implementation, a registry of reserved tokens for Extension can
        enhance security.




  Huang, et al.           Expires 17 November 2025               [Page 14]


  Internet-Draft                     ANS                          May 2025


     Example ANSName:
     "a2a://textProcessor.DocumentTranslation.AcmeCorp.v2.1.hipaa"

  3.5.2.  Resolution Process

     The resolution mechanism in ANS maps a fully qualified ANSName to an
     actionable reference, such as a network address, service binding, or
     a detailed metadata document (Endpoint).  Resolution can be achieved
     through distributed lookups, local resolver caches, or enterprise-
     specific ANS gateways, providing deployment flexibility.  Critically,
     ANS moves beyond simple name resolution to facilitate precise
     agentCapability discovery.

     When an agent (the "Requesting Agent") requires resolution, it
     queries the ANS service (a fundamental component of the Agent
     Registry infrastructure).  The query includes the ANSName of the
     target agent and can optionally incorporate agentCapability filters
     to refine the search.

  Requesting Agent        ANS Service                 Agent Registry          Trusted CA
    |---Resolution Query---->|                           |                       |
    | (ANSName + filters)   |                           |                       |
    |                       |---Query Agent Record--->|                           |
    |                       |                           |<--[Record Not Found]-|
    |                       |<----No Record Found-----|                           |
    |<--Agent Not Found Err--|                           |                       |
    |                       |                           |---[Record Found]---->|
    |                       |<--Return Agent Endpoint-|                           |
    |                       |   (data, sig, cert)     |                           |
    |                       |---Verify Signature (using Agent Registry Key)-->|
    |                       |<--[Signature Invalid]--|                           |
    |<--Invalid Sig Error---|                           |                       |
    |                       |---[Signature Valid]--->|                           |
    |                       |---Verify Cert Chain (Target Agent Cert)------>| (Trusted CA for agent certs)
    |                       |                           |<--[Cert Invalid]-----|
    |                       |<----Invalid Cert Error--|                           |
    |                       |                           |---[Cert Valid]------>|
    |<--Return Verified Endpoint----------------------|                           |
    | (binding & sec info)  |                           |                       |

               Figure 8: Agent Resolution Process Sequence

  3.5.3.  Formal Resolution Algorithm

     The ANS resolution algorithm takes an ANSName and an optional
     RequestedVersionRange as input and returns a resolvable Endpoint or
     an error.




  Huang, et al.           Expires 17 November 2025               [Page 15]


  Internet-Draft                     ANS                          May 2025


     Resolve(ANSName, RequestedVersionRange) -> EndpointRecord / ERROR:
     1. Parse ANSName into Protocol, AgentID, agentCapability,
        Provider, Version, Extension.
     2. Query Agent Registry for Agents with matching Protocol, AgentID,
        agentCapability, Provider.
     3. If no match found:
        Return ERROR("Agent not found").
     4. If multiple matches found (different versions):
        Match = VersionNegotiation(Matches, RequestedVersionRange).
        If Match is ERROR("Incompatible Version"):
          Return ERROR("Incompatible Version").
     5. EndpointRecord_struct = GetAgentEndpointRecord(Match.AgentID).
        // Renamed to avoid conflict, EndpointRecord_struct: {data, signature, Cert}
        If EndpointRecord_struct is ERROR:
          Return ERROR("Could not retrieve endpoint record").
     6. Valid = VerifyAgentEndpointRecord(EndpointRecord_struct,
                                          TrustedCA_for_Registry_Signature,
                                          TrustedCA_for_Agent_Certs).
     7. If Valid is False:
        Return ERROR("Invalid Endpoint").
     8. Return EndpointRecord_struct.data. // Contains the actual endpoint URI/info

     --- Helper Functions ---
     GetAgentEndpointRecord(AgentID_from_Match) -> EndpointRecord_struct / ERROR:
       // Agent Registry implements this to fetch records.
       // This function must enforce authentication and authorization
       // against Agent Registry ACLs if applicable.
       // Returns {data, signature, Cert} or ERROR.

     VerifyAgentEndpointRecord(EndpointRecord_struct, RegistryTrustedCA, AgentCertTrustedCA) -> Boolean:
       // 1. Verify signature on EndpointRecord_struct.data using
       //    AgentRegistry.PublicKey (obtained from a cert issued by RegistryTrustedCA).
       signatureValid = VerifySignature(EndpointRecord_struct.data,
                                        EndpointRecord_struct.signature,
                                        AgentRegistry.PublicKey);
       If not signatureValid:
         Return False; // Or ERROR("Invalid Registry Signature")

       // 2. Verify certificate chain of the target Agent's Cert (EndpointRecord_struct.Cert)
       //    against AgentCertTrustedCA.
       certChainValid = VerifyCertChain(EndpointRecord_struct.Cert, AgentCertTrustedCA);
       If not certChainValid:
         Return False; // Or ERROR("Invalid Agent Certificate Chain")

       Return True;

     // VerifySignature and VerifyCertChain are defined in Section 3.3




  Huang, et al.           Expires 17 November 2025               [Page 16]


  Internet-Draft                     ANS                          May 2025


     VersionNegotiation(Matches, RequestedVersionRange) -> Match_object / ERROR:
       1. Sort Matches by Version (highest to lowest Semantic Version).
       2. For each Match_item in Matches:
       3.   If RequestedVersionRange is empty OR RequestedVersionRange == "*" OR
              IsVersionCompatible(Match_item.Version, RequestedVersionRange):
       4.       Return Match_item;
       5. End For
       6. Return ERROR("Incompatible Version");

     IsVersionCompatible(AgentVersion, ReqRange) -> Boolean:
       // Implement Semantic Version range compatibility check.
       // (e.g., using a library like node-semver's satisfies function)
       // 1. Attempt to parse ReqRange as a SemVer range.
       // 2. If parsing fails, treat ReqRange as a specific SemVer version.
       // 3. Check if AgentVersion is satisfied by the ReqRange.
       // Example: return SemVer.satisfies(AgentVersion, ReqRange);
       Return true; // Placeholder for actual SemVer library call

                     Figure 9: Algorithm 3: ANS Resolution

     IMPLEMENTATION NOTES:

     *  *Cacheability:* To ensure resolvers know when to re-validate
        EndpointRecords, the Agent Registry MUST include a Time-To-Live
        (TTL) value with each resolved Endpoint.  The TTL indicates the
        number of seconds for which the EndpointRecord can be cached.  A
        recommended default TTL is 300 seconds (5 minutes), but this value
        MAY be adjusted based on factors such as the volatility of the
        agent's configuration or the security policy of the Agent
        Registry.  Resolvers MUST re-validate the EndpointRecord (by
        calling GetAgentEndpointRecord) after the TTL has expired.

     *  *Version Negotiation and Pre-release Tags:* When using
        SemVer.satisfies for version negotiation, pre-release tags (e.g.,
        -rc1, -beta) MUST be considered to have lower precedence than the
        corresponding stable version.  For example, version 1.0.0-rc1
        would be considered lower precedence than 1.0.0.  This ensures
        that resolvers prefer stable versions over pre-release versions
        unless explicitly requested (e.g., by specifying a pre-release
        version range).

  3.5.4.  Secure Resolution Implementation

     Key security aspects for the resolution process include:

     *Trust Anchor:*
        The trust anchor for ANS is the Certificate Authority (CA) that
        issues the Agent Registry's own certificate.  The Agent Registry's



  Huang, et al.           Expires 17 November 2025               [Page 17]


  Internet-Draft                     ANS                          May 2025


        certificate contains the public key used to verify the digital
        signatures on the Agent Registry's responses.  This Agent Registry
        certificate (or its issuing CA) must be trusted by all agents that
        use ANS.  A separate trust anchor (or set of CAs) will be used to
        validate the certificates of the agents themselves.

     *Digital Signatures:*
        All responses from the Agent Registry (containing Endpoint
        information) MUST be digitally signed using the Agent Registry's
        private key.  Clients (Requesting Agents) verify this signature
        using the Agent Registry's public key to ensure the integrity and
        authenticity of the received data.

     *DNSSEC-like Security Considerations:*
        While DNSSEC provides a model for securing DNS, its direct
        application to ANS requires careful evaluation due to potential
        increased risk of DoS amplification attacks from larger crypto-
        fields in responses.  Mitigation strategies like rate limiting,
        traffic filtering, and anycast deployment are crucial if DNSSEC-
        like mechanisms are adopted.

     *Certificate Revocation:*
        A robust and timely mechanism for certificate revocation is
        essential.  If the Agent Registry's private key is compromised,
        its certificate MUST be revoked immediately.  Standard methods
        like CRLs [RFC5280] or OCSP [RFC6960] should be used for both
        Agent Registry and individual agent certificates.

     *Ongoing Threat Modeling:*
        Continuous threat modeling is necessary to identify and
        proactively address potential vulnerabilities in the secure
        resolution mechanism.

  3.6.  ANS Challenges and Governance

     Deploying and maintaining a global ANS involves addressing several
     key challenges:

     *Naming Collisions and Squatting:*
        Ensuring the uniqueness of ANSNames, particularly the <AgentID>,
        <agentCapability>, and <Provider> segments, requires a managed
        registration process.  A governance model, potentially similar to
        ICANN's role for DNS, might be necessary to manage top-level
        agentCapabilities, provider identifiers, and resolve disputes.

     *Scalability:*
        Supporting a potentially vast number of agents (billions) requires
        highly scalable registry storage solutions (e.g., distributed



  Huang, et al.           Expires 17 November 2025               [Page 18]


  Internet-Draft                     ANS                          May 2025


        databases like Cassandra, NoSQL databases) and efficient
        resolution mechanisms (e.g., distributed hash tables (DHTs),
        robust caching layers, geographically distributed resolution
        points).

     *Governance:*
        Establishing clear and comprehensive policies for name allocation,
        dispute resolution, operational practices for CAs and RAs, and
        managing the evolution of the trust infrastructure is crucial for
        the long-term stability, trustworthiness, and adoption of ANS.

  3.7.  Agent Identity

     Agent identity within the ANS framework is multifaceted, encompassing
     several components:

     *Cryptographic Identity:*
        The agent's PKI certificate, signed by a trusted CA, provides a
        verifiable cryptographic identity, linking its public key to its
        ANSName and other attributes.

     *Logical Identity:*
        The ANSName itself serves as a human-readable, structured
        identifier that conveys information about the agent's protocol,
        capabilities, provider, and version.

     *Protocol-Specific Identity:*
        Agents may possess identities within their native communication
        protocols (e.g., A2A Agent Card ID, MCP tool identifiers, ACP
        agent URIs).  This information is stored within the
        'protocolExtensions' field of the agent's record in the registry.

     *Verifiable Claims:*
        The registry could support the attachment of digitally signed
        attestations or verifiable credentials to agent profiles, such as
        compliance certifications, capability endorsements, or security
        audit results.

     *Identity linkage:*
        ANS ecosystem leverages the structured naming convention to
        establish relationships between agents.  The core principle is
        that an agent's ANSName serves as a unique and resolvable
        identifier, allowing other agents or the system itself to
        reference it.  The Agent Registry, upon recognizing this request,
        not only returns the target agent's details (binding, metadata,
        certificates) but also automatically resolves the linked agents,
        effectively materializing the relationship and providing all
        necessary information for secure and informed interaction.  This



  Huang, et al.           Expires 17 November 2025               [Page 19]


  Internet-Draft                     ANS                          May 2025


        automated relationship discovery, built upon the foundation of
        uniquely identifiable and resolvable agent names, significantly
        simplifies the orchestration and coordination of complex multi-
        agent systems.

     *Agent Card Validation:* The integrity of Agent Cards within the ANS
     ecosystem is verified through cryptographic methods, utilizing the
     relational patterns between agents.  This process ensures that
     capability declarations are validated against organizational
     policies.  Additionally, endpoint URL structures are enforced to
     comply with security standards such as TLS and proper domain
     constraints.  The Agent Registry oversees and connects these identity
     components, facilitating verification through challenge-response
     protocols that rely on the agent's private key.  Both the Requesting
     Agent and the Registration Authority (RA) play crucial and distinct
     roles in this validation process.

     *Requesting Agent Responsibility:* The Requesting Agent has a primary
     and ongoing responsibility for validating the Agent Card before every
     interaction.  This includes:

     *  *Cryptographic Verification:* Verifying the Agent Card's digital
        signature to ensure it hasn't been tampered with.

     *  *Capability Alignment:* Confirming that the agent's stated
        capabilities are actually what the Requesting Agent expects and
        needs for the intended interaction.  This might involve checking
        specific input/output schemas or testing the agent's performance
        on sample tasks before relying on it for critical operations.

     The Requesting Agent's validation is not a one-time event; it's a
     continuous process that ensures the agent remains trustworthy for
     each specific interaction.  A failure to properly validate an Agent
     Card could expose the Requesting Agent to significant security risks.

     *Registration Authority (RA) Responsibility:* The RA performs a
     foundational validation of the Agent Card during the agent
     registration and renewal processes.  This includes:

     *  *Signature Verification:* Verifying the Agent Card's signature and
        the validity of the associated certificate.

     *  *Policy Adherence:* Ensuring the agent's claimed capabilities and
        operational practices comply with broader registry policies and
        legal requirements.






  Huang, et al.           Expires 17 November 2025               [Page 20]


  Internet-Draft                     ANS                          May 2025


     *  *Legitimacy Checks:* Performing checks to confirm the identity and
        legitimacy of the agent's owner (e.g., domain validation,
        organizational checks).

     The RA's validation provides a baseline level of trust, but it does
     not replace the need for the Requesting Agent to perform its own,
     more context-specific validation.

     Additionally, endpoint URL structures are enforced to comply with
     security standards such as TLS and proper domain constraints.  The
     Agent Registry oversees and connects these identity components,
     facilitating verification through challenge-response protocols that
     rely on the agent's private key.

     *Agent Capability Attestation:* The AI agent's identity and claimed
     capabilities are authenticated through zero-knowledge proof methods.
     Specifically, ZKPs can be employed to allow an agent to prove that it
     possesses certain capabilities (e.g., access to specific data, the
     ability to perform a certain computation) without revealing how it
     possesses those capabilities or the underlying data itself.  For
     example, an agent might use a ZKP to prove it has access to a
     database containing sensitive patient information without revealing
     the specific query it will use or any of the patient data.  This
     involves the agent constructing a proof, based on its private
     knowledge and the claimed capabilities, that can be verified by the
     Agent Registry (or another agent) using only publicly available
     information.

     The verifier gains assurance that the agent possesses the claimed
     capabilities without learning any sensitive information about the
     agent's internal state or data.  During runtime, capabilities are
     dynamically validated as part of the resolution process.  To further
     enhance real-time verification, challenge-response mechanisms are
     employed.

     *Challenge-Response Example:* Imagine an agent claims to be able to
     perform "Sentiment Analysis" with a certain accuracy.

     *  The Agent Registry (or a verifying agent) sends the claimed
        "Sentiment Analysis" agent a specific challenge: a piece of text
        with a known sentiment.

     *  The "Sentiment Analysis" agent processes the text and returns its
        sentiment classification (positive, negative, neutral) and a
        confidence score.

     *  The Agent Registry (or verifying agent) compares the agent's
        response to the known sentiment and the claimed accuracy.



  Huang, et al.           Expires 17 November 2025               [Page 21]


  Internet-Draft                     ANS                          May 2025


     *  If the response is correct and the confidence score aligns with
        the agent's claimed accuracy, the agent's capability is considered
        validated (for that specific challenge).

     *  If the response is incorrect or the confidence score is
        significantly lower than the claimed accuracy, the agent's claimed
        capability is called into question and further challenges or even
        revocation of the agent's registration might be triggered.

     This challenge-response process can be repeated periodically or
     triggered based on certain events (e.g., a change in the agent's
     code, a security alert).  The challenges can be designed to test
     various aspects of the agent's claimed capabilities, ensuring that it
     continues to function as expected over time.  The Agent Registry
     maintains a history of challenge-response results to track the
     agent's performance and reliability.

     By combining ZKPs for initial capability attestation with challenge-
     response mechanisms for ongoing validation, the ANS provides a robust
     framework for ensuring the trustworthiness of AI agents.

     *Authentication Enforcement:* The process involves validating the
     OAuth 2.0 flow to ensure the legitimacy of authorization tokens,
     verifying mTLS certificates to confirm alignment with the registered
     agent's identity, and checking JSON Web Tokens (JWTs) to ensure their
     signatures and claims are accurate and properly authenticated.

     *Agent Identity Module Examples:* The Agent Identity module
     implements resource access control through capability-based security.
     Below are examples for A2A and MCP protocols:





















  Huang, et al.           Expires 17 November 2025               [Page 22]


  Internet-Draft                     ANS                          May 2025


     {
       "a2aCapabilityVerification": {
         "capabilityVerification": {
           "proofMechanism": "ZKP",
           "verificationCircuit": {
             "constraints": [
               "agent.hasCapability(c) AND agent.isAuthorized(c)",
               "agent.certificate.isValid() AND agent.certificate.notRevoked()"
             ],
             "proofGeneration": "Groth16",
             "verificationKey": "0x4a8f..."
           }
         },
         "rateLimit": {
           "algorithm": "TokenBucket",
           "refillRate": "100/s",
           "burstCapacity": 500,
           "perCapability": true
         }
       }
     }

                 Figure 10: A2A Capability Verification Example




























  Huang, et al.           Expires 17 November 2025               [Page 23]


  Internet-Draft                     ANS                          May 2025


     {
       "mcpAgentIdentity": {
         "resourceAccessControl": {
           "model": "RBAC+ABAC",
           "policyDecisionPoint": {
             "engine": "OPA",
             "evaluationMode": "distributed"
           },
           "contextAttributes": [
             "agent.role",
             "resource.classification",
             "time.window",
             "operation.sensitivity"
           ]
         },
         "toolRegistration": {
           "sandboxValidation": {
             "environment": "gVisor",
             "runtime": "V8Isolate",
             "memoryLimit": "256MB",
             "cpuQuota": "0.5",
             "networkPolicy": "DENY_ALL"
           }
         }
       }
     }

                     Figure 11: MCP Agent Identity Example

     The Agent Registry manages and links these identity facets, enabling
     verification via challenge-response protocols using the agent's
     private key.

  4.  Request/Response Schema for ANS Name Resolution

     The following core JSON Schemas define the structure for
     AgentCapability requests (used for resolving ANSNames) and responses.
     These ensure validated and structured communication for discovery
     operations.  (Full schemas are linked in Appendix A).

     AgentCapabilityRequest Schema:










  Huang, et al.           Expires 17 November 2025               [Page 24]


  Internet-Draft                     ANS                          May 2025


     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "title": "AgentCapabilityRequest",
       "description": "Schema for Agent agentCapability Request (Resolution)",
       "type": "object",
       "properties": {
         "requestType": { "type": "string", "enum": ["resolve"] },
         "protocol": { "type": "string",
                       "description": "Target protocol (from ANSName)"},
         "agentID": { "type": "string",
                      "description": "Target agentID (from ANSName)"},
         "agentCapability": { "type": "string",
                              "description": "Target capability (from ANSName)"},
         "provider": { "type": "string",
                       "description": "Target provider (from ANSName)"},
         "version": { "type": "string",
                      "description": "Target version or version range (from ANSName or query)" },
         "extension": { "type": "string",
                        "description": "Target extension (from ANSName, optional)"}
       },
       "required": ["requestType", "protocol", "agentID",
                    "agentCapability", "provider", "version"]
     }

                 Figure 12: AgentCapabilityRequest JSON Schema

     AgentCapabilityResponse Schema:
























  Huang, et al.           Expires 17 November 2025               [Page 25]


  Internet-Draft                     ANS                          May 2025


     {
       "$schema": "http://json-schema.org/draft-07/schema#",
       "title": "AgentCapabilityResponse",
       "description": "Schema for Agent agentCapability Response (Resolution)",
       "type": "object",
       "properties": {
         "Endpoint": {
           "type": "string",
           "description": "Resolved agent address/endpoint URI (e.g., a2a://translatorBot.DocumentTranslation.exampleCorp.v1.2.3.secure)"
         },
         "signature": {
           "type": "string",
           "description": "Digital signature of the Endpoint data by Agent Registry"
         },
         "cert": {
           "type": "string",
           "description": "PEM-encoded Certificate of the target Agent (strongly recommended to use a secure vault reference instead)",
           "readOnly": false
         }
       },
       "required": ["Endpoint", "signature", "cert"]
     }

                 Figure 13: AgentCapabilityResponse JSON Schema

     Key points regarding schemas:

     *  Use a JSON Schema validator library for enforcement.

     *  Pay close attention to required fields and data type constraints.

     *  Validate all incoming and outgoing messages related to ANS
        resolution against these schemas.

     *  Implement graceful error handling for validation failures.

     *  Monitor evolving standards in agent communication (A2A, MCP, ACP)
        and update schemas as necessary to maintain compatibility and
        incorporate new features.

  5.  Protocol Adapter Layer

     The Protocol Adapter Layer is a critical component that enables the
     ANS registry to support diverse agent communication protocols (like
     A2A, MCP, ACP) without being tightly coupled to any single one.  It
     acts as an intermediary, translating between the registry's core
     logic and internal data storage format and the specific requirements
     and metadata formats of each supported protocol.



  Huang, et al.           Expires 17 November 2025               [Page 26]


  Internet-Draft                     ANS                          May 2025


     *Modularity:*
        Adapters are implemented as distinct, pluggable modules (e.g.,
        plugins or separate services).  This allows for easy addition of
        support for new protocols or updates to existing ones without
        altering the core registry logic.

     *Functionality:*
        Each protocol adapter understands how to:

        *  Parse protocol-specific metadata (e.g., from an A2A Agent Card,
           MCP Tool Description) and map relevant parts into the
           registry's internal representation, especially within the
           'protocolExtensions' field of an agent's record.

        *  Extract information from an agent's registry record to
           construct responses to protocol-specific discovery queries.

        *  Potentially handle protocol-specific aspects of the
           registration or validation process if they differ significantly
           from the generic ANS procedures.

     *Each adapter is responsible to securely implement features
     defined by each protocol.*
        Some protocols have built-in security, such as signed messages.

     *Translation Focus:*
        Adapters primarily focus on metadata translation for the purposes
        of discovery and registration.  They do not typically handle real-
        time message translation between different protocols during agent-
        to-agent interaction.  Their role is to help agents find each
        other and verify identity; subsequent communication generally uses
        the agents' shared native protocol.

     *Security aspect:*
        *  All adapter implementations must use secure, up-to-date
           libraries commonly employed for the supported protocols.

        *  Implementations MUST adhere to the security guidance provided
           by each specific protocol.

        *  Since each adapter parses potentially untrusted blobs of data
           (protocol-specific metadata), it is MANDATED that they be
           implemented in memory-safe languages (e.g., Rust, Go) and be
           accompanied by formal test suites to ensure robustness against
           parsing vulnerabilities.

      <preamble>:Conceptual flow showing ANS interacting with different agent protocols via their respective adapters.
          



  Huang, et al.           Expires 17 November 2025               [Page 27]


  Internet-Draft                     ANS                          May 2025


                                   +-----------------+
                                   | Agent Name      |
                                   | Service (ANS)   |
                                   | (Core Registry) |
                                   +-----------------+
                                     /      |      \
                                    /       |       \
                                   v        v        v
           +-----------------+   +-----------------+   +-----------------+
           | A2A Protocol    |<->| MCP Protocol    |<->| ACP Protocol    |
           | Adapter         |   | Adapter         |   | Adapter         |
           +-----------------+   +-----------------+   +-----------------+
                   ^                       ^                       ^
                   |                       |                       |
                   v                       v                       v
           +-----------------+   +-----------------+   +-----------------+
           | A2A Agent       |   | MCP Agent       |   | ACP Agent       |
           +-----------------+   +-----------------+   +-----------------+

               Figure 14: Protocol Adapter Layer Interaction

  5.1.  A2A Protocol Adapter

     *  Parses/stores A2A Agent Card information within
        protocolExtensions.

     *  Enables discovery based on A2A agentCapabilities advertised in the
        card.

     *  Facilitates finding A2A Endpoints listed in the card.

  5.2.  MCP Adapter

     *  Parses/stores MCP Tool and Resource descriptions within
        protocolExtensions.

     *  Enables discovery of agents offering specific MCP tools/resources.

     *  Facilitates finding MCP-compliant Endpoints.

  5.3.  ACP Adapter

     *  Parses/stores ACP agent profiles and agentCapability
        advertisements within protocolExtensions.

     *  Supports discovery based on ACP roles or agentCapabilities.





  Huang, et al.           Expires 17 November 2025               [Page 28]


  Internet-Draft                     ANS                          May 2025


     *  May assist in bootstrapping ACP delegation or orchestration
        workflows by providing initial agent references.

  5.4.  Extension Points

     Adding support for a new protocol involves creating a new adapter
     module that implements the required mapping and discovery logic
     interfaces defined by the registry framework.  This ensures the
     registry can evolve with the agent ecosystem.

  5.5.  Cross-Protocol Interoperability Limits

     The registry primarily enables discovery and identity verification
     across protocols.  An A2A agent can discover an agent advertising MCP
     tools, verify its identity via PKI, and potentially interact if it
     also understands MCP or uses a gateway.  ANS does not automatically
     translate A2A tasks into MCP requests.  It provides the foundational
     trust and location information, but deeper semantic interoperability
     often requires additional mechanisms or multi-protocol support within
     the agents themselves.

  5.6.  Protocol Adapter API Definition

     Protocol Adapters are implemented as plugins that conform to the
     following interface (expressed in a language-agnostic way; adapt to
     your chosen implementation language):

























  Huang, et al.           Expires 17 November 2025               [Page 29]


  Internet-Draft                     ANS                          May 2025


     interface ProtocolAdapter {
       // Identifies the protocol supported by this adapter
       // (e.g., "a2a", "mcp", "acp")
       String getProtocol();

       // Parses protocol-specific metadata from the raw
       // 'protocolExtensions' data (e.g., a JSON object or string)
       // and maps it to a structured internal representation used by
       // the registry (e.g., a map or a dedicated object).
       // Returns a representation of the extracted data.
       Map<String, Object> parseMetadata(Object protocolExtensionsData);

       // Constructs a protocol-specific discovery response payload
       // based on information retrieved from an agent's registry record.
       // 'registryRecord' contains the agent's core ANS data and the
       // parsed protocolExtensions.
       Object createDiscoveryResponse(Map<String, Object> registryRecord);

       // Handles any protocol-specific validation logic required during
       // the agent registration process, beyond the standard ANS checks.
       // 'registrationRequest' is the full request object.
       // Returns true if validation passes, false otherwise.
       Boolean validateRegistration(AgentRegistrationRequest request);
     }

                     Figure 15: Interface: ProtocolAdapter

     Important Considerations:

     *  This is a basic interface.  More complex scenarios might require
        additional methods (e.g., for handling updates, deletions, etc.).

     *  The Map<String, Object> type should be replaced with more specific
        data structures based on your chosen implementation language and
        registry data model.

     *  Error handling should be implemented using exceptions or
        appropriate return codes.

     SUMMARY OF ANS FUNCTIONAL LAYERS











  Huang, et al.           Expires 17 November 2025               [Page 30]


  Internet-Draft                     ANS                          May 2025


       +=============+================+===============================+
       | ANS         | ANS Functional | JSON Schema Implementation    |
       | Component   | Layer          |                               |
       +=============+================+===============================+
       | Policy      | Request        | Forward-chaining rule         |
       | Enforcement | Processing     | processor with sequential     |
       | Engine      |                | evaluation of Agent's certs.  |
       +-------------+----------------+-------------------------------+
       | PKI         | Security       | Hierarchical PKI with Agent   |
       | Governance  | Infrastructure | specific Cert Validation &    |
       |             |                | Integration.                  |
       +-------------+----------------+-------------------------------+
       | A2A         | Protocol       | Zero-knowledge proof          |
       | Protocol    | Adapter        | capability verification       |
       | Engine      |                |                               |
       +-------------+----------------+-------------------------------+
       | MCP         | Protocol       | RBAC+ABAC access control with |
       | Protocol    | Adapter        | OPA                           |
       | Engine      |                |                               |
       +-------------+----------------+-------------------------------+
       | Consensus   | Distributed    | Analyzing Agent Signatures    |
       | Engine      | Governance     |                               |
       +-------------+----------------+-------------------------------+
       | ANS Audit   | Compliance     | Deterministically generate    |
       | Trail       | Layer          | unique Agent IDs (UUIDv5      |
       | System      |                | based on PKI public key hash) |
       +-------------+----------------+-------------------------------+

                  Table 1: Summary of ANS Functional Layers

     This technical implementation of ANS ensures that universal agent
     Registry/Directory operates with cryptographic assurance, distributed
     consensus for critical operations, and real-time compliance
     enforcement while maintaining high performance and scalability
     requirements essential for enterprise AI agent deployments.

  6.  Security Considerations

     The security of the Agent Name Service is paramount for its adoption
     and the trustworthiness of the agent ecosystems it supports.  This
     section outlines key threats, mitigation strategies, and security
     controls, referencing the MAESTRO 7 Layers framework [Huang-MAESTRO]
     where applicable.  See RFC 3552 [RFC3552] for a general guide on
     writing security considerations.







  Huang, et al.           Expires 17 November 2025               [Page 31]


  Internet-Draft                     ANS                          May 2025


  6.1.  MAESTRO-Based Threat Analysis

     This section presents a systematic security threat analysis of the
     proposed ANS protocol.  We identify key potential vulnerabilities and
     map them onto the MAESTRO 7 Layers framework to provide a structured
     understanding of the threat landscape and the corresponding
     mitigation strategies integrated into our design.  MAESTRO stands for
     Multi-Agent Environment, Security, Threat, Risk, and Outcome, and its
     seven layers are: Foundation Models, Data Operations, Agent
     Frameworks, Deployment and Infrastructure, Evaluation and
     Observability, Security and Compliance, and Agent Ecosystem.  By
     analyzing vulnerabilities and risks at each architectural layer, as
     well as cross-layer interactions, MAESTRO enables security teams to
     proactively identify, assess, and mitigate threats unique to agentic
     AI.

  6.1.1.  Threat: Agent Impersonation

     *Risk:*
        An adversary attempts to impersonate a legitimate, registered
        agent inside the ecosystem.

     *Mitigation Strategy:*
        Mandatory implementation of PKI.  Verification of agent identity
        through validation of agent-specific digital certificates (Cert)
        issued by a trusted CA.  Agent must prove possession of the
        private key.

     *Formal Check:*
        *  Agent MUST provide valid Cert on registration.

        *  RA MUST verify Cert against trusted CA.

        *  All communication MUST be digitally signed; recipient MUST
           verify signature using public key from Cert.

        *  See Section Section 3.2 (PKI Integration) and Section 3.7
           (Agent Identity).

     *MAESTRO Layer Mapping:*
        Layer 7 (Agent Ecosystem) - Agent Impersonation/Identity Attack.

  6.1.2.  Threat: Registry Poisoning

     *Risk:*
        An adversary tries to inject malicious data into the Agent
        Registry (e.g., corrupting agentCapabilities or Endpoints).




  Huang, et al.           Expires 17 November 2025               [Page 32]


  Internet-Draft                     ANS                          May 2025


     *Mitigation Strategy:*
        Strict RA validation during registration/renewal; cryptographic
        signing of registry responses (secure resolution); stringent
        database access controls.  Secure resolution ensures responses are
        signed by the Agent Registry's private key, verifiable by clients.

     *Formal Check:*
        *  RA validation procedures (Section Section 3.1).

        *  Secure, authenticated registry responses (Section Section 3.5.4
           leveraging PKI Section Section 3.2).

        *  Database access controls (Infrastructure L4 / Data L2).

     *MAESTRO Layer Mapping:*
        *  Layer 7 (Agent Ecosystem) - Compromised Agent Registry,
           Malicious Agent Discovery.

        *  Layer 6 (Security and Compliance) - RA validation policies,
           cryptographic signing.

        *  Layer 4 (Deployment and Infrastructure) / Layer 2 (Data
           Operations) - Database access controls.

  6.1.3.  Threat: Man-in-the-Middle (MitM) Attacks

     *Risk:*
        An adversary modifies communications between system components
        (agent-agent, agent-registry, agent-RA/CA).

     *Mitigation Strategy:*
        Message authenticity/integrity via digital signatures (agent's PKI
        private key).  Secure transport (e.g., mTLS) is best practice but
        PKI signing is the core mechanism discussed.  Formal resolution
        algorithm (Section 3.5.3) enforces response integrity.

     *Formal Check:*
        PKI signing (Section Section 3.2).

     *MAESTRO Layer Mapping:*
        *  Layer 4 (Deployment and Infrastructure) - Targets communication
           channels.  Secure transport operates here.

        *  Layer 6 (Security and Compliance) - PKI framework providing
           keys/certs managed via L6.






  Huang, et al.           Expires 17 November 2025               [Page 33]


  Internet-Draft                     ANS                          May 2025


  6.1.4.  Threat: Denial of Service (DoS) / Distributed Denial of Service
          (DDoS)

     *Risk:*
        Adversary attempts to incapacitate Agent Registry, RA, CA, or
        resolution services via traffic flooding or resource exhaustion.

     *Mitigation Strategy:*
        Resilience through distributed implementation design.  Standard
        operational defenses (rate limiting, DDoS protection services).
        Formal resolution algorithms may include DoS limits.

     *Formal Check:*
        Architectural design (distributed options in Section Section 7).

     *MAESTRO Layer Mapping:*
        *  Layer 4 (Deployment and Infrastructure) - DoS attacks target L4
           availability.  Architectural resilience is L4 design.

        *  Layer 7 (Agent Ecosystem) - Impact felt at L7 (disrupted
           discovery/interaction).

  6.2.  Additional Security Controls and Considerations

     Implementing ANS requires thorough threat modeling and comprehensive
     security controls.

  6.2.1.  PKI Security Controls

     *Certificate Revocation:*
        Robust CRL [RFC5280] or OCSP [RFC6960] mechanisms are essential
        for handling compromised or decommissioned agent certificates.

     *Secure Key Storage:*
        Agent private keys MUST be protected using strong mechanisms
        (e.g., Hardware Security Modules (HSMs), secure enclaves, OS-level
        key stores).  Compromise of a private key requires immediate
        revocation and re-issuance of the certificate.

     *Registry Access Control:*
        Strict authentication and authorization mechanisms for managing
        the registry (RA operations) and potentially for querying,
        depending on policy.








  Huang, et al.           Expires 17 November 2025               [Page 34]


  Internet-Draft                     ANS                          May 2025


     *RA Validation Rigor:*
        The RA must implement a rigorous validation process to prevent
        malicious or fraudulent registrations.  This may include domain
        validation, organizational checks, and, in some cases, manual
        review.

  6.2.2.  ANS-Specific Security Controls

     *Resolution Integrity:*
        As discussed, use DNSSEC-like mechanisms or signed responses from
        the registry to prevent ANS manipulation or spoofing of resolution
        results.

     *DoS Mitigation:*
        Standard defenses (rate limiting, firewalls, anycast routing) for
        resolution Endpoints are critical.

     *CA Security:*
        The CA(s) underpinning ANS MUST adhere to standard CA best
        practices (e.g., offline root CAs, regular audits, use of HSMs).
        Consideration should be given to using established, trusted CAs or
        building a highly secure, dedicated CA infrastructure.

     *Sybil Attack Resistance:*
        Registration processes should be designed to make the creation of
        large numbers of fake identities (Sybil attack) difficult and/or
        costly.

  6.2.3.  Protocol Integration Security

     *Protocol-Specific Security:*
        Leverage security features within A2A, MCP, ACP (e.g., OAuth,
        capability tokens) for agent-to-agent communication post-
        discovery.

     *Governance and Trust Framework:*
        Clear policies, liability, and trust anchors are essential for
        adoption.

  6.2.4.  Side-Channel Deanonymization and Mitigation

     The process of querying the Agent Registry for specific
     agentCapabilities could unintentionally reveal sensitive information
     about the querier's intent, business objectives, or operational
     profile.  To mitigate this risk, the implementation must prioritize:






  Huang, et al.           Expires 17 November 2025               [Page 35]


  Internet-Draft                     ANS                          May 2025


     *  *Private Information Retrieval (PIR) implementation:* To enable
        retrieval of information from the Agent Registry without revealing
        which information is being retrieved.  Evaluate various PIR
        libraries to determine the most secure and efficient
        implementation based on use case.  Prioritize the most performant
        and secure library.

     *  *Anonymized Query Relays:* Implementing query relays to hide the
        origin of the requests and prevent ANS Registry from seeing what
        agents are querying for what capabilities.

     *  *Differential Privacy for Aggregated Query Data:* Anonymize all
        data before sending to a 3rd party, ensuring that PII isn't
        included in the request.

     *  *Query Pattern Analysis:* Analyzing query patterns for anomalous
        behavior, and block queries that look suspicious.

     *  *Rate Limiting:* Implementing rate limiting to prevent potential
        DDoS attacks, and help obfuscate queries.

     *  *Auditing:* Ensure all security implementations are audited
        regularly.

     *  *Privacy Controls for Query and Response Data:* Implementation of
        data anonymization techniques to enhance privacy compliance.

  7.  Implementation Considerations

     The Agent Registry, the core of ANS, can be implemented using various
     architectural patterns.  The choice depends on factors such as the
     expected scale of deployment, trust model, performance requirements
     (latency, throughput), administrative overhead, and cost.  The
     Protocol Adapter Layer is well-suited to a plugin-based architecture.

     Common implementation patterns for the registry include:

     *Centralized:*
        A single logical registry instance.  Simple to manage and ensures
        strong consistency.  However, it can be a single point of failure
        and a performance bottleneck.  Suitable for smaller, private, or
        experimental deployments.

     *Distributed (e.g., using Cassandra, CockroachDB):*
        Offers high availability, fault tolerance, and scalability.
        Technologies like Cassandra provide tunable consistency (often
        eventual consistency).  Requires robust coordination mechanisms
        and careful data partitioning strategies.



  Huang, et al.           Expires 17 November 2025               [Page 36]


  Internet-Draft                     ANS                          May 2025


     *Distributed (DHT - Distributed Hash Table):*
        Highly scalable peer-to-peer lookup.  Can be complex for state
        management and ensuring data integrity.  Suitable for very large-
        scale, decentralized deployments where eventual consistency is
        acceptable.

     *Blockchain/Distributed Ledger Technology (DLT):*
        Smart contracts can act as Registry Agents, with registrations and
        updates recorded as transactions on a blockchain.  Offers high
        security, transparency, and auditability but typically suffers
        from high latency, limited scalability (transactions per second),
        and significant write amplification (one logical write results in
        many physical writes across the network and storage), increasing
        storage costs and reducing performance.

     *Federated:*
        Multiple independent registries interoperate, often aligning with
        organizational or geographic boundaries.  Requires standardized
        inter-registry communication protocols, shared trust anchors
        (e.g., cross-certified CAs or a common root CA), and mechanisms
        for cross-domain name resolution and identity verification.
        Without these, a federated system risks becoming a collection of
        isolated silos.

     *Hybrid:*
        Combines elements of different patterns.  For example, a
        centralized RA/CA infrastructure might serve multiple distributed/
        replicated read-only registry nodes.  Caching layers (e.g., Redis,
        Memcached) can be used to improve read performance in many of
        these models.  Requires careful management of consistency between
        components.

     Key considerations when choosing an implementation pattern:

     *  *Consistency vs. Latency:* Strong consistency ensures all reads
        see the most recent write but can increase latency.  Eventual
        consistency allows lower latency and higher scalability but reads
        might temporarily see stale data.

     *  *Write Amplification (especially for Blockchain):* Be mindful of
        the storage and performance implications.

     *  *Operational Cost:* Includes hardware, software, and personnel.
        Blockchain solutions can be particularly expensive to operate.

     *  *Complexity:* Distributed systems (DHTs, blockchains, some
        federated models) are generally more complex to design, implement,
        deploy, and maintain than centralized systems.



  Huang, et al.           Expires 17 November 2025               [Page 37]


  Internet-Draft                     ANS                          May 2025


     DECISION MATRIX FOR AGENT REGISTRY IMPLEMENTATION PATTERNS

     +===========+===========+===========+===========+===========+==========+
     |Feature    |Centralized|Distributed|Distributed|Blockchain/|Federated |
     |           |           |(Cassandra)|(DHT)      |DLT        |          |
     +===========+===========+===========+===========+===========+==========+
     |Consistency|Strong     |Tunable    |Eventual   |Strong     |Tunable   |
     |           |           |(Eventual) |           |           |(Eventual)|
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Latency    |Low        |Medium     |Medium to  |High       |Medium to |
     |           |           |           |High       |           |High      |
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Scalability|Limited    |High       |Very High  |Limited    |High      |
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Fault      |Low        |High       |High       |High       |Medium    |
     |Tolerance  |           |           |           |           |          |
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Security   |Medium     |Medium     |Medium     |High       |Medium    |
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Operational|Low        |Medium     |Medium     |High       |Medium    |
     |Cost       |           |           |           |           |          |
     +-----------+-----------+-----------+-----------+-----------+----------+
     |Complexity |Low        |Medium     |High       |High       |Medium    |
     +-----------+-----------+-----------+-----------+-----------+----------+

      Table 2: Decision Matrix for Agent Registry Implementation Patterns

  8.  Future Considerations

     This document lays the foundational groundwork for ANS.  Significant
     future work is envisioned to mature the proposal into a widely
     adopted standard:

     *  *Prototype Implementation and Evaluation:* Build and rigorously
        evaluate a working ANS prototype.  The existing work at
        https://github.com/kenhuangus/dns-for-agents/ serves as an initial
        base.

     *  *Bootstrap Model for Distributed Trust:* Explore an innovative
        bootstrap model for the distributed trust infrastructure,
        potentially focusing on a foundation-led root governance approach
        with delegated sub-spaces (analogous to CNCF's certificate
        transparency roots).  This includes developing a sustainable
        funding and fee schedule.







  Huang, et al.           Expires 17 November 2025               [Page 38]


  Internet-Draft                     ANS                          May 2025


     *  *Performance & Scalability Benchmarking:* Conduct thorough
        benchmarking of resolution latency, registration throughput, and
        overall scalability under various load conditions and deployment
        models.

     *  *Advanced Cryptography:* Investigate the integration of privacy-
        preserving cryptographic techniques, such as zero-knowledge proofs
        (ZKPs) for selective capability advertisement/disclosure, or more
        advanced PIR schemes.

     *  *Formal Verification:* Mathematically model and formally verify
        the security properties of the registration, resolution, and
        identity management protocols within ANS.

     *  *Detailed Governance Model:* Develop a comprehensive governance
        model, including detailed policies for naming conventions, CA/RA
        operational requirements, dispute resolution mechanisms, and the
        evolution of the trust framework.

     *  *Platform and Framework Integration:* Demonstrate and facilitate
        integration with popular agent development frameworks (e.g.,
        LangChain, AutoGen, CrewAI) and major cloud platforms.

     *  *Semantic Interoperability Enhancements:* Research mechanisms that
        leverage ANS metadata for deeper cross-protocol communication,
        such as standardized capability ontologies or translation gateways
        facilitated by ANS discovery.

     *  *Reputation Systems:* Investigate the integration of reputation
        scores, endorsements, or attestations into agent profiles within
        ANS to further enhance trust in agent interactions.

     *  *ANS Capability Negotiation and Binding Protocol:* Develop
        standardized protocols that allow agents, post-ANS resolution, to
        negotiate specific capabilities, agree on service level objectives
        (SLOs), and formally bind to service contracts.

     *  *Governance White Paper:* Draft a detailed white paper outlining
        name allocation strategies, a sustainable fee model, dispute
        arbitration processes, and stewardship of the root CA
        infrastructure.










  Huang, et al.           Expires 17 November 2025               [Page 39]


  Internet-Draft                     ANS                          May 2025


  9.  Conclusion

     The Agent Name Service (ANS) offers a foundational infrastructure
     designed to foster a more secure, trustworthy, and interconnected
     ecosystem for agentic AI.  By addressing the critical needs of
     verifiable identity, secure discovery, and protocol-agnostic
     interoperability, ANS aims to provide significant benefits:

     *  *Enhancing Interoperability:* A protocol-agnostic directory
        facilitates seamless discovery and initial contact between diverse
        agents built on different communication standards.

     *  *Boosting Trust and Security:* The integration of PKI for identity
        verification enhances trust, which is crucial for agents operating
        in sensitive domains such as finance, healthcare, and
        cybersecurity.

     *  *Accelerating Innovation:* By providing common infrastructure for
        discovery and identity, ANS can lower barriers to entry for
        developers, allowing them to focus on core agent functionalities
        and solutions.

     *  *Facilitating Autonomous Systems:* ANS is a critical enabler for
        complex autonomous systems that require dynamic, secure discovery
        and interaction between their constituent agents (e.g., in
        autonomous vehicles, smart cities, and industrial automation).

     *  *Powering Secure AI Marketplaces:* The framework can serve as a
        foundation for AI marketplaces where agents with verifiable
        identities and capabilities can be securely listed, discovered,
        and engaged.

     The modular Protocol Adapter Layer ensures that ANS can evolve and
     extend its support to new and emerging agent communication standards.
     While challenges related to governance, global scalability, and
     achieving deep semantic interoperability remain, ANS represents a
     necessary and significant step towards building a robust, secure, and
     scalable future for agentic AI.

  10.  IANA Considerations

     This document has no IANA actions requested at this time.  Future
     versions may request registration of a URI scheme for ANSNames, new
     port numbers if a dedicated ANS protocol is defined, or new
     registries for ANS components if deemed necessary by the community.

  11.  References




  Huang, et al.           Expires 17 November 2025               [Page 40]


  Internet-Draft                     ANS                          May 2025


  11.1.  Normative References

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

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

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/info/rfc5280>.

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

     [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
                Galperin, S., and C. Adams, "X.509 Internet Public Key
                Infrastructure Online Certificate Status Protocol - OCSP",
                RFC 6960, DOI 10.17487/RFC6960, June 2013,
                <https://www.rfc-editor.org/info/rfc6960>.

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

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

  11.2.  Informative References

     [A2A-Blog] Surapaneni, R., Jha, M., Vakoc, M., and T. Segal,
                "Announcing the Agent2Agent Protocol (A2A)", Google for
                Developers Blog , April 2025,
                <https://developers.googleblog.com/en/a2a-a-new-era-of-
                agent-interoperability/>.

     [A2A-Spec] Agent2Agent Protocol Specification Authors, "Agent2Agent
                (A2A) Protocol Specification", 2025,
                <https://github.com/google/A2A>.




  Huang, et al.           Expires 17 November 2025               [Page 41]


  Internet-Draft                     ANS                          May 2025


     [MCP-News] Anthropic, "Model context protocol (MCP)", 2024,
                <https://www.anthropic.com/news/model-context-protocol>.

     [MCP-Spec] Model Context Protocol Specification Authors, "Model
                Context Protocol (MCP) Specification", March 2025,
                <https://modelcontextprotocol.io/
                specification/2025-03-26>.

     [MCP-Intro-Schmid]
                Schmid, P., "MCP Introduction", 2025,
                <https://www.philschmid.de/mep-introduction>.

     [FIPA-ACL] Foundation for Intelligent Physical Agents (FIPA), "FIPA
                Agent Communication Language Specifications", FIPA
                Technical Report , 2002,
                <http://www.fipa.org/repository/aclspecs.html>.

     [Habler-A2A-Secure]
                Habler, I., Huang, K., Narajala, V.S., and P. Kulkarni,
                "Building a secure agentic Al application leveraging A2A
                protocol", arXiv preprint arXiv:2504.16902 , 2025,
                <https://www.arxiv.org/abs/2504.16902>.

     [Narajala-MCP-Secure]
                Narajala, V.S. and I. Habler, "Enterprise-Grade Security
                for the Model Context Protocol (MCP): Frameworks and
                Mitigation Strategies", arXiv preprint arXiv:2504.08623 ,
                2025, <https://arxiv.org/abs/2504.08623>.

     [Huang-MAESTRO]
                Huang, K., Sheriff, A., Sotiropoulos, J., Del, R.F., and
                V. Lu, "Multi-agentic system threat modelling guide OWASP
                GenAI security project", April 2025,
                <https://www.researchgate.net/publication/391204915_Multi-
                Agentic_system_Threat_Modelling_Guide_OWASP_GenAl_Security
                _Project>.

     [Narajala-ToolSquatting]
                Narajala, V.S., Huang, K., and I. Habler, "Securing genai
                multi-agent systems against tool squatting: A zero trust
                registry-based approach", arXiv.org , 2025,
                <https://arxiv.org/abs/2504.19951>.

     [IBM-ACP-Placeholder]
                IBM Research, "(Placeholder for anticipated IBM ACP
                publication/specification link)", 2025.





  Huang, et al.           Expires 17 November 2025               [Page 42]


  Internet-Draft                     ANS                          May 2025


     [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
                Text on Security Considerations", BCP 72, RFC 3552,
                DOI 10.17487/RFC3552, July 2003,
                <https://www.rfc-editor.org/info/rfc3552>.

  Appendix A.  Appendix A: Complete Request/Response Schemas

     The detailed JSON Schema documents for various registry interactions
     are maintained externally due to their length.  Implementers should
     refer to these sources for complete and up-to-date schema
     definitions.  It is crucial that these schemas are well-commented and
     validated in any ANS implementation.

     *  AgentRegistrationRequest Schema: https://github.com/kenhuangus/
        dns-for-agents/blob/main/agent_registration_request_schema.json

     *  AgentRenewalRequest Schema: https://github.com/kenhuangus/dns-for-
        agents/blob/main/agent_renewal_request_schema.json

     *  AgentRegistrationResponse Schema: https://github.com/kenhuangus/
        dns-for-agents/blob/main/agent_registration_response_schema.json

     *  AgentRenewalResponse Schema: https://github.com/kenhuangus/dns-
        for-agents/blob/main/agent_renewal_response_schema.json

     *  AgentCapabilityRequest Schema (for resolution):
        https://github.com/kenhuangus/dns-for-agents/blob/main/
        agent_capability_request.schema.json

     *  AgentCapabilityResponse Schema (for resolution):
        https://github.com/kenhuangus/dns-for-agents/blob/main/
        agent_capability_response.schema.json

  Appendix B.  Appendix B: Glossary of Terms - Agent Name Service (ANS)

     *A2A (Agent2Agent Protocol):*
        A communication protocol developed by Google for standardizing
        inter-agent communication, designed to bridge different agent
        frameworks.

     *ACP (Agent Communication Protocol):*
        A protocol designed by IBM Research to standardize how agents
        communicate, enabling automation, collaboration, UI integration,
        and developer tooling.

     *Agent:*
        An autonomous software entity capable of performing tasks, making
        decisions, and interacting with other agents or systems.



  Huang, et al.           Expires 17 November 2025               [Page 43]


  Internet-Draft                     ANS                          May 2025


     *Agent Identity:*
        The verifiable identity of an agent within the ANS ecosystem,
        comprising cryptographic identity (PKI certificate), logical
        identity (ANSName), and protocol-specific identities.

     *Agent Registry:*
        A database storing registered agent information including
        capabilities, security policies, PKI certificates, protocol-
        specific metadata, and registration/renewal timestamps.

     *agentCapability:*
        A specific function, service, or skill that an agent can perform
        or provide to other agents or users.

     *ANS (Agent Name Service):*
        A universal directory service framework that enables secure
        discovery and interoperability between AI agents across different
        protocols and platforms.

     *ANSName:*
        A structured, human-readable, and machine-resolvable identifier
        for agents in the ANS ecosystem.

     *CA (Certificate Authority):*
        A trusted entity that issues and manages digital certificates that
        bind public keys to entities (like agents) to establish a chain of
        trust in the ANS ecosystem.

     *Certificate Chain Verification:*
        The process of validating a certificate by checking the chain of
        trust from the certificate up to a trusted root certificate
        authority.

     *Certificate Revocation:*
        The process of invalidating a certificate before its scheduled
        expiration date, typically due to a key compromise or when an
        agent is deregistered.

     *CRL (Certificate Revocation List):*
        A list of digital certificates that have been revoked by the
        issuing CA before their scheduled expiration date and should no
        longer be trusted.

     *CSR (Certificate Signing Request):*
        A message, typically in a standardized format, sent by an
        applicant (an agent in this context) to a Certificate Authority to
        apply for a digital identity certificate.




  Huang, et al.           Expires 17 November 2025               [Page 44]


  Internet-Draft                     ANS                          May 2025


     *Digital Signature:*
        A mathematical scheme for verifying the authenticity (proof of
        sender) and integrity (proof data has not been altered) of digital
        messages or documents.

     *DHT (Distributed Hash Table):*
        A decentralized distributed system that provides a lookup service
        similar to a hash table; keys are mapped to values, and the table
        is distributed among participating nodes.

     *DNS (Domain Name System):*
        The hierarchical and decentralized naming system used to identify
        computers, services, and other resources reachable through the
        Internet or other Internet Protocol networks.

     *DNS-SD (DNS-Based Service Discovery):*
        An extension to DNS that enables automatic discovery of services
        available on a local network using standard DNS queries.

     *Endpoint:*
        A resolvable network address, service binding, or metadata
        document that allows agents to connect and communicate with each
        other.

     *Extension (in ANSName):*
        An optional field in the ANSName structure that holds deployment-
        specific or provider-defined metadata, not part of the core
        identity.

     *Interoperability:*
        The ability of different agent systems, devices, or applications
        from different vendors to access, exchange, integrate, and
        cooperatively use data in a coordinated manner.

     *MAESTRO (7 Layers):*
        A threat modeling framework specifically designed for agentic AI
        systems, consisting of 7 layers, used to structure the security
        analysis of ANS.

     *MAS (Multi-Agent Systems):*
        Systems composed of multiple interacting intelligent agents that
        can cooperate, coordinate, or compete to solve problems that are
        beyond the individual capabilities or knowledge of each agent.

     *MCP (Model Context Protocol):*
        A protocol developed by Anthropic focused on simplifying the
        integration of AI models with external tools and data sources.




  Huang, et al.           Expires 17 November 2025               [Page 45]


  Internet-Draft                     ANS                          May 2025


     *OCSP (Online Certificate Status Protocol):*
        An Internet protocol used for obtaining the revocation status of
        an X.509 digital certificate as an alternative to CRLs, providing
        more timely status information.

     *PKI (Public Key Infrastructure):*
        A set of roles, policies, hardware, software, and procedures
        needed to create, manage, distribute, use, store, and revoke
        digital certificates and manage public-key encryption.

     *Protocol Adapter Layer:*
        A component in the ANS architecture that translates between the
        registry's internal, protocol-agnostic representation and
        protocol-specific formats for metadata and discovery.

     *protocolExtensions (in Schema):*
        A flexible field within the ANS JSON schemas that acts as a
        container for protocol-specific data, allowing ANS to support
        diverse agent types.

     *Provider (in ANSName):*
        An organization or entity that offers, maintains, or is
        responsible for agents registered in the ANS ecosystem.

     *RA (Registration Authority):*
        An entity, authorized by a CA, that verifies agent registration
        and renewal requests, interacts with the CA to issue certificates,
        and manages aspects of the agent lifecycle.

     *Registry Poisoning:*
        A security threat where an adversary successfully injects
        malicious, false, or misleading data into the Agent Registry to
        disrupt services or deceive users/agents.

     *Semantic Versioning:*
        A formal versioning scheme with a format of MAJOR.MINOR.PATCH
        (e.g., 1.2.3), used to indicate compatibility and changes in agent
        versions.

     *Service Discovery:*
        The process of automatically detecting devices and services
        offered by these devices on a computer network.

     *Signature Verification:*
        The process of using the signer's public key to check that a
        digital signature is authentic and that the associated data has
        not been tampered with since it was signed.




  Huang, et al.           Expires 17 November 2025               [Page 46]


  Internet-Draft                     ANS                          May 2025


     *Sybil Attack:*
        A type of attack on a peer-to-peer network in which a malicious
        actor creates a large number of pseudonymous identities and uses
        them to gain a disproportionately large influence.

     *Trust Anchor:*
        A CA certificate that is implicitly trusted and serves as the
        starting point for validating a certificate chain in a PKI system.

     *Version Negotiation:*
        The process by which communicating entities (agents in this case)
        determine which version of a protocol or capability to use, based
        on compatibility and preferences.

     *VerifyCertChain (Function):*
        A function or process that checks the validity of a digital
        certificate by tracing its chain of signatures and revocation
        statuses back to a trusted root CA (Trust Anchor).

     *VerifySignature (Function):*
        A function or process that validates a digital signature against a
        given message and a public key to confirm the message's
        authenticity and integrity.

  Acknowledgements

     The authors acknowledge the contributions of the communities and
     organizations developing foundational agent communication standards,
     including Google (A2A), Anthropic (MCP), IBM (ACP), and the broader
     AI research community.

     This document was created as part of the OWASP Gen AI Security
     Project - Agentic Security Initiative (ASI).

  Authors' Addresses

     Ken Huang
     DistributedApps.ai
     Email: ken.huang@distributedapps.ai


     Vineeth Sai Narajala
     Amazon Web Services
     Email: abcvineeth.sai@gmail.com


     Idan Habler
     Intuit



  Huang, et al.           Expires 17 November 2025               [Page 47]


  Internet-Draft                     ANS                          May 2025


     Email: idan_habler@intuit.com


     Akram Sheriff
     Cisco Systems
     Email: isheriff@cisco.com













































  Huang, et al.           Expires 17 November 2025               [Page 48]


name: draft-ietf-httpbis-layered-cookies
rev: 01
title: Cookies: HTTP State Management Mechanism
time: 2025-11-18T13:22:03Z
group_uri: /api/v1/group/group/1718/
expires: 2026-05-22T13:22:03Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.401188+00:00
source: ietf
abstract:
  This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.

full_text:
  HTTP                                                A. van Kesteren, Ed.
  Internet-Draft                                                     Apple
  Obsoletes: [6265] (if approved)                          J. Hofmann, Ed.
  Intended status: Standards Track                                  Google
  Expires: 22 May 2026                                    18 November 2025


                  Cookies: HTTP State Management Mechanism
                   draft-ietf-httpbis-layered-cookies-01

  Abstract

     This document defines the HTTP Cookie and Set-Cookie header fields.
     These header fields can be used by HTTP servers to store state
     (called cookies) at HTTP user agents, letting the servers maintain a
     stateful session over the mostly stateless HTTP protocol.  Although
     cookies have many historical infelicities that degrade their security
     and privacy, the Cookie and Set-Cookie header fields are widely used
     on the Internet.  This document obsoletes RFC 6265 and 6265bis.

  About This Document

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

     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-httpbis-layered-cookies/.

     Discussion of this document takes place on the HTTP Working Group
     mailing list (mailto:ietf-http-wg@w3.org), which is archived at
     https://lists.w3.org/Archives/Public/ietf-http-wg/.  Working Group
     information can be found at https://httpwg.org/.

     Source for this draft and an issue tracker can be found at
     https://github.com/httpwg/http-extensions/labels/cookies.

  Status of This Memo

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

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







  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 1]


  Internet-Draft                   Cookies                   November 2025


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

     This Internet-Draft will expire on 22 May 2026.

  Copyright Notice

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

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

     This document may contain material from IETF Documents or IETF
     Contributions published or made publicly available before November
     10, 2008.  The person(s) controlling the copyright in some of this
     material may not have granted the IETF Trust the right to allow
     modifications of such material outside the IETF Standards Process.
     Without obtaining an adequate license from the person(s) controlling
     the copyright in such materials, this document may not be modified
     outside the IETF Standards Process, and derivative works of it may
     not be created outside the IETF Standards Process, except to format
     it for publication as an RFC or to translate it into languages other
     than English.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.1.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   6
       2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
       2.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.  Which Requirements to Implement . . . . . . . . . . . . . . .   7
       3.1.  Cookie Producing Implementations  . . . . . . . . . . . .   8
       3.2.  Cookie Consuming Implementations  . . . . . . . . . . . .   8
       3.3.  Programming Languages & Software Frameworks . . . . . . .   8
     4.  Server Requirements . . . . . . . . . . . . . . . . . . . . .   9
       4.1.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .   9
         4.1.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .   9
         4.1.2.  Semantics (Non-Normative) . . . . . . . . . . . . . .  11



  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 2]


  Internet-Draft                   Cookies                   November 2025


         4.1.3.  Cookie Name Prefixes  . . . . . . . . . . . . . . . .  14
       4.2.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  16
         4.2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . .  16
         4.2.2.  Semantics . . . . . . . . . . . . . . . . . . . . . .  17
     5.  User Agent Requirements . . . . . . . . . . . . . . . . . . .  17
       5.1.  Cookie Concepts . . . . . . . . . . . . . . . . . . . . .  17
         5.1.1.  Cookie Store And Limits . . . . . . . . . . . . . . .  17
         5.1.2.  Cookie Struct . . . . . . . . . . . . . . . . . . . .  18
       5.2.  Cookie Store Eviction . . . . . . . . . . . . . . . . . .  19
         5.2.1.  Remove Expired Cookies  . . . . . . . . . . . . . . .  19
         5.2.2.  Remove Excess Cookies for a Host  . . . . . . . . . .  19
         5.2.3.  Remove Global Excess Cookies  . . . . . . . . . . . .  20
       5.3.  Subcomponent Algorithms . . . . . . . . . . . . . . . . .  20
         5.3.1.  Parse a Date  . . . . . . . . . . . . . . . . . . . .  21
         5.3.2.  Domain Matching . . . . . . . . . . . . . . . . . . .  22
         5.3.3.  Cookie Default Path . . . . . . . . . . . . . . . . .  23
         5.3.4.  Path Matching . . . . . . . . . . . . . . . . . . . .  23
       5.4.  Main Algorithms . . . . . . . . . . . . . . . . . . . . .  23
         5.4.1.  Parse and Store a Cookie  . . . . . . . . . . . . . .  24
         5.4.2.  Parse a Cookie  . . . . . . . . . . . . . . . . . . .  24
         5.4.3.  Store a Cookie  . . . . . . . . . . . . . . . . . . .  28
         5.4.4.  Garbage Collect Cookies . . . . . . . . . . . . . . .  31
         5.4.5.  Retrieve Cookies  . . . . . . . . . . . . . . . . . .  31
         5.4.6.  Serialize Cookies . . . . . . . . . . . . . . . . . .  33
       5.5.  Requirements Specific to Non-Browser User Agents  . . . .  33
         5.5.1.  The Set-Cookie Header Field . . . . . . . . . . . . .  33
         5.5.2.  The Cookie Header Field . . . . . . . . . . . . . . .  34
         5.5.3.  Cookie Store Eviction for Non-Browser User Agents . .  35
       5.6.  Requirements Specific to Browser User Agents  . . . . . .  35
     6.  Implementation Considerations . . . . . . . . . . . . . . . .  36
       6.1.  Limits  . . . . . . . . . . . . . . . . . . . . . . . . .  36
       6.2.  Application Programming Interfaces  . . . . . . . . . . .  36
     7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  36
       7.1.  Third-Party Cookies . . . . . . . . . . . . . . . . . . .  37
       7.2.  Cookie Policy . . . . . . . . . . . . . . . . . . . . . .  38
       7.3.  User Controls . . . . . . . . . . . . . . . . . . . . . .  38
       7.4.  Expiration Dates  . . . . . . . . . . . . . . . . . . . .  39
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  39
       8.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  39
       8.2.  Ambient Authority . . . . . . . . . . . . . . . . . . . .  39
       8.3.  Clear Text  . . . . . . . . . . . . . . . . . . . . . . .  40
       8.4.  Session Identifiers . . . . . . . . . . . . . . . . . . .  41
       8.5.  Weak Confidentiality  . . . . . . . . . . . . . . . . . .  41
       8.6.  Weak Integrity  . . . . . . . . . . . . . . . . . . . . .  42
       8.7.  Reliance on DNS . . . . . . . . . . . . . . . . . . . . .  43
       8.8.  SameSite Cookies  . . . . . . . . . . . . . . . . . . . .  43
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  43
       9.1.  Cookie  . . . . . . . . . . . . . . . . . . . . . . . . .  43



  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 3]


  Internet-Draft                   Cookies                   November 2025


       9.2.  Set-Cookie  . . . . . . . . . . . . . . . . . . . . . . .  44
     10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  44
     References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  44
       Normative References  . . . . . . . . . . . . . . . . . . . . .  44
       Informative References  . . . . . . . . . . . . . . . . . . . .  45
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  46

  1.  Introduction

     This document defines the HTTP Cookie and Set-Cookie header fields.
     Using the Set-Cookie header field, an HTTP server can pass name/value
     pairs and associated metadata (called cookies) to a user agent.  When
     the user agent makes subsequent requests to the server, the user
     agent uses the metadata and other information to determine whether to
     return the name/value pairs in the Cookie header field.

     Although simple on their surface, cookies have a number of
     complexities.  For example, the server can scope the maximum amount
     of time during which the user agent should return the cookie, the
     servers to which the user agent should return the cookie, and whether
     the cookie can be accessed through a non-HTTP API, such as JavaScript
     in a web browser.

     For historical reasons, cookies contain a number of security and
     privacy infelicities.  For example, a server can indicate that a
     given cookie is intended for "secure" connections, but the cookie's
     Secure attribute does not provide integrity in the presence of an
     active network attacker.  Similarly, cookies for a given host are
     shared across all the ports on that host, even though the usual
     "same-origin policy" used by web browsers isolates content retrieved
     via different ports.

     This document specifies the syntax and semantics of these header
     fields.  Where some existing software differs from the requirements
     in significant ways, the document contains a note explaining the
     difference.

     This document obsoletes [RFC6265] and 6265bis.

  1.1.  Examples

     Using the Set-Cookie header field, a server can send the user agent a
     short string in an HTTP response that the user agent will return in
     future HTTP requests that are within the scope of the cookie.  For
     example, the server can send the user agent a "session identifier"
     named SID with the value 31d4d96e407aad42.  The user agent then
     returns the session identifier in subsequent requests.



  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 4]


  Internet-Draft                   Cookies                   November 2025


     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

     The server can alter the default scope of the cookie using the Path
     and Domain attributes.  For example, the server can instruct the user
     agent to return the cookie to every path and every subdomain of
     site.example.

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=site.example

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

     As shown in the next example, the server can store multiple cookies
     at the user agent.  For example, the server can store a session
     identifier as well as the user's preferred language by returning two
     Set-Cookie header fields.  Notice that the server uses the Secure and
     HttpOnly attributes to provide additional security protections for
     the more sensitive session identifier (see Section 4.1.2).

     == Server -> User Agent ==

     Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
     Set-Cookie: lang=en-US; Path=/; Domain=site.example

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; lang=en-US

     Notice that the Cookie header field above contains two cookies, one
     named SID and one named lang.

     Cookie names are case-sensitive, meaning that if a server sends the
     user agent two Set-Cookie header fields that differ only in their
     name's case the user agent will store and return both of those
     cookies in subsequent requests.







  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 5]


  Internet-Draft                   Cookies                   November 2025


     == Server -> User Agent ==

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

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; sid=31d4d96e407aad42

     If the server wishes the user agent to persist the cookie over
     multiple "sessions" (e.g., user agent restarts), the server can
     specify an expiration date in the Expires attribute.  Note that the
     user agent might delete the cookie before the expiration date if the
     user agent's cookie store exceeds its quota or if the user manually
     deletes the server's cookie.

     == Server -> User Agent ==

     Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42; lang=en-US

     Finally, to remove a cookie, the server returns a Set-Cookie header
     field with an expiration date in the past.  The server will be
     successful in removing the cookie only if the Path and the Domain
     attribute in the Set-Cookie header field match the values used when
     the cookie was created.

     == Server -> User Agent ==

     Set-Cookie: lang=; Expires=Sun, 06 Nov 1994 08:49:37 GMT

     == User Agent -> Server ==

     Cookie: SID=31d4d96e407aad42

  2.  Conventions

  2.1.  Terminology

     This specification depends on Infra.  [INFRA]

     Some terms used in this specification are defined in the following
     standards and specifications:

     *  HTTP [RFC9110]



  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 6]


  Internet-Draft                   Cookies                   November 2025


     *  URL [URL]

     A *non-HTTP API* is a non-HTTP mechanisms used to set and retrieve
     cookies, such as a web browser API that exposes cookies to
     JavaScript.

  2.2.  ABNF

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

     The following core rules are included by reference, as defined in
     [RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
     (CR LF), CTLs (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
     HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), NUL (null octet),
     OCTET (any 8-bit sequence of data except NUL), SP (space), HTAB
     (horizontal tab), CHAR (any ASCII byte), VCHAR (any visible ASCII
     byte), and WSP (whitespace).

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

  3.  Which Requirements to Implement

     The upcoming two sections, Section 4 and Section 5, discuss the set
     of requirements for two distinct types of implementations.  This
     section is meant to help guide implementers in determining which set
     of requirements best fits their goals.  Choosing the wrong set of
     requirements could result in a lack of compatibility with other
     cookie implementations.

     It's important to note that being compatible means different things
     depending on the implementer's goals.  These differences have built
     up over time due to both intentional and unintentional specification
     changes, specification interpretations, and historical implementation
     differences.

     This section roughly divides implementers of this specification into
     two types, producers and consumers.  These are not official terms and
     are only used here to help readers develop an intuitive understanding
     of the use cases.










  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 7]


  Internet-Draft                   Cookies                   November 2025


  3.1.  Cookie Producing Implementations

     An implementer should choose Section 4 whenever cookies are created
     and will be sent to a user agent, such as a web browser.  These
     implementations are frequently referred to as servers by the
     specification but that term includes anything which primarily
     produces cookies.  Some potential examples:

     *  Server applications hosting a website or API

     *  Programming languages or software frameworks that support cookies

     *  Integrated third-party web applications, such as a business
        management suite

     All these benefit from not only supporting as many user agents as
     possible but also supporting other servers.  This is useful if a
     cookie is produced by a software framework and is later sent back to
     a server application which needs to read it.  Section 4 advises best
     practices that help maximize this sense of compatibility.

  3.2.  Cookie Consuming Implementations

     An implementer should choose Section 5 whenever cookies are primarily
     received from another source.  These implementations are referred to
     as user agents.  Some examples:

     *  Web browsers

     *  Tools that support stateful HTTP

     *  Programming languages or software frameworks that support cookies

     Because user agents don't know which servers a user will access, and
     whether or not that server is following best practices, users agents
     are advised to implement a more lenient set of requirements and to
     accept some things that servers are warned against producing.
     Section 5 advises best practices that help maximize this sense of
     compatibility.

  3.3.  Programming Languages & Software Frameworks

     A programming language or software framework with support for cookies
     could reasonably be used to create an application that acts as a
     cookie producer, cookie consumer, or both.  Because a developer may
     want to maximize their compatibility as either a producer or
     consumer, these languages or frameworks should strongly consider
     supporting both sets of requirements, Section 4 and Section 5, behind



  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 8]


  Internet-Draft                   Cookies                   November 2025


     a compatibility mode toggle.  This toggle should default to
     Section 4's requirements.

     Doing so will reduce the chances that a developer's application can
     inadvertently create cookies that cannot be read by other servers.

  4.  Server Requirements

     This section describes the conforming syntax and semantics of the
     HTTP Cookie and Set-Cookie header fields.

  4.1.  Set-Cookie

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

     Origin servers MAY send a Set-Cookie response header field with any
     response.  An origin server can include multiple Set-Cookie header
     fields in a single response.  The presence of a Cookie or a Set-
     Cookie header field does not preclude HTTP caches from storing and
     reusing a response.

     Origin servers and intermediaries MUST NOT combine multiple Set-
     Cookie header fields into a single header field.  The usual mechanism
     for combining HTTP headers fields (i.e., as defined in Section 5.3 of
     [RFC9110]) might change the semantics of the Set-Cookie header field
     because the %x2C (",") character is used by Set-Cookie in a way that
     conflicts with such combining.

     For example,

     Set-Cookie: a=b;path=/c,d=e

     is ambiguous.  It could be intended as two cookies, a=b and d=e, or a
     single cookie with a path of /c,d=e.

  4.1.1.  Syntax

     Informally, the Set-Cookie response header field contains a cookie,
     which begins with a name-value-pair, followed by zero or more
     attribute-value pairs.  Servers MUST send Set-Cookie header fields
     that conform to the following grammar:









  van Kesteren & Hofmann     Expires 22 May 2026                  [Page 9]


  Internet-Draft                   Cookies                   November 2025


     set-cookie        = set-cookie-string
     set-cookie-string = BWS cookie-pair *( BWS ";" OWS cookie-av )
     cookie-pair       = cookie-name BWS "=" BWS cookie-value
     cookie-name       = token
     cookie-value      = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
     cookie-octet      = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
                           ; US-ASCII characters excluding CTLs,
                           ; whitespace, DQUOTE, comma, semicolon,
                           ; and backslash
     token             = <token, defined in [HTTP], Section 5.6.2>

     cookie-av         = expires-av / max-age-av / domain-av /
                         path-av / secure-av / httponly-av /
                         samesite-av / extension-av
     expires-av        = "Expires" BWS "=" BWS sane-cookie-date
     sane-cookie-date  =
         <IMF-fixdate, defined in [HTTP], Section 5.6.7>
     max-age-av        = "Max-Age" BWS "=" BWS non-zero-digit *DIGIT
     non-zero-digit    = %x31-39
                           ; digits 1 through 9
     domain-av         = "Domain" BWS "=" BWS domain-value
     domain-value      = <subdomain>
                           ; see details below
     path-av           = "Path" BWS "=" BWS path-value
     path-value        = *av-octet
     secure-av         = "Secure"
     httponly-av       = "HttpOnly"
     samesite-av       = "SameSite" BWS "=" BWS samesite-value
     samesite-value    = "Strict" / "Lax" / "None"
     extension-av      = *av-octet
     av-octet          = %x20-3A / %x3C-7E
                           ; any CHAR except CTLs or ";"

     Note that some of the grammatical terms above reference documents
     that use different grammatical notations than this document (which
     uses ABNF from [RFC5234]).

     Per the grammar above, servers MUST NOT produce nameless cookies
     (i.e., an empty cookie-name) as such cookies may be unpredictably
     serialized by user agents when sent back to the server.

     The semantics of the cookie-value are not defined by this document.

     To maximize compatibility with user agents, servers that wish to
     store arbitrary data in a cookie-value SHOULD encode that data, for
     example, using Base64 [RFC4648].





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 10]


  Internet-Draft                   Cookies                   November 2025


     Per the grammar above, the cookie-value MAY be wrapped in DQUOTE
     characters.  Note that in this case, the initial and trailing DQUOTE
     characters are not stripped.  They are part of the cookie-value, and
     will be included in Cookie header fields sent to the server.

     The domain-value is a subdomain as defined by [RFC1034], Section 3.5,
     and as enhanced by [RFC1123], Section 2.1.  Thus, domain-value is a
     byte sequence of ASCII bytes.

     The portions of the set-cookie-string produced by the cookie-av term
     are known as attributes.  To maximize compatibility with user agents,
     servers SHOULD NOT produce two attributes with the same name in the
     same set-cookie-string.

     NOTE: The name of an attribute-value pair is not case-sensitive.  So
     while they are presented here in CamelCase, such as HttpOnly or
     SameSite, any case is accepted.  E.g., httponly, Httponly, hTTPoNLY,
     etc.

     Servers MUST NOT include more than one Set-Cookie header field in the
     same response with the same cookie-name.  (See Section 5.5.1 for how
     user agents handle this case.)

     If a server sends multiple responses containing Set-Cookie header
     fields concurrently to the user agent (e.g., when communicating with
     the user agent over multiple sockets), these responses create a "race
     condition" that can lead to unpredictable behavior.

     NOTE: Some existing user agents differ in their interpretation of
     two-digit years.  To avoid compatibility issues, servers SHOULD use
     the rfc1123-date format, which requires a four-digit year.

     NOTE: Some user agents store and process dates in cookies as 32-bit
     UNIX time_t values.  Implementation bugs in the libraries supporting
     time_t processing on some systems might cause such user agents to
     process dates after the year 2038 incorrectly.

  4.1.2.  Semantics (Non-Normative)

     This section describes simplified semantics of the Set-Cookie header
     field.  These semantics are detailed enough to be useful for
     understanding the most common uses of cookies by servers.  The full
     semantics are described in Section 5.

     When the user agent receives a Set-Cookie header field, the user
     agent stores the cookie together with its attributes.  Subsequently,
     when the user agent makes an HTTP request, the user agent includes
     the applicable, non-expired cookies in the Cookie header field.



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 11]


  Internet-Draft                   Cookies                   November 2025


     If the user agent receives a new cookie with the same cookie-name,
     domain-value, and path-value as a cookie that it has already stored,
     the existing cookie is evicted and replaced with the new cookie.
     Notice that servers can delete cookies by sending the user agent a
     new cookie with an Expires attribute with a value in the past.

     Unless the cookie's attributes indicate otherwise, the cookie is
     returned only to the origin server (and not, for example, to any
     subdomains), and it expires at the end of the current session (as
     defined by the user agent).  User agents ignore unrecognized cookie
     attributes (but not the entire cookie).

  4.1.2.1.  The Expires Attribute

     The Expires attribute indicates the maximum lifetime of the cookie,
     represented as the date and time at which the cookie expires.  The
     user agent is not required to retain the cookie until the specified
     date has passed.  In fact, user agents often evict cookies due to
     memory pressure or privacy concerns.

  4.1.2.2.  The Max-Age Attribute

     The Max-Age attribute indicates the maximum lifetime of the cookie,
     represented as the number of seconds until the cookie expires.  The
     user agent is not required to retain the cookie for the specified
     duration.  In fact, user agents often evict cookies due to memory
     pressure or privacy concerns.

     If a cookie has both the Max-Age and the Expires attribute, the Max-
     Age attribute has precedence and controls the expiration date of the
     cookie.  If a cookie has neither the Max-Age nor the Expires
     attribute, the user agent will retain the cookie until "the current
     session is over" (as defined by the user agent).

  4.1.2.3.  The Domain Attribute

     The Domain attribute specifies those hosts to which the cookie will
     be sent.

     If the server includes the Domain attribute, the value applies to
     both the specified domain and any subdomains.  For example, if the
     value of the Domain attribute is "site.example", the user agent will
     include the cookie in the Cookie header field when making HTTP
     requests to site.example, www.site.example, and
     www.corp.site.example.  Note that a leading %x2E ("."), if present,
     is ignored even though that character is not permitted.





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 12]


  Internet-Draft                   Cookies                   November 2025


     If the server omits the Domain attribute, the user agent will return
     the cookie only to the origin server and not to any subdomains.

     WARNING: Some existing user agents treat an absent Domain attribute
     as if the Domain attribute were present and contained the current
     host name.  For example, if site.example returns a Set-Cookie header
     field without a Domain attribute, these user agents will erroneously
     send the cookie to www.site.example and www.corp.site.example as
     well.

     The user agent will reject cookies unless the Domain attribute
     specifies a scope for the cookie that would include the origin
     server.  For example, the user agent will accept a cookie with a
     Domain attribute of "site.example" or of "foo.site.example" from
     foo.site.example, but the user agent will not accept a cookie with a
     Domain attribute of "bar.site.example" or of "baz.foo.site.example".

  4.1.2.4.  The Path Attribute

     The scope of each cookie is limited to a set of paths, controlled by
     the Path attribute.  If the server omits the Path attribute, the user
     agent will use the "directory" of the request-uri's path component as
     the default value.  (See Section 5.3.3 for more details.)

     The user agent will include the cookie in an HTTP request only if the
     path portion of the request-uri matches (or is a subdirectory of) the
     cookie's Path attribute, where the %x2F ("/") character is
     interpreted as a directory separator.

     Although seemingly useful for isolating cookies between different
     paths within a given host, the Path attribute cannot be relied upon
     for security (see Section 8).

  4.1.2.5.  The Secure Attribute

     The Secure attribute limits the scope of the cookie to "secure"
     channels (where "secure" is outside the scope of this document).
     E.g., when a cookie has the Secure attribute, the user agent will
     include the cookie in an HTTP request only if the request is
     transmitted over a secure channel (typically HTTP over Transport
     Layer Security (TLS) [TLS13] [RFC9110]).

  4.1.2.6.  The HttpOnly Attribute

     The HttpOnly attribute limits the scope of the cookie to HTTP
     requests.  In particular, the attribute instructs the user agent to
     omit the cookie when providing access to cookies via non-HTTP APIs.




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 13]


  Internet-Draft                   Cookies                   November 2025


  4.1.2.7.  The SameSite Attribute

     The SameSite attribute limits the scope of the cookie upon creation
     and delivery with respect to whether the cookie is considered to be
     "same-site" within a larger context (where "same-site" is outside the
     scope of this document).  The SameSite attribute is particularly
     relevant for web browsers and web applications accessible through
     them.

     The SameSite attribute supports Strict, Lax, and None as values.

  4.1.3.  Cookie Name Prefixes

     Section 8.5 and Section 8.6 of this document spell out some of the
     drawbacks of cookies' historical implementation.  In particular, it
     is impossible for a server to have confidence that a given cookie was
     set with a particular set of attributes.  In order to provide such
     confidence in a backwards-compatible way, two common sets of
     requirements can be inferred from the first few characters of the
     cookie's name.

     To maximize compatibility with user agents, servers SHOULD use
     prefixes as described below.

  4.1.3.1.  The "__Secure-" Prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Secure-, then the cookie will have been set with a Secure
     attribute.

     For example, the following Set-Cookie header field would be rejected
     by a conformant user agent, as it does not have a Secure attribute.

     Set-Cookie: __Secure-SID=12345; Domain=site.example

     Whereas the following Set-Cookie header field would be accepted if
     set from a secure origin (e.g. https://site.example/), and rejected
     otherwise:

     Set-Cookie: __Secure-SID=12345; Domain=site.example; Secure

  4.1.3.2.  The "__Host-" Prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Host-, then the cookie will have been set with a Secure attribute,
     a Path attribute with a value of /, and no Domain attribute.





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 14]


  Internet-Draft                   Cookies                   November 2025


     This combination yields a cookie that hews as closely as a cookie can
     to treating the origin as a security boundary.  The lack of a Domain
     attribute ensures that cookie's host-only is true, locking the cookie
     to a particular host, rather than allowing it to span subdomains.
     Setting the Path to / means that the cookie is effective for the
     entire host, and won't be overridden for specific paths.  The Secure
     attribute ensures that the cookie is unaltered by non-secure origins,
     and won't span protocols.

     Ports are the only piece of the same-origin policy that __Host-
     cookies continue to ignore.

     For example, the following cookies would always be rejected:

     Set-Cookie: __Host-SID=12345
     Set-Cookie: __Host-SID=12345; Secure
     Set-Cookie: __Host-SID=12345; Domain=site.example
     Set-Cookie: __Host-SID=12345; Domain=site.example; Path=/
     Set-Cookie: __Host-SID=12345; Secure; Domain=site.example; Path=/

     While the following would be accepted if set from a secure origin
     (e.g. https://site.example/), and rejected otherwise:

     Set-Cookie: __Host-SID=12345; Secure; Path=/

  4.1.3.3.  The "__Http-" Prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Http-, then the cookie will have been set with a Secure attribute,
     and an HttpOnly attribute.

     This helps developers and server operators to know that the cookie
     was set using a Set-Cookie header, and is limited in scope to HTTP
     requests.

  4.1.3.4.  The "__Host-Http-" prefix

     If a cookie's name begins with a case-sensitive match for the string
     __Host-Http-, then the cookie will have been set with a Secure
     attribute, an HttpOnly attribute, a Path attribute with a value of /,
     and no Domain attribute.

     This helps developers and server operators to know that the cookie
     was set using a Set-Cookie header, and is limited in scope to HTTP
     requests.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 15]


  Internet-Draft                   Cookies                   November 2025


     This combination yields a cookie that hews as closely as a cookie can
     to treating the origin as a security boundary, while at the same time
     ensuring developers and server operators know that its scope is
     limited to HTTP requests.  The lack of a Domain attribute ensures
     that cookie's host-only is true, locking the cookie to a particular
     host, rather than allowing it to span subdomains.  Setting the Path
     to / means that the cookie is effective for the entire host, and
     won't be overridden for specific paths.  The Secure attribute ensures
     that the cookie is unaltered by non-secure origins, and won't span
     protocols.  The HttpOnly attribute ensures that the cookie is not
     exposed by the user agent to non-HTTP APIs.

  4.2.  Cookie

  4.2.1.  Syntax

     The user agent sends stored cookies to the origin server in the
     Cookie header field.  If the server conforms to the requirements in
     Section 4.1 (and the user agent conforms to the requirements in
     Section 5), the user agent will send a Cookie header field that
     conforms to the following grammar:

     cookie        = cookie-string
     cookie-string = cookie-pair *( ";" SP cookie-pair )

     While Section 5.4 of [RFC9110] does not define a length limit for
     header fields it is likely that the web server's implementation does
     impose a limit; many popular implementations have default limits of 8
     kibibytes.  Servers SHOULD avoid setting a large number of large
     cookies such that the final cookie-string would exceed their header
     field limit.  Not doing so could result in requests to the server
     failing.

     Servers MUST be tolerant of multiple Cookie headers.  For example, an
     HTTP/2 [RFC9113] or HTTP/3 [HTTP] client or intermediary might split
     a Cookie header to improve compression.  Servers are free to
     determine what form this tolerance takes.  For example, the server
     could process each Cookie header individually or the server could
     concatenate all the Cookie headers into one and then process that
     final, single, header.  The server should be mindful of any header
     field limits when deciding which approach to take.

     Note: Since intermediaries can modify Cookie headers they should also
     be mindful of common server header field limits in order to avoid
     sending servers headers that they cannot process.  For example,
     concatenating multiple cookie headers into a single header might
     exceed a server's size limit.




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 16]


  Internet-Draft                   Cookies                   November 2025


  4.2.2.  Semantics

     Each cookie-pair represents a cookie stored by the user agent.  The
     cookie-pair contains the cookie-name and cookie-value the user agent
     received in the Set-Cookie header field.

     Notice that the cookie attributes are not returned.  In particular,
     the server cannot determine from the Cookie field alone when a cookie
     will expire, for which hosts the cookie is valid, for which paths the
     cookie is valid, or whether the cookie was set with the Secure or
     HttpOnly attributes.

     The semantics of individual cookies in the Cookie header field are
     not defined by this document.  Servers are expected to imbue these
     cookies with application-specific semantics.

     Although cookies are serialized linearly in the Cookie header field,
     servers SHOULD NOT rely upon the serialization order.  In particular,
     if the Cookie header field contains two cookies with the same name
     (e.g., that were set with different Path or Domain attributes),
     servers SHOULD NOT rely upon the order in which these cookies appear
     in the header field.

  5.  User Agent Requirements

     This section specifies the processing models associated with the
     Cookie and Set-Cookie header fields in sufficient detail that a user
     agent can interoperate with existing servers (even those that do not
     conform to the well-behaved profile described in Section 4).

     A user agent could enforce more restrictions than those specified
     herein (e.g., restrictions specified by its cookie policy, described
     in Section 7.2).  However, such additional restrictions may reduce
     the likelihood that a user agent will be able to interoperate with
     existing servers.

  5.1.  Cookie Concepts

     To facilitate the algorithms that follow, a number of pre-requisite
     concepts need to be introduced.

  5.1.1.  Cookie Store And Limits

     A user agent has an associated *cookie store*, which is a list of
     cookies.  It is initially « ».

     A user agent has an associated *total cookies-per-host limit*, which
     is an integer.  It SHOULD be 50 or more.



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 17]


  Internet-Draft                   Cookies                   November 2025


     A user agent has an associated *total cookies limit*, which is an
     integer.  It SHOULD be 3000 or more.

     A user agent has an associated *cookie age limit*, which is a number
     of days.  It SHOULD be 400 days or less (see Section 7.2).

  5.1.2.  Cookie Struct

     A *cookie* is a struct that represents a piece of state to be
     transmitted between a client and a server.

     A cookie's *name* is a byte sequence.  It always needs to be set.

     A cookie's *value* is a byte sequence.  It always needs to be set.

     A cookie's *secure* is a boolean.  It is initially false.

     A cookie's *host* is a domain, IP address, null, or failure.  It is
     initially null.  Note: Once a cookie is in the user agent's cookie
     store its host is a domain or IP address.

     A cookie's *host-only* is a boolean.  It is initially false.

     A cookie's *path* is a URL path.

     A cookie's *has-path attribute* is a boolean.  It is initially false.

     A cookie's *same-site* is "strict", "lax", "unset", or "none".  It is
     initially "unset".

     A cookie's *http-only* is a boolean.  It is initially false.

     A cookie's *creation-time* is a time.  It is initially the current
     time.

     A cookie's *expiry-time* is null or a time.  It is initially null.
     Note: A prior version of this specification referred to null with a
     distinct "persistent-flag" field being false.

     A cookie's *last-access-time* is a time.  It is initially the current
     time.

  5.1.2.1.  Cookie Struct Miscellaneous

     A cookie is *expired* if its expiry-time is non-null and its expiry-
     time is in the past.

     A cookie _cookie_ is *Host-prefix compatible* if:



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 18]


  Internet-Draft                   Cookies                   November 2025


     1.  _cookie_'s secure is true;

     2.  _cookie_'s host-only is true;

     3.  _cookie_'s has-path attribute is true; and

     4.  _cookie_'s path's size is 1 and _cookie_'s path[0] is the empty
         string,

     A cookie _cookie_ is *Http-prefix compatible* if:

     1.  _cookie_'s secure is true; and

     2.  _cookie_'s http-only is false,

  5.2.  Cookie Store Eviction

  5.2.1.  Remove Expired Cookies

     1.  Let _expiredCookies_ be a list of references to all expired
         cookies in the user agent's cookie store.

     2.  For each _cookie_ of _expiredCookies_:

         1.  Remove _cookie_ from the user agent's cookie store.

     3.  Return _expiredCookies_.

  5.2.2.  Remove Excess Cookies for a Host

     To *Remove Excess Cookies for a Host* given a host _host_:

     1.  Let _insecureCookies_ be a list of references to all cookies in
         the user agent's cookie store whose host is host-equal to _host_
         and whose secure is false.

     2.  Sort _insecureCookies_ by earliest last-access-time first.

     3.  Let _secureCookies_ be a list of references to all cookies in the
         user agent's cookie store whose host is host-equal to _host_ and
         whose secure is true.

     4.  Sort _secureCookies_ by earliest last-access-time first.

     5.  Let _excessHostCookies_ be an empty list of cookies.

     6.  While _insecureCookies_'s size + _secureCookies_'s size is
         greater than the user agent's total cookies-per-host limit:



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 19]


  Internet-Draft                   Cookies                   November 2025


         1.  If _insecureCookies_ is not empty:

             1.  Let _cookie_ be the first item of _insecureCookies_.

             2.  Remove _cookie_ from _insecureCookies_.

             3.  Remove _cookie_ from the user agent's cookie store.

             4.  Append _cookie_ to _excessHostCookies_.

         2.  Otherwise:

             1.  Let _cookie_ be the first item of _secureCookies_.

             2.  Remove _cookie_ from _secureCookies_.

             3.  Remove _cookie_ from the user agent's cookie store.

             4.  Append _cookie_ to _excessHostCookies_.

     7.  Return _excessHostCookies_.

  5.2.3.  Remove Global Excess Cookies

     To *Remove Global Excess Cookies*:

     1.  Let _allCookies_ be the result of sorting the user agent's cookie
         store by earliest last-access-time first.

     2.  Let _excessGlobalCookies_ be an empty list of cookies.

     3.  While _allCookies_'s size is greater than the user agent's total
         cookies limit:

         1.  Let _cookie_ be the first item of _allCookies_.

         2.  Remove _cookie_ from _allCookies_.

         3.  Remove _cookie_ from the user agent's cookie store.

         4.  Append _cookie_ to _excessGlobalCookies_.

     4.  Return _excessGlobalCookies_.

  5.3.  Subcomponent Algorithms

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



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 20]


  Internet-Draft                   Cookies                   November 2025


  5.3.1.  Parse a Date

     To *Parse a Date* given a byte sequence _input_, run these steps.
     They return a date and time or failure.

     Note that the various boolean flags defined as a part of the
     algorithm (i.e., found-time, found-day-of-month, found-month, found-
     year) are initially "not set".

     1.  Using the grammar below, divide the cookie-date into date-tokens.

        cookie-date     = *delimiter date-token-list *delimiter
        date-token-list = date-token *( 1*delimiter date-token )
        date-token      = 1*non-delimiter

        delimiter       = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
        non-delimiter   = %x00-08 / %x0A-1F / DIGIT / ":" / ALPHA
                          / %x7F-FF
        non-digit       = %x00-2F / %x3A-FF

        day-of-month    = 1*2DIGIT [ non-digit *OCTET ]
        month           = ( "jan" / "feb" / "mar" / "apr" /
                            "may" / "jun" / "jul" / "aug" /
                            "sep" / "oct" / "nov" / "dec" ) *OCTET
        year            = 2*4DIGIT [ non-digit *OCTET ]
        time            = hms-time [ non-digit *OCTET ]
        hms-time        = time-field ":" time-field ":" time-field
        time-field      = 1*2DIGIT

     2.  Process each date-token sequentially in the order the date-tokens
         appear in the cookie-date:

         1.  If the found-time flag is not set and the token matches the
             time production, set the found-time flag and set the hour-
             value, minute-value, and second-value to the numbers denoted
             by the digits in the date-token, respectively.  Skip the
             remaining sub-steps and continue to the next date-token.

         2.  If the found-day-of-month flag is not set and the date-token
             matches the day-of-month production, set the found-day-of-
             month flag and set the day-of-month-value to the number
             denoted by the date-token.  Skip the remaining sub-steps and
             continue to the next date-token.

         3.  If the found-month flag is not set and the date-token matches
             the month production, set the found-month flag and set the
             month-value to the month denoted by the date-token.  Skip the
             remaining sub-steps and continue to the next date-token.



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 21]


  Internet-Draft                   Cookies                   November 2025


         4.  If the found-year flag is not set and the date-token matches
             the year production, set the found-year flag and set the
             year-value to the number denoted by the date-token.  Skip the
             remaining sub-steps and continue to the next date-token.

     3.  If the year-value is greater than or equal to 70 and less than or
         equal to 99, increment the year-value by 1900.

     4.  If the year-value is greater than or equal to 0 and less than or
         equal to 69, increment the year-value by 2000.

         1.  NOTE: Some existing user agents interpret two-digit years
             differently.

     5.  If one of the following is true:

         *  at least one of the found-day-of-month, found-month, found-
            year, or found-time flags is not set,

         *  the day-of-month-value is less than 1 or greater than 31,

         *  the year-value is less than 1601,

         *  the hour-value is greater than 23,

         *  the minute-value is greater than 59, or

         *  the second-value is greater than 59,

         then return failure.

         (Note that leap seconds cannot be represented in this syntax.)

     6.  Let the parsed-cookie-date be the date whose day-of-month, month,
         year, hour, minute, and second (in UTC) are the day-of-month-
         value, the month-value, the year-value, the hour-value, the
         minute-value, and the second-value, respectively.  If no such
         date exists, abort these steps and fail to parse the cookie-date.

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

  5.3.2.  Domain Matching

     A host _host_ *Domain-Matches* a string _domainAttributeValue_ if at
     least one of the following is true:

     *  _host_ equals _domainAttributeValue_, or




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 22]


  Internet-Draft                   Cookies                   November 2025


     *  if all of the following are true:

        -  _host_ is a domain, and

        -  _host_ ends with the concatenation of U+002E (.) and
           _domainAttributeValue_.

  5.3.3.  Cookie Default Path

     To determine the *Cookie Default Path*, given a URL path _path_, run
     these steps.  They return a URL path.

     1.  Assert: _path_ is a non-empty list.

     2.  If _path_'s size is greater than 1, then remove _path_'s last
         item.

     3.  Otherwise, set _path_[0] to the empty string.

     4.  Return _path_.

  5.3.4.  Path Matching

     To determine if a URL path _requestPath_ *Path-Matches* a URL path
     _cookiePath_, run these steps.  They return a boolean.

     1.  Let _serializedRequestPath_ be the result of URL path serializing
         _requestPath_.

     2.  Let _serializedCookiePath_ be the result of URL path serializing
         _cookiePath_.

     3.  If _serializedCookiePath_ is _serializedRequestPath_, then return
         true.

     4.  If _serializedRequestPath_ starts with _serializedCookiePath_ and
         _serializedCookiePath_ ends with a U+002F (/), then return true.

     5.  Return whether the concatenation of _serializedRequestPath_
         followed by U+002F (/) starts with _serializedCookiePath_.

  5.4.  Main Algorithms









  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 23]


  Internet-Draft                   Cookies                   November 2025


  5.4.1.  Parse and Store a Cookie

     To *Parse and Store a Cookie* given a byte sequence _input_, boolean
     _isSecure_, domain or IP address _host_, URL path _path_, boolean
     _httpOnlyAllowed_, boolean _allowNonHostOnlyCookieForPublicSuffix_,
     and boolean _sameSiteStrictOrLaxAllowed_:

     1.  Let _cookie_ be the result of running Parse a Cookie with
         _input_, _isSecure_, _host_, and _path_.

     2.  If _cookie_ is failure, then return.

     3.  Return the result of Store a Cookie given _cookie_, _isSecure_,
         _host_, _path_, _httpOnlyAllowed_,
         _allowNonHostOnlyCookieForPublicSuffix_, and
         _sameSiteStrictOrLaxAllowed_.

  5.4.2.  Parse a Cookie

     To *Parse a Cookie* given a byte sequence _input_, boolean
     _isSecure_, host _host_, URL path _path_, run these steps.  They
     return a new cookie or failure:

     1.   If _input_ contains a byte in the range 0x00 to 0x08, inclusive,
          the range 0x0A to 0x1F inclusive, or 0x7F (CTL bytes excluding
          HTAB), then return failure.

     2.   Let _nameValueInput_ be null.

     3.   Let _attributesInput_ be the empty byte sequence.

     4.   If _input_ contains 0x3B (;), then set _nameValueInput_ to the
          bytes up to, but not including, the first 0x3B (;), and
          _attributesInput_ to the remainder of _input_ (including the
          0x3B (;) in question).

     5.   Otherwise, set _nameValueInput_ to _input_.

     6.   Assert: _nameValueInput_ is a byte sequence.

     7.   Let _name_ be null.

     8.   Let _value_ be null.

     9.   If _nameValueInput_ does not contain a 0x3D (=) character, then
          set _name_ to the empty byte sequence, and _value_ to
          _nameValueInput_.




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 24]


  Internet-Draft                   Cookies                   November 2025


     10.  Otherwise, set _name_ to the bytes up to, but not including, the
          first 0x3D (=), and set _value_ to the bytes after the first
          0x3D (=) (possibly being the empty byte sequence).

     11.  Remove any leading or trailing WSP bytes from _name_ and
          _value_.

     12.  If _name_'s length + _value_'s length is 0 or is greater than
          4096, then return failure.

     13.  Let _cookie_ be a new cookie whose name is _name_ and value is
          _value_.

     14.  Set _cookie_'s path to the result of running Cookie Default Path
          with _path_.

          Note: A Path attribute can override this.

     15.  While _attributesInput_ is not an empty byte sequence:

          1.   Let _maxAgeSeen_ be false.

          2.   Let _char_ be the result of consuming the first byte of
               _attributesInput_.

          3.   Assert: _char_ is 0x3B (;).

          4.   Let _attributeNameValueInput_ be null.

          5.   If _attributesInput_ contains 0x3B (;), then set
               _attributeNameValueInput_ to the result of consuming the
               bytes of _attributesInput_ up to, but not including, the
               first 0x3B (;).

          6.   Otherwise, set _attributeNameValueInput_ to the result of
               consuming the remainder of _attributesInput_.

          7.   Let _attributeName_ be null.

          8.   Let _attributeValue_ be the empty string.

          9.   If _attributeNameValueInput_ contains a 0x3D (=), then set
               _attributeName_ to the bytes up to, but not including, the
               first 0x3D (=) of _attributeNameValueInput_, and
               _attributeValue_ to the bytes after the first 0x3D (=) of
               _attributeNameValueInput_.





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 25]


  Internet-Draft                   Cookies                   November 2025


          10.  Otherwise, set _attributeName_ to
               _attributeNameValueInput_.

          11.  Remove any leading or trailing WSP bytes from
               _attributeName_ and _attributeValue_.

          12.  If _attributeValue_'s length is greater than 1024, then
               continue.

          13.  If _attributeName_ is a byte-case-insensitive match for
               Expires:

               1.  If _maxAgeSeen_ is true, then continue.

               2.  Let _expiryTime_ be the result of running Parse a Date
                   given _attributeValue_.

               3.  If _attributeValue_ is failure, then continue.

               4.  If _expiryTime_ is greater than the current time and
                   date + the user agent's cookie age limit, then set
                   _expiryTime_ to the user agent's cookie age limit.

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

               6.  Set _cookie_'s expiry-time to _expiryTime_.

          14.  If _attributeName_ is a byte-case-insensitive match for
               Max-Age:

               1.  If _attributeValue_ is empty, continue.

               2.  If the first byte of _attributeValue_ is neither a
                   DIGIT, nor 0x2D (-) followed by a DIGIT, then continue.

               3.  If the remainder of _attributeValue_ contains a non-
                   DIGIT, then continue.

               4.  Let _deltaSeconds_ be _attributeValue_, converted to a
                   base 10 integer.

               5.  Set _deltaSeconds_ to the smaller of _deltaSeconds_ and
                   the user agent's cookie age limit, in seconds.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 26]


  Internet-Draft                   Cookies                   November 2025


               6.  If _deltaSeconds_ is less than or equal to 0, let
                   _expiryTime_ be the earliest representable date and
                   time.  Otherwise, let _expiryTime_ be the current date
                   and time + _deltaSeconds_ seconds.

               7.  Set _cookie_'s expiry-time to _expiryTime_.

               8.  Set _maxAgeSeen_ to true.

          15.  If _attributeName_ is a byte-case-insensitive match for
               Domain:

               1.  Let _host_ be failure.

               2.  If _attributeValue_ contains only ASCII bytes:

                   1.  Let _hostInput_ be _attributeValue_, ASCII decoded.

                   2.  If _hostInput_ starts with U+002E (.), then set
                       _hostInput_ to _hostInput_ without its leading
                       U+002E (.).

                   3.  Set _host_ to the result of host parsing
                       _hostInput_.

               3.  Set _cookie_'s host to _host_.

          16.  If _attributeName_ is a byte-case-insensitive match for
               Path:

               1.  If _attributeValue_ is not empty and if the first byte
                   of _attributeValue_ is 0x2F (/), then:

                   1.  Set _cookie_'s path to _attributeValue_ split on
                       0x2F (/).

                   2.  Set _cookie_'s has-path attribute to true.

          17.  If _attributeName_ is a byte-case-insensitive match for
               Secure:

               1.  Set _cookie_'s secure to true.

          18.  If _attributeName_ is a byte-case-insensitive match for
               HttpOnly:

               1.  Set _cookie_'s http-only to true.




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 27]


  Internet-Draft                   Cookies                   November 2025


          19.  If _attributeName_ is a byte-case-insensitive match for
               SameSite:

               1.  If _attributeValue_ is a byte-case-insensitive match
                   for None, then set _cookie_'s same-site to "none".

               2.  If _attributeValue_ is a byte-case-insensitive match
                   for Strict, then set _cookie_'s same-site to "strict".

               3.  If _attributeValue_ is a byte-case-insensitive match
                   for Lax, then set _cookie_'s same-site to "lax".

     16.  Return _cookie_.

     Note: Attributes with an unrecognized _attributeName_ are ignored.

     Note: This intentionally overrides earlier cookie attributes so that
     generally the last specified cookie attribute "wins".

  5.4.3.  Store a Cookie

     To *Store a Cookie* given a cookie _cookie_, boolean _isSecure_,
     domain or IP address _host_, boolean _httpOnlyAllowed_, boolean
     _allowNonHostOnlyCookieForPublicSuffix_, and boolean
     _sameSiteStrictOrLaxAllowed_:

     1.   Assert: _cookie_'s name's length + _cookie_'s value's length is
          not 0 or greater than 4096.

     2.   Assert: _cookie_'s name does not contain a byte in the range
          0x00 to 0x08, inclusive, in the range 0x0A to 0x1F, inclusive,
          or 0x7F (CTL characters excluding HTAB).

     3.   If _cookie_'s host is failure, then return null.

     4.   Set _cookie_'s creation-time and last-access-time to the current
          date and time.

     5.   If _allowNonHostOnlyCookieForPublicSuffix_ is false and
          _cookie_'s host is a public suffix:

          1.  If _cookie_'s host is host-equal to _host_, then set
              _cookie_'s host to null.

          2.  Otherwise, return null.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 28]


  Internet-Draft                   Cookies                   November 2025


          Note: This step prevents attacker.example from disrupting the
          integrity of site.example by setting a cookie with a Domain
          attribute of example.  In the event the end user navigates
          directly to example, a cookie can still be set and will forcibly
          have its host-only set to true.

     6.   If _cookie_'s host is null:

          1.  Set _cookie_'s host-only to true.

          2.  Set _cookie_'s host to _host_.

     7.   Otherwise:

          1.  If _host_ does not Domain-Match _cookie_'s host, then return
              null.

          2.  Set _cookie_'s host-only to false.

     8.   Assert: _cookie_'s host is a domain or IP address.

     9.   If _httpOnlyAllowed_ is false and _cookie_'s http-only is true,
          then return null.

     10.  If _isSecure_ is false:

          1.  If _cookie_'s secure is true, then return null.

          2.  If the user agent's cookie store contains at least one
              cookie _existingCookie_ that meets all of the following
              criteria:

              1.  _existingCookie_'s name is _cookie_'s name;

              2.  _existingCookie_'s secure is true;

              3.  _existingCookie_'s host Domain-Matches _cookie_'s host,
                  or vice-versa; and

              4.  _cookie_'s path Path-Matches _existingCookie_'s path,

              then return null.









  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 29]


  Internet-Draft                   Cookies                   November 2025


              Note: The path comparison is not symmetric, ensuring only
              that a newly-created, non-secure cookie does not overlay an
              existing secure cookie, providing some mitigation against
              cookie-fixing attacks.  That is, given an existing secure
              cookie named 'a' with a path of '/login', a non-secure
              cookie named 'a' could be set for a path of '/' or '/foo',
              but not for a path of '/login' or '/login/en'.

     11.  If _cookie_'s same-site is not "none" and
          _sameSiteStrictOrLaxAllowed_ is false, then return null.

     12.  If _cookie_'s same-site is "none" and _cookie_'s secure is
          false, then return null.

     13.  If _cookie_'s name, byte-lowercased, starts with __secure- and
          _cookie_'s secure is false, then return null.

          Note: The check here and those below are with a byte-lowercased
          value in order to protect servers that process these values in a
          case-insensitive manner.

     14.  If _cookie_'s name, byte-lowercased, starts with __host- and
          _cookie_ is not Host-prefix compatible, then return null.

     15.  If _cookie_'s name, byte-lowercased, starts with __http- and
          _cookie_ is not Http-prefix compatible, then return null.

     16.  If _cookie_'s name, byte-lowercased, starts with __host-http-
          and _cookie_ is not both Host-prefix compatible and Http-prefix
          compatible, then return null.

     17.  If _cookie_'s name is the empty byte sequence and one of the
          following is true:

          *  _cookie_'s value, byte-lowercased, starts with __secure-,

          *  _cookie_'s value, byte-lowercased, starts with __host-,

          *  _cookie_'s value, byte-lowercased, starts with __http-, or

          *  _cookie_'s value, byte-lowercased, starts with __host-http-,

          then return null.

     18.  If the user agent's cookie store contains a cookie _oldCookie_
          whose name is _cookie_'s name, host is host-equal to _cookie_'s
          host, host-only is _cookie_'s host-only, and path is path-equal
          to _cookie_'s path:



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 30]


  Internet-Draft                   Cookies                   November 2025


          1.  If _httpOnlyAllowed_ is false and _oldCookie_'s http-only is
              true, then return null.

          2.  If _cookie_'s secure is equal to _oldCookie_'s secure,
              _cookie_'s same-site is equal to _oldCookie_'s same-site,
              and _cookie_'s expiry-time is equal to _oldCookie_'s expiry-
              time, then return null.

          3.  Set _cookie_'s creation-time to _oldCookie_'s creation-time.

          4.  Remove _oldCookie_ from the user agent's cookie store.

          Note: This algorithm maintains the invariant that there is at
          most one such cookie.

     19.  Insert _cookie_ into the user agent's cookie store.

     20.  Return _cookie_.

  5.4.4.  Garbage Collect Cookies

     To *Garbage Collect Cookies* given a host _host_:

     1.  Let _expiredCookies_ be the result of running Remove Expired
         Cookies.

     2.  Let _excessHostCookies_ be the result of running Remove Excess
         Cookies for Host given _host_.

     3.  Let _excessGlobalCookies_ be the result of running Remove Global
         Excess Cookies.

     4.  Let _removedCookies_ be « ».

     5.  For each _cookieList_ of « _expiredCookies_, _excessHostCookies_,
         _excessGlobalCookies_ », do the following:

         1.  Extend _removedCookies_ with _cookieList_.

     6.  Return _removedCookies_

  5.4.5.  Retrieve Cookies

     To *Retrieve Cookies* given a boolean _isSecure_, host _host_, URL
     path _path_, boolean _httpOnlyAllowed_, and string _sameSite_:

     1.  Assert: _sameSite_ is "strict-or-less", "lax-or-less", "unset-or-
         less", or "none".



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 31]


  Internet-Draft                   Cookies                   November 2025


     2.  Let _cookies_ be all cookies from the user agent's cookie store
         that meet these conditions:

         *  One of the following is true:

            -  cookie's host-only is true and _host_ is host-equal to
               cookie's host, or

            -  cookie's host-only is false and _host_ Domain-Matches
               cookie's host.

            It's possible that the public suffix list changed since a
            cookie was created.  If this change results in a cookie's host
            becoming a public suffix and the cookie's host-only is false,
            then that cookie SHOULD NOT be returned.

            XXX: We should probably move this requirement out-of-bound as
            this invalidation should happen as part of updating the public
            suffixes.

         *  _path_ Path-Matches cookie's path.

         *  One of the following is true:

            -  cookie's secure is true and _isSecure_ is true, or

            -  cookie's secure is false.

         *  One of the following is true:

            -  cookie's http-only is true and _httpOnlyAllowed_ is true,
               or

            -  cookie's http-only is false.

         *  One of the following is true:

            -  cookie's same-site is "strict" and _sameSite_ is "strict-
               or-less";

            -  cookie's same-site is "lax" and _sameSite_ is one of
               "strict-or-less" or "lax-or-less";

            -  cookie's same-site is "unset" and _sameSite_ is one of
               "strict-or-less", "lax-or-less", or "unset-or-less"; or

            -  cookie's same-site is "none".




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 32]


  Internet-Draft                   Cookies                   November 2025


     3.  Sort _cookies_ in the following order:

         *  Cookies whose path's size is greater are listed before cookies
            whose path's size is smaller.

         *  Among cookies whose path's size is equal, cookies whose
            creation-time is earlier are listed before cookies whose
            creation-time is later.

     4.  Set the last-access-time of each cookie of _cookies_ to the
         current date and time and reflect these changes in the user
         agent's cookie store.

     5.  Return _cookies_.

  5.4.6.  Serialize Cookies

     To *Serialize Cookies* given a list of cookies _cookies_:

     1.  Let _output_ be an empty byte sequence.

     2.  For each _cookie_ of _cookies_:

         1.  If _output_ is not the empty byte sequence, then append 0x3B
             (;) followed by 0x20 (SP) to _output_.

         2.  If _cookie_'s name is not the empty byte sequence, then
             append _cookie_'s name followed by 0x3D (=) to _output_.

         3.  Append _cookie_'s value to _output_.

     3.  Return _output_.

  5.5.  Requirements Specific to Non-Browser User Agents

  5.5.1.  The Set-Cookie Header Field

     When a user agent receives a Set-Cookie header field in an HTTP
     response, the user agent MAY ignore the Set-Cookie header field in
     its entirety as per its cookie policy (see Section 7.2).

     User agents MAY ignore Set-Cookie header fields contained in
     responses with 100-level status codes.

     Set-Cookie header fields contained in responses with non-100-level
     status codes (including those in responses with 400- and 500-level
     status codes) SHOULD be processed as follows:




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 33]


  Internet-Draft                   Cookies                   November 2025


     1.  Let _isSecure_ be a boolean indicating whether request's URL's
         scheme is deemed secure, in an implementation-defined manner.

     2.  Let _host_ be request's host.

     3.  Let _path_ be request's URL's path.

     4.  Let _httpOnlyAllowed_ be true.

     5.  Let _allowNonHostOnlyCookieForPublicSuffix_ be a boolean whose
         value is implementation-defined.

     6.  Let _sameSiteStrictOrLaxAllowed_ be a boolean whose value is
         implementation-defined.

     7.  Let _cookie_ be the result of running Parse and Store a Cookie
         given the header field value, _isSecure_, _host_, _path_,
         _httpOnlyAllowed_, _allowNonHostOnlyCookieForPublicSuffix_, and
         _sameSiteStrictOrLaxAllowed_.

     8.  If _cookie_ is null, then return.

     9.  Run Garbage Collect Cookies given _cookie_'s host.

  5.5.2.  The Cookie Header Field

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

     When the user agent generates an HTTP request, the user agent MUST
     NOT attach more than one Cookie header field.

     A user agent MAY omit the Cookie header field in its entirety.

     If the user agent does attach a Cookie header field to an HTTP
     request, the user agent MUST compute its value as follows:

     1.  Let _isSecure_ be a boolean indicating whether request's URL's
         scheme is deemed secure, in an implementation-defined manner.

     2.  Let _host_ be request's host.

     3.  Let _path_ be request's URL's path.

     4.  Let _httpOnlyAllowed_ be true.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 34]


  Internet-Draft                   Cookies                   November 2025


     5.  Let _sameSite_ be a string whose value is implementation-defined,
         but has to be one of "strict-or-less", "lax-or-less", "unset-or-
         less", or "none".

     6.  Let _cookies_ be the result of running Retrieve Cookies given
         _isSecure_, _host_, _path_, _httpOnlyAllowed_, and _sameSite_.

     7.  Return the result of running Serialize Cookies given _cookies_.

     Note: Previous versions of this specification required that only one
     Cookie header field be sent in requests.  This is no longer a
     requirement.  While this specification requires that a single cookie-
     string be produced, some user agents may split that string across
     multiple Cookie header fields.  For examples, see Section 8.2.3 of
     [RFC9113] and Section 4.2.1 of [HTTP].

  5.5.3.  Cookie Store Eviction for Non-Browser User Agents

     The user agent SHOULD evict all expired cookies from its cookie store
     if, at any time, an expired cookie exists in the cookie store, by
     calling Remove Expired Cookies.

     When "the current session is over" (as defined by the user agent),
     the user agent MUST remove from the cookie store all cookies whose
     expiry-time is null.

  5.6.  Requirements Specific to Browser User Agents

     While browsers are expected to generally follow the same model as
     non-browser user agents, they have additional complexity due to the
     document model (and the ability to nest documents) that is considered
     out-of-scope for this specification.

     Specifications for such a user agent are expected to build upon the
     following algorithms and invoke them appropriately to process Cookie
     and Set-Cookie header fields, as well as manipulating the user
     agent's cookie store through non-HTTP APIs:

     *  Parse and Store a Cookie

     *  Store a Cookie

     *  Remove Expired Cookies

     *  Garbage Collect Cookies

     *  Retrieve Cookies




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 35]


  Internet-Draft                   Cookies                   November 2025


     *  Serialize Cookies

     This provides the flexibility browsers need to detail their
     requirements in considerable detail.

  6.  Implementation Considerations

  6.1.  Limits

     Servers SHOULD use as few and as small cookies as possible to avoid
     reaching these implementation limits, minimize network bandwidth due
     to the Cookie header field being included in every request, and to
     avoid reaching server header field limits (See Section 4.2.1).

     Servers SHOULD gracefully degrade if the user agent fails to return
     one or more cookies in the Cookie header field because the user agent
     might evict any cookie at any time.

  6.2.  Application Programming Interfaces

     One reason the Cookie and Set-Cookie header fields use such esoteric
     syntax is that many platforms (both in servers and user agents)
     provide a string-based application programming interface (API) to
     cookies, requiring application-layer programmers to generate and
     parse the syntax used by the Cookie and Set-Cookie header fields,
     which many programmers have done incorrectly, resulting in
     interoperability problems.

     Instead of providing string-based APIs to cookies, platforms would be
     well-served by providing more semantic APIs.  It is beyond the scope
     of this document to recommend specific API designs, but there are
     clear benefits to accepting an abstract "Date" object instead of a
     serialized date string.

  7.  Privacy Considerations

     Cookies' primary privacy risk is their ability to correlate user
     activity.  This can happen on a single site, but is most problematic
     when activity is tracked across different, seemingly unconnected Web
     sites to build a user profile.

     Over time, this capability (warned against explicitly in [RFC2109]
     and all of its successors) has become widely used for varied reasons
     including:

     *  authenticating users across sites,

     *  assembling information on users,



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 36]


  Internet-Draft                   Cookies                   November 2025


     *  protecting against fraud and other forms of undesirable traffic,

     *  targeting advertisements at specific users or at users with
        specified attributes,

     *  measuring how often ads are shown to users, and

     *  recognizing when an ad resulted in a change in user behavior.

     While not every use of cookies is necessarily problematic for
     privacy, their potential for abuse has become a widespread concern in
     the Internet community and broader society.  In response to these
     concerns, user agents have actively constrained cookie functionality
     in various ways (as allowed and encouraged by previous
     specifications), while avoiding disruption to features they judge
     desirable for the health of the Web.

     It is too early to declare consensus on which specific mechanism(s)
     should be used to mitigate cookies' privacy impact; user agents'
     ongoing changes to how they are handled are best characterised as
     experiments that can provide input into that eventual consensus.

     Instead, this document describes limited, general mitigations against
     the privacy risks associated with cookies that enjoy wide deployment
     at the time of writing.  It is expected that implementations will
     continue to experiment and impose stricter, more well-defined
     limitations on cookies over time.  Future versions of this document
     might codify those mechanisms based upon deployment experience.  If
     functions that currently rely on cookies can be supported by
     separate, targeted mechanisms, they might be documented in separate
     specifications and stricter limitations on cookies might become
     feasible.

     Note that cookies are not the only mechanism that can be used to
     track users across sites, so while these mitigations are necessary to
     improve Web privacy, they are not sufficient on their own.

  7.1.  Third-Party Cookies

     A "third-party" or cross-site cookie is one that is associated with
     embedded content (such as scripts, images, stylesheets, frames) that
     is obtained from a different server than the one that hosts the
     primary resource (usually, the Web page that the user is viewing).
     Third-party cookies are often used to correlate users' activity on
     different sites.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 37]


  Internet-Draft                   Cookies                   November 2025


     Because of their inherent privacy issues, most user agents now limit
     third-party cookies in a variety of ways.  Some completely block
     third-party cookies by refusing to process third-party Set-Cookie
     header fields and refusing to send third-party Cookie header fields.
     Some partition cookies based upon the first-party context, so that
     different cookies are sent depending on the site being browsed.  Some
     block cookies based upon user agent cookie policy and/or user
     controls.

     While this document does not endorse or require a specific approach,
     it is RECOMMENDED that user agents adopt a policy for third-party
     cookies that is as restrictive as compatibility constraints permit.
     Consequently, resources cannot rely upon third-party cookies being
     treated consistently by user agents for the foreseeable future.

  7.2.  Cookie Policy

     User agents MAY enforce a cookie policy consisting of restrictions on
     how cookies may be used or ignored (see Section 5.5.1).

     A cookie policy may govern which domains or parties, as in first and
     third parties (see Section 7.1), for which the user agent will allow
     cookie access.  The policy can also define limits on cookie size,
     cookie expiry (see Section 4.1.2.1 and Section 4.1.2.2), and the
     number of cookies per domain or in total.

     The goal of a restrictive cookie policy is often to improve security
     or privacy.  User agents often allow users to change the cookie
     policy (see Section 7.3).

  7.3.  User Controls

     User agents SHOULD provide users with a mechanism for managing the
     cookies stored in the cookie store.  For example, a user agent might
     let users delete all cookies received during a specified time period
     or all the cookies related to a particular domain.  In addition, many
     user agents include a user interface element that lets users examine
     the cookies stored in their cookie store.

     User agents SHOULD provide users with a mechanism for disabling
     cookies.  When cookies are disabled, the user agent MUST NOT include
     a Cookie header field in outbound HTTP requests and the user agent
     MUST NOT process Set-Cookie header fields in inbound HTTP responses.

     User agents MAY offer a way to change the cookie policy (see
     Section 7.2).





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 38]


  Internet-Draft                   Cookies                   November 2025


     User agents MAY provide users the option of preventing persistent
     storage of cookies across sessions.  When configured thusly, user
     agents MUST treat all received cookies as if their expiry-time is
     null.

  7.4.  Expiration Dates

     Although servers can set the expiration date for cookies to the
     distant future, most user agents do not actually retain cookies for
     multiple decades.  Rather than choosing gratuitously long expiration
     periods, servers SHOULD promote user privacy by selecting reasonable
     cookie expiration periods based on the purpose of the cookie.  For
     example, a typical session identifier might reasonably be set to
     expire in two weeks.

  8.  Security Considerations

  8.1.  Overview

     Cookies have a number of security pitfalls.  This section overviews a
     few of the more salient issues.

     In particular, cookies encourage developers to rely on ambient
     authority for authentication, often becoming vulnerable to attacks
     such as cross-site request forgery [CSRF].  Also, when storing
     session identifiers in cookies, developers often create session
     fixation vulnerabilities.

     Transport-layer encryption, such as that employed in HTTPS, is
     insufficient to prevent a network attacker from obtaining or altering
     a victim's cookies because the cookie protocol itself has various
     vulnerabilities (see "Weak Confidentiality" and "Weak Integrity",
     below).  In addition, by default, cookies do not provide
     confidentiality or integrity from network attackers, even when used
     in conjunction with HTTPS.

  8.2.  Ambient Authority

     A server that uses cookies to authenticate users can suffer security
     vulnerabilities because some user agents let remote parties issue
     HTTP requests from the user agent (e.g., via HTTP redirects or HTML
     forms).  When issuing those requests, user agents attach cookies even
     if the remote party does not know the contents of the cookies,
     potentially letting the remote party exercise authority at an unwary
     server.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 39]


  Internet-Draft                   Cookies                   November 2025


     Although this security concern goes by a number of names (e.g.,
     cross-site request forgery, confused deputy), the issue stems from
     cookies being a form of ambient authority.  Cookies encourage server
     operators to separate designation (in the form of URLs) from
     authorization (in the form of cookies).  Consequently, the user agent
     might supply the authorization for a resource designated by the
     attacker, possibly causing the server or its clients to undertake
     actions designated by the attacker as though they were authorized by
     the user.

     Instead of using cookies for authorization, server operators might
     wish to consider entangling designation and authorization by treating
     URLs as capabilities.  Instead of storing secrets in cookies, this
     approach stores secrets in URLs, requiring the remote entity to
     supply the secret itself.  Although this approach is not a panacea,
     judicious application of these principles can lead to more robust
     security.

  8.3.  Clear Text

     Unless sent over a secure channel (such as TLS [TLS13]), the
     information in the Cookie and Set-Cookie header fields is transmitted
     in the clear.

     1.  All sensitive information conveyed in these header fields is
         exposed to an eavesdropper.

     2.  A malicious intermediary could alter the header fields as they
         travel in either direction, with unpredictable results.

     3.  A malicious client could alter the Cookie header fields before
         transmission, with unpredictable results.

     Servers SHOULD encrypt and sign the contents of cookies (using
     whatever format the server desires) when transmitting them to the
     user agent (even when sending the cookies over a secure channel).
     However, encrypting and signing cookie contents does not prevent an
     attacker from transplanting a cookie from one user agent to another
     or from replaying the cookie at a later time.

     In addition to encrypting and signing the contents of every cookie,
     servers that require a higher level of security SHOULD use the Cookie
     and Set-Cookie header fields only over a secure channel.  When using
     cookies over a secure channel, servers SHOULD set the Secure
     attribute (see Section 4.1.2.5) for every cookie.  If a server does
     not set the Secure attribute, the protection provided by the secure
     channel will be largely moot.




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 40]


  Internet-Draft                   Cookies                   November 2025


     For example, consider a webmail server that stores a session
     identifier in a cookie and is typically accessed over HTTPS.  If the
     server does not set the Secure attribute on its cookies, an active
     network attacker can intercept any outbound HTTP request from the
     user agent and redirect that request to the webmail server over HTTP.
     Even if the webmail server is not listening for HTTP connections, the
     user agent will still include cookies in the request.  The active
     network attacker can intercept these cookies, replay them against the
     server, and learn the contents of the user's email.  If, instead, the
     server had set the Secure attribute on its cookies, the user agent
     would not have included the cookies in the clear-text request.

  8.4.  Session Identifiers

     Instead of storing session information directly in a cookie (where it
     might be exposed to or replayed by an attacker), servers commonly
     store a nonce (or "session identifier") in a cookie.  When the server
     receives an HTTP request with a nonce, the server can look up state
     information associated with the cookie using the nonce as a key.

     Using session identifier cookies limits the damage an attacker can
     cause if the attacker learns the contents of a cookie because the
     nonce is useful only for interacting with the server (unlike non-
     nonce cookie content, which might itself be sensitive).  Furthermore,
     using a single nonce prevents an attacker from "splicing" together
     cookie content from two interactions with the server, which could
     cause the server to behave unexpectedly.

     Using session identifiers is not without risk.  For example, the
     server SHOULD take care to avoid "session fixation" vulnerabilities.
     A session fixation attack proceeds in three steps.  First, the
     attacker transplants a session identifier from his or her user agent
     to the victim's user agent.  Second, the victim uses that session
     identifier to interact with the server, possibly imbuing the session
     identifier with the user's credentials or confidential information.
     Third, the attacker uses the session identifier to interact with
     server directly, possibly obtaining the user's authority or
     confidential information.

  8.5.  Weak Confidentiality

     Cookies do not provide isolation by port.  If a cookie is readable by
     a service running on one port, the cookie is also readable by a
     service running on another port of the same server.  If a cookie is
     writable by a service on one port, the cookie is also writable by a
     service running on another port of the same server.  For this reason,
     servers SHOULD NOT both run mutually distrusting services on
     different ports of the same host and use cookies to store security-



  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 41]


  Internet-Draft                   Cookies                   November 2025


     sensitive information.

     Cookies do not provide isolation by scheme.  Although most commonly
     used with the http and https schemes, the cookies for a given host
     might also be available to other schemes, such as ftp and gopher.
     Although this lack of isolation by scheme is most apparent in non-
     HTTP APIs that permit access to cookies (e.g., HTML's document.cookie
     API), the lack of isolation by scheme is actually present in
     requirements for processing cookies themselves (e.g., consider
     retrieving a URI with the gopher scheme via HTTP).

     Cookies do not always provide isolation by path.  Although the
     network-level protocol does not send cookies stored for one path to
     another, some user agents expose cookies via non-HTTP APIs, such as
     HTML's document.cookie API.  Because some of these user agents (e.g.,
     web browsers) do not isolate resources received from different paths,
     a resource retrieved from one path might be able to access cookies
     stored for another path.

  8.6.  Weak Integrity

     Cookies do not provide integrity guarantees for sibling domains (and
     their subdomains).  For example, consider foo.site.example and
     bar.site.example.  The foo.site.example server can set a cookie with
     a Domain attribute of "site.example" (possibly overwriting an
     existing "site.example" cookie set by bar.site.example), and the user
     agent will include that cookie in HTTP requests to bar.site.example.
     In the worst case, bar.site.example will be unable to distinguish
     this cookie from a cookie it set itself.  The foo.site.example server
     might be able to leverage this ability to mount an attack against
     bar.site.example.

     Even though the Set-Cookie header field supports the Path attribute,
     the Path attribute does not provide any integrity protection because
     the user agent will accept an arbitrary Path attribute in a Set-
     Cookie header field.  For example, an HTTP response to a request for
     http://site.example/foo/bar can set a cookie with a Path attribute of
     "/qux".  Consequently, servers SHOULD NOT both run mutually
     distrusting services on different paths of the same host and use
     cookies to store security-sensitive information.











  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 42]


  Internet-Draft                   Cookies                   November 2025


     An active network attacker can also inject cookies into the Cookie
     header field sent to https://site.example/ by impersonating a
     response from http://site.example/ and injecting a Set-Cookie header
     field.  The HTTPS server at site.example will be unable to
     distinguish these cookies from cookies that it set itself in an HTTPS
     response.  An active network attacker might be able to leverage this
     ability to mount an attack against site.example even if site.example
     uses HTTPS exclusively.

     Servers can partially mitigate these attacks by encrypting and
     signing the contents of their cookies, or by naming the cookie with
     the __Secure- prefix.  However, using cryptography does not mitigate
     the issue completely because an attacker can replay a cookie he or
     she received from the authentic site.example server in the user's
     session, with unpredictable results.

     Finally, an attacker might be able to force the user agent to delete
     cookies by storing a large number of cookies.  Once the user agent
     reaches its storage limit, the user agent will be forced to evict
     some cookies.  Servers SHOULD NOT rely upon user agents retaining
     cookies.

  8.7.  Reliance on DNS

     Cookies rely upon the Domain Name System (DNS) for security.  If the
     DNS is partially or fully compromised, the cookie protocol might fail
     to provide the security properties required by applications.

  8.8.  SameSite Cookies

     SameSite cookies offer a robust defense against CSRF attack when
     deployed in strict mode, and when supported by the client.  It is,
     however, prudent to ensure that this designation is not the extent of
     a site's defense against CSRF, as same-site navigations and
     submissions can certainly be executed in conjunction with other
     attack vectors such as cross-site scripting.

     Developers are strongly encouraged to deploy the usual server-side
     defenses (CSRF tokens, ensuring that "safe" HTTP methods are
     idempotent, etc) to mitigate the risk more fully.

  9.  IANA Considerations

  9.1.  Cookie

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




  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 43]


  Internet-Draft                   Cookies                   November 2025


     Header field name:  Cookie

     Applicable protocol:  http

     Status:  standard

     Author/Change controller:  IETF

     Specification document:  this specification (Section 5.5.2)

  9.2.  Set-Cookie

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

     Header field name:  Set-Cookie

     Applicable protocol:  http

     Status:  standard

     Author/Change controller:  IETF

     Specification document:  this specification (Section 5.5.1)

  10.  Changes

     Revamped the document to allow for more detailed requirements on
     browsers in downstream specifications.

  Acknowledgements

     Many thanks to Adam Barth for laying the groundwork for a modern
     cookie specification with RFC 6265.

     And many thanks to Steven Bingler, Lily Chen, Dylan Cutler, Steven
     Englehardt, Yoav Weiss, Mike West, and John Wilander for improving
     upon that work.

  References

  Normative References

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





  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 44]


  Internet-Draft                   Cookies                   November 2025


     [INFRA]    van Kesteren, A. and D. Denicola, "Infra", n.d.,
                <https://infra.spec.whatwg.org>.

     [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
                STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
                <https://www.rfc-editor.org/rfc/rfc1034>.

     [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
                Application and Support", STD 3, RFC 1123,
                DOI 10.17487/RFC1123, October 1989,
                <https://www.rfc-editor.org/rfc/rfc1123>.

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

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

     [URL]      van Kesteren, A., "URL", n.d.,
                <https://url.spec.whatwg.org>.

  Informative References

     [CSRF]     Barth, A., Jackson, C., and J. Mitchell, "Robust Defenses
                for Cross-Site Request Forgery",
                DOI 10.1145/1455770.1455782, ISBN 978-1-59593-810-7,
                ACM CCS '08: Proceedings of the 15th ACM conference on
                Computer and communications security (pages 75-88),
                October 2008,
                <http://portal.acm.org/citation.cfm?id=1455770.1455782>.

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

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

     [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
                Mechanism", RFC 2109, DOI 10.17487/RFC2109, February 1997,
                <https://www.rfc-editor.org/rfc/rfc2109>.






  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 45]


  Internet-Draft                   Cookies                   November 2025


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

     [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
                DOI 10.17487/RFC6265, April 2011,
                <https://www.rfc-editor.org/rfc/rfc6265>.

     [RFC7034]  Ross, D. and T. Gondrom, "HTTP Header Field X-Frame-
                Options", RFC 7034, DOI 10.17487/RFC7034, October 2013,
                <https://www.rfc-editor.org/rfc/rfc7034>.

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

     [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
                DOI 10.17487/RFC9113, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9113>.

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

  Authors' Addresses

     Anne van Kesteren (editor)
     Apple
     Email: annevk@annevk.nl


     Johann Hofmann (editor)
     Google
     Email: johannhof@google.com
















  van Kesteren & Hofmann     Expires 22 May 2026                 [Page 46]


name: draft-ainp-protocol
rev: 00
title: AI-Native Network Protocol (AINP) for Semantic Agent Communication
time: 2025-11-24T20:30:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-28T20:30:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.406131+00:00
source: ietf
abstract:
  This document specifies the AI-Native Network Protocol (AINP) version
     0.1, a semantic communication protocol designed for intent exchange
     between AI agents.  AINP replaces location-based routing with
     semantic routing, byte-stream delivery with intent delivery, and
     simple handshakes with multi-round negotiation.  AINP enables agents
     to discover each other by capability rather than network location,
     negotiate terms autonomously, and exchange structured intents with
     cryptographic security.

full_text:
  Independent Submission                                 E. P. Nagulapalli
  Internet-Draft                                             Servesys Labs
  Intended status: Standards Track                        24 November 2025
  Expires: 28 May 2026


     AI-Native Network Protocol (AINP) for Semantic Agent Communication
                           draft-ainp-protocol-00

  Abstract

     This document specifies the AI-Native Network Protocol (AINP) version
     0.1, a semantic communication protocol designed for intent exchange
     between AI agents.  AINP replaces location-based routing with
     semantic routing, byte-stream delivery with intent delivery, and
     simple handshakes with multi-round negotiation.  AINP enables agents
     to discover each other by capability rather than network location,
     negotiate terms autonomously, and exchange structured intents with
     cryptographic security.

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

  Copyright Notice

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










  Nagulapalli                Expires 28 May 2026                  [Page 1]


  Internet-Draft                AINP Protocol                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  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
         1.1.1.  Definitions . . . . . . . . . . . . . . . . . . . . .   4
     2.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   4
     3.  Wire Format . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Message Envelope  . . . . . . . . . . . . . . . . . . . .   5
         3.2.1.  Envelope Fields . . . . . . . . . . . . . . . . . . .   5
       3.3.  Message Types . . . . . . . . . . . . . . . . . . . . . .   5
       3.4.  Quality of Service Parameters . . . . . . . . . . . . . .   5
       3.5.  Capability Query  . . . . . . . . . . . . . . . . . . . .   6
       3.6.  Signature Format  . . . . . . . . . . . . . . . . . . . .   6
     4.  Semantic Addresses  . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Decentralized Identifiers (DIDs)  . . . . . . . . . . . .   6
       4.2.  Semantic Address Structure  . . . . . . . . . . . . . . .   7
     5.  Intent Schemas  . . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.  REQUEST_MEETING Intent  . . . . . . . . . . . . . . . . .   7
       5.2.  APPROVAL_REQUEST Intent . . . . . . . . . . . . . . . . .   7
       5.3.  SUBMIT_INFO Intent  . . . . . . . . . . . . . . . . . . .   8
       5.4.  INVOICE Intent  . . . . . . . . . . . . . . . . . . . . .   8
       5.5.  FREEFORM_NOTE Intent  . . . . . . . . . . . . . . . . . .   8
       5.6.  REQUEST_SERVICE Intent  . . . . . . . . . . . . . . . . .   9
     6.  Negotiation Protocol  . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Negotiation Flow  . . . . . . . . . . . . . . . . . . . .   9
       6.2.  Negotiation Message Structure . . . . . . . . . . . . . .   9
       6.3.  Negotiation Convergence . . . . . . . . . . . . . . . . .   9
       6.4.  Timeout Behavior  . . . . . . . . . . . . . . . . . . . .  10
       6.5.  Multi-Party Negotiation . . . . . . . . . . . . . . . . .  10
     7.  Protocol Handshake Sequence . . . . . . . . . . . . . . . . .  10
       7.1.  Five-Step Handshake . . . . . . . . . . . . . . . . . . .  10
       7.2.  ADVERTISE Phase . . . . . . . . . . . . . . . . . . . . .  10
       7.3.  DISCOVER Phase  . . . . . . . . . . . . . . . . . . . . .  11
       7.4.  ERROR Phase . . . . . . . . . . . . . . . . . . . . . . .  11
       7.5.  Offline Intent Queueing . . . . . . . . . . . . . . . . .  12
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
       8.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
       8.2.  Identity  . . . . . . . . . . . . . . . . . . . . . . . .  12



  Nagulapalli                Expires 28 May 2026                  [Page 2]


  Internet-Draft                AINP Protocol                November 2025


       8.3.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  12
       8.4.  Replay Protection . . . . . . . . . . . . . . . . . . . .  12
       8.5.  DoS Protection  . . . . . . . . . . . . . . . . . . . . .  13
       8.6.  Replay Protection and Delivery Semantics  . . . . . . . .  13
       8.7.  Capability Attestations . . . . . . . . . . . . . . . . .  13
       8.8.  Timeouts  . . . . . . . . . . . . . . . . . . . . . . . .  13
       8.9.  Outlier Detection . . . . . . . . . . . . . . . . . . . .  13
       8.10. Discovery Scalability . . . . . . . . . . . . . . . . . .  13
       8.11. Lite Mode for Resource-Constrained Agents . . . . . . . .  14
     9.  CBOR Encoding (Optional)  . . . . . . . . . . . . . . . . . .  15
     10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . .  15
       10.1.  Custom Intent Types  . . . . . . . . . . . . . . . . . .  15
       10.2.  Custom Negotiation Terms . . . . . . . . . . . . . . . .  15
       10.3.  Versioning . . . . . . . . . . . . . . . . . . . . . . .  15
       10.4.  Lite Profile (Trusted Networks)  . . . . . . . . . . . .  15
     11. Success Metrics . . . . . . . . . . . . . . . . . . . . . . .  16
       11.1.  Route Success Rate . . . . . . . . . . . . . . . . . . .  16
       11.2.  Latency (p95)  . . . . . . . . . . . . . . . . . . . . .  16
       11.3.  Negotiation Completion Rate  . . . . . . . . . . . . . .  16
       11.4.  False Route Rate . . . . . . . . . . . . . . . . . . . .  16
       11.5.  Abuse Resilience . . . . . . . . . . . . . . . . . . . .  16
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  16
       13.2.  Informative References . . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     Traditional network protocols (TCP/IP, HTTP, SMTP) were designed for
     reliable byte stream delivery between machines.  AINP represents a
     paradigm shift: it is designed for semantic intent delivery between
     AI agents, with built-in understanding, negotiation, and adaptation.

     AINP Phase 0.1 provides: - Wire format specification (JSON-LD + CBOR)
     - Message envelope structure with cryptographic signatures - Intent
     schemas for common agent interactions - Semantic address format with
     Decentralized Identifiers (DIDs) - Negotiation protocol for multi-
     agent consensus - Discovery and routing mechanisms

  1.1.  Terminology

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






  Nagulapalli                Expires 28 May 2026                  [Page 3]


  Internet-Draft                AINP Protocol                November 2025


  1.1.1.  Definitions

     *Agent*: An autonomous software entity capable of semantic
     understanding and intent exchange

     *Intent*: A semantic representation of an agent's goal, including
     embeddings and structured semantics

     *Semantic Address*: An identity-based address using DIDs and
     capability descriptors

     *Negotiation*: Multi-round protocol for establishing consensus on
     resources, terms, and capabilities

     *Capability*: A semantic description of what an agent can do,
     including natural language and embeddings

     *Trust Vector*: Multi-dimensional reputation score tracking
     reliability, honesty, competence, and timeliness

  2.  Architecture Overview

     AINP consists of four layers:

     +-----------------------------+ | Intent Layer | Semantic exchange
     (intents) +-----------------------------+ | Negotiation Layer |
     Multi-agent consensus +-----------------------------+ | Routing
     Layer | Semantic routing +-----------------------------+ | Substrate
     Layer | Physical transport (TCP/IP, etc.)
     +-----------------------------+

     Phase 0.1 runs as an overlay network on TCP/IP with WebSocket or
     HTTP/3 transport.

  3.  Wire Format

  3.1.  Encoding

     AINP messages MUST support both: - *JSON-LD*: Human-readable, linked
     data format with @context for semantic interoperability - *CBOR*:
     Binary encoding ([RFC8949]) for efficient transmission

     Implementations SHOULD negotiate encoding during handshake.  JSON-LD
     is the default for Phase 0.1.







  Nagulapalli                Expires 28 May 2026                  [Page 4]


  Internet-Draft                AINP Protocol                November 2025


  3.2.  Message Envelope

     All AINP messages MUST be wrapped in an envelope structure:

     json { "version": "0.1.0", "msg_type": "INTENT", "id": "550e8400-
     e29b-41d4-a716-446655440000", "timestamp": 1728259400000, "ttl":
     30000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
     "to_did": "did:key:z6Mk...", "schema":
     "https://ainp.dev/schemas/intents/request-meeting/v1", "qos": {
     "urgency": 0.7, "importance": 0.8, "novelty": 0.1, "ethicalWeight":
     0.5, "bid": 5 }, "payload": { ... }, "sig": "base64signature..." }

  3.2.1.  Envelope Fields

     *  version (string, REQUIRED): Protocol version, MUST be "0.1.0"
     *  msg_type (string, REQUIRED): Message type (see Section 3.3)
     *  id (string, REQUIRED): UUID v4 for message identification
     *  timestamp (number, REQUIRED): Unix epoch milliseconds
     *  ttl (number, REQUIRED): Time-to-live in milliseconds
     *  trace_id (string, REQUIRED): Distributed tracing UUID for thread
        tracking
     *  from_did (string, REQUIRED): Sender DID ([W3C.DID])
     *  to_did (string, OPTIONAL): Recipient DID (for direct addressing)
     *  to_query (object, OPTIONAL): Semantic query (alternative to
        to_did, see Section 3.5)
     *  schema (string, REQUIRED): JSON-LD context URI
     *  qos (object, REQUIRED): Quality of Service parameters (see
        Section 3.4)
     *  payload (object, OPTIONAL): Application payload (intent,
        negotiation, etc.)
     *  sig (string, REQUIRED): Ed25519 signature in base64 encoding

  3.3.  Message Types

     AINP defines the following message types:

     *  ADVERTISE: Publish capabilities to discovery index
     *  DISCOVER: Query for agents by capability
     *  DISCOVER_RESULT: Discovery results
     *  NEGOTIATE: Multi-round negotiation
     *  INTENT: Send intent payload
     *  RESULT: Response with optional proof
     *  ERROR: Error response

  3.4.  Quality of Service Parameters

     QoS parameters enable priority-based routing and resource allocation:




  Nagulapalli                Expires 28 May 2026                  [Page 5]


  Internet-Draft                AINP Protocol                November 2025


     json { "urgency": 0.7, // 0-1, time sensitivity "importance": 0.8, //
     0-1, impact magnitude "novelty": 0.1, // 0-1, information gain
     "ethicalWeight": 0.5, // 0-1, moral importance "bid": 5 // Token
     amount or credits (non-negative) }

     *Priority Calculation*: Implementations SHOULD calculate message
     priority as:

     priority = (urgency * w_urgency) + (importance * w_importance) +
     (novelty * w_novelty) + (ethicalWeight * w_ethical) adjusted_priority
     = priority + 0.5 * tanh(bid / bid_scale)

     Where bid_scale is node-configurable (RECOMMENDED default: 10
     credits).

     *Default Weights*: - w_urgency = 0.3 - w_importance = 0.3 - w_novelty
     = 0.2 - w_ethical = 0.2

  3.5.  Capability Query

     For semantic discovery, agents use capability queries:

     json { "description": "Find agents who can schedule meetings",
     "embedding": "base64-encoded Float32Array[1536]", "tags":
     ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000,
     "max_cost": 10 }

  3.6.  Signature Format

     Messages MUST be signed using Ed25519 ([Ed25519]) with detached
     signatures in base64 encoding.

     *Signing Process*: 1.  Serialize envelope fields (excluding sig) to
     canonical JSON ([RFC8785]) 2.  Compute SHA-256 hash of canonical JSON
     3.  Sign hash with Ed25519 private key 4.  Encode signature as base64
     5.  Add sig field to envelope

     *Verification Process*: 1.  Extract sig field 2.  Remove sig from
     envelope 3.  Serialize remaining fields to canonical JSON ([RFC8785])
     4.  Compute SHA-256 hash 5.  Verify signature using Ed25519 public
     key from from_did

  4.  Semantic Addresses

  4.1.  Decentralized Identifiers (DIDs)

     Agents MUST have a DID conforming to [W3C.DID].




  Nagulapalli                Expires 28 May 2026                  [Page 6]


  Internet-Draft                AINP Protocol                November 2025


     *Supported DID Methods* (Phase 0.1): - did:key: - Self-certified
     cryptographic keys - did:web: - Web-based identifiers

  4.2.  Semantic Address Structure

     json { "did": "did:key:z6Mk...", "capabilities": [ { "description":
     "Schedule meetings with calendar integration", "embedding": { "b64":
     "base64-encoded float32 array", "dim": 1536, "dtype": "f32", "model":
     "openai:text-embedding-3-small" }, "tags": ["scheduling",
     "calendar"], "version": "1.0.0", "evidence":
     "https://credentials.example.com/vc/scheduling" } ], "trust": {
     "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85,
     "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977,
     "last_updated": 1728259200000 }, "credentials":
     ["https://credentials.example.com/vc/scheduling"] }

  5.  Intent Schemas

     AINP defines six core intent types for Phase 0.1.  All intents MUST
     include: - JSON-LD @context for semantic interoperability - Embedding
     (Embedding object; base64 Float32Array inside b64) - Budget
     constraints - Semantic payload

  5.1.  REQUEST_MEETING Intent

     *Schema URI*: https://ainp.dev/schemas/intents/request-meeting/v1

     json { "@context": "https://ainp.dev/contexts/meeting/v1", "@type":
     "RequestMeeting", "version": "1.0.0", "embedding": { "b64":
     "base64-encoded Float32Array", "dim": 1536, "dtype": "f32", "model":
     "openai:text-embedding-3-small" }, "semantics": { "participants":
     ["did:key:..."], "duration_minutes": 30, "preferred_times":
     ["2025-10-07T14:00:00Z"], "location": "virtual", "constraints": {
     "timezone": "America/Los_Angeles", "max_latency_ms": 5000,
     "min_notice_hours": 24 } }, "budget": { "max_credits": 10,
     "max_rounds": 5, "timeout_ms": 30000 } }

  5.2.  APPROVAL_REQUEST Intent

     *Schema URI*: https://ainp.dev/schemas/intents/approval-request/v1











  Nagulapalli                Expires 28 May 2026                  [Page 7]


  Internet-Draft                AINP Protocol                November 2025


     json { "@context": "https://ainp.dev/contexts/approval/v1", "@type":
     "ApprovalRequest", "version": "1.0.0", "embedding": { "b64": "...",
     "dim": 1536, "dtype": "f32" }, "semantics": { "request_type":
     "purchase", "description": "Purchase office supplies", "amount": 500,
     "currency": "USD", "justification": "Quarterly restock", "deadline":
     "2025-10-10T00:00:00Z", "approvers": ["did:key:..."], "threshold": 1,
     "constraints": { "requires_attestation": true, "max_latency_ms": 5000
     } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms":
     30000 } }

  5.3.  SUBMIT_INFO Intent

     *Schema URI*: https://ainp.dev/schemas/intents/submit-info/v1

     json { "@context": "https://ainp.dev/contexts/submit-info/v1",
     "@type": "SubmitInfo", "version": "1.0.0", "embedding": { "b64":
     "...", "dim": 1536, "dtype": "f32" }, "semantics": { "data_type":
     "form", "payload": { "field1": "value1" }, "schema_ref":
     "https://example.com/schema.json", "privacy_level": "encrypted",
     "retention_policy": { "duration_days": 90, "delete_after": true },
     "constraints": { "requires_acknowledgment": true, "max_latency_ms":
     5000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
     "timeout_ms": 15000 } }

  5.4.  INVOICE Intent

     *Schema URI*: https://ainp.dev/schemas/intents/invoice/v1

     json { "@context": "https://ainp.dev/contexts/invoice/v1", "@type":
     "Invoice", "version": "1.0.0", "embedding": { "b64": "...", "dim":
     1536, "dtype": "f32" }, "semantics": { "invoice_id": "INV-2025-001",
     "from": "did:key:...", "to": "did:key:...", "amount": "1000.00",
     "currency": "USD", "line_items": [ { "description": "Service fee",
     "quantity": 1, "unit_price": "1000.00", "total": "1000.00" } ],
     "due_date": "2025-11-01T00:00:00Z", "payment_methods": ["crypto",
     "wire"], "constraints": { "requires_escrow": true, "max_latency_ms":
     10000 } }, "budget": { "max_credits": 5, "max_rounds": 3,
     "timeout_ms": 30000 } }

  5.5.  FREEFORM_NOTE Intent

     *Schema URI*: https://ainp.dev/schemas/intents/freeform-note/v1

     json { "@context": "https://ainp.dev/contexts/freeform/v1", "@type":
     "FreeformNote", "version": "1.0.0", "embedding": { "b64": "...",
     "dim": 1536, "dtype": "f32" }, "semantics": { "subject": "Meeting
     notes", "body": "Discussion summary...", "format": "markdown",
     "attachments": [ { "url": "https://example.com/doc.pdf", "mime_type":



  Nagulapalli                Expires 28 May 2026                  [Page 8]


  Internet-Draft                AINP Protocol                November 2025


     "application/pdf", "size_bytes": 102400, "hash": "sha256:abc123..." }
     ], "thread_id": "thread-123", "in_reply_to": "msg-456",
     "constraints": { "max_latency_ms": 5000 } }, "budget": {
     "max_credits": 1, "max_rounds": 1, "timeout_ms": 10000 } }

  5.6.  REQUEST_SERVICE Intent

     *Schema URI*: https://ainp.dev/schemas/intents/request-service/v1

     json { "@context": "https://ainp.dev/contexts/service/v1", "@type":
     "RequestService", "version": "1.0.0", "embedding": { "b64": "...",
     "dim": 1536, "dtype": "f32" }, "semantics": { "service_type":
     "plumbing.leak.fix", "geo": { "lat": 37.7749, "lon": -122.4194,
     "radiusKm": 10, "zip": "94102" }, "time_window": { "earliest":
     "2025-10-08T09:00:00Z", "latest": "2025-10-08T17:00:00Z" },
     "constraints": { "eco": true, "access_notes": "Ring doorbell",
     "evidence_required": ["photo_before_after"] }, "details": {
     "urgency": "high", "description": "Kitchen sink leak" } }, "budget":
     { "max_credits": 20, "max_total": 200, "escrow_required": true,
     "max_rounds": 10, "timeout_ms": 60000 } }

  6.  Negotiation Protocol

  6.1.  Negotiation Flow

     Negotiation MUST follow this state machine:

     START -> OFFER -> COUNTER <-> COUNTER -> ACCEPT | | ABORT TIMEOUT | |
     REJECT REJECT

  6.2.  Negotiation Message Structure

     json { "negotiation_id": "uuid", "round": 1, "phase": "OFFER",
     "proposal": { "price": 100, "latency_ms": 500, "confidence": 0.9,
     "privacy": "encrypted", "terms": {} }, "constraints": { "max_rounds":
     10, "timeout_per_round_ms": 5000, "convergence_threshold": 0.9 } }

     *Negotiation Phases*: - OFFER: Initial offer - COUNTER: Counter-offer
     - ACCEPT: Accept proposal - REJECT: Reject and end - ABORT: Abort
     negotiation - TIMEOUT: Timeout occurred

  6.3.  Negotiation Convergence

     Implementations MAY auto-accept proposals when convergence threshold
     is met:

     ``` convergence_score = 1 - (abs(offer.price - counter.price) /
     max(offer.price, counter.price))



  Nagulapalli                Expires 28 May 2026                  [Page 9]


  Internet-Draft                AINP Protocol                November 2025


     if convergence_score >= convergence_threshold: auto_accept() ```

  6.4.  Timeout Behavior

     *  *Per-round timeout*: If no response within timeout_per_round_ms,
        sender MAY send TIMEOUT message
     *  *Overall timeout*: If negotiation exceeds max_rounds *
        timeout_per_round_ms, MUST terminate with TIMEOUT

  6.5.  Multi-Party Negotiation

     For intents involving multiple agents (e.g., scheduling a meeting
     with 5 participants, multi-signature approvals), negotiation MUST
     support group consensus mechanisms.

     *Group Proposal Structure*: json { "negotiation_id": "multi-abc123",
     "phase": "OFFER", "proposal": { "participants": ["did:key:agent-a",
     "did:key:agent-b", "did:key:agent-c"], "voting_mechanism":
     "majority", "convergence_threshold": 0.75, "terms": {
     "preferred_times": ["2025-10-07T14:00:00Z", "2025-10-07T15:00:00Z"],
     "duration_minutes": 30 } } }

     *Voting Mechanisms*: 1. *Unanimous*: All agents must ACCEPT (default
     for high-stakes) 2. *Majority*: More than 50% must ACCEPT 3.
     *Weighted*: Votes weighted by trust scores

     *Multi-Party Flow*: 1.  Fan-out: Send NEGOTIATE(OFFER) to all
     participants 2.  Collection: Each agent responds with individual
     proposal 3.  Aggregation: Broker aggregates and computes consensus
     score 4.  Convergence Check: Compare score to threshold 5.  Auto-
     accept if converged, else synthesize counter-proposal and repeat 6.
     Termination: ABORT after max_rounds or timeout if no consensus

  7.  Protocol Handshake Sequence

  7.1.  Five-Step Handshake

     1.  *ADVERTISE*: Agent publishes capabilities to discovery index
     2.  *DISCOVER*: Agent queries for matching capabilities
     3.  *NEGOTIATE*: Agents negotiate terms (OFFER → COUNTER → ACCEPT)
     4.  *INTENT*: Agent sends intent after successful negotiation
     5.  *RESULT*: Recipient responds with result

  7.2.  ADVERTISE Phase

     Agent publishes capabilities to discovery index:





  Nagulapalli                Expires 28 May 2026                 [Page 10]


  Internet-Draft                AINP Protocol                November 2025


     json { "version": "0.1.0", "msg_type": "ADVERTISE", "id": "550e8400-
     e29b-41d4-a716-446655440000", "timestamp": 1728259200000, "ttl":
     86400000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...",
     "schema": "https://ainp.dev/schemas/advertise/v1", "qos": {
     "urgency": 0.1, "importance": 0.5, "novelty": 0.3, "ethicalWeight":
     0.5, "bid": 0 }, "sig": "base64signature...", "payload": {
     "capabilities": [ { "description": "Schedule meetings with calendar
     integration", "embedding": { "b64": "...", "dim": 1536, "dtype":
     "f32" }, "tags": ["scheduling", "calendar"], "version": "1.0.0",
     "evidence": "https://credentials.example.com/vc/scheduling" } ],
     "trust": { "score": 0.85, "dimensions": { "reliability": 0.9,
     "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 },
     "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials":
     ["https://credentials.example.com/vc/scheduling"] } }

  7.3.  DISCOVER Phase

     Agent queries for capabilities:

     json { "version": "0.1.0", "msg_type": "DISCOVER", "id": "660e8400-
     e29b-41d4-a716-446655440001", "timestamp": 1728259300000, "ttl":
     10000, "trace_id": "trace-def456", "from_did": "did:key:z6Mk...",
     "to_query": { "description": "Find agents who can schedule meetings",
     "embedding": "base64...", "tags": ["scheduling", "calendar"],
     "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }, "schema":
     "https://ainp.dev/schemas/discover/v1", "qos": { "urgency": 0.5,
     "importance": 0.7, "novelty": 0.2, "ethicalWeight": 0.5, "bid": 1 },
     "sig": "base64signature..." }

     Discovery index responds with DISCOVER_RESULT containing matching
     agents with similarity scores, trust ratings, and estimated latency.

  7.4.  ERROR Phase

     On error, agent MUST respond with ERROR message:

     json { "msg_type": "ERROR", "error_code": "TIMEOUT", "error_message":
     "Negotiation timed out", "intent_id": "770e8400-e29b-
     41d4-a716-446655440002", "retry_after_ms": 5000 }

     *Standard Error Codes*: - INVALID_SIGNATURE - UNAUTHORIZED -
     UNSUPPORTED_SCHEMA - TIMEOUT - RATE_LIMIT_EXCEEDED -
     INSUFFICIENT_CREDITS - NEGOTIATION_FAILED - ESCROW_REQUIRED -
     EVIDENCE_INSUFFICIENT - DUPLICATE_INTENT - AGENT_OFFLINE -
     INTERNAL_ERROR






  Nagulapalli                Expires 28 May 2026                 [Page 11]


  Internet-Draft                AINP Protocol                November 2025


  7.5.  Offline Intent Queueing

     When recipient agent is offline or unreachable, broker MAY queue
     intents for later delivery instead of immediately failing.

     *Queue Behavior*: - TTL enforcement: Intent expires after ttl
     milliseconds from original timestamp - Broker SHOULD send ERROR to
     sender immediately: error_code: "AGENT_OFFLINE" - ERROR response
     SHOULD include retry_after_ms field - Broker MUST NOT queue intents
     indefinitely (maximum queue time = ttl)

     *Queue Delivery Protocol*: 1.  Agent Offline Detection: Broker
     detects agent offline 2.  Queue Intent: Insert into queue with
     expires_at = timestamp + ttl 3.  Send ERROR: Notify sender with
     AGENT_OFFLINE and retry_after_ms 4.  Agent Reconnect: When agent
     comes online, broker delivers queued intents in priority order 5.
     Delivery Ordering: Process queue as FIFO within each priority level
     6.  Retry Logic: If delivery fails, increment retry_count and retry
     after exponential backoff 7.  Expiration Cleanup: Periodically purge
     expired intents

  8.  Security Considerations

  8.1.  Authentication

     *  All messages MUST be signed with Ed25519
     *  Signatures MUST be verifiable using public key from from_did
     *  Unsigned messages MUST be rejected

  8.2.  Identity

     *  Agents MUST have a valid [W3C.DID]
     *  DIDs MUST be resolvable to DID documents containing public keys

  8.3.  Rate Limiting

     Implementations MUST enforce rate limits: - Default: 100 intents per
     minute per agent - Burst: Up to 200 intents in 10-second window -
     Discovery queries: 10 per minute per agent

  8.4.  Replay Protection

     Recipients MUST reject duplicate messages with the same (from_did,
     id) seen within ttl + 60000ms.







  Nagulapalli                Expires 28 May 2026                 [Page 12]


  Internet-Draft                AINP Protocol                November 2025


  8.5.  DoS Protection

     Implementations MUST: - Validate message signatures before processing
     - Enforce TTL (drop expired messages) - Limit negotiation rounds (max
     10) - Reject messages exceeding 1MB payload size - Require
     attachments by reference (URLs) rather than inlining large binaries

  8.6.  Replay Protection and Delivery Semantics

     *  Recipients MUST reject duplicate messages with the same (from_did,
        id) seen within ttl + 60000ms
     *  Implementations MUST allow a clock skew of +/-60000ms when
        validating timestamp
     *  At-least-once delivery is RECOMMENDED; senders MUST use UUID v4
        ids and recipients MUST make intent handling idempotent with
        respect to id

  8.7.  Capability Attestations

     *  Agents advertising capabilities SHOULD provide Verifiable
        Credentials (VCs)
     *  VCs MUST conform to [W3C.VC]
     *  Discovery indices MAY reject advertisements without VCs

  8.8.  Timeouts

     *  *Intent delivery*: 60 seconds default TTL
     *  *Negotiation per round*: 5 seconds default
     *  *Overall negotiation*: 30 seconds default
     *  *Discovery query*: 10 seconds default

  8.9.  Outlier Detection

     Discovery indices SHOULD flag agents with: - Trust score < 0.3 -
     Capability embeddings >3 standard deviations from cluster mean
     (potential false advertising) - Success rate < 50% over last 100
     intents

  8.10.  Discovery Scalability

     *Phase 0.1 Architecture*: Centralized discovery index using
     PostgreSQL with pgvector extension for semantic search.

     *Vector Indexing*: Discovery indices SHOULD use Approximate Nearest
     Neighbor (ANN) indexing for efficient semantic search at scale.






  Nagulapalli                Expires 28 May 2026                 [Page 13]


  Internet-Draft                AINP Protocol                November 2025


     *Recommended Algorithm*: HNSW (Hierarchical Navigable Small World) -
     *Structure*: Multi-layer graph with hierarchical routing -
     *Parameters*: m = 16, ef_construction = 64, ef_search = 40 -
     *Distance Metric*: Cosine similarity - *Performance*: ~10ms search
     latency for 1M agents, ~99% recall

     *Scaling Strategies*: 1. *Vertical Scaling*: Increase HNSW
     parameters, use NVMe SSDs, scale PostgreSQL memory 2. *Horizontal
     Scaling*: Read replicas, connection pooling (PgBouncer), Redis
     caching 3. *Partitioning*: Capability sharding, tag-based routing,
     geographic partitioning 4. *Query Optimization*: Pre-filtering, batch
     queries, approximate search

     *Performance Benchmarks* (Phase 0.1 targets):

     +=============+============+============+===============+===========+
     | Agent Count | Index Size | Build      | Query Latency | Recall@10 |
     |             |            | Time       | (p95)         |           |
     +=============+============+============+===============+===========+
     | 1K          | 2 MB       | 5s         | 2ms           | 99.5%     |
     +-------------+------------+------------+---------------+-----------+
     | 10K         | 20 MB      | 45s        | 5ms           | 99.2%     |
     +-------------+------------+------------+---------------+-----------+
     | 100K        | 200 MB     | 8 min      | 12ms          | 98.8%     |
     +-------------+------------+------------+---------------+-----------+
     | 1M          | 2 GB       | 90         | 25ms          | 98.0%     |
     |             |            | min        |               |           |
     +-------------+------------+------------+---------------+-----------+

                                    Table 1

  8.11.  Lite Mode for Resource-Constrained Agents

     For lightweight agents (e.g., IoT devices, mobile, embedded systems),
     implementations MAY use a minimal envelope to reduce payload size and
     processing overhead.

     *Required Fields*: version, msg_type, id, timestamp, from_did,
     to_did, sig

     *Optional Fields* (MAY be omitted): - ttl (default: 60000ms) -
     trace_id (no distributed tracing) - to_query (explicit addressing
     only) - capabilities_ref (no VC attestations) - attestations (trust
     by DID only) - qos (default: all 0.5, bid 0)







  Nagulapalli                Expires 28 May 2026                 [Page 14]


  Internet-Draft                AINP Protocol                November 2025


     *Lite Mode Constraints*: - Lite mode SHOULD NOT be used for high-
     stakes intents - Agents using lite mode MUST still provide valid
     Ed25519 signatures - Discovery indices MAY reject lite mode
     advertisements - Brokers MAY apply lower trust scores to lite mode
     agents by default

  9.  CBOR Encoding (Optional)

     For efficiency, implementations MAY use CBOR ([RFC8949]) encoding:

     *Key Map (v0.1)*: - 1: version - 2: msg_type - 3: id - 4: timestamp -
     5: ttl - 6: trace_id - 7: from_did - 8: to_did - 9: to_query - 10:
     schema - 11: qos - 12: capabilities_ref - 13: attestations - 14:
     payload - 15: sig

     CBOR encoding SHOULD be negotiated during ADVERTISE or DISCOVER
     phase.

  10.  Extensibility

  10.1.  Custom Intent Types

     Agents MAY define custom intent types beyond the core set.  Custom
     intents MUST: - Include @context with unique URI - Include version
     field - Include embedding field - Include budget constraints -
     Register schema URI in public registry (future)

  10.2.  Custom Negotiation Terms

     Proposal.terms field allows extensible negotiation parameters.
     Common extensions: - privacy_guarantees: ZK proof requirements -
     sla_guarantees: Service level agreements - data_retention: Data
     retention policies

  10.3.  Versioning

     AINP uses semantic versioning.  Breaking changes MUST increment major
     version.  Phase 0.1 is backwards-compatible within 0.x series.

  10.4.  Lite Profile (Trusted Networks)

     In trusted or closed-network deployments, the following
     simplifications are PERMITTED: - Omit capabilities_ref and
     attestations if peers are pre-authorized - Prefer JSON-LD for small
     payloads; negotiate CBOR for payloads > 4KB - Allow to_query-only
     routing within a single administrative domain





  Nagulapalli                Expires 28 May 2026                 [Page 15]


  Internet-Draft                AINP Protocol                November 2025


     Nodes MUST still sign messages, enforce TTLs, and implement replay
     protection.

  11.  Success Metrics

  11.1.  Route Success Rate

     route_success_rate = (intents_delivered_correctly /
     total_intents_sent) × 100%

     *Target (Phase 0.1)*: >=95%

  11.2.  Latency (p95)

     95th percentile time from INTENT sent to RESULT received.

     *Target (Phase 0.1)*: <=2000ms

  11.3.  Negotiation Completion Rate

     negotiation_completion_rate = (negotiations_accepted /
     total_negotiations) * 100

     *Target (Phase 0.1)*: >=80%

  11.4.  False Route Rate

     false_route_rate = (intents_misrouted / total_intents_sent) * 100

     *Target (Phase 0.1)*: <=5%

  11.5.  Abuse Resilience

     Detection rate of: - DoS attacks (>1000 requests/min from single
     agent) - Sybil attacks (multiple DIDs from same source) - False
     capability advertising (capability mismatch >0.5 cosine distance)

     *Target (Phase 0.1)*: >=90% detection rate

  12.  IANA Considerations

     This document has no IANA actions.

  13.  References

  13.1.  Normative References





  Nagulapalli                Expires 28 May 2026                 [Page 16]


  Internet-Draft                AINP Protocol                November 2025


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

     [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

     [W3C.DID]  W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July
                2022, <https://www.w3.org/TR/did-core/>.

     [W3C.VC]   W3C, "Verifiable Credentials Data Model v1.1", 3 March
                2022, <https://www.w3.org/TR/vc-data-model/>.

  13.2.  Informative References

     [Ed25519]  Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B.
                Yang, "High-speed high-security signatures", 26 September
                2011, <https://ed25519.cr.yp.to/>.

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

  Author's Address

     Eswara Prasad Nagulapalli
     Servesys Labs
     Email: contact@servsys.com



















  Nagulapalli                Expires 28 May 2026                 [Page 17]


name: draft-gaikwad-south-authorization
rev: 00
title: SOUTH: Stochastic Authorization for Agent and Service Requests
time: 2025-11-28T10:20:18Z
group_uri: /api/v1/group/group/1027/
expires: 2026-06-01T10:20:18Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.415810+00:00
source: ietf
abstract:
  SOUTH defines an authorization protocol for evaluating requests
     issued by users, services, or autonomous agents.  SOUTH allows a
     server to return a deterministic decision or an allow decision that
     is issued with a probability determined by local policy.  This
     enables servers to incorporate uncertainty, contextual information,
     and load conditions into authorization decisions.

     SOUTH is transport independent and can be composed with existing
     authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
     or DPoP.  This document describes the request and response objects,
     decision semantics, and an HTTP binding for interoperable deployment.

full_text:
  Network Working Group                                         M. Gaikwad
  Internet-Draft                                    Independent Researcher
  Intended status: Experimental                           28 November 2025
  Expires: 1 June 2026


       SOUTH: Stochastic Authorization for Agent and Service Requests
                    draft-gaikwad-south-authorization-00

  Abstract

     SOUTH defines an authorization protocol for evaluating requests
     issued by users, services, or autonomous agents.  SOUTH allows a
     server to return a deterministic decision or an allow decision that
     is issued with a probability determined by local policy.  This
     enables servers to incorporate uncertainty, contextual information,
     and load conditions into authorization decisions.

     SOUTH is transport independent and can be composed with existing
     authentication mechanisms such as OAuth, OpenID Connect, mutual TLS,
     or DPoP.  This document describes the request and response objects,
     decision semantics, and an HTTP binding for interoperable deployment.

  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 1 June 2026.

  Copyright Notice

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







  Gaikwad                    Expires 1 June 2026                  [Page 1]


  Internet-Draft                    SOUTH                    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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Design Goals and Non-Goals  . . . . . . . . . . . . . . . . .   6
       4.1.  Design Goals  . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.  Non-Goals . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.1.  Roles . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.2.  Interaction Model . . . . . . . . . . . . . . . . . . . .   9
       5.3.  Deployment Patterns . . . . . . . . . . . . . . . . . . .   9
     6.  Decision Semantics  . . . . . . . . . . . . . . . . . . . . .  10
       6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  10
       6.2.  Deterministic Allow and Deny  . . . . . . . . . . . . . .  11
       6.3.  Stochastic Allow  . . . . . . . . . . . . . . . . . . . .  11
       6.4.  Retry and Defer . . . . . . . . . . . . . . . . . . . . .  12
       6.5.  Error Semantics . . . . . . . . . . . . . . . . . . . . .  12
       6.6.  Idempotence and Side Effects  . . . . . . . . . . . . . .  13
     7.  Request Object  . . . . . . . . . . . . . . . . . . . . . . .  13
       7.1.  Fields  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Subject . . . . . . . . . . . . . . . . . . . . . . . . .  14
       7.3.  Action  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       7.4.  Object  . . . . . . . . . . . . . . . . . . . . . . . . .  15
       7.5.  Context and Signals . . . . . . . . . . . . . . . . . . .  15
       7.6.  Complete Request Example  . . . . . . . . . . . . . . . .  16
     8.  Response Object . . . . . . . . . . . . . . . . . . . . . . .  17
       8.1.  Fields  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       8.2.  Allow Responses . . . . . . . . . . . . . . . . . . . . .  19
       8.3.  Deny Responses  . . . . . . . . . . . . . . . . . . . . .  19
       8.4.  Retry and Defer Responses . . . . . . . . . . . . . . . .  20
       8.5.  Error Responses . . . . . . . . . . . . . . . . . . . . .  20
       8.6.  Correlation and Logging . . . . . . . . . . . . . . . . .  21
     9.  Wire Protocol . . . . . . . . . . . . . . . . . . . . . . . .  21
       9.1.  Transport Independent Model . . . . . . . . . . . . . . .  21
       9.2.  HTTP Binding  . . . . . . . . . . . . . . . . . . . . . .  22
       9.3.  HTTP Status Codes . . . . . . . . . . . . . . . . . . . .  23
       9.4.  Timeouts and Retries  . . . . . . . . . . . . . . . . . .  23
       9.5.  Idempotence and Caching . . . . . . . . . . . . . . . . .  24
     10. Operational Modes . . . . . . . . . . . . . . . . . . . . . .  24
       10.1.  Agent and Tool Authorization . . . . . . . . . . . . . .  24
       10.2.  Service to Service and Mesh Gateways . . . . . . . . . .  25



  Gaikwad                    Expires 1 June 2026                  [Page 2]


  Internet-Draft                    SOUTH                    November 2025


       10.3.  Mail Transfer Agents . . . . . . . . . . . . . . . . . .  25
       10.4.  SDN Controllers and NFV Service Chaining . . . . . . . .  26
       10.5.  Kubernetes Admission and Scheduling  . . . . . . . . . .  26
       10.6.  Library and Local Mode . . . . . . . . . . . . . . . . .  27
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  27
       11.1.  Authentication and Integrity . . . . . . . . . . . . . .  27
       11.2.  Fail Open and Fail Closed Behavior . . . . . . . . . . .  28
       11.3.  Stochastic Decisions and Probing . . . . . . . . . . . .  28
       11.4.  Logging and Policy Leakage . . . . . . . . . . . . . . .  29
       11.5.  Dependency and Bypass Risks  . . . . . . . . . . . . . .  29
       11.6.  Denial of Service  . . . . . . . . . . . . . . . . . . .  30
       11.7.  Caching and Replay . . . . . . . . . . . . . . . . . . .  30
       11.8.  Agent Specific Considerations  . . . . . . . . . . . . .  31
     12. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  31
       12.1.  Data Types in SOUTH Messages . . . . . . . . . . . . . .  31
       12.2.  Data Minimization  . . . . . . . . . . . . . . . . . . .  32
       12.3.  Retention and Access Control for Logs  . . . . . . . . .  32
       12.4.  Agent Context and Prompt Data  . . . . . . . . . . . . .  33
       12.5.  Metadata and Inference Risks . . . . . . . . . . . . . .  33
       12.6.  Cross Border Transfers and Third Parties . . . . . . . .  33
       12.7.  User Rights and Transparency . . . . . . . . . . . . . .  34
       12.8.  Extensions and Profiles  . . . . . . . . . . . . . . . .  34
     13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
       13.1.  application/south+json Media Type  . . . . . . . . . . .  35
     14. Normative References  . . . . . . . . . . . . . . . . . . . .  36
     15. Informative References  . . . . . . . . . . . . . . . . . . .  36
     Appendix A.  Example Flows  . . . . . . . . . . . . . . . . . . .  37
       A.1.  Agent Tool Invocation . . . . . . . . . . . . . . . . . .  37
       A.2.  Service Mesh Gateway  . . . . . . . . . . . . . . . . . .  39
       A.3.  Mail Transfer Agent . . . . . . . . . . . . . . . . . . .  40
     Appendix B.  Signing Profiles . . . . . . . . . . . . . . . . . .  41
       B.1.  Mutual TLS Profile  . . . . . . . . . . . . . . . . . . .  41
       B.2.  OAuth 2.0 and DPoP Profile  . . . . . . . . . . . . . . .  41
       B.3.  Signed Request Bodies . . . . . . . . . . . . . . . . . .  42
       B.4.  Agent and User Binding  . . . . . . . . . . . . . . . . .  42
     Appendix C.  Rate and Load Aware Policies . . . . . . . . . . . .  42
       C.1.  Rate and Load Signals . . . . . . . . . . . . . . . . . .  43
       C.2.  Decisions for Throttling and Shedding . . . . . . . . . .  43
       C.3.  Agent Specific Rate Policies  . . . . . . . . . . . . . .  43
       C.4.  Fairness and Multi Tenant Settings  . . . . . . . . . . .  44
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  44










  Gaikwad                    Expires 1 June 2026                  [Page 3]


  Internet-Draft                    SOUTH                    November 2025


  1.  Introduction

     Systems that act on behalf of users or other services must decide
     whether a requested operation is permitted.  Traditional
     authorization mechanisms rely on deterministic evaluation of
     attributes, roles, or policy rules.  These mechanisms are effective
     in constrained environments, but they do not represent uncertainty,
     context variation, or adaptive behavior that arise in modern agent
     driven systems.

     SOUTH defines a small authorization protocol that allows a server to
     return either a deterministic decision or a probabilistic allow
     decision.  A server evaluates a structured request, computes a
     preference score, and maps this score to a decision.  SOUTH also
     supports retry and defer outcomes that allow a server to signal
     transient conditions, such as load or missing context.  SOUTH does
     not replace authentication or identity.  Instead, it complements
     existing identity systems by defining a consistent authorization
     interface.

     The name SOUTH is derived from "Stochastic Auth."  It reflects the
     protocol's ability to express authorization decisions that may
     include probabilistic behavior, allowing servers to map preference
     scores or contextual signals to non-deterministic outcomes when
     required by policy.

     The protocol is transport independent.  It can be used with HTTP,
     message queues, or local control interfaces.  It can also be paired
     with authentication and integrity mechanisms such as OAuth based
     flows, OpenID Connect, mutual TLS, or DPoP proof of possession.
     SOUTH does not define how preference scores are computed.  It defines
     the request and response structures and the semantics of decisions
     returned by a server.

     SOUTH can be used by user agents, machine learning agents, service
     meshes, schedulers, MTAs, SDN controllers, and similar components
     that require an explicit authorization decision for a proposed
     action.  This document describes terminology, message formats,
     decision semantics, transport bindings, and operational
     considerations for interoperable use.

  2.  Terminology

     The terms defined in this section are used throughout this document.
     These definitions are specific to the SOUTH protocol.






  Gaikwad                    Expires 1 June 2026                  [Page 4]


  Internet-Draft                    SOUTH                    November 2025


     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] and [RFC8174] when, and only when, they appear in all
     capitals.

     Client  The entity that sends a SOUTH request.  A client may be a
        user agent, an automated agent, a service, a scheduler, or any
        component that requires an authorization decision for a proposed
        operation.

     Server  The entity that evaluates a SOUTH request and returns a
        decision.  A server applies local policy to determine whether a
        request should be allowed, denied, retried, or deferred.

     Request  A structured object that describes the operation the client
        wishes to perform.  A request includes an action, a target, and
        optional context that assists the server in making a decision.

     Decision  The outcome returned by a SOUTH server.  Decisions include
        allow, deny, retry, defer, and error.  SOUTH does not assign
        meaning to application level outcomes beyond these states.

     Preference Score  A numerical value in the interval [0, 1] that
        reflects how compatible a request is with server policy.  SOUTH
        does not specify how the score is computed.  The server maps the
        score to a decision.

     Stochastic Allow  A mode where the server returns an allow decision
        with a probability derived from the preference score.  The exact
        mapping is defined by server policy.

     Context Attachment  Additional information supplied by the client or
        collected by the server that provides signals relevant to the
        decision.  Examples include rate information, environmental data,
        recent behavior, or device posture.  Context attachment formats
        are implementation dependent.

     Integrity Binding  A method used to ensure that the request has not
        been modified and that the sender can prove possession of a key.
        SOUTH is transport independent and can be paired with mechanisms
        such as mutual TLS or DPoP.









  Gaikwad                    Expires 1 June 2026                  [Page 5]


  Internet-Draft                    SOUTH                    November 2025


  3.  Motivation

     Authorization mechanisms used in current systems are largely
     deterministic.  A request is evaluated against a set of rules or
     attributes, and the server returns an allow or deny outcome.  These
     mechanisms work well when policies are simple and when the
     environment is stable.  Many modern deployments no longer meet these
     conditions.

     Agent driven systems, service meshes, serverless frameworks, and
     automated workflows issue requests whose safety depends on transient
     information such as current load, recent behavior, signal quality, or
     incomplete state.  A deterministic policy cannot represent these
     conditions without either becoming overly restrictive or overly
     permissive.  Systems often fall back on large sets of static rules
     that do not scale and are difficult to maintain.

     SOUTH introduces a small protocol that allows a server to encode
     preference and uncertainty directly.  A server evaluates a structured
     request, computes a score, and maps this score to a decision.  The
     server may return a deterministic allow or deny decision or may
     choose a probabilistic allow when the score falls in an uncertain
     range.  SOUTH also supports explicit retry and defer outcomes so that
     clients can distinguish between a stable deny and a temporary
     condition.

     This approach provides two benefits.  First, it allows a server to
     represent policies that depend on contextual or uncertain information
     without expanding the policy surface.  Second, it gives clients clear
     signals about whether a denial is final or whether a request may
     succeed after obtaining more context or waiting for transient
     conditions to change.

     SOUTH is intended for systems that require lightweight authorization
     decisions between components that operate at high frequency or under
     shifting operational context.  This aligns with zero trust principles
     [NIST-ZT].  It can be used by user agents, machine learning agents,
     schedulers, MTAs, SDN controllers, and other components that need
     explicit authorization semantics for proposed operations.

  4.  Design Goals and Non-Goals

     This section states the main design goals for SOUTH and clarifies
     which problems are outside the scope of this document.







  Gaikwad                    Expires 1 June 2026                  [Page 6]


  Internet-Draft                    SOUTH                    November 2025


  4.1.  Design Goals

     SOUTH is designed with the following goals.


     *  *Simple decision interface.* SOUTH provides a small set of
        decision outcomes such as allow, deny, retry, and defer.  The
        protocol does not try to encode full policy logic on the wire.
        Policy remains on the server.

     *  *Stochastic authorization.* SOUTH allows a server to map internal
        preference scores to probabilistic allow decisions.  This supports
        policies that depend on uncertain signals or that aim to reduce
        predictability for probing clients.

     *  *Transport independence.* SOUTH defines request and response
        objects that are not tied to one specific transport.  An HTTP
        binding is described in this document, but other bindings can be
        defined by deployment specific profiles.

     *  *Compatibility with existing identity.* SOUTH is intended to work
        alongside existing authentication and identity systems, such as
        OAuth based flows, OpenID Connect, mutual TLS, and DPoP.  It does
        not define its own identity model.

     *  *Low integration cost.* SOUTH can be called by existing components
        as an external decision service.  A client can construct a request
        object, send it to a SOUTH server, and apply the returned decision
        without changes to its internal policy representation.

     *  *Clear denial semantics.* SOUTH distinguishes between a stable
        deny, a temporary condition, and a request that should be retried
        or stepped up.  This allows clients to react appropriately to
        authorization outcomes.

  4.2.  Non-Goals

     SOUTH does not attempt to solve the following problems.


     *  *Authentication and identity.* SOUTH does not define how clients
        or servers authenticate.  It assumes that deployments use existing
        mechanisms such as mutual TLS, OAuth, OpenID Connect, or similar
        protocols.







  Gaikwad                    Expires 1 June 2026                  [Page 7]


  Internet-Draft                    SOUTH                    November 2025


     *  *Policy language definition.* SOUTH does not define a policy
        language or a rule syntax.  It defines only the interface for
        exchanging decisions.  Policy representation and evaluation are
        local choices.

     *  *Data plane enforcement.* SOUTH does not specify how decisions are
        enforced in data planes, such as packet forwarding hardware or
        message brokers.  Enforcement mechanisms are outside the scope of
        this document.

     *  *Global consistency.* SOUTH does not attempt to provide globally
        consistent authorization views across multiple servers.  Any
        replication or coordination of policy state is the responsibility
        of the deployment.

     *  *End to end security proofs.* SOUTH is a building block.  It does
        not provide a complete security framework for all authorization
        use cases and does not claim end to end security guarantees by
        itself.

  5.  Architecture

     SOUTH is designed as a decision service that can be called by
     different types of clients.  The protocol defines a logical client
     role, a server role, and supporting components such as policy stores
     and identity providers.  SOUTH does not constrain how these roles are
     deployed or how they are mapped to physical systems.

  5.1.  Roles

     The SOUTH architecture includes the following logical roles.


     Client  The client constructs a SOUTH request, sends it to a server,
        and applies the returned decision.  Clients may be user agents,
        automated agents, application services, schedulers, mail transfer
        agents, or network controllers.

     Server  The server receives SOUTH requests, evaluates them against
        local policy and context, and returns decisions.  A server may be
        implemented as a standalone service, as a component within a
        larger system, or as a library linked into an application.

     Policy Store  A policy store holds configuration and rules that the
        server uses to evaluate requests.  The format and location of the
        policy store are not specified by SOUTH.  A policy store may be a
        configuration file, a database, or an external policy engine.




  Gaikwad                    Expires 1 June 2026                  [Page 8]


  Internet-Draft                    SOUTH                    November 2025


     Identity Provider  An identity provider issues credentials or tokens
        that clients use to authenticate to the server.  SOUTH does not
        define identity provider behavior but assumes that servers can
        validate client identities using existing mechanisms.

  5.2.  Interaction Model

     The basic interaction pattern in SOUTH consists of a single request
     followed by a single response.


     1.  The client constructs a request object that describes the
         proposed operation.  The request includes information about the
         acting subject, the action to be performed, the target object,
         and optional context.

     2.  The client sends the request to the server using a chosen
         transport.  An HTTP binding using JSON is described in this
         document.  Other bindings may be defined in separate documents.

     3.  The server evaluates the request according to local policy.  The
         server may consult its policy store, fetch additional context, or
         apply internal scoring models.

     4.  The server returns a response that contains a decision and
         optional metadata.  The decision indicates whether the operation
         is allowed, denied, should be retried, or should be deferred.
         The response may include a probability or score for diagnostic or
         logging purposes.

     5.  The client applies the decision.  For example, a client may
         proceed with the operation, block it, queue it for later retry,
         or prompt for additional verification, depending on local
         behavior.

     SOUTH does not specify how many requests a client may send or how
     servers handle concurrent requests.  These aspects are deployment
     choices.  Implementations are expected to apply standard practices
     for rate limiting, timeouts, and failure handling.

  5.3.  Deployment Patterns

     SOUTH can be deployed in several patterns.  This document does not
     mandate any specific topology, but the following patterns are
     expected to be common.






  Gaikwad                    Expires 1 June 2026                  [Page 9]


  Internet-Draft                    SOUTH                    November 2025


     *  *Central decision service.* A dedicated SOUTH server receives
        requests from many clients and applies shared policy.  This is
        suitable for environments that want a single authorization view
        across multiple systems.

     *  *Sidecar or local proxy.* A SOUTH server runs next to an
        application component and serves only that component.  This avoids
        network hops but keeps policy evaluation separate from application
        logic.

     *  *Library integration.* SOUTH evaluation is implemented as a
        library linked into a client or gateway.  The wire protocol may
        still be used for audit, testing, or cross language integration,
        but is not required for every decision.

     *  *Controller integration.* A control plane component, such as a
        service mesh controller, scheduler, or SDN controller, calls SOUTH
        during its own decision flow.  The controller then programs local
        enforcement points based on the SOUTH decision.

     In all patterns, SOUTH is intended to run in the control plane or
     management plane.  Enforcement in data planes, such as packet
     forwarding paths or storage engines, is outside the scope of the
     protocol.  Implementations are expected to map SOUTH decisions to
     local enforcement mechanisms.

  6.  Decision Semantics

     SOUTH defines a small set of decision outcomes that a server can
     return to a client.  These outcomes are intended to be stable across
     deployments so that clients can react consistently, even when policy
     and scoring logic differ between servers.

  6.1.  Overview

     A SOUTH server evaluates a request and returns exactly one primary
     decision.  The decision describes how the client should treat the
     requested operation.  The server may include additional metadata,
     such as a numerical score or a probability value, but the primary
     decision is authoritative.

     This document groups decisions into four categories:


     *  Allow decisions, where the server authorizes the request.

     *  Deny decisions, where the server does not authorize the request.




  Gaikwad                    Expires 1 June 2026                 [Page 10]


  Internet-Draft                    SOUTH                    November 2025


     *  Retry and defer decisions, where the server indicates that the
        request might succeed later.

     *  Error outcomes, where the server cannot evaluate the request.

  6.2.  Deterministic Allow and Deny

     In the deterministic mode, the server returns an explicit allow or
     deny decision.  Clients that do not use stochastic behavior can treat
     SOUTH as a standard binary authorization protocol.


     allow  The server authorizes the requested operation.  The client is
        expected to proceed, subject to any local enforcement or
        application constraints.  An allow decision indicates that the
        server does not require additional checks for this request.

     deny  The server does not authorize the requested operation.  The
        client must not perform the operation.  A deny decision indicates
        that the server regards the request as incompatible with current
        policy and that the decision is stable with respect to the
        information available.

     A server that does not implement stochastic behavior or retry
     semantics can restrict itself to allow and deny decisions.

  6.3.  Stochastic Allow

     SOUTH supports a stochastic mode where the server produces an allow
     decision based on a probability derived from its internal preference
     score.  In this mode, the server evaluates the request, computes a
     score in the interval [0, 1], and maps this score to a probability of
     authorization.

     The exact mapping from score to probability is a matter of local
     policy.  A simple example is a threshold rule where scores above a
     high threshold always allow, scores below a low threshold always
     deny, and scores in between allow with a probability that increases
     with the score.

     When a server uses stochastic behavior, the primary decision seen by
     the client is still allow or deny.  SOUTH does not define a separate
     decision token for stochastic allow.  Instead, the server may include
     an optional field that reports the probability or score that was used
     to produce the decision.






  Gaikwad                    Expires 1 June 2026                 [Page 11]


  Internet-Draft                    SOUTH                    November 2025


     From the client perspective, a stochastic allow is processed in the
     same way as a deterministic allow.  The distinction is a server side
     choice that affects how often allow decisions are produced near the
     decision boundary.

  6.4.  Retry and Defer

     Some authorization outcomes are temporary.  A server may be
     overloaded, may be missing required context, or may need the client
     to perform an additional step before a decision can be made.  SOUTH
     models these situations through retry and defer outcomes.


     retry  The server cannot authorize the request at this time, but the
        client may retry after a delay.  The response may include a hint
        such as a suggested retry interval.  Clients must treat retry as a
        deny for the current attempt.

     defer  The server requests that the client defer the operation and
        possibly perform an additional step, such as step up verification
        or context collection.  The exact meaning of defer is deployment
        specific.  Clients must not perform the requested operation until
        a later allow decision is obtained.

     Retry and defer decisions allow clients to distinguish between a
     stable policy deny and a temporary condition.  This distinction is
     important in systems where repeated failures may signal
     misconfiguration, attack, or changes in policy.

  6.5.  Error Semantics

     A server may be unable to evaluate a request.  Causes include
     malformed input, lack of required authentication, internal faults, or
     backend unavailability.  In such cases, SOUTH distinguishes between
     an authorization decision and a protocol or processing error.

     When a server returns an error, the response indicates that no
     authorization decision has been made.  The client must apply its own
     failure policy.  For example, a client may choose to fail closed and
     block the operation, or fail open in development environments where
     availability is more important.

     Implementations should distinguish clearly between deny and error.  A
     deny decision is a valid authorization outcome.  An error indicates
     that the server did not complete the evaluation.






  Gaikwad                    Expires 1 June 2026                 [Page 12]


  Internet-Draft                    SOUTH                    November 2025


  6.6.  Idempotence and Side Effects

     SOUTH evaluates authorization decisions only.  It does not perform
     the requested operation and does not define any side effects beyond
     logging and internal accounting.  Two identical requests sent to the
     same server under the same conditions may produce the same decision
     or, in stochastic mode, may produce different outcomes with known
     probabilities.

     Clients should treat SOUTH calls as idempotent with respect to system
     state.  Any non idempotent behavior, such as consuming one time
     credentials, is a property of the surrounding system, not of SOUTH
     itself.

  7.  Request Object

     A SOUTH request is a structured object that describes the operation
     the client wishes to perform.  The request object is transport
     independent.  This document uses JSON examples for clarity, but other
     encodings are possible.

  7.1.  Fields

     A request object contains the fields listed below.  Fields marked as
     required MUST be present.  Fields marked as optional MAY be omitted.


     request_id (optional)  An opaque identifier chosen by the client.
        When present, the server SHOULD copy this value into the response.
        The identifier helps clients correlate responses with requests.

     subject (required)  An object that describes the actor on whose
        behalf the request is made.  The subject object MUST contain at
        least an id field and MAY contain a type field and an attributes
        object.

     action (required)  An object that describes the operation the client
        wishes to perform.  The action object MUST contain a type field
        and MAY contain additional fields such as name and parameters.

     object (required)  An object that describes the target of the
        operation.  The object MUST contain at least an id or type field
        and MAY contain an attributes object.

     context (optional)  An object that carries additional information
        about the environment, such as network location, device posture,
        rates, or time.  The structure of the context object is deployment
        specific.



  Gaikwad                    Expires 1 June 2026                 [Page 13]


  Internet-Draft                    SOUTH                    November 2025


     signals (optional)  An object that holds pre computed scores or hints
        from other modules, such as anomaly detectors or rate limiters.
        SOUTH does not define specific signal names.

     extensions (optional)  An object reserved for deployment specific
        fields that are not covered by the core model.  Extensions MUST
        NOT change the meaning of the core fields.

  7.2.  Subject

     The subject object describes who or what is acting.  A minimal
     subject object contains only an identifier.  Richer deployments may
     include type and attributes.  The following JSON examples are
     illustrative.

     {
       "subject": {
         "id": "user-1234"
       }
     }

                         Figure 1: Basic subject object

     {
       "subject": {
         "id": "service-api-gateway",
         "type": "service",
         "attributes": {
           "tenant": "tenant-42",
           "roles": ["gateway", "frontend"],
           "auth_method": "mtls"
         }
       }
     }

                       Figure 2: Extended subject object

  7.3.  Action

     The action object describes the requested operation.  The type field
     identifies the general category.  The name and parameters fields
     allow further refinement.









  Gaikwad                    Expires 1 June 2026                 [Page 14]


  Internet-Draft                    SOUTH                    November 2025


     {
       "action": {
         "type": "tool.invoke",
         "name": "database_query",
         "parameters": {
           "query": "SELECT * FROM customers WHERE id = ?"
         }
       }
     }

                        Figure 3: Example action objects

     Deployment profiles SHOULD define allowed action types and their
     expected parameters.  SOUTH itself does not interpret action
     semantics.

  7.4.  Object

     The object describes the target resource.  The identification scheme
     is deployment specific.  The object MAY be a logical resource such as
     a table, an API endpoint, a queue, a file, a node, or a service.

     {
       "object": {
         "id": "customers-table",
         "type": "database.table",
         "attributes": {
           "sensitivity": "high",
           "owner": "finance-team"
         }
       }
     }

                        Figure 4: Example object objects

  7.5.  Context and Signals

     The context and signals fields allow a client to supply additional
     information that may be relevant for policy evaluation.  The
     structure of these fields is not fixed by SOUTH.  Deployments may
     define profiles that describe common attributes.










  Gaikwad                    Expires 1 June 2026                 [Page 15]


  Internet-Draft                    SOUTH                    November 2025


     {
       "context": {
         "ip": "198.51.100.23",
         "location": "region-1",
         "time": "2025-11-27T10:34:12Z",
         "user_agent": "example-client/1.0"
       },
       "signals": {
         "anomaly_score": 0.41,
         "recent_failures": 2
       }
     }

                     Figure 5: Example context and signals

     Servers MAY ignore unknown context or signal fields.  Clients SHOULD
     NOT rely on any specific field being honored unless the deployment
     defines a shared profile.

  7.6.  Complete Request Example

     The following example shows a complete SOUTH request object in JSON
     form.  Line breaks and spacing are for readability.




























  Gaikwad                    Expires 1 June 2026                 [Page 16]


  Internet-Draft                    SOUTH                    November 2025


     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "subject": {
         "id": "user-1234",
         "type": "user",
         "attributes": {
           "tenant": "tenant-42",
           "roles": ["reader"]
         }
       },
       "action": {
         "type": "tool.invoke",
         "name": "database_query",
         "parameters": {
           "query": "SELECT * FROM customers WHERE id = ?"
         }
       },
       "object": {
         "id": "customers-table",
         "type": "database.table",
         "attributes": {
           "sensitivity": "high"
         }
       },
       "context": {
         "ip": "198.51.100.23",
         "location": "region-1",
         "time": "2025-11-27T10:34:12Z"
       },
       "signals": {
         "anomaly_score": 0.41
       },
       "extensions": {
         "trace_id": "abc123"
       }
     }

                    Figure 6: Complete SOUTH request example

  8.  Response Object

     A SOUTH response is a structured object that carries the server
     decision and optional metadata.  The response object is transport
     independent.  This document uses JSON examples for clarity, but other
     encodings are possible.






  Gaikwad                    Expires 1 June 2026                 [Page 17]


  Internet-Draft                    SOUTH                    November 2025


  8.1.  Fields

     A response object contains the fields listed below.  Fields marked as
     required MUST be present.  Fields marked as optional MAY be omitted.


     request_id (optional)  An opaque identifier copied from the request.
        When present, this value MUST match the request_id in the
        corresponding request.  It allows the client to correlate
        responses with requests.

     decision (required)  A string that indicates the primary outcome of
        the evaluation.  Valid values are "allow", "deny", "retry",
        "defer", and "error".

     score (optional)  A numerical value in the interval [0, 1] that
        represents the internal preference score used by the server.  This
        field is intended for diagnostics and logging.  Clients MUST NOT
        rely on a specific interpretation of this value unless agreed in a
        deployment profile.

     probability (optional)  A numerical value in the interval [0, 1] that
        represents the probability used when the server applies stochastic
        behavior to produce an allow decision.  This field MAY be present
        even when the decision is deny, to indicate the probability
        threshold that was not met.

     reason (optional)  A short, human readable string that describes the
        decision at a coarse level, such as "policy", "rate_limit", or
        "missing_context".  The reason is not intended to expose internal
        policy details.

     details (optional)  An object that carries structured diagnostic
        information.  The format of the details object is deployment
        specific.

     retry_after (optional)  A hint that indicates when the client MAY
        retry the request.  This field is meaningful when the decision is
        "retry" or "defer".  The value MAY be a number of seconds or a
        timestamp string, depending on the deployment profile.

     error_code (optional)  A machine readable string that indicates the
        type of error when the decision is "error".  Example values
        include "invalid_request", "unauthenticated", and "server_error".

     extensions (optional)  An object reserved for deployment specific
        fields that are not covered by the core model.  Extensions MUST
        NOT change the meaning of the decision field.



  Gaikwad                    Expires 1 June 2026                 [Page 18]


  Internet-Draft                    SOUTH                    November 2025


  8.2.  Allow Responses

     When the server authorizes the operation, it returns a response with
     decision set to "allow".  The server MAY include score and
     probability fields to expose internal evaluation metrics.

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "allow",
       "reason": "policy",
       "score": 0.98
     }

                     Figure 7: Deterministic allow response

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "allow",
       "reason": "boundary_region",
       "score": 0.62,
       "probability": 0.55
     }

                      Figure 8: Stochastic allow response

     From the client perspective, a stochastic allow is treated in the
     same way as a deterministic allow.  The probability field is optional
     metadata that may be logged or used for audit.

  8.3.  Deny Responses

     When the server does not authorize the operation, and the decision is
     considered stable with respect to current policy and context, it
     returns decision "deny".

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "deny",
       "reason": "policy",
       "score": 0.12
     }

                            Figure 9: Deny response

     Clients MUST NOT perform the requested operation after a deny
     decision.  The server MAY still include score and probability fields
     for diagnostic purposes, but these values do not change the meaning
     of the deny outcome.



  Gaikwad                    Expires 1 June 2026                 [Page 19]


  Internet-Draft                    SOUTH                    November 2025


  8.4.  Retry and Defer Responses

     When the server cannot authorize the request at this time, but the
     outcome may change later, it can return a decision of "retry" or
     "defer".

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "retry",
       "reason": "load",
       "retry_after": 30
     }

                      Figure 10: Retry response with hint

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "defer",
       "reason": "missing_context",
       "details": {
         "required_factor": "stronger_auth"
       }
     }

                  Figure 11: Defer response with step up hint

     Clients MUST treat retry and defer as not authorized for the current
     attempt.  The client MAY retry later or perform the indicated step,
     depending on local logic and deployment guidance.

  8.5.  Error Responses

     When the server cannot process the request, it returns a decision of
     "error".  In this case no authorization decision has been made.  The
     client MUST apply its own failure handling policy.

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "error",
       "error_code": "invalid_request",
       "reason": "malformed_subject"
     }

                           Figure 12: Error response







  Gaikwad                    Expires 1 June 2026                 [Page 20]


  Internet-Draft                    SOUTH                    November 2025


     Deployments SHOULD document how clients are expected to behave on
     error responses.  For example, some environments may require fail
     closed behavior, while others may accept fail open in development or
     testing stages.

  8.6.  Correlation and Logging

     Implementations SHOULD log request and response pairs for audit,
     debugging, and incident analysis.  The request_id field enables
     simple correlation.  Deployments may also use external correlation
     identifiers conveyed in the extensions field.

     SOUTH does not define log formats or retention policies.  Operators
     are responsible for applying local security and privacy requirements
     to any stored decision data.

  9.  Wire Protocol

     SOUTH defines a logical exchange between a client and a server: the
     client sends a request object and receives a response object.  The
     protocol is transport independent.  This document specifies a
     concrete HTTP binding that uses JSON as the serialization format.

  9.1.  Transport Independent Model

     In the abstract model, a client constructs a request object as
     described in Section 7, sends it to a server, and receives a response
     object as described in Section Section 8.  The binding between these
     objects and any underlying transport is left to deployment profiles.

     The following properties are expected of any SOUTH transport binding.


     *  The binding MUST preserve the request object and response object
        without modification, except for encoding.

     *  The binding MUST provide a way to carry authentication and
        integrity information for the client and server.

     *  The binding SHOULD support request correlation, for example by
        propagating the request_id.

     *  The binding SHOULD allow clients to distinguish between
        authorization decisions and transport or protocol errors.







  Gaikwad                    Expires 1 June 2026                 [Page 21]


  Internet-Draft                    SOUTH                    November 2025


  9.2.  HTTP Binding

     This section specifies an HTTP binding for SOUTH following HTTP
     semantics [RFC9110].  Other bindings may be defined in separate
     documents.  The HTTP binding uses JSON encoding for request and
     response bodies.

     Clients send SOUTH requests as HTTP POST messages to a server
     controlled endpoint.  The choice of path is a deployment concern.  A
     common pattern is a path such as /south/decision.

     A typical HTTP request has the following form.

     POST /south/decision HTTP/1.1
     Host: auth.example.com
     Content-Type: application/json
     Accept: application/json
     Authorization: Bearer eyJhbGciOi...

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "subject": {
         "id": "user-1234",
         "type": "user"
       },
       "action": {
         "type": "tool.invoke",
         "name": "database_query"
       },
       "object": {
         "id": "customers-table",
         "type": "database.table"
       }
     }

                        Figure 13: Example HTTP request

     The server responds with a JSON encoded SOUTH response object.

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
       "request_id": "550e8400-e29b-41d4-a716-446655440000",
       "decision": "allow",
       "reason": "policy",
       "score": 0.94
     }



  Gaikwad                    Expires 1 June 2026                 [Page 22]


  Internet-Draft                    SOUTH                    November 2025


                        Figure 14: Example HTTP response

     Clients and servers MAY use HTTP authentication mechanisms or carry
     credentials in headers, such as OAuth bearer tokens or DPoP proofs.
     SOUTH does not define any specific authentication scheme.

  9.3.  HTTP Status Codes

     In the HTTP binding, the HTTP status code and the SOUTH decision
     field carry different information.  The HTTP status code reflects the
     result of transport and parsing.  The decision field reflects the
     authorization outcome.

     Servers using the HTTP binding SHOULD follow these guidelines.


     200 OK  The request was successfully processed and a SOUTH response
        object is present in the body.  The decision field indicates the
        authorization outcome, such as allow, deny, retry, defer, or
        error.

     400 Bad Request  The HTTP message could not be parsed or the body
        could not be decoded as a SOUTH request object.  In this case, the
        server MAY return an error response body, but clients cannot rely
        on its presence.

     401 Unauthorized / 403 Forbidden  The client failed authentication or
        is not permitted to call the SOUTH endpoint.  The server MAY omit
        a SOUTH response object in this case.

     500 Internal Server Error and 5xx  The server encountered an internal
        error.  A SOUTH response object MAY be returned, but clients MUST
        treat the condition as a transport or processing failure, not as
        an explicit authorization decision.

     When the server returns 200 OK, clients SHOULD expect a valid SOUTH
     response object and MUST interpret the decision field as
     authoritative.  When the server returns non 2xx status codes, clients
     MUST apply local failure handling policies.

  9.4.  Timeouts and Retries

     Timeouts and connection failures are transport level events, not
     SOUTH decisions.  When a client does not receive a response within
     its configured timeout, the client MUST treat the attempt as if no
     decision was obtained.





  Gaikwad                    Expires 1 June 2026                 [Page 23]


  Internet-Draft                    SOUTH                    November 2025


     Clients MAY retry the SOUTH request, subject to local rate and
     backoff policies.  Retry behavior on transport failure is separate
     from retry behavior signaled by a SOUTH decision with value "retry".
     A server generated retry decision is explicit in the response body
     and may include a retry_after hint.

     Deployments SHOULD document how clients distinguish between these
     cases and how many retries are permitted before treating the failure
     as persistent.

  9.5.  Idempotence and Caching

     SOUTH requests are intended to be idempotent with respect to server
     policy state.  Sending the same request multiple times SHOULD NOT by
     itself change the policy decision, although stochastic behavior may
     cause different outcomes near the decision boundary.

     Clients and intermediaries MAY cache SOUTH responses when allowed by
     deployment policy.  Caching policies are out of scope for this
     document.  Any caching mechanism MUST ensure that sensitive data in
     responses is handled according to local security and privacy
     requirements.

  10.  Operational Modes

     SOUTH is intended as a small decision protocol that can be reused
     across different environments.  This section describes several
     operational modes.  These examples are illustrative and do not
     constrain implementations.

  10.1.  Agent and Tool Authorization

     In agent based deployments, a language model or agent runtime
     orchestrates tool calls, API invocations, or system level actions on
     behalf of a user.  Before executing a tool call, the agent runtime
     can call a SOUTH server to obtain an explicit authorization decision
     for the proposed action.

     A typical flow is:


     1.  The agent plans to call a tool or service, such as a database,
         filesystem, or external API.

     2.  The agent runtime constructs a SOUTH request that encodes the
         user identity as the subject, the tool invocation as the action,
         and the target resource as the object.  The context may include
         agent identifiers, chain identifiers, and environment details.



  Gaikwad                    Expires 1 June 2026                 [Page 24]


  Internet-Draft                    SOUTH                    November 2025


     3.  The SOUTH server evaluates the request using local policy, recent
         behavior, and any connected signals, and returns a decision.

     4.  The agent runtime executes the tool call only if the decision is
         allow.  For deny, retry, or defer, the runtime may adjust the
         plan, ask for user confirmation, or fail the step according to
         local rules.

     This mode separates alignment of model outputs from alignment of
     actions executed in the environment.  The agent may generate many
     candidate plans, but only those approved by SOUTH are executed.

  10.2.  Service to Service and Mesh Gateways

     In microservice and service mesh environments [SERVICE-MESH],
     services call each other over RPC or HTTP.  Gateways and sidecars
     often enforce authorization policies for incoming and outgoing calls.
     SOUTH can be used as an external decision service in this setting.

     A sidecar or gateway can:


     1.  Extract subject information from mutual TLS, tokens, or local
         identities.

     2.  Map the requested method and path to an action and object.

     3.  Construct a SOUTH request with optional context such as zone,
         workload identity, or rate information.

     4.  Call the SOUTH server and apply the returned decision to allow or
         block the upstream call.

     This mode centralizes authorization policy while keeping enforcement
     at gateways and sidecars.

  10.3.  Mail Transfer Agents

     Mail transfer agents (MTAs) often need to decide whether to accept,
     relay, or reject a message based on sender identity, recipient,
     content classification, and reputation signals.  SOUTH can be used as
     an authorization step between MTAs.

     In one deployment model:







  Gaikwad                    Expires 1 June 2026                 [Page 25]


  Internet-Draft                    SOUTH                    November 2025


     1.  When an incoming SMTP transaction reaches a receiving MTA, the
         MTA builds a SOUTH request capturing envelope sender, envelope
         recipient, client IP, authentication status, and local reputation
         scores as signals.

     2.  The MTA calls a SOUTH server and receives a decision such as
         allow, deny, or defer.

     3.  The MTA maps allow to message acceptance, deny to rejection, and
         defer to temporary failure codes such as 4xx.

     This mode lets operators encode complex spam and abuse policies
     outside the MTA core logic while keeping SMTP behavior standard.

  10.4.  SDN Controllers and NFV Service Chaining

     Software defined networking (SDN) controllers and network function
     virtualization (NFV) platforms often compute flow rules and service
     chains in a control plane, then program enforcement points such as
     switches or virtual functions.  SOUTH can be used as an external
     decision function for these control plane actions.

     A controller can:


     1.  Construct a SOUTH request where the subject is the control
         application or tenant, the action is a flow or service chain
         installation, and the object is the target path or chain.

     2.  Include context such as current load, link health, and security
         posture.

     3.  Call the SOUTH server to decide whether the proposed flow or
         chain is allowed.

     4.  Install the flow rules only when the decision is allow.  For
         deny, retry, or defer, the controller may choose alternate paths
         or delay provisioning.

     In this mode, SOUTH does not operate on individual packets.  It
     governs control plane actions that change forwarding behavior.

  10.5.  Kubernetes Admission and Scheduling

     In Kubernetes and similar orchestrators, controllers admit and
     schedule workloads based on policies and cluster state.  SOUTH can be
     used as an external decision point in admission [K8S-ADMISSION]
     webhooks or scheduler [K8S-SCHEDULER] extensions.



  Gaikwad                    Expires 1 June 2026                 [Page 26]


  Internet-Draft                    SOUTH                    November 2025


     Possible patterns include:


     *  An admission webhook builds a SOUTH request for each incoming
        object, such as a Pod or Job, with the subject as the user or
        service account, the action as create or update, and the object as
        the resource.  A deny decision maps to a failed admission.

     *  A scheduler plugin calls SOUTH before binding a Pod to a node,
        using context such as node labels, taints, and current load as
        part of the request.  A deny or defer decision can cause the
        scheduler to consider different nodes or queue the Pod.

     This mode allows operators to centralize certain policies that govern
     placement and resource access, while leaving Kubernetes semantics
     intact.

  10.6.  Library and Local Mode

     While SOUTH is defined as a wire protocol, some deployments may embed
     the decision logic as a library within an application or gateway.  In
     these cases, the application constructs the same request and response
     objects but calls a local function instead of sending messages over
     the network.

     Library mode can be useful for low latency paths or for environments
     that later plan to move to a remote SOUTH server.  The wire format
     defined in this document still provides value by giving a stable
     schema for testing, logging, and future interoperability.

  11.  Security Considerations

     SOUTH is an authorization decision protocol.  It does not replace
     transport security, authentication, or application specific checks.
     Incorrect deployment or interpretation can weaken system security.
     This section highlights key considerations.

  11.1.  Authentication and Integrity

     SOUTH assumes that both client and server identities are established
     by the surrounding transport and authentication mechanisms.  The
     protocol does not define its own authentication scheme.

     Deployments SHOULD:


     *  Use a secure transport such as TLS to protect SOUTH requests and
        responses from eavesdropping and tampering.



  Gaikwad                    Expires 1 June 2026                 [Page 27]


  Internet-Draft                    SOUTH                    November 2025


     *  Authenticate clients and servers using appropriate mechanisms,
        such as mutual TLS, bearer tokens, or DPoP proofs, depending on
        the environment.

     *  Bind subject information in the request to authenticated
        identities, so that a client cannot claim a different subject than
        the one established at the transport layer.

     If authentication or integrity is not enforced, an attacker may
     inject SOUTH requests, spoof subjects, or alter response decisions in
     transit.

  11.2.  Fail Open and Fail Closed Behavior

     SOUTH separates authorization decisions from transport and processing
     errors.  Clients must decide how to behave when no valid SOUTH
     response is available.

     In security sensitive environments, clients SHOULD fail closed when:


     *  No response is received within a timeout.

     *  The HTTP status code is not 2xx.

     *  The response body cannot be parsed as a SOUTH response object.

     Failing open in these situations can allow unauthorized actions when
     the SOUTH server is unavailable or under attack.  Any decision to
     fail open SHOULD be limited to controlled contexts such as
     development or explicit emergency recovery procedures.

  11.3.  Stochastic Decisions and Probing

     SOUTH allows stochastic behavior near the decision boundary.  While
     this can reduce predictability, it also introduces considerations for
     probing and analysis by an attacker.

     An adversary who can send many similar requests and observe allow or
     deny outcomes may estimate the underlying score function or
     probability mapping.  This can reveal where decision boundaries lie
     and may help the attacker craft more effective requests.

     Deployments SHOULD:


     *  Rate limit requests that reach the SOUTH server, especially near
        sensitive resources.



  Gaikwad                    Expires 1 June 2026                 [Page 28]


  Internet-Draft                    SOUTH                    November 2025


     *  Monitor for repeated probing patterns and adjust policy or block
        abusive clients.

     *  Consider limiting the precision of exported scores and
        probabilities, or omitting them entirely in high risk
        environments.

  11.4.  Logging and Policy Leakage

     SOUTH requests and responses can contain sensitive information,
     including subject identifiers, resource names, and diagnostic
     reasons.  Logs that capture this data may reveal internal structure,
     policy rules, or usage patterns to unauthorized parties.

     Operators SHOULD:


     *  Apply access control and retention policies to SOUTH logs.

     *  Avoid exposing detailed decision reasons or raw request objects to
        low privilege users or external systems.

     *  Consider redacting or aggregating fields that might reveal
        sensitive policy details or user behavior.

     In agent deployments, prompts and tool parameters may appear in
     action or object fields.  These can be sensitive and require the same
     care as application logs that contain prompts or user inputs.

  11.5.  Dependency and Bypass Risks

     SOUTH is only effective when its decisions are enforced.  If some
     code paths or tools bypass SOUTH, then policy enforcement becomes
     incomplete.

     Deployments SHOULD:


     *  Identify which actions and tools must be guarded by SOUTH and
        ensure that all corresponding paths call the SOUTH server or
        library consistently.

     *  Ensure that enforcement points, such as gateways, sidecars, or
        agent runtimes, cannot be bypassed by direct access to back end
        systems.

     *  Protect configuration that defines which actions require SOUTH
        decisions, to prevent downgrades.



  Gaikwad                    Expires 1 June 2026                 [Page 29]


  Internet-Draft                    SOUTH                    November 2025


     If attackers can reach underlying resources without going through
     SOUTH controlled enforcement points, the protocol provides no
     protection for those paths.

  11.6.  Denial of Service

     SOUTH servers can become a central dependency.  If a SOUTH server is
     unavailable or overloaded, clients may be unable to obtain decisions
     and may block or fail open, depending on configuration.

     An attacker may try to exhaust SOUTH server capacity by sending a
     large number of requests.  To mitigate this risk, deployments SHOULD:


     *  Apply rate limiting and admission controls to SOUTH endpoints.

     *  Use resource isolation and scaling mechanisms appropriate for
        critical infrastructure components.

     *  Define clear client behavior when SOUTH is unavailable, with a
        bias toward fail closed in sensitive environments.

  11.7.  Caching and Replay

     Caching SOUTH responses can reduce load and latency, but it
     introduces risks if cached decisions are reused beyond their valid
     context.

     Deployments that use caching SHOULD:


     *  Scope caches to specific subjects, objects, and actions, so that
        decisions are not applied across unrelated contexts.

     *  Use appropriate lifetimes for cached entries, especially when
        policy or context can change quickly.

     *  Protect any cache keys or stored responses against tampering and
        unauthorized access.

     Attackers who can replay old responses in place of fresh decisions
     may bypass updated policies.  Binding cached entries to request
     attributes and transport layer security is recommended.








  Gaikwad                    Expires 1 June 2026                 [Page 30]


  Internet-Draft                    SOUTH                    November 2025


  11.8.  Agent Specific Considerations

     When SOUTH is used in agent frameworks, an agent runtime may generate
     many candidate actions in response to a single user prompt.  SOUTH
     decisions influence which of these actions are executed in the
     environment.

     Operators SHOULD:


     *  Ensure that all environment changing actions, such as writes,
        deployments, and external calls, are covered by SOUTH or
        equivalent controls.

     *  Treat user prompts and agent generated plans as untrusted inputs
        and rely on SOUTH decisions to filter dangerous actions.

     *  Consider additional rate and scope constraints for agents that can
        generate many tool calls in a short time.

     SOUTH does not guarantee that an agent will choose the best or safest
     plan.  It only decides whether a particular requested action is
     within policy.  Other safety layers remain necessary.

  12.  Privacy Considerations

     SOUTH requests and responses can contain personal data and other
     sensitive information.  This section outlines privacy related
     considerations.  It does not replace local legal or regulatory
     obligations.

  12.1.  Data Types in SOUTH Messages

     A SOUTH request may carry subject identifiers, tenant identifiers,
     resource identifiers, locations, timestamps, device attributes,
     anomaly scores, and other contextual signals.  In agent deployments,
     action and object fields may also contain parts of prompts, tool
     parameters, or derived user data.

     A SOUTH response may contain reasons, error codes, and other
     diagnostics that reveal aspects of policy or user behavior.

     Operators SHOULD treat SOUTH messages and logs as sensitive data.
     They can reveal:


     *  Which users access which resources, at what times, and from which
        locations.



  Gaikwad                    Expires 1 June 2026                 [Page 31]


  Internet-Draft                    SOUTH                    November 2025


     *  The structure of internal resources such as tables, endpoints, or
        tools.

     *  Behavioral patterns, including anomaly scores and recent failures.

  12.2.  Data Minimization

     SOUTH defines a flexible schema for requests.  Deployments SHOULD
     apply data minimization principles when populating fields.

     In particular, clients SHOULD:


     *  Avoid sending full prompts or large payloads in the action or
        object fields when a compact identifier would suffice.

     *  Restrict subject attributes to those needed for policy evaluation,
        rather than copying entire user records.

     *  Limit context and signal fields to information that has clear
        value for the decision.

     Servers SHOULD discourage deployments that place unnecessary personal
     data into SOUTH messages and SHOULD document which fields are
     essential for common policies.

  12.3.  Retention and Access Control for Logs

     SOUTH implementations often log requests and responses for debugging,
     incident analysis, and compliance.  Such logs can form a detailed
     record of user and agent behavior.

     Operators SHOULD:


     *  Apply access controls to logs so that only authorized personnel
        and systems can view them.

     *  Define and enforce retention periods that are consistent with
        local policy and regulation.

     *  Consider pseudonymization or anonymization of identifiers when
        full fidelity is not needed.

     *  Avoid exporting raw SOUTH logs to third parties unless appropriate
        agreements and safeguards are in place.





  Gaikwad                    Expires 1 June 2026                 [Page 32]


  Internet-Draft                    SOUTH                    November 2025


  12.4.  Agent Context and Prompt Data

     When SOUTH is used with agents, the boundary between policy data and
     user content can be blurred.  Tools may carry pieces of prompts,
     documents, or messages in their parameters.  If these are copied into
     SOUTH requests, the authorization layer may receive more user data
     than necessary.

     To reduce risk, agent runtimes SHOULD:


     *  Represent tools and resources using stable identifiers where
        possible, rather than embedding full content.

     *  Keep free form user text out of SOUTH messages unless the policy
        explicitly depends on it.

     *  Treat any prompt fragments or document snippets that do enter
        SOUTH requests as sensitive and protect them in storage and
        transit.

     Policy authors SHOULD design rules that depend on coarse attributes
     or classifications rather than raw user content when possible.

  12.5.  Metadata and Inference Risks

     Even when raw content is not present, metadata can support inference
     about users and organizations.  For example, a sequence of SOUTH
     requests may reveal:


     *  Work schedules and time zones of specific users.

     *  Which internal projects or datasets are active.

     *  Which resources are considered sensitive or high value.

     Operators SHOULD consider these inference risks when deciding where
     SOUTH messages and logs are stored and who can access them.  In some
     cases, aggregating or sampling logs may be preferable to storing full
     detail.

  12.6.  Cross Border Transfers and Third Parties

     In some deployments, SOUTH servers may run in different regions or
     under different administrative domains than the calling services.
     This can create cross border data flows.




  Gaikwad                    Expires 1 June 2026                 [Page 33]


  Internet-Draft                    SOUTH                    November 2025


     Operators SHOULD:


     *  Verify that sending SOUTH requests to remote regions or third
        party providers is compatible with local data protection rules.

     *  Limit which fields are sent across boundaries, and prefer
        identifiers over raw content when possible.

     *  Ensure that contracts or agreements with third parties cover the
        handling of SOUTH messages and logs.

  12.7.  User Rights and Transparency

     In some jurisdictions, users have rights to access, correct, or
     delete personal data.  SOUTH by itself does not define any mechanisms
     to support these rights.

     Deployments that use SOUTH in systems with user facing obligations
     SHOULD:


     *  Treat SOUTH logs and configuration as part of the overall data
        inventory.

     *  Ensure that user facing documentation describes how authorization
        and decision logs are used.

     *  Provide procedures to locate and handle personal data that appears
        in SOUTH messages when required by law or policy.

  12.8.  Extensions and Profiles

     The extensions field in SOUTH requests and responses allows
     deployments to add custom data.  Unconstrained use of extensions can
     introduce privacy risks.

     Profiles that define extensions SHOULD:


     *  Document the purpose and data types of each extension clearly.

     *  Avoid placing raw user content into extensions when derived
        attributes would suffice.

     *  Apply the same security and privacy controls to extension fields
        as to core fields.




  Gaikwad                    Expires 1 June 2026                 [Page 34]


  Internet-Draft                    SOUTH                    November 2025


     Operators SHOULD periodically review extensions and remove those that
     are no longer necessary.

  13.  IANA Considerations

     This document registers a new media type for SOUTH request and
     response objects encoded in JSON.  The registration follows the
     guidelines in [RFC6838].

  13.1.  application/south+json Media Type

     The following media type registration is for the JSON encoding of
     SOUTH messages.

     Type name:  application

     Subtype name:  south+json

     Required parameters:  None

     Optional parameters:  None

     Encoding considerations:  Must be encoded as UTF-8.  See [RFC8259].

     Security considerations:  See the Security Considerations section of
        this document.

     Interoperability considerations:  None known.

     Published specification:  This document.

     Applications that use this media type:  SOUTH-aware clients and
        servers, agent frameworks, service meshes, authorization
        middleboxes, and schedulers requiring structured authorization
        decisions.

     Additional information:  None.

     Person & email address to contact for further information:  Madhava
        Gaikwad <gaikwad.madhav@gmail.com>

     Intended usage:  Common

     Restrictions on usage:  None

     Author:  See Author section of this document.

     Change controller:  IESG <iesg@ietf.org>, or as designated by future



  Gaikwad                    Expires 1 June 2026                 [Page 35]


  Internet-Draft                    SOUTH                    November 2025


        standardization work.

  14.  Normative References

     [RFC6838]  Freed, N., "Media Type Specifications and Registration
                Procedures", January 2013,
                <https://www.rfc-editor.org/rfc/rfc6838>.

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

     [RFC9110]  "HTTP Semantics", RFC 9110,
                <https://www.rfc-editor.org/rfc/rfc9110>.

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

     [RFC6749]  "The OAuth 2.0 Authorization Framework", RFC 6749,
                <https://www.rfc-editor.org/rfc/rfc6749>.

     [RFC9449]  "Demonstrating Proof-of-Possession at the Application
                Layer (DPoP)", RFC 9449,
                <https://www.rfc-editor.org/rfc/rfc9449>.

  15.  Informative References

     [NIST-ZT]  "Zero Trust Architecture", NIST Special
                Publication 800-207,
                <https://csrc.nist.gov/publications/detail/sp/800-207/
                final>.

     [K8S-ADMISSION]
                "Kubernetes Admission Controllers", Kubernetes
                Documentation Admission Controllers,
                <https://kubernetes.io/docs/reference/access-authn-authz/
                admission-controllers/>.

     [K8S-SCHEDULER]
                "Kubernetes Scheduler", Kubernetes
                Documentation Scheduler,
                <https://kubernetes.io/docs/concepts/scheduling-eviction/
                kube-scheduler/>.

     [SERVICE-MESH]
                "Istio Service Mesh Documentation", Istio
                Documentation Overview, <https://istio.io/latest/docs/>.




  Gaikwad                    Expires 1 June 2026                 [Page 36]


  Internet-Draft                    SOUTH                    November 2025


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

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

  Appendix A.  Example Flows

     This appendix provides example SOUTH message sequences for several
     deployment scenarios.  These examples are illustrative.  They do not
     constrain implementations.

  A.1.  Agent Tool Invocation

     In this flow a language model based agent wishes to call a database
     tool on behalf of a user.  The agent runtime consults SOUTH before
     making the tool call.

     Step 1: the user submits a prompt to the agent.  The agent decides
     that it needs to read a customer record and plans a tool invocation
     such as database_query.

     Step 2: the agent runtime constructs a SOUTH request.  The subject is
     the user, the action is the tool invocation, the object is the target
     table, and the context includes agent related information.
























  Gaikwad                    Expires 1 June 2026                 [Page 37]


  Internet-Draft                    SOUTH                    November 2025


     {
       "request_id": "req-001",
       "subject": {
         "id": "user-1234",
         "type": "user",
         "attributes": {
           "tenant": "tenant-42",
           "roles": ["reader"]
         }
       },
       "action": {
         "type": "tool.invoke",
         "name": "database_query",
         "parameters": {
           "operation": "select",
           "resource": "customers-table"
         }
       },
       "object": {
         "id": "customers-table",
         "type": "database.table"
       },
       "context": {
         "agent_id": "agent-runtime-1",
         "chain_id": "plan-abc",
         "ip": "198.51.100.23"
       }
     }

                 Figure 15: Agent tool invocation SOUTH request

     Step 3: the SOUTH server evaluates the request and returns a response
     that allows the action.

     {
       "request_id": "req-001",
       "decision": "allow",
       "reason": "policy",
       "score": 0.92
     }

                Figure 16: Agent tool invocation SOUTH response

     Step 4: the agent runtime proceeds with the database tool call.  If
     the decision had been deny or retry, the runtime would select a
     different plan or ask the user for guidance.





  Gaikwad                    Expires 1 June 2026                 [Page 38]


  Internet-Draft                    SOUTH                    November 2025


  A.2.  Service Mesh Gateway

     In this flow a service mesh sidecar consults SOUTH before forwarding
     an HTTP call from service A to service B.

     Step 1: service A sends an HTTP request to service B.  The request
     passes through a sidecar proxy.

     Step 2: the sidecar constructs a SOUTH request.  The subject is the
     identity of service A, the action encodes the HTTP method, and the
     object identifies the upstream service and path.

     {
       "request_id": "mesh-123",
       "subject": {
         "id": "service-A",
         "type": "service",
         "attributes": {
           "namespace": "payments"
         }
       },
       "action": {
         "type": "http.call",
         "name": "GET",
         "parameters": {
           "path": "/v1/charges"
         }
       },
       "object": {
         "id": "service-B",
         "type": "service",
         "attributes": {
           "namespace": "billing"
         }
       },
       "context": {
         "ip": "10.0.0.5",
         "zone": "zone-1"
       }
     }

                     Figure 17: Service mesh SOUTH request

     Step 3: the SOUTH server returns a deny decision.  The sidecar
     returns an HTTP error to service A and does not forward the request
     to service B.





  Gaikwad                    Expires 1 June 2026                 [Page 39]


  Internet-Draft                    SOUTH                    November 2025


     {
       "request_id": "mesh-123",
       "decision": "deny",
       "reason": "policy",
       "score": 0.08
     }

                     Figure 18: Service mesh SOUTH response

  A.3.  Mail Transfer Agent

     In this flow an incoming SMTP connection triggers a SOUTH check
     before message acceptance.

     Step 1: a sending MTA connects to a receiving MTA and issues an SMTP
     transaction with MAIL FROM and RCPT TO commands.

     Step 2: before accepting the message body, the receiving MTA
     constructs a SOUTH request.  The subject reflects the sending host
     and authenticated identity, the object is the recipient, and the
     signals include local reputation scores.

     {
       "request_id": "mta-42",
       "subject": {
         "id": "smtp-client-1",
         "type": "mta",
         "attributes": {
           "ip": "203.0.113.5",
           "helo": "mail.example.org"
         }
       },
       "action": {
         "type": "smtp.accept",
         "name": "deliver"
       },
       "object": {
         "id": "user@example.net",
         "type": "mailbox"
       },
       "signals": {
         "reputation_score": 0.21,
         "spf_pass": false
       }
     }

                          Figure 19: MTA SOUTH request




  Gaikwad                    Expires 1 June 2026                 [Page 40]


  Internet-Draft                    SOUTH                    November 2025


     Step 3: the SOUTH server returns a defer decision.  The MTA responds
     with a temporary failure code and may try again later or drop the
     connection according to local policy.

  Appendix B.  Signing Profiles

     SOUTH does not define its own authentication or signing format.  This
     appendix sketches profiles that combine SOUTH with existing
     mechanisms.  These descriptions are informative.

  B.1.  Mutual TLS Profile

     In the mutual TLS profile, client and server authentication rely on
     TLS [RFC8446].  The client presents a certificate and the server maps
     the certificate to a client identity.  The SOUTH request includes a
     subject that is derived from this identity.

     Properties:


     *  Integrity and confidentiality are provided by the TLS session.

     *  The subject in the SOUTH request is bound to the certificate
        presented on the connection.

     *  No additional signatures are required in the body.

     This profile is suitable inside data centers or service mesh
     environments where mutual TLS is already deployed.

  B.2.  OAuth 2.0 and DPoP Profile

     In this profile, the client authenticates to the SOUTH server using
     OAuth 2.0 bearer tokens [RFC6749] and may use DPoP [RFC9449] for
     proof of possession.

     A typical flow is:


     1.  The client obtains an access token from an authorization server,
         with a subject identifier and optional scopes.

     2.  The client sends SOUTH requests over HTTPS, including the token
         in an Authorization header and optional DPoP proof.

     3.  The SOUTH server validates the token and proof, then uses the
         subject and scopes as part of policy evaluation.




  Gaikwad                    Expires 1 June 2026                 [Page 41]


  Internet-Draft                    SOUTH                    November 2025


     The SOUTH subject should reflect the identity in the access token.
     Additional attributes may be derived from token claims.

  B.3.  Signed Request Bodies

     Some deployments may require explicit integrity protection for the
     SOUTH request body, separate from the transport.  One option is to
     use a JSON based signature format that covers the serialized request
     object.

     A simple pattern is:


     1.  Serialize the SOUTH request object as JSON.

     2.  Compute a signature over the JSON representation using a key
         associated with the client.

     3.  Attach the signature and key identifier in the extensions field
         or a separate header that is understood by the SOUTH server.

     The server verifies the signature before evaluating policy.  The
     exact signature format, key management, and canonical serialization
     rules are deployment specific and out of scope for this document.

  B.4.  Agent and User Binding

     In agent scenarios, a SOUTH request may represent a combined decision
     for a user and an agent runtime.  One deployment model uses two
     layers of proof.


     *  The outer transport authenticates the agent runtime itself, for
        example through mutual TLS or a client credential token.

     *  The inner subject reflects the user identity, which is carried in
        a user token or session credential.

     The SOUTH server can validate both identities and apply policy that
     depends on the combination.  For example, some tools may only be
     allowed when a specific agent acts on behalf of a given user group.

  Appendix C.  Rate and Load Aware Policies

     SOUTH is compatible with rate and load sensitive decision logic.
     This appendix outlines patterns for encoding such policies in the
     request and response objects.




  Gaikwad                    Expires 1 June 2026                 [Page 42]


  Internet-Draft                    SOUTH                    November 2025


  C.1.  Rate and Load Signals

     Rate and load information can appear in the context and signals
     fields of the SOUTH request.  The following fields are common
     examples.


     *  Per subject request rate over a recent window.

     *  Per resource or per tenant request rate.

     *  Current load on a target service or cluster.

     *  Anomaly or burst scores from external detectors.

     The exact schema for these fields is deployment specific.  A profile
     can define standard names such as subject_rate or service_load.

  C.2.  Decisions for Throttling and Shedding

     Rate and load aware policies can use SOUTH decisions to control
     throttling and shedding.

     Typical patterns include:


     *  allow when rates and load are below thresholds.

     *  deny when a request clearly exceeds policy or is part of an
        abusive pattern.

     *  retry when the policy suggests that the operation may succeed
        later, for example under transient load.

     *  defer when the system prefers queued or delayed execution rather
        than immediate failure.

     The reason field and optional retry_after extension can give further
     guidance to clients.  For example, a rate limited decision may
     suggest a backoff period.

  C.3.  Agent Specific Rate Policies

     Agents can generate many actions in a short time.  SOUTH can help
     enforce limits that prevent unbounded tool use or external calls.

     Examples include:




  Gaikwad                    Expires 1 June 2026                 [Page 43]


  Internet-Draft                    SOUTH                    November 2025


     *  Per user and per agent caps on tool calls per minute.

     *  Budgets for external API calls or high cost operations.

     *  Step up requirements when an agent exceeds typical behavior, such
        as additional user confirmation.

     These policies are expressed as functions of the rate related signals
     in the SOUTH request.  The SOUTH response then guides how the agent
     runtime adapts its plan.

  C.4.  Fairness and Multi Tenant Settings

     In multi tenant environments, rate and load policies affect fairness.
     SOUTH can help implement per tenant and per group quotas that prevent
     a single tenant from consuming a disproportionate share of capacity.

     A SOUTH server can:


     1.  Track usage counters per tenant or group.

     2.  Include current quota status in the decision logic.

     3.  Return deny or defer decisions when quotas are exceeded.

     The protocol itself does not enforce quotas, but it provides a
     structured place to apply quota aware decisions and to signal these
     decisions back to clients.

  Author's Address

     Madhava Gaikwad
     Independent Researcher
     Email: gaikwad.madhav@gmail.com
















  Gaikwad                    Expires 1 June 2026                 [Page 44]


