# drafts

name: draft-li-zt-consideration
rev: 03
title: Consideration of Applying Zero Trust Philosophy in Network Infrastructure
time: 2026-01-15T07:33:27Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-19T07:33:27Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T13:09:22.637382+00:00
source: ietf
abstract:
  Network security has traditionally relied on a perimeter-centric
     model, assuming that traffic originating within the network can be
     implicitly trusted.  This model is fundamentally challenged by
     modern, highly distributed, and software-driven network environments
     where internal compromise is a realistic and high-impact threat
     scenario.  This document examines the critical limitations of edge-
     only network protection and the systemic risks that arise from
     insufficient internal validation.  Once the network perimeter is
     bypassed, the absence of internal protection mechanisms facilitates
     rapid lateral movement, impersonation of network entities, and
     interference with critical control and management functions.

     The document argues that Zero Trust (ZT) principles, which mandate
     continuous, dynamic verification of all entities and communications
     regardless of network location, are necessary to address contemporary
     threat models.  Deploying ZT-aligned network protection mechanisms
     beyond the network edge is essential to build resilient,
     controllable, and trustworthy networks.

full_text:
  Zero Trust Working Group                                           X. Li
  Internet-Draft                                                   A. Wang
  Intended status: Informational                                   J. Chen
  Expires: 19 July 2026                                              W. Li
                                                             China Telecom
                                                           15 January 2026


         Consideration of Applying Zero Trust Philosophy in Network
                               Infrastructure
                        draft-li-zt-consideration-03

  Abstract

     Network security has traditionally relied on a perimeter-centric
     model, assuming that traffic originating within the network can be
     implicitly trusted.  This model is fundamentally challenged by
     modern, highly distributed, and software-driven network environments
     where internal compromise is a realistic and high-impact threat
     scenario.  This document examines the critical limitations of edge-
     only network protection and the systemic risks that arise from
     insufficient internal validation.  Once the network perimeter is
     bypassed, the absence of internal protection mechanisms facilitates
     rapid lateral movement, impersonation of network entities, and
     interference with critical control and management functions.

     The document argues that Zero Trust (ZT) principles, which mandate
     continuous, dynamic verification of all entities and communications
     regardless of network location, are necessary to address contemporary
     threat models.  Deploying ZT-aligned network protection mechanisms
     beyond the network edge is essential to build resilient,
     controllable, and trustworthy networks.

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




  Li, et al.                Expires 19 July 2026                  [Page 1]


  Internet-Draft              zt-consideration                January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions used in this document . . . . . . . . . . . . . .   3
     3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Current State of Network Protection . . . . . . . . . . . . .   4
     5.  Risks of the Perimeter-Centric Model  . . . . . . . . . . . .   4
       5.1.  Data Plane Risks: Unrestricted Lateral Movement . . . . .   4
       5.2.  Control Plane Risks: Integrity Exposure . . . . . . . . .   5
       5.3.  Management Plane Risks: API and Orchestration
             Vulnerability . . . . . . . . . . . . . . . . . . . . . .   5
     6.  Necessity of Zero Trust Deployment Within the Network . . . .   5
     7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   7
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
       11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
       11.2.  Informative References . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Traditional network security architectures in operator and enterprise
     environments have long been built around a perimeter-centric
     protection model.  In this model, security mechanisms are primarily
     deployed at network edges—such as access networks [RFC2827], inter-
     domain boundaries, or gateway nodes—under the core assumption that
     traffic originating inside the network can be inherently trusted once
     it passes the perimeter.  This assumption of Implicit Trust reflected
     earlier network environments in which infrastructures were relatively
     static, tightly controlled, and operational roles were clearly



  Li, et al.                Expires 19 July 2026                  [Page 2]


  Internet-Draft              zt-consideration                January 2026


     separated.  In such contexts, perimeter-based protection provided a
     reasonable balance between security and operational complexity.

     Modern networks, however, have evolved into highly distributed,
     virtualized, and software-driven systems.  Automated orchestration,
     programmable control planes [RFC7426], open management interfaces,
     and closed-loop control systems significantly expand the internal
     attack surface and increase the potential impact of internal failures
     or compromise.  As a result, threats originating from within the
     network can no longer be treated as exceptional or out of scope.  The
     reliance on Implicit Trust within the network creates a structural
     mismatch between the threat environment and deployed protection
     mechanisms.

     This document examines the limitations of the perimeter-centric model
     and the necessity of applying Zero Trust principles to network
     protection itself.  Zero Trust rejects trust based on network
     location and emphasizes continuous verification of entities and
     communications.  Applying these principles within the network enables
     more robust containment of compromise and improved resilience of
     network operations.

  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 RFC 2119 [RFC2119] .

  3.  Terminology

     The following terms are defined in this document:

     *  ZTA: Zero Trust Architecture.  An evolving set of cybersecurity
        paradigms that move defenses from static, network-based perimeters
        to focus on users, assets, and resources.

     *  Implicit Trust: The assumption that an entity (user, device,
        traffic flow) is trustworthy solely because of its network
        location (e.g., being inside the network perimeter).

     *  Lateral Movement: The technique used by attackers to progressively
        move deeper into a network from an initial point of compromise,
        often by exploiting Implicit Trust.








  Li, et al.                Expires 19 July 2026                  [Page 3]


  Internet-Draft              zt-consideration                January 2026


  4.  Current State of Network Protection

     In today’s operational networks, the dominant security paradigm
     remains perimeter-centric.  Most protection mechanisms are
     concentrated at the network boundary, reflecting the historical
     assumption of Implicit Trust for internal traffic.  Common practices
     include:

     *  Traffic filtering, access control, and anomaly detection primarily
        enforced at ingress or egress points.[RFC2827]

     *  Security inspection and policy enforcement focused on customer-
        facing interfaces and inter-domain links.

     *  Limited or coarse-grained security controls within the internal
        network, where routers, switches, virtualized network functions,
        and control systems are often treated as mutually trusted.

     This architectural approach originated in an era when networks were
     relatively static and infrastructure components were physically
     isolated.  Under such conditions, deploying strong security controls
     only at the boundary was often sufficient and operationally
     efficient.  However, the shift to virtualized, cloud-native, and
     software-driven networks has rendered this model increasingly
     fragile.

  5.  Risks of the Perimeter-Centric Model

     A security architecture that relies primarily on edge-based
     protection exhibits a critical weakness: once the perimeter is
     breached, the internal network is left largely unprotected.  This
     creates a "hard shell, soft interior" structure, leading to systemic
     risks across the network planes.

  5.1.  Data Plane Risks: Unrestricted Lateral Movement

     The core risk is the unrestricted lateral movement of an attacker who
     gains an initial foothold inside the network.  Because internal
     traffic is subject to minimal verification, a compromised node can
     move across internal segments with limited resistance, accessing
     additional systems and services.  Furthermore, the lack of internal
     validation mechanisms means that compromised nodes can easily
     impersonate other network elements or services, undermining trust
     relationships within the network.  While edge-based mechanisms
     address external spoofing, they do not prevent a compromised internal
     entity from spoofing other internal entities.





  Li, et al.                Expires 19 July 2026                  [Page 4]


  Internet-Draft              zt-consideration                January 2026


  5.2.  Control Plane Risks: Integrity Exposure

     Internal control protocols (e.g., routing, signaling) and management
     interfaces are often designed with the assumption of Implicit Trust.
     This exposure is critical because:

     *  Control protocols may accept unauthenticated or insufficiently
        verified traffic, enabling disruption or manipulation of network
        operations (e.g., malicious routing updates).

     *  In automated and intelligent networks, incorrect or malicious
        internal signals can trigger large-scale misconfigurations or
        service disruptions, as autonomous control loops amplify the
        original compromise.

  5.3.  Management Plane Risks: API and Orchestration Vulnerability

     Modern networks rely heavily on open APIs, software-defined
     networking (SDN) controllers [RFC7426], and automated orchestration
     systems.  These systems manage the entire network state, making them
     high-value targets for attackers.  If an attacker gains access to the
     management plane through a compromised internal entity, they can
     leverage the Implicit Trust to execute high-impact actions, such as
     reconfiguring security policies, redirecting traffic, or disabling
     critical network functions.

     A critical gap in management plane security for core routers and
     critical infrastructure lies in the absence of unified standards.
     Key security data lacks consistent definition and format, with no
     universal benchmarks for detection items or protection mechanisms.
     Collected data, detection alerts and result data also lack a unified
     exchange protocol, leading to insecure or inconsistent transmission.
     These gaps create security blind spots, enabling undetected
     intrusions and lateral movement that threaten core network stability
     under the Implicit Trust model.

  6.  Necessity of Zero Trust Deployment Within the Network

     Zero Trust (ZT) principles address these challenges by eliminating
     Implicit Trust and requiring continuous, dynamic verification across
     the entire network.  Trust is never implicit and must be continuously
     reassessed based on identity, context, and behavior.  This approach
     is necessary for network protection for several reasons:

     *  Elimination of Trust-by-Location: Network nodes and traffic are no
        longer trusted solely because they originate from internal
        segments, forcing explicit authentication and authorization for
        all interactions.



  Li, et al.                Expires 19 July 2026                  [Page 5]


  Internet-Draft              zt-consideration                January 2026


     *  Containment of Compromise: Security enforcement at multiple
        internal points limits the "blast radius" of a compromised
        component and restricts lateral movement, transforming the network
        from a soft interior to a segmented, hardened structure.

     *  Improved Integrity of Control and Management Functions: Continuous
        verification helps ensure that routing, orchestration, and
        monitoring systems operate on trustworthy inputs, which is vital
        for the stability of automated network operations.

     *  Resilience and Compliance: ZT provides a framework for building
        networks that are inherently more resilient to internal threats
        and better aligned with modern security compliance mandates.

     Applying Zero Trust to network protection implies that internal
     communications, forwarding behaviors, and control interactions must
     be subject to security enforcement similar to that applied at the
     perimeter.  This requires the development of network mechanisms that
     can enforce policy based on identity and context, rather than just
     network address and location.

  7.  Conclusion

     The evolution of network architectures and threat models has rendered
     traditional edge-only security approaches insufficient.  While
     perimeter defenses remain necessary, they are no longer adequate on
     their own.  A breach at the boundary can expose the internal network
     to rapid and wide-ranging compromise.  Adopting Zero Trust principles
     within the network is therefore not optional, but essential.  By
     shifting from static, perimeter-based trust to dynamic, continuous
     verification across all network segments, operators can build more
     resilient, controllable, and trustworthy networks.  Zero Trust-
     aligned network protection transforms security from a boundary
     function into an intrinsic property of the network itself, better
     suited to the demands of modern and future network environments.

  8.  Security Considerations

     This document is a Problem Statement and does not propose a solution.
     However, the deployment of Zero Trust principles within the network
     introduces its own set of security and operational considerations
     that must be addressed by any future solution.  These include:

     *  Performance Overhead: Continuous verification and policy
        enforcement at multiple internal points may introduce latency and
        performance overhead to the data plane.





  Li, et al.                Expires 19 July 2026                  [Page 6]


  Internet-Draft              zt-consideration                January 2026


     *  Reliability and Availability: The Policy Decision Point (PDP) and
        Policy Enforcement Point (PEP) components of a ZT architecture
        represent critical infrastructure.  Their failure could lead to
        network disruption or denial of service.

     *  Policy Complexity: Managing fine-grained, dynamic policies across
        a large, distributed network is complex and requires robust
        automation and orchestration to avoid misconfiguration and policy
        conflicts.

  9.  IANA Considerations

     TBD

  10.  Acknowledgement

     TBD

  11.  References

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

     [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
                Defeating Denial of Service Attacks which employ IP Source
                Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
                May 2000, <https://www.rfc-editor.org/info/rfc2827>.

     [RFC7426]  Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
                Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
                Defined Networking (SDN): Layers and Architecture
                Terminology", RFC 7426, DOI 10.17487/RFC7426, January
                2015, <https://www.rfc-editor.org/info/rfc7426>.

  11.2.  Informative References

  Authors' Addresses

     Xueting Li
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China



  Li, et al.                Expires 19 July 2026                  [Page 7]


  Internet-Draft              zt-consideration                January 2026


     Email: lixt2@foxmail.com


     Aijun Wang
     China Telecom
     Beiqijia Town, Changping District
     Beijing
     Beijing, 102209
     China
     Email: wangaj3@chinatelecom.cn


     Jie Chen
     China Telecom
     Zhongshan Avenue, Tianhe District
     Guangzhou
     Guangzhou, 510600
     China
     Email: chenj135@chinatelecom.cn


     Wenhao Li
     China Telecom
     Zhongshan Avenue, Tianhe District
     Guangzhou
     Guangzhou, 510600
     China
     Email: liwh21@chinatelecom.cn























  Li, et al.                Expires 19 July 2026                  [Page 8]


name: draft-li-sidrops-drr-architecture
rev: 01
title: Decentralized RPKI Repository Architecture
time: 2026-01-06T10:01:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T10:01:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:22.640536+00:00
source: ietf
abstract:
  The Resource Public Key Infrastructure (RPKI) plays a crucial role in
     securing inter-domain routing.  However, the current RPKI Repository
     system suffers from fundamental limitations in reliability,
     scalability, and consistency.  In particular, single-point failures
     at repository publication points (PPs), the growing number of
     bidirectional connections between PPs and relying parties (RPs), and
     the lack of a globally consistent historical RPKI data view pose
     significant risks to the resilience, integrity, and authority of the
     global RPKI ecosystem.

     This document proposes the Decentralized RPKI Repository (dRR), a
     novel repository architecture that decouples RPKI object signing
     authority from RPKI object management authority (e.g., storage and
     distribution). dRR introduces a distributed group of certificate
     servers (CSs) and a layer of Monitors to achieve robust, scalable,
     and auditable RPKI data management.  The architecture maintains full
     compatibility with the existing RPKI trust model rooted in the five
     RIR trust anchors, enabling incremental deployment without disrupting
     current relying parties (RPs) validation semantics.  By doing so, dRR
     addresses longstanding repository challenges and enhances the overall
     efficiency and trustworthiness of RPKI-based routing security.

full_text:
  sidrops                                                            D. Li
  Internet-Draft                                       Tsinghua University
  Intended status: Standards Track                                   Y. Su
  Expires: 10 July 2026                                            L. Chen
                                                   Zhongguancun Laboratory
                                                            6 January 2026


                 Decentralized RPKI Repository Architecture
                    draft-li-sidrops-drr-architecture-01

  Abstract

     The Resource Public Key Infrastructure (RPKI) plays a crucial role in
     securing inter-domain routing.  However, the current RPKI Repository
     system suffers from fundamental limitations in reliability,
     scalability, and consistency.  In particular, single-point failures
     at repository publication points (PPs), the growing number of
     bidirectional connections between PPs and relying parties (RPs), and
     the lack of a globally consistent historical RPKI data view pose
     significant risks to the resilience, integrity, and authority of the
     global RPKI ecosystem.

     This document proposes the Decentralized RPKI Repository (dRR), a
     novel repository architecture that decouples RPKI object signing
     authority from RPKI object management authority (e.g., storage and
     distribution). dRR introduces a distributed group of certificate
     servers (CSs) and a layer of Monitors to achieve robust, scalable,
     and auditable RPKI data management.  The architecture maintains full
     compatibility with the existing RPKI trust model rooted in the five
     RIR trust anchors, enabling incremental deployment without disrupting
     current relying parties (RPs) validation semantics.  By doing so, dRR
     addresses longstanding repository challenges and enhances the overall
     efficiency and trustworthiness of RPKI-based routing security.

  Status of This Memo

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

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







  Li, et al.                Expires 10 July 2026                  [Page 1]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
     2.  Terminology and Definitions . . . . . . . . . . . . . . . . .   4
     3.  Design Principles and Objectives  . . . . . . . . . . . . . .   5
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Key Components  . . . . . . . . . . . . . . . . . . . . .   6
         4.1.1.  Certificate Server Group  . . . . . . . . . . . . . .   6
         4.1.2.  Middleware Monitors . . . . . . . . . . . . . . . . .   7
         4.1.3.  Key Differences from the Current System . . . . . . .   7
       4.2.  CS Group Construction . . . . . . . . . . . . . . . . . .   8
       4.3.  CS Group Operation  . . . . . . . . . . . . . . . . . . .  10
         4.3.1.  Publication of New Objects  . . . . . . . . . . . . .  10
         4.3.2.  Revocation of Existing Objects  . . . . . . . . . . .  11
       4.4.  Monitor Operation . . . . . . . . . . . . . . . . . . . .  11
     5.  dRR Operation Procedures  . . . . . . . . . . . . . . . . . .  12
       5.1.  Publication and Synchronization . . . . . . . . . . . . .  12
       5.2.  Revocation and Synchronization  . . . . . . . . . . . . .  13
     6.  dRR Participants and Roles  . . . . . . . . . . . . . . . . .  15
     7.  Benefits and Improvements . . . . . . . . . . . . . . . . . .  16
     8.  Deployment Considerations . . . . . . . . . . . . . . . . . .  17
     9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  18
       11.2.  Informative References . . . . . . . . . . . . . . . . .  19



  Li, et al.                Expires 10 July 2026                  [Page 2]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

  1.  Introduction

     The Resource Public Key Infrastructure has become a cornerstone for
     securing inter-domain routing, providing mechanisms to validate the
     association between Internet number resources (INR) and the entities
     authorized to originate them.  While RPKI has proven effective in
     mitigating certain types of BGP hijacks, the current repository
     system exhibits critical architectural shortcomings.

     In particular, the coupling between repository PPs and certification
     authorities (CAs) results in three fundamental challenges.  First,
     the system is prone to reliability issues: a failure or attack on any
     PP may prevent RPs from obtaining a complete or timely RPKI data
     view.  Second, the existing model lacks scalability, as the
     anticipated growth in the number of PPs and RPs—driven by broader
     deployment of ROAs and ROV—exacerbates synchronization load and
     connection overhead.  Third, the current architecture cannot
     guarantee the consistency and integrity of the RPKI data retrieved by
     RPs.  Maintaining a consistent and complete RPKI data view helps
     improve the accuracy of ROV, facilitates misconfiguration diagnosis,
     and enhances RPKI system's transparency.  These issues are discussed
     in detail in [rpki-repo-ps].

     To address these concerns, this document introduces the Decentralized
     RPKI Repository (dRR), which extends and enhances the existing RPKI
     repository architecture. dRR is founded on the principle of
     decoupling RPKI object signing from data management.  It replaces
     traditional PP-based storage with a distributed and decentralized
     group of certificate servers (CSs), each CS operating as an equal
     peer that collaboratively hosts RPKI data.  INR holders can
     proactively upload their RPKI objects to any trusted CSs within this
     group, thereby retaining greater operational control.

     Additionally, dRR incorporates Monitors as middleware components that
     aggregate updates from the CS group and proactively distribute RPKI
     data to RPs.  This design reduces the number of direct connections
     between RPs and repository nodes and improves both the scalability
     and timeliness of RPKI data distribution.

     Through this architecture, dRR aims to enhance the robustness,
     scalability, and consistency of the global RPKI system while
     preserving compatibility with existing hierarchical trust anchors and
     RPKI data validation processes.






  Li, et al.                Expires 10 July 2026                  [Page 3]


  Internet-Draft  Decentralized RPKI Repository Architectu    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.  Terminology and Definitions

     This document assumes familiarity with the concepts described in "A
     Profile for Resource Certificate Repository Structure" [RFC6481],
     "The RPKI Repository Delta Protocol (RRDP)" [RFC8182], and "An
     Infrastructure to Support Secure Internet Routing" [RFC6480].

     This document defines the following terminology:

     *Decentralized RPKI Repository (dRR):* The new RPKI repository
     architecture proposed in this document. dRR consists of multiple
     Certificate Servers (CSs) that collaboratively store and distribute
     RPKI data, along with Monitors that act as middleware between the CS
     group and RPs.

     *Certificate Server (CS):* A core component of the dRR system.  A CS
     is a node responsible for hosting RPKI objects.  All CS nodes within
     dRR collectively form a group.

     *Monitor:* Represents a key middleware component in dRR that sits
     between CS nodes and RPs.  A Monitor retrieves RPKI data from CS
     nodes and proactively pushes updates to its connected RPs.

     *Object Issuance Information (OII):* Metadata associated with a newly
     issued RPKI object.  An OII is signed by the CA that issued the
     object and includes the fingerprint of the object along with its
     intended storage locations within the CS nodes.  The OII allows the
     CS members to verify the authenticity of the newly issued RPKI
     object.

     *Object Revocation Information (ORI):* Metadata associated with an
     RPKI object that is to be revoked.  An ORI is signed by the INR
     holder of the object.  It includes the fingerprint of the object to
     be revoked and serves to prove that the impacted party has authorized
     the revocation.  The ORI enables the CS members to verify the
     legitimacy of the revocation.







  Li, et al.                Expires 10 July 2026                  [Page 4]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *Verifiable Update Information (VUI):* Cryptographic metadata
     generated by a Monitor when proactively distributing updates to an
     RP.  A VUI enables the RP to verify both the authenticity and the
     completeness of the received RPKI update data.

     These terms are used throughout this document.

  3.  Design Principles and Objectives

     The design of dRR is guided by two primary principles:

     *  Preserve the existing hierarchical trust model: dRR does not
        modify the hierarchical certificate issuance framework rooted in
        the five RIR trust anchors, which MUST remain the foundational
        basis of the global RPKI trust model.  The roles and trust
        relationships of CAs and INR holders remain unchanged.

     *  Separate data management from data signing: While certificate
        issuance continues to be handled by existing RPKI authorities, the
        storage and distribution of RPKI objects are explicitly delegated
        to INR holders and a decentralized set of infrastructure
        components.  INR holders SHALL maintain direct control over where
        and how their RPKI data is hosted.  RPs MUST continue to perform
        cryptographic validation of all received data, preserving end-to-
        end trust guarantees.

     Building on these principles, the dRR architecture serves exclusively
     as an alternative repository layer.  It provides mechanisms for the
     upload, hosting, and storage of resource certificates (RCs), ROAs,
     and potentially newer signed objects such as autonomous system
     provider authorization (ASPA) and signed prefix list (SPLs).  The
     design paradigm establishes a decentralized RPKI data management
     platform, effectively redefining the boundaries of responsibility
     between RPKI authorities and INR holders.  It also supports both
     incremental and full data synchronization for RPs, thereby fulfilling
     all core repository functions without altering existing validation
     semantics.

     The architecture of dRR is explicitly designed to meet the following
     objectives:

     *  Compatibility: dRR MUST NOT alter the hierarchical RPKI
        certificate issuance architecture.  It SHALL remain fully
        compatible with the current RPKI Repository system and SHALL
        support incremental deployment alongside existing PPs without
        disrupting established validation or synchronization workflows.





  Li, et al.                Expires 10 July 2026                  [Page 5]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *  Reliability: dRR SHALL ensure high availability of RPKI data
        through distributed storage.  A single RPKI object MAY be
        redundantly stored across multiple physically isolated repository
        nodes.  Consequently, the integrity and accessibility of RPKI data
        as consumed by RPs SHALL NOT be compromised even if individual
        nodes experience failures.

     *  Scalability: The dRR architecture SHALL prevent uncontrolled
        growth in the number of repository nodes required to host data.
        It SHOULD enable efficient synchronization mechanisms that ensure
        RPs receive timely updates of RPKI data, regardless of the scale
        of ROA and ROV deployment.

     *  Consistency and Auditability: dRR SHALL maintain a complete and
        consistent historical record of RPKI data and operations, ensuring
        that RPs obtain accurate and consistent RPKI data, thereby
        enhancing system transparency, enabling robust auditing, and
        facilitating misconfiguration diagnosis.

     By adhering to these principles and objectives, dRR aims to enhance
     the reliability, scalability, consistency, and Auditability of the
     RPKI repository layer while ensuring full interoperability with the
     existing RPKI infrastructure.

  4.  Architecture Overview

  4.1.  Key Components

     The dRR architecture replaces the conventional RPKI Repository system
     with two principal components: a *distributed Certificate Server
     group* (CS group) and a layer of *middleware Monitors*.

  4.1.1.  Certificate Server Group

     The CS group consists of multiple independent certificate server
     nodes that collectively host and store RPKI data.  Each CS node
     participates equally in this group and operates under a data sharing
     protocol to maintain a consistent view of hosted RPKI objects and
     object operations.  INR holders MAY upload their RC, ROAs, or other
     signed objects issued by RPKI authorities to any subset of trusted CS
     nodes they choose.

     This decentralized model decouples data storage and management
     responsibilities from certificate signing authorities.  As a result:

     *  INR holders maintain operational control and management over their
        RPKI data.




  Li, et al.                Expires 10 July 2026                  [Page 6]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *  RPKI objects MAY be simultaneously stored across multiple CS
        nodes, improving redundancy and availability.

  4.1.2.  Middleware Monitors

     Monitors act as intermediaries between the CS group and RPs.  Each
     Monitor SHALL:

     *  Receive OII and ORI from the CS group.

     *  Retrieve newly published from the specified CS nodes based on OII.

     *  Generate VUI according OII and ORI, and proactively push both VUI
        and the associated newly added RPKI objects to the RPs it serves.

     *  Maintain a full dRR-protected RPKI data snapshot.

     This two-tier proactive data distribution architecture contrasts with
     the traditional model in which each RP MUST periodically poll
     multiple PPs to obtain updates.  By aggregating and pushing updates,
     Monitors reduce synchronization delays and alleviate load on both the
     repository infrastructure and RPs.

  4.1.3.  Key Differences from the Current System

     Compared to the existing RPKI repository architecture, the key
     differences introduced by dRR include:

     *  Flexible Data Storage: Under dRR, INR holders actively upload
        their RPKI objects to selected CS nodes.  They SHALL have the
        freedom to choose multiple trusted nodes for storing their data.
        By decoupling RPKI object signing authority from data management
        responsibilities, dRR transfers operational control of RPKI data
        directly to the legitimate INR holders.  In contrast, the current
        model requires that data signed by a CA MUST be stored exclusively
        at the PP operated or designated by that CA, which is a single
        point storage model.














  Li, et al.                Expires 10 July 2026                  [Page 7]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *  Two-tier Push Model: dRR introduces a layered proactive
        distribution mechanism.  CS nodes SHALL push OII and ORI and
        cryptographic proofs to a designated set of Mnitors.  Each Monitor
        SHALL then retrieve newly added RPKI data from the specific CS
        nodes according to the OII, and SHALL generate VUI and proactively
        distribute both the VUI and the newly added RPKI objects to its
        designated set of RPs.  In dRR, each CS typically serves a defined
        group of Monitors, and each Monitor, in turn, serves a defined
        group of RPs.  For today’s RPKI Repository, the full set of PPs
        and RPs must establish a large number of bidirectional
        connections, which increases the load and pressure of data
        synchronization.

     *  Consistency of RPKI Data View: In dRR, newly uploaded objects and
        object revocation statements SHALL be publicly disseminated across
        the CS group through OII and ORI.  This process ensures the
        consistency and integrity of the RPKI data view seen by the CS
        node, thereby ensuring the integrity of data view seen by RPs and
        the ROV accuracy.  It also helps to enhance the transparency of
        the system and provide audit functions.  By comparison, existing
        PPs operate in isolation, each maintaining and managing its own
        data view without inter-node validation or transparency.

     The distributed CS group is the core component enabling
     decentralization in dRR.  Each server node participates in a protocol
     to build a cross-domain trust network, thereby forming a data hosting
     platform that operates independently of any single RPKI authority.
     All server nodes function as equal participants, collectively
     providing certificate hosting services to INR holders within the RPKI
     system.  The middleware layer of Monitors acts as the central hub for
     data propagation.  It receives consensus-validated RPKI data and
     associated operations from CS group and, based on a proactive push
     model, delivers new RPKI objects to RPs.

  4.2.  CS Group Construction

     The CS group is comprised of multiple CS nodes.  The following
     principles govern the operation and structure of these nodes:

     a) Each CS operates independently of any RPKI authority.  All CS
     nodes SHALL be equal peers and SHALL collectively form a group to
     provide secure and reliable hosting services for INR holders.

     b) Any entity seeking to join the CS group MUST undergo security
     validation performed by the existing CS group members.






  Li, et al.                Expires 10 July 2026                  [Page 8]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     c) All operations within the group—including the registration of new
     CS nodes, registration of INR holders, publication of RPKI objects,
     and object revocation—MUST achieve consensus among all participating
     CS group members.

     The initialization of the CS group, along with the registration
     mechanisms for CS nodes and INR holders, are described below.

     *  Initialization of the CS group: The initial CS group SHALL be
        established jointly by the five RIRs: RIPE NCC, APNIC, AFRINIC,
        LACNIC, and ARIN.  During initialization, each RIR SHALL register
        its CS node within the group.  The registration information for
        each CS node MUST include: (1) A unique identifier for the CS
        node; (2) The node's unique public key; (3) A digital signature
        generated using the private key corresponding to that public key.

     *  Registration of CS Nodes: Entities that meet the eligibility
        requirements MAY apply to operate RPKI object hosting servers and
        join the CS group.  This process proceeds as follows: (1) The
        applying entity submits its registration information to one of the
        five RIRs; (2) Upon successful completion of identity, security,
        and reliability verification (for example, evaluation of the
        applicant's reputation or its capability to operate on robust
        platforms such as CDNs), the RIR SHALL publish the entity's
        registration information to the CS group; (3) The existing group
        members SHALL validate the identity of the new CS node and verify
        the provided signatures; (4) If a majority of group members
        approve, consensus SHALL be reached and the entity's registration
        information SHALL be permanently recorded in the group's global
        ledger.  The entity SHALL then formally become a member of the CS
        group and MAY provide hosting services to INR holders.  If
        consensus is not achieved, the entity SHALL NOT be admitted into
        the CS group.

     *  Registration of INR Holders.  Any INR holder deploying dRR MUST
        first complete identity registration within the CS group.  The
        process is as follows: (1) The INR holder submits its registration
        information to one trusted CS node; (2) The receiving CS node
        SHALL publish the registration information to the group,
        triggering a validation process by the group members. (3) If a
        majority of members validate the registration successfully, the
        INR holder's information SHALL be recorded in the group's global
        ledger.  If consensus is not achieved, registration SHALL fail.








  Li, et al.                Expires 10 July 2026                  [Page 9]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     It is important to note that any RPKI authority inherently holds an
     RC certificate issued by its parent authority (or, in the case of
     RIRs, a self-issued RC root certificate).  Therefore, for the
     purposes of dRR, an RPKI authority is also treated as an INR holder
     and MUST undergo the same INR holder registration process within the
     CS group.

  4.3.  CS Group Operation

     Within dRR, INR holders actively manage the distribution of their
     RPKI objects by uploading them to one or more trusted CS nodes.  The
     CS group ensures the integrity and transparency of these operations
     by requiring that both the publication of new objects and the
     revocation of existing objects be represented as OII and ORI records.
     These records MUST be disseminated across the group and permanently
     recorded in the group's global ledger.  This immutable, time-ordered
     ledger provides a comprehensive audit trail of all RPKI object
     operations.

  4.3.1.  Publication of New Objects

     To publish a new RPKI object, the INR holder submits the newly issued
     object—signed by its parent RPKI authority—to multiple trusted CS
     nodes for secure storage.  The INR holder also submits the
     corresponding OII to a designated CS node, which SHALL publish this
     OII to the CS group.

     *  If consensus on the OII is achieved among group members, the OII
        SHALL be permanently recorded in the group's global ledger.  The
        object is then officially protected by the group and becomes
        available for retrieval and synchronization by RPs.

     *  If consensus is not reached, the publication process SHALL fail,
        and the object SHALL NOT be incorporated into the group's
        authoritative dataset.

     An OII, as defined by this document, MUST include at a minimum: (1)
     The identifiers of the issuer and recipient as recorded in the
     group's registration system; (2) The parent certificate of the newly
     issued object; (3) A unique hash fingerprint of the object; (4) A
     list of CS nodes that store the object; (5) A signature generated by
     the RPKI authority.









  Li, et al.                Expires 10 July 2026                 [Page 10]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


  4.3.2.  Revocation of Existing Objects

     When an RPKI authority intends to revoke an RPKI object previously
     issued to a subordinate INR holder, it MUST first request an ORI from
     that INR holder.  The RPKI authority then submits the ORI to one or
     more trusted CS nodes, which SHALL propagate the ORI to the remaining
     group members.

     *  If consensus on the ORI is achieved among group members, the ORI
        SHALL be written to the global ledger.  The corresponding object
        SHALL then be revoked and removed from the storage of all
        participating CS nodes.

     *  If consensus is not achieved, the revocation SHALL fail, and the
        object SHALL remain valid in the group.

     An ORI, as defined by this document, MUST include at a minimum: (1)
     The unique hash fingerprint of the object to be revoked; (2) An
     authorization signature generated by the INR holders; (3) (Optional)
     Additional endorsements from affected subordinate INR holders when
     applicable.

     By ensuring that all publication and revocation operations undergo
     group-wide consensus and are permanently logged, dRR provides INR
     holders and RPs with a verifiable and tamper-evident history of RPKI
     object management.  This decentralized model significantly
     strengthens accountability and mitigates the risks associated with
     unilateral control by any single RPKI authority.

  4.4.  Monitor Operation

     A Monitor in the dRR architecture acts as a middleware entity
     responsible for bridging the CS group and RPs.  Its primary function
     is to facilitate the efficient dissemination of updated RPKI data to
     RPs.

     Whenever the CS group reaches consensus on a new set of OII and ORI,
     the participating CS nodes SHALL proactively push these confirmed
     records to their connected Monitors.  Each Monitor SHALL then:

     *  Retrieve the newly added or updated RPKI objects from the relevant
        CS nodes based on the received OIIs.

     *  Use the OIIs and ORIs to generate VUI, which cryptographically
        binds the latest updates to a verifiable proof.

     *  Proactively push the VUI, along with the newly retrieved RPKI
        objects, to the set of RPs it serves.



  Li, et al.                Expires 10 July 2026                 [Page 11]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *  Maintain a real-time full dRR-protected RPKI data snapshot to
        serve newly added RPs.

     This process ensures that RPs receive not only the updated data but
     also the cryptographic means to verify both the authenticity and the
     completeness of each update.

  5.  dRR Operation Procedures

     The primary functions of an RPKI Repository are to store, manage, and
     synchronize certificates and signed objects, including the
     publication and revocation of such data.  The following subsections
     describe how these processes are handled in the dRR system.

  5.1.  Publication and Synchronization

     Figure 1 illustrates the end-to-end process by which a new RPKI
     certificate or signed object is published and subsequently
     synchronized to RPs within the dRR system.

     The sequence proceeds as follows:

     Step 1.  Request Object: The INR holder submits a request to the
     relevant RPKI authority to obtain resources along with the
     corresponding RC or signed objects (such as ROAs, ASPAs, or SPLs).

     Step 2.  Issue Object and OII: The RPKI authority issues the
     requested RC or signed object (collectively referred to as objects)
     and returns these, along with the associated OII, to the INR holder.

     Step 3.  Upload the Object and OII: The INR holder uploads the object
     to multiple trusted CS nodes and submits the corresponding OII to one
     of the CS nodes hosting the object.

     Step 4.  Object Hosting: The selected CS nodes store the uploaded
     RPKI object on behalf of the INR holder.

     Step 5.  Consensus in the group: One of the hosting CS nodes submits
     the OII to the CS group.  CS members execute a consensus protocol to
     collectively validate the OII.  If consensus is achieved, the OII is
     permanently recorded in the group's global ledger, completing the
     object publication.

     Step 6.  Push OII to Monitors: The CS nodes push the consensus-
     approved OII to their connected Monitors.






  Li, et al.                Expires 10 July 2026                 [Page 12]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     Step 7.  Retrieving the Object by Monitors: Each Monitor retrieves
     the newly published object from the relevant CS nodes according to
     the details in the OII.

     Step 8.  Pushing Data to RPs: The Monitor generates a VUI record
     based on the new OII and proactively distributes bboth the VUI and
     the newly retrieved RPKI data to its designated RPs.  This enables
     RPs to verify the authenticity and completeness of the received
     updates.

     This coordinated process ensures that newly issued RPKI object is
     reliably stored, transparently validated through group consensus, and
     efficiently delivered to RPs with cryptographic assurances of
     integrity and completeness.

                                  +---------------------------------------+
                                  |                CS group               |
       +-------------+            | +------+                    +------+  |
       |     CA      |            | |  CS  |         ...        |  CS  |  |
       +-+/\+--------+            | +------+  +------>-------+  +------+  |
           |     |                |           |              |            |
  1.request|     |                |           /\ 5.publicize \/           |
    object |     |2.object & OII  |           |     OII      |            |
           |     |                |           |              |            |
           |     |                |           +-------<------+            |
       +-------+\/+--+   3.upload object & OII    +------+  4.storing     |
       | INR holder  |--------------------------->|  CS  |    object      |
       +-------------+            |               +------+                |
                                  +-----+/\+------------------------------+
                                    |     |
                          6.push ORI|     |7.fetch object
                                    |     |
                                    |     |
                                +-+\/+---------+ 8.push VUI/object +--------+
                                |    Monitor   |------------------>|   RP   |
                                +--------------+                   +--------+ ~~~~~~~~~~

     Figure 1: RPKI object publication and synchronization procedure
                                 in dRR.

  5.2.  Revocation and Synchronization

     Figure 2 illustrates the process by which an existing RPKI object is
     revoked within the dRR system and how this revocation information is
     synchronized to RPs:






  Li, et al.                Expires 10 July 2026                 [Page 13]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     Step 1.  Revocation request: The RPKI authority initiates a
     revocation by requesting the INR holder to revoke a specific RPKI
     object.

     Step 2.  Issue ORI: Upon agreeing to the revocation, the INR holder
     generates and signs an ORI, which serves as verifiable proof that the
     INR holder (and any affected subordinate holders) consent to the
     revocation.

     Step 3.  Upload ORI: The RPKI authority submits the signed ORI to one
     of the trusted CS nodes.

     Step 4.  Group consensus: The receiving CS node publishes the ORI to
     the CS group. group members execute a consensus protocol to validate
     and accept the ORI.  If consensus is reached, the ORI is recorded in
     the group's global ledger, the object is officially revoked, and it
     is removed from all relevant CS storage.  If consensus fails, the
     revocation does not proceed.

     Step 5.  Push to Monitors: CS nodes proactively push the consensus-
     approved ORI to their connected Monitors.

     Step 6.  Push to RPs: Monitors generate a VUI based on the new ORI
     and proactively push both the revocation data and the VUI to the RPs
     they serve.  This enables RPs to verify the authenticity and
     completeness of the revocation update.

     This process ensures that object revocations in dRR are
     cryptographically proven, transparently recorded across the group,
     and rapidly synchronized to relying parties through proactive
     distribution.




















  Li, et al.                Expires 10 July 2026                 [Page 14]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


                                 +---------------------------------------+
                       3.upload  |                CS Group               |
      +-------------+    ORI     | +------+                    +------+  |
      |     CA      |------------->|  CS  |         ...        |  CS  |  |
      +-------+/\+--+            | +------+  +------>-------+  +------+  |
          |     |                |           |              |            |
  1.revoke|     |                |           /\ 4.publicize \/           |
   object |     |2.ORI           |           |     ORI      |            |
          |     |                |           |              |            |
          |     |                |           +-------<------+            |
      +-+\/+--------+            |               +------+                |
      | INR holder  |            |               |  CS  |                |
      +-------------+            |               +------+                |
                                 +---------------------------------------+
                                       |
                             5.push ORI|
                                       |
                                       |
                               +-----+\/+-----+   6.push VUI    +--------+
                               |    Monitor   |---------------->|   RP   |
                               +--------------+                 +--------+ ~~~~~~~~~~

    Figure 2: RPKI object revocation and synchronization procedure in
                                   dRR.

     It should be noted that in practice, the CS group may concurrently
     process multiple OIIs and ORIs.  Similarly, a single CS node MAY
     aggregate and push multiple OIIs and ORIs to connected Monitors
     within the same operation.  As a result, the VUI generated by a
     Monitor and delivered to RPs MAY encapsulate multiple new object
     publications and multiple object revocations in a single update.

  6.  dRR Participants and Roles

     The dRR system is explicitly designed to support a diverse set of
     operational participants to ensure technical neutrality, operational
     robustness, and broad stakeholder representation.

     *Operators of Certificate Servers*. Within the CS group, nodes MAY be
     operated not only by the five RIRs—RIPE NCC, APNIC, AFRINIC, LACNIC,
     and ARIN—but also by other qualified entities.  These MAY include
     large Internet Service Providers (ISPs), national Internet
     registries, Content Delivery Network (CDN) service providers, or
     other infrastructure organizations capable of reliably hosting RPKI
     data and serving RPs.  By enabling a mix of technical and geographic
     participation, the CS group mitigates risks associated with
     centralized control and improves the resilience of the overall
     repository system.



  Li, et al.                Expires 10 July 2026                 [Page 15]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *Operators of Monitors*. In the dRR architecture, the Monitor role is
     intended to serve multiple RPs that typically exist within the same
     trust domain as the Monitor itself.  For example, these RPs MAY
     include multiple Autonomous Systems (ASes) under the operational
     control of the same ISP, or networks within the jurisdiction of a
     single governmental or national organization.  This trust
     relationship allows Monitors to efficiently aggregate updates from
     the CS group and securely distribute RPKI data to affiliated RPs,
     thereby reducing synchronization overhead and enhancing overall
     system efficiency.

     By explicitly supporting a multi-party operational model for both CS
     group nodes and Monitors, the dRR architecture fosters participation
     from a range of organizational types and jurisdictions.  This
     approach helps achieve a balanced ecosystem that reflects diverse
     operational interests while reducing systemic dependencies on any
     single class of stakeholder.  The inclusion of varied participants is
     fundamental to ensuring the long-term neutrality, transparency, and
     accountability of the RPKI data distribution infrastructure.  Whether
     and how CS nodes provide services to INR holders on a compensated
     basis is out of scope for this document.

  7.  Benefits and Improvements

     By introducing a group of CS nodes and a layer of Monitors, dRR May
     address several longstanding challenges of the current RPKI
     Repository system and achieves tangible operational benefits:

     *  *Improving Scalability and Mitigating P1:* dRR enhances
        scalability through two key mechanisms.  First, the group's
        controlled admission mechanism ensures that only vetted entities
        can operate CS nodes, effectively limiting the overall number of
        repository nodes while still supporting a globally distributed
        architecture.  Second, dRR's two-tier data distribution model
        means that CS nodes only need to establish connections with their
        designated Monitors, and RPs in turn only maintain connections
        with their respective Monitors.  This structured push model
        significantly reduces the volume of direct bidirectional
        connections between RPs and repository nodes, alleviating
        synchronization pressure and supporting large-scale deployment
        without compromising timeliness or efficiency.










  Li, et al.                Expires 10 July 2026                 [Page 16]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     *  *Enhancing Reliability and Mitigating P2:* In dRR, each RPKI
        object can be simultaneously hosted across multiple CS nodes.
        This means that the failure or compromise of any single node does
        not jeopardize the availability or integrity of RPKI data as
        retrieved by RPs.  Additionally, the federated structure
        inherently filters for participants with the capacity to provide
        robust, stable hosting, further improving the system's resilience
        against localized outages.

     *  *Strengthening Auditability:* Each CS node in dRR maintains
        complete and consistent RPKI data, along with a record of all
        operations performed on the data.  This enables dRR to provide
        reliable auditing capabilities for the RPKI system, thereby
        enhancing the transparency of RPKI data.

  8.  Deployment Considerations

     The incremental deployment of dRR is designed to align with the
     existing hierarchical structure of the RPKI system, following a top-
     down approach.  Specifically, an RPKI object MAY be protected by dRR
     only if its parent RC is already under dRR protection.  This section
     outlines deployment behaviors in partial adoption scenarios.

     (1) Certificate Management Model.

     When an RPKI authority adopts dRR, its subordinate INR holders MAY
     independently decide whether to deploy dRR.  As a result:

     *  An RPKI authority SHALL continue operating its traditional
        repository PP for as long as any of its subordinate INR holders
        have not deployed dRR, to ensure continued hosting of their RPKI
        objects.

     *  Only when all subordinate INR holders have fully transitioned to
        dRR MAY the RPKI authority discontinue operation of its PP.

     *  For subordinate INR holders that have not deployed dRR, their RPKI
        data management remains unchanged, and their objects SHALL
        continue to be stored in the authority's PP.

     *  For INR holders that have deployed dRR, their RPKI data SHALL NOT
        be stored in the parent RPKI authority's PP, and the corresponding
        PP manifest SHALL NOT include RCs or signed objects protected by
        dRR.

     (2)Incremental Data Synchronization.





  Li, et al.                Expires 10 July 2026                 [Page 17]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     During partial deployment phases, RPs SHOULD synchronize data from
     both dRR and the existing RPKI repository system to maintain a
     complete view of the RPKI state.  This involves:

     *  Updates via dRR: The RP applies updates proactively pushed by
        Monitors, using the received VUI and associated data.  The RP
        SHALL add newly published objects indicated by OIIs and remove
        revoked objects as specified by ORIs.

     *  Updates via Traditional Repositories: The RP SHALL continue to
        periodically synchronize RPKI data not protected by dRR by
        querying all relevant repository PPs using protocols such as Rsync
        or RRDP.

     (3)Full Data Synchronization.

     Similarly, during partial deployment, RPs MUST acquire full RPKI data
     snapshot from both dRR Monitor and the current RPKI repository to
     ensure full synchronization of all RPKI objects.

     dRR explicitly supports such phased deployment models.  During
     incremental adoption, dRR continues to provide full security
     assurances for certificates under its protection, ensuring a
     consistent trust model throughout the transition process.

  9.  Security Considerations

     TBD

  10.  IANA Considerations

     This document has no IANA requirements.

  11.  References

  11.1.  Normative References

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

     [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
                "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
                DOI 10.17487/RFC8182, July 2017,
                <https://www.rfc-editor.org/rfc/rfc8182>.






  Li, et al.                Expires 10 July 2026                 [Page 18]


  Internet-Draft  Decentralized RPKI Repository Architectu    January 2026


     [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
                Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
                February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.

     [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
                Resource Certificate Repository Structure", RFC 6481,
                DOI 10.17487/RFC6481, February 2012,
                <https://www.rfc-editor.org/rfc/rfc6481>.

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

  11.2.  Informative References

     [rpki-repo-ps]
                "RPKI Repository Problem Statement", Internet-Draft draft-
                li-sidrops-rpki-repository-problem-statement-02 , 2025,
                <https://datatracker.ietf.org/doc/draft-li-sidrops-rpki-
                repository-problem-statement/>.

  Authors' Addresses

     Dan Li
     Tsinghua University
     Beijing
     China
     Email: tolidan@tsinghua.edu.cn


     Yingying Su
     Zhongguancun Laboratory
     Beijing
     China
     Email: suyy@mail.zgclab.edu.cn


     Li Chen
     Zhongguancun Laboratory
     Beijing
     China
     Email: lichen@zgclab.edu.cn








  Li, et al.                Expires 10 July 2026                 [Page 19]


name: draft-kamimura-rats-behavioral-evidence
rev: 01
title: On the Relationship Between Remote Attestation and Behavioral Evidence Recording
time: 2026-01-09T08:38:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-13T08:38:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.643620+00:00
source: ietf
abstract:
  This document provides an informational discussion of the conceptual
     relationship between remote attestation, as defined in RFC 9334 (RATS
     Architecture), and behavioral evidence recording mechanisms.  It
     observes that these two verification capabilities address
     fundamentally different questions - attestation addresses "Is this
     system in a trustworthy state?" while behavioral evidence addresses
     "What did the system actually do?" - and discusses how they could
     conceptually complement each other in accountability frameworks.
     This document is purely descriptive: it does not propose any
     modifications to RATS architecture, define new mechanisms or
     protocols, or establish normative requirements.  It explicitly does
     not define any cryptographic binding between attestation and
     behavioral evidence.

full_text:
  Remote ATtestation ProcedureS                                T. Kamimura
  Internet-Draft                 VeritasChain Standards Organization (VSO)
  Intended status: Informational                           10 January 2026
  Expires: 14 July 2026


   On the Relationship Between Remote Attestation and Behavioral Evidence
                                 Recording
                 draft-kamimura-rats-behavioral-evidence-01

  Abstract

     This document provides an informational discussion of the conceptual
     relationship between remote attestation, as defined in RFC 9334 (RATS
     Architecture), and behavioral evidence recording mechanisms.  It
     observes that these two verification capabilities address
     fundamentally different questions - attestation addresses "Is this
     system in a trustworthy state?" while behavioral evidence addresses
     "What did the system actually do?" - and discusses how they could
     conceptually complement each other in accountability frameworks.
     This document is purely descriptive: it does not propose any
     modifications to RATS architecture, define new mechanisms or
     protocols, or establish normative requirements.  It explicitly does
     not define any cryptographic binding between attestation and
     behavioral evidence.

  Discussion Venues

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

     Discussion of this document takes place on the Remote ATtestation
     ProcedureS (RATS) Working Group mailing list (rats@ietf.org), which
     is archived at https://mailarchive.ietf.org/arch/browse/rats/.

     Source for this draft and an issue tracker can be found at
     https://github.com/veritaschain/draft-kamimura-rats-behavioral-
     evidence.

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




  Kamimura                  Expires 14 July 2026                  [Page 1]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Document Status . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4
         1.2.1.  What Attestation Alone Establishes (X)  . . . . . . .   4
         1.2.2.  What Behavioral Evidence Alone Establishes (Y)  . . .   5
         1.2.3.  What Considering Both Together Could Enable (X+Y) . .   5
         1.2.4.  Remaining Trust Gaps  . . . . . . . . . . . . . . . .   6
         1.2.5.  Domain Examples . . . . . . . . . . . . . . . . . . .   6
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.1.  RATS Terminology (Reused Without Modification)  . . . . .   7
       2.2.  Behavioral Evidence Terminology . . . . . . . . . . . . .   7
     3.  Conceptual Layering . . . . . . . . . . . . . . . . . . . . .   8
       3.1.  Attestation Layer (RATS)  . . . . . . . . . . . . . . . .   8
       3.2.  Behavioral Evidence Layer . . . . . . . . . . . . . . . .   9
       3.3.  Separation of Concerns  . . . . . . . . . . . . . . . . .  10
     4.  Conceptual Relationship . . . . . . . . . . . . . . . . . . .  10
       4.1.  Different Questions, Different Answers  . . . . . . . . .  10
       4.2.  Temporal Considerations . . . . . . . . . . . . . . . . .  11
       4.3.  No Cryptographic Binding Defined  . . . . . . . . . . . .  11
     5.  Illustrative Example  . . . . . . . . . . . . . . . . . . . .  12
     6.  Non-Goals and Explicit Out-of-Scope Items . . . . . . . . . .  13
       6.1.  No Changes to RATS  . . . . . . . . . . . . . . . . . . .  13
       6.2.  No Protocol or Format Definition  . . . . . . . . . . . .  13
       6.3.  No Normative Requirements . . . . . . . . . . . . . . . .  13
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14



  Kamimura                  Expires 14 July 2026                  [Page 2]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


       7.1.  No Security Composition Claimed . . . . . . . . . . . . .  14
       7.2.  Warning Against False Sense of Security . . . . . . . . .  14
       7.3.  Conceptual Attack Considerations  . . . . . . . . . . . .  14
       7.4.  Independent Security Analysis Required  . . . . . . . . .  15
       7.5.  RATS Threat Model Unchanged . . . . . . . . . . . . . . .  16
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
     Changes from -00  . . . . . . . . . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     The IETF RATS (Remote ATtestation ProcedureS) Working Group has
     developed a comprehensive architecture for remote attestation
     [RFC9334], enabling Relying Parties to assess the trustworthiness of
     remote systems through cryptographic evidence about their state.
     This attestation capability addresses a fundamental question in
     distributed systems: "Is this system in a trustworthy state?"

     A related but distinct verification need exists in many operational
     contexts: the ability to verify what actions a system has actually
     performed after the fact.  This question - "What did the system
     actually do?" - is addressed by behavioral evidence recording
     mechanisms, which create tamper-evident records of system actions and
     decisions.

     This document observes that these two verification capabilities
     address different aspects of system accountability and discusses
     their conceptual relationship.  The document does not propose any
     technical integration, protocol, or cryptographic binding between
     these mechanisms.  Any discussion of "complementary" use is purely
     conceptual and does not imply a composed security property.

  1.1.  Document Status

     This document is purely INFORMATIONAL and NON-NORMATIVE.  It:

     *  Does NOT propose any new RATS mechanisms or architecture changes

     *  Does NOT modify or extend the RATS architecture as defined in
        [RFC9334]

     *  Does NOT define new protocols, claims, tokens, or data formats

     *  Does NOT establish normative requirements for any implementation



  Kamimura                  Expires 14 July 2026                  [Page 3]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *  Does NOT define any cryptographic binding or security composition
        between attestation and behavioral evidence

     *  Remains fully compatible with and respectful of existing RATS
        concepts and design philosophy

     The language in this document uses descriptive terms (MAY, COULD,
     CAN) exclusively to indicate possibilities and observations.  This
     document does not use normative requirements language (MUST, SHOULD,
     SHALL) as there are no mandatory behaviors or requirements being
     specified.

     This document treats behavioral evidence recording systems in general
     terms, using VeritasChain Protocol (VCP) [VCP-SPEC] as one
     illustrative example among various possible approaches.  Other
     systems such as Certificate Transparency [RFC6962] and general
     append-only log architectures employ similar cryptographic techniques
     for different purposes.

  1.2.  Motivation

     This document is motivated by an observation that attestation and
     behavioral evidence recording, while both contributing to system
     accountability, answer fundamentally different questions.
     Understanding this distinction could help system architects avoid
     conflating these mechanisms or assuming one substitutes for the
     other.

  1.2.1.  What Attestation Alone Establishes (X)

     Remote attestation, as defined in [RFC9334], enables a Relying Party
     to assess whether an Attester is in a trustworthy state at the time
     of attestation.  When attestation succeeds, the Relying Party gains
     assurance that:

     *  The Attester's software configuration matches expected Reference
        Values

     *  The Attester is running on genuine, uncompromised hardware (where
        hardware roots of trust are used)

     *  The Attester's identity can be cryptographically verified

     However, attestation alone does NOT establish:

     *  What specific actions the Attester will take after attestation





  Kamimura                  Expires 14 July 2026                  [Page 4]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *  Whether the Attester's future behavior will conform to any
        particular policy

     *  A verifiable record of what the Attester actually did during
        operation

  1.2.2.  What Behavioral Evidence Alone Establishes (Y)

     Behavioral evidence recording mechanisms create tamper-evident
     records of system actions and decisions.  When properly implemented,
     such mechanisms could provide:

     *  A chronological record of what actions the system performed

     *  Cryptographic integrity protection for those records

     *  Evidence for after-the-fact examination of system behavior

     However, behavioral evidence recording alone does NOT establish:

     *  That the system recording the evidence was in a trustworthy state
        when it generated the records

     *  That the system's software, configuration, or hardware was
        uncompromised

     *  That the records accurately reflect what the system actually did
        (a compromised system could generate false records)

  1.2.3.  What Considering Both Together Could Enable (X+Y)

     When an observer has access to both valid Attestation Results for a
     system AND a verifiable behavioral evidence trail from that system,
     the observer could potentially reason:

     *  "At time T1, attestation confirmed the system was in a known-good
        state"

     *  "The behavioral evidence records actions from T1 to T2"

     *  "If the system remained in the attested state throughout this
        period, these behavioral records could be considered more
        trustworthy"








  Kamimura                  Expires 14 July 2026                  [Page 5]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *Critical Limitation:* This reasoning is purely conceptual and
     informal.  This document explicitly does NOT claim that considering
     attestation and behavioral evidence together creates any composed
     security property.  Significant trust gaps remain (see
     Section 1.2.4).

  1.2.4.  Remaining Trust Gaps

     Even when both attestation and behavioral evidence are available,
     significant trust gaps remain that this document does not address:

     *  *Time-of-check vs. time-of-use:* Attestation confirms state at a
        point in time; the system could be compromised immediately after
        attestation

     *  *Attestation-to-logging binding:* No cryptographic mechanism is
        defined to bind Attestation Results to specific behavioral
        evidence entries

     *  *Logging fidelity:* Even a trustworthy system could have bugs in
        its logging implementation

     *  *Selective omission:* A system could pass attestation yet
        selectively omit events from its behavioral records

     *  *Compromised logging infrastructure:* The logging infrastructure
        itself could be compromised independently of the attested system

     These gaps would need to be addressed by specific technical
     mechanisms not defined in this document.  Deployments considering
     both attestation and behavioral evidence should carefully analyze
     their threat model and not assume that informal complementarity
     provides strong security guarantees.

  1.2.5.  Domain Examples

     The following examples illustrate domains where both capabilities
     could be relevant.  These examples are illustrative only and do not
     constitute normative guidance:

     *  *Financial Services:* Algorithmic trading systems may face
        regulatory requirements for both system integrity verification and
        decision audit trails

     *  *Artificial Intelligence:* AI governance frameworks increasingly
        distinguish between system certification and operational logging





  Kamimura                  Expires 14 July 2026                  [Page 6]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *  *Critical Infrastructure:* Systems controlling physical processes
        may benefit from attestation of their configuration alongside
        records of their actions

  2.  Terminology

  2.1.  RATS Terminology (Reused Without Modification)

     This document reuses terminology from the RATS Architecture [RFC9334]
     without modification or extension.  The following terms are used
     exactly as defined in that document:

     Attester  A role performed by an entity that creates Evidence about
        itself and conveys it to a Verifier.  (RFC 9334, Section 2)

     Verifier  A role performed by an entity that appraises Evidence about
        an Attester.  (RFC 9334, Section 2)

     Relying Party  A role performed by an entity that uses Attestation
        Results to make authorization decisions.  (RFC 9334, Section 2)

     Evidence  Information about an Attester's state, generated by the
        Attester.  (RFC 9334, Section 2)

     Attestation Results  Output produced by a Verifier, indicating the
        trustworthiness of an Attester.  (RFC 9334, Section 2)

     Claims  Assertions about characteristics of an Attester.  (RFC 9334,
        Section 2)

     Reference Values  Expected values against which Evidence is compared.
        (RFC 9334, Section 2)

  2.2.  Behavioral Evidence Terminology

     The following terms are used in this document to describe behavioral
     evidence concepts.  These terms are grounded in general systems and
     security literature rather than being newly defined by this document.

     *Note on "Audit" Terminology:* The term "audit" in this document
     follows common systems engineering usage (e.g., "audit log", "audit
     trail") referring to chronological records of system events
     maintained for post-hoc examination.  This usage is consistent with
     standard security terminology as found in sources such as NIST SP
     800-92 (Guide to Computer Security Log Management) [NIST-SP800-92]
     and general operating systems literature.  It does not imply
     regulatory auditing, financial auditing, or compliance certification
     in any jurisdiction-specific sense.



  Kamimura                  Expires 14 July 2026                  [Page 7]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     Audit Event  A recorded occurrence representing a discrete action,
        decision, or state change in a system.  This term is used in
        general systems security contexts and should not be confused with
        RATS Evidence, which describes system state rather than behavior.

     Audit Trail  A chronologically ordered sequence of Audit Events that
        can be examined to reconstruct system behavior.  When
        cryptographic integrity mechanisms are applied, such trails may be
        "verifiable" in the sense that tampering can be detected.

     Behavioral Evidence  In this document, "behavioral evidence" refers
        to records of what a system has done (its actions and decisions),
        as distinct from RATS Evidence, which describes what state a
        system is in (its configuration and properties).  This term is
        used specifically to avoid confusion with the precise RATS
        definition of "Evidence".

  3.  Conceptual Layering

     This section describes an observational framework for understanding
     how attestation and behavioral evidence recording address different
     verification needs.  This framework is purely conceptual and does not
     define any technical integration or protocol.

  3.1.  Attestation Layer (RATS)

     The RATS architecture [RFC9334] addresses trustworthiness assessment
     through remote attestation.  At its core, attestation answers
     questions about system state:

     *  Is the system's software configuration as expected?

     *  Is the system running on genuine, uncompromised hardware?

     *  Does the system's current state match known-good Reference Values?

     *  Can the system's identity and configuration be cryptographically
        verified?

     These questions are fundamentally about the properties and
     characteristics of a system at a point in time or across a
     measurement period.  The RATS architecture provides mechanisms for
     generating, conveying, and appraising Evidence that enables Relying
     Parties to make trust decisions about Attesters.

     Key characteristics of attestation as defined by RATS:

     *  Focuses on system state and configuration



  Kamimura                  Expires 14 July 2026                  [Page 8]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *  Enables trust decisions before or during interactions

     *  Produces Attestation Results for Relying Party consumption

     *  May rely on hardware roots of trust

     *  Addresses the question: "Can I trust this system's current state?"

  3.2.  Behavioral Evidence Layer

     Behavioral evidence recording mechanisms address a different category
     of verification need.  Rather than assessing system state, they
     record what a system has done:

     *  What decisions did an algorithm make?

     *  What actions did the system execute?

     *  What inputs led to what outputs?

     *  What was the sequence and timing of operations?

     These questions are fundamentally about system behavior over time.
     Verifiable behavioral evidence mechanisms could provide ways to
     record, preserve, and verify the integrity of behavioral records,
     enabling after-the-fact examination of system actions.

     Key characteristics of behavioral evidence systems (in general
     terms):

     *  Focus on system behavior and decisions

     *  Enable verification after events have occurred

     *  Produce verifiable records for post-hoc examination

     *  May rely on cryptographic structures such as hash chains, Merkle
        trees, or append-only logs

     *  Address the question: "What did this system do?"

     As an illustrative example, VCP [VCP-SPEC] defines audit trails using
     three integrity layers: event integrity (hashing), structural
     integrity (Merkle trees), and external verifiability (digital
     signatures and anchoring).  Certificate Transparency [RFC6962] uses
     similar cryptographic techniques for a different purpose (public
     logging of certificates).  Other behavioral evidence systems could
     employ different mechanisms.



  Kamimura                  Expires 14 July 2026                  [Page 9]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


  3.3.  Separation of Concerns

     The distinction between attestation and behavioral evidence can be
     understood as a separation of concerns:

        +==========+========================+========================+
        | Aspect   | Attestation (RATS)     | Behavioral Evidence    |
        +==========+========================+========================+
        | Primary  | Is this system         | What did this system   |
        | Question | trustworthy?           | do?                    |
        +----------+------------------------+------------------------+
        | Focus    | System state           | System behavior        |
        +----------+------------------------+------------------------+
        | Temporal | Point-in-time or       | Historical record of   |
        | Scope    | measurement period     | actions                |
        +----------+------------------------+------------------------+
        | Primary  | Trust decision before/ | Post-hoc examination   |
        | Use Case | during interaction     | and accountability     |
        +----------+------------------------+------------------------+
        | Trust    | Hardware/software      | Logging infrastructure |
        | Anchor   | roots of trust         | integrity              |
        +----------+------------------------+------------------------+

              Table 1: Conceptual Comparison of Attestation and
                             Behavioral Evidence

     This separation suggests that attestation and behavioral evidence
     address different needs.  This document observes that neither
     mechanism fully substitutes for the other, but explicitly does not
     claim that using both together creates a composed security property
     (see Section 7).

  4.  Conceptual Relationship

     This section discusses the conceptual relationship between
     attestation and behavioral evidence.  All discussion in this section
     is observational and does not define any protocol, binding, or
     security composition.

  4.1.  Different Questions, Different Answers

     A key observation is that attestation and behavioral evidence answer
     different questions:

     Attestation answers:  "At time T, was this system in a trustworthy
        state?"

     Behavioral evidence answers:  "Between times T1 and T2, what actions



  Kamimura                  Expires 14 July 2026                 [Page 10]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


        did this system perform?"

     Neither question's answer implies the other's:

     *  A system could pass attestation at time T but subsequently perform
        unexpected actions (visible only through behavioral records, if
        recorded honestly)

     *  A system could have complete behavioral records while being
        compromised in ways that attestation might have detected (if
        attestation had been performed)

  4.2.  Temporal Considerations

     Attestation and behavioral evidence may operate on different temporal
     rhythms:

     Attestation Patterns:
        *  At system boot or initialization

        *  Periodically during operation

        *  On-demand when a Relying Party requests

     Behavioral Evidence Patterns:
        *  Continuously, as events occur

        *  At varying granularities depending on event significance

        *  With periodic integrity commitments

     One conceptual model involves attestation confirming system state at
     discrete moments, while behavioral evidence records actions between
     those moments.  However, this document explicitly notes that no
     cryptographic mechanism is defined to bind these two types of
     evidence together.  The "gap" between attestation events represents a
     period during which system state could change without detection.

  4.3.  No Cryptographic Binding Defined

     This document explicitly does NOT define any cryptographic binding
     between Attestation Results and behavioral evidence records.  Such a
     binding would require:

     *  A protocol for cryptographically linking Attestation Results to
        specific behavioral evidence entries

     *  Mechanisms to prevent replay, substitution, or mismatch attacks



  Kamimura                  Expires 14 July 2026                 [Page 11]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     *  Clear semantics for what such a binding would prove

     *  Analysis of the composed security properties

     None of these are provided by this document.  Any deployment
     considering both mechanisms should not assume that informal
     correlation provides the security properties that a formal
     cryptographic binding might offer.

  5.  Illustrative Example

     This section provides a purely illustrative, non-normative example of
     how attestation and behavioral evidence could conceptually relate in
     a hypothetical scenario.  This example:

     *  Does NOT define any protocol or establish any requirements

     *  Is NOT exhaustive of possible deployment patterns

     *  Does NOT imply that this is the only or best way to use these
        mechanisms

     *  Is intended solely to illustrate the conceptual distinctions
        discussed in this document

     Consider a hypothetical automated decision-making system:

     Phase 1: System Startup  The system boots and undergoes remote
        attestation.  A Verifier confirms that the system's software,
        configuration, and hardware environment match expected Reference
        Values.  A Relying Party receives Attestation Results indicating
        the system is in a trustworthy state.

     Phase 2: Operational Period  During operation, the system generates
        behavioral evidence for significant actions.  These records are
        maintained in a tamper-evident structure.  Note: Nothing
        cryptographically binds these records to the earlier attestation.

     Phase 3: Post-Hoc Examination  An examiner later wishes to understand
        the system's behavior.  The examiner could: (a) check that
        Attestation Results existed for relevant times, and (b) examine
        the behavioral evidence for those times.  However, the examiner
        should understand that the informal correlation between these does
        not constitute a cryptographic proof (see Section 1.2.4).

     This example is purely conceptual.  Actual deployments would require
     careful security analysis specific to their threat model.




  Kamimura                  Expires 14 July 2026                 [Page 12]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


  6.  Non-Goals and Explicit Out-of-Scope Items

     To maintain clarity about this document's limited scope, the
     following items are explicitly out of scope and are NOT addressed:

  6.1.  No Changes to RATS

     This document does NOT:

     *  Propose any modifications to the RATS architecture

     *  Define any new attestation mechanisms, Evidence formats, or
        Attestation Result structures

     *  Suggest that RATS should incorporate behavioral evidence
        capabilities

     *  Propose work items for the RATS Working Group

  6.2.  No Protocol or Format Definition

     This document does NOT:

     *  Specify any protocol for connecting attestation and behavioral
        evidence

     *  Define any new claims, tokens, or data structures

     *  Mandate any particular behavioral evidence format or mechanism

     *  Define interoperability requirements between attestation and
        behavioral evidence systems

  6.3.  No Normative Requirements

     This document does NOT:

     *  Establish normative requirements for either attestation or
        behavioral evidence implementations

     *  Specify trust relationships or delegation models

     *  Define any cryptographic binding or security composition

     The sole purpose of this document is to observe and explain the
     conceptual relationship between attestation and behavioral evidence
     as distinct mechanisms addressing different verification questions.




  Kamimura                  Expires 14 July 2026                 [Page 13]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


  7.  Security Considerations

     This document is purely informational and does not define any
     protocols or mechanisms.  However, because it discusses the
     conceptual relationship between two security-relevant mechanisms, the
     following security considerations are important.

  7.1.  No Security Composition Claimed

     This document explicitly does NOT claim that considering attestation
     and behavioral evidence together creates any composed security
     property.  In particular:

     *  No cryptographic binding is defined between Attestation Results
        and behavioral evidence records

     *  The informal observation that both mechanisms "could be used
        together" does not imply any formal security guarantee

     *  Each mechanism's security properties must be analyzed
        independently

     *  The combination does not automatically inherit the security
        properties of either mechanism

  7.2.  Warning Against False Sense of Security

     Readers should be cautioned against assuming that having both
     attestation and behavioral evidence provides comprehensive security.
     Specifically:

     *  *Attestation does not guarantee future behavior:* A system that
        passes attestation at time T could be compromised at time T+1

     *  *Behavioral evidence does not guarantee system integrity:* A
        compromised system could generate false or incomplete behavioral
        records

     *  *Informal correlation is not cryptographic proof:* Observing that
        a system had valid Attestation Results and behavioral evidence for
        the same time period does not constitute a cryptographic proof of
        correct behavior

  7.3.  Conceptual Attack Considerations

     At a conceptual level (without defining any specific protocol),
     deployments considering both attestation and behavioral evidence
     should be aware of risks including:



  Kamimura                  Expires 14 July 2026                 [Page 14]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


     Replay:  Without appropriate binding, an attacker could potentially
        present valid attestation from one context alongside behavioral
        evidence from another context.

     Diversion:  An attacker could potentially direct a Relying Party to
        behavioral evidence from a different (legitimately attested)
        system than the one actually performing operations.

     Relay:  An intermediary could potentially relay attestation
        challenges to a legitimate system while recording behavioral
        evidence from a compromised system.

     Selective omission:  A system could pass attestation yet selectively
        omit events from its behavioral evidence records, particularly if
        the logging mechanism is not included in attestation measurements.

     Time-of-check vs. time-of-use (TOCTOU):  A system's state at
        attestation time may differ from its state when generating
        behavioral evidence, particularly if re-attestation is infrequent.

     These considerations are presented at a conceptual level to inform
     threat modeling.  This document does not define mechanisms to address
     these risks.

  7.4.  Independent Security Analysis Required

     The following security considerations apply independently:

     Attestation Security:  Security considerations for remote attestation
        are thoroughly addressed in [RFC9334].  These considerations are
        unchanged by this document.

     Behavioral Evidence Security:  Behavioral evidence recording
        mechanisms have their own security considerations, including:

        *  Key management for signing records

        *  Protection against selective omission

        *  Integrity of external anchoring mechanisms

        *  Privacy considerations for sensitive data

        *  Trustworthiness of the logging infrastructure itself







  Kamimura                  Expires 14 July 2026                 [Page 15]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


  7.5.  RATS Threat Model Unchanged

     This document does not alter the RATS threat model as defined in
     [RFC9334].  It introduces no new attack surfaces to the RATS
     architecture.  Any deployment-specific threat analysis should
     consider attestation and behavioral evidence as separate mechanisms
     with independent trust assumptions and failure modes.

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/info/rfc9334>.

  9.2.  Informative References

     [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
                Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
                <https://www.rfc-editor.org/info/rfc6962>.

     [NIST-SP800-92]
                National Institute of Standards and Technology, "Guide to
                Computer Security Log Management", NIST Special
                Publication 800-92, September 2006,
                <https://csrc.nist.gov/publications/detail/sp/800-92/
                final>.

     [VCP-SPEC] VeritasChain Standards Organization, "VeritasChain
                Protocol (VCP) Specification Version 1.1", 2025,
                <https://veritaschain.org/spec>.

  Acknowledgments

     The author thanks the RATS Working Group for developing the
     comprehensive attestation architecture documented in RFC 9334.  This
     document builds upon and respects the careful design work reflected
     in that architecture.  The author also thanks reviewers who provided
     feedback emphasizing the importance of clearly distinguishing
     conceptual observations from security claims.





  Kamimura                  Expires 14 July 2026                 [Page 16]


  Internet-Draft        RATS and Behavioral Evidence          January 2026


  Changes from -00

     *  Strengthened Motivation section with explicit X/Y/X+Y reasoning

     *  Added explicit "Remaining Trust Gaps" subsection

     *  Significantly expanded Security Considerations with warnings
        against false sense of security and conceptual attack
        considerations

     *  Added NIST SP 800-92 reference to ground "audit" terminology

     *  Added explicit "No Cryptographic Binding Defined" section

     *  Clarified that the illustrative example is non-normative and non-
        exhaustive

     *  Restructured Non-Goals into categorized subsections

     *  Added RFC 9334 section references to terminology definitions

     *  Removed unused references (SCITT architecture, reference-
        interaction-models, RFC 9162)

  Author's Address

     Tokachi Kamimura
     VeritasChain Standards Organization (VSO)
     Email: kamimura@veritaschain.org
     URI:   https://veritaschain.org





















  Kamimura                  Expires 14 July 2026                 [Page 17]


name: draft-bondar-wca
rev: 00
title: Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-Agent Tool-Call Chains
time: 2026-03-01T11:19:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-02T11:19:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:22.647565+00:00
source: ietf
abstract:
  Large Language Model (LLM)-based agent systems increasingly invoke
     external tools and data sources, yet the epistemic provenance of
     consumed data remains architecturally unregulated.  Data crossing
     tool-call boundaries acquires the apparent trustworthiness of the
     interface rather than reflecting the institutional standing of its
     actual source -- a phenomenon termed "semantic laundering."

     This document specifies the Warrant Certificate Authority (WCA): an
     end-to-end cryptographic attestation infrastructure that certifies
     data sources, not data content.  WCA introduces a provenance layer
     satisfying reference monitor properties (complete mediation,
     tamperproofness, verifiability) for all agent-to-tool interactions.
     The architecture draws on the PKI trust model, OS provenance
     paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks
     (SLSA, in-toto).

     This document defines data structures for tool-call attestation,
     warrant certificates, and a trust hierarchy of certificate
     authorities.  It specifies the provenance-layer protocol and
     introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a
     graduated adoption framework analogous to SLSA build levels.

full_text:
  Network Working Group                                          R. Bondar
  Internet-Draft                                              1 March 2026
  Intended status: Informational                                          
  Expires: 2 September 2026


  Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-
                           Agent Tool-Call Chains
                            draft-bondar-wca-00

  Abstract

     Large Language Model (LLM)-based agent systems increasingly invoke
     external tools and data sources, yet the epistemic provenance of
     consumed data remains architecturally unregulated.  Data crossing
     tool-call boundaries acquires the apparent trustworthiness of the
     interface rather than reflecting the institutional standing of its
     actual source -- a phenomenon termed "semantic laundering."

     This document specifies the Warrant Certificate Authority (WCA): an
     end-to-end cryptographic attestation infrastructure that certifies
     data sources, not data content.  WCA introduces a provenance layer
     satisfying reference monitor properties (complete mediation,
     tamperproofness, verifiability) for all agent-to-tool interactions.
     The architecture draws on the PKI trust model, OS provenance
     paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks
     (SLSA, in-toto).

     This document defines data structures for tool-call attestation,
     warrant certificates, and a trust hierarchy of certificate
     authorities.  It specifies the provenance-layer protocol and
     introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a
     graduated adoption framework analogous to SLSA build levels.

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



  Bondar                  Expires 2 September 2026                [Page 1]


  Internet-Draft                     WCA                        March 2026


     This Internet-Draft will expire on 2 September 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Warrant Erosion . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Semantic Laundering . . . . . . . . . . . . . . . . . . .   7
       3.3.  Insufficiency of Content-Evaluating Mediators . . . . . .   7
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Design Principle  . . . . . . . . . . . . . . . . . . . .   8
       4.2.  System Components . . . . . . . . . . . . . . . . . . . .   8
     5.  Data Structures . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Trusted Source Registry Entry . . . . . . . . . . . . . .   9
       5.2.  Tool-Call Attestation . . . . . . . . . . . . . . . . . .  10
       5.3.  Warrant Certificate . . . . . . . . . . . . . . . . . . .  10
       5.4.  WCA Certificate . . . . . . . . . . . . . . . . . . . . .  11
       5.5.  Attestation Log Entry . . . . . . . . . . . . . . . . . .  11
     6.  WCA Trust Hierarchy . . . . . . . . . . . . . . . . . . . . .  12
       6.1.  Root WCA  . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.2.  Domain WCA  . . . . . . . . . . . . . . . . . . . . . . .  12
       6.3.  Source Certificates . . . . . . . . . . . . . . . . . . .  12
       6.4.  Certificate Lifecycle . . . . . . . . . . . . . . . . . .  13
     7.  Provenance Layer Protocol . . . . . . . . . . . . . . . . . .  13
       7.1.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Reference Monitor Properties  . . . . . . . . . . . . . .  13
       7.3.  Attestation Log . . . . . . . . . . . . . . . . . . . . .  14
     8.  Warrant Attestation Levels  . . . . . . . . . . . . . . . . .  14
       8.1.  WAL-0: No Provenance  . . . . . . . . . . . . . . . . . .  14
       8.2.  WAL-1: Provenance Exists  . . . . . . . . . . . . . . . .  14
       8.3.  WAL-2: Signed Provenance  . . . . . . . . . . . . . . . .  14
       8.4.  WAL-3: Full Verification  . . . . . . . . . . . . . . . .  14
       8.5.  Migration Path  . . . . . . . . . . . . . . . . . . . . .  15
     9.  Non-Interference Requirements . . . . . . . . . . . . . . . .  15
       9.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .  15
       9.2.  Mediated Self-Licensing Risk  . . . . . . . . . . . . . .  15



  Bondar                  Expires 2 September 2026                [Page 2]


  Internet-Draft                     WCA                        March 2026


       9.3.  Mitigation Strategies . . . . . . . . . . . . . . . . . .  16
     10. Integration Considerations  . . . . . . . . . . . . . . . . .  16
       10.1.  Agent Framework Integration  . . . . . . . . . . . . . .  16
       10.2.  Source-Side Requirements . . . . . . . . . . . . . . . .  16
       10.3.  Performance Considerations . . . . . . . . . . . . . . .  17
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  17
       11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  17
       11.2.  Response Substitution  . . . . . . . . . . . . . . . . .  17
       11.3.  Agent Self-Licensing . . . . . . . . . . . . . . . . . .  17
       11.4.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  17
       11.5.  Source Impersonation . . . . . . . . . . . . . . . . . .  17
       11.6.  WCA Compromise . . . . . . . . . . . . . . . . . . . . .  18
       11.7.  Attestation Log Tampering  . . . . . . . . . . . . . . .  18
       11.8.  Limitations  . . . . . . . . . . . . . . . . . . . . . .  18
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       12.1.  WCA URN Namespace  . . . . . . . . . . . . . . . . . . .  18
       12.2.  WAL Level Registry . . . . . . . . . . . . . . . . . . .  18
       12.3.  WCA Epistemic Domain Registry  . . . . . . . . . . . . .  19
       12.4.  WCA Media Types  . . . . . . . . . . . . . . . . . . . .  19
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       13.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Appendix A.  Formal Security Properties . . . . . . . . . . . . .  22
       A.1.  Property 1: No Channel-Based Semantic Laundering  . . . .  22
       A.2.  Property 2: Self-Licensing Prevention under
             Non-Interference  . . . . . . . . . . . . . . . . . . . .  22
       A.3.  Property 3: Provenance Completeness . . . . . . . . . . .  22
       A.4.  Property 4: Query-Response Binding  . . . . . . . . . . .  22
       A.5.  Property 5: Warrant Erosion Auditability  . . . . . . . .  23
       A.6.  Composability . . . . . . . . . . . . . . . . . . . . . .  23
     Appendix B.  TLA+ Model Summary . . . . . . . . . . . . . . . . .  23
     Appendix C.  Comparison with Related Systems  . . . . . . . . . .  23
     Appendix D.  JSON Serialization Examples  . . . . . . . . . . . .  24
       D.1.  Warrant Certificate . . . . . . . . . . . . . . . . . . .  24
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     The rapid deployment of Large Language Model (LLM)-based agent
     architectures has created a category of data provenance risk that
     existing security frameworks do not address.  When AI agents invoke
     external tools -- APIs, databases, web scrapers, knowledge graphs --
     they implicitly trust the data returned.  A response from a trusted
     API may have originated from a retracted study passed through several
     interpretive layers, yet the agent treats all tool outputs uniformly
     as "tool output," conflating the channel's trustworthiness with the
     content's actual provenance.



  Bondar                  Expires 2 September 2026                [Page 3]


  Internet-Draft                     WCA                        March 2026


     This problem is structurally analogous to the blockchain oracle
     problem [CHAINLINK], where smart contracts must rely on external data
     feeds without the ability to verify their correctness on-chain.
     However, AI-agent systems face an additional dimension: not merely
     data accuracy, but preservation of epistemic justification across
     architectural boundaries.

     Prior work [SEMANTIC-LAUNDERING] formalized two phenomena:

     *  Warrant Erosion: the inevitable degradation of epistemic
        justification through interpretive processing.

     *  Semantic Laundering: the acquisition of unwarranted credibility by
        data crossing trusted tool boundaries, constituting a channel-to-
        content trust conflation.

     The same authors [RESPONSIBILITY-VACUUM] demonstrated that human
     oversight undergoes a phase transition from genuine evaluation to
     ritualized approval at sufficient throughput, establishing that
     content-evaluating mediators cannot scale.

     This document specifies the Warrant Certificate Authority (WCA), an
     infrastructure that certifies data sources rather than data content.
     The key insight is architectural: just as PKI Certificate Authorities
     certify server identity without evaluating web page content, WCA
     certifies the institutional standing of data sources without judging
     the truth of individual responses.

     This design is structurally analogous to provenance layers in
     operating systems:

     *  IMA (Integrity Measurement Architecture) [IMA] tracks what code
        ran on a system via kernel-level measurement and TPM anchoring.

     *  CamFlow [CAMFLOW] tracks all information flows as a provenance
        monitor satisfying the reference monitor concept.

     *  LPM (Linux Provenance Modules) [LPM] provides 170 provenance hooks
        parallel to LSM security hooks with 2.7% overhead.

     *  PASS [PASS] introduced provenance-aware storage at the filesystem
        level.

     None of these systems evaluate the correctness or meaning of the data
     they track.  They provide complete, tamperproof, verifiable records
     of what happened.  WCA provides the same for AI agent tool calls: not
     judgment, but attestation.




  Bondar                  Expires 2 September 2026                [Page 4]


  Internet-Draft                     WCA                        March 2026


     This document makes the following contributions:

     1.  Specification of data structures for tool-call attestation,
         warrant certificates, and a hierarchical trust model for
         certificate authorities.

     2.  A provenance-layer protocol satisfying reference monitor
         properties (complete mediation, tamperproofness, verifiability)
         for AI agent tool calls.

     3.  Warrant Attestation Levels (WAL-0 through WAL-3): a graduated
         adoption framework analogous to SLSA [SLSA] build levels,
         providing practical deployment milestones.

     4.  Non-interference requirements and mitigation strategies for
         mediated self-licensing risks.

     5.  Security analysis covering response substitution, self-licensing,
         replay attacks, source impersonation, and attestation log
         tampering.

  2.  Conventions and Terminology

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

     The following terms are used throughout this document:

     Agent:  An LLM-based system that invokes external tools and data
        sources to accomplish tasks.

     Attestation:  A cryptographically signed record binding a specific
        query to a specific response from an identified source at a
        specific time.

     Attestation Log:  An append-only, hash-chained sequence of
        attestation records maintained by the provenance layer.

     Channel-to-Content Trust Conflation:  The error of treating a
        communication channel's trustworthiness as evidence for the
        trustworthiness of specific data transmitted through that channel.

     Domain WCA:  An intermediate certificate authority covering a
        specific epistemic domain, subordinate to a Root WCA.




  Bondar                  Expires 2 September 2026                [Page 5]


  Internet-Draft                     WCA                        March 2026


     Epistemic Domain:  A bounded field of knowledge within which a
        source's institutional authority applies (e.g., "pharmacology",
        "legal-records").

     Epistemic Warrant:  The structured justification backing a
        proposition, comprising observations, inference rules, and
        institutional attestations.  WCA operationalizes only the
        institutional attestation component.

     Institutional Anchor:  The organizational basis for a source's
        authority within its epistemic domain.

     Non-Interference:  The condition that an agent is purely a consumer
        of registered source data, with no pathway to modify or influence
        what registered sources store or return.

     Provenance Layer:  The mandatory intermediary component that mediates
        all tool calls between agent and external sources.

     Root WCA:  The top-level certificate authority in a WCA hierarchy.

     Semantic Laundering:  The phenomenon whereby weakly warranted data
        acquires unwarranted epistemic status by crossing a trusted tool-
        call boundary.

     Self-Licensing:  The condition where an agent generates a proposition
        and subsequently treats it as externally warranted.

     Source:  An external system that provides data to agents via tool
        calls.

     Trusted Source Registry:  A registry maintained by WCA operators
        containing registered sources with their public keys, epistemic
        domains, and institutional anchors.

     Warrant Certificate (WC):  A compound data structure comprising a
        tool-call attestation, the source's certificate, and a chain proof
        to a trusted Root WCA.

     Warrant Attestation Level (WAL):  One of four graduated levels (WAL-0
        through WAL-3) specifying increasing provenance guarantees for
        agent systems.

     W_institutional(s, D):  The institutional warrant of source s in
        domain D.

  3.  Problem Statement




  Bondar                  Expires 2 September 2026                [Page 6]


  Internet-Draft                     WCA                        March 2026


  3.1.  Warrant Erosion

     Epistemic warrant is a structured object, not a scalar:

     warrant(p) = <O, I, S>
     where:
       O = {observations grounding p}
       I = {admissible inference rules deriving p from O}
       S = {signed attestations from institutional sources}

     For any interpretive process f:

     warrant(f(p)) is a subset of warrant(p) by O and I

     Interpretation can only lose observations and inference rules, never
     gain them.  This is the Warrant Erosion Principle
     [SEMANTIC-LAUNDERING].

  3.2.  Semantic Laundering

     Semantic laundering occurs when:

     Laundering(p, t) iff
       S(p) = {} AND trusted(t) AND agent_assigns(W(p) >= W_min)

     Data without institutional attestation gains "warranted" status
     solely by crossing a trusted tool-call interface.  This constitutes
     channel-to-content trust conflation.

  3.3.  Insufficiency of Content-Evaluating Mediators

     For any mediator M that evaluates content:

     evaluates_content(M) implies
       there exists boundary b_M such that
         Laundering(p, b_M) is possible

     The argument proceeds in four steps: (a) M must identify proposition
     boundaries (semantic judgment), (b) M must define canonical
     representations (representational assumptions), (c) M must assign
     warrant status (ritualizes under throughput [RESPONSIBILITY-VACUUM]),
     (d) M's "certified" label becomes a new laundering channel.

     This result motivates WCA's design: certify sources, not content.







  Bondar                  Expires 2 September 2026                [Page 7]


  Internet-Draft                     WCA                        March 2026


  4.  Architecture Overview

  4.1.  Design Principle

     WCA certifies sources, not content.  This distinction avoids the
     mediator vulnerability.  Evaluating content requires semantic
     judgment that scales poorly; certifying provenance requires only
     identity verification and institutional audit -- operations performed
     at registration time, not per-query.

  4.2.  System Components

     A WCA deployment consists of:

     *  Root WCA: Top-level certificate authority.

     *  Domain WCAs: Intermediate CAs for specific epistemic domains.

     *  Trusted Source Registry (R): Authorized data sources with keys and
        domain assignments.

     *  Provenance Layer: Enforcement component mediating all tool calls.

     *  Attestation Log (L): Append-only, hash-chained transaction log.

     *  Registered Sources: Data providers implementing WCA signing.

























  Bondar                  Expires 2 September 2026                [Page 8]


  Internet-Draft                     WCA                        March 2026


     +--------------+
     |  LLM Agent   |
     +------+-------+
            | query q + nonce n
            v
     +------+---------------------------+
     |      PROVENANCE LAYER            |
     |  +-----------------------------+ |
     |  | 1. Log outgoing query       | |
     |  | 2. Lookup source in R       | |
     |  | 3. Route query to source    | |
     |  | 4. Receive signed response  | |
     |  | 5. Verify signature + cert  | |
     |  | 6. Build warrant certificate| |
     |  | 7. Append to attestation log| |
     |  | 8. Deliver (r, WC) or REJECT| |
     |  +-----------------------------+ |
     +------+---------------------------+
            | response r + WC (or rejection)
            v
     +------+-------+
     | Tool / Source |
     | (signs r)    |
     +--------------+

  5.  Data Structures

  5.1.  Trusted Source Registry Entry

     {
       "source_id":   "urn:wca:source:<name>",
       "public_key":  "<SubjectPublicKeyInfo>",
       "domain":      "urn:wca:domain:<domain-name>",
       "anchor":      { "organization": "...", "basis": "..." },
       "valid_from":  "<DateTime>",
       "valid_until": "<DateTime>",
       "issuer_wca":  "urn:wca:authority:<wca-name>",
       "revocation":  { "crl_uri": "...", "ocsp_uri": "..." }
     }

     source_id:  Globally unique URI using the "urn:wca:source:" prefix.

     public_key:  MUST be ECDSA P-256 [RFC6979] or Ed25519 [RFC8032].

     domain:  MUST be from the WCA Epistemic Domain Registry
        (Section 12.3).

     anchor:  Institutional basis for authority, populated during



  Bondar                  Expires 2 September 2026                [Page 9]


  Internet-Draft                     WCA                        March 2026


        registration audit.

     valid_from / valid_until:  Validity period.  Source certificates
        SHOULD have a maximum validity of one year.  Renewal requires re-
        audit.

  5.2.  Tool-Call Attestation

     For query q from agent a to source s returning response r:

     signature = Sign(K_priv_s,
                      H(query || response || timestamp ||
                        nonce || agent_id))

     where Sign() is ECDSA-P256-SHA256 [RFC6979] or Ed25519 [RFC8032], H()
     is SHA-256 [RFC6234], and || denotes concatenation of canonical byte
     encodings.

     Each field MUST be prefixed with a 4-byte big-endian length followed
     by the field bytes.

     The source MUST sign the binding of all five components.  Nonce
     inclusion prevents replay; agent_id inclusion prevents cross-agent
     substitution.

     Protocol:

     1.  Agent generates query q and cryptographically random nonce n (>=
         16 bytes).

     2.  Provenance layer forwards (q, agent_id, n) to source s.

     3.  Source computes response r.

     4.  Source obtains timestamp tau from a trusted time source.

     5.  Source computes signature.

     6.  Source returns (r, tau, signature).

     7.  Provenance layer verifies using K_pub_s from R.

  5.3.  Warrant Certificate








  Bondar                  Expires 2 September 2026               [Page 10]


  Internet-Draft                     WCA                        March 2026


     {
       "attestation":        "<ToolCallAttestation>",
       "source_certificate": "<SourceCertificate>",
       "chain_proof":        ["<CertificateChainEntry>"]
     }

     The SourceCertificate issuer_signature is:

     issuer_signature = Sign(K_priv_WCA,
                             H(source_id || public_key ||
                               domain || anchor ||
                               valid_from || valid_until))

  5.4.  WCA Certificate

     {
       "wca_id":           "urn:wca:authority:<name>",
       "public_key":       "<SubjectPublicKeyInfo>",
       "domain_scope":     ["urn:wca:domain:<d1>", "..."],
       "trust_anchor":     { "organization": "...", "basis": "..." },
       "parent_wca":       "urn:wca:authority:<parent>" or null,
       "valid_from":       "<DateTime>",
       "valid_until":      "<DateTime>",
       "parent_signature": "<OCTET STRING>" or null
     }

     Root WCA certificates are self-signed.  Domain WCA certificates MUST
     be signed by their parent WCA.  WCA key pairs MUST be generated and
     stored in HSMs.  Root WCA key generation MUST use multi-party key
     ceremony procedures.

  5.5.  Attestation Log Entry

     {
       "sequence_number": 42,
       "query":           "<exact bytes>",
       "source_id":       "urn:wca:source:<name>",
       "response":        "<exact bytes>",
       "signature":       "<base64>",
       "timestamp":       "<DateTime>",
       "warrant_cert":    "<WarrantCertificate>",
       "previous_hash":   "<hex>",
       "entry_hash":      "<hex>"
     }







  Bondar                  Expires 2 September 2026               [Page 11]


  Internet-Draft                     WCA                        March 2026


     entry_hash is computed over all preceding fields.  previous_hash
     links to the predecessor.  The log MUST be append-only.
     Implementations SHOULD periodically commit the chain head to an
     external transparency log.

  6.  WCA Trust Hierarchy

  6.1.  Root WCA

     *  MUST store private key in HSM with multi-party access controls.

     *  MUST use offline key storage.

     *  MUST maintain Certificate Transparency log of issued Domain WCA
        certificates.

     *  SHOULD be operated by a consortium or standards body.

  6.2.  Domain WCA

     *  MUST have certificate signed by Root or parent Domain WCA.

     *  MUST specify domain_scope.

     *  MUST perform institutional audit before issuing source
        certificates.

     *  MUST maintain CRL or operate OCSP responder.

     Example hierarchy:

     Root WCA (global trust anchor)
       |
       +-- Health WCA (medicine, pharmacology, genomics)
       |     +-- urn:wca:source:fda-druginteractions-v3
       |     +-- urn:wca:source:pubmed-api-v2
       |
       +-- Legal WCA (legal-records, court-rulings)
       |     +-- urn:wca:source:pacer-federal-courts
       |
       +-- Meteorological WCA (weather, climate)
             +-- urn:wca:source:noaa-weather-api-v3

  6.3.  Source Certificates

     Issuance requires: (1) institutional audit, (2) key verification, (3)
     domain validation.  Certificates SHOULD have maximum one-year
     validity.  Renewal MUST include re-audit.



  Bondar                  Expires 2 September 2026               [Page 12]


  Internet-Draft                     WCA                        March 2026


  6.4.  Certificate Lifecycle

     Issuance -> Active -> Renewal (with re-audit) or Revocation.
     Revocation triggers: key compromise, institutional standing change,
     misrepresentation of data sourcing, WCA operator determination.

     Provenance layer MUST check revocation before accepting signatures.
     Implementations SHOULD cache revocation status (max 24 hours).

  7.  Provenance Layer Protocol

  7.1.  Protocol Flow

     Step 1 - Query Registration:  Agent submits query q with fresh nonce
        n.  Provenance layer records (q, agent_id, n, timestamp_local).

     Step 2 - Source Lookup:  Consult R; verify source is registered and
        certificate is valid.  If invalid, MUST reject and log rejection
        with reason code.

     Step 3 - Query Routing:  Forward (q, agent_id, n) to source over
        authenticated channel.  SHOULD use mTLS.

     Step 4 - Response Receipt:  Source computes r, obtains tau, signs
        binding, returns (r, tau, signature).

     Step 5 - Signature Verification:  Verify using K_pub_s from Cert_s.
        On failure, MUST reject, MUST log failure, MUST NOT deliver to
        agent.

     Step 6 - Warrant Certificate Construction:  Assemble WC =
        (Att(q,s,r), Cert_s, ChainProof).

     Step 7 - Attestation Log Append:  Append e_i = (seq_i, q, s_id, r,
        signature, tau, WC, H(e_{i-1})).

     Step 8 - Delivery or Rejection:  Deliver (r, WC) or rejection notice.
        Rejected data MUST NOT enter agent reasoning context.

     Warrant assignment upon delivery:

     W(r | valid WC from source s in domain D) = W_institutional(s, D)
     W(r | invalid WC or absent WC)            = 0

  7.2.  Reference Monitor Properties

     The provenance layer MUST satisfy three properties per [ANDERSON] and
     [CAMFLOW]:



  Bondar                  Expires 2 September 2026               [Page 13]


  Internet-Draft                     WCA                        March 2026


     RM1 - Complete Mediation:  Every external data access by the agent
        MUST pass through the provenance layer.  The agent MUST NOT have
        direct network access to external sources.  SHOULD be enforced via
        network isolation.

     RM2 - Tamperproofness:  Attestation log MUST be append-only and hash-
        chained.

     RM3 - Verifiability:  Any party with log access and public keys MUST
        be able to independently verify every entry.

  7.3.  Attestation Log

     The log MUST be append-only and hash-chained.  Implementations SHOULD
     replicate to external audit services.  SHOULD define retention policy
     per regulatory context.  SHOULD periodically commit chain head to
     external transparency log.

  8.  Warrant Attestation Levels

  8.1.  WAL-0: No Provenance

     Baseline state.  No guarantees.  Default for current agent systems.

  8.2.  WAL-1: Provenance Exists

     Source identification recorded; cryptographic verification MAY be
     absent.  Provenance layer MUST log source identity and responses.
     Post-hoc attribution possible but not cryptographically verified.
     Adoption cost: minimal (middleware only).

  8.3.  WAL-2: Signed Provenance

     Sources MUST sign responses per Section 5.2.  Source keys MUST be
     certified by Domain WCA.  Provenance layer MUST verify signatures.
     Guarantees: query-response binding, source authenticity, anti-
     laundering bound.  Adoption cost: moderate.

  8.4.  WAL-3: Full Verification

     Provenance layer MUST satisfy RM1-RM3.  All tool calls MUST be logged
     in hash-chained attestation log.  Agents MUST generate signed queries
     with nonces.  Non-interference MUST be enforced or M2 MUST be
     implemented (Section 9.3).  Guarantees: all five security properties
     (Appendix A).  Adoption cost: highest.






  Bondar                  Expires 2 September 2026               [Page 14]


  Internet-Draft                     WCA                        March 2026


           +==========================+=========+=================+
           | Use Case                 | Min WAL | Rationale       |
           +==========================+=========+=================+
           | Exploratory research     | WAL-0   | Low stakes      |
           +--------------------------+---------+-----------------+
           | General info retrieval   | WAL-1   | Post-hoc review |
           +--------------------------+---------+-----------------+
           | Business intelligence    | WAL-2   | Source verify   |
           +--------------------------+---------+-----------------+
           | Medical decision support | WAL-3   | Safety-critical |
           +--------------------------+---------+-----------------+
           | Legal research           | WAL-3   | Regulatory      |
           +--------------------------+---------+-----------------+
           | Financial trading        | WAL-3   | Fiduciary duty  |
           +--------------------------+---------+-----------------+

                                   Table 1

  8.5.  Migration Path

     Phase 1 (WAL-0 to WAL-1): Deploy logging middleware.  Phase 2 (WAL-1
     to WAL-2): Source signing + Domain WCA setup.  Phase 3 (WAL-2 to WAL-
     3): Full RM1-RM3 + attestation log.

  9.  Non-Interference Requirements

  9.1.  Definition

     Agent a satisfies non-interference w.r.t. registry R iff:

     NI-1:  a has no write access to any registered source s in R.

     NI-2:  a does not control or operate any registered source s in R.

     NI-3:  a cannot influence the stored state of any upstream system
        feeding s in R.

     WAL-3 deployments MUST enforce non-interference or implement an
     equivalent mitigation.

  9.2.  Mediated Self-Licensing Risk

     When NI-1 is violated, the following loop is possible:

     1.  Agent generates content.

     2.  Agent writes content to registered source.




  Bondar                  Expires 2 September 2026               [Page 15]


  Internet-Draft                     WCA                        March 2026


     3.  Agent queries that source.

     4.  Source returns content with valid signature.

     5.  Provenance layer issues WC.

     6.  Agent's own content carries institutional warrant.

     TLA+ model checking confirms: with non-interference, 286 states
     explored, no self-licensing.  Without: counterexample in 3
     transitions.

  9.3.  Mitigation Strategies

     WAL-3 deployments MUST enforce at least one:

     M1 - Non-Interference at Deployment:  Read-only access to registered
        sources.  Strongest mitigation.

     M2 - Origin-Aware Warrant Assignment:  If data in source was written
        by agent a, queries from a receive W = 0.

     M3 - Institutional Transformation Gate:  Agent-written data undergoes
        institutional process (peer review, QA) before becoming queryable
        with warrant.

  10.  Integration Considerations

  10.1.  Agent Framework Integration

     LangChain/LangGraph:  Provenance layer as BaseTool.invoke() wrapper.

     AutoGen/AG2:  Shared provenance layer at tool execution boundary.

     Model Context Protocol (MCP):  MCP servers implement signing; MCP
        clients verify via provenance layer.

     OpenAI Function Calling / Anthropic Tool Use:  Provenance layer wraps
        function execution step.

  10.2.  Source-Side Requirements

     Sources at WAL-2+ MUST: generate key pair (ECDSA P-256 or Ed25519),
     implement signing endpoint, undergo institutional audit, implement
     certificate renewal and key rotation.

     Sources SHOULD: use HSMs, implement rate limiting, monitor for
     anomalous signing.



  Bondar                  Expires 2 September 2026               [Page 16]


  Internet-Draft                     WCA                        March 2026


  10.3.  Performance Considerations

     Per-query overhead: sub-millisecond for cryptographic operations.
     Ed25519 signs at ~70K ops/sec, verifies at ~30K ops/sec.  SHA-256 >1
     GB/s.  Dominated by network latency.

     LPM demonstrated 2.7% overhead for whole-system kernel provenance;
     WCA at tool-call granularity is expected negligible.

  11.  Security Considerations

  11.1.  Threat Model

     Attacker can: MITM traffic, operate malicious sources, inject
     unattested data, replay responses, impersonate sources, tamper with
     log.

     Trust assumptions: Root WCA key security (HSM), sound crypto
     primitives, correct RM1-RM3 enforcement, institutional audit at
     registration.

     Out of scope: registered source providing incorrect data (source
     quality, not provenance).

  11.2.  Response Substitution

     Defense: signature covers H(q || r || tau || nonce || agent_id).
     Modification detected.  Residual: key compromise (standard PKI
     mitigations).

  11.3.  Agent Self-Licensing

     Defense: non-interference prevents registration and indirect
     pathways.  W = 0 for agent-generated propositions.  Residual: NI
     violation enables mediated self-licensing (Section 9.3).

  11.4.  Replay Attacks

     Defense: nonce in signature binding.  Timestamp enables freshness.
     Implementations MUST use >= 16 byte random nonces.

  11.5.  Source Impersonation

     Defense: certificate chain to Root WCA.  Residual: WCA compromise.







  Bondar                  Expires 2 September 2026               [Page 17]


  Internet-Draft                     WCA                        March 2026


  11.6.  WCA Compromise

     Defense: HSMs, multi-party ceremonies, CT logs, CRLs/OCSP, short-
     lived certificates.

  11.7.  Attestation Log Tampering

     Defense: hash chain; modification cascades.  External transparency
     log anchoring for additional assurance.

  11.8.  Limitations

     WCA does NOT defend against: source inaccuracy, domain mismatch,
     agent reasoning errors, WCA-source collusion, interpretive warrant
     erosion (but preserves originals in log for audit).

  12.  IANA Considerations

  12.1.  WCA URN Namespace

     This document requests registration of formal URN namespace "wca" per
     [RFC8141].

     Syntax: urn:wca:<entity-type>:<entity-name>

     Entity types: "authority", "source", "domain".

  12.2.  WAL Level Registry

     New IANA registry "Warrant Attestation Levels":

                 +=======+===================+===============+
                 | Level | Name              | Reference     |
                 +=======+===================+===============+
                 | 0     | No Provenance     | This document |
                 +-------+-------------------+---------------+
                 | 1     | Provenance Exists | This document |
                 +-------+-------------------+---------------+
                 | 2     | Signed Provenance | This document |
                 +-------+-------------------+---------------+
                 | 3     | Full Verification | This document |
                 +-------+-------------------+---------------+

                                    Table 2

     New levels require Standards Action [RFC8126].





  Bondar                  Expires 2 September 2026               [Page 18]


  Internet-Draft                     WCA                        March 2026


  12.3.  WCA Epistemic Domain Registry

     New IANA registry "WCA Epistemic Domains" with initial entries:

            +==================+==================================+
            | Domain           | Description                      |
            +==================+==================================+
            | pharmacology     | Drug data, interactions          |
            +------------------+----------------------------------+
            | medical-records  | Clinical records                 |
            +------------------+----------------------------------+
            | medical-lit      | Peer-reviewed medical literature |
            +------------------+----------------------------------+
            | legal-records    | Court records, filings           |
            +------------------+----------------------------------+
            | legal-lit        | Legal scholarship                |
            +------------------+----------------------------------+
            | meteorology      | Weather, climate                 |
            +------------------+----------------------------------+
            | genomics         | Genomic sequences                |
            +------------------+----------------------------------+
            | financial-reg    | Regulatory filings               |
            +------------------+----------------------------------+
            | financial-market | Market data                      |
            +------------------+----------------------------------+
            | geospatial       | Geographic, satellite data       |
            +------------------+----------------------------------+

                                    Table 3

     New domains require Specification Required [RFC8126].

  12.4.  WCA Media Types

     application/wca-warrant-certificate+json:  JSON serialization of
        Warrant Certificates.

     application/wca-attestation-log+json:  JSON serialization of
        Attestation Log entries.

  13.  References

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



  Bondar                  Expires 2 September 2026               [Page 19]


  Internet-Draft                     WCA                        March 2026


     [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and SHA-based HMAC and HKDF)", RFC 6234,
                DOI 10.17487/RFC6234, May 2011,
                <https://www.rfc-editor.org/rfc/rfc6234>.

     [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
                Algorithm (DSA) and Elliptic Curve Digital Signature
                Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
                2013, <https://www.rfc-editor.org/rfc/rfc6979>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

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

     [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
                (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
                <https://www.rfc-editor.org/rfc/rfc8141>.

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

  13.2.  Informative References

     [ANDERSON] Anderson, J. P., "Computer Security Technology Planning
                Study", Technical Report ESD-TR-73-51, 1972.

     [AUTH-PROMPTS]
                Rajagopalan, M. and V. Rao, "Protecting Context and
                Prompts: Deterministic Security for Non-Deterministic AI",
                arXiv 2602.10481, 2026.

     [BAID]     Lin, Z., Zhang, S., Liao, G., Tao, D., and T. Wang,
                "Binding Agent ID", arXiv 2512.17538, 2025.

     [CAMEL]    Debenedetti, E., Shumailov, I., and T. Fan, "Defeating
                Prompt Injections by Design", arXiv 2503.18813, 2025.



  Bondar                  Expires 2 September 2026               [Page 20]


  Internet-Draft                     WCA                        March 2026


     [CAMFLOW]  Pasquier, T., Han, X., Goldstein, M., Moyer, T., Eyers,
                D., Seltzer, M., and J. Bacon, "Practical Whole-System
                Provenance Capture", arXiv 1711.05296, 2017.

     [CHAINLINK]
                Ellis, S., Juels, A., and S. Nazarov, "Chainlink: A
                Decentralized Oracle Network", White Paper, 2017.

     [CIV]      Gupta, A., "CIV: Can AI Keep a Secret? Contextual
                Integrity Verification", arXiv 2508.09288, 2025.

     [DIDS-VCS] Garzon, S. R., "AI Agents with Decentralized Identifiers
                and Verifiable Credentials", arXiv 2511.02841, 2025.

     [GETTIER]  Gettier, E. L., "Is Justified True Belief Knowledge?",
                Analysis Vol. 23, No. 6, pp. 121-123, 1963.

     [IMA]      Linux IMA, "Integrity Measurement Architecture", n.d.,
                <https://sourceforge.net/p/linux-ima/wiki/Home/>.

     [IN-TOTO]  in-toto Project, "A Framework for Securing Software Supply
                Chains", n.d., <https://in-toto.io/>.

     [LPM]      Bates, A., Tian, D. J., Butler, K. R. B., and T. Moyer,
                "Trustworthy Whole-System Provenance for the Linux
                Kernel", USENIX Security Symposium, 2015.

     [MAIF]     Narajala, V. S., "MAIF: Enforcing AI Trust and Provenance
                with an Artifact-Centric Paradigm", arXiv 2511.15097,
                2025.

     [OMEGA]    Stavrakakis, D., "Trusted AI Agents in the Cloud",
                arXiv 2512.05951, 2025.

     [PASS]     Muniswamy-Reddy, K., Holland, D. A., Braun, U., and M.
                Seltzer, "Provenance-Aware Storage Systems", USENIX ATC,
                2006.

     [PROV-AGENT]
                Souza, R., "PROV-AGENT: Unified Provenance for AI Agent
                Interactions", arXiv 2508.02866, 2025.

     [RAG-SIGN] Holmes, S. A., "RAG Sign: Cryptographic Authentication for
                RAG-Enabled LLMs", Springer LNCS 15692, 2025.







  Bondar                  Expires 2 September 2026               [Page 21]


  Internet-Draft                     WCA                        March 2026


     [RESPONSIBILITY-VACUUM]
                Romanchuk, O. and R. Bondar, "The Responsibility Vacuum:
                Organizational Failure in Scaled Agent Systems",
                arXiv 2601.15059, January 2026,
                <https://arxiv.org/abs/2601.15059>.

     [SEMANTIC-LAUNDERING]
                Romanchuk, O. and R. Bondar, "Semantic Laundering in AI
                Agent Architectures: Why Tool Boundaries Do Not Confer
                Epistemic Warrant", arXiv 2601.08333, January 2026,
                <https://arxiv.org/abs/2601.08333>.

     [SLSA]     OpenSSF, "SLSA: Supply-chain Levels for Software
                Artifacts", n.d., <https://slsa.dev/>.

     [SPIFFE]   SPIFFE Project, "Secure Production Identity Framework for
                Everyone", n.d., <https://spiffe.io/>.

     [VFA]      Gupta, A., "Verifiability-First Agents", arXiv 2512.17259,
                2025.

  Appendix A.  Formal Security Properties

     All properties assume RM1-RM3 and EUF-CMA signature security.

  A.1.  Property 1: No Channel-Based Semantic Laundering

     For all p received by agent a: W(p) <= W_institutional(source(p)).
     Data cannot gain warrant above source's institutional standing.

  A.2.  Property 2: Self-Licensing Prevention under Non-Interference

     For all p generated by agent a: if NonInterference(a, R) then W(p) =
     0.

  A.3.  Property 3: Provenance Completeness

     For all data d in agent context: either d has attestation log entry
     with valid WC, or W(d) = 0.

  A.4.  Property 4: Query-Response Binding

     Valid signature implies r is exactly what source s returned to query
     q at time tau.  Substitution detectable.







  Bondar                  Expires 2 September 2026               [Page 22]


  Internet-Draft                     WCA                        March 2026


  A.5.  Property 5: Warrant Erosion Auditability

     Agent interpretation may degrade warrant, but original data and
     attestation are always recoverable from log L.

  A.6.  Composability

     Multi-hop chains: W(final) = min_i(W_institutional(source_i)).  No
     laundering through composition.

  Appendix B.  TLA+ Model Summary

     Model verified with TLC:

     *  WCA_Strict.cfg (non-interference): PASS, 286 states.

     *  WCA_MediatedLoop.cfg (NI violated): FAIL, counterexample in 3
        transitions (agent generates, writes to source, queries back with
        warrant > 0).

  Appendix C.  Comparison with Related Systems

       +=============================+========================+=======+
       | Dimension                   | Covered By             | WCA   |
       +=============================+========================+=======+
       | Agent identity              | BAID, DIDs+VCs, SPIFFE | --    |
       +-----------------------------+------------------------+-------+
       | Execution environment       | Omega, TEEs            | --    |
       +-----------------------------+------------------------+-------+
       | Action audit trails         | PROV-AGENT, VFA, MAIF  | --    |
       +-----------------------------+------------------------+-------+
       | Access control              | CaMeL                  | --    |
       +-----------------------------+------------------------+-------+
       | Prompt/context integrity    | Auth.  Prompts, CIV    | --    |
       +-----------------------------+------------------------+-------+
       | Output signing              | RAG Sign               | --    |
       +-----------------------------+------------------------+-------+
       | *Data source warrant*       | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *Anti-channel-laundering*   | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *Self-licensing prevention* | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *End-to-end attestation*    | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+

                                   Table 4




  Bondar                  Expires 2 September 2026               [Page 23]


  Internet-Draft                     WCA                        March 2026


  Appendix D.  JSON Serialization Examples

  D.1.  Warrant Certificate

     {
       "attestation": {
         "query": "GET /interactions?drug_a=ibuprofen&drug_b=warfarin",
         "source_id": "urn:wca:source:fda-druginteractions-v3",
         "response": "{\"interaction\":\"major\",\"severity\":\"high\"}",
         "timestamp": "2026-02-12T14:30:00Z",
         "nonce": "a7f3c9e1d4b2f6a8e0c7d3b5a9f1e2c4",
         "agent_id": "urn:agent:medical-advisor-v2",
         "signature": "MEUCIQD.../base64...=="
       },
       "source_certificate": {
         "source_id": "urn:wca:source:fda-druginteractions-v3",
         "public_key": "MFkwEwYHKoZIzj0.../base64...",
         "domain": "urn:wca:domain:pharmacology",
         "anchor": {
           "organization": "U.S. Food and Drug Administration",
           "basis": "Federal regulatory mandate",
           "audit_date": "2026-01-15"
         },
         "valid_from": "2026-01-01T00:00:00Z",
         "valid_until": "2027-01-01T00:00:00Z",
         "issuer_wca_id": "urn:wca:authority:health-wca-us",
         "issuer_signature": "MEUCIQCx.../base64...=="
       },
       "chain_proof": [
         {
           "wca_id": "urn:wca:authority:health-wca-us",
           "parent": "urn:wca:authority:root-wca-global-v1",
           "signature": "MEYCIQDp.../base64...=="
         }
       ]
     }

  Acknowledgments

     The foundational concepts of warrant erosion and semantic laundering
     were developed jointly with Oleg Romanchuk in [SEMANTIC-LAUNDERING]
     and [RESPONSIBILITY-VACUUM].

  Author's Address

     Roman Bondar
     Email: bondar.roman@gmail.com




  Bondar                  Expires 2 September 2026               [Page 24]


name: draft-ietf-savnet-inter-domain-architecture
rev: 03
title: Inter-domain Source Address Validation (SAVNET) Architecture
time: 2026-03-01T13:00:32Z
group_uri: /api/v1/group/group/2317/
expires: 2026-09-02T13:00:32Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:22.650896+00:00
source: ietf
abstract:
  This document introduces an inter-domain SAVNET architecture for
     performing AS-level SAV and provides a comprehensive framework for
     guiding the design of inter-domain SAV mechanisms.  The proposed
     architecture empowers ASes to generate SAV rules by sharing SAV-
     specific information between themselves, which can be used to
     generate more accurate and trustworthy SAV rules in a timely manner
     compared to the general information.  During the incremental or
     partial deployment of SAV-specific information, it can utilize
     general information to generate SAV rules, if an AS's SAV-specific
     information is unavailable.  Rather than delving into protocol
     extensions or implementations, this document primarily concentrates
     on proposing SAV-specific and general information and guiding how to
     utilize them to generate SAV rules.  To this end, it also defines
     some architectural components and their relations.

full_text:
  Internet Engineering Task Force                                    D. Li
  Internet-Draft                                       Tsinghua University
  Intended status: Standards Track                                 L. Chen
  Expires: 2 September 2026                        Zhongguancun Laboratory
                                                                   N. Geng
                                                                    Huawei
                                                                    L. Liu
                                                                    L. Qin
                                                   Zhongguancun Laboratory
                                                              1 March 2026


        Inter-domain Source Address Validation (SAVNET) Architecture
               draft-ietf-savnet-inter-domain-architecture-03

  Abstract

     This document introduces an inter-domain SAVNET architecture for
     performing AS-level SAV and provides a comprehensive framework for
     guiding the design of inter-domain SAV mechanisms.  The proposed
     architecture empowers ASes to generate SAV rules by sharing SAV-
     specific information between themselves, which can be used to
     generate more accurate and trustworthy SAV rules in a timely manner
     compared to the general information.  During the incremental or
     partial deployment of SAV-specific information, it can utilize
     general information to generate SAV rules, if an AS's SAV-specific
     information is unavailable.  Rather than delving into protocol
     extensions or implementations, this document primarily concentrates
     on proposing SAV-specific and general information and guiding how to
     utilize them to generate SAV rules.  To this end, it also defines
     some architectural components and their relations.

  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 2 September 2026.



  Li, et al.              Expires 2 September 2026                [Page 1]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  Copyright Notice

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

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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Inter-domain SAVNET Architecture Overview . . . . . . . . . .   7
     5.  SAV-related Information . . . . . . . . . . . . . . . . . . .  12
       5.1.  General Information . . . . . . . . . . . . . . . . . . .  12
         5.1.1.  RPKI ROA objects and ASPA Objects . . . . . . . . . .  12
         5.1.2.  Local Routing Information . . . . . . . . . . . . . .  13
         5.1.3.  IRR Data  . . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  SAV-specific Information  . . . . . . . . . . . . . . . .  13
     6.  SAV Information Base  . . . . . . . . . . . . . . . . . . . .  14
     7.  SAVNET Communication Mechanism  . . . . . . . . . . . . . . .  17
       7.1.  SAV-specific Information Communication Mechanism  . . . .  18
       7.2.  General Information Communication Mechanism . . . . . . .  21
       7.3.  Management Information Communication Mechanism  . . . . .  21
     8.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  22
       8.1.  SAV at Customer Interfaces  . . . . . . . . . . . . . . .  22
         8.1.1.  Limited Propagation of Prefixes . . . . . . . . . . .  22
         8.1.2.  Hidden Prefixes . . . . . . . . . . . . . . . . . . .  24
         8.1.3.  Reflection Attacks  . . . . . . . . . . . . . . . . .  25
         8.1.4.  Direct Attacks  . . . . . . . . . . . . . . . . . . .  27
       8.2.  SAV at Provider/Peer Interfaces . . . . . . . . . . . . .  28
         8.2.1.  Reflection Attacks  . . . . . . . . . . . . . . . . .  28
         8.2.2.  Direct Attacks  . . . . . . . . . . . . . . . . . . .  30
     9.  Meeting the Design Requirements of Inter-domain SAVNET  . . .  31
       9.1.  Improving Validation Accuracy over Existing Mechanisms  .  31
       9.2.  Working in Incremental/Partial Deployment . . . . . . . .  32
       9.3.  Reducing Operational Overhead . . . . . . . . . . . . . .  33
       9.4.  Guaranteeing Efficient Convergence  . . . . . . . . . . .  33
       9.5.  Providing Necessary Security Guarantee  . . . . . . . . .  34
     10. Manageability Considerations  . . . . . . . . . . . . . . . .  36



  Li, et al.              Expires 2 September 2026                [Page 2]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     11. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  36
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  37
     13. Scope and Assumptions . . . . . . . . . . . . . . . . . . . .  37
     14. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  38
     15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  38
       15.1.  Normative References . . . . . . . . . . . . . . . . . .  38
       15.2.  Informative References . . . . . . . . . . . . . . . . .  39
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  41
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

  1.  Introduction

     Attacks based on source IP address spoofing, such as reflective DDoS
     and flooding attacks, continue to present significant challenges to
     Internet security.  Mitigating these attacks in inter-domain networks
     requires effective source address validation (SAV).  While BCP84
     [RFC3704] [RFC8704] offers some SAV solutions, such as ACL-based
     ingress filtering and uRPF-based mechanisms, existing inter-domain
     SAV mechanisms have limitations in terms of validation accuracy and
     operational overhead in different scenarios
     [I-D.ietf-savnet-inter-domain-problem-statement].

     There are various existing general information from different sources
     including RPKI ROA objects and ASPA objects, RIB, FIB, and Internet
     Routing Registry (IRR) data, which can be used for inter-domain SAV.
     Generating SAV rules based on general information, however, cannot
     well satisfy the requirements for new inter-domain SAV mechanisms
     proposed in [I-D.ietf-savnet-inter-domain-problem-statement].  As
     analyzed in Section 5, general information from RPKI ROA objects and
     ASPA objects can be used to infer the prefixes and their permissible
     incoming directions yet cannot be updated in a timely manner to adapt
     to the prefix or route changes, and the local routing information,
     which represents the general information from RIB or FIB, cannot deal
     with the asymmetric routing scenarios and may lead to improper blocks
     or improper permits, while IRR data do not update in a timely manner
     either and are not always accurate.

     Consequently, to address these issues, the inter-domain SAVNET
     architecture focuses on providing a comprehensive framework and
     guidelines for the design and implementation of new inter-domain SAV
     mechanisms.  Inter-domain SAVNET architecture proposes SAV-specific
     information and uses it to generate SAV rules.  SAV-specific
     information consists of prefixes and their corresponding legitimate
     incoming direction to enter an AS.  Inter-domain SAVNET architecture
     can use it to generate more accurate SAV rules.  In order to gather
     the SAV-specific information, a SAV-specific information
     communication mechanism would be developed for origination,
     processing, propagation, and termination of the messages which carry



  Li, et al.              Expires 2 September 2026                [Page 3]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     the SAV-specific information, and it can be implemented by a new
     protocol or extending an existing protocol.  When the prefixes or
     routes change, it can update the SAV-specific information
     automatically in a timely manner.  Also, the inter-domain SAVNET
     architecture will communicate the SAV-specific information over a
     secure connection between authenticated ASes.

     Moreover, during the incremental/partial deployment period of the
     SAV-specific information, the inter-domain SAVNET architecture can
     leverage the general information to generate SAV rules, if the SAV-
     specific information of an AS is unavailable.  Multiple information
     sources may exist concurrently, to determine the one used for
     generating SAV rules, the inter-domain SAVNET architecture assigns
     priorities to the SAV-specific information and different general
     information and generates SAV rules using the SAV-related information
     with the highest-priority.  SAV-specific information has the highest
     priority and the priorities of RPKI ROA objects and ASPA objects,
     RIB, FIB, and IRR data decrease in turn.

     +-----------+
     | AS 1 (P1) #
     +-----------+ \
                    \           Spoofed Packets
                  +-+#+-------+ with Source Addresses in P1 +-----------+
                  |    AS 2   #-----------------------------#   AS 4    |
                  +-+#+-------+                             +-----------+
                    /
     +-----------+ /
     |   AS 3    #
     +-----------+
     AS 4 sends spoofed packets with source addresses in P1 to AS 3
     through AS 2.
     If AS 1 and AS 2 deploy inter-domain SAV, the spoofed packets
     can be blocked at AS 2.

        Figure 1: An example for illustrating the incentive of deploying
                       inter-domain SAVNET architecture.

     The inter-domain SAVNET architecture provides the incentive to deploy
     inter-domain SAV for operators.  Figure 1 illustrates this using an
     example.  P1 is the source prefix of AS 1, and AS 4 sends spoofing
     packets with P1 as source addresses to AS 3 through AS 2.  Assume AS
     4 does not deploy intra-domain SAV, these spoofing packets cannot be
     blocked by AS 4.  Although AS 1 can deploy intra-domain SAV to block
     incoming packets which spoof the addresses of AS 1, these spoofing
     traffic from AS 4 to AS 3 do not go through AS 1, so they cannot be
     blocked by AS 1.  Inter-domain SAVNET architecture can help in this
     scenario.  If AS 1 and AS 2 deploy inter-domain SAVNET architecture,



  Li, et al.              Expires 2 September 2026                [Page 4]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     AS 2 knows that the packets with P1 as source addresses should come
     from AS 1, and the spoofing packets can thus be blocked by AS 2 since
     they come from the incorrect direction.  Specifically, by proposing
     SAV-specific information and using it to generate SAV rules, the
     inter-domain SAVNET architecture gives more deployment incentive
     compared to existing inter-domain SAV mechanisms, which will be
     analyzed in Section 8.

     In addition, this document primarily proposes a high-level
     architecture for describing the communication flow of SAV-specific
     information and general information, guiding how to utilize the SAV-
     specific information and general information for generating SAV rules
     and deploy an inter-domain SAV mechanism between ASes.  This document
     does not specify protocol extensions or implementations.  Its purpose
     is to provide a conceptual framework and guidance for the design and
     development of inter-domain SAV mechanisms, allowing implementers to
     adapt and implement the architecture based on their specific
     requirements and network environments.

  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

     SAV Rule:
        The rule that indicates the validity of a specific source IP
        address or source IP prefix.

     SAV Table:
        The table or data structure that implements the SAV rules and is
        used for performing source address validation on the data plane.

     SAV-specific Information:
        The information that is specialized for SAV rule generation,
        includes the source prefixes and their legitimate incoming
        directions to enter an AS, and is gathered by the communication
        between ASes with the SAV-specific information communication
        mechanism.

     SAV-specific Information Communication Mechanism:
        The mechanism that is used to communicate SAV-specific information
        between ASes and can be implemented by a new protocol or an
        extension to an existing protocol.



  Li, et al.              Expires 2 September 2026                [Page 5]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     Local Routing Information:
        The information that is stored in ASBR's local RIB or FIB and can
        be used to generate SAV rules in addition to the routing purpose.

     General Information:
        The information that is not specialized for SAV but can be
        utilized to generate SAV rules, and is initially utilized for
        other purposes.  Currently, the general information consists of
        the information from RPKI ROA objects and ASPA objects, local
        routing information, and the one from IRR data.

     SAV-related Information:
        The information that can be used to generate SAV rules and
        includes SAV-specific information and general information.

     SAVNET Agent:
        The agent within a SAVNET-adopting AS that is responsible for
        gathering SAV-related information and utilizing it to generate SAV
        rules.

     SAV Information Base:
        SAV information base is a table or data structure for storing SAV-
        related information collected from different SAV information
        sources and is a component within SAVNET agent.

     SAV Information Base Manager:
        SAV information base manager maitains the SAV-related information
        in the SAV information base and uses it to generate SAV rule
        accordingly, and is a component within SAVNET agent.

     Improper Block:
        The validation results that the packets with legitimate source
        addresses are blocked improperly due to inaccurate SAV rules.

     Improper Permit:
        The validation results that the packets with spoofed source
        addresses are permitted improperly due to inaccurate SAV rules.

     Source AS:
        The AS which deploys SAVNET agent and communicates its own SAV-
        specific information to other ASes for generating SAV rules.

     Validation AS:
        The AS which deploys SAVNET agent and generates SAV rules
        according to the received SAV-specific information from source
        ASes.





  Li, et al.              Expires 2 September 2026                [Page 6]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  3.  Design Goals

     The inter-domain SAVNET architecture aims to improve SAV accuracy and
     facilitate partial deployment with low operational overhead, while
     guaranteeing convergence and providing security guarantees to the
     communicated information, which corresponds to the requirements for
     new inter-domain SAV mechanisms proposed in the inter-domain SAVNET
     architecture draft [I-D.ietf-savnet-inter-domain-problem-statement].
     The overall goal can be broken down into the following aspects:

     *  *G1*: The inter-domain SAVNET architecture should learn the real
        paths of source prefixes to any destination prefixes or
        permissible paths that can cover their real paths, and generate
        accurate SAV rules automatically based on the learned information
        to avoid improper blocks and reduce improper permits as much as
        possible.

     *  *G2*: The inter-domain SAVNET architecture should provide
        sufficient protection for the source prefixes of ASes that deploy
        it, even if only a portion of the Internet does the deployment.

     *  *G3*: The inter-domain SAVNET architecture should adapt to dynamic
        networks and asymmetric routing scenarios automatically.

     *  *G4*: The inter-domain SAVNET architecture should promptly detect
        the network changes and launch the convergence process in a timely
        manner, while reducing improper blocks and improper permits during
        the convergence process.

     *  *G5*: The inter-domain SAVNET architecture should provide security
        guarantees for the communicated SAV-specific information.

     Other design goals, such as low operational overhead and easy
     implementation, are also very important and should be considered in
     specific protocols or protocol extensions.

  4.  Inter-domain SAVNET Architecture Overview














  Li, et al.              Expires 2 September 2026                [Page 7]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


      +~~~~~~~~~~~~~~~~~~~~~~~~+       +--------------------+
      |RPKI Cache Server/IRR DB|       | AS X's Provider AS |
      +~~~~~~~~~~~~~~~~~~~~~~~~+       +------------+/\+/\+-+
        ROA & ASPA |                 BGP /            |  |
     Obj./IRR Data |            Message /             |  |
                   |                   /              |  | BGP
     +-----------+\/+----------------+\/+-+           |  | Message
     |                AS X                |  BGP  +--------------+
     | +--------------------------------+ |<------|AS X's Lateral|
     | |          SAVNET Agent          | |Message|   Peer  AS   |
     | +--------------------------------+ |       +--------------+
     +-----+/\+/\+----------------+/\+/\+-+
             |  |                   |  |
         BGP |  | SAV-specific      |  |
     Message |  | Message           |  |
     +------------------+           |  |
     |AS X's Customer AS|           |  |
     +-------+/\+-------+           |  |
               \                    |  |
            BGP \  SAV-specific     |  | BGP
         Message \ Message          |  | Message
         +------------------------------------+
         |          AS X's Customer AS        |
         | +--------------------------------+ |
         | |         SAVNET Agent           | |
         | +--------------------------------+ |
         +------------------------------------+
     AS X and one of its customer ASes have deployed SAVNET agent
     and can exchange SAV-specific information with each other.

                  Figure 2: Inter-domain SAVNET architecture.

     Figure 2 provides an overview of the inter-domain SAVNET
     architecture, showcasing an AS topology and the flow of SAV-related
     information among ASes.  The topology captures the full spectrum of
     AS relationships in the Internet, displaying all peer ASes of AS X
     including customers, lateral peers, and providers and the existence
     of multiple physical links between ASes.  Arrows in the figure
     indicate the direction of the corresponding SAV-related information
     from its source to AS X, such as gathering RPKI ROA objects and ASPA
     objects from RPKI cache server.  The inter-domain SAVNET architecture
     conveys the SAV-related information through various mediums such as
     SAV-specific messages, BGP messages, RTR messages, and FTP messages.
     Based on the SAV-related information, AS X generates SAV rules.  It
     is also worth noting that the inter-domain SAVNET architecture
     discusses AS-level inter-domain SAV.





  Li, et al.              Expires 2 September 2026                [Page 8]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     Figure 2 uses AS X as the representative to illustrate that what SAV-
     related information the SAVNET agent within AS X will collect and
     where the information is from.  AS X has deployed SAVNET agent and
     can generate SAV rules to perform inter-domain SAV by consolidating
     the SAV-related information.  It can obtain SAV-specific information
     from its customer AS which deploys SAVNET agent and local routing
     information originating from the BGP update messages of its neighbor
     ASes.  Also, AS X can obtain RPKI ROA objects and ASPA objects from
     RPKI cache server and IRR data from IRR database.

     The inter-domain SAVNET architecture proposes SAV-specific
     information, which is more accurate and trustworthy than existing
     general information, and can update in a timely manner.  SAV-specific
     information consists of prefixes and their legitimate incoming
     directions.  The SAVNET agent communicates SAV-specific information
     between ASes via SAV-specific messages, when prefixes or routes
     change, it can launch SAV-specific messages timely to update SAV-
     specific information.  Additionally, when SAVNET agent receives SAV-
     specific messages, it will validate whether the SAV-specific
     connections for communicating SAV-specific messages are authentic
     connections from authenticated ASes.  Therefore, when SAV-specific
     information of an AS is available, SAVNET agent will use it to
     generate SAV rules.

     Furthermore, if the SAV-specific information is needed to communicate
     between ASes, a new SAV-specific information communication mechanism
     would be developed to exchange the SAV-specific messages between ASes
     which carry the SAV-specific information.  It should define the data
     structure or format for communicating the SAV-specific information
     and the operations and timing for originating, processing,
     propagating, and terminating the SAV-specific messages.

     The SAVNET agent should launch SAV-specific messages to adapt to the
     route changes in a timely manner.  The SAV-specific information
     communication mechanism should handle route changes carefully to
     avoid improper blocks.  The reasons for leading to improper blocks
     may include late detection of route changes, delayed message
     transmission, or packet losses.  During the convergence process of
     the SAV-specific information communication mechanism, the inter-
     domain SAVNET architecture can use the information from RPKI ROA
     objects and ASPA objects to generate SAV rules until the convergence
     process is finished, since these information includes topological
     information and is more stable, and can thus avoid improper blocks.
     However, the detailed design of the SAV-specific information
     communication mechanism for dealing with route changes is outside the
     scope of this document.





  Li, et al.              Expires 2 September 2026                [Page 9]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     In the incremental/partial deployment stage of the inter-domain
     SAVNET architecture, when the SAV-specific information of some ASes
     is unavailable, SAVNET agent can leverage general information to
     generate SAV rules.  If all these general information is available,
     it is recommended to use RPKI ROA objects and ASPA objects to
     generate SAV rules.  Since compared to the local routing information
     and IRR data, they can provide authoritative prefixes and topological
     information and have less improper blocks.  The systematic
     recommendations for the utilizations of SAV-related information and
     the corresponding rationale will be illustrated in Section 6.

     SAV-specific information communication mechanism will require
     specifying a new inter-router (or inter-AS) communication protocol or
     modifying an existing one.  Therefore, while this is pursued, a new
     SAV mechanism that utilizes RPKI objects (e.g., ROA, ASPA) and BGP
     data (RIB/FIB) can be pursued.  The latter solution may have the
     potential for deployment in the near term since it utilizes existing
     SAV-related information and can be deployed by network operators by
     policy configuration on routers.

     For ASes that support a network controller, such as a multi-AS or
     single-AS controller, operators can deploy the SAVNET agent on the
     controller to represent the ASes it manages and communicate SAV-
     specific information with others.  Additionally, ASes managed by the
     same controller may obtain SAV-specific information directly from the
     controller without needing to communicate with each other.

     Regarding the security concerns, the inter-domain SAVNET architecture
     shares the similar security threats with BGP and can leverage
     existing BGP security mechanisms to enhance both session and content
     security.




















  Li, et al.              Expires 2 September 2026               [Page 10]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     +-----------------------------------------------------------+
     |                           AS X                            |
     | +-------------------------------------------------------+ |
     | |                      SAVNET Agent                     | |
     | | +---------------------+  +--------------------------+ | |
     | | | General Information |  | SAV-specific Information | | |
     | | +---------------------+  +--------------------------+ | |
     | |            |                           |              | |
     | |           \/                          \/              | |
     | | +---------------------------------------------------+ | |
     | | | +-----------------------------------------------+ | | |
     | | | |              SAV Information Base             | | | |
     | | | +-----------------------------------------------+ | | |
     | | |            SAV Information Base Manager           | | |
     | | +---------------------------------------------------+ | |
     | |                          |SAV Rules                   | |
     | +-------------------------------------------------------+ |
     |                            |                              |
     |                           \/                              |
     | +-------------------------------------------------------+ |
     | |                      SAV Table                        | |
     | +-------------------------------------------------------+ |
     +-----------------------------------------------------------+

         Figure 3: SAVNET agent and SAV table within AS X in Figure 2.

     Figure 3 displays the SAVNET agent and SAV table within AS X.  The
     SAVNET agent can obtain the SAV-specific information and general
     information from various SAV information sources including SAV-
     specific messages from other ASes, RPKI cache server, and RIB or FIB
     as long as they are available.  The SAV information base (SIB) within
     the SAVNET agent can store the SAV-specific information and general
     information and is maintained by the SIB manager.  And SIB manager
     generates SAV rules based on the SIB and fills out the SAV table on
     the data plane.  Moreover, the SIB can be managed by network
     operators using various methods such as YANG [RFC6020], Command-Line
     Interface (CLI), remote triggered black hole (RTBH) [RFC5635], and
     Flowspec [RFC8955].  The detailed collection methods of the SAV-
     related information depend on the deployment and implementation of
     the inter-domain SAV mechanisms and are out of scope for this
     document.

     In the data plane, the packets coming from other ASes will be
     validated by the SAV table and only the packets which are permitted
     by the SAV table will be forwarded to the next hop.  To achieve this,
     the router looks up each packet's source address in its local SAV
     table and gets one of three validity states: "Valid", "Invalid" or
     "Unknown".  "Valid" means that there is a source prefix in SAV table



  Li, et al.              Expires 2 September 2026               [Page 11]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     covering the source address of the packet and the valid incoming
     interfaces covering the actual incoming interface of the packet.
     According to the SAV principle, "Valid" packets will be forwarded.
     "Invalid" means there is a source prefix in SAV table covering the
     source address, but the incoming interface of the packet does not
     match any valid incoming interface so that such packets will be
     dropped.  "Unknown" means there is no source prefix in SAV table
     covering the source address.  The packet with "unknown" addresses can
     be dropped or permitted, which depends on the choice of operators.
     The structure and detailed usage of SAV table can refer to
     [sav-table].

  5.  SAV-related Information

     SAV-related information represents the information that can be used
     for SAV and consists of RPKI ROA objects and ASPA objects, local
     routing information, IRR data, and SAV-specific information.  In the
     inter-domain SAVNET architecture, RPKI ROA objects and ASPA objects,
     local routing information, and IRR data are categorized into general
     information.  In the future, if a new information source is created
     and can be used for SAV, but is not originally and specially used for
     SAV, its information can be categorized into general information.  In
     other words, general information can also be considered as dual-use
     information.

  5.1.  General Information

     General information refers to the information that is not directly
     designed for SAV but can be utilized to generate SAV rules, and
     includes RPKI ROA objects and ASPA objects, local routing
     information, and IRR data.

  5.1.1.  RPKI ROA objects and ASPA Objects

     The RPKI ROA objects and ASPA objects are originally designed for the
     routing security purpose.  RPKI ROA objects consists of {prefix,
     maximum length, origin AS} information and are originally used to
     mitigate the route origin hijacking, while RPKI ASPA objects consists
     of {ASN, Provider AS Set} information and are originally used to
     mitigate the route leaks.  Both the objects are verified and
     authoritative.  They are also stable and will not be updated
     frequently.

     Based on ASPA objects, the AS-level network topology can be
     constructed.  And according to the ROA objects and the constructed
     AS-level topology information, an AS can learn all the permissible
     paths of the prefixes from its customer cone.  Therefore, the
     prefixes and all its permissible incoming directions can be obtained.



  Li, et al.              Expires 2 September 2026               [Page 12]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     SAV based on RPKI ROA and ASPA objects only may lead to improper
     blocks, because not all ASes register their ROA and ASPA objects at
     the current stage.  In addition, all the permissible incoming
     directions learned from ASPA objects do not only consist of the real
     incoming directions of the prefixes, but also the extra non-used
     incoming directions by the legitimate traffic.  Only utilizing RPKI
     ROA and ASPA objects for generating SAV rules with their full
     deployment within the customer cone may lead to improper permits when
     not all ASes perform SAV.

     According to a recent study [rpki-time-of-flight], the process of
     updating RPKI information typically requires several minutes to an
     hour.  This encompasses the addition or deletion of RPKI objects and
     the subsequent retrieval of updated information by ASes.

  5.1.2.  Local Routing Information

     The local routing information is originally used to guide the packet
     forwarding on each router and can be stored in the local RIB or FIB.
     It can be parsed from the BGP messages communicated between ASes.
     Existing uRPF-based SAV mechanisms [RFC3704] [RFC8704] use the local
     routing information to generate SAV rules.  As analyzed in
     [I-D.ietf-savnet-inter-domain-problem-statement], in the asymmetric
     routing scenarios, these mechanisms, generating SAV rules using local
     routing information only, have accuracy problems and would lead to
     improper permits or improper blocks.

  5.1.3.  IRR Data

     The IRR data consist of ASes and their corresponding prefixes and can
     be used for SAV [RFC8704].  However, SAV using IRR data only would
     have limited functioning scope, in inter-domain networks, it may only
     be able to prevent spoofing by a stub AS.  In addition, the IRR data
     are not always accurate [RFC8704].

  5.2.  SAV-specific Information

     SAV-specific information is the information that is specifically
     designed for SAV and consists of prefixes and their legitimate
     incoming directions to enter ASes.  It can be contained in the SAV-
     specific messages which are communicated between ASes which deploy
     the inter-domain SAVNET architecture.  When parsing the SAV-specific
     messages and obtaining the SAV-specific information, ASes can learn
     the prefixes and their legitimate incoming direction to enter
     themselves.






  Li, et al.              Expires 2 September 2026               [Page 13]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     Moreover, in the inter-domain SAVNET architecture, a SAV-specific
     information communication mechanism is used to communicate SAV-
     specific information between ASes and distribute the updated
     information to the relative ASes automatically in a timely manner
     once the prefixes or routes change.  Compared against general
     information, it may be expected that SAV-specific information is more
     accurate and trustworthy, while it can update the SAV rules in a
     timely manner to adapt to the prefix or route changes.

  6.  SAV Information Base

  +----------------------------+---------------------------+-------------+
  |  SAV Information Sources   |      Trustworthiness      |  SAV Usage  |
  +----------------------------+---------------------------+-------------+
  |  SAV-specific Information  |Specific security mechanism|             |
  +------------+---------------+---------------------------+             |
  |            |RPKI ROA & ASPA|     X.509 certificates    |             |
  |            +---------------+---------------------------+Complementing|
  |  General   | Local Routing |            ROV,           | each other. |
  |Information |  Information  |   Route leak detection    |             |
  |            +---------------+---------------------------+             |
  |            |   IRR Data    |    Lower level of trust   |             |
  +------------+---------------+---------------------------+-------------+

      Figure 4: SAV information sources, their trustworthiness, and
                           their usage for SAV.

     The SIB is managed by the SIB manager, which can consolidate SAV-
     related information from different sources.  Figure 4 presents the
     summary of SAV information sources, their trustworthiness, and the
     recommendation about how to use them for generating SAV rules.
     Inter-domain SAVNET architecture can use SAV-related information from
     different sources to generate SAV rules.  It recommends using the
     information from all the available sources which is verified as
     trustworthy to generate SAV rules.  Therefore, SAV information
     sources complement each other for SAV.  For example, when both SAV-
     specific and general information are available, the inter-domain
     SAVNET would use them all equally.

     The recommendation for completing each information source for SAV
     depends on their verified trustworthiness.  Each AS deploying inter-
     domain SAVNET can utilize a specific security mechanism as discussed
     in Section 9.5 to validate the received SAV-specific information from
     other ASes to guarantee its Trustworthiness.  RPKI ROA and ASPA
     objects use x.509 certificates [RFC5280] to protect the objects and
     guarantee the trustworthiness.  Beside, local routing information
     relies on some techniques, such as ROV and route leak detection,
     e.g., ASPA or OTC, for achieving the Trustworthiness of their



  Li, et al.              Expires 2 September 2026               [Page 14]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     information.  Instead, IRR data has lower level of trust compared to
     others and may be disregarded if RPKI is deployed well, and they are
     usually updated in a slower manner than the real network changes and
     not always correct.

     It is noteworthy that using each type of SAV information source
     complementally in Figure 4 is recommended rather than mandated.  If a
     new inter-domain SAV mechanism needs to generate SAV rules using an
     informaiton source, it should ensure that the correct information is
     obtained from the corresponding source and adopts appropriate SAV
     actions in the data plane to avoid improper block and minimize
     improper permit.  A new inter-domain SAVNET mechanism, in line with
     the inter-domain SAVNET architecture, has the flexibility to
     determine the utilized SAV information sources and how to use them.
     Especially, when using RPKI ROA objects and ASPA objects as the SAV
     information source, the new inter-domain SAVNET mechanism should
     avoid jeopardizing the use of RPKI in routing security.

                             +----------------+
                             |    AS 3(P3)    |
                             +-+/\-----+/\+/\++
                                /        \  \
                      P3[AS 3] /          \  \ P3[AS 3]
                              /            \  \
                             / (C2P)        \  \
                    +----------------+       \  \
                    |    AS 4(P4)    |        \  \
                    ++/\+/\+/\+/\+/\++         \  \
       P6[AS 1, AS 2] /  /  |  |    \           \  \
            P2[AS 2] /  /   |  |     \           \  \
                    /  /    |  |      \           \  \
                   /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                  /  /      |  |        \           \  \
                 /  /(C2P)  |  |         \           \  \
     +----------------+     |  |          \           \  \
     |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
     +--------+/\+----+     |  | P6[AS 1]   \           \  \
       P6[AS 1] \           |  | NO_EXPORT   \           \  \
        P1[AS 1] \          |  |              \           \  \
        NO_EXPORT \         |  |               \           \  \
                   \ (C2P)  |  | (C2P/P2P) (C2P)\     (C2P) \  \
                +----------------+              +----------------+
                |  AS 1(P1, P6)  |              |    AS 5(P5)    |
                +----------------+              +----------------+
     Both AS 1 and AS 4 deploy the inter-domain SAVNET architecture
     and can exchange the SAV-specific information with each other,
     while other ASes do not deploy it.




  Li, et al.              Expires 2 September 2026               [Page 15]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


                      Figure 5: An example of AS topology.

     +-----+------+------------------+--------+------------------------+
     |Index|Prefix|Incoming Direction|Relation| SAV Information Source |
     +-----+------+------------------+--------+------------------------+
     |  0  |  P1  |       AS 2       |Customer|SAV-specific Information|
     +-----+------+------------------+--------+------------------------+
     |  1  |  P1  |       AS 1       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  2  |  P2  |       AS 2       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  3  |  P3  |       AS 3       |Provider|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  4  |  P5  |       AS 3       |Provider|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  5  |  P5  |       AS 5       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+
     |  6  |  P6  |       AS 2       |Customer|  General Information   |
     |     |      |                  |        |SAV-specific Information|
     +-----+------+------------------+--------+------------------------+
     |  7  |  P6  |       AS 1       |Customer|  General Information   |
     +-----+------+------------------+--------+------------------------+

          Figure 6: An example for the SAV information base of AS 4 in
                                   Figure 6.

     We use the examples shown in Figure 5 and Figure 6 to introduce SIB
     and illustrate how to generate SAV rules based on the SIB.  Figure 6
     depicts an example of the SIB established in AS 4 displayed in
     Figure 5.  Each row of the SIB contains an index, prefix, incoming
     direction of the prefix, reltation between ASes, and the
     corresponding sources of the information.  The incoming direction
     consists of customer, provider, and peer.  For example, in Figure 6,
     the row with index 0 indicates the incoming direction of P1 is AS 2
     and the information source is SAV-specific information.  Note that
     the same SAV-related information may have multiple sources and the
     SIB records them all, such as the row indexed 6.  Moreover, SIB
     should be carefully implemented in the specific protocol or protocol
     extensions to avoid becoming a heavy burden of the router, and the
     similar optimization approaches used for the RIB may be applied.

     Recall that inter-domain SAVNET architecture generates SAV rules
     based on the SAV information sources in the SIB and each type of
     source complements each other.  In addition, in the case of an AS's
     interfaces facing provider or lateral peer ASes where loose SAV rules
     are applicable, the inter-domain SAVNET architecture recommends to
     use blocklist at such directions to only block the prefixes that are
     sure not to come at these directions, while in the case of an AS's



  Li, et al.              Expires 2 September 2026               [Page 16]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     interfaces facing customer ASes that necessitate stricter SAV rules,
     the inter-domain SAVNET architecture recommends to use allowlist to
     only permit the prefixes that are allowed to come at these
     directions.

     Based on the above rules, taking the SIB in Figure 6 as an example to
     illustrate how the inter-domain SAVNET generates rules, AS 4 can
     conduct SAV as follows: SAV at the interfaces facing AS 3 blocks P1,
     P2, and P6 according to the rows indexed 0, 1, 2, 6, and 7 in the
     SIB, SAV at the interfaces facing AS 2 permits P1, P2, and P6
     according to the rows indexed 0, 2, and 6 in the SIB, SAV at the
     interfaces facing AS 1 permit P1 and P6 according to the row indexed
     1 and 7 in the SIB, and SAV at the interfaces facing AS 5 permits P5
     according to the row indexed 5 in the SIB.

  7.  SAVNET Communication Mechanism

     +------+
     |      | SAV-specific Information +-----------------------------+
     |      |<=========================|  SAVNET Agent in other ASes |
     |      |                          +-----------------------------+
     |      |                        +---------------------------------+
     |      |                        | +-----------------------------+ |
     |      |                        | | RPKI ROA Obj. and ASPA Obj. | |
     |      |                        | +-----------------------------+ |
     |      |                        | +-----------------------------+ |
     |      |                        | |             RIB             | |
     |SAVNET|  General Information   | +-----------------------------+ |
     |Agent |<-----------------------| +-----------------------------+ |
     |      |                        | |             FIB             | |
     |      |                        | +-----------------------------+ |
     |      |                        | +-----------------------------+ |
     |      |                        | |         IRR Database        | |
     |      |                        | +-----------------------------+ |
     |      |                        +---------------------------------+
     |      |  Management Information  +-----------------------------+
     |      |<-------------------------|      Network Operators      |
     |      |                          +-----------------------------+
     +------+

         Figure 7: Gathering SAV-related information from different SAV
                              information sources.

     SAV-specific information relies on the communication between SAVNET
     agents, and general information can be from RPKI ROA objects and ASPA
     objects, RIB, FIB, and IRR data.  Therefore, as illustrated in
     Figure 7, the SAVNET agent needs to receive the SAV-related
     information from these SAV information sources.  SAVNET agent also



  Li, et al.              Expires 2 September 2026               [Page 17]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     needs to accept the configurations from network operators for the
     management operations.  Gathering these types of information relies
     on the SAVNET communication mechanism, which includes SAV-specific
     information communication mechanism, general information
     communication mechanism, and management information communication
     mechanism.

  7.1.  SAV-specific Information Communication Mechanism

                    +------------------------+
                    |      AS 3(P3, P3')     |
                    |   +----------------+   |
                    |   |  SAVNET Agent  |   |
                    |   +----------------+   |
                    +-+/\+---------------+/\++
                       /                |  |
        SAV-specific  /                 |  |
         Messages[   /     SAV-specific |  |
        (P1, AS 2)] /         Messages[ |  |
                   /        (P3, AS 3), |  |
                  /        (P3', AS 3)] |  |
         +------------+                 |  |
         |  AS 2(P2)  |                 |  |
         +------+/\+--+                 |  | SAV-specific
     SAV-specific \                     |  | Messages[
        Messages[  \                    |  | (P1, AS 1)]
        (P1, AS 2)] \                   |  |
                     \                  |  |
                   +-------------------+\/+--+
                   |         AS 1(P1)        |
                   |    +--------------+     |
                   |    | SAVNET Agent |     |
                   |    +--------------+     |
                   +-------------------------+
     (1) The path of the legitimate traffic with source addresses in P1
         and destination addresses in P3 is [AS 1, AS 2, AS 3].
     (2) The path of the legitimate traffic with source addresses in P1
         and destination addresses in P3' is [AS 1, AS 3].
     (3) The path of the legitimate traffic with source addresses in P3
         or P3' and destination addresses in P1 is [AS 3, AS 1].

       Figure 8: An example for exchanging SAV-specific information with
       SAV-specific information communication mechanism between AS 1 and
                                     AS 3.

     Figure 8 uses an example to show the exchange of SAV-specific
     information between AS 1 and AS 3 through SAV-specific messages.  The
     SAV-specific information is expressed as <Prefix, Incoming Direction>



  Li, et al.              Expires 2 September 2026               [Page 18]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     pairs, such as (P1, AS 1), (P1, AS 2), (P3, AS 3), and (P3', AS 3) in
     Figure 8.  AS 1 needs to determine the incoming direction to AS 3 for
     its prefix P1 to obtain SAV-specific information, such as (P1, AS 1)
     and (P1, AS 2).  It then assembles this information into SAV-specific
     messages to send to AS 3, which can subsequently generate SAV rules
     based on the received information.  This process may require AS 1 to
     collaborate with intermediate ASes between AS 1 and AS 3 to obtain
     the SAV-specific information.  Similarly, AS 3 needs to determine the
     incoming direction to AS 1 for its prefixes P3 and P3' and send the
     SAV-specific information, such as (P3, AS 3) and (P3', AS 3), to AS 1
     through SAV-specific messages, allowing AS 1 to generate the
     corresponding SAV rules.  AS 3 may also need to collaborate with
     intermediate ASes between AS 3 and AS 1 to gather the required
     information for obtaining the SAV-specific information.

     The SAV-specific information can be exchanged between ASes via SAV-
     specific messages.  SAV-specific messages are used to propagate or
     originate the SAV-specific information between ASes by the SAVNET
     agent.  For an AS which initiates its own SAV-specific messages, its
     SAVNET agent needs to obtain the incoming direction of its own
     prefixes to enter other ASes and assemble them into the SAV-specific
     messages to the corresponding ASes.  When ASes receive the SAV-
     specific messages, they parse the messages to obtain source prefixes
     and their corresponding incoming directions.

     Additionally, if SAV-specific information is communicated between
     ASes, a new SAV-specific information communication mechanism would
     need to be developed to communicate it and can be implemented by a
     new protocol or extending an existing protocol.  The SAV-specific
     information communication mechanism needs to define the data
     structure or format to communicate the SAV-specific messages and the
     operations and timing for originating, processing, propagating, and
     terminating the messages.  If an extension to an existing protocol is
     used to exchange SAV-specific information, the corresponding existing
     protocol should not be affected.  The SAVNET agent is the entity to
     support the SAV-specific communication mechanism.  By parsing the
     SAV-specific messages, it obtains the prefixes and their incoming AS
     direction for maintaining the SIB.  It is important to note that the
     SAVNET agent within an AS has the capability to establish connections
     with multiple SAVNET agents within different ASes, relying on either
     manual configurations by operators or an automatic mechanism.  In
     addition, SAVNET agents should validate the authenticity of the
     connection for communicating the SAV-specific information to verify
     whether the SAV-specific information is provided over a secure
     connection with an authenticated AS.






  Li, et al.              Expires 2 September 2026               [Page 19]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     The need for a SAV-specific communication mechanism arises from the
     facts that the SAV-specific information needs to be obtained and
     communicated between ASes.  Different from the general information
     such as routing information from the RIB, there are no existing
     mechanism which can support the perception and communication of SAV-
     specific information between ASes.  Hence, a SAV-specific
     communication mechanism is needed to provide a medium and set of
     rules to establish communication between different ASes for the
     exchange of SAV-specific information.

     Furthermore, in order to obtain all the source prefixes of an AS, the
     inter-domain SAVNET architecture may communicate with the intra-
     domain SAVNET architecture
     [I-D.ietf-savnet-intra-domain-architecture] to obtain all the
     prefixes belonging to an AS.  If the legitimate incoming directions
     of SAV-specific information are learned from BGP AS_PATH information,
     it needs to note that BGP AS_PATH may hide some interfaces that exist
     between ASes in the scenarios involving topological fork and merge.

     Some scenarios, such as the ones where policy-based routing or static
     route exist in the inter-domain networks, may rely on the wider
     deployment of SAVNET agent or more interactive communication between
     ASes to make the inter-domain SAVNET work better.  In these
     scenarios, operators may override the default BGP decision by using
     policy-based routing or static route.  For example, in Figure 8, AS 2
     may use another AS which does not in the AS path [AS 1, AS 2, AS 3]
     to transmit the legitimate traffic with source addresses in P1 to AS
     3.  For such cases, inter-domain SAVNET may require AS 2 to deploy
     SAVNET agent to obtain the SAV-specific information for the
     legitimate traffic with source addresses in P1, or AS 1 and AS 3 may
     need more interactive communication to obtain the SAV-specific
     information.

     The preferred AS paths of an AS may change over time due to route
     changes caused by operator configurations or network failures.  In
     addition, the SAVNET agent should be aware of the route changes and
     launch SAV-specific messages to adapt to the route changes in a
     timely manner.  The SAV-specific information communication mechanism
     should handle route changes carefully to avoid improper blocks.  The
     reasons for leading to improper blocks may include late detection of
     route changes, delayed message transmission, or packet losses.  If
     the SAVNET agent cannot be aware of the route changes caused by
     failures, it may not be aware of the failures.  A wider deployment of
     SAVNET agent can make network failure sensing more sensitive.
     However, the detailed design of SAV-specific information
     communication mechanism for dealing with route changes is outside the
     scope of this document.




  Li, et al.              Expires 2 September 2026               [Page 20]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  7.2.  General Information Communication Mechanism

     The general information communication mechanism is used for
     communicating routing information between ASes, obtaining RPKI ROA
     objects and ASPA objects from RPKI cache servers, and obtaining the
     information about ASes and their prefixes from IRR databases.  The
     general communication mechanism can be implemented by using existing
     protocols for collecting the relative information, such as BGP, RTR
     [RFC8210], and FTP [RFC959].

  7.3.  Management Information Communication Mechanism

     The primary purpose of the management information communication
     mechanism is to deliver manual configurations of network operators.
     Examples of the management configurations include, but are not
     limited to:

     *  SAVNET configurations using YANG, CLI, RTBH, or Flowspec: Inter-
        domain SAVNET implementations on vendor devices need to accept the
        configurations from operators, such as the SAV rules directly
        configured by operators, and may support various tools to do this,
        such as YANG, CLI, RTBH, or Flowspec.

     *  SAVNET performance analysis: Inter-domain SAVNET implementations
        need to support various operation methods to report the statistics
        of SAVNET, such as alarm and exception reporting, performance
        monitoring and reporting for the control plane and data plane,
        which are discussed in detail in Section 10.

     *  SAVNET deployment provisioning: Inter-domain SAVNET
        implementations may support the configurations which relate to its
        deployment process, such as maximum hardware resources used, "on-
        off" of SAVNET, and access authority.

     Note that the management information can be delivered at any time and
     requires reliable delivery for the management information
     communication mechanism implementation.  Additionally, to support
     performance analysis, the management information communication
     mechanism can carry telemetry information, such as metrics pertaining
     to forwarding performance, the count of spoofing packets and
     discarded packets, and the information regarding the prefixes
     associated with the spoofing traffic, as observed until the most
     recent time.








  Li, et al.              Expires 2 September 2026               [Page 21]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  8.  Use Cases

     This section utilizes the sample use cases to showcase that the
     inter-domain SAVNET architecture can improve the validation accuracy
     in the scenarios of limited propagation of prefixes, hidden prefixes,
     reflection attacks, and direct attacks, compared to existing SAV
     mechanisms, which are also utilized for the gap analysis of existing
     inter-domain SAV mechanisms in
     [I-D.ietf-savnet-inter-domain-problem-statement].  In the following,
     these use cases are discussed for SAV at customer interfaces and SAV
     at provider/peer interfaces, respectively.

  8.1.  SAV at Customer Interfaces

     In order to prevent the source address spoofing, operators can enable
     ACL-based ingress filtering, source-based RTBH filtering, and/or
     uRPF-based mechanisms at customer interfaces, namely Strict uRPF, FP-
     uRPF, VRF uRPF, or EFP-uRPF [manrs] [nist].  However, as analyzed in
     [I-D.ietf-savnet-inter-domain-problem-statement], uRPF-based
     mechanisms may lead to false positives in two inter-domain scenarios:
     limited propagation of prefixes and hidden prefixes, or may lead to
     false negatives in the scenarios of source address spoofing attacks
     within a customer cone, while ACL-based ingress filtering and source-
     based RTBH filtering need to update SAV rules in a timely manner and
     lead to high operational overhead.  The following showcases that the
     inter-domain SAVNET architecture can avoid false positives and false
     negatives in these scenarios.

  8.1.1.  Limited Propagation of Prefixes






















  Li, et al.              Expires 2 September 2026               [Page 22]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


                             +----------------+
                             |    AS 3(P3)    |
                             +-+/\-----+/\+/\++
                                /        \  \
                      P3[AS 3] /          \  \ P3[AS 3]
                              /            \  \
                             / (C2P)        \  \
                    +----------------+       \  \
                    |    AS 4(P4)    |        \  \
                    ++/\+/\+/\+/\+/\++         \  \
                      /  /  |  |    \           \  \
            P2[AS 2] /  /   |  |     \           \  \
                    /  /    |  |      \           \  \
                   /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                  /  /      |  |        \           \  \
                 /  /(C2P)  |  |         \           \  \
     +----------------+     |  |          \           \  \
     |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
     +--------+/\+----+     |  | P6[AS 1]   \           \  \
                \           |  | NO_EXPORT   \           \  \
        P1[AS 1] \          |  |              \           \  \
        NO_EXPORT \         |  |               \           \  \
                   \ (C2P)  |  | (C2P/P2P) (C2P)\     (C2P) \  \
                +----------------+              +----------------+
                |  AS 1(P1, P6)  |              |    AS 5(P5)    |
                +----------------+              +----------------+

         Figure 9: Limited propagation of prefixes caused by NO_EXPORT.

     Figure 9 presents a scenario where the limited propagation of
     prefixes occurs due to the NO_EXPORT community attribute.  In this
     scenario, AS 1 is a customer of AS 2, AS 2 is a customer of AS 4, AS
     4 is a customer of AS 3, and AS 5 is a customer of both AS 3 and AS
     4.  The relationship between AS 1 and AS 4 can be either customer-to-
     provider (C2P) or peer-to-peer (P2P).  AS 1 advertises prefixes P1 to
     AS 2 and adds the NO_EXPORT community attribute to the BGP
     advertisement sent to AS 2, preventing AS 2 from further propagating
     the route for prefix P1 to AS 4.  Similarly, AS 1 adds the NO_EXPORT
     community attribute to the BGP advertisement sent to AS 4, resulting
     in AS 4 not propagating the route for prefix P6 to AS 3.
     Consequently, AS 4 only learns the route for prefix P1 from AS 1 in
     this scenario.  Suppose AS 1 and AS 4 have deployed inter-domain SAV
     while other ASes have not, and AS 4 has deployed EFP-uRPF at its
     customer interfaces.

     In this scenario, existing uRPF-based SAV mechanisms would block the
     traffic with P1 as source addresses improperly, and thus suffer from
     the problem of false positives



  Li, et al.              Expires 2 September 2026               [Page 23]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     [I-D.ietf-savnet-inter-domain-problem-statement].  If the inter-
     domain SAVNET architecture is deployed, AS 1 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P1 as source addresses can arrive at the interfaces facing AS 1
     and AS 2.  As a result, the false positive problem can be avoided.

  8.1.2.  Hidden Prefixes

                                  +----------------+
                  Anycast Server+-+    AS 3(P3)    |
                                  +-+/\-----+/\+/\++
                                     /        \  \
                           P3[AS 3] /          \  \ P3[AS 3]
                                   /            \  \
                                  / (C2P)        \  \
                          +----------------+      \  \
                          |    AS 4(P4)    |       \  \
                          ++/\+/\+/\+/\+/\++        \  \
             P6[AS 1, AS 2] /  /  |  |   \           \  \
                  P2[AS 2] /  /   |  |    \           \  \
                          /  /    |  |     \           \  \
                         /  /     |  |      \ P5[AS 5]  \  \ P5[AS 5]
                        /  /      |  |       \           \  \
                       /  /(C2P)  |  |        \           \  \
           +----------------+     |  |         \           \  \
     User+-+    AS 2(P2)    |     |  | P1[AS 1] \           \  \
           +--------+/\+----+     |  | P6[AS 1]  \           \  \
             P6[AS 1] \           |  | NO_EXPORT  \           \  \
              P1[AS 1] \          |  |             \           \  \
              NO_EXPORT \         |  |              \           \  \
                         \ (C2P)  |  | (C2P)   (C2P) \     (C2P) \  \
                      +----------------+            +----------------+
         Edge Server+-+  AS 1(P1, P6)  |            |    AS 5(P5)    |
                      +----------------+            +----------------+
     P3 is the anycast prefix and is only advertised by AS 3 through BGP.

               Figure 10: A Direct Server Return (DSR) scenario.














  Li, et al.              Expires 2 September 2026               [Page 24]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     Figure 10 illustrates a direct server return (DSR) scenario where the
     anycast IP prefix P3 is only advertised by AS 3 through BGP.  In this
     example, AS 3 is the provider of AS 4 and AS 5, AS 4 is the provider
     of AS 1, AS 2, and AS 5, and AS 2 is the provider of AS 1.  AS 1 and
     AS 4 have deployed inter-domain SAV, while other ASes have not.  When
     users in AS 2 send requests to the anycast destination IP, the
     forwarding path is AS 2->AS 4->AS 3.  The anycast servers in AS 3
     receive the requests and tunnel them to the edge servers in AS 1.
     Finally, the edge servers send the content to the users with source
     addresses in prefix P3.  The reverse forwarding path is AS 1->AS
     4->AS 2.

     In this scenario, existing uRPF-based mechanisms will improperly
     block the legitimate response packets from AS 1 at the customer
     interface of AS 4 facing AS 1
     [I-D.ietf-savnet-inter-domain-problem-statement].  In contrast, if
     the inter-domain SAVNET architecture is deployed, AS 1 can
     communicate the SAV-specific information to AS 4 and AS 4 will be
     aware that the traffic with P3 as source addresses can arrive at the
     interfaces facing AS 1 and AS 3.  As a result, the legitimate
     response packets with P3 as source addresses from AS 1 can be allowed
     and the false positive problem can be avoided.

  8.1.3.  Reflection Attacks



























  Li, et al.              Expires 2 September 2026               [Page 25]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


                                     +----------------+
                                     |    AS 3(P3)    |
                                     +-+/\-----+/\+/\++
                                           /     \  \
                                          /       \  \
                                         /         \  \
                                        / (C2P)     \  \
                               +----------------+    \  \
                               |    AS 4(P4)    |     \  \
                               ++/\+/\+/\+/\+/\++      \  \
                  P6[AS 1, AS 2] /  /  |  |    \        \  \
                       P2[AS 2] /  /   |  |     \        \  \
                               /  /    |  |      \        \  \
                              /  /     |  |       \P5[AS 5]\  \ P5[AS 5]
                             /  /      |  |        \        \  \
                            /  /(C2P)  |  |         \        \  \
                +----------------+     |  |          \        \  \
  Attacker(P1')-+    AS 2(P2)    |     |  | P1[AS 1]  \        \  \
                +--------+/\+----+     |  | P6[AS 1]   \        \  \
                  P6[AS 1] \           |  | NO_EXPORT   \        \  \
                   P1[AS 1] \          |  |              \        \  \
                   NO_EXPORT \         |  |               \        \  \
                              \ (C2P)  |  | (C2P) (C2P)    \  (C2P) \  \
                           +----------------+           +----------------+
                   Victim+-+  AS 1(P1, P6)  |   Server+-+    AS 5(P5)    |
                           +----------------+           +----------------+
  P1' is the spoofed source prefix P1 by the attacker which is inside of
  AS 2 or connected to AS 2 through other ASes.

      Figure 11: A scenario of reflection attacks by source address
                     spoofing within a customer cone.

     Figure 11 depicts the scenario of reflection attacks by source
     address spoofing within a customer cone.  The reflection attack by
     source address spoofing takes place within AS 4's customer cone,
     where the attacker spoofs the victim's IP address (P1) and sends
     requests to servers' IP address (P5) that are designed to respond to
     such requests.  As a result, the server sends overwhelming responses
     back to the victim, thereby exhausting its network resources.  The
     arrows in Figure 11 illustrate the commercial relationships between
     ASes.  AS 3 serves as the provider for AS 4 and AS 5, while AS 4 acts
     as the provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 1 and AS 4 have deployed inter-domain
     SAV, while the other ASes have not.

     In this scenario, EFP-uRPF with algorithm A/B will improperly permit
     the spoofing attacks originating from AS 2
     [I-D.ietf-savnet-inter-domain-problem-statement].  If the inter-



  Li, et al.              Expires 2 September 2026               [Page 26]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     domain SAVNET architecture is deployed, AS 1 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P1 as source addresses can only arrive at the interface facing
     AS 1.  Therefore, at the interface of AS 4 facing AS 2, the spoofing
     traffic can be blocked.

  8.1.4.  Direct Attacks

                                     +----------------+
                                     |    AS 3(P3)    |
                                     +-+/\-----+/\+/\++
                                        |        \  \
                                        |         \  \
                                        |          \  \
                                        | (C2P)     \  \
                               +----------------+    \  \
                               |    AS 4(P4)    |     \  \
                               ++/\+/\+/\+/\+/\++      \  \
                  P6[AS 1, AS 2] /  /  |  |   \         \  \
                       P2[AS 2] /  /   |  |    \         \  \
                               /  /    |  |     \         \  \
                              /  /     |  |      \P5[AS 5] \  \ P5[AS 5]
                             /  /      |  |       \         \  \
                            /  /(C2P)  |  |        \         \  \
                +----------------+     |  |         \         \  \
  Attacker(P5')-+    AS 2(P2)    |     |  | P1[AS 1] \         \  \
                +--------+/\+----+     |  | P6[AS 1]  \         \  \
                  P6[AS 1] \           |  | NO_EXPORT  \         \  \
                   P1[AS 1] \          |  |             \         \  \
                   NO_EXPORT \         |  |              \         \  \
                              \ (C2P)  |  | (C2P)   (C2P) \   (C2P) \  \
                           +----------------+           +----------------+
                   Victim+-+  AS 1(P1, P6)  |           |    AS 5(P5)    |
                           +----------------+           +----------------+
  P1' is the spoofed source prefix P1 by the attacker which is inside of
  AS 2 or connected to AS 2 through other ASes.

      Figure 12: A scenario of the direct attacks by source address
                     spoofing within a customer cone.

     Figure 12 portrays a scenario of direct attacks by source address
     spoofing within a customer cone and is used to analyze the gaps of
     uRPF-based mechanisms below.  The direct attack by source address
     spoofing takes place within AS 4's customer cone, where the attacker
     spoofs a source address (P5) and directly targets the victim's IP
     address (P1), overwhelming its network resources.  The arrows in
     Figure 12 illustrate the commercial relationships between ASes.  AS 3
     serves as the provider for AS 4 and AS 5, while AS 4 acts as the



  Li, et al.              Expires 2 September 2026               [Page 27]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 4 and AS 5 have deployed inter-domain
     SAV, while the other ASes have not.

     In this scenario, EFP-uRPF with algorithm A/B will improperly permit
     the spoofing attacks
     [I-D.ietf-savnet-inter-domain-problem-statement].  If the inter-
     domain SAVNET architecture is deployed, AS 5 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P5 as source addresses can arrive at the interface facing AS 3
     and AS 5.  Therefore, at the interface of AS 4 facing AS 2, the
     spoofing traffic can be blocked.

  8.2.  SAV at Provider/Peer Interfaces

     In order to prevent packets with spoofed source addresses from the
     provider/peer AS, ACL-based ingress filtering, Loose uRPF, and/or
     source-based RTBH filtering can be deployed [nist].
     [I-D.ietf-savnet-inter-domain-problem-statement] exposes the
     limitations of ACL-based ingress filtering, source-based RTBH
     filtering, and Loose uRPF for SAV at provider/peer interfaces in
     scenarios of source address spoofing attacks from provider/peer AS.
     The source address spoofing attacks from provider/peer AS include
     reflection attacks from provider/peer AS and direct attacks from
     provider/peer AS.  The following showcases that the inter-domain
     SAVNET architecture can avoid false negatives in these scenarios.

  8.2.1.  Reflection Attacks























  Li, et al.              Expires 2 September 2026               [Page 28]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


                                   +----------------+
                    Attacker(P1')+-+    AS 3(P3)    |
                                   +-+/\-----+/\+/\++
                                      /        \  \
                                     /          \  \
                                    /            \  \
                                   / (C2P/P2P)    \  \
                           +----------------+      \  \
                           |    AS 4(P4)    |       \  \
                           ++/\+/\+/\+/\+/\++        \  \
              P6[AS 1, AS 2] /  /  |  |    \          \  \
                   P2[AS 2] /  /   |  |     \          \  \
                           /  /    |  |      \          \  \
                          /  /     |  |       \ P5[AS 5] \  \ P5[AS 5]
                         /  /      |  |        \          \  \
                        /  /(C2P)  |  |         \          \  \
            +----------------+     |  |          \          \  \
    Server+-+    AS 2(P2)    |     |  | P1[AS 1]  \          \  \
            +--------+/\+----+     |  | P6[AS 1]   \          \  \
              P6[AS 1] \           |  | NO_EXPORT   \          \  \
               P1[AS 1] \          |  |              \          \  \
               NO_EXPORT \         |  |               \          \  \
                          \ (C2P)  |  | (C2P)    (C2P) \    (C2P) \  \
                       +----------------+             +----------------+
               Victim+-+  AS 1(P1, P6)  |             |    AS 5(P5)    |
                       +----------------+             +----------------+
    P1' is the spoofed source prefix P1 by the attacker which is inside of
    AS 3 or connected to AS 3 through other ASes.

        Figure 13: A scenario of reflection attacks by source address
                       spoofing from provider/peer AS.

     Figure 13 depicts the scenario of reflection attacks by source
     address spoofing from provider/peer AS.  In this case, the attacker
     spoofs the victim's IP address (P1) and sends requests to servers' IP
     address (P2) that respond to such requests.  The servers then send
     overwhelming responses back to the victim, exhausting its network
     resources.  The arrows in Figure 13 represent the commercial
     relationships between ASes.  AS 3 acts as the provider or lateral
     peer of AS 4 and the provider for AS 5, while AS 4 serves as the
     provider for AS 1, AS 2, and AS 5.  Additionally, AS 2 is the
     provider for AS 1.  Suppose AS 1 and AS 4 have deployed inter-domain
     SAV, while the other ASes have not.

     Both ACL-based ingress filtering and source-based RTBH filtering will
     induce additional operational overhead, and Loose uRPF may improperly
     permit spoofed packets
     [I-D.ietf-savnet-inter-domain-problem-statement].  If the inter-



  Li, et al.              Expires 2 September 2026               [Page 29]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     domain SAVNET architecture is deployed, AS 1 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P1 as source addresses can arrive at the interface facing AS 1
     and AS 2.  Therefore, at the interface of AS 4 facing AS 3, the
     spoofing traffic can be blocked.

  8.2.2.  Direct Attacks

                            +----------------+
             Attacker(P2')+-+    AS 3(P3)    |
                            +-+/\-----+/\+/\++
                               /        \  \
                              /          \  \
                             /            \  \
                            / (C2P/P2P)    \  \
                   +----------------+       \  \
                   |    AS 4(P4)    |        \  \
                   ++/\+/\+/\+/\+/\++         \  \
      P6[AS 1, AS 2] /  /  |  |    \           \  \
           P2[AS 2] /  /   |  |     \           \  \
                   /  /    |  |      \           \  \
                  /  /     |  |       \ P5[AS 5]  \  \ P5[AS 5]
                 /  /      |  |        \           \  \
                /  /(C2P)  |  |         \           \  \
    +----------------+     |  |          \           \  \
    |    AS 2(P2)    |     |  | P1[AS 1]  \           \  \
    +--------+/\+----+     |  | P6[AS 1]   \           \  \
      P6[AS 1] \           |  | NO_EXPORT   \           \  \
       P1[AS 1] \          |  |              \           \  \
       NO_EXPORT \         |  |               \           \  \
                  \ (C2P)  |  | (C2P)    (C2P) \     (C2P) \  \
               +----------------+              +----------------+
       Victim+-+  AS 1(P1, P6)  |              |    AS 5(P5)    |
               +----------------+              +----------------+
    P2' is the spoofed source prefix P2 by the attacker which is inside of
    AS 3 or connected to AS 3 through other ASes.

          Figure 14: A scenario of direct attacks by source address
                       spoofing from provider/peer AS.












  Li, et al.              Expires 2 September 2026               [Page 30]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     Figure 14 showcases a scenario of direct attack by source address
     spoofing from provider/peer AS.  In this case, the attacker spoofs
     another source address (P2) and directly targets the victim's IP
     address (P1), overwhelming its network resources.  The arrows in
     Figure 14 represent the commercial relationships between ASes.  AS 3
     acts as the provider or lateral peer of AS 4 and the provider for AS
     5, while AS 4 serves as the provider for AS 1, AS 2, and AS 5.
     Additionally, AS 2 is the provider for AS 1.  Suppose AS 1 and AS 4
     have deployed inter-domain SAV, while the other ASes have not.

     Also, in this scenario, both ACL-based ingress filtering and source-
     based RTBH filtering will induce additional operational overhead, and
     Loose uRPF may improperly permit spoofed packets
     [I-D.ietf-savnet-inter-domain-problem-statement].  If the inter-
     domain SAVNET architecture is deployed, AS 2 can communicate the SAV-
     specific information to AS 4 and AS 4 will be aware that the traffic
     with P2 as source addresses can only arrive at the interface facing
     AS 2.  Therefore, at the interface of AS 4 facing AS 3, the spoofing
     traffic can be blocked.

  9.  Meeting the Design Requirements of Inter-domain SAVNET

     The inter-domain SAVNET architecture proposes the guidelines for the
     design of new inter-domain SAV mechanisms to meet the requirments
     defined in [I-D.ietf-savnet-inter-domain-problem-statement].  The
     followings illustrate the design guidelines to meet the requirements
     one by one.

  9.1.  Improving Validation Accuracy over Existing Mechanisms

     As analyzed in Section 8, existing uRPF-based SAV mechanisms may have
     improper block or improper permit problems in the scenarios of
     limited propagation of prefixes, hidden prefixes, reflection attacks,
     and direct attacks for SAV at customer interfaces, and the scenarios
     of reflection attacks and direct attacks for SAV at provider/peer
     interfaces.

     Inter-domain SAVNET proposes SAV-specific information, which consists
     of the source prefixes of ASes and their corresponding legitimate
     incoming direction to enter other ASes.  ASes which deploy SAVNET
     agent can communicate SAV-specific information with each other and
     generate accurate SAV rules for the prefixes from the SAV-specific
     information.  The use cases shown in Section 8 has demonstrated
     inter-domain SAVNET can improve validation accuracy compared to
     existing SAV mechanisms.  Along with more ASes deploy SAVNET agent
     and communicate SAV-specific information with each other, accurate
     SAV rules can be generated for these ASes and their prefixes can
     obtain better protection.



  Li, et al.              Expires 2 September 2026               [Page 31]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  9.2.  Working in Incremental/Partial Deployment

     A new inter-domain SAVNET mechanism should consider incremental/
     partial deployment as it is not feasible to deploy SAVNET agent
     simultaneously in all ASes, due to various constraints, such as
     device capabilities, versions, or vendors.

     Inter-domain SAVNET can support incremental/partial deployment, as it
     is not mandatory for all ASes to deploy SAVNET agents for
     communicating SAV-specific information.  ASes which deploy SAVNET
     agents can establish a logical neighboring relationship with other
     ASes.  The connections for communicating SAV-specific information can
     be achieved by manual configurations set by operators or an automatic
     neighbor discovery mechanism.  An automatic neighbor discovery
     mechanism can utilize existing protocols or tools to collect the
     SAVNET neighboring information.  This flexibility enables the inter-
     domain SAVNET to accommodate varying degrees of deployment, promoting
     interoperability and collaboration among participating ASes.  During
     the partial/incremental deployment of SAVNET agent, the SAV-specific
     information for the ASes which do not deploy SAVNET agent cannot be
     obtained.  To protect the prefixes of these ASes, inter-domain SAVNET
     can use the general information in the SIB to generate SAV rules.
     When using the general information, inter-domain SAVNET needs to
     guarantee the SAV accuracy for the corresponding application
     scenarios.  The use cases in Section 8 demonstrates that inter-domain
     SAVNET supports incremental/partial deployment.

     As more ASes adopt the inter-domain SAVNET, the "deployed area"
     expands, thereby increasing the collective defense capability against
     source address spoofing.  Furthermore, if multiple "deployed areas"
     can be logically interconnected across "non-deployed areas", these
     interconnected "deployed areas" can form a logical alliance,
     providing enhanced protection against address spoofing.  Especially,
     along with more ASes deploy SAVNET agent and support the
     communication of SAV-specific information, the generated SAV rules
     will become more accurate, as well as enhancing the protection
     capability against source address spoofing.

     In addition, releasing the SAV functions of the inter-domain SAVNET
     incrementally is RECOMMENDED as one potential way to reduce the
     deployment risks and can be considered in its deployment by network
     operators:









  Li, et al.              Expires 2 September 2026               [Page 32]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     *  First, the inter-domain SAVNET can only do the measurement in the
        data plane and do not take any other actions.  Based on the
        measurement data, the operators can evaluate the effect of the
        inter-domain SAVNET on the legitimate traffic, including
        validation accuracy and forwarding performance, as well as the
        operational overhead.

     *  Second, the inter-domain SAVNET can open the function to limit the
        rate of the traffic that is justified as spoofing traffic.  The
        operators can further evaluate the effect of the inter-domain
        SAVNET on the legitimate traffic and spoofing traffic, such as
        limiting the rate of all the spoofing traffic without hurting the
        legitimate traffic.

     *  Third, when the validation accuracy, forwarding performance, and
        operational overhead have been verified on a large scale by the
        live network, the inter-domain SAVNET can open the function to
        directly block the spoofing traffic that is justified by the SAV
        table in the data plane.

  9.3.  Reducing Operational Overhead

     The inter-domain routes or the prefixes of ASes usually change
     dynamically, which requires the SAV rules to be updated
     acutomatically.  ACL-based ingress filtering and source-based RTBH
     filtering requires manual configuration to update SAV rules to adapt
     to the routing or prefix changes, which leads to high operational
     overhead.

     Inter-domain SAVNET proposes the SAV-specific information
     communication mechanism and utilizes it to communicate SAV-specific
     information automatically between ASes which deploy SAVNET agent.
     Upon receiving the SAV-specific information, SAVNET agent will use it
     to generate SAV rules.  The use cases displayed in Section 8.2 show
     that inter-domain SAVNET reduces operational overhead compared to
     ACL-based ingress filtering and source-based RTBH filtering.

  9.4.  Guaranteeing Efficient Convergence

     Convergence issues SHOULD be carefully considered due to the dynamic
     nature of the Internet.  Internet routes undergo continuous changes,
     and SAV rules MUST proactively adapt to these changes, such as prefix
     and route changes, in order to avoid improper block and reduce
     improper permit.  To effectively track these changes, the SAVNET
     agent should proactively communicate the changes of SAV-specific
     information between ASes and generate SAV rules in a timely manner.





  Li, et al.              Expires 2 September 2026               [Page 33]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     The SAVNET agent should launch SAV-specific messages to adapt to the
     route or prefix changes in a timely manner.  During the routing
     convergence process, the traffic paths of the source prefixes can
     undergo rapid changes within a short period.  The changes of the SAV-
     specific information may not be communicated in time between ASes to
     update SAV rules, improper block or improper permit may happen.  Such
     inaccurate validation is caused by the delays in communicating SAV-
     specific information between ASes, which occur due to the factors
     like packet losses, unpredictable network latencies, or message
     processing latencies.  The detailed design of the SAV-specific
     information communication mechanism should consider these issues to
     reduce the inaccurate validation.

     Besides, for the inter-domain SAVNET, the potential ways to deal with
     the inaccurate validation issues during the convergence of the SAV-
     specific information communication mechanism is to consider using the
     information from RPKI ROA objects and ASPA objects to generate SAV
     rules until the convergence process of the SAV-specific communication
     mechanism is finished, since these information is more stable and can
     help avoid improper block, and thus avoiding the impact to the
     legitimate traffic.

  9.5.  Providing Necessary Security Guarantee

     For inter-domain SAVNET, the SAVNET agent plays a crucial role in
     generating and disseminating SAV-specific messages across different
     ASes.  To safeguard against the potential risks posed by a malicious
     AS generating incorrect or forged SAV-specific messages, it is
     important for the SAVNET agents to employ security authentication
     measures for each received SAV-specific message.  The majour security
     threats faced by inter-domain SAVNET can be categorized into two
     aspects: session security and content security.  Session security
     pertains to verifying the identities of both parties involved in a
     session and ensuring the integrity of the session content.  Content
     security, on the other hand, focuses on verifying the authenticity
     and reliability of the session content, thereby enabling the
     identification of forged SAV-specific messages.

     The threats to session security include:

     *  Session identity impersonation: This occurs when a malicious
        router deceitfully poses as a legitimate peer router to establish
        a session with the targeted router.  By impersonating another
        router, the malicious entity can gain unauthorized access and
        potentially manipulate or disrupt the communication between the
        legitimate routers.





  Li, et al.              Expires 2 September 2026               [Page 34]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     *  Session integrity destruction: In this scenario, a malicious
        intermediate router situated between two peering routers
        intentionally tampers with or destroys the content of the relayed
        SAV-specific message.  By interfering with the integrity of the
        session content, the attacker can disrupt the reliable
        transmission of information, potentially leading to
        miscommunication or inaccurate SAV-related data being propagated.

     The threats to content security include:

     *  Message alteration: A malicious router has the ability to
        manipulate or forge any portion of a SAV-specific message.  For
        example, the attacker may employ techniques such as using a
        spoofed Autonomous System Number (ASN) or modifying the AS path
        information within the message.  By tampering with the content,
        the attacker can potentially introduce inaccuracies or deceive the
        receiving ASes, compromising the integrity and reliability of the
        SAV-related information.

     *  Message injection: A malicious router injects a seemingly
        "legitimate" SAV-specific message into the communication stream
        and directs it to the corresponding next-hop AS.  This type of
        attack can be likened to a replay attack, where the attacker
        attempts to retransmit previously captured or fabricated messages
        to manipulate the behavior or decisions of the receiving ASes.
        The injected message may contain malicious instructions or false
        information, leading to incorrect SAV rule generation or improper
        validation.

     *  Path deviation: A malicious router intentionally diverts a SAV-
        specific message to an incorrect next-hop AS, contrary to the
        expected path defined by the AS path.  By deviating from the
        intended routing path, the attacker can disrupt the proper
        dissemination of SAV-related information and introduce
        inconsistencies or conflicts in the validation process.  This can
        undermine the effectiveness and accuracy of source address
        validation within the inter-domain SAVNET architecture.

     Overall, inter-domain SAVNET shares similar security threats with BGP
     and can leverage existing BGP security mechanisms to enhance both
     session and content security.  Session security can be enhanced by
     employing session authentication mechanisms used in BGP.  Similarly,
     content security can benefit from the deployment of existing BGP
     security mechanisms like RPKI, BGPsec, and ASPA.  While these
     mechanisms can address content security threats, their widespread
     deployment is crucial.  Until then, it is necessary to develop an
     independent security mechanism specifically designed for inter-domain
     SAVNET.  One potential approach is for each source AS to calculate a



  Li, et al.              Expires 2 September 2026               [Page 35]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     digital signature for each AS path and include these digital
     signatures within the SAV-specific messages.  Upon receiving a SAV-
     specific message, the SAVNET agent can verify the digital signature
     to ascertain the message's authenticity.  Furthermore, it is worth
     noting that the SAV-specific information communication mechanism may
     need to operate over a network link that is currently under a source
     address spoofing attack.  As a result, it may experience severe
     packet loss and high latency due to the ongoing attack, and the
     implementation of the SAV-specific communication mechanism should
     ensure uninterrupted communication.  Detailed security designs and
     considerations will be addressed in a separate draft, ensuring the
     robust security of inter-domain SAVNET.

  10.  Manageability Considerations

     It is crucial to consider the operations and management aspects of
     SAV information sources, the SAV-specific communication mechanism,
     SIB, SIM, and SAV table in the inter-domain SAVNET architecture.  The
     following guidelines should be followed for their effective
     management:

     First, management interoperability should be supported across devices
     from different vendors or different releases of the same product,
     based on a unified data model such as YANG [RFC6020].  This is
     essential because the Internet comprises devices from various vendors
     and different product releases that coexist simultaneously.

     Second, scalable operation and management methods such as NETCONF
     [RFC6241] and syslog protocol [RFC5424] should be supported.  This is
     important as an AS may have hundreds or thousands of border routers
     that require efficient operation and management.

     Third, management operations, including default initial
     configuration, alarm and exception reporting, logging, performance
     monitoring and reporting for the control plane and data plane, as
     well as debugging, should be designed and implemented in the
     protocols or protocol extensions.  These operations can be performed
     either locally or remotely, based on the operational requirements.

     By adhering to these rules, the management of SAV information sources
     and related components can be effectively carried out, ensuring
     interoperability, scalability, and efficient operations and
     management of the inter-domain SAVNET architecture.

  11.  Privacy Considerations

     TBD




  Li, et al.              Expires 2 September 2026               [Page 36]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  12.  IANA Considerations

     This document has no IANA requirements.

  13.  Scope and Assumptions

     In this architecture, the choice of protocols used for communication
     between the SIM and different SAV information sources is not limited.
     The inter-domain SAVNET architecture presents considerations on how
     to consolidate SAV-related information from various sources to
     generate SAV rules and perform SAV using the SAV table in the
     dataplane.  The detailed design and implementation for SAV rule
     generation and SAV execution depend on the specific inter-domain SAV
     mechanisms employed.

     This document does not cover administrative or business agreements
     that may be established between the involved inter-domain SAVNET
     parties.  These considerations are beyond the scope of this document.
     However, it is assumed that authentication and authorization
     mechanisms can be implemented to ensure that only authorized ASes can
     communicate SAV-related information.

     This document makes the following assumptions:

     *  All ASes where the inter-domain SAVNET is deployed are assumed to
        provide the necessary connectivity between SAVNET agent and any
        intermediate network elements.  However, the architecture does not
        impose any specific limitations on the form or nature of this
        connectivity.

     *  Congestion and resource exhaustion can occur at various points in
        the inter-domain networks.  Hence, in general, network conditions
        should be assumed to be hostile.  The inter-domain SAVNET
        architecture must be capable of functioning reliably under all
        circumstances, including scenarios where the paths for delivering
        SAV-related information are severely impaired.  It is crucial to
        design the inter-domain SAVNET system with a high level of
        resilience, particularly under extremely hostile network
        conditions.  The architecture should ensure uninterrupted
        communication between inter-domain SAVNET agents, even when data-
        plane traffic saturates the link.

     *  The inter-domain SAVNET architecture does not impose rigid
        requirements for the SAV information sources that can be used to
        generate SAV rules.  Similarly, it does not dictate strict rules
        on how to utilize the SAV-related information from diverse sources
        or perform SAV in the dataplane.  Network operators have the
        flexibility to choose their approaches to generate SAV rules and



  Li, et al.              Expires 2 September 2026               [Page 37]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


        perform SAV based on their specific requirements and preferences.
        Operators can either follow the recommendations outlined in the
        inter-domain SAVNET architecture or manually specify the rules for
        governing the use of SAV-related information, the generation of
        SAV rules, and the execution of SAV in the dataplane.

     *  The inter-domain SAVNET architecture does not impose restrictions
        on the selection of the local AS with which AS to communicate SAV-
        specific Information.  The ASes have the flexibility to establish
        connections for SAV-specific communication based on the manual
        configurations set by operators or other automatic mechanisms.

     *  The inter-domain SAVNET architecture provides the flexibility to
        accommodate Quality-of-Service (QoS) policy agreements between
        SAVNET-enabled ASes or local QoS prioritization measures, but it
        does not make assumptions about their presence.  These agreements
        or prioritization efforts are aimed at ensuring the reliable
        delivery of SAV-specific Information between SAVNET agents.  It is
        important to note that QoS is considered as an operational
        consideration rather than a functional component of the inter-
        domain SAVNET architecture.

     *  The SAVNET communication mechanisms are loosely coupled and are
        used for communicating or gathering SAV-related information, and
        how the inter-domain SAVNET synchronizes the management and
        operation configurations is out of scope of this document.

  14.  Contributors

     Mingqing Huang
     Zhongguancun Laboratory
     Beijing
     China
     Email: huangmq@mail.zgclab.edu.cn

     Igor Lubashev
     Akamai Technologies
     145 Broadway
     Cambridge, MA, 02142
     United States of America
     Email: ilubashe@akamai.com

     Many thanks to Mingqing Huang and Igor Lubashev for the significantly
     helpful discussions and revision suggestions.

  15.  References

  15.1.  Normative References



  Li, et al.              Expires 2 September 2026               [Page 38]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


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

     [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
                Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March
                2004, <https://www.rfc-editor.org/rfc/rfc3704>.

     [RFC8704]  Sriram, K., Montgomery, D., and J. Haas, "Enhanced
                Feasible-Path Unicast Reverse Path Forwarding", BCP 84,
                RFC 8704, DOI 10.17487/RFC8704, February 2020,
                <https://www.rfc-editor.org/rfc/rfc8704>.

     [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
                the Network Configuration Protocol (NETCONF)", RFC 6020,
                DOI 10.17487/RFC6020, October 2010,
                <https://www.rfc-editor.org/rfc/rfc6020>.

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6241>.

     [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424,
                DOI 10.17487/RFC5424, March 2009,
                <https://www.rfc-editor.org/rfc/rfc5424>.

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

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

  15.2.  Informative References

     [I-D.ietf-savnet-inter-domain-problem-statement]
                Li, D., Qin, L., Liu, L., Huang, M., and K. Sriram, "Gap
                Analysis, Problem Statement, and Requirements for Inter-
                Domain SAV", Work in Progress, Internet-Draft, draft-ietf-
                savnet-inter-domain-problem-statement-14, 14 February
                2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
                savnet-inter-domain-problem-statement-14>.




  Li, et al.              Expires 2 September 2026               [Page 39]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


     [I-D.ietf-savnet-intra-domain-architecture]
                Li, D., Wu, J., Qin, L., Geng, N., and L. Chen, "Intra-
                domain Source Address Validation (SAVNET) Architecture",
                Work in Progress, Internet-Draft, draft-ietf-savnet-intra-
                domain-architecture-03, 13 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-savnet-
                intra-domain-architecture-03>.

     [RFC5635]  Kumari, W. and D. McPherson, "Remote Triggered Black Hole
                Filtering with Unicast Reverse Path Forwarding (uRPF)",
                RFC 5635, DOI 10.17487/RFC5635, August 2009,
                <https://www.rfc-editor.org/rfc/rfc5635>.

     [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
                Bacher, "Dissemination of Flow Specification Rules",
                RFC 8955, DOI 10.17487/RFC8955, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8955>.

     [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
                Infrastructure (RPKI) to Router Protocol, Version 1",
                RFC 8210, DOI 10.17487/RFC8210, September 2017,
                <https://www.rfc-editor.org/rfc/rfc8210>.

     [RFC959]   Postel, J. and J. Reynolds, "File Transfer Protocol",
                STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985,
                <https://www.rfc-editor.org/rfc/rfc959>.

     [manrs]    MANRS, "MANRS Implementation Guide", 2023,
                <https://www.manrs.org/netops/guide/antispoofing/>.

     [nist]     NIST, "Resilient Interdomain Traffic Exchange: BGP
                Security and DDos Mitigation", 2019,
                <https://www.nist.gov/publications/resilient-interdomain-
                traffic-exchange-bgp-security-and-ddos-mitigation>.

     [rpki-time-of-flight]
                ISOC, "RPKI Time-of-Flight&#58; Tracking Delays in the
                Management, Control, and Data Planes", n.d.,
                <https://dl.acm.org/doi/10.1007/978-3-031-28486-1_18>.

     [sav-table]
                "General Source Address Validation Capabilities", 2025,
                <https://datatracker.ietf.org/doc/draft-ietf-savnet-
                general-sav-capabilities/>.







  Li, et al.              Expires 2 September 2026               [Page 40]


  Internet-Draft      Inter-domain SAVNET Architecture          March 2026


  Acknowledgements

     Many thanks to Alvaro Retana, Kotikalapudi Sriram, Rüdiger Volk,
     Xueyan Song, Ben Maddison, Jared Mauch, Joel Halpern, Aijun Wang,
     Jeffrey Haas, Xiangqing Chang, Changwang Lin, Mingxing Liu, Zhen Tan,
     Yuanyuan Zhang, Yangyang Wang, Antoin Verschuren, Olaf Struck, Siyuan
     Teng, Gert Doering etc. for their reviews, comments, and suggestions.
     Apologies to any others whose names the authors may have
     inadvertently missed mentioning.

  Authors' Addresses

     Dan Li
     Tsinghua University
     Beijing
     China
     Email: tolidan@tsinghua.edu.cn


     Li Chen
     Zhongguancun Laboratory
     Beijing
     China
     Email: lichen@zgclab.edu.cn


     Nan Geng
     Huawei
     Beijing
     China
     Email: gengnan@huawei.com


     Libin Liu
     Zhongguancun Laboratory
     Beijing
     China
     Email: liulb@zgclab.edu.cn


     Lancheng Qin
     Zhongguancun Laboratory
     Beijing
     China
     Email: qinlc@mail.zgclab.edu.cn






  Li, et al.              Expires 2 September 2026               [Page 41]


name: draft-ffm-rats-cca-token
rev: 03
title: Arm's Confidential Compute Architecture Reference Attestation Token
time: 2026-03-02T16:28:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T16:28:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.654078+00:00
source: ietf
abstract:
  The Arm Confidential Compute Architecture (CCA) is series of hardware
     and software innovations that enhance Arm’s support for Confidential
     Computing for large, compute-intensive workloads.  Devices that
     implement CCA can produce attestation tokens as described in this
     memo, which are the basis for trustworthiness assessment of the
     Confidential Compute environment.  This document specifies the CCA
     attestation token structure and semantics.

     The CCA attestation token is a profile of the Entity Attestation
     Token (EAT).  This specification describes what claims are used in an
     attestation token generated by CCA compliant systems, how these
     claims get serialized to the wire, and how they are cryptographically
     protected.

     This informational document is published as an independent submission
     to improve interoperability with Arm's architecture.  It is not a
     standard nor a product of the IETF.

full_text:
  Network Working Group                                           S. Frost
  Internet-Draft                                               Arm Limited
  Intended status: Informational                                T. Fossati
  Expires: 3 September 2026                                         Linaro
                                                                G. Mandyam
                                                              Mediatek Inc
                                                              2 March 2026


    Arm's Confidential Compute Architecture Reference Attestation Token
                        draft-ffm-rats-cca-token-03

  Abstract

     The Arm Confidential Compute Architecture (CCA) is series of hardware
     and software innovations that enhance Arm’s support for Confidential
     Computing for large, compute-intensive workloads.  Devices that
     implement CCA can produce attestation tokens as described in this
     memo, which are the basis for trustworthiness assessment of the
     Confidential Compute environment.  This document specifies the CCA
     attestation token structure and semantics.

     The CCA attestation token is a profile of the Entity Attestation
     Token (EAT).  This specification describes what claims are used in an
     attestation token generated by CCA compliant systems, how these
     claims get serialized to the wire, and how they are cryptographically
     protected.

     This informational document is published as an independent submission
     to improve interoperability with Arm's architecture.  It is not a
     standard nor a product of the IETF.

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



  Frost, et al.           Expires 3 September 2026                [Page 1]


  Internet-Draft       CCA Reference Attestation Token          March 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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     3.  CCA Attester Model  . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Direct  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Delegated . . . . . . . . . . . . . . . . . . . . . . . .   8
       3.3.  Boot Phase  . . . . . . . . . . . . . . . . . . . . . . .   8
       3.4.  Run-time Phase  . . . . . . . . . . . . . . . . . . . . .   9
     4.  CCA Claims  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  CCA Attestation Token top level wrapper . . . . . . . . .  11
       4.2.  CCA Platform token Claims . . . . . . . . . . . . . . . .  11
       4.3.  Caller Claims . . . . . . . . . . . . . . . . . . . . . .  11
         4.3.1.  CCA Platform Nonce  . . . . . . . . . . . . . . . . .  12
       4.4.  Target Identification Claims  . . . . . . . . . . . . . .  12
         4.4.1.  CCA Platform Instance ID  . . . . . . . . . . . . . .  12
         4.4.2.  CCA Platform Implementation ID  . . . . . . . . . . .  13
       4.5.  Target State Claims . . . . . . . . . . . . . . . . . . .  14
         4.5.1.  CCA Platform Profile Definition . . . . . . . . . . .  14
         4.5.2.  Security Lifecycle  . . . . . . . . . . . . . . . . .  14
         4.5.3.  Platform Config . . . . . . . . . . . . . . . . . . .  17
         4.5.4.  Platform Config . . . . . . . . . . . . . . . . . . .  18
       4.6.  Software Inventory Claims . . . . . . . . . . . . . . . .  18
         4.6.1.  Software Components . . . . . . . . . . . . . . . . .  19
         4.6.2.  CCA Platform Hash Algorithm ID  . . . . . . . . . . .  21
         4.6.3.  CCA Platform Client ID  . . . . . . . . . . . . . . .  21
         4.6.4.  CCA Platform Manufacturing Config . . . . . . . . . .  21
         4.6.5.  CCA Platform Extension  . . . . . . . . . . . . . . .  22
         4.6.6.  CCA Platform Peer Signers . . . . . . . . . . . . . .  23
         4.6.7.  CCA Platform TBB ROTPK  . . . . . . . . . . . . . . .  24
       4.7.  Verification Claims . . . . . . . . . . . . . . . . . . .  24
         4.7.1.  Verification Service Indicator  . . . . . . . . . . .  24
       4.8.  CCA Realm state token Claims  . . . . . . . . . . . . . .  25
         4.8.1.  Realm Nonce . . . . . . . . . . . . . . . . . . . . .  25
         4.8.2.  Realm Profile Definition  . . . . . . . . . . . . . .  26
         4.8.3.  Realm Personalisation Value . . . . . . . . . . . . .  26
         4.8.4.  Realm Initial Measurement . . . . . . . . . . . . . .  27



  Frost, et al.           Expires 3 September 2026                [Page 2]


  Internet-Draft       CCA Reference Attestation Token          March 2026


         4.8.5.  Realm Extensible Measurements . . . . . . . . . . . .  27
         4.8.6.  Realm Hash Algorithm Measurements . . . . . . . . . .  27
         4.8.7.  Realm Public Key  . . . . . . . . . . . . . . . . . .  28
         4.8.8.  Realm Public Key Hash Algorithm ID  . . . . . . . . .  28
       4.9.  Backwards Compatibility Considerations  . . . . . . . . .  28
       4.10. Token Binding . . . . . . . . . . . . . . . . . . . . . .  29
       4.11. Reference Profile . . . . . . . . . . . . . . . . . . . .  29
         4.11.1.  Token Encoding and Signing . . . . . . . . . . . . .  29
         4.11.2.  Freshness Model  . . . . . . . . . . . . . . . . . .  30
         4.11.3.  Synopsis . . . . . . . . . . . . . . . . . . . . . .  30
     5.  Collated CDDL . . . . . . . . . . . . . . . . . . . . . . . .  31
     6.  Signing key implementation alternatives . . . . . . . . . . .  36
     7.  CCA Attestation Token Verification  . . . . . . . . . . . . .  37
       7.1.  AR4SI Trustworthiness Claims Mappings . . . . . . . . . .  38
       7.2.  Endorsements, Reference Values and Verification Key
             Material  . . . . . . . . . . . . . . . . . . . . . . . .  39
     8.  Implementation Status . . . . . . . . . . . . . . . . . . . .  39
     9.  Security and Privacy Considerations . . . . . . . . . . . . .  40
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
       10.1.  CBOR Web Token Claims Registration . . . . . . . . . . .  40
         10.1.1.  Arm CCA Attestation CMW  . . . . . . . . . . . . . .  40
         10.1.2.  Security Lifecycle Claim . . . . . . . . . . . . . .  40
         10.1.3.  Implementation ID Claim  . . . . . . . . . . . . . .  41
         10.1.4.  Software Components Claim  . . . . . . . . . . . . .  41
         10.1.5.  Verification Service Indicator Claim . . . . . . . .  41
         10.1.6.  Platform Config Claim  . . . . . . . . . . . . . . .  42
         10.1.7.  Platform Hash Algorithm ID Claim . . . . . . . . . .  42
         10.1.8.  Platform Manufacturing Config  . . . . . . . . . . .  42
         10.1.9.  Platform Extension . . . . . . . . . . . . . . . . .  43
         10.1.10. Platform TBB RoTPK . . . . . . . . . . . . . . . . .  43
         10.1.11. Platform Peer Signers  . . . . . . . . . . . . . . .  43
         10.1.12. CCA Token Platform Token Label . . . . . . . . . . .  44
         10.1.13. Realm Personalization Value Claim  . . . . . . . . .  44
         10.1.14. Realm Hash Algorithm ID Claim  . . . . . . . . . . .  44
         10.1.15. Realm Public Key Claim . . . . . . . . . . . . . . .  45
         10.1.16. Realm Initial Measurement Claim  . . . . . . . . . .  45
         10.1.17. Realm Extensible Measurements Claim  . . . . . . . .  45
         10.1.18. Realm Public Key Hash Algorithm ID Claim . . . . . .  46
         10.1.19. CCA Token Delegated Realm Token Label  . . . . . . .  46
       10.2.  Media Types  . . . . . . . . . . . . . . . . . . . . . .  47
       10.3.  CoAP Content-Formats Registration  . . . . . . . . . . .  47
         10.3.1.  Registry Contents  . . . . . . . . . . . . . . . . .  47
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  47
       11.1.  Normative References . . . . . . . . . . . . . . . . . .  47
       11.2.  Informative References . . . . . . . . . . . . . . . . .  49
     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  51
       A.1.  Delegated Mode  . . . . . . . . . . . . . . . . . . . . .  51
         A.1.1.  Platform Claims Set . . . . . . . . . . . . . . . . .  51



  Frost, et al.           Expires 3 September 2026                [Page 3]


  Internet-Draft       CCA Reference Attestation Token          March 2026


         A.1.2.  Realm Claims Set  . . . . . . . . . . . . . . . . . .  54
         A.1.3.  Platform Attestation Key  . . . . . . . . . . . . . .  55
         A.1.4.  Realm Attestation Key . . . . . . . . . . . . . . . .  55
         A.1.5.  Signed and Bound Assembly . . . . . . . . . . . . . .  55
       A.2.  Direct Mode . . . . . . . . . . . . . . . . . . . . . . .  61
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  61
     Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  61
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  61

  1.  Introduction

     The Arm Confidential Compute Architecture (CCA) [CCA-ARCH] is a set
     of hardware [RME] and firmware [RMM] specifications, backed by a
     reference implementation [TF-RMM] .

     CCA provides confidential compute environments, called Realms, that
     can be dynamically allocated by the Normal world host.  The initial
     state of a Realm, and of the platform on which it executes, can be
     attested.  Attestation allows the Realm owner to establish trust in
     the Realm, before provisioning any secrets to it.  The Realm does not
     have to inherit the trust from the Non-secure hypervisor which
     controls it.

     As outlined in the RATS Architecture [RFC9334], an Attester produces
     a signed collection of Claims that constitutes Evidence about its
     target environment.  This document focuses on the output provided by
     requests from the Realm to the Realm Management Monitor (RMM)
     management component for an attestation token that covers the state
     of that Realm and the CCA Platform.  This output corresponds to
     Evidence in [RFC9334] and, as a design decision, the CCA attestation
     token is a profile of the Entity Attestation Token (EAT) [EAT].  Note
     that there are other profiles of EAT available, such as
     [I-D.kdyxy-rats-tdx-eat-profile] and [I-D.mandyam-rats-qwestoken],
     for use with different use cases and by different attestation
     technologies.

     Since the CCA tokens are consumed by services outside the device,
     there is an actual need to ensure interoperability.  Interoperability
     needs are addressed here by describing the exact syntax and semantics
     of the attestation claims, and defining the way these claims are
     encoded and cryptographically protected.

     Further details on concepts expressed below can be found in the Realm
     Management Monitor specification 1.0 [RMM].

     As mentioned in the abstract, this memo documents a vendor extension
     to the RATS architecture, and is not a standard.




  Frost, et al.           Expires 3 September 2026                [Page 4]


  Internet-Draft       CCA Reference Attestation Token          March 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.

     The terms Attester, Relying Party, Verifier, Attestation Result,
     Target Environment, Attesting Environment and Evidence are defined in
     [RFC9334].  We use the term "receiver" to refer to Relying Parties
     and Verifiers.

     We use the terms Evidence, "CCA attestation token", and "CCA token"
     interchangeably.  The terms "sender" and Attester are used
     interchangeably.  Likewise, we use the terms Verifier and
     "verification service" interchangeably.

     RoT:
        Root of Trust, the minimal set of software, hardware and data that
        has to be implicitly trusted in the platform - there is no
        software or hardware at a deeper level that can verify that the
        Root of Trust is authentic and unmodified.  An example of a RoT
        suitable for CCA would be an isolated Trusted subsystem
        responsible for initial measurements, lifecycle state management,
        identity and attestation services.  The services that the RoT
        provides for securitization of the CCA environment are described
        as Hardware-Enforced Security (HES) - see Section B4.1.5 of
        [RME-SYSARCH].

     Realm-World:
        Realm World, provides a security state and physical address range
        that provides an execution environment for VMs that is isolated
        from the Normal and Secure worlds.  The controlling firmware
        running in the Realm world can access memory in the Normal world
        to allow shared buffers.  (This is similar to Trusted Execution
        Environment (TEE), "secure world", or "secure enclave".)

     Realm:
        the Realm execution environment, is an Arm CCA environment that
        can be dynamically allocated by the Normal world Host.

     NW-Host:
        Normal world host, refers to the security domain outside of the
        restricted Root, Secure and Realm worlds.  This typically contains
        the host hypervisor and supervisory services.  The NW-Host can
        allocate and manage resource allocation and can manage the
        scheduling for other worlds.



  Frost, et al.           Expires 3 September 2026                [Page 5]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     In this document, the structure of data is specified in Concise Data
     Definition Language (CDDL) [RFC8610].

  3.  CCA Attester Model

     There are two kinds of CCA Attester: direct and delegated.  Their
     architectural arrangements are described in Section 3.1 and
     Section 3.2, respectively.

     Both arrangements implement a "layered attester" (Section 3.2 of
     [RFC9334]) with exactly two layers: platform and realm.

     The Realm Management Monitor (RMM) is the top layer Attesting
     Environment.  It attests to the initial memory content of each Realm
     that is executed on a CCA platform, any dynamic measurements provided
     by Realm guest code and aditional evidence about the state of a
     Realm.

     The HES (Hardware Enforced Security) is the bottom layer Attesting
     Environment, which acts as the CCA platform hardware RoT.  It attests
     to the executables and configuration contents of the "Monitor
     Security Domain", which includes the RMM, as well as the identity,
     configuration and state of the CCA platform.  This produces a set of
     claims forming the CCA Platform evidence.

     The following architecture applies to both following attester models.

























  Frost, et al.           Expires 3 September 2026                [Page 6]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                                        .----------.
                                        |          |
                                        | Verifier |
                                        |          |
                                        '----------'
                                             ^
     .-----------------------------------.   |
     |    .-------------.                |   |
     |    | Target      |                |   |
     |    | Environment +----.           |   | Layered
     |    |             | TE |           |   | Evidence for
     |    | Realm 1     |    +----.      |   | Platform and
     |    '-+--+--------'    | TE |      |   | Realm
     |      |  | Realm 2     |    |      |   |
     |      |  '-+--+--------'    |      |   |
     |      |    |  |  ...        |      |   |
     |      |    |  '-+-----------'      |   |
     |      |    |    | Collect Claims   |   |
     | .----| ---|----|----------------. |   |
     | |    v    v    v    Target      | |   |
     | |   .-----------.   Environment | |   |
     | |  | Realm       |              | |   |
     | |  | Management  +-------------------'
     | |  | Monitor     | .----------. | |
     | |  | (RMM)       | |   BLs    | | |
     | |  |             | '----------' | |
     | |  |             |              | |
     | |  | Attesting   | .----------. | |
     | |  | Environment | |   CFGs   | | |
     | |   '-----------'  '----------' | |
     | |    ^                 Platform | |
     | '----|--------------+-----------' |
     |      | Evidence     | Collect     |
     |      | for          | Claims      |
     |      | Platform     v             |
     |  .---+----------------------.     |
     | | Hardware                   |    |
     | | Enforced                   |    |
     | | Security       Attesting   |    |
     | | (HES)          Environment |    |
     |  '--------------------------'     |
     '-----------------------------------'

                             Figure 1: CCA Attester







  Frost, et al.           Expires 3 September 2026                [Page 7]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  3.1.  Direct

     The structure of the CCA direct Attester is illustrated in TODO-fig-
     cca-direct-attester.

     In the direct model, the RMM creates a set of claims that represent
     the state of a Realm.  This set of claims is hashed and that hash is
     passed to the HES when requesting the CCA Platform evidence.  This
     hash is included in a claim within the CCA Platform evidence.  The
     platform evidence is signed using the CCA Platform Attestation Key
     (CPAK).

     The CCA Evidence produced with the direct model comprises a signed
     EAT for the platform token and an unsigned EAT for the realm token,
     wrapped in a CMW [CMW] collection.  The intra-collection binding is
     detailed in Section 4.10.

     change addresses: Issue #16 (https://github.com/SimonFrost-Arm/draft-
     ffm-rats-cca-token/issues/16)

  3.2.  Delegated

     The structure of the CCA delegated Attester is illustrated in
     Figure 1.

     In the delegated model, the RMM uses its own private key called RAK
     (Realm Attestation Key) to sign the claims regarding the requesting
     Realm.

     The RAK keypair is derived within the HES.  The RAK is transferred
     over a trusted channel to the RMM.  The platform evidence include a
     claim containg a hash of the RAK public key.  The platform evidence
     is signed using the CCA Platform Attestation Key (CPAK).

     The CCA Evidence produced in delegated mode comprises two separately
     signed EATs, one for the platform, another for the realm, wrapped in
     a CMW [CMW] collection.  The intra-collection binding is detailed in
     Section 4.10.

     TODO: Device Token

  3.3.  Boot Phase

     The HES Attesting Environment is responsible for collecting the
     information to be represented in CCA platform claims and to assemble
     them into Evidence.





  Frost, et al.           Expires 3 September 2026                [Page 8]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     The Main Bootloader, executing at boot-time, measures the trusted
     computing base (TCB) of the Realm World - i.e., loaded firmware
     components and the associated configuration payloads - and sends them
     to the HES RoT to be stored isolated.  See Figure 2.

         i-th Target    Main Boot        HES
         Environment      Loader         RoT
              |             |             |
     .--------|-------------|-------------|----.
     | loop i |             |             |    |
     |        | measure     |             |    |
     |        |o------------+             |    |
     |        |             | write       |    |
     |        |             | measurement |    |
     |        |             +------------>|    |
     '--------|-------------|-------------|----'
              |             |             |

                       Figure 2: CCA Attester Boot Phase

  3.4.  Run-time Phase

     The Realm Management Monitor (RMM), executing at run-time, maintains
     measurements for the state of a Realm.  It can respond to requests
     issued from a Realm for an attestation token relevant for that Realm
     by obtaining a CCA Platform attestation token from the HES RoT and
     combining that with an attestation token containing Evidence
     reflecting Realm state.

     The HES RoT, executing at run-time, maintains measurements for the
     state of the CCA platform TCB, including the lifecycle state of the
     CCA platform.  It can answer requests coming from the RMM to collect
     and format claims corresponding to that state and use a CCA Platform
     Attestation Key (CPAK) to sign them (see Figure 3).  How the CPAK is
     derived is implementation-specific.
















  Frost, et al.           Expires 3 September 2026                [Page 9]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                HES           Realm
                RoT           Manager     Verifier
                 |               |           |
                 |               |           |
       Platform  |               |           |
       Boot      |               |           |
       State     | Req. Platform |           |
         |       | Token (#RAK)  |           |
         |       |<--------------+           |
         v       |               |           |
       Platform  |               |           |
       Token     |               |           |
                 |               |           |
        sign .---+               |           |
        w/   |   |               |           |
        CPAK '-->|   Plat Token  |           |
                 +-------------->|           |
                 |               |           |
                 |     Realm     |           |
                 |     State     |           |
                 |       |       |           |
                 |       |       |           |
                 |       v       |           |
                 |     Realm     |           |
                 |     Token     |           |
                 |               |           |
                 |      sign .---+           |
                 |      w/   |   |           |
                 |      RAK  '-->|           |
                 |               |           |
                 |               |           |
                 |               | CCA Token |
                 |               +---------->|
                 |               |           |

                     Figure 3: CCA Attester Run-time Phase

     A reference implementation of the CCA Attester is provided by
     [TF-RMM].

  4.  CCA Claims

     This section describes the claims to be used in a CCA reference
     attestation token.

     There are two logical sections within the CCA attestation token,
     relating to the two Target Environment elements:




  Frost, et al.           Expires 3 September 2026               [Page 10]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  The CCA Platform token

     *  The Realm state token

     The two sections use inter-related claims to bind together into a
     single logical unit.  See Section 9 for more details.

     The above tokens are presented to the requester within a top level
     Conceptual Message Wrapper (CMW) collection [CMW].

     CDDL [RFC8610] along with text descriptions is used to define each
     claim independent of encoding.  The following CDDL type(s) are reused
     by different claims:

     arm-platform-hash-type = bytes .size 32 /
                              bytes .size 48 /
                              bytes .size 64

  4.1.  CCA Attestation Token top level wrapper

     The above tokens are presented to the requester within a top level
     CMW collection [CMW].  The collection map has two entries, one for a
     bstr encoding of the CCA Platform token and the other for a bstr
     encoding of the Realm state token.  The type of the CMW entry will
     vary for the Realm state token depending on whether the delegated or
     direct model is used by an implementation.

     ; CMW (draft-ietf-rats-msg-wrap) Collection
     cca-token = #6.907(cca-token-cmw)

     ; CoAP Content-Format for "application/eat+cwt"
     eat-cwt-coap-cf = 263

     cca-token-cmw = {
       0xACCA => [
         eat-cwt-coap-cf
         bytes .cbor COSE_Sign1<arm-platform-claims>
       ]
       0xACD1 => [
         eat-cwt-coap-cf
         bytes .cbor COSE_Sign1<cca-realm-claims>
       ]
     }

  4.2.  CCA Platform token Claims

  4.3.  Caller Claims




  Frost, et al.           Expires 3 September 2026               [Page 11]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.3.1.  CCA Platform Nonce

     The Nonce claim is used to carry a challenge provided by the caller
     to demonstrate freshness of the generated token.

     The EAT [EAT] nonce (claim key 10) is used.  Since the EAT nonce
     claim offers flexiblity for different attestation technologies, this
     specifications applies the following constraints to the nonce-type:

     *  The length MUST be either 32, 48, or 64 bytes.

     *  Only a single nonce value is conveyed.  The array notation MUST
        NOT be used for encoding the nonce value.

     Where the CCA Platform implementation uses the Delegated Token
     signing model Section 4.10, the value of the Nonce claim will be a
     hash of the Realm Public Key claim of the CCA Realm State token
     Section 4.8.7.

     This claim MUST be present in a CCA Platform attestation token.

     arm-platform-challenge-label = 10

     arm-platform-challenge = (
         arm-platform-challenge-label => arm-platform-hash-type
     )

  4.4.  Target Identification Claims

  4.4.1.  CCA Platform Instance ID

     The Instance ID claim represents the unique identifier of the
     Platform Attestation Key (PAK).  The EAT ueid (claim key 256) of type
     RAND is used.  The following constraints apply to the ueid-type:

     *  The length MUST be 33 bytes.

     *  The first byte MUST be 0x01 (RAND) followed by the 32-byte unique
        identifier of the PAK.












  Frost, et al.           Expires 3 September 2026               [Page 12]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     eat-ueid-rand-type = bytes .join eat-ueid-rand-fmt

     eat-ueid-rand-fmt = [
       ; the type byte is 0x01
       ueid-rand-typ
       bytes .size 32
     ]

     ueid-rand-typ = h'01'

     This claim MUST be present in a CCA Platform attestation token.

     arm-platform-instance-id-label = 256 ; EAT ueid

     arm-platform-instance-id-type = eat-ueid-rand-type

     arm-platform-instance-id = (
         arm-platform-instance-id-label => arm-platform-instance-id-type
     )

  4.4.2.  CCA Platform Implementation ID

     The Implementation ID claim uniquely identifies the implementation of
     the CCA Platform.  The value of the CCA platform Implementation ID
     claim can be used by a verification service to locate the details of
     the CCA platform implementation from an endorser or manufacturer.
     Such details are used by a verification service to determine the
     security properties or certification status of the CCA Platform
     implementation.

     The value and format of the ID is decided by the manufacturer or a
     particular certification scheme.  For example, the ID could take the
     form of a product serial number, database ID, or other appropriate
     identifier.

     This claim MUST be present in a CCA Platform attestation token.

     Note that this identifies the CCA Platform implementation, not a
     particular instance.  To uniquely identify an instance, see the
     Instance ID claim Section 4.4.1.

     arm-platform-implementation-id-label = 2396 ; PSA implementation ID
     arm-platform-implementation-id-type = bytes .size 32

     arm-platform-implementation-id = (
         arm-platform-implementation-id-label =>
             arm-platform-implementation-id-type
     )



  Frost, et al.           Expires 3 September 2026               [Page 13]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.5.  Target State Claims

  4.5.1.  CCA Platform Profile Definition

     The CCA platform profile claim identifies the EAT profile to which
     the CCA platform token conforms.  This allows a receiver to assign
     the intended semantics to the rest of the claims found in the token.

     The EAT eat_profile (claim key 265) is used.

     The format of the CCA platform profile claim is defined as a text
     string of value "tag:arm.com,2024:cca_platform#2.0.0".

     This claim MUST be present in a CCA Platform attestation token.

     See Section 4.9, for considerations about backwards compatibility
     with previous versions of the CCA Platform attestation token format.

     arm-platform-profile-label = 265 ; EAT profile

     arm-platform-profile-type = "tag:arm.com,2024:cca_platform#2.0.0"

     arm-platform-profile = (
         arm-platform-profile-label => arm-platform-profile-type
     )

  4.5.2.  Security Lifecycle

     The Security Lifecycle claim represents the current lifecycle state
     of the CCA Platform.

     The state is represented by an integer that is divided as follows:

     *  major[15:8] - CCA Platform security lifecycle state, and

     *  minor[7:0] - IMPLEMENTATION DEFINED state.

     The CCA Platform lifecycle states are illustrated in Figure 4.  A non
     debugged CCA platform will be in arm-platform-lifecycle-secured
     state.  Realm Management Security Domain debug is always recoverable,
     and would therefore be represented by arm-platform-lifecycle-non-
     platform-rot-debug state.  Root world debug is recoverable on a HES
     system and would be represented by arm-platform-lifecycle-
     recoverable-platform-rot state.  On a non-HES system Root world debug
     is usually non-recoverable, and would be represented by arm-platform-
     lifecycle-lifecycle-decommissioned state

     This claim MUST be present in a CCA Platform attestation token.



  Frost, et al.           Expires 3 September 2026               [Page 14]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                      .--------------------------.
                      | Device Assembly and Test |
                      '------------+-------------'
                                   | Device
                                   | Lockdown
                                   v
                     .----------------------------.
                     | CCA Security Provisioning  |
                     '-----------+----------------'
                                 |
                    Provisioning |  .---------------------.
                      Lockdown   |  |                     |
                                 v  v                     |
                           .----------------.             |Recoverable
            .--------------+    Secured     +--------.    |
            |              '-+--------------'        |    |
           Non               |          ^     Recoverable |
       Recoverable       RM Debug       |     Root Debug  |
       Root Debug          Enable       |            |    |
            |                |          |            |    |
            |                v          |            v    |
            |              .---------- -+--.      .-------+-.
            |              | Realm Manager |      |  Root   |
            |              |    Debug      |      | Debug   |
            |              '---------------'      '--+------'
            |                                        |
            |            .---------------.           |
            '----------->+   Terminate   +<----------'
                         '---------------'
                                 |
                                 |
                                 v
                         .----------------.
                         | Decommissioned |
                         '----------------'

                    Figure 4: CCA Platform Lifecycle States

     The CDDL representation is shown below.  Table 1 provides the
     mappings between Figure 4 and the data model.











  Frost, et al.           Expires 3 September 2026               [Page 15]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  arm-platform-lifecycle-label = 2395 ; PSA lifecycle

  arm-platform-lifecycle-unknown-type = 0x0000..0x00ff
  arm-platform-lifecycle-assembly-and-test-type = 0x1000..0x10ff
  arm-platform-lifecycle-platform-rot-provisioning-type = 0x2000..0x20ff
  arm-platform-lifecycle-secured-type = 0x3000..0x30ff
  arm-platform-lifecycle-non-platform-rot-debug-type = 0x4000..0x40ff
  arm-platform-lifecycle-recoverable-platform-rot-debug-type = 0x5000..0x50ff
  arm-platform-lifecycle-decommissioned-type = 0x6000..0x60ff

  arm-platform-lifecycle-type =
      arm-platform-lifecycle-unknown-type /
      arm-platform-lifecycle-assembly-and-test-type /
      arm-platform-lifecycle-platform-rot-provisioning-type /
      arm-platform-lifecycle-secured-type /
      arm-platform-lifecycle-non-platform-rot-debug-type /
      arm-platform-lifecycle-recoverable-platform-rot-debug-type /
      arm-platform-lifecycle-decommissioned-type

  arm-platform-lifecycle = (
      arm-platform-lifecycle-label => arm-platform-lifecycle-type
  )

     arm-platform-lifecycle-unknown-type is not shown in Figure 4; it
     represents an invalid state that must not occur in a system.


























  Frost, et al.           Expires 3 September 2026               [Page 16]


  Internet-Draft       CCA Reference Attestation Token          March 2026


         +=====================================+====================+
         | CDDL                                | Lifecycle States   |
         +=====================================+====================+
         | arm-platform-lifecycle-unknown-type |                    |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-assembly-    | Assembly and Test  |
         | and-test-type                       |                    |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-platform-    | CCA Platform       |
         | rot-provisioning-type               | Provisioning       |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-secured-type | Secured            |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-non-         | Non-Recoverable    |
         | platform-rot-debug-type             | CCA Platform Debug |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-recoverable- | Recoverable CCA    |
         | platform-rot-debug-type             | Platform Debug     |
         +-------------------------------------+--------------------+
         | arm-platform-lifecycle-             | Decommissioned     |
         | decommissioned-type                 |                    |
         +-------------------------------------+--------------------+

                      Table 1: Lifecycle States Mappings

  4.5.3.  Platform Config

     The CCA platform config claim describes the set of chosen
     implementation options of the CCA platform.  As an example, these may
     include a description of the level of physical memory protection
     which is provided.

     The CCA platform config byte string contains implementation
     information that is provided by the chip vendor and the device
     vendor.  This is expected to include the following system properties
     (see {RME-SYSARCH}} for details):

     *  Per-PAS encryption (all RME systems will require this property)

     *  MEC

     *  MPE Level

        -  L0 (none)

        -  L1 (encryption only)

        -  L2 (encryption and integrity)



  Frost, et al.           Expires 3 September 2026               [Page 17]


  Internet-Draft       CCA Reference Attestation Token          March 2026


        -  L3 (anti-replay)

     *  RME-DA support

     *  RME-CDA support

     The layout and encoding of this information is IMPLEMENTATION
     DEFINED.

     An attestation verifier should use information from the an
     attestation profile document applicable to the implementation to
     understand the IMPLEMENTATION DEFINED choices made for this field.
     Reference values can be accompanied by a bitmask identifying the
     relevant portion of the platform config claim.

     This claim MUST be present in a CCA Platform attestation token.

     arm-platform-config-label = 2401 ; PSA platform range
                                      ; TBD: add to IANA registration
     arm-platform-config-type = bytes

     arm-platform-config = (
         arm-platform-config-label => arm-platform-config-type
     )

  4.5.4.  Platform Config

     The CCA platform manufacturing config claim represents a record of
     production phases and testing conducted during the manufacturing
     process for this instance.

     The CCA platform manufacturing config claim is optional in a CCA
     platform token

     arm-platform-manufacturing-config-label = 2403

     arm-platform-manufacturing-config-type = bytes

     arm-platform-manufacturing-config = (
         arm-platform-manufacturing-config-label =>
             arm-platform-manufacturing-config-type
     )

  4.6.  Software Inventory Claims







  Frost, et al.           Expires 3 September 2026               [Page 18]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.6.1.  Software Components

     The Software Components claim is a list of software components which
     can affect the behavior of the CCA platform.

     This claim MUST be present in a CCA Platform attestation token.

     Each entry in the Software Components list describes one software
     component using the attributes described in the following
     subsections.  Unless explicitly stated, the presence of an attribute
     is OPTIONAL.

     It is expected that an implementation will describe the expected
     software component values within the profile.  In some
     implementations, a software component may consist of a configuration
     data item.

     Note that, as described in [RFC9334], a relying party will typically
     see the result of the appraisal process from the Verifier in form of
     an Attestation Result, rather than the CCA Platform token from the
     attesting endpoint.  Therefore, a relying party is not expected to
     understand the Software Components claim.  Instead, it is for the
     Verifier to check this claim against the available Reference Values
     and provide an answer in form of an "high level" Attestation Result,
     which may or may not include the original Software Components claim.

   arm-platform-sw-components-label = 2399 ; PSA software components

   arm-platform-sw-component = {
     ? 1 => text,                   ; component type
       2 => arm-platform-hash-type, ; measurement value
     ? 4 => text,                   ; version
       5 => arm-platform-hash-type, ; signer id
     ? 6 => text,                   ; hash algorithm identifier
   }

   arm-platform-sw-components = (
       arm-platform-sw-components-label => [ + arm-platform-sw-component ]
   )

  4.6.1.1.  Component Type

     The Component Type attribute (key=1) is a short string representing
     the role of this software component.  This attribute is intended for
     use as a hint to help the verifier understand how to evaluate the CCA
     platform software component measurement value.

     This attribute is optional in a CCA Platform software component.



  Frost, et al.           Expires 3 September 2026               [Page 19]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.6.1.2.  Measurement Value

     The Measurement Value attribute (key=2) represents a hash of the
     state of the software component in memory at the time it was
     initialized.  The measurement values are implemented such that the
     values can only be extended rather than set.  The values are
     initialised to 0, so the value reported in attestation will be H(
     0 || H(software component)).  If the CCA platform supports Live
     Firmware Activation then the value reported in attestation may have
     been further extended by measurements of updates to the software
     component.  In this case, the value of the measurement must be
     validated by reconstructing the reported value using information from
     the Firmware Activity Log

     The value MUST be a cryptographic hash of 256 bits or stronger.

     This attribute MUST be present in a CCA Platform software component.

  4.6.1.3.  Version

     The Version attribute (key=4) is the issued software version in the
     form of a text string.  The meaning of this string is defined by the
     software component vendor.

     This attribute is optional in a CCA Platform software component.

  4.6.1.4.  Signer ID

     The Signer ID attribute (key=5) uniquely identifies the signer of the
     software component.  The identification is typically accomplished by
     hashing the signer's public key.  The value of this attribute will
     correspond to the entry in the original manifest for the component.
     This can be used by a Verifier to ensure the components were signed
     by an expected trusted source.

     This attribute MUST be present in a CCA Platform software component.

  4.6.1.5.  Measurement Description

     The Measurement Description attribute (key=6) contains a string
     identifying the hash algorithm used to compute the corresponding
     Measurement Value.  The string SHOULD be encoded according to "Hash
     Name String" in the "Named Information Hash Algorithm Registry"
     [IANA.named-information].







  Frost, et al.           Expires 3 September 2026               [Page 20]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.6.2.  CCA Platform Hash Algorithm ID

     The CCA platform hash algorithm ID claim is a text string that
     identifies the algorithm used to calculate the extended measurements
     in the CCA platform token.

     The string SHOULD be encoded according to "Hash Name String" in the
     "Named Information Hash Algorithm Registry" [IANA.named-information].

     The CCA platform hash algorithm ID claim MUST be present in a CCA
     platform token.

    arm-platform-hash-algo-id-label = 2402 ; PSA platform range
                                           ; TBD: add to IANA registration

    arm-platform-hash-algo-id = (
        arm-platform-hash-algo-id-label => text
    )

  4.6.3.  CCA Platform Client ID

     The CCA platform client ID claim identifies the security domain from
     which the attestation token was requested.

     In this profile, the only valid value for the CCA platform client ID
     claim is the Realm Management Security Domain (RMSD).

     The CCA platform client ID claim MUST be present in a CCA platform
     token.

     arm-platform-client-id-label = 2394 ; PSA namespace

     arm-platform-client-id-rmsd = 1 ; Realm Management Security Domain

     arm-platform-client-id-type =
         arm-platform-client-id-rmsd

     arm-platform-client-id = (
         arm-platform-client-id-label => arm-platform-client-id-type
     )

  4.6.4.  CCA Platform Manufacturing Config

     The CCA platform manufacturing config claim represents a record of
     production phases and testing conducted during the manufacturing
     process for this instance.

     The values encoding in this claim are implementation defined.



  Frost, et al.           Expires 3 September 2026               [Page 21]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     The CCA platform manufacturing config claim is OPTIONAL in a CCA
     platform token

     arm-platform-manufacturing-config-label = 2403

     arm-platform-manufacturing-config-type = bytes

     arm-platform-manufacturing-config = (
         arm-platform-manufacturing-config-label =>
             arm-platform-manufacturing-config-type
     )

  4.6.5.  CCA Platform Extension

     The CCA platform extension claim identifies components which have
     been added to the CCA platform at runtime and supplies verification
     hashes for evidence obtained from those components.

     An example of such a component is a coherent memory (CMEM) device

     The CCA platform extension claim is OPTIONAL in a CCA platform token

  arm-platform-extension-label = 2404

  ; protocols that support VCA (Version-Capabilities-Algorithm message concatenation)
  $protocols-support-vca /= "spdm-1.2.0"
  $protocols-support-vca /= "spdm-1.2.1"
  $protocols-support-vca /= "spdm-1.2.2"
  $protocols-support-vca /= "spdm-1.2.3"
  $protocols-support-vca /= "spdm-1.3.0"
  $protocols-support-vca /= "spdm-1.3.1"
  $protocols-support-vca /= "spdm-1.3.2"
  $protocols-support-vca /= "spdm-1.4.0"

  ; device types requiring a form of encryption
  $type-with-encryption /= "cxl-type-3"

  encryption-type = (
      host-side-encryption: 0
      target-side-encryption: 1
      no-encryption: 2
  )

  arm-platform-extension-device-common = (
      ? 1 => text,            ; hash algorithm identifier
      2 => arm-platform-hash-type,     ; device measurements exchange digest
      3 => arm-platform-hash-type,     ; certificate chain digest
      4 => bool,              ; indicates whether this PDEV uses IDE



  Frost, et al.           Expires 3 September 2026               [Page 22]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  )

  arm-platform-extension-device = {
      arm-platform-extension-device-common
      (
          ( ; ---- VCA digest required ----
              5 => $protocols-support-vca,    ; protocol, e.g. "spdm-1.2.3"
              6 => arm-platform-hash-type,             ; SPDM VCA digest
          )
       // ( ; ---- no VCA needed ----
              5 => text                       ; protocol
          )
      )
      (
          (
              7 => $type-with-encryption,     ; device type, e.g. "cxl-type-3
              8 => &encryption-type,          ; indicates encryption type
          )
       // ( ; ---- no encryption type needed ----
              7 => text
          )
      )
  }

  arm-platform-extension = (
      arm-platform-extension-label => [ + arm-platform-extension-device ]
  )

  4.6.6.  CCA Platform Peer Signers

     In the event that the CCA platform consists of multiple peer RoTs
     which are unable to establish a single attestation signing entity at
     boot time, it is necessary for an attestation report produced by one
     of those RoTs to identify its peers where execution may be
     subsequently scheduled.  The CCA platform peer signers claim is used
     to provide this information to a verifier.

     The CCA platform peer signers claim is OPTIONAL in a CCA platform
     token

     The data type for this claim is Implementation Defined as different
     underlying RoT technologies or provisioning schemes are likely.









  Frost, et al.           Expires 3 September 2026               [Page 23]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     arm-platform-peer-signers-label = 2406

     arm-platform-peer-signers-type = bytes

     arm-platform-peer-signers = (
         arm-platform-peer-signers-label => arm-platform-peer-signers-type
     )

  4.6.7.  CCA Platform TBB ROTPK

     Where an implementation of the CCA platform follows the Trusted Board
     Boot specification [TBB], the platform will include several
     provisioned public key identifiers which are used to establish a
     chain of trust.  The CCA platform TBB ROTPK claim is used to provide
     this information to a verifier.

     The CCA platform tbb rotpk claim is OPTIONAL in a CCA platform token

     arm-platform-tbb-rotpk-label = 2405

     arm-platform-tbb-rotpk-type = [ + arm-platform-tbb-rotpk-item ]

     arm-platform-tbb-rotpk-item = {
         1 => tstr,             ; e.g. "CM" or "DM"
         2 => int,              ; active ROTPK array
         3 => int,              ; index in the active array
         4 => arm-platform-hash-type    ; hash object
     }

     arm-platform-tbb-rotpk = (
         arm-platform-tbb-rotpk-label => arm-platform-tbb-rotpk-type
     )

  4.7.  Verification Claims

     The following claims are part of the CCA Platform token (and
     therefore still Evidence) but aim to help receivers, including
     relying parties, with the processing of the received attestation
     Evidence.

  4.7.1.  Verification Service Indicator

     The Verification Service Indicator claim is a hint used by a relying
     party to locate a verification service for the token.  The value is a
     text string that can be used to locate the service (typically, a URL
     specifying the address of the verification service API).  A Relying
     Party may choose to ignore this claim in favor of other information.




  Frost, et al.           Expires 3 September 2026               [Page 24]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     ; PSA verification service
     arm-platform-verification-service-label = 2400
     arm-platform-verification-service-type = text

     arm-platform-verification-service = (
         arm-platform-verification-service-label =>
             arm-platform-verification-service-type
     )

     It is assumed that the relying party is pre-configured with a list of
     trusted verification services and that the contents of this hint can
     be used to look up the correct one.  Under no circumstances must the
     relying party be tricked into contacting an unknown and untrusted
     verification service since the returned Attestation Result cannot be
     relied on.

     Note: This hint requires the relying party to parse the content of
     the CCA Platform token.  Since the relying party may not be in
     possession of a trust anchor to verify the digital signature, it uses
     the hint in the same way as it would treat any other information
     provided by an external party, which includes attacker-provided data.

     The CCA platform verification service indicator claim is OPTIONAL in
     a CCA platform token.

  4.8.  CCA Realm state token Claims

     The CCA Realm state token contains claims that represent the Target
     Environment that is the Realm that requested the attestation report.

  4.8.1.  Realm Nonce

     The Nonce claim is used to carry a challenge provided by the caller
     to demonstrate freshness of the generated token.

     The EAT [EAT] nonce (claim key 10) is used.  Since the EAT nonce
     claim offers flexiblity for different attestation technologies, this
     specification applies the following constraints to the nonce-type:

     *  The length MUST be 64 bytes.

     *  Only a single nonce value is conveyed.  The array notation MUST
        NOT be used for encoding the nonce value.

     This claim MUST be present in a CCA Realm state attestation token.






  Frost, et al.           Expires 3 September 2026               [Page 25]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     cca-realm-challenge-label = 10
     cca-realm-challenge-type = bytes .size 64

     cca-realm-challenge = (
         cca-realm-challenge-label => cca-realm-challenge-type
     )

  4.8.2.  Realm Profile Definition

     The Realm profile claim identifies the EAT profile to which the Realm
     token conforms.  This allows a receiver to assign the intended
     semantics to the rest of the claims found in the token.

     The EAT eat_profile (claim key 265) is used.

     The format of the CCA platform profile claim is defined as a text
     string of value "tag:arm.com,2024:realm#2.0.0".

     This claim is OPTIONAL in a CCA Realm attestation token.  If the
     Realm profile is not included in a CCA Realm token then the profile
     value used in the CCA Platform token should refer to a profile that
     describes both Platform and Realm claims.

     cca-realm-profile-label = 265 ; EAT profile

     cca-realm-profile-type = "tag:arm.com,2024:realm#2.0.0"

     cca-realm-profile = (
         cca-realm-profile-label => cca-realm-profile-type
     )

  4.8.3.  Realm Personalisation Value

     The Realm Personalization Value (RPV) claim contains the RPV which
     was provided at Realm creation.

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-personalization-value-label = 44235
     cca-realm-personalization-value-type = bytes .size 64

     cca-realm-personalization-value = (
         cca-realm-personalization-value-label =>
             cca-realm-personalization-value-type
     )






  Frost, et al.           Expires 3 September 2026               [Page 26]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.8.4.  Realm Initial Measurement

     The Realm Initial Measurement claim contains the compound extension
     of measurements taken of Realm memory and state before the Realm is
     activated.

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-initial-measurement-label = 44238

     cca-realm-initial-measurement = (
         cca-realm-initial-measurement-label => cca-realm-measurement-type
     )

  4.8.5.  Realm Extensible Measurements

     The Realm Extensible Measurements claim contains measurements
     provided by Realm guest software and extended to the set of Realm
     Extensible Measurements maintained by the RMM.

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-extensible-measurements-label = 44239

     cca-realm-extensible-measurements = (
         cca-realm-extensible-measurements-label =>
             [ 4*4 cca-realm-measurement-type ]
     )

  4.8.6.  Realm Hash Algorithm Measurements

     The Realm hash algorithm ID claim identifies the algorithm used to
     calculate all hash values which are present in the Realm token.

     The string value of the claim SHOULD be encoded according to "Hash
     Name String" in the "Named Information Hash Algorithm Registry"
     [IANA.named-information].

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-hash-algo-id-label = 44236

     cca-realm-hash-algo-id = (
         cca-realm-hash-algo-id-label => text
     )






  Frost, et al.           Expires 3 September 2026               [Page 27]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.8.7.  Realm Public Key

     The Realm public key claim identifies the attestation key which is
     used to sign the Realm token

     The value of the Realm public key claim is a byte string
     representation of a COSE_Key.

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-public-key-label = 44237

     ; See RFC8152 for definition of COSE_Key
     cca-realm-public-key-type = bstr .cbor COSE_Key

     cca-realm-public-key = (
         cca-realm-public-key-label => cca-realm-public-key-type
     )

  4.8.8.  Realm Public Key Hash Algorithm ID

     The Realm public key hash algorithm identifier claim identifies the
     algorithm used to hash the value of the Realm Public Key claim
     Section 4.8.7 such that it can be presented as a Challenge for the
     bound CCA Platform token Section 4.10.

     This claim MUST be present in a CCA Realm state attestation token.

     cca-realm-public-key-hash-algo-id-label = 44240

     cca-realm-public-key-hash-algo-id = (
         cca-realm-public-key-hash-algo-id-label => text
     )

  4.9.  Backwards Compatibility Considerations

     This profile conforms to the claims in the Beta release of the 2.0
     release of the Realm Management Monitor specification.  [RMM].

     TODO Backwards compat incl notes 1.1./2.0 with note that 1.0 is
     theoretical










  Frost, et al.           Expires 3 September 2026               [Page 28]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  4.10.  Token Binding

     The reference implementation uses a 'Delegated Model' for token
     signing.  In this model, the completion of signing operations for the
     CCA token is delegated from the CCA Platform RoT to the RMM.  When
     the RMM initialises, it obtains a 'Realm Attestation Token' (RAK)
     signing key pair from the CCA Platform RoT.  The public part of that
     key pair is hashed and used as a challenge to obtain a CCA Platform
     token (signed by the CCA Platform RoT).  When guest code in a Realm
     requests a CCA Attestation token, the RMM prepares a Realm state
     token, signed by the RAK private key, then wraps both tokens in a CMW
     Collection.  The two tokens are bound together by the Nonce claim in
     the CCA Platform token having the same value as a hash of the Realm
     Public key claim in the Realm state token (using the hash algorithm
     identified by the Realm Public Key Hash Algorithm ID claim).

     A verifier MUST check this binding is valid when verifying a CCA
     Attestation token.

     An implementation may choose instead a 'Direct Model'.  In this
     model, when guest code in a Realm requests a CCA Attestation token,
     the RMM prepares a Realm state claim set, but does not wrap it in a
     CMW.  Instead, the claim set is hashed and this value is used as a
     Challenge to obtain a CCA Platform token, signed by the CCA Platform
     RoT.  The CCA Platform and Realm state claim set are presented within
     a CMW Collection as in the Delegated model.  The two parts of the
     collection are bound together by the Nonce claim in the CCA Platform
     token having the same value as the hash of the Realm state claim set.
     If the Direct Model is used, the CCA Platform profile claim
     Section 4.5.1 MUST have a different value from the reference profile.
     The map value within the CCA Attestation token CMW Collection for the
     Realm state claim set MUST also have a different value to that used
     for a Realm state CMW token.  In such a profile, the Realm Public Key
     Section 4.8.7 and Realm Public Key Hash Algorithm ID Section 4.8.8
     claims will not be used.

  4.11.  Reference Profile

  4.11.1.  Token Encoding and Signing

     The CCA attestation token is encoded in CBOR [STD94] format.  The
     CBOR representation of a CCA attestation token MUST be "valid"
     according to the definition in Section 1.2 of [STD94].  Besides, only
     definite-length string, arrays, and maps are allowed.

     The CCA reference profile is designed to not emit CBOR preferred
     serializations (Section 4.1 of [STD94]).  This profile assumes that
     the Verifier MUST be a variation-tolerant CBOR decoder.



  Frost, et al.           Expires 3 September 2026               [Page 29]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     Cryptographic protection is obtained by wrapping the CCA Platform and
     Realm state claims-set each in a COSE Web Token (CWT) [RFC8392].  The
     signature structure MUST be a tagged (18) COSE_Sign1 [STD96].

     Acknowledging the variety of markets, regulations and use cases in
     which the CCA attestation token can be used, the baseline profile
     does not impose any strong requirement on the cryptographic
     algorithms that need to be supported by Attesters and Verifiers.  The
     flexibility provided by the COSE format should be sufficient to deal
     with the level of cryptographic agility needed to adapt to specific
     use cases.  It is RECOMMENDED that commonly adopted algorithms are
     used, such as those discussed in [COSE-ALGS].  It is expected that
     receivers will accept a wider range of algorithms, while Attesters
     would produce CCA tokens using only one such algorithm.

     The CCA Platform token is always directly signed by the CCA Platform
     RoT.  Therefore, the CCA Platform claims-set is never carried in a
     Detached EAT bundle (Section 5 of [EAT]).

  4.11.2.  Freshness Model

     The CCA token supports the freshness models for attestation Evidence
     based on nonces and epoch handles (Section 10.2 and Section 10.3 of
     [RFC9334]) using the nonce claim to convey the nonce or epoch handle
     supplied by the Verifier.  No further assumption on the specific
     remote attestation protocol is made.

     Note that use of epoch handles is constrained by the type
     restrictions imposed by the eat_nonce syntax.  For use in CCA tokens,
     it must be possible to encode the epoch handle as an opaque binary
     string between 8 and 64 octets.

  4.11.3.  Synopsis

     Table 2 presents a concise view of the requirements described in the
     preceding sections.















  Frost, et al.           Expires 3 September 2026               [Page 30]


  Internet-Draft       CCA Reference Attestation Token          March 2026


      +==================+=============================================+
      | Issue            | Profile Definition                          |
      +==================+=============================================+
      | CBOR/JSON        | CBOR MUST be used                           |
      +------------------+---------------------------------------------+
      | CBOR Encoding    | Definite length maps and arrays MUST be     |
      |                  | used                                        |
      +------------------+---------------------------------------------+
      | CBOR Encoding    | Definite length strings MUST be used        |
      +------------------+---------------------------------------------+
      | CBOR             | Variant serialization MAY be used           |
      | Serialization    |                                             |
      +------------------+---------------------------------------------+
      | COSE Protection  | COSE_Sign1 MUST be used                     |
      +------------------+---------------------------------------------+
      | Algorithms       | [COSE-ALGS] SHOULD be used                  |
      +------------------+---------------------------------------------+
      | Detached EAT     | Detached EAT bundles MUST NOT be sent       |
      | Bundle Usage     |                                             |
      +------------------+---------------------------------------------+
      | Verification Key | Any identification method listed in         |
      | Identification   | Appendix F.1 of [EAT]                       |
      +------------------+---------------------------------------------+
      | Endorsements     | See Section 7.2                             |
      +------------------+---------------------------------------------+
      | Freshness        | nonce or epoch ID based                     |
      +------------------+---------------------------------------------+
      | Claims           | Those defined in Section 4.  As per general |
      |                  | EAT rules, the receiver MUST NOT error out  |
      |                  | on claims it does not understand.           |
      +------------------+---------------------------------------------+

                          Table 2: Baseline Profile

  5.  Collated CDDL

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     cca-token = #6.907(cca-token-cmw)
     eat-cwt-coap-cf = 263
     cca-token-cmw = {
       0xACCA => [
             eat-cwt-coap-cf,
             bytes .cbor COSE_Sign1<arm-platform-claims>,
     ],
       0xACD1 => [
             eat-cwt-coap-cf,
             bytes .cbor COSE_Sign1<cca-realm-claims>,



  Frost, et al.           Expires 3 September 2026               [Page 31]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     ],
     }
     COSE_Sign1<C> = #6.18([
           Headers,
           payload: bytes .cbor C,
           signature: bytes,
     ])
     cca-realm-claims = cca-realm-claim-map
     cca-realm-claim-map = {
       cca-realm-challenge,
       ? cca-realm-profile,
       cca-realm-personalization-value,
       cca-realm-initial-measurement,
       cca-realm-extensible-measurements,
       cca-realm-hash-algo-id,
       cca-realm-public-key,
       cca-realm-public-key-hash-algo-id,
       cca-realm-mec-policy,
     }
     cca-realm-challenge-label = 10
     cca-realm-challenge-type = bytes .size 64
     cca-realm-challenge = (cca-realm-challenge-label => cca-realm-\
                                                           challenge-type)
     cca-realm-extensible-measurements-label = 44239
     cca-realm-extensible-measurements = (cca-realm-extensible-\
                    measurements-label => [4*4cca-realm-measurement-type])
     cca-realm-hash-algo-id-label = 44236
     cca-realm-hash-algo-id = (cca-realm-hash-algo-id-label => text)
     cca-realm-initial-measurement-label = 44238
     cca-realm-initial-measurement = (cca-realm-initial-measurement-\
                                      label => cca-realm-measurement-type)
     cca-realm-measurement-type = bytes .size 32 / bytes .size 48 / \
                                                            bytes .size 64
     cca-realm-personalization-value-label = 44235
     cca-realm-personalization-value-type = bytes .size 64
     cca-realm-personalization-value = (cca-realm-personalization-value-\
                            label => cca-realm-personalization-value-type)
     cca-realm-profile-label = 265
     cca-realm-profile-type = "tag:arm.com,2024:realm#2.0.0"
     cca-realm-profile = (cca-realm-profile-label => cca-realm-profile-\
                                                                     type)
     cca-realm-public-key-hash-algo-id-label = 44240
     cca-realm-public-key-hash-algo-id = (cca-realm-public-key-hash-algo-\
                                                         id-label => text)
     cca-realm-public-key-label = 44237
     cca-realm-public-key-type = bstr .cbor COSE_Key
     cca-realm-public-key = (cca-realm-public-key-label => cca-realm-\
                                                          public-key-type)



  Frost, et al.           Expires 3 September 2026               [Page 32]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     cca-realm-mec-policy-label = 44243
     cca-realm-mec-policy = (cca-realm-mec-policy-label => "shared" / "\
                                                                 private")
     label = int / tstr
     values = any
     COSE_Key = {
       1 => tstr / int,
       ? 2 => bstr,
       ? 3 => tstr / int,
       ? 4 => [+ tstr / int],
       ? 5 => bstr,
       * label => values,
     }
     arm-platform-claims = arm-platform-claim-map
     arm-platform-claim-map = {
       arm-platform-profile,
       arm-platform-challenge,
       arm-platform-implementation-id,
       arm-platform-instance-id,
       arm-platform-config,
       arm-platform-lifecycle,
       arm-platform-sw-components,
       ? arm-platform-verification-service,
       arm-platform-hash-algo-id,
       arm-platform-client-id,
       ? arm-platform-manufacturing-config,
       ? arm-platform-extension,
       ? arm-platform-peer-signers,
       ? arm-platform-tbb-rotpk,
     }
     arm-platform-challenge-label = 10
     arm-platform-challenge = (arm-platform-challenge-label => arm-\
                                                       platform-hash-type)
     arm-platform-config-label = 2401
     arm-platform-config-type = bytes
     arm-platform-config = (arm-platform-config-label => arm-platform-\
                                                              config-type)
     arm-platform-hash-algo-id-label = 2402
     arm-platform-hash-algo-id = (arm-platform-hash-algo-id-label => text)
     arm-platform-hash-type = bytes .size 32 / bytes .size 48 / bytes .\
                                                                   size 64
     arm-platform-implementation-id-label = 2396
     arm-platform-implementation-id-type = bytes .size 32
     arm-platform-implementation-id = (arm-platform-implementation-id-\
                             label => arm-platform-implementation-id-type)
     arm-platform-instance-id-label = 256
     arm-platform-instance-id-type = eat-ueid-rand-type
     arm-platform-instance-id = (arm-platform-instance-id-label => arm-\



  Frost, et al.           Expires 3 September 2026               [Page 33]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                                                platform-instance-id-type)
     arm-platform-profile-label = 265
     arm-platform-profile-type = "tag:arm.com,2024:cca_platform#2.0.0"
     arm-platform-profile = (arm-platform-profile-label => arm-platform-\
                                                             profile-type)
     arm-platform-lifecycle-label = 2395
     arm-platform-lifecycle-unknown-type = 0x0000 .. 0x00ff
     arm-platform-lifecycle-assembly-and-test-type = 0x1000 .. 0x10ff
     arm-platform-lifecycle-platform-rot-provisioning-type = 0x2000 .. \
                                                                    0x20ff
     arm-platform-lifecycle-secured-type = 0x3000 .. 0x30ff
     arm-platform-lifecycle-non-platform-rot-debug-type = 0x4000 .. 0x40ff
     arm-platform-lifecycle-recoverable-platform-rot-debug-type = 0x5000 \
                                                                 .. 0x50ff
     arm-platform-lifecycle-decommissioned-type = 0x6000 .. 0x60ff
     arm-platform-lifecycle-type = arm-platform-lifecycle-unknown-type / \
     arm-platform-lifecycle-assembly-and-test-type / arm-platform-\
     lifecycle-platform-rot-provisioning-type / arm-platform-lifecycle-\
     secured-type / arm-platform-lifecycle-non-platform-rot-debug-type / \
     arm-platform-lifecycle-recoverable-platform-rot-debug-type / arm-\
                                    platform-lifecycle-decommissioned-type
     arm-platform-lifecycle = (arm-platform-lifecycle-label => arm-\
                                                  platform-lifecycle-type)
     arm-platform-sw-components-label = 2399
     arm-platform-sw-component = {
       ? 1 => text,
       2 => arm-platform-hash-type,
       ? 4 => text,
       5 => arm-platform-hash-type,
       ? 6 => text,
     }
     arm-platform-sw-components = (arm-platform-sw-components-label => [\
                                             + arm-platform-sw-component])
     arm-platform-verification-service-label = 2400
     arm-platform-verification-service-type = text
     arm-platform-verification-service = (arm-platform-verification-\
                  service-label => arm-platform-verification-service-type)
     arm-platform-client-id-label = 2394
     arm-platform-client-id-rmsd = 1
     arm-platform-client-id-type = arm-platform-client-id-rmsd
     arm-platform-client-id = (arm-platform-client-id-label => arm-\
                                                  platform-client-id-type)
     arm-platform-manufacturing-config-label = 2403
     arm-platform-manufacturing-config-type = bytes
     arm-platform-manufacturing-config = (arm-platform-manufacturing-\
                   config-label => arm-platform-manufacturing-config-type)
     arm-platform-extension-label = 2404
     $protocols-support-vca /= "spdm-1.2.0" / "spdm-1.2.1" / "spdm-1.2.2\



  Frost, et al.           Expires 3 September 2026               [Page 34]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     " / "spdm-1.2.3" / "spdm-1.3.0" / "spdm-1.3.1" / "spdm-1.3.2" / "\
                                                               spdm-1.4.0"
     $type-with-encryption /= "cxl-type-3"
     encryption-type = (
       host-side-encryption: 0,
       target-side-encryption: 1,
       no-encryption: 2,
       )
     arm-platform-extension-device-common = (
       ? 1 => text,
       2 => arm-platform-hash-type,
       3 => arm-platform-hash-type,
       4 => bool,
       )
     arm-platform-extension-device = {
       arm-platform-extension-device-common,
       ((
                         5 => $protocols-support-vca,
                         6 => arm-platform-hash-type,
                   ) // 5 => text),
       ((
                         7 => $type-with-encryption,
                         8 => &encryption-type,
                   ) // 7 => text),
     }
     arm-platform-extension = (arm-platform-extension-label => [+ arm-\
                                               platform-extension-device])
     arm-platform-peer-signers-label = 2406
     arm-platform-peer-signers-type = bytes
     arm-platform-peer-signers = (arm-platform-peer-signers-label => arm-\
                                               platform-peer-signers-type)
     arm-platform-tbb-rotpk-label = 2405
     arm-platform-tbb-rotpk-type = [+ arm-platform-tbb-rotpk-item]
     arm-platform-tbb-rotpk-item = {
       1 => tstr,
       2 => int,
       3 => int,
       4 => arm-platform-hash-type,
     }
     arm-platform-tbb-rotpk = (arm-platform-tbb-rotpk-label => arm-\
                                                  platform-tbb-rotpk-type)
     eat-ueid-rand-type = bytes .join eat-ueid-rand-fmt
     eat-ueid-rand-fmt = [
       ueid-rand-typ,
       bytes .size 32,
     ]
     ueid-rand-typ = h'01'
     Headers = (



  Frost, et al.           Expires 3 September 2026               [Page 35]


  Internet-Draft       CCA Reference Attestation Token          March 2026


       protected: empty_or_serialized_map,
       unprotected: header_map,
       )
     empty_or_serialized_map = bstr .cbor header_map / bstr .size 0
     header_map = {
       Generic_Headers,
       * label => values,
     }
     Generic_Headers = (
       ? 1 => int / tstr,
       ? 2 => [+ label],
       ? 3 => tstr / int,
       ? 4 => bstr,
       ? (5 => bstr // 6 => bstr),
       )

  6.  Signing key implementation alternatives

     In the CCA Platform reference design, PAKs (Section 3.4, Paragraph 2)
     are raw public keys.

     Some implementations may choose to use a PAK that is a certified
     public key.  If this option is taken, the value of the CCA Platform
     Profile Definition claim Section 4.5.1 MUST be altered from the
     reference implementation value.

     Where the implementation uses a CPAK that is endorsed via an X.509
     certificate chain, the endorsement artefacts can be included in the
     COSE_Sign1 envelope of the CCA platform token using parameters from
     CBOR Object Signing and Encryption (COSE) Header Parameters for
     Carrying and Referencing X.509 Certificates [COSE-X509].  It is
     recommended that this is done as follows:

     *  The CPAK certificate is identified by including an x5t thumbprint
        parameter in the COSE_Sign1 protected header.

     *  The CPAK certificate itself is then packaged within an x5chain
        parameter in the COSE_Sign1 unprotected header.

     *  This x5chain parameter can also include other certificates that
        endorse the CPAK certificate.

     Alternatively, the other certificates in the chain that endorses the
     CPAK certificate can be packaged in an additional entry within the
     RATS Conceptual Messages Wrapper [CMW] token






  Frost, et al.           Expires 3 September 2026               [Page 36]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  7.  CCA Attestation Token Verification

     To verify the token for the reference profile, the initial need is to
     check correct encoding for the token.  Primary trust is established
     by checking the signing of the CCA Platform token CWT.  The key used
     for verification is supplied to the Verifier by an authorized
     Endorser along with the corresponding Attester's Implementation ID
     and Instance ID.  For the verifier, this ID information claim is used
     to assist locating the key used to verify the signature covering the
     CCA Platform CWT token.  The verifier can also be supplied with the
     information that the key instance has been revoked and is no longer
     valid.

     If an implementation has chosen to endorsed the CPAK via an X.509
     certificate chain, the ID claims may not be required to verify the
     CPAK.  Instead this is achieved by forming a full X.509 chain to the
     trusted Certificate Authority root and validating that chain.

     Additional validation checks on the token are:

     *  Checking that the binding between the CCA Platform token and the
        Realm state token is valid Section 4.10}. This has the side effect
        of establishing the trustworthiness of the RAK public key.

     *  Validating that the Realm state token is correctly signed by the
        RAK.

     *  Checking that the value of the lll claim is cca-platform-
        lifecycle-secured state.  Note that some other values of this
        claim (cca-platform-lifecycle-non-psa-rot-debug and cca-platform-
        lifecycle-recoverable-psa-rot states) may indicate that the
        attester is only temporarily unsuitable and the verifier may
        choose the to indicate this as a contraindication rather than a
        full verification failure.  See discussion of the CCA platform
        lifecycle in [RMM].

     The Verifier will typically operate a policy where values of some of
     the claims in this profile can be compared to reference values,
     registered with the Verifier for a given deployment, in order to
     confirm that the device is endorsed by the manufacturer supply chain.
     The policy may require that the relevant claims must have a match to
     a registered reference value.  All claims may be worthy of additional
     appraisal.  It is likely that most deployments would include a policy
     with appraisal for the following claims:

     *  Implementation ID - the value of the Implementation ID can be used
        to identify the verification requirements of the deployment.




  Frost, et al.           Expires 3 September 2026               [Page 37]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Software Component, Measurement Value - this value can uniquely
        identify a firmware release from the supply chain.  In some cases,
        a Verifier may maintain a record for a series of firmware
        releases, being patches to an original baseline release.  A
        verification policy may then allow this value to match any point
        on that release sequence or expect some minimum level of maturity
        related to the sequence.

     *  Software Component, Signer ID - where present in a deployment,
        this could allow a Verifier to operate a more general policy than
        that for Measurement Value as above, by allowing a token to
        contain any firmware entries signed by a known Signer ID, without
        checking for a uniquely registered version.

  7.1.  AR4SI Trustworthiness Claims Mappings

     [RATS-AR4SI] defines an information model that Verifiers can employ
     to produce Attestation Results.  AR4SI provides a set of standardized
     appraisal categories and tiers that greatly simplifies the task of
     writing Relying Party policies in multi-attester environments.

     The contents of Table 3 are intended as guidance for implementing a
     PSA Verifier that computes its results using AR4SI.  The table
     describes which PSA Evidence claims (if any) are related to which
     AR4SI trustworthiness claim, and therefore what the Verifier must
     consider when deciding if and how to appraise a certain feature
     associated with the PSA Attester.

     TODO: Ar4SI TODO: LFA FAL






















  Frost, et al.           Expires 3 September 2026               [Page 38]


  Internet-Draft       CCA Reference Attestation Token          March 2026


      +===================+=============================================+
      | Trustworthiness   | Related PSA claims                          |
      | Vector claims     |                                             |
      +===================+=============================================+
      | configuration     | Software Components (Section 4.6.1)         |
      +-------------------+---------------------------------------------+
      | executables       | ditto                                       |
      +-------------------+---------------------------------------------+
      | file-system       | N/A                                         |
      +-------------------+---------------------------------------------+
      | hardware          | Implementation ID (Section 4.4.2) and CCA   |
      |                   | Platform config (TODO)                      |
      +-------------------+---------------------------------------------+
      | instance-identity | Instance ID (Section 4.4.1).  The Security  |
      |                   | Lifecycle (Section 4.5.2) can also impact   |
      |                   | the derived identity.                       |
      +-------------------+---------------------------------------------+
      | runtime-opaque    | Indirectly derived from executables,        |
      |                   | hardware, and instance-identity.  The       |
      |                   | Security Lifecycle (Section 4.5.2) can also |
      |                   | be relevant: for example, any debug state   |
      |                   | will expose otherwise protected memory.     |
      +-------------------+---------------------------------------------+
      | sourced-data      | N/A                                         |
      +-------------------+---------------------------------------------+
      | storage-opaque    | Indirectly derived from executables,        |
      |                   | hardware, and instance-identity.            |
      +-------------------+---------------------------------------------+

                         Table 3: AR4SI Claims mappings

     This document does not prescribe what value must be chosen based on
     each possible situation: when assigning specific Trustworthiness
     Claim values, an implementation is expected to follow the algorithm
     described in Section 2.3.3 of [RATS-AR4SI].

  7.2.  Endorsements, Reference Values and Verification Key Material

     The [CCA-ENDORSEMENTS] defines a protocol based on the [RATS-CoRIM]
     data model that can be used to convey CCA Endorsements, Reference
     Values and Verification Key Material to the Verifier.

  8.  Implementation Status


     // RFC Editor: please remove this section before publication.





  Frost, et al.           Expires 3 September 2026               [Page 39]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     Implementations of this specification are provided by the Trusted
     Firmware-RMM project [TF-RMM] and the Veraison project [Veraison].
     These implementations are released as open-source software.

  9.  Security and Privacy Considerations

     This specification re-uses the EAT specification and therefore the
     CWT specification.  Hence, the security and privacy considerations of
     those specifications apply here as well.

     Attestation tokens contain information that may be unique to a device
     and therefore they may allow singling out an individual device for
     tracking purposes.  Deployments that have privacy requirements must
     take appropriate measures to ensure that the token is only used to
     provision anonymous/pseudonym keys.

  10.  IANA Considerations

     TODO: Issue #34 (https://github.com/SimonFrost-Arm/draft-ffm-rats-
     cca-token/issues/34) find document centric change controller TODO:
     additional top level claims

  10.1.  CBOR Web Token Claims Registration

     IANA is requested to make permanent the following claims that have
     been assigned via early allocation in the "CBOR Web Token (CWT)
     Claims" registry [IANA-CWT].

  10.1.1.  Arm CCA Attestation CMW

     *  Claim Name: arm-cca-attestation-cmw

     *  Claim Description: Arm CCA Attestation CMW

     *  JWT Claim Name: N/A

     *  Claim Key: 907

     *  Claim Value Type(s): unsigned integer

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.1 of RFCthis

  10.1.2.  Security Lifecycle Claim

     *  Claim Name: arm-platform-security-lifecycle




  Frost, et al.           Expires 3 September 2026               [Page 40]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: Arm Platform Security Lifecycle

     *  JWT Claim Name: N/A

     *  Claim Key: 2395

     *  Claim Value Type(s): unsigned integer

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.5.2 of RFCthis

  10.1.3.  Implementation ID Claim

     *  Claim Name: arm-platform-implementation-id

     *  Claim Description: Arm Platform Implementation ID

     *  JWT Claim Name: N/A

     *  Claim Key: 2396

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.4.2 of RFCthis

  10.1.4.  Software Components Claim

     *  Claim Name: arm-platform-software-components

     *  Claim Description: Arm Platform Software Components

     *  JWT Claim Name: N/A

     *  Claim Key: 2399

     *  Claim Value Type(s): array

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.1 of RFCthis

  10.1.5.  Verification Service Indicator Claim

     *  Claim Name: arm-platform-verification-service-indicator




  Frost, et al.           Expires 3 September 2026               [Page 41]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: Arm Platform Verification Service Indicator

     *  JWT Claim Name: N/A

     *  Claim Key: 2400

     *  Claim Value Type(s): text string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.7.1 of RFCthis

  10.1.6.  Platform Config Claim

     *  Claim Name: arm-platform-config

     *  Claim Description: Arm Platform Configuration

     *  JWT Claim Name: N/A

     *  Claim Key: 2401

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.5.3 of RFCthis

  10.1.7.  Platform Hash Algorithm ID Claim

     *  Claim Name: arm-platform-hash-algm-id

     *  Claim Description: Arm Platform Hash Algorithm ID

     *  JWT Claim Name: N/A

     *  Claim Key: 2402

     *  Claim Value Type(s): text string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.2 of RFCthis

  10.1.8.  Platform Manufacturing Config

     *  Claim Name: arm-platform-manufacturing-config




  Frost, et al.           Expires 3 September 2026               [Page 42]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: Arm Platform Manufacturing Config

     *  JWT Claim Name: N/A

     *  Claim Key: 2403

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.4 of RFCthis

  10.1.9.  Platform Extension

     *  Claim Name: arm-platform-extension

     *  Claim Description: Arm Platform Extension

     *  JWT Claim Name: N/A

     *  Claim Key: 2404

     *  Claim Value Type(s): array

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.5 of RFCthis

  10.1.10.  Platform TBB RoTPK

     *  Claim Name: arm-platform-tbb-rotpk

     *  Claim Description: Arm Platform TBB RoTPK

     *  JWT Claim Name: N/A

     *  Claim Key: 2405

     *  Claim Value Type(s): array

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.7 of RFCthis

  10.1.11.  Platform Peer Signers

     *  Claim Name: arm-platform-peer-signers




  Frost, et al.           Expires 3 September 2026               [Page 43]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: Arm Platform Peer Signers

     *  JWT Claim Name: N/A

     *  Claim Key: 2406

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.6.7 of RFCthis

  10.1.12.  CCA Token Platform Token Label

     *  Claim Name: cca-platform-token-label

     *  Claim Description: CCA Token Platform Token Label

     *  JWT Claim Name: N/A

     *  Claim Key: 44234

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.1 of RFCthis

  10.1.13.  Realm Personalization Value Claim

     *  Claim Name: cca-realm-personalization-value

     *  Claim Description: CCA Realm Personalisation Value

     *  JWT Claim Name: N/A

     *  Claim Key: 44235

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.3 of RFCthis

  10.1.14.  Realm Hash Algorithm ID Claim

     *  Claim Name: cca-realm-hash-algm-id




  Frost, et al.           Expires 3 September 2026               [Page 44]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: CCA Realm Hash Algorithm ID

     *  JWT Claim Name: N/A

     *  Claim Key: 44236

     *  Claim Value Type(s): text string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.6 of RFCthis

  10.1.15.  Realm Public Key Claim

     *  Claim Name: cca-realm-public-key

     *  Claim Description: CCA Realm Public Key

     *  JWT Claim Name: N/A

     *  Claim Key: 44237

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.7 of RFCthis

  10.1.16.  Realm Initial Measurement Claim

     *  Claim Name: cca-realm-initial-measurement

     *  Claim Description: CCA Realm Initial Measurement

     *  JWT Claim Name: N/A

     *  Claim Key: 44238

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.4 of RFCthis

  10.1.17.  Realm Extensible Measurements Claim

     *  Claim Name: cca-realm-extensible-measurements




  Frost, et al.           Expires 3 September 2026               [Page 45]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     *  Claim Description: CCA Realm Extensible Measurements

     *  JWT Claim Name: N/A

     *  Claim Key: 44239

     *  Claim Value Type(s): array

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.4 of RFCthis

  10.1.18.  Realm Public Key Hash Algorithm ID Claim

     *  Claim Name: cca-realm-public-key-hash-algm-id

     *  Claim Description: Realm Public Key Hash Algorithm ID Claim

     *  JWT Claim Name: N/A

     *  Claim Key: 44240

     *  Claim Value Type(s): text string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.8.8 of RFCthis

  10.1.19.  CCA Token Delegated Realm Token Label

     *  Claim Name: cca-platform-delegated-realm-label

     *  Claim Description: CCA Token Platform Token Label

     *  JWT Claim Name: N/A

     *  Claim Key: 44241

     *  Claim Value Type(s): byte string

     *  Change Controller: TBD

     *  Specification Document(s): Section 4.1 of RFCthis








  Frost, et al.           Expires 3 September 2026               [Page 46]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  10.2.  Media Types

     No new media type registration is requested.  To indicate that the
     transmitted content is a CCA attestation token, applications can use
     the application/eat+cwt media type defined in [EAT-MEDIATYPES] with
     the eat_profile parameter set to tag:arm.com,2023:cca_platform#1.0.0.

  10.3.  CoAP Content-Formats Registration

     IANA is requested to register a CoAP Content-Format ID in the "CoAP
     Content-Formats" registry [IANA-CoAP-Content-Formats]:

     *  A registration for the application/eat+cwt media type with the
        eat_profile parameter equal to
        "tag:arm.com,2023:cca_platform#1.0.0"

     The Content-Formats should be allocated from the Expert review range
     (0-255).

  10.3.1.  Registry Contents

     *  Media Type: `application/eat+cwt;
        eat_profile="tag:arm.com,2023:cca_platform#1.0.0"

     *  Encoding: -

     *  Id: To-be-assigned by IANA

     *  Reference: RFCthis

     *  Media Type: `application/eat+cwt;
        eat_profile="tag:arm.com,2023:realm#1.0.0"

     *  Encoding: -

     *  Id: To-be-assigned by IANA

     *  Reference: RFCthis

  11.  References

  11.1.  Normative References

     [CCA-ARCH] Arm, "Learn the architecture - Introducing Arm
                Confidential Compute Architecture", 19 March 2025,
                <https://developer.arm.com/documentation/den0125/400>.





  Frost, et al.           Expires 3 September 2026               [Page 47]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     [CMW]      Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
                D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
                in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
                11 December 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-msg-wrap-23>.

     [COSE-ALGS]
                Schaad, J., "CBOR Object Signing and Encryption (COSE):
                Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
                August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

     [EAT]      Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
                Wallace, "The Entity Attestation Token (EAT)", Work in
                Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-eat-31>.

     [EAT-MEDIATYPES]
                Lundblade, L., Birkholz, H., and T. Fossati, "EAT Media
                Types", Work in Progress, Internet-Draft, draft-ietf-rats-
                eat-media-type-12, 3 November 2024,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                eat-media-type-12>.

     [IANA-CWT] IANA, "CBOR Web Token (CWT) Claims", 2022,
                <https://www.iana.org/assignments/cwt/cwt.xhtml#claims-
                registry>.

     [IANA.named-information]
                IANA, "Named Information",
                <https://www.iana.org/assignments/named-information>.

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

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.







  Frost, et al.           Expires 3 September 2026               [Page 48]


  Internet-Draft       CCA Reference Attestation Token          March 2026


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

     [RME]      Arm, "Learn the architecture - Realm Management
                Extension", 26 September 2025,
                <https://developer.arm.com/documentation/den0126/0102>.

     [RME-SYSARCH]
                Arm, "Arm Realm Management Extension (RME) System
                Architecture", 15 December 2025,
                <https://developer.arm.com/documentation/den0129/ca>.

     [RMM]      Arm, "Realm Management Monitor specification 2.0", 3
                February 2026,
                <https://developer.arm.com/documentation/den0137/2-0bet0>.

     [STD94]    Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/rfc/rfc8949>.

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

     [TBB]      Arm, "Trusted Board Boot", 30 December 2024,
                <https://trustedfirmware-
                a.readthedocs.io/en/stable/design/trusted-board-
                boot.html>.

  11.2.  Informative References

     [CCA-ENDORSEMENTS]
                Deshpande, Y. and T. Fossati, "A CoRIM Profile for Arm's
                Confidential Computing Architecture (CCA) Endorsements",
                Work in Progress, Internet-Draft, draft-ydb-rats-cca-
                endorsements-03, 5 January 2026,
                <https://datatracker.ietf.org/doc/html/draft-ydb-rats-cca-
                endorsements-03>.








  Frost, et al.           Expires 3 September 2026               [Page 49]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     [COSE-X509]
                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>.

     [I-D.kdyxy-rats-tdx-eat-profile]
                Kostal, G., Dittakavi, S., Yeluri, R., Xia, H., and J. Yu,
                "EAT profile for Intel(r) Trust Domain Extensions (TDX)
                attestation result", Work in Progress, Internet-Draft,
                draft-kdyxy-rats-tdx-eat-profile-02, 13 December 2024,
                <https://datatracker.ietf.org/doc/html/draft-kdyxy-rats-
                tdx-eat-profile-02>.

     [I-D.mandyam-rats-qwestoken]
                Mandyam, G., Sekhar, V., and S. Mohammed, "The Qualcomm
                Wireless Edge Services (QWES) Attestation Token", Work in
                Progress, Internet-Draft, draft-mandyam-rats-qwestoken-00,
                1 November 2019, <https://datatracker.ietf.org/doc/html/
                draft-mandyam-rats-qwestoken-00>.

     [IANA-CoAP-Content-Formats]
                IANA, "CoAP Content-Formats", 2022,
                <https://www.iana.org/assignments/core-parameters>.

     [RATS-AR4SI]
                Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
                Scarlata, "Attestation Results for Secure Interactions",
                Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
                09, 15 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
                ar4si-09>.

     [RATS-CoRIM]
                Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
                W. Pan, "Concise Reference Integrity Manifest", Work in
                Progress, Internet-Draft, draft-ietf-rats-corim-09, 20
                October 2025, <https://datatracker.ietf.org/doc/html/
                draft-ietf-rats-corim-09>.

     [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
                W. Pan, "Remote ATtestation procedureS (RATS)
                Architecture", RFC 9334, DOI 10.17487/RFC9334, January
                2023, <https://www.rfc-editor.org/rfc/rfc9334>.

     [TF-RMM]   Trusted Firmware Project, "Trusted Firmware-RMM", 2022,
                <https://www.trustedfirmware.org/projects/tf-rmm>.




  Frost, et al.           Expires 3 September 2026               [Page 50]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     [Veraison] The Veraison Project, "Veraison ccatoken package", 2022,
                <https://github.com/veraison/ccatoken>.

  Appendix A.  Examples

     The following examples show CCA attestation tokens for an
     hypothetical system comprising a single number of software component.
     The attesting device is in a lifecycle state (Section 4.5.2) of
     SECURED.

  A.1.  Delegated Mode

     The following sample claim set and token are representative of a CCA
     Token using "delegated mode" described in Section 3.2.

     In this model, the eat_nonce claim in the Platform token contains a
     hash of the RAK public key claim in the Realm token.

  A.1.1.  Platform Claims Set

     The CCA Platform claims set is

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
       265:"tag:arm.com,2024:cca_platform#2.0.0",
       10:h'\
        0D22E08A98469058486318283489BDB36F09DBEFEB1864DF433FA6E54EA2D711',
       2396:h'\
        7F454C4602010100000000000000000003003E00010000005058000000000000',
       256:h'\
      0107060504030201000F0E0D0C0B0A090817161514131211101F1E1D1C1B1A1918',
       2401:h'CFCFCFCF',
       2395:12291,
       2402:"sha-256",
       2400:"https://veraison.example/.well-known/veraison/verification",
       2394: 1,
       2399:[
         {
           1:"RSE_BL1_2",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        9A271F2A916B0B6EE6CECB2426F0B3206EF074578BE55D9BC94F6F3FE3AB86AA',
           6:"sha-256"
         },
         {
           1:"RSE_BL2",



  Frost, et al.           Expires 3 September 2026               [Page 51]


  Internet-Draft       CCA Reference Attestation Token          March 2026


           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        53C234E5E8472B6AC51C1AE1CAB3FE06FAD053BEB8EBFD8977B010655BFDD3C3',
           6:"sha-256"
         },
         {
           1:"RSE_S",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        1121CFCCD5913F0A63FEC40A6FFD44EA64F9DC135C66634BA001D10BCF4302A2',
           6:"sha-256"
         },
         {
           1:"AP_BL1",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        1571B5EC78BD68512BF7830BB6A2A44B2047C7DF57BCE79EB8A1C0E5BEA0A501',
           6:"sha-256"
         },
         {
           1:"AP_BL2",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        10159BAF262B43A92D95DB59DAE1F72C645127301661E0A3CE4E38B295A97C58',
           6:"sha-256"
         },
         {
           1:"SCP_BL1",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        10122E856B3FCD49F063636317476149CB730A1AA1CFAAD818552B72F56D6F68',
           6:"sha-256"
         },
         {
           1:"SCP_BL2",
           5:h'\
        F14B4987904BCB5814E4459A057ED4D20F58A633152288A761214DCD28780B56',
           2:h'\
        AA67A169B0BBA217AA0AA88A65346920C84C42447C36BA5F7EA65F422C1FE5D8',
           6:"sha-256"
         },
         {
           1:"AP_BL31",



  Frost, et al.           Expires 3 September 2026               [Page 52]


  Internet-Draft       CCA Reference Attestation Token          March 2026


           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        2E6D31A5983A91251BFAE5AEFA1C0A19D8BA3CF601D0E8A706B4CFA9661A6B8A',
           6:"sha-256"
         },
         {
           1:"RMM",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        A1FB50E6C86FAE1679EF3351296FD6713411A08CF8DD1790A4FD05FAE8688164',
           6:"sha-256"
         },
         {
           1:"HW_CONFIG",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        1A252402972F6057FA53CC172B52B9FFCA698E18311FACD0F3B06ECAAEF79E17',
           6:"sha-256"
         },
         {
           1:"FW_CONFIG",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        9A92ADBC0CEE38EF658C71CE1B1BF8C65668F166BFB213644C895CCB1AD07A25',
           6:"sha-256"
         },
         {
           1:"TB_FW_CONFIG",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        238903180CC104EC2C5D8B3F20C5BC61B389EC0A967DF8CC208CDC7CD454174F',
           6:"sha-256"
         },
         {
           1:"SOC_FW_CONFIG",
           5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
           2:h'\
        E6C21E8D260FE71882DEBDB339D2402A2CA7648529BC2303F48649BCE0380017',
           6:"sha-256"
         }
       ]
     }



  Frost, et al.           Expires 3 September 2026               [Page 53]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  A.1.2.  Realm Claims Set

     The CCA Realm claims set is

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
         265: "tag:arm.com,2024:realm#2.0.0", / eat_profile /
         10: h'\
     6E86D6D97CC713BC6DD43DBCE491A6B40311C027A8BF85A39DA63E9CE44C132A8A11\
     9D296FAE6A6999E9BF3E4471B0CE01245D889424C31E89793B3B1D6B1504', / \
                                                               eat_nonce /
         44236: "sha-256", / Realm hash algorithm /
         44240: "sha-256", / RAK hash algorithm /
         44235: h'\
     54686520717569636B2062726F776E20666F78206A756D7073206F76657220313320\
     6C617A7920646F67732E54686520717569636B2062726F776E20666F7820', / PV /
         44237: << { / RAK /
             1: 2, / kty=EC2 /
             -1: 2, / crv=P-384 /
             -2: h'\
     76F988091BE585ED41801AECFAB858548C63057E16B0E676120BBD0D2F9C29E056C5\
                           D41A0130EB9C21517899DC23146B', / x-coordinate /
             -3: h'\
     28E1B062BD3EA4B315FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF\
                            3D918F2F94FFC4228E50919544AE' / y-coordinate /
         } >>,
         44238: h'\
     311314AB73620350CF758834AE5C65D9E8C2DC7FEBE6E7D9654BBE864E300D49', \
                                                                   / RIM /
         44239: [
             h'\
     24D5B0A296CC05CBD8068C5067C5BD473B770DDA6AE082FE3BA30ABE3F9A6AB1', \
                                                                / REM[0] /
             h'\
     788FC090BFC6B8ED903152BA8414E73DAF5B8C7BB1E79AD502AB0699B659ED16', \
                                                                / REM[1] /
             h'\
     DAC46A58415DC3A00D7A741852008E9CAE64F52D03B9F76D76F4B3644FEFC416', \
                                                                / REM[2] /
             h'\
     32C6AFC627E55585C03155359F331A0E225F6840DB947DD96EFAB81BE2671939'  \
                                                                / REM[3] /
         ],
         44243: "private"  / MEC policy /
     }





  Frost, et al.           Expires 3 September 2026               [Page 54]


  Internet-Draft       CCA Reference Attestation Token          March 2026


  A.1.3.  Platform Attestation Key

     The COSE Key representation of the Platform Attestation Key (PAK)
     used for creating the COSE Sign1 signature over the CCA Platform
     token is

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
       / kty /  1: 2,  / EC2 /
       / crv / -1: 2,  / P-384 /
       / x-coordinate / -2: h'\
     212867C52E2B9508B0A420A90560F394D2DFAA21BDD7514FF1A901AFE7E1F78BB11D\
                                            4E66F8A8A38AFA76AF6A31C4DE8C',
       / y-coordinate / -3: h'\
     84CE2DAFC9964258B53FAD718774F45620D111B176E8318E1187DB0235A318D37BA5\
                                            97FEE80E0E4C762A12BCB3EA6ED4',
       / private key /  -4: h'\
     8AC090C995869F61AC1358F02B021A26AB6EB386203AC735D7CE9855538B91F74C44\
                                             B0D580243EFB799A293DCBAA0899'
     }

  A.1.4.  Realm Attestation Key

     The COSE Key representation of the Realm Attestation Key (RAK) used
     for creating the COSE Sign1 signature over the CCA Realm token is

     =============== NOTE: '\' line wrapping per RFC 8792 ================

     {
       / kty /  1: 2,  / EC2 /
       / crv / -1: 2,  / P-384 /
       / x-coordinate / -2: h'\
     76F988091BE585ED41801AECFAB858548C63057E16B0E676120BBD0D2F9C29E056C5\
                                            D41A0130EB9C21517899DC23146B',
       / y-coordinate / -3: h'\
     28E1B062BD3EA4B315FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF\
                                            3D918F2F94FFC4228E50919544AE',
       / private key /  -4: h'\
     2011C7F03CEE4325176E524F033C0CE1E21A76E6C1A4F0B839AA1DF61E0E8A5C8A05\
                                             740F9B69EFA7EB1A4185BD117F68'
     }

  A.1.5.  Signed and Bound Assembly

     The resulting CMW collection is





  Frost, et al.           Expires 3 September 2026               [Page 55]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     =============== NOTE: '\' line wrapping per RFC 8792 ================

     907({
       44234: [
         263,
         << 18([
           h'A1013822',
           {},
           << {
             265:"tag:arm.com,2024:cca_platform#2.0.0",
             10:h'\
        0D22E08A98469058486318283489BDB36F09DBEFEB1864DF433FA6E54EA2D711',
             2396:h'\
        7F454C4602010100000000000000000003003E00010000005058000000000000',
             256:h'\
      0107060504030201000F0E0D0C0B0A090817161514131211101F1E1D1C1B1A1918',
             2401:h'CFCFCFCF',
             2395:12291,
             2402:"sha-256",
             2394: 1,
             2400:"https://veraison.example/.well-known/veraison/\
                                                            verification",
             2399:[
               {
                 1:"RSE_BL1_2",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        9A271F2A916B0B6EE6CECB2426F0B3206EF074578BE55D9BC94F6F3FE3AB86AA',
                 6:"sha-256"
               },
               {
                 1:"RSE_BL2",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        53C234E5E8472B6AC51C1AE1CAB3FE06FAD053BEB8EBFD8977B010655BFDD3C3',
                 6:"sha-256"
               },
               {
                 1:"RSE_S",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        1121CFCCD5913F0A63FEC40A6FFD44EA64F9DC135C66634BA001D10BCF4302A2',
                 6:"sha-256"
               },
               {



  Frost, et al.           Expires 3 September 2026               [Page 56]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                 1:"AP_BL1",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        1571B5EC78BD68512BF7830BB6A2A44B2047C7DF57BCE79EB8A1C0E5BEA0A501',
                 6:"sha-256"
               },
               {
                 1:"AP_BL2",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        10159BAF262B43A92D95DB59DAE1F72C645127301661E0A3CE4E38B295A97C58',
                 6:"sha-256"
               },
               {
                 1:"SCP_BL1",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        10122E856B3FCD49F063636317476149CB730A1AA1CFAAD818552B72F56D6F68',
                 6:"sha-256"
               },
               {
                 1:"SCP_BL2",
                 5:h'\
        F14B4987904BCB5814E4459A057ED4D20F58A633152288A761214DCD28780B56',
                 2:h'\
        AA67A169B0BBA217AA0AA88A65346920C84C42447C36BA5F7EA65F422C1FE5D8',
                 6:"sha-256"
               },
               {
                 1:"AP_BL31",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        2E6D31A5983A91251BFAE5AEFA1C0A19D8BA3CF601D0E8A706B4CFA9661A6B8A',
                 6:"sha-256"
               },
               {
                 1:"RMM",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        A1FB50E6C86FAE1679EF3351296FD6713411A08CF8DD1790A4FD05FAE8688164',
                 6:"sha-256"
               },
               {



  Frost, et al.           Expires 3 September 2026               [Page 57]


  Internet-Draft       CCA Reference Attestation Token          March 2026


                 1:"HW_CONFIG",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        1A252402972F6057FA53CC172B52B9FFCA698E18311FACD0F3B06ECAAEF79E17',
                 6:"sha-256"
               },
               {
                 1:"FW_CONFIG",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        9A92ADBC0CEE38EF658C71CE1B1BF8C65668F166BFB213644C895CCB1AD07A25',
                 6:"sha-256"
               },
               {
                 1:"TB_FW_CONFIG",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        238903180CC104EC2C5D8B3F20C5BC61B389EC0A967DF8CC208CDC7CD454174F',
                 6:"sha-256"
               },
               {
                 1:"SOC_FW_CONFIG",
                 5:h'\
        5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3',
                 2:h'\
        E6C21E8D260FE71882DEBDB339D2402A2CA7648529BC2303F48649BCE0380017',
                 6:"sha-256"
               }
             ]
           } >>,
           h'\
     31D04D52CCDE952C1E32CBA181885A40B8CC38E0528C1E89589807642AA5E3F2BC37\
     F95374506BFF4D2E4BE7063C4D72419270C722E8D4D93EE8B6C9FACE3B43C9761A49\
                 941AB6F38FFDFF496AD463B4CBFA11D83E23E31F7F62329DE30C1CC8'
         ]) >>
       ],

       44241: [
         263,
         << 18([
           h'A1013822',
           {},
           << {
             265:"tag:arm.com,2024:realm#2.0.0",
             10:h'\



  Frost, et al.           Expires 3 September 2026               [Page 58]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     6E86D6D97CC713BC6DD43DBCE491A6B40311C027A8BF85A39DA63E9CE44C132A8A11\
            9D296FAE6A6999E9BF3E4471B0CE01245D889424C31E89793B3B1D6B1504',
             44236:"sha-256",
             44240:"sha-256",
             44235:h'\
     54686520717569636B2062726F776E20666F78206A756D7073206F76657220313320\
            6C617A7920646F67732E54686520717569636B2062726F776E20666F7820',
             44237:h'\
     A40102200221583076F988091BE585ED41801AECFAB858548C63057E16B0E676120B\
     BD0D2F9C29E056C5D41A0130EB9C21517899DC23146B22583028E1B062BD3EA4B315\
     FD219F1CBB528CB6E74CA49BE16773734F61A1CA61031B2BBF3D918F2F94FFC4228E\
                                                              50919544AE',
             44238:h'\
        311314AB73620350CF758834AE5C65D9E8C2DC7FEBE6E7D9654BBE864E300D49',
             44239:[
               h'\
        24D5B0A296CC05CBD8068C5067C5BD473B770DDA6AE082FE3BA30ABE3F9A6AB1',
               h'\
        788FC090BFC6B8ED903152BA8414E73DAF5B8C7BB1E79AD502AB0699B659ED16',
               h'\
        DAC46A58415DC3A00D7A741852008E9CAE64F52D03B9F76D76F4B3644FEFC416',
               h'\
         32C6AFC627E55585C03155359F331A0E225F6840DB947DD96EFAB81BE2671939'
             ],
             44243: "private"  / MEC policy /
           } >>,
           h'\
     580B1DEA32D30AC6884C86B39CBE0FCB03BD00DF5103F9BAB01386A46A3BA8143E27\
     ED6D4EB0D0A2724ABDF9640C09462FACE6DF186909DFA6EB131E3A7918276077ACDA\
                 B8A8BDECA6B0EAAFAB66E1439C1371F4FB1D6AAC047481B5DC75DD46'
         ]) >>
       ]
     })

     which has the following base16 encoding:

     d9038ba219acca821901075905f2d28444a1013822a0590585aa19010978
     237461673a61726d2e636f6d2c323032343a6363615f706c6174666f726d
     23322e302e300a58200d22e08a98469058486318283489bdb36f09dbefeb
     1864df433fa6e54ea2d71119095c58207f454c4602010100000000000000
     000003003e00010000005058000000000000190100582101070605040302
     01000f0e0d0c0b0a090817161514131211101f1e1d1c1b1a191819096144
     cfcfcfcf19095b193003190962677368612d32353619095a01190960783a
     68747470733a2f2f7665726169736f6e2e6578616d706c652f2e77656c6c
     2d6b6e6f776e2f7665726169736f6e2f766572696669636174696f6e1909
     5f8da401695253455f424c315f320558205378796307535df3ec8d8b15a2
     e2dc5641419c3d3060cfe32238c0fa973f7aa30258209a271f2a916b0b6e
     e6cecb2426f0b3206ef074578be55d9bc94f6f3fe3ab86aa06677368612d



  Frost, et al.           Expires 3 September 2026               [Page 59]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     323536a401675253455f424c320558205378796307535df3ec8d8b15a2e2
     dc5641419c3d3060cfe32238c0fa973f7aa302582053c234e5e8472b6ac5
     1c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c306677368612d32
     3536a401655253455f530558205378796307535df3ec8d8b15a2e2dc5641
     419c3d3060cfe32238c0fa973f7aa30258201121cfccd5913f0a63fec40a
     6ffd44ea64f9dc135c66634ba001d10bcf4302a206677368612d323536a4
     016641505f424c310558205378796307535df3ec8d8b15a2e2dc5641419c
     3d3060cfe32238c0fa973f7aa30258201571b5ec78bd68512bf7830bb6a2
     a44b2047c7df57bce79eb8a1c0e5bea0a50106677368612d323536a40166
     41505f424c320558205378796307535df3ec8d8b15a2e2dc5641419c3d30
     60cfe32238c0fa973f7aa302582010159baf262b43a92d95db59dae1f72c
     645127301661e0a3ce4e38b295a97c5806677368612d323536a401675343
     505f424c310558205378796307535df3ec8d8b15a2e2dc5641419c3d3060
     cfe32238c0fa973f7aa302582010122e856b3fcd49f063636317476149cb
     730a1aa1cfaad818552b72f56d6f6806677368612d323536a40167534350
     5f424c32055820f14b4987904bcb5814e4459a057ed4d20f58a633152288
     a761214dcd28780b56025820aa67a169b0bba217aa0aa88a65346920c84c
     42447c36ba5f7ea65f422c1fe5d806677368612d323536a4016741505f42
     4c33310558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe3
     2238c0fa973f7aa30258202e6d31a5983a91251bfae5aefa1c0a19d8ba3c
     f601d0e8a706b4cfa9661a6b8a06677368612d323536a40163524d4d0558
     205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238c0fa97
     3f7aa3025820a1fb50e6c86fae1679ef3351296fd6713411a08cf8dd1790
     a4fd05fae868816406677368612d323536a4016948575f434f4e46494705
     58205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238c0fa
     973f7aa30258201a252402972f6057fa53cc172b52b9ffca698e18311fac
     d0f3b06ecaaef79e1706677368612d323536a4016946575f434f4e464947
     0558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cfe32238c0
     fa973f7aa30258209a92adbc0cee38ef658c71ce1b1bf8c65668f166bfb2
     13644c895ccb1ad07a2506677368612d323536a4016c54425f46575f434f
     4e4649470558205378796307535df3ec8d8b15a2e2dc5641419c3d3060cf
     e32238c0fa973f7aa3025820238903180cc104ec2c5d8b3f20c5bc61b389
     ec0a967df8cc208cdc7cd454174f06677368612d323536a4016d534f435f
     46575f434f4e4649470558205378796307535df3ec8d8b15a2e2dc564141
     9c3d3060cfe32238c0fa973f7aa3025820e6c21e8d260fe71882debdb339
     d2402a2ca7648529bc2303f48649bce038001706677368612d3235365860
     31d04d52ccde952c1e32cba181885a40b8cc38e0528c1e89589807642aa5
     e3f2bc37f95374506bff4d2e4be7063c4d72419270c722e8d4d93ee8b6c9
     face3b43c9761a49941ab6f38ffdff496ad463b4cbfa11d83e23e31f7f62
     329de30c1cc819acd182190107590259d28444a1013822a05901eca91901
     09781c7461673a61726d2e636f6d2c323032343a7265616c6d23322e302e
     300a58406e86d6d97cc713bc6dd43dbce491a6b40311c027a8bf85a39da6
     3e9ce44c132a8a119d296fae6a6999e9bf3e4471b0ce01245d889424c31e
     89793b3b1d6b150419accc677368612d32353619acd0677368612d323536
     19accb584054686520717569636b2062726f776e20666f78206a756d7073
     206f766572203133206c617a7920646f67732e54686520717569636b2062
     726f776e20666f782019accd586ba40102200221583076f988091be585ed
     41801aecfab858548c63057e16b0e676120bbd0d2f9c29e056c5d41a0130



  Frost, et al.           Expires 3 September 2026               [Page 60]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     eb9c21517899dc23146b22583028e1b062bd3ea4b315fd219f1cbb528cb6
     e74ca49be16773734f61a1ca61031b2bbf3d918f2f94ffc4228e50919544
     ae19acce5820311314ab73620350cf758834ae5c65d9e8c2dc7febe6e7d9
     654bbe864e300d4919accf84582024d5b0a296cc05cbd8068c5067c5bd47
     3b770dda6ae082fe3ba30abe3f9a6ab15820788fc090bfc6b8ed903152ba
     8414e73daf5b8c7bb1e79ad502ab0699b659ed165820dac46a58415dc3a0
     0d7a741852008e9cae64f52d03b9f76d76f4b3644fefc416582032c6afc6
     27e55585c03155359f331a0e225f6840db947dd96efab81be267193919ac
     d367707269766174655860580b1dea32d30ac6884c86b39cbe0fcb03bd00
     df5103f9bab01386a46a3ba8143e27ed6d4eb0d0a2724abdf9640c09462f
     ace6df186909dfa6eb131e3a7918276077acdab8a8bdeca6b0eaafab66e1
     439c1371f4fb1d6aac047481b5dc75dd46

  A.2.  Direct Mode

     The following sample claim sets and the resulting CCA Token are
     representative of a CCA Token using "direct mode" (Section 3.1).

     In "direct mode" the eat_nonce claim in the Platform token contains a
     hash of the Realm claims set, which includes verifier-provided
     challenge data.

     TODO

  Acknowledgments

     TODO

  Contributors

     Yogesh Deshpande
     Arm Limited
     Email: Yogesh.Deshpande@arm.com


     Sergei Trofimov
     Arm Limited
     Email: Sergei.Trofimov@arm.com


  Authors' Addresses

     Simon Frost
     Arm Limited
     Email: Simon.Frost@arm.com






  Frost, et al.           Expires 3 September 2026               [Page 61]


  Internet-Draft       CCA Reference Attestation Token          March 2026


     Thomas Fossati
     Linaro
     Email: thomas.fossati@linaro.org


     Giri Mandyam
     Mediatek Inc
     Email: giridhar.mandyam@gmail.com











































  Frost, et al.           Expires 3 September 2026               [Page 62]


name: w3c-authentform
rev: 00
title: User Agent Authentication Forms
time: 19990203
states: []
categories: ["Human-agent interaction"]
tags: []
fetched_at: 2026-03-08T13:09:36.711264+00:00
source: w3c
abstract:
  This note proposes a new HTML capability to aid in the development of authenticated web user interfaces.


name: w3c-cuap
rev: 00
title: Common User Agent Problems
time: 20030128
states: []
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:36.724552+00:00
source: w3c
abstract:
  This document explains some common mistakes in user agents due to incorrect or incomplete implementation of specifications, and suggests remedies. It also suggests some "good behavior" where specifications themselves do not specify any particular behavior (e.g., in the face of error conditions). This document is not a complete set of guidelines for good user agent behavior. Note: This document does not incriminate specific user agents. W3C does not generally track bugs or errors in implementations. That information is generally tracked by the vendors themselves or third parties.


name: w3c-UAAG10
rev: 00
title: User Agent Accessibility Guidelines 1.0
time: 20021217
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.727976+00:00
source: w3c
abstract:
  This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological). User agents include HTML browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of HTML browsers and media players, this document will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities.


name: w3c-UAAG10-TECHS
rev: 00
title: Techniques for User Agent Accessibility Guidelines 1.0
time: 20021217
states: []
categories: ["Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.731260+00:00
source: w3c
abstract:
  This document provides techniques for satisfying the checkpoints defined in "User Agent Accessibility Guidelines 1.0" [UAAG10] . These techniques address key aspects of the accessibility of user interfaces, content rendering, application programming interfaces ( APIs ), and languages such as the Hypertext Markup Language ( HTML ), Cascading Style Sheets ( CSS ) and the Synchronized Multimedia Integration Language ( SMIL ). The techniques listed in this document are not required for conformance to the Guidelines. These techniques are not necessarily the only way of satisfying the checkpoint, nor are they a definitive set of requirements for satisfying a checkpoint.


name: w3c-UAAG20-requirements
rev: 00
title: User Agent Accessibility Guidelines 2.0 Requirements
time: 20071031
states: []
categories: ["Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-08T13:09:36.734568+00:00
source: w3c
abstract:
  This First Public Working Draft outlines the requirements that the User Agent Accessibility Guidelines Working Group (UAWG) has set for development of User Agent Accessibility Guidelines 2.0 (UAAG 2.0). These requirements are based on feedback from the use of UAAG 1.0 and will be used to determine if the UAWG has met its goals as UAAG 2.0 advances through the W3C Recommendation Track Process.


name: w3c-UAAG20
rev: 00
title: User Agent Accessibility Guidelines (UAAG) 2.0
time: 20151215
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.738210+00:00
source: w3c
abstract:
  This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of browsers and media players, this document will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities. The "User Agent Accessibility Guidelines 2.0" ( UAAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative ( WAI ).


name: w3c-wai-aria-implementation
rev: 00
title: WAI-ARIA 1.0 User Agent Implementation Guide
time: 20140320
states: []
categories: ["Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.751165+00:00
source: w3c
abstract:
  Describes how user agents should support keyboard navigation, respond to roles, states, and properties provided in Web content via WAI-ARIA, and expose this to accessibility APIs.


name: w3c-UAAG20-Reference
rev: 00
time: 20151215
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.757658+00:00
source: w3c
title:
  UAAG 2.0 Reference: Explanations, Examples, and Resources for User Agent Accessibility Guidelines 2.0

abstract:
  This document provides explanation of the intent of UAAG 2.0 success criteria, examples of implementation of the UAAG 2.0 guidelines, best practice recommendations and additional resources for the guidelines.


name: w3c-agent-attributes
rev: 00
title: Client-Specific Web Services by Using User Agent Attributes
time: 19971230
states: []
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.760685+00:00
source: w3c
abstract:
  This document describes a simple framework for realizing client-specific web services. The proposed method uses the client properties such as screen size and colors, available input methods, web page capacity, secondary storage size, product category, CPU type, and etc., which we call "User Agent Attributes". We also describe an implementation of this framework by using the User-Agent header in HTTP. This enables the client-specific services for various Internet information appliances like Internet-TVs, PDAs, and smart phones.


