IETF Daily Digest

The ZONEMD resource record checks the integrity and helps verify the authenticity of an entire DNS zone by storing a cryptographic hash of the zone data computed under a configurable collation method; name servers use it as a checksum during zone transfers. RFC 8976 defined the SIMPLE collation method, suited to small, rarely updated zones. This document introduces the MERKLE3 scheme for large, dynamic zones. MERKLE3 uses a Merkle tree so the digest can be computed in parallel and incrementally, avoiding a full recomputation on every change.

Examines whether additional Computing-Aware Traffic Steering (CATS) requirements are needed when service segmentation is applied to related CATS use cases. It names AR/VR and Distributed AI Inference as the relevant use cases. Service segmentation here splits a service into subtasks that run in parallel or in sequence before their results are combined. The draft frames the resulting requirements question rather than specifying a solution.

Addresses service segmentation, a newer deployment approach in which one service is split into several distributed subtasks that together form a pipeline. It examines how to direct sessions through subtask instances arranged in sequential, parallel, or iterative pipeline patterns. It proposes a MUP Sequence Session Transform to steer traffic through the subtasks in a required order. The document also considers how to keep services continuous when pipelines are updated, which is especially challenging when stateful subtasks are involved.

Describes a generic congestion-avoidance solution that provides local link congestion avoidance within the Segment Routing (SR) framework. Building on the concept of Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute, the selected shortest path can bypass a congested link while avoiding the formation of micro-loops. A key advantage is that the approach requires no protocol extensions. It is intended to react to local congestion quickly within existing SR deployments.

Extends the Benchmarking Methodology Working Group's lab-characterization work from physical and virtual network functions to containerized ones. As network functions move from virtual machines to containers, benchmarking setups increasingly depend on how resource allocation and networking are defined for the containerized functions. The draft identifies the additional factors that must be considered when benchmarking containerized network functions running on general-purpose hardware. It aims to keep benchmarking results meaningful and comparable in container environments.

Updates RFC 6532, which extended the internet email format to allow UTF-8 in many contexts. This document slightly restricts the set of allowed addresses in header fields to simplify their use. It is the simpler of a pair of documents, containing only globally viable rules that are straightforward to implement. Its companion defines more complex rules that take regional usage into account and describe addresses readable and cut-and-pasteable within particular communities and locales.

Extends OAuth 2.0 so that a client instance can present an attestation bound to its own key when interacting with an Authorization Server or Resource Server. This lets the client demonstrate it is legitimate, as confirmed by a client attester, while keeping its intended service provider hidden from that attester. The mechanism can also serve as a form of OAuth client authentication. It targets scenarios needing stronger assurance about the client software making requests.

Introduces a Power Conserving Path Placement Strategy (PCPPS) for traffic engineering. During periods of low demand, PCPPS concentrates traffic onto a small set of network resources, allowing the remaining resources to become idle or nearly idle and thus save energy. When demand rises again, PCPPS redistributes the traffic across resources as needed. The goal is energy-efficient operation without compromising capacity when it is actually required.

Introduces a bitwise match filter component for source and destination IPv4/IPv6 address fields. These components extend the BGP Flow Specification framework. They are designed to support dynamic traffic load balancing that keeps traffic in both directions on the same path. The bitwise matching gives operators finer-grained control over which address bits a filter rule applies to.

By its name, this draft appears to define a BGP Flow Specification extension for matching or filtering QUIC traffic within the IDR framework. It is probably an individual submission proposing new Flowspec match components or actions aimed at QUIC flows. The official abstract could not be retrieved on this run, so this description is approximate and will be grounded on the next run.

