IETF Internet-Drafts & RFCs — Daily Digest

Defines the Agent Registry Protocol (ARPA), an HTTP/JSON protocol for publishing and resolving information about software agents: their operational deployments, typed relationships, bounded delegated authority, lifecycle status and associated evidence. ARPA cleanly separates identification, authentication, authorization, assurance and lifecycle state, and stresses that registration, authentication, capability advertisement or proof verification do not by themselves confer authority to act. The design targets deterministic fail-safe behavior when authority information is revoked, suspended, expired, stale, conflicting, unavailable or unverifiable.

Addresses long-term verifiability of agent delegation records across the post-quantum transition. It argues that a delegation record kept as evidence must be anchored in trusted time and re-anchored before its protecting algorithms weaken, noting that an RFC 3161 timestamp is itself a signature a quantum-capable adversary could forge with any date. The draft states requirements agent identity mechanisms should meet to stay sound: the algorithms binding each delegation hop to its trust anchor must be visible and retained; trust anchors must migrate before the credentials under them; every retained record must be anchored with post-quantum anchoring from a stated transition date and maintained by renewal; and evidence credentials must be signed post-quantum from that same date. It flags that delegation chains propagate the weakest algorithm and cross organizational boundaries.

Specifies procedures for distributing BGP-LS key parameters for inter-domain links between two Autonomous Systems. It defines a new BGP-LS NLRI type for an Inter-AS Link plus three new TLV descriptors for it. These extensions let operators collect inter-domain interconnect information and automatically compute the inter-AS topology from data carried by BGP-LS.

Introduces new IPFIX Information Elements that identify the Segment Routing Path Segment Identifier (PSID), enabling SR path identification for both SR-MPLS and SRv6 in exported flow records.

Describes a scalable solution for realizing network slicing in IP/MPLS networks. It lets a service provider partition one physical network into multiple logical networks of varying size, structure and function, each dedicated to specific services or customers, while keeping slice elasticity in resource allocation. Compliant domains and nodes provide forwarding treatment (scheduling, drop policy, resource usage) based on slice identifiers, supporting multiple services over a single physical network.

Defines a client-side, out-of-band process that lets OAuth clients use the authorization code grant without being able to host the redirect_uri themselves. A simple helper page produces a single copyable value that the resource owner pastes into the waiting client application, completing the flow.

By its name, this IVY working group draft (revision -05) probably concerns an entitlement inventory model for the IVY (inventory/asset) work area, likely describing how entitlements are represented and inventoried. The official abstract page could not be retrieved on this run, so this description is approximate and will be grounded from the abstract on the next run.

By its name (revision -02), this individual draft named 'aer1' is of undetermined scope; the abbreviation is not self-explanatory. The official abstract page could not be retrieved on this run, so this description is approximate and will be grounded on the next run.

Describes the BBS digital signature scheme, a secure multi-message signature protocol that supports proving knowledge of a signature while selectively disclosing any subset of the signed messages. It signs multiple messages while producing a single constant-size signature, and lets the holder create zero-knowledge proofs of knowledge of a signature that reveal nothing about undisclosed messages or the signature itself, while guaranteeing authenticity and integrity of the disclosed messages.

Describes FALCON (FAst Latency and COngestion Notification), a method that lets a traffic source learn the queuing delay and congestion status of a path with a notification lag no greater than the one-way propagation delay from the congested node back to the source. It combines in-network telemetry and source routing: a forward packet records its path and the receiver returns a high-priority packet source-routed along the exact reverse, collecting forward-direction queue state. With hop-by-hop flow control (e.g. PFC) it can also gather buffer state so the source acts before throttling and can distinguish the root of congestion. It targets data-center and single-domain WAN networks and is designed for IOAM and SRv6.

Specifies vaara.receipt/v1, a signed, independently recomputable record that binds a decision about an autonomous action to the evidence it was made on, and optionally to external timestamp anchors. It uses JSON Canonicalization (JCS) so any third party can recompute digests and verify signatures without the issuer. Trust is root-agnostic: verifiable with or without a hardware TEE and re-expressible as an IETF RATS Entity Attestation Result. Downstream specs pin to a version and add their own evidence schema without redefining the envelope; receipts are recomputable from public conformance vectors with standalone checkers.

Building on RFC 8949 (CBOR), this document normatively defines a 'preferred-plus' serialization suitable for most CBOR-based protocols, so designers and implementers need not specify serialization details themselves, and also defines a deterministic serialization; both are largely compatible with widely deployed practice. It updates RFC 8949 with a rule limiting how new tag definitions affect the CBOR data model, and clarifies bignums, floating-point NaN handling, determinism and byte-string wrapping.

