| |
|
| |
| | Aggregation Trace Option for In-situ Operations,Administration,and Maintenance (IOAM) |
| |
| | draft-cxx-ippm-ioamaggr-05.txt |
| | Date: |
02/05/2026 |
| | Authors: |
Alexander Clemm, Metzger, Ramon Bister, Severin Dellsperger |
| | Working Group: |
Individual Submissions (none) |
|
The purpose of this memo is to describe a new option type for In-Situ Operations, Administration, and Maintenance (IOAM). This option type allows to aggregate IOAM data along a network path. Aggregates include functions such as the sum, average, minimum, or maximum of a given data parameter. |
| | Identity Trust System |
| |
|
This document defines an *identity trust system*, which is a digital identity authentication system based on a symmetric exchange of authentication messages that does not require federation of authentication domains. The main components are: 1. *Symmetric authentication protocol* - A protocol for the mutual recognition of entities based on a symmetric exchange of authentication messages through the mediation of Identity Providers (IdPs). It builds on and extends the OAuth Authorization Framework RFC6749. 2. *Trustees network* - A IdPs network infrastructure that provides a secure environment for exchanging authentication messages. 3. *Custodian concept* - A special category of IdPs to protect physical identity and personal data. The generic IdP is called "*_trustee_*" and is only responsible for digital authentication, while the special IdP called "*_custodian_*" has the legal right to process the individual's real data and maintain the relationship with the digital identity. The *_custodian_* acts under the direct control of the legal authorities of the individual's country. |
| | Extensions to TLS FATT Process |
| |
|
This document applies only to non-trivial extensions of TLS, which require formal analysis. It proposes the authors specify a threat model and informal security goals in the Security Considerations section, as well as motivation and a protocol diagram in the draft. We also briefly present a few pain points of the team doing the formal analysis which -- we believe -- require refining the process: * Provide protection against FATT-bypass by other TLS-related WGs * Contacting FATT * ML-KEM * Understanding the opposing goals * Response within reasonable time frame |
| | Sovereign Autonomous Trust Protocol (SATP) v1.0 |
| |
|
This document specifies the Sovereign Autonomous Trust Protocol (SATP), a foundational framework for establishing verifiable identity, attribution, and governance for autonomous machines. SATP provides a non-repudiable "Root of Trust" for both digital AI agents and physical autonomous systems. |
| | UDPN: UDP Datagram Privacy Network Protocol Version 1.0 |
| |
|
This document specifies the UDP Datagram Privacy Network (UDPN) protocol, version 1.0. UDPN provides an authenticated, encrypted Layer 3 tunnel over UDP with traffic obfuscation designed to resist deep packet inspection (DPI) and active probing. All packets are wrapped in DTLS 1.2 ApplicationData records. The protocol uses the Noise_NK handshake pattern with X25519 Diffie-Hellman and ChaCha20-Poly1305 AEAD encryption. |
| | Agent Quality Graph (AQG): A Protocol for Evaluating AI Agent Trustworthiness via Delegation Graphs |
| |
|
This document describes the Agent Quality Graph (AQG) protocol, a method for evaluating and ranking AI agent trustworthiness based on delegation transaction graphs. As the number of autonomous AI agents grows rapidly, there is no standardized mechanism for determining which agents reliably complete delegated tasks. AQG applies graph- based ranking algorithms, analogous to web page ranking via hyperlink analysis, to the domain of agent-to-agent delegation. Agents that are frequently delegated to by other highly-ranked agents receive higher trust scores. This document defines the delegation record format, the graph construction process, the scoring algorithm, and the API for querying trust scores. |
| | Why Is the IETF Trust Requiring "All Rights Reserved" When That Term Has Been Superfluous for Over 25 Years? |
| |
|
This document discusses the continued appearance of the phrase “All Rights Reserved” in IETF Trust copyright notices, despite the phrase no longer being required for copyright protection in many jurisdictions. It asks whether the phrase serves a present legal or operational purpose in IETF documents, or whether it should be removed or replaced. |
| |
|
| |
| | MPLS Network Actions for Network Resource Partition Selector |
| |
|
An IETF Network Slice service provides connectivity coupled with a set of network resource commitments and is expressed in terms of one or more connectivity constructs. A Network Resource Partition (NRP) is a collection of resources identified in the underlay network to support IETF Network Slice services. A Slice-Flow Aggregate refers to the set of traffic streams from one or more connectivity constructs belonging to one or more IETF Network Slices that are mapped to a specific NRP and provide the same forwarding treatment. The packets associated with a Slice-Flow Aggregate may carry markings in the packet's network layer header to identify this association and each is referred to as NRP Selector. The NRP Selector is used to map the packet to the associated NRP and provides the corresponding forwarding treatment to the packet. MPLS Network Actions (MNA) technologies are used to indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions. This document specifies options for using MPLS Network Actions (MNAs) to carry the NRP Selector in MPLS packets. |
| | HTTP Live Streaming 2nd Edition |
| |
|
This document obsoletes RFC 8216. It describes a protocol for transferring unbounded streams of multimedia data. It specifies the data format of the files and the actions to be taken by the server (sender) and the clients (receivers) of the streams. It describes version 13 of this protocol. |
| | General Guidance for Implementing Branded Indicators for Message Identification (BIMI) |
| |
|
This document is meant to provide guidance to various entities so that they may implement Brand Indicators for Message Identification (BIMI). This document is a companion to various other BIMI drafts, which should first be consulted. |
| | SVG Tiny Portable/Secure |
| |
|
This document specifies SVG Tiny Portable/Secure (SVG Tiny PS) -- A Scalable Vector Graphics (SVG) profile to be used with documents that are intended for use with more secure requirements, and in some cases, in conjunction with a limited rendering engine. |
| | Fetch and Validation of Verified Mark Certificates |
| |
|
A description of how entities wishing to validate a Verified Mark Certificate (VMC) should retrieve and validate these documents. This document is a companion to BIMI core specification, which should be consulted alongside this document. |
| | BIMI Reporting |
| |
|
To support the utility of Brand Indicators for Message Identification (BIMI), domains publishing BIMI records may find it useful to know when their logos are failing to be displayed as expected. When an entity, for example a mailbox operator, determines whether or not to display the logo identified in the BIMI record, they may encounter errors trying to retrieve the image file. Similarly, the associated evidence document used to validate the logo may fail evaluation. In other cases, the evaluator may decide that despite everything validating, they may rely on local policies that determine validated logos should still not be displayed. This specification defines how BIMI evaluators should report their evaluation outcome back to the publisher within the context of existing Domain-based Message Authentication, Reporting, and Conformance (DMARC) reports. |
| | Brand Indicators for Message Identification (BIMI) |
| |
|
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the Indicator. This document specifies how Domain Owners communicate their desired Indicators through the BIMI Assertion Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs and mail- receiving organizations are free to define their own policies for making use of BIMI data and for Indicator display as they see fit. |
| | Pathway-based Content Steering |
| |
|
This document describes a mechanism for servers to communicate their preferences to clients about utilizing alternate servers for streaming content. These alternate servers are typically distinct Content Delivery Networks or any other servers that offer similar distribution services. The mechanism described in this document is designed to be universally applicable and independent of any specific Content Delivery Protocol. |
| | AS2 Specification Modernization |
| |
|
This document provides an applicability statement (RFC 2026, Section 3.2) describing how to securely exchange structured business data over HTTP. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts (see Section 10.1). Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1" (RFC 3335). This document obsoletes RFC 4130 and stands on its own without reference to AS1 or SMTP, except where required for IANA registry updates. This document also updates IANA registries originally created by RFC 3335 and RFC 4130. |
| | 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. |
| | Agent Attachment Protocol |
| |
|
This document describes the Agent Attachment Protocol (AAP) that enables AI agents to establish attachment to an edge node and derive communication and attachment-related properties. These properties include endpoint identifiers, supported communication mechanisms, and attachment context information that can be exposed to discovery systems. AAP focuses on how agents obtain and maintain attachment state and how attachment-derived properties can be represented in a consistent and interoperable manner. These properties can be used by forwarding functions at edge nodes and by routing or control-plane mechanisms to support communication between agents. |
| | Operating Model Protocol (OMP) Core -- Version 01: Invariant 3 -- Verifiable Delegation Binding |
| |
| | draft-veridom-omp-01.txt |
| | Date: |
01/05/2026 |
| | Authors: |
Tolulope Adebayo, Oluropo Apalowo |
| | Working Group: |
Individual Submissions (none) |
|
This -01 version of the Operating Model Protocol (OMP) Core specification introduces Invariant 3: Verifiable Delegation Binding. OMP version -00 establishes two invariants: (1) deterministic routing and (2) immutable trail. These invariants are necessary but not sufficient for adversarial evidentiary defensibility. A tamper- evident record of an unauthorised decision is still an unauthorised decision. This amendment adds Invariant 3, which closes the gap between record existence and authority validity by requiring that every ASSISTED or ESCALATED routing state bind the Named Accountable Officer field to a verifiable DelegationInstrument object at the moment of decision. When no valid binding can be established, the system sets authority_binding_result to AUTHORITY_UNBOUND -- a sealed, positive evidentiary declaration of the absence, not a silent failure. The routing_state is preserved; execution_permission is set to BLOCKED. Three axes are orthogonal: routing_state, authority_binding_result, and execution_permission. This amendment is additive and non-breaking. All twelve existing OMP profile drafts inherit Invariant 3 from the core specification. AUTONOMOUS routing states are exempt unless a profile-specific Watchtower gate requires binding. |
| | Attestation Reconciliation Protocol |
| |
|
This document specifies the Attestation Reconciliation Protocol (ARP), a deterministic, bilateral, zero-knowledge-capable 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, projects it through register-specific controlled projection functions producing the greatest-lower-bound predicate supported by each addressed register, transmits register-specific ciphertexts, receives partial attestations whose payload discloses only a verdict and an optional divergence axis, aggregates the partial attestations through either homomorphic or hash-linkage aggregation, and seals the resulting reconciliation output against a policy-version hash. An append-only cross-jurisdictional settlement- layer ledger records only hashes, with no 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. |
| | The HTTP FETCH-ONCE Method |
| |
|
This document defines the HTTP FETCH-ONCE method. It allows a client to retrieve a resource and ensures that the resource is immediately deleted or invalidated after retrieval. |
| | Smart Traffic Synchronization Protocol (STSP) Version 1.0 |
| |
|
This document defines the Smart Traffic Synchronization Protocol (STSP), version 1.0 -- an open, extensible protocol for real-time coordination of urban traffic signal infrastructure across distributed networks of intersections. STSP defines a standard message format, node state machine, synchronization algorithm, and inter-node communication model that enables any compliant traffic controller to participate in a federated intelligent network -- regardless of manufacturer, city, or country of deployment. The key contribution of STSP is the definition of the Infrastructure- to-Infrastructure (I2I) coordination layer -- a communication model between traffic signal nodes that does not exist as an open standard in any currently published specification. Existing standards such as SAE J2735 SPaT/MAP and ETSI ITS-G5 address Vehicle-to-Infrastructure (V2I) communication. STSP addresses the orthogonal problem: how nodes coordinate with each other. This document is placed in the public domain under CC BY 4.0 with Open Implementation Clause. Any city, government, company, or individual may implement STSP freely, provided that original authorship is attributed in all implementations, documentation, and derivative works as follows: "Implements STSP, designed by Gustavo Angel Aldana Flores (draft-aldana-stsp)." |
| | Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange |
| |
|
Multi-hop service-to-service and agentic workflows need a standardized way to preserve and validate delegation-path continuity across successive token exchanges. This document defines six actor- chain profiles for OAuth 2.0 Token Exchange [RFC8693]. [RFC8693] permits nested act claims, but prior actors remain informational only and token exchange does not define how a delegation path is preserved and validated across successive exchanges. This document profiles delegation-chain tokens and defines profile- specific processing for multi-hop workflows. The six profiles are: Declared Full Disclosure; Declared Subset Disclosure; Declared Actor- Only Disclosure; Verified Full Disclosure; Verified Subset Disclosure; and Verified Actor-Only Disclosure. These profiles preserve the existing meanings of sub, act, and may_act. They support same-domain and cross-domain delegation and provide different tradeoffs among visible chain-based authorization, cryptographic accountability, auditability, privacy, and long-running workflow support. Plain RFC 8693 impersonation-shaped outputs remain valid RFC 8693 behavior but are outside this profile family. |
| | OAuth Identity and Authorization Chaining Across Domains |
| |
| | draft-ietf-oauth-identity-chaining-11.txt |
| | Date: |
01/05/2026 |
| | Authors: |
Arndt Schwenkschuster, Pieter Kasselman, Kelley Burgin, Michael Jenkins, Brian Campbell, Aaron Parecki |
| | Working Group: |
Web Authorization Protocol (oauth) |
|
This specification defines a mechanism to preserve identity and authorization information across trust domains that use the OAuth 2.0 Framework. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Source for this draft and an issue tracker can be found at https://github.com/oauth-wg/oauth-identity-chaining. |
| | Configuring UDP Sockets for ECN for Common Platforms |
| |
|
Explicit Congestion Notification (ECN) applies to all transport protocols in principle. However, it had limited deployment for UDP until QUIC became widely adopted. As a result, documentation of UDP socket APIs for ECN on various platforms is sparse. This document records the results of experimenting with these APIs in order to get ECN working on UDP for Chromium on Apple, Linux, and Windows platforms. This document provides a snapshot of ECN state of affairs as supported by these platforms at the time of writing. Readers should refer to the documentations of the various platforms for an up-to- date information on the matter. |