Describes a delivery contract for how an AI agent presents a consequential decision to the human principal it acts for, and how that principal accepts, declines, amends, or rejects it. The envelope has eight named slots, covering a summary, supporting findings, recommendations, an offer of further detail, a question, labeled options with reasoning for each, one recommended option, and two escape hatches. It is sent as a structured field in a Model Context Protocol tool result, so any client can render it the same way. A dual-veto handshake lets the principal either change the answer while accepting the question, or reject the question and reopen deliberation, and either party can refuse to proceed. A SHA-256 digest over the JCS-canonicalized envelope lets a resolution or external receipt reference that exact envelope, and the informational memo introduces no new transport.

Updates the Bound End-to-End Tunnel (BEET) mode for ESP described in RFC 7402. The update aligns that description with the addition of BEET mode for IKEv2, without changing any processing behavior. In effect it is an editorial and specification-alignment update rather than a change to the protocol's on-the-wire operation. It keeps BEET mode consistent across the ESP and IKEv2 specifications.

Describes a new BGP extended community attribute for advertising the node-ID. The node-ID extended community lets BGP carry a node identifier alongside route advertisements. This enables use cases that need to associate routes or policy with a specific node. The document specifies the attribute's format and semantics.

Builds on BGP Flow Specification Version 2 (FSv2), a flexible framework for distributing traffic-filtering rules and associated actions. It observes that existing Flow-spec actions (rate limiting, redirecting, marking) do not address newer needs for adaptive bandwidth optimization. To fill that gap, the document defines a new traffic-filtering action that lets operators compress selected traffic on demand across multiple network domains. The action is carried in BGP Extended Communities designed to fit the FSv2 architecture.

PSI-02 is a domain profile of Proof of Stateful Integrity for records supporting carbon-sequestration claims, including field samples, remote-sensing extracts, and calculation inputs. Each record is sealed as a PSI receipt so later changes, reordering, or deletions can be detected, and only digests are sealed (not the records themselves). The profile proves integrity and ordering only, not that sequestration happened, that a methodology was followed, or that a credit is valid. The revision corrects revision 00, which carried an unrelated disability-services abstract.

PSI-03 is a profile of Proof of Stateful Integrity for records of dispatch instructions and metered responses between a virtual power plant operator and its distributed energy resources. Each record is sealed as a PSI receipt so later changes, reordering, or removal can be detected, and only record digests are submitted for sealing. The profile proves integrity and ordering only; it does not show that a resource performed as instructed, that metering is accurate, or that a market rule was met. The revision corrects earlier revisions that carried this title over an abstract about practitioner identity bonds.

PSI-04 is a profile of Proof of Stateful Integrity for records about vulnerable people, such as clinical-trial participants and recipients of disability or aged-care services. Each state change in a record is sealed as a receipt linked to the previous one, so a later edit or removal of a step becomes detectable. Only digests are sealed, so no personal data leaves the record holder. The profile demonstrates integrity and ordering, but does not show that care was adequate or that any regulation was met. This revision removes revision 00's MPC and zero-knowledge claims and its request for a URI scheme.

Introduces PSI-07, a specialized profile of the Proof of Stateful Integrity framework for organic-certification records such as supply purchases, field activities, and inspection notes. Each record is sealed as a PSI receipt so later changes, reordering, or deletions can be detected, and only record digests are sealed (not the underlying data). The profile proves integrity and ordering only; it does not show that a product is organic or that a certification standard was met. The revision aligns the content with the title after earlier revisions carried an abstract about regulatory monitoring.

Defines PSI-08, a domain profile of Proof of Stateful Integrity for access events on health records. Each event records that an access occurred, the role involved, and the stated purpose. Each record is sealed as a PSI receipt so later changes, reordering, or deletions can be detected, and only digests are sealed. The profile establishes integrity and ordering but does not show that an access was permitted, appropriate, or lawful. The revision aligns the body with the title after revision 00 paired it with an abstract about predicate chains.

