| |
|
| |
| | Automated Certificate Management Environment (ACME) Device Attestation Extension |
| |
| | draft-ietf-acme-device-attest-04.txt |
| | Date: |
05/05/2026 |
| | Authors: |
Brandon Weeks, Ganesh Mallaya, Sven Rajala, Corey Bonnell, Ryan Hurst |
| | Working Group: |
Automated Certificate Management Environment (acme) |
|
This document specifies new identifiers and a challenge for the Automated Certificate Management Environment (ACME) protocol which allows validating the identity of a device using attestation. |
| | BGP-LS Extension for Inter-AS Topology Retrieval |
| |
|
This document specifies the procedure 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, as well as three new type-length-values (TLVs) for the BGP-LS Inter-AS Link descriptor. These BGP-LS extensions enable Software-Defined Networking (SDN) controllers to retrieve network topology across inter-AS environments. These extensions and procedures allow network operators to collect inter-domain interconnect information and automatically compute the end-to-end network topology using information provided by the BGP-LS protocol. |
| | VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4 |
| |
|
This document defines an experimental specification for a new type of Outbound Route Filter (ORF), known as the Virtual Private Network (VPN) Prefix ORF. The VPN Prefix ORF mechanism is applicable when VPN routes from different Virtual Routing and Forwarding (VRF) instances are exchanged through a single shared Border Gateway Protocol (BGP) session. The purpose of the VPN Prefix ORF mechanism is to control the overload of VPN routes based on Route Distinguisher (RD), Route Target (RT) and other necessary routing information. This mechanism is applicable to intra-domain scenarios. |
| | Use of Remote Attestation with Certification Signing Requests |
| |
| | draft-ietf-lamps-csr-attestation-25.txt |
| | Date: |
05/05/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. |
| | 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. |
| | YANG Schema Comparison |
| |
|
This document specifies an algorithm for comparing two revisions of a YANG schema to determine the scope of changes, and a list of changes, between the revisions. The output of the algorithm can be used to help select an appropriate revision-label or YANG semantic version number for a new revision. Included is also a YANG module describing the output of this algorithm. |
| | Post-Session Execution Assurance (PSEA): A Security Model for Verifying Authority at the Moment of Action |
| |
|
Modern security architectures assume that trust established at login can safely extend to all subsequent actions within a session. This assumption is fundamentally flawed. Sessions preserve the memory of authentication but not the certainty of authority. Post-Session Execution Assurance (PSEA) is an architectural security model that addresses this gap by requiring cryptographic proof of real human presence, device trust, and execution authority at the exact moment a sensitive action is approved -- independent of prior authentication or session state. This paper defines the PSEA model, its core principles, its distinction from existing security paradigms, and its implications for regulated and mission-critical systems. |
| | YANG deVELpment PrOCEss and maintenance (VELOCE) |
| |
|
This document describes a YANG deVELpment PrOCEss and maintenance (VELOCE) that is more suitable for the development of YANG modules or YANG modules update within the IETF. 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/mjethanandani/veloce. |
| | Discovery of Model Context Protocol Servers via DNS TXT Records |
| |
|
This document defines a DNS-based mechanism for the discovery of Model Context Protocol (MCP) servers, the identity properties of the organisations that operate them, and (new in this revision) the cryptographic identity envelope bound to an individual Sovereign- tier ~handle published under the same zone. Three TXT resource records are defined. The _mcp. record (defined in v01) advertises the presence, endpoint URL, transport protocol, cryptographic identity, and capability profile of an MCP server associated with a domain name. The _org-alter. record (introduced in v02) advertises the canonical organisational identity of the domain operator: legal entity name, registry identifier, founding date, primary regions of operation, and any regulatory frameworks under which the operator is bound to refuse external automated access. The _alter. record (introduced in this revision) publishes an Ed25519-signed identity envelope binding a ~handle to a public key, an IdentityLog Signed Tree Head root, and a revocation commitment. Taken together, the three records provide service discovery, organisational identity bootstrap, and individual identity recognition from a single canonical source: the domain's own DNS zone. This revision additionally requires DNSSEC [RFC4033] validation of envelope responses and a DANE TLSA [RFC6698] pin binding the MCP endpoint's leaf certificate to the published zone. A companion URI scheme (alter:) is registered provisionally with IANA per [RFC7595] for handle dispatch. The mechanism complements HTTPS- based discovery (.well-known/mcp/server-card.json and .well-known/ alter-envelope.json) by providing a lightweight, resolver-cached bootstrap that requires no HTTPS round-trip. The design follows the precedent established by DKIM [RFC6376], SPF [RFC7208], DMARC [RFC7489], MTA-STS [RFC8461], and the existing _mcp. / _org-alter. labels of v01-v02. |
| | The Crovia Seal: A Cryptographic Receipt Format for AI-Generated Output Provenance |
| |
|
This document specifies the Crovia Seal v1, a compact, tamper-evident JSON receipt that may be attached to any output produced by an AI generator (large language model, image model, audio model, or composite system) to record its provenance in a cryptographically verifiable form. A Crovia Seal binds an issuer's identity to the SHA-256 digests of an input/output pair, the identity and parameters of the generator, an emission timestamp, and a per-issuer hash chain, under an Ed25519 signature computed over a strict canonicalization (CSC-1) of the receipt with explicit domain separation. Optional fields permit transparency-log inclusion proofs and witness co- signatures. The Seal is designed for offline verification and for inclusion in third-party transparency logs and standards-based revocation infrastructure. |
| | Extended Diagnostic Notation (EDN) Use with Transport Layer Security (TLS) Presentation Language (PL) Objects |
| |
|
Extended Diagnostic Notation was designed as a superset of JSON to represent CBOR instance documents in human-readable format. This document describes how it can be used to represent instances encoded using the TLS Presentation Language. |
| | SFC: Self-Describing Resilient Container File Format |
| |
|
This document specifies the Self-Describing Resilient Container (SFC) file format, a general-purpose binary container format designed for reliable transmission of arbitrary file data over unreliable, bandwidth-constrained, or asynchronous channels including physical media hand-carry, multi-session transfers, and heterogeneous delivery paths. SFC encapsulates any file or directory tree into independently addressable, self-identifying chunks. Each chunk carries sufficient metadata to identify itself and verify its own integrity in isolation. Full reconstruction additionally requires a Global Header; this distinction is made explicit throughout. This document defines a Core specification and five optional Profiles: Image (SFC/P1), Split Transport (SFC/P2), HTTP Hints (SFC/P3), Preprocessing (SFC/P4), and Directory (SFC/P5). |
| | OAuth 2.0 Client Instance Assertions using Actor Tokens |
| |
|
This specification defines a profile for representing OAuth 2.0 client instance identity to an authorization server. It registers a new actor_token_type, urn:ietf:params:oauth:token-type:client- instance-jwt, that carries the instance identity as a signed JWT presented via the actor_token parameter defined by OAuth 2.0 Token Exchange (RFC 8693). To support presentation outside token exchange, this specification also permits actor_token and actor_token_type on selected additional grant types. The profile does not introduce a new client_instance identifier in protocol messages. Instead, it defines client metadata parameters (applicable to clients identified by a Client ID Metadata Document (CIMD) or registered via OAuth Dynamic Client Registration (RFC 7591)) that let a client_id identify a logical client whose concrete runtime instances are authenticated by one or more trusted instance issuers (for example, workload identity systems). The Authorization Server validates the instance assertion and represents the instance either as an act claim, when another principal is present (e.g., a user delegating to the instance), or as the access token's sub, when the instance itself is the principal (e.g., a client credentials grant). The issued access token is sender-constrained to a key the instance possesses. |
| | Protocol 427: An HTTP Budget-Required Status Code with Post-Quantum-Signed Budget Attestations |
| |
|
Internet-deployed software agents are increasingly authorized to spend money, consume metered services, or commit other resources on behalf of human or organizational principals. Existing HTTP authentication and payment patterns conflate two orthogonal concerns: whether the requester holds a credential at all (the "401" axis), and whether the requester has been authorized to spend a specific amount through a specific settlement rail (the "budget" axis). This document defines the 427 (Budget Required) HTTP status code, the "Budget" HTTP authentication scheme, a CBOR-encoded Budget- Attestation envelope signed with a post-quantum digital signature algorithm, and a version-negotiation mechanism using the existing 426 (Upgrade Required) status code. The mandatory primary signature uses ML-DSA-87 (FIPS 204). An optional "rail-keyed" signature, computed with a hash-based stateless signature algorithm, provides cryptographic diversification for settlement-rail submissions. |
| | RadSec: RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) |
| |
|
This document defines transport profiles for running RADIUS over Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), allowing the secure and reliable transport of RADIUS messages. RADIUS/TLS and RADIUS/DTLS are collectively referred to as RadSec. This document obsoletes RFC6614 and RFC7360, which specified experimental versions of RADIUS over TLS and DTLS. |
| | Remote Attestation with Multiple Verifiers |
| |
|
IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details. |
| | TCP RST Diagnostic Payload |
| |
|
This document specifies an experimental diagnostic payload format returned in TCP RST segments. Such payloads are used to share with an endpoint the reasons for which a TCP connection has been reset. Sharing this information is meant to ease diagnostic and troubleshooting. This specification builds on provisions that are already present in RFC 9293 "Transmission Control Protocol (TCP)". As such, this document does not require any change to RFC 9293. |
| | Workload Authentication Using Mutual TLS |
| |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones to complex multi-service, multi-cloud, multi-tenant deployments. This document profiles a workload authentication based on X.509 workload identity certificates using mutual TLS (mTLS). |
| | WIMSE Workload Credentials |
| |
| | draft-ietf-wimse-workload-creds-01.txt |
| | Date: |
05/05/2026 |
| | Authors: |
Brian Campbell, Joseph Salowey, Arndt Schwenkschuster, Yaron Sheffer, Yaroslav Rosomakho |
| | Working Group: |
Workload Identity in Multi System Environments (wimse) |
|
The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the credentials that workloads use to represent their identity. They can be used in various protocols to authenticate workloads to each other. To use these credentials, workloads must provide proof of possession of the associated private key material, which is covered in other documents. This document focuses on the credentials alone, independent of the proof-of- possession mechanism. |
| |
|
| |
| | 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 measurement. 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 IOAM data fields. |
| | Encrypted ESP Echo Protocol |
| |
|
This document defines the Encrypted ESP Echo Function, a mechanism to assess the reachability of IP Security (IPsec) network paths using Encapsulating Security Payload (ESP) packets. It detects end-to-end path status by exchanging only encrypted ESP packets between IPsec peers. The Encrypted Echo message can either use existing congestion control payloads from RFC9347 or a new message format defined here, with an option to specify a preferred return path when there is more than one pair of IPsec SAs between the same set of IPsec peers. A peer can announce support using a new IKEv2 Status Notification ENCRYPTED_PING_SUPPORTED. |
| | KEM-based Authentication for TLS 1.3 |
| |
|
This document gives a construction for a Key Encapsulation Mechanism (KEM)-based authentication mechanism in TLS 1.3. This proposal authenticates peers via a key exchange protocol, using their long- term (KEM) public keys. |
| | KEM-based pre-shared-key handshakes for TLS 1.3 |
| |
|
This document gives a construction in which (long-term) KEM public keys are used in the place of TLS PSK keys, avoiding concerns that may affect systems that use symmetric-key-based PSK, such as requiring key diversification and protection of symmetric-keys' confidentiality. This mechanism is inspired by AuthKEM (and could use AuthKEM certificate public keys for resumption), but can be independently implemented. |
| | Root CA Certificate Rekeying in the Scenario of Post Quantum Migration |
| |
|
In the public key infrastructures (PKIs), root certification authority (CA) certificate rekeying is crucial to guarantee business continuity. Two approaches are given in [RFC4210] for entities which are belonging to different generations to verify each other's certificate chain. However, these approaches rely on the assumption that the old entities can be updated. In this draft, we propose a One-way Link Certificate based solution such that old entities are transparent to root CA certificate rekeying. Namely, during the overlapping lifetime of two root CA certificates, without any update in old entities, old and new entities can verify each other's certificate chain smoothly. Furthermore, the proposed solution works in both traditional PKIs, and post-quantum (PQ) PKIs, where the certificate can be pure PQ or hybrid ones. |
| | Reverso for the QUIC protocol |
| |
|
This document describes a QUIC version re-designing the layout of the QUIC protocol to avoid memory fragmentation at the receiver and allows implementers seeking a more efficient implementation to have the option to implement contiguous zero-copy at the receiver. This document describes the change from QUIC v1 required in packet formats, variable-length integers and frame formats. Everything else from QUIC v1 described in [RFC9000] is untouched. |
| | Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Reflecting STAMP Packet MPLS Extension Headers |
| |
|
The Simple Two-Way Active Measurement Protocol (STAMP) and its optional extensions can be used for Edge-To-Edge (E2E) active measurement. 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 MPLS extension headers, including MPLS Network Action Sub-Stacks and Post-Stack Header, for HBH and E2E active measurements, for example, using IOAM data fields. |
| | An EAT Profile for Trustworthy Device Assignment |
| |
|
In confidential computing, device assignment (DA) is the method by which a device (e.g., network adapter, GPU), whether on-chip or behind a PCIe Root Port, is assigned to a Trusted Virtual Machine (TVM). For the TVM to trust an assigned device, the device must provide the TVM with attestation Evidence confirming its identity and the state of its firmware and configuration. Since Evidence claims can be processed by 3rd party entities (e.g., Verifiers, Relying Parties) external to the TVM, there is a need to standardize the representation of DA-related information in Evidence to ensure interoperability. This document defines an attestation Evidence format for DA as an EAT (Entity Attestation Token) profile. |
| | ICMP Error Handling in SRv6 based VPN Networks |
| |
|
The document specifies procedures for handling ICMP error in SRv6-based Virtual Private Network (VPN). |
| | vCon Lifecycle Management using SCITT |
| |
|
This document proposes using the SCITT (Supply Chain, Integrity, Transparency, and Trust) protocol to record, communicate and coordinate the lifecycle of Virtual Conversations (vCons), which are standardized containers for conversational data like call recordings, transcripts, and chat logs. While vCons enable capturing and sharing conversation details for AI analysis and business purposes, they lack mechanisms for proving compliance with privacy regulations and consent management. SCITT addresses this by providing an immutable, append-only transparency ledger that records key lifecycle events—from vCon creation and consent management to call recording, as well as data processing and deletion—enabling entities to demonstrate regulatory compliance and maintain trust across distributed systems. The framework specifically addresses consent management challenges under regulations like GDPR and CCPA, where consent can be revoked at any time, requiring coordinated deletion across all parties that have received the vCon. By combining vCons with SCITT, organizations can build scalable, transparent governance systems that protect personal data rights while enabling responsible use of conversational data for AI and business applications. |
| | vCon World Transcription Format Extension |
| |
|
This document defines the World Transcription Format (WTF) extension for Virtualized Conversations (vCon). The WTF extension provides a standardized analysis framework for representing speech-to-text transcription data from multiple providers within vCon containers. This extension defines a comprehensive analysis format that enables consistent transcription processing, quality assessment, and interoperability across different transcription services while preserving provider-specific features through extensible fields. The WTF extension is designed as a Compatible Extension that introduces a new analysis type for transcription data without altering existing vCon semantics, ensuring backward compatibility with existing vCon implementations. |
| | Properties and Use Cases for Integrating Remote Attestation with Secure Channel Protocols |
| |
| | draft-mihalcea-seat-use-cases-02.txt |
| | Date: |
04/05/2026 |
| | Authors: |
Ionut Mihalcea, Muhammad Sardar, Thomas Fossati, Tirumaleswar Reddy.K, Yuning Jiang, Meiling Chen |
| | Working Group: |
Individual Submissions (none) |
|
This document outlines desirable properties 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 properties 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. |
| | SOCKS Protocol Version 4 |
| |
|
This document describes SOCKS version 4, a protocol designed to facilitate TCP proxy services across a network firewall. SOCKS operates at the session layer, providing application users with transparent access to network services on the other side of the firewall. It is application-protocol independent, allowing it to support a wide range of services, including those utilizing encryption, while maintaining minimum processing overhead by simply relaying data after initial access control checks. The protocol defines two primary operations: CONNECT for establishing outbound connections to an application server, and BIND for preparing for and accepting inbound connections initiated by an application server. |
| | SOCKS Protocol Version 4A |
| |
|
This document specifies SOCKS Protocol Version 4A, an independent protocol originated from the SOCKS Protocol Version 4. This protocol allows SOCKS clients to delegate domain name resolution to the SOCKS server. This is particularly useful in environments where the client host cannot resolve the destination host's domain name due to restrictive network policies or lack of DNS access. 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/4socks/socks4. |
| | Judgment Event Protocol (JEP) |
| |
|
This document defines the Judgment Event Protocol (JEP), a neutral verifiable event format for decision-related operations in human, organizational, software, and autonomous agent systems. JEP specifies four immutable event verbs: Judgment (J), Delegation (D), Termination (T), and Verification (V). It defines a signed JSON event structure, anti-replay fields, detached JSON Web Signature (JWS) verification over JSON Canonicalization Scheme (JCS) canonicalized payloads, event hash and reference semantics, validation levels, structured validation results, failure codes, extension handling, trust-profile interfaces, and determinability boundaries. JEP is intended to provide a global protocol-level interoperability layer for verifiable decision event records. JEP-Core does not define legal liability, authorization validity, regulatory compliance, organizational trust decisions, global identity, global truth, or mandatory support for any specific credential, identity, AI platform, agent framework, or blockchain system. --- |
| | Delegation Receipt Protocol for AI Agent Authorization |
| |
|
This document defines the Delegation Receipt Protocol (DRP), a cryptographic authorization primitive for AI agent deployments. Before any agent action executes, the authorizing user signs an Authorization Object containing scope boundaries, time window, operator instruction hash, and model state commitment. This signed receipt is published to an append-only log before the agent runtime receives control. The protocol removes the operator as a trusted third party by making the user's private key the sole signing authority over the delegation record. |
| | EST Lightweight Operations |
| |
|
This document defines eight new operations for the Enrollment over Secure Transport (EST) protocol specified in RFC 7030: ucacaps, ucacert, ucacerts, ucrlinfo, ucrl, usimpleenroll, usimplereenroll, and userverkeygen. These operations deliver PKI objects, including CA certificates, certificate chains, CRLs, and enrolled certificates, as Base64-encoded DER or PEM, without the CMS encapsulation used by the corresponding EST operations in RFC 7030. The ucacaps operation enables EST clients to discover which operations the EST server supports. Eliminating the CMS wrapper for these responses reduces code size and parsing complexity. This document updates RFC 7030. |
| | JEP Profiles and Interoperability |
| |
|
This document defines optional trust profiles and interoperability bindings for the Judgment Event Protocol (JEP). JEP-Core defines the neutral event protocol. This document defines how actor identifiers, keys, credentials, authorization context, attestations, archival systems, and chain systems can be bound to JEP events without changing JEP-Core semantics. The profiles in this document are optional. A JEP-Core implementation MUST NOT require support for DID, VC, X.509, OAuth, RATS, blockchain anchoring, HJS, JAC, or any specific AI platform or agent framework. --- Companion Drafts This draft depends on draft-wang-jep-judgment-event-protocol-06. Conformance classes, schemas, test vectors, and reference-validator behavior are defined in draft-wang-jep-conformance-00. |
| | JEP Conformance and Test Suite |
| |
|
This document defines conformance classes, validation-result structure, schema requirements, test-vector categories, reference-validator behavior, and implementation testing guidance for the Judgment Event Protocol (JEP). It is a companion to draft-wang-jep-judgment-event- protocol-06. The purpose of this document is to make JEP implementations testable, interoperable, and auditable across languages, platforms, identity systems, and deployment profiles. --- |
| | Compliance Profile of Signed Action Receipts for AI Agents |
| |
|
This document defines a compliance profile of the signed action receipt format used by AI agents to record machine-readable evidence of access-control decisions. The profile binds receipt fields to the operational record-keeping obligations of Articles 12 and 26 of Regulation (EU) 2024/1689 (the EU AI Act) and to the ICT-related incident management requirements of Article 17 of Regulation (EU) 2022/2554 (DORA). It does not redefine the wire format, the canonicalization rule, or the signing algorithms of the underlying receipt format. It tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, mandates two-anchor timestamping, and adds two extension fields. |
| | MCP Aggregation Protocol (MCP-AX): Hierarchical Tool Namespace Delegation for Model Context Protocol Servers |
| |
|
This document specifies MCP-AX, an aggregation protocol for Model Context Protocol (MCP) servers. MCP-AX enables hierarchical composition of tool namespaces across heterogeneous networks of MCP servers, from cloud services to resource-constrained embedded devices. The protocol defines a master-subagent architecture directly inspired by the AgentX protocol (RFC 2741), adapted for the tool/resource model of MCP rather than the OID/MIB model of SNMP. MCP-AX introduces recursive namespace delegation, capability-aware routing, transport bridging for constrained nodes, and irreversibility-gated tool dispatch suitable for autonomous and semi- autonomous AI agent systems. |
| | Export of GTP-U Information in IP Flow Information Export (IPFIX) |
| |
| | draft-ietf-opsawg-ipfix-gtpu-09.txt |
| | Date: |
04/05/2026 |
| | Authors: |
Dan Voyer, Sriram Gopalakrishnan, Thomas Graf, Vyasraj Satyanarayana, Cristian Staicu |
| | Working Group: |
Operations and Management Area Working Group (opsawg) |
|
This document introduces IP Flow Information Export (IPFIX) Information Elements to report information contained in the Generic Packet Radio Service Tunneling Protocol(GTP) User Plane header such as Tunnel Endpoint Identifier, and data contained in its session container extension header. |
| | PIM Flooding Mechanism and Source Discovery Enhancements |
| |
|
The Protocol Independent Multicast (PIM) Flooding Mechanism (PFM) provides a generic hop-by-hop message exchange framework for distributing multicast information among PIM routers. Existing PFM procedures enable efficient source discovery without reliance on Rendezvous Points, shared trees, or initial data registers. This document specifies enhancements to PFM forwarding behavior to improve efficiency and scalability. In particular, it introduces mechanisms to reduce redundant message transmission over multiple parallel links and extends the encoding of multicast information through additional Type-Length-Value (TLV) structures and sub-TLVs to convey richer flow-related data. These enhancements optimize control-plane overhead while preserving interoperability with existing PFM procedures, enabling more efficient dissemination of multicast state in PIM networks. |
| | Batched Token Issuance Protocol |
| |
|
This document specifies two variants of the Privacy Pass issuance protocol that allow for batched issuance of tokens. These allow clients to request more than one token at a time and for issuers to issue more than one token at a time. |
| | RPL DIS Modifications and Applications |
| |
|
This document augments [RFC6550] by defining new DODAG Information Solicitation (DIS) flags and options that enable a RPL node to exert finer control over how neighboring RPL routers respond to its DIO solicitations. In addition, this document describes several use cases that motivate these DIS extensions and illustrate scenarios in which enhanced control of DIO responses improves network efficiency, responsiveness, and robustness. |
| | Updates to SFrame Cipher Suites Registry |
| |
|
This document addresses two omissions in the Secure Frames (SFrame) protocol specification. First, the definition of the IANA registry for SFrame ciphersuites omits several important fields. This document updates the IANA registry specified by RFC 9605 and requests that IANA add those fields, defining the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level. |
| | 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. |
| | Privacy Primer for vCon Developers |
| |
|
This document serves as a primer for technical professionals involved in the processing (which includes collecting, using, disclosure, and erasure) of personal data, including not only basic identifiers like name, age, and address, but also sensitive data contained in communications, including biometrics obtained from audio and video recordings. It outlines key concepts in data privacy and communications privacy, addressing the ethical and legal considerations surrounding the collection, processing, sharing, access, retention, and disclosure of individuals’ data. The document covers fundamental privacy principles, defines important roles in data processing, and explains individuals’ rights regarding their personal information. It also discusses the scope of protected personal information, including sensitive data categories, and explores techniques like data aggregation and anonymization. While referencing existing IETF work on privacy in Internet communications, this draft extends beyond to address individuals' data privacy in relation to organizations handling such data. The goal is to provide a comprehensive overview of privacy considerations, aligning with fair information practices and current regulatory frameworks, to guide professionals in implementing privacy-respecting data management practices. |
| |
|
| |
| | Matroska Media Container Tag Specifications |
| |
| | draft-ietf-cellar-tags-25.txt |
| | Date: |
03/05/2026 |
| | Authors: |
Steve Lhomme, Moritz Bunkus, Dave Rice |
| | Working Group: |
Codec Encoding for LossLess Archiving and Realtime transmission (cellar) |
|
Matroska is a multimedia container format. It can store timestamped multimedia data but also chapters and tags. The Tag elements add important metadata to identify and classify the information found in a Matroska Segment. This document defines the Matroska multimedia container tags, namely the tag names and their respective semantic meaning. |
| | Authorized update to MUD URLs |
| |
|
This document provides a way for an RFC8520 Manufacturer Usage Description (MUD) definitions to declare what are acceptable replacement MUD URLs for a device. RFCEDITOR-please-remove: this document is being worked on at: https://github.com/mcr/iot-mud-acceptable-urls |
| | JSON Meta Application Protocol (JMAP) Email Delivery Push Notifications |
| |
|
This document specifies an extension to the JSON Meta Application Protocol (JMAP) that allows clients to receive an object via the JMAP push channel whenever a new email is delivered that matches a client- defined filter. The object can also include properties from the email, to allow a user notification to be displayed without having to make a further network request. |
| | YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm |
| |
|
This document defines a YANG data model to support OSPF Application- Specific Link Attributes and Flexible Algorithm. It also specifies the initial version of IANA-maintained YANG modules for IGP Algorithm Types, IGP Metric-Types, and IGP Link Attribute Applications. |
| | 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. |
| | MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents |
| |
|
This document specifies MARC, a vendor-neutral control and uncertainty-disclosure profile for generative models and agentic systems. MARC defines a small set of interoperable control metadata, separates pre-decision capability assessment from post-decision answer confidence, identifies the target of confidence disclosures, and defines a bounded primary action set for answering, clarification, retrieval, tool use, additional deliberation, abstention, and escalation. MARC does not standardize model internals, training methods, agent discovery, authorization, transport, tool schemas, provenance systems, or claims about machine cognition. Instead, it defines externally observable semantics that can be implemented by model providers, orchestration layers, evaluation harnesses, API gateways, and user-facing systems. The goal is to reduce silent failure, unnecessary externalization, and misleading uncertainty communication while improving auditability and interoperability. |
| | Sovereign Verification & Trust Protocol (SVTP) v1.0 |
| |
|
This document specifies the Sovereign Verification & Trust Protocol (SVTP), a foundational framework for establishing verifiable identity, attribution, and governance for autonomous machines. SVTP provides a non-repudiable "Root of Trust" for both digital AI agents and physical autonomous systems (e.g., industrial robotics, autonomous vehicles). By defining the SVTP-DID (did:svtp) and the Protocol Seal mechanism, this standard enables secure machine-to-machine (M2M) interaction, automated compliance with NIST-800-218, and institutional-grade liability containment in the machine economy. |
| | Update to Automatic Bandwidth Adjustment Procedure of Stateful PCE for MPLS-TE and SR-TE LSPs |
| |
|
The Stateful PCE extensions allow Stateful control of Traffic Engineering (TE) LSPs using PCEP for RSVP-TE and Segment Routing (SR) (for both MPLS and IPv6 Data planes) for both PCE-Initiated and PCC- Initiated LSPs. Extensions to the Path Computation Element Communication Protocol (PCEP) for MPLS-TE Label Switched Path (LSP) Automatic Bandwidth Adjustments with Stateful PCE are defined in RFC 8733. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for each of the attributes. The sub-TLVs are included if there is a change since the last information sent in the PCEP message. However, it lacks a mechanism to remove an attribute identified by the sub-TLV explicitly. This document updates RFC 8733 by defining the behaviour to remove an attribute explicitly. In addition, this updates allow applying this PCEP extensions to SR-TE LSPs (for both MPLS and IPv6 Data planes), in addition to MPLS-TE LSPs. |
| | A well-known URI for publishing service parameters |
| |
| | draft-ietf-tls-wkech-12.txt |
| | Date: |
03/05/2026 |
| | Authors: |
Stephen Farrell, Rich Salz, Benjamin Schwartz |
| | Working Group: |
Transport Layer Security (tls) |
|
We define a well-known URI at which an HTTP origin can inform an authoritative DNS server, or other interested parties, about its Service Bindings. Service binding data can include Encrypted ClientHello (ECH) configurations, that may change frequently. This allows the HTTP origin, in collaboration with DNS infrastructure elements, to publish and rotate its own ECH keys. Other service binding data such as information about TLS supported groups is unlikely to change quickly, but the HTTP origin is much more likely to have accurate information when changes do occur. Service data published via this mechanism is typically available via an HTTPS or SVCB resource record. |
| |
|
| |
| | 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. |