Defines a Platform Ownership Endorsement (POE): a signed statement that a specific Intel confidential-computing platform instance, identified by its Platform Instance Identity (PIID), belongs to a named owner. POEs let a Verifier bind the attested hardware identity of an Intel SGX or TDX platform to an operational owner (e.g. a cloud provider) during appraisal, giving a Relying Party a trustworthy owner identity without trusting the attestation service or any in-band platform claim. POE is defined as a profile of the IETF CoRIM data model.

Specifies the Agent Passport System (APS), a protocol for representing and evaluating the authority exercised by AI agents. APS separates agent identity, represented principal, delegated authority, policy approval, admission to dispatch, observed results and external effects, defining cryptographic identity and principal records, monotonic delegation, revocation and authority-lifecycle semantics, deterministic action/decision references, signed governed-action records, verifier outcomes and evidence resolution. Requirements split into APS Core (always carried) and opt-in Candidate features. A valid signature, receipt or delegation chain is not treated as proof of external truth or of the absence of an out-of-band execution path.

Defines an optional claims profile of OAuth 2.0 Attestation-Based Client Authentication. When selected, it requires an attester-assigned client instance identifier, scoped by default to the validating server, that stays stable across verified key changes, and adds continuity and privacy rules for that identifier. Conveying instance context in tokens and introspection responses stays optional; authentication and proof methods follow the base specification.

OAuth 2.0 Attestation-Based Client Authentication requires an authorization server to trust the attester making statements about a client instance but does not define how a client identifies the attesters authorized to attest for it. This specification adds a client metadata parameter for naming endorsed attesters and their verification key locations, and establishes how authorization servers validate endorsements while retaining control over trust decisions, without introducing new authentication credentials or methods.

By its name, this CATS-related individual draft (new -00) probably describes service characteristics for agent services in the context of Computing-Aware Traffic Steering (CATS), likely defining metrics or attributes used to steer traffic toward agent service instances. The official abstract page could not be retrieved on this run, so this description is approximate and will be grounded on the next run.

BGP Flow Specification v1 (RFC 8955/8956/9117) distributes traffic filter policy via BGP; deployment surfaced issues that FSv2 addresses, using a distinct NLRI to separate the two versions. Based on early implementation feedback that breaking FSv2 into a progression of documents would aid deployment, this document specifies the basic FSv2 NLRI with user ordering of filters, added to FSv1 IP filters and FSv2 actions.

Defines how multiple Security Event Tokens (SETs) can be delivered to a recipient using HTTP POST over TLS. The SETs are carried in the body of an HTTP POST to a recipient-operated endpoint, and the recipient signals successful or failed transmission via the HTTP response.

Defines IPFIX Information Elements and export profiles for QUIC packet, header, frame, aggregate and connection observations. It distinguishes wire-visible information from values requiring version-specific parsing, packet-protection processing or endpoint state, and reports observation provenance, processing outcome and export completeness.

Notes that advertising capabilities in Hello packets helps support optional features when establishing and maintaining adjacencies. The document defines a new TLV carried in Hellos to advertise such capabilities.

Describes procedures for performance measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP, RFC 8762) with its optional extensions (RFC 8972, RFC 9503). The procedures apply to SR-MPLS paths, including segment lists of SR-MPLS policies, SR-MPLS IGP best paths and Flex-Algo paths, as well as Layer-3 and Layer-2 services carried over SR-MPLS paths.

The SRv6 counterpart to the SR-MPLS performance-measurement work: it describes procedures for performance measurement in SRv6 networks using STAMP (RFC 8762) with its optional extensions (RFC 8972, RFC 9503). The procedures apply to links and SRv6 paths, including segment lists of SRv6 policies, SRv6 IGP best paths and Flex-Algo paths, plus Layer-3 and Layer-2 services carried over SRv6 paths.

Building on RFC 5837 (extending ICMP for interface and next-hop identification), this document introduces a similar ICMP extension for node identification. It lets a node provide a unique IP address and/or a textual name in cases where individual interfaces may lack a unique IP address, for example IPv6-only deployments where all next-hops are IPv6 even for IPv4 routes, improving diagnostics such as traceroute.

Describes a mechanism to reduce post-quantum transmission overhead when using Merkle Tree Ladders (MTL) in DNSSEC. Called SigTag and enabled via EDNS(0), it lets a client indicate knowledge of a specific MTL ladder so the DNS server can omit the full underlying signature from its response, reducing message payload.