Defines PSI-09, a profile of Proof of Stateful Integrity for age-assurance providers. It records that a check was run, which method was used, and what the result was. Each record is sealed as a PSI receipt so tampering, reordering, or deletion can be detected, and only record digests are sealed. The profile covers integrity and ordering only, so it does not establish a person's age, the method's accuracy, or compliance with any age-assurance law. The revision notes that revision 00 wrongly paired the title with text about tribunal verdicts, now withdrawn.

Introduces Proof of Stateful Integrity (PSI), a format for issuing signed receipts over digital records. Each receipt ties a SHA-256 hash of a canonically serialized JSON record to an issuer signature, a monotonic counter, and a Merkle root built under the RFC 6962 profile, with an optional external timestamp reference. A verifier needs only the record, the receipt, and the issuer's public key, and can check them without contacting the issuer. PSI shows integrity, origin, and ordering, but says nothing about whether a record is true, lawful, safe, or compliant. This revision supersedes revision 01 and drops earlier zero-knowledge, MPC, and inclusion-proof claims not supported by the reference implementation.

Introduces PSI-Age, a version of Proof of Stateful Integrity for age-assurance decisions, so a relying party can later show which provider decision it relied on. Its substance has been superseded by draft-singh-apex-psi-09 and it is kept mainly for continuity. Each record is sealed as a PSI receipt so later changes, reordering, or deletions can be detected, and only digests are sealed. PSI-Age demonstrates integrity and ordering only; it does not establish a person's age, the accuracy of the method, or compliance with any age-assurance law. The revision withdraws revision 00's zero-knowledge claim, since no such proof system is specified.

Describes a profile of Proof of Stateful Integrity for logging actions taken by software agents, including their calls to language models and tools. The agent's runtime creates a fingerprint of each action on its own system and submits only that fingerprint for sealing, so later changes or deletions are detectable. A receipt proves only that a record existed in a given state at a given time; it does not establish that the action was correct, safe, permitted, or lawful, and assigns no responsibility. This revision removes earlier liability language and updates the Merkle commitment to match a companion draft.

Defines the Compliance-Receipt HTTP response header, a Structured Field that references a Proof of Stateful Integrity (PSI) receipt for a response. The signature protects all security-relevant parameters. The header only shows that the issuer sealed a digest of the response. Despite its name, it does not show that the response or the service meets any legal or policy requirement.

Defines the Merkle commitment profile used by Proof of Stateful Integrity (PSI) receipts. It reuses the Merkle Tree Hash and inclusion proof from RFC 9162 unchanged, sets a fixed leaf ordering, and explains how receipts declare the profile and how verifiers obtain and check inclusion proofs. A valid proof shows only that a leaf was committed under a given root, not that the sealed content is true or lawful. This revision drops the lexicographic ordering and odd-leaf duplication of revision 00, which conflicted with RFC 9162, and withdraws all anchoring claims except OpenTimestamps.

Argues that communication between AI agents, and between agents and tools, is expected to be pivotal in 6G systems. It notes that 3GPP TR 22.870 describes use cases and possible service requirements for agent communication in 6G. The draft draws examples from that report and proposes possible requirements for agent communication protocols. It is intended to inform the development of such protocols for 6G environments.

Proposes an addition to BGP Flow Specification Version 2 that lets operators filter traffic by the origin AS of its destination IP address. This helps with DDoS mitigation or traffic redirection when many target addresses change often but share a single destination origin AS. The extension is described as one that enables filtering based on the Origin Autonomous System. It gives operators a compact way to express policies tied to destination-side origin ASes.

Extends BGP Flow Specification Version 2 so that traffic can be filtered by the origin AS of its source IP address. This helps against DDoS attacks where the attack sources are numerous or constantly changing but belong to a single source AS. By matching on the source-side origin AS, operators can write one rule covering many volatile source addresses. The mechanism complements destination-based filtering in the FSv2 framework.

Proposes a lightweight way to fingerprint IS-IS link-state databases. Operators in large networks could use it to confirm that all routers have synchronized their databases and to estimate how quickly flooding spreads. The document also describes YANG model extensions for accessing this information. It defines an optional TLV that carries the fingerprint in IIH and CSNP PDUs so neighbors can quickly check synchronization.

