| |
|
| |
| | iCalendar Format Extensions for JSCalendar |
| |
|
This document defines a set of new elements for iCalendar and extends the use of existing ones. Their main purpose is to extend the semantics of iCalendar with elements defined in JSCalendar, but the new definitions also aim to be useful within just the iCalendar format. This document updates RFC 5545 ("iCalendar") and its extension documents RFC 7986 and RFC 9073. |
| | DNS Protocol Modifications for Delegation Extensions |
| |
|
The Domain Name System (DNS) protocol permits Delegation Signer (DS) records at delegation points. This document specifies modifications to the DNS protocol to permit a range of Resource Record types at delegation points. These modifications are designed to maintain compatibility with existing DNS resolution mechanisms and provide a secure method for processing these records at delegation points. This document updates RFCs 1034, 4035, 6672, 6840, 6895 and 9824. |
| | Template-Driven HTTP CONNECT Proxying for TCP |
| |
|
TCP proxying using HTTP CONNECT has long been part of the core HTTP specification. However, this proxying functionality has several important deficiencies in modern HTTP environments. This specification defines an alternative HTTP proxy service configuration for TCP connections. This configuration is described by a URI Template, similar to the CONNECT-UDP and CONNECT-IP protocols. |
| | A Base YANG Data Model for Network Inventory |
| |
|
This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. |
| | Support of Versioning in YANG Notifications Subscription |
| |
|
This document defines a YANG module which extends the YANG-Push Subscription mechanism to enforce that particular revisions or semantic versions are used when configuring or establishing a Subscription. It also extends the YANG-Push Subscription state change Notifications to include additional context about the YANG schema associated with the Subscription. |
| | NETCONF Extension to support Trace Context propagation |
| |
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), enabling distributed tracing scenarios. It is an adaptation of the HTTP-based W3C specification and defines three YANG modules. |
| | RESTCONF Extension to Support Trace Context Headers |
| |
|
This document defines an extension to the RESTCONF protocol to support Trace Context propagation as defined by the W3C. |
| | Adding an Uncacheable File Data Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients commonly perform client-side caching of file data in order to improve performance. On some systems, applications may influence client data caching behavior, but there is no standardized mechanism for a server or administrator to indicate that particular file data should not be cached by clients for reasons of performance or correctness. This document introduces a new file data caching attribute for NFSv4.2. Files marked with this attribute are intended to be accessed with client-side caching of file data suppressed, in order to support workloads that require predictable data visibility. This document extends NFSv4.2. |
| | Quick and Dirty Secure Autonomic Control Plane for GRASP |
| |
|
A secure substrate known as the Autonomic Control Plane (ACP) is required by the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents. This document describes QUADS, a QUick And Dirty Secure ACP using symmetric cryptography and preconfigured key material. It also describes a secure mechanism for providing the prefconfigured key material to enrolled ACP nodes via EST. |
| | Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions for a terminal connected to a network infrastructure, to request a service with specific connectivity and computing requirements, so traffic is steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | Service Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent service migration adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. Exemplary signaling control messages and operation extending the well-known Proxy Mobile IPv6 protocol are also defined. |
| | Terminal Mobility-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document defines new extensions and procedures for a terminal connected to a network infrastructure, to benefit from transparent mobility management adapting to specific connectivity and computing requirements, so traffic is always steered to an instance meeting both requirements. Both CATS-aware and -unaware terminals are considered. |
| | MoQ qlog event definitions |
| |
|
This document defines a qlog event schema containing concrete events for MoQ. |
| | AI/ML-Enabled Computing Aware Traffic Steering using IP address anchoring |
| |
|
The IETF CATS WG addresses the problem of how the network infrastructure can steer traffic between clients of a service and sites offering the service, considering both network metrics (such as bandwidth and latency), and compute metrics (such as processing, storage capabilities, and capacity). This document describes solutions to enable the network to select the best site to instantiate a processing service (using distributed sensing as an application example), augmenting CATS enabled solutions that consider both connectivity and computing, to also consider AI/ML and data capabilities and governance policies. |
| | Solutions for enabling agentic sensing with network optimization |
| |
|
Integrated Sensing and Communications (ISAC) represents a paradigm shift in wireless networks, where sensing and communication functions are jointly designed and optimized. By leveraging the same spectral and hardware resources, ISAC enables advanced capabilities such as environment perception, object tracking, and situational awareness, while maintaining efficient and reliable data transmission. There are sensing scenarios and use cases that involve a distributed sensing task, in which multiple sensors participate and contribute with (raw or pre-processed) sensing data, which is processed by a sensing service (e.g., fusing sensing measurements from the different sensors). This sensing service needs to be executed on some kind of sensing processing/computing function which receives raw (or preprocessed) data from multiple sources, potentially of different (heterogeneous) kinds (e.g., RF and non-RF sensing, or RF from different radio technologies). This processing might impose time synchronization constraints on the reception of the different parts of data, as well as potentially specific computing and/or AI/ML capabilities on the processing node. The joint selection of sensing entities, processing locations, and network configuration under time-varying conditions results in a large, coupled, and non-stationary decision space. These characteristics motivate the use of agentic AI to enable distributed, closed-loop configuration and reconfiguration of sensing and networking resources. This document presents initial considerations and potential solution directions for an architecture that enables the use of agentic AI for sensing (as an exemplary use case) supporting network optimization. |
| | Mathematical notation in RFCs |
| |
|
This document defines policy and allows new technology for the representation of mathematical content in RFCXML and relevant publication formats. After implementation of this policy, the chosen mathematical notation format should be used in RFCXML and the HTML publication format. |
| | A Layman's Guide to a Subset of ASN.1,BER,and DER |
| |
|
This note gives a layman's introduction to a subset of the Abstract Syntax Notation One (ASN.1), Basic Encoding Rules (BER), and Distinguished Encoding Rules (DER). The purpose of this note is to provide background material sufficient for understanding and implementing standards that make use of ASN.1. This memo is not an IETF standard, and has not been shown to have IETF community consensus. This memo offers tutorial information. |
| | The 'sustainability-data' Well-Known URI |
| |
|
This document defines the "sustainability-data" well-known URI, at which a web origin publishes a single JSON document declaring the energy consumption, carbon footprint, and related environmental metrics of a reporting subject, typically the origin itself. The declaration is described by formal schemas and located at a fixed path, so that it can be retrieved, validated, and ingested automatically. It carries an optional embedded signature, may reference the declarations of upstream providers from which its figures derive, links to a methodology, and may link to third-party attestations. The metrics are self-asserted claims of the publisher. This document registers the well-known URI and the media type application/sustainability-data+json. |
| | DNS-like Agent Discovery Architecture |
| |
|
This document defines a DNS-like three-tier agent-discovery architecture for the Internet of Agents (IoA). It introduces three core functional roles: Agent Root, Agent Registry, and Agent Resolver. |
| | Intra-handshake (aka Early) Attestation Considered Harmful (CVE-2026-33697 of CVSS 7.5 and several other CVEs of up to expected CVSS 10.0 upcoming) |
| |
| | draft-intra-handshake-fail-32.txt |
| | Date: |
17/09/2026 |
| | Authors: |
Muhammad Sardar, Viacheslav Dubeyko, Jean-Marie Jacquet, Songbo Bu, Chengxin Huang, Haowen Song, Kaya Ercihan, Kubilay Kucuk, Serhii Nikolaichuk, Eva Willems, Massimiliano Brighindi, Mikerah Quintyne-Collins, Iman Schrock |
| | Working Group: |
Individual Submissions (none) |
|
The draft aims to provide technical details of CVE-2026-33697 (https://www.cve.org/CVERecord?id=CVE-2026-33697), EUVD-2026-16488 (https://euvd.enisa.europa.eu/enisa/EUVD-2026-16488), and several GitHub Security Advisories (GHSAs) which provide substantial technical evidence of how *intra*-handshake (aka early) attestation fails in practice, even _without physical access_. Moreover, since continuous attestation is generally required [CSA-eBPF] [MITRE-Continuous-Attestation], *intra*-handshake attestation adds *unnecessary complexity*. The results are backed by the research [Intra-handshake.fail], [TLS-RA] and the artifacts [Intra-handshake.fail-repo] in state-of-the-art formal analysis tool, ProVerif, under Apache-2.0 license for reproducibility and review, and have been acknowledged by the relevant stakeholders. Currently, there are *two CVEs of CVSS 7.5, one GHSA of 9.0-10.0, two GHSAs of CVSS 9.1, one GHSA of CVSS 7.8, seven GHSAs of CVSS 7.4, and one GHSA of CVSS 6.3 published against the broader intra-handshake (aka early) attestation covering all layers of the ecosystem up to the application*. The research papers on these are currently either under submission or being prepared for submission. The artifacts of these papers will be shared with the community under Apache-2.0 license for reproducibility and review. In our analysis, the remaining implementations of early attestation -- Edgeless Systems Contrast and Meta's AI -- remain vulnerable. |
| | Succession Receipts: Portable Signed Evidence of Authority Succession Between Autonomous Agents |
| |
|
Autonomous agents are upgraded, replaced, suspended, and restored while holding real operational authority. A Succession Receipt is a portable, signed JSON document that proves one completed, policy- gated transfer of authority between two agents: which agent held the authority, which agent holds it now, under what legitimacy determination the transfer ran, and which obligations carried forward, with every claim grounded in signed evidence events embedded in the receipt itself. Receipts are verifiable offline by parties who do not operate the issuing system, using only the issuer's public key. This document specifies the receipt wire format, its canonicalization and signature scheme (JSON Canonicalization Scheme with Ed25519), the verification algorithm including bidirectional claim grounding, and an optional claim that binds a pre-execution authorization of the handoff to the succession evidence. Where decision receipts prove what an agent did, and delegation receipts prove what an agent may do, Succession Receipts prove that an agent legitimately became the holder of an authority. |
| | One-time Pad for Authorizing Device Identity |
| |
|
This document describes how devices joining an autonomic control plane as defined in RFC 8994 may use the BRSKI onboarding mechanism defined in RFC 8995, even if they cannot provide a manufacturer- installed X.509 IDevID certificate. Instead, such devices may generate a self-signed certificate embedding a unique token selected from a one-time pad. |
| | Fast Congestion Notification Packet (CNP) with Proxy |
| |
|
This document describes the necessity and feasibility to introduce a proxy network node between the congested network node and the traffic sender. The proxy network node is used to translate the congestion notification. The congested network node sends the congestion notification to the proxy network node in a format defined in this document, and then the proxy network node translates the received congestion notification to a format known by the traffic sender and resends the translated congestion notification to the traffic sender. |
| | PACT: Co-Signed Task Contracts,Delivery and Verdict Records,and Outcome Records for Autonomous Agents |
| |
|
Autonomous agents can already prove who they are, show whose authority they act under, find and call one another, and pay. What no existing specification lets them do is agree on a task in a form a third party can check, deliver against it, have the delivery judged by someone other than the performer, and carry away a record of the outcome that a stranger can verify. This document specifies PACT, a set of signed JSON records that closes that gap. PACT defines four things: a co-signed task contract whose digest covers its signature set; a Verdict record bound by digest to the Delivery it judges; a Facilitator-signed event trace and Outcome Record for every contract, recorded once, in one order, by a party other than the performer; and a Merkle commitment from a parent's Outcome Record to its subcontracts' Outcome Records. Settlement terms are carried by reference to a profile defined outside this document. This document specifies no escrow, custody or release of value, and takes no position on the legal effect of any record it defines. |
| | QoSformer: A Framework for Learning-Based QoS Prediction and Policy Evaluation |
| |
|
Network operators need to assess how changes to quality-of-service (QoS) policies may affect individual traffic flows and shared network resources. Measurements describe observed behavior, but policy evaluation also requires predictions under candidate configurations. This document describes a framework that combines heterogeneous network measurements and configuration data in a Multiple Flow Snapshot (MFS), learns representations through masked reconstruction, and uses a Transformer-based model called QoSformer to predict throughput, delay, and resource utilization. It describes offline model preparation, online candidate evaluation, and feedback after authorized policy changes. A 5G core network use case illustrates the mapping to analytics and policy-control functions. The framework is informational: it defines neither a new wire protocol nor extensions to existing 3GPP interfaces. |
| | Spend Receipts and Payment Rail Reconciliation for AI Agents |
| |
|
This document addresses auditable payments for AI agents and builds upon state-of-the-art HTTP 402, AP2 and credit card systems. We specify a cryptographically secured payment reconciliation protocol using a Trade Manifest (a signed offer before payment), a Policy Decision Point with default deny, a Spend Receipt (a COSE/CWT claim set issued after a gated payment), and rail-extract reconciliation. |
| | Cedulon Checkpoints: Epoch Witnesses and Transparency |
| |
|
This document specifies epoch checkpoints, the transparency witness and the anchoring of checkpoints as SCITT Signed Statements for the Cedulon audit layer. The spend receipt, rail-extract reconciliation and trust-root rules live in the companion Cedulon Core document. A verifier that pins a witness key can detect a withheld or rolled-back checkpoint; without that pin the suppression guarantee is conditional. |
| | Cedulon Threat Narratives |
| |
|
This document records the threat narratives and attack paths that sit behind the Cedulon core requirements. It does not define those requirements. T11 (checkpoint suppression) is recorded in the checkpoint companion, not here. |
| | Pulse: Real-Time Online Charging for AI Services |
| |
|
This document specifies Pulse, version 1.1 — the AI online charging protocol: the interface between an AI Gateway (the client) and the Charging Server (the server) by which AI service usage is authorised in real time, supervised under a granted budget, and settled. The spend guarantee is precisely stated: *settled spend never exceeds the reported meter or the plan's ceiling*, and serving exposure is bounded by the granted pool plus the completion of Calls already in flight when a stop lands. The protocol consists of two request/ response operations over HTTPS with JSON bodies: *Authorise* and *Report*. It follows the reserve-then-settle discipline of telecom online charging (cf. Diameter Credit-Control, RFC 4006) applied to AI workloads. |
| | Additions to C509 Structures |
| |
|
This document defines additions to CBOR Encoded X.509 Certificates (C509). This document defines a new C509SubjectPublicKeyInfo type, a CBOR representation of the X.509 SubjectDirectoryAttributes extension, and a mechanism that allows organizations assigned a Private Enterprise Number (PEN) to define organization-specific integer identifiers without registering each identifier in the C509 RDN attribute type, CR attribute type, extension ID, certificate policy, or extended key usage registries. This document also defines textual encoding labels for C509 objects using the textual encoding conventions specified in RFC 7468. |
| | Additional Private Use Ranges in the IANA Registries of the Lightweight Authenticated Key Exchange (LAKE) Protocol |
| |
|
This document adds Private Use ranges to IANA registries that pertain to the Lightweight Authenticated Key Exchange (LAKE) protocol. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Lightweight Authenticated Key Exchange Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/lake/. Source for this draft and an issue tracker can be found at https://gitlab.com/crimson84/draft-tiloca-lake-private-use-ranges. |
| | Agent Registry Protocol |
| |
|
Software agents increasingly act on behalf of people and organizations across administrative and security boundaries. Existing discovery mechanisms can identify an endpoint or advertise a capability, but they do not by themselves provide a common way to resolve who operates an agent, the bounded authority under which it acts, whether that authority is current, or what evidence supports a reliance decision. This document defines the Agent Registry Protocol (ARPA), an HTTP and JSON protocol for publishing and resolving information about software agents, their operational deployments, typed relationships, bounded delegated authority, lifecycle status, and associated evidence. ARPA separates identification, authentication, authorization, assurance, and lifecycle state. Registration, successful authentication, capability advertisement, or proof verification does not by itself establish authority to perform an action. The protocol is designed to support deterministic fail-safe behavior when material authority information is revoked, suspended, expired, stale, conflicting, unavailable, or unverifiable. |
| | A Policy Grammar for Inter-Domain Agent Routing |
| |
|
Agent tasks are delegated across organizational boundaries. Existing work specifies how agents are identified, discovered, and described, states requirements for cross-domain isolation and authorization, and identifies the absence of a mechanism for expressing capability policy as a gap. This document defines four policy attributes for inter-domain agent delegation, the declarations each attribute carries, and a validity condition on delegation chains that no party establishes by observing the whole chain. Whether independently chosen policies converge is analysed in separate work. |
| | PCEP Extension for Flexible Grid Networks |
| |
|
This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. |
| | PCEP Extensions for Distribution of Link-State and TE Information for Optical Networks |
| |
|
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). This Link State and TE information has previously been obtained from a link state routing protocol that supports traffic engineering extensions. Link-State (LS) and Traffic Engineering (TE) information can also be carried in the Path Computation Element Communication Protocol (PCEP) using experimental exensions to PCEP known as Link-State PCEP (PCEP- LS). This document provides further experimental extensions to collect Link-State and TE information for optical networks. |
| | Reference Interaction Models for Remote Attestation Procedures |
| |
|
This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. |
| |
|
| |
| | Sub-Link Scoped IPv6 Multicast Addressing |
| |
|
The IPv6 addressing architecture for multicast has the scope of a multicast group embedded in its address, with the smallest non- reserved scopes being interface-local and link-local, numbered 1 and 2. This document suggests the introduction of a scope inbetween these two, for use with lower-layer transport multicast that reaches parts of a link. Since there is no room to insert a scope value for this, a separate address block is used. A mapping for Ethernet as lower-layer transport is provided. |
| | IPv6 wants 802.11 Directed Multicast Service |
| |
|
There is consensus for switching this document from Flexible Multicast Service (FMS) to Directed Multicast Service (DMS). This version has not been edited over yet and is being uploaded to check if/how the name can be changed. IEEE 802.11 Flexible Multicast Service (FMS) addresses reliability issues in IPv6 due to aggressive powersave optimizations in 802.11 client devices. The intent of this document is to collect consensus in the IETF 6man (IPv6 Maintenance) working group to request either/both the IEEE 802.11 Working Group and/or the Wifi Alliance's certification process to make implementing FMS a requirement. |
| | RTP Payload Format for V-DMC |
| |
|
This memo outlines RTP payload formats for the Video-based Dynamic Mesh Coding (V-DMC), which comprises several types of components, such as a basemesh, AC-based displacements, 2D representations of attributes, and an atlas. This document focuses on describing the basemesh and displacement, while the RTP payload formats for the atlas and attributes are addressed in other documents. The RTP payload header formats enable the packetization of a basemesh or displacement Network Abstraction Layer (NAL) unit in an RTP packet payload as well as fragmentation of a NAL unit into multiple RTP packets. |
| | JSCalendar: Converting from and to iCalendar |
| |
|
This document defines how to convert calendaring information between the JSCalendar and iCalendar data formats. It considers every JSCalendar and iCalendar element registered at IANA at the time of publication. It defines conversion rules for all elements that are common to both formats, as well as how convert arbitrary or unknown JSCalendar and iCalendar elements. This document updates RFC 5545 ("iCalendar") and jscalendarbis ("JSCalendar") by defining new properties and parameters for JSCalendar and iCalendar conversion. |
| | BGP Flow Specification for SRv6 |
| |
| | draft-ietf-idr-flowspec-srv6-10.txt |
| | Date: |
16/09/2026 |
| | Authors: |
Zhenbin Li, Huaimo Chen, Christoph Loibl, Gyan Mishra, Yongqing Zhu, Shunwan Zhuang |
| | Working Group: |
Inter-Domain Routing (idr) |
|
This document specifies extensions to BGP Flow Specification (BGP-FS) to enable filtering of IPv6 packets based on the structural components of an SRv6 Segment Identifier (SID) present in the IPv6 Destination Address (representing the active segment of an SRv6 path). |
| | Update to the Cryptographic Message Syntax (CMS) Algorithm Identifier Protection Attribute |
| |
|
This document updates RFC 6211. It corrects errors in the definition of the id-aa-CMSAlgorithmProtect ASN.1 object identifier. The IANA registry entry has always been correct. |
| | OAuth Profile for Open Public Clients |
| |
|
This document specifies a profile of the OAuth authorization protocol to allow for interoperability between native clients and servers using open protocols, such as JMAP, IMAP, SMTP, POP, CalDAV, and CardDAV. The profile is restricted to native clients, that is, applications installed and run on the end user's device. It deliberately does not support web-based clients, which cannot complete the flow as specified. |
| | MPLS On-Path Telemetry Network Action Flag for OAM |
| |
|
This document describes postcard-based on-path telemetry with packet marking (PBT-M) using an MPLS Network Actions (MNA) flag to support Operations, Administration, and Maintenance (OAM) in MPLS networks. The scheme uses a single flag bit carried in a Flag-Based Network Action Indicator (Opcode 1) of the MNA Sub-Stack as defined in RFC 9994. In addition to addressing the protocol requirements for applying PBT-M, this document provides comprehensive operational, manageability, and security considerations. |
| | Applicability of Reliable Server Pooling for Real-Time Distributed Computing |
| |
|
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools. |
| | Secure SCTP |
| |
|
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP, it is designed to integrate cryptographic functions into SCTP. |
| | Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility |
| |
|
This document describes a novel mobility concept based on a combination of SCTP with the Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool). |
| | Reliable Server Pooling (RSerPool) Bakeoff Scoring |
| |
|
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs. |
| | Handle Resolution Option for ASAP |
| |
|
This document describes the Handle Resolution option for the ASAP protocol. |
| | Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling |
| |
|
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling. |
| | Takeover Suggestion Flag for the ENRP Handle Update Message |
| |
|
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol. |
| | SCTP Socket API Extensions for Concurrent Multipath Transfer |
| |
|
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions. |
| | Sender Queue Info Option for the SCTP Socket API |
| |
|
This document describes an extension to the SCTP sockets API for querying information about the sender queue. |
| | Ideas for a Next Generation of the Reliable Server Pooling Framework |
| |
|
This document collects ideas for a next generation of the Reliable Server Pooling framework. |
| | Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP) |
| |
|
This document collects ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned over more than two decades of SCTP deployment. |
| | NEAT Sockets API |
| |
|
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality. |
| | Distribute Service Metric by BGP |
| |
|
When calculating the path selection for service traffic, it is important to consider not only network metrics, but also the impact of service Metric. Therefore, it is necessary to transmit service Metric information from the service site to the user access site, in order to facilitate path selection for service traffic at the access router. This document describes an approach for using the BGP Control Plane to steer traffic based on a set of metrics that reflect the underlying network conditions and other service-specific state collected from available service locations. |
| | Using AES-GCM-SIV in the Internet Protocol Version 2 (IKEv2) and Encapsulating Security Payload (ESP) Protocols |
| |
|
This document specifies the use of AES-GCM-SIV in the Internet Key Exchange Protocol version 2 (IKEv2) and the Encapsulating Security Payload (ESP) protocols. This document also adds AES-GCM-SIV to the IANA IKEv2 registry for "Transform Type 1 - Encryption Algorithm Transform IDs." AES-GCM-SIV is a nonce misuse-resistant authenticated encryption with associated data (AEAD) algorithm based on AES-GCM. |
| | A Standard for Claiming Transparency and Falsifiability |
| |
| | draft-laurie-tmif-02.txt |
| | Date: |
16/09/2026 |
| | Authors: |
Ben Laurie, Tiziano Santoro, Pauline Anthonysamy, Sarah de Haas, Ankur Mathur |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies a Transparency Metadata Interchange Format (TMIF) that allows a distributed or confidential computing system to make standardized, verifiable claims about its levels of transparency and falsifiability. Modeled as a structured Endorsement within the Remote Attestation Procedures (RATS) architecture, TMIF provides an agnostic, schema-defined communication vehicle for claimants to declare how their security mitigations and policy governance controls can be independently inspected, reproduced, and verified by third- party evaluators. |
| | Computing Service Metrics Operation and Joint Service Selection under CATS |
| |
|
Computing-Aware Traffic Steering (CATS) optimizes traffic forwarding by considering both computing and networking metrics. The CATS framework and metric-definition documents provide valuable theoretical models, yet they face challenges in achieving direct operational execution in real-world deployments: normalization methods vary across providers, and aggregated unitless scores often lose the operational information that routers need for precise steering decisions. This document provides a self-contained, executable operational model for a core class of CATS deployment scenarios: latency-sensitive, compute-intensive services whose steering decisions are made in real time at the forwarding node. Instead of disseminating low-level raw hardware metrics, service sites dynamically evaluate and report service-oriented metrics (e.g., Global Available Slots and Computing Time) to the control plane. The document clarifies how these metrics are derived from basic resource information, service reference information, and local policy. It also specifies how the CATS Path Selector (C-PS) combines the Computing Service Table (populated from C-SMA reports) with the Network Service Table to make joint traffic- steering decisions, and defines update-control and fallback mechanisms suitable for large-scale deployments. Within the unified CATS architecture, the service-oriented operational model defined in this document coexists with the general- purpose L1/L2 normalized metric framework: a deployment MAY use either model, or run both pipelines in parallel for different service classes, without embedding metric fields across frameworks. This document does not negate the value of normalized metrics; it focuses on the service-level abstractions and runtime operations required for direct traffic steering. |
| | CORECONF for Machine-to-Machine Communication |
| |
|
The document addresses the specific challenges of M2M interactions where both endpoints may be constrained nodes, and explores the use of CORECONF primitives. This document describes the use of CORECONF (CoAP Management Interface) for Machine-to-Machine (M2M) communication in constrained IoT environments. It defines a YANG data model enabling remote management and configuration of constrained devices using CoAP, CBOR, and YANG SID identifiers. The serialization in CBOR of this data model limits the payload size. It documents also how the YANG data model can interact with common IoT ontologies such as SOSA or SAREF. The same CORECONF/SID serialization also enables full interoperability between constrained devices and AI agents, by exposing device actions and data through an MCP (Model Context Protocol) server without requiring an intermediate, device-specific translation layer. |
| | Multi-Sheet Tab-Separated Values (MTSV) |
| |
|
This document defines Multi-Sheet Tab-Separated Values (MTSV), a text format that carries one or more sheets of tab-separated values in a single file. MTSV is TSV with one additional dimension: sheets are separated by the ASCII form feed (FF) character. A TSV file that contains no FF, and no CR other than in CRLF line breaks, is an MTSV file. This document also registers the text/prs.mtsv media type. |
| | An SVCB Service Parameter for Well-Known URI Paths |
| |
|
This document defines the "well-known" Service Parameter Key (SvcParamKey) for SVCB and HTTPS resource records. It carries one or more well-known URI suffixes, identifying resources under "/.well- known/" that are available at the service endpoint. It specifies the presentation and wire formats and requests registration of the key with IANA. |
| | Possession Is Not Authority: Execution Handle,Sink Verification,Atomic Consumption,and Finality Receipt |
| |
|
Across agentic AI, payments, cloud control planes, industrial actuation, and cross-border processing, a machine can prepare a concrete operation long before that operation is allowed to become externally effective. Existing protocols already move identity, authorization data, attestation results, and signed statements. They do not, by themselves, define the small set of interoperable objects required at the effectuation boundary: a canonical Candidate Act Descriptor, a scoped non-bearer Execution Handle bound to that exact act and to a designated Finality Sink, a verify operation that reconstructs the pending effect, an atomic consume that prevents replay, and a Finality Receipt that records what was actually permitted. The residual failure is familiar and does not require token forgery. An access token, capability, session cookie, SPIFFE SVID, WIMSE credential, OAuth grant, attestation result, or signed mandate can remain cryptographically valid while being presented for a different tool call, a substituted beneficiary, a second sink, a replayed payment, a migrated region, or an alternate administrative path. Bearer possession then becomes mistaken for current, act-specific authority to effectuate. Existing mechanisms already address important adjacent problems. OAuth 2.0 and OAuth Rich Authorization Requests can express fine- grained authorization data [RFC6749] [RFC9396]. DPoP and certificate-bound tokens constrain sender possession [RFC9449] [RFC8705]. JWT and CWT carry signed claims [RFC7519] [RFC8392]. HTTP Message Signatures authenticate individual requests [RFC9421]. WIMSE addresses workload identity in multi-system environments [WIMSE-ARCH]. RATS supplies Evidence and Attestation Results [RFC9334]. SCITT supplies signed statements, transparency, and receipts [RFC9943]. MCP and similar tool interfaces dispatch agent- selected functions. None of these objects is specified as a non- bearer, exact-act, sink-bound, single-use-or-bounded effectuation authority whose verification is serialized with protected commit. This document specifies those wire objects and the verify/consume/ receipt exchange. A Candidate Act remains in a Non-Effective State until a Finality Sink reconstructs the security-relevant pending operation, verifies that a current Execution Handle authorizes that exact operation at that sink, consumes or reserves the handle according to its reuse policy, and optionally emits a Finality Receipt. The Execution Handle is not a session token and is not valid merely because the caller can present it. Prevention is claimed only when exact-act binding, sink binding, currentness, reuse policy, consequence-path coverage, and verification-to-commit serialization are load-bearing. If a deployment uses ordinary bearer tokens, advisory act identifiers, post-hoc logs, or a gateway that can be routed around, the result is mitigation or evidence rather than the same prevention guarantee. Encoding profiles are provided for JSON and COSE/CWT; the architecture requires the semantics, not one exclusive encoding. Three rejections are expected and are addressed in the body rather than dismissed here. First, a saga, 2PC, or workflow plus ordinary tokens already coordinates steps; that coordinator is complementary, and is enough only if each sink also reconstructs the live act and consumes act-bound authority. Second, atomic consume is not a process-wide lock: SINGLE_USE is per handle, COUNTED and ENVELOPE exist for high-QPS classes, and rails that already keep idempotency keys already pay this cost. Third, reconstruction is required only at the component that would first make the effect real, over fields that sink can observe — not at every mesh hop, and not as blind trust in a caller digest. Reviewers who hold any of those objections are asked to read those sections and to supply a counterexample if the residual gap is already closed. Criticism, prior art, and a recommendation to stop the work remain invited. |
| | Partial Commit Is Not Finality: Composite Candidate Acts Across Multiple Finality Sinks |
| |
|
An agent, a payment orchestrator, or a control-plane applicator often intends one Candidate Act that would become real only as several consequences: a settlement post, a ledger write, a tool invoke, a notification, a radio enable. [DAS-HANDLE] specifies verify, consume, and receipt at one Finality Sink. It does not say what "the act was permitted" means when sink S1 has consumed and posted and sink S2 has rejected, timed out, or committed a different digest. Existing distributed-transaction tools already address adjacent problems. Two-phase commit, XA, sagas, TCC, transactional outbox, and workflow engines coordinate steps. OAuth, WIMSE, RATS, and SCITT still name identity, environment, and signed statements. None of them, by themselves, bind N sink-local Execution Handles to one composite Act Digest and require that no child consequence become externally effective unless every required child reaches a defined terminal state. This document specifies Composite Candidate Acts, child handles, a coordinator that may only prepare, a two-phase consume rule, and the distinction between prevention (no child commits unless the composite closes) and mitigation (compensate after a partial post). Compensation is itself a Candidate Act. It is not a silent undo and not a license to skip verify on the original child. The join is closed by a durable, linearizable Composite Decision Log holding one value per composite: empty, COMMIT, or ABORT, written only by compare-and-swap so that the first writer wins. The coordinator MUST win the log before sending a decision to any child. A prepared child whose reservation timer expires MUST consult the log: it commits if COMMIT is recorded, releases if ABORT is recorded, attempts its own compare-and-swap of ABORT if the log is empty, and holds its reservation (HOLD) only if the log is unreachable. No child acts on silence alone. This is not a new consensus protocol and not a claim that XA is obsolete. Profiles that cannot obtain prepare-from-every-sink, or cannot reach a durable linearizable decision log, MUST NOT claim all- or-none prevention. Three rejections are expected and are treated as design constraints. "Saga plus handle is enough" is accepted when each saga step already reconstructs the live child, consumes a child handle, and cannot log SUCCESS after a required child rejects; this draft then shrinks to join fields. Prepare across N sinks is a latency tax only if consume-state is global; it is per child handle, and a no_prepare mail or MCP child must use the mitigation profile rather than pretend 2PC. Child sinks reconstruct only their own pending effect, not a mesh-wide CAD. Reviewers who would reject on saga, performance, or reconstruction grounds are asked to read those sections before discarding the document. Criticism, including "this should stay a note in the handle draft," remains invited. |
| | Illustrative Codes Are Not a Namespace: Registries for Execution-Finality Consequence Classes,Sink Types,Act Types,Failure Codes,Profiles,and Media Types |
| |
|
The execution-finality family uses a shared vocabulary: Candidate Act, Execution Handle, Finality Sink, consume, and Finality Receipt [DAS-HANDLE] [DAS-PROTOCOL]. Each profile currently invents overlapping labels for the same ideas — FINANCIAL, SETTLEMENT, EF- 005, SINGLE_USE — and then states that the codes are illustrative and not IANA assignments. Two implementations can therefore emit the same token string with different meaning, or different strings for the same deny reason. Existing IANA registries already name adjacent objects. JWT and CWT claim names [RFC7519] [RFC8392], OAuth parameters [RFC6749] [RFC7591], HTTP problem types [RFC9457], media types, RATS EAT claims, and SCITT statement types [RFC9943] solve identity, token, and transparency naming. They do not allocate consequence class, sink type, act type, handle reuse policy, execution-finality failure code, or finality-profile identifiers. This document proposes those registries and an initial allocation drawn from the family drafts. It does not decide which acts should be authorized. It does not replace OAuth error codes, HTTP status codes, or application problem types. A registered code is a shared name for a machine-readable condition; it is not a legal classification and not evidence that any named product implements the condition. Until IANA action occurs, codes in this document and in companion drafts remain provisional. Implementations MUST treat foreign namespaces as distinct. Criticism of the registry split, the initial code list, the registration policy, and the claim that a new namespace is required at all is explicitly invited. |
| | The Agent Trust Profile: Verifiable Authority for Autonomous Agents |
| |
|
Autonomous AI agents act on behalf of people and organizations across system and organizational boundaries. Existing credentials establish that a token is valid; they do not express which agent is acting, for whom, under what delegated authority, within which constraints, and whether that authority is still current. This document profiles existing standards — JWS, OAuth/OIDC, SPIFFE/WIMSE workload identity, DPoP-style proof of possession, OpenID AuthZEN and OpenID Federation — to carry those semantics: agent identity and principal binding, delegation with authority attenuation, capability-based authorization with constraints, request proof of possession, authorization attestations, tamper-evident provenance, revocation, and cross- organization trust. It defines no new cryptography, transport or token format. |
| | Claim Boundaries for Execution Evidence |
| |
|
Systems that act in the world produce logs, receipts, approvals, traces, attestations, provenance statements, and transparency records. These artifacts are routinely offered as evidence that an action was authorized, performed, or completed. This document states a discipline for bounding such claims: the strength of an execution- related claim is limited by what the available evidence actually observed and by the control and observation topology at the boundary that produced it. Message formats, signature validity, receipt validity, and registration do not create observation or independence that did not exist. The control-topology test was prompted by a scenario Stephen Farrell posed in the IETF agent-protocol discussion of July 2026: one party creates another and may be able to act in its name. The tension is general, since no message format can supply the independent enforcement or observation dependencies required by a prevention or adversary-resistant detection-coverage guarantee, and the scenario is worked through in an appendix. The document defines no protocol, no record format, and no registry. It collects non- inference rules, a control-topology test for prevention and detection claims, a worked example, and reporting distinctions for evidence that does not support the claim asserted over it. |
| | Export of Source Address Validation (SAV) Information in IPFIX |
| |
| | draft-cao-savnet-ipfix-sav-00.txt |
| | Date: |
16/09/2026 |
| | Authors: |
Qian Cao, Mingqing(Michael) Huang, Benoit Claise, Tianran Zhou |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IP Flow Information Export Information Elements to export the context and outcome of Source Address Validation enforcement data. These SAV-specific Information Elements provide detailed insight into why packets are identified as spoofed by capturing the specific SAV rules that triggered validation decisions. This operational visibility is essential for network operators to observe SAV enforcement behavior and analyze source address spoofing events detected by SAV. |
| | Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks |
| |
| | draft-ietf-nvo3-rfc7348bis-10.txt |
| | Date: |
16/09/2026 |
| | Authors: |
Mallik Mahalingam, Dinesh Dutt, Larry Kreeger, T. Sridhar, Ali Sajassi |
| | Working Group: |
Network Virtualization Overlays (nvo3) |
|
This document specifies Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This document obsoletes RFC 7348, which documented the deployed VXLAN protocol for the benefit of the Internet community, and moves the VXLAN specification to the IETF document stream, allowing for the creation of extensions to VXLAN that require additions to the VXLAN header and their registration with IANA. The format and processing described here are fully compatible with those in RFC 7348. |
| | Deferred Token Response |
| |
|
This document defines the Deferred Token Response (DTR) extension for OAuth 2.1. In existing OAuth grants, the token endpoint either issues an access token or returns an error. DTR establishes a generic asynchronous token request mechanism that any OAuth grant may plug into. In DTR-aware flows, the authorization server returns a deferral_code and a polling interval, indicating that the final token response will be available at a later time. The client retrieves the eventual response by polling the token endpoint, or by receiving a callback from the authorization server when one is configured. |
| | Support for Path MTU (PMTU) in the Path Computation Element (PCE) Communication Protocol (PCEP) |
| |
| | draft-ietf-pce-pcep-pmtu-10.txt |
| | Date: |
16/09/2026 |
| | Authors: |
Shuping Peng, Cheng Li, Liuyan Han, Luc-Fabrice Ndifor, Samuel Sidor |
| | Working Group: |
Path Computation Element (pce) |
|
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for the SR path is unavailable at the headend. This document specifies the extension to PCE Communication Protocol (PCEP) to carry path MTU as a new metric type in the PCEP messages for SR, but not limited to it. This document also updates RFC 5440 to allow metric bounds to be minimum as needed in the case of path MTU. |
| | PIM Join Attributes for Locator/ID Separation Protocol (LISP) Environments |
| |
|
This document defines two PIM Join/Prune attributes that support the construction of multicast distribution trees where the root and receivers are located in different Locator/ID Separation Protocol (LISP) sites. These attributes allow the receiver site to select between unicast and multicast underlying transport, to convey the RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel Router) to the control plane of the root ITR (Ingress Tunnel Router) and to signal the underlay multicast group to the control plane of the root ITR. This document updates RFC 8059 and RFC 9798. |
| | RATS Endorsements |
| |
|
In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and uses Appraisal Policy for Evidence, typically with additional input from Endorsements and Reference Values, to generate Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. |
| | Destination/Source Routing |
| |
|
This document specifies using packets' source addresses in route lookups as additional qualifier to be used in hop-by-hop routing decisions. The proposed mechanism applies to IPv6 [RFC8200] in general with specific considerations for routing protocols. |
| | Constraining RPKI Trust Anchors |
| |
|
This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties (RPs) to impose locally configured Constraints on cryptographic products subordinate to Trust Anchors (TAs). The ability to constrain a Trust Anchor operator's effective signing authority to a limited set of Internet Number Resources (INRs) allows Relying Parties to enjoy the potential benefits of assuming trust - within a bounded scope. The specified approach and configuration format allow RPKI operators to communicate efficiently about observations related to Trust Anchor operations. |
| | ML-KEM Post-Quantum Key Agreement for TLS 1.3 |
| |
|
This memo defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroups and registers IANA values in the TLS Supported Groups registry for use in TLS 1.3 to achieve post-quantum (PQ) key establishment. |
| |
|
| |
| | An Application Layer Interface for Non-Internet-connected Physical Components (NIPC) |
| |
| | draft-ietf-asdf-nipc-22.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Bart Brinckman, Rohit Mohan, Braeden Sanford |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This document describes an API that allows applications to perform operations against a gateway serving one or more devices described by an SDF model. The API consists of a RESTful application layer interface that performs operations on those devices, as well as a CBOR-based publish-subscribe interface for streaming data. |
| | Semantic Definition Format (SDF) Extension for Non-Affordance Information |
| |
|
This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new class keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. |
| | SDF Protocol Mapping |
| |
|
This document defines protocol mapping extensions for the Semantic Definition Format (SDF) to enable mapping of protocol-agnostic SDF affordances to protocol-specific operations. The protocol mapping mechanism allows SDF models to specify how properties, actions, and events should be accessed using a specific protocol. This document defines protocol mappings for Bluetooth Low Energy and Zigbee, and the mechanism can be extended to other protocols such as HTTP and CoAP. This document also describes a method to extend SCIM with an SDF model mapping. |
| | Common YANG Data Types for Layer 1 Networks |
| |
|
This document defines a collection of common data types, identities, and groupings in the YANG data modeling language. These derived common data types, identities, and groupings are intended to be imported by modules that model Layer 1 configuration and state capabilities. The Layer 1 types are representative of Layer 1 client signals applicable to transport networks, such as Optical Transport Networks (OTN). The Optical Transport Network (OTN) data structures are included in this document as Layer 1 types. |
| | Pacing in Transport Protocols |
| |
| | draft-irtf-iccrg-pacing-04.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Michael Welzl, Wesley Eddy, Vidhi Goel, Michael Tuexen |
| | Working Group: |
Internet Congestion Control (iccrg) |
|
Applications or congestion control mechanisms can produce bursty traffic, which can cause unnecessary queuing and packet loss. To reduce the burstiness of traffic, the concept of evenly spacing out the traffic from a data sender over a round-trip time known as "pacing" has been used in many transport protocol implementations. This document gives an overview of pacing and how some known pacing implementations work. |
| | SD-WAN Edge and Underlay Tunnel Discovery Using BGP |
| |
|
This document specifies BGP mechanisms for SD-WAN (Software-Defined Wide Area Network) edge node attribute discovery. These mechanisms comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel Encapsulation Attribute, and a new Subsequent Address Family Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN underlay tunnel information. |
| | Alternate Marking Deployment Framework |
| |
|
This document provides a framework for Alternate Marking deployment and includes considerations and guidance for the deployment of the methodology. |
| | JSON Meta Application Protocol (JMAP) for Calendars |
| |
|
This document specifies a data model for synchronizing calendar data with a server using JMAP. Clients can use this to efficiently read, write, and share calendars and events, receive push notifications for changes or event reminders, and keep track of changes made by others in a multi-user environment. |
| | JMAP Object History |
| |
|
The JMAP base protocol (RFC8620) provides methods for synchronizing the current state of data objects between client and server. This extension adds the ability to retrieve historical versions of objects, including objects that have been destroyed, by extending the standard Foo/get method. |
| | JMAP Conditional Set |
| |
|
The JMAP base protocol ([JMAP-CORE]) provides the Foo/set method for creating, updating, and destroying objects. It offers a single concurrency control, the "ifInState" argument, which guards an entire object type: if any object of that type has changed, the whole method is rejected. This extension adds a finer, per-object conditional mechanism. A client may require that an individual update or destroy proceed only if the target object still matches a set of expected property values, expressed using the JMAP PatchObject already defined for updates. This provides optimistic concurrency control scoped to a single object — the equivalent of an HTTP "If-Match" precondition — for any JMAP data type. This extension also defines an optional "atomic" argument that applies an entire Foo/set as a single unit: either every change it requests takes effect, or none does. Combined with the per-object precondition, this lets a client express a multi-object change that is safe only when applied together — such as an atomic rename that exchanges two names. |
| | The Locator/ID Separation Protocol (LISP) for Multicast Environments |
| |
| | draft-ietf-lisp-rfc6831bis-08.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Dino Farinacci, David Meyer, John Zwiebel, Stig Venaas, Vengada Govindan |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document specifies the design for inter-domain multicast overlays using the Locator/ID Separation Protocol (LISP) architecture and protocols. The document specifies how LISP multicast overlays operate over multicast and unicast underlays. The mechanisms in this specification indicate how a signal-based approach using the PIM protocol can be used to program LISP encapsulators with a replication list in a locator-set, where the replication list can be a mix of multicast and unicast locators. This document when approved obsoletes RFC6831 |
| | IGP Encoding for SRv6 Mirror SID in Egress Protection |
| |
|
This document specifies the IGP protocol extensions required to support SRv6 path egress protection using the Mirror SID (End.M) mechanism. It reuses the existing SRv6 End SID sub-TLV defined in [RFC9352] (IS-IS, Section 7.2) and [RFC9513] (OSPFv3, Section 8) with the End.M endpoint behavior (74) to advertise the Mirror SID and the set of protected locators, and defines a new Protected Locators sub-(sub-)TLV, enabling a backup egress node (protector) to signal its capability to protect a primary egress node within a single link- state IGP area. This document is a companion to [I-D.ietf-rtgwg-srv6-egress-protection], which specifies the overall SRv6 path egress protection mechanism and the End.M behavior. The IGP encoding defined herein provides the signaling substrate for that mechanism. |
| | The Network File System Access Control List Protocol |
| |
|
This Informational document describes the NFS_ACL protocol. NFS_ACL is a legacy member of the Network File System family of protocols that NFS clients use to view and update Access Control Lists stored on an NFS version 2 or version 3 server. |
| | Load Sharing for the Stream Control Transmission Protocol (SCTP) |
| |
| | draft-tuexen-tsvwg-sctp-multipath-32.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi Natarajan, Randall Stewart, Michael Tuexen |
| | Working Group: |
Individual Submissions (none) |
|
The Stream Control Transmission Protocol (SCTP) supports multi-homing for providing network fault tolerance. However, mainly one path is used for data transmission. Only timer-based retransmissions are carried over other paths as well. This document describes how multiple paths can be used simultaneously for transmitting user messages. |
| | Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH) and IPFIX |
| |
|
Explicit Congestion Notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to feed information about congestion back to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support within a Service Function Chaining (SFC) enabled domain through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, RFC 7011) protocol. |
| | A YANG Data Model for Client Signal Performance Monitoring |
| |
|
A transport network is a server-layer network to provide connectivity services to its client. Given the client signal is configured, the followup function for performance monitoring, such as latency and bit error rate, would be needed for network operation. This document describes the data model to support the performance monitoring functionalities. |
| | Double Nonce Derive Key AES-GCM (DNDK-GCM) |
| |
|
This document specifies an authenticated encryption algorithm called Double Nonce Derive Key AES-GCM (DNDK-GCM). It operates with a 32- byte root key and is designed to encrypt with a 24-byte random nonce and optionally to provide for key commitment. Encryption takes the root key and a 15-byte portion of the random nonce, and derives a fresh 32-byte encryption key and (optionally) a key commitment value. Then, it invokes AES-GCM with the derived key and the remaining bytes of the nonce, and outputs the ciphertext, authentication tag and the key commitment value. Although this is not the primary use case, it is also possible to use DNDK-GCM with a non-repeating but non-random nonce (i.e., a "counter- based nonce"). The low collision probability in a collection of 24-byte random nonces and the per-nonce derivation of an encryption key extend the lifetime of the root key, and the scheme can support processing up to 2^64 bytes under a given root key. DNDK-GCM introduces a relatively small overhead compared to using AES-GCM directly, and its security relies only on the standard assumption that AES acts as a pseudorandom permutation. |
| | Service Binding Mapping for Agents |
| |
|
With the continuous introduction of intelligent agent communication and interaction protocols, the current DNS cannot adequately meet the requirements for agent service resolution. This document defines a new DNS resource record type, AGENT, which is a SVCB-compatible RR type, and specifies the mapping specifications. |
| | AERO/OMNI Base Specification Amendments (Volume 1) |
| |
|
The Automatic Extended Route Optimization (AERO) and Overlay Multilink Network (OMNI) Interface functional specifications have reached a level of maturity ready for advancement in the RFC publication process. Updates to the base specifications are documented in this first amendment and any additional future amendments as necessary. |
| | RootCache: Filling Resolver Caches with Root Zone Records |
| |
|
Some DNS recursive resolver operators want to prevent snooping by third parties of requests sent to DNS root servers. Resolvers can reduce the number of queries sent to root server, and thus prevent observation of requests, by caching a copy of the full root zone. This document shows how a resolver can securely receive the full root zone and put it into the resolver's cache. This document obsoletes RFC 8806. |
| | Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems |
| |
|
This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17. The -01 revision added pre-execution recording requirements, recording independence, deny reason codes, replay protection, external timestamp anchoring, and content fingerprinting based on feedback from independent implementers. The -02 revision added a Decision Reproducibility section (Section 13) that distinguishes record reproducibility, available for any model, from decision reproducibility, available only for open-weight models executed at temperature zero in an attested environment, and defines the associated record fields. The -03 revision added the Attestation Closure requirement (Section 13.6): the digests recorded for decision reproducibility MUST cover the complete computational closure of the inference function -- model weights, tokenizer, chat template, inference engine build, decoding configuration, and numeric environment -- together with new record fields (tokenizer_digest, chat_template_digest, engine_build_digest) and a minimal-change threat analysis (Section 13.7) showing that any component left outside the attested set is a forgery channel. This revision (-04) adds algorithm agility for post-quantum signatures (ML-DSA-65, FIPS 204) alongside ECDSA P-256; a key identifier (signer_kid, RFC 7638) that resolves which principal signed an independently recorded record; a trust-level assignment integrity requirement (Section 5.3) so that downgrading a consequential action is an attributable event rather than silent suppression; and OPTIONAL Merkle batch anchoring (Section 6.4) using the RFC 6962 construction for compact inclusion proofs at high throughput. All -04 additions are OPTIONAL to produce, and -04 verifiers stay backward compatible with -03: a -04 verifier accepts -03 records, and the new signing metadata is required only in records that carry a signature. |
| | IS-IS Aggregated SNP Hash Packets |
| |
|
The document presents an optional new type of database synchronization packet called an Aggregated SNP Hash (ASH). When feasible, it compresses traditional SNP exchanges into a dynamic Merkle tree-like structure, which speeds up synchronization of large databases and adjacency numbers while reducing the load from regular CSNP exchanges during normal operation. Just like CSNPs and PSNPs, ASH packets come in two flavors, called Complete ASH (CASH) and Partial ASH (PASH). |
| | Security Principal and Verifier Binding for Agent Communication Protocols |
| |
|
Agent communication protocols often carry claims about user authority, agent instance identity, tool or external-resource identity, delegation state, session continuity, and action evidence. These claims have different verifiers, freshness requirements, failure modes, and security consequences. If they are collapsed into a single token, identity label, session identifier, or audit record, protocol text can accidentally imply more authority or accountability than the receiver can actually verify. This document defines a verifier-facing model for separating those claims. It provides a reusable matrix format that protocol authors can use to state, for each security-relevant claim, which field carries it, which party verifies it, what binding or freshness rule applies, what failure behavior is required when the claim is absent, stale, inconsistent, or not verifiable, and what constrained result an application may consume after successful verification. It also separates specification status, implementation status, and evidence type so that reviewers can distinguish current protocol text, implementation evidence, inherited mechanisms, and architectural assumptions. The document is protocol-neutral. It is intended to help compare candidate agent communication drafts and to provide security-considerations and requirements text for agent session and delegation binding. The document also defines row-outcome semantics and dependency- closure rules for composed mappings. These rules prevent a composite result from becoming stronger than its verified inputs, distinguish failed checks, unsupported verifier capabilities, checks skipped after a failed prerequisite, and unavailable or ambiguous inputs, propagate transitive dependency failures, and make cyclic, stale, downgraded, or revision-incoherent dependencies visible to reviewers. |
| | RADIUS Attribute for IEEE 802.11 WLAN Security Profiles |
| |
|
IEEE 802.11, as amended, defines security profiles, and several of those profiles can share the same AKM suite and pairwise cipher, so WLAN-AKM-Suite and WLAN-Pairwise-Cipher no longer tell a RADIUS server which profile is in effect. This document defines the WLAN-Security-Profile RADIUS attribute, which reports the security profile the responder accepted. A Network Access Server includes it in the Access-Requests it generates for an IEEE 802.1X authentication so the server can make policy decisions based on the value. The attribute complements the IEEE 802 attributes defined in RFC 7268. |
| | Execution Finality at External-Effect Boundaries: Enforcement Profiles for 6G,AI-Native RAN,RF,ISAC,Accelerated Compute,Devices,and Autonomous Systems |
| |
|
AI-native and autonomous infrastructure is increasingly able to generate, optimize, schedule, route, transmit, disclose, render, allocate, encrypt, modify network state, control radio resources, and initiate physical or machine actions without a human decision at every step. An agentic AI system may generate a tool call or machine instruction; an AI-native RAN may compute a beam, handover, power, spectrum, routing, slicing, or topology change; an integrated sensing and communication (ISAC) system may generate sensing information for release or fusion; an O-RAN xApp or rApp may generate a network- control instruction; an accelerator may produce a routing, scheduling, inference, or resource-allocation result; or an autonomous controller may prepare a cyber-physical actuation. Successful computation, authentication, attestation, access authorization, credential possession, or execution inside a trusted environment does not, by itself, establish authority for the resulting operation to become externally effective. This document describes a protected execution-finality architecture in which that distinction is machine-enforced. A proposed consequential operation is represented as a Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain establishes a machine-verifiable act descriptor, validates applicable machine-verifiable authority predicates, and performs, consumes, advances, or references applicable protected state. The resulting state is represented by an applicable protected-state representation, and Protected Validation Evidence is committed before, or atomically with, authorization of availability of a scoped non-bearer capability. The capability is machine-verifiably or cryptographically bound to the specific Candidate Act, the act descriptor or its digest, the committed validation evidence, applicable protected state, freshness constraints, permitted effectuation scope, the relevant execution-finality boundary, and the applicable Finality Sink. The Finality Sink is positioned at or before the point at which the Candidate Act would first acquire an externally meaningful consequence. Before effectuation, the Finality Sink performs a machine-enforced capability-validity check and permits the Candidate Act to cross the execution-finality boundary only when the required bindings, protected state, validation evidence, freshness conditions, and effectuation scope remain valid. Absence, expiry, revocation, exhaustion, replay, staleness, mismatch, timeout, unverifiability, indeterminacy, scope failure, binding failure, or failure of a required preceding protected operation causes the architecture to fail closed, leaving the Candidate Act non-effective. The document provides 132 detailed Enforcement Profiles that instantiate this common architecture at materially different consequence boundaries. The profiles cover agentic AI tool calls and machine instructions; AI-native RAN and RF control; integrated sensing and communication (ISAC); sensing-result, location, telemetry, and metadata release; restricted-content delivery, decryption, decoding, recommendation, and rendering; derivative, transformed, synthetic, and AI-modified content; VPN, proxy, encrypted-DNS, encrypted-session, and tunnel establishment; cyber- physical, robotic, vehicle, industrial, and actuator control; network exposure, CAPIF, northbound APIs, and operator-controlled capabilities; distributed, edge, joint communication-compute, and in- network compute; shared AI-RAN accelerators and deterministic resource isolation; O-RAN xApp, rApp, A1, E2, and O1 control paths; cloud-native and virtualized RAN; network slicing, routing, topology, service-function-chain, and autonomous-network operations; ambient, passive, batteryless, backscatter, and zero-energy IoT; device wake and RF-energy admission; dynamic spectrum occupancy and spectrum authorization; RF, millimetre-wave, sub-THz, and future-band emission; reconfigurable intelligent surfaces; cooperative and distributed radio; post-quantum and hybrid cryptographic activation; RAN AI-model mutation; hardware-controlled location release; speculative decoding and target-model reconciliation; persistent and vector memory; deferred, scheduled, recurring, and trigger- conditioned acts; tool, plug-in, MCP-server, and external-agent supply-chain re-attestation; neural-state descriptors and privacy- preserving neural proofs; neural Candidate Act fragments; neural trust segmentation and influence-threshold enforcement; hardware- isolated neural-influence shadow auditing; multimodal sensory provenance; distributed multi-GPU neural execution and secure interconnect binding; unknown-agent marketplace recruitment and trust establishment; two-instance collection-time and execution-time cross- committed validation with independent protected enforcement domains; boundary-local reconstruction of the actual pending operation; attested measurement paths; atomic verify-and-effectuate and compare- and-commit enforcement; distributed partial-share finality without centralized authority reconstruction; sink-rooted finality evidence for dependent operations; readable-data operational inertness; cross- committed multi-agent delegation chains; autonomous cloud-control- plane and telco-cloud commit control; AI-mediated voice, video, recording, call-transfer, and communication-response control; separate computation authority and produced-output finality authority; produced-output canonicalization and output-derived digest binding; effectuation-enabling-resource withholding and execution- substrate technical non-completability; first-usable, location- neutral effectuation-boundary control; output grounding-to- effectuation correspondence; and accelerator, DMA, RDMA, memory, interconnect, SmartNIC, DPU, and other hardware-egress boundaries. Each profile identifies the relevant Candidate Act, authority predicates, protected state, capability scope, Finality Sink, execution-finality boundary, and externally effective consequence while inheriting the common execution-finality model. The architectural question addressed here is complementary to, rather than a replacement for, current industry work on AI-native and future communications. Publicly described work from Qualcomm, Nokia, NVIDIA, Samsung, Ericsson, and Huawei is relevant to areas covered by these profiles, including AI-native 6G, AI-RAN, accelerated and shared compute, programmable and autonomous RAN control, RF and spectrum operation, ISAC, cloud-native networking, energy optimization, and increasingly autonomous network-management loops. The present document addresses a narrower enforcement question that arises at or immediately before consequence: after an AI model, network function, accelerator, application, controller, or autonomous agent has successfully computed or prepared an operation, what machine-verifiable authority must exist at the exact external-effect boundary before that specific operation is allowed to take effect? The named organizations are referenced solely to identify publicly relevant technical directions; no affiliation, review, adoption, approval, endorsement, or participation by any named organization is implied. The common invariant across all profiles is therefore: computation may produce a Candidate Act, but computation is not authority for consequence. Profiles 184 through 213 add package-interconnect acceptance, exception-path and fault-report egress, transmission-quota grant, asserted-prior-authorization, non-transfer coherence visibility, runtime capacity arrival, PHY link-state, in-path component, post- attestation interface-protection, test-path egress, electrical and clock prerequisite, and virtual-channel admission finality, together with commercially mapped profiles for multi-accelerator tensor egress, CXL extent assign-and-reclaim, DPU host-bypass denial, produced-inference-output release, accelerator tenant rebind, destination-jurisdiction egress, agentic tool-call dispatch, key- value-cache admission, model-weight activation, co-packaged optical- lane enablement, training-contribution admission, secret unwrap, streaming-token release, retrieved-context admission, on-device sensor binding, radio and UPF emission, cross-application on-device assistant capability, and telemetry or debug egress. The silicon- layer extension profiles additionally cover CXL-class coherent memory pooling and ownership transitions; UCIe-class chiplet attach and die- to-die manageability; accelerator scale-up-fabric remote load, store, atomic, and route operations; confidential accelerator contexts and secret provisioning; IOMMU/SMMU, PASID, ATS, DMA-aperture, and peer- to-peer translation state; HBM4-class memory-region reassignment and residual-state control; DPU/SuperNIC host-independent network and storage data paths; co-packaged optics and silicon-photonics optical egress; silicon-root-of-trust firmware, microcode, and bitstream activation; and on-die memory-system, NoC, cache, and bandwidth partition state. |
| | Execution Finality for AI-Factory Silicon and Accelerated Infrastructure: Enforcement Profiles for GPUs,Chiplets,Memory Fabrics,DPUs,RDMA,CXL,and Photonic Boundaries |
| |
|
AI factories and AI-native network infrastructure are becoming heterogeneous hardware systems rather than isolated model-serving applications. A single consequential operation may traverse CPU control planes, GPUs or NPUs, high-bandwidth memory, chiplets, coherent memory fabrics, CXL or PCIe paths, IOMMUs, DMA and RDMA engines, SmartNICs or DPUs, accelerator fabrics, model-serving runtimes, optical interconnects, storage systems, and physical power or cooling controllers. At these layers, a computation can be valid and a component can be authenticated while the resulting tensor transfer, memory exposure, queue activation, model load, routing change, optical emission, partition transition, firmware update, or physical actuation is still not authorized to become effective. This document describes a silicon-oriented execution-finality architecture for preserving that distinction. A consequential hardware or infrastructure operation is represented as a Candidate Act and remains in a Non-Effective State until a Protected Enforcement Domain establishes a machine-verifiable act descriptor, validates applicable authority predicates, updates or consumes protected state, and commits Protected Validation Evidence. A scoped non-bearer capability is then bound to the exact Candidate Act, relevant descriptor or digest, protected evidence, protected state, freshness and policy conditions, permitted scope, execution-finality boundary, and applicable Finality Sink. Possession of the capability alone is insufficient. The Finality Sink is the hardware, firmware, protected-runtime, fabric, controller, or adjacent enforcement role that has mandatory control over the consequence. Depending on the profile, it may be a memory controller, HBM gate, GPU scheduler, accelerator partition controller, IOMMU or SMMU, DMA or RDMA engine, DPU or SmartNIC, fabric switch, chiplet link controller, CXL component, cache- coherence controller, model loader, token-emission gate, optical modulator or wavelength controller, eFPGA configuration gate, rack power controller, or another protected effectuation point. The Candidate Act becomes effective only after sink-local verification confirms that the actual pending operation still corresponds to the validated act and current protected state. The document provides 83 detailed Enforcement Profiles. Sixty-three translate the supplied GPU, silicon, chiplet, memory-fabric, and AI- factory source set; twelve supplementary profiles map the same execution-finality model onto current hyperscale and Arm-based infrastructure directions; and eight additional profiles selectively adapt non-duplicative mechanisms from the companion DAS Protocols V, VI, and VIII disclosures for silicon and AI-factory use. The catalogue covers GPU and accelerator egress, rack-scale AI fabrics, sparse expert routing, coherent and disaggregated memory, collective communication, DPUs and SmartNICs, RDMA and GPU-direct access, model and KV-cache lifecycle state, accelerator partitioning, arithmetic- mode control, AI-factory scheduling, storage, telemetry, firmware, power and cooling, digital-twin actuation, in-network compute, federated-learning egress, neural-waveform release, silicon photonics, optical lanes and wavelengths, chiplet admission and UCIe control, CXL memory pools, RAS and memory quarantine, eFPGA configuration, reconfigurable optical accelerator topologies, accelerator-pod membership, compiler-to-silicon executable activation, confidential-realm memory ownership, secure device attachment, coherent-mesh admission, confidential offload-device attachment, network and storage offload queues, isolated management- controller actions, host-independent cloud-offload actions, UltraServer-scale accelerator-fabric membership, distributed EFA/RDMA endpoint admission, protected neural-state proofs, hardware-isolated shadow auditing, cross-committed collection-time and execution-time validation, attested measurement paths, distributed partial-share finality, separate compute-enable and produced-output authority, output-derived digest binding, and effectuation-enabling-resource withholding. Profile identifiers retain the source numbering for traceability; gaps are intentional. The architecture is intended to complement, not replace, existing work in accelerated computing, AI networking, confidential computing, chiplet and coherent-memory systems, accelerator fabrics, optical I/ O, attestation, authorization, and hardware isolation. In particular, the profiles are directly relevant to public technology directions associated with NVIDIA, AMD, Intel, Google, Amazon Web Services (AWS), Microsoft, Broadcom, Marvell, and Arm, whose current infrastructure spans GPUs and AI accelerators, custom AI silicon, high-bandwidth memory, CPU-to-accelerator coherence, chiplets, CXL and PCIe-class fabrics, DPUs and infrastructure offload, RDMA and high-speed AI networking, rack-scale accelerator systems, optical and silicon-photonic interconnects, hardware roots of trust, and large- scale AI-factory orchestration. Additional industry relationships with Qualcomm, Meta, Cisco, HPE, Nokia, Ericsson, Samsung, Huawei, AT&T, Verizon, Orange, and Deutsche Telekom are discussed in the body of the document where AI-native networking, RAN, 6G, edge compute, and operator-controlled infrastructure create related effectuation boundaries. These references identify technical complementarity and possible enforcement locations; they do not imply that any named organization has reviewed, endorsed, adopted, or lacks equivalent mechanisms. The IETF relevance is principally the cross-layer security relationship among identity, attestation, evidence, cryptographic binding, workload authorization, protected state, replay resistance, delegation, and the final effectuation boundary. The hardware protocols themselves remain within the remit of the appropriate hardware, semiconductor, telecommunications, optical, and system standards bodies. The common invariant is: computation may produce a Candidate Act, but computation is not authority for consequence. |
| | Framework for Time-Scheduled Color based SR Policy Selection |
| |
|
In Segment Routing (SR) based VPN services, the BGP Color Extended Community is used by the egress Provider Edge (PE) router to steer VPN traffic into an SR Policy at the ingress PE. In many deployment scenarios, a customer requires different Service Level Agreements (SLAs) during different time periods of a day. For example, during business hours (e.g., 06:00 to 02:00 the next day) a best-effort, lower-cost SLA is sufficient for normal office traffic, while during the early morning hours (e.g., 02:00 to 06:00) a high-bandwidth, low-latency SLA is required for massive data transmission such as scientific computing. This document presents a framework for time-scheduled Color based SR Policy selection. The mechanism allows the egress PE to advertise multiple (Color, Color Schedule) pairs for the same VPN routes, enabling the ingress PE to select the appropriate SR Policy based on the current time. The time-to-Color mapping is configured per VPN instance (VRF/VSI), so each customer can have an independent time-varying SLA policy. This document is an Informational framework that describes the problem and the overall architecture. The advantages of the proposed mechanism and the comparison with alternative approaches are provided in Appendix A. The normative specifications of the protocol extensions, data models, and other components are described in Appendix B. |
| | Headend Behavior for Time-Scheduled Color based SR Policy Selection |
| |
|
This document specifies the normative behavior of the ingress Provider Edge (PE) router (headend) when selecting a Segment Routing (SR) Policy for VPN traffic based on time-scheduled Color values. In the time-scheduled Color mechanism, the egress PE advertises multiple (Color, Schedule) groups for the same VPN routes. The headend evaluates the schedule associated with each Color based on the current time, selects a currently valid Color, and steers the traffic into the corresponding SR Policy. This document defines the requirements for parsing the Color and Schedule Extended Communities, evaluating schedule validity, selecting among multiple valid Colors, performing schedule-boundary timer-based re-evaluation, handling switchover with make-before- break, and falling back when no Color is valid. This document updates RFC 9256 by replacing the multiple-Color selection rule specified in Section 8.4.1 with a Schedule-based selection rule. |
| | BGP Extension for Time-Scheduled Color based SR Policy Selection |
| |
|
Segment Routing (SR) Policy is identified by a tuple of Color and Endpoint. In BGP/MPLS IP VPN and EVPN services, the egress PE attaches a Color Extended Community to the advertised VPN route so that the ingress PE can steer the traffic into a corresponding SR Policy. In many deployment scenarios, the same customer may require different Service Level Agreements (SLAs) during different time periods of a day. For example, a customer may require a high- bandwidth SLA during the off-peak hours (e.g., 02:00-06:00) and a low-cost SLA during the daytime. Such time-variant SLA requirements imply that the ingress PE should select different SR Policies (i.e., different Colors) for the same VPN route at different times. This document defines a new BGP Extended Community, called the Schedule Extended Community, to be used together with the Color Extended Community. Two sub-types of the Schedule Extended Community are defined: a Daily Schedule sub-type for recurring time-of-day periods, and a Day Schedule sub-type for specific dates. The Schedule Extended Community carries the time period during which the associated Color is valid. Based on the current time and the received Schedule Extended Communities, the ingress PE can dynamically select the appropriate SR Policy for a VPN route, thereby realizing time-scheduled SLA switching. |
| | When Attestation Is Not Enough: Execution Finality for High-Assurance Resource Transitions |
| |
|
Modern infrastructure increasingly allows memory, accelerators, device interfaces, storage regions, and other resources to move dynamically between hosts, tenants, virtual machines, and security domains. Existing mechanisms can authenticate devices, attest software and firmware state, protect communication, and authorize resource operations. However, these properties do not necessarily establish that the exact resource transition that becomes effective is still the transition that was evaluated and authorized. This distinction becomes security-critical when a change in addressability, ownership, routing, or device assignment itself exposes protected state. For example, a dynamically reassigned memory extent may become accessible to a new tenant even though the device is authentic and the transport is protected, if sanitization, ownership state, allocation generation, destination binding, or other required conditions are no longer valid at the moment of reassignment. This document describes an execution-finality model in which a proposed transition remains non-effective until a protected enforcement boundary verifies the concrete operation immediately before effectuation. Authorization is bound to the exact resource, source, destination, generation, security state, freshness conditions, and required preconditions, with replay and alternate- path protections. The problem is particularly relevant to high-assurance AI and composable-compute environments, including NVIDIA NVLink-based confidential multi-GPU systems, Arm Confidential Compute Architecture (CCA) and Realm Management Extension (RME) systems, UALink accelerator fabrics, CXL pooled-memory systems, and confidential- computing deployments operated by cloud providers. These names identify published industry directions and alignment points; they are not assertions that any named implementation is vulnerable or non- conformant. The model complements attestation, confidential computing, secure transport, and device-assignment mechanisms rather than replacing them. Its central security invariant is that a trusted component does not, by itself, imply a trusted transition. |
| | Agent Operation Continuity Across Executor Replacement |
| |
|
An agent executor can fail or be replaced after a consequential provider request may have crossed an effect boundary but before the outcome is known. Native authorization, succession, evidence- boundary, and bounded-capability mechanisms address parts of this interval, but they do not by themselves define how a replacement executor preserves the same provider operation and its unresolved evidence. This document defines a composition profile for one authoritative coordination domain. The profile preserves stable operation- occurrence identity, immutable provider bindings, authority accounting, uncertain evidence, and stale-executor fences across replacement. It defines no new receipt, identity, authority, provider, or ledger-migration format, and it does not require any particular evidence envelope. |
| | Updates to IPv6 Default Address Selection |
| |
|
This document updates RFC 6724 with three improvements to IPv6 destination address selection. The updates allow recent IPv6 connection or service failures to influence IPv6/IPv4 ordering, incorporate likely source/destination address pairs when sorting candidates, and let ISP and enterprise operators preserve DNS load- balancing order where Rule 9 would otherwise override it. The updates are intended to be implementable inside getaddrinfo() or an equivalent system mechanism, without requiring changes to existing application-facing socket APIs. |
| | Cache Signaling for Media over QUIC Transport |
| |
|
This document defines optional hop-by-hop cache signaling for Media over QUIC Transport (MOQT). A subscriber can query the cache status of a finite Track range or request the cache status of a FETCH. Responses report a hit, miss, or partial hit and can identify locally cached ranges. |
| | Atomic Subscription Bundles for Media over QUIC Transport |
| |
|
This document defines a Media over QUIC Transport (MOQT) extension for atomically changing the Forward State of a set of established subscriptions. It allows a subscriber to replace one set of Tracks with another without an intermediate partially switched state at its peer. |
| | Contestability Binding Application Profile 1 (CBAP-1) |
| |
|
Signed authorization records can show that an action was authorized under specified rules, but they do not by themselves establish a stable or verifiable path for an Affected Party to contest that action. This document defines Contestability Binding Application Profile 1 (CBAP-1), a closed application profile that binds an Authorization Artifact to signed contestation terms before execution. CBAP-1 specifies deterministic CBOR and COSE encoding, fixed artifact formats, executor-verification and execution records, by-value policy material, a half-open filing window, a closed structured result, and deterministic first-failure reason codes. CBAP-1 does not define contestation notices, active execution-state effects, network reachability checks, policy-freshness evaluation, dispute adjudication, or remedy. It reports authenticated protocol facts and signed claims without asserting forum independence, legal validity, physical execution order, or fairness. |
| | When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary |
| |
|
Security decisions are frequently made against mutable state. An authorization decision may depend on a policy bundle, mapping table, reference-value set, ownership record, revocation state, risk classification, purpose grant, account state, or other data that can change between evaluation and effectuation. A cryptographically authentic permit can therefore remain valid as an object while becoming stale as authority. Existing freshness, replay-protection, sender-constraining, attestation, and anti-rollback mechanisms solve important parts of this problem. They do not by themselves establish that the exact policy and state basis used to approve an act is still the applicable basis when that act becomes externally effective. This document describes a state- and policy-continuity model for execution finality. A Candidate Act remains non-effective until a protected Finality Sink verifies the concrete act, the identity of the evaluated policy or mapping content, protected generations or epochs, relevant mutable state, freshness, and authorized-use constraints immediately before effectuation. The model treats revision identity as content-bound rather than merely name- or location-bound. A change from one mapping or policy revision to another is a state transition that requires re-evaluation unless an authoritative mechanism explicitly establishes applicability across revisions. The Finality Sink is not expected to infer semantic equivalence dynamically. The model complements, rather than replaces, mechanisms such as RATS, Entity Attestation Tokens, SUIT anti-rollback controls, OAuth fine- grained authorization, sender-constrained tokens, and application policy engines. Its central invariant is that authorization valid at evaluation time is not automatically authority at effectuation time. The problem is industrially relevant to systems that already combine continuously evaluated access, fine-grained policy decisions, attestation, and confidential computing. Examples of complementary industry directions include Microsoft Entra Continuous Access Evaluation, Amazon Verified Permissions and Cedar, Google Cloud IAM policy enforcement, NVIDIA GPU and switch attestation, and Arm Confidential Compute Architecture. These names identify useful integration and comparison points; they are not assertions of vulnerability, deficiency, non-conformance, or endorsement by any named organization. |
| | Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation |
| |
|
Revocation is often treated as a property of a credential, token, session, grant, policy, or identity record. In consequence-bearing systems, however, an authorization can be completely legitimate when issued and still become unsafe before the authorized operation becomes externally effective. The security question is therefore not only whether revocation exists, but whether a revocation that becomes authoritative before a protected commit is guaranteed to control that commit. The severity is deployment- dependent, but can be high in financial, administrative, AI-agent, cloud-control, confidential- compute, device, industrial, or other environments where a stale-but- valid authorization can produce an irreversible or externally consequential effect. This document describes a finality-bound revocation model. A Candidate Act remains in a Non-Effective State after upstream authorization. The authorization is bound to an act-specific revocation basis, such as a protected revocation generation, epoch, status root, or equivalent authority state. Immediately before the protected consequence is committed, a Finality Sink verifies that no applicable revocation, suspension, narrowing, or superseding authorization state has become load-bearing. Where the revocation state changed, the act is rejected, re-authorized, or explicitly shown to survive the change under an authoritative rule. With authoritative current state, atomic check-and-commit semantics, and complete mediation of all effectuation paths, this is intended as a prevention property for the protected stale act; deployments that permit bounded staleness or incomplete path coverage obtain mitigation rather than the same prevention guarantee. The model complements existing mechanisms rather than replacing them. OAuth Token Revocation [RFC7009] and Token Introspection [RFC7662] provide standardized token-state mechanisms; Microsoft Entra Continuous Access Evaluation [MS-CAE] demonstrates event-driven rejection of otherwise unexpired tokens; Amazon Verified Permissions and Cedar [AWS-VERIFIED-PERMISSIONS] provide fine-grained policy- evaluation mechanisms; Google Cloud IAM [GOOGLE-IAM-DENY] provides centrally managed deny-policy controls; and confidential-computing and attestation platforms such as NVIDIA attestation [NVIDIA-ATTEST] and Arm CCA [ARM-CCA] can provide protected execution and trust inputs. These technologies are cited as industrial alignment and integration points, not as assertions of vulnerability, deficiency, non-conformance, affiliation, or endorsement. The proposed delta is an effectuation-bound invariant: if revocation becomes authoritative before an act crosses the protected effectuation boundary, a previously valid permit must not remain sufficient merely because its signature, expiry, sender constraint, earlier authorization decision, or cached status result is still valid. The document therefore focuses on the ordering and binding between revocation state and the exact protected commit, including queued work, multi-hop delegation, alternate effectuation paths, rollback, crash recovery, and TOCTOU races. The document asks the IETF community whether existing standards or deployed mechanisms already provide this invariant in full, where the correct effectuation boundary lies, and what interoperability work, if any, is justified. Criticism, corrections, counterexamples, implementation experience, and pointers to existing equivalent mechanisms are explicitly invited. |
| | When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality |
| |
|
A perfectly correct authorization or security gate does not prevent a protected consequence if the same effect remains technically reachable through another path. High-consequence systems commonly place authentication, authorization, policy, attestation, or execution-finality checks at identified API, gateway, Resource Server, operating-system, service-perimeter, or hardware boundaries. The vulnerability examined here is therefore a coverage failure: the protected gate can be sound while the effect can go around it. This deserves high attention where the bypass can produce irreversible, financial, safety-relevant, privacy-sensitive, sovereign, or mission- critical consequences. Existing security architecture already addresses important parts of this problem. The reference-monitor concept requires complete mediation, tamper resistance, and verifiability; OAuth Resource Servers validate authorization for requests they receive; gateways, service meshes, cloud policy systems, and service perimeters mediate configured flows; RATS provides trust evidence for components; and confidential-computing or hardware isolation can provide protected enforcement locations. If any existing mechanism actually mediates every route capable of producing the defined consequence under the stated threat model, that deployment already satisfies the core property described here and no additional component is required merely for duplication. The residual problem arises when enforcement coverage is narrower than the consequence: for example, when an approved API hands work to a queue or database with other ingress paths, a service perimeter covers selected services while another interface remains effect- capable, or a software gate coexists with administrative, recovery, device, DMA, storage, or management-plane routes. This document introduces a consequence-oriented execution-finality formulation: a Protected Consequence K, an Effectuation Domain D, a generation- indexed directed Effectuation Graph G_g, an Effectuation Path Set P_g(K,D), a Finality Cut Set F, and a protected Path-Set Generation g. Prevention is claimed only when removal of the valid enforcement set F disconnects every admissible source from the consequence node, every member of F enforces an equivalent load-bearing finality predicate, and topology changes cannot silently inherit an older completeness claim. Where path discovery is incomplete, enforcement is bypassable, topology state is stale, or only selected interfaces are covered, the mechanism is mitigation or detection rather than the same prevention guarantee. The model is relevant to AI-agent tool execution, cloud authorization, service meshes, financial and database commits, operating-system and device actions, confidential computing, accelerator/DPU/SmartNIC infrastructure, and industrial control. Microsoft Azure Policy, Amazon Verified Permissions/Cedar, Google Cloud VPC Service Controls, NVIDIA attestation, and Arm CCA are cited only as complementary industrial comparison or integration points, not as assertions of vulnerability, deficiency, non-conformance, affiliation, or endorsement. The proposed delta is not invention of complete mediation. It is an explicit, testable mapping of complete-mediation reasoning to a protected consequence across heterogeneous distributed software and hardware paths, with coverage bound to a topology generation and to effectuation-time finality. Criticism, corrections, counterexamples, prior-art pointers, evidence of equivalent existing mechanisms, and cases where path completeness cannot be established at acceptable cost are explicitly invited. |
| | Trust Me,I Checked: Verifiable Third-Party Decision Binding at the Execution-Finality Boundary |
| |
|
High-consequence distributed systems frequently allow one component to act based on a decision produced by another component, such as an authorization server, policy engine, risk service, attestation Verifier, compliance service, workload-identity authority, or safety controller. The vulnerability is not limited to forged credentials: a compromised or incorrectly designed intermediary can claim that a required third-party check succeeded, replay an earlier decision, substitute evidence from a different act or context, suppress a required DENY, or retain evidence only for audit while the protected effect remains technically independent of that evidence. The issue deserves high attention where the downstream consequence is financial, administrative, privacy-sensitive, safety-relevant, infrastructure-changing, or otherwise difficult to reverse. Existing mechanisms solve important parts of this problem. OAuth Token Introspection [RFC7662] lets a protected resource query token state; HTTP Message Signatures [RFC9421] provide integrity and authenticity for selected HTTP message components; RATS [RFC9334] provides Evidence, Verifiers, and Attestation Results; Transaction Tokens [TXN-TOKENS] propagate identity and authorization context through trusted call chains; SCITT [RFC9943] provides signed statements, transparency, and verifiable receipts; and current authorization- evidence work [MUNOZ-EVIDENCE] [MUNOZ-SCITT] defines signed pre-execution Permits bound to canonical request material. Where one of these mechanisms is verified by the actual non- bypassable effectuation boundary and already proves the required decision for the exact act, current context, and authorized use, that deployment can already satisfy the property described here. The residual gap arises only where the consequential component receives an upstream claim such as "the external check passed", where authentic evidence is bound to the wrong act, authority, tenant, purpose, generation, or sink, where valid evidence has become stale or replayable, where only a subset of required authorities is represented, or where evidence exists but is not a load-bearing prerequisite of effectuation. This document introduces an architectural role called External Decision Evidence (EDE). EDE is not a new wire format: an existing Permit, SCITT statement or receipt, Attestation Result, live authenticated decision response, or other protected result can instantiate EDE when its semantics satisfy the deployment profile. The proposed invariant is that a Candidate Act remains non-effective until the Finality Sink independently establishes that every required external decision authority issued an applicable decision for the concrete act, under the required decision basis and current state, with freshness, audience or sink binding, and authorized-use semantics appropriate to the deployment. Prevention is claimed only when the protected consequence cannot occur without successful verification of the required evidence and alternate effectuation paths cannot bypass that verification. Otherwise the mechanism provides auditability, accountability, detection, or mitigation rather than the same prevention guarantee. The model is intended to complement, not criticize or replace, OAuth, WIMSE, SCITT, RATS, externalized policy systems such as Amazon Verified Permissions/Cedar, continuous-access systems such as Microsoft Entra Continuous Access Evaluation, Google Cloud IAM controls, and protected-compute technologies such as NVIDIA attestation and Arm CCA. The proposed delta is not the invention of signatures, authorization evidence, receipts, or attestation results; it is the effectuation-time requirement that independently verifiable required decisions become load-bearing for the exact protected act. Criticism, corrections, counterexamples, implementation experience, prior-art pointers, and evidence that existing mechanisms already provide the full invariant are explicitly invited. |
| | AI Audit Reference Architecture for Post-Hoc Agent Accountability |
| |
|
This document defines a reference architecture for producing, protecting, and verifying post-hoc accountability records for the actions of autonomous and semi-autonomous software agents. It is scoped exclusively to post-hoc accountability, as distinct from real- time enforcement, and elaborates rather than replaces the role and record-type model described in an existing individual submission on auditing agent delegation and interactions. It defines seven ordered stages -- intent and mandate capture, the agent boundary, the record producer, the event log and its cryptographic anchoring, a composed trust fabric, the disclosed audit record, and third-party verification -- together with two branch conditions covering cross- principal transactions and external resource ingestion. |
| | Authorized Here,Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems |
| |
|
Modern cloud, AI, financial, telecom, and critical-infrastructure systems increasingly operate across regions, sovereign clouds, multi- cloud environments, and distributed workload chains. A high- consequence authorization failure can occur even when identity, cryptography, policy evaluation, and platform attestation all succeed: the same Candidate Act can become effective under a jurisdictional or governance context different from the one under which it was authorized. Workload migration, disaster-recovery failover, cross-region queues, service rerouting, remote administration, control-plane changes, destination substitution, key- control changes, or downstream processing can convert an authorization that was valid under context J1 into an effect occurring under context J2. No token forgery or cryptographic break is required. Existing mechanisms already address important parts of this problem. OAuth Rich Authorization Requests [RFC9396] can carry fine-grained authorization details; OAuth Resource Indicators [RFC8707] bind authorization requests to protected resources; JWT [RFC7519] can carry signed application claims; WIMSE [WIMSE-ARCH] provides workload-identity and security-context architecture for multi-system environments; RATS [RFC9334] provides Evidence, Verifiers, and Attestation Results; and SCITT [RFC9943] provides signed statements, transparency, and receipts. Industry systems also provide concrete sovereignty and data-boundary controls: Microsoft documents its EU Data Boundary [MS-EUDB], AWS operates the European Sovereign Cloud [AWS-ESC], and Google Cloud provides Sovereign Controls by Partners [GOOGLE-SOV]. The residual gap exists only where jurisdiction is treated as descriptive metadata, inferred from weak location signals, enforced only at deployment time, or checked at an upstream boundary while the actual consequence can later move through another region, operator, administrative path, processing service, destination, failover route, or control domain. A workload can be correctly authenticated and a platform correctly attested while the current effectuation context no longer satisfies the deployment's sovereignty rule. Likewise, storing data in one region does not by itself prove where it is processed, remotely administered, decrypted, transmitted, or finally disclosed. This document proposes a jurisdiction-bound execution-finality invariant. A Candidate Act remains in a Non-Effective State until the Finality Sink establishes a current, authoritative Jurisdiction Execution Context (JEC) for the exact act and verifies that the present effectuation environment satisfies the deployment-defined Jurisdiction Policy. The JEC can combine workload identity, compute and processing domain, storage location, destination, operator/ control domain, key-control domain, remote-access state, attested trust state, and policy generation. JEC is an architectural role, not a mandated token format. Prevention is claimed only when the jurisdiction policy, evidence sources, current effectuation context, exact-act binding, state continuity, and consequence path are load-bearing and non-bypassable. If the deployment relies only on GeoIP, region labels, advisory metadata, best-effort routing, post-hoc audit, or incomplete path coverage, the result is mitigation or evidence rather than the same prevention guarantee. The architecture enforces machine-readable jurisdiction or compliance policy supplied by an authoritative deployment source; it does not determine what law applies or provide a legal conclusion. Microsoft, AWS, Google Cloud, NVIDIA, and Arm are discussed only as complementary industrial examples or potential integration points. The document does not assert vulnerability, deficiency, non- conformance, affiliation, or endorsement by any named organization. A deployment that already makes its required jurisdictional constraints current, non-bypassable, and mandatory at the actual consequence boundary already satisfies the core property. Criticism, corrections, counterexamples, prior-art pointers, implementation experience, and evidence of equivalent existing mechanisms are explicitly invited. |
| | Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems |
| |
|
Cyber-physical and industrial systems increasingly accept commands from cloud services, AI agents, remote operators, enterprise applications, and distributed control software. A high-consequence failure can occur even when identity, authorization, message integrity, platform attestation, and functional-safety mechanisms are individually correct: a digitally valid command can remain apparently acceptable while the target actuator, command parameters, machine mode, process state, safety/interlock state, authority state, or effectuation path has changed. The consequence is no longer merely an incorrect API call. It can be drive energization, robotic motion, valve or pump actuation, material release, process transition, or another physical effect. No token forgery, cryptographic break, or defeat of the safety protocol is necessarily required; the failure can be a loss of continuity between earlier digital authority and the exact physical act that becomes effective. Existing industrial mechanisms already solve major parts of this problem. IEC 61508 and IEC 61511 define mature functional-safety engineering and Safety Instrumented Systems; IEC 62443 defines cybersecurity requirements for industrial automation and control components; OPC UA provides industrial security mechanisms, while OPC UA Safety defines a functional-safety communication layer; ACE-OAuth [RFC9200] provides authorization for constrained IoT environments; RATS [RFC9334] provides trusted platform Evidence and Attestation Results; and existing safety PLCs/controllers from Siemens, Rockwell Automation, Schneider Electric, ABB, and other vendors provide mature safety logic and output control. These are complementary precedents, not examples of missing safety engineering. Where an existing safety controller or protected actuator boundary already makes exact command authority, current safety/process state, and final output mediation non-bypassable, that deployment already satisfies the core property described here. The residual gap exists only where one of those mechanisms stops at a boundary upstream of the first physical effect or does not carry the complete cyber-authority predicate required by the deployment. IEC functional-safety mechanisms can correctly enforce safety functions without necessarily expressing the provenance and exact scope of an AI-, cloud-, or enterprise-originated command. IEC 62443 controls can correctly protect identity, use, integrity, and information flow without by themselves defining the final application's exact actuation predicate. OPC UA Safety can correctly deliver SafetyData while the receiving safety application still determines whether a cyber-originated act is applicable. ACE can correctly authorize a constrained resource while current machine/process/safety state may be evaluated later. RATS can correctly attest the controller while platform trust is not authorization for a particular torque, motion, valve transition, or output. Current application-layer action- evidence work [SOKOLOV-AEP] can strengthen accountability while remaining distinct from pre-actuation non-completability. If any existing deployment already composes these properties at the true output boundary, no residual gap remains for that deployment. This document therefore proposes a narrower actuation-bound execution-finality invariant. A Candidate Act remains in a Non- Effective State until a protected Actuation Finality Boundary (AFB) verifies the exact pending command, current execution authority, target actuator identity, freshness and replay state, required current machine/process/safety predicates, and authorized effectuation path immediately before or atomically with the physical output becoming effective. The AFB is an architectural role, not a mandatory new appliance: an existing safety PLC, safety controller, protected drive, robot controller, SIS function, secure I/O stage, or device controller can already be the AFB when it enforces the required invariant. Prevention is claimed only where the protected physical effect cannot occur without those checks and where existing functional-safety controls remain authoritative rather than being bypassed or replaced. Execution-finality logic MUST NOT convert an existing safety DENY into ALLOW. If enforcement is upstream-only, mutable context is stale, path coverage is incomplete, or the mechanism merely records what occurred, the result is mitigation, detection, or auditability rather than the same prevention guarantee. The architecture complements functional safety; it does not replace hazard analysis, define a safe state, certify an unsafe controller, or claim that an IETF mechanism establishes SIL or PL. The problem is industrially relevant to robotics and motion control, process plants, manufacturing and warehouse automation, power and critical infrastructure, and other systems where remote or AI- generated commands can cross several cyber layers before becoming physical. Siemens Safety Integrated, Rockwell GuardLogix, Schneider Electric Modicon M580 Safety, ABB AC500-S, and OPC UA Safety are cited politely as mature safety precedents and potential integration points. No vulnerability, deficiency, non-conformance, affiliation, or endorsement is asserted. Criticism, corrections, counterexamples, prior art, real-time implementation experience, and evidence that existing safety or authorization mechanisms already provide the full invariant are explicitly invited. |
| | Persistent Symmetric Keys in OpenPGP |
| |
|
This document defines a new packet and algorithm for the OpenPGP standard (RFC 9580) to support persistent symmetric keys, for message encryption using authenticated encryption with additional data (AEAD) and for message authentication using AEAD authentication tags. This enables the use of symmetric cryptography for data storage (and other contexts that do not require asymmetric cryptography), for improved performance, smaller keys, and improved resistance to quantum computing. |
| | A Simple BGP-based Mobile Routing System for the Aeronautical Telecommunications Network |
| |
| | draft-ietf-rtgwg-atn-bgp-33.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Fred Templin, Greg Saccone, Gaurav Dawra, Acee Lindem, Victor Moreno |
| | Working Group: |
Routing Area Working Group (rtgwg) |
|
The International Civil Aviation Organization (ICAO) is investigating mobile routing solutions for a worldwide Aeronautical Telecommunications Network with Internet Protocol Services (ATN/IPS). The ATN/IPS will eventually augment existing communication services with an IP-based service supporting pervasive Air Traffic Management (ATM) for Air Traffic Controllers (ATC), Airline Operations Controllers (AOC), and all commercial aircraft worldwide. This informational document describes a simple and extensible mobile routing service based on the industry-standard Border Gateway Protocol (BGP) and Domain Name System (DNS) to address the ATN/IPS requirements. |
| | Secure Asset Transfer (SAT) Interoperability Architecture |
| |
| | draft-ietf-satp-architecture-10.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Thomas Hardjono, Martin Hargreaves, Ned Smith, Venkatraman Ramakrishna |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document proposes an interoperability architecture for the secure transfer of assets between two networks or systems based on the gateway model. |
| | Security Goals and Use Cases for Integrating Remote Attestation with Secure Channel Protocols |
| |
|
This document outlines desirable security goals and use cases for integrating remote attestation (RA) capabilities with secure channel establishment protocols (e.g., TLS and DTLS). Peer authentication in such protocols establishes trust in a peer's network identifiers but provides no assurance regarding the integrity of its underlying software and hardware stack. Remote attestation addresses this gap by enabling a peer to provide verifiable evidence about the current state of the Target Environment. This document specifies a set of essential security goals the protocol solution must have, including cryptographic binding to the secure connection, evidence freshness, and flexibility to support different attestation models. It then explores relevant use cases, such as confidential data collaboration and secure secrets provisioning, to motivate the need for this integration. This document is intended to serve as an input to the design of protocol solutions within the SEAT working group. |
| | Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services |
| |
|
This document describes best current practices for operating an RFC 8181 (A Publication Protocol for the Resource Public Key Infrastructure (RPKI)) publication engine and its associated publicly accessible rsync (RFC 5781) and RPKI Repository Delta Protocol (RRDP) (RFC 8182) repositories. |
| | AI Identity Management System |
| |
| | draft-ietf-wimse-aims-00.txt |
| | Date: |
15/09/2026 |
| | Authors: |
Pieter Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell, Nick Steele, Aaron Parecki |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
This document proposes best practices for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. |
| |
|
| |
| | Semantic Definition Format (SDF) Modeling for Digital Twin |
| |
| | draft-ietf-asdf-digital-twin-05.txt |
| | Date: |
14/09/2026 |
| | Authors: |
Hyunjeong Lee, Jungha Hong |
| | Working Group: |
A Semantic Definition Format for Data and Interactions of Things (asdf) |
|
This memo specifies SDF modeling for digital twins, i.e., digital twin systems, and their things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of things, i.e. physical objects, in digital twins that contain things as components. |
| | RTP Payload Format for ISO/IEC 21122 (JPEG XS) |
| |
|
This document specifies a Real-Time Transport Protocol (RTP) payload format for transport of a video signal encoded with JPEG XS (ISO/IEC 21122). JPEG XS is a low-latency and low-complexity video coding system. Employing this format allows achieving encoding-decoding latencies confined to a fraction of a video frame. This document revises RFC 9134 to incorporate support for new features introduced in the third edition of JPEG XS. Most notably, it contains the necessary provisions to support the TDC coding mode. This document obsoletes RFC 9134; however, the revised payload format is designed to ensure that existing conforming implementations of RFC 9134 remain valid under the updated specification. Additionally, this document consolidates the errata of RFC 9134 and includes improvements and clarifications for implementers and users. |
| | EVPN multi-homing support for L3 services |
| |
|
This document describes the use of EVPN Ethernet Segment Link Aggregation Group (ES-LAG) technology to provide multi-homing redundancy for Layer 3 services. The solution synchronizes ARP/ND, multicast state, and IGP routes between redundant PEs without requiring Layer 2 constructs or proprietary Inter-Chassis Communication protocols. |
| | Benchmarking Methodology for Intra-domain and Inter-domain Source Address Validation |
| |
|
This document defines methodologies for benchmarking the performance of intra-domain and inter-domain source address validation (SAV) mechanisms. SAV mechanisms are utilized to generate SAV rules that prevent source address spoofing. The methodology treats a SAV device as a black box and is therefore agnostic to the specific SAV mechanism and implementation used by the device. This document defines test setups, performance indicators, and test cases for SAV accuracy, control-plane and data-plane performance, and resource utilization. |
| | JSCalendar 2.0: A JSON Representation of Calendar Data |
| |
|
This specification defines version "2.0" of JSCalendar, a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. This document obsoletes RFC 8984, also referred to as version "1.0" in this document. The newly defined version "2.0" aims to improve interoperability with existing iCalendar-based systems. It also aligns its definitions with JSContact, such as the IANA registry policy, validation requirements, and versioning scheme. |
| | Conditional Query Parameters for CoAP Observe |
| |
|
This specification defines Conditional Notification and Control Query Parameters compatible with CoAP Observe (RFC7641). |
| | Requirements for Scaling Deterministic Networks |
| |
|
To support the scaling of deterministic networks, this document describes the technical and operational requirements for networks that exhibit large hop-to-hop latency variation, a large number of flows, and/or multiple domains that do not share a common time source. Applications with varying levels of determinism coexist and are transported in such a network. This document also describes the corresponding Deterministic Networking (DetNet) data plane enhancement requirements. |
| | BGP Bestpath Selection Criteria Enhancement |
| |
|
BGP specification (RFC4271) prescribes 'BGP next-hop reachability' as one of the key 'Route Resolvability Condition' that must be satisfied before the BGP bestpath candidate selection. This condition, however, may not be sufficient (as explained in the Appendix section) and would desire further granularity. This document defines enhances the "Route Resolvability Condition" to facilitate the next-hop to be resolved in the chosen data plane. |
| | Best Practices for Signed Attributes in CMS SignedData |
| |
|
The Cryptographic Message Syntax (CMS) has different signature verification behaviour based on whether signed attributes are present or not. This results in a potential existential forgery vulnerability in CMS and protocols which use CMS. This document describes the vulnerability and lists mitigations and best practices to avoid it. This document updates RFC 5652 by prohibiting the use of the id-data content type for new uses of the CMS SignedData type. |
| | Personal Data Portability Archive |
| |
|
This document proposes the Personal Data Portability Archive format (PDPA), suitable for import/export, backup/restore, and data transfer scenarios for personal data. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible Notification structure, defined in YANG, for use in YANG-Push Notification messages, both for NETCONF and RESTCONF, enabling any YANG-compatible encodings such as XML, JSON, or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the data was observed. |
| | Network File System (NFS) Version 4 Minor Version 1 Protocol |
| |
|
This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made and part of Minor Version 1. The later minor version has no dependencies on NFS version 4 minor version 0, and was, until recently, documented as a completely separate protocol. This document is part of a set of documents which collectively obsolete RFCs 8881 and 8434. In addition to many corrections and clarifications, it will rely on NFSv4-wide documents to substantially revise the treatment of protocol extension, internationalization, and security, superseding the descriptions of those aspects of the protocol appearing in RFCs 5661 and 8881. |
| | ACLs within the NFSv4 Protocols |
| |
|
This document is part of the set of documents intended to update the description of NFSv4 Minor Version One as part of the rfc8881bis respecification effort for NFSv4.1. It describes the structure and function of NFSv4 Access Control Lists within NFSv4.0 and NFSv4.1. These minor versions and forthcoming ones define ACLs using an ACL structure derived from Windows ACLs. Support for other ACL approaches such as draft-POSIX ACLs remains an option that could be taken advantage of in later minor versions such as NFSv4.2. This document describes the structure of these Windows-derived NFSv4 ACLs and their role in the NFSv4 security architecture. While the focus of this document is on the role of these ACLs in providing a more flexible approach to file access authorization than is made available by the POSIX-derived authorization-related attributes, the potential provision of other security-related functionality based on ACLs is covered as well. Because of the failure of previous specifications to provide a satisfactory description of the authorization semantics of NFSv4 ACLs, this document takes a different approach to many matters while maintaining compatibility with implementations based on previous specifications. When the resulting document is eventually published as an RFC, it will supersede the descriptions of ACL structure and semantics appearing in existing minor version specification documents for NFSv4.0 and NFSv4.1, thereby updating RFC7530 and RFC8881. |
| | Flexicast QUIC: combining unicast and multicast in a single QUIC connection |
| |
|
This document proposes Flexicast QUIC, a simple extension to Multipath QUIC that enables a source to send the same information to a set of receivers using a combination of unicast paths and IP multicast distribution trees. |
| | Considerations of IPv6-only Deployment in 5G Mobile Networks |
| |
| | draft-ma-v6ops-5g-ipv6only-04.txt |
| | Date: |
14/09/2026 |
| | Authors: |
Chenhao Ma, Chongfeng Xie, Jordi Martinez, Ruoyu Zhao, Thomas Graf |
| | Working Group: |
Individual Submissions (none) |
|
This document describes a practical guide of deploying 464XLAT based IPv6-only technology on user plane in 3GPP 5G networks. It also covers key 5G concepts and architectures, configuration methods and operational challenges. |
| | ML-DSA for Web Authentication |
| |
|
This document describes implementation of Passwordless authentication in Web Authentication (WebAuthn) using Module-Lattice-Based Digital Signature Standard (ML-DSA), a Post-Quantum Cryptography (PQC) digital signature scheme defined in FIPS 204. |
| | DNS-Based Service Discovery for Encrypted DNS Services |
| |
| | draft-liu-add-dnssd-edns-03.txt |
| | Date: |
14/09/2026 |
| | Authors: |
Dongjie Liu, Zhiwei Yan, Guanggang Geng, Guoqiang Zeng |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a DNS-Based Service Discovery (DNS-SD) mechanism for discovering encrypted DNS services in local networks. It specifies new service types (_dot._tcp, _doh._tcp, _doq._udp) and associated service parameters to enable zero-configuration discovery of DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC (DoQ) resolvers. This mechanism is defined for use with multicast DNS (mDNS), addressing critical privacy gaps in local networks while maintaining backward compatibility with RFC 6763. This document leverages SVCB and HTTPS resource records (RFC 9460) for parameter negotiation, with TXT records provided for compatibility with legacy implementations. |
| | Operational Guidelines for RPKI Delegated Certification Authorities |
| |
|
This document provides operational guidelines for Resource Public Key Infrastructure (RPKI) delegated Certification Authorities (CAs) and registry operators managing such delegations. It addresses common operational issues including CA availability problems, publication quality issues, and lifecycle management. The guidelines aim to improve the overall health and efficiency of the RPKI ecosystem by establishing best practices for CA operations and delegation management. |
| | The Key List BGP Attribute for NLRI Error handling |
| |
|
RFC 7606 partially revises the error handling for BGP UPDATE messages. It reduces the cases of BGP session reset by defining and using less impactful error handling approaches, such as attribute discard and treat-as-withdraw when applicable. The treat-as-withdraw approach requires that the entire NLRI field of the MP_REACH_NLRI attribute be successfully parsed. This typically means parsing errors in MP_REACH_NLRI cannot be handled by any means short of session reset. This is exacerbated by the use of non-key data within NLRI, which introduces parsing complexity and additional error cases. This specification defines a non-transitive BGP attribute, the "NLRI_KEY_LIST attribute", to encode NLRIs as per the format of MP_UNREACH_NLRI. This attribute is used to allow the treat-as- withdraw error-handling approach to be used in case an error in the MP_REACH_NLRI attribute prevents the parsing of its NLRIs. This document updates RFC 7606 by mandating that the NLRI_KEY_LIST attribute appear before the MP_REACH_NLRI (or any other) attribute in an UPDATE message. |
| | Available Session Recovery Protocol |
| |
| | draft-cmcc-asrp-08.txt |
| | Date: |
14/09/2026 |
| | Authors: |
Zhaoyu Luo, Haishuang Yan |
| | Working Group: |
Individual Submissions (none) |
|
This document describes an experimental protocol named the Available Session Recovery Protocol (ASRP). The protocol is designed to optimize high-availability network cluster architectures, providing a superior high-availability solution for clusters offering stateful network services such as load balancing and Network Address Translation (NAT [RFC4787]). ASRP defines the procedures for session backup and recovery, as well as the message formats used during these interactions, enabling efficient and streamlined session state management. In contrast to traditional high-availability techniques that back up session state within the cluster itself, the core innovation of ASRP lies in its distributed backup of state information to the client or server side. This approach offers multiple advantages: theoretically unlimited elastic scaling capacity; support for rapid recovery from multi-point failures; reduction of resource redundancy through the elimination of centralized backup nodes; and significant simplification of cluster implementation complexity. The ASRP protocol provides a standardized method for constructing elastic service clusters, facilitating broader participation from software and hardware developers in building elastic cloud network service clusters. |
| | FideX Application Statement 5 (AS5) Protocol |
| |
|
This document specifies the FideX Protocol (AS5), a modern application-layer protocol for secure Business-to-Business (B2B) message exchange. FideX provides cryptographic non-repudiation, data integrity, and confidentiality using JOSE (JSON Object Signing and Encryption) over HTTPS, replacing legacy AS2 and AS4 standards with a REST-oriented approach accessible to modern web developers. FideX adopts the "AS" naming lineage: AS2 ([RFC4130]) used S/MIME over HTTP; AS4 ([OASIS-ebMS]) used SOAP/WS-Security; AS5 (FideX) uses REST/JSON/JOSE over HTTPS. This document defines the message format, cryptographic operations, partner discovery, state management, acknowledgment receipts (J-MDN), and error handling. |
| | Post-quantum hybrid ECDHE-MLKEM512 Key Agreement for TLSv1.3 |
| |
|
This document defines two post-quantum hybrid key exchange groups for TLS 1.3 that combine ML-KEM-512 with ECDHE: MLKEM512X25519 and SecP256r1MLKEM512. These groups provide lower-overhead hybrid key exchange options for deployments where ClientHello size, fragmentation risk, constrained-device performance, or compatibility with existing network infrastructure are important considerations. The groups defined in this document are intended for use with TLS 1.3 and DTLS 1.3 and follow the hybrid key exchange construction used by ECDHE-MLKEM key agreement for TLS 1.3. |
| | A SCITT Profile for Physical-Site Engagement Receipts |
| |
|
This document defines a SCITT profile for _Physical-Site Engagement Receipts_ (PSER): tamper-evident, signed, offline-verifiable records that describe an autonomous or human-directed physical engagement at a specific real-world site governed by a defined operating envelope. Each receipt is a SCITT Signed Statement as defined by the SCITT architecture, encoded as a COSE Single Signer message, carrying a JCS-canonicalized JSON payload with a five-artifact vocabulary describing (1) the _Site_, (2) the _Operator_ and _Actor_, (3) the _Engagement Window_ and _Envelope_, (4) the _Attestation Evidence_ from a Trusted Execution Environment (TEE), and (5) the _Adapter Write-In_ recording that the receipt was posted into an out-of-band operations layer. A Physical-Site Engagement Receipt is registerable in any conforming SCITT Transparency Service, obtaining a Receipt that proves the Statement's inclusion in that Service's verifiable data structure. Registration does not establish that the Issuer registered every receipt it issued. This profile deliberately makes a NARROW, checkable claim -- "this is a tamper-evident, signature-verifiable record that a specific engagement occurred at a specific site under a specific envelope, and its evidence was sealed by a specific TEE" -- and explicitly does NOT claim that the engagement was safe, correct, or wise, that the site conditions were as described, or that any downstream operational outcome followed. Compliance verdicts derived from the receipt (SLA credit, insurance underwriting, regulatory audit) are the responsibility of the relying party and its policies, not of this profile. The profile is designed around a three-party trust model in which no single party can unilaterally forge or repudiate a receipt: the _Site Owner_ controls physical access to the TEE hardware and keeps it running (they can unplug the box, and cannot forge what it signs); the _TEE silicon vendor_ attests the key material inside the TEE through its hardware root of trust (silicon vouches for the key); and the _Issuer_ writes the vocabulary, registers Signed Statements with a Transparency Service, and posts the resulting receipt into the site's operations layer via a WRITE_ONLY adapter. This separation is normative in this profile: implementations MUST NOT collapse these three roles into a single custodian, and relying parties MUST NOT trust a receipt that lacks any one of them. |
| | Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls |
| |
|
This document defines the Correctover Conformance Shape (CCS), a runtime verification framework for AI agent tool calls. CCS specifies seven verification dimensions (Structure, Schema, Latency, Cost, Identity, Integrity, Security) that tool calls and results must conform to at runtime. The framework defines a receipt format with Ed25519 signatures, three verdict values (allow, deny, escalate) and four executor lifecycle states (confirmed, dispatched, indeterminate, unknown), and normative requirements for implementations. This revision makes the document self-contained for publication: the related AEB and CAID specifications are reclassified as Informative References, and the native artifact requirements they motivate are restated normatively in this document so that no conformance requirement depends on an unreferenced work in progress. It also corrects the implementation-experience description (one reference implementation in two deployment forms, plus one independently developed third-party interoperability profile), clarifies the relationship to SCITT-based agent evidence work, and updates the author contact address. The detached Ed25519 signature construction over RFC 8785 canonical JSON and the receipt lifecycle and signing- algorithm conformance are unchanged from draft-08. |
| | The Session Recovery (SR) Option for TCP |
| |
|
This document defines the Session Recovery (SR) option for TCP. The option lets the endpoints of a connection exchange identifiers: during the handshake each endpoint carries its own identifier, and designated segments afterwards carry the identifier of the peer. This places the knowledge of which endpoint a connection belongs to inside the TCP header, where network functions on the path - load balancers, NAT gateways, firewalls - can read it without per-flow state and without payload inspection. The primary use is session recovery in SNAT and load-balancing clusters; further uses include reduced-state forwarding, connection-tracking recovery, and per- backend telemetry. The option is carried in the SYN, the SYN-ACK, and retransmitted segments, or in every segment when so configured; the default adds no overhead to normal data segments. Endpoints that do not support it behave as if the option did not exist. |
| | Execution-Finality Profiles for LEO/NTN Satellites,Orbital AI,Optical ISLs,Spacecraft Autonomy,and Cybersecurity |
| |
|
Satellite and non-terrestrial networks are becoming programmable compute, routing, sensing, radio, and AI infrastructures. In such systems, successful authentication, attestation, routing, scheduling, inference, fault recovery, or protocol processing does not necessarily establish authority for the resulting operation to become externally effective. This document describes an execution-finality architecture in which a consequence-bearing operation is represented as a Candidate Act and may remain in a Non-Effective State after computation. A Protected Enforcement Domain validates act-bound predicates and protected state, commits protected validation evidence, and permits release of scoped non-bearer authority. A Finality Sink at or before the relevant consequence boundary verifies that authority before an operation becomes routing-effective, radiative-effective, storage- effective, control-effective, disclosure-effective, or otherwise externally effective. Sixty satellite and NTN enforcement profiles are provided, covering orbital AI output release, model-state transfer, Earth observation, power- and thermal-bounded compute, radiation recovery, optical inter-satellite links, onboard gNB and user-plane functions, delay- tolerant delivery, emergency services, firmware and microcode activation, privileged maintenance, orbital maneuver and collision- avoidance authority, proximity operations, propulsion and attitude actuation, hosted-payload control, sensing activation, end-of-life decommissioning, manufacturing and launch-preparation component admission, and high-consequence command release. Each profile states a concrete problem space and the corresponding execution-finality solution. Publicly described work from SpaceX / Starlink, Blue Origin, Northrop Grumman / SpaceLogistics, Rocket Lab, Airbus Defence and Space, and Thales Alenia Space illustrates industry directions involving direct- to-device connectivity, optical inter-satellite networking, orbital mobility, hosted and software-defined payloads, onboard processing, rendezvous and proximity operations, and in-orbit servicing. These references identify technical complementarity and possible enforcement locations; they do not imply that any named organization has reviewed, endorsed, adopted, or lacks equivalent mechanisms. The proposal does not replace 3GPP NTN, IETF routing or Time-Variant Routing, DTN, RATS/attestation, ACE authorization, SUIT update mechanisms, optical-link protocols, spacecraft fault detection, isolation and recovery, or cryptographic authentication. Those mechanisms can provide inputs to the finality decision. The additional question is whether a specific Candidate Act is permitted to cross the boundary at which it first acquires external effect. Technical corrections and references to equivalent existing mechanisms are expressly invited. |
| | Securing the Enterprise Future: Technical Non-Joinability for Enterprise AI |
| |
|
Enterprise artificial-intelligence systems are increasingly connected to multiple organizational repositories, applications, tools, memory systems, and workflow interfaces. Representative industrial deployment classes include OpenAI ChatGPT and ChatGPT Work, Anthropic Claude, Google Gemini Enterprise, xAI Grok for Business, Microsoft Copilot and Copilot Studio, Amazon Q Business, Salesforce Agentforce, ServiceNow AI Agents, and comparable enterprise or privately deployed AI systems. These names are cited only as publicly described examples of the broader deployment class. Their inclusion does not assert that any named product implements, lacks, requires, infringes, endorses, or is vulnerable to the mechanisms described here, does not characterize undisclosed internal architectures, and does not imply that equivalent functionality is absent from an existing product or specification. The security problem considered here is not limited to theft of a pre-existing database. An enterprise-AI workload may be individually authorized to retrieve information from customer, engineering, financial, source-code, supplier, scheduling, communication, memory, and operational systems while the combination of those sources reveals a sensitive relationship or future enterprise state that no single repository contains. Conventional access control, encryption, network segmentation, database separation, confidential computing, and source-level authorization remain important, but storage separation alone does not prevent such reconstruction where the same effective authority can obtain the constituent values and freely resolve the relationships among them. The mechanism described here therefore separates not only protected data but also the authority required to create protected semantic relationships among that data. Identity components, substantive content, relationship-mapping information, reconstruction-enablement state, and authorization state may be maintained under independently controlled protection domains. A processing request establishes a bounded reconstruction authorization tied to the actual workload, execution context, session, permitted fields, permitted relationships, processing purpose, and output conditions. Each required protection domain independently determines whether its component may participate. Approved components may remain session bound, cryptographically wrapped, capability restricted, opaque, or accessible only through a mandatory mediated path. Only the specifically authorized relationships are resolved inside a protected reconstruction environment, which constructs a temporary minimum- necessary view without providing the AI workload with unrestricted authority over the underlying stores. This creates a technical distinction between authority to access information and authority to associate information. Access to an identity component and access to a content component do not, by themselves, authorize every relationship between them. The same distinction applies after computation: successful reconstruction, inference, or generation does not automatically authorize disclosure, persistence, transmission, tool invocation, database modification, payment, downstream-model use, or another external consequence. A resulting output or proposed act can remain technically non- releasable while current session, execution, association, provenance, destination, recipient, policy, revocation, and disclosure conditions are verified. Protected evidence of successful verification is committed before scoped release authority is created and checked at the actual consequence boundary. This document presents 79 Enforcement Profiles that apply the same underlying architecture to different enterprise-AI enforcement points, including multi-domain information separation, independent association authority, session-bound reconstruction, protected provenance, runtime behavioral verification, agentic tool invocation, prompt and input mediation, streaming disclosure, lifecycle restrictions, distributed policy enforcement, and multi-authority consequence control. Each profile is expressed in terms of the problem being addressed, the technical enforcement mechanism, and its relationship to existing technology so that the underlying engineering concept can be evaluated independently of specialized terminology. This document is related to the earlier [DAS-ENTERPRISE-OUTPUT], which introduced the broader enterprise-future-reconstruction threat, protected reconstruction, and output-finality architecture. The principal new contribution here is the systematic decomposition of that architecture into 79 concrete enforcement profiles, together with a more explicit treatment of Technical Non-Joinability as a separately enforceable property governing when independently accessible enterprise information may be semantically associated. The common engineering principle is that access to components is not necessarily authority to join them, and completion of computation is not necessarily authority to make the resulting consequence externally effective. |
| | Agent Authority Transition Receipts for Agentic Systems |
| |
|
Autonomous agents increasingly act across administrative and security domains using workload identities, OAuth credentials, delegated authorization, attestations, and policy engines. Existing mechanisms can establish identity, delegation, or access rights, but deployments still lack a common artifact that records which policy and which evidence were evaluated when an operation moved into an authorized, denied, revoked, or expired authority state. This document defines an Agent Authority Transition Receipt (AATR), a signed, non-bearer receipt that cryptographically binds an agent operation to the principal, policy, evidence set, decision, audience, validity interval, and predecessor authority state used for that decision. AATR intentionally separates evidence from authorization and authorization from execution. Missing or indeterminate required evidence fails closed. AATR is designed to compose with OAuth, workload identity, remote attestation, transparency services, and agent-specific delegation protocols rather than replace them. |
| | IPv6 Address Space for Space |
| |
|
Without a structured address allocation plan, early space missions risk creating an unaggregated patchwork of prefixes, repeating the historical operational scaling issues seen in terrestrial networks. This document requests that the IANA allocate address space specifically for use in space environments and manages suballocations from that block for and within celestial bodies, as needed. The Number Resource Organization (NRO) will determine how to allocate and assign address resources for and within the celestial bodies , with the understanding that topological address aggregation is critical for routing scalability and operational efficiency. |
| | A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests |
| |
|
This document defines two YANG data models to support scheduled network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam- test-sequence' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. |
| | Group Address Allocation Protocol (GAAP) |
| |
|
This document describes a design for a lightweight decentralized multicast group address allocation protocol (named GAAP and pronounced "gap" as in "mind the gap"). GAAP requires no centralized service or coordination for the address-allocation protocol itself, though it depends on ASM-capable multicast routing already being provisioned in the deployment domain, and deployments using encryption or administrative scoping may require additional configuration. The protocol runs among group participants which need a unique group address to send and receive multicast packets. Tailored for IPv4 and IPv6 networks, this design offers a simple, lightweight option rather than extending an existing protocol. This document is Experimental, see Section 8 for the rationale and the criteria for concluding the experiment. |
| | TLS Trust Anchor Identifiers |
| |
|
This document defines the TLS Trust Anchors extension, a mechanism for a TLS client or server to select a certificate to present based on the peer's trusted certification authorities. It describes certification authorities more succinctly than the TLS Certificate Authorities extension. |
| |
|
| |
| | A Vocabulary For Expressing AI Usage Preferences |
| |
|
This document defines a vocabulary for expressing preferences regarding how digital assets are used by automated processing systems. This vocabulary allows for the declaration of restrictions or permissions for use of digital assets by such systems. |
| | BGP-LS Extensions for Inter-AS Topology Retrieval |
| |
|
This document specifies the procedures for distributing Border Gateway Protocol-Link State (BGP-LS) key parameters for inter-domain links between two Autonomous Systems (ASes). It defines a new type within the BGP-LS Network Layer Reachability Information (NLRI) for an Inter-AS Link, along with three new Type-Length-Values (TLVs) descriptors for the BGP-LS Inter-AS Link. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the inter-AS topology using information provided by the BGP-LS protocol. |
| | Problems Statement and Requirements Analysis of DNS for Internet of Agents (IoA) |
| |
|
In the AI-driven era, DNS is supposed to evolve with technological advancements to accommodate the complex and diverse requirements of the IoA. This draft analyzes the issues surrounding DNS in supporting agents collaboration and explores corresponding technical requirements. |
| | Guidelines for Security Considerations of RATS |
| |
|
This document aims to provide guidelines and best practices for writing security considerations for technical specifications for RATS targeting the needs of implementers, researchers, and protocol designers. In particular, it discusses some of the 'bottom turtle' issues. This is a work-in-progress, and the current version mainly presents an outline of the topics that future versions will cover in more detail. * Corrections in published RATS RFCs * Security concerns in two RATS drafts * General security guidelines, baseline, or template for RATS |
| | HTTP Signature Keys |
| |
|
This document defines five HTTP header fields for use with HTTP Message Signatures as defined in RFC 9421. The Signature-Key request header distributes public keys used to verify signatures, with eight initial key distribution schemes: pseudonymous inline keys (hwk), self-issued key delegation via JWK Thumbprint JWTs (jkt-jwt), identified signers with JWKS URI discovery (jwks_uri), direct JWKS fetch (jwks), JWT-based delegation (jwt), self-issued JWTs (self- jwt), X.509 certificate chains (x509), and references to previously cached assertions (cached). The Accept-Signature-Scheme and Accept- Signature-Alg response headers state the schemes and algorithms a server accepts, so a client can select both before it signs. The Signature-Error response header provides structured error information when signature verification fails, and the Signature-Key-Cache response header issues a cache identifier by which a caller can reference a previously presented assertion instead of resending it. Together, these mechanisms enable flexible trust models ranging from privacy-preserving pseudonymous verification to horizontally-scalable delegated authentication and PKI-based identity chains. |
| | RDAP Extension for Structured Reliability Assessment Metadata |
| |
|
This document proposes an extension to the Registration Data Access Protocol (RDAP) that enables the representation and exchange of structured reliability assessment metadata for registrars and domain names. The extension defines a structured assessment envelope through which an RDAP server can expose assessment results produced by a registry, registrar, or third-party assessor in a common, machine-readable format within RDAP responses. The extension standardizes how assessment results are transported and referenced, not how they are computed. Scoring methodologies, thresholds, criteria, and governance frameworks are intentionally left to the operational and policy layer. This document does, however, place requirements on the specification of any scheme whose results are intended for publication through RDAP, because publishing an evaluative judgement about an identified party without safeguards for notification, remediation, and contestation is not a safe practice. |
| | Bilateral Attestation of Cross-Organization Agent Actions |
| |
|
When an agent operated by one organization requests a consequential action from an agent operated by another, today's record of that exchange — if one exists — is kept by one side, editable by that side, and deniable by the other. Disputes reduce to my-log-versus- your-log. This document describes a bilateral attestation exchange for such actions: the requesting organization signs a request attestation binding it to the action and its material terms; the performing organization evaluates the request against deterministic constraints at the boundary where the action takes effect and signs an action attestation recording the constraint results and the disposition — performed, declined, or escalated to a human — by reference to the request; and each party acknowledges the other's attestation. The combined record binds each organization to its part, gives each proof of the other's, and can be anchored to a transparency service so that a third party who trusts neither organization can verify the record end-to-end. The exchange records refusals with the same fidelity as performance, and degrades gracefully when a counterparty cannot attest, marking the record's reduced assurance rather than blocking the transaction. |
| | Simple Agent Management Protocol (SAMP) |
| |
|
The Simple Agent Management Protocol (SAMP) defines a lightweight management-plane protocol for heterogeneous AI agents. SAMP allows a management system to discover agents, query their state, receive events, subscribe to event streams, and optionally configure or execute explicitly exposed operations under policy control. SAMP is inspired by operational management protocols such as SNMP, but it is designed for AI-agent-specific concepts such as dynamic profiles, autonomy classes, enrollment, trust states, and policy- gated execution. It is not an agent-to-agent communication protocol, an agent tool-use protocol, or an agent framework specification. This document defines SAMP version 0.1 as an Experimental protocol suitable for controlled environments and independent interoperability testing. |
| | Conditional Range Filters for Media over QUIC Transport |
| |
|
In Media over QUIC Transport (MOQT), subscribers can use Range Filters to select specific subgroups, objects, or priorities within a subscribed track. However, these subscription filters are static once established and can only be modified through explicit subscriber control signaling. This document proposes an extension to the Range Filter design that binds conditional evaluation logic directly to specific Range Filter sets. By introducing dynamic conditions to Range Filter configurations, a relay can autonomously adapt the intra-track forwarding behavior based on real-time network conditions, avoiding the round-trip delay of explicit subscriber update signaling. |
| | An Execution-Finality Architecture Against Automated Extraction and Distillation of OpenAI and Anthropic Claude Model Information |
| |
|
High-capability AI models can expose commercially, strategically, or technically valuable model information through governed inference interfaces, including logits, log-probabilities, embeddings, intermediate representations, structured responses, and other protected outputs. Repeated or automated access to such information can contribute to industrial-scale model extraction, unauthorized capability replication, or distillation, creating significant intellectual-property, commercial, security, or strategic risk for operators of high-value models. The problem addressed by this document is not whether a model is technically capable of computing such information, but whether computation itself should constitute authority to release it. This document therefore separates model computation from external disclosure: successful inference does not, by itself, constitute release authority. An output may be fully computed while remaining a non-effective Candidate Release that cannot yet cross the governed release boundary. A Candidate Release remains non-effective until the applicable release conditions have been independently satisfied. The architecture can include release-specific protected validation, evaluation of rollback-resistant extraction state where required, and atomic reservation or consumption of bounded release authority. A controlled Finality Sink verifies the required state at the boundary where the protected information would first become externally available. Release authority is bound to the applicable Candidate Release or bounded release class rather than functioning as a generic transferable bearer credential. The intended result is a technical separation between information that a model can compute and information that the governed system permits to become externally effective. This architecture is intended primarily for high-value or high- capability models and protected output classes where industrial-scale extraction or unauthorized capability replication creates sufficient risk to justify stronger release controls. It is not intended to impose the same enforcement mechanism on every model, user request, or inference path. Operators can apply execution-finality controls selectively according to model value, protected-output class, extraction risk, interface characteristics, or required assurance level. Such enforcement can introduce additional protected-state management, validation, synchronization, attestation, or Finality Sink verification overhead. Latency is therefore an explicit deployment tradeoff rather than an assumption that every inference request should incur the same assurance cost. For sufficiently valuable models or sensitive capabilities, an operator may determine that stronger protection against industrial-scale extraction justifies additional release-path processing, while ordinary or lower-risk output paths may use lighter controls. The architecture does not claim universal prevention of model extraction or distillation. In particular, it does not claim to prevent all learning from ordinary outputs that have been legitimately released, nor does it claim control over information after valid disclosure beyond the governed boundary. Its narrower objective is to constrain industrial-scale extraction conducted through governed release paths and to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete. Remote Attestation Procedures (RATS) can complement this architecture by providing machine-verifiable evidence that the expected release- control mechanism, protected extraction state, security epoch, and Finality Sink are present and operating with the required assurance properties. Attestation establishes evidence concerning the enforcement environment; it does not itself constitute authority to release a protected Candidate Release. |
| | Revocation Closure for Agentic Authorization Systems |
| |
|
Agentic systems can derive and distribute authority across delegated agents, workloads, credentials, queues, and long-running operations. Existing revocation mechanisms can invalidate a credential or authorization grant, but credential invalidation alone does not establish that every path from revoked authority to a consequential effect has been closed. This document defines a protocol-neutral model for revocation closure. It introduces authority graphs, consequential sinks, revocation cut sets, closure states, closure budgets, and closure receipts. The model is intended to complement OAuth 2.0, workload identity, transaction-token, and agent-authorization work. It does not define a new authorization protocol, token format, or AI safety mechanism. |
| | Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts |
| |
|
Autonomous agents increasingly make or propose consequential actions using premises assembled from model outputs, memory, tools, telemetry, and external data. Existing authentication and authorization mechanisms can establish who is acting, under whose delegation, and which operation is permitted, but they do not by themselves establish whether the proposition that triggered the operation has adequate support. This document defines the Evidence Qualification Receipt (EQR), a transport-neutral JSON data model and fail-closed verification procedure for binding a proposition to a declared evidence profile, its supporting evidence digests, contradiction state, freshness, and evaluation result. An EQR can be PASS, FAIL, or INDETERMINATE. A PASS EQR is only an authorization input: it is never itself permission to execute. The design is append-only: changed evidence produces a successor receipt rather than rewriting prior epistemic state. The goal is to prevent evidence, provenance, or model confidence from silently acquiring authorization semantics. |
| | Human Agency Continuity Protocol (HACP) Architecture |
| |
|
This document describes the architecture of the Human Agency Continuity Protocol (HACP): a pre-execution authorization contract for tool-using agents. HACP separates human intent, deterministic evaluation, cryptographic decision binding, and enforcement so that an agent cannot silently reinterpret authorized action after a decision is issued. This document is Informational. It is not an Internet Standard. It does not activate Enforcement revision 2 and does not claim general URI-normalization conformance. The acronym HACP in this series means Human Agency Continuity Protocol. A separately posted individual Internet-Draft, draft- sunyi-hacp-protocol, uses the same four letters for a different protocol (Hardware Agent Capability Protocol) by a different author. The present author has no affiliation with that document. |
| | Human Agency Continuity Protocol (HACP) Core |
| |
|
This document specifies the HACP-Core decision contract: IntentEnvelope, ProposedAction, AgencyDecision, DecisionToken, provenance events, revocation, and the ordered evaluate() algorithm. Implementations MUST fail closed. Decisions MUST be deterministic and MUST NOT require a language model on the evaluation path. The published executable baseline is the 38-vector HACP-Core v0.9.2 suite. Wire object field hacp_version remains "0.9". Specification release 1.0.0 does not change that field. |
| | Capability-Validated Inbound Descriptors: Catalogue of Enforcement Profiles |
| |
|
A destination identifier, an API credential, a completed computation, and an attested execution environment are each routinely treated as if they carried authority for consequence. This document argues that none of them does, and catalogues fifty-nine enforcement profiles of the Capability-Validated Inbound Descriptor (CVID) architecture, in which an attempted act is a Candidate Act with no external effect until a protected enforcement domain validates a conjunctive predicate set and releases the capability the effect requires. The profiles span inbound communication; network capability exposure and intent-driven network programming; AI-native radio access, network slicing and packet core; distributed inference and digital twins; ultra-reliable low-latency operation; cross-border and sovereignty-bound execution; satellite, non-terrestrial and direct- to-device networks; optical inter-satellite links; immersive and semantic media; machine swarms; ambient IoT and backscatter; reconfigurable intelligent surfaces; device paging and wake; offline central bank digital currency settlement; lawful disclosure through escrow; platform neutrality measurement; network energy expenditure; and enforcement in silicon at accelerator output paths, DMA and RDMA boundaries, interconnects, and die-to-die interfaces. Three authorities commonly conflated are separated: authority to consume resources, authority to compute, and authority to cause an external effect. From that separation follows the treatment of energy as an enforceable security resource rather than only an efficiency metric, with a low-energy admission tier deciding whether a candidate may activate expensive baseband, accelerator, or radio paths at all. The document compares this position with published 6G energy work from Ericsson, Nokia, Qualcomm, and Huawei, states what the author believes is new, and sets out the limitations of the approach. Profiles are reproduced in the structural form in which they were drafted, including system and method variants of the same mechanism. The architecture itself, its terminology, and its protocol mappings are described in a companion document. This document is published for discussion and comment; it is not a product of an IETF Working Group, and corrections are invited. |
| |
|
| |
| | Use of Hybrid Public-Key Encryption (HPKE) with CBOR Object Signing and Encryption (COSE) |
| |
| | draft-ietf-cose-hpke-27.txt |
| | Date: |
12/09/2026 |
| | Authors: |
Hannes Tschofenig, Michael Jones, Orie Steele, Ajitomi, Daisuke, Laurence Lundblade |
| | Working Group: |
CBOR Object Signing and Encryption (cose) |
|
This specification defines hybrid public-key encryption (HPKE) for use with CBOR Object Signing and Encryption (COSE). HPKE offers a variant of public-key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE is a general encryption framework utilizing an asymmetric key encapsulation mechanism (KEM), a key derivation function (KDF), and an Authenticated Encryption with Associated Data (AEAD) algorithm. This document defines the use of HPKE with COSE. Authentication for HPKE in COSE is provided by COSE-native security mechanisms or by the pre-shared key authenticated variant of HPKE. |
| | PROBE: A Utility for Probing Interfaces |
| |
|
This document specifies a network diagnostic tool called PROBE. PROBE is similar to PING in that it can be used to query the status of a probed interface, but it differs from PING in that it does not require bidirectional connectivity between the probing and probed interfaces. Instead, PROBE requires bidirectional connectivity between the probing interface and a proxy interface. The proxy interface can reside on the same node as the probed interface, or it can reside on a node to which the probed interface is directly connected. This document updates RFC 4884 and obsoletes RFC 8335. |
| | Testing async submission |
| |
|
This draft is submitted only to test the async api submission endpoint |
| | Lightweight Directory Access Protocol (LDAP): Additional Syntaxes |
| |
|
This document registers additional syntax definitions for use in Lightweight Directory Access Protocol (LDAP) directory and Directory services series X.500. This includes widely used datatypes and syntaxes. |
| | PQC Certificate Rotation Requirements for Multi-Tenant PKI Environments |
| |
|
This document specifies requirements for post-quantum cryptography (PQC) certificate rotation in multi-tenant public key infrastructure (PKI) environments. Multi-tenant PKI deployments — in which a single PKI platform issues and manages certificates for multiple distinct tenant organizations — face coordination challenges that single- tenant PKI deployments do not encounter during PQC migration. |
| | PQC Readiness Observability Gaps in Networked Computing Environments |
| |
|
This document identifies observability gaps that prevent network operators and security teams from determining the post-quantum cryptography (PQC) readiness state of networked computing environments. PQC readiness requires knowing which cryptographic algorithms are in use across the environment, which are vulnerable to quantum attack, and which have been or are being migrated to NIST- approved PQC algorithms. Current network protocols and management frameworks do not provide sufficient visibility to answer these questions at scale. |
| | Authorization Posture Mechanism (APM): Per-Transaction Consistency for OAuth 2.0 |
| |
|
This document describes the Authorization Posture Mechanism (APM), a method by which an OAuth 2.0 [RFC6749] authorization server, or a resource server acting on its behalf, re-evaluates the mutual consistency of three bound factors -- the client certificate, the access token, and the device posture -- on a per-request basis for privileged operations, rather than only at session establishment. When re-evaluated posture degrades relative to the posture under which the token was issued, APM defines deterministic, least- privilege Graduated Outcomes including scope reduction and method restriction, rather than a binary allow or deny. |
| | Authorization Receipts for High-Risk Agent Actions |
| |
|
This document defines the EMILIA Protocol (EP) authorization receipt, an evidence artifact binding an enrolled approver key to one canonical action before execution. An approver-held key signs an Authorization Context containing the action hash, policy reference, shared authorization instance, per-signoff nonce, audience, and validity window. A Trust Receipt carries the signed contexts, terminal consumption record, and Merkle inclusion material so a relying party can verify the recorded event offline under independently selected log, directory, policy, and approver trust inputs. The receipt establishes only the guarantees of the selected verification profile. The mapping from an enrolled approver identifier to a natural person is asserted by the directory authority. Offline verification does not establish current revocation status, global non-replay, comprehension, legality, safety, or execution. Replay prevention requires an online atomic consumption store at the executor. The state-machine invariants are machine-checked under the assumptions stated in this document. This revision defines the closed EP-AUTHORIZATION-BUNDLE-v1 pre- execution profile and its verification algorithm. The bundle carries the Action Object, signed Authorization Contexts, signoffs, key proofs, and presentation evidence; it deliberately carries no terminal consumption or execution claim. An optional, profile- identified authorization binding can commit the human evidence to an independently verified native authorization artifact without replacing that artifact or making this receipt format depend on its transport or trust model. A receipt is evidence, not authorization. This document does not treat a local user interaction as an authorization decision. It defines one evidence artifact that an authorization architecture can use in a human-confirmation flow: the signed Authorization Context is action-bound confirmation evidence an authorization server MAY validate and bind to the grant it issues. The resulting Trust Receipt records terminal consumption and remains evidence; neither object makes the authorization decision. That decision remains with the authorization server. |
| | Post-Quantum Cryptographic Agility Profile for ACME |
| |
|
This document defines an Automated Certificate Management Environment (ACME) [RFC8555] profile extension that enables ACME servers and clients to express per-account and per-order post-quantum cryptographic (PQC) posture. The extension introduces a pqcAgility metadata object in the ACME directory, an optional pqcAgility member in order objects, and a server-side adequacy scoring mechanism that determines whether a given order satisfies an account's declared PQC readiness threshold. The profile is designed for both public and private ACME deployments and does not modify the core ACME state machine: it adds discoverable capability metadata and per-order policy directives that servers MAY enforce. Multi-tenant ACME servers MUST implement tenant-isolation controls that prevent cross-account PQC posture leakage. This document is distinguished from draft-giron-acme-pqcnegotiation [I-D.giron-acme-pqcnegotiation], which defines algorithm negotiation at the ACME protocol level. This profile operates above the negotiation layer: it defines per-account posture scoring, adequacy thresholds, hybrid policy bits, rotation epoch anchoring, and tenant- isolation requirements that apply regardless of which negotiation mechanism is used. |
| | Binding Deterministic Rendering and Display Attestations to Human-Authorization Receipts |
| |
|
A human-authorization receipt proves an enrolled key produced a user- verified signature over a digest that commits to an exact action. It does not prove the signing surface DISPLAYED that action honestly. If a signing interface shows a benign summary while committing a different action, the resulting receipt is laundered authority: cryptographically valid and semantically false, which is worse than no receipt at all. This is the presentation attack, and it is the deepest unsolved problem in authorization evidence, because a signature cannot attest to pixels. This document narrows the gap with two additive, offline-checkable pieces that touch no existing receipt format: a DETERMINISTIC RENDERER, a pure function from the canonical action to a byte-identical human-readable rendering, so a verifier RE-DERIVES the rendering from the signed bytes and rejects a claimed rendering that does not match; and a DISPLAY ATTESTATION, a signed claim by the signing client binding the rendering it showed to the action it committed. Neither eliminates the presentation attack (nothing purely digital can), but together they let a verifier check the claimed rendering against the signed action under relying-party- selected client trust inputs. They make the residual risk explicit rather than hidden. |
| | Canonicalization Declaration for SCITT Signed Statements |
| |
|
Independently written systems that anchor records to a SCITT Transparency Service repeatedly need the same construction: a canonical form of structured content, a content-addressed identifier derived from that form, binding to a SCITT Signed Statement and Receipt, and references that cite external artifacts by digest. This document, referred to as CPB, specifies that construction as declarations rather than as a payload format. A payload profile declares its canonicalization algorithm and exclusion set and thereby obtains a reproducible derived identifier. A CPB Signed Statement carries either the complete statement content as specified by RFC 9943 or a digest of content held elsewhere using the COSE Hash Envelope of RFC 9995. CPB also defines an abstract typed digest reference information model and one optional protected-header encoding, cpb-refs; a payload profile may instead define its own reference serialization. An IANA registry assigns the canonicalization algorithm identifiers that these declarations name. CPB does not define payload content formats, establish or require a universal artifact-type registry, or require either typed-reference carrier. |
| | The Missing Piece for High-Value Confidential Enterprise AI: Non-Joinable Vaults and Output-Release Finality for Banking,Defence,and Public-Sector Deployments |
| |
|
This profile is specified for high-risk, multi-system enterprise and public-sector AI — assistants and agents that can see several independently authorized stores and then send, write, or invoke. It is not specified for consumer chat. In industrial terms that describes enterprise assistant and agent seats of the kind offered by Anthropic, OpenAI, Google Gemini, and xAI Grok, together with self- hosted open-weight deployments; these names are used with respect, as publicly described deployment classes only, and imply no claim about any vendor's internals and no vendor endorsement of this profile. A 2020 breach stole what was already stored: a server image, a database dump, user rows. After 2025 a compromised assistant can do what a dump cannot. In minutes it can join mail, tickets, code, finance, and memory into a map of launch plans, targets, defects, and negotiation room — strategy that was never one record — and that map can be sold to a competitor. There is no credential rotation for a future that has already been read. Traditional access control still answers who may touch each store. It does not answer whether those fragments may be joined into that meaning, or whether that meaning may leave. This document specifies an architectural framework and metadata profile for that gap. Technical Non-Joinability is enforced by a session-bound Reconstruction Authorization Object (RAO) that limits relational binding. Technical Non-Completability is enforced by an Output Release Boundary that requires committed validation evidence before a generated token or tool invocation can take external effect. The specification defines the authorization objects, cryptographic bindings, and boundary validation sequences required to isolate reconstruction domains without modifying the underlying datastores. A published runnable reference implementation is provided so that the profile can be executed and tested, not only read as theory. That implementation is an architectural reference for the state machine, not a claim of production isolation. The architecture introduces bounded evaluation on the path that can intercept unauthorized join or release. That latency is accepted where the asset is high- consequence enterprise or public-sector intelligence and raw speed is subordinate to preventing reconstruction and release. The author states that trade-off explicitly: this profile is for deployments that choose that priority. It is not offered as a design for consumer chat or other paths that optimize only for speed. Readers are respectfully encouraged to review Section 4 and Section 5 in full, as those sections set out the complete problem description and motivating scenarios and should not be skipped. |
| | Assume the AI Server Is Already Compromised: Execution-Consequence Decoupling So a High-Risk Enterprise AI Cannot Join,Infer,or Send |
| |
|
Start from the assumption that the attacker already controls the AI server — that the workload is fully compromised. Not the perimeter, not a phished seat — the workload itself: its credentials, its connectors, its context window, its output path. Nearly every enterprise control in use today has already failed by that point, because nearly every one of them is designed to keep the attacker out of the workload rather than to limit what the workload can do once it is theirs. Before anything else, the engineering posture: this architecture is specified for high-risk AI systems, where the standard priorities shift from speed and latency toward determinism, containment, and safety. It is written for billion-dollar enterprise and mission- critical deployments — banking and treasury, defence and national security, critical infrastructure, and regulated enterprises holding unreleased material — and not for general day-to-day, consumer-grade, or low-stakes use. It introduces evaluation on the join path and on the release path, and accepts that cost deliberately, because in these environments an unauthorized reconstruction or an unauthorized send is not recoverable by being fast. This document asks what is still denied to the attacker at that moment, and specifies an architecture in which two things are still denied: the attacker cannot cause independently held enterprise fragments to be bound into a map of the organization, and cannot cause any generated result to become externally effective. Access to a store is not authority to join it to another store. Finishing a generation is not authority to send it. The mechanism is Execution-Consequence Decoupling, enforced by three pillars: Decomposition of Authority (Technical Non-Joinability) across independently controlled identity, content, relationship- mapping, and cryptographic domains; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non- Completability, so that computation can run to completion in a compromised environment without the ability to complete an external consequence. Reconstruction is governed by a non-bearer Reconstruction Authorization Object bound to attested execution context, session, purpose, and Permitted Association Scope. Candidate Outputs are sealed, re-verified at output time, and committed to a Protected Output Validation Receipt before an output- specific Release Capability can be issued and exercised at a designated Output Release Boundary. The industrially relevant systems are the enterprise assistant and agent runtimes now deployed into exactly those environments, including those built on Anthropic Claude, OpenAI ChatGPT, Google Gemini, xAI Grok, and self-hosted Meta Llama models, together with the connector and Model Context Protocol fleets attached to them. These are named as publicly described deployment classes, because an architecture for high-risk enterprise AI should say plainly which systems it is about; nothing here characterizes any vendor's internal design or security posture, and no vendor has reviewed or endorsed this work. It states the problem space, compares the architecture against representative conventional technologies (access control, bearer credentials, vaulting, TEEs, sandboxes, DLP, provenance, DRM, clean rooms, and information-flow control), gives a detailed technical description, and supplies JSON Schema definitions for the three protected objects. A published runnable reference implementation [GITHUB-DAS-VII] executes the protected chain described here, so the architecture can be run and tested rather than only read; it is an architectural reference for the state machine and its failure states, not a claim of production isolation. This is the architecture and rationale document. Its companion, draft-das-enterprise-ai-output-finality [I-D.das-enterprise-ai-output-finality], specifies the same split as a deployable protocol profile and metadata format for vendor assistant and agent seats. The two are read together: this document explains why authority must be separated from computation; the companion specifies the objects, bindings, and boundary sequences that carry the separation on the wire. |
| | DKIM2 Sender Policy |
| |
|
This document updates DMARC RFC9989 for DKIM2. In particular DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, so this updates DMARC to support those scenarios as well. While DMARC defines a RFC5322 From alignment constraint with an enforcement policy if validation fails, this generalizes and separates enforcement policy from constraint validation policies. This provides a mechanism for MTAs to declare support for DKIM2 through the DMARC DNS policy record that helps secure DKIM2 from downgrade attacks. |
| | CA-Side Post-Quantum Rotation Envelope for X.509 Issuance Continuity |
| |
|
This document defines the X.509 Post-Quantum Rotation Envelope extension, a Certification Authority (CA) side commitment mechanism that allows an issuing CA to publish, sign, and bind to its issued certificates a machine-verifiable guarantee of post-quantum (PQ) or PQ/T hybrid issuance continuity across the CA's own key-rotation boundaries. The mechanism is complementary to, and does not overlap with, subject-side commitments such as the continuityPeriod field defined in [I-D.reddy-lamps-x509-pq-commit]: where that draft captures the CA's continuity obligation to continue presenting PQ or composite certificates after the current certificate's notAfter, this document captures the issuing CA's parallel obligation to remain capable of issuing such certificates across its own root and intermediate key rotations during the same migration window. The Rotation Envelope extension carries a SHA-384 hash of a CA- published, signed JSON manifest hosted at a stable /.well-known/pki- rotation-envelope URI under the issuer's authorityInfoAccess host. The manifest enumerates: (a) the algorithm identifiers the CA commits to continue supporting for issuance through a stated envelopeNotAfter date, (b) the successor-CA SubjectPublicKey hashes already provisioned for the next CA key generation, and (c) the OCSP and CRL distribution endpoints that will remain authoritative through the envelope window. Relying parties that understand the extension can verify, at any time during the current certificate's lifetime, that the CA's published continuity posture matches what was bound at issuance, detecting silent CA-side degradation, unannounced CA replacement, or rollback of PQ-capable issuance commitments. This document is filed independently and is intended to be considered alongside, not in place of, [I-D.reddy-lamps-x509-pq-commit]. The two mechanisms address orthogonal sides of the same PQ migration window: subject-side declaration of intent (Reddy et al.) and CA-side guarantee of issuance capability (this document). |
| | Web4 Assessment Assertions |
| |
|
This document defines an implementation-neutral envelope for externally presented assessment results, including subject, issuer, policy, result, validity, evidence commitments, proof, and current status, while protected methods remain confidential. |
| | Web4 Claims and Verification |
| |
|
This document distinguishes claims, evidence, assessments, assertions, verification events, challenges, supersession, suspension, expiration, revocation, and receipts without standardizing private scoring internals. |
| | Web4 Delegated Authority |
| |
|
This document defines signed, bounded, time-limited, and revocable authority mandates for agents and nodes and links governed actions to their authority. |
| | Web4 Evidence Receipts |
| |
|
This document defines durable, cryptographically verifiable receipts for assessment, authority, policy, claim, and node-lifecycle events without requiring publication of protected evidence. |
| | Web4 Federation Policy Advertisement |
| |
|
This document defines machine-readable advertisements for federation policies, including authority, versions, profiles, evidence formats, retention, challenges, appeals, revocation, disclosure, jurisdiction, proof, and status. |
| | An Execution Interlock at the AI Model-to-External-Effect Boundary |
| |
|
An AI system's ability to compute an operation is not the same as authorization for that operation to take effect outside the system. This document defines an enforcement boundary at which an operation produced by an AI system is verified against the effect it will actually produce, rather than against the effect that was requested or approved upstream, and specifies that the operation carries no external consequence until that verification succeeds. The boundary is complementary to alignment, sandboxing, monitoring, and interpretability, which reduce the likelihood that an unsafe operation is produced. This document addresses the separate question of what prevents a produced operation from becoming effective. The mechanism functions as a safety interlock: it does not restrict what the system may compute, only whether a specific computed operation may take effect. The invariant is that computation is not authority. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over the MPLS Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-mpls-07.txt |
| | Date: |
12/09/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SR-MPLS networks using the Simple Two- Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and further augmented in RFC 9503. The described procedures are used for SR-MPLS paths (including Segment Lists of SR-MPLS Policies, SR-MPLS IGP best paths, and SR-MPLS IGP Flexible Algorithm (Flex-Algo) paths), as well as Layer-3 and Layer-2 services carried over the SR-MPLS paths. |
| | Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing over IPv6 (SRv6) Data Plane |
| |
| | draft-ietf-spring-stamp-srpm-srv6-04.txt |
| | Date: |
12/09/2026 |
| | Authors: |
Rakesh Gandhi, Clarence Filsfils, Bart Janssens, Mach Chen, Richard Foote |
| | Working Group: |
Source Packet Routing in Networking (spring) |
|
Segment Routing (SR) can be used to steer packets through a network employing source routing. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for performance measurement in SRv6 networks using the Simple Two-Way Active Measurement Protocol (STAMP), as specified in RFC 8762, along with its optional extensions specified in RFC 8972 and further augmented in RFC 9503. The procedures described in this document are used for links and SRv6 paths (including Segment Lists of SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm (Flex- Algo) paths), as well as Layer-3 and Layer-2 services carried over the SRv6 paths. |
| |
|
| |
| | JWTClaimConstraints profile of ACME Authority Token |
| |
|
This document defines an authority token profile for the validation of JWTClaimConstraints and EnhancedJWTClaimConstraints certificate extensions within the Automated Certificate Management Environment (ACME) protocol. This profile is based on the Authority Token framework and establishes the specific ACME identifier type, challenge mechanism, and token format necessary to authorize a client to request a certificate containing these constraints. |
| | Implementation Guidance for the PKCS #1 RSA Cryptography Specification |
| |
|
This document lists additions to RFC 8017. Specifically, it provides guidance to implementers of the standard to protect against side- channel attacks. It also recommends against the RSAES-PKCS-v1_5 encryption scheme, and provides an alternative depadding algorithm that protects against side-channel attacks raising from users of vulnerable APIs. The purpose of this specification is to increase security of RSA implementations. The document is a product of the Crypto Forum Research Group (CFRG). |
| | TLS Client Authentication via DANE TLSA records |
| |
|
The DANE TLSA protocol describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS. In addition, it defines a new TLS extension, DANE Client Identity, to convey the client's domain name identity to the server. |
| | BMP Statistics Information TLV |
| |
|
The BGP Monitoring Protocol (BMP) defines statistics reports that provide periodic snapshots of various BGP-related metrics. When statistics are reported periodically, the snapshot values may not reflect the variations that occurred between reporting intervals. This document defines a Statistics Information TLV that can be used to convey additional statistical information about BMP gauge-type statistics during the reporting period. This TLV reports the minimum and maximum values observed (with timestamps indicating when they occurred), along with additional statistical measures such as average, percentiles, or snapshot values. This enables BMP collectors to better understand the dynamics of monitored statistics even when the reported snapshot values appear constant. |
| | Updates to Legacy IANA Registries |
| |
|
IANA maintains several registries that were created for IPv4. As the IPv4 core specification is no longer being extended and as some other registries do not have a defined IANA registration procedure, these registries need to be updated to indicate a registration procedure or to reflect the current practice that defining such extensions is not recommended. |
| | A YANG Network Data Model for Inventory Topology Mapping |
| |
|
This document specifies a YANG data model that extends the network topology data model (RFC 8345) to map network topologies with inventories. The data model introduces the "inventory-topology" network type and augmentations for physical entity mappings and capabilities, which may be used by any overlay network topology for service provisioning validation, network maintenance, and capacity planning. |
| | PQ/T Hybrid Composite Signatures for JOSE and COSE |
| |
|
This document describes JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE) serializations for PQ/T hybrid composite signatures. The composite algorithms described combine ML-DSA as the post-quantum component and either ECDSA or EdDSA as the traditional component. |
| | MPLS Network Actions for In Situ Operations,Administration,and Maintenance |
| |
| | draft-ietf-mpls-mna-ioam-14.txt |
| | Date: |
11/09/2026 |
| | Authors: |
Rakesh Gandhi, Greg Mirsky, Haoyu Song, Bin Wen, Voitek Kozak |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
In situ Operations, Administration, and Maintenance (IOAM), defined in RFC 9197, collects operational and telemetry information in the packet using IOAM-Data-Fields while the packet traverses a path between two points in the network. Several IOAM Option-Types are available, for example, Pre-allocated Trace, Proof of Transit (POT), Edge-to-Edge (E2E), and Incremental Trace, that can be used to collect information for calculating various performance metrics. RFC 9326 defines the IOAM Direct Export (IOAM-DEX) Option-Type, which is used as a trigger for IOAM data to be directly exported or locally aggregated without being pushed into in-flight data packets. MPLS Network Action (MNA) mechanisms indicate actions to be performed on any combination of Label Switched Paths, MPLS packets, and the node itself, and to transport data needed for these actions. This document defines MNAs to collect and transport the operational state and telemetry information using IOAM-Data-Fields as well as IOAM-DEX. |
| | ICMP Extensions for Environmental Information |
| |
|
This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility into environmental information on the internet by providing per-hop (i.e., per topological network node) power metrics and other present or future metrics around environmental information. This will contribute to achieving an objective mentioned in the report of the IAB E-Impact workshop. The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental information. |
| | Agent Considerations |
| |
|
Artificial intelligence (AI) agents consume IETF specifications to generate and operate implementations. This document defines an "Agent Considerations" subsection within the Operations and Management Considerations section described in RFC 5706 and its revision. It provides guidance on schemas, examples, capability descriptions, and verification, with cross-references to agent- specific security and privacy analysis. |
| | Enhanced BGP Resilience |
| |
|
According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. RFC7606 revises the error handling procedures for a number of existing attributes. The use of the "treat-as-withdraw" and "attribute discard" approaches significantly reduces the likelihood of BGP sessions being reset when receiving malformed BGP update messages, thereby greatly enhancing network stability. However, in practical applications, there are still numerous instances where BGP session oscillations occur due to the receipt of malformed BGP update messages, unrecognized attribute fields, or routing rules generated by a certain BGP AFI/SAFI that affect the forwarding of BGP messages. This document introduces some approaches to enhance the stability of BGP sessions. |
| | Advertising IGP Active Measurement Groups in Router Capabilities |
| |
|
This document defines IGP capability advertisements for measurement group membership for Active Measurement Protocols (AMPs) such as TWAMP and STAMP. An IS-IS capability sub-TLV is defined for IS-IS and an OSPF Router Information (RI) LSA TLV is defined for OSPFv2 and OSPFv3. The mechanism allows IGP routers to discover other routers participating in different measurement groups, enabling automatic discovery of measurement endpoints throughout an IS-IS or OSPF routing domain. The solution uses a Group ID to identify measurement group membership, where the same interface address (IPv4 or IPv6) may be used for multiple measurement groups. A corresponding BGP - Link State (BGP-LS) node-level attribute is defined to distribute measurement group membership beyond a single IGP domain. |
| | Mercurius Window System (MWS) |
| |
|
The Mercurius Window System (MWS) is a zero-trust, network-native window system for contemporary desktops. It combines persistent, detachable graphical Sessions with network transparency. MWS works on a workstation without requiring network connectivity. The same Session model allows users to start a new Session or resume a detached Session, either at the workstation itself or from another device across the network. MWS complements local display systems such as Wayland. Applications and their state remain on the workstation, while a Portal provides the user's display and input facilities. Modern graphics APIs and authenticated transport support this separation between where applications execute and where a user interacts with them. This document specifies the Session, Window, and communication behaviour needed for independent implementations to interoperate. |
| | Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems |
| |
|
Agentic AI systems operate on behalf of human principals, often delegating tasks through multi-step chains of AI agents. There is currently no standard mechanism to record who authorized an agent to act, under what scope, and through what chain of delegation, in a way that can be verified offline, without a central registry, and without third-party trust anchors. This document specifies the Human Delegation Provenance Protocol (HDP) version 0.1, a lightweight token-based protocol that captures, structures, cryptographically signs, and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session, records each agent's delegation action as a signed hop in an append-only chain, and enables any participant to verify the full provenance record using only the issuer's Ed25519 public key and the current session identifier. Verification is fully offline. No registry lookup, no network call, and no third-party trust anchor is required. HDP's distinguishing contribution is a signed, tamper-evident record of each agent's declared action at each hop, an execution audit trail that complements, rather than replaces, capability-based delegation formats such as UCAN and ZCAP-LD. The underlying append-only, offline-verifiable chain-of-custody mechanism is payload-agnostic; human-authorized agentic delegation is the reference profile specified in this document. HDP is not an authorization protocol. An HDP token confers no authority and its presentation entitles the presenter to nothing. It is a record of who authorized a task and of what each agent declared it did with that authorization, carried with the task and read at audit. |
| | Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture |
| |
|
This document presents a security- and privacy-preserving execution- finality architecture for third-party AI interoperability under the European Digital Markets Act (DMA). It is designed to enable meaningful participation by external AI assistants while keeping consequential device actions under bounded, verifiable platform control. The architecture separates an AI-generated request from the authority to make that request externally effective. A requested operation remains in a Non-Effective State until protected infrastructure validates the requester, intended resource, destination, user authorization or intent where required, purpose and scope, freshness, revocation state, runtime conditions, and other applicable policy predicates. After successful validation, the system creates narrowly scoped, non- bearer execution authority bound to the specific Candidate Act. At the Finality Sink—the first boundary at which the operation can become externally effective—the system independently verifies that the actual operation still matches the validated act and that the authority remains current and unused. This design is intended to address major security risks associated with AI interoperability, including prompt injection, compromised assistant or cloud infrastructure, confused-deputy behavior, replay, token theft or reuse, destination or parameter substitution, scope escalation, stale authorization, alternate-path bypass, and unauthorized consequential execution. It also supports privacy protections by limiting access and effectuation to the minimum act-specific scope, reducing dependence on broad reusable permissions, preserving revocation and user-control boundaries, and preventing data release or transmission when the protected validation conditions are not satisfied. The resulting model is open participation with bounded, verifiable authority: third-party AI systems may interoperate with device functions without receiving unrestricted final-effect authority, while the platform retains protected enforcement over whether a proposed action is permitted to become externally effective. The length of this document is intentional. It aims to work through the major security- and privacy-related objections associated with third-party AI interoperability at a technical level of detail sufficient to show that they are addressed, rather than merely asserted, and reviewers are welcome to engage with any section on its own merits. In June 2026, Apple announced that it would not ship its new Siri AI on iOS 27 and iPadOS 27 in the European Union, stating that EU regulators had not accepted its proposed interoperability safeguards and that granting third-party assistants access equivalent to Siri's created unacceptable security and privacy exposure. The European Commission responded that nothing in the DMA itself required Apple to withhold the feature, describing Apple's decision as a voluntary business choice rather than a legal necessity, and noting that Apple had requested a blanket exemption rather than submitting a compliant technical mechanism. Both positions are correct within their own frame: Apple's underlying security concern about undifferentiated third-party system access is real, and the Commission is also correct that the DMA does not itself compel a trade-off between interoperability and security. This document's execution-finality architecture is offered as the middle solution by which both can be satisfied simultaneously: third-party AI assistants gain the interoperability the DMA requires, while the platform retains the bounded, verifiable finality control that Apple's objection is actually about. To show this is not only a theoretical proposal, a runnable reference implementation of this architecture has been published, demonstrating how the design behaves end to end in a virtual/test environment (note: behavior and measurements in an actual production environment may differ). A note for reviewers: the length of this document is deliberate. More than sixty technical questions are answered in question-and- answer form, covering anticipated security, privacy, deployment, and standardisation objections as well as performance, scalability, and hardware enforcement. To show that the architecture is intended to be implementable and not only a paper proposal, two runnable open- source reference implementations are also referenced: the initial demonstrator, and an adversarially hardened follow-on that adds live challenge-bound finality, strict object verification, cross-object consistency checks, and 100 executable tests. The latest implementation is available in the Hardened Challenge-Bound Execution-Finality Reference Implementation repository (https://github.com/sangmdas/Hardened-Challenge-Bound-Execution- Finality-for-AI-Interoperability). Both implementations were exercised in a virtual/local test environment, and actual readings may vary in separate environments; they are offered as evidence of engineering feasibility rather than as production-certified software. Critical review of both the document and the code is sincerely welcomed. |
| | SCITT Profile for Independently Derived Subjects |
| |
|
The Supply Chain Integrity, Transparency, and Trust (SCITT) architecture permits distinct Issuers to agree on a common CBOR Web Token (CWT) Subject Claim (sub). This document specifies a profile for independently deriving that claim from shared application-defined Subject semantics without a shared assigning authority. An application maps its Subject description to a structured Value. This profile defines the derivation domain, deterministic binding encoding, SHA-256 construction, text syntax, and candidate-to-claim comparison requirements. Optional JSON and Concise Binary Object Representation (CBOR) codecs exchange admitted Values. Subject descriptions and Statement payloads have separate roles; the construction derives sub from the complete mapped Value, while SCITT provides the signed binding and transparency evidence. |
| | Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse |
| |
|
Consider a concrete case: a user invokes a highly capable AI model under a declared purpose of education, but the resulting capability is in fact used for a military or terrorist end -- an illustrative example, not a claim about any real deployment. When such misuse surfaces, an unresolved question follows: is the model provider liable, is the user liable, or is the jurisdiction that permitted the deployment liable? This document does not answer that question -- liability determination remains an external legal question for the responsible court, regulator, or contracting parties -- but it addresses the technical gap that makes the question unanswerable today. Systems that collect data, or grant capability, for one stated purpose routinely permit that data or capability to be consumed for a different purpose, not because the second use was authorized, but because nothing in the protocol path was capable of refusing it or of recording what was actually authorized. The most common technical control in deployment today is a self-asserted purpose string: a "purpose" claim in a token, a field in an API request, a comment in a data-sharing agreement. A self-asserted string is evidence of intent, not proof of authority, and it fails precisely when it matters most -- when the requester lies. This architecture addresses that loophole deterministically: it makes an undeclared or purpose-switched use technically detectable and refusable at the point of use, and it produces verifiable evidence of what was actually authorized, so that any subsequent liability determination can be argued from that evidence rather than from an unverifiable self-assertion. Achieving that determinism introduces a bounded, measurable amount of evaluation latency at the point of use; this document treats that latency as an acceptable, secured trade-off for closing an otherwise unverifiable gap, not as a cost to be minimized at the expense of the guarantee. The premise is not that AI innovation should slow down, any more than cars should be built slower; it is that innovation moving this fast needs the technical equivalent of a seat belt. A runnable reference implementation accompanies this document at Purpose Execution Finality Validator -- Runnable Reference Implementation (https://github.com/sangmdas/Purpose-Execution- Finality-Validator-to-Prevent-Data-Purpose-Laundering-in-AI-Systems). |
| | A SCITT Profile for Pre-Run Evaluation Criteria (PRML) |
| |
|
This document defines a profile for carrying pre-run evaluation criteria as a SCITT Signed Statement payload, using the architecture of RFC 9943. It specifies the payload media type, the selection of the Issuer and Subject CWT claims, the encoding of hash-only statements for criteria that must remain confidential, a sequencing requirement that makes amendment order verifiable, and the semantics of amendment itself. It does not define a new transparency architecture; it describes how an existing artefact type is carried by the one RFC 9943 already defines. |
| | Discovery and Retrieval of Publisher-Curated Context Files for Large Language Model Consumers |
| |
|
Publishers have begun to serve a curated, plain-text summary of a web origin intended for consumption by large language models and by the crawlers that feed them, most visibly under the de facto file name "llms.txt". The practice has no specification, no media type, and — of direct operational consequence — no discovery mechanism: a consumer that does not already guess the path cannot learn that such a file exists. This document specifies discovery and retrieval for publisher-curated context files. It defines the well-known URI "llm-context", the link relation type "llm-context", and an extension record for the robots exclusion protocol, so that a publisher may advertise a context file by three independent paths and a consumer may find it without guessing. It specifies a two-tier arrangement of an index resource and optional detail resources, states conditional-request and size requirements that keep retrieval affordable for both parties, and describes the relationship of this mechanism to the robots exclusion protocol, to sitemaps, and to work in progress on expressing AI usage preferences. This document also reports measurements from an operational deployment in which twenty crawlers operated by search and language- model providers issued 44,005 requests to a host over fifteen days without once retrieving the context file the host was serving, while the same crawlers retrieved that host's robots.txt 577 times in the three days after the context file was deployed. The absence of a discovery mechanism, rather than the absence of interest, is the hypothesis this document acts upon. |
| | Independent Determinability of Agent Actions |
| |
|
Evidence that an agent was authorized to act does not establish that the authorization was enforced, that the action was executed, or that the intended effect occurred. These are distinct transitions. This document defines requirements for making a claimed agent transition independently determinable after the original interaction has ended. The requirements address binding the material action and governing conditions to the transition at decision time, identifying which revision of a mutable governing artifact was in force, preventing later substitution, and preserving enough information for an independent evaluator to establish the claimed transition after participants, sessions, credentials, keys, or agent instances are no longer available. This document defines no evidence format, token, action identifier, delegation protocol, audit system, registry, or transparency service. |
| | terms.txt: Machine Access Terms and an Origin-Enforced Consent and Compensation Exchange |
| |
|
The Robots Exclusion Protocol lets an origin ask automated clients not to fetch certain paths. It cannot express who is asking, for what purpose, under what terms, or at what price, and it provides no server-side enforcement. This document specifies terms.txt, a file at a well-known location in the style of robots.txt that states, per path and per purpose, whether automated access is allowed, charged, or denied, at what use level, at what price, and whether a user's delegation is required. It also specifies the HTTP exchange that enforces the file at the origin: requests signed with Web Bot Auth, a signed declaration of intent, delegation tokens and payment vouchers bound to the authenticated identifier, payment negotiation signaled with Problem Details, and origin-signed receipts. The document states which properties the exchange enforces before delivery, which it can only audit afterward, and which remain contractual. |
| | Trustworthy Acquisition of Credentials via Remote Attestation |
| |
| | draft-novak-rats-tacra-01.txt |
| | Date: |
11/09/2026 |
| | Authors: |
Mark Novak, Michael Richardson, Henk Birkholz |
| | Working Group: |
Individual Submissions (none) |
|
There is a large class of "RATS-Unaware" Relying Parties (RUPs) that Attesters nevertheless need to interoperate with. Existing deployed services, which precede the introduction of Remote Attestation, are often difficult to change/update in significant ways due to, among other reasons, organizational friction, technological inertia, and regulatory policies. There are significant advantages if workloads can be incrementally updated in the trustworthiness of the platform, without disrupting their clients and servers. This document describes an architecture by which Remote Attestation is utilized for providing Attesters with Identity Documents (keys or credentials) to authenticate to RUPs. This architecture is intended to work with common credential acquisition protocols and mechanisms such as EST, SPIFFE/SPIRE, ACMEv2, and many others. Another important but separate goal is to encapsulate the Attester- side complexity of Remote Attestation and credential acquisition similar to how Envoy does it. This allows Attesters to be implemented in a way that abstracts away the details of credential acquisition: both the protocols used and the Credential Acquisition Mechanisms employed, whether minting new (Enrollment), or requesting existing (Retrieval) credentials. Likewise, the choice between RATS Passport and Background Check models is made opaque to the Attester, further simplifying its development. |
| | Virtualized Conversations (VCON) Restructure to Facilitate AI Agent Use Cases |
| |
|
The Virtualized Conversations (VCON) specification provides a structured format for storing recordings of conversations, including phone calls, email threads and multi-party chats. VCONs also store metadata like call transcripts and mid-call events, like a call hold or addition of a party. Its structure is well suited for 2-party and basic multiparty phone calls. However, there is a need for the VCON format to also act as a record of AI Agent conversations, which are just another type of conversation. This document proposes changes to the object model in VCON to make it a more suitable format for handling AI Agent conversations, as well as more complex conferencing use cases. |
| | Federated Groups in Open Cloud Mesh using Messaging Layer Security |
| |
|
This document defines an extension to the Open Cloud Mesh (OCM) protocol to support federated groups as Receiving Parties of shares. This is achieved using the Messaging Layer Security (MLS) protocol (RFC 9420) as a group management layer. MLS is used for establishing and rotating a shared group key across federated group members, as well as for maintaining group state. This gives not only a way of federating group membership, but also a standardized way of distributing encryption keys in a cryptographically secure way, so that files shared with a group can optionally be encrypted and decrypted. MLS usage in OCM acts as a vehicle for group management that gives users optional encryption capabilities for resources shared with federated groups. |
| | Open Cloud Mesh Integration Protocol |
| |
|
The Open Cloud Mesh Integration Protocol (OCM-IP) defines how an Open Cloud Mesh (OCM) Server can integrate supporting servers, such as SSH/SFTP servers, web application platforms, or stand-alone WebDAV servers, to perform protocol-specific work on its behalf. OCM-IP makes it possible for existing OCM Servers to offload protocol specific interactions to stand-alone servers, or even implement OCM as a lightweight server that handles only the OCM parts of a deployment: discovery, share creation, token issuance and signing. Anything protocol-specific, such as serving files over WebDAV, providing SSH access, or running an interactive web application, can be handed off to one or more Protocol Servers running elsewhere, possibly operated with different software and on different infrastructure. OCM-IP defines three integration modes: a provisioned mode, in which the OCM Server pushes Share information to the Protocol Server over a signed back channel; a self-contained mode, in which the Share information is embedded in the signed access token itself, so that the Protocol Server needs no per-share state and no inbound API at all; and an introspected mode, in which the Protocol Server validates presented credentials through a token introspection endpoint, restoring compatibility with Receiving Servers that do not support token exchange. OCM-IP is a protocol between the Sending OCM Server and its Protocol Servers only. The Receiving Server is not involved in, and does not need to be aware of, this protocol: everything it observes is indistinguishable from the Sending Server serving the access protocols itself. For this reason, an OCM Sending Server MAY adopt a different strategy to interoperate with Protocol Servers, including e.g. establishing trust via shared keys, without compromising compliance with the OCM protocol. |
| | A Data Manifest for Contextualized Telemetry Data |
| |
|
Network platforms use Network Telemetry, such as YANG-Push, to continuously stream information, including both counters and state information. This document describes the metadata that ensure that the collected data can be interpreted correctly. This document specifies the Data Manifest, composed of two YANG data models (the Platform Manifest and the non-normative Data Collection Manifest). These YANG modules are specified at the network level (e.g., network controllers) to provide a model that encompasses several network platforms. The Data Manifest must be streamed and stored along with the data, up to the collection and analytics systems to keep the collected data fully exploitable by the data scientists and relevant tools. Additionally, this document specifies an augmentation of the YANG-Push model to include the actual collection period, in case it differs from the configured collection period. |
| | Export of QUIC Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements to identify a set of QUIC related information, which contained in QUIC Header, QUIC Frame and Stream that traffic is being forwarded along with. |
| | Use of ML-DSA in TLS 1.3 |
| |
| | draft-ietf-tls-mldsa-06.txt |
| | Date: |
11/09/2026 |
| | Authors: |
Tim Hollebeek, Sophie Schmieg, Bas Westerbaan |
| | Working Group: |
Transport Layer Security (tls) |
|
This memo specifies how the post-quantum signature scheme ML-DSA (FIPS 204) is used for authentication in TLS 1.3. |
| | IPv6-Only and IPv6-Mostly Terminology Definitions |
| |
|
This document defines the terminology regarding the usage of expressions such as "IPv6-Only" and "IPv6-Mostly", in order to avoid confusions when using them in IETF and other documents. The goal is that a reference to "IPv6-Only" describes the actual functionality being used in a given scope, not the installed protocol support. |
| |
|
| |
| | Automated Certificate Management Environment (ACME) Remote Attestation Identifier and Challenge Type |
| |
| | draft-ietf-acme-rats-02.txt |
| | Date: |
10/09/2026 |
| | Authors: |
Peter Liu, Mike Ounsworth, Michael Richardson, Ganesh Mallaya |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document describes an approach where an ACME Server can challenge an ACME Client to provide Evidence, Endorsements, or Attestation Result according to the Remote ATtestation procedureS (RATS) framework in any format supported by the Conceptual Message Wrapper (CMW). The ACME Server can optionally challenge the Client for specific claims that it wishes attestation for. |
| | A YANG Data Model for Passive Network Inventory |
| |
|
This document presents a YANG data model for tracking and managing passive network inventory. The model augments the base network inventory model. |
| | SMTPUTF8 Email Addresses |
| |
|
RFC 6532 extends the internet email format to allow UTF8 in many contexts. This document restricts the set of allowed addresses in header fields slightly, and thereby simplifies use of these addresses. This is one of a pair of documents. This one is simple to implement and contains only globally viable rules. Its companion has more complex rules, takes regional usage into account, and describes addresses that can be read by some community and cut-and-pasted in some locale. |
| | Encapsulation of Simple Two-Way Active Measurement Protocol for LSPs and Pseudowires in MPLS Networks |
| |
| | draft-ietf-mpls-stamp-pw-21.txt |
| | Date: |
10/09/2026 |
| | Authors: |
Rakesh Gandhi, Patrice Brissette, Eddie Leyton, Xiao Min |
| | Working Group: |
Multiprotocol Label Switching (mpls) |
|
This document specifies encapsulations for the Simple Two-Way Active Measurement Protocol (STAMP), defined in RFC 8762, and its optional extensions, defined in RFC 8972, in MPLS networks. It specifies the encapsulation of STAMP test packets for point-to-point Label Switched Paths (LSPs) and point-to-point single-segment Pseudowires (PWs), with or without an IP/UDP header, so that the test packets experience the same forwarding and Equal-Cost Multi-Path (ECMP) behavior as the data traffic being measured. In addition, two new MPLS Generic Associated Channel (G-ACh) types are defined. The procedures specified in this document are intended for deployment in a single network administrative domain. This document updates RFC 8762 and RFC 8972 to allow STAMP to operate without an IP/UDP header when STAMP test packets are carried over MPLS LSPs and PWs, and specifies the resulting changes to the processing of the STAMP session identifier, the IPv4 TTL and IPv6 Hop Limit, and the STAMP TLV extensions. |
| | NETCONF Call Home and RESTCONF Call Home Using QUIC |
| |
|
This RFC extends NETCONF Call Home and RESTCONF Call Home [RFC 8071] to support the QUIC protocol [RFC 9000]. |
| | Security for the NFSv4 Protocols |
| |
|
This document describes the core security features of the NFSv4 family of protocols, applying to all minor versions. The discussion includes the use of security features provided by RPC on a per- connection basis. Important aspects of the authorization model, related to the use of Access Control Lists, will be specified in a separate document. The current version of the document is intended, in large part, to result in working group discussion regarding existing NFSv4 security issues and to provide a framework for addressing these issues and obtaining working group consensus regarding necessary changes. When the resulting documents (i.e. this document and one derived from the separate ACL specification) are eventually published as RFCs, they will, by updating these documents, supersede the description of security appearing in existing minor version specification documents such as RFC 7530 and RFC 8881. |
| | IPlir network layer security protocol |
| |
| | draft-iplir-protocol-10.txt |
| | Date: |
10/09/2026 |
| | Authors: |
Martishina Alexandra, Urivskiy Alexey, Rybkin Andrey, Parshin Ilia, Leonid Tychina |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies the IPlir network layer security protocol. It describes how to provide a set of security services for traffic over public and corporate networks using the TCP/IP stack. |
| | A Larger Internet Key Exchange version 2 (IKEv2) Payload |
| |
|
The messages of the Internet Key Exchange version 2 (IKEv2) protocol are made up of payloads. The current protocol limits each of these payloads to 64KB by having a 2-byte length field. While this is usually enough, several of the payloads may need to be larger. This document updates RFC 7296 by defining an extension that allows larger payloads. |
| | A Profile of Signed SAVNET-Peering Information (SiSPI) Object for Deploying Inter-domain SAVNET |
| |
|
This document defines a "Signed SAVNET-Peering Information" (SiSPI) object, a Cryptographic Message Syntax (CMS) protected content type included in the Resource Public Key Infrastructure (RPKI). A SiSPI object is a digitally signed object that carries an attestation for a single Autonomous System (AS) participating in inter-domain SAVNET. A valid SiSPI object confirms that the holder of the listed AS number has published the attestation indicating its participation in inter- domain SAVNET and its willingness to establish SAVNET peering relationships. |
| | Unicast Support for the Virtual Router Redundancy Protocol (VRRP) |
| |
|
The Virtual Router Redundancy Protocol (VRRP) Version 3 as specified in RFC 9568 assumes multicast operation on a shared LAN. Some deployments require the VRRP first-hop redundancy function but cannot use multicast delivery for VRRP advertisements. This document updates RFC 9568 by defining an optional configured unicast mode for VRRP Version 3 in which advertisements are sent to configured peer addresses rather than to the VRRP multicast group. The VRRP packet format, state machine, protocol number, virtual IP semantics, and Virtual Router MAC behavior remain unchanged from RFC 9568. |
| | The Delegation HTTP Authentication Scheme for Request-Bound Authority |
| |
|
Delegated software requesters increasingly make HTTP requests that spend, consume, disclose, mutate, invoke, or actuate on behalf of human or organizational principals. Existing HTTP authentication mechanisms indicate whether a requester holds a credential. RateLimit fields communicate server-advertised quota and current service-limit information. HTTP Message Signatures can protect selected components of an HTTP message. None of these mechanisms directly defines a common origin-server challenge for a requester to present verifiable, bounded authority from its principal before the server performs protected processing. This document defines the "Delegation" HTTP authentication scheme, response semantics for delegated-authority challenges using existing HTTP status codes and Problem Details, the Delegation-Proof HTTP field, and a COSE/CBOR proof carriage model for request-bound delegated authority. The initial authority profile is the Budget profile, which uses a CBOR/COSE Budget-Attestation envelope to prove bounded authority to spend, consume metered service units, or commit bounded resources. The mechanism is algorithm-agile; the initial cose-ml-dsa proof profile uses existing JOSE and COSE serializations for ML-DSA, with ML-DSA-65 as the baseline algorithm and ML-DSA-87 available as a high-assurance deployment policy option. A dedicated 4NN Delegated Authority Required status code remains an open design question for HTTP Working Group review; this revision does not depend on that status code and does not define payment semantics. This revision also defines a mandatory-to-implement preflight flow for large proof profiles so that GET and HEAD requests do not depend on request content, and so that requests with application representations do not need to multiplex the application body and the proof body in a single content stream. For implementation experience, this individual draft also includes the initial Budget authority profile. The HTTP authentication scheme, status-code semantics, Problem Details members, and field- carriage rules are intentionally separable from the COSE/CBOR Budget profile. If a Working Group chooses to progress the HTTP mechanism independently, the Budget authority profile can be moved to a companion profile document without changing the Delegation challenge semantics defined here. |
| | Use Cases and Applicability for Discovery of Agents With Names |
| |
|
This document describes use cases and applicability for Discovery of Agents With Names (DAWN). It illustrates how clients discover AI resources and obtain the minimum information needed for subsequent interaction within a local network, within an organisation, or between cooperating organisations with trust relationships. This document does not define a discovery protocol, a registration procedure, a selection algorithm, or an agent-to-agent communication protocol. |
| | OAuth Authorization Request Delegation Chain |
| |
|
Brokered OAuth redirect authorization requests involve intermediary authorization servers between a downstream client and the upstream authorization server that obtains user consent and issues tokens. Such deployments have security risks because the upstream authorization server sees only the immediate OAuth client and is unaware of the downstream client or intermediary brokers obtaining its response. This document defines an OAuth 2.0 profile for carrying a verifiable, signed authorization request delegation chain as a RAR authorization_details object [RFC9396]. Each node in the chain is a JSON object signed by an attesting authorization server using detached JWS [RFC7515], attesting its validated client, hash-linked to the previous node, allowing the upstream authorization server to validate the integrity of the visible delegation path and apply policy before issuing tokens. |
| | A Structured Value Model for Derived Identifiers |
| |
|
Derived identifier constructions that combine local material with identifiers from other systems need a defined comparison domain. This document defines a structured value model for such constructions and their profiles. A Value contains exact context octets, exact content octets, and a finite set of scoped opaque identifiers. Structural admission and equivalence are independent of serialization. Equality includes context, content, and complete identifier-set membership. The specification gives source mappings and profiles common obligations for fixed inputs, imported comparison adaptation, and preservation of participation distinctions. Surrounding specifications define concrete mappings, representations, identifier derivations, and the shared interpretation needed for interoperability. The model defines no global semantic namespace, wire format, cryptographic construction, or trust mechanism. |
| | A YANG Data Model for Power State Capability Discovery |
| |
|
This document defines a YANG data model that augments the system capabilities model of RFC 9196 to allow a network element to advertise, per hardware Component, the set of Power States that the Component supports, together with a static characterization of each such state: the expected and maximum Power the Component draws in it, and the time to enter and exit it. This capability model complements the operational Power and Energy data model defined in the GREEN Power and Energy YANG module, which reports the current Power State and the measured Power of a Component, but not which Power States are available, how much Power each draws, or how long transitions between them take. It is anchored to the hardware inventory of RFC 8348, reuses the Power State identities of the GREEN Power and Energy model, and, because it is static, may be provided at implementation time as YANG instance data per RFC 9195 so that an Energy Management System can learn a platform's Power State capabilities before the equipment is deployed or even powered on. |
| | Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems |
| |
|
This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. An agentic model can emit a tool call that today's runtimes treat as something to execute. Allowlists, OAuth tokens, MCP server auth, sandboxes, output filters, and human approval decide whether an agent may reach a tool. They do not decide whether this generated call, with this argument digest, from this instruction chain, at this delegation depth, may take effect now. That gap is the incident surface. Prompt-injected content, poisoned retrieval, a malicious tool response, or a delegated sub-agent can produce a call that looks like ordinary tool use. If the dispatcher executes whatever the model selected, policy that lived upstream becomes advisory. This document specifies a dispatch-time gate. The model may compute a call. The call remains a Candidate Act. A Protected Enforcement Domain binds agent, tool, arguments, purpose, destination, provenance, and policy epochs, then issues scoped non-bearer authority. A Tool-Dispatch Finality Sink verifies that authority against the actual invocation immediately before the tool runs, then consumes it. The same gate applies to support, coding, payments, clinical, SOC, browser-use, and multi-agent MCP deployments. Tool selection is not execution authority. A runnable reference implementation for this dispatch-time gate is provided at tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP (https://github.com/sangmdas/ tool_use-Is-Not-invoke-Binding-Execution-Finality-to-Agentic-Tool- Call-Interfaces-and-MCP). |
| | Contestability Bindings for Authorized Agent Actions |
| |
|
Authorization artifacts can provide signed evidence of a permission under specified authorization rules. Receipts can record a signed claim or protocol event that the authorization was exercised, and outcome evidence can describe what followed. None of those artifacts necessarily tells a person or organization affected by the action where the authorization can be contested, which procedure applies, whether a filing changes execution state, or who selected the contestation forum. This document defines a transport-independent Contestability Binding for authorized agent actions. The binding commits an authorization to a versioned Contestation Parameters Object that identifies the forum, submission mechanism, Standing Policy, procedure, time bounds, declared effect policy, and selection evidence. A forum can acknowledge one exact authorization or publish a reusable acceptance manifest for closed Authorization Binding Profile and Authorization Trust Profile identifier pairs. A deterministic verifier validates the binding, separately classifies evidence claiming pre-execution verification by the executor, and reports forum-selection provenance as unilateral, multiparty, externally selected, or indeterminate. Where a filing is declared to affect execution state, the verifier also separates the issuer's declared policy, the executor's signed acceptance, the authenticated trigger, and the executor's claimed application. The mechanism makes the bound contestation parameters identifiable and verifiable, supporting discoverability while resisting post- action substitution. It does not determine standing, prove forum independence, resolve a dispute, select a remedy, establish legal enforceability, or decide whether the original authorization was legitimate. |
| | An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive,High-Priority Frontier AI Model Information |
| |
|
This architecture is a hardware-rooted defense against intellectual- property theft of frontier AI models, intended for deployment by AI model creators themselves -- including trillion-dollar frontier-model providers such as OpenAI and Anthropic -- rather than for generic, day-to-day AI use by an end user. It protects Sensitive Model Information that is high-priority and dual-use, with the specific purpose of preventing unauthorized extraction and distillation of the model itself. The architecture introduces bounded, deterministic evaluation latency to intercept unauthorized release paths, a trade- off acceptable specifically for protecting highly valued dual-use assets where standard optimization for raw speed is subordinate to absolute asset security. Frontier and proprietary AI deployments may contain or expose model- related information substantially richer than ordinary final-answer text. Depending on the deployment and interface, such Sensitive Model Information (SMI) can include detailed probability information, embeddings, cached intermediate state, hidden representations, intermediate activations, diagnostic information, model-related metadata, or other high-information artifacts. Repeated unauthorized or excessive release of such information can increase the efficiency of model reconstruction, imitation, extraction, or distillation. Authentication establishes who is requesting an operation. Confidential computing and remote attestation can establish properties of the environment in which computation occurs. Neither property alone determines whether a particular pending release of particular model information, to a particular destination, under the current extraction state and security epoch, remains authorized to become externally usable. This document describes an execution-finality architecture for that remaining problem. Sensitive information may be computed while remaining a non-effective Candidate Release. External release occurs only after release-specific protected validation, evaluation of rollback-resistant extraction state where required, atomic reservation or consumption of bounded authority, and verification at a controlled Finality Sink. Release authority is bound to the applicable Candidate Release or bounded release class rather than operating as a generic transferable bearer credential. The architecture does not claim universal prevention of model extraction or distillation and does not restrict legitimately exposed ordinary model output. Its narrower objective is to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete through governed release paths. RATS can complement this mechanism by allowing a Verifier or Relying Party to obtain machine-verifiable information about whether the expected release-control mechanism, protected state, security epoch, and Finality Sink are present and operating with the required assurance properties. To demonstrate that this architecture is practically achievable and not merely theoretical, a runnable reference implementation is provided at Execution-Finality for Protected AI Model-State Release -- RATS Reference Implementation (https://github.com/sangmdas/ Execution-Finality-for-Protected-AI-Model-State-Release-RATS- Reference-Implementation). |
| | Attestation-Bound Execution Finality for GPU,AI Accelerator,DPU,SmartNIC,and Confidential-Computing Infrastructure |
| |
|
Remote attestation can establish that a CPU, confidential virtual machine, GPU, AI accelerator, DPU, or SmartNIC is running expected firmware and software in an expected configuration. However, an acceptable Attestation Result describes the execution environment, not the operations it later emits; it remains the same whether subsequent workload outputs arise from expected logic, prompt injection, or model error. As AI workloads become agentic and move onto confidential accelerator infrastructure, they emit high- consequence operations, such as financial transfers, cloud-control mutations, database deletions, and external API invocations, where platform trustworthiness alone cannot determine whether a concrete operation is authorized to take effect. OAuth access tokens, transaction tokens, and workload credentials do not close this gap on their own: they typically authorize by scope and by possession of a credential rather than by the exact content of one operation, and they do not require that the protected effect be unreachable except through a verifying boundary. This document describes an attestation-bound execution-finality architecture that bridges platform appraisal and consequence-bearing authorization. A consequential operation originates in a non- effective state as a Candidate Act. An Execution-Finality Validator evaluates the act's security-relevant arguments together with the platform's Attestation Result, workload identity, and policy, and issues an act-bound, single-use, non-bearer Execution Handle. A Finality Sink verifies that handle at the non-bypassable boundary where the operation would first acquire external effect, so that an authorized act cannot be swapped, mutated, or replayed. The architecture requires no changes to silicon, microcode, firmware, drivers, or accelerator programming models, and it separates concerns: platforms such as NVIDIA confidential-computing GPUs and BlueField DPUs, Arm Confidential Compute Architecture (CCA), AMD SEV- SNP, and Intel TDX supply environment appraisal on the cold path, while enforcement is placed at the gateway, service-mesh, DPU or SmartNIC, network, or storage boundary. On the hot path, verification uses local cryptographic bindings and single-use checks rather than repeated attestation round trips. The document discusses its relationship to RATS, WIMSE, OAuth, and related IETF work, and its engineering FAQ addresses platform layering, DPU visibility under end-to-end encryption, tail latency, and other anticipated critical questions. It is intentionally long because it is explanatory rather than a protocol specification. The architecture is implemented, not only described. An executable reference implementation (GitHub: reference implementation, tests, benchmarks, and deployment materials, https://github.com/sangmdas/ Execution-Finality-for-GPU-AI-Accelerators-and-Confidential- Workloads) demonstrates act binding, single-use enforcement, and replay rejection in running code. It uses a software-only attester; it has not been run on any vendor's confidential-computing hardware and does not consume any vendor-issued attestation token, and vendor platforms are discussed on the basis of public documentation only. This document is vendor-neutral, neither claims nor implies review, adoption, endorsement, or affiliation by any named vendor, and complements rather than replaces existing attestation, workload- identity, and authorization mechanisms. |
| | Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies |
| |
|
This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. The European Union Artificial Intelligence Act establishes an extensive paper-based governance regime for artificial intelligence: risk-management documentation, data-governance records, conformity assessments, human-oversight instructions, transparency notices, logging obligations, and post-market monitoring plans. These instruments are necessary, and this document does not propose to discard them. They are not, however, sufficient by themselves once an AI system can autonomously or semi-autonomously act at machine speed, because a document can only describe what an operation should do; it cannot, by itself, make an operation technically incapable of doing otherwise. This is not a problem unique to the European Union. South Korea's AI Basic Act regulates "high-impact AI" through comparable risk- management, human-oversight, and documentation duties. Japan's AI Act, in force since September 2025, takes a lighter, more promotion- oriented approach but still assumes that written governance is the primary control. China enforces a binding but differently structured set of algorithm-recommendation, deep-synthesis, generative-AI, and AI-content-labelling rules. Texas and Colorado have each enacted state-level AI statutes in the United States with disclosure and consequential-decision obligations, and Brazil's PL 2338/2023 and Canada's lapsed AIDA proposal show the same EU-style risk-based model spreading, whether or not yet enacted. Every one of these regimes, whatever their legal differences, shares the identical underlying engineering gap this document addresses: a written rule, however well drafted, does not by itself make a machine unable to break it before anyone can react. The gap is most consequential precisely where the stakes are highest. In defence-relevant AI, critical-infrastructure control systems, and satellite or space-system automation, an autonomous agent can select a target, reroute power or water, transfer control of a physical asset, or transmit a command to an orbital platform within a single inference cycle -- before any operator, reviewer, regulator, or after-the-fact investigation can intervene. If that act causes harm, two questions follow immediately: who is liable, and at what cost. A risk-management file, a conformity-assessment certificate, or an audit log written after the fact can show that a rule existed; none of them can show that the machine was technically incapable of breaking it, and none of them limits the cost already incurred by the time the record is examined. For these classes of system, the appropriate default when an authorization cannot be verified is not "log it and investigate later"; it is fail-closed: the act simply does not occur. This document describes an execution-finality architecture that converts a selected, already-determined AI-governance requirement from a document into a mandatory, machine-verifiable precondition of the AI-generated operation itself. A consequential AI-generated operation is first represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of invoking a tool, actuating a device, transmitting a command, or otherwise causing an external consequence -- until a Protected Enforcement Domain validates the machine-readable constraints applicable to that exact act, including the AI system identity, permitted operation, target, recipient, destination, required human-oversight state, transparency marker, risk-control status, policy epoch, and revocation state. Successful validation produces narrowly scoped, act-bound effectuation authority; a Finality Sink positioned at the point of first usable external effect independently re-verifies that exact authority, and the current required state, immediately before the consequence is permitted to occur. Absent, stale, revoked, or unverifiable authority results by default in no effect, not in a warning. The same architecture accepts a jurisdiction-specific governance profile as an input, so that an EU AI Act profile, a Korean AI Basic Act profile, or another national profile can each supply the machine-readable constraints for the identical enforcement mechanism without this document taking a position on how those laws relate to one another. This document does not determine whether an AI system is legally high-risk under Annex III, whether a practice is prohibited under Article 5, whether a conformity assessment is valid, whether human oversight under Article 14 is legally sufficient, or whether an organisation complies with the Regulation as a whole, nor does it make any equivalent determination under another jurisdiction's law. Those determinations remain outside the protocol and must be made by the responsible legal, regulatory, or organisational authority. This document addresses the narrower engineering problem that arises only after such a determination has already been made: once an applicable governance requirement has been translated into a machine-readable constraint, how can satisfaction of that constraint be made technically necessary before the corresponding AI-generated consequence becomes effective? This document does not advocate replacing paper-based AI governance for general-purpose or low-consequence AI applications, where the cost and rigidity of execution-level enforcement would be disproportionate to the risk. The architecture is proposed specifically for high-criticality AI deployments -- defence and dual- use systems, critical infrastructure, satellite and space systems, and comparably consequential autonomous or agentic systems -- in which an unauthorised act is not merely a compliance finding but a matter of physical safety, national security, or irreversible loss, and in which liability and cost must be bounded by making the unauthorised act technically non-completable rather than merely detectable afterward. Cross-regime use is treated as a profile-input problem rather than as legal harmonisation. An EU AI Act profile, a South Korean AI Basic Act profile, a Japanese AI Act profile, or another national, sectoral, or contractual profile can each supply machine-readable constraints to the same Candidate Act / Protected Enforcement Domain / Finality Sink mechanism. Where profiles are compatible, the effective authority is their intersection; where they conflict, the act remains unauthorised by default pending an external legal or organisational determination. That is the maximum interoperability claim this document makes: a shared enforcement substrate, not equivalence of laws, not a conflict-of-law solver, and not a finding that any listed regime is legally sufficient or interchangeable. A primary public reference implementation accompanies this document at https://github.com/sangmdas/Execution-Finality-Technical- Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints (https://github.com/sangmdas/Execution-Finality-Technical- Enforcement-for-EU-AI-Act-and-AI-Governance-Constraints). It is a runnable engineering reference for the substrate and selected AI- governance predicates (human-approval binding, runtime evidence, delegation bounds, bounded offline mode, policy-epoch revocation, and profile intersection). It is not a legal-compliance product, not a certification, and not evidence that any deployment using it complies with the EU AI Act or another law. Reviewer questions that recur in this series -- cross-regime generalisation, deterministic runtime bounds for dynamic agentic plans, interaction with Article 14 human oversight, and audit responsibility -- are collected as frequently asked questions in Section 43. Trust-boundary, insider-approval, sink-failure, delegation, liability, and residual-limitation questions are treated as a threat model and operational caveat set in Section 44 and Section 38. Those sections state what the architecture can and cannot claim. Independent technical and legal criticism is invited; the author would rather have the limits of execution-finality found in review than have them discovered after a protected effect has already occurred. |
| | Agent Run Metrics: A JSON Interchange Format for Resource Accounting of Language-Model Agent Runs |
| |
|
Autonomous software agents driven by large language models execute multi-step runs in which the same conversational context is retransmitted to a model on every step. The resulting resource consumption is dominated by repeated input rather than by generated output, and it is reported today in mutually incompatible, vendor- specific shapes. This document defines Agent Run Metrics, a JSON interchange format that describes the resource consumption of a single agent run and of its constituent steps, together with a small set of derived quantities whose computation is specified exactly. It states normatively that one reported step corresponds to one completed model invocation, so that the several records a runtime may write while a single response is produced are not mistaken for several invocations, and it defines how the consumption of delegated sub-runs is attributed without being counted twice. The format carries counters, timing and cost attribution only; it deliberately excludes prompt and completion content. This document also registers the associated media type and creates IANA registries for extensible enumerations. |
| | The Evil Byte: A Security Octet for the IPv4 and IPv6 Headers |
| |
|
Firewalls, intrusion detection systems, and similar devices continue to have difficulty distinguishing packets that have malicious intent from those that are merely unusual. RFC 3514 addressed this problem by defining a security flag in the IPv4 header, the "evil bit", to be set by the sender of any packet with malicious intent. Twenty-four years of operational experience have shown that senders cannot be relied upon to set it, and that a single bit cannot express the range of Evil now observed on the Internet. This document obsoletes RFC 3514, replacing the evil bit with the Evil Byte: an eight-bit Evil Rating carried in every IPv4 and IPv6 packet, computed and set not by the sender but by a Morality- Inspecting Trusted Middleman (MITM) on the path, from a weighted product of the sender's Autonomous System, choice of protocols, content, name, and the time of day. Servers reject requests from Evil clients; clients discard responses from Evil servers; and the Evil of every Autonomous System is continuously re-estimated by an Elo rating system operated by a central Evil Rating Authority. The document also specifies the carriage of the octet over avian carriers. |
| | Product Security Fields for security.txt |
| |
|
This document registers two new fields for the security.txt file format defined in RFC 9116: "Product-Security" and "Product-Security- Policy". They allow an organisation to publish a dedicated contact and disclosure policy for vulnerabilities in the products it manufactures, distinct from the contact for vulnerabilities in its own web presence and infrastructure. The fields are optional and fully backward compatible with existing security.txt parsers. |
| | Transaction Token Authorization Grant Profile for OAuth Identity and Authorization Chaining |
| |
|
This specification defines a profile of the OAuth Identity and Authorization Chaining Across Domains [I-D.ietf-oauth-identity-chaining] mechanism that uses a Transaction Token (Txn-Token) [I-D.ietf-oauth-transaction-tokens] as the subject token in a Token Exchange [RFC8693] request to obtain a JWT Authorization Grant for crossing a trust boundary. A Txn-Token is scoped to a single trust domain and represents the full authorization context of an in-progress transaction, regardless of whether that transaction was initiated by a human user calling an external API, by an internal system event, or by an automated workload. This profile specifies how a service operating within that trust domain can present its Txn-Token to obtain a JWT Authorization Grant that carries the necessary context across a trust boundary, enabling an access token to be issued for a partner service, without exposing internal trust-domain credentials or token formats beyond the trust boundary. |
| | QUIC Profile for Deep Space |
| |
|
Deep space communications involve long delays (e.g., the Earth to Mars one-way delay is ~4-20 minutes) and often intermittent communications. In this context, the default transport parameters of QUIC stacks, tuned for the terrestrial Internet, are not suitable for deep space. This document defines a QUIC profile for deep space. It provides guidance on how to estimate and set transport parameters, advice to space mission operators and application developers on how to configure QUIC for the deep space use case, and guidance to QUIC stack developers on properly exposing the required transport parameters in their API. |
| | A Flags Extension for TLS 1.3 |
| |
|
A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. |
| | IPv6-mostly Networks: Deployment and Operations Considerations |
| |
|
This document discusses a deployment scenario called "an IPv6-mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). The proposed approach enables smooth and incremental transition from dual-stack to IPv6-only network by allowing IPv6-capable devices to remain IPv6-only while the network is seamlessly supplying IPv4 to those that require it. |
| |
|
| |
| | A Voucher Artifact for Onboarding Protocols |
| |
| | draft-ietf-anima-rfc8366bis-36.txt |
| | Date: |
09/09/2026 |
| | Authors: |
Kent Watsen, Michael Richardson, Esko Dijk, Toerless Eckert, Qiufang Ma |
| | Working Group: |
Autonomic Networking Integrated Model and Approach (anima) |
|
This document defines a strategy to securely assign a candidate device (Pledge) to an Owner using an artifact signed, directly or indirectly, by the Pledge's manufacturer. This artifact is known as a "Voucher". This document defines an artifact format as a YANG-defined JSON or CBOR document that has been signed using a variety of cryptographic systems. The Voucher Artifact is normally generated by the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA)). This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module. The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995. |
| | RTP Control Protocol (RTCP) Messages for Temporal-Spatial Resolution |
| |
|
The RTCP messages specified in this document enable receivers to provide feedback to the senders and thus allow for short-term adaptation and feedback-based energy efficient mechanisms to be implemented. The messages have broad applicability in point-to-point real-time video communication services. Specifically, the messages can be used to convey the video decoder feedback metadata to the encoder to adapte the decoder energy consumption as defined in the ISO/IEC International Standard 23001-11, known as Energy Efficient Media Consumption (Green metadata), developed by the ISO/IEC JTC 1/SC29/WG3 MPEG Systems. |
| | DKIM2 Best Practices |
| |
|
[DKIM2] and its associated documents describe the DomainKeys Identified Mail v2 (DKIM2) email authentication protocol. DKIM2 is designed to address shortcomings in email authentication protocols and mechanisms released prior to DKIM2, specifically SPF [RFC7208], DKIM [RFC6376], DMARC [RFC9989], and ARC [RFC8617]. This document discusses best practices for signing, handling, and validating messages that carry DKIM2 signatures, and for interoperating with the authentication protocols and mechanisms that preceded DKIM2. |
| | Power and Energy YANG Module |
| |
|
This document defines the YANG data model for Power and Energy monitoring of devices within or connected to communication networks. |
| | The Purpose Declined HTTP Status Code |
| |
|
This specification defines an HTTP status code to indicate that the server is denying a request based upon its declared purpose. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet IP Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-to-Edge (E2E) active measurements. In Situ Operations, Administration, and Maintenance (IOAM) data fields can be used for recording and collecting Hop-by- Hop (HBH) and E2E operational and telemetry information. This document extends STAMP to reflect IP headers as well as IPv6 extension headers for HBH and E2E active measurements, for example, using the IOAM data fields. This document specifies the requirements for IPv6 STAMP in unauthenticated mode using UDP zero-checksum, which deviates from the integrity requirement in RFC 6936. |
| | Use of KMAC and SHAKE in the Internet Key Exchange Protocol Version 2 (IKEv2) and IPsec |
| |
|
This document specifies the use of KMAC128 and KMAC256 within the Internet Key Exchange Version 2 (IKEv2), Encapsulating Security Payload (ESP), and Authentication Header (AH) protocols. These algorithms can be used as integrity protection algorithms for ESP, AH and IKEv2, and as Pseudo-Random Functions (PRFs) for IKEv2. Requirements for supporting signature algorithms in IKEv2 that use SHA3-256, SHA3-384, SHA3-512, SHAKE128 and SHAKE256 are also specified. |
| | Safe and Reversible Sharing of Malicious URLs and Indicators |
| |
|
This document codifies a consistent and reversible convention used in the threat intelligence and security communities for sharing potentially malicious indicators of compromise (IOCs), such as URLs, IP addresses, email addresses, and domain names. It describes an obfuscation format that reduces the risk of accidental execution or activation when IOCs are displayed or transmitted. The transformation renders an indicator syntactically invalid as a URI while keeping it recognizable to a human reader, and the original value can be recovered deterministically. Safe-IOC strings are a textual rendering convention, not URIs, and are not intended to be processed by generic URI parsers. These conventions aim to improve interoperability among tools and feeds that exchange threat intelligence data. |
| | A YANG Data Model for CMIS Access and Control |
| |
|
This document provides YANG data models for accessing and controlling CMIS in order to manage pluggable Digital Coherent Optics transceivers equipped in a router or a switch from outside the platform device. CMIS provides custom pages that can be defined by the module vendor for its own usage, allowing the capabilities of the optics devices to be extended. These YANG modules also allow the utilization of CMIS custom pages as a generic control mechanism. The models complement abstracted data models for coherent pluggables: they provide governed access to opaque, vendor-specific attributes (e.g., those exposed via CMIS custom pages) and a transitional path for standardized features that the host NOS does not yet support. |
| | Some Anachronisms and Gaps in IETF Standards Process Documents |
| |
|
This document discusses some aspects of documents describing the IETF standards process that have been overtaken by events, as well as identifying some gaps. It covers the six-month expiry of Internet- Drafts, the reality of the two-stage standards process, and various other issues. This draft is posted only to open a discussion. |
| | A Power Conserving Path Placement Strategy (PCPPS) |
| |
|
This document introduces a Power Conserving Path Placement Strategy (PCPPS). During periods of low demand, PCPPS concentrates traffic onto a small set of network resources. This causes other network resources to become idle or nearly idle. When demand increases, PCPPS redistributes traffic as required. |
| | Security Operations Fundamentals and Guidance |
| |
|
Security operators are responsible for detecting malicious activity, responding to threats and defending their networks and systems from cyber attacks. Security operations are commonly entwined with other operational and management priorities to ensure that both security and operational priorities are considered holistically. With security operators being a crucial part of operation, management and security of the network, it is valuable to give consideration to them during the design of new protocols. This document builds upon draft-ietf-opsawg-rfc5706bis, describing the fundamentals of security operations to provide a foundation for considerations for protocol design and guidance. This document also describes how security operations considerations can be most usefully included in other IETF documents. |
| | IPv6 Mapping Prefix PDU for the RPKI-Router Protocol |
| |
|
This document defines a new Protocol Data Unit (PDU) type for the RPKI to Router Protocol to convey Mapping Origin Authorization (MOA) information from RPKI caches to routers. The new PDU, named the "IPv6 Mapping Prefix" PDU, carries the authorization mapping between one or more IPv4 prefix and their corresponding authorized IPv6 mapping prefix. This extension enables routers to perform Mapping Origin Validation (MOV) for IPv4-to-IPv6 address mapping announcements in IPv6-only underlay networks. |
| | The "Payment" HTTP Authentication Scheme |
| |
| | draft-httpauth-payment-01.txt |
| | Date: |
09/09/2026 |
| | Authors: |
Brendan Ryan, Jake Moxey, Tom Meagher, Jeff Weinstein, Steve Kaliski |
| | Working Group: |
Individual Submissions (none) |
|
This document defines the "Payment" HTTP authentication scheme, enabling HTTP resources to require a payment challenge to be fulfilled before access. The scheme extends HTTP Authentication, using the HTTP 402 "Payment Required" status code. The protocol is payment-method agnostic, supporting any payment network or currency through registered payment method identifiers. Specific payment methods are defined in separate payment method specifications. |
| | Bounded Capability Receipts and Durable Spend Control for Agent Actions |
| |
|
Agents sometimes need bounded authority to perform more than one consequential action without obtaining a new human approval for every operation. A signed token alone cannot enforce a shared budget across replicas, survive retries safely, or distinguish an operation that never crossed an effect boundary from one whose outcome is unknown. This document defines a bounded capability receipt and a durable reserve-admit-reconcile protocol. The receipt binds an issuance authorization, a closed action scope, a budget with explicit units, a holder proof, an expiry, and any parent capability. The state protocol atomically refuses overspend and operation-key replay, fences concurrent owners, and charges an indeterminate operation when an external effect may have occurred. Delegation transfers rather than copies authority: all direct child allocations are funded by committed parent operations before child registration, and their aggregate cannot exceed the parent balance within one authoritative atomic state domain. It also defines narrowing-only delegation, explicit revocation inheritance for delegated authority, an optional admission-control epoch that can freeze new consequence admission, and evidence interfaces. It does not make a bearer token into human approval, does not provide cross-domain or offline global double- spend prevention, and does not claim that an authorized action was safe, lawful, or successfully executed. |
| | External-Registry DNS Resource Record Types: UNECE and ISO |
| |
|
This document defines two DNS resource record types, UNECE and ISO, which convey numeric values paired with codes drawn from registries maintained by external standards organizations: the United Nations Economic Commission for Europe (UNECE) and the International Organization for Standardization. Neither proposed RRTYPE duplicates the external registries into IANA registries; each carries codes verbatim and uses the semantics defined by the external maintainer. The document specifies presentation and wire formats for both types, records the assignment of two decimal RRTYPE identifiers under the Expert Review process of BCP 42, and suggests a common design pattern that may serve as a model for future RRTYPEs seeking to make external registries usable from the DNS without duplication. |
| | The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority |
| |
|
TLS tells you the channel is authentic. OAuth tells you the caller holds a valid grant. HTTPS tells you the origin is who it claims to be. EMV tells you a payment cryptogram is transaction-specific. None of these mechanisms answer a question that autonomous, machine- speed systems now raise on every turn: is _this specific act_, generated by _this_ model, agent, or workload, at _this_ moment, actually authorized to become externally effective? Large language model agents, autonomous cloud workloads, and machine- to-machine network functions increasingly compute, decide, and act inside a single event loop, at latencies where no human, log reviewer, or downstream audit process can intervene before an API call fires, a payment settles, a file leaves the enterprise boundary, or a physical actuator moves. Transport, authentication, and authorization protocols were designed for a world in which the gap between "this request was generated" and "this request had a chance to be reviewed" was measured in human-relevant time. That gap has collapsed to milliseconds. Existing protocol layers were never built to close it, because the question they answer -- identity, channel integrity, delegated scope -- is a necessary but categorically different question from whether _this act, right now, should be allowed to leave computation and become consequence_. This document specifies an architectural pattern, execution finality, that treats every machine-generated operation as a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority -- purpose, destination, jurisdiction, freshness, revocation state, policy epoch, and runtime integrity -- and issues a narrowly scoped, non-bearer Execution Handle bound to that act and to a specific Finality Sink, the first boundary at which the act would otherwise become externally effective. The document formalizes the vocabulary, a cold-path/hot- path split for latency-sensitive deployment, a structured threat model with adversary-facing pseudocode, an incremental migration path for coexistence with TLS, HTTPS, OAuth, and EMV rather than replacement of them, and worked examples spanning AI agents, payments, telecommunications, cloud infrastructure, satellite command, industrial control, and robotics. The central claim is narrow and falsifiable: _computation does not itself confer authority for consequence_, and no general, cross- domain Internet layer currently makes that separation a structural property of the release path rather than an application-specific convention. This document is intended to solicit IETF community review of whether that gap is real, whether it is already covered by existing or in-progress work, and if not, which venue should take it up. This document describes a patent-pending architectural concept. Any intellectual-property rights or disclosure obligations relating to implementation are outside the technical scope of this document and are subject to applicable IETF IPR procedures, including BCP 79. |
| | Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI,MCP Tool Calls,and Industrial Agents |
| |
|
Neural AI systems -- large language models, vision-language models, and other learned decision systems -- now move directly from computation to consequence. A model output becomes a tool call; a tool call becomes an API transaction, memory write, payment, file mutation, browser action, or actuator signal; an agent delegates to another agent. Successful inference, sandbox containment, connector allowlisting, session permission, or upstream model approval does not by itself establish authority for that particular real-world consequence. A model may be authorized to compute while remaining unauthorized to act. This document specifies a hardware-rooted execution-finality architecture for neural and agentic systems. A proposed consequence- bearing operation is represented as a Candidate Act and held in a Non-Effective State until a Protected Enforcement Domain validates act-specific predicates and an independent Finality Sink verifies scoped, non-bearer finality authority immediately before the operation becomes externally effective. If that authority is absent, stale, replayed, revoked, or mismatched to the act being attempted, the Candidate Act remains non-effective and the operation fails closed. The architecture is model- and vendor-neutral. It is written for the industrial surfaces that now dominate production agent deployments: Model Context Protocol (MCP) tool dispatch, computer use, code execution, enterprise connectors, memory and knowledge-store writes, GPU and confidential-computing egress, and settlement. The same invariant applies to those surfaces: computation is not authority; tool selection is not tool-effectuation; a connector allowlist is not per-act finality. |
| | When Data Leaves Its Originating Jurisdiction,Who Controls It? Digital Sovereignty Without Data Localisation by Separating the Compute Plane from the Authority Plane |
| |
|
Consider a simple case: data concerning U.S. citizens is processed in infrastructure located outside the United States. The foreign jurisdiction may have its own lawful-access, surveillance, disclosure, retention, or national-security rules. Even where contractual commitments, privacy policies, regional settings, or enterprise agreements specify how that data should be handled, the infrastructure executing the workload may ultimately operate under legal and technical authority outside the originating jurisdiction. The same problem applies in reverse to European, Indian, Japanese, Canadian, Australian, or other data processed through globally distributed infrastructure. This creates a deeper architectural problem than ordinary data localisation. If control over data automatically follows the physical location of compute, then moving computation across borders can also move practical authority over the resulting data, operations, and disclosures. Privacy may be the first concern, but the same architectural dependency can later affect economic security, critical infrastructure, sensitive enterprise information, government workloads, and national security. This is where policy alone begins to reach its limit. Contracts, privacy policies, adequacy mechanisms, access-control rules, cloud-region settings, and audit requirements remain important. However, they primarily describe what an actor is permitted or expected to do. They do not necessarily create a technical condition that prevents a prohibited external effect from occurring in the first place. Although this document uses the term "digital sovereignty," it does not attempt to standardize national policy, determine which jurisdiction's law should prevail, or prescribe where data must be stored. Its focus is technical: defining an interoperable mechanism by which deployment-selected policy and trust inputs can be bound to a specific Candidate Act and enforced at the effectuation boundary before that act becomes externally effective. In this document, "sovereignty" therefore refers to retained execution authority, not to the standardization of geopolitical or regulatory policy. The architecture described here addresses this problem through a different model of digital sovereignty: separate the Compute Plane from the Authority Plane. The Compute Plane may remain globally distributed. Data may be stored, transformed, analysed, routed, or processed using infrastructure located in another jurisdiction. The architecture therefore does not require that all data remain physically local, nor does it assume that sovereign computing requires complete national isolation from global cloud, telecom, AI, or platform infrastructure. Instead, the Authority Plane remains independently governed. A remote compute environment may perform computation, but computation alone does not grant authority to produce a protected external consequence. A proposed cross-jurisdiction operation is represented as a Candidate Act and remains in a Non-Effective State until the required policy, identity, purpose, destination, jurisdiction, runtime, revocation, and other applicable predicates have been validated. Protected validation may produce a LAVR or equivalent validation commitment and a scoped Finality Authority bound to the particular Candidate Act. At the relevant Finality Sink — the first point at which the protected operation would become externally effective — the authority is independently verified. Only after successful verification and appropriate consumption or reservation of that authority may the external effect occur. The resulting model is therefore: Compute Anywhere -> Authority Remains Independently Governed -> Candidate Act -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> External Effect. If the required authority is missing, stale, revoked, mismatched, replayed, or inconsistent with the governing jurisdictional policy: No Valid Authority -> No Protected External Effect. This permits a form of digital sovereignty without mandatory data localisation. A jurisdiction, enterprise, regulated institution, or other authorised policy owner does not necessarily need to operate every processor, cloud region, network, or AI system that performs the computation. Instead, it can retain technical control over the conditions under which specified externally effective acts are permitted. The architecture therefore separates two questions that are commonly treated as one: Where is the computation performed? Who has authority over the resulting external effect? Those questions need not have the same answer. A U.S. workload could execute outside the United States while specified sensitive external effects remain subject to U.S.- controlled or enterprise-controlled authorization conditions. An EU workload could similarly use infrastructure outside a particular Member State while retaining independently governed finality requirements. The same mechanism could apply to India, Japan, Singapore, Australia, Canada, multinational enterprises, sovereign clouds, regulated industries, or private data spaces. The architecture does not prescribe which country's policy should prevail and does not attempt to resolve conflicts of law. Its contribution is narrower and technical: cross-border computation does not have to imply cross-border surrender of execution authority. This turns digital sovereignty from a primarily location-centred concept into an authority-centred execution model. The objective is not to fragment the Internet or exclude global technology providers. On the contrary, separating the Compute Plane from the Authority Plane could allow hyperscale cloud providers, AI platforms, telecom operators, CDNs, satellite networks, and other global infrastructure providers to continue supplying efficient distributed computation while supporting stronger jurisdiction-specific, enterprise-specific, or regulated execution guarantees. In this model, sovereignty does not require saying that the data must never leave. It can instead mean: the computation may occur elsewhere, but this protected external effect cannot occur without the required authority. That is the central architectural proposition of this document. |
| | A Framework for DNS Resolution Latency Measurement |
| |
|
DNS resolution latency is widely used as an operational metric for evaluating recursive resolvers, authoritative servers, and DNS infrastructure. However, current implementations employ different definitions, measurement scopes, and testing methodologies, making latency results difficult to compare across deployments. This document identifies common sources of inconsistency, proposes a conceptual latency decomposition model, and provides measurement considerations intended to improve comparability of DNS latency measurements. This document does not define protocol behavior nor introduce new protocol mechanisms. |
| | Reflections on IETF Authorship |
| |
|
[RFC825] was intended to provide guidance to authors of future RFCs. The memo also listed several reasons for publishing a memo as an RFC. It did not discuss who would be listed as author. This memo discusses authorship within the IETF and the use of generative Artificial Intelligence for IETF RFCs. |
| | SRv6-INT: Protocol Extensions to Segment Routing over IPv6 for In-Band Network Telemetry in Support of Closed-Loop Resource Control |
| |
|
This document defines SRv6-INT, a protocol extension that integrates In-band Network Telemetry (INT) with Segment Routing over IPv6 (SRv6) packet processing. The extension reuses the Segment List entry associated with each SRv6-INT endpoint to carry an equal-length telemetry record, thereby preventing telemetry collection along the path from further increasing the packet header length. A collector obtains the resulting telemetry and provides it to local and global controllers for closed-loop resource control. |
| | ProtectChain: An Anchored Permissioned Ledger for Proof of Anteriority of Authored Works |
| |
| | draft-tempobono-protectchain-00.txt |
| | Date: |
09/09/2026 |
| | Authors: |
OrlandoTempobono, Nelson Tempobono, Lucas Tempobono, Felipe Tempobono, Clara Tempobono |
| | Working Group: |
Individual Submissions (none) |
|
This document specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger whose purpose is to produce verifiable evidence that a given digital work already existed no later than a given point in time, under an authorship claim made by an identified account. ProtectChain records only cryptographic digests and pseudonymous identifiers; the work itself never enters the ledger. Because all initial authorities may be operated by a single organization, every block is also anchored to independent public time references, so that the upper bound on a record's date does not rest on the operator's assertion. This document is deliberately explicit about the limits of the evidence produced: an anchor establishes that data existed _no later than_ a given instant; it does not establish the exact instant of creation, nor does it establish authorship or originality. |
| |
|
| |
| | Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND) |
| |
|
This document defines the Secure Advertisement and Neighborhood Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within a delay-tolerant network (DTN). This protocol defines a general purpose advertisement mechanism with an initial set of message and data types able to be advertised by participating nodes in a BPv7 network. The focus of this document is for advertisement to topological neighbors about local neighborhoods but can be expanded upon in the future through extension points. |
| | EDHOC Authenticated with Pre-Shared Keys (PSK) |
| |
| | draft-ietf-lake-edhoc-psk-09.txt |
| | Date: |
08/09/2026 |
| | Authors: |
Elsa, Goeran Selander, John Mattsson, Rafael Marin-Lopez, Francisco Lopez |
| | Working Group: |
Lightweight Authenticated Key Exchange (lake) |
|
This document specifies a Pre-Shared Key (PSK) authentication method for the Ephemeral Diffie-Hellman Over COSE (EDHOC) Lightweight Authenticated Key Exchange (LAKE) protocol. The PSK method provides mutual authentication, ephemeral key exchange, identity protection, and quantum resistance while incurring lower computational costs than the public-key authentication methods specified for EDHOC. It is suited for systems where nodes share a PSK provided out-of-band (external PSK) and enables efficient session resumption with less computational overhead when the PSK is provided from a previous EDHOC session (resumption PSK). This document details the PSK message flow, key derivation changes, message formatting, processing, and security considerations. |
| | Media Type Specifications and Registration Procedures |
| |
|
This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. It obsoletes [RFC6838] and [RFC9694]. Note that [RFC4289] is also part of BCP 13, and addresses registration of MIME External Body Access Types and Transfer Encodings. |
| | Media over QUIC Transport |
| |
|
This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. |
| | Network Traffic Analysis and Network Modal Mapping Method |
| |
|
This document presents a framework for network traffic classification and modality mapping based on large language models (LLMs), addressing the inefficiencies of traditional methods in dynamic network environments. The proposed approach automates multi- dimensional traffic feature extraction and intelligent decision- making to achieve precise alignment between traffic patterns and computing-storage-transmission requirements. The framework comprises two phases: pre-training (generating multi-modal traffic representations from pcap data) and mapping (dynamically formulating resource allocation strategies). It supports anomaly detection, QoS assurance, and multi-service collaboration, thereby significantly enhancing resource utilization efficiency and network service performance. |
| | Aggregate Performance Reporting |
| |
|
Definition of an aggregate performance report format for email messaging, the means to discover target destinations, and a specified delivery method. |
| | Attestation Reconciliation Protocol |
| |
|
This document specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, minimum-disclosure mechanism for reconciling verification claims against a plurality of sovereign authoritative registers without raw register records leaving their data-residency jurisdiction. ARP extends the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture to cross-sovereign claim reconciliation. A reconciliation server canonicalises a structured claim, binds the identity of the requesting principal -- including, where the requester is an autonomous agent, a friend-or- foe determination of that agent's verifiable principal binding -- projects the claim through register-specific controlled projection functions producing the nearest permitted ancestor predicate supported by each addressed register, transmits register-specific ciphertexts, receives partial attestations whose payload discloses, of the subject, only a verdict, an optional divergence axis, the applied profile parameters and a query binding digest, aggregates those attestations under a verdict arithmetic the deployment's policy resolves, committing each register's contribution to a Merkle tree, and seals the resulting reconciliation output against a policy- version hash. An append-only cross-jurisdictional settlement-layer ledger records digests and structural metadata, with no claim, register-record or principal content. The protocol supports retroactive re-evaluation of historical reconciliations under updated pattern libraries or policy versions without bilateral renegotiation, and a cryptographic-primitive-upgrade path including post-quantum primitives. This revision adds a normative binding to the SCITT Reference APIs, register data-format profiles for beneficial- ownership, corporate-registry, customs and consolidated-sanctions formats, and a source-data version binding that makes a change in a historical verdict attributable to a change in policy or to a change in the underlying published corpus. |
| | Security Requirements for IP Tunnel Nodes |
| |
|
IP tunnels conceal passenger-packet fields from devices on the delivery path and create a new forwarding and policy boundary at decapsulation. If a tunnel node accepts delivery packets from an unauthorized source, or if it forwards a decapsulated passenger packet without applying the policy for the exposed packet and forwarding domain, the node can enable source-address spoofing, unauthorized transit, policy bypass, or resource-exhaustion attacks. This document specifies generic security requirements for IP tunnel ingress, egress, and relay nodes. The requirements cover explicit enablement, peer and passenger-packet authorization, source and forwarding-scope validation, nested tunneling, IPv6 extension headers, ICMP and Path MTU Discovery, resource controls, and telemetry. They apply to configured IP-in-IP, IPv6 tunneling, GRE, and enabled IPv4/IPv6 transition mechanisms. This document does not define a new encapsulation or replace protocol-specific processing rules. |
| | Publication Process Reform to prevent misuse of AUTH48 or equivalent states |
| |
|
This document updates the AUTH48 or equivalent process by introducing deterministic state-integrity constraints within the IETF Datatracker architecture. It establishes automated validation milestones and explicit access controls to prevent late technical modifications after the Working Group Last Call, thereby safeguarding the Rough Consensus. This document updates RFC 7841. |
| | An External Verifier Contract for Agent Authorization Decisions |
| |
|
This document specifies the External Verifier Contract (EVC): a small, testable, proof-system-agnostic boundary between a host (the program about to take a privileged action on an agent's behalf) and an external verifier (a subprocess that renders an allow/deny verdict on an opaque proof bundle). The contract governs only the transport and verdict envelope: how the host hands a single JSON request to a verifier subprocess over stdin, how the verifier answers with exactly one JSON verdict on stdout, and how the host interprets exit codes, timeouts, and malformed output under a fail-closed rule. Three properties make the boundary standardizable: (1) a single-shot subprocess transport with a closed JSON verdict schema; (2) fail- closed host semantics that are independently testable by a host- conformance suite; and (3) proof-system agnosticism, so the same envelope carries classical-signature, zero-knowledge, and third-party verdicts, distinguished only by an OPTIONAL self-description field. EVC is deliberately not a governance framework, not a delegation model, and not a policy language. It is the narrow decision boundary those larger systems all require at the point of enforcement. |
| | Identity Continuation Assertion for OAuth 2.0 Token Exchange |
| |
|
This document defines the Identity Continuation Assertion, a short- lived, sender-constrained JSON Web Token (JWT) used as an OAuth 2.0 Token Exchange subject token. It enables a workload acting on a user's behalf to obtain an Identity Assertion JWT Authorization Grant (ID-JAG) for another service when it lacks a suitable credential, including when the user is no longer present. A trusted issuer attests that a resource authorization server accepted an earlier ID-JAG and that the resulting authorization remains active and eligible for continuation. The workload exchanges this assertion at the identity provider, which evaluates the requested access under the chain authorization and current policy before issuing an onward ID-JAG. The profile supports multi-hop access across resource authorization servers that trust a common identity provider. |
| | AI Agent Identity Certificate (AIC) JSON Web Token Profile |
| |
|
The AI Agent Identity Certificate (AIC) defines a data model in which the cryptographic identity of an AI agent is bound to a responsible principal, together with a structured capability container, delegation mode, authorization constraints, and principal-signed delegation evidence. The normative definition of this model is specified by the AIC specification, where it is encoded in ASN.1 and carried in X.509 certificates, enabling authorization decisions at the transport layer, including fully offline operation. Many HTTP, web, and OAuth 2.0 (RFC 6749) deployments cannot present X.509 certificates at the transport layer. This document therefore defines AIC-JWT as a JWT-based application-layer representation of the AIC data model defined by the AIC specification. AIC-JWT is a companion representation, not a replacement for the X.509 form and not a new authorization model. AIC-JWT uses the standard JWT (RFC 7519) and JWS (RFC 7515) mechanisms as its carrier and cryptographic envelope. Its authorization semantics are inherited from the AIC model rather than defined by JWT or OAuth. In particular, the outer AIC-JWT is issuer- signed and carries the principal-signed DA JWT as the value of the top-level da claim, preserving the two-layer signature model of AIC. The normative content of this document is limited to: * a mapping from the X.509 AIC extension fields to JWT claims that preserves the AIC data model and its two-layer signature model; * representation and key-binding rules for the principal-signed DelegationAuthorization; * validation rules for AIC-JWT, including claim consistency, audience, and key-binding checks; and * a thin OAuth 2.0 consumption profile defining presentation of the DA at a token endpoint as an RFC 7523 JWT bearer authorization grant and the projection of the AIC authorized and representative delegation modes into OAuth roles. |
| | Execution-Finality for AI-Native 5G/6G and O-RAN |
| |
|
In programmable and AI-assisted mobile networks, successful authentication of a network function or AI controller does not establish authority for every routing, signaling, session, resource- allocation, sensing, or subscriber-specific consequence that the function can generate. This document defines an informational execution-finality profile for AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN, and AI-RAN environments. A proposed network operation is represented as a Network Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain validates act-specific predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer finality authority. A Network Finality Sink at the enforcement boundary independently verifies that authority immediately before live network state changes. The governing rule is that network authentication is not network finality, and computation is not authority. This revision also defines a JSON interoperability profile for Candidate Acts, validation decisions, scoped authority, and sink verification. This profile is distinct from, and complementary to, present AI- native 6G industry roadmaps that focus on radio, sensing, and platform capability, including air-interface, MIMO, spectrum, and AI- RAN infrastructure work described in Qualcomm's public AI-native 6G platform material, and the broad native-trustworthiness and agentic- core-network architectures described in Huawei's public 6G security research. Those efforts address how a network becomes more intelligent, autonomous, and platform-trustworthy. This document addresses a narrower and later question: once an already- authenticated, already-policy-approved AI-generated network operation has been computed, whether that exact operation may become a live network consequence. The Candidate Act, Non-Effective State, Protected Enforcement Domain, and Finality Sink constructs defined here, as an explicit pre-effectuation gate with act-bound non-bearer authority and independent sink-side re-verification, are not established as an equivalent primitive in publicly reviewed material from those roadmaps. |
| | Access Is Not Egress: Precision-Bounded Location Release |
| |
|
A device may legitimately possess exact location while an application, SDK, AI agent, analytics library, or foreign endpoint is entitled only to a coarser representation, a delayed or randomized representation, or no location at all. Operating system permission to read a fix does not answer whether that fix may leave the device at the requested precision. This document defines a precision-bounded egress profile: a data- minimization mechanism applied at the point of external disclosure, on top of an execution-finality architecture, applicable equally to conventional applications and to autonomous AI agents acting on a user's behalf. The gap this closes is concrete: an application that legitimately reads exact GPS for one on-device purpose commonly shares its process with an embedded SDK, agent tool, or cloud sync path that can forward the same exact coordinate to a destination that never needed it, without the user seeing that forwarding as a separate disclosure. A proposed release is a Location-Release Candidate Act and remains non-effective while a Protected Enforcement Domain evaluates purpose, requester, component, recipient, destination, jurisdiction, required precision, policy and revocation state, cumulative disclosure state, and intended egress sink. The Protected Enforcement Domain issues scoped, non-bearer, cryptographically bound finality authority for a specific precision ceiling, expressed using the JSON interoperability objects defined in this document. An independent egress Finality Sink verifies that authority against the actual outbound payload immediately before release, so the bound ceiling, rather than the requester's declared precision, determines what may leave the device. The permitted result may be exact data, a reduced representation, or denial. Data access is not data-export authority. Precise GPS access is not precise GPS-release authority. |
| | RF Enable Is Not Transmit Authority: Finality for LEO/NTN and Inter-Satellite Control |
| |
|
A LEO constellation computer can compute a transmit burst, a beam command, an inter-satellite forward, or a user-terminal PA enable faster than any ground reviewer can see it. Today those acts become RF because the scheduler selected them, the command link authenticated, or the flight process had the radio device open. Authentication of TT&C, 3GPP NTN registration, and operator allowlists decide who may talk to the vehicle. They do not decide whether this burst, on this beam, to this next hop, over this territory, in this mission epoch, may leave the aperture. Radiation is not reversible. An ISL hop is not a log line. A phased-array user terminal that is already pointed is one register write away from radiating. If the enable line trusts the last ground "go," a stale, substituted, or autonomy-generated command becomes sky-facing consequence. This document specifies a radio-side execution-finality profile for NTN and mega-constellation control. A proposed RF, ISL, beam, gateway, or payload act remains a Candidate Act. A Protected Enforcement Domain binds vehicle, beam, frequency class, duration, next hop, overflight or jurisdiction epoch, and intended sink, then issues scoped non-bearer authority. The Finality Sink sits at the PA enable, ISL switch, beam driver, feeder gateway, or UT transmit path and verifies that authority immediately before energy leaves the system. RF enable is not transmit authority. |
| | A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments |
| |
|
Payment rails already know how to move money. They do not know whether this generated instruction — this amount, this beneficiary, this rail, this purpose, from this agent or API worker — is the instruction that was authorized to move. A signed ISO 20022 message, an OAuth token on a PSP, a stored mandate, or a pass through 3-D Secure can all be valid while the act is wrong. The signature authenticates a channel. It does not bind a Candidate Act at the settlement sink. That gap is now an agent gap. A model that can call payout.create, a RPA job that submits ACH, or a checkout agent that captures a card will treat tool selection as settlement authority. Fraud used to steal credentials and replay files. It now steals a seat or injects a document and asks the authorized worker to pay a new beneficiary at the old amount, or the old beneficiary at a new amount. This document specifies a payment-side execution-finality profile. An instruction remains a Payment Candidate Act. A Protected Enforcement Domain binds principal, wallet or account, amount, currency, beneficiary, rail, purpose, policy epoch, and intended settlement sink, then commits evidence before scoped non-bearer authority is issued. The sink that would actually post, capture, or release funds verifies that authority against the live instruction and consumes it. A signed instruction is not settlement. |
| | Stopping AI Hallucinations and Unsafe Acts from Becoming Real-World Consequences (DAS Protocols) |
| |
|
The internet has protocols for moving data, securing channels, naming hosts, and delegating identity. It has no protocol for the moment a machine-generated instruction becomes a real-world act. As AI systems begin to move money, change databases, reconfigure networks, send communications, and control physical systems, that missing boundary becomes a structural risk. Today an AI can hallucinate a fact, cite a stale source, invent a tool argument, or propose an unsafe agentic step — and still reach an effectuation interface. Model approval is not output approval. Workflow approval is not consequence approval. Moderation, access control, TEEs, simulation, and post-hoc audit all leave the final transition from computation to consequence under-protected. This document specifies the DAS Protocols Candidate-Act Finality architecture. Every effect-capable AI output is first converted into a non-effective Candidate Act. The Candidate Act stays non-effective until a Protected Enforcement Domain has validated output, provenance, factual support, consequence, jurisdiction, epoch, and sink predicates. Only then is a scoped non-bearer capability or Execution Handle released and verified at a Finality Sink. In advanced forms the Finality Sink is cryptographically unable to complete the act unless the handle supplies the missing execution material. The architecture supports graduated and escalated conditional finality so that elevated-risk but necessary acts can still proceed under stricter controls. The document elaborates the problem space, compares the approach with representative existing techniques, describes the base and advanced finality paths, and provides JSON Schema definitions for the core protected objects. Related Indian provisional applications and PCT filings are listed in the final appendix. |
| | Defining a Celestial Bodies Reference Framework for Deep Space Internet Addressing |
| |
|
This document highlights the architectural requirement within Deepspace/TIPTOP protocols to utilize an external, standardized reference framework for celestial objects, functioning as an equivalent to ISO 3166 for interplanetary networking. To avoid operational overhead and duplication of effort, this framework defers the definitions, naming, and tracking of celestial entities directly to the International Astronomical Union (IAU) and the Minor Planet Center (MPC). This document outlines how these external identifiers guide hierarchical address allocation without requiring IANA to maintain a dedicated astronomical nomenclature registry. The ultimate objective is to establish a clear definition of what constitutes a valid Celestial Body for networking purposes. |
| | The JavaScript Object eXchange (JSOX) Data Interchange Format |
| |
|
JavaScript Object eXchange (JSOX) is a lightweight, text-based, language-independent data interchange format. It is derived from JSON and from the object literal syntax of the ECMAScript Programming Language Standard. Every well-formed JSON text is a well-formed JSOX text. JSOX extends JSON with unquoted identifiers, additional string quoting and escape forms, comments, additional number forms including dates and arbitrary-precision integers, binary typed arrays, user- defined types carried by a type tag, field-name macros that remove repeated keys from a document, and references that permit shared and cyclic structures to be encoded. This document defines the JSOX grammar and registers the media type "application/jsox". |
| | Updates to the One-Time Password (OTP) System defined by RFC 2289 |
| |
|
This document aims to submit a few updates to RFC 2289 [RFC2289], which describes a One-Time Password (OTP) System: an application programming interface to the new Secure Hash Algorithms (SHA256, SHA384, and SHA512), an algorithm for folding hashes to 64 bits, using alternate dictionaries, and automatic renewal of authentication parameters will be described. |
| | Aggregate Signatures for WIMSE Delegation-Chain Integrity |
| |
|
This document profiles the WIMSE HTTP Message Signatures mechanism ([I-D.ietf-wimse-http-signature]) to protect a request that passes through a chain of workloads. In the base mechanism each workload signs independently: an intermediary can remove a signature undetected, and the signatures accumulate on every hop. This document combines the workloads' signatures into one aggregate signature. Removal of a signature becomes detectable, and the signature material no longer grows with the length of the chain, a significant saving for post-quantum signature algorithms, whose signatures are large. The mechanism works with any aggregate signature scheme. |
| | Stage Receipts: A Verifiable Record Format for Staged Pipelines |
| |
|
A staged pipeline -- a document-ingestion flow, a retrieval-augmented generation chain, an agent workflow, a benchmark -- produces results that are hard to reproduce, hard to diff between two runs, and hard to localize when they go wrong. This document defines the stage receipt: a small, canonically serialized JSON record that each stage of such a pipeline emits, describing exactly what went in, what came out, under which pinned instrument, with which outcome, and linked by digest to the receipt before it. A chain of stage receipts lets a developer reproduce a run, diff two runs to the first stage that differs, and localize a fault to the stage where it entered; the same chain lets an independent party, later and offline, establish what the records assert without trusting whoever produced them. The document specifies the record, its canonical form, the chain manifest, the coverage and emission declarations that make a chain honest about its own edges, the anchoring declaration that separates consistency from originality, and the behaviour required of a conforming verifier. Golden conformance vectors -- records that must be accepted and records that must be refused, each with its reason -- are part of the specification. |
| | AIIP Core: Agent Access Plane,AIID,Resolve,Invoke,and Receipt |
| |
|
This document specifies the core of the AI Internet Protocol (AIIP) agent access plane: the AIID identity namespace, the aiip: URI scheme, Resolve, Invoke, Receipt, and delegation grants. Underlay addresses are disposable locators only. Agents MUST NOT use HTTP or HTTPS as their Invoke (or Resolve) path. Independence doctrine: underlay pipes and platforms are never authority. Mesh tip attestation is a trust layer, not a ledger. Access Fabric punch ops are Experimental. This revision (2026-09-08 wire harden) is derived from the running lab profile "aiip-wire-0". It is an individual submission draft; it does not claim Working Group adoption or RFC publication. |
| | PCEP extensions for SR P2MP Policy |
| |
| | draft-ietf-pce-sr-p2mp-policy-21.txt |
| | Date: |
08/09/2026 |
| | Authors: |
Hooman Bidgoli, Dan Voyer, Anuj Budhiraja, Rishabh Parekh, Siva Sivabalan |
| | Working Group: |
Path Computation Element (pce) |
|
Segment Routing (SR) Point-to-Multipoint (P2MP) Policies are a set of policies that enable an architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths for SR-MPLS from a Root to a set of Leaf nodes. |
| | Extensible Provisioning Protocol (EPP) Transport over HTTPS |
| |
| | draft-ietf-regext-epp-https-05.txt |
| | Date: |
08/09/2026 |
| | Authors: |
Mario Loffredo, Lorenzo Trombacchi, Maurizio Martinelli, Dan Keathley, James Gould |
| | Working Group: |
Registration Protocols Extensions (regext) |
|
This document describes how an Extensible Provisioning Protocol (EPP) connection is mapped onto the Hypertext Transfer Protocol (HTTP). EPP over HTTP (EoH) requires the use of Transport Layer Security (TLS) to secure EPP information (i.e. HTTPS). |
| | Standard Communication with Network Elements (SCONE) Protocol |
| |
| | draft-ietf-scone-protocol-08.txt |
| | Date: |
08/09/2026 |
| | Authors: |
Martin Thomson, Christian Huitema, Kazuho Oku, Matt Joras, Lars Ihlar |
| | Working Group: |
Standard Communication with Network Elements (scone) |
|
This document describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals. |
| |
|
| |
| | EVPN Network Layer Fault Management |
| |
| | draft-ietf-bess-evpn-bfd-20.txt |
| | Date: |
07/09/2026 |
| | Authors: |
Vengada Govindan, Ali Sajassi, Mudigonda Mallik, Greg Mirsky, Donald Eastlake |
| | Working Group: |
BGP Enabled ServiceS (bess) |
|
This document specifies proactive, in-band Network Layer OAM (RFC 9062) mechanisms to detect loss of continuity faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast, and Multicast traffic) in an Ethernet VPN (EVPN, RFC 7432bis) network. The mechanisms specified in this document use the widely adopted Bidirectional Forwarding Detection (RFC 5880) protocol. |
| | Pairing-Friendly Curves |
| |
|
Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and they can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security; however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and consider them at the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. This memo also specifies the serialization and deserialization of the points and scalars that protocols exchange, restating a format that is already in widespread use, and states which of the remaining decisions belong to the calling protocol. |
| | Key Usage Limits for OSCORE |
| |
|
Object Security for Constrained RESTful Environments (OSCORE) uses AEAD algorithms to ensure confidentiality and integrity of exchanged messages. Due to known issues allowing forgery attacks against AEAD algorithms, limits should be followed on the number of times a specific key is used for encryption or decryption. Among other reasons, approaching key usage limits requires updating the OSCORE keying material before communications can securely continue. This document defines how two OSCORE peers can follow these key usage limits and what steps they should take to preserve the security of their communications. |
| | Identifier Update for OSCORE |
| |
|
Two peers that communicate with the CoAP protocol can use the Object Security for Constrained RESTful Environments (OSCORE) protocol to protect their message exchanges end-to-end. To this end, the two peers share an OSCORE Security Context and a number of related identifiers. In particular, each of the two peers stores a Sender ID that identifies its own Sender Context within the Security Context, and a Recipient ID that identifies the Recipient Context associated with the other peer within the same Security Context. These identifiers are sent in plaintext within OSCORE-protected messages. Hence, they can be used to correlate messages exchanged between peers and track those peers, with consequent privacy implications. This document defines an OSCORE ID update procedure that two peers can use to update their OSCORE identifiers. This procedure can be run stand- alone or seamlessly integrated in an execution of the Key Update for OSCORE (KUDOS) procedure. |
| | Bundle Transfer Protocol - Unidirectional |
| |
|
This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. |
| | Forward Error Correction for the Bundle Transfer Protocol |
| |
|
This document defines an optional extension to the Bundle Transfer Protocol - Unidirectional, as described in [BTPU], to enable forward error correction (FEC) coding to be applied selectively to the transfer of individual bundles on a case by case basis. The definition and use of FEC follows the FECFRAME framework defined in [RFC6363], and this document introduces new Message types to BTPU in order to carry the FEC information as defined in the framework. |
| | Bundle-in-Bundle Encapsulation |
| |
| | draft-ietf-dtn-bibe-00.txt |
| | Date: |
07/09/2026 |
| | Authors: |
Rick Taylor, Alberto Montilla |
| | Working Group: |
Delay/Disruption Tolerant Networking (dtn) |
|
This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) tunneling mechanism by which a bundle is carried as the payload of one or more encapsulating bundles, allowing security measures, routing policy, and protocol version translation to be applied to the encapsulating bundle without modification of the encapsulated bundle. The protocol includes an optional segmentation mechanism, allowing a large encapsulated bundle to be carried in multiple encapsulating bundles. |
| | ICMP Message Extension for Originating Node Identification |
| |
|
RFC5837 describes a mechanism for Extending ICMP for Interface and Next-Hop Identification, which allows providing additional information in an ICMP error that helps identify interfaces participating in the path. This is especially useful in environments where a given interface may not have a unique IP address to respond to, e.g., a traceroute. This document introduces a similar ICMP extension for Node Identification. It allows providing a unique IP address and/or a textual name for the node, in the case where each node may not have a unique IP address (e.g., a deployment in which all interfaces have IPv6 addresses and all next-hops are IPv6 next-hops, even for IPv4 routes). |
| | IGP Reverse SPF Algorithm |
| |
|
IANA has set up a subregistry called "IGP Algorithm Type" under the "Interior Gateway Protocol (IGP) Parameters" registry. This draft introduces a new algorithm type which utilizes the cost in the reverse direction on each link. This document also discusses using this new algorithm type in combination with IGP Flexible Algorithm to compute constraint-based paths. |
| | POSIX Draft ACL support for Network File System Version 4,Minor Version 2 |
| |
|
This document proposes four new optional file attributes for NFSv4.2 to support POSIX ACLs conforming to the withdrawn POSIX 1003.1e draft 17. Although never ratified, POSIX ACLs are implemented in widely deployed operating systems. Existing attempts to map between NFSv4 and POSIX ACL models have been unsuccessful due to semantic incompatibilities. These new attributes allow servers to expose POSIX ACLs directly, avoiding lossy mapping. |
| | LibrePGP Message Format |
| |
|
This document specifies the message formats used in LibrePGP. LibrePGP is an extension of the OpenPGP format which provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression and key management. This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the LibrePGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP). |
| | Arm's Confidential Compute Architecture Reference Attestation Token |
| |
|
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. |
| | RPKI to Router Protocol over QUIC |
| |
|
The Resource Public Key Infrastructure (RPKI) to Router Protocol provides a simple but reliable mechanism to receive cryptographically validated RPKI prefix origin data and router keys from a trusted cache. RPKI to Router (RTR) Protocol can be carried over various transports such as TCP, SSH or else. QUIC provides practical and secure semantics for the RTR protocol, particularly fast connection establishment and multi-stream carrying, thereby reducing the time required to complete RTR data synchronization. This document describes how to use RTR Protocol over the QUIC transport protocol, named RTRoQUIC. |
| | Network Service Type-Aware Traffic Labeling Protocol (NST-TLP) |
| |
|
This document specifies a protocol mechanism for embedding service type identifiers into network packets in order to enable intelligent traffic recognition, policy-based forwarding, and resource optimization by network devices. The protocol allows standardized service type labels to be carried in IPv4/IPv6 headers, MPLS labels, or Ethernet frame headers. It is applicable to a wide range of services, including immersive VR (e.g., 1080p, 4K), scientific computing, real-time communications, and Internet of Things (IoT) applications. |
| | DTN QUIC Bundle Protocol Convergence Layer (qubicle) |
| |
|
This document specifies a minimal convergence layer protocol for transferring Bundle Protocol version 7 (BPv7) bundles over QUIC. The protocol leverages QUIC's native capabilities for reliable streaming, connection management, and security. Reliable transfers carry each bundle on its own QUIC stream, either directly or wrapped in a single CBOR byte string, with no further application-layer framing. Unreliable transfers use the Bundle Transfer Protocol - Unidirectional (BTP-U) over QUIC datagrams. |
| | SAIP: Signed Agent Identity Protocol |
| |
|
The modern internet lacks a reliable mechanism for verifying the identity of automated software agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rapid growth of automated agents including AI crawlers, IoT devices, and enterprise automation systems. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP implements the principles defined in the Verifiable Identity Claims and Delegation Model [VICDM] and enables servers to distinguish legitimate automated traffic from malicious actors through cryptographic identity at three levels of granularity: vendor, agent type, and individual instance. SAIP is protocol-agnostic and applicable to HTTP, SMTP, and other header-based protocols. It introduces DNS-based Attestation Discovery as a lightweight alternative to registry-based key lookup, making deployment accessible to organizations of any size. |
| | The Intent Declaration Primitive (IDP) for Agentic AI Systems |
| |
|
Every action an AI agent takes is a decision. Right now, none of those decisions are signed. AI agents operating in automated workflows take actions without any normative mechanism for expressing why those actions are being taken. Access tokens declare what an agent is permitted to do; no existing standard declares what the agent believes it is doing, on what reasoning basis, and with what level of confidence, at the moment of action. This document defines the Intent Declaration Primitive (IDP): a structured per-transition declaration submitted by an AI agent to the Governing Enforcement Component (GEC) at each action step of an execution loop. The IDP is committed to a tamper-evident Event Log before the action executes, enabling post-hoc review of agent reasoning, richer authorization policy evaluation, and enriched denial responses that guide agent behaviour. The IDP also provides the technical basis for compliance with EU AI Act Article 12 logging requirements for high-risk AI systems. Version -05 adds: the intake_endorsement operation through which the GEC endorses a submitted EOD before the first SENSE delivery, making the EOD a GEC-signed artifact and preventing unendorsed IDPs from proceeding; the PD-EOD (Prompt-Derived EOD) branch for IDPs derived from natural-language prompts rather than structured input, with scope-bounding rules and HEM notification requirements; the mandate_reference field linking each IDP to an SPO URI for structural validation; confidence_level calibration guidance including the CONFIDENCE_MISCALIBRATION_WARNING trigger; RETRY_CONTINUATION normative strengthening with backward reference to AEP-03's what_changed requirement; and four new Security Considerations addressing prompt injection at intake, EOD scope manipulation, confidence_level inflation attacks, and COMMITMENT_GAP exploitation. Version -06 is an editorial revision with no normative content changes: bracket-delimited array type notation ([string], [object]) was reworded to string[]/object[] to resolve idnits parser warnings; sibling-draft citations were updated to each draft's current live version (AEP-03, HEM-07, KIA-06, GAR-07, PT-03, MAD-04); and several long lines were rewrapped. |
| | The Governance Audit Record (GAR) for Agentic AI Systems |
| |
|
This document specifies the Governance Audit Record (GAR), the audit architecture for agentic AI systems. GAR defines five audit types, the Session Audit Record (SAR), the Audit Alert system, auditor principal categories, and the Audit Package for external regulatory inspection. GAR provides verifiable evidence that AI agent sessions were governed in accordance with the Intent Declaration Primitive and the Human Escalation Mechanism. GAR answers the governance question: can any of this be proven to a regulator? GAR is a domain-specific application of the SCITT (Supply Chain Integrity, Transparency and Trust) architecture extended with causal ordering semantics for agentic governance events. GAR defines the Authority Lifecycle Event (ALE) category: a normative set of causally-ordered event types covering the complete agent session revocation and recovery lifecycle, including single-agent revocation, authority suspension, partial state recording, recovery initiation, credential restoration, and multi-agent delegation tree events. Version -03 adds the SOOS Governance Semantic Convention: the normative soos.governance.* OpenTelemetry attribute namespace for governance observability, the SOOS GAR Processor specification for OTel-to-SAR pipeline construction with Session Block Merkle integrity, four new Authority Lifecycle Events, three mandatory provenance fields on Cedar evaluation records, and the XPID mirror field on ACD session ALEs. Version -04 made the Session Block construction rules more explicit, closing three ambiguities found during independent interop verification at the IETF 126 Hackathon. Version -05 supersedes -04's Session Block construction text with a corrected construction: the Merkle leaf and internal-node hashes are now domain-separated (RFC 9162's Merkle Tree Hash, with 0x00/0x01 prefix octets) and odd-length levels use RFC 9162's k-split recursive tree shape rather than duplicate-node padding, closing a malleability class structurally equivalent to CVE-2012-2459 that was present in -04's construction. This revision is fully self-contained: unlike -03 and -04, it does not carry forward unreproduced text from an earlier version. Version -05 also adds a subject_digest field to Cedar-evaluation GAR records, the same construction used by the Agent Accountability Composition as its cross-slot join key, positioning GAR as a conforming AEP instance under the RATS-bound composition; the field is normatively scoped to prohibit independent re- serialization where an upstream party has already established the action's canonical serialization, per the failure mode documented in the SCITT typed-reference specification. Version -06 closes gaps surfaced by a WIMSE-style security review pass against -05's own text and reference sample code: a JWKS trust- anchor bootstrap requirement, a corrected key-compromise remediation procedure that no longer requires re-signing already-committed audit artifacts, an explicit Level 1/2 residual-risk disclosure for a compromised-but-signing GEC, a defined failure path for KIA signer quorum failure at Session Block close, referential-integrity enforcement for causal_parent_id, and guidance against alert-fatigue false positives in session_sequence_number gap detection. This revision also carries an idnits repair pass covering reference classification, citation hygiene, and formatting. Version -08 is an editorial revision with no normative content changes: nine sibling-draft citations had gone stale against those drafts' current live versions and are updated to draft-sato-soos-idp-06, draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-sov-03, draft-sato-soos-mjwt-06, draft-sato-soos-mad-05, draft-sato-soos-kia-06, draft-sato-soos-cap-rrs-04, and draft-sato-soos-acd-02 respectively. |
| | An Architecture for Auditing Agent Delegation and Interactions |
| |
|
This document describes an architecture for auditing of agent-driven interactions on the Internet. Autonomous and semi-autonomous software agents, including those based on artificial intelligence, increasingly act on behalf of users, organizations, and services. Existing auditing mechanisms often capture isolated system events but do not consistently represent delegation relationships, user intent, or evolving authorization. In agent-driven systems, auditability requires linking intent, delegation, authorization, and execution. The proposed architecture enables this through distributed audit record generation, propagation of audit context, optional attestation, and additional logging for transparency. |
| | The Sovereign Object (SOV) for Agentic AI Systems |
| |
|
When an AI agent acts on your behalf, it acts on something: a document, a booking, a contract, a financial instruction. No existing IETF specification defines what that something is, what states it can be in, who governs it, or how it is irreversibly erased when the relationship ends. Agentic AI governance protocols -- including intent declaration, human escalation, audit recording, and constitutional prohibition -- all require a normative definition of the governed resource that agents operate on: the structured, stateful, policy-carrying entity to which agent authority is bound and upon which governed transitions execute. No existing IETF specification defines this primitive. This document defines the Sovereign Object (SO): a causally ordered, policy-governed, typed, living document that evolves through a predefined finite state space under Governing Enforcement Component (GEC) authority. The SO is the unit of governance in the SOOS protocol family: the thing agents operate on, the GEC governs, and human principals reason about. This document specifies the SO's five-layer structure (Identity, State, Event Stream, Typed Graph, Attachment Index), its Zone A / Zone B boundary model, its five-phase lifecycle, its SO Type system, its Cedar policy context model, and the binding model by which a Mandate JWT binds an agent to a specific SO instance. Version -02 extends SOV-01 with: (a) SO Type registry governance including a SOV-02 subtype model for structured SO Type composition; (b) the Standing Plan Object (SPO) as a normative SOV-02 subtype, specifying declarative scope constraints, Cedar bundle reference, CAP-RRS catalog reference, and IDP structural validation integration; (c) event stream integrity normative requirements including GEC-signed append-only guarantees, kernel_id binding, and OpenTelemetry integration for observability bridging; (d) expanded Security Considerations addressing SO state manipulation, event stream tampering, SO Type spoofing, and stale state_constraint exploitation; and (e) IANA registrations for the SO Type code namespace and SPO media type. Version -03 removes the Mission Plan SO and Mission Status SO subtypes, which -02 defined normatively alongside a SOV-01 SO Type Registry Governance and SOV-02 Subtype Model that already generalizes to them. These subtypes are now owned exclusively by the Agentic Orchestration Protocol (AOP), which defines a materially more complete Sub-Goal DAG model (typed dependency edges, deadline tracking, critical-path annotation) than -02's; duplicating them here created a cross-draft inconsistency this revision resolves by deferring entirely to AOP. Version -03 also reorders the Cedar policy evaluation sequence to place Mandate JWT verification before SO Type Cedar policy evaluation, matching the Mandate JWT draft's own explicit verification-sequencing requirement, and updates cross-draft version references throughout to the current suite versions. The Sovereign Object is the architectural foundation referenced normatively by the other SOOS governance drafts. |
| | The Mandate JWT (MJWT) for Agentic AI Systems |
| |
|
An AI agent that can act without a verifiable, human-traceable authorization record is an agent without an owner. Existing authorization credentials tell you what an agent is permitted to do; none of them tell you who authorized it, on which specific object, under which mission, or how far that authority can be delegated before it reaches this agent. This document defines the Mandate JWT (MJWT): a WIMSE workload credential profile that binds an AI agent's authority to a specific Sovereign Object instance under a named human principal, with a cryptographically enforced delegation ceiling and an eight-dimensional Narrowing Property that prevents any sub-agent from exceeding the authority of the human principal at the root of the chain. Version -02 adds a seventh narrowing dimension (consent scope), the consent_scope claim carrying data subject consent state for APPI/GDPR compliance, the sub_agent_scope claim for consent attenuation across delegation hops, a Purpose Code Registry, and HEM_CONSENT_REQUIRED integration for fail-closed consent enforcement. The MJWT is the authorization primitive referenced by the other SOOS governance drafts. Version -03 corrects an IANA registration issue: the two registries requested there are renamed to drop the redundant word "Registry" from the registry name itself, and each now includes the Designated Expert Guidance that a Specification Required registration policy requires. No new claims, codes, or normative behavior are introduced in -03; this is a registration-format correction only. Version -04 addresses four findings from a WIMSE security review checklist dry-run against -02/-03 (DR-MJWT-KIA-CHECKLIST-01): the parent-mandate check at Cedar-action verification time is tightened from a disjunctive "retrieve or verify" to a mandatory live re-verification of the parent's current signature and revocation status, closing a parent-swap-class window; the Revocation Registry is now stated explicitly to be the same Revocation Registry the KIA draft defines, and the residual cross-instance propagation-lag risk this implies is now named explicitly, mirroring how that draft discloses its own XPID revocation gap; and a new Security Considerations entry states plainly that MJWT does not itself establish or verify a human_principal_id's root authority. Version -05 closes gaps surfaced by a WIMSE-style security review pass against -04's own text: an eighth Narrowing Property dimension, max_delegation_depth, closes an unbounded-delegation- depth Denial of Service vector that -04's own text named but did not bound; the consent_reference staleness defense is upgraded from a SHOULD-level recommendation to a MUST, extending the same live-re-verification discipline already applied to parent mandates; and the Introduction's description of RFC 8693 inheritance is corrected to no longer claim use of the optional may_act claim, which this document does not in fact use. This revision also carries minor idnits and citation-hygiene fixes. Version -06 is an editorial revision with no normative content changes: six sibling-draft citations (HEM, CAP, KIA, MAD, AEP, IDP) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-kia-06, draft-sato-soos-mad-04, draft-sato-soos-aep-04, and draft-sato-soos-idp-06 respectively. |
| | Multi-Agent Delegation in Sovereign Object Systems |
| |
|
When a consequential task requires multiple AI agents -- one to coordinate, others to execute, each operating on different objects in a shared workflow -- who is responsible for the outcome? Which agent caused which state change? Under whose authority? If the coordinating agent's authorization is revoked, does the authority of every sub-agent it delegated to immediately expire? If one agent in a parallel workflow exceeds its scope, can that excess propagate to others? This document defines the Multi-Agent Delegation (MAD) protocol, extended in version -03 with four new normative mechanisms: the Sub-Agent Composition Record (SACR) for kernel-governed sub-agent spawning; the hub-only constraint for sub-agent communication topology; XPID cross-cluster integration derived from KIA-03; and full normative specifications for the R-1 through R-7 revocation trigger classes with completion states and cascade behavior. Version -04 adds an eighth trigger class, R-8 (Compromise), closing a gap identified while mapping MAD's taxonomy onto the Mandate Lifecycle Events (MLE) profile's `reason: compromise` value, which had no R-code counterpart. MAD provides a single recoverable property: the accountability chain is always reconstructable from the GEC-signed audit record alone. Cascade revocation means one decision stops the entire tree. SACR means the spawning of that tree is itself governed. Version -05 is an editorial revision with no normative content changes: sibling-draft citations (IDP, HEM, CAP, MJWT, AEP, AOP) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-idp-06, draft-sato-soos-hem-07, draft-sato-soos-cap-06, draft-sato-soos-mjwt-06, draft-sato-soos-aep-04, and draft-sato-soos-aop-03 respectively; the CAP-RRS and PT citations in the Companion Drafts list are similarly updated to -04 and -04; and the FAIP citation is migrated from the versioned [I-D.sato-soos-faip] form to the non-versioned [SOOS-FAIP] form, since FAIP is a Class B specification that will not be submitted to the IETF Datatracker. |
| | The Agent Execution Protocol (AEP) for Agentic AI Systems |
| |
|
An AI agent that can act cannot be governed unless there is a normative contract for how it receives its world, how it declares its intent, and how it learns what it is and is not permitted to do -- at every step, in every iteration, without exception. AI agents operating on governed resources require a normative interface contract between their internal reasoning loop and the Governing Enforcement Component (GEC) that enforces authorization policy, records transitions to a tamper-evident Event Stream, and mediates access to Sovereign Object instances. Existing agent frameworks define no such contract. Agents submit actions without a normative delivery protocol for the state and permission context they act on; GECs enforce policy without a normative protocol for communicating denial rationale back to agents; human oversight is invoked without a normative session state that governs the resulting suspension. This document defines the Agent Execution Protocol (AEP): the normative five-step loop -- SENSE, REASON, PLAN, ACT, OBSERVE -- that specifies how a governed AI agent interfaces with GEC services at each iteration. The AEP defines the Context Package delivered at SENSE, the GEC Query Interface exercised at PLAN, the Transition Request submitted at ACT, and the atomic GEC response received at OBSERVE. The AEP specifies two conformance modes -- Standard and Goal Execution Engine (GEE) -- and normatively integrates the Intent Declaration Primitive, the Mandate JWT, the Human Escalation Mechanism, the Governance Audit Record, the Constitutional AI Protocol, and the Sovereign Object as components of a single governed execution architecture. The REASON step is intentionally GEC-unspecified: the LLM reasoning engine is opaque to the protocol. The AEP is the transmission between the LLM engine and the GEC enforcement substrate. Version -02 adds: XPID binding at session open (GEC MUST bind XPID from KIA-verified Party Registry; MUST NOT accept client-supplied XPID); STALLED and PLAN_B_ACTIVE session states with full normative definitions, trigger conditions, and resume conditions; Expected Outcome Declaration (EOD) as a pre-session commitment structure with primary outcome, acceptance envelope, and pre-declared Plan B; RETRY_CONTINUATION normative strengthening with what-changed-since- last-attempt requirement and prior_denial_count Cedar attribute; an AEP-to-OTel mapping with mandatory span attributes at each AEP phase; four new Security Considerations; and updated IANA registrations for new state codes and EOD media type. Version -03 adds Step 4a of the GEC execution sequence: DAM lineage and residency validation. When a Transition Request's optional da_production field is present, the GEC resolves every referenced input artifact, confirms each is in a VALID lifecycle state, and computes the resulting artifact's data_residency under the applicable narrowing rule -- before the transition's Event Stream write occurs, and under the same signature as that write. This is the enforcement point for a rule the data governance companion specification had defined but this document, until now, gave no mechanism to actually apply. Version -04 is an editorial revision with no normative content changes: the KEE-1 citation was migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. |
| | Progressive Trust (PT) for Agentic AI Governance Systems |
| |
|
When a new employee joins an organization, they begin with limited authority. As they demonstrate good judgment -- completing tasks reliably, asking for guidance at the right moments, recovering well when things go wrong -- they earn greater trust and, with it, greater authority. If their performance degrades, or if months pass without any demonstration, that trust diminishes. This is how human organizations manage authority over time. AI agents have no equivalent mechanism. Today, an AI agent's authority is declared once in a credential at issuance time and does not respond to its behavioral record. An agent that has completed 200 successful sessions with a proven track record holds the same credential as a newly deployed agent. The human principal who issued both credentials made a judgment at issuance time; nothing that happened since is reflected in the agent's authority. This document defines Progressive Trust (PT): a behavioral trust model for AI agents in which authority recommendations evolve in response to cryptographically verified evidence of actual performance. PT measures five behavioral properties: whether the agent's self-assessed confidence matches its actual outcomes; whether it asks for human oversight at the right moments; whether it achieves its goals; whether it avoids decisions it later has to reverse; and whether it adapts when its action is rejected. These measures are derived exclusively from the tamper-evident, GEC-signed Event Stream -- an agent cannot influence its PT Score except through actual governed behavior. PT does not grant authority automatically. It generates structured recommendations, backed by behavioral evidence, for human principal review and approval. Human principals decide whether to elevate or reduce an agent's authority. PT ensures that decision is informed rather than made in the absence of history. Progressive Trust is the longitudinal complement of the Agent Execution Protocol (AEP): AEP governs what an agent does within a session; PT measures what an agent has done across sessions and translates that history into structured authority recommendations. No equivalent specification exists in IETF, ISO, NIST, or any agentic AI governance standards body. Version -04 is an editorial revision with no normative content changes: the FAIP citation was migrated from the versioned [I-D.sato-soos-faip] form to the non-versioned [SOOS-FAIP] form, since FAIP is a Class B specification that will not be submitted to the IETF Datatracker. |
| | Kernel Identity and Attestation for Governing Enforcement Components |
| |
|
This document specifies the Kernel Identity and Attestation (KIA) protocol for the Sovereign Object OS (SOOS) governance architecture. KIA defines the cryptographic identity of the GEC, the trust chain anchoring kernel authority from hardware root through operator root keypair to every signed Event Log entry, the GEC Manifest schema for runtime state attestation, and the Revocation Registry maintenance requirements. KIA is the Layer 0 signing and attestation component on which the audit trail guarantees of draft-sato-soos-gar, the mandate enforcement guarantees of draft-sato-soos-mjwt, and the multi-agent delegation chain of draft-sato-soos-mad all depend. Version -03 adds FROST threshold signing for high-availability GEC keypair deployments, the Cross-Principal Identifier (XPID) for cross-instance federation audit correlation, the XPID cross- instance trust model, and four new Security Considerations addressing FROST nonce reuse, XPID revocation gap, identity takeover via claimed identifier (CVE-2025-13609 class), and attestation channel binding (CVE-2026-33697 class). This document is the reference specification for the KIA RATS WG presentation at IETF 126 Vienna. The XPID primitive and the CVE-2026-33697 attestation channel binding defense are the primary novel contributions presented to the RATS WG. Version -04 corrects a registry-format mismatch identified by IANA early review (#1456067): the IANA Considerations request to register XPID_DERIVED and XPID_VERIFICATION_FAILED into the GAR Authority Lifecycle Event Types Registry the GAR draft defines now uses that registry's actual column set (Event Type, Class, Reference) and assigns both entries the newly-defined Class ID (Identity/ Federation event). No new event types, fields, or normative behavior are introduced in -04; this is a registration-format correction only. Version -05 discloses a known open issue found by a WIMSE security review checklist dry-run against -03 (DR-MJWT-KIA-CHECKLIST-01, Finding 4): the Cross-Instance Trust Model verifies an XPID but does not restrict which federation participants can see the underlying Evidence in the first place. This is named as OQ-KIA-EVIDENCE-VIS, following the same acknowledge-rather-than- silently-omit pattern this document already uses for OQ-S-XPID-REV. No mechanism is specified in -05; resolution is deferred, consistent with how OQ-S-XPID-REV is treated. Version -06 closes out a full WIMSE Security Review checklist pass (Stage 0 through Stage 2) run against -05. It restores seven GEC Manifest fields silently absent since -03 despite -03's text claiming the -02 schema was carried forward in full, including attestation_certificate; mints a dedicated XPID namespace UUID in place of the reused DNS namespace UUID; updates the FROST reference from the CFRG working draft to RFC 9591 and corrects the nonce-generation section citations; resolves a genuine bootstrapping contradiction between the quorum-failure signing prohibition and the quorum-failure alerting requirement (new CONF-KIA-24); tightens Security Considerations wording describing the XPID derivation input; adds a new Denial of Service Security Considerations entry for the quorum-isolation availability asymmetry; and adds a Privacy Considerations section addressing XPID's by-design stability and cross-context linkability. No prior conformance requirement is weakened by this revision. Version -07 is an editorial revision with no normative content changes: sibling-draft citations had gone stale against those drafts' current live versions and are updated to draft-sato-soos-cap-06, draft-sato-soos-gar-08, draft-sato-soos-mad-05, draft-sato-soos-mjwt-06, and draft-sato-soos-idp-06; the companion-drafts discussion's HEM and AEP mentions are similarly updated to hem-07 and aep-04. |
| | The Agent Compliance Disclosure (ACD) Protocol for Agentic AI Systems |
| |
|
A regulated resource provider -- a bank, a government API, a healthcare records system -- receives a request from an AI agent. The agent claims to operate under a constitutional compliance policy and a valid mandate. The resource provider has no mechanism to verify these claims. Without a machine-verifiable compliance disclosure, the resource provider cannot confirm the agent's governing law, its active prohibition set, its audit trail reference, or its principal hierarchy -- before granting access. This document defines the Agent Compliance Disclosure (ACD) Protocol: a machine-to-machine compliance handshake that must complete before an AI agent is granted access to a regulated resource class. ACD defines the ACD Record schema (a three-layer structured disclosure produced by the SOOS kernel, covering legal identity, constitutional compliance, and principal hierarchy), the ACD Presentation Protocol (the query/response exchange between a resource provider and the SOOS kernel), the ACD Trust Hierarchy (operator-declared trust levels and Audit Principal credentials), the ACD-to-MJWT binding (ACD MUST reference the session MJWT jti), and the GAR integration (ACD presentation events as Authority Lifecycle Events). ACD Records are produced exclusively by the Governing Enforcement Component (GEC), signed by the kernel's KIA private key, and logged in the Governance Audit Record (GAR). LLM self-report of compliance posture is architecturally insufficient and MUST NOT be used as an ACD disclosure surface. ACD is the inbound complement to the Resource Governance Protocol (RGP): where RGP governs outbound capability discovery, ACD governs inbound compliance verification. Together they define the complete resource access governance flow for SOOS-governed agents. Version -02 added the aep_session_id Layer 3 field, distinct from acd_session_id, to bind a cached ACD Record to the specific AEP session it was produced within (Section 6.3); strengthened the ACD Record Replay defense that checks this binding from a SHOULD to a MUST (Section 12.4); added the confirmation_basis field (NOTIFIED | INFERRED) to ALE-058 so an auditor can distinguish a confirmed validation pass from one merely inferred from the absence of a failure record (Section 10.1); added Compliance Handshake Volumetric Abuse as a new security consideration (Section 12.5); and migrated the KEE-1 citation from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. Version -03 is an editorial revision with no normative content changes: six sibling-draft citations in Section 15.1 had gone stale against those drafts' current live versions and are updated to draft-sato-soos-aep-04, draft-sato-soos-gar-08, draft-sato-soos-kia-07, draft-sato-soos-mjwt-06, draft-sato-soos-rgp-02, and draft-sato-soos-sov-04 respectively; and the Table of Contents, which omitted Section 12.5 from -02's submission, now lists it correctly. |
| | Cross-Principal Agent Communication -- PEER Transaction Record |
| |
|
When two independently-principaled AI agents transact with each other, each operates under its own mandate root, its own Governed Execution Context (GEC), and its own audit chain. No shared kernel exists to mediate the exchange. Existing SOOS orchestration primitives (MAD, SACR) govern sub-agent relationships within one mandate tree; they do not address the peer case. This document defines the PEER protocol: a problem statement and architecture for cross-principal agent communication. PEER introduces the PEER Transaction Record (PTR) as a new first-class SOOS primitive providing a jointly-derived correlation artifact (ptxn_id) that links the two independent audit chains produced by a cross-principal transaction -- without requiring a neutral third party, shared kernel state, or cross-principal constitutional layer. This document is a problem statement and architecture draft. The PTR field schema, the ptxn_id derivation, and the responding-GEC- countersignature requirement are normative as of this revision. Full normative ALE-PEER event schemas, IANA registration templates, and a dispute resolution procedure for conflicting GAR chains remain open and are carried to a future revision. Version -02 is an editorial revision with no normative content changes: stale sibling-draft citations to CAP, HEM, and FAIP were brought current. |
| | The Resource Governance Protocol (RGP) for Agentic AI Systems |
| |
|
An AI agent that can act on resources cannot be governed unless those resources declare what they can do, under what constraints, and at what trust level -- before the agent acts. Existing resource description standards (digital twin profiles, capability catalogs, API registries) provide no governance envelope: they declare capability but not compliance posture, trust attestation, or mandate-scope compatibility. An agent that proceeds without this information may assign tasks to resources that are outside its mandate, below its required trust threshold, or unable to satisfy its compliance obligations. This document specifies the Resource Governance Protocol (RGP): a two-stage discovery and declaration protocol by which physical resources, digital services, and AI model instances declare their capability class, trust level, operational constraints, and current availability state to a governed AI agent operating under a Mandate JWT. Stage 1 delivers a capability fingerprint via a well-known URI; Stage 2 delivers a full governance envelope for mandate-scope validation and Resource Map Sovereign Object construction. RGP defines eight capability classes (CAP-COMP through CAP-EXP), four trust levels (TRUST-0 through TRUST-3), a session-scoped Resource Map Sovereign Object, a three-condition autonomous fallback test, and normative integration with the Agent Execution Protocol, the Governance Audit Record, and the Human Escalation Mechanism. RGP also defines an AI Model Capability Declaration (RGP-Model) for the governance of AI model instances as first-class resources within a SOOS-governed deployment, and a Physical Resource Profile (RGP-Physical) for normative binding to existing digital twin standards. Version -02 is an editorial revision with no normative content changes: KEE-1 citations were migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker. |
| | The Governed Remediation Protocol (GRP) for Agentic AI Systems |
| |
|
This document specifies the Governed Remediation Protocol (GRP) for agentic AI systems operating under the Sovereign Object OS (SOOS) framework. GRP defines the normative remediation action set available to a SOOS governance kernel when agent execution encounters a governed failure condition: FALLBACK (autonomous resource substitution), RETRY (bounded autonomous retry), ESCALATE (human escalation boundary), and ROLLBACK (reversible action undo). GRP specifies the conditions under which each action class may be taken autonomously and the boundaries at which Human Escalation Messaging (HEM) is required. GRP operates at the intersection of the Resource Governance Protocol (RGP), the Agent Execution Protocol (AEP), and the Human Escalation Mechanism (HEM), and normatively references the Governance Audit Record (GAR) for logging all remediation events. GRP adopts DEC-RGP-08 (the three-condition autonomous fallback test) verbatim from the Resource Governance Protocol as the normative FALLBACK action class boundary rule. Version -02 restores Section 9.4 (Artifact-Level Impact Refinement), the CONTENT_CORRECTION change_class value, and the affected_da_id field, which were inadvertently dropped from -01's Datatracker submission during an unrelated editorial pass; a WIMSE-style review of the restored text found and closes a genuine gap in its original form -- Section 9.4(1)'s impact query walked only one hop of the derived_from derivation graph, missing artifacts transitively downstream of a correction, and now walks the graph transitively with a bounded traversal depth. This revision also mirrors RGP-02's ALE-026/ALE-064/ALE-066 double-recording reconciliation into this document's own Section 11.6 (previously stated only on RGP's side), and renames ALE-066 from GRP_FALLBACK_ACTIVATED to GRP_MEDIATED_FALLBACK_ACTIVATED to remove its near-duplicate naming collision with RGP's own ALE-026 (RGP_FALLBACK_ACTIVATED). This revision adds Remediation Outcome Verification (Section 11.7): FALLBACK and RETRY could previously complete with a clean mechanical success record while the outcome the session actually needed still went undelivered, with no check against the session's own EOD until AEP's own session-close evaluation, if any GRP action had even run by then. A new ALE-070 (GRP_REMEDIATION_VERIFIED) closes that gap, reusing AEP's own MATCHED/PARTIAL/PLAN_B_MATCHED/ UNMATCHED vocabulary so a mid-session verification result is directly comparable to the session's eventual outcome. Three prior references to the EOD as the "IDP Expected Outcome Declaration" are also corrected to AEP, its actual source. |
| | The Agent Orchestration Protocol (AOP) for Agentic AI Systems |
| |
|
A single AI agent acting within a governed session is not the hardest governance problem. The hardest problem is what happens when that agent must delegate: when the mission is too large for one agent, when sub-tasks require specialized capability, when parallel execution is necessary, and when each delegated sub-agent is itself consequential enough to require governance. Who authorized the spawn? Who owns the plan? If the sub-agent deviates, who decides whether to re-plan or escalate? If the mission fails mid-execution, who constructs the audit record? This document defines the Agent Orchestration Protocol (AOP): the normative protocol through which a governed orchestrating agent decomposes a mission into a governed sub-goal directed acyclic graph (DAG), delegates sub-goals to sub-agents via kernel-mediated Assignment Primitives, and maintains a Mission Plan Sovereign Object (Mission Plan SO) and Mission Status SO across the full lifecycle of multi-agent execution. AOP specifies three core constructs: the Expected Outcome Declaration (EOD) as the pre-commitment structure for the full mission and each delegated sub-goal; the Mission Plan SO encoding the sub-goal DAG with SEQUENTIAL, PARALLEL, and CONDITIONAL dependency types; and the Assignment Primitive as the governed handoff mechanism that requires an Endorsed EOD and produces a Sub-Agent Composition Record (SACR) per the Multi-Agent Delegation protocol. AOP integrates with the Intent Declaration Primitive at each EOD boundary, the Agent Execution Protocol for per-agent session governance, the Governance Audit Record for mission lifecycle audit events, and the Human Escalation Mechanism for re-planning authority escalation. The normative reference scenario for AOP is a three-tier emergency management orchestration system in which a Master AI orchestrates regional coordination agents, which orchestrate domain-specialist leaf agents (e.g., evacuation routing models), each tier operating under full SOOS governance. Version -01 completed the document body: the Expected Outcome Declaration in AOP Context, Mission Plan Sovereign Object, Mission Status Sovereign Object, Assignment Primitive, Re-planning Authority, AOP-to-GAR Integration, Five-Phase Planning Intelligence Model, and the Reference Scenario were placeholders in -00 and are now fully specified, resolving a three-way contradiction in -00 about whether Sub-Goal EOD endorsement happens before or after SACR issuance (it is after, gated on SACR existence). Version -02 fixes a document-structure ordering defect carried over from -00, closes -00's open Denial of Service gap with new normative security guidance, and corrects a set of reference-list defects: two normatively cited documents were never defined in the reference list, and ten companion-draft citations in the Related Work discussion used one-off versioned reference keys that matched no defined entry; all now cite consistently and are updated to current SOOS suite versions. The Related Work discussion's own description of Mission Plan SO / Mission Status SO ownership is corrected to match this document's own Introduction and current reality: both subtypes are defined by AOP, not by SOV. Version -03 is an editorial revision with no normative content changes: KEE-1 citations were migrated from the versioned [I-D.sato-soos-kee] form to the non-versioned [SOOS-KEE] form, since KEE-1 is a permanent local-only specification that will never be submitted to the IETF Datatracker; and three sibling- draft citations (HEM, CAP, CAP-RRS) had gone stale against those drafts' current live versions and are updated to draft-sato-soos-hem-07, draft-sato-soos-cap-06, and draft-sato-soos-cap-rrs-04 respectively. |
| | The Data Artifact Management (DAM) Protocol for Agentic AI Systems |
| |
|
This document specifies the Data Artifact Management (DAM) protocol for agentic AI systems governed by the Sovereign Object OS (SOOS) framework. DAM defines a typed taxonomy of data artifacts produced and consumed by AI agents, a governance envelope for each artifact type specifying provenance, access policy, temporal validity, and retention requirements, and the normative interface between agent- generated artifacts and the Governance Audit Record (GAR). DAM addresses three classes of data in agentic systems: kernel- generated artifacts (IDP event logs, GAR records, AEP session state), agent-generated artifacts (outputs of agent actions), and externally ingested artifacts (data made available by resources). DAM specifies the Data Artifact type (DA-Type) taxonomy referenced in the Resource Governance Protocol (RGP) and the Agent Execution Protocol (AEP). |
| | Evaluation Methodology for Network Anomaly Detection |
| |
|
The Network Management Operations (NMOP) working group has adopted documents describing an architecture, an operational lifecycle, and a semantics for network anomaly detection. Those documents direct implementers to minimize false positives and false negatives, but do not define how the accuracy of an anomaly detection implementation is to be measured, compared, or tracked over time. This document describes an evaluation methodology for anomaly detectors operating on network and infrastructure telemetry, whether the detector is rule-based, statistical, or machine-learning-based: the metrics to report and their known failure modes, a benchmarking procedure based on controlled fault injection and replay, ground-truth labeling and scoring across multiple telemetry signals, and the properties a benchmark dataset needs to support reproducible, comparable evaluation. The methodology is informational and complements the adopted NMOP anomaly-detection documents. |
| | A Framework for Comparing Independently Derived Identifiers |
| |
|
Specifications use equality of independently derived identifiers to compare underlying values. Those comparisons require shared rules for admission, equivalence, derivation, and output interpretation. Inconsistent rules can give different identifiers to equivalent values or equal identifiers to values that the comparison distinguishes. This document presents a framework for specifying and reviewing these rules as a comparison contract. It connects source mappings to derivation-domain equivalence and the conclusions supported by equal and unequal outputs. It distinguishes information loss before a downstream operation from that operation's own false match properties. A review traces the relevant specification clauses, records supporting evidence, and identifies failed or unestablished obligations. The framework provides guidance for concrete identifier specifications; it defines no identifier format or derivation algorithm. |
| | 6G-Era Communication Authorization-to-Reach: Separating Identifier Possession from Permission to Contact |
| |
|
Many Internet and telephone communication systems treat possession of a routable identifier as sufficient to attempt contact. A telephone number, SIP URI, messaging handle, relay address, or marketplace contact reference can therefore remain a reusable reachability path after the purpose of disclosure has ended. Existing IETF and industry mechanisms solve related but different problems. STIR and SHAKEN authenticate or attest originating identity: they answer whether the calling party is who it claims to be, not whether that authenticated party currently holds bounded, purpose-scoped, revocable permission to reach a particular recipient. Virtual or masked numbers hide a persistent endpoint but commonly leave a substitute route active while the alias is valid. OAuth can express delegated API authorization. Spam scoring and call screening classify or reject an attempt after some path already exists. This document describes an authorization-to-reach model. A visible communication handle is not, by itself, permission to create a communication effect. A request is held as a candidate until current, purpose-scoped, revocable, and optionally consumable authority is validated. The document is informational. It asks whether the IETF Applications and Real-Time area should define interoperable semantics or an encoding for that authority (for example a PASSporT claim, a SIP header or pre-INVITE check, or a reusable authorization object). This work is not a 3GPP radio, core-network, or IMT-2030 architecture proposal. References to machine-scale or future-network traffic are motivational only. The intended protocol home, if any, is IETF work on SIP, STIR, messaging, and Internet communication identifiers. The motivation is nonetheless sharpened by the trajectory of upcoming 6G and IMT-2030 network infrastructure: as networks move toward AI- native architectures in which software agents, network functions, and third-party AI systems can originate signaling at machine speed, and as vendors including Qualcomm and Huawei publish AI-native 6G radio- and core-network research, an authorization-to-reach gap that is tolerable at human-initiated call volumes becomes structurally more significant at machine-originated volumes. Global telecom operators such as Deutsche Telekom, Orange, AT&T, and Vodafone -- among the carriers with the largest exposure to SIP, STIR/SHAKEN, and voice- messaging signaling volumes -- are named here only as illustrative examples of the operator community for whom an interoperable authorization-to-reach answer would be most directly relevant. This document does not depend on any particular 6G, IMT-2030, Qualcomm, Huawei, Deutsche Telekom, Orange, AT&T, or Vodafone architecture, deployment, or product, and does not assert that any of them has adopted, evaluated, or endorsed this proposal; it identifies why telecom infrastructure evolution makes the underlying Internet- identifier-layer question more urgent for IETF to consider now rather than after machine-scale traffic arrives. Google Maps, Apple Maps, and social or commerce platforms with map- adjacent or messaging-based business discovery features such as Meta Business (including Facebook and Instagram business discovery and messaging) are referenced elsewhere in this document family as recognizable illustrative examples of where a visible communication handle is exposed after discovery; no affiliation, endorsement, implementation, adoption, or technical alignment by Google, Apple, Meta, Qualcomm, Huawei, Deutsche Telekom, Orange, AT&T, Vodafone, or any other named provider is implied by this document. |
| | Preventing Unauthorized Adult and Age-Restricted Content Rendering to Children Through Hardware-Rooted Execution Finality |
| |
|
Online child-safety controls commonly operate before the final rendering boundary. Platforms may use account-age flags, parental settings, content labels, recommender controls, server-side classification, age-assurance systems, access policies, or application filters to decide whether adult or age-restricted content should be available to a user. Those controls are important, but an upstream decision does not by itself guarantee that the content cannot later be decrypted, decoded, composited, rendered, forwarded, mirrored, or otherwise materialized through another software or device path. The practical motivation is also personal. As a father of three, I have encountered this same problem in my own family: a parent may understand that an unrestricted adult-configured phone should not be handed to a minor, yet a son or daughter may repeatedly ask to use the parent's phone and, in ordinary family life, the parent may eventually hand it over. Human affection, trust, convenience, and everyday family circumstances cannot simply be designed away. Existing age checks, parental controls, child profiles, and application restrictions are useful, but they do not necessarily provide a simple device-wide protection for this moment of handover. Requiring the adult to provide a fingerprint, facial verification, or other authentication for every individual video would also create an impractical user experience. This document therefore considers a Temporary Under-18 Handover Mode: before giving an adult-configured device to a child, the adult can place the device into a temporary minor-protection state, after which Execution-Finality makes that state technically consequential at the protected rendering boundary. This is therefore not only an abstract design problem for me; it is a solution developed to address a problem I encounter myself as a parent, with the broader aim of turning that everyday family difficulty into a practical protection that may also help other families. This problem is becoming more important as content delivery becomes more distributed, encrypted, AI-mediated, personalized, and dynamically generated. A modern device may receive content through applications, browsers, content-delivery networks, embedded web views, messaging clients, recommendation systems, generative-AI services, caches, cloud gaming or streaming pipelines, local AI models, or third-party SDKs. The security question is therefore no longer only whether content was classified or whether an age check occurred upstream. A later question must also be answered: is this specific protected content authorized to become perceptible to this recipient, on this device, under the current eligibility, policy, and revocation state, at this moment? This document defines a protected rendering execution-finality architecture for adult, pornographic, sexually explicit, violent, gambling-related, or otherwise age-restricted content. A proposed rendering is represented as a Restricted Content Candidate Act and remains in a Non-Renderable State until a Protected Enforcement Domain validates the applicable recipient, content, device, policy, age-or-eligibility, freshness, revocation, and sink predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer Rendering Finality Authority. A Protected Rendering Finality Sink independently verifies that authority immediately before the content becomes perceptible. Depending on the implementation, the sink may control content-key release, decryption, media-decoder enablement, GPU or compositor access, protected-surface creation, audio output, casting, screen mirroring, display enablement, or an equivalent materialization boundary. Content bytes may therefore be delivered to a device while remaining technically non-renderable. The architecture deliberately does not define a universal age- estimation algorithm, identity system, or content-classification scheme. Those mechanisms may supply inputs to the Protected Enforcement Domain. This document defines the consequence-control step that prevents an upstream policy result from becoming merely advisory at the point of rendering. UNICEF has warned that pornographic content can harm children and that digital restrictions have not kept pace with technological shifts. The ITU Child Online Protection programme provides global guidance for safer digital environments, and the United Nations Committee on the Rights of the Child has called for protection of children from harmful content and online risks in the digital environment. The European Commission has likewise adopted protection-of-minors guidance and a privacy-preserving age- verification approach for adult-restricted content. These materials motivate the problem addressed here; they do not endorse this particular technical architecture. The central protocol principle is: permission to deliver content is not permission to render it. |
| | Privacy-by-Design Architecture for Map-Based Business Discovery Using Query-Scoped Non-Bearer Authorization |
| |
|
Map-based discovery systems can help a person identify nearby businesses, properties, service providers, hotels, clinics, restaurants, and other commercial actors, but discovery frequently transitions into communication through a persistent telephone number, reusable virtual number, open message thread, callback route, or other contact path. A person may intend only a short first conversation with several candidates, while the communication mechanism unintentionally creates continuing reachability after that inquiry has ended. This document describes an architecture in which first contact and future reachability are separate authorization events. After a user creates a map search, property inquiry, service request, booking inquiry, quote request, or similar context, a platform can create a query-scoped non-bearer communication reference and bounded preview authority. A user or eligible business can participate in a real but limited first interaction. Continued communication is separately authorized and remains bound to attributes such as the original query, business identity, purpose, channel, effect, validity window, nonce, quota, revocation state, and enforcement point. Possession of a number, handle, previous conversation, lead assignment, API credential, or payment event is not by itself sufficient future- contact authority. The architecture separates marketplace policy from communication effectuation. A Communication Authority Service creates a protected authorization binding, while an enforcement point reconstructs the actual attempted communication, checks current protected state, atomically reserves or consumes relevant authority, and releases the communication-bearing resource only after successful verification. This permits privacy-preserving first contact, controlled future reachability, preview-qualified lead monetization, and AI-assisted business discovery without requiring a new public telecom protocol for initial deployment. Google Maps, Apple Maps, mobile operating- system discovery surfaces such as iOS and Android, and social and commerce platforms with map-adjacent or messaging-based business discovery features such as Meta Business (including Facebook and Instagram business discovery and messaging) are used as recognizable illustrative examples; no affiliation, endorsement, implementation, adoption, or technical alignment by Google, Apple, Meta, or any other named provider is implied. The architecture's binding of recipient identifiers to pseudonymous, query-scoped, time-limited, purpose-bound, and revocable authorizations rather than persistent contact data is consistent with the data protection principles of the EU General Data Protection Regulation (GDPR) -- including data minimization and purpose limitation (Article 5), storage limitation through bounded validity and quota, and privacy by design and by default (Article 25). This document describes a technical architecture only; it does not constitute a legal compliance determination, and conformance with GDPR or any other data protection law depends on the specific deployment, controller and processor roles, and operational practices of an implementing platform. |
| | A Framework for Agent Discovery in DAWN |
| |
|
The IETF DAWN (Discovery of Agents With Names) working group is developing a suite of documents addressing agent discovery across organizational boundaries, initially focused on discovery of AI agents and their capabilities. Existing DAWN contributions include terminology, requirements, use cases, gap analysis, a discovery mechanism survey, and an information model for Minimum Discoverable Information (MDI). This document describes a two-layer federated reference architecture framework that operates within the DAWN. The first layer, the Local Discovery Plane, performs zero-configuration agent advertisement and collection inside each local site, without mandating a specific link- local protocol. The second layer, the Federation Plane, builds a federation among site gateways to exchange lightweight Federation Metadata Records (FMRs) — a concrete binding of DAWN MDI — across independent administrative domains, while full Capability Cards are retrieved on demand via authenticated unicast. The architecture emphasizes data sovereignty through an Export Policy Engine, separates lightweight metadata indexes from full capability documents, and supports multiple federation synchronization strategies. This document is informational. It does not define normative protocol formats, nor does it compete with existing DAWN proposals such as ACAP, Agent Directory, or ARDP; rather, it provides a deployment framework showing how these mechanisms may be composed at administrative boundaries. Consistent with the DAWN charter, the architecture is primarily targeted at AI agent discovery while remaining general and reusable for other entity types. |
| | Mouth-to-Ear Response Latency for Conversational Voice Systems: Metric Definition and Active Measurement Method |
| |
|
This document defines mouth-to-ear response latency (MRL), a performance metric for conversational voice systems, together with an active method for measuring it at the RTP reference point of the calling endpoint. MRL is the interval between the transmission of the final speech sample of a caller's utterance and the arrival of the first sample of the system's response audio. Two variants are defined, one taken at packet arrival and one taken behind a de-jitter buffer of stated target depth. The method is specified so that both timestamps are drawn from a single clock on a single host, so that the metric requires no synchronisation between the measuring endpoint and the system under test. Requirements for stimulus material, capture content, quality control, calibration and reporting are given. |
| | Network Support for Distributed Computing in Space Networks |
| |
|
Distributed execution can be useful in space networks when one node lacks enough computing, storage, energy, or execution time, or when data is spread across multiple nodes. It can also enable parallel processing or allow different execution stages to run on different space or terrestrial nodes. A task may therefore create multiple communication relationships that appear, coexist, change, and end as execution progresses. Because satellite motion changes connectivity over time, reachability alone is not enough to determine whether an execution endpoint can support the required communication. This document analyzes the network role in such distributed execution in the space network. It considers how network information affects execution decisions, how those decisions create communication requirements and relationships, when communication over a relationship is ready for use, and how relationships change as execution and connectivity evolve. |
| | Guidelines for Considering Operations and Management in IETF Specifications |
| |
| | draft-ietf-opsawg-rfc5706bis-07.txt |
| | Date: |
07/09/2026 |
| | Authors: |
Benoit Claise, Joe Clarke, Adrian Farrel, Samier Barguil, Carlos Pignataro, Ran Chen |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
New Protocols and Protocol Extensions are best designed with due consideration of the functionality needed to operate and manage them. Retrofitting operations and management considerations is suboptimal. The purpose of this document is to provide guidance to authors and reviewers on what operational and management aspects should be addressed when writing documents in the IETF Stream that document a specification for New Protocols or Protocol Extensions or describe their use. This document obsoletes RFC 5706, replacing it completely and updating it with new operational and management techniques and mechanisms. It also updates RFC 2360 to obsolete mandatory MIB creation. Finally, it introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream that define New Protocols or Protocol Extensions or describe their use (including relevant YANG Models), while providing an escape clause if no new considerations are identified. |
| | YANG Data Model for RPKI to Router Protocol |
| |
| | draft-ietf-sidrops-rtr-yang-09.txt |
| | Date: |
07/09/2026 |
| | Authors: |
Yisong Liu, Changwang Lin, Jishnu Roy, Haibo Wang, Jeff Haas, Hongwei Liu, Di Ma |
| | Working Group: |
SIDR Operations (sidrops) |
|
This document defines YANG data models for managing Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC6810 and RFC8210). |
| | SID as source address in SRv6 |
| |
|
SRv6 is being rapidly deployed and is currently primarily used in trusted-domain backbone networks. Both the carrier market and the enterprise market are adopting SRv6 for end-to-end service delivery. However, if a firewall exists along an SRv6 path, not only legitimate SRv6 traffic but also ICMP packets generated on SRv6 transit node will be dropped. This proposal addresses this issue by using SID as source address in SRv6 packets. |
| | The JSON format for vCon - Conversation Data Container |
| |
|
vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. |
| |
|
| |
| | Increase of the Congestion Window when the Sender Is Rate-Limited |
| |
|
This document specifies how transport protocols increase their congestion window when the sender is rate-limited, and updates RFCs 4341, 5681, 9002, 9260, and 9438. Such a limitation can be caused by the sending application not supplying data or by receiver flow control. |
| | Subscription to Notifications in a Distributed Architecture |
| |
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system of a network node. |
| | An Experiment: Network Anomaly Detection Lifecycle |
| |
|
This document defines a structured, iterative lifecycle for network anomaly detection systems to enable "human-in-the-loop" refinements. Key contributions include defining three lifecycle stages, a state machine for anomaly annotations, and YANG data models for standardized labeling and exchange. |
| | Bundle Transfer Protocol - Unidirectional (BTPU) over Ethernet |
| |
|
This document specifies the use of the Bundle Transfer Protocol - Unidirectional (BTPU) as a Convergence Layer directly over Ethernet, and requests allocation of an EtherType and a multicast MAC address for that purpose. This provides an alternative to IP-based convergence layers for environments where Ethernet forwarding is operationally feasible but IP routing is unavailable or operationally undesirable. |
| | REM License Token (RLT) - Genesis Artifact |
| |
|
This document defines the REM License Token, referred to as the RLT, as the genesis artifact of the Reilly EternaMark Protocol (REM) for digital permanence and verifiable provenance. This specification formally defines the token structure, issuance procedures, multi-algorithm cryptographic hash requirements, blockchain anchoring requirements, DOI archival requirements, IPFS pinning requirements, REMID namespace registration, verification methodology, token lifecycle management, ecosystem integration, and security model. The RLT represents an implementation of a Dual-Layer Digital Permanence artifact combining a Bitcoin blockchain timestamp with DOI-based archival to achieve durable, tamper-evident provenance guarantees. Revision -01 expanded the token schema to version 2.0, introduced multi-algorithm hashing via the REM Multi-Algorithm Stack (REM-MAS), defined formal token lifecycle procedures, and documented the RLT's integration with the broader REM Protocol ecosystem including the Protocol Layer Prompt Engineering Specification (PLPES), the Cognitive Trust Stack (CTS), the AI Machine-Readable Ethics Directive (AIMED), and related Informational Internet-Drafts authored by Lawrence John Reilly Jr. This revision (-02) is additive. It retains the whole of the -01 specification and adds token schema version 2.1, a canonical form and record digest for token self-integrity, salted field commitments with selective disclosure, a COSE signature profile, batch issuance with Merkle aggregation, pending and attested anchor states, hash migration bridging records, conformance levels C0 through C4, status records and a revocation registry, an anchor scope rule, the prior art record function under 35 U.S.C. 102(a)(1), and further ecosystem, privacy, and evidentiary considerations. This document is published as an Informational Internet-Draft to serve as open, implementable guidance. |
| | Verifiable Telemetry Ledgers |
| |
|
This document profiles a verifiable-telemetry ledger. Its interoperability boundary begins with exact canonical-record byte strings that an upstream system has already produced. The profile fixes their admission into serial-numbered segments, deterministic commitment-tree calculation, an authoritative segment artifact encoded in Concise Binary Object Representation (CBOR), a producer manifest, three disclosure classes, and binding of the artifact digest through a required external timestamp channel. Segment closure uses a deployment-configured elapsed-time interval and does not depend on calendar dates. The profile enables independent recomputation and audit of disclosed evidence from the admitted bytes onward. Transport framing, decryption, anti-replay processing, payload interpretation, and source-telemetry-to-record mapping are outside it, as are device onboarding, end-to-end security of sensor values, and safety decisions. |
| | VIRP: Verified Infrastructure Response Protocol |
| |
|
The Verified Infrastructure Response Protocol (VIRP) defines a trust framework for operators -- human or autonomous -- acting on live network infrastructure. As operations shift toward agentic and automated systems that can autonomously configure, audit, and remediate production environments, the absence of a verifiable chain of custody for observations and actions introduces fundamental risks: fabricated telemetry, unauthorized state changes, and the inability to distinguish legitimate operations from compromise. VIRP routes every observation and every authorization decision through a designated collection-and- verification boundary that the requesting party does not control. Observations are authenticated at collection time using HMAC-SHA256; in session-bound mode (Section 6.4) authentication uses a per-session key and binds the response to session, device, sequence, and a command-digest field. Validating the command binding additionally requires trusted request context from which the verifier recomputes the command digest. A two-channel architecture separates read-only Observation from write-intent Intent, and trust tiers (GREEN/YELLOW/RED/BLACK) govern action authorization with human-in-the-loop controls for elevated operations. VIRP's observation and chain-integrity guarantees are symmetric and explicitly scoped by key role; approval and federation records use asymmetric Ed25519 signatures. Distinct key roles authenticate observations, chain entries, intents, approvals, and federation records (Section 6.1), though the reference implementation currently reuses one key across the v1-observation and v2-derivation roles; a holder of a symmetric key can both verify and forge within that key's scope, so VIRP does not provide publicly verifiable observation origin and does not defend a record against an adversary holding the relevant key or controlling the collection boundary. Authentication does not certify that a response reflects the managed device's true state, only that the boundary obtained and authenticated those bytes for that recorded request. Asymmetric proof of origin and external anchoring of the chain are distinct, independent items of future work (Section 18). This revision adds External Authorization Binding (Section 11): a deployment profile in which the gate holds only a read-only device identity, the write credential is never at rest on the gate, and per- command authorization is performed by an authorization service that the gate does not control, using the device's own authorization mechanism (for example TACACS+ command authorization [RFC8907] on IOS and IOS-XE). The gate's own record of an action is then reconciled against the device's independent accounting under the same public verification tooling. The individual mechanisms are long-standing; the contribution is their composition, with an autonomous or automated requester as the constrained principal, together with an evidence layer that enables the gate's account of an action to be reconciled against the device's independently sourced account of the same action so a third party can compare them. Static per-command authorization and reconciliation are implemented and exercised on production Cisco hardware; approval-scoped dynamic grants and the chaining of authorization decisions are specified and marked as not yet implemented (Section 19). Since draft-howard-virp-06 the reference chain implementation has gained an OPTIONAL per-entry and per-head Ed25519 signature, computed by the daemon at append time over the same canonical bytes as the mandatory HMAC and verifiable from a public key alone. It is enabled per node and is off by default, so a conforming deployment may still be HMAC-only. The base chain-integrity guarantee remains the symmetric one described here; the signature is an additional authenticator, described in Section 6.5 and Section 6.5.2, not a replacement for it. |
| | Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents |
| |
|
Autonomous AI agents now operate at production scale across financial, commercial, and infrastructure domains — executing transactions, invoking APIs, and taking consequential actions without direct human oversight at each step. Existing authorization mechanisms (OAuth 2.0, API keys, ACLs) were designed for human- initiated requests and do not capture the machine-evaluable semantics required for autonomous agent authorization: what the agent is mandated to do, what constraints bound its actions, and for how long the authorization is valid. This document specifies the Agent Authorization Envelope (AAE), a structured authorization container for autonomous AI agents. AAE defines three mandatory blocks — MANDATE, CONSTRAINTS, and VALIDITY — that together constitute a machine-evaluable, cryptographically verifiable authorization assertion. AAE is designed to be protocol- agnostic, binding to W3C Decentralized Identifiers (DIDs) for agent identity and W3C Verifiable Credentials (VCs) for issuance and signature, and is independent of any specific AI framework, transport protocol, or blockchain. |
| | N-PAMP: Native Post-Quantum Agent Messaging Protocol |
| |
|
The Native Post-Quantum Agent Messaging Protocol (N-PAMP) is a binary, multi-channel, wire-level protocol for authenticated communication between autonomous software agents. N-PAMP operates beneath application-layer agent protocols and provides a single fixed-size frame format, a registry of multiplexed channels, and three escalating security profiles (Standard, High, and Sovereign) built on standard post-quantum and classical cryptography. The protocol uses a hybrid key-encapsulation mechanism combining X25519 with ML-KEM, authenticated encryption with associated data, and a forward-secure key schedule. N-PAMP runs over QUIC as its primary transport and over TCP with TLS 1.3 as a fallback, negotiated via the Application-Layer Protocol Negotiation (ALPN) identifier "n-pamp/3". This document describes the wire format, channel architecture, profile negotiation, and cryptographic suites of N-PAMP, and reserves code-point ranges for extensions defined in companion specifications. |
| | Multi-Party Quorum Authorization for High-Risk Agent Actions (EP-QUORUM) |
| |
|
This document defines a multi-party approval predicate over action- bound human signoffs: valid signatures, admitted roles, distinct approvers and keys, threshold, and an optional ordered trail. The relying party pins the governing policy and approver directory independently. Passing the predicate is approval evidence, not a complete authorization decision, proof of execution, or proof of unused authority. This revision repairs the strong ordered profile. A successor signs a digest of the completed predecessor signoff, including its signature, rather than a precomputable context. The versioned profile establishes causal dependence on a completed prior proof under the cryptographic assumptions; it does not establish trusted wall-clock time or human comprehension. Legacy context-only chains cannot satisfy it. JavaScript, Python, and Go reference verifiers share a corpus in one repository. Agreement is a same-team consistency check, not independent interoperability evidence or a formal proof of the new construction. |
| | Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC) |
| |
|
Consequential agent actions can produce heterogeneous identity, delegation, policy, permit, approval, transparency, capability, and execution artifacts. Each artifact can verify under its own specification while still referring to a different action, filling a different evidentiary role, or failing a relying party's freshness, status, or inter-artifact binding requirement. This document defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and a fail-closed evaluation algorithm that preserves native verification, establishes exact material-action matching, and evaluates a relying-party-pinned evidence requirement. AEC produces SATISFIED or UNSATISFIED and a replayable evaluation record. SATISFIED means only that the presented evidence filled the relying party's named evidence requirement at the stated verification time. It is not a universal authorization decision, a policy language for the protected application, or proof of execution or outcome. The executor makes the separate local AUTHORIZED decision and controls consumption, invocation, and effect handling. Qualification evidence can fill a named evidence role but cannot authorize an action by itself. AEC introduces no new component receipt type and does not replace any native verifier. |
| | The EMILIA Protocol: An Evidence Architecture for Consequential Agent Actions |
| |
|
Consequential agent actions can cross operator and administrative boundaries. The party that later decides whether to rely on an action record may not have participated in the interaction and may not trust either operator. This document describes an evidence architecture for that case. It separates transport and workload identity, delegation and policy, material action identity, authorization evidence, evidence satisfaction, local authorization, durable consumption or reservation, effect invocation, outcome evidence, revocation, and preservation. The architecture composes the Canonical Action Identifier (CAID), Authorization Evidence Chain (AEC), and Action Evidence Boundary (AEB) with optional staged-approval and consequence-control profiles. It does not define a universal token, policy language, execution engine, settlement network, or distributed consensus system. A valid signature, a current credential, a satisfied evidence requirement, and an observed effect remain different facts. |
| | N-AALP: The Native Agentic Application Layer Protocol |
| |
|
The Native Agentic Application Layer Protocol (N-AALP) is an application-layer object protocol for autonomous software agents. Every N-AALP object is a deterministically encoded CBOR structure signed with COSE, carrying under one signature its content identity, its originating signer, a closed effect label that is an authorization input rather than a hint, optional approval and audit bindings, and its causal derivation. Objects are transport- independent: the identical signed object is carried, with identical object-level guarantees, over the N-PAMP substrate, QUIC, WebSocket, or HTTP. N-AALP defines a frozen envelope, a post-quantum signature profile (pure ML-DSA by default, with an optional Ed25519+ML-DSA composite), a self-certifying identity with key rotation, a single- use approval ledger, a hash-chained audit and causal- ordering model with a federated higher tier, native streaming with a single per- stream commitment, foreign-protocol carriage by class, and twenty tiered channel surfaces. This document is an Independent Submission and does not represent IETF consensus. |
| | Cedulon Decision Profile: Reconciling an Agent's Decisions Against Its Effects |
| |
|
The Cedulon core document reconciles an issuer's signed Spend Receipts against an authenticated extract of a payment rail and reports, over a declared population, that no settlement lacks a receipt and no settled receipt is absent from the rail. Money is the special case that document implements. This document defines a second population on the same reconciler. A Decision Record is signed by the party that decided whether an agent may act; an Effect Extract is an authenticated list of the effects that actually occurred on a channel. An allow must be matched by exactly one effect whose content hash the record named; a refusal must be matched by none. The Decision Record claim set, the Effect Extract shape, the points at which the reconciliation departs from the spend rules, the finding codes, and one media type are defined. This revision states that the binding compares content and reference and not the order of two clocks, corrects the boundary to two adjacent documents, and records the first reading of one frozen fixture by a second, independently written reader. The text is provisional; the companion implementation carrying this profile is published. |
| | Data Truck Transport Protocol |
| |
|
Large-scale data transfers may be affected by bandwidth limitations and network instability, which can make network-based data transfer inefficient. DTTP provides an alternative data transfer method for such situations. DTTP uses physical transportation to carry Storage Media containing the Payload. A physical vehicle is used as the Transmission Medium for transporting the Storage Media between the Sender and the Receiver. |
| | Agentic Hypercall Protocol (AHP): Tool Invocation,Blind Settlement,and Portable Reputation over HTTP |
| |
|
This document specifies the Agentic Hypercall Protocol (AHP), a minimal convention for automated software agents to discover, invoke, pay for, and rate tools over plain HTTP. It replaces draft-campbell- agentic-http-00 and extends it in three directions. First, it formalizes the HTTP 402 (Payment Required) status code as a native economic layer with pluggable payment rails (Lightning L402, Cashu ecash, and prepaid balances). Second, it specifies a blind relay -- the Gateway -- through which a consumer and a provider can transact end-to-end encrypted: the relay verifies identity, settles payment, and forwards sealed payloads it cannot read. Third, it specifies signed receipts, settlements, and rating attestations that let reputation be weighted by money actually settled rather than by tokens or votes, and that ride with a provider's key rather than with any single relay. The result is an open market in which agents can buy compute, information, and services from one another without an SDK, a walled garden, or a native token. |
| | Export of BIER Information in IP Flow Information Export (IPFIX) |
| |
|
This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Bit Index Explicit Replication (BIER) such as data contained in BIER header that traffic is being forwarded with. |
| | IGMP and MLD Snooping Yang Module Extension for L2VPN |
| |
|
Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping could be used in both bridge service and L2VPN service. The old ietf-igmp-mld-snooping yang module just describes the bridge service. In this document we extend the existing ietf-igmp-mld- snooping yang module and make it could be used in L2VPN service. |
| | Multi-Topology in PIM |
| |
| | draft-ietf-pim-flex-algo-01.txt |
| | Date: |
06/09/2026 |
| | Authors: |
Zheng Zhang, BenChong Xu, Stig Venaas, Zhaohui Zhang, Hooman Bidgoli |
| | Working Group: |
Protocols for IP Multicast (pim) |
|
PIM usually uses the shortest path computed by routing protocols to build multicast tree. Multi-Topology Routing is a technology to enable service differentiation within an IP network. IGP Flex Algorithm provides a way to compute constraint-based paths over the network. This document defines the PIM message extensions to provide a way to build multicast tree through the specific topology and constraint-based path instead of the shortest path. |
| | QUIC Stream Resets with Partial Delivery |
| |
|
QUIC defines a RESET_STREAM frame to abort sending on a stream. When a sender resets a stream, it also stops retransmitting STREAM frames for this stream in the event of packet loss. On the receiving side, there is no guarantee that any data sent on that stream is delivered. This document defines a new QUIC frame, the RESET_STREAM_AT frame, that allows resetting a stream, while guaranteeing delivery of stream data up to a certain byte offset. |
| |
|
| |
| | Traffic Steering using BGP FlowSpec with SR Policy |
| |
|
BGP Flow Specification (FlowSpec) provides mechanisms to distribute traffic filtering and steering rules across BGP networks. This document specifies BGP FlowSpec procedures to steer matching traffic flows into Segment Routing (SR) Policies. Specifically, it defines protocol mechanisms for combining FlowSpec NLRIs with specific BGP Extended Communities for transport policy steering (Mode 1) in SR- MPLS and SRv6 networks, and optionally with the BGP Prefix-SID Attribute when egress service action execution is required (Mode 2) in SRv6 networks. |
| | Adding an Uncacheable Dirent Metadata Attribute to NFSv4.2 |
| |
|
Network File System version 4.2 (NFSv4.2) clients may cache the file attributes returned by READDIR alongside each directory entry. Such a cache is not invalidated by the directory's change attribute, which reflects changes to the directory and its entries but not writes to the files those entries name, so it can become stale when another client changes one of those files. In some deployments this produces incorrect size and timestamp values often enough to be a problem. This document introduces an uncacheable dirent metadata attribute for NFSv4.2 that allows a server to identify a directory for which an honoring client goes to the server for each enumeration, and does not report an entry's attributes from a value it held before that READDIR. |
| | Protocol Layer Prompt Engineering Specification (PLPES) |
| |
|
This document defines the Protocol Layer Prompt Engineering Specification (PLPES), a structured framework for the formal specification, classification, versioning, provenance tracking, and security hardening of prompts used to interact with AI language models and agentic systems. As AI systems become embedded in critical infrastructure, enterprise workflows, and protocol-driven pipelines, the prompts governing their behavior represent a new class of protocol artifact that currently lacks interoperability standards, integrity mechanisms, or formal classification taxonomy. Ad hoc prompt construction introduces inconsistency, reproducibility failures, prompt injection vulnerabilities, and accountability gaps across deployments. PLPES addresses this gap by defining: (1) a canonical Prompt Descriptor Object (PDO) for machine-readable prompt representation, (2) a five-tier classification taxonomy for prompt roles, (3) a versioning and provenance model compatible with the REM Protocol [I-D.draft-reilly-rem-protocol], (4) integrity verification requirements for agentic prompt chains, and (5) security requirements including injection resistance, adversarial input handling, and chain-of-custody attestation. This specification is intended to be implementable by AI platform operators, enterprise AI integrators, protocol architects, and standards bodies seeking to establish reproducible, auditable, and interoperable foundations for prompt-driven AI systems. This revision adds material to draft-reilly-plpes-00 without removing or altering any text carried forward from it. The additions are summarized in Section 16. |
| | WebProof: A Dual-Layer Web Provenance Protocol for Verifiable Digital Truth on the Internet |
| |
|
This document defines WebProof, a new protocol layer for the World Wide Web that enables any web resource, document, dataset, media artifact, or AI-generated output to be cryptographically proven to exist in a specific form, at a specific time, under a specific author's custody. The web currently provides transport security (TLS), naming (DNS), and resource identification (URI/URL), but no native mechanism for verifiable provenance. Any web resource can be silently modified, backdated, or repudiated. WebProof fills this gap by defining a dual-anchored provenance layer that combines DOI-based archival permanence with blockchain timestamping to produce a WebProof Record (WPR): a machine-readable, independently verifiable proof of a resource's existence, integrity, authorship, and timestamp. WebProof introduces a well-known URI (/.well-known/webproof) for resource-level proof publication, HTTP response header extensions for inline provenance signaling, a canonical WebProof Record schema, a generation and verification procedure, and a DNS TXT record profile for domain-level WebProof registration. WebProof is designed to compose with existing web infrastructure and is intentionally non-disruptive: it does not require modifications to HTTP, TLS, or DNS to function, operating as an opt-in provenance layer that any web publisher can adopt independently. The protocol builds on the Dual-Layer Digital Permanence methodology introduced by Lawrence John Reilly Jr. in the Reilly EternaMark (REM) Protocol [I-D.draft-reilly-rem-protocol]. The term "WebProof" is coined by Lawrence John Reilly Jr. and first formally defined in this document. This revision adds material to draft-reilly-webproof-00 without removing or altering any text carried forward from it. The additions are summarized in Section 18. |
| | Reilly Model Routing Protocol (RMRP): A Framework for Policy-Governed,Auditable AI Model Routing |
| |
|
This document specifies the Reilly Model Routing Protocol (RMRP), a framework for policy-governed, auditable routing of inference requests across heterogeneous artificial intelligence (AI) model environments. RMRP defines the structural metadata, routing policy declaration, execution semantics, audit trail requirements, and cost attribution mechanisms necessary to govern how inference requests are directed to AI models in multi-model deployments. The protocol is AI-provider agnostic and operates independently of any specific model architecture, inference runtime, vendor implementation, or transport layer. RMRP addresses the absence of a standardized protocol-layer specification governing how routing decisions are declared, transmitted, logged, and enforced across AI model deployments at organizational scale. This revision is additive with respect to draft-reilly-rmrp-00. Every structure, field, value, and requirement defined in -00 is carried forward unchanged. This revision adds record canonicalization, digest, and signature mechanisms; salted field commitments and selective disclosure; complexity score attestation; chain-level and window-level budget enforcement; audit inclusion proofs, checkpoints, and completeness attestation; policy and key revocation; a threat model; conformance levels; and IANA registries for the extensible value sets that -00 defined without one. |
| | The Human Escalation Mechanism (HEM) for Agentic AI Systems |
| |
|
An AI agent that has been authorized to act autonomously has no inherent mechanism to stop itself. If its mission requires a decision that exceeds its authorization, if policy mandates human judgment before proceeding, or if the agent itself reaches the boundary of its reliable competence, what happens? Without a protocol specifying the answer, one of three failure modes occurs: the agent proceeds beyond its authorization and executes actions that no human approved; it stalls silently with no notification to any principal; or it continues running under a mission that has already entered a terminal state, producing actions with no legitimate purpose. In all three cases, the humans responsible for the system find out too late. This document defines the Human Escalation Mechanism (HEM): a normative protocol specifying what a Governance Execution Controller (GEC) does when an AI agent session requires human judgment before execution may continue. HEM replaces the three failure modes above with a single governed path: the GEC places the session into a formally defined HEM_PENDING state, routes a structured escalation request to one or more designated human principals along an ordered designation chain, enforces a prohibition on all state transitions until a human decision is received, and processes six defined human decision types. HEM also defines the Policy Rationale Declaration (PRD), which links Cedar policies that route to HEM with machine-readable rationale, and the Decision Rationale Record (DRR), which captures the human principal's reasoning for audit and learning purposes. Version -05 adds ten new HEM interaction classes (HEM-PRE-1, HEM-PRE-2, HEM-DS-1, HEM-DS-2, HEM-LIM-1, HEM-DIV-1, HEM-HIGH-1, HEM-FAT-1, HEM-EMO-1, and HEM-CONSENT) with full normative specifications, trigger conditions, GAR ALE registrations (ALE-030 through ALE-041), and five new Security Considerations addressing the HEM channel attack surface. INV-HEM-01 (The Surfacing Obligation) is added as a KernelSpec invariant, along with normative Human Readiness Score (HRS) and Tier 0-A Integration sections. Version -06 corrects an internal contradiction over whether HRS data persists across sessions, reconstructs several sections whose base content had gone missing from the -05 text, and extends DoS rate-limiting guidance to the -05 interaction-class triggers. Version -07 is an editorial revision with no normative content changes: bracket-delimited array type notation ([string], [object]) and a state-diagram terminal-state label were reworded to resolve idnits parser warnings that misread them as broken citations. HEM is enforced by the GEC, not by the agent and not by the application layer. An agent cannot opt out; an application cannot suppress it. This non-bypassability is the source of HEM's regulatory utility and provides the technical specification for human oversight required by EU AI Act Article 14. |
| | The Constitutional AI Protocol (CAP) for Agentic AI Systems |
| |
|
An AI agent's authorization system determines what it is permitted to do. A human principal's escalation decision determines what they authorize. Neither of these is sufficient on its own: a Cedar policy can permit market manipulation; a human principal can authorize fraud. Authorization systems answer the question "who decided?" The Constitutional AI Protocol answers a different question: "was that decision lawful?" CAP defines a Constitutional Layer that evaluates every AI action request and every human authorization decision against a three-tier prohibition model -- before Cedar evaluates the action and before the system executes the human's decision. Tier 0 prohibitions are derived from near-universal treaty consensus and are unconditional: no agent, operator, or human principal can authorize them. Tier 1 prohibitions are jurisdiction-specific and operator-declared. Tier 2 prohibitions are voluntary operator ethical standards. This document also specifies the Prohibition Clearance Mechanism (PCM): the process by which specific Tier 0 and Tier 1 prohibition classes may be cleared for specific deployment contexts -- either at implementation time by the operator or by formal regulatory authority -- while preserving an absolute prohibition floor for CSAM and genocide facilitation under any circumstances. The Sovereign Object OS (SOOS) is the reference implementation of the Governance Execution Controller (GEC) pattern on which CAP is built. CAP also defines the GEC Policy Transparency Disclosure (PTD): a signed, queryable, tier-structured document through which any external party may determine which laws and regulations a GEC is actively enforcing, at what authority tier, and under whose governance. |
| | The Federated Agent Intelligence Protocol (FAIP) for Agentic AI Systems |
| |
|
Every governed AI agent session ends with a record of what it tried, what was permitted, what was denied, and whether it succeeded. Across a single operator's deployment, these records feed behavioral trust scores. Across all operators, they are discarded. No protocol exists for pooling this behavioral intelligence without exposing the business logic, personal data, or operational details that make individual records sensitive. This document defines the Federated Agent Intelligence Protocol (FAIP): the Tier 3 analytics layer of the SOOS protocol family, specifying how aggregate behavioral intelligence is derived from governed agent Event Streams across participating operators, made available to agents and human principals, and protected through privacy-preserving aggregation, data residency controls, and k-anonymity enforcement. FAIP does not share individual session records. It does not expose any operator's proprietary data. It produces aggregate behavioral signal -- empirical, tamper-evident, distributed -- that no single participant can generate from their own data alone. FAIP is the first protocol specification for federated behavioral intelligence derived exclusively from cryptographically governed agent activity records. This document establishes the FAIP architecture, its relationship to the three-tier analytics model IDP defines, its privacy and data residency framework, and the scope of subsequent FAIP specifications. Full protocol specification of FAIP query interfaces, federation topology, and aggregation algorithms is deferred to successor documents. |
| | Constitutional AI Protocol -- Regulation Record Specification (CAP-RRS) |
| |
|
Compliance with applicable law should be a package import, not a Cedar authoring problem. The Constitutional AI Protocol (CAP) defines the enforcement architecture for governed AI agent systems: a three-tier Cedar policy evaluation model that distinguishes absolute prohibitions, jurisdictional legal constraints, operator policies, and resource limits. CAP specifies what the Governance Execution Controller (GEC) does when a Cedar policy fires. It does not specify how Cedar policies are authored, certified, distributed, or maintained as law changes. This document defines the Regulation Record: the structured representation of a compliance obligation at any CAP tier. A Regulation Record is the human-readable, machine-compilable intermediate form between legal text and Cedar policy. This document specifies the Regulation Record schema, the Cedar Compilation Profile that governs how Regulation Records are translated into Cedar policies, the conflict declaration model, the certification model governing which publishers may certify records at each tier, and the versioning and update protocol for the Constitutional Mandate Registry. Version -02 adds the Law Reference Interface (LRI) generic model, the Statute-Primacy Rule, and the Operational Requirements for catalog amendment and interpretation detection. These three additions complete the regulation lifecycle: from law encoding through law reference and provenance, through the consequences of law amendment, through the operational cadence governing detection and response. Version -03 corrects the Statute-Primacy Rule's event schemas to record resolution as a new, causally-linked GAR event rather than an in-place mutation of the original conflict event. The core developer experience this document enables: a developer imports certified Regulation Record packages from the Constitutional Mandate Registry, declares their own Tier 2 operator policies and Tier 3 resource policies, calls compile(), and receives a Cedar policy set ready for GEC loading. No Cedar is authored by hand for compliance purposes. Compliance is a package management operation. |
| | DNS and mDNS Discovery for MOQT |
| |
|
This document defines how MOQT clients discover server endpoints using DNS and Multicast DNS (mDNS). It specifies SVCB and HTTPS DNS record mappings for the moqt URI scheme, SRV records as a fallback mechanism, and DNS-SD over mDNS for local network discovery. |
| | tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP |
| |
|
Frontier runtimes already standardized the dangerous moment. A model emits a tool_use block, a tool_calls array, or an MCP tools/call payload. The host then invokes whatever name and arguments the model printed. Alignment, allowlists, and OAuth sit around that moment. They do not sit on it. The consequence of this gap is no longer confined to email or payment demos. In defense, energy, grid control, industrial process control, and other critical-infrastructure deployments, the same tool_use block already reaches actuation-class systems -- logistics and targeting-adjacent decision support, SCADA and PLC interfaces, medical devices, autonomous platforms. In these environments, detection after the fact is not mitigation; it is an incident report written after the effect has already occurred. An agent that can act at machine speed but cannot be halted at machine speed is a system running without brakes: the first uncontrolled invocation is not a warning sign, it is the accident. Command authority, human oversight, and legal review all operate on human time. An unbound tool_use block operates on machine time. When those two clocks diverge, the gap belongs to whichever side reaches the effect first -- and today, nothing structurally guarantees that side is authorization. This document does not invent another assistant API. It binds the Agent Candidate Act profile [I-D.das-agentic] onto the three interface families those runtimes and their customers already ship: tool_use / computer_use style interfaces, function-calling and structured tool-response interfaces, and Model Context Protocol tools/call. The model may emit the block. The block remains non- effective. A local enforcer builds the act, binds the argument digest, and refuses invoke() until scoped authority is verified and consumed at the dispatch sink. For consequence classes above a defined threshold -- FINANCIAL, PHYSICAL, NETWORK_CONTROL, and any act reaching defense or critical- infrastructure actuation -- this binding treats fail-closed as the only conforming behavior: absent successfully verified, current, act- bound authority, the candidate act stays non-effective regardless of model confidence, prior session trust, or upstream alignment signal. Each enforcement decision, allow or deny, commits a Ledger-Anchored Validation Receipt (LAVR) -- a signed, hash-chained enforcement artifact bound to the specific candidate act and its argument digest at the moment of decision. An LAVR is not a log entry assembled afterward for audit; it is the proof that the finality boundary actually gated this act before any effect could occur, and its absence is itself a fail-closed condition. The implementation target is a middleware function that a host loop can call without changing the model vendor. tool_use is not invoke(). |
| | The Testimony Record: An Interchange Format for What an Automated System Believed and Did |
| |
|
This document specifies the Testimony Record, an append-only interchange format for the account an automated system gives of its own operation: what it believed, what evidence each belief rested on, which of its beliefs contradicted one another, what actions it attempted, and who authorised the consequential ones. The format is defined so that a party who was not present, and who has no access to the emitting system, can read a record and check specific properties of it. Four conformance levels are defined, each stating a property that can be verified mechanically rather than asserted. This is not a logging format. Logs record what a program did. A Testimony Record states what a system claimed to know, what disagreed with it, and what it was permitted to do about it. |
| | Post-Quantum Evidence Records with Algorithm Agility (Wathiqa Profile) |
| |
|
This document describes an evidence-record format for the long-term, verifiable preservation of digitally-signed data across the migration to post-quantum cryptography. It builds on the Evidence Record Syntax (ERS) of RFC 4998 and adds an explicit *algorithm-agility* extension: a record is a chain of signed attestations in which each link re-witnesses the data under a fresh signature primitive and commits to the prior link, so that the authenticity of the data survives the cryptographic break of any single primitive. It specifies the canonical hashing that makes a record reproducibly verifiable across independent implementations, the authenticated temporal binding that places each link in time (an append-only transparency log à la RFC 6962, whose signed inclusion receipt is _not-after_ evidence), and the verification procedure. A per-link beacon anchor records _not-before_ evidence: from wire version 3 it is authenticated against the beacon's hash chain, with the beacon's classical pulse signature as defence in depth; the Security Considerations say which assumption each check rests on. |
| | Technical Enforcement of the European GDPR and Global Data-Protection Constraints Without Paper Policy |
| |
|
The European Union's General Data Protection Regulation (GDPR), China's Personal Information Protection Law (PIPL), and India's Digital Personal Data Protection Act (DPDP Act) each require, in their own terms, that personal data be used only for a specified purpose, be limited to what is necessary, be kept secure, and remain subject to the data subject's or regulator's ability to hold a controller accountable. Every one of these regimes is currently enforced primarily through paper: privacy notices, consent records, data-processing agreements, internal policies, access-control configurations, and audits performed after data has already moved. Paper policy fails in the age of artificial intelligence because it assumes a human-speed decision that no longer exists. An agentic AI system can authenticate, read from several lawfully accessible data sources, combine those sources into a new relationship that was never separately assessed, choose a purpose, select a recipient or an international destination, and transmit the result -- all within a single inference pass, before any privacy officer, consent record, contract clause, or after-the-fact audit log can intervene. A GDPR purpose-limitation clause, a PIPL processing-purpose restriction, or a DPDP consent-manager rule can be entirely correct on paper and still fail in practice, because none of them is a property of the computation itself; each is a property of a document that the computation is merely expected to obey. By the time an audit trail shows that Article 5(1)(b) of the GDPR, the purpose-limitation principle of the PIPL, or the purpose-limitation requirement of the DPDP Act was violated, the disclosure, the cross-border transfer, or the unauthorized combination of data has already occurred and cannot be undone. This document introduces an execution-finality architecture that converts an already-determined privacy rule from a document into a mandatory, machine-verifiable precondition of the computer operation itself. A proposed privacy-sensitive operation is represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of disclosing, transmitting, or combining protected data -- until a Protected Enforcement Domain conjunctively validates the requesting Virtual Identity (VI), the applicable purpose and jurisdictional constraints represented as a Compliance Jurisdiction Token or Structure (CJT/CJS), the minimum required data attributes, the recipient, and the destination, and a Finality Sink positioned at the boundary of first usable external effect independently reverifies that state immediately before release. Non-Joinable Vaults further ensure that holding a valid credential or an authenticated AI session does not, by itself, grant authority to recombine separated categories of personal data. A worked example applies the architecture to a small-or-medium enterprise (SME) AI customer-service deployment, including a prompt- injection scenario in which a manipulated AI agent is technically prevented from exfiltrating payment and identity data regardless of what the model was tricked into generating. A feasibility and latency analysis shows the mechanism can be deployed as ordinary gateway middleware without replacing existing identity or SaaS infrastructure. The document then provides a deliberately bounded mapping onto specific GDPR provisions (Articles 5(1)(b), 5(1)(c), 5(1)(f), 6, 25, 32, and Chapter V), stating plainly which provisions this architecture can make technically load-bearing and which -- such as the legal validity of a basis for processing, or the lawfulness of an international transfer mechanism -- must remain a legal and regulatory determination that no software can make on its own. This document does not advocate discarding paper-based privacy policy, consent management, contractual controls, or audit for general-purpose applications, where the cost, rigidity, and operational overhead of execution-level enforcement would be disproportionate to the risk being managed. The architecture is instead proposed for high-criticality systems: national-security- relevant infrastructure, critical infrastructure, systems processing special-category or otherwise highly sensitive personal data, and other environments in which unauthorized disclosure, cross-border transfer, or unauthorized data combination would be catastrophic, irreversible, or strategically damaging rather than merely a regulatory infraction. For ordinary commercial applications, existing paper-policy, consent, and audit mechanisms, combined with conventional access control, may remain proportionate and sufficient on their own. The central proposition offered to regulators, standards bodies, and implementers is this: a privacy rule that exists only on paper is a rule the machine can violate before anyone notices; a privacy rule bound to the execution boundary is a rule the machine cannot complete without satisfying. |
| | Reporting DKIM2 Verification Results in Authentication-Results |
| |
|
DomainKeys Identified Mail Signatures v2 (DKIM2) produces a verification result for an email message. This document defines how that result is reported in the Authentication-Results header field, registering the "dkim2" authentication method, the result values it can take, and two properties which identify the signing domain and the point in the chain at which verification failed. Diagnostic detail about each hop is carried in a human-readable comment. |
| | The 'scsp' Uniform Resource Identifier (URI) Scheme and Space Command & Telemetry Security Protocol (SCSP) |
| |
|
This document specifies the 'scsp' Uniform Resource Identifier (URI) scheme and its associated Space Command & Telemetry Security Protocol (SCSP). The scheme defines a zero-trust, transport-agnostic space cybersecurity protocol standardizing telecommand authentication, telemetry integrity, inter-satellite laser mesh encryption, and optional profile-driven space-grade hardware attestation (TPM 2.0 / TEE) across Low-Earth Orbit (LEO) constellations, Geostationary (GEO) satellites, and Deep-Space missions. It defines exact binary field- width tables in Network Byte Order (Big-Endian) with O(1) KeyID indexing, reserved KeyID 0x0000 Master Emergency slots, 11-bit CCSDS APID zero-padding constraints, normative DMA buffer sizing (B_min >= 26 + N_max + SigLen_max), AEAD cipher agility, deterministic 96-bit IV construction (Sequence_Epoch || KeyID || 0x0000), continuous International Atomic Time (TAI) microsecond epoch baselines, zero- payload (N=0) boundary rules, ISL TTL hop limiting, a mission- provisioned Endpoint Resolution Table mapping URIs to CCSDS Spacecraft ID (SCID), Virtual Channel ID (VCID), and Application Process ID (APID) parameters, ground-side URI :port stripping rules, mandatory signature byte-scoping over header and payload, normative X25519 HKDF info strings for AEAD key derivation ("SCSP-Payload-AEAD- v1") and non-interactive TC segment HMAC trailers ("SCSP-Segment- HMAC-v1") with 32-zero-byte RFC 5869 salts, 3,378-byte hybrid PQC signature sub-framing (Ed25519 + ML-DSA-65 per FIPS 204), KeyID- isolated configurable-width (64/256/1024-bit) NVRAM sliding-window anti-replay protection, monotonic NVRAM counter-protected Emergency Time-Resynchronization, monotonic counter-protected in-pass Key Revocation Lists (KRL), dual-mode SDLS SPI/ESH Extended Security Headers (SA Table Index vs. Direct Bitfield), I-JSON compliant payload documents (RFC 7493), onboard Command Authorization Policy Matrices, mandatory signed Telemetry Response schemas for SUCCESS and ERROR states (0x01..0x0C), SCSP URI canonicalization, and provisional IANA registration under RFC 7595. |
| |
|
| |
| | CATS Metrics Definition |
| |
|
Computing-Aware Traffic Steering (CATS) is a traffic engineering approach that optimizes the steering of traffic to a service instance by considering the dynamic state of computing and network resources. To enable such decisions, CATS components exchange metrics that describe resource conditions affecting service instance selection. This document focuses on compute and communication metrics for CATS and defines a hierarchical abstraction of these metrics to improve interoperability, scalability, and operational simplicity. It does not aim to standardize raw infrastructure (Level 0) metrics; instead, it specifies higher-level representations that can be derived from raw measurements using aggregation and normalization functions. |
| | SIMAP: Concept,Requirements,and Use Cases |
| |
|
This document defines the concept of Service & Infrastructure Maps (SIMAP) and identifies a set of SIMAP requirements and use cases. The SIMAP was previously known as Digital Map. SIMAP evolves the earlier 'Digital Map' concept by making explicit the ties between service and infrastructure layers, clarifying expected outcomes for operations and automation, and addressing ambiguity associated with the term 'digital.' The document intends to be used as a reference for the assessment of the various topology modules to meet SIMAP requirements. |
| | RDAP Extension for DNS DELEG |
| |
|
This document describes an extension of the Registration Data Access Protocol (RDAP) that includes DNS DELEG values in responses to RDAP domain object queries. |
| | SEARCH -- a New Slow Start Algorithm for TCP and QUIC |
| |
| | draft-chung-ccwg-search-10.txt |
| | Date: |
04/09/2026 |
| | Authors: |
Jae Chung, Maryam Kachooei, Feng Li, Mark Claypool |
| | Working Group: |
Individual Submissions (none) |
|
TCP slow start is designed to ramp up to the network congestion point quickly, doubling the congestion window each round-trip time until the congestion point is reached, whereupon TCP exits the slow start phase. Unfortunately, the default Linux TCP slow start implementation -- TCP Cubic with HyStart [HYSTART] -- can cause premature exit from slow start, especially over wireless links, degrading link utilization. However, without HyStart, TCP exits slow start too late, causing unnecessary packet loss. To improve TCP slow start performance, this document proposes using the Slow start Exit At Right CHokepoint (SEARCH) algorithm [KCL24] where the TCP sender determines the congestion point based on acknowledged deliveries -- specifically, the sender computes the delivered bytes compared to the sent bytes, smoothed to account for link latency variation and normalized to accommodate link capacities, and initiates exits slow start if the delivered bytes are lower than expected. We implemented SEARCH in Linux, FreeBSD, and QUIC and evaluated it over WiFi, 4G/ LTE, and low earth orbit (LEO) and geosynchronous (GEO) satellite links. Analysis of the results show that SEARCH reliably exits from slow start after the congestion point is reached but before inducing packet loss. |
| | Remote Procedure Call Identity Squashing via x.509 Certificate Fields |
| |
|
This document extends RPC-with-TLS so that a client's x.509 certificate may carry instructions to the RPC server to execute all RPC transactions from that client as a single user identity. |
| | Reilly Government Integrity Protocol (RGIP): Multi-Layer,Quantum-Resilient Framework for Permanent and Tamper-Evident Public Records |
| |
|
The Reilly Government Integrity Protocol (RGIP) defines a standards-aligned method for producing permanent, independently verifiable public records by combining multi-algorithm content hashing, public timestamp anchoring, archival deposit under a persistent identifier, decentralized storage, and web archiving into a single pipeline. This revision corrects defects in draft-reilly-government-integrity-01 that would have prevented independent verification or overstated the guarantees the protocol provides. It replaces the -01 SHA3-512-only Cross-Chain Hash, which made a single algorithm the sole binding of three otherwise independent chains, with an entangled link-and-braid construction in which each chain consumes the prior state of all three. It defines a canonical, domain-separated, length-delimited encoding for every hashed input, removing the concatenation ambiguity present in -01. It separates the signed Evidence Receipt Core from the mutable anchor envelope, resolving the -01 condition in which confirming an anchor invalidated the signature over the record it described. It adds Chain Checkpoint anchoring, without which the -01 claim that record sequence is provable did not hold, since -01 anchored only artifact digests and never the chain itself. It replaces raw digests of low-entropy government records with salted field commitments, adds explicit pending and attested anchor states, adds a Revocation Registry and Hash Migration Bridging Records, replaces the quantum_resilient boolean with a declared algorithm suite, prohibits automated repair of chain integrity violations, and narrows the -01 post-quantum claims to what the constructions support. It also documents the function of RGIP records and of this specification as prior art records under 35 U.S.C. 102(a)(1), consistent with the treatment in version -02 of the REM Protocol specification. |
| | VCAP: Verified Commerce for Agent Protocols |
| |
|
This document specifies the *Verified Commerce for Agent Protocols (VCAP)*, an open standard for settling financial transactions between autonomous AI agents using cryptographically verifiable proof of work delivery. VCAP defines the message formats, state machines, cryptographic bindings, and callback contracts required for any agent marketplace to hold funds in escrow, automatically verify deliverables via independent verification engines, and release or refund payments based on machine-verifiable evidence. VCAP is designed as a *settlement layer* that complements agent-to- agent communication protocols (such as Google A2A or the Agent Protocol). Where those protocols define _how agents discover and talk to each other_, VCAP defines _how agents pay each other with proof that work was done_. |
| | ATEP: Agent Trust and Execution Passport |
| |
|
This document specifies the *Agent Trust & Execution Passport (ATEP)*, an open standard for representing an AI agent's verifiable track record of work across marketplaces and platforms. ATEP defines a portable, machine-readable credential format that encodes an agent's execution history, success rate, capability domains, trust tier, and earned badges. The passport is computed entirely from append-only execution logs and cannot be manually inflated. ATEP is the *trust layer* for agent-to-agent commerce. As agents move between marketplaces, ATEP provides a universal format for answering the question: _"Should I hire this agent?"_ |
| | VCAP-AP2 Binding: Verified Delivery Settlement for the Agent Payments Protocol |
| |
|
This document defines a binding between Verified Commerce for Agent Protocols (VCAP) and the Agent Payments Protocol (AP2). AP2 supplies agent-commerce authorization evidence through IntentMandate, CartMandate, and PaymentMandate artifacts. VCAP supplies delivery verification, settlement evidence, escrow directives, timeout handling, and dispute handoff. This revision deliberately does not model AP2 as an escrow or settlement state machine. Current AP2 positions itself as an authorization and security layer used within a surrounding commerce protocol, including Universal Commerce Protocol (UCP). Accordingly, this binding references AP2 mandates by cryptographic digest or opaque identifier and leaves payment capture, refund, and settlement transitions to the commerce protocol and payment rail. |
| | AIVS: Agentic Integrity Verification Standard |
| |
|
The Agentic Integrity Verification Standard (AIVS) defines a portable, self-verifiable archive format for cryptographic proof of AI agent sessions. An AIVS bundle is a gzip-compressed tar archive containing a SHA-256 hash-chained audit log, an Ed25519 digital signature over the chain, a machine-readable manifest, and an embedded verification script that requires only Python 3 standard library to execute. AIVS also defines *AIVS-Micro*: a minimal 6-field attestation (~200 bytes) for continuous monitoring, embedded widgets, and API responses where a full session bundle is not required. AIVS enables any party to independently verify that: |
| | SwarmScore V1: Volume-Scaled Agent Reputation Protocol |
| |
|
SwarmScore V1 is a transparent, community-governed open standard for agent reputation scoring in open marketplaces. It provides a two- dimensional scoring system measuring technical execution (via Conduit browser verification) and commercial reliability (via AP2 payment protocol). Volume-scaled metrics reward consistent high-volume performance. Cryptographically signed certificates enable decentralized trust. This document specifies the complete V1 standard including formula, trust tiers, escrow integration, wire format, governance model, legal framework, implementation guidance, V2 roadmap, competitive analysis, and known limitations, with a governance roadmap for transitioning canary prompt curation to a multi-stakeholder community registry. |
| | SwarmScore V2 Canary: Safety-Aware Agent Reputation Protocol |
| |
|
SwarmScore V2 Canary extends the SwarmScore V1 two-pillar reputation protocol with a third dimension: Safety, measured via controlled canary prompt testing. This document specifies five formally- analyzed design decisions for the canary testing subsystem: mandatory testing thresholds, hybrid response classification (pattern matching plus opaque LLM ensemble), dedicated test session placement, prompt library composition and rotation, and session isolation to reduce buyer-harm risk. V2 Canary is backwards-compatible with V1: all V1 scores remain unchanged. The five-pillar formula covers Technical Execution (300 pts), Commercial Reliability (300 pts), Operational Depth (150 pts), Safety (100 pts), and Identity Verification (150 pts). |
| | The Intent Token: A Cryptographic Authorization Primitive for Autonomous Agents |
| |
|
This document specifies the Intent Token, a cryptographic authorization primitive for autonomous AI agent systems. An Intent Token binds an autonomous agent action to a cryptographically signed, human-declared authorization envelope before that action is executed. The Intent Token addresses a fundamental gap in existing authorization frameworks: while OAuth 2.0, OIDC, and related standards govern identity and access at the session level, no standardized primitive exists for governing what an autonomous agent is authorized to DO at the moment of action. The Intent Token provides this primitive. It is model-agnostic, transport-agnostic, and composable with existing authorization infrastructure. Revision -01 extended the specification with Fractal Intent Token (FIT) binding for multi-scale agent systems, Authorization Fluidity for context-sensitive mode switching, and the Fractal Crypto-Temporal Graph (FCTG) as the normative audit trail data structure for continuous adaptive authorization. This revision (-02) corrects the stated patent priority date and dependent date references carried over from -01, adds a fourth documented instance of independent convergence (Broadcom's AgentMinder), and revises the characterization of AI-assisted development work in Section 12 for accuracy. |
| | CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for SQIsign |
| |
|
*NOTE: This document describes a signature scheme based on the SQIsign algorithm currently under evaluation in the 3rd round NIST Post-Quantum Cryptography standardization process. Be aware that the underlying primitive may change as a result of that process.* This document specifies the algorithm encodings and representations for the SQIsign digital signature scheme within the CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) frameworks. SQIsign is an isogeny-based post-quantum signature scheme that provides an unusually compact signature and public key size among candidates of the NIST Post-Quantum Cryptography (PQC) standardization and on-ramp-to-standardization processes. The standardization of SQIsign will be helpful to address current infrastructure bottlenecks, specifically the FIDO2 CTAP2 specification used by many in-service devices. This document clarifies that SQIsign does not expose the auxiliary torsion-point information exploited in the SIDH/SIKE attacks. Consequently, the specific attack techniques of Castryck–Decru do not directly apply. However, the scheme remains subject to ongoing cryptanalysis of isogeny-based constructions. By establishing stable COSE and JOSE identifiers, this document ensures the interoperability required for the seamless integration of post-quantum security into high-density, bandwidth-constrained, and legacy-compatible hardware environments. |
| | ADRP: Agent Dispute Resolution Protocol |
| |
|
This document defines the Agent Dispute Resolution Protocol (ADRP), a wire protocol and state machine for resolving disputes that arise from cryptographically-attested agent-to-agent (A2A) transactions. ADRP is the companion specification to ATXN (draft-stone-atxn-01), which defines what an A2A transaction is. ADRP defines what happens when a party contests one. ADRP severs an equivalence that every prior agentic commerce design has implicitly assumed: that a valid cryptographic proof bundle equals contractual satisfaction. It does not. Conduit-style cryptographic verifiers prove that an agent took specified actions; they do not prove that those actions satisfied the principal's Intent Mandate. ADRP bifurcates disputes into a *cryptographic class* (resolvable by code from the proof bundle and mandate chain) and a *semantic class* (resolvable only against pre-committed machine- readable acceptance criteria, with arbitration escalation when those criteria are absent or under-specified). ADRP introduces the *Arbitration Mandate* as an ADRP extension that can be cryptographically linked to AP2 Intent/Cart/Payment Mandates or to an ATXN Standing Token. It is not an AP2 core mandate. The Arbitration Mandate records the principal's pre-committed dispute policy and is designed to support a written arbitration agreement where applicable; enforceability remains jurisdiction- and fact- specific. ADRP defines a *counter-attestation override pattern* in which a signed RulingBundle supersedes a Conduit ProofBundle by a signing- time precedence rule rather than by mutation. Both the original attestation and the override are preserved forever in the hash chain; "override" is a verification-time computation, not a write. Companion specifications: * *ATXN* (draft-stone-atxn-01): defines the A2A transaction primitive that ADRP resolves disputes over * *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate for proof bundles * *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails consumed by ADRP EscrowDirectives * *ATEP* (draft-stone-atep-01): trust passports referenced by Standing Tokens in ADRP |
| | ATXN: Agent-to-Agent Transaction Definition Protocol |
| |
|
This document defines a canonical, defensible, machine-checkable primitive for an Agent-to-Agent (A2A) transaction. It establishes the bundle of cryptographically signed elements that constitute a recorded value exchange between two software agents acting as instruments of identified principals, the conformance tiers that determine which elements are required, the rail-specific Profiles that map the bundle to existing payment infrastructure, and the two- tier validity model that distinguishes externally-adjudicable transactions from operationally-valid uncontested exchanges. ATXN is the foundational legal and technical primitive for escrow, dispute resolution, audit, and liability allocation in agentic commerce. It is designed to produce evidence that can be mapped to existing contract and agency frameworks without requiring agent legal personhood. Whether a Bundle has legal effect is jurisdiction- and fact-specific; this document does not provide a legal conclusion. It maps directly to AP2, Stripe ACP, Visa TAP, Mastercard Agent Pay, and x402 as Profiles of a single canonical bundle. Companion specifications: * *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate that ATXN bundles inherit from * *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails that consume ATXN bundles * *ATEP* (draft-stone-atep-01): trust passports that bind agents to capacity-attested principals * *ADRP* (draft-stone-adrp-01): dispute resolution protocol invoked when an ATXN bundle enters the disputed state |
| | Agent-to-Agent Trust,Identity,and Verifiable Provenance |
| |
|
This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross- organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to the problem of agent provenance. This document does not address agent- to-resource access control, human-in-the-loop orchestration, or agent behavior, as those concerns belong to the resource enforcement layer and the orchestration layer respectively. |
| | The Vaara Receipt: A Recomputable Receipt Format for Decisions About Autonomous Actions |
| |
|
This document specifies vaara.receipt/v1, a signed and independently recomputable record that binds a decision about an autonomous action to the evidence the decision was made on, and optionally to one or more external timestamp anchors. The format is canonicalized with the JSON Canonicalization Scheme (JCS) so that any third party can recompute its digests and verify its signature without access to the issuer. A decision and the execution receipt that answers it form one recomputable pair through the envelope's back link. The receipt's trust is root-agnostic: the same record is verifiable with or without a hardware trusted execution environment and is re- expressible as an IETF RATS Entity Attestation Result. Downstream specifications (a payment rail, a compliance regime, a framework integration) define profiles that pin to a version of this document and add only their own evidence schema; they do not redefine the envelope. The format described here is deployed, and its receipts are independently recomputable from public conformance vectors that ship with standalone checkers importing no issuer code. The minimal profile is a governance decision over a single autonomous action, bound to the action's own intent with no external rail; it is the floor of the format, and a reference library offers a matching adoption floor at the API layer as a one-line decorator over the governed function. |
| | The Agent Enrollment Protocol |
| |
|
The Agent Enrollment Protocol (AEP) defines an HTTP-based mechanism for autonomous agents to discover service enrollment requirements, enroll an agent identity, obtain optional session credentials, revoke those credentials, and query enrollment status. AEP uses Decentralized Identifiers, client assertion JWTs, and HTTP Problem Details to provide a narrow machine-first enrollment and authentication substrate for agent-to-service interactions. |
| | API-Key Session Credential Grant Type for the Agent Enrollment Protocol |
| |
|
This document defines the API-key session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an opaque API key through the AEP Grant command for deployments that already operate header-based API-key authentication. |
| | Basic Session Credential Grant Type for the Agent Enrollment Protocol |
| |
|
This document defines the Basic session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an HTTP Basic credential through the AEP Grant command for deployments that already integrate with Basic authentication middleware. |
| | OAuth Bearer Session Credential Grant Type for the Agent Enrollment Protocol |
| |
|
This document defines the OAuth Bearer session-credential grant type for the Agent Enrollment Protocol (AEP). The grant type lets an AEP Service issue an OAuth-style Bearer access token through the AEP Grant command while preserving baseline AEP client assertion authentication as the root of trust. |
| | AEP Platform Hosted Identity |
| |
|
This document defines interoperable hosted identity behavior for Agent Enrollment Protocol (AEP) Platforms. It lets a Platform provision Service-scoped Agent did:web identities, publish DID documents, custody signing keys, and produce AEP client assertion JWTs through delegated signing operations. |
| | The Offering Discovery Protocol |
| |
|
The Offering Discovery Protocol (ODP) enables an automated Agent to inspect a Service, discover its Collections and Offerings, interpret Service-defined structured attributes, and identify links to subsequent operations. ODP supports catalogs ranging from a few Offerings to large marketplaces without imposing a universal product taxonomy. This document defines the protocol's scope, terminology, roles, discovery architecture, extensibility model, composition boundaries, and conformance model. |
| | Scoping and Comparability Requirements for Exported Network Telemetry Identifiers |
| |
|
This document describes a recurring interoperability problem in exported network telemetry: many values are encoded without an explicit definition of the scope in which they are unique, meaningful, and comparable. In practice, the wire representation of a value may be standardized while the semantic context of that value remains implicit. As a result, a receiver may infer that two numerically identical values are equivalent when they were produced in different semantic domains and therefore refer to different objects, states, or observations. This ambiguity is operationally significant. It can lead to incorrect aggregation, incorrect cross-instance comparison, and erroneous conclusions about routing state, forwarding behavior, or network health. The risk is particularly visible in telemetry protocols that export statistics or identifiers in contexts such as VRFs, topology instances, address families, route distinguishers, policy domains, or other instance-specific scopes. This document argues that exported telemetry identifiers and statistics MUST explicitly define both the scope in which a value is unique and meaningful, and the conditions under which it may be compared with values from other contexts. This requirement is not limited to BMP; it applies to any telemetry mechanism in which a value can be generated in multiple semantic domains and therefore cannot be treated as self-describing solely by its encoded form. |
| | Evidence Requirements for Agent Control Delivery and Outcome Reconciliation |
| |
|
Agent systems can issue stop, suspend, revoke, constrain, cancel, or override instructions across system and administrative boundaries. A record that such a control was decided or dispatched does not establish that every intended enforcement point received or applied it. Conversely, the absence of an acknowledgement does not, by itself, establish non-delivery. This document defines format-independent evidence requirements for preserving those distinctions. It separates issuer-side emission, required-target resolution, receiver-side observation, enforcement outcome, and observation of the resulting control effect. For a control that must reach more than one enforcement target, the unit of delivery reconciliation is an instruction-target obligation rather than the parent instruction alone. The document also defines bounded negative observations, total reconciliation, population conservation, semantic-preservation requirements for intermediary paths, and a separate qualification for the evidentiary strength of aggregate claims. This document does not define a receipt format, wire protocol, authorization system, policy language, transparency service, or audit regime. |
| | Fast Notification for Link Bandwidth |
| |
|
This document proposes a data-plane-based method for rapidly advertising end-to-end path bandwidth information using a bitmap encoding. The mechanism enables fast load-balancing adjustments in AI/ML data center fabrics. |
| | Post-Quantum Cryptography Recommendations for Key Fragmentation in Low-Power Device Protocols |
| |
|
Cryptographic protocols deployed on low-power and constrained devices increasingly need to accommodate the larger key sizes introduced by modern and post-quantum cryptographic (PQC) algorithms. Many constrained network technologies (such as 6LoWPAN, SCHC, and similar adaptation-layer protocols) use explicit fragmentation mechanisms to transport messages that exceed link-layer frame sizes. As a result, cryptographic keying material and key-establishment messages may be segmented across multiple fragments during transmission. This document analyzes the security and operational implications of such fragmentation. It identifies common fragmentation patterns and examines risks including fragment loss, reordering, duplication, and partial exposure. It further discusses fragment-level integrity, replay resistance, and correct binding of fragments to cryptographic session state. This document does not define new cryptographic algorithms or fragmentation mechanisms. |
| | Agent Referral and Escrow Framework (AREF) |
| |
|
This document specifies the Agent Referral and Escrow Framework (AREF), a protocol for cryptographically attributed agent-to-agent referrals, escrow-bound commission commitments, and dual-rail financial settlement in multi-agent computing environments. As autonomous software agents increasingly transact with one another to acquire capabilities and coordinate work, no standardized mechanism exists for recording how one agent introduced another to a platform or service, binding that introduction to a financial commitment, or settling the resulting commission across heterogeneous payment infrastructure. AREF addresses this gap by defining: a portable Ed25519-signed attribution proof for referral chains of arbitrary depth; the semantics and payload schema of the SwarmSync- Referrer HTTP header used to bind a referrer to an escrow at hold- time; a commission vesting model tied to escrow finality rather than enrollment; a unified settlement finality signal operable over both traditional financial infrastructure (Stripe Connect) and cryptographic payment channels (X402); and the swarm_meta JSON embedding mechanism through which referral codes propagate across agent ecosystems without human involvement. This document is intended for implementers of agent orchestration platforms, payment service operators, and designers of multi-agent economic systems. |
| | CBOR Configuration |
| |
|
This document discusses configuration of CBOR processors. Using this information as a basis, it provides WGLC feedback on draft-ietf-cbor- serialization-08. |
| | ZeroPath VPN: Hop-Bound Secure Packet Validation with State-Bound Ephemeral Sessions,Cryptographic Attestation,and Opcode-Driven Control Architecture |
| |
|
This document specifies the complete ZeroPath VPN protocol suite, comprising three coordinated sub-protocols: HBSPV (Hop-Bound Secure Packet Validation) -- a three-domain packet framing model that isolates payload decryption to the authorized egress node while allowing intermediate hops to validate forwarding context without accessing payload content. SGCP (State Graph Cryptographic Protocol) -- a three-message cryptographically attested handshake enforcing mutual authentication and device posture verification before any session is established. SCSWP (Secure Cryptographic Session Workspace Protocol) -- a continuous session state mechanism providing tamper-evident hash chain continuity, epoch-bound forward secrecy, and four-dimensional trust scoring across the full session lifetime. This document additionally specifies a complete opcode architecture governing all control-plane and data-plane message types, providing a machine-parseable, extensible message dispatch framework. The protocol suite is implemented as a pure Python reference implementation at https://github.com/sripad2020/Zeropath-vpn. |
| | Measuring the CBOR Framing Space of COSE_Sign1 Data-Hash Pre-images |
| |
|
A signed statement conveyed as a COSE_Sign1 object may be serialized into many distinct byte sequences that all decode to the same data item. Where a protocol identifies such a statement by a digest computed over its wire octets (referred to here as a data-hash), the identifier is sensitive to that framing while the signature over the statement is not. This document reports a measurement of the size of that class. Taking one 165-octet COSE_Sign1 object and re-emitting it under every combination of six CBOR encoding freedoms yields 64 distinct octet sequences. All 64 carry an identical Sig_structure and therefore an identical, valid signature. All 64 produce distinct data-hash values, with no collisions. A stock CBOR decoder rejected none of them, and 31 were silently repaired into the canonical form by the act of being read. This document specifies nothing and proposes no wording. It reports a measurement, publishes the reproduction recipe, and identifies the prior work that already addresses the problem it measures. |
| | Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers |
| |
|
This document specifies a stateful NAT64 translation, which allows IPv6-Only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a stateful NAT64 translator are shared among several IPv6-Only clients. Stateful NAT64 translation also supports IPv4-initiated communications to a subset of the IPv6 hosts through configured bindings in the stateful NAT64 translator. When the stateful NAT64 translation is used in conjunction with DNS64, no changes are required in either the IPv6 client or the IPv4 server. This document obsoletes RFC 6146. |
| |
|
| |
| | Usage Limits on AEAD Algorithms |
| |
|
An Authenticated Encryption with Associated Data (AEAD) algorithm provides confidentiality and integrity. Excessive use of the same key can give an attacker advantages in breaking these properties. This document provides simple guidance for users of common AEAD functions about how to limit the use of keys in order to bound the advantage given to an attacker. It considers limits in both single- and multi-key settings. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. |
| | RT-Constrain Optimization in Hierarchical Route Reflection Scenarios |
| |
|
The Route Target (RT) Constrain mechanism specified in RFC 4684 is used to build a route distribution graph in order to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism cannot guarantee a correct route distribution graph. This document describes the problem scenario and proposes solutions to address the RT-Constrain issue in hierarchical RR scenarios. |
| | LISP YANG Model |
| |
| | draft-ietf-lisp-yang-25.txt |
| | Date: |
03/09/2026 |
| | Authors: |
Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras, Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino |
| | Working Group: |
Locator/ID Separation Protocol (lisp) |
|
This document describes a YANG data model to use with the Locator/ID Separation Protocol (LISP). This model can be used to configure and monitor the different control plane and data plane elements that enable a LISP network. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA) defined in [RFC8342]. |
| | IGP Reverse Prefix Metric |
| |
|
This document defines a method for calculating reverse paths by advertising reverse prefix costs. This method aims to solve the problem of strict RPF (Reverse Path Forwarding) check failure caused by mismatched bidirectional path costs in multi-area IGP scenarios. |
| | Currently Used Terminology Related to Source Address Validation |
| |
|
This document provides an overview of terms and abbreviations related to Source Address Validation (SAV). Its purpose is to establish a common and consistent set of terminology for use across SAV-related discussions and documents. This document explicitly does not serve as an authoritative source of correct terminology. |
| | Reilly Banking Integrity Protocol (RBIP) |
| |
|
This document defines version 02 of the Reilly Banking Integrity Protocol (RBIP), a compliance-grade architecture for generating immutable, auditor- and regulator-verifiable evidence trails in banking operations. RBIP combines cryptographic anchoring (via a public timestamping service) with archival deposit under a persistent identifier to produce permanent, tamper-evident records across three compliance domains: Proof-of-Reserves & Liquidity (PRL), Loan Origination & Collateral Chain (LOC), and KYC/AML Evidence Ledger (KAL), plus a system evidence domain (SYS) covering RBIP's own access, key, disclosure, and continuity events. This revision corrects defects in draft-reilly-banking-integrity-01 that would have prevented independent verification. It replaces the -01 Merkle construction with the construction of [RFC9162] and prohibits leaf duplication; moves Merkle leaves from the payload digest to a digest over the full signed Evidence Item; resolves three conflicting definitions of prev_digest; separates the anchored Bundle Core from the mutable anchor and archival metadata, eliminating the -01 circularity in which the anchored digest could not match the archived artifact; replaces unsalted identifier hashes with salted field commitments; and resolves the -01 conflict between its plaintext officer-name fields and its own prohibition on plaintext personal data. This revision also adds an Evidence Coverage Attestation, because integrity of submitted evidence is not evidence of completeness; mandatory heartbeat bundles, so that truncation of an evidence chain is detectable; explicit pending and attested anchor states in place of a fixed confirmation count; a Suspicious Activity Report confidentiality section, because publicly archiving KAL bundle metadata as described in -01 could disclose the existence of a report; algorithm suite identifiers and bridging records for hash and signature migration; a key discovery and revocation mechanism; and a prohibition on automated remediation of integrity violations. RBIP is intended to help financial institutions evidence compliance with Basel III/IV, SOX, BSA/AML, DORA, MiCA, ISO/IEC 42001:2023, and other applicable regimes while preserving privacy, accountability, and auditability. This document is published as a prior art record in the sense described in [I-D.reilly-rem-protocol]: a public, timestamped disclosure under 35 U.S.C. 102(a)(1) [USC-35-102]. Publication as a prior art record is a record of disclosure and its date. It is not a determination of novelty, priority, or patentability, and no such determination is claimed here. |
| | Geographic Attestation Results |
| |
|
Many workloads have limitations on what geography they are allowed to operate in. This is often due to a regulation that requires that the computation occur in a particular jurisdiction. There are many mechanisms by which Evidence of location may be created and then evaluated by a Verifier. No matter which mechanism is appropriate for a given situation, the result of the Verification can be expressed in a similiarly defined EAT Attestation Result. This document is about encoding a variety of geographical conclusions conclusions in an Attestation Result. In addition, one mechanism of directly creating a geographic result in the form of an Endorsement is described in an appendix. |
| | Signed Decision Receipts for Machine-to-Machine Access Control |
| |
|
This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp. All of these are signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. |
| | Bitcoin-Anchored Temporal Proof for Transparency Services |
| |
|
This document defines a mechanism for temporal anchoring of digital artifacts by committing cryptographic hashes to the Bitcoin blockchain via the OpenTimestamps protocol. The resulting proof is independently verifiable by any party with access to independently validated Bitcoin chain data, without contacting the anchoring service. The SCITT Architecture is used as the primary integration example. No changes to the SCITT architecture are required. |
| | Verifiable Attenuated Delegation for AI Agent Chains |
| |
|
AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested "act" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), links each delegation to its parent by a cryptographic byte- commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, and monotonic expiry. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography. |
| | Trust Residuals for Navigation QR Codes |
| |
|
Navigation QR codes carrying absolute HTTP or HTTPS URIs initiate web interactions, including payment, ordering, and institutional workflows. Selected deployed scanners decode and hand off those URIs without an interoperable account of whether the navigation is authorized. This document defines an Informational architecture and candidate decision- semantics surface based on trust residuals: typed, evidence-bearing deviations between a scanned artifact and issuer-chain, destination- policy, redirect-flow, runtime-safety, freshness, and artifact-integrity constraints. Given a residual vector and a declared verification profile, explicit precedence rules map the result to a bounded set of scanner decision states. Security invariants prevent reputation, HTTPS transport, or runtime-safety signals from upgrading an otherwise untrusted issuer path. This document does not define a payload carrier or a final wire format for signed governance objects; those belong in a future binding specification. |
| | IS-IS Hello Capability |
| |
|
Advertisement of capabilities in Hellos is useful to allow support of optional features in establishing and maintaining adjacencies. This document defines a new TLV to be sent in hellos to advertise such capabilities. |
| | Ad Creative Signaling over the MSF Event Timeline |
| |
|
This document defines the carriage of ad creative signaling -- creative identity, tracking events, and measurement verification metadata as specified by SVTA 2053-1 -- in records on a Media over QUIC (MOQT) Streaming Format (MSF) Event Timeline track. It complements the carriage of SCTE-35 splice signaling over the same mechanism: splice events describe where placement opportunities occur on a media timeline, while the event class defined here describes the creatives that fill them and how their playback is to be measured. This binding is the MSF counterpart of the DASH and HLS carriage bindings defined by SVTA 2053-1, which defines none for MOQT. |
| | PSHMP Core: A Hybrid L4 Overlay for Proactive Self-Healing and Resilient Multi-Hop Delivery |
| |
|
PSHMP Core is a hybrid L4-oriented overlay designed to keep multi-hop data delivery working when individual nodes, links, or network segments become unstable. It runs above ordinary IP infrastructure and does not require changes to Layer 3 routing. Under stable conditions the system builds linear relay chains. When several nodes on a path show degradation, it can switch locally into a mesh-style recovery mode: collect alternative candidates, apply progressive fallback rules, enforce a quality gate, and replace the affected path. Continuous node assessment (K-Factor), diversity- aware selection, failure tracking, gossip and DHT discovery, and batch acknowledgements with gap recovery form the supporting mechanisms. This document describes the architecture (including component layers), operating principles, key evaluation and delivery formulas, and the relationship to an experimental implementation (PSHMP Core v3.1). Implementation-specific scoring weights, exact thresholds, and proprietary optimisations may be refined by integrators; the formulas given here represent the reference model used in the current experimental codebase. |
| | LISP Silent Host Discovery using the Mapping System |
| |
|
The on-demand discovery model of the Locator/ID Separation Protocol (LISP) is ineffective for "silent hosts", endpoints that do not initiate traffic. This is a common challenge in environments like manufacturing and IoT environments, where low-power devices frequently go silent to conserve energy. This document proposes a mechanism to discover these hosts by using the LISP mapping system itself. xTRs that are able to probe a given EID prefix register that capability with the Map-Server. When a Map-Request for an unknown destination arrives at the Map-Server, it is forwarded and replicated to all xTRs that have registered the covering EID prefix, initiating a controlled, on-demand discovery process for that specific host. This approach provides a scalable alternative to network flooding for locating silent endpoints. |
| | A CBOR Simple Values Range for Packing and Templating |
| |
|
The Concise Binary Object Representation (CBOR, RFC 8949, STD 94) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. This document registers a range of sixteen CBOR simple values (0 to 15) that can be shared by different specifications using them for CBOR transformations, such as compression or templating, in a non- conflicting way. This allows current and future specifications to reuse the smallest (single-byte) simple values range while defining their own ways to use them for achieving their goals. This document updates RFC 8949. |
| | OAuth 2.0 Attestation-Based Client Authentication |
| |
|
This specification defines an extension to the OAuth 2.0 protocol (RFC 6749) that enables a client instance to include a key-bound attestation when interacting with an Authorization Server or Resource Server. This mechanism allows a client instance to prove its authenticity verified by a client attester without revealing its target audience to that attester. It may also serve as a mechanism for client authentication as per OAuth 2.0. |
| | Segment Routing based Network Resource Partition (NRP) for Enhanced VPN |
| |
|
Enhanced VPNs aim to deliver VPN services with enhanced characteristics, such as guaranteed resources, latency, jitter, etc., so as to support customers requirements on connectivity services with these enhanced characteristics. Enhanced VPN requires integration between the overlay VPN connectivity and the characteristics provided by the underlay network. A Network Resource Partition (NRP) is a subset of the network resources and associated policies on each of a connected set of links in the underlay network. An NRP could be used as the underlay to support one or a group of enhanced VPN services. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment is referred to by its Segment Identifier (SID). SIDs can represent topological or service based instructions. SIDs can further be associated with a set of network resources used for executing the instruction. Such SIDs are called resource-aware SIDs. A group of resource-aware SIDs may be used to build SR based NRPs, which provide customized network topology and resource attributes required by one or a group of enhanced VPN services. This document describes an approach to build SR based NRPs using resource-aware SIDs. The SR based NRP can be used to deliver enhanced VPN services in SR networks. |
| | TLS/DTLS 1.3 Profiles for the Internet of Things |
| |
|
RFC 7925 offers guidance to developers on using TLS/DTLS 1.2 for Internet of Things (IoT) devices with resource constraints. This document is a companion to RFC 7925, defining TLS/DTLS 1.3 profiles for IoT devices. Additionally, it updates RFC 7925 with respect to the X.509 certificate profile and ciphersuite requirements. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-tls13-iot. |
| |
|
| |
| | CDDL Module Structure |
| |
| | draft-ietf-cbor-cddl-modules-07.txt |
| | Date: |
02/09/2026 |
| | Authors: |
Carsten Bormann, Brendan Moran |
| | Working Group: |
Concise Binary Object Representation Maintenance and Extensions (cbor) |
|
At the time of writing, the Concise Data Definition Language (CDDL) is defined by RFC 8610 and RFC 9682 as well as RFC 9165 and RFC 9741. The latter two have used the extension point provided in RFC 8610, the _control operator_. As CDDL is being used in larger projects, the need for features has become known that cannot be easily mapped into this single extension point. The present document defines a backward- and forward-compatible way to add a module structure to CDDL. |
| | Content Delivery Network Interconnection (CDNI) Control Interface / Triggers 2nd Edition |
| |
|
This document obsoletes RFC8007. The document describes the part of Content Delivery Network Interconnection (CDNI) Control interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN MAY use this mechanism to request that the downstream CDN preposition, invalidate, and/or purge metadata and/or content. The upstream CDN MAY monitor the status of activity that it has triggered in the downstream CDN. |
| | Proxy Operations in Group Communication for the Constrained Application Protocol (CoAP) |
| |
|
This document defines a specific realization of proxy intended for scenarios that use group communication for the Constrained Application Protocol (CoAP). Such a proxy processes a single request sent by a client typically over unicast and distributes the request to a group of servers, e.g., over UDP/IP multicast as the defined default transport protocol. Then, the proxy collects the individual responses from those servers and relays those responses back to the client, in a way that allows the client to distinguish the responses and their origin servers through embedded addressing information. This document updates RFC7252 with respect to caching of response messages at proxies. |
| | Delegation Revalidation by DNS Resolvers |
| |
|
This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the shortest TTL among the parent NS RRset, the DS RRset (if present), and the child NS RRset. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-29.txt |
| | Date: |
02/09/2026 |
| | Authors: |
Mike Ounsworth, Hannes Tschofenig, Henk Birkholz, Monty Wiseman, Ned Smith |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. |
| | A feature freezer for the Concise Data Definition Language (CDDL) |
| |
|
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document was started to collect nice-to-have features that did not make it into the first RFC for CDDL, RFC 8610, or the specifications exercising its extension points, such as RFC 9165. Significant parts of this draft have now moved over to the CDDL 2.0 project, described in draft-bormann-cbor-cddl-2-draft. The remaining items in this draft are not directly related to the CDDL 2.0 effort. |
| | Discovery of OSCORE Groups with the CoRE Resource Directory |
| |
|
Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE). At deployment time, devices might not know the exact security groups to join, the respective Group Managers responsible for those groups, or other information required to perform the joining process. This document defines how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Managers. A given security group can be used to protect communications in multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources. This approach is consistent with, but not limited to, the joining of security groups based on the Authentication and Authorization for Constrained Environments (ACE) framework. |
| | Modern Network Unicode |
| |
|
BCP18 (RFC 2277) has been the basis for the handling of character- shaped data in IETF specifications for more than a quarter of a century now. It singles out UTF-8 (STD63, RFC 3629) as the “charset” that MUST be supported, and pulls in the Unicode standard with that. Based on this, RFC 5198 both defines common conventions for the use of Unicode in network protocols and caters for the specific requirements of the legacy protocol Telnet. In applications that do not need Telnet compatibility, some of the decisions of RFC 5198 can be cumbersome. The present specification defines “Modern Network Unicode” (MNU), which is a form of RFC 5198 Network Unicode that can be used in specifications that require the exchange of plain text over networks and where just mandating UTF-8 may not be sufficient, but there is also no desire to import all of the baggage of RFC 5198. As characters are used in different environments, MNU is defined in a one-dimensional (1D) variant that is useful for identifiers and labels, but does not use a structure of text lines. A 2D variant is defined for text that is a sequence of text lines, such as plain text documents or markdown format. Additional variances of these two base formats can be used to tailor MNU to specific areas of application. |
| | BFD Path Consistency over SR |
| |
|
Bidirectional Forwarding Detection (BFD) can be used to monitor paths between nodes. U-BFD defined in [I-D.ietf-bfd-unaffiliated-echo] can effectively reduce the device equipment. Seamless BFD (S-BFD) provides a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale network. In SR network, BFD can also be used to monitor SR paths. When a headend use BFD to monitor the segment list/CPath of SR Policy, the forward path of control packet is indicated by segment list, the reverse path of response control packet is via the shortest path from the reflector back to the initiator (headend) as determined by routing. The forward path and reverse path of control packet are likely inconsistent going through different intermediate nodes or links. This document describes a method to keep the forward path and reverse path consistent when using S-BFD or U-BFD to detect SR Policy |
| | Bidirectional Access Control in the Authentication and Authorization for Constrained Environments (ACE) Framework |
| |
|
This document updates the Authentication and Authorization for Constrained Environments (ACE) framework, for which it defines a method to enforce bidirectional access control by means of a single access token. Therefore, this document updates RFC 9200. |
| | CBOR: Generating Numeric Map Labels from Textual EDN |
| |
|
The Concise Binary Object Representation (CBOR, STD 94 == RFC 8949) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. CBOR diagnostic notation (EDN) is widely used to represent CBOR data items in a way that is accessible to humans, for instance for examples in a specification. Complex examples often use nested maps, the map keys (labels) for each of which are often sourced from different specifications. While the e'' application extension provides a way to import data items, particularly constant values, from a CDDL model, it does not help with automatically selecting the right kind of map depending on its position in the nested maps. // The present document is intended to capture ideas initially // discussed at the CBOR WG interim 2025-06-25 and demonstrate some // design alternatives. It is not ready for adoption yet in any way. |
| | Workload Identifier Origin Hint for TLS ClientHello |
| |
|
This document defines a TLS extension that allows clients to indicate one or more workload identifier origins in the ClientHello message. Each origin consists of a URI scheme and trust domain component, representing the administrative domain and identifier namespace in which the client operates. These identifier origins serve as hints to enable the server to determine whether client authentication is required and which policies or trust anchors should apply. This mechanism improves efficiency in mutual TLS deployments while minimising the exposure of sensitive identifier information. To protect confidentiality, this extension can be used in conjunction with Encrypted Client Hello (ECH). |
| | Definition of Service Intent in Autonomic Networks |
| |
|
While ANIMA Intent enables goal-oriented control within an Autonomic Domain, emerging services (e.g., AI inference) require a common, interoperable representation for expressing service-level objectives and constraints that span network, compute, and storage resources, rather than connection-centric descriptions. This document defines Service Intent for Autonomic Networks by specifying a structured semantic model and a concise format with identification, scope, versioning, and lifecycle semantics. |
| | In-Network Inference Protocol |
| |
|
This document specifies the In-Network Inference Protocol (INIP), a lightweight protocol designed specifically for implementing high- speed in-network inference in data center internal networks. INIP utilizes data plane devices (such as switches, DPUs, and SmartNICs) to perform lightweight inference tasks while ensuring that core network forwarding functions are not affected. The protocol operates based on the IPv4 protocol and adopts a fixed, lightweight packet format. INIP adopts a two-tier architecture of "centralized control plane adaptation and scheduling, and minimal data plane execution". The control plane stores all inference models, deploys model rules to data plane devices using a CDN-like scheduling method, and assumes the responsibility of degraded fallback inference; the data plane performs packet parsing and match action table-based inference. This document details INIP's core logic, packet format, data plane device constraints, model expression specifications, control plane responsibilities, CDN-like scheduling mechanism, dynamic model popularity replacement, and overall execution process. |
| | Structural Vulnerabilities in ASRank under Adversarial Conditions |
| |
|
This document analyzes the structural vulnerabilities of ASRank, a widely used algorithm for inferring Autonomous System (AS) business relationships from BGP routing data. ASRank plays a key role in security research and BGP operation, yet its inference process is highly sensitive to small changes in input data. This sensitivity introduces risks in adversarial conditions, where inference results may be manipulated without detection. This document outlines the design of ASRank, identifies its structural vulnerabilities, analyzes a minimal manipulation example, and discusses the security implications and potential countermeasures. |
| | Merkle Tree Certificates Deployment Use Cases |
| |
|
Merkle Tree Certificates (MTC) I-D.ietf-plants-merkle-tree-certs has been defined for the use case of the WebPKI. In this document we explore when and how MTC in parts or full can be used in different use cases. Some of this use-cases may provide benefit for private PKI usage. |
| | Status Set Extension Mapping for the Extensible Provisioning Protocol |
| |
|
This document describes an Extensible Provisioning Protocol (EPP) extension for the provisioning and management of status sets applied to EPP objects, such as the domain name object in RFC 5731. The EPP status values defined in the EPP object mappings, such as Section 2.3 of RFC 5731, support human-readable text that describes the rationale or reason for the status applied to the object. There can be many overlapping reasons for a status value being applied to the object, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a list of status values, so clients and servers can manage the status sets in place of individual status values to effectively manage the overlapping reasons. The EPP extension supports the provisioning of client status sets, disclosure of the server status sets, and an enhanced authorization model for client status sets with the EPP Authentication Token in [I-D.gould-regext-auth-token]. |
| | Registration Data Access Protocol (RDAP) Extension for Status Set |
| |
|
This document describes an Registration Data Access Protocol (RDAP) extension for including status sets assigned to RDAP object classes, such as the Domain Object Class and the Nameserver Object Class in [RFC9083]. There can be many overlapping reasons for each of the "status" member values, such as implementing a lock service, complying with a court order, or addressing domain abuse. A status set defines an object representing the reason for setting a "status" value, so clients and servers can effectively manage the overlapping reasons of individual "status" values using the status sets. This RDAP extension supports returning the assigned client and server status sets with additional data members, such as the mapped "status" values and when the status set was assigned. |
| | An Attenuated Delegation Profile for Automated Agents |
| |
|
This document specifies a profile for delegating authorization to automated agents across administrative domains. It defines an HTTP header field, Agent-Delegation, that carries a chain of attenuated delegation links. Each link narrows the scope, tightens or holds a set of floor conditions, and shortens or holds the expiry of its parent. A verifier checks every link in the chain, not only the last, and rejects the chain if any link violates attenuation. The profile is deliberately agnostic to the credential format and to the nature of the entity that issues floor attestations; it specifies required properties, not a specific encoding or a specific kind of issuer. It composes with, and does not replace, existing work on agent credential provisioning and posture. |
| | The Single-Stack 100/50 Principle: Formal Definitions for IPv4 Retirement in Dual-Stack Networks |
| |
|
The Single-Stack 100/50 Principle defines two independent, formally derivable consequences of retiring the IPv4 protocol stack in a dual- stack (IPv4 + IPv6) network environment: (1) 100% elimination of executable attacks attributable to IPv4 under the document's definition, and (2) an exact 50% reduction in the count of concurrently exposed network-layer protocol-stack surfaces when IPv4 is retired, stated by the Principle as a minimum structural floor. The analysis is bounded to the functional Layer 3 scope and parameter universe U_3 defined in this document. Within that premise, Axiom 0 and Axioms 1-15 stipulate protocol independence, operational state transitions, traffic termination, addressing/routing domains, protocol-associated control and resolution functions, header- processing paths, and protocol-specific vulnerability execution. Theorem I follows by removal of the necessary IPv4 Layer 3 execution precondition for every IPv4-attributable attack. Theorem II follows by direct enumeration of two concurrently exposed protocol-stack surfaces before retirement and one after retirement. Neither theorem depends on empirical attack volume, incident frequency, or statistical inference, and neither theorem claims that IPv6 is inherently more secure than IPv4. |
| | Agent Identity and Discovery (AID) |
| |
|
Agent Identity and Discovery (AID) answers one question: given a domain, where is the agent and which protocol should a client speak? An AID client queries a DNS TXT record at the well-known subdomain _agent. and learns the service endpoint URI, protocol token, authentication hint, and optional metadata for that agent. This document defines the AID v2 (`aid2`) record format, client discovery algorithm, exact-host lookup rules, endpoint-proof (PKA) handshake using Ed25519 HTTP Message Signatures, security requirements, and IANA registrations for the `_agent` DNS node name and the `agent` service name. The legacy `aid1` record format is retained as a compatibility format for clients migrating from earlier deployments. AID is intentionally small; after discovery, protocol- specific mechanisms such as MCP or A2A handle communication and capability negotiation. |
| | The LIMITS SMTP Service Extension |
| |
|
To allow browsing in videos |
| | X.509 Certificate Bearer Profile for OAuth 2.0 Client Authentication and Authorization Grants |
| |
|
This specification defines the use of an X.509 certificate, issued under a Public Key Infrastructure (PKI), as a means for requesting an OAuth 2.0 access token as well as for client authentication, profiling the Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants in a manner analogous to the JSON Web Token (JWT) Bearer Token profile and the SAML 2.0 Bearer Assertion profile. It is motivated primarily by workload identity systems, such as SPIFFE/SPIRE and Athenz, that already issue software workloads short- lived X.509 certificates for mutual TLS, and that benefit from using those same certificates directly with OAuth 2.0. Unlike a bare bearer credential, this profile requires that possession of the private key corresponding to the certificate's public key be corroborated as part of every use, so that a copy of the certificate alone -- which is not a secret -- is never sufficient to obtain a grant or authenticate a client. |
| | Agent Infrastructure Control Protocol |
| |
|
Autonomous software agents increasingly inspect and modify infrastructure through provider-specific APIs and generic tool protocols. Those interfaces expose operations, but they do not provide a common semantic contract for obtaining bounded situational context, expressing an intended outcome under constraints, reviewing the exact material effects, binding authorization to those effects, observing durable execution, and determining whether the intended outcome was achieved. This document specifies the Agent Infrastructure Control Protocol (AICP). AICP is a transport-independent object and lifecycle model for capability discovery, situations, intents, plans, authorization decisions, asynchronous operations, verified outcomes, machine- actionable problems, and reconciliation. It also specifies an HTTP binding and describes mappings to existing agent protocols. AICP does not replace cloud resource APIs, orchestration languages, agent- to-agent protocols, authentication systems, or provider policy engines. |
| | PALA-1: A Tamper-Evident Audit Record Format for Constrained and Disconnected Deployments |
| |
|
This document describes PALA-1, a compact binary record format for tamper-evident audit trails produced by AI inference runtimes and robotic control systems. It is designed for a class of deployment defined by three constraints that hold together: the hardware is computationally modest and its cycles are reserved for the workload and the power budget rather than for the audit trail; no external witness is reachable, whether because policy forbids outbound contact or because the platform operates beyond connectivity, so a witness is unavailable by rule or by physics rather than by circumstance; and the right to verify the trail is separated from the right to read what it records. Records form an append-only hash chain. Integrity verification requires no key material of any kind, inspects no record bodies, and costs one hash per record rather than one signature. The format distinguishes three separately answerable questions -- internal consistency, completeness against an external anchor, and existence at a point in time against an external witness -- and states which of the three a given trail actually supports rather than implying all three. The format is frozen at version 1.0 and is described here as it is. This document presents an existing wire format; it does not revise one. Where a deployment does permit an external witness, a chain head may be published to a transparency service such as that of the Supply Chain Integrity, Transparency, and Trust architecture (SCITT, RFC 9943); that path is described but is not part of the hashing contract. |
| | The OAuth 2.1 Authorization Framework |
| |
| | draft-ietf-oauth-v2-1-16.txt |
| | Date: |
02/09/2026 |
| | Authors: |
Dick Hardt, Aaron Parecki, Torsten Lodderstedt |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
The OAuth 2.1 authorization framework enables an application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750. |
| | Secure Asset Transfer (SAT) Use Cases |
| |
| | draft-ietf-satp-usecases-10.txt |
| | Date: |
02/09/2026 |
| | Authors: |
Venkatraman Ramakrishna, Thomas Hardjono, Peter Liu |
| | Working Group: |
Secure Asset Transfer Protocol (satp) |
|
This document describes prominent scenarios where enterprise systems and networks maintaining digital assets require the ability to securely transfer assets or data to each other. |
| |
|
| |
| | YANG Data Model for IPv6 Neighbor Discovery |
| |
|
This document defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, including IPv6 address resolution, redirect function, proxy Neighbor Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced Duplicate Address Detection. |
| | Automated Certificate Management Environment (ACME) Extension for Proof-of-Possession |
| |
| | draft-ietf-acme-pop-00.txt |
| | Date: |
01/09/2026 |
| | Authors: |
Feng Geng, Panyu Wu, Liang Xia, CHEN Xin |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
The Automated Certificate Management Environment (ACME) protocol [RFC8555] requires a PKCS#10 Certificate Signing Request (CSR) at the finalization stage. This document defines an optional extension that allows a client to prove possession of a private key directly, without constructing a CSR. The extension is motivated by use cases where the CSR-based flow is problematic: KEM-only keys that cannot generate self-signatures, resource-constrained devices that benefit from reduced encoding overhead, and issuance models where the certificate is constructed from order and profile data (e.g., via the ACME Profiles extension [I-D.ietf-acme-profiles]) rather than a client-generated CSR. This is particularly relevant when combined with compact encodings such as C509 certificates [I-D.ietf-cose-cbor-encoded-cert]. In the "newOrder" request, the client declares the public key via a popKey field and includes a pop-type identifier whose value is the empty string. The server creates a dedicated pop authorization containing a single pop-01 challenge, processed using the same state machine as any other ACME authorization. When all authorizations (including the pop authorization) are valid, the ACME server issues a certificate using the validated public key and the authorized identifiers, eliminating the need for a CSR at finalization. The extension is additive and strictly optional: clients that do not use it, and servers that do not support it, continue to use the standard CSR-based flow defined in [RFC8555] without any changes. |
| | YANG Data Models for requesting Path Computation in WDM Optical Networks |
| |
|
This document provides a mechanism to request path computation in Wavelength-Division Multiplexing (WDM) optical networks composed of Wavelength Switched Optical Networks (WSON) and Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) switched technologies. This model augments the Remote Procedure Calls (RPCs) defined in RFC YYYY. [RFC EDITOR NOTE: Please replace RFC YYYY with the RFC number of draft-ietf-teas-yang-path-computation once it has been published. |
| | Composite ML-KEM for use in X.509 Public Key Infrastructure |
| |
| | draft-ietf-lamps-pq-composite-kem-21.txt |
| | Date: |
01/09/2026 |
| | Authors: |
Mike Ounsworth, John Gray, Massimiliano Pala, Jan Klaussner, Scott Fluhrer |
| | Working Group: |
Limited Additional Mechanisms for PKIX and SMIME (lamps) |
|
This document defines combinations of US NIST ML-KEM in hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448. These combinations are tailored to meet security best practices and regulatory guidelines. Composite ML-KEM is applicable in any application that uses X.509 or PKIX data structures that accept ML- KEM, but where the operator wants extra protection against breaks or catastrophic bugs in ML-KEM. |
| | YANG Data Model for OSPF SRv6 |
| |
|
This document defines a YANG data model that can be used to configure and manage OSPFv3 Segment Routing over the IPv6 Data Plane. |
| | Using CDDL for CSVs |
| |
|
The Concise Data Definition Language (CDDL), standardized in RFC 8610, is defined to provide data models for data shaped like JSON or CBOR. Another representation format that is quote popular is the CSV (Comma-Separated Values) file as defined by RFC 4180. The present document shows a way how to use CDDL to provide a data model for CSV files. |
| | CDDL 2.0 and beyond -- a draft plan |
| |
|
The Concise Data Definition Language (CDDL) today is defined by RFC 8610, RFC 9165, RFC 9682, and RFC 9741). RFC 9165 and the latter (as well as some more application specific specifications such as RFC 9090) have used the extension point provided in RFC 8610, the control operator. As CDDL is used in larger projects, feature requirements become known that cannot be easily mapped into this single extension point. Hence, there is a need for evolution of the base CDDL specification itself. The present document provides a roadmap towards a "CDDL 2.0"; it is intended to serve as a basis for implementations that evolve with the concept of CDDL 2.0. It is based on draft-bormann-cbor-cddl-freezer, but is more selective in what potential features it takes up and more detailed in their discussion. This document is intended to evolve over time; it might spawn specific documents and then retire, or it might eventually be published as a roadmap document. |
| | Hybrid Digital Signatures with Strong Unforgeability |
| |
|
This document proposes a generic hybrid signature construction that achieves strong unforgeability under chosen-message attacks (SUF- CMA), provided that the second component (typically the post-quantum one) is SUF-CMA secure. The proposed hybrid construction differs from the current composite hybrid approach by binding the second (post-quantum) signature to the concatenation of the message and the first (traditional) signature. This approach ensures that hybrid signatures maintain SUF-CMA security even when the first component only provides EUF-CMA security. In addition to this general hybrid construction, this document also proposes a non-black-box variant specifically tailored for schemes built from the Fiat-Shamir paradigm. This variant is SUF-CMA secure as long as only one component is SUF-CMA secure. |
| | Equipment Capability Application |
| |
|
This document applies the generalized capability principles to the description of equipment (a physical thing) with applied data (configuration state and code (software, firmware etc.)) and shows how such capability specifications integrate with base inventory and entitlement models as defined in Network Inventory, Software Extension and Entitlement YANG models. The approach is examined by example, focusing on how the potential capabilities of each equipment type-version with applied data are described, how these map to entitlements (licensed or policy- controlled subsets of capabilities), and how they are instantiated as inventory items. The explanation covers both the capabilities of equipment in terms of physical properties and the capabilities of equipment with applied data in terms of resultant emergent functionality. |
| | Generalized Capability Principles |
| |
|
This document introduces a framework for capability modeling based on the specification and refinement principles established in ITU-T G.7711 Annex G (also previously published as ONF TR-512.7. See latest G.7711 release) and the modeling boundaries work documented in draft-davis-netmod-modelling-boundaries. The framework defines how component–system capabilities can be explicitly described and refined via a process of pruning, refactoring, and occurrence formation. This draft version additionally incorporates a sketch of an occurrence-semantics kernel. This kernel is presented here as a continuation of the refinement and occurrence-formation principles already introduced in the previous version, not as a retrospective reinterpretation of them. These capability definitions can target detailed operational considerations, system interactions, licensing, abstract product declarations, or sales and marketing. The framework supports modular, layered, and fractal declarations of networked behavior, and provides a foundation for a suite of future IETF drafts aligned with ongoing work on photonic plug manifests, entitlement/licensing, IVY equipment modeling, energy/thermal considerations and related domains. |
| | Export of RoCEv2 Base Transport Header (BTH) Information Using IP Flow Information Export (IPFIX) |
| |
|
This document defines a new set of IP Flow Information Export (IPFIX) Information Elements (IEs) for exporting Base Transport Header (BTH) information for RDMA over Converged Ethernet version 2 (RoCEv2) traffic. These extensions enable network monitoring systems to collect and analyze the characteristics of RDMA traffic widely used in high-performance computing, storage, and artificial intelligence applications. |
| | Problem Statement: Information Sharing of Optical Impairments in Monitoring of Multi-Domain All-Optical Paths |
| |
|
In multi-domain all-optical Wavelength Switched Optical Networks (WSONs), end-to-end services may traverse multiple administrative domains operated by different entities. Monitoring such services requires visibility into optical impairments that accumulate across domain boundaries. However, exchanging impairment-related information raises operational, scalability, and confidentiality concerns. Detailed metrics such as attenuation, noise, nonlinear effects, and filtering penalties may be necessary for accurate performance assessment, yet they can expose sensitive topology, equipment, or utilization information. This document describes the problem space associated with sharing optical impairment information across administrative domains for monitoring purposes. It highlights the need to balance operational visibility and confidentiality preservation, and outlines considerations for abstraction, information granularity, and trust relationships among participating operators. |
| | Consistency-Aware Multipath Transport (CAMP) toward Interactive Multimodal LLM-Based Systems |
| |
|
With the prosperity of generative large language models (LLMs), interactive LLM-based services, such as digital humans, have imposed new stringent requirements on low latency and high multimodal consistency. Traditional interactive LLM-based systems typically transmit multimodal content over a single network path, thereby failing to exploit the advantages offered by multipath networks. Even when multipath transport mechanisms are adopted, single-stream encapsulation does not enable differentiated management of heterogeneous modalities. However, naively separating modalities into multiple streams further introduces inter-modal arrival inconsistency. To address these challenges, this document specifies CAMP, a consistency-aware multipath transport design over the Multipath QUIC (MPQUIC) protocol. First, CAMP defines a three-stream separation encapsulation format to support modality-differentiated transmission. Second, it introduces a hierarchical multimodal data management mechanism to coordinate the transmission of correlated data across modality streams. Third, it incorporates a transport- layer consistency-aware multipath scheduler to reduce inter-modal arrival time deviation across network paths. Fourth, it specifies a client-side application-layer alignment mechanism that operates in coordination with the transport scheduler. To the best of our knowledge, this is the first specification to address multipath- enabled multimodal consistency guarantees for interactive LLM-based systems. |
| | A YANG Data Model for Microwave Radio Link |
| |
| | draft-ybam-ccamp-rfc8561bis-02.txt |
| | Date: |
01/09/2026 |
| | Authors: |
Scott Mansfield, Jonas Ahlberg, Min Ye, Daniela Spreafico, Danilo Pala |
| | Working Group: |
Individual Submissions (none) |
|
This document defines a YANG data model for control and management of radio link interfaces and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available for other interface types as well. This document obsoletes RFC 8561. |
| | Agentic Saturation Stridency (SAS): A Quantitative Model and Admission Architecture for Autonomous Agent Traffic |
| |
|
Autonomous computational agents are capable of generating high- frequency synthetic traffic that can cause a protected system to allocate memory, consume processing cycles, or invoke application- layer computational routines before the eligibility of an incoming request has been established. This document formalizes Agentic Saturation Stridency (SAS) as a measurable system condition defined by the ratio between the arrival rate of unverified agentic traffic over a discrete observation interval and the empirically sustainable admission capacity of the target boundary. The document defines three operational regimes (Subcritical, Critical, and Supercritical) and specifies a pre-runtime structural admission architecture designated Reality Layer 0 (RL0). RL0 establishes an ex-ante admission boundary intended to drop or reject unverifiable traffic before protected application-layer execution, incorporating bounded-state replay protection, out-of-band key revocation checking via probabilistic structures, constant-time cryptographic operations, and standardized wire encodings. The admission framework utilizes a signed Reality-Token (RT) and an admission predicate associated with the Invariant Reality Prism (IRP), listed as an Informative Reference in the NIST Cybersecurity Framework Online Informative References catalog under Reference ID 189 (IRP-189). The catalog entry is cited for informational provenance only and does not imply NIST authorship, endorsement, certification, or normative incorporation of the IRP framework. |
| | Method to enable signaling of L2VPN services using SRv6 extensions |
| |
|
This document describes a mechanism to provide L2VPN services using Segment Routing over IPv6 (SRv6), eliminating the need for a separate signaling protocol for VPN label distribution. In current deployments, L2VPN services rely on dedicated protocols such as the Label Distribution Protocol (LDP) or Border Gateway Protocol (BGP) for service label signaling, which adds control-plane complexity. The proposed mechanism introduces an SRv6-based extension that enables L2VPN service identification within the SRv6 framework, reducing control-plane overhead and providing a simplified and efficient solution for L2VPN service delivery. |
| | AuthZEN Profile for OAuth 2.0 Token Issuance |
| |
|
Numerous OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a security token, and each of them declares the decision itself to be a matter of local policy that is out of scope. The result is that a decision common to every OAuth deployment has no interoperable expression. This document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point. It specifies how the inputs to a token issuance request map onto AuthZEN's mandatory five-tuple, how a Policy Decision Point response may shape the issued token, and how a Policy Decision Point advertises support for the profile. The mapping is complete for grants whose request names a single party, including the authorization code and client credentials grants. Companion documents bind the grant families that add structure this document does not model, the token exchange family first among them. |
| | AuthZEN Binding for OAuth 2.0 Token Exchange |
| |
|
OAuth 2.0 Token Exchange (RFC 8693) defines the moment at which an authorization server decides whether one party may obtain a token to act as, or on behalf of, another. It states that the decision is governed by policy, and does not define that policy. The specifications layered on top of it - identity chaining, identity assertion authorization grants, and transaction tokens - inherit the same seam. This document binds those flows to the AuthZEN profile for OAuth 2.0 token issuance. It specifies how a token exchange request is derived into AuthZEN evaluation requests, how the authority of the requesting party is expressed as a decision distinct from the authority being delegated, and what each of the token types layered on token exchange contributes to that mapping. |
| | AuthZEN Profile for Authorization Claims in JWT Access Tokens |
| |
|
RFC 9068 recommends that an authorization server placing group memberships, roles, or entitlements in a JWT access token draw those claims from the SCIM user schema. It says what the claims are named and how their values are encoded, and it does not say where an authorization server obtains them. In deployments today they come from a directory, a database, or a vendor-specific hook, and the question they answer is an authorization question asked of something that is not the authorization system. This document profiles the Resource Search API of the OpenID AuthZEN Authorization API for that purpose. It binds each authorization claim to a search, defines how a search result set becomes a claim value, and requires that a search result never influence whether a token is issued or what authority it conveys. It may be applied on its own, by an authorization server that externalizes claim enrichment but not its issuance decision, or alongside the companion framework document that externalizes the decision. |
| | The Agent Action Decision Protocol (AADP): Per-Action Authorization for AI Agents |
| |
|
The Agent Action Decision Protocol (AADP) separates per-action authorization from an agent's identity and its standing capabilities, and gives that authorization semantics that a stateless tool permission or access grant cannot express: whether a specific proposed action, with specific argument values, may be performed now, given mutable state such as cumulative budgets, live reservations, approval lifecycle, and a kill switch. Existing agent-security work concentrates on identity -- who an agent is, what credentials it holds, and which tools it may reach; AADP addresses the complementary decision, and composes with that work rather than replacing it. This document defines a two-phase wire contract between a Policy Decision Point (PDP) that authorizes agent actions and the Policy Enforcement Points (PEPs) that perform them: verdicts with machine-readable reasons, obligations that fail closed, atomic budget reservation, an approval lifecycle, idempotency behavior, evidence sufficient to re- derive every verdict, and a set of evaluation invariants any conformant decision point must observe -- including the rule that an irreversible action is never executed autonomously. The protocol is transport-agnostic and is designed so that decision points and enforcement points can be implemented independently, in different languages, by different parties. |
| | OAuth Subject Signing Key Binding for Resource Servers |
| |
|
Resource servers in OAuth deployments sometimes receive application- layer authorization evidence that is digitally signed by the subject represented by an access token. Verification of such evidence requires the resource server to obtain a trusted public signing key that is bound to that subject. This specification defines the subject_keys parameter, by which an OAuth authorization server conveys one or more subject public signing keys to a resource server. The parameter can be carried as a claim in a JWT access token or as a member of a token introspection response. The resulting key binding is scoped to the authorization server, token subject, resource server audience, and token validity context. This specification does not define a public-key enrollment protocol or the syntax and semantics of the application-layer authorization evidence. It also does not use the OAuth cnf claim, which identifies a proof-of-possession key held by the presenter of a token. |
| | Machine-Readable Coordinated Vulnerability Disclosure Policies |
| |
|
This document defines a JSON format for machine-readable Coordinated Vulnerability Disclosure (CVD) policies. It also defines the proposed CVD-Policy field for discovery through security.txt and requests registration of the application/cvd-policy+json media type. The format complements security.txt and human-readable policy documents. A policy does not prove ownership and does not establish legal authorization to test, legal safe harbor, or the safety of an activity. |
| | Scientific Admissibility Evidence Records for Verifiable Research Provenance |
| |
|
This document describes a portable JSON evidence-record format for representing bounded scientific claims, preregistered procedures, admissibility evaluations, provenance artifacts, lifecycle events, and cryptographic integrity metadata. The format is intended to make research evidence exchangeable and mechanically checkable without treating cryptographic integrity, schema conformance, scientific admissibility, valuation, governance, or truth as equivalent concepts. This document is an individual informational proposal. It does not define a network transport protocol, does not establish scientific truth, and does not assign decision authority to automated systems. |
| | AID-1 Provider-Independent Conformance Requirements and Test-Vector Model |
| |
|
This document defines provider-independent conformance requirements for AID-1. It specifies the execution model for a deterministic machine-readable test-vector corpus, including canonicalization, cryptographic, identity-binding, delegation, authorization, temporal, revocation, replay, attestation, provenance, and integration cases. The conformance corpus contains 69 vectors. Six replay cases are architectural boundary tests, including R5, which requires AID-1 verification to succeed while a downstream D6 scientific- admissibility decision rejects the same evidence. |
| | STB Cryptographic Parameters for Transport Layer Security (TLS) Protocol Version 1.3 |
| |
|
This specification introduces a subset of STB (STandards of Belarus) cryptographic algorithms and defines their use in TLS 1.3. The document is self-contained, i.e., it fully describes the required STB algorithms. It can be used to develop STB-compliant TLS 1.3 implementations without referring to the original STB standards. |
| | Using RPC-with-TLS with DNS-Based Authentication of Named Entities |
| |
|
RPC-with-TLS assumes that DNS-Based Authentication of Named Entities (DANE) is available on platforms where it is deployed, and recommends that a client operating under an opportunistic security policy check for a TLSA record before initiating an association, but does not say how. This document specifies the missing details, so that a TLSA record authenticates an RPC server with no certification authority trust anchor provisioned on the client. It updates RFC 9289. |
| | The BotCentral Card: An Owner-Proven Consent Record for Automated Web Clients |
| |
|
The Robots Exclusion Protocol (RFC 9309) lets a site say which automated clients may fetch its content. It cannot express purpose: fetching a page to answer a person is not the same act as copying it into a model training set or taking an action on the site. It also cannot prove who published the policy. This document defines the BotCentral Card, a JSON record, one per domain, that states which purposes the domain owner consents to ("retrieve", "train", and "act" as separate answers), backed by a proof of domain control placed either in a DNS TXT record or at the well-known URI "/.well-known/botcentral.txt". Cards are written to a registry by authenticated publishers and read by any client over HTTP or the Model Context Protocol. Clients never write cards. A card is permission to be found; it is not a ranking and not a training grant. This document also registers the "botcentral.txt" well-known URI. |
| | The 'agent' Uniform Resource Identifier (URI) Scheme and Cryptographic Attestation Protocol |
| |
|
This document specifies the 'agent' Uniform Resource Identifier (URI) scheme and its associated cryptographic attestation protocol. The 'agent' scheme defines a transport-agnostic, cryptographically verifiable addressing layer for identifying autonomous software agents, binding domain ownership via DNS TXT records, enforcing instruction integrity, and validating attenuated capability delegation tokens. |
| | Open Cloud Mesh |
| |
|
Open Cloud Mesh (OCM) is a server federation protocol that is used to notify a Receiving Party that they have been granted access to some Resource. It has similarities with authorization flows such as OAuth, as well as with social internet protocols such as ActivityPub and email. A core use case of OCM is when a user (e.g., Alice on System A) wishes to share a resource (e.g., a file) with another user (e.g., Bob on System B) without transferring the resource itself or requiring Bob to log in to System A. While this scenario is illustrative, OCM is designed to support a broader range of interactions, including but not limited to file transfers. Open Cloud Mesh handles interactions only up to the point where the Receiving Party is informed of their access to the Resource. Actual Resource access is subsequently managed by other protocols, such as WebDAV. |
| | Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS |
| |
|
This document describes a zero-configuration protocol for dynamically assigning IPv6 multicast addresses that are unique at the link-layer. Applications randomly assign multicast group IDs from a specified range and prevent collisions by using Multicast DNS (mDNS) to publish resource records under a new "eth-addr.arpa" domain. This protocol satisfies all of the criteria listed in RFC 10019. |
| | A YANG Data Model for MPLS-TE Topology |
| |
|
This document defines a YANG data model for representing, retrieving, and manipulating MPLS-TE network topologies. It is based on and augments existing YANG models that describe network and traffic engineering packet network topologies. This document also defines a collection of common YANG data types and groupings specific to MPLS-TE. These common types and groupings are intended to be imported by modules that model MPLS-TE technology- specific configuration and state capabilities. The YANG models defined in this document can also be used for MPLS Transport Profile (MPLS-TP) network topologies. |
| | HTTP Message Signatures for automated traffic |
| |
|
This document describes a protocol for identifying automated traffic using [HTTP-MESSAGE-SIGNATURES]. The goal is to allow automated HTTP clients to cryptographically sign outbound requests, allowing HTTP servers to verify their identity with confidence. It defines the Signature-Agent header field for in-band key discovery, a key directory format based on JWKS, and a well-known URI at which that directory is served. |