Defines the Authorization Evidence Chain (EP-AEC): a transport-agnostic composition object and fail-closed evaluation algorithm for heterogeneous identity, delegation, policy, permit, approval, transparency, capability and execution artifacts produced by consequential agent actions. It keeps native cryptographic verification separate from relying-party acceptance, enforces exact material-action matching and evaluates a relying-party-pinned evidence requirement, producing SATISFIED or UNSATISFIED plus a replayable evaluation record. SATISFIED means only that presented evidence met the named requirement at the stated time; it is not a universal authorization decision or proof of execution.

Defines a transport-neutral Authorization Evidence Challenge data model, bound to a relying party's exact action, for when a relying party refuses a consequential agent action because evidence is missing, stale, unverified, not accepted or not bound. The challenge identifies outstanding evidence requirements, freshness/status constraints, acceptable presentation profiles and retry state, while authorizing nothing. It also defines an HTTP challenge-response carrier using 403 Forbidden and RFC 9457 Problem Details, optional retry timing with per-challenge jitter mapped to Retry-After, bounded replay state with fail-closed behavior, and an optional evaluation-lineage profile carrying an authenticated issuer statement about one evaluation.

Describes how to apply the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) together with Merkle Tree Ladders (MTL) as a conservative post-quantum algorithm for DNSSEC, referred to as the ML-DSA-MTL signature scheme. It specifies how to represent ML-DSA-MTL keys and signatures in DNSSEC, specifically for ML-DSA-44 with SHAKE-128.

Defines P10, a third-party-verifiable binding for NotDemonstrated(reason=underdetermined). A conforming receipt carries two canonical witness worlds compatible with the same closed evidence set that produce different values for the same frozen claim. The witness result is checked against committed profile semantics and bound into a SCITT Transparent Statement containing an in-toto Statement v1 predicate. The result establishes underdetermination only relative to the declared profile and does not identify the actual world or establish either claim value as true.

Defines AAuth Events, an event subscription and delivery mechanism for agents operating under the AAuth Protocol. It specifies the subscribe token agents use to register callbacks with resources, the event token resources deliver when events fire, and the delivery path through the Agent Provider. It lets agents receive asynchronous notifications without a public endpoint, using the cryptographic identity established by the AAuth Protocol.

Defines AAuth Budgets, an extension to the AAuth Protocol that carries a spending ceiling from a person server to a resource. A budget is a ceiling on what an agent may consume at one resource, denominated in a unit the resource declares, carried as a claim in the auth token and enforced by the resource. Budgets parallel scope: the agent asks, the resource offers, person and access servers may narrow, and the auth token carries what was granted. The extension adds budget and budget_consumed claims, budget_units and a usage_endpoint to resource metadata, and an AAuth-Budget response header reporting a request's cost and remainder.

Defines AAuth Rich Resource Requests (R3), an extension enabling structured, vocabulary-based authorization for resource access. Resources publish content-addressed R3 authorization documents and advertise vocabularies describing their operations; agents request access using those vocabularies, and auth tokens carry granted operations in the same format so resources enforce directly from the token. Resources annotate operations with the credential each requires so an agent can plan before its first call. R3 provides human-displayable context for consent and content-addressed audit provenance via an r3_s256 hash in auth tokens.

Provides informational guidance for agent providers (APs) on enrolling agents and issuing AAuth agent tokens. It covers per-platform key handling, optional platform attestation, agent identifier strategies and refresh patterns. The mechanisms are not normative protocol but common patterns that interoperable AP implementations can adopt or adapt.

Specifies extensions to the SUIT manifest format that let a manifest author, update distributor or device operator control the distribution and installation of updates to devices more precisely. The extensions also provide a mechanism to inform a management system of Software Identifier and Software Bill of Materials information about an updated device.

Addresses authenticated provenance for a request and response passing through a chain of workloads: proof of which workloads participated and whether each changed the message. The base WIMSE HTTP Message Signatures mechanism authenticates only one workload's message to its immediate recipient. This document establishes provenance using per-hop digests of what each hop received and forwarded (detecting an omitted hop that changed the message), and closes the remaining gap with an aggregate signature that stays close to the size of one signature regardless of chain length. It works with any aggregate signature scheme.

Describes a simple, decentrally extensible and efficient format for data serialization. (The official abstract is brief; further detail is in the document body.)