Defines a new component type for BGP Flow Specification Version 2, whose rules and actions are carried through an extensible type-length-value filter architecture. The new component belongs to the Routing Filter Family and adds filtering by community. Instead of matching only on the destination address in the Flowspec NLRI, a rule can check the BGP community tagged on that destination's route. The authors intend the mechanism for use within a single administrative domain.

BGP Flow Specification Version 2 (FSv2) distributes traffic-flow rules and filtering actions through an extensible, TLV-based filter-family design. This draft introduces a new FSv2 component type under the Routing Filter Family for filtering by community. The match condition checks the BGP Community attributes of the route that matches a packet's source IP address. The authors intend the mechanism for use within a single administrative domain.

Notes that AI coding agents draw persistent context from organization, project, user, vendor, and task sources, but current formats lack a shared model for authority, file scope, enforceability, and audit evidence. It introduces the Agent Context Interchange Protocol (ACIP), a YAML-based format with host resolution behavior for those sources. The protocol covers source precedence, file matching, and a distinction between enforceable constraints, textual directives, and preferences. It includes a resolution receipt, compatibility with AGENTS.md and Agent Skills, and migration profiles for tools without native support. Plain-language instructions alone cannot compel an agent's behavior, so enforcement requires a host or outside control at the point of action.

Observes that ORCHID guidance for the Host Identity Protocol (HIP) and the Drone Remote Identification Protocol (DRIP) has grown over time and is spread across many resources, including the hierarchy added in RFC 9374 and ORCHID use in other frameworks. This draft gathers those lessons and minor corrections into one specification. It obsoletes RFC 7343 and updates RFC 7401 and RFC 9374. It aims to keep ORCHID-aware implementations interoperable.

Notes that RFC 7468 defines a text encoding, widely called PEM, that wraps data structures in labels like 'CERTIFICATE'. Because no registry tracks these labels, they are hard to find and used inconsistently. The draft proposes an IANA registry to address this gap. It also defines a new label, 'OCSP RESPONSE', for encoding OCSP responses.

Presents a method for information distribution and subscription that works within GRASP. It leaves the GRASP protocol itself unchanged. Instead, it layers a new mechanism on top of GRASP capabilities that already exist. The result is a publish/distribute pattern usable by autonomic nodes without protocol modification.

Notes that devices authorized to join an autonomic control plane, as defined in RFC 8994, can use OASIS MQTT publish/subscribe telemetry to share arbitrary information. The approach requires an MQTT message broker. That broker may be announced through GRASP (RFC 8990) flooding. The document thus layers MQTT-based telemetry on top of the autonomic control plane and its discovery mechanisms.

Systematically examines emerging agent-based use cases and sorts them into distinct scenarios. For each scenario it outlines the specific authorization requirements. It then compares these requirements against the OAuth 2.0 framework and its common extensions to identify gaps. The authors intend these findings to lay groundwork for new OAuth Working Group extensions that would support safer and more interoperable agent systems.

Specifies version 1.3 ('Reader Profile') of the Agentic Reasoning Protocol. It defines a JSON manifest, served at a well-known location, in which a domain operator describes an entity, with an optional Ed25519 signature whose public key is published in a DNS TXT record. A valid signature shows the operator published exactly this file and that it has not changed, but does not show that the statements in the file are true. Version 1.3 adds a wording profile limiting manifest text to third-person statements, a required provenance statement, and a readable description of the signature with pointers for checking it. It also adds a Markdown representation bound to the manifest by a SHA-256 digest, a discovery profile, and key revocation via an empty key value in the DNS record.

