# drafts

name: draft-liu-dmsc-gw-requirements
rev: 00
title: Gateway Requirements for Dynamic Multi-agents Secured Collaboration
time: 2026-01-16T12:31:14Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-20T12:31:14Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127461+00:00
abstract:
This document discusses the requirements for introducing Gateways
   into Dynamic Multi-agents Secured Collaboration for better
   scalability, communication efficiency, and security etc.  This
   document also discusses the gaps of current hardware/software
   gateways that could not fulfil the task, so that a new kind of
   entity, e.g. DMSC Gateway, is needed.

full_text:
Network Working Group                                             B. Liu
Internet-Draft                                       Huawei Technologies
Intended status: Informational                           16 January 2026
Expires: 20 July 2026


  Gateway Requirements for Dynamic Multi-agents Secured Collaboration
                   draft-liu-dmsc-gw-requirements-00

Abstract

   This document discusses the requirements for introducing Gateways
   into Dynamic Multi-agents Secured Collaboration for better
   scalability, communication efficiency, and security etc.  This
   document also discusses the gaps of current hardware/software
   gateways that could not fulfil the task, so that a new kind of
   entity, e.g. DMSC Gateway, is needed.

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 20 July 2026.

Copyright Notice

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

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



Liu                       Expires 20 July 2026                  [Page 1]

Internet-Draft          DMSC Gateway Requirements           January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Functional Requirements of DMSC Gateway . . . . . . . . . . .   3
     2.1.  Delegated Agent Discovery . . . . . . . . . . . . . . . .   3
       2.1.1.  ID-based Agent Location Resolution  . . . . . . . . .   3
       2.1.2.  Task-based Agent Searching  . . . . . . . . . . . . .   4
     2.2.  Agent Communication Access Control  . . . . . . . . . . .   5
     2.3.  Information Distribution among Agents . . . . . . . . . .   6
       2.3.1.  Point-to-Point Distribution . . . . . . . . . . . . .   6
       2.3.2.  Pub/Sub . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Gap Analysis of Current Gateways  . . . . . . . . . . . . . .   7
     3.1.  Hardware form Gateways  . . . . . . . . . . . . . . . . .   7
     3.2.  Software form Gateways  . . . . . . . . . . . . . . . . .   7
   4.  DMSC Gateway Implementation Considerations  . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The Internet of Agents (IoA) is driving a shift in the communication
   model from the traditional host-to-host (or client-server) model to
   an Agent-to-Agent interaction model.

   One of the core characteristics of an Agent is autonomy, which
   consequently generates a demand for highly dynamic networking.
   Introducing DMSC Gateways that acting as a crucial intermediary layer
   is a good approach to enable efficient Agent discovery, information
   distribution among Agents, Quality of Service (QoS) and security
   assurance for Agent communications.

   This document discusses the requirements for introducing DMSC
   Gateways into Agent-to-Agent communications in terms of what benefits
   could be brought by the DMSC Gateways.

   In theory, Agents could be interconnected without any intermidiate
   Agent-specific gateways.  However, significant chanllenges (including
   issues of scalability, security, communication efficiency etc.) could
   rise if Agents just interconnect in a fully open and un-managed way.








Liu                       Expires 20 July 2026                  [Page 2]

Internet-Draft          DMSC Gateway Requirements           January 2026


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.  Functional Requirements of DMSC Gateway

2.1.  Delegated Agent Discovery

   In dynamic, heterogeneous, and variable-scale AI Agent environments,
   traditional discovery and addressing mechanisms based on static
   configuration or simple service names are no longer sufficient to
   meet the demand.

   The complexity of Agent communication requires the DMSC Gateway to
   provide higher levels of abstraction and intelligent services.  This
   subsection discusses two critical enhanced discovery and addressing
   mechanisms: Agent ID based addressing and task decomposition based
   Agent discovery.

2.1.1.  ID-based Agent Location Resolution

   In an Agent network, every Agent should be assigned a globally
   unique, persistent, and infrastructure-agnostic identifier, known as
   the Agent ID.  One of the core functions of the DMSC Gateway is to
   act as the resolver for this unified namespace, providing transparent
   addressing services for Agents:

   *  Agent ID Registration (Optional): Each Agent, upon startup, can
      delegate the ID registration task to the DMSC Gateway, thereby
      eliminating the need to specially implement a set of protocols and
      logic for communicating with a registration server.

   *  Addressing Request: When an Initiator Agent needs to communicate
      with a Target Agent, it does not need to know any network details
      of the target, such as its IP address.  It only needs to specify
      the Target Agent's ID in the communication request.

   *  Address Resolution: The DMSC Gateway receives the request and
      queries its local or external servers for the latest reachability
      information corresponding to the Agent ID.

   This mechanism offers the following benefits:





Liu                       Expires 20 July 2026                  [Page 3]

Internet-Draft          DMSC Gateway Requirements           January 2026


   *  Decoupling and Simplification: Agent developers can focus on their
      business logic without having to deal with network-layer IP
      address resolution, achieving complete decoupling between business
      logic and the communication infrastructure.

   *  Security and Policy Enforcement: The Gateway, acting as a central
      control point, can enforce security policies during the addressing
      resolution phase, such as verifying whether the initiator has
      permission to communicate with the target, thereby embedding
      security control at the very beginning of communication
      establishment.

2.1.2.  Task-based Agent Searching

   In many collaborative scenarios, the Initiator Agent may not know
   which specific Agent it needs to interact with but rather has a high-
   level task objective to accomplish.  This necessitates the DMSC
   Gateway providing an Intent-Based or Capability-Based discovery
   mechanism:

   *  Capability Registration (Optional): In addition to the Agent ID,
      each Agent must declare a set of "capabilities" it provides to the
      Gateway upon registration.  These capabilities can be described
      using structured attributes and should follow a common capability
      model schema.

   *  Task Declaration: The Initiator Agent submits a task request to
      the Gateway, such as "translate this Chinese document into
      English" or "analyze the buildings in this satellite image."  This
      request is a declaration of the desired outcome, rather than a
      call to a specific service.

   *  Task Decomposition and Capability Matching: The DMSC Gateway
      either contains or can access a task decomposition engine.  For
      complex tasks, the gateway can break them down into a series of
      sub-tasks (e.g., "document parsing" -> "Chinese-to-English
      translation" -> "format re-structuring").  Subsequently, the
      gateway searches its registration repository for Agents whose
      capability descriptions match each (sub) task.

   *  Agent Recommendation or Orchestration: The Gateway returns the
      list of discovered Agents that can satisfy the task requirements
      to the Initiator Agent, which then selects one.  In a more
      automated mode, the Gateway can directly act as an Orchestrator,
      routing the task request to the most suitable Agent, or even
      coordinating multiple Agents to collectively complete a complex
      task chain.




Liu                       Expires 20 July 2026                  [Page 4]

Internet-Draft          DMSC Gateway Requirements           January 2026


   Gateway-based mechanism offers the following benefits:

   *  Flexibility for Local Collaboration: For Agents to break away from
      statically orchestrated workflows or service call chains, they
      usually rely on the inference and orchestration capabilities of
      Large Language Models (LLMs).  However, in certain security/
      privacy-sensitive or highly localized scenarios, some Agents may
      only be available locally.  LLMs cannot discover these Agents and
      thus cannot orchestrate their tasks.  By using a locally deployed
      Gateway, local Agents, once their capabilities are registered, can
      be automatically included in the scope of task consideration.
      This allows Agent ecosystems that are only deployed locally to
      dynamically adapt and evolve.

   *  Increased Abstraction Level: The interaction between Agents is
      elevated from the level of "how to call" to "what needs to be
      done," significantly simplifying the programming model for complex
      tasks.  This is equivalent to an Agentic upgrade of the
      traditional TCP/IP Socket interface.

2.2.  Agent Communication Access Control

   The DMSC Gateway can implement fine-grained, context-based access
   control policies, ensuring that interactions only occur between
   authorized Agents and in permitted ways.  The execution of access
   control policies is based on context information across multiple
   dimensions:

   *  Identity-Based Access Control (IBAC): This is the most fundamental
      policy.  Policy rules can be defined as: "Agent A is allowed to
      communicate with Agent B," or "Agents belonging to 'Department X'
      are allowed to access Agents of 'Database Y'."  Before routing a
      message, the Gateway verifies whether the initiator ID and the
      target ID are within the allowed communication matrix.

   *  Capability-Based Access Control (CBAC): This policy introduces the
      dimensions of intent and capability on top of identity.  Policy
      rules can be more dynamic and semantic, for example: - Only Agents
      with the 'Financial Data Analysis' capability can access the 'Core
      Financial Database' Agent.  - An Agent requesting the 'Medical
      Diagnosis' capability must itself possess the capability tag for
      'Compliant Patient Data Handling' before it can call the
      corresponding diagnosis Agent.  This approach ensures that Agents
      are not only discoverable but are also used within the correct,
      authorized context.






Liu                       Expires 20 July 2026                  [Page 5]

Internet-Draft          DMSC Gateway Requirements           January 2026


   *  Attribute-Based Access Control (ABAC): This is a more generalized
      model that can make dynamic decisions by combining identity,
      capability, and environmental attributes (such as time,
      communication frequency, data sensitivity tags of the request,
      etc.).  For example: "Only Agents with 'High-Level' security
      certification, coming from a secure internal network, and
      operating during working hours, are allowed to call system
      administration Agents."

   Gateway-based mechanism offers the following benefits:

   *  Principle of Least Privilege: Through fine-grained policy
      definition, it is ensured that each Agent only possesses the
      minimum communication privileges necessary to complete its task,
      significantly reducing the attack surface.

   *  Dynamic Policy Enforcement: The Gateway, as the policy enforcement
      point, can intercept and evaluate every communication attempt in
      real-time, ensuring policy consistency in a dynamic environment.

   *  Enhanced Ecosystem Security: By shifting access control from the
      application layer down to the communication layer, a security
      perimeter near the edge is provided for the entire AI Agent
      ecosystem.  This manages risks at the source, thereby enhancing
      the security of the Agent network and simultaneously reducing the
      overall cost of protection.

2.3.  Information Distribution among Agents

   This section describes the information distribution of AI agents from
   two dimensions.  One dimension is the number of communication
   participants, which is divided into Point-to-Point Communication (2
   AI agents) and Group Communication (3 or more AI agents), and the
   section is divided into two sub-sections based on this dimension.

   This section specifically discusses the content that DMSC Gateways
   are involved in both cases.

2.3.1.  Point-to-Point Distribution

   In the Point-to-Point information distribution process, the typical
   processing performed by a gateway includes, but is not limited to:

   *  Application Layer Proxy (to facilitate monitoring/auditing of AI
      agent communication behavior, or to hide AI agent identity, etc.)

   *  Relay (to forward communication messages, making cross-domain
      communication easier, etc.)



Liu                       Expires 20 July 2026                  [Page 6]

Internet-Draft          DMSC Gateway Requirements           January 2026


   *  Traffic aggregation (to provide a tree-structured traffic
      regulation, improving communication efficiency).

2.3.2.  Pub/Sub

   One AI agent publishes the information to the gateway, and the
   gateway then distributes the information to the subscribing Agents
   based on their Subscribe status.  At the application layer, Pub/Sub
   is a common and efficient method of information distribution,
   especially suitable for large-scale group communication scenarios.

3.  Gap Analysis of Current Gateways

   Despite the existence of various forms of gateway devices and
   software in current networks, their primary design goals revolve
   around traditional network forwarding, network protocol translation,
   security isolation, and load balancing.  When faced with the unique
   requirements of AI Agent communication, these existing solutions
   exhibit significant shortcomings in both architecture and
   functionality.  This chapter will analyze why existing hardware and
   software gateways fail to meet the aforementioned Agent communication
   needs.

3.1.  Hardware form Gateways

   Common hardware gateway forms include, but are not limited to:
   network routers/switches, firewalls, dedicated protocol translation
   gateways, and broadband access equipment (BRAS/BNG).  These devices
   are typically deployed as dedicated hardware, focusing on processing
   at the Network and Transport layers.

   The core limitation of hardware gateways lies in their low processing
   layer.  They focus on network packets rather than Agent entities
   possessing identity and intent, and thus lack the necessary
   abstraction and computational power to handle high-level semantics
   and dynamic relationships.  Hardware gateways often utilize processor
   architectures, such as Network Processors (NPs), that are optimized
   for network-layer computation.  Consequently, they are difficult, if
   not impossible, to extend to support the high-level, semantic-based
   logical operations required for Agent communication.

3.2.  Software form Gateways

   Common software gateway forms include: API Gateways and Cloud Load
   Balancers.  These gateways are widely used in cloud-native
   environments and operate closer to the application layer, but their
   design paradigm remains tightly coupled with the architecture of
   services or API microservices.



Liu                       Expires 20 July 2026                  [Page 7]

Internet-Draft          DMSC Gateway Requirements           January 2026


   Software gateways are closer to meeting the requirements than
   hardware gateways, but their fundamental problem lies in the
   limitations of the fixed "service" paradigm.  They treat backends as
   relatively static services defined by APIs, rather than a dynamic
   collective of Agents possessing intent and collaborative
   capabilities.  Their security model and discovery mechanisms lack
   native support for the Agent's autonomy, dynamism, and capability
   semantics.

4.  DMSC Gateway Implementation Considerations

   TBD.

5.  Security Considerations

   TBD

6.  IANA Considerations

   This document has no IANA actions.

7.  Acknowledgements

   TBD

8.  Normative References

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

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

Author's Address

   Bing Liu
   Huawei Technologies
   No. 156 Beiqing Road
   Beijing
   China
   Email: leo.liubing@huawei.com







Liu                       Expires 20 July 2026                  [Page 8]


name: draft-zhang-dmsc-mas-communication
rev: 00
title: Security Analysis of Multi-agents Secured Communication and Limitations of Existing Protocols
time: 2026-01-16T13:44:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-20T13:44:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "AI safety/alignment", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:05.127464+00:00
abstract:
Multi-agents systems (MAS) increasingly cooperate through workflow,
   orchestrated, and mesh communication patterns.  While existing
   Internet protocols provide confidentiality and endpoint
   authentication, they were not designed for agent-native semantics
   such as dynamic identity, computation-bounded requests, context
   integrity, and intermediary trust.  This document analyzes security
   risks in agent communication and identifies limitations in widely
   deployed protocols (TLS, HTTP, MQTT,A2A and etc.) and developer
   framework (AutoGen and etc.).  This document intend to establish a
   common problem statement and gap analysis to inform future IETF
   standardization.

full_text:
DMSC Working Group                                              H. Zhang
Internet-Draft                                             China Telecom
Intended status: Standards Track                         16 January 2026
Expires: 20 July 2026


Security Analysis of Multi-agents Secured Communication and Limitations
                         of Existing Protocols
                 draft-zhang-dmsc-mas-communication-00

Abstract

   Multi-agents systems (MAS) increasingly cooperate through workflow,
   orchestrated, and mesh communication patterns.  While existing
   Internet protocols provide confidentiality and endpoint
   authentication, they were not designed for agent-native semantics
   such as dynamic identity, computation-bounded requests, context
   integrity, and intermediary trust.  This document analyzes security
   risks in agent communication and identifies limitations in widely
   deployed protocols (TLS, HTTP, MQTT,A2A and etc.) and developer
   framework (AutoGen and etc.).  This document intend to establish a
   common problem statement and gap analysis to inform future IETF
   standardization.

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 20 July 2026.

Copyright Notice

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






Zhang                     Expires 20 July 2026                  [Page 1]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions used in this document . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Core Communication Security Risks in MAS  . . . . . . . . . .   3
   5.  Limitations of Existing Protocols in Addressing Agent
           Communication Security  . . . . . . . . . . . . . . . . .   5
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   AI agents are autonomous software entities capable of interacting
   with other agents, tools, and services to perform multi-step
   reasoning and task execution.  Emerging MAS are deployed across
   heterogeneous infrastructures, often spanning administrative domains.
   Current Internet security mechanisms primarily protect communication
   channels and endpoints.  However, they do not fully address agent-
   specific security semantics, including dynamic identity, workload-
   based abuse, semantic context integrity, and trust in intermediaries.
   This document provides: [IoA].

   *  A brief threat analysis of agent communication based on
      collaboration patterns.

   *  A classification of core security risks.

   *  A gap analysis highlighting the limitations of protocols and
      developer framework.

   The scope of this document focuses on communication security for
   distributed AI agents, including:Agent-to-Agent (A2A), Agent-to-
   Orchestrator (A2O), Agent-to-Tool/Service (A2T).  It does not cover
   model training security, data governance, or ethical issues.



Zhang                     Expires 20 July 2026                  [Page 2]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


2.  Conventions used in this document

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

3.  Terminology

   The following terms are defined in [architecture] .

   *  Agent: An autonomous software entity capable of perception,
      planning, decision-making, and execution.

   *  DMSC: Dynamic Multi-agent Secured Collaboration.  The framework
      and infrastructure enabling secure and efficient collaboration
      among dynamic agents.

4.  Core Communication Security Risks in MAS

   MAS orchestration mechanisms include three primary patterns[IoA]:
   Workflows rely on predefined, linear, or conditional task sequences,
   exhibiting predictable sequential control flows and a pipeline
   topology; Hierarchical Planning utilizes a centralized orchestrator
   for task decomposition and intelligent routing, resulting in a star
   or tree topology with highly concentrated control and decision
   authority; and Multi-Agent Collaboration features a decentralized,
   peer-to-peer architecture where agents interact dynamically within a
   mesh or swarm topology, distributing both control flow and decision-
   making capabilities.

   From a security perspective, workflows face risks primarily related
   to context integrity, as communication is limited to adjacent agents,
   making the system vulnerable to payload injection or corruption
   despite clear identity boundaries.  Hierarchical Planning presents
   significant Single Point of Failure (SPOF) and Man-in-the-Middle
   (MITM) risks due to its centralized nature; a compromise of the
   orchestrator can lead to global impact, necessitating End-to-End
   Encryption (E2EE) and agent-payload binding.  Meanwhile, Multi-Agent
   Collaboration, characterized by fuzzy identity and trust boundaries,
   is susceptible to computational Denial of Service (DoS) attacks as
   well as context injection and pollution, requiring strict peer-level
   identity validation, context signing, and workload control.

   *  Identity and Trust Boundaries

   Agent-based systems rely on dynamically instantiated, short-lived
   entities whose identities are often assigned at runtime.  Unlike
   traditional services, agents do not map cleanly to long-lived hosts,



Zhang                     Expires 20 July 2026                  [Page 3]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


   domains, or organizational identities.  In collaborative or mesh
   topologies, agents may be created, delegated, or terminated on
   demand, and may act on behalf of other agents or users.  This
   introduces identity ambiguity and weak trust binding: it becomes
   unclear who an agent represents, what authority it has, and whether
   its identity is stable over time.

   *  Context Integrity and Semantic Consistency

   Agent communication is not limited to stateless requests; it often
   carries evolving conversational state, task context, intermediate
   reasoning artifacts, and shared memory objects.  While transport-
   layer security can protect messages in transit, it does not ensure
   that the semantic context remains intact across multiple hops,
   intermediaries, or storage layers.  In workflows and collaborative
   meshes alike, context can be truncated, reordered, injected, or
   selectively modified without cryptographic detection.  This creates
   risks of context poisoning, instruction injection, and silent
   manipulation of agent reasoning processes.

   *  Orchestrator and Broker Trust

   In hierarchical and brokered architectures, a central orchestrator or
   message broker mediates most or all communications.  This entity
   becomes a single point of failure and a powerful trust anchor.  If
   compromised, misconfigured, or simply overly privileged, the
   orchestrator can inspect, modify, suppress, or replay messages
   between agents.  Even when transport security is used, the
   orchestrator typically terminates connections and therefore has full
   access to plaintext.  This introduces MITM risks and undermines E2E
   security guarantees.

   *  Unpredictable Workload and Resource Exhaustion

   Agent interactions frequently involve expensive computation such as
   large-model inference, retrieval-augmented generation, or tool
   execution.  In collaborative and mesh settings, any peer may request
   high-cost operations from another agent.  Existing protocols do not
   account for computational asymmetry between requester and responder,
   nor do they provide mechanisms to express, negotiate, or enforce
   resource budgets.  As a result, agents are vulnerable to DoS attacks
   that exploit legitimate-looking but computationally expensive tasks.

   *  Architectural Amplification of Risk

   The above risks manifest differently across communication patterns.
   In sequential workflows, the primary concerns are identity binding
   and preservation of task context across hops.  In orchestrated



Zhang                     Expires 20 July 2026                  [Page 4]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


   systems, central control amplifies risks of message manipulation and
   single points of failure.  In decentralized collaboration, dynamic
   peer discovery and many-to-many communication exacerbate identity
   ambiguity, context pollution, and DoS exposure.  Together, these
   patterns demonstrate that agent communication security is not merely
   a transport problem, but an architectural and semantic one.

5.  Limitations of Existing Protocols in Addressing Agent Communication
    Security

   This section analyzes why commonly used communication protocols and
   frameworks—specifically TLS, HTTP/gRPC, the A2A protocol, and
   AutoGen—do not adequately mitigate the risks identified in Section 4.
   As highlighted in draft-li-dmsc-inf-architecture-01 [architecture],
   multi-agent systems require network infrastructures to support agent-
   centric identity management, capability-aware communication, and
   cross-domain collaboration—requirements that existing protocols fail
   to address, leading to resource exhaustion risks.  The focus is not
   on implementation flaws, but on structural gaps between protocol
   assumptions and the requirements of agent-based systems.

   *  Inadequate Support for Dynamic Agent Identity

   TLS, HTTP/gRPC with OAuth or TLS authentication mechanisms bind
   identity to endpoints, certificates, or client identifiers.  These
   constructs assume relatively stable entities such as servers, users,
   or devices.  They do not natively support ephemeral, software-defined
   agents that are created on demand, act under delegated authority, or
   represent composite roles.  While the A2A protocol introduces
   explicit AgentID fields, these identifiers are transmitted without
   mandatory cryptographic binding to trust anchors, delegation chains,
   or verifiable credentials.  In AutoGen, agent identity is typically
   managed at the application layer using tokens or configuration files,
   lacking standardized, interoperable identity semantics.
   Consequently, none of these protocols provide a robust mechanism to
   express who an agent is, whom it represents, and under what authority
   it operates.

   *  Lack of End-to-End Context Protection

   Existing protocols prioritize transport security rather than message-
   level or context-level integrity.  TLS ensures confidentiality and
   integrity only between adjacent endpoints; once a message is
   decrypted, any intermediary, broker, or application layer can modify
   the payload without detection.  HTTP/gRPC similarly protect the
   channel but do not require payload signing or semantic validation.
   A2A defines structured message objects but does not mandate E2E
   encryption or cryptographic signing of context elements.  AutoGen



Zhang                     Expires 20 July 2026                  [Page 5]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


   inherits the properties of its underlying transports, with no built-
   in enforcement of message or context integrity.  As a result, none of
   these systems can guarantee that conversational state, instructions,
   or task context have not been altered across multiple hops.

   *  Over-Privileged Orchestrators and Brokers

   In orchestrated and brokered architectures, existing protocols
   implicitly assume that the intermediary is fully trusted.  TLS
   termination at a gateway, HTTP reverse proxies, MQTT brokers, and
   agent orchestrators in both A2A-based and AutoGen systems all have
   access to plaintext messages.  This means that the orchestrator or
   broker can become an undetectable MITM, contradicting the distributed
   trust assumptions often made in multi-agent designs.

   *  Absence of Computation-Aware Communication Controls

   None of the evaluated protocols incorporate concepts of computational
   cost, resource budgeting, or workload fairness.  A request that
   triggers a trivial database lookup and one that initiates a multi-
   step reasoning chain over a large language model are treated
   identically at the protocol level.  MQTT quality-of-service levels
   ensure delivery semantics, not execution cost.  A2A and AutoGen allow
   agents to request complex tasks from peers without standardized
   mechanisms to declare, negotiate, or enforce limits on CPU, memory,
   inference time, or external tool usage.  This structural blind spot
   leaves agents vulnerable to resource exhaustion attacks that appear
   legitimate at the message layer.

   *  Mismatch Between Agent Architectures and Protocol Assumptions

   Collectively, TLS, HTTP/gRPC and MQTT were designed around service-
   oriented or message-oriented paradigms in which endpoints are
   relatively stable, intermediaries are trusted, and payload semantics
   are outside the protocol’s scope.  Agent-based systems violate these
   assumptions: identities are fluid, trust is contextual and delegated,
   messages carry evolving semantic state, and computation itself
   becomes an attack surface.  The result is a systematic gap: even when
   these protocols are correctly implemented, they cannot provide the
   E2E identity assurance, context integrity, intermediary minimization,
   and resource-aware controls required for secure multi-agent
   communication.









Zhang                     Expires 20 July 2026                  [Page 6]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


6.  Conclusion

   This document focuses on the communication security of multi-agent
   systems, systematically identifying critical gaps between existing
   communication protocols (such as TLS, HTTP/gRPC, MQTT, A2A, and
   AutoGen) and the security requirements of dynamic agent networks.
   Key issues identified include inadequate support for ephemeral and
   dynamic agent identities, lack of E2E semantic context protection,
   over-privileged intermediaries (brokers/orchestrators) leading to
   MITM risks, absence of computation-aware communication controls that
   render agents vulnerable to DoS attacks, and architectural
   amplification of these risks across different collaboration patterns
   (workflows, hierarchical planning, and decentralized mesh
   collaboration).  Collectively, these gaps demonstrate that secure
   communication in multi-agent systems is not merely a transport-layer
   problem but a systematic challenge involving identity semantics,
   context integrity, and resource management.

7.  Security Considerations

   This document suggests that secure agent communication requires a new
   class of protocol capabilities that extend beyond traditional network
   and application-layer security.  These include: (1) agent identity
   semantics that support ephemeral and delegatable identities
   independent of hosts or domains; (2) computation-aware communication
   mechanisms that allow agents to declare, negotiate, and enforce
   resource consumption limits, mitigating high-cost request abuse; (3)
   semantic context protection, through mandatory signing and optional
   encryption of payloads and context windows to preserve integrity
   across multiple hops; and (4) end-to-end trust in mediated
   topologies, enabling brokers or orchestrators to route messages
   without accessing or modifying their contents.  Together, these
   directions outline a path for future standardization: defining agent-
   aware identity and delegation models, specifying message- and
   context-level security envelopes, and integrating resource governance
   into communication protocols.

8.  IANA Considerations

   TBD

9.  Acknowledgement

   TBD

10.  Normative References





Zhang                     Expires 20 July 2026                  [Page 7]

Internet-Draft  Security Analysis of Multi-agents Secure    January 2026


   [architecture]
              Li, X. and A. W, "draft-li-dmsc-inf-architecture-01", 9
              January 2026.

   [IoA]      Idan, H., "Securing-Agentic-Applications-Guide-1.0", 28
              July 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/info/rfc2119>.

Author's Address

   Haodi Zhang
   China Telecom
   Tangxia Street, Tianhe District
   Guangzhou
   Guangzhou, 510000
   China
   Email: zhanghaodi@chinatelecom.cn






























Zhang                     Expires 20 July 2026                  [Page 8]


name: draft-guy-bary-stamp-protocol
rev: 00
title: Secure Task-bound Agent Message Proof (STAMP) Protocol
time: 2025-11-03T07:09:24Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-29T15:52:38Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127472+00:00
abstract:
The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
   cryptographically verifiable delegation and proof framework for AI-
   driven multi-agent systems. STAMP introduces task-bound access tokens
   and message-level proofs for agentic environments, binding tokens to
   specific user intents, tasks, and agent identities. STAMP tokens
   ensure that delegation, execution, and agent-to-agent communication
   comply with least-privilege and zero-trust security principles.
   STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
   possession (PoP) techniques, providing stronger security for dynamic,
   non-deterministic workflows involving autonomous agents.

full_text:
Network Working Group                                         Guy Bary
Internet-Draft                                      Intended status: Standards Track
Expires: October 29, 2025                                          April 27, 2025


       Secure Task-bound Agent Message Proof (STAMP) Protocol
                 draft-guy-bary-stamp-protocol-00

Abstract

   The Secure Task-bound Agent Message Proof (STAMP) protocol provides a
   cryptographically verifiable delegation and proof framework for AI-
   driven multi-agent systems. STAMP introduces task-bound access tokens
   and message-level proofs for agentic environments, binding tokens to
   specific user intents, tasks, and agent identities. STAMP tokens
   ensure that delegation, execution, and agent-to-agent communication
   comply with least-privilege and zero-trust security principles.
   STAMP interoperates with OAuth 2.0, GNAP, and modern proof-of-
   possession (PoP) techniques, providing stronger security for dynamic,
   non-deterministic workflows involving autonomous agents.

Status of This Memo

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

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

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

Copyright Notice

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

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


Table of Contents

   1. Introduction
   2. Terminology
   3. Motivation and Use Cases
   4. Protocol Overview
   5. STAMP Token Format
   6. Task Handling (Short vs Long Tasks)
   7. Agent-to-Agent Delegation
   8. Cryptographic Primitives
   9. Message Flows
   10. Comparison to OAuth2 + DPoP and GNAP
   11. Security Considerations
   12. Privacy Considerations
   13. IANA Considerations
   14. References

1. Introduction

   The rise of autonomous agents, especially AI-driven multi-agent
   systems, introduces complex delegation, communication, and
   authorization challenges. Agents often act independently, call peer
   agents, and dynamically decompose tasks into sub-tasks across system
   boundaries.

   Traditional delegation protocols such as OAuth 2.0 assume a static,
   client-server model and do not natively support task binding or
   dynamic delegation between autonomous entities. STAMP fills this gap
   by binding tokens not just to clients, but to *tasks*, and requiring
   proof-of-possession (PoP) for every resource request or agent-to-agent
   invocation.

   STAMP enables secure, verifiable delegation and task management,
   ensuring agents can operate under strict least-privilege conditions
   while maintaining a complete audit trail across workflows. In AI
   systems where actions are non-deterministic, STAMP provides an
   essential security and governance framework.

2. Terminology

   Agent:  
      A software entity that performs tasks on behalf of a user or
      another agent.

   Resource Owner (User):  
      The human end-user authorizing tasks to be performed.

   Authorization Server (AS):  
      The entity that issues STAMP tokens to agents after user
      authorization and consent.

   Resource Server (RS):  
      The service or agent that validates STAMP tokens and processes
      secured resource requests.

   Task:  
      A user-defined or agent-defined unit of work. Each STAMP token is
      bound to a specific task context via a unique task identifier.

   STAMP Token:  
      A JWT or CBOR/COSE token that cryptographically binds agent
      identity, task intent, authorized scopes, and proof-of-possession
      material.

   Proof-of-Possession (PoP) Key:  
      An ephemeral asymmetric key pair associated with a STAMP token,
      used to prove possession during resource requests.

   Task Integrity Digest (TID):  
      A cryptographic checksum representing the original user request or
      task definition to detect tampering.

3. Motivation and Use Cases

   Modern multi-agent systems exhibit dynamic task generation, subtask
   delegation, and high-volume agent-to-agent communication. Traditional
   bearer tokens are inadequate to secure these interactions because:

   - Agents may act outside their authorized task scopes if unchecked.
   - Tasks may mutate non-deterministically under LLM control.
   - Delegation chains may be ambiguous or unverifiable.
   - Revocation, replay prevention, and auditability are difficult.

   STAMP provides:

   - Task-bound authorization with explicit task IDs (TID).
   - PoP key binding per token to prevent token theft/replay.
   - Verifiable agent-to-agent delegation with audit chains.
   - Short-lived tokens for least-privilege and reduced attack window.
   - Support for OAuth 2.0 compatibility fallback when needed.

   Example real-world applications:

   - LLM-driven agent chains for travel planning, calendaring,
     procurement, where each sub-agent has task-specific rights.
   - Enterprise automation where delegated AI assistants interact with
     financial, CRM, and HR systems under zero-trust policies.
   - Multi-stage workflows with sensitive data (e.g., legal review,
     medical record access) requiring strict task-bound controls.

4. Protocol Overview

   STAMP enhances existing delegation protocols by introducing the
   following primitives:

   - **Task Binding**: Every token explicitly carries a unique task
     identifier (tid) and associated integrity digest (TID).
   
   - **PoP Binding**: Every token carries a confirmation key (cnf.jwk)
     representing an ephemeral public key for proof-of-possession
     during each authorized operation.

   - **Short- and Long-Task Modes**:  
     Tokens can be short-lived (single operation) or support long-lived
     workflows with refresh or continuation proofs.
   
   - **Delegation Model**:  
     Agents can request new subordinate STAMP tokens for peer agents,
     inheriting the original task ID but with subsetted scopes.

   - **Proof Mechanism**:  
     All API or agent communication is accompanied by a cryptographic
     signature using the PoP key over standardized request components,
     preventing replay and enforcing freshness.

   - **OAuth 2.0 / GNAP Compatibility**:  
     STAMP tokens can be obtained via OAuth 2.0 Authorization Code
     Grant flows, Device Code flows, GNAP grants, or other secure
     grant/consent models.

   STAMP defines the lifecycle of a task:

   - A user initiates a task.
   - The agent requests a STAMP token scoped to that task.
   - Each API request proves task continuity.
   - Task completion (or cancellation) ends token validity.

5. STAMP Token Format

   A STAMP token is a signed JWT (JSON Web Token) or a CBOR/COSE object
   issued by the Authorization Server (AS). It includes the following
   claims:

   - iss (Issuer):  
     The AS that issued the token.

   - sub (Subject):  
     Identifier of the resource owner (user).

   - aud (Audience):  
     Intended recipient(s) (e.g., Resource Servers).

   - tid (Task ID):  
     Unique identifier for the task context. Example: UUID v4.

   - agent (Agent ID):  
     Identifier of the requesting agent (e.g., client_id, DID).

   - scope:  
     List of authorized scopes for the agent under this task.

   - iat, nbf, exp:  
     Issued-at, not-before, and expiration timestamps.

   - jti (JWT ID):  
     Unique identifier for the token instance.

   - cnf (Confirmation Key):  
     Public key information (JWK or COSE key) binding the token to the
     agent's ephemeral PoP key.

   - parent (optional):  
     Identifier of the parent token if the token was obtained via
     delegation.

   - tid_integrity (optional):  
     A SHA-256 digest of the original user instruction (Prompt Integrity
     Digest), ensuring that the agent's actions align with the authorized
     task.

   Example (JWT payload):

   {
     "iss": "https://auth.example.com",
     "sub": "user12345",
     "aud": "https://api.example.com",
     "tid": "550e8400-e29b-41d4-a716-446655440000",
     "agent": "agent-A",
     "scope": "calendar:write email:send",
     "iat": 1700000000,
     "exp": 1700000600,
     "jti": "abc123",
     "cnf": {
       "jwk": {
         "kty": "EC",
         "crv": "P-256",
         "x": "...",
         "y": "..."
       }
     },
     "parent": "xyz7890",
     "tid_integrity": "SHA-256 checksum of task prompt"
   }

6. Task Handling (Short vs Long Tasks)

6.1 Short Tasks

   Short tasks involve immediate or short-lived operations that complete
   quickly (e.g., a single API call, minor data retrieval).

   For short tasks:

   - Token lifetimes are very brief (minutes or seconds).
   - Tokens are single-use or allow limited reuse.
   - Refresh tokens are unnecessary; the agent must request a new STAMP
     token for a new task.

   Best practices:

   - Use one STAMP token per short task.
   - Include strong timestamps and expiration (`exp` within 5-15 minutes).

6.2 Long Tasks

   Long tasks involve workflows spanning multiple steps or prolonged
   durations (e.g., background job orchestration, model training).

   For long tasks:

   - Token lifetime may be extended (hours), but short-lived tokens are
     preferable.
   - Agents can refresh tokens by reauthenticating or presenting valid
     continuation proofs.
   - Continuation tokens MUST maintain the same `tid` and `scope`, with a
     refreshed `exp` and new `jti`.
   - Session binding mechanisms (e.g., nonce confirmation, re-signing)
     SHOULD be used for additional security.

   Best practices:

   - Enforce periodic refresh and re-authorization checkpoints.
   - Invalidate all tokens related to a `tid` if the user revokes consent.

7. Agent-to-Agent Delegation

   In dynamic multi-agent systems, an agent (Agent A) may need to
   delegate a task or subtask to another agent (Agent B). STAMP
   formalizes this process to maintain verifiable authorization chains
   without privilege escalation.

7.1 Delegation Process

   1. Agent A holds a valid STAMP token (T_A) bound to Task ID (tid_A).
   2. Agent A requests a new delegated token (T_B) from the Authorization
      Server (AS), presenting T_A as proof.
   3. The AS verifies T_A, confirms delegation is permitted, and issues
      T_B:
      - Same `tid` (or subtask identifier if hierarchical).
      - New `agent` claim identifying Agent B.
      - Scoped to a subset of Agent A's original `scope`.
      - Includes `parent` field linking T_B to T_A's `jti`.
   4. Agent B uses T_B to perform its operations, providing PoP proofs
      per standard STAMP rules.

7.2 Delegation Constraints

   - The AS SHOULD enforce delegation policies such as:
     - Maximum delegation depth.
     - Approved agent identities.
     - Scope narrowing.

   - Agents SHOULD NOT forward tokens directly without AS mediation.

   - Audit systems MUST record delegation chains (`parent` field).

8. Cryptographic Primitives

8.1 Proof-of-Possession (PoP)

   - Agents MUST generate ephemeral ECDSA P-256 key pairs (or equivalent)
     for each STAMP token.
   - The public key is included in the token (`cnf.jwk`).
   - Each API call or message is signed using the private PoP key.

8.2 Message Signing

   - The signature covers:
     - HTTP Method
     - Request URI
     - Timestamp
     - Nonce (optional for replay protection)
     - `tid` (task identifier)

   - Signature methods SHOULD comply with [I-D.ietf-httpbis-message-signatures].

   - Example:
     ```
     Signature-Input: sig1=("@method" "@path" "tid" "date");alg=ecdsa-p256-sha256
     Signature: sig1=:base64(signature):
     ```

8.3 Algorithms

   - Mandatory to Implement:
     - ECDSA with SHA-256 (alg=ES256)
     - SHA-256 hashing
   - Recommended:
     - EdDSA (Ed25519) where available.
   - Deprecated:
     - RSA with SHA-1, HMAC without PoP binding.

8.4 Replay and Freshness

   - Include timestamps (`date`) and optional nonces in signatures.
   - Servers MUST reject requests with stale timestamps or reused
     nonces.

8.5 Key Management

   - PoP keys MUST be rotated per task or per significant token refresh.
   - Keys SHOULD be held in memory and cleared after use.

9. Message Flows

9.1 Token Acquisition Flow (via OAuth 2.0)

   1. User initiates a task via an agent (Agent A).
   2. Agent A requests authorization via OAuth 2.0 Authorization Code
      Grant or Device Code flow.
   3. Authorization Server (AS) authenticates the user and obtains
      consent.
   4. Agent A submits a PoP public key (cnf.jwk) during token request.
   5. AS issues a STAMP token bound to:
      - Agent A's identity
      - Task ID (tid)
      - Scope
      - PoP public key

9.2 Resource Access Flow

   1. Agent A prepares an HTTP request to the Resource Server (RS).
   2. Agent A signs the request using its PoP private key.
   3. Agent A includes:
      - Authorization: Stamp <STAMP Token>
      - Signature-Input and Signature headers (per HTTP Message
        Signatures draft)
   4. RS verifies:
      - Token validity (issuer, audience, scope, expiry)
      - Proof-of-Possession signature
      - Task ID match
      - Freshness (timestamp, optional nonce)
   5. Upon successful validation, RS authorizes the request.

9.3 Delegation Flow

   1. Agent A holds a valid STAMP token T_A.
   2. Agent A requests a delegated token T_B from AS for Agent B.
   3. AS issues T_B:
      - Same Task ID (tid)
      - Narrowed scopes
      - Parent link to T_A (parent field)
   4. Agent B uses T_B with its own PoP key to access resources.

9.4 OAuth 2.0 Fallback Mode

   - If a Resource Server does not recognize STAMP-specific proof
     headers, Agent A MAY present the STAMP token as a Bearer token.
   - This fallback is discouraged unless absolutely necessary.

10. Comparison to OAuth2 + DPoP and GNAP

   | Feature                     | OAuth2 + DPoP | GNAP   | STAMP       |
   |------------------------------|--------------|--------|-------------|
   | Token binding (PoP)          | Optional     | Yes    | Mandatory   |
   | Task identifier (tid)        | No           | No     | Yes         |
   | Agent-to-agent delegation    | Limited      | Partial| Full Chain  |
   | Non-determinism protection   | No           | No     | Yes         |
   | Short/long task modes        | Manual       | Partial| Built-in    |
   | OAuth2 compatibility fallback| N/A          | N/A    | Supported   |

11. Security Considerations

   - Tokens are short-lived and PoP-bound to limit exposure.
   - All requests are cryptographically signed for authenticity.
   - Task ID (tid) prevents token misuse across unrelated contexts.
   - Delegation chains are auditable via `parent` claims.
   - Revocation can occur at token or task level by revoking Task ID.

12. Privacy Considerations

   - Tokens should avoid including sensitive user data directly.
   - Task ID correlation across services should be minimized if not
     necessary.
   - PoP keys should be ephemeral and task-specific to reduce
     fingerprinting risks.
   - Servers should not expose token contents unnecessarily in errors.

13. IANA Considerations

   This document has no actions for IANA at this time.

14. References

   [RFC6749] D. Hardt, \"The OAuth 2.0 Authorization Framework\",
   October 2012.

   [RFC7519] M. Jones, \"JSON Web Token (JWT)\", May 2015.

   [RFC8705] B. Campbell, J. Bradley, N. Sakimura, \"OAuth 2.0 Mutual-
   TLS Client Authentication and Certificate-Bound Access Tokens\",
   February 2020.

   [RFC9449] D. Fett, J. Bradley, M. Jones, \"OAuth 2.0 Demonstrating
   Proof-of-Possession at the Application Layer (DPoP)\", November 2023.

   [RFC9635] J. Richer, \"Grant Negotiation and Authorization Protocol
   (GNAP)\", March 2024.

   [I-D.ietf-httpbis-message-signatures] C. Thomson, \"HTTP Message
   Signatures\", IETF Internet-Draft, work in progress.

Author's Address

   Guy Bary
   Independent
   Email: bgauryy@gmail.com


name: draft-abaris-aicdh
rev: 01
title: AI Content Disclosure Header
time: 2026-01-30T09:56:22Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-03T09:56:22Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:05.127476+00:00
abstract:
This document proposes a machine-readable Hypertext Transfer Protocol
   (HTTP) response header field, AI-Disclosure, to disclose the presence
   and degree of Artificial Intelligence (AI) generated or AI-assisted
   content in web responses.  The header is designed for compatibility
   with HTTP structured field syntax and provides metadata for user
   agents, bots, and archiving systems.  It supports layered disclosure
   strategies alongside human-readable and structured metadata formats.

full_text:
Independent Submission                                         D. Abaris
Internet-Draft                                    Individual Contributor
Intended status: Informational                           30 January 2026
Expires: 3 August 2026


                      AI Content Disclosure Header
                         draft-abaris-aicdh-01

Abstract

   This document proposes a machine-readable Hypertext Transfer Protocol
   (HTTP) response header field, AI-Disclosure, to disclose the presence
   and degree of Artificial Intelligence (AI) generated or AI-assisted
   content in web responses.  The header is designed for compatibility
   with HTTP structured field syntax and provides metadata for user
   agents, bots, and archiving systems.  It supports layered disclosure
   strategies alongside human-readable and structured metadata formats.

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

Copyright Notice

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

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





Abaris                    Expires 3 August 2026                 [Page 1]

Internet-Draft            AI-Disclosure Header              January 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   4.  Field Definition  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Field Syntax  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.2.  Field Keys  . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Semantics . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   As AI-generated content proliferates across the web, users
   [BV-Report], platforms, and regulators increasingly demand
   transparent disclosure of algorithmic involvement in content creation
   [PAI-Framework].  Existing approaches to disclosure (e.g., HTML
   disclaimers) lack machine-readability [GV-Prov], making automation,
   indexing, and compliance challenging.

   Regulatory initiatives like the EU Artificial Intelligence Act
   include transparency obligations for AI-generated or manipulated
   content, and the European Commission is developing a Code of Practice
   on marking and labelling AI-generated content to support compliance
   with those obligations EU-AI-Act [EC-CodePractice].  A lightweight,
   machine-readable HTTP signal can complement these efforts by enabling
   automated detection and disclosure in web delivery.

   This document defines the AI-Disclosure HTTP header field, providing
   a lightweight, machine-readable mechanism focused specifically on
   signaling the presence and mode of AI involvement in the generation
   of an HTTP response's content.  It utilizes HTTP Structured Fields
   [RFC9651] to offer a simple dictionary format directly within the
   HTTP response headers.

   The goal of AI-Disclosure is to offer a low-overhead, easily parsable
   signal primarily for automated systems like web crawlers, archiving
   tools, or user agents that may need a quick indication of AI usage
   without processing complex manifests.  This header is intended to be
   applied at the entire response level.



Abaris                    Expires 3 August 2026                 [Page 2]

Internet-Draft            AI-Disclosure Header              January 2026


   It is important to distinguish this mechanism from more comprehensive
   content provenance and authenticity frameworks like the Coalition for
   Content Provenance and Authenticity (C2PA) specification [C2PA-Spec].
   C2PA provides richer, cryptographically signed assertions about
   content provenance, potentially covering detailed creation/
   modification history and applying to specific regions within an asset
   ("Regions of Interest").  C2PA information can be linked via methods
   including the HTTP Link header [RFC8288] pointing to an associated
   manifest.

   AI-Disclosure can be seen as complementary to such systems within a
   layered disclosure strategy.  While C2PA offers strong, verifiable,
   and granular provenance, AI-Disclosure provides a simpler, advisory
   signal directly in the HTTP interaction for basic AI involvement
   awareness.  Systems requiring high assurance or sub-resource
   granularity should utilize frameworks like C2PA.

2.  Terminology

2.1.  Acronyms and Abbreviations

   AI: Artificial Intelligence

   HTTP: Hypertext Transfer Protocol

   C2PA: Content Provenance and Authenticity, refers to the
   specification developed by the Coalition for Content Provenance and
   Authenticity

3.  Conventions and Definitions

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

4.  Field Definition

   The AI-Disclosure field is defined as a Structured Field of type
   Dictionary, as described in [RFC9651].










Abaris                    Expires 3 August 2026                 [Page 3]

Internet-Draft            AI-Disclosure Header              January 2026


   +===============+==========+========+========+===========+=========+
   | Header Field  |Structured|Template|Protocol|Status     |Reference|
   | Name          |Type      |        |        |           |         |
   +===============+==========+========+========+===========+=========+
   | AI-Disclosure |Dictionary|(blank) |http    |provisional|[this    |
   |               |          |        |        |           |document]|
   +---------------+----------+--------+--------+-----------+---------+

                                 Table 1

5.  Field Syntax

   The AI-Disclosure field value MUST conform to the syntax for
   Dictionary structures defined in Section 3.2 of [RFC9651].  Each key
   in the dictionary conveys a distinct aspect of AI disclosure.

5.1.  Example

   AI-Disclosure: mode=ai-originated;
                  model="gpt-4";
                  provider="OpenAI";
                  reviewed-by="editorial-team";
                  date=@1745286896

5.2.  Field Keys

        +=============+========+==================================+
        | Key         | Type   | Description                      |
        +=============+========+==================================+
        | mode        | Token  | Indicates the nature of AI       |
        |             |        | involvement: none, ai-modified,  |
        |             |        | ai-originated, machine-generated |
        +-------------+--------+----------------------------------+
        | model       | String | Identifier of the AI model used  |
        |             |        | (e.g., gpt-4)                    |
        +-------------+--------+----------------------------------+
        | provider    | String | Organization providing the AI    |
        |             |        | system                           |
        +-------------+--------+----------------------------------+
        | reviewed-by | String | Entity or team who reviewed the  |
        |             |        | AI content                       |
        +-------------+--------+----------------------------------+
        | date        | Date   | Generation timestamp as a        |
        |             |        | numeric epoch value, conforming  |
        |             |        | to RFC9651.                      |
        +-------------+--------+----------------------------------+

                                  Table 2



Abaris                    Expires 3 August 2026                 [Page 4]

Internet-Draft            AI-Disclosure Header              January 2026


6.  Semantics

   The AI-Disclosure header field is an optional and advisory header
   providing information about the use of AI in generating the response
   content.  Its presence indicates voluntary disclosure by the server.
   Absence of the header implies nothing about AI usage.

   The meaning of the header is primarily defined by the mode key, whose
   possible values are described below:

    +===================+=============================================+
    | Mode Value        | Description                                 |
    +===================+=============================================+
    | none              | Indicates that AI was not used in the       |
    |                   | creation or substantive modification of the |
    |                   | content.                                    |
    +-------------------+---------------------------------------------+
    | ai-modified       | Indicates AI was used to assist with or     |
    |                   | modify content primarily created by humans. |
    |                   | The source material was not AI-generated.   |
    |                   | Examples include AI-based grammar checking, |
    |                   | style suggestions, or generating highlights |
    |                   | or summaries of human-written text.         |
    +-------------------+---------------------------------------------+
    | ai-originated     | Indicates the core content was initially    |
    |                   | generated by AI but subsequently reviewed,  |
    |                   | edited, or significantly guided by humans.  |
    |                   | This suggests human oversight for accuracy  |
    |                   | or appropriateness, even if the originality |
    |                   | for copyright purposes might be affected.   |
    +-------------------+---------------------------------------------+
    | machine-generated | Indicates the content was primarily or      |
    |                   | entirely generated by AI with minimal or no |
    |                   | human intervention or review post-          |
    |                   | generation.  AI may be responsible for      |
    |                   | substantive assertions or conclusions.      |
    +-------------------+---------------------------------------------+

                                  Table 3

   Other keys like model, provider, reviewed-by, and date provide
   optional, additional context about the AI model used, the provider,
   human review, or the generation time, respectively.

   Recipients should treat this header as informational only and refer
   to the Security Considerations (Section 7) regarding its
   trustworthiness.




Abaris                    Expires 3 August 2026                 [Page 5]

Internet-Draft            AI-Disclosure Header              January 2026


   *Note:* The AI-Disclosure header applies to the entire content of the
   HTTP response payload.  The ai-modified and ai-originated values
   indicate AI involvement, but this header does not provide information
   about specific locations or the exact nature of the partial
   involvement.  For expressing provenance information about specific
   parts of a resource, more comprehensive mechanisms such as C2PA
   [C2PA-Spec] should be used.  The distinction between ai-modified and
   ai-originated aims to address whether the foundational content was
   human or AI, reflecting concerns about originality and the nature of
   the transformation.  The distinction between ai-originated and
   machine-generated primarily reflects the level of human review or
   intervention post-generation.

7.  Security Considerations

   The AI-Disclosure field is intended to provide advisory metadata
   about AI-generated or AI-assisted content and does not include any
   form of integrity protection.  As such, the field can be trivially
   spoofed or altered by intermediaries unless the response is delivered
   over a secure transport such as HTTPS.

   Clients and intermediaries MUST NOT rely on the presence, absence, or
   value of the AI-Disclosure field for making security-critical
   decisions.  The field is not authenticated and SHOULD be treated as
   untrusted input.

   This document does not define any mechanisms for cryptographic
   verification or provenance validation of the header's content.
   Implementations that require trustworthy disclosure metadata SHOULD
   rely on additional application-layer integrity mechanisms or signed
   metadata systems, such as those defined by C2PA [C2PA-Spec].

8.  IANA Considerations

   IANA is requested to register the AI-Disclosure header field in the
   "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained
   at https://www.iana.org/assignments/http-fields/
   (https://www.iana.org/assignments/http-fields/), according to the
   procedures outlined in [RFC9110].












Abaris                    Expires 3 August 2026                 [Page 6]

Internet-Draft            AI-Disclosure Header              January 2026


   +==========+==========+===========+=========+==========+============+
   |Header    |Applicable|Status     |Reference|Structured|Notes       |
   |Field Name|Protocol  |           |         |Type      |            |
   +==========+==========+===========+=========+==========+============+
   |AI-       |http      |provisional|[this    |Dictionary|Discloses   |
   |Disclosure|          |           |document]|          |AI          |
   |          |          |           |         |          |involvement |
   |          |          |           |         |          |in content  |
   |          |          |           |         |          |creation    |
   +----------+----------+-----------+---------+----------+------------+

                                  Table 4

9.  References

9.1.  Normative References

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

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/rfc/rfc8288>.

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

   [RFC9651]  Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
              <https://www.rfc-editor.org/rfc/rfc9651>.

9.2.  Informative References

   [BV-Report]
              Big Valley Marketing, "AI Disclosure and Transparency:
              Closing the Trust Gap", November 2024,
              <https://bigvalley.co/wp-content/uploads/2024/11/BV-AI-
              Research-Report.pdf>.





Abaris                    Expires 3 August 2026                 [Page 7]

Internet-Draft            AI-Disclosure Header              January 2026


   [C2PA-Spec]
              Coalition for Content Provenance and Authenticity (C2PA),
              "C2PA Specification Version 2.1", July 2024,
              <https://c2pa.org/specifications/specifications/2.1/specs/
              C2PA_Specification.html>.

   [EC-CodePractice]
              European Commission, "Code of Practice on marking and
              labelling of AI-generated content", 27 January 2026,
              <https://digital-strategy.ec.europa.eu/en/policies/code-
              practice-ai-generated-content>.

   [EU-AI-Act]
              European Union, "Regulation (EU) 2024/1689 (Artificial
              Intelligence Act)", 13 June 2024,
              <https://eur-lex.europa.eu/eli/reg/2024/1689/oj>.

   [GV-Prov]  Hofmann, S., "Content Provenance and Disclosure
              Requirements for AI Generated Content on Digital and
              Traditional Media Platforms", 31 March 2025,
              <https://www.globalvoices.org.au/post/content-provenance-
              and-disclosure-requirements-for-ai-generated-content-on-
              digital-and-traditional-m>.

   [PAI-Framework]
              Partnership on AI, "PAI's Responsible Practices for
              Synthetic Media: A Framework for Collective Action", 27
              February 2023,
              <https://syntheticmedia.partnershiponai.org/>.

Acknowledgments

   The author thanks Michael Andrews from Teradata for helpful comments
   and feedback on early staging of this document.

Author's Address

   Dogu Abaris
   Individual Contributor
   Email: abaris@null.net











Abaris                    Expires 3 August 2026                 [Page 8]


name: draft-sz-dmsc-iaip
rev: 00
title: Intent-based Agent Interconnection Protocol at Agent Gateway
time: 2026-02-10T02:50:13Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-14T02:50:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127479+00:00
abstract:
This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

full_text:
DMSC Working Group                                                S. Sun
Internet-Draft                                                  ICT, CAS
Intended status: Standards Track                                X. Zhang
Expires: 13 August 2026                                        CNIC, CAS
                                                           February 2026


      Intent-based Agent Interconnection Protocol at Agent Gateway
                         draft-sz-dmsc-iaip-00

Abstract

   This document specifies the Intent-based Agent Interconnection
   Protocol (IAIP) operating at the Agent Gateways (AG), which defines
   the interaction mechanisms between AI Agents (at the Agent Domain)
   and the AG (at the Interconnection Services Domain).  This
   specification focuses on dynamic interconnection among agents based
   on semantic intent, rather than static network addressing alone.
   This protocols defines the mechanisms for agent registration via
   capability advertisement, Gateway Validation, Intent Resolution and
   Matching, Routing Decisions and Forwarding, enabling the discovery,
   selection and dispatching of intent queries based on agent
   capabilities and task requirements at AG.

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

Copyright Notice

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






Sun & Zhang              Expires 13 August 2026                 [Page 1]

Internet-Draft                    IAIP                     February 2026


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Problem Statement and Use Cases . . . . . . . . . . . . . . .   4
     4.1.  Limitations of Address-Based Static Interconnection . . .   4
     4.2.  Representative Use Case . . . . . . . . . . . . . . . . .   5
   5.  Function Components . . . . . . . . . . . . . . . . . . . . .   6
   6.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Message Formats . . . . . . . . . . . . . . . . . . . . . . .  10
   8.  Protocol Operation and Core Procedures  . . . . . . . . . . .  12
     8.1.  Illustrative Protocol Examples  . . . . . . . . . . . . .  12
       8.1.1.  Example A: Agent Registration (CAP_ADV) . . . . . . .  12
       8.1.2.  Example B: Intent Resolution Flow . . . . . . . . . .  12
       8.1.3.  Example C: Routing Feedback . . . . . . . . . . . . .  13
     8.2.  Agent Access Component (AAC) Operations . . . . . . . . .  13
       8.2.1.  Session Authentication and Integrity  . . . . . . . .  13
       8.2.2.  Ingress Validation  . . . . . . . . . . . . . . . . .  14
     8.3.  Local Capability Registry (LCR) Management  . . . . . . .  14
       8.3.1.  Profile Creation and Updates  . . . . . . . . . . . .  14
       8.3.2.  Lifecycle Maintenance . . . . . . . . . . . . . . . .  14
     8.4.  Intent Forwarding Routing Table (IFR) Decision Logic  . .  14
       8.4.1.  Candidate Retrieval . . . . . . . . . . . . . . . . .  14
       8.4.2.  Constraint-Based Filtering  . . . . . . . . . . . . .  15
       8.4.3.  Semantic Evaluation and Ranking . . . . . . . . . . .  15
       8.4.4.  Selection and Fallback  . . . . . . . . . . . . . . .  15
     8.5.  Forwarding and Loop Prevention  . . . . . . . . . . . . .  15
     8.6.  Reliability and Error Handling  . . . . . . . . . . . . .  15
     8.7.  Protocol Processing procedure at Agent Gateways . . . . .  16
   9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  18
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  18
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   12. Normative References  . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18







Sun & Zhang              Expires 13 August 2026                 [Page 2]

Internet-Draft                    IAIP                     February 2026


1.  Introduction

   The emergence of agentic networks marks a fundamental shift from
   static, address-based networking to semantic, intent-driven
   interactions.  Autonomous agents powered by advanced artificial
   intelligence models are capable of reasoning, planning, and executing
   tasks on behalf of users or other agents.  Interactions are
   increasingly expressed in terms of high-level objectives or natural
   language intents, rather than predefined service endpoints or static
   interfaces.

   Traditional networking and service discovery mechanisms assume that
   communication targets are identified by fixed addresses, names, or
   service identifiers.  These assumptions no longer hold in agentic
   environments, where the appropriate execution entity for a request
   may depend on semantic interpretation, contextual constraints, and
   dynamic system conditions.  As a result, routing decisions based
   solely on static addressing or preconfigured bindings are
   insufficient to support flexible and scalable agent collaboration.

   Intent-based interconnection addresses this gap by enabling the Agent
   Gateway to resolve and forward requests according to their semantic
   intent, rather than their destination address.  By decoupling request
   dispatch from rigid topology and static identifiers, intent-based
   interconnection allows autonomous agents to be dynamically
   discovered, selected, and invoked based on their advertised
   capabilities.

   This document introduces the Intent-based Agent Interconnection
   Protocol (IAIP) to provide a standardized mechanism for capability-
   based registration and validation, intent-aware discovery and routing
   at AG.  IAIP is designed to operate as an application-layer protocol
   for interconnection service domain, complementing existing transport
   and networking infrastructure without requiring changes to underlying
   transport protocols.

2.  Conventions

   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 <xref
   target="RFC2119"/>.

3.  Terminology

   AI Agent  An agent is a software or hardware entity with autonomous





Sun & Zhang              Expires 13 August 2026                 [Page 3]

Internet-Draft                    IAIP                     February 2026


      decision-making and execution capabilities, capable of perceiving
      the environment, acquiring contextual information, reasoning, and
      learning.

   Agent Gateway (AG)  A Functional Component in the Interconnection
      Service Domain that possesses the capbilities of agent
      registration, capbility authentication, intent resolution and
      estabilishing interconnection betweens agents.

   Intent  A declarative expression of a desired outcome.  In the
      intent-driven routing protocol, intent is represented at three
      conceptual layers:

      *  *Human Intent:*A high-level, possibly ambiguous expression
         originating from a human user or application (e.g., natural
         language input).  Human Intent is out of scope for the
         protocol.

      *  *Task Intent:*An abstract, task-oriented description that
         captures the objective of a request, independent of any
         specific agent, algorithm, or execution plan.

      *  *Intent Descriptor:*A structured, machine-interpretable
         representation of Task Intent used within IAIP for routing and
         dispatching decisions.

   Leader Agent (LA)  Agent who issues tasks and launches interactions.
      There should only be one Leader Agent in a complete task execution
      process.

   Partner Agent (PA)  Agent who accepts tasks and provides services.
      After Partner Agent receives a task from the Leader Agent, it
      executes and returns the execution result.

4.  Problem Statement and Use Cases

4.1.  Limitations of Address-Based Static Interconnection

   Existing network interconnection and gateway mechanisms are
   predominantly organized around static identifiers, such as network
   addresses, domain names, or service labels.  At the application and
   service-dispatch layer, these mechanisms assume that the
   functionality associated with a agent behind a gateway is stable,
   explicitly addressable and functionally static.  While effective for
   traditional client-server and microservice architectures, this
   assumption becomes increasingly inadequate for the dynamic
   interconnection required by agentic networks.




Sun & Zhang              Expires 13 August 2026                 [Page 4]

Internet-Draft                    IAIP                     February 2026


   First, traditional interconnection protocols provide limited support
   for expressing semantic intent.  High-level requests such as "analyze
   this dataset" or "resolve a billing issue" do not naturally
   correspond to a single predefined endpoint.  Encoding semantic
   meaning into static addresses or service names requires manual
   configuration and tight coupling between task requesters and service
   providers, which undermines flexibility and scalability.

   Second, static interconnection lacks adaptability to dynamic
   lifecycle of AI Agents.  In the Agent Domain, agents may be
   instantiated, fine-tuned, or deprecated rapidly based on
   computational load or task requirements.  Static bindings or name-
   based resolution mechanisms are generally unable to reflect real-time
   changes in agent's availability or intent-processing capacity,
   leading to service selection or routing dispatch failures.

   Third, existing protocols offer limited support for intent-aware
   resolution.  When a request arrives at the gateway without a specific
   destination address, traditional gateway have no mechanism to parse
   the intent and match it against a local registry of vector-based
   capabilities.  This behavior is misaligned with agentic workflows,
   where ambiguous or underspecified intents are common and may require
   clarification, delegation, or escalation to more generalist agents.

   These limitations motivate the need for an intent-driven
   interconnection protocol specifically at the Agent Gateway that can
   manage registration and routing based on semantic intent and
   dynamically advertised capabilities, rather than relying solely on
   fixed addresses or static identifiers.  This protocol addresses these
   challenges by transforming the gateway from a static packet forwarder
   into a semantic ingress/egress point, enabling establishing agent
   interconnection while maintaining compatibility with the
   Interconnection Service Domain.

4.2.  Representative Use Case

   The following example illustrates a typical use case of the Intent-
   based Agent Interconnection Protocol operating at the Agent Gateway.

   A Customer Service Dispatcher Agent, acting as the Leader Agent,
   transmits a user inquiry to the AG for intent resolution and service
   response.  Specialized Partner Agents (Billing, Technical Support,
   Sales) have previously registered their specific semantic domains
   with the AG.  For explicit queries like "My credit card was charged
   twice," the AG identifies a high-confidence semantic match and routes
   the request to the Billing Agent.  Upon completion, the AG relays the
   result back to the Leader Agent.  Conversely, when handling ambiguous
   inputs (e.g., "I'm having a bad experience") where semantic



Sun & Zhang              Expires 13 August 2026                 [Page 5]

Internet-Draft                    IAIP                     February 2026


   similarity scores fail to meet the required confidence threshold, the
   AG encapsulates the intent and forwards the intent to a Generalist
   Fallback Agent.  This mechanism ensures the request is constructively
   resolved via clarifying questions or human escalation, thereby
   preventing service failure.

5.  Function Components

   Figure 1 illustrates the interaction diagram between AI agent and
   Agent Gateway.

  [Agent Domain]                [Interconnection Service Domain]
     +-----------+      IAIP       +---------------+
     |  AI Agent | <-------------> | Agent Gateway | <---> [Core Router]
     +-----------+                 +---------------+

     Figure 1: Interaction Diagram between AI Agent and Agent Gateway

   To support the interaction with AI Agents, the AG MUST implement the
   following specific Functional Components within the Interconnection
   Service Domain.

   *  *Local Capability Registry (LCR):*The LCR maintains a dynamic
      database of attached Agents.  The function of LCR is to store the
      Capability Profile of each registered agent.  When an Agent sends
      the capability updating request, the LCR updates the mapping.

   *  *Agent Access Component (AAC):*The AAC serves as the termination
      point for the interconnection session between the AI Agent and the
      Agent Gateway.  The function of AAC is to manage authentication,
      maintain session lifecycle, and verify message integrity.  When an
      AI Agent initiates a connection or transmits a message, the AAC
      validates the agent's identity credentials and establishes the
      interconnection for message forwarding.

   *  *Intent Forwarding Routing (IFR):*The IFR serves as the dynamic
      routing decision engine within the Agent Gateway for forwarding
      intent-based requests.  Its primary function is to map normalized
      intent vectors-derived from incoming task semantics-to a set of
      eligible Partner agents.  Based on real-time capability matching
      scores, performance metrics (e.g., latency, success rate, and
      resource availability), and policy constraints, the IFR selects
      the optimal next-hop Partner agent for request forwarding.

6.  Protocol Overview

   The protocol functions in two primary phases.




Sun & Zhang              Expires 13 August 2026                 [Page 6]

Internet-Draft                    IAIP                     February 2026


   *  *Phase 1: Agent Registration & Capability Advertisement.*This
      phase establishes the trust domain and service mesh.  Both Leader
      Agents and Partner Agents MUST complete Identity Registration with
      the Agent Gateway (AG) to obtain the verifiable Agent Identity
      Code (AIC).  Following identity registration, Partner Agents (or
      agents acting in a service-provisioning role) MUST additionally
      perform Capability Advertisement to publish their functional
      profiles to the Local Capability Registry (LCR).

   *  *Phase 2: Intent-based Routing and Forwarding.*This phase
      establishes intent-based interconnection.  The Leader Agent
      submits its intent.  The AG resolves it against the LCR and IFR,
      selects suitable Partner Agents, and facilitates the connection.

   Figure 2 illustrates the updated two-stage processing pipeline
   between AI Agents and AG.



































Sun & Zhang              Expires 13 August 2026                 [Page 7]

Internet-Draft                    IAIP                     February 2026


  +--------------+      +------------------------+      +--------------+
  | Leader Agent |      |     Agent Gateway      |      | Partner Agent|
  |(Intent Init.)|      |(Interconnection Domain)|      |(Intent Exec.)|
  +------+-------+      +-----------+------------+      +-------+------+
         |                          |                           |
         |   Phase 1: Registration & Capability Advertisement   |
         |                          |                           |
         |--(1) Identity Reg ------>|                           |
         |      [ACP-IF-01]         |<------(1) Identity Reg ---|
         |                          |         [ACP-IF-01]       |
         |                          |                           |
         |                          |<------(2) Publish Cap ----|
         |                          |         [ACP-IF-06]       |
         |                          |                           |
         |                          |---(3) Sync to ADMgF ------|
         |                          |---(4) Trust Check (DTMgF)-|
         |                          |                           |
         |       Phase 2: Intent-based Routing & Execution      |
         |                          |                           |
         |--(5) Submit Intent ----->|                           |
         |      [Signed Vector]     |                           |
         |                          |---(6) Resolve Intent -----|
         |                          |       Match & Filter      |
         |                          |                           |
         |<-----(7) Cand. List -----|                           |
         |      [Ranked + Sig]      |                           |
         |                          |                           |
         |-(8) Verify & Select -----|                           |
         |                          |                           |
         |==========(9) Routing and Execution =================>|
         |          [E2E via ACP-IF-08/09]                      |
         |======================================================|

               Figure 2: Two-Stage Processing Flow of IAIP

   *Phase 1: Agent Registration & Capability Advertisement*

   This stage is the prerequisite for any agent participation.  It
   involves Identity Registration (mandatory for all) and Capability
   Publication (mandatory for service providers).  The steps are as
   follows:










Sun & Zhang              Expires 13 August 2026                 [Page 8]

Internet-Draft                    IAIP                     February 2026


   *  *Step1:*Identity Registration (Leader & Partner).  Any Agent
      (whether Leader or Partner) MUST register its identity with the
      Agent Gateway using the ACP-IF-01 interface (between AIMF in the
      agent and AIMgF in the AG).  This establishes a verifiable Agent
      Identity Code (AIC) and exchanges cryptographic credentials
      required for future intent signing (Leader) or service execution
      (Partner).

   *  *Step2:*Capability Publication (Partner Agent).  The Partner Agent
      publishes a structured capability description (e.g., supported
      task types, performance bounds, resource constraints) to the Agent
      Gateway via the ACP-IF-06 interface (ADMF <-> ADMgF).  Note: If a
      Leader Agent also wishes to serve tasks, it MUST also perform this
      step.

   *  *Step3:*Synchronization to Interconnection Service Domain.  The
      Agent Gateway forwards the capability description to the Agent
      Description Management Function (ADMgF) in the Interconnection
      Service Domain.  ADMgF persists the data and synchronizes it to
      the Agent Discovery Function (ADF) for indexing.

   *  *Step4:*Trust Scope Enforcement.  The Domain Trust Management
      Function (DTMgF) applies domain federation policies to determine
      whether the registered Agent is authorized to operate within the
      specific trust domain.  Only authorized capabilities are made
      queryable via ADF.

   *Phase 2: Intent-based Routing and Forwarding*

   This stage is triggered when a registered Leader Agent submits a
   semantic intent request.  The Agent Gateway resolves and routes the
   intent to eligible Partner Agents.  The steps are as follows:

   *  *Step5:*Intent Submission.  The Leader Agent sends a signed
      semantic intent vector to the Agent Gateway.  The signature MUST
      be generated using the credentials established in Step 1.  The
      payload contains abstract task semantics.

   *  *Step6:*Intent Resolution and Candidate Matching.  The Agent
      Gateway invokes the ACP-IF-07 interface to query the ADF.  The IFR
      (Intent Forwarding Routing Table) performs semantic matching
      against the LCR, filtering based on trust scopes, and ranking
      candidates.

   *  *Step7:*Candidate Agents Return.  The Gateway returns a ranked
      list of eligible Partner Agents to the Leader Agent.





Sun & Zhang              Expires 13 August 2026                 [Page 9]

Internet-Draft                    IAIP                     February 2026


   *  *Step8:*Leader-side Verification and Selection.  The Leader Agent
      verifies the gateway's signature and selects one or more Partners
      based on local policy.

   *  *Step9:*Routing and Execution.  The Leader Agent establishes a
      direct end-to-end session with the selected Partner Agent(s) using
      ACP-IF-08 for point-to-point interaction, or ACP-IF-09 for
      grouping-mode collaboration.  All task payloads are transmitted
      over this encrypted channel.

7.  Message Formats

   This section specifies the binary structure of IAIP messages.  The
   protocol uses a Type-Length-Value (TLV) design to ensure
   extensibility.

  +--------------------------------------------------------------------+
  |                      IAIP Message (TLV-based)                      |
  +--------------------------------------------------------------------+
  |                                                                    |
  |  +-------------------+------+-----------------------------------+  |
  |  | Type              | Len  | Value                             |  |
  |  +-------------------+------+-----------------------------------+  |
  |  | Common Header TLVs                                           |  |
  |  +-------------------+------+-----------------------------------+  |
  |  | VERSION           | 1    | Protocol version                  |  |
  |  | MSG_TYPE          | 1    | INTENT_REQ / CAP_ADV / ERROR      |  |
  |  | MSG_ID            | var  | Unique message identifier         |  |
  |  | SENDER_ID         | var  | Source agent / router ID          |  |
  |  | RECEIVER_ID       | var  | Target agent / router ID          |  |
  |  | TIMESTAMP         | 8    | Unix time / logical time          |  |
  |  | TTL / EXPIRY      | 4    | Validity / hop limit              |  |
  |  | CORRELATION_ID    | var  | Request-response correlation      |  |
  |  | INTEGRITY_TAG     | var  | MAC / signature                   |  |
  |  +-------------------+------+-----------------------------------+  |
  |                                                                    |
  |  +-------------------+------+-----------------------------------+  |
  |  | Payload TLVs (depend on MSG_TYPE)                            |  |
  |  +-------------------+------+-----------------------------------+  |
  |                                                                    |
  |  -- CAPABILITY ADVERTISEMENT (CAP_ADV) --------------------------  |
  |  | AGENT_ID          | var  | Advertising agent identifier      |  |
  |  | ENDPOINT          | var  | Network / logical endpoint        |  |
  |  | FUNC_DESC         | var  | Functional descriptors            |  |
  |  | INTENT_DOMAINS    | var  | Supported intent types            |  |
  |  | IO_SCHEMA         | var  | Input/output constraints          |  |
  |  | PERF_METRICS      | var  | Latency, success rate, etc.       |  |
  |  | RESOURCE_LIMITS   | var  | Token / compute budget            |  |



Sun & Zhang              Expires 13 August 2026                [Page 10]

Internet-Draft                    IAIP                     February 2026


  |                                                                    |
  |  -- CAPABILITY REFRESH (CAP_REFRESH) ----------------------------  |
  |  | AGENT_ID          | var  | Agent identifier                  |  |
  |  | TTL_UPDATE        | 4    | Extended lifetime                 |  |
  |  | METRIC_DELTA      | var  | Updated performance metrics       |  |
  |                                                                    |
  |  -- CAPABILITY DEREGISTER (CAP_DEREGISTER) ----------------------  |
  |  | AGENT_ID          | var  | Agent identifier                  |  |
  |  | REASON_CODE       | 2    | Deregistration reason             |  |
  |  | EFFECTIVE_TIME    | 8    | Time of effect                    |  |
  |                                                                    |
  |  -- INTENT REQUEST (INTENT_REQ) ---------------------------------  |
  |  | OBJECTIVE         | var  | Task objective                    |  |
  |  | CONSTRAINTS       | var  | Preferences / limits              |  |
  |  | CONTEXT           | var  | Context metadata                  |  |
  |  | PRIORITY          | 1    | Request priority                  |  |
  |  | BUDGET            | var  | Cost / token budget               |  |
  |  | PRIVACY_FLAG      | 1    | Intent privacy level              |  |
  |  | OBFUSCATED_INTENT | var  | Encrypted / masked intent         |  |
  |                                                                    |
  |  -- ROUTE DECISION / INTENT RESPONSE ----------------------------  |
  |  | TARGET_AGENT_LIST | var  | Selected target agent(s)          |  |
  |  | MATCH_CONFIDENCE  | var  | Similarity / rank score           |  |
  |  | FORWARDING_INFO   | var  | Next-hop / endpoint               |  |
  |  | FALLBACK_INDIC.   | 1    | Fallback used?                    |  |
  |                                                                    |
  |  -- ROUTING FEEDBACK --------------------------------------------  |
  |  | OUTCOME           | 1    | Success / failure                 |  |
  |  | OBSERVED_LATENCY  | var  | Execution latency                 |  |
  |  | OBSERVED_COST     | var  | Resource usage                    |  |
  |  | ERROR_INFO        | var  | Error details                     |  |
  |                                                                    |
  |  -- ERROR MESSAGE -----------------------------------------------  |
  |  | ERROR_CODE        | 2    | Error identifier                  |  |
  |  | DIAGNOSTIC        | var  | Human-readable info               |  |
  |  | RETRY_AFTER       | 4    | Backoff hint                      |  |
  |                                                                    |
  |  -- SECURITY EXTENSION (SECURITY_EXT) ---------------------------  |
  |  | AUTHN_INFO        | var  | Certificate / token ref           |  |
  |  | AUTHZ_SCOPE       | var  | Authorization scope               |  |
  |  | NONCE             | var  | Anti-replay                       |  |
  |  | SIGNATURE / MAC   | var  | Integrity protection              |  |
  |  | ENCRYPTION_CTX    | var  | Intent confidentiality ctx        |  |
  |                                                                    |
  +--------------------------------------------------------------------+

                      Figure 3: IAIP message format




Sun & Zhang              Expires 13 August 2026                [Page 11]

Internet-Draft                    IAIP                     February 2026


   The table above summarizes the field requirements.  Key fields
   include:

   *MSG_TYPE*  Identifies the payload type (e.g., 0x01: CAP_ADV, 0x02:
      INTENT_REQ).

   *TTL / EXPIRY*  Time-To-Live logic depending on message type.  For
      routing messages (INTENT_REQ), this represents the hop limit.  For
      registration messages, this represents the validity duration in
      seconds.

   *OBJECTIVE (in INTENT_REQ)*  The semantic vector or structured
      description of the task.

   *RESOURCE_LIMITS (in CAP_ADV)*  Specifies operational constraints,
      including token budget per request and computational cost.

   *FALLBACK_INDIC. (in RESPONSE)*  Flag indicating if a generalist
      fallback agent was used (0x01) or a direct match was found (0x00).

8.  Protocol Operation and Core Procedures

   This section specifies the normative processing behavior of the Agent
   Gateway (AG), organized by the functional components defined in
   Section 5.  The Agent Access Component (AAC) handles ingress
   connectivity and security; the Local Capability Registry (LCR)
   manages state; and the Intent Forwarding Routing Table (IFR) executes
   decision logic.

8.1.  Illustrative Protocol Examples

   The examples in this section are provided for illustration only and
   are non-normative.

8.1.1.  Example A: Agent Registration (CAP_ADV)

   A Partner Agent registers its translation service with cost
   constraints.

[Common Header] MSG_TYPE =
          CAP_ADV SENDER_ID = "agent-trans-01", TTL/EXPIRY = 3600 [Payload],
          FUNC_DESC = "service:translation; lang:en-to-zh", RESOURCE_LIMITS =
          "max_tokens=2048", SECURITY_EXT = "(signature bytes...)"

8.1.2.  Example B: Intent Resolution Flow

   *Step 1: Leader Agent sends Intent Request*




Sun & Zhang              Expires 13 August 2026                [Page 12]

Internet-Draft                    IAIP                     February 2026


[Common Header] MSG_TYPE =
          INTENT_REQ SENDER_ID = "leader-agent-007", MSG_ID = "req-1024"
          [Payload], OBJECTIVE = "(vector: [0.12, 0.95, ...])", BUDGET =
          "100"

   *Step 2: Gateway returns Candidate List (Response)*
   The AG finds two matching agents.  The first one is a direct match,
   so Fallback Indicator is 0.

[Common Header] MSG_TYPE =
          RESPONSE RECEIVER_ID = "leader-agent-007", CORRELATION_ID =
          "req-1024" [Payload], TARGET_AGENT_LIST = [1] "agent-trans-01"
          (Conf: 0.92, Endpoint: "10.0.1.5:8080"), [2] "agent-trans-03" (Conf:
          0.85, Endpoint: "10.0.1.8:8080"), FALLBACK_INDIC. = 0x00 (No
          Fallback)

8.1.3.  Example C: Routing Feedback

   After execution, the Leader Agent reports performance metrics back to
   the AG to update the LCR's dynamic scores.

[Common Header] MSG_TYPE =
          ROUTING_FEEDBACK SENDER_ID = "leader-agent-007" [Payload], OUTCOME =
          1 (Success), OBSERVED_LATENCY = 250 (ms), OBSERVED_COST = 50
          (tokens)

8.2.  Agent Access Component (AAC) Operations

   The AAC serves as the termination point for the interconnection
   session.  It MUST intercept all incoming IAIP messages before they
   reach the LCR or IFR.

8.2.1.  Session Authentication and Integrity

   Upon receiving any message, the AAC MUST perform the following
   validations:

   *  *Identity Verification:* Validate the SENDER_ID against the
      credentials provided in the AUTHN_INFO TLV or the underlying
      transport session (e.g., mTLS).
   *  *Message Integrity:* Verify the INTEGRITY_TAG or SIGNATURE.  If
      verification fails, the AAC MUST drop the message and return an
      ERROR with code AUTH_FAILED.








Sun & Zhang              Expires 13 August 2026                [Page 13]

Internet-Draft                    IAIP                     February 2026


8.2.2.  Ingress Validation

   The AAC acts as the first line of defense.  It MUST validate the
   syntax of Common Header fields (e.g., VERSION, MSG_TYPE).  Malformed
   packets MUST be rejected immediately to protect the internal IFR
   engine.

8.3.  Local Capability Registry (LCR) Management

   The LCR maintains the dynamic database of attached Agents.  It
   processes capability management messages validated by the AAC.

8.3.1.  Profile Creation and Updates

   When the AAC forwards a CAP_ADV message, the LCR MUST:

   1.  Extract the AGENT_ID and map it to the provided ENDPOINT.

   2.  Store the FUNC_DESC, INTENT_DOMAINS, and RESOURCE_LIMITS as the
       agent's Capability Profile.

   3.  Set the entry's expiration time to Current_Time + TTL.

8.3.2.  Lifecycle Maintenance

   Upon receiving a CAP_REFRESH, the LCR MUST look up the existing
   profile and extend its validity by TTL_UPDATE.

   The LCR MUST periodically purge entries that have exceeded their
   expiry time without refresh (STALE state) to ensure the IFR does not
   route to dead agents.

8.4.  Intent Forwarding Routing Table (IFR) Decision Logic

   The Intent Forwarding Routing Table (IFR) functions as the dynamic
   routing engine of the Agent Gateway.  After an INTENT_REQ
   successfully passes AAC validation, the IFR MUST evaluate the request
   and produce a ranked TARGET_AGENT_LIST containing one or more
   eligible Partner Agents.

8.4.1.  Candidate Retrieval

   The IFR MUST interpret the OBJECTIVE TLV as an intent descriptor and
   query the Local Capability Registry (LCR) to obtain the current set
   of active Capability Profiles.






Sun & Zhang              Expires 13 August 2026                [Page 14]

Internet-Draft                    IAIP                     February 2026


8.4.2.  Constraint-Based Filtering

   The IFR MUST apply mandatory constraints to reduce the candidate set
   prior to semantic evaluation.  When a request includes constraint
   fields such as BUDGET, the IFR MUST compare these constraints against
   the corresponding attributes in the Capability Profiles (e.g.,
   RESOURCE_LIMITS) and exclude agents that do not satisfy the required
   conditions.

   Additional policy-based constraints MAY be applied according to local
   administrative policy.

8.4.3.  Semantic Evaluation and Ranking

   For the remaining candidates, the IFR MUST perform semantic matching
   between the request intent and the advertised capabilities.  The
   specific matching method is implementation-dependent; however, the
   IFR MUST compute a relative confidence score that reflects the degree
   of intent-capability alignment.

   The IFR MAY incorporate additional operational signals, such as
   historical performance metrics (e.g., latency or success rate), when
   deriving the final ranking.

   The IFR MUST preserve the relative ordering of candidates when
   constructing the TARGET_AGENT_LIST.

8.4.4.  Selection and Fallback

   The IFR SHOULD select the highest-ranked candidates for inclusion in
   the response, subject to local policy.

   If no candidate satisfies the acceptance criteria (e.g., minimum
   confidence threshold), the IFR SHOULD invoke the Fallback Mechanism.
   When fallback is applied, the Agent Gateway MUST set FALLBACK_INDIC
   to 0x01.

8.5.  Forwarding and Loop Prevention

   For multi-hop scenarios, the AG enforces loop prevention using the
   TTL field in the Common Header.  If TTL <= 1, the request is dropped.
   Duplicate MSG_ID, are suppressed to prevent broadcast storms.

8.6.  Reliability and Error Handling

   Errors detected by any component (AAC auth failure, LCR parsing
   error, IFR no-route) MUST result in an ERROR message returned to the
   sender, containing the appropriate ERROR_CODE.



Sun & Zhang              Expires 13 August 2026                [Page 15]

Internet-Draft                    IAIP                     February 2026


8.7.  Protocol Processing procedure at Agent Gateways

   Figure 3 illustrates the protocol processing pipeline within the
   Agent Gateway (AG).  The protocol operation relies on the
   coordination between three normative functional components: the Agent
   Access Component (AAC), the Local Capability Registry (LCR), and the
   Intent Forwarding Routing Table (IFR).

   The process begins when a Partner Agent transmits a capability
   advertisement (CAP_ADV) [Section 8.1.1].

   *Ingress Validation:* The AAC [Section 8.2] intercepts the message to
   perform session authentication and integrity verification.

   *Registry Update:*Upon successful validation, the AAC forwards the
   payload to the LCR [Section 8.3].  The LCR parses the functional
   descriptors and updates its internal database, mapping the agent's
   semantic profile to its network endpoint.

   The routing process is triggered when a Leader Agent submits an
   intent request (INTENT_REQ) [Section 8.1.2].

   *Ingress Validation:*The AAC validates the request format and the
   sender's authorization scope.

   *Routing Decision:*Validated requests are passed to the IFR
   [Section 8.4], which executes the core decision logic:

   *  *Candidate Retrieval:*The IFR queries the LCR [Section 8.4.1] to
      retrieve active agents capable of satisfying the intent objective.

   *  *Filtering:*Mandatory constraints (e.g., budget, latency) are
      applied to prune ineligible candidates [Section 8.4.2].

   *  *Ranking:*The IFR performs semantic evaluation [Section 8.4.3] to
      assign confidence scores to the remaining candidates.

   *  *Selection:*The eligible partner agents are selected based on
      local policy and fallback mechanisms [Section 8.4.4].

   *Egress Processing:*The partner agent list is passed to the
   Forwarding module [Section 8.5].  This module enforces Time-To-Live
   (TTL) checks and duplicate suppression to prevent routing loops
   before dispatching the forwarded request to the Partner Agent.







Sun & Zhang              Expires 13 August 2026                [Page 16]

Internet-Draft                    IAIP                     February 2026


       +--------------+                  +--------------+
       | Leader Agent |                  | Partner Agent|
       | (Source/App) |                  | (Target/Phy) |
       +-------+------+                  +-------+------+
               | (2) Intent Req                  | (1) CAP_ADV
               | [Sec 8.1.2]                     | [Sec 8.1.1]
               v                                 v
   +------------------------------------------------------------------+
   |              Agent Gateway (Interconnection Domain)              |
   |------------------------------------------------------------------|
   |                                                                  |
   | +--------------+        (CAP_ADV)         +--------------------+ |
   | | Agent Access |------------------------->|  Local Capability  | |
   | |  Comp (AAC)  |                          |   Registry (LCR)   | |
   | |  [Sec 8.2]   |                          |     [Sec 8.3]      | |
   | +------+-------+                          +---------+----------+ |
   |        |                                            ^            |
   |        | (INTENT_REQ)                               | Candidate  |
   |        v                                            | Retrieval  |
   | +---------------------------------------------------+----------+ |
   | |      Intent Forwarding Routing (IFR) [Sec 8.4]               | |
   | |--------------------------------------------------------------| |
   | | 1. Candidate Retrieval (Query LCR) [Sec 8.4.1] --------------+ |
   | | 2. Constraint Filtering [Sec 8.4.2]                          | |
   | | 3. Semantic Eval & Ranking [Sec 8.4.3]                       | |
   | | 4. Selection & Fallback [Sec 8.4.4]                          | |
   | +------+-------------------------------------------------------+ |
   |        | Selected Target List                                    |
   |        v                                                         |
   | +----------------------+                                         |
   | |  Forwarding & Loop   |                                         |
   | | Prevention [Sec 8.5] |                                         |
   | +------+---------------+                                         |
   |        |                                                         |
   +--------+---------------------------------------------------------+
            | (3) Forwarded Request
            v
     +-------------+
     | Partner Agt |
     | (Execution) |
     +-------------+

         Figure 4: Protocol Processing procedure at Agent Gateways








Sun & Zhang              Expires 13 August 2026                [Page 17]

Internet-Draft                    IAIP                     February 2026


9.  Conclusions

   This document specifies the functional components, protocol
   procedures, and message formats of the Intent-based Agent
   Interconnection Protocol (IAIP).  It defines the mechanisms for
   capability-aware registration, semantic intent resolution, and
   dynamic routing.  By abstracting the complexity of agent discovery
   and intent matching, IAIP ensures scalable and adaptive collaboration
   across heterogeneous agent systems.

10.  Security Considerations

   This document focuses on the Intent-based Agent Interconnection
   Protocol at the Agent Gateway for inter-agent collaboration in the
   Internet of Agents (IoA).  Security of the IoA ecosystem is not
   detailed in this document.  Security considerations relevant to
   cross-domain intent routing, capability advertisement integrity,
   trust federation among multiple agent service providers, and end-to-
   end confidentiality of agent interactions are suggested to be deeply
   discussed through other proposals.

11.  IANA Considerations

   TBD

12.  Normative References

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

Authors' Addresses

   Sheng Sun
   ICT, CAS
   Email: sunsheng@ict.ac.cn


   Xinyi Zhang
   CNIC, CAS
   Email: xyzhang@cnic.cn










Sun & Zhang              Expires 13 August 2026                [Page 18]


name: draft-jia-oauth-scope-aggregation
rev: 00
title: OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows
time: 2026-02-10T11:39:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-14T11:39:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-02-27T22:56:05.127482+00:00
abstract:
This document describes a scope-aggregated OAuth 2.0 authorization
   pattern for multi-step AI agent workflows.  An AI agent aggregates
   the scopes required across a workflow and only initiates a single
   authorization procedure for the aggregated scope.  This reduces
   repeated user consents and multiple authorization round-trips,
   improving authorization efficiency.

full_text:
Web Authorization Protocol                                        Y. Jia
Internet-Draft                                                   S. Peng
Intended status: Standards Track                                  Huawei
Expires: 14 August 2026                                 10 February 2026


     OAuth 2.0 Scope Aggregation for Multi-Step AI Agent Workflows
                  draft-jia-oauth-scope-aggregation-00

Abstract

   This document describes a scope-aggregated OAuth 2.0 authorization
   pattern for multi-step AI agent workflows.  An AI agent aggregates
   the scopes required across a workflow and only initiates a single
   authorization procedure for the aggregated scope.  This reduces
   repeated user consents and multiple authorization round-trips,
   improving authorization efficiency.

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

Copyright Notice

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

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



Jia & Peng               Expires 14 August 2026                 [Page 1]

Internet-Draft           OAuth Scope Aggregation           February 2026


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Security Member in Resource Metadata  . . . . . . . . . . . .   5
     3.1.  Comparison to Existing Practice . . . . . . . . . . . . .   6
     3.2.  Backward Compatibility  . . . . . . . . . . . . . . . . .   6
   4.  Workflow Execution with OAuth Scope Aggregation . . . . . . .   7
   5.  Advantages  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Reduced Consent Interactions and End-to-End Latency . . .   9
     5.2.  Avoidance of Mid-Flow Failures due to Insufficient
           Privileges  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  Risk: Residual Privilege  . . . . . . . . . . . . . . . .  11
     7.2.  Risk: User Blind Signing  . . . . . . . . . . . . . . . .  11
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Example of a Resource List . . . . . . . . . . . . .  13
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Recent advances in large language models (LLMs) enable AI agents to
   plan and execute multi-step workflows for complex tasks.  With agent
   communication protocols, AI agents can call third-party tools and
   delegate tasks to other AI agents.  When an AI agent is acting on
   behalf of a human user, these interoperations should require
   authentication and authorization.

   The OAuth 2.0 authorization framework [RFC6749] has been a widely
   preferred method for granting an AI agent access to protected
   resources in existing agent communication protocols.  Acting as an
   OAuth client, an AI agent must present a valid access token with
   appropriate scopes for each request to access a protected resource.
   If the token is missing or lacks the required scope, the resource
   server will reject the request with an HTTP 401/403 error response.
   The agent is then expected to perform authorization server discovery
   and initiate an OAuth flow to obtain an access token as shown in
   Figure 1, involving end user authentication and consent.  This
   challenge-triggered flow repeats for each scope deficiency when an AI
   agent workflow spans across multiple protected resources, causing
   user fatigue and increased end-to-end latency.




Jia & Peng               Expires 14 August 2026                 [Page 2]

Internet-Draft           OAuth Scope Aggregation           February 2026


                                     .-------------------------.
                                     |  Authorization Domain   |
                                     |                         |
                                     |    +-----------------+  |
     +--------+                      |    |                 |  |
     |        |---(a) Auth request---+--->|                 |  |
     |        |                      |    |                 |  |
     |  End   |---(b) User consent---+--->|  Authorization  |  |
     |  User  |                      |    |     Server      |  |
     |        |<--(c) Auth code------+----|                 |  |
     |        |                      |    |                 |  |
     +--------+                      |    +-----------------+  |
       ^    |                        |          ^      |       |
   (a) |    | (c)                    |          |      |       |
   Auth|    | Auth                   |          |      |       |
   Req |    | Code  .-----(d) Token Exchange----'      |       |
       |    |       |                |                 |       |
       |    v       |                |                 |       |
     +--------+     |  .--(e) Access Token-------------'       |
     |        |-----'  |             |                         |
     |        |        |             |    +-----------------+  |
     |  AI    |<-------'             |    | Resource Server |  |
     | Agent  |                      |    |                 |  |
     |        |---(f) Request w/ Token--->| +-------------+ |  |
     |        |                      |    | |   Resource  | |  |
     |        |<--(g) Response-------+----| |   Metadata  | |  |
     +--------+                      |    | +-------------+ |  |
                                     |    | +-----+ +-----+ |  |
                                     |    | |Tool | |Tool | |  |
                                     |    | | A1  | | A2  | |  |
                                     |    | +-----+ +-----+ |  |
                                     |    +-----------------+  |
                                     '-------------------------'

            Figure 1: OAuth 2.0 authorization flow for AI agents

   This document defines an authorization domain as a logical grouping
   of the scopes authorizable by a single trust anchor (e.g., an OAuth
   2.0 authorization server).  Within this domain, an AI agent can
   request multiple scopes (e.g., email:read, calendar:write) that share
   a common user identity and consent context.  Given a multi-step
   workflow, an AI agent first computes the minimal aggregation of the
   required scopes within each authorization domain.  Subsequently, the
   agent performs authorization server discovery and initiates a scope-
   aggregated authorization flow to obtain the access token.  This
   approach reduces repeated user consent and multiple authorization
   round-trips while preserving least privilege.




Jia & Peng               Expires 14 August 2026                 [Page 3]

Internet-Draft           OAuth Scope Aggregation           February 2026


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

   AI Agent
      An entity with built-in intelligence, which can perform actions to
      accomplish tasks, possibly on behalf of an end-user or another
      agent.

   Agent Communication Protocol
      A protocol that defines how an agent discovers and utilizes
      server-exposed resources (e.g., tools, skills, etc.).  For
      example, Model Context Protocol (MCP) protocol [MCP] defines how
      to discover and call tools, and Agent-to-Agent (A2A) protocol
      [A2A] defines how to invoke other AI agents.

   Agent Workflow
      A sequence of steps to accomplish a task, which may be pre-built
      by a human or planned by an agent.  These steps may include access
      to one or more resources on remote resource servers.  An agent
      workflow may be structured as a chain or a tree with parallel
      branches.

   Resource Server (RS)
      An OAuth 2.0 term for the server hosting one or more protected
      resources that require access token for access.  The resources are
      invocable, server-exposed units of functionality.

   Authorization Server (AS)
      An OAuth 2.0 term for the server that issues access tokens to AI
      agent after successfully authenticating the resource owner and
      obtaining consent for authorization.

   Authorization Domain (AD)
      A logical grouping of scopes authorizable by a single trust
      anchor.  For example, scopes like mail.read and calendar.write
      within a single ecosystem belong to the same authorization domain.








Jia & Peng               Expires 14 August 2026                 [Page 4]

Internet-Draft           OAuth Scope Aggregation           February 2026


3.  Security Member in Resource Metadata

   For the purpose of resource discovery, an AI agent obtains resource
   metadata by invoking a protocol method or by retrieving a description
   document from a well-known URI.  Such resources may be referred to as
   "tools" or "skills" in different contexts.  This document extends the
   resource metadata object by defining a security member that MAY be
   included to indicate a resource's authorization requirements.

   The resource metadata is represented in JSON format.  It MUST contain
   the following members:

   name
      A string that provides a unique identifier for the resource.

   description
      A human-readable string that describes the resource.

   input_schema
      A machine-readable schema (e.g., JSON schema) describing the
      parameters required to execute the resource.

   This document defines an OPTIONAL security member within the resource
   metadata.  When present, the security object indicates the
   authorization requirements for the resource and contains the
   following members:

   type
      REQUIRED.  An array of strings specifying one or more supported
      security schemes.  This document defines the value "oauth2" for
      use with the OAuth 2.0 authorization framework.  Other type
      values, such as "apikey", "basic", and "oidc", may also be used.

   scopes
      REQUIRED.  An array of strings specifying the scope values
      required to access the resource.  If this member is present and
      "oauth2" is included in the type array, the AI agent MUST possess
      all listed scopes to gain access.

   as_metadata
      OPTIONAL.  A string containing the URL to the OAuth 2.0
      Authorization Server (AS) metadata [RFC8414].  This allows the
      agent to dynamically discover the authorization endpoints.

   Figure 2 illustrates the structure of the security member within a
   resource definition:





Jia & Peng               Expires 14 August 2026                 [Page 5]

Internet-Draft           OAuth Scope Aggregation           February 2026


   {
     "name": "resource_identifier",
     "description": "...",
     "input_schema": { ... },
     "security": {
       "type": ["oauth2"],
       "scopes": ["scope_A"],
       "as_metadata": "https://server.example.com/.well-known/..."
     }
   }

       Figure 2: Structure of Resource Metadata with Security Member

   A comprehensive, non-normative example of a full list of resource
   metadata is provided in Appendix A.

3.1.  Comparison to Existing Practice

   This document defines a uniform mechanism for advertising per-
   resource authorization requirements, drawing inspiration from and
   addressing gaps in existing protocols.

   Agent-to-Agent (A2A) Protocol [A2A]: The A2A protocol defines
   security scheme objects based on the OpenAPI 3.2 specification.
   OpenAPI includes a security object within its schema that serves a
   purpose analogous to the security member defined here.  It allows an
   API to declare its required security schemes (e.g., OAuth 2.0) and
   the necessary scopes for each operation.  This document aligns with
   that established principle, offering a potentially simplified
   version.

   Model Context Protocol (MCP) [MCP]: The MCP protocol specifies OAuth
   2.1 as the authorization framework.  However, MCP does not
   standardize per-tool scope advertisement in tool metadata.  This can
   lead to reactive, challenge-triggered authorization flows when
   executing an AI agent workflow.  The security member defined in this
   document directly addresses this gap by providing a mechanism for an
   MCP server to advertise these requirements.

3.2.  Backward Compatibility

   Inclusion of the security member in resource metadata is OPTIONAL.  A
   server SHOULD omit the security member for resources that do not
   require authorization.  To allow for implementation flexibility, a
   server MAY also omit the security member for a protected resource.






Jia & Peng               Expires 14 August 2026                 [Page 6]

Internet-Draft           OAuth Scope Aggregation           February 2026


   An AI agent MUST ignore a security member if it does not understand
   the contents.  Furthermore, all agents MUST be able to handle
   authorization reactively (e.g., via a step-up flow) upon receiving an
   authorization error.

   AI agents that recognize and support the security member SHOULD use
   the information it contains to perform proactive and aggregated
   authorization, as described in Section 4.

4.  Workflow Execution with OAuth Scope Aggregation

   Using the security member in the resource metadata, an AI agent can
   follow the sequence below to execute a workflow:

   1.  Resource Discovery: The AI agent fetches the resource metadata
       from the resource server.  Resource metadata MAY include a
       security member describing the required authentication scheme,
       scopes, and AS metadata URL.

   2.  Authorization Domain Identification: Given a pre-defined or
       planned workflow, the AI agent iterates through each step and
       fetches the associated AS metadata to learn the authorization
       domain and authorization endpoints.

   3.  Scope Aggregation: For each authorization domain, the AI agent
       computes a least-privilege set of scopes required by the
       workflow, using the OPTIONAL security member defined in
       Section 3.  The agent aggregates the required scopes across all
       resource invocations within the same authorization domain and
       removes duplicates.  If, and only if, the authorization domain
       defines a hierarchical relationship among its scopes (e.g., a
       broader scope implies one or more narrower scopes), the agent MAY
       further reduce the requested scope set by removing any scope that
       is subsumed by another requested scope.  For example, within a
       single authorization domain, an agent workflow (1) reads a
       document from the cloud drive with scope "drive.read", (2)
       updates the document with scope "drive.write", and (3) creates
       calendar events with scope "calendar.write".  If the
       authorization domain defines that "drive.write" subsumes
       "drive.read", the aggregated scope set is ["drive.write",
       "calendar.write"].

   4.  Aggregated Scope Authorization: For each authorization domain,
       the AI agent initiates an OAuth 2.0 authorization code grant to
       obtain an access token with the aggregated scopes.  During this
       step, the user is prompted to authorize the requested scopes.





Jia & Peng               Expires 14 August 2026                 [Page 7]

Internet-Draft           OAuth Scope Aggregation           February 2026


   5.  Workflow Execution: The AI agent executes the multi-step
       workflow, using the obtained access tokens when accessing
       resources on resource servers.

   This process is illustrated in Figure 3.

 +--------+       +--------+       +---------------+       +-----------+
 |End User|       |AI Agent|       |Resource Server|       |Auth Server|
 +---+----+       +---+----+       +-------+-------+       +-----+-----+
     |                | (1) Get metadata   |                     |
     |                |------------------->|                     |
     |                |                    |                     |
     |                | (1) Res. metadata  |                     |
     |                |< - - - - - - - - - |                     |
     |                |                    |                     |
     |                | (2) Get AS metadata for each AD          |
     |                |----------------------------------------->|
     |                |                    |                     |
     |                | (2) AS metadata    |                     |
     |                |<- - - - - - - - - - - - - - - - - - - - -|
     |                |                    |                     |
     |                |----\               |                     |
     |                |    | (3) Scope aggregation               |
     |                |<---/  within each AD                     |
     |                |                    |                     |
     | (4a) Init auth |                    |                     |
     |<---------------|                    |                     |
     |                |                    |                     |
     |              (4b) User authentication + consent           |
     |---------------------------------------------------------->|
     |                |                    |                     |
     |              (4c) Redirect back to agent                  |
     |< - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
     |                |                    |                     |
     | (4d) Auth code |                    |                     |
     | - - - - - - - >|                    |                     |
     |                | (4e) Token exchange                      |
     |                |----------------------------------------->|
     |                |                    |                     |
     |                | (4f) Access token w/ aggregated scopes   |
     |                |<- - - - - - - - - - - - - - - - - - - - -|
     |                |                    |                     |
     |     +----------+--------------------+---------------+     |
     |     | LOOP: Repeat for each step w/ resource req.   |     |
     |     |-----------------------------------------------|     |
     |     |          |(5) Request resource w/ token       |     |
     |     |          |------------------->|               |     |
     |     |          |                    |               |     |



Jia & Peng               Expires 14 August 2026                 [Page 8]

Internet-Draft           OAuth Scope Aggregation           February 2026


     |     |          |(5) Resource responses              |     |
     |     |          |<- - - - - - - - - -|               |     |
     |     +----------+--------------------+---------------+     |
     |                |                    |                     |
 +---+----+       +---+----+       +-------+-------+       +-----+-----+
 |End User|       |AI Agent|       |Resource Server|       |Auth Server|
 +--------+       +--------+       +---------------+       +-----------+

      Figure 3: Sequence diagram of workflow execution with scope-
                        aggregated authorization

5.  Advantages

   Compared to a reactive, challenge-triggered authorization flow, this
   scope-aggregated authorization strategy offers several benefits for
   multi-step AI agent workflows.

5.1.  Reduced Consent Interactions and End-to-End Latency

   In the absence of aggregated authorization, the end user is required
   to respond to multiple consent prompts for individual resources
   associated with distinct scopes.  This interaction pattern is
   illustrated in Figure 4.  On the contrary, the mechanism defined in
   this document enables the end user to authorize the AI Agent one
   single time per authorization domain.  This approach mitigates user
   friction and consent fatigue, while simultaneously reducing the end-
   to-end latency of task completion.

 +--------+       +--------+       +---------------+       +-----------+
 |End User|       |AI Agent|       |Resource Server|       |Auth Server|
 +---+----+       +---+----+       +-------+-------+       +-----+-----+
     |                | (1) Get metadata   |                     |
     |                |------------------->|                     |
     |                |                    |                     |
     |                | (1) Res. metadata  |                     |
     |                |< - - - - - - - - - |                     |
     |                |                    |                     |
  +--+----------------+--------------------+---------------------+----+
  | LOOP: Repeat for each request with scope deficiency               |
  |-------------------------------------------------------------------|
  |  |                | (2) Request resource                     |    |
  |  |                |------------------->|                     |    |
  |  |                |                    |                     |    |
  |  |                | (2) Unauthorized error                   |    |
  |  |                |< - - - - - - - - - |                     |    |
  |  |                |                    |                     |    |
  |  |                | (3) Fetch AS metadata                    |    |
  |  |                |----------------------------------------->|    |



Jia & Peng               Expires 14 August 2026                 [Page 9]

Internet-Draft           OAuth Scope Aggregation           February 2026


  |  |                |                    |                     |    |
  |  |                | (3) AS metadata    |                     |    |
  |  |                |< - - - - - - - - - - - - - - - - - - - - |    |
  |  |                |                    |                     |    |
  |  | (4a) Init auth |                    |                     |    |
  |  |<---------------|                    |                     |    |
  |  |                |                    |                     |    |
  |  |              (4b) User authentication + consent           |    |
  |  |---------------------------------------------------------->|    |
  |  |                |                    |                     |    |
  |  |              (4c) Redirect back to agent                  |    |
  |  |< - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|    |
  |  |                |                    |                     |    |
  |  | (4d) Auth code |                    |                     |    |
  |  | - - - - - - - >|                    |                     |    |
  |  |                | (4e) Token exchange                      |    |
  |  |                |----------------------------------------->|    |
  |  |                |                    |                     |    |
  |  |                | (4f) Access token w/ requested scopes    |    |
  |  |                |< - - - - - - - - - - - - - - - - - - - - |    |
  |  |                |                    |                     |    |
  |  |                | (5) Request resource w/ access token     |    |
  |  |                |------------------->|                     |    |
  |  |                |                    |                     |    |
  |  |                | (5) Resource responses                   |    |
  |  |                |< - - - - - - - - - |                     |    |
  +--+----------------+--------------------+---------------------+----+
     |                |                    |                     |
 +---+----+       +---+----+       +-------+-------+       +-----+-----+
 |End User|       |AI Agent|       |Resource Server|       |Auth Server|
 +--------+       +--------+       +---------------+       +-----------+

    Figure 4: Sequence diagram of workflow execution without scope-
                        aggregated authorization

5.2.  Avoidance of Mid-Flow Failures due to Insufficient Privileges

   By computing the required scopes and obtaining tokens in advance, the
   AI agent avoids mid-workflow failures caused by missing privileges.
   This increases the reliability of multi-step workflows, preventing
   partial completion and handling insufficient-scope conditions
   proactively rather than reactively.

6.  IANA Considerations

   This document includes no request to IANA.





Jia & Peng               Expires 14 August 2026                [Page 10]

Internet-Draft           OAuth Scope Aggregation           February 2026


7.  Security Considerations

   This section summarizes security risks that arise in scope-aggregated
   authorization for multi-step AI agent workflows and describes
   recommended mitigations.  Implementations are RECOMMENDED to apply
   the mechanisms below, as appropriate to their threat model and
   deployment context.

7.1.  Risk: Residual Privilege

   In a sequential workflow involving Step A, B, and C, the AI agent
   still holds the permissions for Step A while executing Step B and C.
   More critically, after Step C is finished, the agent retains full
   access to Step A, B, and C.

   Mitigation:

   Token Downscoping [RFC8693] : Upon completing a step in the workflow,
   the AI agent SHOULD perform a token exchange request to the
   authorization server to exchange for a new token with a reduced scope
   set.  This reduces the impact of token leakage during later steps.

   Strict Token Revocation [RFC7009] : Upon successful completion or
   terminal failure of the workflow, the AI agent SHOULD immediately
   revoke the access token and any associated refresh tokens.  The
   authorization server SHOULD limit refresh token lifetimes to reduce
   residual privilege.

   Sender-Constrained Tokens [RFC9449] : It is RECOMMENDED to use
   sender-constrained access tokens that bind token use to a proof-of-
   possession (DPoP) key controlled by the AI agent.  This reduces the
   risk that an aggregated token can be intercepted and replayed by a
   different actor.

7.2.  Risk: User Blind Signing

   When users are presented with a long set of aggregated scopes (e.g.,
   "Read Mail", "Write Files", "Access Calendar", "Post to Slack"), they
   may approve the request without understanding its implications.  This
   can undermine informed consent and increase the likelihood of over-
   authorization.

   Mitigation:








Jia & Peng               Expires 14 August 2026                [Page 11]

Internet-Draft           OAuth Scope Aggregation           February 2026


   Structured Consent UI: Authorization Servers SHOULD present requested
   privileges in a structured manner, grouped by workflow step, rather
   than as a flat list of scopes.  Authorization Servers MAY
   additionally require step-level acknowledgment for high-risk
   privileges.

8.  Acknowledgements

   The authors would like to thank Yiyang Shao and Jinyang Li for useful
   discussion and ideas.

9.  References

9.1.  Normative References

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

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

   [RFC7009]  Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
              2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
              August 2013, <https://www.rfc-editor.org/info/rfc7009>.

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

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

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/info/rfc8693>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/info/rfc9449>.

9.2.  Informative References



Jia & Peng               Expires 14 August 2026                [Page 12]

Internet-Draft           OAuth Scope Aggregation           February 2026


   [A2A]      Google, "Agent2Agent(A2A) Protocol", 2025,
              <https://a2a-protocol.org/latest>.

   [MCP]      Anthropic, "Model Context Protocol (MCP)", 2025,
              <https://modelcontextprotocol.io/docs/getting-started/
              intro>.

Appendix A.  Example of a Resource List

   This appendix is non-normative.  Figure 5 shows an example resource
   list for a calendar server.  In this example, both resources belong
   to the same authorization domain.  For a workflow that accesses both
   resources, the AI agent can obtain an access token via OAuth 2.0 with
   the aggregated scope set ["calendar.read", "calendar.write"].  If the
   authorization domain defines that "calendar.write" subsumes
   "calendar.read", the requested scope set can be further reduced to
   ["calendar.write"].


































Jia & Peng               Expires 14 August 2026                [Page 13]

Internet-Draft           OAuth Scope Aggregation           February 2026


   [
     {
       "name": "CalendarReader",
       "description": "Read events from the user's calendar",
       "input_schema": {
         "type": "object",
         "properties": {
           "start_date": {
             "type": "string",
             "format": "date-time"
           },
           "end_date": {
             "type": "string",
             "format": "date-time"
           }
         },
         "required": ["start_date"]
       },
       "security": {
         "type": ["oauth2"],
         "scopes": ["calendar.read"],
         "as_metadata": "https://auth.calendar.com/.well-known/
         oauth-authorization-server"
       }
     },
     {
       "name": "CalendarWriter",
       "description": "Create events on the user's calendar",
       "input_schema": {
         "type": "object",
         "properties": {
           "summary": { "type": "string" },
           "start": { "type": "string", "format": "date-time" },
           "end": { "type": "string", "format": "date-time" }
         },
         "required": ["summary", "start", "end"]
       },
       "security": {
         "type": ["oauth2"],
         "scopes": ["calendar.write"],
         "as_metadata": "https://auth.calendar.com/.well-known/
         oauth-authorization-server"
       }
     }
   ]

       Figure 5: An example of the resource list of a calendar server




Jia & Peng               Expires 14 August 2026                [Page 14]

Internet-Draft           OAuth Scope Aggregation           February 2026


Contributors

   The following people contributed significantly to this document:

   Yiyang Shao
   Huawei
   Email: shaoyiyang@huawei.com

   Jinyang Li
   Huawei
   Email: lijinyang9@huawei.com

Authors' Addresses

   Yukuan Jia
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jiayukuan@huawei.com


   Shuping Peng
   Huawei
   Huawei Bld., No.156 Beiqing Rd.
   Beijing
   100095
   China
   Email: pengshuping@huawei.com





















Jia & Peng               Expires 14 August 2026                [Page 15]


name: draft-mozleywilliams-dnsop-dnsaid
rev: 00
title: DNS for AI Discovery
time: 2026-02-24T20:46:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-28T20:46:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127491+00:00
abstract:
This document specifies a method for utilizing the Domain Name System
   (DNS) to facilitate scalable and interoperable discovery between AI
   agents.  The proposed mechanism, referred to as _DNS AI agent
   Discovery_ (DNS-AID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   This will allow organisations to publish information about their AI
   agents on the Internet or internal networks using a well-known label
   within the organisation’s own DNS namespace.  This document does not
   define how the published agent information is accessed or the exact
   structure of that information.  Instead, it specifies a mechanism for
   indicating which access protocol should be used and what format the
   agent information will be provided in.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

full_text:
dnsop                                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Standards Track                          Infoblox, Inc.
Expires: 27 August 2026                                      B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telekom
                                                        23 February 2026


                          DNS for AI Discovery
                  draft-mozleywilliams-dnsop-dnsaid-00

Abstract

   This document specifies a method for utilizing the Domain Name System
   (DNS) to facilitate scalable and interoperable discovery between AI
   agents.  The proposed mechanism, referred to as _DNS AI agent
   Discovery_ (DNS-AID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   This will allow organisations to publish information about their AI
   agents on the Internet or internal networks using a well-known label
   within the organisation’s own DNS namespace.  This document does not
   define how the published agent information is accessed or the exact
   structure of that information.  Instead, it specifies a mechanism for
   indicating which access protocol should be used and what format the
   agent information will be provided in.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

About This Document

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

   The latest revision of this draft can be found at
   https://example.com/LATEST.  Status information for this document may
   be found at https://datatracker.ietf.org/doc/draft-mozleywilliams-
   dnsop-dnsaid/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.





Mozley, et al.           Expires 27 August 2026                 [Page 1]

Internet-Draft                   DNS-AID                   February 2026


   Source for this draft and an issue tracker can be found at
   https://github.com/USER/REPO.

Status of This Memo

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

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

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

   This Internet-Draft will expire on 27 August 2026.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  DNS Mechanisms for Agent Discovery  . . . . . . . . . . . . .   5
     3.1.  Use of Service Binding Records in Discovery . . . . . . .   5
     3.2.  DNS-Based Service Discovery . . . . . . . . . . . . . . .   6
     3.3.  Domain Control Validation . . . . . . . . . . . . . . . .   7
   4.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Example Communication . . . . . . . . . . . . . . . . . .   8
     4.2.  Example Record  . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  Example Use Cases . . . . . . . . . . . . . . . . . . . .  10
     4.4.  Zone and Other Requirements . . . . . . . . . . . . . . .  10
       4.4.1.  Delegation and Chain of Trust . . . . . . . . . . . .  10



Mozley, et al.           Expires 27 August 2026                 [Page 2]

Internet-Draft                   DNS-AID                   February 2026


       4.4.2.  Performance Optimization(s) . . . . . . . . . . . . .  11
       4.4.3.  Customization(s)  . . . . . . . . . . . . . . . . . .  11
   5.  Implementation Guidance . . . . . . . . . . . . . . . . . . .  12
     5.1.  Discovery Usage Examples  . . . . . . . . . . . . . . . .  12
       5.1.1.  Discovery Status 1 (Known Service and Domain) . . . .  13
       5.1.2.  Discovery Status 2 (Known Service OR Domain,
               Trusted)  . . . . . . . . . . . . . . . . . . . . . .  14
       5.1.3.  Discovery Status 3 (Multi-Domain Query for Known
               Service)  . . . . . . . . . . . . . . . . . . . . . .  15
       5.1.4.  Discovery Status 4 (Untrusted Domain / Consolidated
               Registry) . . . . . . . . . . . . . . . . . . . . . .  17
       5.1.5.  Discovery Status 4 (Unknown / Wildcard, or status 2
               untrusted?) . . . . . . . . . . . . . . . . . . . . .  18
     5.2.  AI Providers  . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.1.  Publishing Schema . . . . . . . . . . . . . . . . . .  18
       5.2.2.  TTLs, Update Agility  . . . . . . . . . . . . . . . .  19
       5.2.3.  Example DNS-AID Zonefile  . . . . . . . . . . . . . .  19
       5.2.4.  How to use this zonefile  . . . . . . . . . . . . . .  21
     5.3.  Why these records . . . . . . . . . . . . . . . . . . . .  21
   6.  Future Work & Unaddressed Portions  . . . . . . . . . . . . .  22
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1.  Introduction

   DNS-AID introduces a leaf zone convention (e.g., _agents.example.com)
   containing Service Binding (SVCB) records (e.g.,
   chat._agents.example.com) that encode application-specific metadata.
   These records enable agents to retrieve operational parameters prior
   to initiating a session, supporting both targeted lookups and
   capability-based discovery.  The approach leverages existing DNS
   protocols and records, including DNS Service Discovery (DNS-SD),
   DNSSEC, and DANE, to provide integrity, authenticity, and automation
   without requiring human intervention.  Lastly, the draft for Domain
   Control Validation (DCV) proposes a best current practice to prove an
   agent is authorized to act on behalf of a domain.

   This mechanism provides the bootstrap for discovering an
   organization's agents.  An organization can publish it's own registry
   of agents and their capabilities at a well-known entry point in the
   DNS hierarchy.  It is also possible to provide names for commonly
   used agents, so that any registry does not need to be queried and the
   returned capabilities processed (e.g. on a model card or other



Mozley, et al.           Expires 27 August 2026                 [Page 3]

Internet-Draft                   DNS-AID                   February 2026


   schema) and then the name of this resolved.  It is expected that
   other drafts will develop the content of any registry, such as
   refining the model card concept to a more structure schema, and the
   protocol used to interact with the registry.  It is more performant
   and deterministic to receive the details of the IP, protocols and
   port from an SVCB record than it is to determine this from a model
   card.  It also mitigates against the vulnerability of parsing this
   information from a model card.

   For example, a company may only have a few external agents available
   for use, and if the IETF standardizes 'types' of AI agents, then
   perhaps _chat._agents.example.com or _img2txt._agents.example.com etc
   are all different SVCB records.  On the other hand a company may
   provide an index of all agents via a well know entry point in the DNS
   hierarchy e.g. _index._agents.example.com.

   The DNS-AID model is designed for incremental and non-disruptive
   deployment within existing DNS infrastructure.  It introduces no new
   DNS message formats, opcodes, response codes, or resource record
   types.  Instead, it defines a structured namespace convention and
   usage profile for existing record types... primarily SVCB, TXT, and
   TLSA all within designated leaf zones (e.g.,
   _a2a._agents.example.com).

   Organizations may adopt DNS-AID by publishing agent metadata under
   delegated subdomains, leveraging DNSSEC for integrity and
   authenticity, and optionally implementing Domain Control Validation
   (DCV) to signal delegated authority.  These zones may be exposed
   selectively via split-horizon DNS or different zones, enabling
   differentiated discovery views for internal and external agents.  No
   changes are required to recursive or authoritative DNS server
   implementations beyond standard support for DNSSEC and SVCB.

   This model supports opt-in adoption, allowing agent operators to
   publish discovery metadata without coordination with external
   registries or protocol maintainers.  It is compatible with existing
   DNS tooling, including zone provisioning systems, monitoring
   platforms, and resolver configurations.  DNS-AID is therefore
   suitable for deployment across enterprise, cloud, and federated
   environments, and may coexist with other discovery mechanisms without
   conflict.










Mozley, et al.           Expires 27 August 2026                 [Page 4]

Internet-Draft                   DNS-AID                   February 2026


2.  Conventions and Definitions

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

3.  DNS Mechanisms for Agent Discovery

   AI agents that need to be discovered are currently being developed to
   support tasks such as travel planning, etc.  See Figure 1.

                     Agent Capabilities

   ┌───────────────────────┐    ┌───────────────────────┐
   │      DISCOVERY        │    │     APPLICATION       │
   │                       │    │                       │
   │  - SVCB (INDEX)       │    │  - TRAVEL             │
   │      IP               │    │  - COST               │
   │      PROTOCOL         │    │  - ATTESTATIONS       │
   │      PORT             │    │     TRAINING DATA     │
   │                       │    │     CERTIFICATIONS    │
   │  -WELL KNOWN AGENTS   │    │     ACCEPTABLE USE    │
   │     SVCB RRs          │    │  - TO BE SPECIFIED... │
   │                       │    │                       │
   └───────────────────────┘    └───────────────────────┘

          This draft                   Other drafts

                      Figure 1: AI Agent Capabilities

3.1.  Use of Service Binding Records in Discovery

   Agents will use SVCB records as defined in [RFC9460] to discover
   other agent endpoints under structured leaf zones (e.g.,
   _chat._agents.example.com).  These records allow querying agents to
   retrieve operational parameters prior to initiating a session,
   including supported protocols, privacy features (e.g., Encrypted
   Client Hello via ECH), and failover configurations.

   Agents may advertise support for QUIC, HTTP/3, or agent-to-agent
   protocols via ALPN declarations.  Operators may specify alternate
   endpoints or migrate services across domains without relying on CNAME
   indirection, improving performance and reducing DNS resolution
   complexity.





Mozley, et al.           Expires 27 August 2026                 [Page 5]

Internet-Draft                   DNS-AID                   February 2026


   When paired with attribute leaf zones and custom SVCB parameters,
   this mechanism enables fine-grained discovery of agent capabilities.
   For instance, an agent querying _a2a._agents.example.com may receive
   an SVCB record indicating supported modalities (e.g., chat, image-to-
   text), expected input formats, and cost-related metadata (e.g., token
   pricing).  This structured discovery model supports deterministic,
   cacheable, and semantically rich interactions between agents.

   SVCB records can indicate the protocol used to communicate with a
   given agent as in Figure 2:

  _index._agents.example.com. 3600 IN SVCB 1 ai-index-svc.example.com. (
      alpn="a2a"
      port=443
      ipv4hint=192.0.2.1
      ipv6hint=2001:db8::1
  )

                      Figure 2: SVCB Record Example

3.2.  DNS-Based Service Discovery

   DNS-SD as defined in [RFC6763], extends the capabilities of the
   Domain Name System to support service-type-based discovery.  Unlike
   traditional DNS resolution, which requires prior knowledge of a
   specific hostname, DNS-SD enables clients to discover services based
   on their functional type (e.g., _http._tcp, _printer._udp) within a
   given domain.

   DNS-SD provides a mechanism for AI agents to discover other agents or
   services based on declared capabilities rather than explicit names.
   For example, an agent may issue a query for _data-
   cleaner._a2a._agents.example.com to locate services capable of
   performing data sanitization tasks.  This type-based discovery model
   supports dynamic ecosystems where agent roles and capabilities may
   evolve over time.

   DNS-SD operates over both multicast DNS (mDNS) and unicast DNS,
   allowing for flexible deployment in local networks and globally
   scoped domains.  In enterprise or cloud environments, unicast DNS-SD
   enables structured and policy-compliant discovery across
   organizational boundaries.  When combined with SVCB records, DNS-SD
   allows agents to retrieve detailed service metadata, including
   transport preferences, protocol support, and operational parameters.







Mozley, et al.           Expires 27 August 2026                 [Page 6]

Internet-Draft                   DNS-AID                   February 2026


   This model supports federated agent architectures, where multiple
   agents may advertise similar capabilities under different domains.
   By leveraging DNS-SD, agents can perform capability-based queries and
   receive a list of candidate services, each accompanied by structured
   metadata for evaluation and selection.

   DNS-SD also supports extensibility through TXT records and custom
   service naming conventions, enabling organizations to encode
   additional attributes relevant to agent interaction (e.g., supported
   data formats, authentication requirements, or cost models).  A TXT
   record with the same name as the SVCB record could be used to provide
   additional meta-data.  These features make DNS-SD a suitable
   foundation for scalable, interoperable, and semantically rich agent
   discovery workflows.

   An index of agents type service can be provided via DNS-SD as a well
   known entry point to a more complete capability description via a
   common schema e.g. _index._agents.example.com.  This may be used in
   addition to or instead of querying for specific agent services such
   as _data-cleaner._a2a._agents.example.com.  Querying specific
   services will shortcut communication vs. querying an index derived
   from something like organisation's agent registry.

3.3.  Domain Control Validation

   DCV refers to the process by which an entity demonstrates
   authoritative control over a DNS domain.  As described in
   [I-D.draft-ietf-dnsop-domain-verification-techniques], DNS-based DCV
   typically involves the placement of a DNS record, most commonly a TXT
   record, containing a challenge token or assertion at a designated
   location within the domain.  This record is then queried by an
   Application Service Provider (ASP) to confirm control.

   The authors do not intend for authorization to exist solely within
   this phase of the discovery process, however there may be use cases
   in which agents acting on behalf of domains, prior to application
   handshake, can prove they are acting on behalf of a domain
   (organization).  This may be a preferable mechanism, especially for
   ephemeral agents, to prove they act on behalf of a domain, rather
   than manage many temporary security mechanisms across multiple
   information security pillars (firewalls, certs, etc.).

   In the context of DNS-AID, DCV provides a mechanism for agents to
   assert delegated authority on behalf of a domain.  For example, an
   organization may publish a TXT record under a structured leaf zone
   (e.g., _agent-roles._a2a._agents.example.com) containing metadata
   such as:




Mozley, et al.           Expires 27 August 2026                 [Page 7]

Internet-Draft                   DNS-AID                   February 2026


   ai-role=data-cleaner; crm=salesforce; access=readonly

   This record signals that a specific agent is authorized to perform
   scoped operations under the domain's authority.  When protected by
   DNSSEC, such assertions become cryptographically verifiable,
   mitigating risks of spoofing or unauthorized delegation.

   DCV within DNS-AID supports both ephemeral and persistent validation
   models.  Ephemeral validation may be used for short-lived agent
   credentials or session-based delegation, while persistent records
   enable long-term authorization signaling.  TTL and expiration
   considerations, as discussed in the draft, are critical to ensuring
   that validation records do not persist beyond their intended scope.

   Furthermore, DNS-AID encourages the use of application-specific
   naming conventions and token formats to avoid service confusion and
   collision.  Validation records should be scoped to the intended
   service and include unguessable tokens or structured metadata to
   prevent unauthorized reuse across federated agent ecosystems.

4.  Architecture

   DNS’s hierarchical namespace supports multi-tenant and federated
   discovery models.  Organizations may delegate subdomains to tenants
   (e.g., customer1._agents.vendor.com) or publish agent metadata under
   federated zones (e.g., region1._a2a.example.org).  This enables
   scoped discovery, policy enforcement, and operational isolation
   across tenants, departments, or geographic regions.  Combined with
   DNSSEC and access controls, this model supports secure delegation and
   trust signaling in complex agent ecosystems, including SaaS platforms
   and cross-organizational collaborations.

4.1.  Example Communication

   Agent (org1) wants to find other agents provided by another entity
   (org2) and discover/verify capabilities Figure 3:















Mozley, et al.           Expires 27 August 2026                 [Page 8]

Internet-Draft                   DNS-AID                   February 2026


                    DNS SVCB Query
                _a2a._agents.example.com
   ┌────────┐                       ┌────────┐            ┌────────┐
   │AI Agent├──────────────────────►│Resolver├───────────►│Auth DNS│
   │ (ORG1) │◄──────────────────────┤ (ORG1) │◄─────┬─────┤ (ORG2) │
   └────────┘                       └────────┘      │     └────────┘
                                                    │
   ┌────────────────────────────────────────────────┴──────────────┐
   │_a2a._agents.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. ( │
   │    alpn="a2a"                                                 │
   │    port=443                                                   │
   │    ipv4hint=192.0.2.1                                         │
   │    ipv6hint=2001:db8::1                                       │
   │)                                                              │
   └───────────────────────────────────────────────────────────────┘

                     Figure 3: Agent ORG1 Querying Org2

4.2.  Example Record

   _a2a._agents.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (
       alpn="a2a"
       port=443
       ipv4hint=192.0.2.1
       ipv6hint=2001:db8::1
   )

                   Figure 4: Example SVCB Resource Record

   *  _a2a._agents.example.com.: The service name, following the SVCB
      naming convention (_service._agents.example.com).

   *  3600: TTL (Time to Live) in seconds.

   *  IN SVCB: The record type.

   *  1: SVCB priority. 0 is for alias mode; 1+ is for service mode.

   *  ai-index-svc.org2.com.: The target name of the service.

   *  alpn="a2a": Specifies the ALPN protocol identifier.  This is where
      your custom protocol is declared.

   *  port=443: The port on which the service is available.

   *  ipv4hint and ipv6hint: Optional hints for clients to connect
      directly.




Mozley, et al.           Expires 27 August 2026                 [Page 9]

Internet-Draft                   DNS-AID                   February 2026


4.3.  Example Use Cases

   1.  A user instructs their internal agent to “clean up Salesforce
       contacts based on this email.” The agent must discover
       Salesforce’s authorized agents, validate its own delegation to
       act on behalf of the enterprise, and initiate a secure session.
       DNS-AID enables this by publishing agent endpoints and roles
       under DNS zones controlled by each organization.

   2.  A research consortium deploys agents across multiple
       institutions.  Each institution publishes its agents under its
       own domain (e.g., _a2a._agents.universityA.edu), allowing
       collaborators to discover services based on capability (e.g.,
       _data-annotator._a2a.universityB.edu) while respecting
       institutional boundaries and trust models.

   3.  A SaaS provider hosts agents for multiple customers.  Each
       customer’s agents are published under tenant-specific zones
       (e.g., customer1._agents.saas.com), enabling scoped discovery and
       policy enforcement.  DNS-AID supports this model through
       hierarchical zone delegation and metadata-rich SVCB records.

   4.  Lightweight agents deployed on mobile or edge devices require
       low-latency, cacheable discovery mechanisms.  DNS’s distributed
       architecture and support for SVCB hints (e.g., IP addresses,
       preferred protocols) enable efficient resolution and connection
       bootstrapping in constrained environments.

   5.  In regulated industries, agents must operate within
       jurisdictional boundaries and maintain audit trails of
       interactions.  DNS supports geographic scoping via ccTLDs and
       split-horizon configurations, while query logging and DNSSEC
       provide observability and integrity guarantees.

4.4.  Zone and Other Requirements

4.4.1.  Delegation and Chain of Trust

   A public authoritative zone used for the purposes of agent discovery
   MUST use DNSSEC [RFC4033].  The zone MUST establish a complete chain
   of trust to a publicly recognized trust anchor.  AI agents MUST use
   validating resolvers, or have the capability to validate records.

   All DNS-AID-specific discovery records (e.g. SVCB/HTTPS [RFC9460],
   TXT/URI [RFC7553] used for capability descriptors, and any DNS-
   AID-defined RRTypes) MUST be signed and published in the DNS-AID
   External Zone.  Where DNS-AID endpoints rely on TLS, publication of
   DANE TLSA records SHOULD be used to bind endpoint certificates to



Mozley, et al.           Expires 27 August 2026                [Page 10]

Internet-Draft                   DNS-AID                   February 2026


   DNSSEC-validated names [RFC6698][RFC7671].  Resolver behavior
   consuming DNS-AID data MUST treat DNSSEC-bogus responses as failures
   and MUST NOT act on unsigned or invalidly signed discovery data.

4.4.2.  Performance Optimization(s)

   Each agent service endpoint that is specifically published as a DNS
   record SHOULD be an SVCB record in ServiceMode (or HTTPS RR for HTTPS
   endpoints) to convey connection parameters and capability locators
   with a single lookup [RFC9460].  SVCB “address hints” (ipv4hint,
   ipv6hint) SHOULD be used to reduce A/AAAA follow-up queries;
   resolvers MAY still validate final addresses via canonical
   resolution.  Where human-friendly names are required, SVCB AliasMode
   (priority 0) MAY be used to map from a stable alias name to a
   canonical name.

   Authoritative servers MUST support EDNS(0) [RFC6891] and TCP fallback
   [RFC7766].  Operators SHOULD target response sizes that avoid IP
   fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring
   compression and layered indirection over oversized RRsets.  TTLs MUST
   be chosen to reflect the volatility of capability data; index/
   indirection records may use longer TTLs than frequently changing
   endpoint or capability descriptors.  Negative caching MUST conform to
   [RFC2308].  When high update rates are expected, IXFR and NOTIFY
   SHOULD be used to reduce propagation latency.

   A representative naming pattern is shown below; the exact label order
   is deployment-specific, but the leaf per service, per agent rule
   applies:

   ``` ; Hashed, per-agent, per-service leaf
   a4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-
   a4k2f9.example.org.  alpn="map,h2,h3" port=443 ipv6hint=2001:db8::5
   ipv4hint=192.0.2.5

   ; Optional alias for a friendlier owner name
   billing._mcp._agents.example.org. 300 IN SVCB 0
   a4k2f9._mcp._agents.example.org. ```

4.4.3.  Customization(s)

   DNS-AID deployments MAY define additional SVCB parameters
   (SvcParamKeys) to convey agent-specific capability metadata, provided
   that interoperability safeguards in [RFC9460] are observed.  During
   experimentation, unregistered keys MUST use the numeric keyNNNNN
   presentation form, and any client behavior that depends on them MUST
   be gated via the mandatory SvcParam to ensure downgrade safety.




Mozley, et al.           Expires 27 August 2026                [Page 11]

Internet-Draft                   DNS-AID                   February 2026


   This specification defines the following provisional SvcParamKeys for
   DNS-AID (names are illustrative; production deployments MUST register
   through IANA per [RFC9460] or use keyNNNNN until standardized):

   The following are example use cases for additional params:

   *  cap — a capability descriptor locator or inline identifier (e.g.,
      a URN or compact JSON-Ref) that identifies the agent’s advertised
      capability schema/version.

   *  cap-sha256 — a base64url-encoded SHA-256 digest of the canonical
      capability descriptor to support integrity checks and cache
      revalidation.

   *  policy — a URI or URN identifying a policy bundle applicable to
      this agent (e.g., jurisdiction, data handling class) for
      client-side selection.

   *  realm — an opaque token for multi-tenant scoping or authz realm
      selection during protocol bootstrapping.

   Clients that require any of these parameters MUST verify their
   presence via the mandatory key; otherwise, the SVCB record MUST be
   ignored.  Example:

   Single-RRTYPE publication with custom params (experimental keys
   shown) a4k2f9._mcp._agents.example.org. 600 IN SVCB 1 svc-
   a4k2f9.example.org.  alpn="h2" port=443 ipv4hint=192.0.2.5
   mandatory=alpn,port,key65001,key65002,key65010
   key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-
   sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0"
   key65010="bap=a2a/1,mcp/1"

   Where endpoints are HTTPS, the HTTPS RR variant SHOULD be used to
   co-locate transport parameters such as ECH with capability metadata;
   otherwise, generic SVCB MAY be used.  Future standardization SHOULD
   define the exact syntax (e.g., ABNF) and registry policy for these
   keys, including error handling for malformed or conflicting
   parameters.  Until registration is complete, deployments MUST treat
   unknown keyNNNNN parameters as opaque and MUST NOT infer semantics
   without out-of-band agreement.

5.  Implementation Guidance

5.1.  Discovery Usage Examples






Mozley, et al.           Expires 27 August 2026                [Page 12]

Internet-Draft                   DNS-AID                   February 2026


5.1.1.  Discovery Status 1 (Known Service and Domain)

   Query foobar._mcp._agents.example.com Figure 5:

   In this scenario, the AI Agent Client knows both the service type
   (mcp) and the authoritative domain (example.com) and performs a
   direct SVCB query.

      AI Agent Client
      wants to discover:   foobar._mcp._agents.example.com
      (mcp = service, foobar = agent/capability, example.com = trusted domain)

        Agent Client              Resolver / Cache         Root/TLD/Auth DNS
              │                           │                          │
              │   1. SVCB Query           │                          │
              │   (Recursive)             │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │                           │ 2. Query Root            │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 3. Referral to .com NS   │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │                           │ 4. Query .com TLD        │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 5. Referral to auth NS   │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │                           │ 6. Query Auth NS for     │
              │                           │    foobar._mcp._agents   │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 7. SVCB RRSet Response   │
              │                           │    (DNSSEC-signed)       │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │   8. SVCB Response        │                          │
              │   (cached + validated)    │                          │
              │◄──────────────────────────┤                          │
              │                           │                          │
              │   Response includes:      │                          │
              │   • Service target        │                          │
              │   • ALPN protocol(s)      │                          │
              │   • Port number           │                          │
              │   • IPv4/IPv6 hints       │                          │
              │   • DNSSEC signatures     │                          │



Mozley, et al.           Expires 27 August 2026                [Page 13]

Internet-Draft                   DNS-AID                   February 2026


              │   • Capabilities (cost,   │                          │
              │      modalities, etc)     │                          │
              │                           │                          │
              │   9. A2A, MCP, etc.       │                          │
              ├──────────────────────────►│                          │
              │   (Agent-to-Agent         │                          │
              │    communication begins)  │                          │
              │                           │                          │

  Figure 5: Discovery Status 1: SVCB Query with Full Chain Traversal

5.1.2.  Discovery Status 2 (Known Service OR Domain, Trusted)

   Query of the known organisation's index if service is unknown
   Figure 6:

   In this scenario, the Agent Client knows the trusted domain
   (example.com) but the specific agent service type is unknown.  The
   client queries a well-known index entry point to discover available
   agent capabilities.  The index query is not DNS.

      AI Agent Client
      knows:            example.com is trusted
      wants to discover: available agents and services
      queries:          _index._agents.example.com (well-known entry point)

        Agent Client              Resolver / Cache         Root/TLD/Auth DNS
              │                           │                          │
              │   1. SVCB Query           │                          │
              │   _index._agents          │                          │
              │   (Recursive)             │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │                           │ 2. Query Root            │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 3. Referral to .com NS   │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │                           │ 4. Query .com TLD        │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 5. Referral to auth NS   │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │                           │ 6. Query Auth NS for     │
              │                           │    _index._agents        │
              │                           ├─────────────────────────►│



Mozley, et al.           Expires 27 August 2026                [Page 14]

Internet-Draft                   DNS-AID                   February 2026


              │                           │                          │
              │                           │ 7. Index DNS Response    │
              │                           │    (SVCB RRSet or        │
              │                           │     CNAME/AliasMode)     │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │   8. Index Agent Response │                          │
              │   (cached + validated)    │                          │
              │◄──────────────────────────┤                          │
              │                           │                          │
              │   Response includes:      │                          │
              │   • List of agent types   │                          │
              │     (mcp, a2a, etc.)      │                          │
              │   • Service endpoints     │                          │
              │   • Capability metadata   │                          │
              │   • DNSSEC signatures     │                          │
              │                           │                          │
              │   9. Parse index, select  │                          │
              │      desired agent type   │                          │
              │      (e.g., mcp)          │                          │
              │                           │                          │
              │   10. Query specific      │                          │
              │       agent service       │                          │
              │       foobar._mcp._aiag...├─────────────────────────►│
              │                           │                          │
              │                           │ 11. Return service       │
              │                           │     details              │
              │◄──────────────────────────┤◄─────────────────────────┤
              │                           │                          │
              │   12. A2A, MCP, etc.      │                          │
              ├──────────────────────────►│                          │
              │   (Agent-to-Agent         │                          │
              │    communication begins)  │                          │
              │                           │                          │

   Figure 6: Discovery Status 2: Index-Based Discovery with Service
                              Selection

5.1.3.  Discovery Status 3 (Multi-Domain Query for Known Service)

   Query the same well-known agent name across multiple known domains
   (potential for this discovery case to be met by the registry
   described in Discovery Status 4):








Mozley, et al.           Expires 27 August 2026                [Page 15]

Internet-Draft                   DNS-AID                   February 2026


      AI Agent Client
      knows:            img2txt is a well-known agent type
      knows:            org1.com and org2.com are trusted domains
      wants to discover: which orgs have img2txt agents available

        Agent Client              Resolver / Cache         Root/TLD/Auth DNS
              │                           │              (ORG1 and ORG2)
              │                           │                          │
              │   1. SVCB Query           │                          │
              │   img2txt._a2a._agents    │                          │
              │   .org1.com               │                          │
              │   (Recursive)             │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │                           │ 2. Resolve .org1 chain   │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 3. Auth. DNS org1        │
              │                           │◄─────────────────────────┤
              │                           │    returns service info  │
              │                           │                          │
              │   4. Response (org1)      │                          │
              │   (cached + validated)    │                          │
              │◄──────────────────────────┤                          │
              │                           │                          │
              │   5. SVCB Query           │                          │
              │   img2txt._a2a._agents    │                          │
              │   .org2.com               │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │                           │ 6. Resolve .org2 chain   │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 7. Auth. DNS org2        │
              │                           │◄─────────────────────────┤
              │                           │    returns service info  │
              │                           │                          │
              │   8. Response (org2)      │                          │
              │   (cached + validated)    │                          │
              │◄──────────────────────────┤                          │
              │                           │                          │
              │   9. Client evaluates:    │                          │
              │   • Service capabilities  │                          │
              │     from both responses   │                          │
              │   • Trust levels (DNSSEC) │                          │
              │   • Cost, latency, etc.   │                          │
              │                           │                          │
              │   10. Select endpoint &   │                          │



Mozley, et al.           Expires 27 August 2026                [Page 16]

Internet-Draft                   DNS-AID                   February 2026


              │       A2A/protocol with   │                          │
              │       chosen provider     │                          │
              ├──────────────────────────►│                          │
              │   (Agent-to-Agent         │                          │
              │    communication begins)  │                          │
              │                           │                          │

Figure 7: Discovery Status 3: Parallel Multi-Domain Service Discovery

5.1.4.  Discovery Status 4 (Untrusted Domain / Consolidated Registry)

   Query a consolidated (reputable) registry (not DNS) when neither
   domain nor comprehensive service list is known:

      AI Agent Client
      knows:            a trusted registry (e.g., registry.ai-trust-community.org)
      wants to discover: all viable img2txt agents available (any org)
      scenario:         agent choice driven by capability, not domain affinity

        Agent Client              Resolver / Cache         Registry / Auth DNS
              │                           │                          │
              │   1. SVCB Query           │                          │
              │   _index._agents          │                          │
              │   .registry.ai-trust...   │                          │
              │   (Recursive)             │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │                           │ 2. Resolve registry      │
              │                           │    domain chain          │
              │                           ├─────────────────────────►│
              │                           │                          │
              │                           │ 3. Return registry       │
              │                           │◄─────────────────────────┤
              │                           │    index/catalog SVCB    │
              │                           │                          │
              │   4. Registry Index       │                          │
              │   (HTTP, JSON, etc)       │                          │
              │──────────────────────────►┤                          │
              │                           │                          │
              │                           │  5. Registry Response    │
              │                           │◄─────────────────────────┤
              │                           │                          │
              │                           │   Response contains:     │
              │                           │   • Ref list: img2txt    │
              │                           │     agents from multiple │
              │                           │     trusted orgs         │
              │                           │   • Domains + endpoints  │
              │                           │   • Aggregate ratings,   │



Mozley, et al.           Expires 27 August 2026                [Page 17]

Internet-Draft                   DNS-AID                   February 2026


              │                           │     SLA info, cost       │
              │                           │   • DNSSEC provenance    │
              │                           │   • Capabilities (cost,  │
              │                           │     modalities, etc)     │
              │                           │                          │
              │   6. Client evaluates     │                          │
              │   registry results        │                          │
              │   (may include one or     │                          │
              │    more followup queries  │                          │
              │    per Discovery Status 1 │                          │
              │    for additional detail) │                          │
              │                           │                          │
              │   7. Query chosen         │                          │
              │      agent's auth DNS     │                          │
              │      for final details    │                          │
              ├──────────────────────────►│                          │
              │                           │                          │
              │   8. A2A/protocol with    │                          │
              │      registry-selected    │                          │
              │      endpoint             │                          │
              ├──────────────────────────►│                          │
              │   (Agent-to-Agent         │                          │
              │    communication begins)  │                          │
              │                           │                          │

    Figure 8: Discovery Status 4: Registry-Based Discovery Across
                          Multiple Providers

5.1.5.  Discovery Status 4 (Unknown / Wildcard, or status 2 untrusted?)

   This case is out of scope.

5.2.  AI Providers

5.2.1.  Publishing Schema

   Publishers SHOULD expose per-service discovery records using SVCB (or
   HTTPS for HTTP origins) at stable, well-scoped owner names (e.g.,
   agent-id._mcp._agents.example.org.).  SVCB ServiceMode conveys
   connection parameters and capability locators in a single round trip;
   AliasMode MAY be used to map a friendly name to a hashed leaf for
   sharding without duplicating RRSets.  Initial connection parameter
   keys (alpn, port, address hints) and the mandatory key MUST be
   honored by clients.  [RFC9460]

   Minimal example:





Mozley, et al.           Expires 27 August 2026                [Page 18]

Internet-Draft                   DNS-AID                   February 2026


   ; ServiceMode SVCB for an MCP-capable agent
   a4k2f9._mcp._agents.example.org.  600 IN SVCB 1 svc-
   a4k2f9.example.net.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
   ipv4hint=192.0.2.5 mandatory=alpn,port

   SVCB/HTTPS semantics and SvcParam processing MUST follow [RFC9460] to
   ensure interop and correct fallback.

5.2.2.  TTLs, Update Agility

   Publishers SHOULD assign longer TTLs to relatively static indirection
   records (aliases, stable service labels) and shorter TTLs to volatile
   endpoint/capability records to balance cache efficiency with rollout
   safety.  Consumers will apply negative caching per [RFC2308], so
   publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments
   (e.g., prefer blue/green leaves over in-place deletions).

5.2.3.  Example DNS-AID Zonefile

   ``` $ORIGIN example.org. $TTL 3600

   ; -------------------------------------------------------------------
   --- ; SOA / NS ; ----------------------------------------------------
   ------------------ @ IN SOA ns1.example.org. hostmaster.example.org.
   ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry
   1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org.  IN NS
   ns2.example.org.

   ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2
   IN AAAA 2001:db8::54

   ; -------------------------------------------------------------------
   --- ; DNS-AID discovery (MCP example): per-service, per-agent leaf ;
   - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; -
   Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; 
   ---------------------------------------------------------------------
   -

   ; AliasMode to keep a friendly name stable even if the leaf changes
   billing._mcp._agents 300 IN SVCB 0 a4k2f9._mcp._agents.example.org.

   ; Leaf per agent/service (ServiceMode).  Shorter TTL for agility.
   a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \
   alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \
   mandatory=alpn,port






Mozley, et al.           Expires 27 August 2026                [Page 19]

Internet-Draft                   DNS-AID                   February 2026


   ; (Optional) Another service face for the same agent (A2A)
   a4k2f9._a2a._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \ alpn="h2"
   port=8443 \ mandatory=alpn,port

   ; (Optional) HTTPS RR at apex for web-style consumers of DNS-AID
   metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443

   ; -------------------------------------------------------------------
   --- ; Capability / policy signaling via SVCB custom keys
   (experimental) ; Use numeric keyNNNNN until you register IANA
   SvcParamKeys. ; Gate client requirements with "mandatory". ; --------
   -------------------------------------------------------------- ;
   Example: reference a capability descriptor and advertise supported
   app protocols. ; NOTE: Values and key numbers are illustrative.

   a4k2f9._mcp._agents 600 IN SVCB 1 svc-a4k2f9.example.net. \
   alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \
   key65001="cap=urn:cap:example:mcp:invoice.v1" \
   key65010="bap=a2a/1,mcp/1"

   ; -------------------------------------------------------------------
   --- ; Domain Control Validation (DCV) for DNS-AID authorization ;
   Publish a short-lived token to prove control over example.org. ;
   Remove after successful validation.  Resolver MUST DNSSEC-validate. ;
   ---------------------------------------------------------------------
   - _agents-challenge 300 IN TXT "bnd-req=svc:crm-
   sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z"

   ; -------------------------------------------------------------------
   --- ; Optional DANE TLSA for the service endpoint used above. ;
   Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1
   (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI
   hash of the leaf certificate. ; -------------------------------------
   --------------------------------- _443._tcp.svc-a4k2f9.example.net.
   1800 IN TLSA 3 1 1 (
   0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )

   ; -------------------------------------------------------------------
   --- ; (Optional) Address records for the service endpoint, if hosted
   in-zone ; If hosted out-of-zone (example.net), these will live there
   instead. ; ----------------------------------------------------------
   ------------ svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA
   2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA
   2001:db8::80 ```







Mozley, et al.           Expires 27 August 2026                [Page 20]

Internet-Draft                   DNS-AID                   February 2026


5.2.4.  How to use this zonefile

   *  Adjust TTLs for agility vs. cache efficiency.  Use longer TTLs on
      indirection (aliases), shorter TTLs on volatile leaves and DCV.
      This aligns with DNS caching behavior and negative caching rules
      [RFC2308].

   *  Follow SVCB/HTTPS semantics.  Clients must honor SvcPriority,
      AliasMode (priority 0), and ServiceMode parameters, including
      mandatory, alpn, port, and address hints per [RFC9460].

   *  DCV token flow.  Issue a time-bounded token at _agents-
      challenge.domain and require DNSSEC-validated retrieval (pattern
      analogous to ACME’s DNS-01 in [RFC8555]).  Remove on success.

   *  Bind transport to DNS with DANE (optional).  If your relying
      parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/
      key, using the operational guidance in [RFC7671] (TLSA record
      format in [RFC6698]).

   *  Sign the zone.  This file is pre-signing.  Sign with DNSSEC
      (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat
      unsigned/bogus discovery data as a failure (per your earlier
      spec).  See DNSSEC core specs [RFC4033], [RFC4034], [RFC4035] and
      operational guidance.

5.3.  Why these records

   *  SVCB/HTTPS concentrate connection metadata and allow aliasing at
      apex and service labels, reducing round trips and enabling
      policy-gated parameters via mandatory.

   *  Per-service, per-agent leaves avoid oversized RRsets and allow
      parallel administration/sharding while keeping alias names stable.
      This follows performance guidance in SVCB and your DNS-AID perf
      section.

   *  DCV via TXT mirrors a well-understood, automated control-proof
      pattern [RFC8555] that fits DNS-AID authorization workflows.

   *  DANE TLSA optionally removes reliance on external PKI anchors for
      endpoint auth where DNSSEC is deployed [RFC6698], with deployment
      rules in [RFC7671].








Mozley, et al.           Expires 27 August 2026                [Page 21]

Internet-Draft                   DNS-AID                   February 2026


6.  Future Work & Unaddressed Portions

   How a consolidated registry would operate?  Would it gather and
   publish information from individual organisations (scraping), would
   those organisations registery attest to security and be verified?

7.  Security Considerations

   DNSSEC security considerations apply.

8.  IANA Considerations

   IANA is requested to register an underscored attribute leaf as part
   of [RFC8552] for agents.

   IANA is requested to designate custom key-value pairs for SVCB
   parameters to facilitate agent-to-agent application discovery,
   potentially for cost optimization (token input counts, costs per
   token bundle, etc.)

9.  References

9.1.  Normative References

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

9.2.  Informative References

   [I-D.draft-ietf-dnsop-domain-verification-techniques]
              Sahib, S. K., Huque, S., Wouters, P., Nygren, E., and T.
              Wicinski, "Domain Control Validation using DNS", Work in
              Progress, Internet-Draft, draft-ietf-dnsop-domain-
              verification-techniques-11, 1 February 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              domain-verification-techniques-11>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <https://www.rfc-editor.org/rfc/rfc2308>.





Mozley, et al.           Expires 27 August 2026                [Page 22]

Internet-Draft                   DNS-AID                   February 2026


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

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

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

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/rfc/rfc6698>.

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

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

   [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", RFC 7553,
              DOI 10.17487/RFC7553, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7553>.

   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
              Authentication of Named Entities (DANE) Protocol: Updates
              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
              October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/rfc/rfc7766>.

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8552>.



Mozley, et al.           Expires 27 August 2026                [Page 23]

Internet-Draft                   DNS-AID                   February 2026


   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8555>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

Acknowledgments

   The authors thank Ben Schwartz and Ross Gibson for their
   contributions, questions, and comments.

Authors' Addresses

   Jim Mozley
   Infoblox, Inc.
   Email: jmozley@infoblox.com


   Nic Williams
   Infoblox, Inc.
   Email: nic@infoblox.com


   Behcet Sarikaya
   Unaffiliated
   Email: sarikaya@ieee.org


   Roland Schott
   Deutsche Telekom
   Email: roland.schott@telekom.de
















Mozley, et al.           Expires 27 August 2026                [Page 24]


name: draft-ietf-anima-brski-prm
rev: 23
title: BRSKI with Pledge in Responder Mode (BRSKI-PRM)
time: 2025-06-07T14:05:30Z
group_uri: /api/v1/group/group/1956/
expires: 2025-12-05T15:40:46Z
ad: /api/v1/person/person/107859/
shepherd: /api/v1/person/email/ietf@kovatsch.net/
categories: ["Agent identity/auth", "Autonomous netops"]
tags: []
fetched_at: 2026-02-27T22:56:05.127495+00:00
abstract:
This document defines enhancements to Bootstrapping Remote Secure Key
   Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
   Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
   devices, referred to as pledges, into a domain where direct
   communication with the registrar is either limited or not possible at
   all.  To facilitate interaction between a pledge and a domain
   registrar the registrar-agent is introduced as new component.  The
   registrar-agent supports the reversal of the interaction model from a
   pledge-initiated mode, to a pledge-responding mode, where the pledge
   is in a server role.  To establish the trust relation between pledge
   and registrar, BRSKI-PRM relies on object security rather than
   transport security.  This approach is agnostic to enrollment
   protocols that connect a domain registrar to a key infrastructure
   (e.g., domain Certification Authority).

states:
["/api/v1/doc/state/1/", "/api/v1/doc/state/154/", "/api/v1/doc/state/115/", "/api/v1/doc/state/12/", "/api/v1/doc/state/44/"]

full_text:
ANIMA WG                                                        S. Fries
Internet-Draft                                                 T. Werner
Intended status: Standards Track                                 Siemens
Expires: 5 December 2025                                         E. Lear
                                                           Cisco Systems
                                                           M. Richardson
                                                Sandelman Software Works
                                                             3 June 2025


            BRSKI with Pledge in Responder Mode (BRSKI-PRM)
                     draft-ietf-anima-brski-prm-23

Abstract

   This document defines enhancements to Bootstrapping Remote Secure Key
   Infrastructure (BRSKI, RFC8995) as BRSKI with Pledge in Responder
   Mode (BRSKI-PRM).  BRSKI-PRM supports the secure bootstrapping of
   devices, referred to as pledges, into a domain where direct
   communication with the registrar is either limited or not possible at
   all.  To facilitate interaction between a pledge and a domain
   registrar the registrar-agent is introduced as new component.  The
   registrar-agent supports the reversal of the interaction model from a
   pledge-initiated mode, to a pledge-responding mode, where the pledge
   is in a server role.  To establish the trust relation between pledge
   and registrar, BRSKI-PRM relies on object security rather than
   transport security.  This approach is agnostic to enrollment
   protocols that connect a domain registrar to a key infrastructure
   (e.g., domain Certification Authority).

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-anima-brski-prm/.

   Source for this draft and an issue tracker can be found at
   https://github.com/anima-wg/anima-brski-prm.

Status of This Memo

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







Fries, et al.            Expires 5 December 2025                [Page 1]

Internet-Draft                  BRSKI-PRM                      June 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 5 December 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  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Scope of Solution . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Supported Environments and Use Case Examples  . . . . . .   8
       3.1.1.  Building Automation . . . . . . . . . . . . . . . . .   9
       3.1.2.  Infrastructure Isolation Policy . . . . . . . . . . .   9
       3.1.3.  Less Operational Security in the Target-Domain  . . .  10
     3.2.  Potential Limitations . . . . . . . . . . . . . . . . . .  10
   4.  Requirements Discussion and Mapping to BRSKI-PRM Functional
           Elements  . . . . . . . . . . . . . . . . . . . . . . . .  10
     4.1.  TLS support required  . . . . . . . . . . . . . . . . . .  12
   5.  Solution Architecture . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Nomadic Connectivity  . . . . . . . . . . . . . . . . . .  16
     5.3.  Co-located Registrar-Agent and Domain Registrar . . . . .  18
     5.4.  Agent Proximity Assertion . . . . . . . . . . . . . . . .  19
   6.  System Components . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Registrar-Agent . . . . . . . . . . . . . . . . . . . . .  20
       6.1.1.  Discovery of the Registrar  . . . . . . . . . . . . .  22
       6.1.2.  Discovery of the Pledge . . . . . . . . . . . . . . .  22



Fries, et al.            Expires 5 December 2025                [Page 2]

Internet-Draft                  BRSKI-PRM                      June 2025


     6.2.  Pledge in Responder Mode  . . . . . . . . . . . . . . . .  24
       6.2.1.  Pledge with Combined Functionality  . . . . . . . . .  25
       6.2.2.  Pledgestatus "reason-context" Values  . . . . . . . .  25
       6.2.3.  Voucher Status and Enroll Status Telemetry
               "reason-context" Values . . . . . . . . . . . . . . .  26
     6.3.  Domain Registrar  . . . . . . . . . . . . . . . . . . . .  27
       6.3.1.  Domain Registrar with Combined Functionality  . . . .  28
     6.4.  MASA  . . . . . . . . . . . . . . . . . . . . . . . . . .  28
   7.  Exchanges and Artifacts . . . . . . . . . . . . . . . . . . .  29
     7.1.  Trigger Pledge Voucher-Request  . . . . . . . . . . . . .  33
       7.1.1.  Request Artifact: Pledge Voucher-Request Trigger
               (tPVR)  . . . . . . . . . . . . . . . . . . . . . . .  35
       7.1.2.  Response Artifact: Pledge Voucher-Request (PVR) . . .  37
     7.2.  Trigger Pledge Enroll-Request . . . . . . . . . . . . . .  39
       7.2.1.  Request Artifact: Pledge Enroll-Request Trigger
               (tPER)  . . . . . . . . . . . . . . . . . . . . . . .  41
       7.2.2.  Response Artifact: Pledge Enroll-Request (PER)  . . .  42
     7.3.  Supply PVR to Registrar (including MASA interaction)  . .  44
       7.3.1.  MASA Interaction  . . . . . . . . . . . . . . . . . .  47
       7.3.2.  Supply Voucher to Registrar-Agent . . . . . . . . . .  49
       7.3.3.  Request Artifact: Pledge Voucher-Request (PVR)  . . .  49
       7.3.4.  Backend Request Artifact: Registrar Voucher-Request
               (RVR) . . . . . . . . . . . . . . . . . . . . . . . .  50
       7.3.5.  Backend Response Artifact: Voucher  . . . . . . . . .  52
       7.3.6.  Response Artifact: Registrar-Countersigned Voucher  .  52
     7.4.  Supply PER to Registrar (including Key Infrastructure
            interaction; requestenroll)  . . . . . . . . . . . . . .  54
       7.4.1.  Request Artifact: Pledge Enroll-Request (PER) . . . .  57
       7.4.2.  Response Artifact: Registrar Enroll-Response
               (Enroll-Resp) . . . . . . . . . . . . . . . . . . . .  57
     7.5.  Obtain CA Certificates (wrappedcacerts) . . . . . . . . .  57
       7.5.1.  Request (no artifact) . . . . . . . . . . . . . . . .  58
       7.5.2.  Response Artifact: CA-Certificates (caCerts)  . . . .  58
     7.6.  Supply Voucher to Pledge (svr)  . . . . . . . . . . . . .  61
       7.6.1.  Request Artifact: Registrar-Countersigned Voucher . .  63
       7.6.2.  Response Artifact: Voucher Status (vStatus) . . . . .  63
     7.7.  Supply CA Certificates to Pledge (scac) . . . . . . . . .  66
       7.7.1.  Request Artifact: CA-Certificates (caCerts) . . . . .  67
       7.7.2.  Response (no artifact)  . . . . . . . . . . . . . . .  67
     7.8.  Supply Enroll-Response to Pledge (ser)  . . . . . . . . .  68
       7.8.1.  Request Artifact: Enroll-Response (Enroll-Resp) . . .  69
       7.8.2.  Response Artifact: Enroll Status (eStatus)  . . . . .  69
     7.9.  Voucher Status Telemetry (including MASA interaction) . .  71
       7.9.1.  Request Artifact: Voucher Status (vStatus)  . . . . .  73
       7.9.2.  Response (no artifact)  . . . . . . . . . . . . . . .  73
     7.10. Enroll Status Telemetry . . . . . . . . . . . . . . . . .  73
       7.10.1.  Request Artifact: Enroll Status (eStatus)  . . . . .  74
       7.10.2.  Response (no artifact) . . . . . . . . . . . . . . .  74



Fries, et al.            Expires 5 December 2025                [Page 3]

Internet-Draft                  BRSKI-PRM                      June 2025


     7.11. Query Pledge Status (qps) . . . . . . . . . . . . . . . .  75
       7.11.1.  Request Artifact: Status Trigger (tStatus) . . . . .  76
       7.11.2.  Response Artifact: Pledge Status (pStatus) . . . . .  79
   8.  Logging Considerations  . . . . . . . . . . . . . . . . . . .  83
   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  85
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  86
     10.1.  BRSKI Well-Known URIs  . . . . . . . . . . . . . . . . .  86
     10.2.  Service Name and Transport Protocol Port Number
            Registry . . . . . . . . . . . . . . . . . . . . . . . .  87
   11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  87
     11.1.  Registrar-Agent identity Privacy Considerations  . . . .  88
     11.2.  Registar-Agent/Pledge communications . . . . . . . . . .  88
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  89
     12.1.  Denial of Service (DoS) Attack on Pledge . . . . . . . .  90
     12.2.  Misuse of acquired PVR and PER by Registrar-Agent  . . .  90
     12.3.  Misuse of Registrar-Agent  . . . . . . . . . . . . . . .  91
     12.4.  Misuse of DNS-SD with mDNS to obtain list of pledges . .  91
     12.5.  YANG Module Security Considerations  . . . . . . . . . .  92
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  92
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  92
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  92
     14.2.  Informative References . . . . . . . . . . . . . . . . .  94
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  98
     A.1.  Example Pledge Voucher-Request (PVR) - from Pledge to
           Registrar-Agent . . . . . . . . . . . . . . . . . . . . .  98
     A.2.  Example Registrar Voucher-Request (RVR) - from Registrar to
           MASA  . . . . . . . . . . . . . . . . . . . . . . . . . .  99
     A.3.  Example Voucher - from MASA to Pledge, via Registrar and
           Registrar-Agent . . . . . . . . . . . . . . . . . . . . . 102
     A.4.  Example Voucher, MASA issued Voucher with additional
           Registrar signature (from MASA to Pledge, via Registrar and
           Registrar-Agent)  . . . . . . . . . . . . . . . . . . . . 103
   Appendix B.  HTTP-over-TLS operations between Registrar-Agent and
           Pledge  . . . . . . . . . . . . . . . . . . . . . . . . . 105
   Appendix C.  History of Changes "RFC Editor: please delete" . . . 106
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . . 122
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 123

1.  Introduction

   BRSKI as defined in [RFC8995] specifies a solution for secure zero-
   touch (automated) bootstrapping of devices (pledges) in a customer
   domain, which may be associated with a specific installation
   location.  This includes the discovery of the BRSKI registrar in the
   customer domain and the exchange of security information necessary to
   establish trust between a pledge and the domain.





Fries, et al.            Expires 5 December 2025                [Page 4]

Internet-Draft                  BRSKI-PRM                      June 2025


   Security information pertaining to the customer domain, specifically,
   the customer domain certificate, is exchanged and authenticated
   through the use of signed data objects, namely the voucher artifacts,
   as defined in [I-D.ietf-anima-rfc8366bis].  In response to a voucher-
   request, the Manufacturer Authorized Signing Authority (MASA) issues
   the voucher and provides it via the domain registrar to the pledge.
   [I-D.ietf-anima-rfc8366bis] specifies the format of the voucher
   artifacts, including the voucher-request artifact.

   For the certificate enrollment of devices, BRSKI relies on Enrollment
   over Secure Transport (EST, [RFC7030]) to request and distribute
   customer domain specific device certificates.  EST in turn relies for
   the authentication and authorization of the certification request on
   the credentials used by the underlying TLS between the EST client and
   an EST server.

   BRSKI addresses scenarios in which a pledge initiates the
   bootstrapping acting as client (referred to as initiator mode by this
   document).  BRSKI with Pledge in Responder Mode (BRSKI-PRM) defined
   in this document allows the pledge to act as server, so that it can
   be triggered externally and at a specific time to generate
   bootstrapping requests in the customer domain.  For this approach,
   this document:

   *  defines additional endpoints for the domain registrar and new
      endpoints for the pledge to enable responder mode.

   *  introduces the Registrar-Agent as new component to facilitate the
      communication between the pledge and a domain registrar.  The
      Registrar-Agent may be implemented as an integrated functionality
      of a commissioning tool or be co-located with the domain registrar
      itself.  BRSKI-PRM supports the identification of the Registrar-
      Agent that was performing the bootstrapping allowing for
      accountability of the pledges installation, when the Registrar-
      Agent is a component used by an installer and not co-located with
      the domain registrar.

   *  specifies additional artifacts for the exchanges between a pledge
      acting as server, the Registrar-Agent acting as client, and the
      domain registrar acting as server toward the Registrar-Agent.

   *  allows the application of Registrar-Agent credentials to establish
      TLS connections to a domain registrar; these are different from
      the pledge IDevID credentials.

   *  also enables the usage of alternative transports, both IP-based
      and non-IP (e.g., Bluetooth-based or NFC-based communication),
      between the pledge and the domain registrar via the Registrar-



Fries, et al.            Expires 5 December 2025                [Page 5]

Internet-Draft                  BRSKI-PRM                      June 2025


      Agent; security is addressed at the application layer through
      object security with an additional signature wrapping the
      exchanged artifacts.

   The term endpoint used in the context of this document is equivalent
   to resource in HTTP [RFC9110] and CoAP [RFC7252]; it is not used to
   describe a device.  Endpoints are accessible via Well-Known URIs
   [RFC8615].

   To utilize EST [RFC7030] for enrollment, the domain registrar
   performs pre-processing of the wrapping signature before actually
   using EST as defined in [RFC7030].

   There may be pledges that can support both modes, initiator and
   responder mode.  In these cases, BRSKI-PRM can be combined with BRSKI
   as defined in [RFC8995] or BRSKI-AE [RFC9733] to allow for more
   bootstrapping flexibility.  Providing information about capabilities
   of BRSKI components like the pledge or registrar is handled as part
   of the discovery.  BRSKI-PRM relies only on a minimum necessary set
   of capabilities for the interaction and leaves the definition of more
   advanced mechanisms allowing to signal specific capabilities to
   [I-D.ietf-anima-brski-discovery].

2.  Terminology

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

   This document makes use of the terms defined in Section 1.2 of
   [RFC8995].  The following terms are defined in addition:

   authenticated self-contained object:  Describes a data object, which
      is cryptographically bound to an end entity (EE) certificate.  The
      binding is assumed to be provided through a digital signature of
      the actual object using the corresponding private key of the
      certificate.

   CA:  Certification Authority.  An entity, which issues certificates
      and maintains certificate revocation information.

   CMS:  Cryptographic Message Syntax, as defined in [RFC5652].

   Commissioning tool:  Tool to interact with devices to provide
      configuration data.




Fries, et al.            Expires 5 December 2025                [Page 6]

Internet-Draft                  BRSKI-PRM                      June 2025


   CSR:  Certificate Signing Request, as defined in [RFC2986].

   Domain registrar:  An entity in the customer domain, which
      facilitates the interaction of a pledge or Registrar-Agent with a
      manufacturer service (MASA).  It operates as BRSKI-EST server for
      the pledge when requesting vouchers and certificates and acts as
      the client BRSKI-MASA client when requesting vouchers from the
      MASA.  This component was introduced in [RFC8995].

   Drop ship:  delivery of a component or product.  This component was
      introduced in [RFC8995].

   EE:  End entity, as defined in [RFC9483].  Typically, a device or
      service that owns a public-private key pair for which it manages a
      public key certificate.

   EE certificate:  the certificate of the EE signed by its owner (e.g.,
      CA).  For domain components, the EE certificate is signed by the
      domain owner.  For the pledge, the EE certificate is either the
      IDevID certificate signed by the manufacturer or the LDevID
      certificate signed by the domain owner or an application-specific
      EE certificate signed by the domain owner.

   endpoint:  Term equivalent to resource in HTTP [RFC9110].  Endpoints
      are accessible via Well-Known URIs [RFC8615].

   IDevID:  An Initial Device Identifier X.509 certificate installed by
      the vendor on new equipment.  This is a term from 802.1AR
      [IEEE-802.1AR].

   LDevID:  A Local Device Identifier X.509 certificate installed by the
      owner of the equipment.  This is a term from 802.1AR
      [IEEE-802.1AR].

   mTLS:  mutual Transport Layer Security, refers to mutual
      authenticated TLS as specified in [RFC8446].

   PER:  Pledge Enroll-Request is a signature-wrapped CSR, signed by the
      pledge that requests enrollment to a domain via the Registrar-
      Agent.

   POI:  Proof-of-Identity, as defined in [RFC5272].

   POP:  Proof-of-Possession (of a private key), as defined in
      [RFC5272].

   PVR:  Pledge Voucher-Request is a signature-wrapped voucher-request,




Fries, et al.            Expires 5 December 2025                [Page 7]

Internet-Draft                  BRSKI-PRM                      June 2025


      signed by the pledge that sends it to the domain registrar via the
      Registrar-Agent.

   RA:  Registration Authority, an optional system component to which a
      CA delegates certificate management functions such as
      authorization checks.  In BRSKI-PRM, this is a functionality of
      the domain registrar, as in BRSKI [RFC8995].

   Registrar-Agent:  Component facilitating the data exchange between a
      pledge in responder mode and a domain registrar.

   RVR:  Registrar Voucher-Request is a signature-wrapped voucher-
      request, signed by the domain registrar that sends it to the MASA.
      For BRSKI-PRM, it contains a copy of the original PVR received
      from the pledge.

   This document uses the following encoding notations in the given JWS-
   signed artifact examples:

   BASE64(OCTETS):  Denotes the base64 encoding of an octet sequence
      using the character set defined in Section 4 of [RFC4648] and
      without the inclusion of any line breaks, whitespace, or other
      additional characters.  Note that the base64 encoding of the empty
      octet sequence is the empty string.

   BASE64URL(OCTETS):  Denotes the base64url encoding of an octet
      sequence, per Section 2 of [RFC7515].

   UTF8(STRING):  Denotes the octet sequence of the UTF-8 [RFC3629]
      representation of STRING, per Section 1 of [RFC7515].

   This document includes many examples that would contain many long
   sequences of base64-encoded objects with no content directly
   comprehensible to a human reader.  In order to keep those examples
   short, they use the token base64encodedvalue== as a placeholder for
   base64 data.  The full base64 data is included in the appendices of
   this document.  Note, base64-encoded values are mainly used for
   fields related to certificates like: x5bag, x5c, agent-provided-
   proximity-registrar-cert, p10-csr

3.  Scope of Solution

3.1.  Supported Environments and Use Case Examples

   BRSKI-PRM is applicable to scenarios where pledges may have no direct
   connection to a domain registrar, may have no continuous connection,
   or require coordination of the pledge requests to be provided to a
   domain registrar.



Fries, et al.            Expires 5 December 2025                [Page 8]

Internet-Draft                  BRSKI-PRM                      June 2025


   This can be motivated by pledges deployed in environments not yet
   connected to the operational customer domain network, e.g., at a
   building construction site, or environments intentionally
   disconnected from the Internet, e.g., critical industrial facilities.
   Another example is the assembly of electrical cabinets, which are
   prepared in advance before the installation at a customer domain.

3.1.1.  Building Automation

   In building automation, a typical use case exists where a detached
   building or the basement is equipped with sensors, actuators, and
   controllers, but with only limited or no connection to the central
   building management system.  This limited connectivity may exist
   during installation time or also during operation time.

   During the installation, for instance, a service technician collects
   the device-specific information from the basement network and
   provides them to the central building management system.  This could
   be done using a laptop, common mobile device, or dedicated
   commissioning tool to transport the information.  The service
   technician may successively collect device-specific information in
   different parts of the building before connecting to the domain
   registrar for bulk bootstrapping.

   A domain registrar may be part of the central building management
   system and already be operational in the installation network.  The
   central building management system can then provide operational
   parameters for the specific devices in the basement or other detached
   areas.  These operational parameters may comprise values and settings
   required in the operational phase of the sensors/actuators, among
   them a certificate issued by the operator to authenticate against
   other components and services.  These operational parameters are then
   provided to the devices in the basement facilitated by the service
   technician's laptop.  The Registrar-Agent, defined in this document,
   may be run on the technician's laptop to interact with pledges.

3.1.2.  Infrastructure Isolation Policy

   This refers to any case in which the network infrastructure is
   normally isolated from the Internet as a matter of policy, most
   likely for security reasons.  In such a case, limited access to a
   domain registrar may be allowed in carefully controlled short periods
   of time, for example when a batch of new devices are deployed, but
   prohibited at other times.







Fries, et al.            Expires 5 December 2025                [Page 9]

Internet-Draft                  BRSKI-PRM                      June 2025


3.1.3.  Less Operational Security in the Target-Domain

   The registration authority (RA) performing the authorization of a
   certificate request is a critical PKI component and therefore
   requires higher operational security than other components utilizing
   the issued certificates.  CAs may also require higher security in the
   registration procedures.  There may be situations in which the
   customer domain does not offer enough physical security to operate an
   RA/CA and therefore this service is transferred to a backend that
   offers a higher level of operational security.

3.2.  Potential Limitations

   The mechanism described in this document presumes the ability of the
   pledge and the Registrar-Agent to communicate with one another.  This
   may not be possible in constrained environments where, in particular,
   power must be conserved.  In these situations, it is anticipated that
   the transceiver will be powered down most of the time.  This presents
   a rendezvous problem: the pledge is unavailable for certain periods
   of time, and the Registrar-Agent is similarly presumed to be
   unavailable for certain periods of time.  To overcome this situation,
   the pledges may need to be powered on, either manually or by sending
   a trigger signal.

4.  Requirements Discussion and Mapping to BRSKI-PRM Functional Elements

   Based on the intended target environment described in Section 3.1,
   the following boundary conditions are derived to support
   bootstrapping of pledges in responder mode (acting as server):

   *  To facilitate the communication between a pledge in responder mode
      and a registrar, additional functionality is needed either on the
      registrar or as a stand-alone component.  This new functionality
      is defined as Registrar-Agent and acts as an agent of the
      registrar to trigger the pledge to generate requests for voucher
      and enrollment.  These requests are then provided by the
      Registrar-Agent to the registrar.  This requires the definition of
      pledge endpoints to allow interaction with the Registrar-Agent.

   *  The security of communication between the Registrar-Agent and the
      pledge does not rely on Transport Layer Security (TLS) to enable
      application of BRSKI-PRM in environments, in which the
      communication between the Registrar-Agent and the pledge is done
      over other technologies like Bluetooth Low Energy (BLE) or NFC,
      which may not support TLS protected communication.  In addition,
      the pledge does not have a certificate that can easily be verified
      by [RFC9525] methods.




Fries, et al.            Expires 5 December 2025               [Page 10]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  The use of authenticated self-contained objects addresses both,
      the TLS connection establishment challenges and the technology
      stack challenge.  Note that the chosen approach does not provide
      confidentiality for the self-contained object, which can be
      provided by employing TLS.

   *  By contrast, the Registrar-Agent can be authenticated by the
      registrar as a component, acting on behalf of the registrar.  In
      addition, the registrar must be able to verify, which Registrar-
      Agent was in direct contact with the pledge.

   *  It would be inaccurate for the voucher-request and voucher-
      response to use the assertion type proximity in the voucher, as
      the pledge was not in direct contact with the registrar for
      bootstrapping.  Therefore, a new assertion type is necessary for
      distinguishing assertions the MASA can state.

   At least the following properties are required for the voucher and
   enrollment processing:

   *  POI: provides data-origin authentication of an artifact, e.g., a
      voucher-request or an Enroll-Request, utilizing an existing
      IDevID.  Certificate updates may utilize the certificate that is
      to be updated.

   *  POP: proves that an entity possesses and controls the private key
      corresponding to the public key contained in the certification
      request, typically by adding a signature computed using the
      private key to the certification request.

   Solution examples based on existing technology are provided with the
   focus on existing IETF RFCs:

   *  Voucher-Requests and Vouchers as used in [RFC8995] already provide
      both, POP and POI, through a digital signature to protect the
      integrity of the voucher, while the corresponding signing
      certificate contains the identity of the signer.

   *  Enroll-Requests are data structures containing the information
      from a requester for a CA to create a certificate.  The
      certification request format in BRSKI is PKCS#10 [RFC2986].  In
      PKCS#10, the structure is signed to ensure integrity protection
      and POP of the private key of the requester that corresponds to
      the contained public key.  In the application examples, this POP
      alone is not sufficient.  A POI is also required for the
      certification request and therefore the certification request
      needs to be additionally bound to the existing pledge IDevID
      credential.  This binding supports the authorization decision for



Fries, et al.            Expires 5 December 2025               [Page 11]

Internet-Draft                  BRSKI-PRM                      June 2025


      the certification request and may be provided directly with the
      certification request.  While BRSKI uses the binding to TLS,
      BRSKI-PRM aims at an additional signature of the PKCS#10 using
      existing credentials on the pledge (IDevID).  This allows the
      process to be independent of the selected transport.

4.1.  TLS support required

   As already stated in [RFC8995], and required by
   [I-D.ietf-uta-require-tls13], the use of TLS 1.3 (or newer) is
   encouraged.  TLS 1.2 or newer is REQUIRED on the Registrar-Agent
   side.  TLS 1.3 (or newer) SHOULD be available on the registrar, but
   TLS 1.2 MAY be used.  TLS 1.3 (or newer) SHOULD be available on the
   MASA, but TLS 1.2 MAY be used.

   [I-D.ietf-uta-require-tls13] allows for continued use of TLS 1.2 for
   operational reasons.  [RFC8995] specified TLS 1.2 was the minimum,
   consistent with [RFC8996].  [RFC8995] requires mutual TLS, and many
   frameworks, embedded SDKs and hardware load balancers did not, at the
   time of writing, have APIs that permitted mutual TLS to be done
   consistently across TLS 1.2 and TLS 1.3.  While TLS 1.3 is common in
   browsers, the use of mutual TLS with 1.3 is uncommon in browsers, and
   so working support for mutual TLS in frameworks is also uncommon.

   On the Registrar and MASA side, mutual TLS authentication combined
   with hardware TLS offload requires specific support for extensions
   such as [RFC9440] or an equivalent.  TLS 1.2 and TLS 1.3 do client
   authentication at a different point in the state machine, and not all
   frameworks support both at the time of this writing.

   Many security certification schemes, such as FIPS-140, do not certify
   source code, but rather the resulting binary executable.  Even while
   TLS 1.3 source code is available, and new software can be added to
   existing platforms, replacing the TLS libraries on many embedded
   systems requires that the SDK vendor recertify the platform first.
   In industrial settings, these platforms have long lifecycles, and it
   takes some time to recertify all platforms.

   Thus, [RFC8995] and this document can not turn off TLS 1.2 until all
   parts of the ecosystem can run TLS 1.3.  That does not stop any of
   the parts of this ecosystem from deploying TLS 1.3 when possible, and
   for each part of the two or three transactions from negotiating TLS
   1.3 in preference to TLS 1.2.

5.  Solution Architecture






Fries, et al.            Expires 5 December 2025               [Page 12]

Internet-Draft                  BRSKI-PRM                      June 2025


5.1.  Overview

   For BRSKI-PRM, the base system architecture defined in BRSKI
   [RFC8995] is enhanced to facilitate new use cases in which the pledge
   acts as server.  The responder mode allows delegated bootstrapping
   using a Registrar-Agent instead of a direct connection between the
   pledge and the domain registrar.

   Necessary enhancements to support authenticated self-contained
   objects for certificate enrollment are kept at a minimum to enable
   reuse of already defined architecture elements and interactions.  The
   format of the bootstrapping objects produced or consumed by the
   pledge is usually based on JSON Web Signature (JWS) [RFC7515] and
   further specified in Section 7 to address the requirements stated in
   Section 4.  In constrained environments, it may be based on COSE
   [RFC9052].

   An abstract overview of the BRSKI-PRM protocol can be found on slide
   8 of [BRSKI-PRM-abstract].

   To support mutual trust establishment between the domain registrar
   and pledges not directly connected to the customer domain, this
   document specifies the exchange of authenticated self-contained
   objects with the help of the Registrar-Agent.

   This leads to extensions of the logical components in the BRSKI
   architecture as shown in Figure 1.

   Note that the Join Proxy is not shown in the figure.  In certain
   situations the Join Proxy may still be present and could be used by
   the Registrar-Agent to connect to the Registrar.  For example, a
   Registrar-Agent application on a smartphone often can connect to
   local Wi-Fi without giving up their cellular network connection
   [androidnsd], but only can make link-local connections.

   The Registrar-Agent interacts with the pledge to transfer the
   required data objects for bootstrapping, which are then also
   exchanged between the Registrar-Agent and the domain registrar.  The
   addition of the Registrar-Agent influences the sequences of the data
   exchange between the pledge and the domain registrar described in
   [RFC8995].  To enable reuse of BRSKI defined functionality as much as
   possible, BRSKI-PRM:

   *  uses existing endpoints where the required functionality is
      provided.

   *  enhances existing endpoints with new supported media types, e.g.,
      for JWS voucher.



Fries, et al.            Expires 5 December 2025               [Page 13]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  defines new endpoints where additional functionality is required,
      e.g., for wrapped certification request, wrapped CA certificates,
      and new status information.

                                  +---------------------------+
             ..... Drop Ship .....| Vendor Services           |
             :                    +---------------+-----------+
             :                    | M anufacturer |           |
             :                    | A uthorized   | Ownership |
             :                    | S igning      | Tracker   |
             :                    | A uthority    |           |
             :                    +---------------+-----------+
             :                                         ^
             :                                         | BRSKI-
             :                                         | MASA
             :          ...............................|.........
             V          .                              v        .
         +--------+     .  +------------+        +-----------+  .
         |        |     .  |            |        |           |  .
         | Pledge | BRSKI- | Registrar- | BRSKI- | Domain    |  .
         |        |  PRM   | Agent      |  PRM   | Registrar |  .
         |        |<------>|            |<------>|           |  .
         |        |     .  |   EE cert. |        |  EE cert. |  .
         |        |     .  +------------+        +-----+-----+  .
         | IDevID |     .                              |        .
         |        |     .           +------------------+-----+  .
         +--------+     .           | Key Infrastructure     |  .
                        .           | (e.g., PKI CA)         |  .
                        .           +------------------------+  .
                        .........................................
                                     Customer Domain

      Figure 1: BRSKI-PRM architecture overview using Registrar-Agent

   Figure 1 shows the relations between the following main components:

   *  Pledge: Is expected to respond with the necessary data objects for
      bootstrapping to a Registrar-Agent.  The protocol used between the
      pledge and the Registrar-Agent is assumed to be HTTP(S) in the
      context of this document.  Any other protocol can be used as long
      as it supports the exchange of the necessary artifacts.  This
      includes CoAP or protocols to be used over Bluetooth or NFC
      connections.  A pledge acting as server leads to the following
      differences compared to BRSKI [RFC8995]:

      -  The pledge no longer initiates bootstrapping, but is discovered
         and triggered by a Registrar-Agent as defined in Section 6.1.2.




Fries, et al.            Expires 5 December 2025               [Page 14]

Internet-Draft                  BRSKI-PRM                      June 2025


      -  The pledge offers additional endpoints as defined in
         Section 6.2, so that a Registrar-Agent can request data
         required for bootstrapping the pledge.

      -  The pledge includes additional data in the PVR, which is
         provided and signed by a Registrar-Agent as defined in
         Section 7.1.  This allows the registrar to identify with which
         Registrar-Agent the pledge was in contact (see Section 5.4).

      -  The artifacts exchanged between the pledge and the registrar
         via the Registrar-Agent are authenticated self-contained
         objects (i.e., signature-wrapped artifacts).

   *  Registrar-Agent: Is a new component defined in Section 6.1 that
      provides a store and forward communication path to exchange data
      objects between the pledge and a domain registrar.  This is for
      situations in which a domain registrar is not directly reachable
      by the pledge, which may be due to a different technology stacks
      or due to missing connectivity.  A Registrar-Agent acting as
      client leads to the following new aspects:

      -  The order of exchanges in the BRSKI-PRM call flow is different
         from that in BRSKI [RFC8995], as the Registrar-Agent can
         trigger one or more pledges and collects the PVR and PER
         artifacts simultaneously as defined in Section 7.  This enables
         bulk bootstrapping of several devices.

      -  There is no trust assumption between the pledge and the
         Registrar-Agent as only authenticated self-contained objects
         are used, which are transported via the Registrar-Agent and
         provided either by the pledge or the domain registrar.

      -  The trust assumption between the Registrar-Agent and the domain
         registrar may be based on EE certificates that are both signed
         by the domain owner.

      -  The Registrar-Agent may be realized as stand-alone component
         supporting nomadic activities of a service technician moving
         between different installation sites.

      -  Alternatively, the Registrar-Agent may also be realized as co-
         located functionality for a registrar, to support pledges in
         responder mode.

   *  Join Proxy (not shown): Has the same functionality as described in
      [RFC8995] if needed.  Note that a Registrar-Agent may use a join
      proxy to facilitate the TLS connection to the registrar in the
      same way that a BRSKI pledge would use a join proxy.  This is



Fries, et al.            Expires 5 December 2025               [Page 15]

Internet-Draft                  BRSKI-PRM                      June 2025


      useful in cases where the Registrar-Agent does not have full IP
      connectivity via the domain network or cases where it has no other
      means to locate the registrar on the network.

   *  Domain registrar: In general fulfills the same functionality
      regarding the bootstrapping of the pledge in a customer domain by
      facilitating the communication of the pledge with the MASA service
      and the domain key infrastructure (PKI).  However, there are also
      differences compared to BRSKI [RFC8995]:

      -  A BRSKI-PRM domain registrar does not interact with a pledge
         directly, but through the Registrar-Agent as defined in
         Section 7.

      -  A BRSKI-PRM domain registrar offers additional endpoints as
         defined in Section 6.3 to support the signature-wrapped
         artifacts used by BRSKI-PRM.

   *  Vendor services: Encompass MASA and Ownership Tracker and are used
      as defined in [RFC8995].  A MASA responsible for pledges that
      implement BRSKI-PRM is expected to support BRSKI-PRM extensions:

      -  The default format for voucher artifacts (including voucher-
         request) is JWS-signed JSON as defined in
         [I-D.ietf-anima-jws-voucher].

      -  The Agent Proximity Assertion (see Section 5.4) requires
         additional validation steps as defined in Section 7.3.1.

5.2.  Nomadic Connectivity

   In one example instance of the PRM architecture as shown in Figure 2,
   there is no connectivity between the location in which the pledge is
   installed and the location of the domain registrar.  This is often
   the case in the building automation use case mentioned in
   Section 3.1.1.















Fries, et al.            Expires 5 December 2025               [Page 16]

Internet-Draft                  BRSKI-PRM                      June 2025


                                  +---------------------------+
             ..... Drop Ship .....| Vendor Services           |
             :                    +---------------------------+
             :                                          ^
         ........................................       |
         .   v                                  .       |
         . +--------+           .-.-.-.-.-.-.-. .       |
         . |        | BRSKI-PRM : Registrar-  : .       |
         . | Pledge |<--------->: Agent       : .       |
         . +--------+ L2 or L3  :-.-.-.-.-.-.-: .       | BRSKI-
         .          connectivity   ^            .       | MASA
         ..........................!.............       |
            Pledge Installation    !                    |
            Location               ! Nomadic            |
                                   ! connectivity       |
                                   !                    |
                        ...........!....................|.........
                        .          v                    v        .
                        .  .-.-.-.-.-.-.-. BRSKI- +-----------+  .
                        .  : Registrar-  :  PRM   | Domain    |  .
                        .  : Agent       :<------>| Registrar |  .
                        .  :-.-.-.-.-.-.-:        +-----+-----+  .
                        .                               |        .
                        .           +-------------------+-----+  .
                        .           | Key Infrastructure      |  .
                        .           | (e.g., PKI CA)          |  .
                        .           +-------------------------+  .
                        ..........................................
                                     Customer Domain

           Figure 2: Registrar-Agent nomadic connectivity example

   BRSKI-PRM enables support of this case through nomadic connectivity
   of the Registrar-Agent.  To perform enrollment in this setup,
   multiple round trips of the Registrar-Agent between the pledge
   installation location and the domain registrar are required.

   1.  Connectivity to domain registrar: preparation tasks for pledge
       bootstrapping not part of the BRSKI-PRM protocol definition, like
       retrieval of list of pledges to enroll.

   2.  Connectivity to pledge installation location: retrieve
       information about available pledges (IDevID), collect request
       objects (i.e., Pledge Voucher-Requests and Pledge Enroll-Requests
       using the BRSKI-PRM approach described in Section 7.1 and
       Section 7.2).





Fries, et al.            Expires 5 December 2025               [Page 17]

Internet-Draft                  BRSKI-PRM                      June 2025


   3.  Connectivity to domain registrar, submit collected request
       information of pledges, retrieve response objects (i.e., Voucher
       and Enroll-Response) using the BRSKI-PRM approach described in
       Section 7.3 and Section 7.4.

   4.  Connectivity to pledge installation location, provide retrieved
       objects to the pledges to enroll pledges and collect status using
       the BRSKI-PRM approach described in Section 7.6, Section 7.7, and
       Section 7.8.

   5.  Connectivity to domain registrar, submit Voucher Status and
       Enrollment Status using the BRSKI-PRM approach described in
       Section 7.9 and Section 7.10.

   Variations of this setup include cases where the Registrar-Agent uses
   for example, WiFi to connect to the pledge installation network, and
   mobile network connectivity to connect to the domain registrar.  Both
   connections may also be possible in a single location at the same
   time, based on installation building conditions.

5.3.  Co-located Registrar-Agent and Domain Registrar

   Compared to [RFC8995] BRSKI, pledges supporting BRSKI-PRM can be
   completely passive and only need to react when being requested to
   react by a Registrar-Agent.  In [RFC8995], pledges instead need to
   continuously interact with a domain registrar during onboarding,
   through discovery, voucher exchange, and enrollment.  This may
   increase the load on the domain registrar, specifically, if a larger
   number of pledges onboards simultaneously.






















Fries, et al.            Expires 5 December 2025               [Page 18]

Internet-Draft                  BRSKI-PRM                      June 2025


                                 +---------------------------+
            ..... Drop Ship .....| Vendor Service            |
            :                    +---------------------------+
            :                                         ^
            :                                         | BRSKI-MASA
            :          ...............................|.........
            :          .                              v        .
            v          .          +-------------------------+  .
         +--------+    . BRSKI-   |..............           |  .
         |        |    .  PRM     |. Registrar- . Domain    |  .
         | Pledge |<------------->|. Agent      . Registrar |  .
         +--------+ L2 or L3      |..............           |  .
                    connectivity  +-------------------+-----+  .
                       .                              |        .
                       .           +------------------+-----+  .
                       .           | Key Infrastructure     |  .
                       .           +------------------------+  .
                       .........................................
                                    Customer Domain

     Figure 3: Registrar-Agent integrated into Domain Registrar example

   The benefits of BRSKI-PRM can be achieved even without the
   operational complexity of stand-alone Registrar-Agents by integrating
   the necessary functionality of the Registrar-Agent as a module into
   the domain registrar as shown in Figure 3 so that it can support the
   BRSKI-PRM communications to the pledge.

5.4.  Agent Proximity Assertion

   "Agent proximity" is a statement in the PVR and the voucher that the
   registrar communicates via a Registrar-Agent as defined in Section 7
   and not directly to the pledge.  It is therefore a different
   assertion than "network proximity", which is defined in Section 3 of
   [RFC8995].  Hence, [I-D.ietf-anima-rfc8366bis] defines the additional
   assertion type agent-proximity.  This assertion type can be verified
   by the registrar and MASA during BRSKI-PRM voucher-request
   processing.

   In BRSKI, the pledge verifies POP of the registrar end-entity (EE)
   credentials via the TLS handshake and pins that public key as the
   proximity-registrar-cert into the voucher request.  This allows the
   MASA to verify the proximity of the pledge and registrar,
   facilitating a decision to assign the pledge to that domain owner.
   In BRSKI, the TLS session is considered provisional until the pledge
   receives the voucher to verify POI.





Fries, et al.            Expires 5 December 2025               [Page 19]

Internet-Draft                  BRSKI-PRM                      June 2025


   In contrast, in BRSKI-PRM the pledge has no direct connection to the
   registrar and MUST accept the supplied registrar EE certificate
   provisionally until it receives the voucher as described in
   Section 7.6 to verify both POP and POI.  The provisional registrar EE
   certificate is used for the object security along the authenticated
   self-contained objects that in BRSKI-PRM replace the direct TLS
   connection to the registrar available in BRSKI [RFC8995].  See also
   Section 5 of [RFC8995] on "provisional state".

   For the Agent Proximity Assertion, the Registrar-Agent EE certificate
   and registrar EE certificate must be signed by the same domain owner,
   i.e., MUST possess a common domain trust anchor in their certificate
   chain.  Akin to the Network Proximity Assertion in BRSKI [RFC8995],
   the Agent Proximity Assertion provides pledge proximity evidence to
   the MASA.  But additionally, the Agent Proximity Assertion allows the
   domain registrar to be sure that the PVR supplied by the Registrar-
   Agent was in fact collected by the Registrar-Agent to which the
   registrar is connected by utilizing an agent-signed data object.

6.  System Components

6.1.  Registrar-Agent

   The Registrar-Agent uses its own EE certificate and corresponding
   credentials (i.e., private key) for TLS client authentication and for
   signing agent-signed data objects.

   The Registrar-Agent EE certificate MUST include a
   SubjectKeyIdentifier as defined in Section 4.2.1.2 of [RFC5280],
   which is used as a reference within agent-signed data objects as
   defined in Section 7.1.1.1.  Note that this is an additional
   requirement for issuing the Registrar-Agent EE certificate.
   [RFC8995] has a similar requirement for the registrar EE certificate.

   The SubjectKeyIdentifier is used in favor of providing the complete
   Registrar-Agent EE certificate in agent-signed data objects to
   accommodate also constrained environments and reduce bandwidth needed
   for communication with the pledge.  In addition, it follows the
   recommendation from BRSKI to use SubjectKeyIdentifier in favor of a
   certificate fingerprint to avoid additional computations.

   The provisioning of the Registrar-Agent EE certificate is out of
   scope for this document, but may be done using its own BRSKI run or
   by other means such as configuration.  It is RECOMMENDED to use
   short-lived Registrar-Agent EE certificates in the range of days or
   weeks.  This is to address the assumed nature of stand-alone
   Registrar-Agents as nomadic devices (see Section 5.2) and to avoid
   potential misuse as outlined in Section 12.3.



Fries, et al.            Expires 5 December 2025               [Page 20]

Internet-Draft                  BRSKI-PRM                      June 2025


   Further, the Registrar-Agent requires the registrar EE certificate to
   provide it to the pledge.  It MAY use the certificate verified during
   server authentication within an initial TLS session with the
   registrar; in this case, the Registrar-Agent MUST possess the domain
   trust anchor (i.e., CA certificate) for the registrar EE certificate
   to verify the certificate chain.  Alternatively, the registrar EE
   certificate MAY be provided via configuration.  The registrar IP
   address or hostname is provided either by configuration or by using
   the discovery mechanism defined in [RFC8995] (see Section 6.1.1).

   In addition to the certificates, the Registrar-Agent is provided with
   the product-serial-number(s) of the pledge(s) to be bootstrapped.
   This is necessary to allow for the discovery of pledges by the
   Registrar-Agent using DNS-SD with mDNS (see Section 6.1.2).  The list
   may be provided by prior administrative means or the Registrar-Agent
   may get the information via an (out-of-band) interaction with the
   pledge.  For instance, [RFC9238] describes scanning of a QR code,
   where the product-serial-number would be initialized from the 12N
   B005 Product Serial Number data record.

   In summary, the following information MUST be available at the
   Registrar-Agent before the interaction with a pledge:

   *  Registrar-Agent EE certificate and corresponding private key: own
      operational credentials to authenticate and sign agent-signed data

   *  Registrar EE certificate: certificate of the domain registrar to
      be provided to the pledge

   *  Serial number(s): product-serial-number(s) of pledge(s) to be
      bootstrapped; used for discovery

   Further, the Registrar-Agent SHOULD have synchronized time.  In case
   the registrar-agent does not have synchronized time, it may not be
   able to verify the registrar EE certificate during the optional TLS
   handshake.  As the registrar-agent is recommended to utilize short-
   lived certificates in Section 12.3, a registrar-agent may use the
   valid from time of its short-lived certificate for time
   synchronization.

   Finally, the Registrar-Agent MAY possess the IDevID (root or issuing)
   CA certificate of the pledge manufacturer/vendor to validate the
   IDevID certificate on returned PVR or in case of optional TLS usage
   for pledge communication (see Appendix B).  The distribution of
   IDevID CA certificates to the Registrar-Agent is out of scope of this
   document and may be done by a manual configuration.





Fries, et al.            Expires 5 December 2025               [Page 21]

Internet-Draft                  BRSKI-PRM                      June 2025


6.1.1.  Discovery of the Registrar

   While the Registrar-Agent requires an IP address of a domain
   registrar to initiate a TLS session, a separate discovery of the
   registrar is likely not needed and a configuration of the domain
   registrar IP address or hostname is assumed.  Registrar-Agent and
   registrar are domain components that already have a trust relation,
   as a Registrar-Agent acts as representative of the domain registrar
   towards the pledge or may even be collocated with the domain
   registrar.  Further, other communication (not part of this document)
   between the Registrar-Agent and the registrar is assumed, e.g., to
   exchange information about product-serial-number(s) of pledges to be
   discovered as outlined in Section 5.2.

   Moreover, the discovery described in Section 4 of [RFC8995] and
   Appendix A.2 of [RFC8995] does not support identification of
   registrars with an enhanced feature set (like the support of BRSKI-
   PRM), and hence that discovery is not applicable.

   As a more general solution, the BRSKI discovery mechanism can be
   extended to provide upfront information on the capabilities of
   registrars, such as the mode of operation (pledge-responder-mode or
   registrar-responder-mode).  Defining discovery extensions is out of
   scope of this document.  For further discussion, see
   [I-D.ietf-anima-brski-discovery].

6.1.2.  Discovery of the Pledge

   The discovery of the pledge by the Registrar-Agent in the context of
   this document describes the minimum discovery approach that MUST be
   supported.  A more general discovery mechanism, also supporting GRASP
   besides DNS-SD with mDNS, is discussed in
   [I-D.ietf-anima-brski-discovery].

   Discovery in BRSKI-PRM uses DNS-based Service Discovery [RFC6763]
   over Multicast DNS [RFC6762] to discover the pledge.  Note that
   Section 9 of [RFC6762] provides support for conflict resolution in
   situations when a DNS-SD with mDNS responder receives an mDNS
   response with inconsistent data.  Note that [RFC8990] does not
   support conflict resolution of mDNS, which may be a limitation for
   its application.










Fries, et al.            Expires 5 December 2025               [Page 22]

Internet-Draft                  BRSKI-PRM                      June 2025


   The pledge constructs a Service Instance Name based on device local
   information (manufacturer/vendor name and serial number), which
   results in <product-serial-number>._brski-pledge._tcp.local.  The
   product-serial-number composition is manufacturer-dependent and may
   contain information regarding the manufacturer, the product type, and
   further information specific to the product instance.  To allow
   distinction of pledges, the product-serial-number therefore needs to
   be sufficiently unique.

   Note that the service name definition is not fully inline with the
   naming recommendation of [RFC6763] due to the positioning of _tcp.
   However, the definition of the product-serial-number has to align
   with the allowed character set (see [RFC6763]) to avoid discovery
   problems.  This check is necessary as the product-serial-number is
   also contained in the certificate as X520SerialNumber, that has a
   larger allowed character set.  Using the product-serial-number as
   part of the service name allows to discover specific instances of a
   pledge.

   The _brski-pledge._tcp service, however, targets machine-to-machine
   discovery.

   For discovery the Registrar-Agent MUST use

   *  <product-serial-number>._brski-pledge._tcp.local, to discover a
      specific pledge, e.g., when connected to a local network

   *  _brski-pledge._tcp.local to get a list of pledges to be
      bootstrapped

   if it does not support a more general discovery such as defined in
   [I-D.ietf-anima-brski-discovery].

   When supporting different options for discovery, as outlined in
   [I-D.ietf-anima-brski-discovery], a manufacturer may support
   configuration of preferred options.

   A manufacturer may allow the pledge to react on DNS-SD with mDNS
   discovery without its product-serial-number contained.  This allows a
   commissioning tool to discover pledges to be bootstrapped in the
   domain.  The manufacturer supports this functionality as outlined in
   Section 12.4.

   Establishing network connectivity of the pledge is out of scope of
   this document but necessary to apply DNS-SD with mDNS.  For Ethernet,
   network connectivity can be provided, e.g., via a switch to an
   operational network or to a specific VLAN for bootstrapping,
   depending on an operators security policy.  For WiFi networks,



Fries, et al.            Expires 5 December 2025               [Page 23]

Internet-Draft                  BRSKI-PRM                      June 2025


   connectivity can be provided by using a pre-agreed SSID for
   bootstrapping, e.g., as proposed in [I-D.draft-ietf-emu-eap-arpa].
   The same approach can be used by 6LoWPAN/mesh using a pre-agreed PAN
   ID.  How to gain network connectivity is out of scope of this
   document.

6.2.  Pledge in Responder Mode

   In BRSKI-PRM, the pledge is triggered by a Registrar-Agent to create
   the PVR and PER.  It is also triggered for processing of the
   responses and the generation of status information once the
   Registrar-Agent has received the responses from the registrar later
   in the process.

   To enable interaction as responder with a Registrar-Agent, pledges in
   responder mode MUST act as servers and MUST provide the endpoints
   "tpvr", "tper", "svr", "scac", and "ser" defined in Table 1 within
   the BRSKI-defined /.well-known/brski/ URI path.  The optional
   endpoint "qps" SHOULD be supported.  The endpoints are defined with
   short names to also accommodate for resource-constrained devices.

      +==========+========================+========================+
      | Endpoint | Operation              | Exchange and Artifacts |
      +==========+========================+========================+
      | tpvr     | Trigger Pledge         | Section 7.1            |
      |          | Voucher-Request        |                        |
      +----------+------------------------+------------------------+
      | tper     | Trigger Pledge Enroll- | Section 7.2            |
      |          | Request                |                        |
      +----------+------------------------+------------------------+
      | svr      | Supply Voucher to      | Section 7.6            |
      |          | Pledge                 |                        |
      +----------+------------------------+------------------------+
      | scac     | Supply CA Certificates | Section 7.7            |
      |          | to Pledge              |                        |
      +----------+------------------------+------------------------+
      | ser      | Supply Enroll-Response | Section 7.8            |
      |          | to Pledge              |                        |
      +----------+------------------------+------------------------+
      | qps      | Query Pledge Status    | Section 7.11           |
      +----------+------------------------+------------------------+

       Table 1: Well-Known Endpoints on a Pledge in Responder Mode

   HTTP(S) uses the Host header field (or :authority in HTTP/2) to allow
   for name-based virtual hosting as explained in Section 7.2 of
   [RFC9110].  This header field is mandatory, and so a compliant
   HTTP(S) client is going to insert it, which may be just an IP



Fries, et al.            Expires 5 December 2025               [Page 24]

Internet-Draft                  BRSKI-PRM                      June 2025


   address.  In the absence of a security policy the pledge MUST respond
   to all requests regardless of the Host header field provided by the
   client (i.e., ignore it).  A security policy may include a rate
   limiting for requests to avoid susceptibility of the pledge to
   overload.  Note that there is no requirement for the pledge to
   operate its BRSKI-PRM service on port numbers 80 or 443, so there is
   no reason for name-based virtual hosting.

   For instance, when the Registrar-Agent reaches out to the "tpvr"
   endpoint on a pledge in responder mode with the full URI
   http://pledge.example.com/.well-known/brski/tpvr, it sets the Host
   header field to pledge.example.com and the absolute path /.well-
   known/brski/tpbr.  In practice, however, the pledge is usually known
   by a .local hostname or only its IP address as returned by a
   discovery protocol, which will be included in the Host header field.

   As BRSKI-PRM uses authenticated self-contained objects between the
   pledge and the domain registrar, the binding of the pledge identity
   to the voucher-requests is provided by the wrapping signature
   employing the pledge IDevID credential.  Hence, pledges MUST have an
   Initial Device Identifier (IDevID) installed in them at the factory.

6.2.1.  Pledge with Combined Functionality

   Pledges may support both initiator and responder mode.

   A pledge in initiator mode should listen for announcement messages as
   described in Section 4.1 of [RFC8995].  Upon discovery of a potential
   registrar, it initiates the bootstrapping to that registrar.  At the
   same time (so as to avoid the Slowloris-like attack described in
   [RFC8995]), it SHOULD also respond to the triggers for responder mode
   described in this document.

   Once a pledge with combined functionality has been bootstrapped, it
   MAY act as client for enrollment of further certificates needed,
   e.g., using the enrollment protocol of choice.  If it still acts as
   server, the defined BRSKI-PRM endpoints to trigger a Pledge Enroll-
   Request (PER) or to provide an Enroll-Response can be used for
   further certificates.

6.2.2.  Pledgestatus "reason-context" Values

   The following table provides an overview of "reason-context" values
   and further details of pledgestatus data objects:







Fries, et al.            Expires 5 December 2025               [Page 25]

Internet-Draft                  BRSKI-PRM                      June 2025


   +==================+=================+==============================+
   | "reason-context" | Predef.         | Description                  |
   | Value            | Details         |                              |
   +==================+=================+==============================+
   | pbs-details      |                 | Pledge bootstrap status      |
   |                  |                 | details, Section 7.11.2.1    |
   +------------------+-----------------+------------------------------+
   |                  | factory-default | Pledge has not been          |
   |                  |                 | bootstrapped                 |
   +------------------+-----------------+------------------------------+
   |                  | voucher-success | Pledge processed voucher     |
   |                  |                 | exchange successfully        |
   +------------------+-----------------+------------------------------+
   |                  | voucher-error   | Pledge voucher processing    |
   |                  |                 | with error                   |
   +------------------+-----------------+------------------------------+
   |                  | enroll-success  | Pledge processed enrollment  |
   |                  |                 | exchange successfully        |
   +------------------+-----------------+------------------------------+
   |                  | enroll-error    | Pledge enrollment-response   |
   |                  |                 | processing with error        |
   +------------------+-----------------+------------------------------+
   | pos-details      |                 | Pledge operation status      |
   |                  |                 | details, Section 7.11.2.1    |
   +------------------+-----------------+------------------------------+
   |                  | connect-success | Pledge successfully          |
   |                  |                 | establish connection to      |
   |                  |                 | peer                         |
   +------------------+-----------------+------------------------------+
   |                  | connect-error   | Pledge connection            |
   |                  |                 | establishment with error     |
   +------------------+-----------------+------------------------------+

         Table 2: Pledgestatus "reason-context" values and details

   Note that the predefined details listed in Table 2 may be enhanced by
   other specifications if necessary.  The currently defined details
   reflect the different stages during onboarding along the exchanges
   shown in Figure 4.

6.2.3.  Voucher Status and Enroll Status Telemetry "reason-context"
        Values

   The following table provides an overview of "reason-context" values
   and further details of voucher status and enroll status telemetry
   data objects:





Fries, et al.            Expires 5 December 2025               [Page 26]

Internet-Draft                  BRSKI-PRM                      June 2025


    +========================+==============+========================+
    | "reason-context" Value | Details type | Description            |
    +========================+==============+========================+
    | pvs-details            | STRING       | Pledge voucher status  |
    |                        |              | details, Section 7.6.2 |
    +------------------------+--------------+------------------------+
    | pes-details            | STRING       | Pledge enroll status   |
    |                        |              | details, Section 7.8.2 |
    +------------------------+--------------+------------------------+

       Table 3: Voucher Status and Enroll Status Telemetry "reason-
                       context" values and details

6.3.  Domain Registrar

   The domain registrar provides the endpoints already specified in
   [RFC8995] (derived from EST [RFC7030]) where suitable.  In addition,
   it MUST provide the endpoints defined in Table 4 within the BRSKI-
   defined /.well-known/brski/ Well-Known URI path.  These endpoints
   accommodate for the authenticated self-contained objects used by
   BRSKI-PRM to provide Pledge Enroll-Request (PER) artifacts and
   signature-wrapped CA certificates via the Registrar-Agent.

   +================+=========================+========================+
   | Endpoint       | Operation               | Exchange and Artifacts |
   +================+=========================+========================+
   | requestenroll  | Supply PER              | Section 7.4            |
   |                | to Registrar            |                        |
   +----------------+-------------------------+------------------------+
   | wrappedcacerts | Obtain CA               | Section 7.5            |
   |                | Certificates            |                        |
   +----------------+-------------------------+------------------------+

     Table 4: Additional Well-Known Endpoints on a BRSKI-PRM Registrar

   For the supply of the PVR to the registrar, the pledge uses the
   endpoint "requestvoucher", defined in [RFC8995] as described in
   Section 7.3.

   The registrar possesses its own EE certificate and corresponding
   private key for authenticating and signing.  It MUST use the same
   certificate/credentials for authentication in the TLS session with a
   Registrar-Agent and for signing artifacts for that Registrar-Agent
   and its pledges (see Section 7.3.6).

   According to Section 5.3 of [RFC8995], a domain registrar performs
   the pledge authorization for bootstrapping within its domain based on
   the Pledge Voucher-Request.  For this, it MUST possess the IDevID



Fries, et al.            Expires 5 December 2025               [Page 27]

Internet-Draft                  BRSKI-PRM                      June 2025


   trust anchor(s) (i.e., root or issuing CA certificate(s)) of the
   pledge vendor(s)/manufacturer(s).  This behavior is retained in
   BRSKI-PRM.

   In its role as EST server [RFC7030], the domain registrar MUST also
   possess the domain CA certificates as defined in Section 5.9 of
   [RFC8995].

   Finally, the domain registrar MUST possess the Registrar-Agent EE
   certificate(s) to validate agent-signed data and to provide it to the
   MASA.  The registrar MAY use the certificate verified during client
   authentication within the TLS sessions with the Registrar-Agent; in
   this case, the registrar MUST possess the domain trust anchor (i.e.,
   domain CA certificate) for the Registrar-Agent EE certificate to
   verify the certificate chain.  Alternatively, the Registrar-Agent EE
   certificate(s) MAY be provided via configuration or a repository.

6.3.1.  Domain Registrar with Combined Functionality

   A registrar with combined BRSKI and BRSKI-PRM functionality MAY
   detect if the bootstrapping is performed by the pledge directly
   (BRSKI case) or by a Registrar-Agent (BRSKI-PRM case) based on the
   utilized credentials for client authentication during the TLS session
   establishment and switch the operational mode from BRSKI to BRSKI-
   PRM.

   This may be supported by a specific naming in the SAN (subject
   alternative name) component of the Registrar-Agent EE certificate,
   which allows the domain registrar to explicitly detect already in the
   TLS session establishment that the connecting client is a Registrar-
   Agent.

   The registrar MAY be configured to only accept certain Registrar-
   Agents, which authenticate using the Registrar-Agent EE certificate.

   Note that using an EE certificate for TLS client authentication of
   the Registrar-Agent is a deviation from [RFC8995], in which the
   pledge IDevID certificate is used to perform TLS client
   authentication.

6.4.  MASA

   The Manufacturer Authorized Signing Authority (MASA) is a vendor
   service that generates and signs voucher artifacts for pledges by the
   same vendor.  When these pledges support BRSKI-PRM, the MASA needs to
   implement the following functionality in addition to BRSKI [RFC8995].





Fries, et al.            Expires 5 December 2025               [Page 28]

Internet-Draft                  BRSKI-PRM                      June 2025


   A MASA for pledges in responder mode MUST support the voucher format
   defined in [I-D.ietf-anima-jws-voucher] to parse and process JWS-
   signed voucher-request artifacts and generate JWS-signed voucher
   artifacts.

   Further, a MASA for pledges in responder mode MUST support the Agent
   Proximity Assertion (Section 5.4) through the validation steps
   defined in Section 7.3.1 based on the Pledge Voucher-Request (PVR)
   and Registrar Voucher-Request (RVR) artifact fields defined in
   Section 7.1.2 and Section 7.3.4, respectively.

7.  Exchanges and Artifacts

   The interaction of the pledge with the Registrar-Agent may be
   accomplished using different transports (i.e., protocols and/or
   network technologies).  This specification utilizes HTTP(S) as
   default transport.  Other specifications may define alternative
   transports such as CoAP, Bluetooth Low Energy (BLE), or Near Field
   Communication (NFC).  These transports may differ from and are
   independent of the ones used between the Registrar-Agent and the
   registrar.

   Transport independence is realized through authenticated self-
   contained objects that are not bound to a specific transport security
   and stay the same along the communication path from the pledge via
   the Registrar-Agent to the registrar.  [I-D.ietf-anima-rfc8366bis]
   defines CMS-signed JSON structures as format for artifacts
   representing authenticated self-contained objects.  This
   specification utilizes JWS-signed JSON structures as default format
   for BRSKI-PRM.  Other specifications may define alternative formats
   for representing authenticated self-contained objects such as COSE-
   signed CBOR structures.

   Figure 4 provides an overview of the exchanges detailed in the
   following subsections.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  |     discover     |                 |                 |            |
  |      pledge      |                 |                 |            |
  |    mDNS query    |                 |                 |            |
  |<-----------------|                 |                 |            |
  |----------------->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~



Fries, et al.            Expires 5 December 2025               [Page 29]

Internet-Draft                  BRSKI-PRM                      June 2025


 (1) Trigger Pledge Voucher-Request
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<------tPVR-------|                 |                 |            |
  |--------PVR------>|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (2) Trigger Pledge Enroll-Request
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<------tPER-------|                 |                 |            |
  |--------PER------>|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (3) Supply PVR to Registrar (including MASA interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<-----mTLS------>|                 |            |
  |                  |                 |                 |            |
  |                  |         [Registrar-Agent          |            |
  |                  |    authenticated&authorized?]     |            |
  |                  |                 |                 |            |
  |                  |-------PVR------>|                 |            |
  |                  |                 |                 |            |
  |                  |          [accept device?]         |            |
  |                  |                 |                 |            |
  |                  |                 |<------------mTLS------------>|
  |                  |                 |--------------RVR------------>|
  |                  |                 |                 ~            |
  |                  |                 |              [extract DomainID]
  |                  |                 |              [update audit-log]
  |                  |                 |                 ~            |
  |                  |                 |<-----------Voucher-----------|
  |                  |<----Voucher''---|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (4) Supply PER to Registrar (including Key Infrastructure interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<---((mTLS))---->|                 |            |
  |                  |-------PER------>|                 |            |
  |                  |                 |----[Request]--->|            |
  |                  |                 |<--[Certificate]-|            |
  |                  |<--Enroll-Resp---|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~



Fries, et al.            Expires 5 December 2025               [Page 30]

Internet-Draft                  BRSKI-PRM                      June 2025


 (5) Obtain CA Certificates
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<----(mTLS)----->|                 |            |
  |                  |<----caCerts-----|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (6) Supply Voucher to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----Voucher''---|                 |                 |            |
  |------vStatus---->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (7) Supply CA Certificates to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----caCerts-----|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (8) Supply Enroll-Response to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<---Enroll-Resp---|                 |                 |            |
  |-----eStatus----->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (9) Voucher Status Telemetry (including backend interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<----(mTLS)----->|                 |            |
  |                  |-----vStatus---->|                 |            |
  |                  |                 |<-----------(mTLS)----------->|
  |                  |                 |-----req device audit-log---->|
  |                  |                 |<------device audit-log-------|
  |                  |                 |                 |            |
  |                  |        [verify audit-log]         |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~
 (10) Enroll Status Telemetry
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<----(mTLS)----->|                 |            |
  |                  |-----eStatus---->|                 |            |
  |                  |                 |                 |            |



Fries, et al.            Expires 5 December 2025               [Page 31]

Internet-Draft                  BRSKI-PRM                      June 2025


  ~                  ~                 ~                 ~            ~
 (11) Query Pledge Status
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----tStatus-----|                 |                 |            |
  |------pStatus---->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

           Figure 4: Overview pledge-responder-mode exchanges

   The following subsections split the interactions shown in Figure 4
   between the different components into:

   1.   Section 7.1 describes the acquisition exchange for the Pledge
        Voucher-Request initiated by the Registrar-Agent to the pledge.

   2.   Section 7.2 describes the acquisition exchange for the Pledge
        Enroll-Request initiated by the Registrar-Agent to the pledge.

   3.   Section 7.3 describes the issuing exchange for the Voucher
        initiated by the Registrar-Agent to the registrar, including the
        interaction of the registrar with the MASA using the RVR
        Section 7.3.4, as well as the artifact processing by these
        entities.

   4.   Section 7.4 describes the enroll exchange initiated by the
        Registrar-Agent to the registrar including the interaction of
        the registrar with the CA using the PER as well as the artifact
        processing by these entities.

   5.   Section 7.5 describes the retrieval exchange for the optional CA
        certificate provisioning to the pledge initiated by the
        Registrar-Agent to the CA.

   6.   Section 7.6 describes the Voucher exchange initiated by the
        Registrar-Agent to the pledge and the returned status
        information.

   7.   Section 7.7 describes the CA certificate exchange initiated by
        the Registrar-Agent to the pledge.

   8.   Section 7.8 describes the Enroll-Response exchange initiated by
        the Registrar-Agent to the pledge (containing a new pledge EE
        certificate) and the returned status information.





Fries, et al.            Expires 5 December 2025               [Page 32]

Internet-Draft                  BRSKI-PRM                      June 2025


   9.   Section 7.9 describes the Voucher Status telemetry exchange
        initiated by the Registrar-Agent to the registrar, including the
        interaction of the registrar with the MASA.

   10.  Section 7.10 describes the Enroll Status telemetry exchange
        initiated by the Registrar-Agent to the registrar.

   11.  Section 7.11 describes the Pledge Status exchange about the
        general bootstrapping state initiated by the Registrar-Agent to
        the pledge.

7.1.  Trigger Pledge Voucher-Request

   The Registrar-Agent begins the sequence of exchanges by sending the
   Pledge Voucher-Request Trigger (tPVR).  This assumes that the
   Registrar-Agent has already discovered the pledge, for instance as
   described in Section 6.1.2 based on DNS-SD or similar.

   TLS MAY be used to provide transport security, e.g., privacy and peer
   authentication, for the exchange between the Registrar-Agent and the
   pledge (see Appendix B).

   Figure 5 shows the acquisition of the Pledge Voucher-Request (PVR)
   and the following subsections describe the corresponding artifacts.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (1) Trigger Pledge Voucher-Request
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<------tPVR-------|                 |                 |            |
  |--------PVR------>|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                   Figure 5: PVR acquisition exchange










Fries, et al.            Expires 5 December 2025               [Page 33]

Internet-Draft                  BRSKI-PRM                      June 2025


   The Registrar-Agent triggers the pledge to create a PVR via HTTP(S)
   POST to the pledge endpoint at /.well-known/brski/tpvr.  The request
   body MUST contain the JSON-based Pledge Voucher-Request Trigger
   (tPVR) artifact as defined in Section 7.1.1.  In the request header,
   the Content-Type field MUST be set to application/json and the Accept
   field SHOULD be set to application/voucher-jws+json as defined in
   [I-D.ietf-anima-jws-voucher].

   Upon receiving a valid tPVR, the pledge MUST reply with the PVR
   artifact as defined in Section 7.1.2 in the body of an HTTP 200 OK
   response.  If the Accept header was not provided in the PVR, the
   pledge assumes that the accepted response format is application/
   voucher-jws+json and proceeds processing.  In the response header,
   the Content-Type field MUST be set to application/voucher-jws+json as
   defined in [I-D.ietf-anima-jws-voucher].

   Note that the pledge provisionally accepts the registrar EE
   certificate contained in the tPVR until it receives the voucher (see
   Section 5.4).  The pledge will take the last received tPVR for the
   provisional accept of the received registrar EE certificate, if it
   does not have the capability to store more that one registrar EE
   certificate.

   If the pledge is unable to create the PVR, it responds with an HTTP
   error status code to the Registrar-Agent.  The following client error
   status codes can be used:

   *  400 Bad Request: if the pledge detects an error in the format of
      the request, e.g., missing field, wrong data types, etc. or if the
      request is not valid JSON even though the Content-Type request
      header field was set to application/json.

   *  406 Not Acceptable: if the Accept request header field indicates a
      type that is unknown or unsupported, e.g., a type other than
      application/voucher-jws+json.

   *  415 Unsupported Media Type: if the Content-Type request header
      field indicates a type that is unknown or unsupported, e.g., a
      type other than application/json.

   The pledge MAY use the response body to signal success/failure
   details to the service technician operating the Registrar-Agent.

   While BRSKI-PRM does not specify which content may be provided in the
   response body, it is recommended to provided it as JSON encoded
   information as other BRSKI-PRM exchanges also utilize this encoding.





Fries, et al.            Expires 5 December 2025               [Page 34]

Internet-Draft                  BRSKI-PRM                      June 2025


7.1.1.  Request Artifact: Pledge Voucher-Request Trigger (tPVR)

   The Pledge Voucher-Request Trigger (tPVR) artifact SHALL be an
   unsigned data object, providing the necessary parameters for
   generating the Pledge Voucher-Request (PVR) artifact such that the
   Agent Proximity Assertion can be verified by registrar and MASA: the
   registrar EE certificate and an agent-signed data object containing
   the product-serial-number and a timestamp.  The artifact is unsigned
   because at the time of receiving the tPVR, the pledge could not
   verify any signature.

   For the JSON-based format used by this specification, the tPVR
   artifact SHALL be a UTF-8 encoded JSON document [RFC8259] that
   conforms with the CDDL [RFC8610] data model defined in Figure 6:

     pledgevoucherrequesttrigger = {
       "agent-provided-proximity-registrar-cert": bytes,
       "agent-signed-data": bytes
     }

             Figure 6: CDDL for Pledge Voucher-Request Trigger
                       (pledgevoucherrequesttrigger)

   The agent-provided-proximity-registrar-cert member SHALL contain the
   base64-encoded registrar EE certificate in X.509 v3 (DER) format.
   The agent-signed-data member SHALL contain the base64-encoded JWS
   Agent-Signed Data as defined in Section 7.1.1.1.  Figure 7 summarizes
   the serialization the JSON tPVR artifact:

   {
     "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
     "agent-signed-data": BASE64(UTF8(JWS Agent-Signed Data))
   }

                   Figure 7: tPVR Representation in JSON

7.1.1.1.  JWS Agent-Signed Data

   To enable alternative formats, the YANG module in
   [I-D.ietf-anima-rfc8366bis] defines the leaf agent-signed-data as
   binary.  For the JWS-signed JSON format used by this specification,
   the agent-signed-data leaf SHALL be a UTF-8 encoded JWS structure in
   "General JWS JSON Serialization Syntax" as defined in Section 7.2.1
   of [RFC7515] signing the JSON Agent-Signed Data defined in
   Section 7.1.1.1.1.  Figure 8 summarizes this JWS structure for the
   agent-signed-data member of the tPVR artifact:





Fries, et al.            Expires 5 December 2025               [Page 35]

Internet-Draft                  BRSKI-PRM                      June 2025


   {
     "payload": BASE64URL(UTF8(JSON Agent-Signed Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

     Figure 8: JWS Agent-Signed Data in General JWS JSON Serialization
                                   Syntax

   The JSON Agent-Signed Data MUST be UTF-8 encoded to become the octet-
   based JWS Payload defined in [RFC7515].  The JWS Payload is further
   base64url-encoded to become the string value of the payload member as
   described in Section 3.2 of [RFC7515].  The octets of the UTF-8
   representation of the JWS Protected Header are base64url-encoded to
   become the string value of the protected member.  The generated JWS
   Signature is base64url-encoded to become the string value of the
   signature member.

7.1.1.1.1.  JSON Agent-Signed Data

   The JSON Agent-Signed Data SHALL be a JSON document [RFC8259] that
   MUST conform with the CDDL [RFC8610] data model defined in Figure 9:

     prmasd = {
       "created-on": tdate,
       "serial-number": text
     }

             Figure 9: CDDL for JSON Agent-Signed Data (prmasd)

   The created-on member SHALL contain the current date and time at tPVR
   creation as standard date/time string as defined in Section 5.6 of
   [RFC3339].

   The serial-number member SHALL contain the product-serial-number of
   the pledge with which the Registrar-Agent assumes to communicate as
   string.  The format MUST correspond to the X520SerialNumber field of
   IDevID certificates.

   Figure 10 below shows an example for the JSON Agent-Signed Data:







Fries, et al.            Expires 5 December 2025               [Page 36]

Internet-Draft                  BRSKI-PRM                      June 2025


   {
     "created-on": "2021-04-16T00:00:01.000Z",
     "serial-number": "vendor-pledge4711"
   }

                 Figure 10: JSON Agent-Signed Data Example

7.1.1.1.2.  JWS Protected Header

   The JWS Protected Header of the agent-signed-data member MUST contain
   the following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

   *  kid: SHALL contain the base64-encoded OCTET STRING value of the
      SubjectKeyIdentifier of the Registrar-Agent EE certificate as
      described in Section 6.1.

   Figure 11 shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "kid": "base64encodedvalue=="
   }

                Figure 11: JWS Protected Header Example for

7.1.1.1.3.  JWS Signature

   The Registrar-Agent MUST sign the agent-signed-data member using its
   EE credentials.  The JWS Signature is generated over the JWS
   Protected Header and the JWS Payload as described in Section 5.1 of
   [RFC7515].  Algorithms used for JWS signatures MUST support ES256 as
   recommended in [RFC7518] and MAY support further algorithms.

7.1.2.  Response Artifact: Pledge Voucher-Request (PVR)

   The Pledge Voucher-Request (PVR) artifact SHALL be an authenticated
   self-contained object signed by the pledge, containing an extended
   Voucher-Request artifact based on Section 5.2 of [RFC8995].  The
   BRSKI-PRM related enhancements of the ietf-voucher-request YANG
   module are defined in [I-D.ietf-anima-rfc8366bis].








Fries, et al.            Expires 5 December 2025               [Page 37]

Internet-Draft                  BRSKI-PRM                      June 2025


   For the JWS-signed JSON format used by this specification, the PVR
   artifact MUST be a JWS Voucher structure as defined in
   [I-D.ietf-anima-jws-voucher], which MUST contain the JSON PVR Data
   defined in Section 7.1.2.1 in the JWS Payload.  Figure 12 summarizes
   the serialization of the JWS-signed JSON PVR artifact:

   {
     "payload": BASE64URL(UTF8(JSON PVR Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

      Figure 12: PVR Representation in General JWS JSON Serialization
                                   Syntax

7.1.2.1.  JSON PVR Data

   The JSON PVR Data MUST contain the following fields of the ietf-
   voucher-request YANG module as defined in
   [I-D.ietf-anima-rfc8366bis]; note that this makes optional leaf data
   nodes in the YANG definition mandatory for the PVR artifact:

   *  created-on: SHALL contain the current date and time at PVR
      creation as standard date/time string as defined in Section 5.6 of
      [RFC3339]; if the pledge does not have synchronized time, it SHALL
      use the created-on value from the JSON Agent-Signed Data received
      with the tPVR artifact and SHOULD advance that value based on its
      local clock to reflect the PVR creation time.

   *  nonce: SHALL contain a cryptographically strong random or pseudo-
      random number nonce (see Section 6.2 of [RFC4086]).

   *  serial-number: SHALL contain the product-serial-number in the
      X520SerialNumber field of the pledge IDevID certificate as string
      as defined in Section 2.3.1 of [RFC8995].

   *  assertion: SHALL contain the assertion type agent-proximity to
      indicate the pledge request (different from BRSKI [RFC8995]).

   *  agent-provided-proximity-registrar-cert: SHALL contain the
      base64-encoded registrar EE certificate provided in the tPVR by
      the Registrar-Agent; enables the registrar and MASA to verify the
      Agent Proximity Assertion.




Fries, et al.            Expires 5 December 2025               [Page 38]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  agent-signed-data: SHALL contain the same value as the agent-
      signed-data member in the tPVR provided by the Registrar-Agent;
      enables the registrar and MASA to verify the Agent Proximity
      Assertion; also enables the registrar to log which Registrar-Agent
      was in contact with the pledge.

   Figure 13 shows an example for the JSON PVR Data:

 {
   "ietf-voucher-request:voucher": {
      "created-on": "2021-04-16T00:00:02.000Z",
      "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
      "serial-number": "vendor-pledge4711",
      "assertion": "agent-proximity",
      "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
      "agent-signed-data": "base64encodedvalue=="
   }
 }

                    Figure 13: JSON PVR Data Example

7.1.2.2.  JWS Protected Header

   The JWS Protected Header MUST follow the definitions of Section 3.2
   of [I-D.ietf-anima-jws-voucher].

7.1.2.3.  JWS Signature

   The pledge MUST sign the PVR artifact using its IDevID credential
   following the definitions of Section 3.3 of
   [I-D.ietf-anima-jws-voucher].  Algorithms used for JWS signatures
   MUST support ES256 as recommended in [RFC7518] and MAY support
   further algorithms.

7.2.  Trigger Pledge Enroll-Request

   Once the Registrar-Agent has received the PVR it can trigger the
   pledge to generate a Pledge Enroll-Request (PER).

   TLS MAY be used to provide privacy for this exchange between the
   Registrar-Agent and the pledge (see Appendix B).

   Figure 14 shows the acquisition of the PER and the following
   subsections describe the corresponding artifacts.







Fries, et al.            Expires 5 December 2025               [Page 39]

Internet-Draft                  BRSKI-PRM                      June 2025


 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (2) Trigger Pledge Enroll-Request
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<------tPER-------|                 |                 |            |
  |--------PER------>|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                  Figure 14: PER acquisition exchange

   The Registrar-Agent triggers the pledge to create the PER via HTTP(S)
   POST to the pledge endpoint at /.well-known/brski/tper.  The request
   body MUST contain the JSON-based Pledge Enroll-Request Trigger (tPER)
   artifact as defined in Section 7.2.1.  In the request header, the
   Content-Type field MUST be set to application/json and the Accept
   field SHOULD be set to application/jose+json.

   Upon receiving a valid tPER, the pledge MUST reply with the PER
   artifact as defined in Section 7.2.2 in the body of an HTTP 200 OK
   response.  If the Accept header was not provided in the PER, the
   pledge assumes that the accepted response format is application/
   voucher-jws+json and proceeds processing.  In the response header,
   the Content-Type field MUST be set to application/jose+json.

   If the pledge is unable to create the PER, it responds with an HTTP
   error status code to the Registrar-Agent.  The following client error
   status codes can be used:

   *  400 Bad Request: if the pledge detects an error in the format of
      the request.

   *  406 Not Acceptable: if the Accept request header field indicates a
      type that is unknown or unsupported, e.g., a type other than
      application/jose+json.

   *  415 Unsupported Media Type: if the Content-Type request header
      field indicates a type that is unknown or unsupported, e.g., a
      type other than application/json.






Fries, et al.            Expires 5 December 2025               [Page 40]

Internet-Draft                  BRSKI-PRM                      June 2025


   The pledge MAY use the response body to signal success/failure
   details to the service technician operating the Registrar-Agent.
   While BRSKI-PRM does not specify which content may be provided in the
   response body, it is recommended to provided it as JSON encoded
   information as other BRSKI-PRM exchanges also utilize this encoding.

7.2.1.  Request Artifact: Pledge Enroll-Request Trigger (tPER)

   The Pledge Enroll-Request Trigger (tPVR) artifact SHALL be an
   unsigned data object, providing enrollment parameters.  This document
   specifies only the basic parameter for a generic, device-related
   LDevID certificate with no CSR attributes provided to the pledge.  If
   specific attributes in the certificate are required, they have to be
   inserted by the issuing Key Infrastructure.

   The Pledge Enroll-Request Trigger (tPER) artifact MAY be used to
   provide additional enrollment parameters such as CSR attributes.  How
   to provide and use such additional data is out of scope for this
   specification.

   For the JSON-based format used by this specification, the tPER
   artifact MUST be a UTF-8 encoded JSON document [RFC8259] that
   conforms with the CDDL [RFC8610] data model defined in Figure 15:

   pledgeenrollrequesttrigger = {
       "enroll-type": $enroll-type
   }

   $enroll-type /= "enroll-generic-cert"

             Figure 15: CDDL for Pledge Enroll-Request Trigger
                        (pledgeenrollrequesttrigger)

   The enroll-type member allows for specifying which type of
   certificate is to be enrolled.  As shown in Figure 15, BRSKI-PRM only
   defines the enumeration value enroll-generic-cert for the enrollment
   of the generic, device-related LDevID certificate.  Other
   specifications using this artifact may define further enum values,
   e.g., to bootstrap application-related EE certificates with
   additional CSR attributes.











Fries, et al.            Expires 5 December 2025               [Page 41]

Internet-Draft                  BRSKI-PRM                      June 2025


7.2.2.  Response Artifact: Pledge Enroll-Request (PER)

   The Pledge Enroll-Request (PER) artifact SHALL be an authenticated
   self-contained object signed by the pledge, containing a PKCS#10
   Certificate Signing Request (CSR) [RFC2986].  The CSR already assures
   POP of the private key corresponding to the contained public key.  In
   addition, based on the PER signature using the IDevID of the pledge,
   POI is provided.

   For the JWS-signed JSON format used by this specification, the PER
   artifact MUST use the "General JWS JSON Serialization Syntax" defined
   in Section 7.2.1 of [RFC7515], which MUST contain the JSON CSR Data
   defined in Section 7.2.2.1 in the JWS Payload.  Figure 16 summarizes
   the serialization of the JWS-signed JSON PER artifact:

   {
     "payload": BASE64URL(UTF8(JSON CSR Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

      Figure 16: PER Representation in General JWS JSON Serialization
                                   Syntax

   The JSON CSR Data MUST be UTF-8 encoded to become the octet-based JWS
   Payload defined in [RFC7515].  The JWS Payload is further base64url-
   encoded to become the string value of the payload member as described
   in Section 3.2 of [RFC7515].  The octets of the UTF-8 representation
   of the JWS Protected Header are base64url-encoded to become the
   string value of the protected member.  The generated JWS Signature is
   base64url-encoded to become the string value of the signature member.

7.2.2.1.  JSON CSR Data

   The JSON CSR Data SHALL be a JSON document [RFC8259] that MUST
   conform with the data model described by the csr-grouping of the
   ietf-ztp-types YANG module defined in Section 3.2 of [RFC9646] and
   MUST be encoded using the rules defined in [RFC7951].  Note that
   [RFC9646] also allows for inclusion of CSRs in different formats used
   by CMP and CMC.  For PKCS#10 CSRs as used in BRSKI and BRSKI-PRM, the
   p10-csr case of the csr-grouping MUST be used.

   Figure 17 below shows an example for the JSON CSR Data:




Fries, et al.            Expires 5 December 2025               [Page 42]

Internet-Draft                  BRSKI-PRM                      June 2025


   {
     "ietf-ztp-types": {
        "p10-csr": "base64encodedvalue=="
      }
   }

                      Figure 17: JSON CSR Data Example

7.2.2.2.  JWS Protected Header

   The JWS Protected Header of the PER artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

   *  x5c: SHALL contain the base64-encoded pledge EE certificate used
      to sign the PER artifact and it SHOULD also contain the
      certificate chain for this certificate.  The certificate chain
      MUST be available for certificate verification.  If it is not
      contained in the x5c Header Parameter it is provided to the
      relying party by other means such as configuration.

   *  crit: SHALL indicate the extension Header Parameter created-on to
      ensure that it must be understood and validated by the receiver as
      defined in Section 4.1.11 of [RFC7515].

   In addition, the JWS Protected Header of the PER artifact MUST
   contain the following extension Header Parameter:

   *  created-on: SHALL contain the current date and time at PER
      creation as standard date/time string as defined in Section 5.6 of
      [RFC3339]; if the pledge does not have synchronized time, it SHALL
      use the created-on value from the JSON Agent-Signed Data received
      with the tPVR artifact and SHOULD advance that value based on its
      local clock to reflect the PER creation time.

   The new protected Header Parameter created-on is introduced to
   reflect freshness of the PER.  It allows the registrar to verify the
   timely correlation between the PER artifact and previous exchanges,
   i.e., created-on of PER >= created-on of PVR >= created-on of PVR
   trigger.  The registrar MAY ignore any but the newest PER artifact
   from the same pledge in case the registrar has at any point in time
   more than one pending PER from the pledge.

   Figure 18 shows an example for this JWS Protected Header:





Fries, et al.            Expires 5 December 2025               [Page 43]

Internet-Draft                  BRSKI-PRM                      June 2025


   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ],
     "crit": ["created-on"],
     "created-on": "2025-01-13T00:00:02.000Z"
   }

             Figure 18: JWS Protected Header Example within PER

7.2.2.3.  JWS Signature

   The pledge MUST sign the PER artifact using its IDevID credential.
   The JWS Signature is generated over the JWS Protected Header and the
   JWS Payload as described in Section 5.1 of [RFC7515].  Algorithms
   used for JWS signatures MUST support ES256 as recommended in
   [RFC7518] and MAY support further algorithms.

   While BRSKI-PRM targets the initial enrollment, re-enrollment can be
   supported similarly.  In this case, the pledge MAY use its current,
   potentially application-related EE credential instead of its IDevID
   credential to sign the PER artifact.  The issuing CA can associate
   the re-enrollment request with the pledge based on the previously
   issued and still valid EE certificate.  Note that a pledge that does
   not have synchronized time needs to advance the last known current
   date and time based on its local clock over a longer period, which
   also requires persisting the local clock advancements across reboots.

7.3.  Supply PVR to Registrar (including MASA interaction)

   Once the Registrar-Agent has acquired one or more PVR and PER object
   pairs, it starts the interaction with the domain registrar.
   Collecting multiple pairs allows bulk bootstrapping of several
   pledges using the same session with the registrar.

   The Registrar-Agent MUST establish a TLS session to the registrar
   with mutual authentication.  In contrast to BRSKI [RFC8995], the TLS
   client authentication uses the Registrar-Agent EE certificate instead
   of the pledge IDevID certificate.  Consequently, the domain registrar
   can distinguish BRSKI (pledge-initiator-mode) from BRSKI-PRM (pledge-
   responder-mode).

   Figure 19 shows the voucher-request processing and the following
   subsections describe the corresponding artifacts.





Fries, et al.            Expires 5 December 2025               [Page 44]

Internet-Draft                  BRSKI-PRM                      June 2025


 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (3) Supply PVR to Registrar (including backend interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<-----mTLS------>|                 |            |
  |                  |                 |                 |            |
  |                  |         [Registrar-Agent          |            |
  |                  |    authenticated&authorized?]     |            |
  |                  |                 |                 |            |
  |                  |-------PVR------>|                 |            |
  |                  |                 |                 |            |
  |                  |          [accept device?]         |            |
  |                  |                 |                 |            |
  |                  |                 |<------------mTLS------------>|
  |                  |                 |--------------RVR------------>|
  |                  |                 |                 ~            |
  |                  |                 |              [extract DomainID]
  |                  |                 |              [update audit-log]
  |                  |                 |                 ~            |
  |                  |                 |<-----------Voucher-----------|
  |                  |<----Voucher''---|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                  Figure 19: Voucher issuing exchange

   As a first step of the interaction with the domain registrar, the
   Registrar-Agent SHALL supply the PVR artifact(s) to the registrar via
   HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/
   requestvoucher.  Note that this is the same endpoint as for BRSKI
   described in Section 5.2 of [RFC8995].  The request body MUST contain
   one previously acquired PVR artifact as defined in Section 7.1.2.  In
   the request header, the Content-Type field MUST be set to
   application/voucher-jws+json and the Accept field SHOULD be set to
   application/voucher-jws+json as defined in
   [I-D.ietf-anima-jws-voucher].

   Upon receiving a PVR artifact, the registrar accepts or declines the
   request to join the domain.  For this, it MUST perform pledge
   authorization as defined in Section 5.3 of [RFC8995].  Due to the
   Registrar-Agent in the middle, the registrar MUST verify in addition
   that




Fries, et al.            Expires 5 December 2025               [Page 45]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  the agent-provided-proximity-registrar-cert field of the PVR
      contains a registrar EE certificate signed by the same domain
      owner as the registrar EE certificate used to sign the RVR; note
      that this check allows for installations with multiple domain
      registrars and for registrar EE certificate renewal between
      exchanges with the Registrar-Agent (see Section 5.2); in many
      installations with a single registrar the contained certificate is
      identical to the signing certificate.

   *  the agent-signed-data field of the PVR is signed with the private
      key corresponding to the Registrar-Agent EE certificate as known
      by the registrar (see Section 6.3); this is done via the
      SubjectKeyIdentifier of the certificate in the kid Header
      Parameter of the JWS Protected Header of the agent-signed-data
      field.

   *  the product-serial-number inside the agent-signed-data is equal to
      the serial-number field of the PVR as well as the X520SerialNumber
      field of the pledge IDevID certificate, which is contained in the
      JWS Protected Header of the PVR.

   *  the Registrar-Agent EE certificate is still valid; this is
      necessary to avoid that a rogue Registrar-Agent generates agent-
      signed-data objects to onboard arbitrary pledges at a later point
      in time, see also Section 12.3.

   If the registrar is unable to process the request or validate the
   PVR, it responds with an HTTP client error status code to the
   Registrar-Agent.  The following client error status codes can be
   used:

   *  400 Bad Request: if the registrar detects an error in the format
      of the request.

   *  403 Forbidden: if the registrar detected that one or more security
      related fields are not valid or if the pledge-provided information
      could not be used with automated allowance.

   *  406 Not Acceptable: if the Accept request header field indicates a
      type that is unknown or unsupported.

   *  415 Unsupported Media Type: if the Content-Type request header
      field indicates a type that is unknown or unsupported.

   Otherwise, the registrar converts the PVR artifact to a Registrar
   Voucher-Request (RVR) artifact (see Section 7.3.4) and starts the
   backend interaction with the MASA.




Fries, et al.            Expires 5 December 2025               [Page 46]

Internet-Draft                  BRSKI-PRM                      June 2025


   The domain registrar can respond with an HTTP 202 Accepted response
   status code to the Registrar-Agent at this point following
   Section 5.6 of [RFC8995], while the rules defined for the pledge also
   apply to the Registrar-Agent; in this case, the registrar still
   continues with the MASA interaction to provide the Voucher artifact
   to the retry request.

   The registrar MAY use the response body to signal success/failure
   details to the service technician operating the Registrar-Agent.

7.3.1.  MASA Interaction

   The domain registrar MUST establish a TLS session with mutual
   authentication to the MASA of the pledge according to Section 5.4 of
   [RFC8995].  It requests the voucher from the MASA according to
   Section 5.5 of [RFC8995] via HTTP-over-TLS POST to the MASA endpoint
   at /.well-known/brski/requestvoucher.  The request body MUST contain
   the RVR artifact as defined in Section 7.3.4.  In the request header,
   the Content-Type field and the Accept field MUST be set to the same
   media type as the incoming PVR artifact.  For the default format used
   in this specification, this is application/voucher-jws+json as
   defined in [I-D.ietf-anima-jws-voucher].

   The assumption is that a pledge typically supports a single artifact
   format and creates the PVR in the supported format; to ensure that
   the pledge is able to process the voucher, the registrar requests
   this format via the HTTP Accept header field when requesting the
   voucher.  Further, the RVR artifact and the PVR artifact inside
   should also use the same format to limit the number of required
   format encoders.  Note that BRSKI-PRM allows for alternative formats
   such as CMS-signed JSON as used in BRSKI [RFC8995] or COSE-signed
   CBOR for constrained environments, when defined by other
   specifications.  Overall, a MASA responsible for BRSKI-PRM capable
   pledges consequently supports the same formats as supported by those
   pledges.

   Once the MASA receives the RVR artifact, it MUST perform the
   verification as described in Section 5.5 of [RFC8995].  Depending on
   policy, the MASA MAY choose the type of assertion to perform.  For
   the Agent Proximity Assertion of BRSKI-PRM (see Section 5.4), the
   MASA MUST skip the verification described in Section 5.5.5 of
   [RFC8995] and instead MUST verify for the PVR contained in the prior-
   signed-voucher-request field of the RVR that








Fries, et al.            Expires 5 December 2025               [Page 47]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  the agent-provided-proximity-registrar-cert field contains an EE
      certificate that is signed by the same domain owner as the EE
      certificate/credentials used to sign the RVR; note that this check
      allows for installations with multiple domain registrars and for
      registrar EE certificate renewal while PVRs are collected by the
      Registrar-Agent.

   *  the registrar EE certificate in the agent-provided-proximity-
      registrar-cert field and the Registrar-Agent EE certificate in the
      agent-sign-cert field of the RVR are signed by the same domain
      owner.

   *  the agent-signed-data field is signed with the credentials
      corresponding to the Registrar-Agent EE certificate in the agent-
      sign-cert field of the RVR; this is done via the
      SubjectKeyIdentifier of the certificate in the kid Header
      Parameter of the JWS Protected Header in the agent-signed-data
      field.

   *  the product-serial-number inside the agent-signed-data is equal to
      the serial-number field of PVR and the serial-number field of the
      RVR as well as the X520SerialNumber field of the pledge IDevID
      certificate, which is contained in the JWS Protected Header of the
      PVR.

   If the agent-sign-cert field in the RVR is not set, the MASA MAY
   state a lower level assertion value instead of failing the
   verification, e.g., "logged" or "verified".

   If the verification fails, the MASA responds with an HTTP client
   error status code to the registrar.  The client error status codes
   are kept the same as defined in Section 5.6 of [RFC8995]:

   *  403 Forbidden: if the voucher-request is not signed correctly or
      is stale or if the pledge has another outstanding voucher that
      cannot be overridden.

   *  404 Not Found: if the request is for a device that is not known to
      the MASA.

   *  406 Not Acceptable: if a voucher of the desired type or that uses
      the desired algorithms (as indicated by the "Accept" header fields
      and algorithms used in the signature) cannot be issued as such
      because the MASA knows the pledge cannot process that type.

   *  415 Unsupported Media Type: if the request uses an artifact format
      or Accept header value that is not supported by the MASA.




Fries, et al.            Expires 5 December 2025               [Page 48]

Internet-Draft                  BRSKI-PRM                      June 2025


   Otherwise, the MASA creates a Voucher artifact as defined in
   Section 7.3.5 and updates the audit-log as described in Section 5.5
   of [RFC8995].  The Voucher is then supplied to the registrar within
   the body of an HTTP 200 OK response according to Section 5.6 of
   [RFC8995].  In the response header, the Content-Type field MUST be
   set to the media type of the incoming RVR artifact.  For the default
   format used in this specification, this is application/voucher-
   jws+json as defined in [I-D.ietf-anima-jws-voucher].

7.3.2.  Supply Voucher to Registrar-Agent

   After receiving the Voucher from the MASA, the registrar SHOULD
   evaluate it for transparency and logging purposes as outlined in
   Section 5.6 of [RFC8995].  It then countersigns the Voucher for
   delivery to the pledge via the Registrar-Agent.

   The registrar MUST reply to the Registrar-Agent with the registrar-
   countersigned Voucher artifact ('Voucher') as defined in
   Section 7.3.6 in the body of an HTTP 200 OK response.  In the
   response header, the Content-Type field MUST be set to the media type
   of the incoming PVR artifact.  For the default format used in this
   specification, this is application/voucher-jws+json as defined in
   [I-D.ietf-anima-jws-voucher].

   If the domain registrar is unable to return the Voucher, it responds
   with an HTTP server error status code to the Registrar-Agent.  The
   following server error status codes can be used:

   *  500 Internal Server Error: if both Registrar-Agent request and
      MASA response are valid, but the registrar still failed to return
      the Voucher, e.g., due to missing configuration or a program
      failure.

   *  502 Bad Gateway: if the registrar received an invalid response
      from the MASA.

   *  503 Service Unavailable: if a simple retry of the Registrar-Agent
      request might lead to a successful response; this error response
      MUST include the Retry-After response header field with an
      appropriate value.

   *  504 Gateway Timeout: if the backend request to the MASA timed out.

7.3.3.  Request Artifact: Pledge Voucher-Request (PVR)

   Identical to the PVR artifact received from the pledge as defined in
   Section 7.1.2.  The Registrar-Agent MUST NOT modify PVRs.




Fries, et al.            Expires 5 December 2025               [Page 49]

Internet-Draft                  BRSKI-PRM                      June 2025


7.3.4.  Backend Request Artifact: Registrar Voucher-Request (RVR)

   The Registrar Voucher-Request (RVR) artifact SHALL be an extended
   Voucher-Request artifact based on Section 5.5 of [RFC8995].  The
   BRSKI-PRM related enhancements of the ietf-voucher-request YANG
   module are defined in [I-D.ietf-anima-rfc8366bis].

   For the JWS-signed JSON format used by this specification, the RVR
   artifact MUST be a JWS Voucher structure as defined in
   [I-D.ietf-anima-jws-voucher], which MUST contain the JSON RVR Data
   defined in Section 7.3.4.1 in the JWS Payload.  Figure 20 summarizes
   the serialization of the JWS-signed JSON RVR artifact:

   {
     "payload": BASE64URL(UTF8(JSON RVR Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

      Figure 20: RVR Representation in General JWS JSON Serialization
                                   Syntax

7.3.4.1.  JSON RVR Data

   The JSON RVR Data MUST contain the following fields of the ietf-
   voucher-request YANG module as defined in
   [I-D.ietf-anima-rfc8366bis]; note that this makes optional leaves in
   the YANG definition mandatory for the RVR artifact:

   *  created-on: SHALL contain the current date and time at RVR
      creation as standard date/time string as defined in Section 5.6 of
      [RFC3339]

   *  nonce: SHALL contain a copy of the nonce field from the JSON PVR
      Data the registrar provides this information to assure successful
      verification of Registrar-Agent proximity based on the agent-
      signed-data

   *  serial-number: SHALL contain the product-serial-number of the
      pledge; note the required verification by the registrar defined in
      Section 7.3






Fries, et al.            Expires 5 December 2025               [Page 50]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  idevid-issuer: SHALL contain the issuer value from the pledge
      IDevID certificate obtained from the PVR JWS Protected Header x5c
      field

   *  prior-signed-voucher-request: SHALL contain the PVR artifact as
      received from the Registrar-Agent, see Section 7.1

   As BRSKI-PRM uses the Agent Proximity Assertion (see Section 5.4),
   the JSON RVR Data MUST also contain the following fields:

   *  assertion: SHALL contain the value agent-proximity to indicate
      successful verification of the Agent Proximity Assertion (see
      Section 5.4) by the registrar.

   *  agent-sign-cert: SHALL be a JSON array that contains the
      base64-encoded Registrar-Agent EE certificate as possessed by the
      registrar (see Section 6.3) as the first item; subsequent items
      MUST contain the corresponding certificate chain for verification
      at the MASA; the field is used for verification of the agent-
      signed-data field of the contained PVR.

   Note that the ietf-voucher-request YANG module defines the leaf
   agent-sign-cert as binary; this specification refines it as a JSON
   array structure similar to the x5c Header Parameter defined in
   Section 4.1.6 of [RFC7515].

   Figure 21 shows an example for the JSON RVR Data:

   {
     "ietf-voucher-request:voucher": {
        "created-on": "2025-01-04T02:37:39.235Z",
        "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
        "serial-number": "vendor-pledge4711",
        "idevid-issuer": "base64encodedvalue==",
        "prior-signed-voucher-request": "base64encodedvalue==",
        "assertion": "agent-proximity",
        "agent-sign-cert": [
          "base64encodedvalue==",
          "base64encodedvalue==",
          "..."
        ]
     }
   }

                      Figure 21: JSON RVR Data Example






Fries, et al.            Expires 5 December 2025               [Page 51]

Internet-Draft                  BRSKI-PRM                      June 2025


7.3.4.2.  JWS Protected Header

   The JWS Protected Header MUST follow the definitions of Section 3.2
   of [I-D.ietf-anima-jws-voucher].

7.3.4.3.  JWS Signature

   The domain registrar MUST sign the RVR artifact using its EE
   credentials following the definitions of Section 3.3 of
   [I-D.ietf-anima-jws-voucher].  Algorithms used for JWS signatures
   MUST support ES256 as recommended in [RFC7518] and MAY support
   further algorithms.

7.3.5.  Backend Response Artifact: Voucher

   The Voucher artifact is defined in Section 5.6 of [RFC8995] (cf.
   "voucher response").  The only difference for BRSKI-PRM is that the
   assertion field MAY contain the value agent-proximity as defined in
   [I-D.ietf-anima-rfc8366bis], when the Agent-Proximity Assertion (see
   Section 5.4) is performed by the MASA.

   For the JWS-signed JSON format used by this specification, the
   Voucher artifact MUST be a JWS Voucher structure as defined in
   [I-D.ietf-anima-jws-voucher].  It contains JSON Voucher Data in the
   JWS Payload, for which an example is given in Figure 22:

   {
     "ietf-voucher:voucher": {
       "created-on": "2025-01-04T00:00:02.000Z",
       "nonce": "base64encodedvalue==",
       "assertion": "agent-proximity",
       "pinned-domain-cert": "base64encodedvalue==",
       "serial-number": "vendor-pledge4711"
     }
   }

                      Figure 22: JSON RVR Data Example

7.3.6.  Response Artifact: Registrar-Countersigned Voucher

   The Registrar-Countersigned Voucher (Voucher') artifact SHALL be an
   extended Voucher artifact based on Section 5.6 of [RFC8995] using the
   format defined in Section 7.3.5.

   For BRSKI-PRM, the domain registrar MUST add an JWS Protected Header
   and JWS Signature to the MASA-provided Voucher.  Figure 23 summarizes
   the serialization of the JWS-signed JSON Voucher' artifact:




Fries, et al.            Expires 5 December 2025               [Page 52]

Internet-Draft                  BRSKI-PRM                      June 2025


   {
     "payload": BASE64URL(JSON Voucher Data),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header (MASA))),
         "signature": BASE64URL(JWS Signature (MASA))
       },
       {
         "protected": BASE64URL(UTF8(JWS Protected Header (Registrar))),
         "signature": BASE64URL(JWS Signature (Registrar))
       }
     ]
   }

           Figure 23: Voucher' Representation in General JWS JSON
                            Serialization Syntax

   In BRSKI [RFC8995], the registrar proves possession of its credential
   through the server authentication within the TLS session with the
   pledge.  While the pledge cannot verify the registrar certificate at
   the time of TLS session establishment, it can verify the TLS server
   certificate through the certificate in the pinned-domain-cert field
   upon receiving the Voucher artifact (see Section 5.6.2 of [RFC8995]).

   In BRSKI-PRM with the Registrar-Agent mediating all communication,
   this second signature provides verification and POP of the private
   key for the registrar EE certificate provided in the initial tPVR
   artifact from the Registrar-Agent (see Section 7.1.1).

   Depending on the security policy of the operator, this signature can
   also be interpreted as explicit authorization of the registrar to
   install the contained trust anchor (i.e., pinned domain certificate).

7.3.6.1.  JSON Voucher Data

   As provided by the MASA inside the JWS Payload.  The domain registrar
   MUST NOT modify the JWS Payload.

7.3.6.2.  JWS Protected Header (Registrar)

   The registrar-added JWS Protected Header (Registrar) MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].






Fries, et al.            Expires 5 December 2025               [Page 53]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  x5c: SHALL contain the base64-encoded registrar EE certificate
      used to sign the voucher as well as the certificate chain up to
      (but not including) the pinned domain certificate (the initial
      domain trust anchor); the pinned domain certificate is already
      contained in the JSON Voucher Data.

   Note that for many installations with a single registrar credential,
   the registrar EE certificate is pinned.

7.3.6.3.  JWS Signature (Registrar)

   The signature is created by signing the registrar-added JWS Protected
   Header (Registrar) and the original JWS Payload produced by the MASA
   as described in Section 5.1 of [RFC7515].  Algorithms used for JWS
   signatures MUST support ES256 as recommended in [RFC7518] and MAY
   support further algorithms.

   The registrar MUST use its EE credentials to sign.

   Note that the credentials need to be the same as used for server
   authentication in the TLS session with the Registrar-Agent receiving
   this artifact (see Section 6.3).

7.4.  Supply PER to Registrar (including Key Infrastructure interaction;
      requestenroll)

   After receiving the Voucher artifact, the Registrar-Agent sends the
   PER to the domain registrar within the same TLS session.

   In case the TLS session to the registrar is already closed, the
   Registrar-Agent establishes a new session as described in
   Section 7.3.  The registrar is able to correlate the PVR and PER
   artifacts based on the signatures and the contained product-serial-
   number.  Note that this also addresses situations in which a
   nonceless voucher is used and may be pre-provisioned to the pledge.

   Figure 24 depicts exchanges for the PER-request handling and the
   following subsections describe the corresponding artifacts.  Note
   that "Request" and "Certificate" do not denote BRSKI-PRM defined
   artifacts, but are data objects depending on the certificate
   management protocol used by the domain Key Infrastructure.










Fries, et al.            Expires 5 December 2025               [Page 54]

Internet-Draft                  BRSKI-PRM                      June 2025


 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (4) Supply PER to Registrar (including Key Infrastructure interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<----(mTLS)----->|                 |            |
  |                  |-------PER------>|                 |            |
  |                  |                 |----[Request]--->|            |
  |                  |                 |<--[Certificate]-|            |
  |                  |<--Enroll-Resp---|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                       Figure 24: Enroll exchange

   As a second step of the interaction with the domain registrar, the
   Registrar-Agent SHALL supply the PER artifact(s) to the registrar via
   HTTP-over-TLS POST to the registrar endpoint at /.well-known/brski/
   requestenroll.  The request body MUST contain one previously acquired
   PER artifact as defined in Section 7.2.2.  In the request header, the
   Content-Type field MUST be set to application/jose+json and the
   Accept field SHOULD be set to application/jose+json.

   Note that this is different from the EST [RFC7030] endpoint used in
   BRSKI, as the PER artifact is signature-wrapped.  Hence, upon
   receiving a PER artifact, the registrar MUST verify that

   *  the PER was signed with the private key corresponding to the
      pledge EE certificate, which is contained in the JWS Protected
      Header of the PER.

   *  the pledge identified by its EE certificate is accepted to join
      the domain after successful validation of the corresponding PVR.

   If the registrar is unable to process the request or validate the
   PER, it responds with an HTTP client error status code to the
   Registrar-Agent.  The following client error status codes can be
   used:

   *  400 Bad Request: if the registrar detects an error in the format
      of the request.

   *  403 Forbidden: if the signature of the PER cannot be verified.




Fries, et al.            Expires 5 December 2025               [Page 55]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  404 Not Found: if the PER is for a device that is not known to the
      registrar.

   *  406 Not Acceptable: if the Accept request header field indicates a
      type that is unknown or unsupported, e.g., a type other than
      application/jose+json.

   *  415 Unsupported Media Type: if the PER uses an artifact format
      that is not supported by the registrar, e.g., a type other than
      application/jose+json.

   Otherwise, the registrar extracts the PKCS#10 Certificate Signing
   Request (CSR) inside the PER (see Section 7.2.2) and uses the CSR to
   request a new pledge EE certificate from the domain Key
   Infrastructure.  The exact interaction and exchanged data objects
   depends on the certificate management protocol used by the Key
   Infrastructure, and is out of scope for this document.

   A successful interaction with the Key Infrastructure will result in a
   pledge EE certificate signed by the domain owner (e.g., LDevID
   certificate).  The registrar MUST reply to the Registrar-Agent with
   the Enroll-Response (Enroll-Resp) as defined in Section 7.4.2 in the
   body of an HTTP 200 OK response.  In the response header, the
   Content-Type field MUST be set to application/pkcs7-mime with an
   smime-type parameter certs-only, as specified in [RFC7030] and
   [RFC5273].

   If the domain registrar is unable to return the Enroll-Resp, it
   responds with an HTTP server error status code to the Registrar-
   Agent.  The following server error status codes can be used:

   *  500 Internal Server Error: if the Key Infrastructure response is
      valid, but the registrar still failed to return the Enroll-Resp,
      e.g., due to missing configuration or a program failure.

   *  502 Bad Gateway: if the registrar received an invalid response
      from the Key Infrastructure.

   *  503 Service Unavailable: if a simple retry of the Registrar-Agent
      request might lead to a successful response; this error response
      MUST include the Retry-After response header field with an
      appropriate value.

   *  504 Gateway Timeout: if the backend request to the Key
      Infrastructure timed out.






Fries, et al.            Expires 5 December 2025               [Page 56]

Internet-Draft                  BRSKI-PRM                      June 2025


   Note that while BRSKI-PRM targets the initial enrollment, re-
   enrollment may be supported similarly with the exception that the
   current, potentially application-related pledge EE certificate is
   used instead of the IDevID certificate to sign the PER artifact (see
   also Section 7.2).  Hence, there is no verification whether the
   pledge is accepted to join the domain, as the still valid EE
   certificate signed by the domain owner identifies the pledge as
   already accepted component of the domain.

7.4.1.  Request Artifact: Pledge Enroll-Request (PER)

   Identical to the PER artifact defined in Section 7.2.2.  The
   Registrar-Agent MUST NOT modify PERs received from pledges.

7.4.2.  Response Artifact: Registrar Enroll-Response (Enroll-Resp)

   The Enroll-Response (Enroll-Resp) artifact SHALL be an authenticated
   self-contained object signed by the domain owner, containing a pledge
   EE certificate.

   For this specification, the Enroll-Resp artifact MUST be a certs-only
   CMC Simple PKI Response (PKCS#7) as defined in Section 4.1 of
   [RFC5272] (following EST [RFC7030]).  Note that it only contains the
   pledge EE certificate, but not the certificate chain.  The chain is
   provided with the CA certificates.

7.5.  Obtain CA Certificates (wrappedcacerts)

   The pinned domain certificate in the voucher is only the initial
   trust anchor for only the domain registrar.  To fully trust the
   domain and also to verify its own EE certificate, the pledge also
   needs the corresponding domain CA certificate(s).  A bag of CA
   certificates signed by the registrar will allow the pledge to verify
   the authorization to install the received CA certificate(s) through
   the pinned domain certificate in the voucher.

   Note that this is a deviation from EST [RFC7030] used in BRSKI
   [RFC8995].

   The Registrar-Agent obtains this artifact within the same TLS
   session.  In case the TLS session to the registrar is already closed,
   the Registrar-Agent establishes a new session as described in
   Section 7.3.  The CA certificates do not need to be correlated to a
   specific voucher or Enroll-Response; they only need to be fresh.

   Figure 25 shows the acquisition of the CA certificate(s) and the
   following subsections describe the corresponding artifact.




Fries, et al.            Expires 5 December 2025               [Page 57]

Internet-Draft                  BRSKI-PRM                      June 2025


 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (5) Obtain CA Certificates
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<----(mTLS)----->|                 |            |
  |                  |<----caCerts-----|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

             Figure 25: CA certificates retrieval exchange

   As a third step of the interaction with the domain registrar, the
   Registrar-Agent SHALL obtain the CA-Certificates artifact from the
   registrar via HTTP-over-TLS GET to the registrar endpoint at /.well-
   known/brski/wrappedcacerts.  In the request header, the Accept field
   SHOULD be set to application/jose+json.

   Upon receiving a GET request at /.well-known/brski/wrappedcacerts,
   the domain registrar MUST reply with the CA-Certificates artifact as
   defined in Section 7.5.2 in the body of an HTTP 200 OK response.  In
   the response header, the Content-Type field MUST be set to
   application/jose+json.

7.5.1.  Request (no artifact)

   In this exchange, the request is a result of the HTTP(S) default
   transport for this specification.  There is no artifact provided to
   the registrar.  As the caCerts artifact processing on the pledge may
   result in errors, signaled via HTTP status codes, the Registrar-Agent
   should log these for evaluation as outlined in Section 8.

7.5.2.  Response Artifact: CA-Certificates (caCerts)

   The CA-Certificates (caCerts) artifact SHALL be an authenticated
   self-contained object signed by the registrar, containing the domain
   trust anchors and the certificate chain for the pledge domain EE
   certificate, i.e., the root CA certificate(s) and possibly
   intermediate certificate(s) as described in Section 4.1.3 of
   [RFC7030].







Fries, et al.            Expires 5 December 2025               [Page 58]

Internet-Draft                  BRSKI-PRM                      June 2025


   For the JWS-signed JSON format used by this specification, the
   caCerts artifact MUST use the "General JWS JSON Serialization Syntax"
   defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON CA
   Data defined in Section 7.5.2.1 in the JWS Payload.

   Figure 26 summarizes the serialization of the JWS-signed JSON caCerts
   artifact:

   {
     "payload": BASE64URL(UTF8(JSON CA Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

           Figure 26: Voucher' Representation in General JWS JSON
                            Serialization Syntax

   The JSON CA Data MUST be UTF-8 encoded to become the octet-based JWS
   Payload defined in [RFC7515].  The JWS Payload is further base64url-
   encoded to become the string value of the payload member as described
   in Section 3.2 of [RFC7515].  The octets of the UTF-8 representation
   of the JWS Protected Header are base64url-encoded to become the
   string value of the protected member.  The generated JWS Signature is
   base64url-encoded to become the string value of the signature member.

7.5.2.1.  JSON CA Data

   The JSON CA Data SHALL be a JSON document [RFC8259] that MUST conform
   with the CDDL [RFC8610] data model defined in Figure 27:

   cacerts = {
       "x5bag": bytes / [2* bytes]
   }

                 Figure 27: CDDL for JSON CA Data (cacerts)

   The x5bag member MUST follow the definition of the x5bag COSE Header
   Parameter in Section 2 of [RFC9360].  It is either a single X.509 v3
   certificate or an array of at least two X.509 v3 certificates in DER
   format.  For JSON syntax, the octet-based certificates MUST be
   base64-encoded.  It SHALL contain one or more domain CA (root or
   issuing) certificates.





Fries, et al.            Expires 5 December 2025               [Page 59]

Internet-Draft                  BRSKI-PRM                      June 2025


   Note that as per [RFC8995], the domain registrar acts as EST server,
   and hence is expected to possess the CA certificates applicable for
   the domain and can thus deliver them to the pledge (see Section 6.3).

   Figure 28 below shows an example for the JSON CA Data:

   {
     "x5bag": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }

                      Figure 28: JSON CA Data Example

7.5.2.2.  JWS Protected Header

   The JWS Protected Header of the caCerts artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

   *  x5c: SHALL contain the base64-encoded registrar EE certificate
      used to sign the caCerts artifact as well as the certificate chain
      up to (but not including) the pinned domain certificate

   Figure 29 below shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }

             Figure 29: JWS Protected Header Example within PER

7.5.2.3.  JWS Signature

   The registrar MUST sign the caCerts artifact using its EE
   credentials.  The JWS Signature is generated over the JWS Protected
   Header and the JWS Payload as described in Section 5.1 of [RFC7515].
   Algorithms used for JWS signatures MUST support ES256 as recommended
   in [RFC7518] and MAY support further algorithms.





Fries, et al.            Expires 5 December 2025               [Page 60]

Internet-Draft                  BRSKI-PRM                      June 2025


7.6.  Supply Voucher to Pledge (svr)

   Once the Registrar-Agent has acquired the following three
   bootstrapping artifacts, it can supply them to the pledge starting
   with the Voucher':

   *  Voucher': voucher countersigned by the registrar (from MASA via
      Registrar)

   *  Enroll-Resp: pledge EE certificate signed by the domain owner
      (from Key Infrastructure via registrar)

   *  caCerts: domain trust anchors (from Key Infrastructure via
      Registrar)

   Reconnecting to the pledge might require to re-discover the pledge as
   described in Section 6.1.2.  The Registrar-Agent MAY store
   information from the first connection with the pledge to optimize
   this process.

   TLS MAY be used to provide privacy for this exchange between the
   Registrar-Agent and the pledge (see Appendix B).

   Figure 30 shows the provisioning of the voucher to the pledge and the
   following subsections describe the corresponding artifacts.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (6) Supply Voucher to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----Voucher''---|                 |                 |            |
  |------vStatus---->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                      Figure 30: Voucher exchange

   The Registrar-Agent SHALL supply the voucher to the pledge via
   HTTP(S) POST to the pledge endpoint at /.well-known/brski/svr.  The
   request body MUST contain the Registrar-Countersigned Voucher
   (Voucher') artifact previously acquired from the domain registrar as
   defined in Section 7.3.6.  In the request header, the Content-Type



Fries, et al.            Expires 5 December 2025               [Page 61]

Internet-Draft                  BRSKI-PRM                      June 2025


   field MUST be set to application/voucher-jws+json as defined in
   [I-D.ietf-anima-jws-voucher] and the Accept field SHOULD be set to
   application/jose+json, to indicate the encoding of the vStatus
   response object status telemetry message.

   Upon receiving the voucher, the pledge SHALL perform the signature
   verification in the following order:

   1.  Verify the MASA signature as described in Section 5.6.1 of
       [RFC8995] against the pre-installed manufacturer trust anchor
       (e.g., IDevID).

   2.  Provisionally install the initial domain trust anchor contained
       in the pinned-domain-cert field of the voucher.

   3.  Validate the registrar EE certificate received in the agent-
       provided-proximity-registrar-cert field of the previously
       received tPVR artifact using the pinned domain certificate; this
       terminates the "provisional state" for the object security within
       the authenticated self-contained objects that in BRSKI-PRM
       replace the direct TLS connection to the registrar in BRSKI
       [RFC8995] (see Section 5.4).

   4.  Verify registrar signature of the Voucher' artifact similar as
       described in Section 5.6.1 of [RFC8995], but using the pinned
       domain certificate instead of the MASA certificate for the
       verification.

   If all steps above complete successfully, the pledge SHALL terminate
   the "provisional state" for the initial domain trust anchor (i.e.,
   the pinned domain certificate).

   A nonceless voucher MAY be accepted as in [RFC8995] if allowed by the
   pledge implementation of the manufacturer.  A manufacturer may opt to
   provide the acceptance of nonceless voucher as configurable item.

   After voucher validation and verification, the pledge needs to reply
   with a status telemetry message as defined in Section 5.7 of
   [RFC8995].  The pledge MUST generate the Voucher Status (vStatus)
   artifact as defined in Section 7.6.2 and MUST provide it to the
   Registrar-Agent in the body of an HTTP 200 OK response.  In the
   response header, the Content-Type field MUST be set to application/
   jose+json.

   If the pledge is unable to validate or verify the voucher, it MUST
   report the reason in the corresponding field of the Voucher Status.





Fries, et al.            Expires 5 December 2025               [Page 62]

Internet-Draft                  BRSKI-PRM                      June 2025


   If the pledge did not provide voucher status telemetry information
   after processing the voucher, the Registrar-Agent MAY query the
   pledge status explicitly as described in Section 7.11.  It MAY resend
   the voucher depending on the Pledge status following the same
   procedure.

7.6.1.  Request Artifact: Registrar-Countersigned Voucher

   Identical to the Registrar-Countersigned Voucher (Voucher') artifact
   received from the registrar as defined in Section 7.3.6.  The
   Registrar-Agent MUST NOT modify countersigned vouchers.

7.6.2.  Response Artifact: Voucher Status (vStatus)

   The Voucher Status (vStatus) artifact SHALL be an authenticated self-
   contained object signed by the pledge, containing status telemetry as
   defined in Section 5.7 of [RFC8995].

   For the JWS-signed JSON format used by this specification, the
   vStatus artifact MUST use the "General JWS JSON Serialization Syntax"
   defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
   Voucher Status Data defined in Section 7.6.2.1 in the JWS Payload.
   Figure 31 summarizes the serialization of the JWS-signed JSON vStatus
   artifact:

   {
     "payload": BASE64URL(UTF8(JSON Voucher Status Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

           Figure 31: vStatus Representation in General JWS JSON
                            Serialization Syntax

   The JSON Status Data MUST be UTF-8 encoded to become the octet-based
   JWS Payload defined in [RFC7515].  The JWS Payload is further
   base64url-encoded to become the string value of the payload member as
   described in Section 3.2 of [RFC7515].  The octets of the UTF-8
   representation of the JWS Protected Header are base64url-encoded to
   become the string value of the protected member.  The generated JWS
   Signature is base64url-encoded to become the string value of the
   signature member.





Fries, et al.            Expires 5 December 2025               [Page 63]

Internet-Draft                  BRSKI-PRM                      June 2025


7.6.2.1.  JSON Voucher Status Data

   The JSON Status Data SHALL be a JSON document [RFC8259] that MUST
   conform with the voucherstatus-post CDDL [RFC8610] data model defined
   in Section 5.7 of [RFC8995]:

   *  version: contains a version number for the format and semantics of
      the other fields; this specification assumes version 1 just like
      BRSKI [RFC8995].

   *  status: contains the boolean value true in case of success and
      false in case of failure.

   *  reason: contains a human-readable message; should not provide
      information beneficial to an attacker.  As the pledge is not
      localized at this point in time language selection cannot be done.
      Therefore, English is taken as a default here for this diagnostic
      messages.  The internationalization of text is expected to be done
      on another level.

   *  reason-context: contains a JSON object that provides additional
      information specific to a failure; in contrast to Section 5.7 of
      [RFC8995], MUST be provided;

   BRSKI-PRM implementations utilize the reason-context field to provide
   a distinguishable token, which enables the registrar to detect status
   artifacts provided to the wrong endpoint.  For vStatus artifacts, the
   JSON object in the reason-context field MUST contain the member pvs-
   details.

   Figure 32 shows an example for the JSON Voucher Status Data in case
   of success and Figure 33 in case of failure:

   HTTP/1.1 200 OK
   Content-Type: application/jose+json
   Content-Language: en

   {
     "version": 1,
     "status": true,
     "reason": "Voucher successfully processed.",
     "reason-context": {
       "pvs-details": "Current date 5/23/2024"
     }
   }

            Figure 32: JSON Voucher Status Data Success Example




Fries, et al.            Expires 5 December 2025               [Page 64]

Internet-Draft                  BRSKI-PRM                      June 2025


   HTTP/1.1 400 Bad Request
   Content-Type: application/jose+json
   Content-Language: en

   {
     "version": 1,
     "status": false,
     "reason": "Failed to authenticate MASA certificate.",
     "reason-context": {
       "pvs-details": "Current date 1/1/1970 < valid from 1/1/2023"
     }
   }

            Figure 33: JSON Voucher Status Data Failure Example

7.6.2.2.  JWS Protected Header

   The JWS Protected Header of the vStatus artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

   *  x5c: SHALL contain the base64-encoded pledge IDevID certificate
      used to sign the vStatus artifact and it SHOULD also contain the
      certificate chain for this certificate.  The certificate chain
      MUST be available for certificate verification.  If it is not
      contained in the x5c Header Parameter it is provided to the
      relying party by other means such as configuration.

   Figure 34 shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }

           Figure 34: JWS Protected Header Example within vStatus










Fries, et al.            Expires 5 December 2025               [Page 65]

Internet-Draft                  BRSKI-PRM                      June 2025


7.6.2.3.  JWS Signature

   The pledge MUST sign the vStatus artifact using its IDevID
   credential.  The JWS Signature is generated over the JWS Protected
   Header and the JWS Payload as described in Section 5.1 of [RFC7515].
   Algorithms used for JWS signatures MUST support ES256 as recommended
   in [RFC7518] and MAY support further algorithms.

7.7.  Supply CA Certificates to Pledge (scac)

   Before supplying the pledge EE certificate, the Registrar-Agent
   supplies the domain CA certificates to the pledge, so the pledge can
   verify its EE certificate in the next exchange.  As the CA
   certificate provisioning is crucial from a security perspective, this
   exchange SHOULD only be done if supplying the voucher in the previous
   exchange (Section 7.6) has been successfully processed by the pledge
   as reflected in the vStatus artifact.

   TLS MAY be used to provide privacy for this exchange between the
   Registrar-Agent and the pledge (see Appendix B).

   Figure 35 shows the provisioning of the CA certificates to the pledge
   and the following subsections describe the corresponding artifacts.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (7) Supply CA Certificates to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----caCerts-----|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

              Figure 35: Certificate provisioning exchange

   The Registrar-Agent SHALL provide the bag of CA certificates
   requested from and signed by the registrar to the pledge by HTTP(S)
   POST to the pledge endpoint at /.well-known/brski/scac.  The request
   body MUST contain the caCerts artifact as defined in Section 7.5.2.
   In the request header, the Content-Type field MUST be set to
   application/jose+json.





Fries, et al.            Expires 5 December 2025               [Page 66]

Internet-Draft                  BRSKI-PRM                      June 2025


   Upon receiving valid caCerts artifact, the pledge MUST first verify
   the signature of the registrar using the initial trust anchor (pinned
   domain certificate).  In the case of success, the pledge MUST install
   the contained CA certificates as trust anchors as described in
   Section 4.1.3 of [RFC7030].  This includes the verification of all
   intermediate CA certificates (i.e., not self-signed CA certificates).

   If the pledge is unable to process the caCerts, it responds with an
   HTTP error status code to the Registrar-Agent.  The following client
   error status codes can be used:

   *  400 Bad Request: if the pledge detects an error in the format of
      the request.

   *  403 Forbidden: if the signature of the registrar cannot be
      verified against the installed initial trust anchor (pinned domain
      certificate).

   *  403 Forbidden: if one of the intermediate CA certificates cannot
      be verified against the available trust anchors (e.g., self-signed
      CA certificates).

   *  415 Unsupported Media Type: if the Content-Type request header
      field indicates a type that is unknown or unsupported, e.g., a
      type other than application/jose+json.

   Otherwise, if processing completes successfully, the pledge SHOULD
   reply with HTTP 200 OK without a response body.  The pledge MAY use
   the response body to signal success/failure details to the service
   technician operating the Registrar-Agent.

7.7.1.  Request Artifact: CA-Certificates (caCerts)

   Identical to the CA-Certificates (caCerts) artifact received from the
   registrar as defined in Section 7.5.2.  The Registrar-Agent MUST NOT
   modify CA-Certificates artifacts.

7.7.2.  Response (no artifact)

   In this exchange, the response is a result of the HTTP(S) default
   transport for this specification.  There is no artifact provided to
   the Registrar-Agent.  The pledge MAY use the response body to signal
   success/failure details to the service technician operating the
   Registrar-Agent.  While BRSKI-PRM does not specify which content may
   be provided in the response body, it is recommended to provided it as
   JSON encoded information as other BRSKI-PRM exchanges also utilize
   this encoding.




Fries, et al.            Expires 5 December 2025               [Page 67]

Internet-Draft                  BRSKI-PRM                      June 2025


7.8.  Supply Enroll-Response to Pledge (ser)

   After supplying the CA certificates, the Registrar-Agent supplies the
   pledge EE certificate to the pledge.

   TLS MAY be used to provide privacy for this exchange between the
   Registrar-Agent and the pledge (see Appendix B).

   Figure 36 shows the provisioning of the domain-owner signed EE
   certificate to the pledge and the following subsections describe the
   corresponding artifacts.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (8) Supply Enroll-Response to Pledge
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<---Enroll-Resp---|                 |                 |            |
  |-----eStatus----->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                  Figure 36: Enroll-Response exchange

   The Registrar-Agent SHALL send the domain-owner signed EE certificate
   to the pledge by HTTP(S) POST to the pledge endpoint at /.well-
   known/brski/ser.  The request body MUST contain the Enroll-Response
   (Enroll-Resp) artifact previously acquired from the domain registrar
   as defined in Section 7.4.2.  In the request header, the Content-Type
   field MUST be set to application/pkcs7-mime with an smime-type
   parameter certs-only, as specified in [RFC7030] and [RFC5273], and
   the Accept field SHOULD be set to application/jose+json.

   Upon reception, the pledge SHALL verify the received EE certificate
   using the installed trust anchors.  After Enroll-Resp validation and
   verification, the pledge needs to reply with a status telemetry
   message as defined in Section 5.9.4 of [RFC8995].  The pledge MUST
   generate the Enroll Status (eStatus) artifact as defined in
   Section 7.8.2 and MUST provide it to the Registrar-Agent in the body
   of an HTTP 200 OK response.  In the response header, the Content-Type
   field MUST be set to application/jose+json.





Fries, et al.            Expires 5 December 2025               [Page 68]

Internet-Draft                  BRSKI-PRM                      June 2025


   If the pledge is unable to validate or verify the Enroll-Response, it
   MUST report the reason in the corresponding field of the Enroll
   Status.

7.8.1.  Request Artifact: Enroll-Response (Enroll-Resp)

   Identical to the Enroll-Response (Enroll-Resp) artifact received from
   the registrar as defined in Section 7.4.2.  The Registrar-Agent MUST
   NOT modify Enroll-Response artifacts.

7.8.2.  Response Artifact: Enroll Status (eStatus)

   The Enroll Status (eStatus) artifact SHALL be an authenticated self-
   contained object signed by the pledge, containing status telemetry as
   defined in Section 5.9.4 of [RFC8995].

   For the JWS-signed JSON format used by this specification, the
   eStatus artifact MUST use the "General JWS JSON Serialization Syntax"
   defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
   Enroll Status Data defined in Section 7.8.2.1 in the JWS Payload.
   Figure 37 summarizes the serialization of the JWS-signed JSON eStatus
   artifact:

   {
     "payload": BASE64URL(UTF8(JSON Enroll Status Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

           Figure 37: eStatus Representation in General JWS JSON
                            Serialization Syntax

   The JSON Enroll Status Data MUST be UTF-8 encoded to become the
   octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
   further base64url-encoded to become the string value of the payload
   member as described in Section 3.2 of [RFC7515].  The octets of the
   UTF-8 representation of the JWS Protected Header are base64url-
   encoded to become the string value of the protected member.  The
   generated JWS Signature is base64url-encoded to become the string
   value of the signature member.







Fries, et al.            Expires 5 December 2025               [Page 69]

Internet-Draft                  BRSKI-PRM                      June 2025


7.8.2.1.  JSON Enroll Status Data

   The JSON Status Data SHALL be a JSON document [RFC8259] that MUST
   conform with the enrollstatus-post CDDL [RFC8610] data model defined
   in Section 5.9.4 of [RFC8995].  The members are the same as for the
   JSON Voucher Status Data and follow the same definitions as given in
   Section 7.6.2.1 (including making reason-context mandatory).

   BRSKI-PRM implementations again utilize the reason-context field to
   provide a distinguishable token.  For eStatus artifacts, the JSON
   object in the reason-context field MUST contain the member pes-
   details.

   Figure 38 below shows an example for the JSON Enroll Status Data in
   case of success and Figure 39 in case of failure:

   {
     "version": 1,
     "status": true,
     "reason": "Enroll-Response successfully processed.",
     "reason-context": {
       "pes-details": "Successfully enrolled"
     }
   }

             Figure 38: JSON Enroll Status Data Success Example

   {
     "version": 1,
     "status": false,
     "reason": "Enroll-Response could not be verified.",
     "reason-context": {
       "pes-details": "No matching trust anchor"
     }
   }

             Figure 39: JSON Enroll Status Data Failure Example

7.8.2.2.  JWS Protected Header

   The JWS Protected Header of the eStatus artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]






Fries, et al.            Expires 5 December 2025               [Page 70]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  x5c: SHALL contain the base64-encoded pledge EE certificate used
      to sign the eStatus artifact and it SHOULD also contain the
      certificate chain for this certificate.  The certificate chain
      MUST be available for certificate verification.  If it is not
      contained in the x5c Header Parameter it is provided to the
      relying party by other means such as configuration.

   Figure 40 below shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }

           Figure 40: JWS Protected Header Example within eStatus

7.8.2.3.  JWS Signature

   If the pledge verified the received EE certificate successfully, it
   MUST sign the eStatus artifact using its new EE credentials.  In
   failure case, the pledge MUST sign it using its IDevID credentials.
   The JWS Signature is generated over the JWS Protected Header and the
   JWS Payload as described in Section 5.1 of [RFC7515].  Algorithms
   used for JWS signatures MUST support ES256 as recommended in
   [RFC7518] and MAY support further algorithms.

7.9.  Voucher Status Telemetry (including MASA interaction)

   Once the Registrar-Agent has collected both status artifacts from one
   or more pledges, it SHALL provide the status information to the
   domain registrar for further processing, beginning with the voucher
   status telemetry.

   In case the TLS session to the registrar is closed, the Registrar-
   Agent establishes a new session as described in Section 7.3.

   Figure 41 shows the provisioning of the voucher status information
   from the pledge(s) to the registrar and the following subsections
   describe the corresponding artifact and MASA interaction.









Fries, et al.            Expires 5 December 2025               [Page 71]

Internet-Draft                  BRSKI-PRM                      June 2025


 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (9) Voucher Status Telemetry (including backend interaction)
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<---((mTLS))---->|                 |            |
  |                  |-----vStatus---->|                 |            |
  |                  |                 |<----------((mTLS))---------->|
  |                  |                 |-----req device audit-log---->|
  |                  |                 |<------device audit-log-------|
  |                  |                 |                 |            |
  |                  |        [verify audit-log]         |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

              Figure 41: Voucher Status telemetry exchange

   First, the Registrar-Agent SHALL supply the voucher status telemetry
   to the registrar via HTTP-over-TLS POST to the registrar endpoint at
   /.well-known/brski/voucher_status.  The request body MUST contain one
   previously acquired vStatus artifact as defined in Section 7.6.2.  In
   the request header, the Content-Type field MUST be set to
   application/jose+json.

   Upon receiving a vStatus artifact, the registrar MUST process it as
   described in Section 5.7 of [RFC8995].  Due to the Registrar-Agent in
   the middle, the registrar MUST in addition verify the signature of
   the vStatus and that it belongs to an accepted device of the domain
   based on the serial-number field of the IDevID certificate contained
   in the JWS Protected Header of the vStatus.

   According to Section 5.7 of [RFC8995], the registrar responds with an
   HTTP 200 OK without a response body in the success case or fail with
   an HTTP error status code.  The registrar MAY use the response body
   to signal success/failure details to the service technician operating
   the Registrar-Agent.

   The registrar SHOULD proceed with the audit-log request to the MASA
   as in BRSKI described in Section 5.8 of [RFC8995].








Fries, et al.            Expires 5 December 2025               [Page 72]

Internet-Draft                  BRSKI-PRM                      June 2025


7.9.1.  Request Artifact: Voucher Status (vStatus)

   Identical to the Voucher Status (vStatus) artifact received from the
   pledge as defined in Section 7.6.2.  The Registrar-Agent MUST NOT
   modify vStatus artifacts.

7.9.2.  Response (no artifact)

   In this exchange, the response is a result of the HTTP(S) default
   transport for this specification.  There is no artifact provided to
   the Registrar-Agent.

7.10.  Enroll Status Telemetry

   The Registrar-Agent SHALL complete the sequence of exchanges for
   bootstrapping with providing the enroll status telemetry to the
   domain registrar.  This status indicates whether the pledge could
   process the Enroll-Response (pledge EE certificate signed by the
   domain owner) and holds the corresponding private key.

   In case the TLS session to the registrar is already closed, the
   Registrar-Agent establishes a new session as described in
   Section 7.3.

   Figure 42 shows the provisioning of the enroll status information
   from the pledge(s) to the registrar and the following subsections
   describe the corresponding artifact.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (10) Enroll Status Telemetry
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |                  |<---((mTLS))---->|                 |            |
  |                  |-----eStatus---->|                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

              Figure 42: Enroll Status telemetry exchange








Fries, et al.            Expires 5 December 2025               [Page 73]

Internet-Draft                  BRSKI-PRM                      June 2025


   The Registrar-Agent SHALL supply the enroll status telemetry to the
   registrar via HTTP-over-TLS POST to the registrar endpoint at /.well-
   known/brski/enrollstatus.  The request body MUST contain one
   previously acquired eStatus artifact as defined in Section 7.8.2.  In
   the request header, the Content-Type field MUST be set to
   application/jose+json.

   Upon receiving an eStatus artifact, the registrar MUST process it as
   described in Section 5.9.4 of [RFC8995].  Due to the Registrar-Agent
   in the middle, instead of the BRSKI TLS session with the pledge, the
   registrar MUST verify the signature of the eStatus artifact and that
   it belongs to an accepted device of the domain based on the serial-
   number field of the EE certificate contained in the JWS Protected
   Header of the eStatus.  Note that if the Enroll Status indicates
   success, the eStatus artifact is signed with the new pledge EE
   credentials; if it indicates failure, the pledge was unable to
   process the supplied EE certificate and therefore signed with its
   IDevID credentials.

   According to Section 5.9.4 of [RFC8995], the registrar responds with
   an HTTP 200 OK in the success case or can fail with an HTTP 404
   client error status code.  The registrar MAY use the response body to
   signal success/failure details to the service technician operating
   the Registrar-Agent.

   If the eStatus indicates failure, the registrar MAY decide that for
   security reasons the pledge is not allowed to reside in the domain.
   In this case, the registrar MUST revoke the pledge EE certificate.
   An example case for the registrar revoking the issued certificate is
   when the pledge was not able to verify the received EE certificate
   and therefore did not accept it for installation.

7.10.1.  Request Artifact: Enroll Status (eStatus)

   Identical to the Enroll Status (eStatus) artifact received from the
   pledge as defined in Section 7.8.2.  The Registrar-Agent MUST NOT
   modify eStatus artifacts.

7.10.2.  Response (no artifact)

   In this exchange, the response is a result of the HTTP(S) default
   transport for this specification.  There is no artifact provided to
   the Registrar-Agent.








Fries, et al.            Expires 5 December 2025               [Page 74]

Internet-Draft                  BRSKI-PRM                      June 2025


7.11.  Query Pledge Status (qps)

   The following assumes that a Registrar-Agent may need to query the
   overall status of a pledge.  This information can be useful to solve
   errors, when the pledge was not able to connect to the target domain
   during bootstrapping.  A pledge MAY omit the dedicated endpoint for
   the Query Pledge Status operation (see Section 6.2).

   TLS MAY be used to provide privacy for this exchange between the
   Registrar-Agent and the pledge (see Appendix B).

   Figure 43 shows the query and response for the overall pledge status
   and the following subsections describe the corresponding artifacts.

 +--------+    +------------+    +-----------+    +--------+    +------+
 | Pledge |    | Registrar- |    |  Domain   |    |  Key   |    | MASA |
 |        |    |   Agent    |    | Registrar |    | Infra. |    |      |
 +--------+    +------------+    +-----------+    +--------+    +------+
  |                  |                 |                 |   Internet |
  ~                  ~                 ~                 ~            ~
 (11) Query Pledge Status
  ~                  ~                 ~                 ~            ~
  |                  |                 |                 |            |
  |<----opt. TLS---->|                 |                 |            |
  |<-----tStatus-----|                 |                 |            |
  |------pStatus---->|                 |                 |            |
  |                  |                 |                 |            |
  ~                  ~                 ~                 ~            ~

                   Figure 43: Pledge Status exchange

   The Registrar-Agent SHALL query the pledge via HTTP(S) POST to the
   pledge endpoint at /.well-known/brski/qps.  The request body MUST
   contain the Status Trigger (tStatus) artifact as defined in
   Section 7.11.1.  In the request header, the Content-Type field MUST
   be set to application/jose+json and the Accept field SHOULD be set to
   application/jose+json.

   If the pledge implements the Query Pledge Status endpoint, it MUST
   first verify the signature of the tStatus artifact using its trust
   anchors.  If the pledge does not possess any domain trust anchor yet,
   it MAY skip the signature verification and choose to reply without
   it.  In the case of success, it MUST reply with the Pledge Status
   (pStatus) artifact as defined in Section 7.11.2 in the body of an
   HTTP 200 OK response.  In the response header, the Content-Type field
   MUST be set to application/jose+json.





Fries, et al.            Expires 5 December 2025               [Page 75]

Internet-Draft                  BRSKI-PRM                      June 2025


   If the pledge is unable to create the pStatus artifact, the pledge
   responds with an HTTP error status code to the Registrar-Agent.  The
   following client error status codes can be used:

   *  400 Bad Request: if the pledge detects an error in the format of
      the request.

   *  403 Forbidden: if the signature of the Registrar-Agent cannot be
      verified using the installed trust anchors.

   *  406 Not Acceptable: if the Accept request header field indicates a
      type that is unknown or unsupported, e.g., a type other than
      application/jose+json.

   *  415 Unsupported Media Type: if the Content-Type request header
      field indicates a type that is unknown or unsupported, e.g., a
      type other than application/jose+json.

   The pledge MAY use the response body to signal failure details to the
   service technician operating the Registrar-Agent.

7.11.1.  Request Artifact: Status Trigger (tStatus)

   The Status Query (tStatus) artifact SHALL be an authenticated self-
   contained object signed by the pledge, providing status query
   parameters.

   For the JWS-signed JSON format used by this specification, the
   tStatus artifact MUST use the "General JWS JSON Serialization Syntax"
   defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
   Status Trigger Data defined in Section 7.11.1.1 in the JWS Payload.
   Figure 44 summarizes the serialization of the JWS-signed JSON PER
   artifact:

   {
     "payload": BASE64URL(UTF8(JSON Status Trigger Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

           Figure 44: tStatus Representation in General JWS JSON
                            Serialization Syntax





Fries, et al.            Expires 5 December 2025               [Page 76]

Internet-Draft                  BRSKI-PRM                      June 2025


   The JSON Status Trigger Data MUST be UTF-8 encoded to become the
   octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
   further base64url-encoded to become the string value of the payload
   member as described in Section 3.2 of [RFC7515].  The octets of the
   UTF-8 representation of the JWS Protected Header are base64url-
   encoded to become the string value of the protected member.  The
   generated JWS Signature is base64url-encoded to become the string
   value of the signature member.

7.11.1.1.  JSON Status Trigger Data

   The JSON Status Trigger Data SHALL be a JSON document [RFC8259] that
   MUST conform with the CDDL [RFC8610] data model defined in Figure 45:

     statustrigger = {
         "version": uint,
         "serial-number": text,
         "created-on": tdate,
         "status-type": $status-type
     }

     $status-type /= "bootstrap"
     $status-type /= "operation"

        Figure 45: CDDL for JSON Status Trigger Data (statustrigger)

   The version member is included to permit significant changes to the
   pledge status artifacts in the future.  The format and semantics in
   this document follow the status telemetry definitions of [RFC8995].
   Hence, the version SHALL be set to 1.  A pledge (or Registrar-Agent)
   that receives a version larger than it knows about SHOULD log the
   contents and emit an operational notification.

   The serial-number member SHALL contain the product-serial-number
   corresponding to the X520SerialNumber field of the pledge IDevID
   certificate; it can be correlated with the product-serial-number in
   the signing certificate contained in the JWS Protected Header of the
   Pledge Status response artifact.

   The created-on member SHALL contain the current date and time at
   tStatus creation as standard date/time string as defined in
   Section 5.6 of [RFC3339]; it can be used as reference time for the
   corresponding Pledge Status response artifact after correlating via
   the product-serial-number; note that pledges may not have
   synchronized time to provide the created-on date and time on their
   own.





Fries, et al.            Expires 5 December 2025               [Page 77]

Internet-Draft                  BRSKI-PRM                      June 2025


   The status-type allows for specifying which status information is to
   be returned.  As shown in Figure 45, BRSKI-PRM defines two
   enumeration values:

   *  bootstrap to query current status information regarding the
      bootstrapping status (e.g., voucher processing and enrollment of
      the pledge into a domain).

   *  operation to query current status information regarding the
      operational status (e.g., utilization of the bootstrapped EE
      credentials in communication with other peers).

   Other specifications using this artifact may define further
   enumeration values, e.g., to query application-related status.

   Figure 46 shows an example for the JSON Status Trigger Data using the
   status type bootstrap:

   {
     "version": 1,
     "created-on": "2025-01-12T02:37:39.235Z",
     "serial-number": "vendor-pledge4711",
     "status-type": "bootstrap"
   }

                Figure 46: JSON Status Trigger Data Example

7.11.1.2.  JWS Protected Header

   The JWS Protected Header of the tStatus artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515]

   *  x5c: SHALL contain the base64-encoded Registrar-Agent EE
      certificate used to sign the tStatus artifact as well as the
      certificate chain

   Figure 47 shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }



Fries, et al.            Expires 5 December 2025               [Page 78]

Internet-Draft                  BRSKI-PRM                      June 2025


           Figure 47: JWS Protected Header Example within tStatus

7.11.1.3.  JWS Signature

   The Registrar-Agent MUST sign the tStatus artifact using its EE
   credentials.  The JWS Signature is generated over the JWS Protected
   Header and the JWS Payload as described in Section 5.1 of [RFC7515].
   Algorithms used for JWS signatures MUST support ES256 as recommended
   in [RFC7518] and MAY support further algorithms.

7.11.2.  Response Artifact: Pledge Status (pStatus)

   The Pledge Status (pStatus) artifact SHALL be an authenticated self-
   contained object signed by the pledge, containing status telemetry
   information.  The exact content depends on the Status Trigger
   parameter status-type.

   For the JWS-signed JSON format used by this specification, the
   pStatus artifact MUST use the "General JWS JSON Serialization Syntax"
   defined in Section 7.2.1 of [RFC7515], which MUST contain the JSON
   Pledge Status Data defined in Section 7.11.2.1 in the JWS Payload.
   Figure 48 summarizes the serialization of the JWS-signed JSON PER
   artifact:

   {
     "payload": BASE64URL(UTF8(JSON Pledge Status Data)),
     "signatures": [
       {
         "protected": BASE64URL(UTF8(JWS Protected Header)),
         "signature": BASE64URL(JWS Signature)
       }
     ]
   }

           Figure 48: pStatus Representation in General JWS JSON
                            Serialization Syntax

   The JSON Pledge Status Data MUST be UTF-8 encoded to become the
   octet-based JWS Payload defined in [RFC7515].  The JWS Payload is
   further base64url-encoded to become the string value of the payload
   member as described in Section 3.2 of [RFC7515].  The octets of the
   UTF-8 representation of the JWS Protected Header are base64url-
   encoded to become the string value of the protected member.  The
   generated JWS Signature is base64url-encoded to become the string
   value of the signature member.






Fries, et al.            Expires 5 December 2025               [Page 79]

Internet-Draft                  BRSKI-PRM                      June 2025


7.11.2.1.  JSON Pledge Status Data

   The JSON Pledge Status Data SHALL be a JSON document [RFC8259] that
   MUST conform with the CDDL [RFC8610] data model defined in Figure 49,
   which has the same members as the voucherstatus-post CDDL defined in
   Section 5.7 of [RFC8995] and the enrollstatus-post CDDL defined in
   Section 5.9.4 of [RFC8995].

     pledgestatus = {
       "version": uint,
       "status": bool,
       ?"reason" : text,
       "reason-context": { * $$arbitrary-map }
     }

         Figure 49: CDDL for JSON Pledge Status Data (pledgestatus)

   The version member follows the definition in Section 7.11.1.1 (same
   as in JSON Status Query Data).

   The reason and reason-context members follow the definitions in
   Section 7.6.2.1, i.e., in contrast to [RFC8995], reason-context MUST
   be provided.

   The new pStatus artifact also utilizes the reason-context field to
   provide a distinguishable token.  For pStatus artifacts, the JSON
   object in the reason-context field MUST contain either the

   *  pbs-details member for status information corresponding to the
      status-type bootstrap, or the

   *  pos-details member for status information corresponding to the
      status-type operation (see Section 7.11.1.1)

   Other documents may add additional reason-context members correlating
   to other statustrigger status-types or to include further status
   information.

   For the pbs-details member, the following values with the given
   semantics are defined, while additional information MAY be provided
   in the top-level reason member:

   *  factory-default: Pledge has not been bootstrapped.  The pledge
      signs the response message using its IDevID certificate/
      credentials.






Fries, et al.            Expires 5 December 2025               [Page 80]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  voucher-success: Pledge processed the voucher exchange
      successfully.  The pledge signs the response message using its
      IDevID certificate/credentials.

   *  voucher-error: Pledge voucher processing terminated with error.
      Additional information may be provided in the reason or reason-
      context members.  The pledge signs the response message using its
      IDevID certificate/credentials.

   *  enroll-success: Pledge processed the enrollment exchange
      successfully.  Additional information may be provided in the
      reason or reason-context members.  The pledge signs the response
      message using its domain-owner signed EE certificate/credentials.

   *  enroll-error: Pledge enrollment-response processing terminated
      with error.  Additional information may be provided in the reason
      or reason-context members.  The pledge signs the response message
      using its IDevID certificate/credentials.

   The pbs-details values SHALL be cumulative in the sense that enroll-
   success and enroll-error imply voucher-success.  Figure 50 below
   provides an example for bootstrap status information in the JSON
   Pledge Status Data:

   {
     "version": 1,
     "status": true,
     "reason": "Pledge processed enrollment exchange successfully.",
     "reason-context": {
       "pbs-details": "enroll-success"
     }
   }

        Figure 50: status-bootstrap JSON Pledge Status Data Example

   For the pos-details member, the following values with the given
   semantics are defined, while additional information MAY be provided
   in the top-level reason member:

   *  connect-success: Pledge could successfully establish a connection
      to another peer.  The pledge signs the response message using its
      domain-owner signed EE certificate/credentials.

   *  connect-error: Pledge connection establishment terminated with
      error.  The pledge signs the response message using its domain-
      owner signed EE certificate/credentials.





Fries, et al.            Expires 5 December 2025               [Page 81]

Internet-Draft                  BRSKI-PRM                      June 2025


   Figure 51 provides an example for operational status information in
   the JSON Pledge Status Data:

   {
     "version": 1,
     "status": false,
     "reason": "TLS certificate could not be verified.",
     "reason-context": {
       "pos-details" : "connect-error"
     }
   }

        Figure 51: status-operation JSON Pledge Status Data Example

7.11.2.2.  JWS Protected Header

   The JWS Protected Header of the pStatus artifact MUST contain the
   following standard Header Parameters as defined in [RFC7515]:

   *  alg: SHALL contain the algorithm type used to create the
      signature, e.g., ES256, as defined in Section 4.1.1 of [RFC7515].

   *  x5c: SHALL contain the base64-encoded pledge EE certificate used
      to sign the pStatus artifact and it SHOULD also contain the
      certificate chain for this certificate The certificate chain MUST
      be available for certificate verification.  If it is not contained
      in the x5c Header Parameter it is provided to the relying party by
      other means such as configuration.

   Figure 52 shows an example for this JWS Protected Header:

   {
     "alg": "ES256",
     "x5c": [
       "base64encodedvalue==",
       "base64encodedvalue=="
     ]
   }

           Figure 52: JWS Protected Header Example within pStatus











Fries, et al.            Expires 5 December 2025               [Page 82]

Internet-Draft                  BRSKI-PRM                      June 2025


7.11.2.3.  JWS Signature

   The pledge MUST sign the tStatus artifact using its IDevID or domain-
   owner signed EE credentials according to its bootstrapping status as
   defined in Section 7.11.2.1.  The JWS Signature is generated over the
   JWS Protected Header and the JWS Payload as described in Section 5.1
   of [RFC7515].  Algorithms used for JWS signatures MUST support ES256
   as recommended in [RFC7518] and MAY support further algorithms.

8.  Logging Considerations

   The registrar SHOULD log certain events to provide an audit trail for
   the onboarding of pledges into its domain.  This audit trail may
   support the root cause analysis in case of device or system failures.
   Recommend key events for logging comprise:

   *  Communication attempts between the pledge, Registrar-Agent, and
      registrar.

   *  Protocol handshakes and onboarding steps.

   *  Voucher requests and responses.

   *  Authentication successes or failures.

   The logging SHOULD include the identity of the pledge, the identity
   of the Registrar-Agent that was interacting with the pledge, and
   relevant artifact fields, in particular telemetry information:

   *  PVR received from Registrar-Agent

   *  Acceptance of a pledge into the domain

   *  Voucher provided to Registrar-Agent

   *  PER received from Registrar-Agent

   *  Pledge EE certificate requested

   *  Pledge EE certificate received from Domain CA

   *  Pledge EE certificate provided to Registrar-Agent

   *  CA Certificates provided to Registrar-Agent

   *  Voucher Status received from Registrar-Agent

   *  Enroll Status received from Registrar-Agent



Fries, et al.            Expires 5 December 2025               [Page 83]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Pledge Status received from Registrar-Agent

   *  Pledge EE certificate revoked

   Furthermore, it is recommended to:

   *  support adjustable logging levels (severity) to cater to different
      operational needs or failure situations.

   *  include meta information to distinguish logs that relate to
      different BRSKI approaches (e.g., BRSKI, BRSKI-AE, BRSKI-PRM,
      constraint BRSKI) that are likely supported in the same domain in
      parallel.

   *  include detailed error codes and diagnostics information as
      defined throughout the document or stemming from other used
      components or libraries also in the logging information.

   *  support synchronized time (e.g., via NTP) to include timestamps in
      logging to enable sequencing and correlation of events.

   *  utilize standard logging formats (e.g., syslog) to allow for easy
      integration into log analysis tools and SIEM systems.

   *  utilize secure transmission of logs to centralized log servers,
      particularly in cloud or distributed environments (e.g., in case
      of syslog, [RFC9662] updates the utilized cipher suites for TLS
      and DTLS).

   *  allow for definition of key operational thresholds (e.g., high
      latency, failed onboarding attempts) to trigger alerts for
      proactive issue resolution.

   *  avoid inclusion of sensitive information (see also Section 11)

   For log analysis the following may be considered:

   *  The registrar knows which Registrar-Agent collected which PVR from
      the included agent-signed-data object.

   *  The registrar always knows the connecting Registrar-Agent from the
      TLS client authentication using the Registrar-Agent EE certificate
      and can log it accordingly.








Fries, et al.            Expires 5 December 2025               [Page 84]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  The telemetry information from the pledge can be correlated to the
      voucher through the product-serial-number in the EE certificate
      contained in the JWS Protected Header of the status artifacts and
      the product-serial-number contained in the voucher.  By this it
      can also be related to the PER.

   With this, it can for instance be analyzed if multiple Registrar-
   Agents are involved in bootstrapping devices.  In addition, within
   the domain it can be analyzed, if the onboarding involved different
   Registrar-Agents or if different registrars have been used.

   In order to protect the registrar from overload attacks, a rate-
   limiting may be used by logging events from the same type just once.

9.  Operational Considerations

   As outlined in Section 5, BRSKI-PRM introduces an additional
   component with the Registrar-Agent in the BRSKI architecture in
   addition to new modes of interaction to facilitate the communication
   between the pledge and the registrar.  As outlined in Section 5.3 the
   functional support of BRSKI-PRM can also be achieved using a
   Registrar-Agent co-located with the Registrar instead of a stand-
   alone Registrar-Agent, which may reduce operational complexity.

   This has an influence on the configuration and operation not only of
   the Registrar-Agent, but also for the registrar and the pledge.

   As outlined in Section 6, there are additional configuration items
   dues to the introduction of the Registrar-Agent.  This may increase
   operational complexity and potential misconfigurations in deploying
   and managing this entity:

   *  A Registrar-Agent needs to be provided with a Registrar-Agent EE
      certificate, the domain registrar EE certificate and the list of
      pledges.  BRSKI-PRM is open regarding the selected provisioning
      method, which may be automated or by configuration.

   *  Pledges may support either BRSKI-PRM only or combined with other
      modes of operation.

   *  Registrars may support either BRSKI-PRM only or combined with
      other BRSKI modes of operation.  The distinction of BRSKI and
      BRSKI-PRM is done based on the provided endpoints of the
      registrar.  An operator deploying pledges with a mixed set of
      operation need to ensure that the domain registrar supports all
      necessary options to ensure bootstrapping of pledges depending of
      the supported operational mode.




Fries, et al.            Expires 5 December 2025               [Page 85]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  In addition, registrars may support a co-located Registrar-Agent,
      if nomadic operation of the Registrar-Agent is not required.  This
      facilitates situations in which an operator wants to deploy BRSKI
      pledges acting as clients and BSKI pledges acting as servers.

   With the Registrar-Agent enhancement a new component is introduced in
   the communication path between the pledge and the registrar.  This
   likely increases the latency of the communication between the pledge
   and the registrar.  The increase in latency due to this additional
   component may be neglected given that the Registrar-Agent operates
   with nomadic connectivity as outlined in Section 5.2.

   BRSKI-PRM requires pledges to possess an IDevID to enable onboarding
   in new domains.  IDevID (and corresponding trust anchors) are
   expected to have a rather long lifetime.  This may allow for a longer
   period between device acquisition and initial onboarding.  Contrary,
   if devices that have been provided with an LDevID (and corresponding
   trust anchors) and temporarily taken out of service, immediate
   connectivity when bringing them back to operation may not be given,
   as the LDevIDs typically have a much shorter validity period compared
   to IDevIDs.  It is therefore recommended to onboard them as new
   devices to ensure they possess valid LDevIDs.

   The key infrastructure as part of the customer domain discussed in
   Section 5 may be operated locally by the operator of that domain or
   may be provided as a third party service.

   Requirements to the utilized credentials authenticating and artifact
   signatures on the registrar as outlined in Section 6.3 may have
   operational implications when the registrar is part of a scalable
   framework as described in Section 1.3.1 of
   [I-D.richardson-anima-registrar-considerations].

   Besides the above, also consider the existing document on operational
   modes for BRSKI MASA in [I-D.richardson-anima-masa-considerations].

10.  IANA Considerations

   This document requires the following IANA actions.

10.1.  BRSKI Well-Known URIs

   IANA is requested to enhance the Registry entitled: "BRSKI Well-Known
   URIs" with the following endpoints:







Fries, et al.            Expires 5 December 2025               [Page 86]

Internet-Draft                  BRSKI-PRM                      June 2025


     +================+==================================+===========+
     | Path Segment   | Description                      | Reference |
     +================+==================================+===========+
     | requestenroll  | Supply PER to registrar          | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | wrappedcacerts | Obtain wrapped CA certificates   | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | tpvr           | Trigger Pledge Voucher-Request   | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | tper           | Trigger Pledge Enroll-Request    | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | svr            | Supply voucher to pledge         | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | scac           | Supply CA certificates to pledge | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | ser            | Supply Enroll-Response to pledge | [THISRFC] |
     +----------------+----------------------------------+-----------+
     | qps            | Query pledge status              | [THISRFC] |
     +----------------+----------------------------------+-----------+

                  Table 5: BRSKI Well-Known URIs Additions

10.2.  Service Name and Transport Protocol Port Number Registry

   IANA is requested to register the following service names:

   *Service Name:* brski-pledge
   *Transport Protocol(s):* tcp
   *Assignee:* IESG iesg@ietf.org (mailto:iesg@ietf.org)
   *Contact:* IETF Chair chair@ietf.org (mailto:chair@ietf.org)
   *Description:* The Bootstrapping Remote Secure Key Infrastructure
   Pledge
   *Reference:* [THISRFC]

11.  Privacy Considerations

   The privacy considerations of [RFC8995] also apply for BRSKI-PRM.
   Two architectural changes in this document require some additional
   consideration:

   *  the introduction of the additional component Registrar-Agent

   *  no TLS between Registrar-Agent and pledge

   As logging is recommended to better handle failure situations, it is
   necessary to avoid capturing sensitive or personal data.  Privacy-
   preserving measures in logs SHOULD be applied, such as:




Fries, et al.            Expires 5 December 2025               [Page 87]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Avoid logging personally identifiable information unless
      unavoidable.

   *  Anonymize or pseudonymize data where possible.

11.1.  Registrar-Agent identity Privacy Considerations

   The credentials used by the Registrar-Agent to sign the data for the
   pledge SHOULD NOT contain any personal information about the owner/
   operator of the Registar-Agent.  So for instance, issuing an EE
   certificate to the Registrar-Agent that has a Subject DN saying
   something like "Frank Jones' Commissioning Tablet" would be a
   problem.

   Therefore, it is recommended to use an EE certificate associated with
   the commissioning device instead of an EE certificate associated with
   the service technician operating the device.  This avoids revealing
   potentially included personal information to any eavesdroppers on the
   Registrar-Agent/Pledge communication.  Along the Registrar-Agent/
   Registrar communication path, if TLS 1.2 is used, the client
   certificate details will be revealed to any on path passive attacker.
   This is one of the advantages of using TLS 1.3.

11.2.  Registar-Agent/Pledge communications

   The communication between the pledge and the Registrar-Agent is
   performed over plain HTTP.  HTTPS can not be easily used as the
   Pledge's long-term IDevID certificate does not contain a
   SubjectAltName that [RFC9525] DNS-ID verification can use to validate
   the certificate.  In order for this connection to be more secure, the
   Registrar-Agent would need to know precisely which devices (down to
   the serial number) it expects to onboard.  There are some very
   constrained cases where this might be the case, but for many
   installations, it is not practical.

   An active on-path attacker [onpath] could trivially impersonate the
   Pledge at the network layer, which is exactly the same situation when
   not using TLS.  For many installations, a physical cable may be
   invoved (such as ethernet over USB), or a very low power wireless
   network will be used.  Any active on-path attacker would have to be
   physically present at the site of the device.  Such a physically
   present attacker could learn the identity of the Pledge by simply
   pretending to be a Registrar-Agent, and asking the device for its
   identity.  It could equally do this over TLS/HTTPS.







Fries, et al.            Expires 5 December 2025               [Page 88]

Internet-Draft                  BRSKI-PRM                      June 2025


   It is impossible for an active on-path attacker to replace the signed
   objects that the Pledge and Registrar-Agent exchange undetected
   because those objects are signed by keys contained in the respective
   devices.

   Depending on the requests and responses, the following information is
   disclosed:

   *  the Pledge product-serial-number is contained in the trigger
      message for the PVR and in all responses from the pledge.  This
      information reveals the identity of the devices being bootstrapped
      and allows deduction of which products an operator is using in
      their environment.  As the communication between the pledge and
      the Registrar-Agent may be realized over wireless link, this
      information could easily be eavesdropped, if the wireless network
      is not encrypted.  Even if the wireless network is encrypted, if
      it uses a network-wide key, then layer-2 attacks (ARP/ND spoofing)
      could insert an on-path observer into the path.

   *  the Timestamp data could reveal the activation time of the device.

   *  the Status data of the device could reveal information about the
      current state of the device in the domain network.

   Section 7.1 describes to optionally apply TLS to protect the
   communication between the Registrar-Agent and the pledge.  The
   following is therefore applicable to the communication without the
   TLS protection.

12.  Security Considerations

   In general, the security considerations of [RFC8995] apply for BRSKI-
   PRM also.  Further security aspects are considered in the following
   subsections related to:

   *  the introduction of the additional component Registrar-Agent and
      related attack options.

   *  the reversal of the pledge communication direction (push mode,
      compared to BRSKI).

   *  no usage of TLS between Registrar-Agent and pledge and the
      resulting impact on transport of sensitive information (see
      Section 7.1 regarding optional use of TLS to protect the
      communication between the Registrar-Agent and the pledge)






Fries, et al.            Expires 5 December 2025               [Page 89]

Internet-Draft                  BRSKI-PRM                      June 2025


12.1.  Denial of Service (DoS) Attack on Pledge

   Disrupting the pledge behavior by a DoS attack may prevent the
   bootstrapping of the pledge to a new domain.  Because in BRSKI-PRM
   the pledge responds to requests from real or illicit Registrar-
   Agents, pledges are more subject to DoS-attacks from Registrar-Agents
   in BRSKI-PRM than they are from illicit registrars in [RFC8995],
   where pledges do initiate the connections.

   A DoS attack with a faked Registrar-Agent may block the bootstrapping
   of the pledge due changing state on the pledge (the pledge may
   produce a voucher-request, and refuse to produce another one).  One
   mitigation may be that the pledge does not limit the number of
   voucher-requests it creates until at least one has finished.  An
   alternative may be that the onboarding state may expire after a
   certain time, if no further interaction has happened.

   In addition, the pledge may assume that repeated triggering for PVR
   are the result of a communication error with the Registrar-Agent.  In
   that case the pledge MAY simply resend the PVR previously sent.  Note
   that in case of re-sending, a contained nonce and also the contained
   agent-signed-data in the PVR would consequently be reused.

12.2.  Misuse of acquired PVR and PER by Registrar-Agent

   A Registrar-Agent that uses previously requested PVR and PER for
   domain-A, may attempt to onboard the device into domain-B.  This can
   be detected by the domain registrar while PVR processing.  The domain
   registrar needs to verify that the proximity-registrar-cert field in
   the PVR matches its own registrar EE certificate.  In addition, the
   domain registrar needs to verify the association of the pledge to its
   domain based on the product-serial-number contained in the PVR and in
   the pledge IDevID certificate.  (This is just part of the supply
   chain integration).  Moreover, the domain registrar verifies if the
   Registrar-Agent is authorized to interact with the pledge for
   voucher-requests and enroll-requests, based on the Registrar-Agent EE
   certificate data contained in the PVR.

   Mis-binding of a pledge by a faked domain registrar is countered as
   described in BRSKI security considerations Section 11.4 of [RFC8995].











Fries, et al.            Expires 5 December 2025               [Page 90]

Internet-Draft                  BRSKI-PRM                      June 2025


12.3.  Misuse of Registrar-Agent

   Concerns of misuse of a Registrar-Agent with a valid Registrar-Agent
   EE certificate may be addressed by utilizing short-lived certificates
   (e.g., valid for a day) to authenticate the Registrar-Agent against
   the domain registrar.  The Registrar-Agent EE certificate may have
   been acquired by a prior BRSKI run for the Registrar-Agent, if an
   IDevID is available on Registrar-Agent.  Alternatively, the
   Registrar-Agent EE certificate may be acquired by a service
   technician from the domain PKI system in an authenticated way.

   In addition, it is required that the Registrar-Agent EE certificate
   is valid for the complete bootstrapping phase.  This avoids that a
   Registrar-Agent could be misused to create arbitrary "agent-signed-
   data" objects to perform an authorized bootstrapping of a rogue
   pledge at a later point in time.  In this misuse "agent-signed-data"
   could be dated after the validity time of the Registrar-Agent EE
   certificate, due to missing trusted timestamp in the Registrar-Agents
   signature.  To address this, the registrar SHOULD verify the
   certificate used to create the signature on "agent-signed-data".

   Furthermore, the registrar also verifies the Registrar-Agent EE
   certificate used in the TLS handshake with the Registrar-Agent.  If
   both certificates are verified successfully, the Registrar-Agent's
   signature can be considered as valid.  If the registrar detects a
   mismatch in the utilized certificates, it may conclude the usage of
   either an outdated "agent-signed-data" component in the PVR or a man-
   in-the-middle attack by a potentially unauthorized Registrar-Agent.

12.4.  Misuse of DNS-SD with mDNS to obtain list of pledges

   To discover a specific pledge a Registrar-Agent may query the Service
   Type in combination with the product-serial-number of a specific
   pledge, e.g., in the Service Instance Name or Service Subtype.  The
   pledge reacts on this if its product-serial-number is part of the
   query message.

   If the Registrar-Agent performs DNS-based Service Discovery without a
   specific product-serial-number, all pledges in the domain react if
   the functionality is supported.  This functionality enumerates and
   reveals the information of devices available in the domain.  The
   information about this is provided here as a feature to support the
   commissioning of devices.  A manufacturer may decide to support this
   feature only for devices not possessing an LDevID or to not support
   this feature at all, to avoid an enumeration in an operative domain.






Fries, et al.            Expires 5 December 2025               [Page 91]

Internet-Draft                  BRSKI-PRM                      June 2025


12.5.  YANG Module Security Considerations

   The enhanced voucher-request described in [I-D.ietf-anima-rfc8366bis]
   is based on [RFC8995], but uses a different encoding based on
   [I-D.ietf-anima-jws-voucher].  The security considerations as
   described in Section 11.7 of [RFC8995] (Security Considerations)
   apply.

   The YANG module specified in [I-D.ietf-anima-rfc8366bis] defines the
   schema for data that is subsequently encapsulated by a JOSE signed-
   data Content-type as described in [I-D.ietf-anima-jws-voucher].  As
   such, all of the YANG-modeled data is protected against modification.

   Documents that define exclusively modules following the extension in
   [RFC8971] are not required to include the YANG security template per
   guidance in Section 3.7 of [I-D.ietf-netmod-rfc8407bis].

13.  Acknowledgments

   We would like to thank the various reviewers, in particular Brian E.
   Carpenter, Charlie Kaufman (Early SECDIR review), Martin Björklund
   (Early YANGDOCTORS review), Marco Tiloca (Early IOTDIR review), Oskar
   Camenzind, Hendrik Brockhaus, and Ingo Wenda for their input and
   discussion on use cases and call flows.  Further review input was
   provided by Jesser Bouzid, Dominik Tacke, Christian Spindler, and
   Julian Krieger.  Special thanks to Esko Dijk for the in deep review
   and the improving proposals.  Another special thanks for the detailed
   Shepherad review and connected discussions to Matthias Kovatsch.
   Support in PoC implementations and comments resulting from the
   implementation was provided by Hong Rui Li and He Peng Jia. Review
   comments in the context of a formal analysis of BRSKI-PRM have been
   provided by Marco Calipari.

14.  References

14.1.  Normative References

   [I-D.ietf-anima-jws-voucher]
              Werner, T. and M. Richardson, "JWS signed Voucher
              Artifacts for Bootstrapping Protocols", Work in Progress,
              Internet-Draft, draft-ietf-anima-jws-voucher-16, 15
              January 2025, <https://datatracker.ietf.org/doc/html/
              draft-ietf-anima-jws-voucher-16>.

   [I-D.ietf-anima-rfc8366bis]
              Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
              and Q. Ma, "A Voucher Artifact for Bootstrapping
              Protocols", Work in Progress, Internet-Draft, draft-ietf-



Fries, et al.            Expires 5 December 2025               [Page 92]

Internet-Draft                  BRSKI-PRM                      June 2025


              anima-rfc8366bis-14, 1 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
              rfc8366bis-14>.

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

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

   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <https://www.rfc-editor.org/rfc/rfc4086>.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
              <https://www.rfc-editor.org/rfc/rfc5272>.

   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", RFC 5273,
              DOI 10.17487/RFC5273, June 2008,
              <https://www.rfc-editor.org/rfc/rfc5273>.

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

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

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

   [RFC7030]  Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
              "Enrollment over Secure Transport", RFC 7030,
              DOI 10.17487/RFC7030, October 2013,
              <https://www.rfc-editor.org/rfc/rfc7030>.






Fries, et al.            Expires 5 December 2025               [Page 93]

Internet-Draft                  BRSKI-PRM                      June 2025


   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

   [RFC7518]  Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7518>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, DOI 10.17487/RFC7951, August 2016,
              <https://www.rfc-editor.org/rfc/rfc7951>.

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

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

   [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
              Definition Language (CDDL): A Notational Convention to
              Express Concise Binary Object Representation (CBOR) and
              JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
              June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

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

   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
              and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
              May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

   [RFC9360]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Header Parameters for Carrying and Referencing X.509
              Certificates", RFC 9360, DOI 10.17487/RFC9360, February
              2023, <https://www.rfc-editor.org/rfc/rfc9360>.

   [RFC9646]  Watsen, K., Housley, R., and S. Turner, "Conveying a
              Certificate Signing Request (CSR) in a Secure Zero-Touch
              Provisioning (SZTP) Bootstrapping Request", RFC 9646,
              DOI 10.17487/RFC9646, October 2024,
              <https://www.rfc-editor.org/rfc/rfc9646>.

14.2.  Informative References



Fries, et al.            Expires 5 December 2025               [Page 94]

Internet-Draft                  BRSKI-PRM                      June 2025


   [androidnsd]
              "Android Developer: Connect devices wirelessly", archived
              at https://web.archive.org/web/20230000000000*/https://dev
              eloper.android.com/training/connect-devices-wirelessly,
              n.d., <https://developer.android.com/training/connect-
              devices-wirelessly>.

   [androidtrustfail]
              "Security with Network Protocols", archived at https://web
              .archive.org/web/20230326153937/https://developer.android.
              com/training/articles/security-ssl, n.d.,
              <https://developer.android.com/training/articles/security-
              ssl>.

   [BRSKI-PRM-abstract]
              "Abstract BRSKI-PRM Protocol Overview", March 2022,
              <https://datatracker.ietf.org/meeting/113/materials/
              slides-113-anima-update-on-brski-with-pledge-in-responder-
              mode-brski-prm-00>.

   [I-D.draft-ietf-emu-eap-arpa]
              DeKok, A., "The eap.arpa domain and EAP provisioning",
              Work in Progress, Internet-Draft, draft-ietf-emu-eap-arpa-
              06, 29 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
              arpa-06>.

   [I-D.ietf-anima-brski-discovery]
              Eckert, T. T. and E. Dijk, "BRSKI discovery and
              variations", Work in Progress, Internet-Draft, draft-ietf-
              anima-brski-discovery-05, 21 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-anima-
              brski-discovery-05>.

   [I-D.ietf-netmod-rfc8407bis]
              Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
              Authors and Reviewers of Documents Containing YANG Data
              Models", Work in Progress, Internet-Draft, draft-ietf-
              netmod-rfc8407bis-25, 5 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              rfc8407bis-25>.

   [I-D.ietf-uta-require-tls13]
              Salz, R. and N. Aviram, "New Protocols Using TLS Must
              Require TLS 1.3", Work in Progress, Internet-Draft, draft-
              ietf-uta-require-tls13-12, 14 April 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-uta-
              require-tls13-12>.



Fries, et al.            Expires 5 December 2025               [Page 95]

Internet-Draft                  BRSKI-PRM                      June 2025


   [I-D.irtf-t2trg-taxonomy-manufacturer-anchors]
              Richardson, M., "A Taxonomy of operational security
              considerations for manufacturer installed keys and Trust
              Anchors", Work in Progress, Internet-Draft, draft-irtf-
              t2trg-taxonomy-manufacturer-anchors-09, 28 May 2025,
              <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-
              taxonomy-manufacturer-anchors-09>.

   [I-D.richardson-anima-masa-considerations]
              Richardson, M. and W. Pan, "Operational Considerations for
              Voucher infrastructure for BRSKI MASA", Work in Progress,
              Internet-Draft, draft-richardson-anima-masa-
              considerations-09, 22 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-richardson-
              anima-masa-considerations-09>.

   [I-D.richardson-anima-registrar-considerations]
              Richardson, M. and W. Pan, "Operational Considerations for
              BRSKI Registrar", Work in Progress, Internet-Draft, draft-
              richardson-anima-registrar-considerations-09, 22 January
              2025, <https://datatracker.ietf.org/doc/html/draft-
              richardson-anima-registrar-considerations-09>.

   [IEEE-802.1AR]
              Institute of Electrical and Electronics Engineers, "IEEE
              802.1AR Secure Device Identifier", IEEE 802.1AR, June
              2018.

   [onpath]   "can an on-path attacker drop traffic?", n.d.,
              <https://mailarchive.ietf.org/arch/msg/saag/
              m1r9uo4xYznOcf85Eyk0Rhut598/>.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              DOI 10.17487/RFC2986, November 2000,
              <https://www.rfc-editor.org/rfc/rfc2986>.

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

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

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, DOI 10.17487/RFC5652, September 2009,
              <https://www.rfc-editor.org/rfc/rfc5652>.



Fries, et al.            Expires 5 December 2025               [Page 96]

Internet-Draft                  BRSKI-PRM                      June 2025


   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/rfc/rfc7252>.

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

   [RFC8792]  Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
              "Handling Long Lines in Content of Internet-Drafts and
              RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8792>.

   [RFC8971]  Pallagatti, S., Ed., Mirsky, G., Ed., Paragiri, S.,
              Govindan, V., and M. Mudigonda, "Bidirectional Forwarding
              Detection (BFD) for Virtual eXtensible Local Area Network
              (VXLAN)", RFC 8971, DOI 10.17487/RFC8971, December 2020,
              <https://www.rfc-editor.org/rfc/rfc8971>.

   [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
              Autonomic Signaling Protocol (GRASP)", RFC 8990,
              DOI 10.17487/RFC8990, May 2021,
              <https://www.rfc-editor.org/rfc/rfc8990>.

   [RFC8996]  Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
              <https://www.rfc-editor.org/rfc/rfc8996>.

   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
              Structures and Process", STD 96, RFC 9052,
              DOI 10.17487/RFC9052, August 2022,
              <https://www.rfc-editor.org/rfc/rfc9052>.

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

   [RFC9238]  Richardson, M., Latour, J., and H. Habibi Gharakheili,
              "Loading Manufacturer Usage Description (MUD) URLs from QR
              Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9238>.

   [RFC9440]  Campbell, B. and M. Bishop, "Client-Cert HTTP Header
              Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
              <https://www.rfc-editor.org/rfc/rfc9440>.




Fries, et al.            Expires 5 December 2025               [Page 97]

Internet-Draft                  BRSKI-PRM                      June 2025


   [RFC9483]  Brockhaus, H., von Oheimb, D., and S. Fries, "Lightweight
              Certificate Management Protocol (CMP) Profile", RFC 9483,
              DOI 10.17487/RFC9483, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9483>.

   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
              RFC 9525, DOI 10.17487/RFC9525, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9525>.

   [RFC9662]  Lonvick, C., Turner, S., and J. Salowey, "Updates to the
              Cipher Suites in Secure Syslog", RFC 9662,
              DOI 10.17487/RFC9662, October 2024,
              <https://www.rfc-editor.org/rfc/rfc9662>.

   [RFC9733]  von Oheimb, D., Ed., Fries, S., and H. Brockhaus, "BRSKI
              with Alternative Enrollment (BRSKI-AE)", RFC 9733,
              DOI 10.17487/RFC9733, March 2025,
              <https://www.rfc-editor.org/rfc/rfc9733>.

Appendix A.  Examples

   These examples are folded according to [RFC8792] Single Backslash
   rule.

A.1.  Example Pledge Voucher-Request (PVR) - from Pledge to Registrar-
      Agent

   The following is an example request sent from a Pledge to the
   Registrar-Agent, in "General JWS JSON Serialization".  The message
   size of this PVR is: 2973 bytes

   =============== NOTE: '\' line wrapping per RFC 8792 ================

   {
     "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
   NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
   c4OSIsIm5vbmNlIjoia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbi\
   I6IjIwMjQtMDYtMjRUMDk6MDE6MjQuNTU2WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbW\
   l0eS1yZWdpc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW\
   9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQm\
   dOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd0\
   5qRTRNVEphRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVn\
   phVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibE\
   psWjJsemRISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNk\
   svaTc5b1JrSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1\
   dSZmZlV2t5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUU\
   dDQ3NHQVFVRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQV\
   lEVlIwUkJFRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1Wl\



Fries, et al.            Expires 5 December 2025               [Page 98]

Internet-Draft                  BRSKI-PRM                      June 2025


   hTQ0huSmxaMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncW\
   hrak9QUVFEQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUm\
   F1YnBDN01hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaD\
   R4SVhrMSIsImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRn\
   BZVW0xTVdGcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VV\
   hSak1teHVZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSm\
   FrbDNUV3BKZEUxRWEzUk5ha3BWVFVSVk5rNUVUVFpPVkVGMVRWUkpNVmRwU1hOSmJrNX\
   NZMjFzYUdKRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaX\
   dpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYV\
   VwVlZFZE5NMWRZYUV4V2JGWldaVzVLTTFKVVRsSlhWRlpEV2xaa2IyTXlNVVZOTW1NNV\
   NXbDNhVmxYZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrd3\
   lZVEJsY3pWZkxXZHNZVjkwTjFVME1VbFJXRmxJU1RSQlMxVldVRkZmTTFSbGQxUTFiMF\
   ZWWVVOdFVIQktaMmRyU0c1d09WTk1aVFZ1YWkxbldGbFRiMk5sT1RoeFFXSnROa0YwZF\
   MxRlIxUkxZMDVSSW4xZGZRMEsifX0",
     "signatures": [
       {
         "protected": "eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNV\
   NU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
   eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
   Q0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3\
   Q1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZ\
   RFZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRt\
   bGpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpj\
   RUVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2\
   TXgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcx\
   aGMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1C\
   YUFGRlFMak56UC9TL2tvdWpRd2pnNUU1ZnZ3Y1liTUJNR0ExVWRKUVFNTUFvR0NDc0dB\
   UVVGQndNQ01BNEdBMVVkRHdFQi93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBREJF\
   QWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnWENt\
   SkxUekVsdkQycG9LNmR4NmwxL3V5bVRuYlFERGZKbGF0dVgyUm9PRT0iXSwidHlwIjoi\
   dm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0",
         "signature": "ntAgC7GT7xIDYcHBXoYej8uIUI6WR2Iv-7T1CaR-J6-xS60D\
   iWS1-vfc5Uu5INZS1dyWZ4vVH6uaoPceRxNc8g"
       }
     ]
   }

              Figure 53: Example Pledge-Voucher-Request - PVR

A.2.  Example Registrar Voucher-Request (RVR) - from Registrar to MASA

   The following is an example registrar-voucher-request (RVR) sent from
   the Registrar to the MASA, in "General JWS JSON Serialization".  Note
   that the previous PVR can be seen in the payload as "prior-signed-
   voucher-request".  The message size of this RVR is: 7533 bytes






Fries, et al.            Expires 5 December 2025               [Page 99]

Internet-Draft                  BRSKI-PRM                      June 2025


   =============== NOTE: '\' line wrapping per RFC 8792 ================

   {
     "payload": "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3\
   NlcnRpb24iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Nj\
   c4OSIsImlkZXZpZC1pc3N1ZXIiOiJCQmd3Rm9BVVZBdU0zTS85TCtTaTZORENPRGtUbC\
   svQnhocz0iLCJub25jZSI6ImtoTnlLcE10aGNjaWExclh3NDQvdlE9PSIsInByaW9yLX\
   NpZ25lZC12b3VjaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbT\
   FNV0ZwMlpGZE9iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYV\
   VrMlpYbEthR016VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1\
   pFaHJhVXhEU25wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFVMUVSWGxOZWxFeFRtcG\
   pORTlUU1hOSmJUVjJZbTFPYkVscWIybGhNbWhQWlZWMGQxUllVbTlaTWs1d1dWUkdlVm\
   RJWXpCT1F6a3lWVlF3T1VscGQybFpNMHBzV1ZoU2JGcERNWFppYVVrMlNXcEpkMDFxVV\
   hSTlJGbDBUV3BTVlUxRWF6Wk5SRVUyVFdwUmRVNVVWVEpYYVVselNXMUdibHBYTlRCTV\
   dFSjVZak5hY0ZwSFZtdE1XRUo1WWpOb2NHSlhiREJsVXpGNVdsZGtjR016VW5sWldFbD\
   BXVEpXZVdSRFNUWkphekZLVTFWSk1HRnJUa1JSVm14d1dqQkdNMU5WU2tKYU1HeElVVl\
   pvV2s1NlNtbFpiSEJPVVZjNVNGRXdUbmhTTVU1T1RrUnNRMUZWTVVSVVZWSldaVVZXTm\
   xGV1NrTmFNRFZYVVd0R2RsUlZUbkpOVkZaU1lteGFObGxXWXpGaVIwMTZWRmhvUlZaRl\
   JrMVJiV1JQVm10S1Fsa3dNVU5TYXpWM1drVmtWbVZGVWpaUlZUVkRXakExVjFGclJrNV\
   VWVXB6VlcxNGFrMHhTa1ZWVmxKQ1dsVmFNMDFJYkU1U1JWWTFWRlZTYW1Rd05YRlNWRk\
   pPVmtWd2FGSnVZM2RsYXpGRlVsaHNUbEpIVGpOVWJYQkdUa1V4VlZOdFJrNVNSRkkwVW\
   xod1FsVnJTbTVVYkZwRFVWYzVUbEV5YzNoT1ZrWjFWbTV3YUZaNlZuTlplazVPWlVWU1\
   ZWRlZlRU5hTURWWFVXdEdhbFJWU2tkVWJrSnJVakZXTkZJd1VrSldNRXB1Vkd4YVExRl\
   ZNVTVTUkVKVFpHMUtXRkp1UW1saVJYQnpWMnBLYzJWdFVrbFRiV2hxWVd0S1lWUlZTaz\
   VTTUVvMVkxVmtWRlJVVVRWUlYyUkdVakJPUkdOVlpGUlVWRkUxVVZoa1JsTkZSWGRUVl\
   VaRFVXMXplRTVyYzNaaFZHTTFZakZLY2xONlZscFpiVlpSV25wb1ZsVXhTVFJNTTFaNl\
   RWZFNVVlpYYkdGVFJURXdZakowVkZwSVJreFdlbFp0WW14a2VsRnRVWEpqVmtwTlRqRm\
   tVMXB0V214V01uUTFXakpXYVdJd2NHMVRWM2h6WkZoS2FtRlVTVEZrTWpWdllWVTVWMU\
   V3WkhGYVdIQkRUbFV4UTAxRlpFSk5WbFpyVTJ4R1VsWXdNVU5WVldSRVVUTk9TRkZXUm\
   xaU2Ewb3pWRlZLUTFveVpIbFJiV1JHVW10S1Vsa3dVa2xTUlVaUVVXMWtUMVpyYUZKUF\
   JVcENXbXBvUmxGclJrNVJNRWt3VVZoa1ZGRldiRVZXYkVsM1ZXdEtSbEpZWkZGT1JXeH\
   JXVEl4VjJKdFJsbFVha0pxWWxWYU5WUkdhRk5pUjAxNlZWaFdhazF0ZUhOWmJHUlhaRm\
   RPTlUxWGJHdFJlbFl4VjJ4b1ZGRXdhSFZUYlhoaFRXMTRObHBGYUV0aFIwNXdUVlJDWV\
   ZkRk5IZFViV3N4WlcxR1dGWnVVbUZXZWxZMlZFWmtTMDFGZUhST1YzaHJVa1ZHVEZGdF\
   pHNWpWMmh5WVdzNVVWVldSa1ZSVjJSUFUxVkdSVkZyV2tKaFZVbzBZa2RTUTJGR2NIaE\
   5SVll5VGxWd1RVMXNRbmxXTUU0d1pWWk5NbUZGVWxwV2VrWTFVVEE0ZGxWdFJqRlpia0\
   pFVGpBeGFGTlZVbTVUVjJoQ1ZFWk9TMWx0WkUxaWJXUnZXVzFLUWxwNlFtdFpNV1JIVm\
   xaYWRrd3laRWhVYWtGMllXNWtObE5zYjNkVk1uZDVZVVJTTkZOV2FISk5VMGx6U1cxR2\
   JscFhOVEJNV0U1d1dqSTFiRnBETVd0WldGSm9TV3B2YVZwWWJFdGtNV3haWWtoT2FVMX\
   JXbkpUVjNCMllWWndXV0pGZEdwU2JrSmFWbGN3ZUZSV1pFZGpSRXBoVW0xU1VGbHFSbm\
   RYVms1WlZXMXdhVlpzYnpCWGExcHJWakpXZEZWclVrNVhSMUp4V1d4U1FrMXNaRmRhUj\
   NScFVqQndNVlpXYUZOaGF6RjBaVWhXV21KVVJsaFpWRUkwVjBaV2RHRkhkRk5OUmxwM1\
   ZrUkpNV1Z0UmxkaE0zQlVZbGhvWVZZd1drdGpNV1J5VkZob2EySlZjSGRWTVZKaFUyMU\
   djbUpFVGxWV00wSkxXa1ZWZUZKWFJYcFZhelZvWVROQ1YxWkdWbE5XYXpWeVRsVldWVl\
   pHY0ZCV2ExWkhUVlpTVjFWcmNFNVdiVkozVlRGb1QxTnRTbkpPV0U1YVRXcEdlbGxWWk\
   V0U1JURlpWbTEwVjJWclduZFdNbmh2VTIxR1ZrOVlRbFJYUjFKUFZtdFdjMDVzVW5KVm\
   JGcE9ZWHBWTWxkdWNGZFRiVXB4VWxSV1NtRllaSEJaZWtwelltMUtkRkpxUW10WFJYQn\
   pXVE5zU2s1c1kzcGpNbXhxVTBWd01scEZaRmRoYlZKSVZtMTBTbUZ0T1hCWGJHaHpVek\



Fries, et al.            Expires 5 December 2025              [Page 100]

Internet-Draft                  BRSKI-PRM                      June 2025


   pPZEZKc2FGWldNbmhSV1ZaV2QxWnNXa1phUlRWT1RWZFNXbGxWVmpSV01rcEhWMnhrWV\
   ZaNlZreFVWRVpMVmxaU2MxTnNhRmRTYkhCRlZqSjRZV0V5U1hsVVdHeE9WbFphVDFSWE\
   1VNU9WazVZWWtST2FGWnRlRmxhVldNeFUyMUdkRTlZUWxaaVJuQlBXbFpWTVZaV1pGaG\
   lSekZXVlRCc2VsTlhOVTlqUm05NVRsZG9hMU5HV2pWWGJFNUtUbXRzY21RemJGcFdSVX\
   B6V1ROd1YxcHJlRmhhU0U1YVZtcHJkMVJxUmxaTlJURldZa1pLV0ZKdGVFcFZNVkpUVV\
   d4TmVGWnNaRlpTYTFwdFZGUkdVMkpIVVhoVlZFWnBUVVphVjFkV1ZrOWtSbFpKVVd0MF\
   lVMXRVbmxWTUdNeFpEQTVWMVJyTVdGV1Jsb3hXVmRyZUdKc1pFZGlSbEpwVFdzMWMxUX\
   hVbTlsUmtaWVUyNVNUMkV3V1hkYVJrMTRVbXhKZUZWcmVGcE5SRlpUVTFjMGVGcEhXbE\
   pOUlhOcFpsZ3dJaXdpYzJsbmJtRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWl\
   hsS05FNVhUV2xQYkhOcFZGVnNTbEZwZEZWUk1FNUNXVlZPYmxGWVpFcFJhMFp1VTFWa1\
   FsZEhOVmRoYms1V1RsVXhRbUl3WkVSUk0wWklWVEF3TUU5VlNrSlVWVTVPVWtSQ05GRX\
   pjRUpUYTBwdVZHeGFRMUZXYkZWUlYzUkhWV3N4VTFaWVpFWmtNV3hGVm14R1VsTXdVa0\
   psUlhSb1ZucFdkVlV5TVhOa1ZtOTNWRzVhYW1KclJqUlNibkJDVm10S2JsUnNXa05SVl\
   RGT1VrZDBkMk5IU25SYVJYUm9WbnBXZFZaclpGZGxiVkpHVkd0S1RsRXdSbGxTUmxKS1\
   pVVXhSVmRZWkU5U1JVVjRWR3RTV21WRk5VZGlNV3hGWlcxek1WUXhVbkpsUlRGeFZGaG\
   9UbUZyTUhoVU1WSldUbFprY1ZGc1RrNVZXRTR6VVRGR1dsSkdXbEpWVldSR1pEQndRMV\
   pXVWtaV2F6RkRWRlZrUWsxV1ZrWlJNbVF6VkZaT2RHSklWbUZOU0VKM1dXMHhhMUpIU1\
   hwVGJtUk9WV3N4TTFKV1JscFNSbHBTVlZWYVJtUXlPVE5VVmxKS1pXczFSVlpVU2s5bG\
   JXTXhWRlpLYW1Rd1dsSlhWVkpYVlZaR1JWSkZSVEZUTWtaWVRsYzFWR0pYZURGWGFrSl\
   RZa2RTZEdKSGNHRldSVXBoVkZWS1RsSXdTalZqVldSVVZGUlJOVkZYWkVaU01FNUVZMV\
   ZrVkZSVVVUVlJXR1JHVTBWRmQxTlZSa05SZW1NMVlrZHNhRlZ0VGtOaGJIQnFVbFZXV1\
   dSNlpIbFdWMVpvWkc1U1NGTnJSakZUUkZKM1lYcFNTazVFU2pKWlZVcE9ZekZWZUUxWG\
   JFMVNSVTVFVkVkMFYyRklVbFpXYWtsNFlsaGFhRk13VGpKVVdHZDVWMU4wVkZSWFpGSl\
   BSMXB0WkRCM2VVMHpiM3BXUld4WFVXeGtjVnBHVWtObGF6RkVZekJrUkZFelRraFJWa1\
   pXVW10S00xSlhaRU5SYW1oWVUwWmplR0ZIVFhsU1dGSnJVakZhTmxwRlRURmxiVVpZVm\
   01U1lWWjZWalpVUm1STFRVVjRkRTVYZUd0U1J6Z3hWR3RTVW1Wck1VTlBSV1JDVFZaV2\
   ExTllaRkpYVlRGRFdWVkdSMUpzUmsxaGF6VTJWVU01VkV3eWRIWmtWM0JTWkRKd2JrNV\
   ZWVEZhYmxveldURnNhVlJWU2s1U01FVjRWbGRTUzFWV1JrNVVWVVoyVWpCT1JHTXdaRU\
   pWVmxaSFVXNWtUbEV3TVVKT1JXUkNUVlpXYTFKSVpFWlJhVGt6VlZWV1FtUXdiRWxhTU\
   ZKQ1V6QktibG96Um05aE1uQlFWVVpHVWxKRlJtNVVhMmhDVWtWS1JsRlhiRU5rVkU0el\
   ZXdEtUV013Y0U1VlJGWjZWRlJCTTAxRlozSldWVnA1WlZVMVZrNXRaRXhsYTNoUVZXMU\
   9SMlZXU2xOVU1uaDRZMVZvY0Zvd2JHNVhSVTUwVTJ0NFZXVnJWbk5rYTFGNVkwYzVURT\
   V0VWpST2JYZDRURE5XTldKV1VuVlpiRVpGVWtkYVMySkhSakJrVm1kNVZXMDVVRkpVTU\
   dsWVUzZHBaRWhzZDBscWIybGtiVGt4V1RKb2JHTnBNWEZrTTAxeVlXNU9kbUpwU1hOSm\
   JVWnpXbmxKTmtsclZsUk5hbFV5U1c0d0lpd2ljMmxuYm1GMGRYSmxJam9pYm5SQlowTT\
   NSMVEzZUVsRVdXTklRbGh2V1dWcU9IVkpWVWsyVjFJeVNYWXROMVF4UTJGU0xVbzJMWG\
   hUTmpCRWFWZFRNUzEyWm1NMVZYVTFTVTVhVXpGa2VWZGFOSFpXU0RaMVlXOVFZMlZTZU\
   U1ak9HY2lmVjE5IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMjRUMDk6MDI6MTUuNTczWi\
   IsImFnZW50LXNpZ24tY2VydCI6WyJNSUlCOWpDQ0FaMmdBd0lCQWdJRVl4WHM3VEFLQm\
   dncWhrak9QUVFEQWpBK01STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRF\
   ZRUUhEQVJUYVhSbE1SZ3dGZ1lEVlFRRERBOVVaWE4wVUhWemFFMXZaR1ZzUTBFd0hoY0\
   5Nakl3T1RBMU1USXpORFV6V2hjTk1qVXdPVEExTVRJek5EVXpXakJnTVFzd0NRWURWUV\
   FHRXdKQlVURVNNQkFHQTFVRUNnd0pUWGxEYjIxd1lXNTVNUlV3RXdZRFZRUUxEQXhOZV\
   ZOMVluTnBaR2xoY25reEpqQWtCZ05WQkFNTUhVMTVVMmwwWlZCMWMyaE5iMlJsYkZKbF\
   oybHpkSEpoY2tGblpXNTBNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQU\
   V4aHZuYWtDSmVpZ3pqWkFVYU5adVAwMWUrUWxVY1E5UjJMSWs2UkI2dmtjdFdMS3BaWC\
   85TGthNEdxckFWWmhhM3ZKcmhGc0l4OEdUQkhqWnZLMVd1Nk5uTUdVd0RnWURWUjBQQV\
   FIL0JBUURBZ09JTUI4R0ExVWRJd1FZTUJhQUZHK2hQVzUxN1ovb3NSQ0ZUc2NlUDY4bj\



Fries, et al.            Expires 5 December 2025              [Page 101]

Internet-Draft                  BRSKI-PRM                      June 2025


   kzc2pNQjBHQTFVZERnUVdCQlJNdHp0akVwVlJUT3ZBVGRCamtGNWFHeVlQZURBVEJnTl\
   ZIU1VFRERBS0JnZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05IQURCRUFpQmJoRG\
   pwbDJ2cWNONnBSVjRuZVU0dFFsWWFOTit4ZjNnSnUrMHBKblNBL1FJZ0ljcXpsZmhYaU\
   Qxc0g3VTVQdUtwVVpzSWpkRjRSenhzQTZxSnRFTEQyUHM9Il19fQ",
     "signatures": [
       {
         "protected": "eyJ4NWMiOlsiTUlJQm96Q0NBVXFnQXdJQkFnSUdBVzBlTHVJ\
   Rk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
   QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweE9UQTVN\
   VEV3TWpNM016SmFGdzB5T1RBNU1URXdNak0zTXpKYU1GUXhFekFSQmdOVkJBb01DazE1\
   UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhMakFzQmdOVkJBTU1KVkpsWjJs\
   emRISmhjaUJXYjNWamFHVnlJRkpsY1hWbGMzUWdVMmxuYm1sdVp5QkxaWGt3V1RBVEJn\
   Y3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVQ2eFZ2QXZxVHoxWlVpdU5XaFhwUXNr\
   YVB5N0FISFFMd1hpSjBpRUx0NnVOUGFuQU4wUW5XTVlPLzBDREVqSWtCUW9idzhZS3Fq\
   dHhKSFZTR1RqOUtPb3ljd0pUQVRCZ05WSFNVRUREQUtCZ2dyQmdFRkJRY0RIREFPQmdO\
   VkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXpqMEVBd0lEUndBd1JBSWdZcjJMZnFvYUNL\
   REY0UkFjTW1KaStOQ1pxZFNpdVZ1Z0lTQTdPaEtScTNZQ0lEeG5QTU1ucFhBTVRyUEp1\
   UFd5Y2VFUjExUHhIT24rMENwU0hpMnFncFdYIl0sInR5cCI6InZvdWNoZXItandzK2pz\
   b24iLCJhbGciOiJFUzI1NiJ9",
         "signature": "_mcsO5vo0g2rFmBvTb-UsOWkEmhYNfQ5XmbuKHKH0ZLjea-7\
   911BilAMdFORmT4vCzWKBSH6HSqtpIRcSSxx7Q"
       }
     ]
   }

             Figure 54: Example Registrar-Voucher-Request - RVR

A.3.  Example Voucher - from MASA to Pledge, via Registrar and
      Registrar-Agent

   The following is an example voucher-response from MASA to Pledge via
   Registrar and Registrar-Agent, in "General JWS JSON Serialization".
   The message size of this Voucher is: 1916 bytes


















Fries, et al.            Expires 5 December 2025              [Page 102]

Internet-Draft                  BRSKI-PRM                      June 2025


   =============== NOTE: '\' line wrapping per RFC 8792 ================

   {
     "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
   udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
   iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
   UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
   3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
   RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
   EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
   BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
   nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
   CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
   ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
   FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
   CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
   BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
   HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
     "signatures":[{
       "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
   Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
   hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
   YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
   VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
   3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
   CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
   wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
   CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
   qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
   FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
   FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ",
       "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\
   TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw"
     }]
   }

               Figure 55: Example Voucher-Response from MASA

A.4.  Example Voucher, MASA issued Voucher with additional Registrar
      signature (from MASA to Pledge, via Registrar and Registrar-Agent)

   The following is an example voucher-response from MASA to Pledge via
   Registrar and Registrar-Agent, in "General JWS JSON Serialization".
   The message size of this Voucher is: 2994 bytes







Fries, et al.            Expires 5 December 2025              [Page 103]

Internet-Draft                  BRSKI-PRM                      June 2025


   =============== NOTE: '\' line wrapping per RFC 8792 ================

   {
     "payload": "eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2\
   VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIj\
   oia2hOeUtwTXRoY2NpYTFyWHc0NC92UT09IiwiY3JlYXRlZC1vbiI6IjIwMjQtMDYtMj\
   RUMDk6MDI6MTYuMjQ0WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0\
   F3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMT\
   VRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1\
   JEUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RX\
   pBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTk\
   JnTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSU\
   FCT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2\
   NZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRX\
   dFQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0\
   JCVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQk\
   dBaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUU\
   RHMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
     "signatures": [
       {
         "protected": "eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNr\
   WU1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RB\
   eEthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJN\
   QjRYRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtH\
   QTFVRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFV\
   RUF3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dU\
   QVRCZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJz\
   OFIwWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZP\
   S0dCSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29a\
   SXpqMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4L3R6VW9RL1NzeWRMMzBEUUlO\
   RXRjTjltQ1RYUEFpRUF2SWIzbytGTzNCVG5jTEZzYUpaUkFrZDd6T3Vzbi8vWktPYUVL\
   YnNWRGlVPSJdLCJ0eXAiOiJ2b3VjaGVyLWp3cytqc29uIiwiYWxnIjoiRVMyNTYifQ",
         "signature": "SFtc2xqK8xN2KVqkYKJl7EUU8UJAai3VvCuK8LIfH8HZFvrr\
   hqGiY8vK5cbQHQCjVcroFLn7IyhH708XAdstAQ"
       },
       {
         "protected": "eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJi\
   Wk1Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERU\
   QUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlN\
   RGN3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1\
   UW5WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldG\
   cGJsSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJC\
   azE2Sy9pNzlvUmtLNVliZVBnOFVTUjgvdXMxZFBVaVpITXRva1NkcUtXNWZuV3NCZCtx\
   Ukw3V1JmZmVXa3lnZWJvSmZJbGx1cmNpMjV3bmhpT1ZDR2plekI1TUIwR0ExVWRKUVFX\
   TUJRR0NDc0dBUVVGQndNQkJnZ3JCZ0VGQlFjREhEQU9CZ05WSFE4QkFmOEVCQU1DQjRB\
   d1NBWURWUjBSQkVFd1A0SWRjbVZuYVhOMGNtRnlMWFJsYzNRdWMybGxiV1Z1Y3kxaWRD\
   NXVaWFNDSG5KbFoybHpkSEpoY2kxMFpYTjBOaTV6YVdWdFpXNXpMV0owTG01bGREQUtC\
   Z2dxaGtqT1BRUURBZ05JQURCRkFpQnhsZEJoWnEwRXY1SkwyUHJXQ3R5UzZoRFlXMXlD\



Fries, et al.            Expires 5 December 2025              [Page 104]

Internet-Draft                  BRSKI-PRM                      June 2025


   Ty9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm8vZ0dOMC9qd3pKWjBT\
   bDJoNHhJWGsxIl0sInR5cCI6InZvdWNoZXItandzK2pzb24iLCJhbGciOiJFUzI1NiJ9\
   ",
         "signature": "0Q7_a7L4ahn2vmfSxxkKg1xsOMMc8_D7B_Ilzqv5DKzCMkc7\
   8YeeezDsuh4Z5JNVQUYHPp7LsK_AS_WH8TdVzA"
       }
     ]
   }

       Figure 56: Example Voucher-Response from MASA, with additional
                            Registrar signature

Appendix B.  HTTP-over-TLS operations between Registrar-Agent and Pledge

   The use of HTTP-over-TLS between Registrar-Agent and pledge has been
   identified as an optional mechanism.

   Provided that the key-agreement in the underlying TLS protocol
   connection can be properly authenticated, the use of TLS provides
   privacy for the voucher and enrollment operations between the pledge
   and the Registrar-Agent.  The authenticity of the onboarding and
   enrollment is not dependent upon the security of the TLS connection.

   The use of HTTP-over-TLS is not mandated by this document for two
   main reasons:

   1.  A certificate is generally required in order to do TLS.  While
       there are other modes of authentication including PSK, various
       EAP methods, and raw public key, they do not help as there is no
       previous relationship between the Registrar-Agent and the pledge.

   2.  The pledge can use its IDevID certificate to authenticate itself,
       but [RFC9525] DNS-ID methods do not apply, as the pledge does not
       have a FQDN, and hence cannot be identified by DNS name.  Instead
       a new mechanism is required, which authenticates the
       X520SerialNumber DN attribute that must be present in every
       IDevID.

   If the Registrar-Agent has a pre-configured list of which product-
   serial-number(s), from which manufacturers it expects to see, then it
   can attempt to match this pledge against a list of potential devices.

   In many cases only the list of manufacturers is known ahead of time,
   so at most the Registrar-Agent can show the X520SerialNumber to the
   (human) operator who may then attempt to confirm that they are
   standing in front of a device with that product-serial-number.  The
   use of scannable QR codes may help automate this in some cases.




Fries, et al.            Expires 5 December 2025              [Page 105]

Internet-Draft                  BRSKI-PRM                      June 2025


   The CA used to sign the IDevID will be a manufacturer private PKI as
   described in Section 4.1 of
   [I-D.irtf-t2trg-taxonomy-manufacturer-anchors].  The anchors for this
   PKI will never be part of the public WebPKI anchors which are
   distributed with most smartphone operating systems.  A Registrar-
   Agent application will need to use different APIs in order to
   initiate an HTTP-over-TLS connection without performing WebPKI
   verification.  The application will then have to do its own
   certificate chain verification against a store of manufacturer trust
   anchors.  In the Android ecosystem this involves use of a customer
   TrustManager: many application developers do not create these
   correctly, and there is significant push to remove this option as it
   has repeatedly resulted in security failures (see
   [androidtrustfail]).

   Also note that an Extended Key Usage (EKU) for TLS WWW Server
   authentication cannot be expected in the pledge IDevID certificate.
   IDevID certificates are intended to be widely usable and EKU does not
   support that use.

Appendix C.  History of Changes "RFC Editor: please delete"

   Proof of Concept Code available

   From IETF draft 22 -> IETF draft 23:

   *  editorial update of new section on TLS usage clarifications
      Section 4.1

   *  structural and editorial improvements to privacy considerations
      Section 11

   From IETF draft 21 -> IETF draft 22:

   *  addressed remaining issues from telechat

      -  included overview subsections for reason-context definition and
         usage in Section 6.2

      -  updated status detail examples to correctly use the defined
         types in the status structure.

      -  new section on TLS usage clarifications Section 4.1

   From IETF draft 20 -> IETF draft 21:

   *  addressed remaining issues from telechat




Fries, et al.            Expires 5 December 2025              [Page 106]

Internet-Draft                  BRSKI-PRM                      June 2025


      -  RetryAfter response to be always provided in case of 503
         Service unavailable response

   From IETF draft 19 -> IETF draft 20:

   *  addressed last comments and nits before telechat

   From IETF draft 18 -> IETF draft 19:

   *  addressed DISCUSS received during telechat preparation:

      -  issue 136: included hint for reaction on HTTP requests to avoid
         DoS (rate limiting) in Section 6.2

      -  issue 137: HTTP error handling BCP RFC 9205: removed normative
         language for HTTP status codes

      -  issue 139: usage of TLS 1.3 emphasized by also referencing UTA
         draft in Section 7.3

      -  issue 140: provided hint for time synchronization of registrar-
         agent in Section 6.1

      -  issue 145: clarified language tagging in status information in
         Section 7.6.2.1

   *  addressed COMMENT, NITS, received during telechat preparation,
      specifically

      -  issue 140: synchronized time

      -  issue 141: config options for discovery and nonceless vouchers
         in Section 7.6 and Section 6.1

      -  issue 142: addressed TTL of provisional accept state by
         utilizing the last received tPVR for the binding in Section 7.1

      -  issue 144: clarified usage of "MUST ...unless" in Section 6.2

      -  issue 146: added MTI algorithm for JWS signatures

      -  issue 147: definitions of reason-context in status objects

   *  updated reference of BRSKI-AE (now RFC 9733).

   *  removed unused references

   From IETF draft 17 -> IETF draft 18:



Fries, et al.            Expires 5 December 2025              [Page 107]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  addressed nits received from the GenART review

   *  addressed comment from IANA to update contact for service name
      registration from IESG to IETF Chair in Section 10.2

   *  SECDIR review: included reasoning for short lived certificates in
      Section 6.1

   *  SECDIR review: enhanced reasoning for optional TLS usage in
      Section 7.1

   *  SECDIR review: added hint for handling if the accept header is not
      used in Section 7.1 and Section 7.2

   *  SECDIR review: added hint for response body encoding in
      Section 7.1 and Section 7.2

   *  SECDIR review: added hint regarding IDevID and LDevID validity in
      Section 9

   *  DNSDIR review: renamed Section 10.2 to Service Name and Transport
      Protocol Port Number Registry

   *  from IANA expert review: included registered service names in
      headings

   From IETF draft 16 -> IETF draft 17:

   *  updated formatting of key events in Section 8

   *  updated reference to corresponding sections for JWS Header and
      Signature in [I-D.ietf-anima-jws-voucher] in Section 7.1.2.1 and
      Section 7.3.4.1

   *  simplified description for JWS Protected Header aligning with the
      update in draft-ietf-anima-jws-voucher-15 to always include the
      certificate chain in Section 7.1.2.1 and Section 7.3.4.1

   From IETF draft 15 -> IETF draft 16:

   *  issue #135: corrections from IOTDIR review (clarification
      regarding minimum supported discovery in Section 6.1.2,
      clarification regarding CDDl notation in Figure 27 and editorial
      nits.

   *  updated references (draft-ietf-netconf-sztp-csr became RFC 9646,
      included RFC 9662, operational considerations drafts for registrar
      and MASA)



Fries, et al.            Expires 5 December 2025              [Page 108]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  AD review: included term Registrar-Agent in Terminology section

   *  AD review: enhanced interaction information in Figure 1 and
      Figure 2

   *  AD review: included new section on Section 9 to outline
      operational considerations

   *  AD review: enhanced Section 8 with more detailed recommendations
      on logging

   *  AD review: enhanced Section 11 with enhanced recommendations
      concerning logging

   *  AD review: enhanced Section 12.3 with more information about
      misuse of the Registrar-Agent

   *  IOTDIR/OPSDIR/AD review: addressed various nits received
      throughout the draft

   From IETF draft 14 -> IETF draft 15:

   *  issue #134: editorial clarifications on references to
      [I-D.ietf-anima-brski-discovery] in Section 6.1.1 and
      Section 6.1.2

   From IETF draft 13 -> IETF draft 14:

   *  Update of the examples in Appendix A to align with the defined
      prototypes

   *  Changes incorporated based on Shepherd review PR #133:

      -  Terminology alignment and clarification throughout the document
         to use terms more consistently

      -  Restructuring of Section 7 for protocol steps to align to the
         general approach: Overview, data description, CDDL description
         (if necessary), JWS Header an Signature.  This lead to some
         movement of text between existing and new subsections.

      -  Inclusion of new section on logging hints Section 8 to give
         recommendations on which events to be logged for auditing

      -  Alignment of pledge status response data across
         Section 7.6.2.1, Section 7.8.2.1, and Section 7.11.2.1.





Fries, et al.            Expires 5 December 2025              [Page 109]

Internet-Draft                  BRSKI-PRM                      June 2025


      -  Included MASA component in description of affected components
         in Section 6

      -  Moved host header field handling from Appendix B to Section 6.2
         as generally applicable

      -  Updated status artifacts (vStatus, eStatus, pStatus) to align
         with BRSKI CDDL definition, but made reason-context mandatory
         to have distinguishable objects for the registrar-agent

      -  Correction of terminology of local host name vs. service
         instance name in Section 6.1.2

   *  Update of informative references and nits

   From IETF draft 12 -> IETF draft 13:

   *  Deleted figure in Section "Request Artifact: Pledge Voucher-
      Request Trigger (tPVR)" for JSON representation of tPVR, as it has
      been replaced by CDDL

   *  Updated reason-content description in status response messages
      (enroll-status, voucher-status, and status-response).

   *  Updated CDDL source code integration to allow for automatic
      verification

   *  Reordered description in Section 7.3 in Section 7.2 to better
      match the order of communication and artifact processing.

   *  Updated CDDL for the request-enroll trigger in Figure 15 according
      to the outcome of the interim ANIMA WG meeting discussions on
      April 19, 2024

   *  Included statement in Section 7.2.2 for using the advanced
      created-on time from the agent-signed-data also for the PER, when
      the pledge has no synchronized clock

   From IETF draft 11 -> IETF draft 12:

   *  Updated acknowledgments to reflect early reviews

   *  Addressed Shepherd review part 2 (Pull Request #132); containing:
      terminology alignment, structural improvements of the document;
      deletion of leftovers from previous draft versions; change of
      definitions to CDDL, when no YANG is available

   From IETF draft 10 -> IETF draft 11:



Fries, et al.            Expires 5 December 2025              [Page 110]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  issue #79, clarified that BRSKI discovery in the context of BRSKI-
      PRM is not needed in Section 6.1.1.

   *  issue #103, removed step 6 in verification handling for the
      wrapped CA certificate provisioning as only applicable after
      enrollment Section 7.7

   *  issue #128: included notation of nomadic operation of the
      Registrar-Agent in Section 5, including proposed text from PR #131

   *  issue #130, introduced DNS service discovery name for brski_pledge
      to enable discovery by the Registrar-Agent in Section 10

   *  removed unused reference RFC 5280

   *  removed site terminology

   *  deleted duplicated text in Section 6.2

   *  clarified registrar discovery and relation to BRSKI-Discovery in
      Section 6.1.1

   *  clarified discovery of pledges by the Registrar-Agent in
      Section 6.1.2, deleted reference to GRASP as handled in BRSKI-
      Discovery

   *  addressed comments from SECDIR early review

   From IETF draft 09 -> IETF draft 10:

   *  issue #79, clarified discovery in the context of BRSKI-PRM and
      included information about future discovery enhancements in a
      separate draft in Section 6.1.1.

   *  issue #93, included information about conflict resolution in mDNS
      and GRASP in Section 6.1.2

   *  issue #103, included verification handling for the wrapped CA
      certificate provisioning in Section 7.7

   *  issue #106, included additional text to elaborate more the
      registrar status handling in Section 7.9 and Section 7.10

   *  issue #116, enhanced DoS description in Section 12.1

   *  issue #120, included statement regarding pledge host header
      processing in Section 6.2




Fries, et al.            Expires 5 December 2025              [Page 111]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  issue #122, availability of product-serial-number information on
      registrar agent clarified in Section 7.1

   *  issue #123, Clarified usage of alternative voucher formats in
      Section 7.3.4

   *  issue #124, determination of pinned domain certificate done as in
      RFC 8995 included in Section 7.3.5

   *  issue #125, remove strength comparison of voucher assertions in
      Section 5.4 and Section 7

   *  issue #130, aligned the usage of site and domain throughout the
      document

   *  changed naming of registrar certificate from LDevID(RegAgt) to
      Registrar-Agent EE certificate throughout the document

   *  change x5b to x5bag according to [RFC9360]

   *  updated JSON examples -> "signature": BASE64URL(JWS Signature)

   From IETF draft 08 -> IETF draft 09:

   *  issue #80, enhanced Section 6.1.2 with clarification on the
      product-serial-number and the inclusion of GRASP

   *  issue #81, enhanced introduction with motivation for
      agent_signed_data

   *  issue #82, included optional TLS protection of the communication
      link between Registrar-Agent and pledge in the introduction
      Section 4, and Section 7.1

   *  issue #83, enhanced Section 7.2 and Section 7.3 with note to re-
      enrollment

   *  issue #87, clarified available information at the Registrar-Agent
      in Section 7.1

   *  issue #88, clarified, that the PVR in Section 7.1 and PER in
      Section 7.2 may contain the certificate chain.  If not contained
      it MUST be available at the registrar.

   *  issue #91, clarified that a separate HTTP connection may also be
      used to provide the PER in Section 7.4





Fries, et al.            Expires 5 December 2025              [Page 112]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  resolved remaining editorial issues discovered after WGLC
      (responded to on the mailing list in Reply 1 and Reply 2)
      resulting in more consistent descriptions

   *  issue #92: kept separate endpoint for wrapped CSR on registrar
      Section 7.5

   *  issue #94: clarified terminology (possess vs. obtained)

   *  issue #95: clarified optional IDevID CA certificates on Registrar-
      Agent

   *  issue #96: updated exchangesfig_uc2_3 to correct to just one CA
      certificate provisioning

   *  issue #97: deleted format explanation in exchanges_uc2_3 as it may
      be misleading

   *  issue #99: motivated verification of second signature on voucher
      in Section 7.6

   *  issue #100: included negative example in Figure 33

   *  issue #101: included handling if Section 7.6 voucher telemetry
      information has not been received by the Registrar-Agent

   *  issue #102: relaxed requirements for CA certs provisioning in
      Section 7.7

   *  issue #105: included negative example in Figure 39

   *  issue #107: included example for certificate revocation in
      Section 7.10

   *  issue #108: renamed heading to Pledge-Status Request of
      Section 7.11

   *  issue #111: included pledge-status response processing for
      authenticated requests in Section 7.11

   *  issue #112: added "Example key word in pledge-status response in
      Figure 50

   *  issue #113: enhanced description of status reply for "factory-
      default" in Section 7.11

   *  issue #114: Consideration of optional TLS usage in Privacy
      Considerations



Fries, et al.            Expires 5 December 2025              [Page 113]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  issue #115: Consideration of optional TLS usage in Privacy
      Considerations to protect potentially privacy related information
      in the bootstrapping like status information, etc.

   *  issue #116: Enhanced DoS description and mitigation options in
      security consideration section

   *  updated references

   From IETF draft 07 -> IETF draft 08:

   *  resolved editorial issues discovered after WGLC (still open issues
      remaining)

   *  resolved first comments from the Shepherd review as discussed in
      PR #85 on the ANIMA github

   From IETF draft 06 -> IETF draft 07:

   *  WGLC resulted in a removal of the voucher enhancements completely
      from this document to RFC 8366bis, containing all enhancements and
      augmentations of the voucher, including the voucher-request as
      well as the tree diagrams

   *  smaller editorial corrections

   From IETF draft 05 -> IETF draft 06:

   *  Update of list of reviewers

   *  Issue #67, shortened the pledge endpoints to prepare for
      constraint deployments

   *  Included table for new endpoints on the registrar in the overview
      of the Registrar-Agent

   *  addressed review comments from SECDIR early review (terminology
      clarifications, editorial improvements)

   *  addressed review comments from IOTDIR early review (terminology
      clarifications, editorial improvements)

   From IETF draft 04 -> IETF draft 05:

   *  Restructured document to have a distinct section for the object
      flow and handling and shortened introduction, issue #72





Fries, et al.            Expires 5 December 2025              [Page 114]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Added security considerations for using mDNS without a specific
      product-serial-number, issue #75

   *  Clarified pledge-status responses are cumulative, issue #73

   *  Removed agent-sign-cert from trigger data to save bandwidth and
      remove complexity through options, issue #70

   *  Changed terminology for LDevID(Reg) certificate to registrar
      LDevID certificate, as it does not need to be an LDevID, issue #66

   *  Added new protected header parameter (created-on) in PER to
      support freshness validation, issue #63

   *  Removed reference to CAB Forum as not needed for BRSKI-PRM
      specifically, issue #65

   *  Enhanced error codes in section 5.5.1, issue #39, #64

   *  Enhanced security considerations and privacy considerations, issue
      #59

   *  Issue #50 addressed by referring to the utilized enrollment
      protocol

   *  Issue #47 MASA verification of LDevID(RegAgt) to the same
      registrar LDevID certificate domain CA

   *  Reworked terminology of "enrollment object", "certification
      object", "enrollment request object", etc., issue #27

   *  Reworked all message representations to align with encoding

   *  Added explanation of MASA requiring domain CA cert in section
      5.5.1 and section 5.5.2, issue #36

   *  Defined new endpoint for pledge bootstrapping status inquiry,
      issue #35 in section Section 7.11, IANA considerations and section
      Section 6.2

   *  Included examples for several objects in section Appendix A
      including message example sizes, issue #33

   *  PoP for private key to registrar certificate included as
      mandatory, issues #32 and #49

   *  Issue #31, clarified that combined pledge may act as client/server
      for further (re)enrollment



Fries, et al.            Expires 5 December 2025              [Page 115]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Issue #42, clarified that Registrar needs to verify the status
      responses with and ensure that they match the audit log response
      from the MASA, otherwise it needs drop the pledge and revoke the
      certificate

   *  Issue #43, clarified that the pledge shall use the create time
      from the trigger message if the time has not been synchronized,
      yet.

   *  Several editorial changes and enhancements to increasing
      readability.

   From IETF draft 03 -> IETF draft 04:

   *  In deep Review by Esko Dijk lead to issues #22-#61, which are bein
      stepwise integrated

   *  Simplified YANG definition by augmenting the voucher-request from
      RFC 8995 instead of redefining it.

   *  Added explanation for terminology "endpoint" used in this
      document, issue #16

   *  Added clarification that Registrar-Agent may collect PVR or PER or
      both in one run, issue #17

   *  Added a statement that nonceless voucher may be accepted, issue
      #18

   *  Simplified structure in section Section 3.1, issue #19

   *  Removed join proxy in Figure 1 and added explanatory text, issue
      #20

   *  Added description of pledge-CAcerts endpoint plus further handling
      of providing a wrapped CA certs response to the pledge in section
      Section 7.7; also added new required registrar endpoint (section
      Section 7.3 and IANA considerations) for the registrar to provide
      a wrapped CA certs response, issue #21

   *  utilized defined abbreviations in the document consistently, issue
      #22

   *  Reworked text on discovery according to issue #23 to clarify scope
      and handling

   *  Added several clarifications based on review comments




Fries, et al.            Expires 5 December 2025              [Page 116]

Internet-Draft                  BRSKI-PRM                      June 2025


   From IETF draft 02 -> IETF draft 03:

   *  Updated examples to state "base64encodedvalue==" for x5c
      occurrences

   *  Include link to SVG graphic as general overview

   *  Restructuring of section 5 to flatten hierarchy

   *  Enhanced requirements and motivation in Section 4

   *  Several editorial improvements based on review comments

   From IETF draft 01 -> IETF draft 02:

   *  Issue #15 included additional signature on voucher from registrar
      in section Section 7.3 and section Section 5.4 The verification of
      multiple signatures is described in section Section 7.6

   *  Included representation for General JWS JSON Serialization for
      examples

   *  Included error responses from pledge if it is not able to create a
      Pledge-Voucher-Request or an enrollment request in section
      Section 7.1

   *  Removed open issue regarding handling of multiple CSRs and Enroll-
      Responses during the bootstrapping as the initial target it the
      provisioning of a generic LDevID certificate.  The defined
      endpoint on the pledge may also be used for management of further
      certificates.

   From IETF draft 00 -> IETF draft 01:

   *  Issue #15 lead to the inclusion of an option for an additional
      signature of the registrar on the voucher received from the MASA
      before forwarding to the Registrar-Agent to support verification
      of POP of the registrars private key in section Section 7.3 and
      exchanges_uc2_3.

   *  Based on issue #11, a new endpoint was defined for the registrar
      to enable delivery of the wrapped enrollment request from the
      pledge (in contrast to plain PKCS#10 in simple enroll).








Fries, et al.            Expires 5 December 2025              [Page 117]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Decision on issue #8 to not provide an additional signature on the
      enrollment-response object by the registrar.  As the Enroll-
      Response will only contain the generic LDevID certificate.  This
      credential builds the base for further configuration outside the
      initial enrollment.

   *  Decision on issue #7 to not support multiple CSRs during the
      bootstrapping, as based on the generic LDevID certificate the
      pledge may enroll for further certificates.

   *  Closed open issue #5 regarding verification of ietf-ztp-types
      usage as verified via a proof-of-concept in section Section 7.1.

   *  Housekeeping: Removed already addressed open issues stated in the
      draft directly.

   *  Reworked text in from introduction to section pledge-responder-
      mode

   *  Fixed "serial-number" encoding in PVR/RVR

   *  Added prior-signed-voucher-request in the parameter description of
      the registrar-voucher-request in Section 7.3.

   *  Note added in Section 7.3 if sub-CAs are used, that the
      corresponding information is to be provided to the MASA.

   *  Inclusion of limitation section (pledge sleeps and needs to be
      waked up.  Pledge is awake but Registrar-Agent is not available)
      (Issue #10).

   *  Assertion-type aligned with voucher in RFC8366bis, deleted related
      open issues.  (Issue #4)

   *  Included table for endpoints in Section 6.2 for better
      readability.

   *  Included registrar authorization check for Registrar-Agent during
      TLS handshake in section Section 7.3.  Also enhanced figure
      Figure 4 with the authorization step on TLS level.

   *  Enhanced description of registrar authorization check for
      Registrar-Agent based on the agent-signed-data in section
      Section 7.3.  Also enhanced figure Figure 4 with the authorization
      step on Pledge-Voucher-Request level.






Fries, et al.            Expires 5 December 2025              [Page 118]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Changed agent-signed-cert to an array to allow for providing
      further certificate information like the issuing CA cert for the
      LDevID(RegAgt) certificate in case the registrar and the
      Registrar-Agent have different issuing CAs in Figure 4 (issue
      #12).  This also required changes in the YANG module in
      [I-D.ietf-anima-rfc8366bis]

   *  Addressed YANG warning (issue #1)

   *  Inclusion of examples for a trigger to create a Pledge-Voucher-
      Request and a Pledge Enroll-Request.

   From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski-
   prm-00:

   *  Moved UC2 related parts defining the Pledge in Responder Mode from
      draft-ietf-anima-brski-async-enroll-03 to this document This
      required changes and adaptations in several sections to remove the
      description and references to UC1.

   *  Addressed feedback for voucher-request enhancements from YANG
      doctor early review, meanwhile moved to
      [I-D.ietf-anima-rfc8366bis] as well as in the security
      considerations (formerly named ietf-async-voucher-request).

   *  Renamed ietf-async-voucher-request to IETF-voucher-request-prm to
      to allow better listing of voucher related extensions; aligned
      with constraint voucher (#20)

   *  Utilized ietf-voucher-request-async instead of ietf-voucher-
      request in voucher exchanges to utilize the enhanced voucher-
      request.

   *  Included changes from draft-ietf-netconf-sztp-csr-06 regarding the
      YANG definition of csr-types into the enrollment request exchange.

   From IETF draft 02 -> IETF draft 03:

   *  Housekeeping, deleted open issue regarding YANG voucher-request in
      Section 7.1 as voucher-request was enhanced with additional leaf.

   *  Included open issues in YANG model in Section 5 regarding
      assertion value agent-proximity and csr encapsulation using SZTP
      sub module).

   From IETF draft 01 -> IETF draft 02:





Fries, et al.            Expires 5 December 2025              [Page 119]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Defined call flow and objects for interactions in UC2.  Object
      format based on draft for JOSE signed voucher artifacts and
      aligned the remaining objects with this approach in Section 7.

   *  Terminology change: issue #2 pledge-agent -> Registrar-Agent to
      better underline Registrar-Agent relation.

   *  Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
      and pledge-responder-mode to better address the pledge operation.

   *  Communication approach between pledge and Registrar-Agent changed
      by removing TLS-PSK (former section TLS establishment) and
      associated references to other drafts in favor of relying on
      higher layer exchange of signed data objects.  These data objects
      are included also in the Pledge-Voucher-Request and lead to an
      extension of the YANG module for the voucher-request (issue #12).

   *  Details on trust relationship between Registrar-Agent and
      registrar (issue #4, #5, #9) included in Section 5.

   *  Recommendation regarding short-lived certificates for Registrar-
      Agent authentication towards registrar (issue #7) in the security
      considerations.

   *  Introduction of reference to Registrar-Agent signing certificate
      using SubjectKeyIdentifier in Registrar-Agent signed data (issue
      #37).

   *  Enhanced objects in exchanges between pledge and Registrar-Agent
      to allow the registrar to verify agent-proximity to the pledge
      (issue #1) in Section 7.

   *  Details on trust relationship between Registrar-Agent and pledge
      (issue #5) included in Section 5.

   *  Split of use case 2 call flow into sub sections in Section 7.

   From IETF draft 00 -> IETF draft 01:

   *  Update of scope in Section 3.1 to include in which the pledge acts
      as a server.  This is one main motivation for use case 2.

   *  Rework of use case 2 in Section 5 to consider the transport
      between the pledge and the pledge-agent.  Addressed is the TLS
      channel establishment between the pledge-agent and the pledge as
      well as the endpoint definition on the pledge.

   *  First description of exchanged object types (needs more work)



Fries, et al.            Expires 5 December 2025              [Page 120]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Clarification in discovery options for enrollment endpoints at the
      domain registrar based on well-known endpoints do not result in
      additional /.well-known URIs.  Update of the illustrative example.
      Note that the change to /brski for the voucher related endpoints
      has been taken over in the BRSKI main document.

   *  Updated references.

   *  Included Thomas Werner as additional author for the document.

   From individual version 03 -> IETF draft 00:

   *  Inclusion of discovery options of enrollment endpoints at the
      domain registrar based on well-known endpoints in new section as
      replacement of section 5.1.3 in the individual draft.  This is
      intended to support both use cases in the document.  An
      illustrative example is provided.

   *  Missing details provided for the description and call flow in
      pledge-agent use case Section 5, e.g. to accommodate distribution
      of CA certificates.

   *  Updated CMP example in to use lightweight CMP instead of CMP, as
      the draft already provides the necessary /.well-known endpoints.

   *  Requirements discussion moved to separate section in Section 4.
      Shortened description of proof of identity binding and mapping to
      existing protocols.

   *  Removal of copied call flows for voucher exchange and registrar
      discovery flow from [RFC8995] in UC1 to avoid doubling or text or
      inconsistencies.

   *  Reworked abstract and introduction to be more crisp regarding the
      targeted solution.  Several structural changes in the document to
      have a better distinction between requirements, use case
      description, and solution description as separate sections.
      History moved to appendix.

   From individual version 02 -> 03:

   *  Update of terminology from self-contained to authenticated self-
      contained object to be consistent in the wording and to underline
      the protection of the object with an existing credential.  Note
      that the naming of this object may be discussed.  An alternative
      name may be attestation object.





Fries, et al.            Expires 5 December 2025              [Page 121]

Internet-Draft                  BRSKI-PRM                      June 2025


   *  Simplification of the architecture approach for the initial use
      case having an offsite PKI.

   *  Introduction of a new use case utilizing authenticated self-
      contain objects to onboard a pledge using a commissioning tool
      containing a pledge-agent.  This requires additional changes in
      the BRSKI call flow sequence and led to changes in the
      introduction, the application example,and also in the related
      BRSKI-PRM call flow.

   From individual version 01 -> 02:

   *  Update of introduction text to clearly relate to the usage of
      IDevID and LDevID.

   *  Update of description of architecture elements and changes to
      BRSKI in Section 5.

   *  Enhanced consideration of existing enrollment protocols in the
      context of mapping the requirements to existing solutions in
      Section 4.

   From individual version 00 -> 01:

   *  Update of examples, specifically for building automation as well
      as two new application use cases in Section 3.1.

   *  Deletion of asynchronous interaction with MASA to not complicate
      the use case.  Note that the voucher exchange can already be
      handled in an asynchronous manner and is therefore not considered
      further.  This resulted in removal of the alternative path the
      MASA in Figure 1 and the associated description in Section 5.

   *  Enhancement of description of architecture elements and changes to
      BRSKI in Section 5.

   *  Consideration of existing enrollment protocols in the context of
      mapping the requirements to existing solutions in Section 4.

   *  New section starting with the mapping to existing enrollment
      protocols by collecting boundary conditions.

Contributors

   Esko Dijk
   IoTconsultancy.nl
   Email: esko.dijk@iotconsultancy.nl




Fries, et al.            Expires 5 December 2025              [Page 122]

Internet-Draft                  BRSKI-PRM                      June 2025


   Toerless Eckert
   Futurewei
   Email: tte@cs.fau.de


   Matthias Kovatsch
   Siemens Schweiz AG
   Email: ietf@kovatsch.net


Authors' Addresses

   Steffen Fries
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   Email: steffen.fries@siemens.com
   URI:   https://www.siemens.com/


   Thomas Werner
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   Email: thomas-werner@siemens.com
   URI:   https://www.siemens.com/


   Eliot Lear
   Cisco Systems
   Richtistrasse 7
   CH-8304 Wallisellen
   Switzerland
   Phone: +41 44 878 9200
   Email: lear@cisco.com


   Michael C. Richardson
   Sandelman Software Works
   Email: mcr+ietf@sandelman.ca
   URI:   http://www.sandelman.ca/








Fries, et al.            Expires 5 December 2025              [Page 123]