Specifies extensions to the Lightweight Authenticated Key Exchange (LAKE) protocol, formerly EDHOC, to resist quantum-computer adversaries by incorporating post-quantum Key Encapsulation Mechanisms for both key exchange and authentication. It defines a new signature-free KEM-based authentication method in which both parties authenticate using KEMs, enabling quantum-resistant authentication without digital signatures when PQC KEMs such as the NIST-standardized ML-KEM are used.

Presents technical details of multiple CVEs and GitHub Security Advisories arguing that early (handshake-time) attestation fails in practice, even without physical access to the target machine, and that continuous attestation is generally required so early attestation only adds unnecessary complexity. The work, backed by ProVerif formal-analysis artifacts under Apache-2.0, documents two CVSS 9.1 CVEs, one CVSS 7.5 CVE, and several GHSAs ranging from 6.3 up to 9.0-10.0. It notes that most early-attestation implementations have been archived or moved to post-handshake attestation, while analysis finds Edgeless Systems Contrast and Meta's AI still vulnerable, and recommends users carefully evaluate their systems.

Defines how a Holder presents an issuer-signed JWT credential directly to an HTTP resource server using OAuth 2.0 Demonstrating Proof of Possession (DPoP). The credential is carried in the Authorization header with the DPoP scheme, and possession of the key confirmed in the credential's cnf claim is demonstrated with a DPoP proof. The wire format matches a DPoP-bound access token; what it adds is a model in which the credential is issued by an authorization server or IdP the resource server already trusts, may carry no issuer-defined audience, and has its status checked, with no AS or presentation protocol involved between issuance and use.

Defines the Canonical Action Identifier (CAID) so that authorization, delegation, execution and audit artifacts can identify an action comparably even when formats encode action fields differently. It specifies a typed action object, a canonicalization and digest suite, a compact identifier string and versioned action-type definitions with required material fields, binding external value sets to integrity-checked snapshots. It sets a strict JSON input profile, an ordered set of refusal reasons and a digest identifying validation semantics, and requests seven registries. An Action-Mapping Profile projects natively verified artifacts into a common action type with closed results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT and INDETERMINATE. CAID carries no trust semantics.

Defines a protocol for real-time interactive communication between users and AI agents over Media over QUIC Transport (MOQT). It maps streaming inference outputs (ASR transcripts, LLM tokens, TTS audio) to the MOQT object model, defines a turn-taking control protocol with barge-in support for voice interactions, and establishes track-structure conventions for live agent sessions. It operates as an application-layer profile atop MOQT without modifying transport semantics.

A deliberately non-technical document making the point that anyone can publish an Internet-Draft, and that doing so does not mean 'the IETF thinks' or 'the IETF is planning' anything. At revision -25, it is a long-running, tongue-in-cheek reminder about the status of Internet-Drafts rather than a protocol specification.

Presents an operator-perspective framework for building and running IPv6-only underlay networks that span multiple domains (multiple interconnected Autonomous Systems). To carry residual IPv4 traffic, it proposes stateless IPv4/IPv6 address mapping as the basis for IPv4-as-a-Service, so IPv4 packets are translated at the network edge and forwarded across the IPv6-only underlay without per-flow state or conversion gateways on the data path. It is a problem statement, guidance and requirements document covering applicability and trust boundaries, mapping-prefix allocation options, and operational, manageability and security considerations.

Defines a Traceroute Extension Block (TREB) for Bundle Protocol Version 7 (BPv7). Each participating node along a bundle's path appends a hop-record with its Node ID, selected next hop, event time and link characteristics; the same block, copied into bundle status reports, returns traceroute data to the source. It is opt-in and intended for designated diagnostic bundles on scheduled, bandwidth-constrained paths. In delivery-report-only operation a single status report returns the full recorded path and records its own return path, giving a round-trip trace. Status report generation stays governed by RFC 9171.

Proposes BGP SAVNET, extending BGP for source address validation (SAV). Existing SAV mechanisms suffer from inaccurate validation or high operational overhead in some scenarios. BGP SAVNET propagates SAV-related information through BGP messages so edge/border routers can automatically generate accurate SAV rules; these rules build a validation boundary for the network and check the validity of source addresses on arriving data packets.

The SCONE protocol relies on the receiver of SCONE packets to send bandwidth estimates back to the sender via unspecified application-layer messages, but a peer may have SCONE receive capability at the QUIC layer without the necessary application-level functionality. This document defines a new QUIC frame that directly reports the contents of received SCONE packets to address those cases, with no change to the interaction with SCONE Network Elements.