Defines a SCITT profile for creating independently verifiable, tamper-evident records of autonomous AI agent actions. It specifies the AgentInteractionRecord (AIR) as the COSE_Sign1 signed payload for material agent actions, and maps SCITT roles so the agent's operator acts as Issuer and an independent Evidence Custodian acts as Transparency Service. The profile sets Registration Policy requirements for hash-chain integrity, temporal ordering, and sequence completeness, and adds a redaction receipt mechanism for privacy-preserving custody. It offers informational mappings to several regulatory frameworks, including EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI risk guidelines, PCI DSS, and MiFID II.

Notes that BGP FlowSpec uses BGP to distribute traffic-flow information along with filtering actions. The document proposes extensions to FlowSpec for distributing Source Address Validation (SAV) rules. The new components would let SAV rules be carried and acted upon within the FlowSpec framework. (The abstract is brief; the Introduction gives more detail on the new components.)

Describes GEVP, a minimal protocol for epistemic convergence, renamed from VCP to avoid a naming clash with draft-kamimura-scitt-vcp. GEVP's Epistemic State Machine is mapped to the evidence categories of the Gravit Verifiable Epistemic Decision Standard (VEDS). This revision corrects the Implementation Status section because the threshold calibration and cost relation in earlier revisions could not be reproduced. Those results are replaced with reproducible ones, and the draft no longer recommends any specific theta threshold.

Introduces a Signed Evaluation Receipt that records one evaluation result as signed payload bytes. Existing envelopes can cite a receipt by the SHA-256 digest of those bytes, and a DSSE envelope can carry the bytes along with the receipt's own signature. The document sets out the exact bytes and a matching rule, and maps receipt fields onto DSSE, the in-toto test-result Statement, and the SLSA Verification Summary Attestation. It shows that a receipt's signature already works as a valid DSSE signature, and describes SCITT Signed Statements that reference a receipt only by its digest. It declares the receipt digest as an artifact type and relates receipts to pre-run criteria written in PRML, defining no new format or predicate.

Sets out proposed requirements and test cases for identifying SCITT Signed Statements. It separates matching a reference to a statement from retrieving the statement, verifying its signature, authorizing its issuer, and confirming registration. It also examines how different identification approaches handle changes to a statement's encoding and to the context of its registration. The author presents the requirements as material for technical discussion, not a working group position. The draft does not create a common reference format, assign a COSE header parameter, or define a relationship vocabulary.

Defines a Signed Evaluation Receipt, a single JSON object recording one evaluation outcome: whether a score met a stated threshold for a named metric on a named test suite. The object is signed with Ed25519 over a domain-separated encoding of its canonical bytes. The receipt establishes who signed the recorded bytes, but not that the recorded result is accurate, and does not by itself prove it was registered with a Transparency Service. Under SCITT, such transparency requires separately registering the receipt (or its digest) in a signed statement and verifying the SCITT Receipt returned. That registration and verification is out of scope.

Introduces probe tracks for Media over QUIC Transport: synthetic objects generated on demand to measure the bandwidth of a single network hop, which are never forwarded or cached and sit under reserved, session-scoped namespaces. The track name sets the probe's shape, including target bitrate, duration or size, object rate, object size, group structure, and key-object bursts. A subscriber can request a downlink probe so the relay generates traffic, helping it judge whether a higher-bitrate track is sustainable before switching. A publisher can instead generate an uplink probe and send it to its relay to measure the publisher-to-relay hop.

Extends the CDNI metadata model so that metadata can be applied conditionally and at several points in a dCDN's handling of requests. It introduces processing stages, each giving the CDN a chance to inspect and modify requests and responses. Caching rules, for example, can be triggered by characteristics of an HTTP request header, and responses from a source can be changed on the fly, such as by inserting or removing headers. The specification relies on the Metadata Expression Language for these conditional checks.

Explains how an Extended Community can be derived from a Route Target, how the derived community maps back to its Route Target, and how the two differ. It lists the code points already assigned for this derivation and requests the remaining ones. It does not define how these derived communities are used, leaving that to the specifications for each use. It is primarily a code-point and mapping specification.

Entropy labels (ELs) in the SR-MPLS data plane improve load-balancing, and RFC 8662 allows several Entropy Label Indicator (ELI)/EL pairs in one label stack. This document introduces Entropy Label Positions (ELP), which specify where in the stack these pairs should go. It then defines extensions to the Path Computation Element Communication Protocol (PCEP) that carry this ELP information in SR-MPLS networks. The goal is coordinated EL placement under PCE control.

By its name (RADEXT working group, 'EPCS'), this draft is a RADIUS extension. It most likely defines new RADIUS attributes or procedures for a specific capability denoted by EPCS. The official abstract could not be retrieved on this run, so this description is approximate and will be grounded from the abstract on the next run.

In the RATS architecture (RFC 9334), a Verifier uses an Appraisal Policy for Evidence, usually with Endorsements and Reference Values, to produce Attestation Results for Relying Parties. This document explains what Endorsements are for and what to weigh when choosing their message format, without defining a conceptual message format for Endorsements or Reference Values. It updates RFC 9334 by clarifying how those two are described, sorting RATS conceptual messages into actual state, reference state, and appraisal policy. It adds guidance on conditionally endorsed values, endorsing verification keys, timeliness, and multiple Endorsements.

Describes a common architecture for inter-domain source address validation (SAV). It explains how SAV-specific and SAV-related information from multiple sources can be gathered and used to determine which incoming directions are legitimate for each source prefix. A SAV agent stores this information in a SAV Information Base, and a SAV Information Base Manager uses it to create or update the SAV table. The document covers deployment, operation, convergence, manageability, security, and privacy. It does not define a specific protocol, protocol extension, or SAV-table generation algorithm.

Defines a simple protocol, built on HTTP, that lets WebRTC-based viewers play content from streaming services, content delivery networks, or WebRTC transmission networks. It establishes a standard way to initiate and negotiate WebRTC playback sessions. The protocol (WHEP) is the egress counterpart to WHIP for ingest. It aims to make WebRTC-based media consumption interoperable across implementations.

Notes that AI agents increasingly act through local tool servers on the same host, reached over channels such as MCP's stdio transport, which fall outside HTTP-based authorization and often leave reusable credentials in the agent's memory. The document proposes a per-call proof for local tool invocation. A Call Authority running outside the agent evaluates policy, issues a short-lived, single-use proof tied to the exact tool name and arguments via a canonical action digest, and verifies that proof for the tool server. The tool server rejects any invocation whose proof is missing or fails verification. The proof format stays opaque to the agent and tool server, is defined in separate evidence-type profiles, and the document includes a binding for MCP stdio.

Proposes performing Source Address Validation (SAV) at the boundary of an intra-domain network using BGP. Boundary routers would automatically build accurate SAV rules from routing data and SAV-specific details. Those rules would form a checkpoint that verifies the source addresses of packets entering the network. The document also defines BGP extensions that let boundary routers share this SAV-specific information with one another.

Introduces SPA-based SAVNET, a source address validation (SAV) mechanism for intra-domain networks that relies on routers exchanging Source Prefix Advertisement (SPA) information. Boundary routers use routing information and SPA information to generate accurate SAV rules automatically. Together these rules form a validation boundary that checks the source addresses of packets entering the intra-domain network. The document explains how to implement this approach using OSPF and IS-IS.

Proposes building more precise OAuth 2.0 authorization requests using schemas tailored to a specific application domain, which define the limits a client's actions must stay within. A client submits a schema instance in the authorization_details parameter, and once the authorization server approves it, that instance determines what the resulting access token permits. Approved instances follow a lifecycle affecting token issuance, refresh, and resource access. Resource servers check each client action against the approved instance using deterministic rules. It also introduces 'reverse-guided authorization', where a resource server's error response references a schema profile that tells the client what authorization it needs for its next step.

Proposes a way to map YANG schemas and instance data onto TM Forum (TMF) data models and APIs. The approach would let orchestrators offer TMF-compliant interfaces that give TMF API consumers direct access to a YANG data store. It covers two areas: converting YANG schemas into TMF catalog specifications (TMF633 and TMF634), and converting YANG instance data for order management (TMF641, TMF652) and activation management (TMF640, TMF702).

Describes a 'compute-location gate', a wire-layer negotiation in which a client and an identity-inference server agree on where an inference runs, before any computation starts, based on how the input signal was obtained. It defines three provenance classes: active inference (initiated by the principal) may run on the server and write to a server-held identity vector; aggregate observation over a sufficiently large cohort may run on the server but yields only population-level results; and individual passive observation must stay on the observing device and never reach a server. The gate relies on consent-class matching and a wire-layer refusal, not on cryptographic proof. The informational memo reuses existing discovery, handle, and policy mechanisms without adding a new transport.

Describes the Morning Brief, a bounded-lifetime summary of signals, escalations, decisions, and optional commerce quotes that one organisation or agent sends to another under an Identity Accord. Each signal is tagged with a provenance class (active self-report, passive aggregate, or passive individual observation), and the passive-individual class is barred from the wire and rejected at the grammar level. Readers must present a capability token scoped to category and provenance class, which the issuer applies before composing the payload. The brief is signed with COSE_Sign1 over a JCS-canonicalised payload, bound to the issuer's Sovereign-tier handle, and expires by default after 24 hours, with a revocation endpoint discovered via DNS TXT records. The document covers only the wire format, leaving rendering, storage, and retention out of scope.

Critiques a coordination-protocol anti-pattern seen in cross-tool agentic systems and offers substrate observation as an alternative that avoids negotiating a wire format among concurrent sessions of a single identity-bound principal. The memo is Informational and proposes no protocol element for standardization. Instead it explains what should not be standardized for this problem and why, and names existing substrate mechanisms that can fill the role. Companion memos cover the identity primitives this memo assumes.

Describes a wire-level format that lets a language model label each individual claim in its output with the external data source, if any, that supported it, drawn from a fixed, closed list of source categories. The memo defines that list, how labels attach to claims, and how a receiving party may filter labels when deciding what to accept. It introduces two terminal states, one for claims made without any corroboration and one for claims whose supporting evidence had gone stale, placing them on the same footing as a plain assertion or a denial. It does not dictate how the model must behave; it defines a format that lets a relying party check what the model actually consulted. The memo is Informational.

Defines the foundational layer of Keysingate. It covers how documents are serialized and signed, how timestamps are formatted, and how a signed object gets an upper time limit from anchors recorded on public networks. It describes the chain of channel documents that passes serial-number ranges from issuer to holder, plus a status record that tracks a container's lifecycle. The aim is for separate implementations to produce identical bytes and reach the same verification result. The work journal and its export are covered in a companion document.

Describes a Keysingate container that keeps a work journal of unsigned pages, closed by a single portable seal that covers all earlier pages and moves forward with each new record. The document defines the journal's pages, records, and seals, plus two journal forms (unanchored and anchored). It covers two export types a third party can receive: one page with its proof, or the whole journal once. It explains how a verifier can check either export without contacting anyone, and defines a Solana anchoring profile using a blind memo, so outsiders see only that a write occurred. The core documents, time format, and anchor rule come from draft-nam-ksg-core.

Defines learnlog, a log format for learning software. Each record holds typed events describing what a learner did and how other parties, human or software, responded. The format aims to preserve the AI assistance needed to interpret a learner's performance, but does not establish independent learning or whether an intervention worked. Entries are linked by hash, and a producer can sign the latest link so a reader who trusts the key can detect unauthorized changes; some changes remain undetectable and are described in the security considerations. An event can be redacted while the rest of the record still verifies, and the document defines the files, records, entries, events, and event-schema registries.

Proposes an operational profile for agentic systems that continue proposing work after their authorization changes, when delegated credentials, queued jobs, and in-flight operations may keep producing effects during the gap. The profile separates agent proposals from authoritative authorization, effect admission, computation termination, and bounded closure. It covers enforcement assumptions, revocation barriers, handling of downstream delegated work, status evidence, and fault tests. It complements existing authorization and revocation mechanisms rather than replacing them, and does not define a new token format, claim closure beyond its declared coverage, undo committed effects, or attribute mental states to an agent.

Observes that agentic systems often change their models, prompts, memory, policies, tools, and execution environments during handoffs. It proposes an observation profile for recording these transitions and the evidence behind them, sorting discontinuities into five groups: state, memory, policy, authority, and lineage. It separates manual or simulated observations from attested executions and requires reporting of coverage and missing data. It describes evaluation designs for continuity and bounded governance, and states that continuity records do not grant authority, establish clinical or subjective-experience claims, or validate an uncalibrated composite score.

Notes that distributed authorization systems often conflate observations, policy evaluations, evidence records, authorization decisions, and execution receipts, which can lead to fail-open behavior, stale authority, and false completeness claims. To prevent this it defines 'non-collapse semantics', requiring explicit, typed transitions between observation, evidence, authorization, and execution states. It requires failing closed when a needed premise is missing or uncertain, and provides rules for deciding when different representations agree on a declared invariant. The informational document does not define a new wire protocol.

Describes a protocol-neutral architecture that separates holding a capability from having authority over the boundaries where that capability could cause real-world effects. It models authority as reachability within a graph of capabilities that changes over time. It introduces revocation cuts, points that sever access paths when a credential is withdrawn. It specifies fail-closed rules for delegation and revocation, so uncertain states default to denial.

Observes that agentic systems can pass authority among delegated agents, workloads, credentials, queues, and long-running operations, and that revoking a credential or grant does not by itself prove every path from revoked authority to a real-world effect has been shut off. The document proposes a protocol-independent model for establishing that revocation is complete. Its building blocks include authority graphs, consequential sinks, cut sets, closure states, closure budgets, and closure receipts. It is meant to complement existing OAuth 2.0, workload-identity, transaction-token, and agent-authorization efforts, and does not define a new protocol, token format, or AI-safety mechanism.

Describes five behaviors that a supplied OctaTouch gesture-runtime smoke-test script expects. The document is a narrow test profile, not a full gesture specification. The runtime code and its dependencies were not included with the script, so the tests were not run as part of this archive. For the same reason, the draft makes no claim that any implementation is interoperable or conforms to it.

Presents an experimental framework for studying how independent human reasoners and software agents solve problems together. It treats several properties as separate things to measure: strong task synergy, semantic coherence, continuity of state and identity, provenance, authorization, and persistence of behavioral goals. It proposes a controlled study with eight conditions, along with requirements for how results should be reported. It explicitly does not introduce a new on-the-wire standard or a test for consciousness.

By its name, this draft (now at revision 19) appears to be an individual submission specifying 'AER1'. The acronym is not expanded in retrievable metadata, and the official abstract could not be fetched on this run. This description is therefore approximate and will be grounded from the abstract on the next run.

Aims to let clients discover minimal public information about AI resources before interacting with them, within a local network, an organization, or among cooperating parties on the public Internet. It presents a two-layer federated reference architecture: a Local Discovery Plane for zero-configuration advertisement within each site, and a Federation Plane where site gateways exchange lightweight Federation Metadata Records across administrative domains with integrity protection. It emphasizes data sovereignty through an Export Policy Engine and supports iterative discovery via referrals and delegation. It prefers DNS-based federation (Mode A, with DNSSEC) while allowing non-DNS alternatives (Mode B). The informational document excludes semantic matchmaking, ranking, and capability-based selection.