From 56292b5945c5a450c81bc92330d2bae41a7cdaa8 Mon Sep 17 00:00:00 2001 From: Mikhail Sergeev Date: Sun, 18 Oct 2026 01:15:16 -0700 Subject: [PATCH] Complete CBEE publication history and editorial workflow --- .editorconfig | 19 + .gitattributes | 12 + .github/pull_request_template.md | 7 +- .github/workflows/build.yml | 41 + .github/workflows/release.yml | 57 + .gitignore | 8 + CONTRIBUTING.md | 16 +- LICENSE-CODE | 29 + LICENSE.md | 26 +- Makefile | 17 + README.md | 143 +- published/00/README.md | 31 + published/00/SHA256SUMS | 2 + .../00/draft-sergeev-claim-boundaries-00.txt | 2128 ++++++++++++ .../00/draft-sergeev-claim-boundaries-00.xml | 2935 +++++++++++++++++ published/01/README.md | 31 + published/01/SHA256SUMS | 2 + .../01/draft-sergeev-claim-boundaries-01.txt | 2464 ++++++++++++++ .../01/draft-sergeev-claim-boundaries-01.xml | 2334 +++++++++++++ published/02/README.md | 33 +- published/README.md | 47 + published/revisions.json | 71 + requirements.txt | 2 + review/editor-copy.md | 835 +++++ tests/test_release.py | 110 + tests/test_tools.py | 131 + tools/draft.py | 285 ++ tools/release.py | 181 + 28 files changed, 11935 insertions(+), 62 deletions(-) create mode 100644 .editorconfig create mode 100644 .gitattributes create mode 100644 .github/workflows/build.yml create mode 100644 .github/workflows/release.yml create mode 100644 .gitignore create mode 100644 LICENSE-CODE create mode 100644 Makefile create mode 100644 published/00/README.md create mode 100644 published/00/SHA256SUMS create mode 100644 published/00/draft-sergeev-claim-boundaries-00.txt create mode 100644 published/00/draft-sergeev-claim-boundaries-00.xml create mode 100644 published/01/README.md create mode 100644 published/01/SHA256SUMS create mode 100644 published/01/draft-sergeev-claim-boundaries-01.txt create mode 100644 published/01/draft-sergeev-claim-boundaries-01.xml create mode 100644 published/README.md create mode 100644 published/revisions.json create mode 100644 requirements.txt create mode 100644 review/editor-copy.md create mode 100644 tests/test_release.py create mode 100644 tests/test_tools.py create mode 100644 tools/draft.py create mode 100644 tools/release.py diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000..6ae8661 --- /dev/null +++ b/.editorconfig @@ -0,0 +1,19 @@ +root = true + +[*] +charset = utf-8 +end_of_line = lf +insert_final_newline = true +indent_style = space +indent_size = 2 + +[*.py] +indent_size = 4 + +[Makefile] +indent_style = tab + +[published/**] +trim_trailing_whitespace = false +insert_final_newline = false + diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..d3ca874 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,12 @@ +* text=auto eol=lf +# Preserve official archive bytes on every platform. +published/**/*.xml -text +published/**/*.txt -text + +# Count the actual RFCXML manuscript as a source, not only the build tooling. +/draft-sergeev-claim-boundaries.xml linguist-detectable=true +# Do not count the frozen duplicate publication as another source language. +published/** linguist-documentation=true +# Generated from the XML; keep its diff collapsed unless a reviewer expands it. +review/editor-copy.md linguist-generated=true + diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index d4178c7..7486940 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -8,8 +8,13 @@ Explain which claim or inference the change clarifies and why it is supported. ## Checks performed +Run `make review`, `make check`, `make test`, and `make build` when the +formatter is installed. Include the regenerated reading copy. Record any +check that could not be run; do not edit an existing published snapshot. + List the checks run and their results. For a rendering, give the formatter version and command; note checks that could not be completed. -Keep the published/02 snapshot unchanged. +Keep every published snapshot unchanged. Contribution terms, attribution, and privacy guidance are in CONTRIBUTING.md. + diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml new file mode 100644 index 0000000..d9148a9 --- /dev/null +++ b/.github/workflows/build.yml @@ -0,0 +1,41 @@ +name: Build and check draft +on: + push: + branches: [main] + pull_request: + workflow_dispatch: +permissions: + contents: read +concurrency: + group: draft-build-${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: true +jobs: + build: + name: Source checks and RFCXML build + runs-on: ubuntu-24.04 + timeout-minutes: 10 + steps: + - uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 + with: + persist-credentials: false + - uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 + with: + python-version: '3.12' + - name: Install pinned formatter and record the environment + run: | + mkdir -p build + python -m pip install -r requirements.txt + python -m pip freeze > build/environment.txt + - name: Check source, frozen publication, and editorial tools + run: make check test + - name: Render with official xml2rfc and repeat in the same environment + run: make build + - name: Preserve public renderings and diagnostics + if: always() + uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 + with: + name: editor-build-${{ github.sha }}-${{ github.run_attempt }} + path: build/ + if-no-files-found: error + retention-days: 14 + diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml new file mode 100644 index 0000000..91a4a8d --- /dev/null +++ b/.github/workflows/release.yml @@ -0,0 +1,57 @@ +name: Release a published IETF revision +on: + workflow_dispatch: + inputs: + revision: + description: 'Already published I-D revision (two digits, e.g. 00)' + required: true + default: '02' + type: string + target_commit: + description: 'Full main-history commit SHA containing the exact published/NN archive' + required: true + type: string + notes: + description: 'Optional short summary of this revision' + required: false + default: '' + type: string +permissions: + contents: read +concurrency: + group: ietf-release-${{ inputs.revision }} + cancel-in-progress: false +jobs: + release: + if: github.repository == 'Witnessability/cbee-spec' && github.ref == 'refs/heads/main' + runs-on: ubuntu-24.04 + timeout-minutes: 10 + permissions: + contents: write + steps: + - uses: actions/checkout@fbc6f3992d24b796d5a048ff273f7fcc4a7b6c09 + with: + fetch-depth: 0 + persist-credentials: false + - uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1 + with: + python-version: '3.12' + - name: Check the source and regression tests + run: make check test + - name: Verify the IETF archive, publish the GitHub release, and read back assets + env: + GH_TOKEN: ${{ github.token }} + REVISION: ${{ inputs.revision }} + TARGET_COMMIT: ${{ inputs.target_commit }} + NOTES: ${{ inputs.notes }} + run: | + python tools/release.py --revision="$REVISION" --commit="$TARGET_COMMIT" --notes="$NOTES" --publish + - name: Preserve verification results + if: always() + uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 + with: + name: release-verification-${{ github.run_id }}-${{ github.run_attempt }} + path: build/release/ + if-no-files-found: warn + retention-days: 14 + diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..bcbe807 --- /dev/null +++ b/.gitignore @@ -0,0 +1,8 @@ +/build/ +/.venv/ +__pycache__/ +*.pyc +.DS_Store +.env +.env.* + diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 47d7aab..b721b8b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -13,9 +13,15 @@ assess the proposal. You do not need an implementation or a patch to contribute. For manuscript edits, change only `draft-sergeev-claim-boundaries.xml` and keep the pull request focused on one issue. Describe the reason for the change and -the checks performed, including formatter version and command if you rendered -the manuscript. Keep the frozen `published/02/` files unchanged. Working -renderings are review aids, rather than additional editable manuscript sources. +the checks performed. Run `make review`, `make check`, `make test`, and, +with the formatter installed, `make build`. Include the regenerated +`review/editor-copy.md` in the PR; do not hand-edit it or the TXT/HTML outputs. +Keep every frozen `published/NN/` XML/TXT and checksum file unchanged. +Working renderings are review aids, rather than additional editable sources. + +Use a short-lived topic branch for a focused change. After review and successful +checks, merge it into `main` and remove the merged branch. Published revisions +use immutable tags and archive directories, not long-lived release branches. The editor records dispositions and retains material disagreement. A merge does not establish IETF consensus, implementation behavior, or permission to @@ -30,7 +36,8 @@ the [IETF Note Well](https://www.ietf.org/about/note-well/), [BCP 79](https://www.rfc-editor.org/info/bcp79), and the [IETF Trust Legal Provisions](https://trustee.ietf.org/license-info). Contribute material you are entitled to provide under those terms. -The manuscript retains its document notices; see [LICENSE.md](LICENSE.md). +The manuscript retains its document notices; [LICENSE.md](LICENSE.md) also +identifies the separate BSD 3-Clause license for repository tooling. There is no additional repository CLA or signed editorial form. ## Attribution and privacy @@ -45,3 +52,4 @@ of issues and pull requests unless disclosure has been authorized. If an example needs sensitive material to make its point, discuss a safe way to present it with the editor first. Follow the participation guidance linked from the IETF Note Well. + diff --git a/LICENSE-CODE b/LICENSE-CODE new file mode 100644 index 0000000..be2ab8e --- /dev/null +++ b/LICENSE-CODE @@ -0,0 +1,29 @@ +BSD 3-Clause License + +Copyright (c) 2026 Mikhail Sergeev +All rights reserved. + +Redistribution and use in source and binary forms, with or without +modification, are permitted provided that the following conditions are met: + +1. Redistributions of source code must retain the above copyright notice, + this list of conditions and the following disclaimer. +2. Redistributions in binary form must reproduce the above copyright notice, + this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. +3. Neither the name of the copyright holder nor the names of its contributors + may be used to endorse or promote products derived from this software + without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" +AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE +ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE +LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE +POSSIBILITY OF SUCH DAMAGE. + diff --git a/LICENSE.md b/LICENSE.md index 7043981..2c128b8 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -1,7 +1,21 @@ -# Document rights +# Licensing + +## Internet-Draft and manuscript contributions + +The Internet-Draft XML, published TXT, and generated manuscript renderings +retain their IETF Trust copyright notices and applicable +[IETF Trust Legal Provisions](https://trustee.ietf.org/license-info). +The code-components provisions of those terms apply where relevant. +This repository does not relicense the Internet-Draft under a general +software license. See [CONTRIBUTING.md](CONTRIBUTING.md), +[BCP 78](https://www.rfc-editor.org/info/bcp78), and +[BCP 79](https://www.rfc-editor.org/info/bcp79). + +## Repository tooling + +The separately authored files in `tools/`, `tests/`, and `.github/`, and the +`Makefile`, are available under the BSD 3-Clause terms in [LICENSE-CODE](LICENSE-CODE). +This grant covers that tooling, not third-party dependencies or the manuscript. +Dependencies retain their own licenses. The applicable IETF obligations for +contributions are not replaced by this software license. -The Internet-Draft includes its applicable IETF Trust copyright and license -notices. See [BCP 78](https://www.rfc-editor.org/info/bcp78) and the -[IETF Trust Legal Provisions](https://trustee.ietf.org/license-info/). -This file does not replace those notices or grant new rights to third-party material. -See also the [IETF Note Well](https://www.ietf.org/about/note-well/). diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..1491f38 --- /dev/null +++ b/Makefile @@ -0,0 +1,17 @@ +PYTHON ?= python3 + +.PHONY: all review check test build +all: check test build + +review: + $(PYTHON) tools/draft.py review + +check: + $(PYTHON) tools/draft.py check + +test: + $(PYTHON) -m unittest discover -s tests -v + +build: + $(PYTHON) tools/draft.py build + diff --git a/README.md b/README.md index e5182dd..d88c9ae 100644 --- a/README.md +++ b/README.md @@ -3,38 +3,56 @@ An individual Internet-Draft on what logs, receipts, signatures, attestations, and other execution evidence can establish about an action. +[![Build and check draft](https://github.com/Witnessability/cbee-spec/actions/workflows/build.yml/badge.svg?branch=main&event=push)](https://github.com/Witnessability/cbee-spec/actions/workflows/build.yml) + Editing workspace for **draft-sergeev-claim-boundaries**, an individual Internet-Draft by **Mikhail Sergeev**, with intended status **Informational**. -The document is an individual contribution; repository activity does not -establish working-group adoption or IETF consensus. +It is not an adopted working-group document or an IETF consensus statement. -**Published baseline:** revision **-02**. This workspace starts from the exact -published XML and TXT. Changes to the working source remain editorial work -until a new revision is submitted and posted by the IETF. +**Published baseline: -02**, posted on **15 October 2026 (UTC)**. +The working XML currently matches that publication exactly. +All published revisions, **-00, -01, and -02**, are preserved below. +Changes to the working source remain editorial work until a new revision is +submitted and posted by the IETF. ## Read, review, and contribute **To read or comment, no installation is needed.** Start with the -[published HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.html), -then [open a feedback issue](https://github.com/Witnessability/cbee-spec/issues/new?template=feedback.md) +[published HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.html) +or the [editor's reading copy](review/editor-copy.md), then +[open a feedback issue](https://github.com/Witnessability/cbee-spec/issues/new?template=feedback.md) or [email the editor](mailto:mikhailsergeev369@gmail.com). A section reference, a claim to examine, and a question or counterexample are enough. | Resource | Purpose | | --- | --- | -| [Published -02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) | The authoritative IETF revision | -| [Document and revision history](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/) | Official status and subsequent posted revisions | -| [Published HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.html) | Read the published document in a browser | -| [Working RFCXML](draft-sergeev-claim-boundaries.xml) | The single editable manuscript source | -| [Frozen XML/TXT and checksums](published/02/) | Published baseline for comparisons | -| [Issues](https://github.com/Witnessability/cbee-spec/issues) / [pull requests](https://github.com/Witnessability/cbee-spec/pulls) | Questions, counterexamples, and proposed changes | -| [Contribution guidance](CONTRIBUTING.md) | Review, attribution, and applicable IETF contribution terms | -| [Revision preparation and submission](PUBLICATION-PROCESS.md) | Review, preflight, exact-file approval, and publication verification | +| [Published -02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) | The authoritative current IETF revision | +| [Publication history](published/README.md) | Every posted revision, dates, summaries, and official links | +| [GitHub releases](https://github.com/Witnessability/cbee-spec/releases) | Revision tags, notes, exact XML/TXT, and SHA256SUMS | +| [Editor's reading copy](review/editor-copy.md) | GitHub-readable working text generated from the XML | +| [Working RFCXML](draft-sergeev-claim-boundaries.xml) | The only editable manuscript source | +| [Published archives](published/) | Frozen -00/-01/-02 files and checksums | +| [Issues](https://github.com/Witnessability/cbee-spec/issues) / [pull requests](https://github.com/Witnessability/cbee-spec/pulls) | Questions, counterexamples, and proposed edits | +| [Builds and review artifacts](https://github.com/Witnessability/cbee-spec/actions/workflows/build.yml) | Working XML/TXT/HTML, diff from -02, hashes, and logs | +| [Contribution guidance](CONTRIBUTING.md) | Review, attribution, and IETF contribution terms | +| [Preparation and submission](PUBLICATION-PROCESS.md) | Preflight, exact-file approval, and publication verification | Feedback by email is equally welcome; GitHub participation is optional. Repository merges record editorial decisions, without implying contributor endorsement or a working-group decision. +## Published revisions + +| Revision | IETF posting date (UTC) | Main changes | Files | +| --- | --- | --- | --- | +| [-02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) | 2026-10-15 | Certificate Transparency example; authorization-status evidence, availability, and decision-time use | [Archive](published/02/) · [Release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-02) | +| [-01](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/01/) | 2026-09-23 | Independence capabilities; support and evidence bases; non-inference rules 11–13; reporting distinctions | [Archive](published/01/) · [Release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-01) | +| [-00](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/00/) | 2026-09-16 | Initial claim-boundary discipline, control-topology test, and worked examples | [Archive](published/00/) · [Release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-00) | + +The [history index](published/README.md) separates IETF posting timestamps +from document dates and the later creation of this GitHub mirror. +The IETF archive remains authoritative. + ## Scope CBEE examines the boundary between an execution-related claim and the evidence @@ -48,37 +66,76 @@ record format, registry, or universal evidence-production mechanism. Its reporting distinctions describe what available evidence supports; they are not a protocol-conformance test suite. -## Edit and review +## Edit and build -Edit `draft-sergeev-claim-boundaries.xml` for manuscript changes. Keep a focused -change, identify the affected section or XML anchor, and explain how the -wording changes the claim or its evidence boundary. Follow -[CONTRIBUTING.md](CONTRIBUTING.md) when opening a pull request. +**This is a document repository.** The Python tools generate a reading copy, +check source links and archive integrity, run the official xml2rfc formatter, +and compare the working source with published -02. The build badge reports +editorial checks, not validation of the model or approval to publish. -The files under `published/02/` are frozen. Check their integrity locally with: +Python **3.12** is the CI environment. xml2rfc is pinned in `requirements.txt`; +the reading-copy, integrity, and regression commands use the standard library. ```sh -cd published/02 -sha256sum -c SHA256SUMS +python3 -m venv .venv +. .venv/bin/activate +python -m pip install -r requirements.txt +# Edit draft-sergeev-claim-boundaries.xml, then: +make review # refresh review/editor-copy.md +make check # source anchors/xrefs, all archive hashes, reading copy +make test # editorial and release-tool regressions +make build # official xml2rfc TXT/HTML, repeated in one environment ``` -Render working TXT/HTML with xml2rfc into a local build directory, recording -the formatter version and commands used. Generated renderings are review aids; -the root XML remains the manuscript source. The publication checklist in -[PUBLICATION-PROCESS.md](PUBLICATION-PROCESS.md) covers the current preflight -and exact files required for an author's submission decision. - -## Revision policy - -Preserve already posted revisions under `published/NN/`. A future revision -gets its own identity and archive; preparing it does not change the -02 -snapshot. The IETF archive is authoritative for posted revisions. - -Submission requires the author's decision for the exact package and intended -actions. A GitHub release, when separately authorized, records a revision -already posted by the IETF. This repository currently has no build, submission, -or release workflow; the documented manual process applies. - -The repository history begins with the published -02 files and the public -contribution process. Earlier private Git history and correspondence are not -part of this home. See [LICENSE.md](LICENSE.md) for the document notices. +Open `build/index.html` locally. CI artifacts contain the exact working XML, +TXT/HTML renderings, source diff from -02, output hashes, formatter logs, and +resolved package versions. Generated build files are not committed. Dependency +installation uses the network; rendering disables network reference resolution +and rejects local-file includes. + +These checks do not establish semantic correctness, interoperability, legal +clearance, IETF acceptance, or a fresh online idnits result. Preparing a new +submission still requires the review and current preflight in +[PUBLICATION-PROCESS.md](PUBLICATION-PROCESS.md). + +## GitHub releases + +Release titles follow the I-D revision (`-00`, `-01`, ...); tags use the full +document name, such as `draft-sergeev-claim-boundaries-02`. Every release +records an already posted IETF revision and includes XML, TXT, and SHA256SUMS. + +The initial history is imported after -02 was published. Historical tags point +to the public archive-import commit, not reconstructed private development +commits. For a historical revision, use its `published/NN/` directory or release +assets; the root XML remains the current working source. + +To mirror a future **already published** revision, preserve its exact files and +checksums under `published/NN/`, update the pinned archive inventory and history, +and merge the reviewed change. Run +[Release a published IETF revision](https://github.com/Witnessability/cbee-spec/actions/workflows/release.yml) +on `main`, supplying the two-digit revision and full archive commit SHA. +The workflow compares the files with the live IETF archive, creates the GitHub +release, and downloads its assets to verify them again. It refuses to move an +existing tag or overwrite conflicting assets. A matching rerun only verifies +the existing release. No release runs automatically on a push or merge. + +## Branch and revision policy + +`main` is the single ongoing development branch. Use short-lived topic branches +for focused PRs and delete them after their commits are merged. Retain an +additional branch only for active work with a stated purpose. Tags and frozen +archive directories preserve published revisions without release branches. + +Keep one editable root XML and immutable published XML/TXT snapshots. The +official -00 and -01 XML use older RFCXML syntax and are intentionally preserved +without conversion; the working -02 XML uses RFCXML v3. + +Ordinary CI has read-only repository permissions. Only the manually invoked +GitHub release job has contents-write permission for tags, releases, and assets. +No workflow submits to Datatracker, sends mail, or merges a PR. Submitting a new +I-D requires the author's decision for the exact package and intended actions. + +The public Git history starts with -02 and the contribution process; older +publications are imported as frozen artifacts. Private Git history and +correspondence are not imported. See [LICENSE.md](LICENSE.md) for the document +notices and the separate tooling license. diff --git a/published/00/README.md b/published/00/README.md new file mode 100644 index 0000000..fafbf41 --- /dev/null +++ b/published/00/README.md @@ -0,0 +1,31 @@ +# Published CBEE -00 + +[Datatracker](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/00/) · [Official HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-00.html) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-00) · [All revisions](../README.md) + +- IETF posting event: **2026-09-16T23:37:06Z** (UTC). +- Date inside the document: **17 September 2026**. +- Intended status: Informational; individual Internet-Draft. + +Initial individual Internet-Draft: the bounding principle, claim ceilings, non-inference rules, a control-topology test, and worked examples. + +## Frozen files + +The XML and TXT were downloaded from the official IETF archive and checked +byte-for-byte on 18 October 2026. They are preserved without reformatting. +SHA256SUMS covers exactly those two files. + +| File | Bytes | SHA-256 | +| --- | ---: | --- | +| [draft-sergeev-claim-boundaries-00.xml](draft-sergeev-claim-boundaries-00.xml) | 151463 | 640d2f2804cd2d7aeb495ed1294a03908906aa10b6e8bfd1d848b73e97ee5076 | +| [draft-sergeev-claim-boundaries-00.txt](draft-sergeev-claim-boundaries-00.txt) | 97001 | 6167510091e13a39e8f3116091f5207d69b0da6a7bd0b550e0372b68c8a88b59 | + +Verify from this directory with: sha256sum -c SHA256SUMS. +The [machine-readable history](../revisions.json) records the official URLs, +posting events, and file identities for every revision. + +The GitHub release is a later mirror of this existing IETF publication. +Its tag identifies the public archive-import commit; it does not claim that +this Git repository existed on the IETF posting date. Use this directory or +the release assets for -00; the root XML is the current working source. + +The official XML uses legacy RFCXML syntax. Do not convert this archived copy. diff --git a/published/00/SHA256SUMS b/published/00/SHA256SUMS new file mode 100644 index 0000000..109795d --- /dev/null +++ b/published/00/SHA256SUMS @@ -0,0 +1,2 @@ +640d2f2804cd2d7aeb495ed1294a03908906aa10b6e8bfd1d848b73e97ee5076 draft-sergeev-claim-boundaries-00.xml +6167510091e13a39e8f3116091f5207d69b0da6a7bd0b550e0372b68c8a88b59 draft-sergeev-claim-boundaries-00.txt diff --git a/published/00/draft-sergeev-claim-boundaries-00.txt b/published/00/draft-sergeev-claim-boundaries-00.txt new file mode 100644 index 0000000..8a085ed --- /dev/null +++ b/published/00/draft-sergeev-claim-boundaries-00.txt @@ -0,0 +1,2128 @@ + + + + +Network Working Group M. Sergeev +Internet-Draft Independent Researcher +Intended status: Informational 17 September 2026 +Expires: 21 March 2027 + + + Claim Boundaries for Execution Evidence + draft-sergeev-claim-boundaries-00 + +Abstract + + Systems that act in the world produce logs, receipts, approvals, + traces, attestations, provenance statements, and transparency + records. These artifacts are routinely offered as evidence that an + action was authorized, performed, or completed. This document states + a discipline for bounding such claims: the strength of an execution- + related claim is limited by what the available evidence actually + observed and by the control and observation topology at the boundary + that produced it. Message formats, signature validity, receipt + validity, and registration do not create observation or independence + that did not exist. The control-topology test was prompted by a + scenario Stephen Farrell posed in the IETF agent-protocol discussion + of July 2026: one party creates another and may be able to act in its + name. The tension is general, since no message format can supply the + independent enforcement or observation dependencies required by a + prevention or adversary-resistant detection-coverage guarantee, and + the scenario is worked through in an appendix. The document defines + no protocol, no record format, and no registry. It collects non- + inference rules, a control-topology test for prevention and detection + claims, a worked example, and reporting distinctions for evidence + that does not support the claim asserted over it. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 21 March 2027. + + + +Sergeev Expires 21 March 2027 [Page 1] + +Internet-Draft Claim Boundaries September 2026 + + +Copyright Notice + + Copyright (c) 2026 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 1.1. Scope and non-goals . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The bounding principle . . . . . . . . . . . . . . . . . . . 5 + 4. Evidence bases: what did the evidence observe? . . . . . . . 5 + 5. The claim ceiling . . . . . . . . . . . . . . . . . . . . . . 6 + 6. Non-inference rules . . . . . . . . . . . . . . . . . . . . . 8 + 7. A claim-boundary review lens . . . . . . . . . . . . . . . . 11 + 8. The control-topology test . . . . . . . . . . . . . . . . . . 12 + 9. When stronger claims become supportable . . . . . . . . . . . 15 + 10. Worked example: a payment . . . . . . . . . . . . . . . . . . 18 + 11. Reporting what the evidence supports . . . . . . . . . . . . 19 + 12. Applicability beyond AI agents . . . . . . . . . . . . . . . 21 + 13. Related work . . . . . . . . . . . . . . . . . . . . . . . . 24 + 14. Security considerations . . . . . . . . . . . . . . . . . . . 28 + 15. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29 + 16. Informative References . . . . . . . . . . . . . . . . . . . 29 + Appendix A. The (a,b,c) scenario worked through . . . . . . . . 36 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 + Document development disclosure . . . . . . . . . . . . . . . . . 38 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 + +1. Introduction + + An operator states that "the payment was executed". The artifact + behind the statement is a signed log entry produced by the operator's + own service. The signature verifies. The schema validates. The + entry was registered with a transparency service. None of that + establishes that the payment reached the payment network, only that + the operator recorded and registered a well-formed statement saying + so. + + + + +Sergeev Expires 21 March 2027 [Page 2] + +Internet-Draft Claim Boundaries September 2026 + + + Gaps of this kind are routine wherever execution-related evidence is + consumed: audit pipelines, compliance reporting, supply-chain + attestation, and incident forensics. They appeared recently and + sharply in the IETF's agent-protocol discussions of 2026, in + protocols for AI agents, where one party's software performs actions + whose records are produced largely by the acting side itself. + + The failure mode is semantic and assurance inflation: the strength of + a claim silently grows as an artifact moves between parties, formats, + and summaries. A record of an invocation is cited as proof of + execution. A valid signature is read as truth of the signed + statement. The presence of an audit trail is read as completeness of + coverage. An authorization is reported as an action performed. Each + step feels small. The result is a claim no producing boundary ever + observed. + + This document states the bounding discipline in one place, in + protocol-neutral terms, so that specifications, deployments, and + reviews can name the exact point at which a claim outruns its + evidence. + +1.1. Scope and non-goals + + This document is descriptive. It defines no wire format, no + transport, no carrier, no record or receipt format, no authority or + authorization mechanism, no registry, and no generic evidence + protocol. It does not compete with, extend, or profile any of the + systems discussed in Section 13. It states analytic limits that hold + whichever of those systems carries the evidence. Because it + specifies no protocol behavior, it does not use BCP 14 requirement + keywords: statements of the form "X does not establish Y" are claims + about what an artifact can support, not conformance requirements. + + This document states a claim-appraisal discipline, not an evidence- + design discipline. It identifies when available evidence does or + does not establish a claim, from the position of a relying party + deciding what to conclude from what it has. It does not prescribe + the complete set of observations, bindings, retention mechanisms, or + architecture that would have to be put in place in advance so that a + given claim remains determinable later. Enforcement or observation + at the time of an action and determination at a later time are + related, but they are not the same requirement. What further + material should have been captured or bound at action time, where, + and by whom, is related work and outside the scope of this document. + + The discipline is not new in its parts. Bounded claim statements are + established practice in specific domains: a time-stamp token is + evidence that a datum existed before a particular time, and the + + + +Sergeev Expires 21 March 2027 [Page 3] + +Internet-Draft Claim Boundaries September 2026 + + + authority time-stamps only a hash of the datum and does not examine + it [RFC3161]; DKIM distinguishes the signing domain from the + purported author and limits its integrity assertion to the content + covered by the signature [RFC6376]; certificate transparency + describes its logs as making misissuance detectable rather than + preventing it [RFC9162]; supply-chain transparency describes itself + as holding issuers accountable rather than preventing dishonest ones + [RFC9943]. This document collects such statements as one discipline + for execution-related evidence and claims no priority for any + individual rule. + +2. Terminology + + This document uses the following terms descriptively. + + Claim: A statement offered for reliance, concerning an action: that + it was intended, authorized, invoked, performed, completed, or had + an effect. + + Evidence: Artifacts offered in support of a claim: records, logs, + receipts, signatures, attestations, provenance statements, + transparency entries, and similar. + + Producing boundary: The vantage point, component, or interface at + which a piece of evidence was produced, together with what that + vantage point could observe and who controls it. This document + uses "producing boundary" throughout as its genus term for that + vantage point. + + Interested party: A party whose conduct the claim describes or whose + incentives are served by the claim being accepted; typically the + operator of the acting system. + + Relying party: A party deciding whether to accept the claim. + + Control topology: The arrangement of which parties control which + enforcement points, observation points, keys, and delivery paths + relevant to a claim. + + Independence: A property of deployment and control, relative to a + stated party and threat model: a component is independent of a + party only if that party cannot direct, bypass, or silently + suppress it. Independence is not established by a label, a field + value, a distinct key, an organizational name, or a count of + components alone. + + + + + + +Sergeev Expires 21 March 2027 [Page 4] + +Internet-Draft Claim Boundaries September 2026 + + +3. The bounding principle + + The strength of an execution-related claim is bounded by two things: + + 1. what the available evidence actually observed, at the boundary + that produced it; and + + 2. the control and observation topology at that boundary: who + operated it, who could bypass it, and through whose hands its + output travels. + + Message format, signature validity, receipt validity, and + registration do not raise either bound. A format can carry a + statement about control or observation. It cannot create control or + observation that did not exist. A signature authenticates bytes + under a key. By itself it establishes neither the truth of what the + bytes assert nor the signer's control of the boundary they describe. + A receipt's evidential force depends on the property being checked, + the observations or proofs that support it, and the applicable trust + and deployment assumptions. Successful verification of a + registration receipt can support that a statement was registered + under the service's policy. Registration alone does not establish + that the event described in the statement occurred. + + These limits concern what follows from the stated evidence and + premises. They do not preclude an inference from complementary + observations whose relationships and load-bearing assumptions are + established. Cryptographic verification can support those + assumptions. It does not supply a missing observation by + authenticating a statement about it. + +4. Evidence bases: what did the evidence observe? + + Execution-related artifacts answer different questions, and the + differences are load-bearing. At minimum, the following bases are + worth distinguishing: + + Observation: Some event concerning the action was recorded or + reported. Absence of a record alone is not an observation that an + event did not occur. + + Intent: A specific intention, plan, approval, or decision concerning + the exact action is evidenced. This establishes neither the + validity of the approval nor anything about performance. + + Invocation: The exact request crossed an observed invocation + boundary. This does not establish that the invoked operation + executed or had an effect. + + + +Sergeev Expires 21 March 2027 [Page 5] + +Internet-Draft Claim Boundaries September 2026 + + + Execution: Performance of the exact action was evidenced at a + boundary in a position to observe execution. This does not + establish completion of a larger process, a durable external + effect, goal satisfaction, correctness, or policy compliance. + + These bases are ordered by content depth. The bases organize + different evidential questions and need not be mutually exclusive. + Evidence relevant to one base does not, merely by being assigned to + that base, satisfy the evidential criteria relied on for another. + Distinctions of this kind, between stages of an action's lifecycle + whose evidence does not carry across, are long established in + distributed-systems practice (for example the separation of a remote + procedure call's invocation from its execution and its result). One + executable realization that binds exact predicates to these four + bases appears in [I-D.sergeev-wexp-core]. This document does not + depend on it. + + Two further distinctions cut across the bases. Verification reach + (who can check a record) is orthogonal to claim strength: a third- + party-verifiable invocation record is still invocation evidence. And + asserted content differs from observed content: a mediator's record + may faithfully report what the mediator asserts about a downstream + outcome it never observed. A useful record says at which boundary it + was produced and whether each statement in it was observed there or + merely asserted there. + + The action referred to by a claim should be identified at the + relevant boundary. A business intention, an authorization, a request + attempt, an execution, and a durable effect need not have a one-to- + one relation. Retries, proxies, and idempotent processing can change + those relations. A composite claim depends on evidence establishing + the particular bindings it uses. This document prescribes no common + identifier format. + +5. The claim ceiling + + A claim dimension is a family of claims that the same kind of + evidence bears on, such as the bases of Section 4. On a stated + dimension, and under stated premises, a producing boundary limits the + claims its evidence can support. Call that limit its claim ceiling. + The term does not presume that all claims on a dimension are + comparable, or that one uniquely strongest claim exists. + + A boundary in a position to observe invocations, but not execution, + cannot warrant execution claims. That holds no matter how many well- + formed execution assertions its records carry. + + + + + +Sergeev Expires 21 March 2027 [Page 6] + +Internet-Draft Claim Boundaries September 2026 + + + The underlying idea is old and this document claims no priority for + it: a conclusion cannot be stronger than the vantage from which its + supporting evidence was produced. Prior and operational formulations + of the same limit, and this document's relationship to them, are + described in Section 13. None of them is needed to state or apply + the rule as given here. + + Two properties keep a claim ceiling honest. + + The first is that it is an exclusion rule, not an evidence source. + It can prevent a stronger claim from being supported, but it never + creates support. A supported claim still requires positive evidence + at its own base. + + The second is that the ceiling is only as good as the grounding of + the boundary description itself. A boundary descriptor asserted by + the producer is the producer's account. A signature can attribute it + to a key holder. Separate evidence can attest it. But attribution + is not proof of actual boundary control, and a relying party that + accepts a self-described boundary has accepted the producer's framing + of what was observable. + + Grounding a boundary description need not be technical. A preserving + repository may undergo external certification. Its account of its + own custody, fixity, and succession practice is then assessed against + a published standard by a body the repository does not control + [ISO16363], under a separate regime that sets requirements for the + bodies performing that audit and certification [CCSDS652-1]. + + A relying party that relies on such an assessment rather than on the + repository's own account is bounded by what the assessment actually + examined. + + The accepted boundary description must apply to the time and + deployment context of the claimed action. A later assessment or a + current configuration does not, by itself, establish the earlier + boundary's properties. + + The same applies to any premise that would make the producer's + records informative without observation. Where a claim rests on the + producer's incentives or objectives being known, that knowledge is + itself a premise requiring its own grounding. An alignment asserted + by the producer is the producer's account. + + A record that requires no later cooperation from the party whose + conduct is at issue is not, for that reason, independent of that + party. A record it made at the time and left in place needs nothing + from it afterwards and remains its own account of itself. The + + + +Sergeev Expires 21 March 2027 [Page 7] + +Internet-Draft Claim Boundaries September 2026 + + + distinction between independence from cooperation and independence of + the evidence itself follows an exchange with Douglas Wadkins; see + [I-D.wadkins-agentproto-action-determinability]. + + A claim ceiling is relative. It is stated for one claim dimension, + at one observation boundary, with the support relation proper to that + dimension: which evidence supports which claim on it. Examples are + the bases of Section 4 and, separately, the prevention claims and the + detection claims of Section 8. + + Claims on different dimensions are not ranked against one another by + a ceiling. An execution claim and a detection claim are distinct + facets, not points on one scale, and this document defines no scalar + scale, level, or score on which all claims are ordered. "Stronger" + and "weaker" in this document are always read within the dimension at + issue. + +6. Non-inference rules + + The following rules restate Section 3 as individual limits. Each + names an inference that is invalid without additional, separately + established premises. None is original here; scoped versions of + several appear in the documents cited in Section 13. + + The rules state bounded limits on inference. Inclusion requires an + explicit scope and a checkable justification of the stated limit. + Analytical justification, relevant prior work, and documented + practical cases are identified separately, and a documented case is + not a prerequisite for inclusion; claims about practical occurrence + or consequences require their own support. Neither an illustrative + example nor a standards reference is presented here as a documented + incident. + + The list is not closed. The set has grown as readers reported + promotions the earlier rules did not reach. A reader who finds a + promotion these rules do not name has found a gap in this section, + not a licence for the promotion. + + 1. Successful signature verification does not by itself establish + the truth of an event claim in the signed content. Establishing + that correspondence requires grounds beyond signature validity. + Separately, signature validity alone does not establish the + signer's control of the boundary described by the claim. The + same distinction is drawn for verifiable credentials, where + verifiability of a credential does not imply the truth of the + claims encoded in it [VC-DATA-MODEL], and for signed DID + documents, where proofs in the document do not by themselves + necessarily prove control over the DID [DID-CORE]. + + + +Sergeev Expires 21 March 2027 [Page 8] + +Internet-Draft Claim Boundaries September 2026 + + + 2. Attribution of an actor is not proof of actorship. That a + record is attributed to a party -- by a key, an identifier, or a + credential associated with that party -- does not establish that + the party performed the action, where another party can obtain, + invoke, or emulate the attributed capability. Where one party + creates or hosts another and can reach that other's signing or + authenticating capability, an action attributed to the hosted + party may have been performed by the host. + + 3. A receipt, record, or registration is not external execution or + effect. Registration establishes that a statement entered a log + or service under that service's policy. Matching records held + by different parties establish that the parties agree about + content (correspondence). Correspondence does not establish + which event preceded which (precedence), and it does not + establish occurrence. + + 4. Presence of records is not completeness of coverage. A set of + records, each individually authentic, does not establish that + the set is all the records there are. Detecting omission + requires something the retained records cannot supply: an + independently grounded expectation of the complete population, + or a recording boundary that cannot be bypassed. + + 5. Absence of a record is not non-occurrence, unless the + observation regime supports that inference. The inference from + "no record" to "no event" is valid only where a declared, + enforced recording boundary meets three conditions. It covers + the event class. It cannot be bypassed by the parties in + question. And gaps in the record stream are themselves + detectable, for example against a pre-declared cadence or + sequence carried in the records and watched by a party outside + the producer. Otherwise absence is only absence. + + Such an inference also requires an identified interval, evidence + that the required recording and delivery coverage held for that + interval, and resolution of relevant delays and gaps. + Detectability of a gap does not license a non-occurrence claim + while the gap remains unresolved. The conclusion is limited to + the specified event class, population, and interval under the + stated assumptions. + + + + + + + + + + +Sergeev Expires 21 March 2027 [Page 9] + +Internet-Draft Claim Boundaries September 2026 + + + Bypass of the recording boundary is not the only way a record + can fail to appear. A record may have been made and then + withheld, whether by a retention policy that removed it or by a + disclosure decision that did not produce it + [AP-SCHROCK-RETENTION]. Where either is possible, the result is + a statement about the evidence set examined and not about the + recording boundary, and the conditions above are not met by the + boundary alone. + + 6. Authority granted is not action performed. Authorization + evidence, however exact, single-use, and attenuated, bounds what + a grant permits at the point where it is enforced. It does not + establish that the authorized action occurred. What is missing + is evidence on the action's own basis: an observation of + invocation or of execution, at a boundary in a position to make + it, or a record that constitutes the action rather than + describing it (Section 4 and Section 9). + + 7. Internal observation is not independent observation of an + external effect. A record produced inside the acting party's + boundary can establish, at most, what that boundary observed; + statements in it about effects at other systems are assertions. + In particular, a record minted by the deciding or authorizing + side cannot by itself establish the order of its own decision + against an effect that side does not observe. + + 8. Time and sequence evidence is bounded by the observation and + control properties of its source, like any other evidence. A + timestamp or sequence number is only as strong as the party and + mechanism that produced it: one minted by the interested party + over its own record orders that record, not the world. This is + not a claim that time evidence is worthless. Trusted time- + stamping has a distinct and stronger evidentiary role: a time- + stamp token from an appropriately trusted authority is evidence + that a datum existed before a particular time [RFC3161]. And a + sequencing mechanism whose observational domain covers both of + two events can order them. The rule is that the strength of the + time or sequence claim follows the source, and must not be read + past what that source observed and controlled. + + 9. A missing or unverifiable load-bearing premise cannot be + silently promoted. Where support for a claim depends on a + premise that was not evaluated, or that only the interested + party can vouch for, the claim inherits that limitation. The + honest output is the weaker claim, or the same claim explicitly + conditioned on the producer's own account. + + + + + +Sergeev Expires 21 March 2027 [Page 10] + +Internet-Draft Claim Boundaries September 2026 + + + 10. Current authentication, when its verified scope is limited to a + present binding, does not by itself establish identity + continuity or succession relative to an earlier subject. + Identity continuity, succession, and the present applicability + of prior authorization, standing, or reputation are distinct + claims. Each requires grounds covering the specific relation or + applicability asserted under the relevant identity and + authorization rules. A record's evidentiary force depends on + those rules and its verified properties, not merely on its + statement of the claim. DID Core states the corresponding limit + for persistent identifiers: absent published operational + policies, requesting parties are not expected to assume that an + identifier is persistent for the same subject [DID-CORE]. + + Every rule here is stated against premises. The premises a + conclusion rests on, their grounds, and their status should be + available directly or by unambiguous reference. A premise accepted + as a matter of policy is not thereby independently established. + Where the premises change, whether the conclusion remains warranted + has to be checked rather than assumed. + + Aggregation, transformation, summarization, and re-signing remove + none of these limitations. A pipeline that normalizes, merges, or + re-encodes evidence inherits each relevant limitation of its inputs + unless a specific limitation is specifically resolved by additional + evidence. An unsupported widening of a claim at the output of such a + pipeline is a defect to locate, not a result to report. + +7. A claim-boundary review lens + + The rules above can be applied as a short checklist when reviewing a + specification, a deployment, or an evidence design. For a given + claim, ask: + + 1. Exact claim. What exact claim, about what exact action, is + being made? + + 2. Producing boundary. Which boundary produced the supporting + evidence, and what could that boundary observe? + + 3. Control, bypass, suppression. Who controls that boundary? Can + the interested party bypass it, or suppress or alter its output + unobservably? Did those properties hold at the relevant time? + + 4. Ceiling. On the claim dimension at issue, what claim or claims + can that boundary warrant? Does the asserted claim exceed them? + + + + + +Sergeev Expires 21 March 2027 [Page 11] + +Internet-Draft Claim Boundaries September 2026 + + + 5. Positive evidence. Is there positive evidence at the claim's + own base, or is the claim resting on a ceiling, a signature, or + a registration that excludes stronger claims but supplies none? + + 6. Prevention, detection coverage, or a particular finding. If the + claim is that misbehavior is prevented, which independently + controlled enforcement point does it rest on (Section 8)? If + the claim is that misbehavior of a specified class cannot be + concealed, which independently controlled observation and + delivery dependencies does that coverage rest on? For a claim + that a particular event was detected, which evaluation act + (evaluator, predicate, evidence basis, window or context) is + identified? + + 7. Observation of effect. Is the consequential effect observed at + a boundary outside the interested party's control, whether an + external footprint or the relying party's own observation + boundary (Section 9)? + + 8. Completeness and absence. Does the claim depend on the record + set being complete, or on an absence meaning non-occurrence? Is + that supported (rules 4 and 5)? What interval and delivery + horizon were evaluated, and were relevant gaps resolved? + + 9. Pipeline widening. Does any step between production and + reliance widen the claim beyond what the producing boundary + supported? + + 10. Reporting category. When the evidence falls short, is the + outcome reported as a downgrade, unsupported, not established, + or unverifiable (Section 11), rather than silently rounded up? + + The considerations sections of [RFC3552] (security) and [RFC6973] + (privacy) are the models for this genre: a document states, in its + own terms, what its mechanisms do and do not establish, and what + residual exposure remains. This lens applies the same documentation + discipline to the semantic strength of execution-related claims. It + is a review aid, not a conformance procedure. + +8. The control-topology test + + Claims that an architecture prevents or detects misbehavior are + execution-related claims about the architecture itself, and they are + bounded the same way. Farrell's (a,b,c) scenario, described in + Appendix A, motivates the control-topology test used here. Stated + mechanism-neutrally: + + Prevention: A claim that party B is prevented from performing or + + + +Sergeev Expires 21 March 2027 [Page 12] + +Internet-Draft Claim Boundaries September 2026 + + + forging an action requires an enforcement point that B does not + control and cannot bypass, positioned so that the action cannot + complete without it. A component outside B's control that is not + actually required for the action prevents nothing. + + Detection coverage: A claim that misbehavior in a specified class + cannot be concealed by B requires two things. + + Evidence: adequate to distinguish that misbehavior under the + stated assumptions. + + Controls: delivery or omission controls that prevent B from + hiding it without an observable indication. + + The claim should state its coverage, timing, and failure limits. + These coverage conditions are distinct from establishing that a + particular event was detected from evidence already obtained. + + Independence: The prevention and coverage properties above depend on + deployment and control, relative to the stated party, claim, and + threat model. Independence is established by who actually + operates the enforcement or observation point and through whose + hands its output travels. A distinct key, component name, field, + label, second log, or organizational name does not, by itself, + establish those properties. + + An architecture claiming prevention or adversary-resistant detection + coverage should set out three things: + + * which independently controlled enforcement or observation + dependencies the guarantee rests on; + + * what the relevant bypass, forgery, and suppression limits are; + + * what happens when a dependency is unavailable or cannot be + validated. + + Without those dependencies, that guarantee is not established against + adversarial B, whatever its message formats carry. This does not + invalidate a narrower finding supported by evidence that has actually + been received and evaluated. + + A protected observation path is not, by itself, sufficient for + detection. The evidence must support a check that distinguishes the + specified misconduct under the stated assumptions. An observable gap + can establish a loss of coverage without establishing which + underlying event occurred. + + + + +Sergeev Expires 21 March 2027 [Page 13] + +Internet-Draft Claim Boundaries September 2026 + + + A claim that a particular event was detected requires an identifiable + evaluation act. The record should name which evaluator evaluated, + which predicate was checked and with what result, and on what + evidence basis. Where a window or context applies, it should name + that too. + + Such a finding does not, by itself, establish that all events of that + class were detectable or detected. A path that could have revealed + an event is not a record that anyone looked. This document defines + no format for stating those items. + + Existing mechanisms slot into this test rather than exempting + themselves from it. Remote attestation [RFC9334] contributes where + three conditions hold: + + * the Evidence covers the property at issue; + + * the adversarial party can neither forge nor substitute the + Evidence or the Attestation Result, nor control the appraisal + path; + + * the result is freshly and securely bound to the relevant actor and + action. + + RFC 9334 permits its roles to be aggregated into one entity, so + independence from a given party is a property of the deployment, not + of the architecture. + + Threshold signing [RFC9591] contributes a prevention dependency + exactly where the adversarial party cannot reach the threshold + without an independently controlled signer that checks the exact + operation and can withhold its share. These mechanisms contribute + only to the properties and dependencies actually established by their + deployment. + + OAuth sender-constraining mechanisms such as DPoP [RFC9449] can limit + the use of stolen tokens. They do not by themselves prevent B from + invoking a key through a signing interface B controls. That holds + whether the key was provisioned by another party or stored as non- + exportable. + + An isolated execution environment, including a trusted execution + environment (TEE), can contribute an enforcement dependency where B + cannot modify or bypass the relevant checks. Claims about effects + outside that environment still require an appropriate evidence basis. + + + + + + +Sergeev Expires 21 March 2027 [Page 14] + +Internet-Draft Claim Boundaries September 2026 + + + The WIMSE architecture [I-D.ietf-wimse-arch] separates workload + authentication from authorization and permits different placements of + policy enforcement. The test therefore asks who controls the + deployed enforcement point and which operations it covers, rather + than treating workload identity or credential provisioning as + evidence that the claimed operation occurred. + + The independently controlled point need not be cryptographic. A + preserving repository may be audited and certified against a + published standard [ISO16363], by a body the repository does not + control and which is itself accredited under a separate regime + [CCSDS652-1]. That contributes a detection dependency on two + conditions. The audit observes the practice at issue. The audited + party cannot suppress an adverse finding without the suppression + becoming visible. + + That contribution is limited by the audit's scope, period, sampling, + access, and reporting arrangements. Certification alone does not + establish complete observation of all relevant conduct, nor the + visibility of every suppressed adverse finding. The recursion + terminates in an accreditation body that some party must be prepared + to treat as terminal. + + The test is indifferent to whether the point outside the party in + question is a key, a verifier, or an accreditation regime. It asks + only whether the deployment placed one there, and what that point + actually covers. + +9. When stronger claims become supportable + + The discipline is not only subtractive. Stronger claims about a + particular effect become supportable when the effect is observed at a + boundary capable of observing it. That capability is judged under + the stated threat and control model. The evidence of that + observation must also be protected against undetected fabrication or + alteration by the interested party. Coverage claims additionally + depend on the observation and delivery conditions described in + Section 8. + + An external footprint is one important route to such observation. + Examples are movement on a payment rail, and resource or + configuration records in an external provider's control plane. In + each, a system the interested party does not control observed + something at its own boundary, and a relying party can check that + system's records against the claim. + + It is not the only route. The observing boundary may be any of + several things: + + + +Sergeev Expires 21 March 2027 [Page 15] + +Internet-Draft Claim Boundaries September 2026 + + + * an external service, a counterparty, or a settlement system; + + * an external control plane; + + * the relying party's own observation boundary, where the relying + party itself observes the effect: a state change in a system it + operates, or a delivery it takes receipt of itself; + + * another point that is in a position to observe the relevant fact + and that the interested party does not control under the stated + threat model. + + A distinct third party is not always necessary. The relying party's + own observation may provide the required evidence, subject to the + same claim-specific trust and deployment assumptions. + + A further route relies on a record constituting the precise action + claimed, rather than describing a separate action: + + * a signed order that is the order; + + * a recorded state transition on a ledger that is the transfer; + + * a recorded command whose issuance is itself the claimed action; + + * a write-ahead entry that defines the commit. + + Such a record supports that precise claim, because issuing or + accepting it constitutes the action under the applicable rules. The + evidence must establish the conditions that give the record that + constitutive effect, including any applicable authority, acceptance, + and commit or finality conditions. A record on a branch that was + never accepted does not constitute the action merely by resembling + one that would. + + What it supports is bounded by the action it constitutes and extends + no further. A ledger entry that is the transfer establishes the + transfer, not that goods moved. A signed order that is the order + establishes the order, not that it was carried out. Where a record + describes an action it does not constitute, this route does not + apply. + + The qualifications travel with the pattern: + + + + + + + + +Sergeev Expires 21 March 2027 [Page 16] + +Internet-Draft Claim Boundaries September 2026 + + + * The observing boundary supports claims at its own observation + boundary and no further. A payment network's record establishes + what the network observed about a transfer at its boundary, not + that a business obligation was satisfied. A relying party's own + observation establishes what the relying party observed at its + boundary, and no more. + + * The observation, whether an external footprint or the relying + party's own, must be bound to the exact action claimed. A + matching amount, timestamp, or counterparty is correlation, and + correlation supports weaker claims than a validated binding. + + * The protection afforded by the observing boundary is itself a + threat-model statement. For a particular finding, the relevant + protection is against the operator of the acting system + fabricating or undetectably altering the evidence for the claimed + observation. Against the operator of the observing boundary + itself, the pattern gives no additional support. Where the + relying party observes at its own boundary, the claim rests on the + relying party's own observation, which is independent of the + interested party but not of the relying party. + + * Ordering claims, such as that the decision preceded the effect, + require an ordering relation whose observational domain includes + both terms. That means one boundary that observed both, or + records from the two boundaries that can be securely related and + ordered. Matching records alone establish neither the order of + the records nor the order of the events. + + * The ability to prevent an observation from being made, to bypass + its boundary, or to withhold the resulting evidence does not, by + itself, invalidate evidence that has been received. Subject to + the qualifications above, the received evidence may support a + particular finding within its observational and temporal scope. + It does not, by itself, establish completeness or the absence of + contrary observations. Any finding that depends on the + completeness of a specified evidence set or on absence as evidence + of non-occurrence requires the corresponding coverage and gap- + resolution basis (rules 4 and 5). + + Deployments that want strong claims should therefore prefer actions + whose effects are observable at a boundary outside the interested + party's control. That may be an external footprint or the relying + party's own observation. They should also prefer evidence that binds + those observations to exact actions, over additional self-produced + artifacts. + + + + + +Sergeev Expires 21 March 2027 [Page 17] + +Internet-Draft Claim Boundaries September 2026 + + +10. Worked example: a payment + + Consider an agent that reports having paid a supplier. Three + evidence artifacts and a report combining them are on the table. The + point of the example is that they support different claims, and that + a report must keep separate what each boundary observed from what it + merely asserts. + + 1. A self-produced execution record. The operator's own service + emits a signed record: "paid supplier S, amount X, at time T". + Observed at that boundary: that the operator's service produced + and signed this statement. Asserted, not observed there: that + the payment reached S. What it supports on its own: that the + operator stated a payment; not that the payment occurred (rules + 1, 3, 7). + + This example assumes that the record contains only the operator's + own statement. If it carries independently verifiable evidence + from another source, that evidence is appraised at its own + producing boundary. The party assembling the container does not + determine every item's origin. + + 2. A transparency registration. The signed record is registered + with a transparency or receipt service, yielding an inclusion + proof. Observed: that this statement was registered under the + service's policy. Any claim about registration time depends on + the time evidence provided and its verified scope. Not + established: the truth of the statement or the occurrence of the + payment (rule 3). Registration raises auditability, not the + claim ceiling. + + 3. External payment-network evidence. A record from the payment + network -- a settlement entry or network-issued confirmation -- + that the network observed a transfer matching the action. + Observed at a boundary outside the operator's control: that the + network saw a transfer with these attributes. This is the + footprint of Section 9. It must be bound to the exact action. A + bare amount-and-time match is correlation. Its strength holds + against the operator, not against the payment network's own + operator. + + 4. A composite report. A report that draws on all three should + read, in substance, as three statements. The operator asserts a + payment (1). The assertion is registered and independently + checkable as an assertion (2). And where (3) is present and + bound to the exact action, a system outside the operator observed + a matching transfer at its boundary. That last supports a + payment-reached-the-network claim, to the extent the binding + + + +Sergeev Expires 21 March 2027 [Page 18] + +Internet-Draft Claim Boundaries September 2026 + + + holds and that evidence is protected against fabrication or + undetected alteration by the operator. Absent (3), or another + observation of the transfer at a boundary outside the operator's + control (Section 9), the supportable claim is that the operator + stated and registered a payment, not that a payment occurred. + + The example makes no universal assertion about what any particular + service observes. What a given payment service, transparency + service, or agent runtime actually observed is a fact about that + deployment, to be stated from its evidence, not assumed from its + role. + +11. Reporting what the evidence supports + + Where evidence does not support the claim asserted over it, the + useful output is not a bare failure. The distinctions that matter to + a relying party: + + Downgrade to the supportable claim: Report the strongest claim on + the dimension at issue that the evidence does support, or the + supported claims where there is no unique strongest one, alongside + the asserted claim it does not. "Invocation established; + execution asserted only" is actionable; "invalid" is not. + + Unsupported: The relevant assessment ran over the evidence + evaluated, and that evidence failed it. This is a finding about + the evaluated evidence, relative to the evidence set and the + appraisal context in which it was evaluated. It is not a property + of the world, and a different evidence set may support the claim. + + Not established: The assessment did not run, the evidence was not + available, or the premise was outside the evaluation's scope. The + evaluated material does not establish the claim. It does not + establish the negation of the claim either. This is the absence + of a finding, and it is not refutation. "Not established" does + not mean the claim is false. Nor is it permission to discard + evidence that positively supports a claim at its own base. A base + well supported by its own evidence stays supported, even while a + stronger claim over it is not established. Collapsing "not + established" into "unsupported", or either into "refuted", + destroys information a relying party needs: "we checked and it + failed" and "we could not check" call for different decisions. + + Unverifiable: The statement is one that the evaluator in question + cannot check from the evidence and inputs available to it at the + time of evaluation. The standing example is a producer's + description of its own deployment, which an evaluator may be + unable to check without deployment access or other adequate + + + +Sergeev Expires 21 March 2027 [Page 19] + +Internet-Draft Claim Boundaries September 2026 + + + evidence about that deployment. The category is relative to a + verifier or evaluator, and to an evidence or input set. Where + they matter, it is relative to an evaluation context or time as + well. A statement unverifiable to one evaluator may be verifiable + to another with access the first lacks. Such statements can still + be worth carrying. They should be marked as resting on the + producer's account, so a reader can see which parts of a composite + claim rest on trust. + + The category is relative to an evaluator and, where relevant, to a + moment. So a statement can pass from verifiable to unverifiable + while the record itself is unchanged. The evaluator that could + check it may cease to exist. It may lose the access it depended + on, or the means to interpret what it holds. + + A report that fixes the category without fixing the evaluator and + the moment says less than it appears to. + + These distinctions are not a mutually exclusive result-code set. + Unverifiability may explain why a claim is not established, while the + same report identifies a weaker claim that is supported. Where the + evidence establishes the negation of a claim, the report should state + that finding and its basis explicitly rather than treating it as mere + absence of support. + + Each of these categories is relative to the evidence actually + evaluated, and a report is more useful when it says what that + evidence was. The evaluated set may itself be incomplete or + selected. Every record in it can verify while records that would + have changed the outcome were never delivered: rule 4 of Section 6, + met again at the reporting layer. + + A verdict stated over a named evidence basis is a verdict over that + basis, not over all evidence that exists. A verdict that does not + name its basis invites exactly the widening this document is about. + + Appraisal results travel. One evaluator's result may be consumed by + a later composite report: that a claim is not established, for + instance. The later relying party then needs to distinguish an + attributable appraisal from an unattributed conclusion. + + Propagated or aggregated appraisal results should therefore retain + enough provenance to identify three things: + + * who or what appraised; + + * the evidence or input basis, or a stable reference to it; + + + + +Sergeev Expires 21 March 2027 [Page 20] + +Internet-Draft Claim Boundaries September 2026 + + + * the predicate, profile, or evaluation context under which the + result was reached, including the boundary at which the appraisal + was made. + + Without that, "not established" degrades across aggregation into + somebody's unattributed conclusion. That is the aggregation limit of + Section 6 arriving at the reporting layer. + + This is a consideration for reporting designs. It is not a record + format and not a general retention requirement. The provenance of an + appraisal establishes who appraised what, under which context. It + does not establish that the underlying event occurred. + + A reporting design that preserves these distinctions makes inflation + visible: every summary that would erase one of them is a place where + a stronger claim would otherwise silently replace a weaker one. + +12. Applicability beyond AI agents + + Nothing in this discipline is stated in terms specific to AI agents. + The same bounding questions apply to: + + * audit logging and monitoring pipelines, where the questions are + what the log source observed and who can write to it; + + * evidence collection and archiving practice [RFC3227]; + + * signed system logs [RFC5848]; + + * transparency systems ([RFC9162], [RFC9943]); + + * long-term evidence records [RFC4998]; + + * compliance reporting and incident forensics; + + * operational telemetry, which is self-reported by instrumented code + and designed for diagnosis rather than adjudication. + + Agent systems sharpened the problem. Actions are initiated by + software whose records are produced mostly at the acting side, and + delegation chains multiply the boundaries across which claims travel + and inflate. But the rules in Section 6 are stated as properties of + evidence rather than of agents. + + One domain is worked here: the long-term preservation of records, + where no agent acts and no payment is made. It was chosen because it + shares neither substrate nor vocabulary with the example of + Section 10. + + + +Sergeev Expires 21 March 2027 [Page 21] + +Internet-Draft Claim Boundaries September 2026 + + + A preserving repository holds a record deposited by its creator. + Different claims about that record require different evidence. + Fixity evidence can support a claim that deposited bytes have not + changed relative to an accepted baseline. Identity and provenance + evidence may support an authenticity assessment under stated + assumptions. + + Neither finding, by itself, establishes that the record was reliable + when created or that its content was accurate. Evidence about its + creation process may come from the creator or from other sources, and + may itself be preserved by the repository. Preservation does not + convert custody integrity into truth of the original content. That + is an instance of the claim ceiling of Section 5. + + A correctly maintained chain of archive time-stamps can preserve + previously established integrity and existence-at-time evidence under + its cryptographic and time-source assumptions [RFC4998] [RFC3161]. + Recomputing a digest alone does not establish when the data existed, + and renewal does not establish the truth of their content (rules 1 + and 8 of Section 6). + + A gap in a deposited series supports no conclusion about what was + never deposited, unless the deposit regime was declared, enforced, + and observable to a party outside the depositor. Where such a regime + exists, the inference it licenses belongs to the regime and not to + the retained records (rule 5). + + Whether a preserved record can still be evaluated depends on the + record, the available representation and provenance information, and + the evaluator's knowledge and access. This illustrates the + evaluator- and time-relative unverifiability discussed in Section 11. + OAIS addresses continued understandability for an identified + Designated Community, including the information needed to interpret + preserved content [ISO14721]. + + Two public findings state the same bound outside computing entirely, + in the words of the bodies that made them. + + In the English prosecutions arising from the Post Office Horizon + accounting system, the Court of Appeal found that the prosecutor + "treated what was no more than a shortfall shown by an unreliable + accounting system as an incontrovertible loss", and that defendants + were convicted "on the basis that the Horizon data must be correct, + and cash must therefore be missing, when in fact there could be no + confidence as to that foundation" [HAMILTON]. + + + + + + +Sergeev Expires 21 March 2027 [Page 22] + +Internet-Draft Claim Boundaries September 2026 + + + The load-bearing premise was the reliability of that system. The + court recorded three things about it. The prosecutor was under a + duty to investigate subpostmasters' claims that there were problems + with it. The prosecutor represented it as reliable while "refusing + to countenance any suggestion to the contrary". And its "failures of + investigation and disclosure" were "so egregious as to make the + prosecution of any of the 'Horizon cases' an affront to the + conscience of the court". + + On the reading taken here, that is the position rule 9 of Section 6 + names. The claim rested on a premise the relying party was required + to test and did not adequately test, and whose contrary material it + did not disclose. + + The court's findings are its own. The connection drawn to the rule + is this document's. The judgment does not address what a bounded + report of the same evidence would have said, and is not cited for + that part of the rule. + + In the inquiry into the Grenfell Tower fire, the panel considered a + large-scale fire test. Failure to meet its performance criteria + would show a system unlikely to comply with the applicable + requirement. But "the converse was not necessarily true": a system + might meet the criteria and still perform unacceptably in use + [GRENFELL2]. A bounded test result refuses a claim in one direction + and does not establish it in the other. + + A third case shows the bound where the test results themselves were + genuine outputs of a genuine test. Vehicles were certified against + emissions standards on the strength of those results. Software + detected the test condition and enabled full emissions controls only + then, so the vehicles "meet emissions standards in the laboratory or + testing station, but during normal operation" emitted up to forty + times the NOx standard [EPA-VW]. The result established the + behaviour of the vehicle under the conditions the test applied, which + was all it had ever observed. The certificate carried it to a claim + about the vehicle in use (Section 5 and rule 7 of Section 6). + + These authorities reached findings within their own legal and + regulatory settings, each asking what a record before it established. + Their connection to the rules stated here is this document's reading. + + Applicability to the other domains listed above is asserted on the + same grounds and is not worked case by case here. + + + + + + + +Sergeev Expires 21 March 2027 [Page 23] + +Internet-Draft Claim Boundaries September 2026 + + +13. Related work + + The following work provides established mechanisms and domain- + specific treatments relevant to these limits. This document collects + selected implications for the appraisal of execution-related claims. + + Non-bypassable mediation and tamper-evident logging: Two older + lineages give this discipline its positive content. The + reference-monitor lineage established that a security-relevant + decision is only enforced where every access is mediated by a + mechanism the controlled party cannot bypass and cannot tamper + with -- the prevention half of Section 8. The tamper-evident and + transparency-logging lineage established that alteration or + equivocation in a record set can be made externally detectable -- + the detection half. + + Certificate transparency provides inclusion and consistency checks + over log views [RFC9162]. A misbehaving log can nevertheless + present inconsistent views to different clients. Detecting that + behavior depends on comparing relevant observations, or on other + mechanisms and deployment assumptions that address such split + views. + + This document restates the boundary conditions those lineages + already identified. It adds no mechanism, and claims none of + them. + + Attestation: RFC 9334 [RFC9334] defines remote-attestation roles, + appraisal flows, and trust assumptions, including constraints on + Claims collection, the strength of Attestation Results, and the + separation of Attesting and Target Environments. EAT [RFC9711] + defines a claims token. This document draws on those established + concerns to organize a review discipline for execution-related + claims across artifact classes. It defines no remote-attestation + machinery. + + Transparency and receipts: COSE Receipts [RFC9942] convey proofs of + properties of a verifiable data structure, including inclusion and + consistency. Successful verification supports the specified data- + structure predicate under the applicable cryptographic and trust + assumptions. It does not, by itself, establish that an event + described in a registered statement occurred. SCITT [RFC9943] + applies transparency mechanisms to supply-chain statements and + explicitly addresses the limits posed by dishonest issuers. + Certificate transparency [RFC9162] provides log proofs whose use + remains bounded by the split-view problem set out earlier in this + section. These are established examples of bounded evidence + claims. + + + +Sergeev Expires 21 March 2027 [Page 24] + +Internet-Draft Claim Boundaries September 2026 + + + Supply-chain step attribution: in-toto [IN-TOTO] binds the artifacts + flowing between the steps of a software supply chain, the order in + which the steps were performed, and the identity of the party that + signed for each, against a layout declared in advance by the + project owner. Its no-key-compromise analysis assumes that the + developer host systems are not compromised and that no functionary + holding a valid key acts against the chain. Within those + assumptions the binding is strong. The paper separately analyzes + how the guarantees degrade under functionary or project-owner key + compromise. Both the assumptions and the degradation cases are + boundary statements of the kind this document asks producers to + make explicit. + + Record integrity, existence, and evidence handling: Signed syslog + [RFC5848], evidence records [RFC4998], time-stamps [RFC3161], and + evidence-collection guidance [RFC3227] protect integrity, origin, + ordering, existence-at-time, and chain-of-custody of records. + These protections do not, by themselves, establish that the events + described in the records occurred as described. + + Provenance: PROV [PROV-DM] models provenance as asserted + descriptions that feed trust assessment, not as verdicts. + + Prior formulations by the author: The four bases of Section 4 and + the ceiling of Section 5 restate, in generic terms and without the + level scale used there, content levels and the boundary axiom + (Axiom BC) of earlier joint work with Vladimir Ikher [WITMODEL]. + The Witnessability Conceptual Core states the conceptual + generalization of that axiom as a derived rule (the Boundary + Ceiling Rule of version 1.0) [WCC-CORE]. The WEXP appraisal core + [I-D.sergeev-wexp-core] gives an exclusion-only operational + realization that binds exact predicates to the four bases of + Section 4. + + This document uses the generic term and preserves that exclusion- + only role. It makes no claim of independent discovery or + priority. Its rules can be stated and applied without either + work. The author's interest in WEXP is disclosed below. + + Agent-protocol evidence work: Individual Internet-Drafts address + per-claim verifier, binding, freshness, and failure discipline + [I-D.bu-agentproto-security-principal-binding]; enrollment and + key-binding assumptions [I-D.yossif-enrollment-problem]; evidence + of authorization decisions [I-D.bradleyb-audit-decision-records]; + and an architecture for auditing agents' interactions and + delegation [I-D.kuehlewind-audit-architecture]. + + + + + +Sergeev Expires 21 March 2027 [Page 25] + +Internet-Draft Claim Boundaries September 2026 + + + An outcome-binding profile [I-D.schrock-ep-outcome-binding] + separates the authorization of an action from its observed effect. + It binds signed observations from executors, systems of record, + and independent observers to the same authorization, action + digest, and operation, with exact-equality checks on the action + and source bindings, plus relying-party-defined observation-window + requirements. It treats a declared control domain as relying- + party policy input rather than proof of independence. And it + returns an indeterminate state when required evidence is missing + or unauthenticated. + + Work on agent control delivery and outcome reconciliation + [I-D.abak-agent-control-delivery-evidence] distinguishes control + issuance and dispatch, receiver-side observation, enforcement + outcome, and observation of the resulting effect. + + A further draft [I-D.wadkins-agentproto-action-determinability] + states mechanism-independent requirements for making a claimed + agent transition independently determinable after the original + interaction has ended. It addresses the binding of the material + action and its governing conditions, a verification procedure that + establishes that those conditions actually governed the transition + when it occurred, determination without the cooperation of any + original participant, and negative, transferred, or incomplete + transitions. + + These works address related questions at specific boundaries. The + discipline here can be applied to the claims made over their + evidence. + + Non-inference rules stated for a record format: In the agent2agent + discussion of a dimensional model for agent-protocol proposals, + Blake Morrison set out three rules for records carried under + different extensions of one format [AP-MORRISON-RULES]. + + Non-inference: written about values, and so constrains what a + value carries rather than whether a record exists. + + Comparison: does reach existence, in Morrison's words: "the + absence of a matching record is reported as such rather than + compared against a value". + + Cross-extension: a record under one extension is not to be read + as evidence that a record under another extension exists, and + its value is not to be carried across. + + + + + + +Sergeev Expires 21 March 2027 [Page 26] + +Internet-Draft Claim Boundaries September 2026 + + + Morrison observed that the comparison rule reaches existence only + inside a comparison between two protocols, and that reading one + protocol's records on their own neither rule covers. That is the + boundary rule 5 of Section 6 draws for the general case. The + cross-extension rule is rule 4 of Section 6 scoped to one format: + the presence of one record does not establish the existence of + another. + + The third rule is stated there with requirement keywords, which + are not reproduced here because this document uses none. The + wording above is a paraphrase and the original is in the cited + message. + + These are proposals made on a mailing list, not text adopted in + any document. They are cited here as independent statements of + the same limits, not as support for this document. + + Considerations-section genre: RFC 3552 [RFC3552] requires every RFC + to state what its mechanisms do and do not protect; RFC 6973 + [RFC6973] guides documents, where their content warrants it, in + stating what privacy exposure remains. This document extends that + documentation discipline to the semantic strength of execution- + related claims. It does not own the practice. + + Records authenticity and long-term preservation: Archival + diplomatics states the distinction this document restates for + execution evidence, and states it earlier and for a different + substrate. The InterPARES programme separates three properties of + a record [INTERPARES] [DURANTI1998]. + + Reliability: its trustworthiness at the point of creation. + + Accuracy: the correctness of its content. + + Authenticity: that it is what it purports to be, with its + identity and integrity preserved in the respects the assessment + treats as essential. + + That assessment does not by itself carry reliability. Fixity + evidence supports a claim about preserved bytes relative to an + accepted baseline and does not establish reliability or accuracy. + + The reference model for an open archival information system + assigns a preserving repository the responsibility of keeping + preserved information independently understandable to an + identified Designated Community, including the representation + information needed to interpret it [ISO14721]. For repositories + that undergo external certification, the repository's own account + + + +Sergeev Expires 21 March 2027 [Page 27] + +Internet-Draft Claim Boundaries September 2026 + + + of its practice is assessed by an external body against a + published standard [ISO16363], under a regime that sets + requirements for those bodies [CCSDS652-1]. Such certification is + not a general property of preserving repositories. This document + applies the bounding relation those disciplines already state to + execution-related claims and to the control topology of the + producing boundary. It adds no preservation machinery. + + Authentication and admissibility in evidence law: The separation of + what an artifact is from what its content establishes is + normative, not only analytic. Under the United States Federal + Rules of Evidence, a certified record generated by an electronic + process, and a certified copy authenticated by digest comparison, + are self-authenticating. + + The advisory committee states three limits on that [FRE902]. Such + a certification establishes authenticity only. An opponent + remains free to object on hearsay, relevance, or confrontation + grounds. And authenticating a machine output establishes that the + output came from that system, rather than that the information it + carries is reliable. + + Under Federal Rule of Civil Procedure 37(e)(2), specified adverse + presumptions and remedies for lost electronically stored + information require a finding of intent to deprive, subject to the + rule's other conditions [FRCP37E]. This is a procedural rule, not + a general test of the logical strength of missing evidence. + + These legal examples illustrate bounded uses of evidence. Their + burdens, admissibility rules, and remedies remain outside this + document's scope. + + Assurance cases: The claims-argument-evidence tradition provides + structured argumentation over evidence. ISO/IEC/IEEE 15026-2 + specifies requirements for assurance-case structure terminology + [ISO15026-2], and the Goal Structuring Notation community standard + provides a notation for such arguments [GSN]. The presence of an + assurance case or a graphical representation does not, by itself, + establish that a particular evidential inference is justified. + +14. Security considerations + + This document defines no protocol and introduces no new attack + surface. Its subject is the prevention of a class of security + failures that occur at the semantic layer: relying parties accepting + claims stronger than the evidence supports. + + Cautions about the discipline itself, including its misuse: + + + +Sergeev Expires 21 March 2027 [Page 28] + +Internet-Draft Claim Boundaries September 2026 + + + * The discipline does not make a dishonest or compromised evidence + source honest. It bounds what a relying party should infer. It + does not improve the evidence. + + * "Not established" is not a licence to discard evidence. A finding + that a stronger claim is not established is not a basis for + setting aside evidence that positively supports a weaker claim at + its own base. The correct output is the supported weaker claim, + reported as such (Section 11), not the removal of the evidence. + + * Deliberately unobservable topology is a limitation to report, not + an exoneration. An interested party may arrange that its + enforcement or observation points cannot be checked by anyone + else. The correct conclusion is then that the corresponding + prevention or detection-coverage guarantee is unsupported by the + evidence available to the relying party: the independence it + requires cannot be shown, and the report says so. This does not + extend to every case-level finding that received evidence may + support. Unobservability is not evidence of good behavior. + + * Conformance vocabulary is itself inflatable. "Consistent with the + claim-boundary discipline" is not a property a document or product + can certify by assertion. The test is whether specific claims are + bounded by specific producing boundaries, checked claim by claim. + + * Detection mechanisms leak. Making refusals, gaps, or suppression + observable to an external party discloses timing and frequency + information to that party. Deployments should weigh the + observability required by Section 8 against what the observation + channel itself reveals; [RFC6973] is the model for stating that + residual exposure. + +15. IANA considerations + + This document has no IANA actions. + +16. Informative References + + [AP-ECKEL] Eckel, C., "Re: [Agentproto] Re: DRAFT minutes from the + AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 30 July 2026, + . + + + + + + + + +Sergeev Expires 21 March 2027 [Page 29] + +Internet-Draft Claim Boundaries September 2026 + + + [AP-FARRELL-ABC] + Farrell, S., "Re: [Agentproto] Re: DRAFT minutes from the + AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 29 July 2026, + . + + [AP-FARRELL-CHEAT] + Farrell, S., "Re: [Agentproto] DRAFT minutes from the + AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 30 July 2026, + . + + [AP-JIANG-CONTINUITY] + Jiang, Y., "Re: focused review request on security + principal binding, agent2agent", message to the + agent2agent mailing list, 15 September 2026, + . + + [AP-MORRISON-RULES] + Morrison, B., "[agent2agent] Re: New I-D : A Dimensional + Model for Characterizing AI Agent Protocol Proposals and + Their Substrates", message to the agent2agent mailing + list, 4 September 2026, + . + + [AP-SAMMARTANO] + Sammartano, S., "Re: [Agentproto] Re: DRAFT minutes from + the AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 30 July 2026, + . + + [AP-SAMMARTANO-FRAMING] + Sammartano, S., "Re: [Agentproto] Re: DRAFT minutes from + the AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 30 July 2026, + . + + + + + + + + + +Sergeev Expires 21 March 2027 [Page 30] + +Internet-Draft Claim Boundaries September 2026 + + + [AP-SCHROCK-RETENTION] + Schrock, I., "[agent2agent] Re: New I-D : A Dimensional + Model for Characterizing AI Agent Protocol Proposals and + Their Substrates", message to the agent2agent mailing + list, 14 September 2026, + . + + [AP-SERGEEV-GATE] + Sergeev, M., "[Agentproto] Re: DRAFT minutes from the + AGENTPROTO BoF", message to the agentproto@ietf.org + mailing list, 30 July 2026, + . + + [CCSDS652-1] + Consultative Committee for Space Data Systems, + "Requirements for Bodies Providing Audit and Certification + of Candidate Trustworthy Digital Repositories", + CCSDS 652.1-M-3, Issue 3, December 2024, + . + + [DID-CORE] World Wide Web Consortium, "Decentralized Identifiers + (DIDs) v1.0", W3C Recommendation, Sections 9.2 and 9.11, + 19 July 2022, . + + [DURANTI1998] + Duranti, L., "Diplomatics: New Uses for an Old Science", + Scarecrow Press, 1998. + + [EPA-VW] United States Environmental Protection Agency, "Learn + About Volkswagen Violations", agency overview of the Clean + Air Act violations, including the Notice of Violation of + 18 September 2015, September 2015, + . + + [FRCP37E] United States, "Federal Rules of Civil Procedure, Rule + 37(e), Failure to Preserve Electronically Stored + Information, with Advisory Committee Notes", December + 2015. + + [FRE902] United States, "Federal Rules of Evidence, Rule 902(13) + and Rule 902(14), with Advisory Committee Notes", December + 2017. + + + + + + +Sergeev Expires 21 March 2027 [Page 31] + +Internet-Draft Claim Boundaries September 2026 + + + [GRENFELL2] + Grenfell Tower Inquiry, "Grenfell Tower Inquiry: Phase 2 + Report, Volume 1", HC 19-I, Part 1, Chapter 2, paragraphs + 2.122-2.123, September 2024, + . + + [GSN] SCSC Assurance Case Working Group, "Goal Structuring + Notation Community Standard, Version 3", SCSC 141C, 2021, + . + + [HAMILTON] Court of Appeal (Criminal Division), England and Wales, + "Hamilton & Ors v Post Office Ltd", [2021] EWCA Crim 577, + paragraphs 136-137, 23 April 2021, + . + + [I-D.abak-agent-control-delivery-evidence] + Abak, A. T., "Evidence Requirements for Agent Control + Delivery and Outcome Reconciliation", Work in Progress, + Internet-Draft, draft-abak-agent-control-delivery- + evidence-01, 4 September 2026, + . + + [I-D.bradleyb-audit-decision-records] + B, B., "Signed Decision Records for Agent Authorization: + Disclosures, Entry Emission, and Ordering Evidence", Work + in Progress, Internet-Draft, draft-bradleyb-audit- + decision-records-00, 13 August 2026, + . + + [I-D.bu-agentproto-security-principal-binding] + Bu, S., "Security Principal and Verifier Binding for Agent + Communication Protocols", Work in Progress, Internet- + Draft, draft-bu-agentproto-security-principal-binding-07, + 15 September 2026, . + + [I-D.fengfar-led] + Farrell, S. and C. Feng, "Dealing with LLMs in IETF + Discussions", Work in Progress, Internet-Draft, draft- + fengfar-led-01, 6 August 2026, + . + + + + +Sergeev Expires 21 March 2027 [Page 32] + +Internet-Draft Claim Boundaries September 2026 + + + [I-D.ietf-wimse-arch] + Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload + Identity in a Multi System Environment (WIMSE) + Architecture", Work in Progress, Internet-Draft, draft- + ietf-wimse-arch-08, 6 July 2026, + . + + [I-D.kuehlewind-audit-architecture] + Kühlewind, M. and H. Birkholz, "An Architecture for + Auditing Agent Delegation and Interactions", Work in + Progress, Internet-Draft, draft-kuehlewind-audit- + architecture-01, 7 September 2026, + . + + [I-D.schrock-ep-outcome-binding] + Schrock, I., "Outcome Binding for Authorized Actions and + Independently Observed Effects", Work in Progress, + Internet-Draft, draft-schrock-ep-outcome-binding-00, 28 + July 2026, . + + [I-D.sergeev-wexp-core] + Sergeev, M. and V. Ikher, "The Witnessed Execution + Protocol (WEXP): Core Specification", Work in Progress, + Internet-Draft, draft-sergeev-wexp-core-01, 16 August + 2026, . + + [I-D.wadkins-agentproto-action-determinability] + Wadkins, D. L., "Independent Determinability of Agent + Actions", Work in Progress, Internet-Draft, draft-wadkins- + agentproto-action-determinability-00, 11 September 2026, + . + + [I-D.yossif-enrollment-problem] + Yossif, M. K., "Problem Statement: Enrollment and Key- + Binding Assumptions in Execution Authority Evidence", Work + in Progress, Internet-Draft, draft-yossif-enrollment- + problem-00, 22 July 2026, + . + + [IN-TOTO] Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, + R., and J. Cappos, "in-toto: Providing farm-to-table + guarantees for bits and bytes", 28th USENIX Security + + + +Sergeev Expires 21 March 2027 [Page 33] + +Internet-Draft Claim Boundaries September 2026 + + + Symposium, August 2019, + . + + [INTERPARES] + Duranti, L., "The Long-term Preservation of Authentic + Electronic Records: Findings of the InterPARES Project", + 2005, . + + [ISO14721] International Organization for Standardization, "Space + Data System Practices -- Reference model for an open + archival information system (OAIS)", also issued as CCSDS + 650.0-M-3, December 2024, ISO 14721:2025, Edition 3, March + 2025. + + [ISO15026-2] + ISO/IEC/IEEE, "Systems and software engineering -- Systems + and software assurance -- Part 2: Assurance case", + ISO/IEC/IEEE 15026-2:2022, 2022. + + [ISO16363] International Organization for Standardization, "Space + data and information transfer systems -- Audit and + certification of trustworthy digital repositories", + ISO 16363:2025, Edition 2, March 2025. + + [PROV-DM] World Wide Web Consortium, "PROV-DM: The PROV Data Model, + W3C Recommendation", April 2013, + . + + [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, + "Internet X.509 Public Key Infrastructure Time-Stamp + Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August + 2001, . + + [RFC3227] Brezinski, D. and T. Killalea, "Guidelines for Evidence + Collection and Archiving", BCP 55, RFC 3227, + DOI 10.17487/RFC3227, February 2002, + . + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + . + + [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence + Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, + August 2007, . + + + + +Sergeev Expires 21 March 2027 [Page 34] + +Internet-Draft Claim Boundaries September 2026 + + + [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog + Messages", RFC 5848, DOI 10.17487/RFC5848, May 2010, + . + + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + . + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + . + + [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate + Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, + December 2021, . + + [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and + W. Pan, "Remote ATtestation procedureS (RATS) + Architecture", RFC 9334, DOI 10.17487/RFC9334, January + 2023, . + + [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., + Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of + Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, + September 2023, . + + [RFC9591] Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood, + "The Flexible Round-Optimized Schnorr Threshold (FROST) + Protocol for Two-Round Schnorr Signatures", RFC 9591, + DOI 10.17487/RFC9591, June 2024, + . + + [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. + Wallace, "The Entity Attestation Token (EAT)", RFC 9711, + DOI 10.17487/RFC9711, April 2025, + . + + [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. + Fournet, "CBOR Object Signing and Encryption (COSE) + Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, + . + + + + + + + +Sergeev Expires 21 March 2027 [Page 35] + +Internet-Draft Claim Boundaries September 2026 + + + [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, + Y., and S. Lasker, "An Architecture for Trustworthy and + Transparent Digital Supply Chains", RFC 9943, + DOI 10.17487/RFC9943, June 2026, + . + + [VC-DATA-MODEL] + World Wide Web Consortium, "Verifiable Credentials Data + Model v2.0", W3C Recommendation, Section 1.1, 2025, + . + + [WCC-CORE] Sergeev, M. A., "Witnessability Conceptual Core 1.0", + DOI 10.5281/zenodo.21865251, July 2026, + . + + [WITMODEL] Sergeev, M. A. and V. Ikher, "Toward a Witnessability + Model for AI and Software Execution Systems: A Boundary- + Based Framework for Classifying Execution Evidence", + Version 1.1, bridge revision; also at DOI 10.2139/ + ssrn.6994720, August 2026, + . + +Appendix A. The (a,b,c) scenario worked through + + In the agentproto mailing-list discussion of July 2026, in the thread + on the draft minutes of the AGENTPROTO BoF, Stephen Farrell posed a + gating scenario [AP-FARRELL-ABC]. In his words: + + If (a,b,c) is a comms path between agents (perhaps within a tree) + and if 'c' is actually a newly created entity, but one that needs + access to a long-term secret credential accessible at 'a' (e.g. + pwd or SSH private key) and where that credential must not be + exposed to 'b' nor easily abused - then how's that going to work? + + He emphasized that "the scenario I posited is one where 'b' creates + 'c' and so is in a fine place to cheat" [AP-FARRELL-CHEAT]. + + The list discussion produced concrete mitigations, collected in a + reply by Shawn Sammartano [AP-SAMMARTANO], who credited most of them + to existing mechanisms: + + * exact, single-use, attenuated permission slips bound to request + bytes; + + * hardware-protected keys, and threshold signing; + + * short-lived credentials, and forward-moving counters; + + + + +Sergeev Expires 21 March 2027 [Page 36] + +Internet-Draft Claim Boundaries September 2026 + + + * delegation budgets, and delays with cancellation windows; + + * approval separated from the creator. Sammartano also stated the + hard case plainly: "If b builds c, then b can read c's key, so b + can be c. No message format fixes that, mine included." + + The author proposed an enforcement/observation framing in response to + that discussion [AP-SERGEEV-GATE]. The control-topology test of + Section 8 refines that framing by distinguishing adversary-resistant + detection coverage from a particular finding made from evidence + already obtained. Farrell posed the scenario. This document does + not attribute the generalized test to him. Applied to the scenario: + + * Exact, single-use, attenuated authority bounds what the grant + authorizes, where it is enforced. It does not establish that an + action attributed to c was not performed by b, where b created or + hosts c and can obtain or invoke c's signing capability (rules 2 + and 6 of Section 6). + + * A message format can carry the relevant control or evidence. It + cannot create the required independence (Section 3). + + * A prevention claim at that boundary needs an enforcement point b + does not control and cannot bypass. A claim that covered + misbehavior cannot be concealed needs evidence b cannot forge, on + a path b cannot silently prune (Section 8). Attestation and + threshold signing supply such points only in deployments that + actually place them outside b. + + * What is missing in the hard case is not another field. It is a + point outside b that either enforces or observes, and no message + format creates one. + + This is narrower than solving credential custody. It makes the + assurance claim and its trust boundary reviewable before a mechanism + is chosen, which is what a chartering or design review needs. + +Acknowledgments + + The scenario of Appendix A was posed by Stephen Farrell + [AP-FARRELL-ABC]. The mitigation list and the plain statement of the + key-custody limit were collected by Shawn Sammartano [AP-SAMMARTANO], + who also confirmed the enforcement/observation framing used here + [AP-SAMMARTANO-FRAMING]; Charles Eckel proposed that 'a' authorize + 'c' to do something specific on 'a's behalf, rather than expose a + long-term credential [AP-ECKEL]. Yuning Jiang raised the continuity + of an identity across restarts, instance changes, and key rotation, + which is how the question behind rule 10 of Section 6 entered this + + + +Sergeev Expires 21 March 2027 [Page 37] + +Internet-Draft Claim Boundaries September 2026 + + + work [AP-JIANG-CONTINUITY]. The distinction itself is older and is + drawn in [DID-CORE]. Vladimir Ikher is the author's co-author on the + earlier work [WITMODEL] from which the bases of Section 4 and the + ceiling of Section 5 are restated here. This document also benefited + from the broader agentproto and agent2agent mailing-list discussions + of 2026 on evidence, delegation, and audit. The author thanks their + participants without implying that any of them endorses this + document. + + Douglas Wadkins reviewed a pre-submission draft; the statement of + scope in Section 1.1, the additions to Section 11, and the + qualification in Section 12 are responses to his comments. + +Document development disclosure + + This document was drafted with substantial assistance from generative + AI tools, working from the author's prior publications, + specifications, and mailing-list correspondence, at the author's + direction. It also incorporates material arising from adversarial + review conducted with such tools: the wording of several rules, and + the separation of analytical justification from documented practical + confirmation stated in Section 6, were reached that way. The author + reviewed the resulting text and is responsible for its content, + citations, and attributions. [I-D.fengfar-led] discusses LLM use in + IETF discussions and explicitly excludes Internet-Draft and RFC text + from its scope. This disclosure is voluntary. + + The author also has an implementation interest in this area: the WEXP + appraisal layer [I-D.sergeev-wexp-core] is the author's own work. + This document is usable independently of it. No organizational + independence between the two works is claimed. + +Author's Address + + Mikhail Sergeev + Independent Researcher + Email: mikhailsergeev369@gmail.com + + + + + + + + + + + + + + +Sergeev Expires 21 March 2027 [Page 38] diff --git a/published/00/draft-sergeev-claim-boundaries-00.xml b/published/00/draft-sergeev-claim-boundaries-00.xml new file mode 100644 index 0000000..315195a --- /dev/null +++ b/published/00/draft-sergeev-claim-boundaries-00.xml @@ -0,0 +1,2935 @@ + + + + + + + + + + +]> + + + + + Claim Boundaries for Execution Evidence + + + Independent Researcher +
+ mikhailsergeev369@gmail.com +
+ + + + + + + evidence claims audit attestation agents + + + + + + +Systems that act in the world produce logs, receipts, approvals, +traces, attestations, provenance statements, and transparency records. +These artifacts are routinely offered as evidence that an action was +authorized, performed, or completed. This document states a discipline +for bounding such claims: the strength of an execution-related claim +is limited by what the available evidence actually observed and by the +control and observation topology at the boundary that produced it. +Message formats, signature validity, receipt validity, and +registration do not create observation or independence that did not +exist. The control-topology test was prompted by a scenario Stephen +Farrell posed in the IETF agent-protocol discussion of July 2026: one +party creates another and may be able to act in its name. The tension is +general, since no message format can supply the independent +enforcement or observation dependencies required by a prevention or +adversary-resistant detection-coverage guarantee, and the scenario is +worked through in an appendix. The document defines no protocol, no +record format, and no registry. It collects non-inference rules, a +control-topology test for prevention and detection claims, a worked +example, and reporting distinctions for evidence that does not support +the claim asserted over it. + + + + + + + + + + + + + + +
Introduction + +An operator states that "the payment was executed". The artifact +behind the statement is a signed log entry produced by the operator's +own service. The signature verifies. The schema validates. The entry +was registered with a transparency service. None of that establishes +that the payment reached the payment network, only that the operator +recorded and registered a well-formed statement saying so. + +Gaps of this kind are routine wherever execution-related evidence is +consumed: audit pipelines, compliance reporting, supply-chain +attestation, and incident forensics. They appeared recently and +sharply in the IETF's agent-protocol discussions of 2026, in +protocols for AI agents, where one party's software performs actions +whose records are produced largely by the acting side itself. + +The failure mode is semantic and assurance inflation: the strength of +a claim silently grows as an artifact moves between parties, formats, +and summaries. A record of an invocation is cited as proof of +execution. A valid signature is read as truth of the signed +statement. The presence of an audit trail is read as completeness of +coverage. An authorization is reported as an action performed. Each +step feels small. The result is a claim no producing boundary ever +observed. + +This document states the bounding discipline in one place, in +protocol-neutral terms, so that specifications, deployments, and +reviews can name the exact point at which a claim outruns its +evidence. + +
Scope and non-goals + +This document is descriptive. It defines no wire format, no +transport, no carrier, no record or receipt format, no authority or +authorization mechanism, no registry, and no generic evidence +protocol. It does not compete with, extend, or profile any of the +systems discussed in . It states analytic limits that hold +whichever of those systems carries the evidence. Because it +specifies no protocol behavior, it does not use BCP 14 requirement +keywords: statements of the form "X does not establish Y" are claims +about what an artifact can support, not conformance requirements. + +This document states a claim-appraisal discipline, not an +evidence-design discipline. It identifies when available evidence does or does not +establish a claim, from the position of a relying party deciding +what to conclude from what it has. It does not prescribe the +complete set of observations, bindings, retention mechanisms, or +architecture that would have to be put in place in advance so that +a given claim remains determinable later. Enforcement or observation +at the time of an action and determination at a later time are +related, but they are not the same requirement. What further material +should have been captured or bound at action time, where, and by +whom, is related work and outside the +scope of this document. + +The discipline is not new in its parts. Bounded claim statements are +established practice in specific domains: a time-stamp token is +evidence that a datum existed before a particular time, and the +authority time-stamps only a hash of the datum and does not examine +it ; DKIM distinguishes the signing domain from the purported author and +limits its integrity assertion to the content covered by the +signature ; certificate transparency +describes its logs as making misissuance detectable rather than +preventing it ; supply-chain transparency describes itself +as holding issuers accountable rather than preventing dishonest ones +. This document collects such statements as one discipline +for execution-related evidence and claims no priority for any +individual rule. + +
+
+
Terminology + +This document uses the following terms descriptively. + +
+
Claim:
+
+ A statement offered for reliance, concerning an action: that it was +intended, authorized, invoked, performed, completed, or had an +effect. +
+
Evidence:
+
+ Artifacts offered in support of a claim: records, logs, receipts, +signatures, attestations, provenance statements, transparency +entries, and similar. +
+
Producing boundary:
+
+ The vantage point, component, or interface at which a piece of +evidence was produced, together with what that vantage point could +observe and who controls it. This document uses "producing +boundary" throughout as its genus term for that vantage point. +
+
Interested party:
+
+ A party whose conduct the claim describes or whose incentives are +served by the claim being accepted; typically the operator of the +acting system. +
+
Relying party:
+
+ A party deciding whether to accept the claim. +
+
Control topology:
+
+ The arrangement of which parties control which enforcement points, +observation points, keys, and delivery paths relevant to a claim. +
+
Independence:
+
+ A property of deployment and control, relative to a stated party +and threat model: a component is independent of a party only if +that party cannot direct, bypass, or silently suppress it. +Independence is not established by a label, a field value, a +distinct key, an organizational name, or a count of components +alone. +
+
+ +
+
The bounding principle + +The strength of an execution-related claim is bounded by two things: + + + what the available evidence actually observed, at the boundary +that produced it; and + the control and observation topology at that boundary: who +operated it, who could bypass it, and through whose hands its +output travels. + + +Message format, signature validity, receipt validity, and +registration do not raise either bound. A format can carry a +statement about control or observation. It cannot create control or +observation that did not exist. A signature authenticates bytes under +a key. By itself it establishes neither the truth of what the bytes +assert nor the signer's control of the boundary they describe. +A receipt's evidential force depends on the property being checked, +the observations or proofs that support it, and the applicable trust +and deployment assumptions. Successful verification of a registration +receipt can support that a statement was registered under the +service's policy. Registration alone does not establish that the event +described in the statement occurred. + +These limits concern what follows from the stated evidence and +premises. They do not preclude an inference from complementary +observations whose relationships and load-bearing assumptions are +established. Cryptographic verification can support those +assumptions. It does not supply a missing observation by +authenticating a statement about it. + +
+
Evidence bases: what did the evidence observe? + +Execution-related artifacts answer different questions, and the +differences are load-bearing. At minimum, the following bases are +worth distinguishing: + +
+
Observation:
+
+ Some event concerning the action was recorded or reported. Absence +of a record alone is not an observation that an event did not occur. +
+
Intent:
+
+ A specific intention, plan, approval, or decision concerning the +exact action is evidenced. This establishes neither the validity of +the approval nor anything about performance. +
+
Invocation:
+
+ The exact request crossed an observed invocation boundary. This +does not establish that the invoked operation executed or had an +effect. +
+
Execution:
+
+ Performance of the exact action was evidenced at a boundary in a +position to observe execution. This does not establish completion +of a larger process, a durable external effect, goal satisfaction, +correctness, or policy compliance. +
+
+ +These bases are ordered by content depth. The bases organize +different evidential questions and need not be mutually exclusive. +Evidence relevant to one base does not, merely by being assigned to +that base, satisfy the evidential criteria relied on for another. Distinctions of this kind, between stages of +an action's lifecycle whose evidence does not carry across, are long +established in distributed-systems practice (for example the +separation of a remote procedure call's invocation from its +execution and its result). One executable realization that binds +exact predicates to these four bases appears in +. This document does not depend on it. + +Two further distinctions cut across the bases. Verification reach +(who can check a record) is orthogonal to claim strength: a +third-party-verifiable invocation record is still invocation +evidence. And asserted content differs from observed content: a +mediator's record may faithfully report what the mediator asserts +about a downstream outcome it never observed. A useful record says at +which boundary it was produced and whether each statement in it was +observed there or merely asserted there. + +The action referred to by a claim should be identified at the +relevant boundary. A business intention, an authorization, a request +attempt, an execution, and a durable effect need not have a +one-to-one relation. Retries, proxies, and idempotent processing can +change those relations. A composite claim depends on evidence +establishing the particular bindings it uses. This document +prescribes no common identifier format. + +
+
The claim ceiling + +A claim dimension is a family of claims that the same kind of +evidence bears on, such as the bases of . On a stated +dimension, and under stated premises, a producing boundary limits the +claims its evidence can support. Call that limit its claim ceiling. +The term does not presume that all claims on a dimension are +comparable, or that one uniquely strongest claim exists. + +A boundary in a position to observe invocations, but not execution, +cannot warrant execution claims. That holds no matter how many +well-formed execution assertions its records carry. + +The underlying idea is old and this document claims no priority for +it: a conclusion cannot be stronger than the vantage from which its +supporting evidence was produced. Prior and operational formulations +of the same limit, and this document's relationship to them, are +described in . None of them is needed to state or apply +the rule as given here. + +Two properties keep a claim ceiling honest. + +The first is that it is an exclusion rule, not an evidence source. It +can prevent a stronger claim from being supported, but it never +creates support. A supported claim still requires positive evidence +at its own base. + +The second is that the ceiling is only as good as the grounding of +the boundary description itself. A boundary descriptor asserted by +the producer is the producer's account. A signature can attribute it +to a key holder. Separate evidence can attest it. But attribution is +not proof of actual boundary control, and a relying party that +accepts a self-described boundary has accepted the producer's framing +of what was observable. + +Grounding a boundary description need not be technical. A preserving +repository may undergo external certification. Its account of its own +custody, fixity, and succession practice is then assessed against a +published standard by a body the repository does not control +, under a separate regime that sets requirements for the +bodies performing that audit and certification . + +A relying party that relies on such an assessment +rather than on the repository's own account is bounded by what the +assessment actually examined. + +The accepted boundary description must apply to the time and +deployment context of the claimed action. A later assessment or a +current configuration does not, by itself, establish the earlier +boundary's properties. + +The same applies to any premise that would make the producer's +records informative without observation. Where a claim rests on the +producer's incentives or objectives being known, that knowledge is +itself a premise requiring its own grounding. An alignment asserted +by the producer is the producer's account. + +A record that requires no later cooperation from the party whose +conduct is at issue is not, for that reason, independent of that +party. A record it made at the time and left in place needs nothing +from it afterwards and remains its own account of itself. The +distinction between independence from cooperation and independence +of the evidence itself follows an exchange with Douglas Wadkins; see +. + +A claim ceiling is relative. It is stated for one claim dimension, at +one observation boundary, with the support relation proper to that +dimension: which evidence supports which claim on it. Examples are +the bases of and, separately, the prevention claims and the +detection claims of . + +Claims on different dimensions are not ranked against one another by +a ceiling. An execution claim and a detection claim are distinct +facets, not points on one scale, and this document defines no scalar +scale, level, or score on which all claims are ordered. "Stronger" +and "weaker" in this document are always read within the dimension at +issue. + +
+
Non-inference rules + +The following rules restate as individual limits. Each +names an inference that is invalid without additional, separately +established premises. None is original here; scoped versions of +several appear in the documents cited in . + +The rules state bounded limits on inference. Inclusion requires an +explicit scope and a checkable justification of the stated limit. +Analytical justification, relevant prior work, and documented +practical cases are identified separately, and a documented case is +not a prerequisite for inclusion; claims about practical occurrence +or consequences require their own support. Neither an illustrative +example nor a standards reference is presented here as a documented +incident. + +The list is not closed. The set has grown as readers reported +promotions the earlier rules did not reach. A reader who +finds a promotion these rules do not name has found a gap in this +section, not a licence for the promotion. + + + Successful signature verification does not by itself establish the +truth of an event claim in the signed content. Establishing that +correspondence requires grounds beyond signature validity. +Separately, signature validity alone does not establish the +signer's control of the boundary described by the claim. The same +distinction is drawn for verifiable credentials, where +verifiability of a credential does not imply the truth of the +claims encoded in it , and for signed DID +documents, where proofs in the document do not by themselves +necessarily prove control over the DID . + Attribution of an actor is not proof of actorship. That a record +is attributed to a party -- by a key, an identifier, or a +credential associated with that party -- does not establish that +the party performed the action, where another party can obtain, +invoke, or emulate the attributed capability. Where one party +creates or hosts another and can reach that other's signing or +authenticating capability, an action attributed to the hosted +party may have been performed by the host. + A receipt, record, or registration is not external execution or +effect. Registration establishes that a statement entered a log or +service under that service's policy. Matching records held by +different parties establish that the parties agree about content +(correspondence). Correspondence does not establish which event +preceded which (precedence), and it does not establish occurrence. + Presence of records is not completeness of coverage. A set of +records, each individually authentic, does not establish that the +set is all the records there are. Detecting omission requires +something the retained records cannot supply: an independently +grounded expectation of the complete population, or a recording +boundary that cannot be bypassed. + Absence of a record is not non-occurrence, unless the observation +regime supports that inference. The inference from "no record" to +"no event" is valid only where a declared, enforced recording +boundary meets three conditions. It covers the event class. It +cannot be bypassed by the parties in question. And gaps in the +record stream are themselves detectable, for example against a +pre-declared cadence or sequence carried in the records and +watched by a party outside the producer. Otherwise absence is only +absence. +Such an inference also requires an identified interval, evidence +that the required recording and delivery coverage held for that +interval, and resolution of relevant delays and gaps. +Detectability of a gap does not license a non-occurrence claim +while the gap remains unresolved. The conclusion is limited to +the specified event class, population, and interval under the +stated assumptions. +Bypass of the recording boundary is not the only way a record can +fail to appear. A record may have been made and then withheld, +whether by a retention policy that removed it or by a disclosure +decision that did not produce it . Where either is possible, the +result is a statement about the evidence set examined and not +about the recording boundary, and the conditions above are not +met by the boundary alone. + Authority granted is not action performed. Authorization +evidence, however exact, single-use, and attenuated, bounds what a +grant permits at the point where it is enforced. It does not +establish that the authorized action occurred. What is missing is +evidence on the action's own basis: an observation of invocation +or of execution, at a boundary in a position to make it, or a +record that constitutes the action rather than describing it +( and ). + Internal observation is not independent observation of an external +effect. A record produced inside the acting party's boundary can +establish, at most, what that boundary observed; statements in it +about effects at other systems are assertions. In particular, a +record minted by the deciding or authorizing side cannot by itself +establish the order of its own decision against an effect that +side does not observe. + Time and sequence evidence is bounded by the observation and +control properties of its source, like any other evidence. A +timestamp or sequence number is only as strong as the party and +mechanism that produced it: one minted by the interested party +over its own record orders that record, not the world. This is not +a claim that time evidence is worthless. Trusted time-stamping has +a distinct and stronger evidentiary role: a time-stamp token from +an appropriately trusted authority is evidence that a datum +existed before a particular time . And a sequencing +mechanism whose observational domain covers both of two events can +order them. The rule is that the strength of the time or sequence +claim follows the source, and must not be read past what that +source observed and controlled. + A missing or unverifiable load-bearing premise cannot be silently +promoted. Where support for a claim depends on a premise that was +not evaluated, or that only the interested party can vouch for, +the claim inherits that limitation. The honest output is the +weaker claim, or the same claim explicitly conditioned on the +producer's own account. + Current authentication, when its verified scope is limited to a + present binding, does not by itself establish identity continuity + or succession relative to an earlier subject. Identity continuity, + succession, and the present applicability of prior authorization, + standing, or reputation are distinct claims. Each requires grounds + covering the specific relation or applicability asserted under the + relevant identity and authorization rules. A record's evidentiary + force depends on those rules and its verified properties, not + merely on its statement of the claim. DID Core states the + corresponding limit for persistent identifiers: absent published + operational policies, requesting parties are not expected to assume + that an identifier is persistent for the same subject + . + + +Every rule here is stated against premises. The premises a conclusion +rests on, their grounds, and their status should be available directly +or by unambiguous reference. A premise accepted as a matter of policy +is not thereby independently established. Where the premises change, +whether the conclusion remains warranted has to be checked rather than +assumed. + +Aggregation, transformation, summarization, and re-signing remove +none of these limitations. A pipeline that normalizes, merges, or +re-encodes evidence inherits each relevant limitation of its +inputs unless a specific limitation is specifically resolved by +additional evidence. An unsupported widening of a claim at the output +of such a pipeline +is a defect to locate, not a result to report. + +
+
A claim-boundary review lens + +The rules above can be applied as a short checklist when reviewing a +specification, a deployment, or an evidence design. For a given +claim, ask: + + + Exact claim. What exact claim, about what exact action, is being +made? + Producing boundary. Which boundary produced the supporting +evidence, and what could that boundary observe? + Control, bypass, suppression. Who controls that boundary? Can the +interested party bypass it, or suppress or alter its output +unobservably? Did those properties hold at the relevant time? + Ceiling. On the claim dimension at issue, what claim or claims +can that boundary warrant? Does the asserted claim exceed them? + Positive evidence. Is there positive evidence at the claim's own +base, or is the claim resting on a ceiling, a signature, or a +registration that excludes stronger claims but supplies none? + Prevention, detection coverage, or a particular finding. If the +claim is that misbehavior is prevented, which independently +controlled enforcement point does it rest on ()? If +the claim is that misbehavior of a specified class cannot be +concealed, which independently controlled observation and +delivery dependencies does that coverage rest on? For a claim +that a particular event was detected, which evaluation act +(evaluator, predicate, evidence basis, window or context) is +identified? + Observation of effect. Is the consequential effect observed at a +boundary outside the interested party's control, whether an +external footprint or the relying party's own observation +boundary ()? + Completeness and absence. Does the claim depend on the record set +being complete, or on an absence meaning non-occurrence? Is that +supported (rules 4 and 5)? What interval and delivery horizon +were evaluated, and were relevant gaps resolved? + Pipeline widening. Does any step between production and reliance +widen the claim beyond what the producing boundary supported? + Reporting category. When the evidence falls short, is the outcome +reported as a downgrade, unsupported, not established, or +unverifiable (), rather than silently rounded up? + + +The considerations sections of (security) and +(privacy) are the models for this genre: a document states, in its +own terms, what its mechanisms do and do not establish, and what +residual exposure remains. This lens applies the same documentation +discipline to the semantic strength of execution-related claims. It +is a review aid, not a conformance procedure. + +
+
The control-topology test + +Claims that an architecture prevents or detects misbehavior are +execution-related claims about the architecture itself, and they are +bounded the same way. Farrell's (a,b,c) scenario, described in +, motivates the control-topology test used here. Stated +mechanism-neutrally: + +
+
Prevention:
+
+ A claim that party B is prevented from performing or forging an +action requires an enforcement point that B does not control and +cannot bypass, positioned so that the action cannot complete +without it. A component outside B's control that is not actually +required for the action prevents nothing. +
+
Detection coverage:
+
+ A claim that misbehavior in a specified class cannot be concealed +by B requires two things. + + +
+
Evidence:
+
+ adequate to distinguish that misbehavior under the stated +assumptions. +
+
Controls:
+
+ delivery or omission controls that prevent B from hiding it +without an observable indication. +
+
+ + The claim should state its coverage, timing, and failure limits. +These coverage conditions are distinct from establishing that a +particular event was detected from evidence already obtained. +
+
Independence:
+
+ The prevention and coverage properties above depend on deployment +and control, relative to the stated party, claim, and threat +model. Independence is established by who actually operates the +enforcement or observation point and through whose hands its +output travels. A distinct key, component name, field, label, +second log, or organizational name does not, by itself, establish +those properties. +
+
+ +An architecture claiming prevention or adversary-resistant detection +coverage should set out three things: + + + which independently controlled enforcement or observation +dependencies the guarantee rests on; + what the relevant bypass, forgery, and suppression limits are; + what happens when a dependency is unavailable or cannot be +validated. + + +Without those dependencies, that guarantee is not established +against adversarial B, whatever its message formats carry. This does +not invalidate a narrower finding supported by evidence that has +actually been received and evaluated. + +A protected observation path is not, by itself, sufficient for +detection. The evidence must support a check that distinguishes the +specified misconduct under the stated assumptions. An observable gap +can establish a loss of coverage without establishing which +underlying event occurred. + +A claim that a particular event was detected requires an identifiable +evaluation act. The record should name which evaluator evaluated, +which predicate was checked and with what result, and on what +evidence basis. Where a window or context applies, it should name +that too. + +Such a finding does not, by itself, establish that all events of that +class were detectable or detected. A path that could have revealed an +event is not a record that anyone looked. This document defines no +format for stating those items. + +Existing mechanisms slot into this test rather than exempting +themselves from it. Remote attestation contributes where +three conditions hold: + + + the Evidence covers the property at issue; + the adversarial party can neither forge nor substitute the Evidence +or the Attestation Result, nor control the appraisal path; + the result is freshly and securely bound to the relevant actor and +action. + + +RFC 9334 permits its roles to be aggregated into one entity, so +independence from a given party is a property of the deployment, not +of the architecture. + +Threshold signing contributes a prevention dependency +exactly where the adversarial party cannot reach the threshold +without an independently controlled signer that checks the exact +operation and can withhold its share. These mechanisms contribute +only to the properties and dependencies actually established by their +deployment. + +OAuth sender-constraining mechanisms such as DPoP can +limit the use of stolen tokens. They do not by themselves prevent B +from invoking a key through a signing interface B controls. That +holds whether the key was provisioned by another party or stored as +non-exportable. + +An isolated execution environment, including a trusted execution +environment (TEE), can contribute an enforcement dependency where B +cannot modify or bypass the relevant checks. Claims about effects +outside that environment still require an appropriate evidence basis. + +The WIMSE architecture separates workload +authentication from authorization and permits different placements of +policy enforcement. The test therefore asks who controls the deployed +enforcement point and which operations it covers, rather than +treating workload identity or credential provisioning as evidence +that the claimed operation occurred. + +The independently controlled point need not be cryptographic. +A preserving repository may be audited and certified against a +published standard , by a body the repository does not +control and which is itself accredited under a separate regime +. That contributes a detection dependency on two +conditions. The audit observes the practice at issue. The audited +party cannot suppress an adverse finding without the suppression +becoming visible. + +That contribution is limited by the audit's scope, period, sampling, +access, and reporting arrangements. Certification alone does not +establish complete observation of all relevant conduct, nor the +visibility of every suppressed adverse finding. The recursion +terminates in an accreditation body that some party must be prepared +to treat as terminal. + +The test is indifferent to whether the point outside the party in +question is a key, a verifier, or an accreditation regime. It asks +only whether the deployment placed one there, and what that point +actually covers. + +
+
When stronger claims become supportable + +The discipline is not only subtractive. Stronger claims about a +particular effect become supportable when the effect is observed at +a boundary capable of observing it. That capability is judged under +the stated threat and control model. The evidence of that observation +must also be protected against undetected fabrication or alteration +by the interested party. Coverage claims additionally depend on the +observation and delivery conditions described in . + +An external footprint is one important route to such observation. +Examples are movement on a payment rail, and resource or +configuration records in an external provider's control plane. In +each, a system the interested party does not control observed +something at its own boundary, and a relying party can check that +system's records against the claim. + +It is not the only route. The observing boundary may be any of +several things: + + + an external service, a counterparty, or a settlement system; + an external control plane; + the relying party's own observation boundary, where the relying +party itself observes the effect: a state change in a system it +operates, or a delivery it takes receipt of itself; + another point that is in a position to observe the relevant fact +and that the interested party does not control under the stated +threat model. + + +A distinct third party is not always necessary. The relying party's +own observation may provide the required evidence, subject to the +same claim-specific trust and deployment assumptions. + +A further route relies on a record constituting the precise action +claimed, rather than describing a separate action: + + + a signed order that is the order; + a recorded state transition on a ledger that is the transfer; + a recorded command whose issuance is itself the claimed action; + a write-ahead entry that defines the commit. + + +Such a record supports that precise claim, because issuing or +accepting it constitutes the action under the applicable rules. The +evidence must establish the conditions that give the +record that constitutive effect, including any applicable authority, +acceptance, and commit or finality conditions. A record on a branch +that was never accepted does not constitute the action merely by +resembling one that would. + +What it supports is bounded by the action it constitutes and extends +no further. A ledger entry that is the transfer establishes the +transfer, not that goods moved. A signed order that is the order +establishes the order, not that it was carried out. Where a record +describes an action it does not constitute, this route does not +apply. + +The qualifications travel with the pattern: + + + The observing boundary supports claims at its own observation +boundary and no further. A payment network's record establishes +what the network observed about a transfer at its boundary, not +that a business obligation was satisfied. A relying party's own +observation establishes what the relying party observed at its +boundary, and no more. + The observation, whether an external footprint or the relying +party's own, must be bound to the exact action claimed. A matching +amount, timestamp, or counterparty is correlation, and correlation +supports weaker claims than a validated binding. + The protection afforded by the observing boundary is itself a +threat-model statement. For a particular finding, the relevant +protection is against the operator of the acting system fabricating +or undetectably altering the evidence for the claimed observation. +Against the operator of the observing boundary itself, +the pattern gives no additional support. Where the relying party +observes at its own boundary, the claim rests on the relying +party's own observation, which is independent of the interested +party but not of the relying party. + Ordering claims, such as that the decision preceded the effect, +require an ordering relation whose observational domain includes +both terms. That means one boundary that observed both, or records +from the two boundaries that can be securely related and ordered. +Matching records alone establish neither the order of the records +nor the order of the events. + The ability to prevent an observation from being made, to bypass +its boundary, or to withhold the resulting evidence does not, by +itself, invalidate evidence that has been received. Subject to the +qualifications above, the received evidence may support a +particular finding within its observational and temporal scope. It +does not, by itself, establish completeness or the absence of +contrary observations. Any finding that depends on the completeness +of a specified evidence set or on absence as evidence of +non-occurrence requires the corresponding coverage and +gap-resolution basis (rules 4 and 5). + + +Deployments that want strong claims should therefore prefer actions +whose effects are observable at a boundary outside the interested +party's control. That may be an external footprint or the relying +party's own observation. They should also prefer evidence that binds +those observations to exact actions, over additional self-produced +artifacts. + +
+
Worked example: a payment + +Consider an agent that reports having paid a supplier. Three evidence +artifacts and a report combining them are on the table. The point of the example is that they +support different claims, and that a report must keep separate what +each boundary observed from what it merely asserts. + + + A self-produced execution record. The operator's own service +emits a signed record: "paid supplier S, amount X, at time T". +Observed at that boundary: that the operator's service produced +and signed this statement. Asserted, not observed there: that the +payment reached S. What it supports on its own: that the operator +stated a payment; not that the payment occurred (rules 1, 3, 7). +This example assumes that the record contains only the operator's +own statement. If it carries independently verifiable evidence +from another source, that evidence is appraised at its own +producing boundary. The party assembling the container does not +determine every item's origin. + A transparency registration. The signed record is registered with +a transparency or receipt service, yielding an inclusion proof. +Observed: that this statement was registered under the service's +policy. Any claim about registration time depends on the time +evidence provided and its verified scope. Not established: the truth of the statement or +the occurrence of the payment (rule 3). Registration raises +auditability, not the claim ceiling. + External payment-network evidence. A record from the payment +network -- a settlement entry or network-issued confirmation -- +that the network observed a transfer matching the action. Observed +at a boundary outside the operator's control: that the network saw +a transfer with these attributes. This is the footprint of +. It must be bound to the exact action. A bare +amount-and-time match is correlation. Its strength holds against +the operator, not against the payment network's own operator. + A composite report. A report that draws on all three should read, in +substance, as three statements. The operator asserts a payment (1). +The assertion is registered and independently checkable as an +assertion (2). And where (3) is present and bound to the exact +action, a system outside the operator observed a matching transfer +at its boundary. That last supports a payment-reached-the-network +claim, to the extent the binding holds and that evidence is +protected against fabrication or undetected alteration by the +operator. Absent (3), or +another observation of the transfer at a boundary outside the +operator's control (), the supportable claim is +that the operator stated and registered a payment, not that a +payment occurred. + + +The example makes no universal assertion about what any particular +service observes. What a given payment service, transparency service, +or agent runtime actually observed is a fact about that deployment, +to be stated from its evidence, not assumed from its role. + +
+
Reporting what the evidence supports + +Where evidence does not support the claim asserted over it, the +useful output is not a bare failure. The distinctions that matter to +a relying party: + +
+
Downgrade to the supportable claim:
+
+ Report the strongest claim on the dimension at issue that the +evidence does support, or the supported claims where there is no +unique strongest one, alongside the asserted claim it does not. +"Invocation established; execution asserted only" is actionable; +"invalid" is not. +
+
Unsupported:
+
+ The relevant assessment ran over the evidence evaluated, and that +evidence failed it. This is a finding about the evaluated evidence, +relative to the evidence set and the appraisal context in which it +was evaluated. It is not a property of the world, and a different +evidence set may support the claim. +
+
Not established:
+
+ The assessment did not run, the evidence was not available, or the +premise was outside the evaluation's scope. The evaluated material +does not establish the claim. It does not establish the negation +of the claim either. This is the absence of a finding, and it is +not refutation. "Not established" does not mean the claim is +false. Nor is it permission to discard evidence that positively +supports a claim at its own base. A base well supported by its own +evidence stays supported, even while a stronger claim over it is +not established. Collapsing +"not established" into "unsupported", or either into "refuted", +destroys information a relying party needs: "we checked and it +failed" and "we could not check" call for different decisions. +
+
Unverifiable:
+
+ The statement is one that the evaluator in question cannot check +from the evidence and inputs available to it at the time of +evaluation. The standing example is a producer's description of +its own deployment, which an evaluator may be unable to check +without deployment access or other adequate evidence about that +deployment. The category is relative to a verifier or evaluator, and to an +evidence or input set. Where they matter, it is relative to an +evaluation context or time as well. A statement unverifiable to one +evaluator may be verifiable to another with access the first +lacks. Such statements +can still be worth carrying. They should be marked as resting on +the producer's account, so a reader can see which parts of a +composite claim rest on trust. + + + The category is relative to an evaluator and, where relevant, to +a moment. So a statement can pass from verifiable to unverifiable +while the record itself is unchanged. The evaluator that could +check it may cease to exist. It may lose the access it depended +on, or the means to interpret what it holds. + + A report that fixes the category without fixing the evaluator and +the moment says less than it appears to. +
+
+ +These distinctions are not a mutually exclusive result-code set. +Unverifiability may explain why a claim is not established, while +the same report identifies a weaker claim that is supported. Where +the evidence establishes the negation of a claim, the report should +state that finding and its basis explicitly rather than treating it +as mere absence of support. + +Each of these categories is relative to the evidence actually +evaluated, and a report is more useful when it says what that +evidence was. The evaluated set may itself be incomplete or selected. +Every record in it can verify while records that would have changed +the outcome were never delivered: rule 4 of , met +again at the reporting layer. + +A verdict stated over a named evidence basis is a verdict over that +basis, not over all evidence that exists. A verdict that does not +name its basis invites exactly the widening this document is +about. + +Appraisal results travel. One evaluator's result may be consumed by a later composite report: +that a claim is not established, for instance. The later relying +party then needs to distinguish an attributable appraisal from an +unattributed conclusion. + +Propagated or aggregated appraisal results should therefore retain +enough provenance to identify three things: + + + who or what appraised; + the evidence or input basis, or a stable reference to it; + the predicate, profile, or evaluation context under which the +result was reached, including the boundary at which the appraisal +was made. + + +Without that, "not established" degrades across aggregation into +somebody's unattributed conclusion. That is the aggregation limit of + arriving at the reporting layer. + +This is a consideration for reporting designs. It is not a record +format and not a general retention requirement. The provenance of an +appraisal establishes who appraised what, under which context. It +does not establish that the underlying event occurred. + +A reporting design that preserves these distinctions makes inflation +visible: every summary that would erase one of them is a place where +a stronger claim would otherwise silently replace a weaker one. + +
+
Applicability beyond AI agents + +Nothing in this discipline is stated in terms specific to AI agents. +The same bounding questions apply to: + + + audit logging and monitoring pipelines, where the questions are +what the log source observed and who can write to it; + evidence collection and archiving practice ; + signed system logs ; + transparency systems (, ); + long-term evidence records ; + compliance reporting and incident forensics; + operational telemetry, which is self-reported by instrumented code +and designed for diagnosis rather than adjudication. + + +Agent systems sharpened the problem. Actions are initiated by +software whose records are produced mostly at the acting side, and +delegation chains multiply the boundaries across which claims travel +and inflate. But the rules in are stated as +properties of evidence rather than of agents. + +One domain is worked here: the long-term preservation of records, +where no agent acts and no payment is made. It was chosen because it +shares neither substrate nor vocabulary with the example of +. + +A preserving repository holds a record deposited by its creator. +Different claims about that record require different evidence. +Fixity evidence can support a claim that deposited bytes have not +changed relative to an accepted baseline. Identity and provenance +evidence may support an authenticity assessment under stated +assumptions. + +Neither finding, by itself, establishes that the record was reliable +when created or that its content was accurate. Evidence about its +creation process may come from the creator or from other sources, and +may itself be preserved by the repository. Preservation +does not convert custody integrity into truth of the original +content. That is an instance of the claim ceiling of . + +A correctly maintained chain of archive time-stamps can preserve +previously established integrity and existence-at-time evidence +under its cryptographic and time-source assumptions +. Recomputing a digest alone does not establish when the +data existed, and renewal does not establish the truth of their +content (rules 1 and 8 of ). + +A gap in a deposited +series supports no conclusion about what was never deposited, unless +the deposit regime was declared, enforced, and observable to a party +outside the depositor. Where such a regime exists, the inference it +licenses belongs to the regime and not to the retained records (rule +5). + +Whether a preserved record can still be evaluated depends on the +record, the available representation and provenance information, and +the evaluator's knowledge and access. This illustrates the +evaluator- and time-relative unverifiability discussed in +. OAIS addresses continued understandability for an +identified Designated Community, including the information needed to +interpret preserved content . + +Two public findings state the same bound outside computing +entirely, in the words of the bodies that made them. + +In the English prosecutions arising from the Post Office Horizon +accounting system, the Court of Appeal found that the prosecutor +"treated what was no more than a shortfall shown by an unreliable +accounting system as an incontrovertible loss", and that defendants +were convicted "on the basis that the Horizon data must be correct, +and cash must therefore be missing, when in fact there could be no +confidence as to that foundation" . + +The load-bearing premise was the reliability of that system. The +court recorded three things about it. The prosecutor was under a duty +to investigate subpostmasters' claims that there were problems with +it. The prosecutor represented it as reliable while "refusing to +countenance any suggestion to the contrary". And its "failures of +investigation and disclosure" were "so egregious as to make the +prosecution of any of the 'Horizon cases' an affront to the +conscience of the court". + +On the reading taken here, that is the position rule 9 of + names. The claim rested on a premise the relying +party was required to test and did not adequately test, and whose +contrary material it did not disclose. + +The court's findings are its own. The connection drawn to the rule is +this document's. The judgment does not address what a bounded report +of the same evidence would have said, and is not cited for that part +of the rule. + +In the inquiry into the Grenfell Tower fire, the panel considered a +large-scale fire test. Failure to meet its performance criteria would +show a system unlikely to comply with the applicable requirement. But +"the converse was not necessarily true": a system might meet the +criteria and still perform unacceptably in use . A +bounded test result refuses a claim in one direction and does not +establish it in the other. + +A third case shows the bound where the test results themselves were +genuine outputs of a genuine test. Vehicles were certified against +emissions standards on the strength of those results. Software detected the test +condition and enabled full emissions controls only then, so the +vehicles "meet emissions standards in the laboratory or testing +station, but during normal operation" emitted up to forty times the +NOx standard . The result established the behaviour of the +vehicle under the conditions the test applied, which was all it had +ever observed. The certificate carried it to a claim about the +vehicle in use ( and rule 7 of ). + +These authorities reached findings within their own legal and +regulatory settings, each asking what a record before it established. +Their connection to the rules stated here is this document's +reading. + +Applicability to the other domains listed above is asserted on the +same grounds and is not worked case by case here. + +
+
Related work + +The following work provides established mechanisms and +domain-specific treatments relevant to these limits. This document +collects selected implications for the appraisal of +execution-related claims. + +
+
Non-bypassable mediation and tamper-evident logging:
+
+ Two older lineages give this discipline its positive content. The +reference-monitor lineage established that a security-relevant +decision is only +enforced where every access is mediated by a mechanism the +controlled party cannot bypass and cannot tamper with -- the +prevention half of . The tamper-evident and +transparency-logging lineage established that alteration or +equivocation in a record set can be made externally detectable -- +the detection half. + + + Certificate transparency provides inclusion and consistency checks +over log views . A misbehaving log can nevertheless +present inconsistent views to different clients. Detecting that +behavior depends on comparing relevant observations, or on other +mechanisms and deployment assumptions that address such split views. + + This document restates the boundary conditions those lineages +already identified. It adds no mechanism, and claims none of +them. +
+
Attestation:
+
+ RFC 9334 defines remote-attestation roles, appraisal +flows, and trust assumptions, including constraints on Claims +collection, the strength of Attestation Results, and the +separation of Attesting and Target Environments. EAT +defines a claims token. This document draws on those established +concerns to organize a review discipline for execution-related +claims across artifact classes. It defines no remote-attestation +machinery. +
+
Transparency and receipts:
+
+ COSE Receipts convey proofs of properties of a +verifiable data structure, including inclusion and consistency. +Successful verification supports the specified data-structure +predicate under the applicable cryptographic and trust assumptions. +It does not, by itself, establish that an event described in a +registered statement occurred. SCITT applies +transparency mechanisms to supply-chain statements and explicitly +addresses the limits posed by dishonest issuers. Certificate +transparency provides log proofs whose use remains +bounded by the split-view problem set out earlier in this section. +These are +established examples of bounded evidence claims. +
+
Supply-chain step attribution:
+
+ in-toto binds the artifacts flowing between the steps +of a software supply chain, the order in which the steps were +performed, and the identity of the party that signed for each, +against a layout declared in advance by the project owner. Its +no-key-compromise analysis assumes that the developer host systems +are not compromised and that no functionary holding a valid key +acts against the chain. Within those assumptions the binding is +strong. The paper separately analyzes how the guarantees degrade +under functionary or project-owner key compromise. Both the +assumptions and the degradation cases are boundary statements of +the kind this document asks producers to make explicit. +
+
Record integrity, existence, and evidence handling:
+
+ Signed syslog , evidence records , time-stamps +, and evidence-collection guidance protect +integrity, origin, ordering, existence-at-time, and chain-of-custody +of records. These protections do not, by themselves, establish that +the events described in the records occurred as described. +
+
Provenance:
+
+ PROV models provenance as asserted descriptions that +feed trust assessment, not as verdicts. +
+
Prior formulations by the author:
+
+ The four bases of and the ceiling of restate, +in generic terms and without the level scale used there, content +levels and the boundary axiom (Axiom BC) of earlier joint work with +Vladimir Ikher . The Witnessability Conceptual Core +states the conceptual generalization of that axiom as a derived rule +(the Boundary Ceiling Rule of +version 1.0) +. The WEXP appraisal core + gives an exclusion-only operational +realization that binds exact predicates to the four bases of +. + + + This document uses the generic term and preserves that +exclusion-only role. It makes no claim of independent discovery or +priority. Its rules can be stated and applied without either work. +The author's interest in WEXP is disclosed below. +
+
Agent-protocol evidence work:
+
+ Individual Internet-Drafts address per-claim verifier, binding, +freshness, and failure discipline +; enrollment and +key-binding assumptions ; evidence +of authorization decisions ; +and an architecture for auditing agents' interactions and delegation +. + + + An outcome-binding profile +separates the authorization of an action from its observed effect. +It binds signed observations from executors, systems of record, and +independent observers to the same authorization, action digest, and +operation, with exact-equality checks on the action and source +bindings, plus relying-party-defined observation-window +requirements. +It treats a declared control domain as relying-party policy input +rather than proof of independence. And it returns an indeterminate +state when required evidence is missing or unauthenticated. + + Work on agent control delivery and outcome reconciliation + distinguishes control +issuance and dispatch, receiver-side observation, enforcement +outcome, and observation of the resulting effect. + + A further draft +states mechanism-independent requirements for making a claimed +agent transition independently determinable after the original +interaction has ended. It addresses the binding of the material +action and its governing conditions, a verification procedure that +establishes that those conditions actually governed the transition +when it occurred, determination without the cooperation of any +original participant, and negative, transferred, or incomplete +transitions. + + These works address related questions at specific boundaries. The +discipline here can be applied to the claims made over their +evidence. +
+
Non-inference rules stated for a record format:
+
+ In the agent2agent discussion of a dimensional model for +agent-protocol proposals, Blake Morrison set out three rules for +records carried under different extensions of one format +. + + +
+
Non-inference:
+
+ written about values, and so constrains what a value carries +rather than whether a record exists. +
+
Comparison:
+
+ does reach existence, in Morrison's words: "the absence of a +matching record is reported as such rather than compared +against a value". +
+
Cross-extension:
+
+ a record under one extension is not to be read as evidence that +a record under another extension exists, and its value is not +to be carried across. +
+
+ + Morrison observed that the comparison rule reaches existence only +inside a comparison between two protocols, and that reading one +protocol's records on their own neither rule covers. That is the +boundary rule 5 of draws for the general case. The +cross-extension rule is rule 4 of scoped to one +format: the presence of one record does not establish the existence +of another. + + The third rule is stated there with requirement keywords, which are +not reproduced here because this document uses none. The wording +above is a paraphrase and the original is in the cited message. + + These are proposals made on a mailing list, not text adopted in any +document. They are cited here as independent statements of the same +limits, not as support for this document. +
+
Considerations-section genre:
+
+ RFC 3552 requires every RFC to state what its mechanisms +do and do not protect; RFC 6973 guides documents, where +their content warrants it, in stating what privacy exposure remains. +This document extends that documentation discipline to the semantic +strength of execution-related claims. It does not own the practice. +
+
Records authenticity and long-term preservation:
+
+ Archival diplomatics states the distinction this document restates +for execution evidence, and states it earlier and for a different +substrate. The InterPARES programme separates three properties of a +record . + + +
+
Reliability:
+
+ its trustworthiness at the point of creation. +
+
Accuracy:
+
+ the correctness of its content. +
+
Authenticity:
+
+ that it is what it purports to be, with its identity and +integrity preserved in the respects the assessment treats as +essential. +
+
+ + That assessment does not by itself carry reliability. Fixity evidence supports a +claim about preserved bytes relative to an accepted baseline and +does not establish reliability or accuracy. + + The reference model for an open archival +information system assigns a preserving repository the +responsibility of keeping preserved information independently +understandable to an identified Designated Community, including +the representation information needed to interpret it +. For repositories that undergo external +certification, the repository's own account of its practice is +assessed by an external body against a published standard +, under a regime that sets requirements for those +bodies . Such certification is not a general +property of preserving repositories. This document applies the +bounding relation those disciplines already state to +execution-related claims and to the control topology of the +producing boundary. It adds no preservation machinery. +
+
Authentication and admissibility in evidence law:
+
+ The separation of what an artifact is from what its content +establishes is normative, not only analytic. Under the United +States Federal Rules of Evidence, a certified record generated by +an electronic process, and a certified copy authenticated by +digest comparison, are self-authenticating. + + + The advisory committee states three limits on that . Such +a certification establishes authenticity only. An opponent remains +free to object on hearsay, relevance, or confrontation grounds. And +authenticating a machine output establishes that the output came +from that system, rather than that the information it carries is +reliable. + + Under Federal +Rule of Civil Procedure 37(e)(2), specified adverse presumptions +and remedies for lost electronically stored information require a +finding of intent to deprive, subject to the rule's other +conditions . This is a procedural rule, not a general +test of the logical strength of missing evidence. + + These legal examples illustrate bounded uses of evidence. Their +burdens, admissibility rules, and remedies remain outside this +document's scope. +
+
Assurance cases:
+
+ The claims-argument-evidence tradition provides structured +argumentation over evidence. ISO/IEC/IEEE 15026-2 specifies +requirements for assurance-case structure terminology +, and the Goal Structuring Notation community +standard provides a notation for such arguments . The +presence of an assurance case or a graphical representation does +not, by itself, establish that a particular evidential inference +is justified. +
+
+ +
+
Security considerations + +This document defines no protocol and introduces no new attack +surface. Its subject is the prevention of a class of security +failures that occur at the semantic layer: relying parties accepting +claims stronger than the evidence supports. + +Cautions about the discipline itself, including its misuse: + + + The discipline does not make a dishonest or compromised evidence +source honest. It bounds what a relying party should infer. It does +not improve the evidence. + "Not established" is not a licence to discard evidence. A finding +that a stronger claim is not established is not a basis for +setting aside evidence that positively supports a weaker claim at +its own base. The correct output is the supported weaker claim, +reported as such (), not the removal of the evidence. + Deliberately unobservable topology is a limitation to report, not +an exoneration. An interested party may arrange that its enforcement or observation +points cannot be checked by anyone else. The correct conclusion is +then that the corresponding prevention or detection-coverage +guarantee is unsupported by the evidence available to the relying +party: the independence it requires cannot be shown, and the report +says so. This does not +extend to every case-level finding that received evidence may +support. +Unobservability is not evidence of good behavior. + Conformance vocabulary is itself inflatable. "Consistent with the +claim-boundary discipline" is not a property a document or product +can certify by assertion. The test is whether specific claims are +bounded by specific producing boundaries, checked claim by claim. + Detection mechanisms leak. Making refusals, gaps, or suppression +observable to an external party discloses timing and frequency +information to that party. Deployments should weigh the +observability required by against what the observation +channel itself reveals; is the model for stating that +residual exposure. + + +
+
IANA considerations + +This document has no IANA actions. + +
+ + + + + + + + + + + + + + + + Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) + + + + + + + This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] + + + + + + + + + Guidelines for Evidence Collection and Archiving + + + + + A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. + + + + + + + + + + Guidelines for Writing RFC Text on Security Considerations + + + + + All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. + + + + + + + + + + Evidence Record Syntax (ERS) + + + + + + In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK] + + + + + + + + + Signed Syslog Messages + + + + + + This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK] + + + + + + + + + DomainKeys Identified Mail (DKIM) Signatures + + + + + + DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. + This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] + + + + + + + + + + Privacy Considerations for Internet Protocols + + + + + + + + + + This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. + + + + + + + + + Certificate Transparency Version 2.0 + + + + + + This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. + This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. + Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. + + + + + + + + + Remote ATtestation procedureS (RATS) Architecture + + + + + + + + In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. + + + + + + + + + OAuth 2.0 Demonstrating Proof of Possession (DPoP) + + + + + + + + + This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. + + + + + + + + + The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures + + + + + + + This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime-order groups and hash functions. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. + + + + + + + + + The Entity Attestation Token (EAT) + + + + + + + An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. + An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. + + + + + + + + + CBOR Object Signing and Encryption (COSE) Receipts + + + + + + + CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. + + + + + + + + + An Architecture for Trustworthy and Transparent Digital Supply Chains + + + + + + + + Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. + + + + + + + + + + The Witnessed Execution Protocol (WEXP): Core Specification + + Independent Researcher + + + Independent Researcher + + + + The Witnessed Execution Protocol (WEXP) Core defines carrier-neutral + appraisal semantics for execution-related evidence. It defines four + distinct content bases, two independent evidence qualifiers, the + Boundary Ceiling, exact-claim support, deterministic accept, + downgrade, and reject verdicts, composition without inflation, and a + normalized interface between evidence-carrying profiles and + appraisers. WEXP Core does not define a record serialization, + signature envelope, action identifier, authorization model, or + evidence-artifact schema. A companion Native Record profile can + encode the normalized inputs defined here, and other carriers can do + so without adopting that record format. + + + + + + + + + + + + Security Principal and Verifier Binding for Agent Communication Protocols + + + + + Agent communication protocols often carry claims about user + authority, agent instance identity, tool or external-resource + identity, delegation state, session continuity, and action evidence. + These claims have different verifiers, freshness requirements, + failure modes, and security consequences. If they are collapsed into + a single token, identity label, session identifier, or audit record, + protocol text can accidentally imply more authority or accountability + than the receiver can actually verify. + + This document defines a verifier-facing model for separating those + claims. It provides a reusable matrix format that protocol authors + can use to state, for each security-relevant claim, which field + carries it, which party verifies it, what binding or freshness rule + applies, what failure behavior is required when the claim is absent, + stale, inconsistent, or not verifiable, and what constrained result + an application may consume after successful verification. It also + separates specification status, implementation status, and evidence + type so that reviewers can distinguish current protocol text, + implementation evidence, inherited mechanisms, and architectural + assumptions. The document is protocol-neutral. It is intended to + help compare candidate agent communication drafts and to provide + security-considerations and requirements text for agent session and + delegation binding. + + The document also defines row-outcome semantics and dependency- + closure rules for composed mappings. These rules prevent a composite + result from becoming stronger than its verified inputs, distinguish + failed checks, unsupported verifier capabilities, checks skipped + after a failed prerequisite, and unavailable or ambiguous inputs, + propagate transitive dependency failures, and make cyclic, stale, + downgraded, or revision-incoherent dependencies visible to reviewers. + + + + + + + + + + + + An Architecture for Auditing Agent Delegation and Interactions + + Ericsson + + + Fraunhofer SIT + + + + This document describes an architecture for auditing of agent-driven + interactions on the Internet. Autonomous and semi-autonomous + software agents, including those based on artificial intelligence, + increasingly act on behalf of users, organizations, and services. + Existing auditing mechanisms often capture isolated system events but + do not consistently represent delegation relationships, user intent, + or evolving authorization. In agent-driven systems, auditability + requires linking intent, delegation, authorization, and execution. + The proposed architecture enables this through distributed audit + record generation, propagation of audit context, optional + attestation, and additional logging for transparency. + + + + + + + + + + + + Signed Decision Records for Agent Authorization: Disclosures, Entry Emission, and Ordering Evidence + + + + + Audit systems for autonomous agents commonly record the actions an + agent performed. This makes the non-occurrence of a permitted action + unrepresentable: when nothing happens, there is no action to emit + anything. This document describes an evidence model that records the + authorization decision rather than the action. A decision exists + whether or not the action follows, so denials, expiries, and + commitments that were granted and never honoured remain + representable. + + The document defines four disclosures that make a decision record + independently evaluable, an entry-emission rule for states a relying + party may need to reason about, and the evidentiary basis for claims + that a decision preceded its effect. It distinguishes + correspondence, where two records agree about what happened, from + precedence, where the order of decision and effect is established, + and it requires records to state which of the two they carry. + + + + + + + + + + + + Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence + + Yuthent + + + + Any scheme that produces cryptographic evidence of execution + authority roots its entire trust chain in an enrollment: the moment + at which a key becomes bound to a subject and a device, and at which + a verifier begins to treat signatures under that key as meaningful. + Every downstream proof is only as trustworthy as that binding. If an + attacker substitutes a key of their choosing at enrollment, every + subsequent proof verifies correctly and yet attests to the wrong + party. This document is a problem statement. It describes the + foundational key-substitution threat, records the relevant public + facts about consumer-platform biometric and key APIs that bound what + an enrollment can establish, and states the assumptions a verifier of + execution authority evidence must be able to make about the + enrollment its proofs depend on. Specific enrollment ceremonies are + out of scope. This document defines no protocol or mechanism. + + + + + + + + + + + + Outcome Binding for Authorized Actions and Independently Observed Effects + + EMILIA Protocol, Inc. + + + + Authorization proves what action was permitted; it does not prove + what happened after execution. An executor-signed result improves + attribution but remains a claim by the party that acted. This + document specifies a source-routed Outcome Binding profile. Signed + predicted effects identify the source role and source class required + to evaluate each predicate. Executors, systems of record, and + independent observers sign closed observation objects bound to the + same authorization, action digest, Canonical Action Identifier, + consumption nonce, operation, facility, and observation window. A + deterministic verifier separates evidence availability from + comparison: missing or unauthenticated required sources yield an + indeterminate lifecycle state; authentic observations yield the + closed comparison result in_bounds, divergent, or incomparable. The + profile improves consequence reconciliation without claiming physical + truth, sensor correctness, or legal finality. + + + + + + + + + + + + Workload Identity in a Multi System Environment (WIMSE) Architecture + + + + + + + + + + + + + + + + Independent Determinability of Agent Actions + + Strakewright + + + + + + + + Evidence Requirements for Agent Control Delivery and Outcome Reconciliation + + + + + + + + + + Dealing with LLMs in IETF Discussions + + + + + + + + + + + + + Re: [Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + [Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: [Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: [Agentproto] DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: [Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: [Agentproto] Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Verifiable Credentials Data Model v2.0 + + World Wide Web Consortium + + + +W3C Recommendation, Section 1.1 + + + Decentralized Identifiers (DIDs) v1.0 + + World Wide Web Consortium + + + +W3C Recommendation, Sections 9.2 and 9.11 + + + [agent2agent] Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates + + + + + +message to the agent2agent mailing list + + + [agent2agent] Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates + + + + + +message to the agent2agent mailing list + + + Re: focused review request on security principal binding, agent2agent + + + + + +message to the agent2agent mailing list + + + Toward a Witnessability Model for AI and Software Execution Systems: A Boundary-Based Framework for Classifying Execution Evidence + + + + + + + + +Version 1.1, bridge revision; also at DOI 10.2139/ssrn.6994720 + + + Witnessability Conceptual Core 1.0 + + + + + + + + + + Hamilton & Ors v Post Office Ltd + + Court of Appeal (Criminal Division), England and Wales + + + +[2021] EWCA Crim 577, paragraphs 136-137 + + + Grenfell Tower Inquiry: Phase 2 Report, Volume 1 + + Grenfell Tower Inquiry + + + +HC 19-I, Part 1, Chapter 2, paragraphs 2.122-2.123 + + + Learn About Volkswagen Violations + + United States Environmental Protection Agency + + + +agency overview of the Clean Air Act violations, including the Notice of Violation of 18 September 2015 + + + in-toto: Providing farm-to-table guarantees for bits and bytes + + + + + + + + + + + + + + + + + +28th USENIX Security Symposium + + + PROV-DM: The PROV Data Model, W3C Recommendation + + World Wide Web Consortium + + + + + + + Diplomatics: New Uses for an Old Science + + + + + +Scarecrow Press + + + The Long-term Preservation of Authentic Electronic Records: Findings of the InterPARES Project + + + + + + + + + Space Data System Practices -- Reference model for an open archival information system (OAIS) + + International Organization for Standardization + + + + +also issued as CCSDS 650.0-M-3, December 2024 + + + Space data and information transfer systems -- Audit and certification of trustworthy digital repositories + + International Organization for Standardization + + + + + + + + Requirements for Bodies Providing Audit and Certification of Candidate Trustworthy Digital Repositories + + Consultative Committee for Space Data Systems + + + + + + + + Systems and software engineering -- Systems and software assurance -- Part 2: Assurance case + + ISO/IEC/IEEE + + + + + + + + Goal Structuring Notation Community Standard, Version 3 + + SCSC Assurance Case Working Group + + + + + + + + Federal Rules of Evidence, Rule 902(13) and Rule 902(14), with Advisory Committee Notes + + United States + + + + + + + Federal Rules of Civil Procedure, Rule 37(e), Failure to Preserve Electronically Stored Information, with Advisory Committee Notes + + United States + + + + + + + + + + + + +
The (a,b,c) scenario worked through + +In the agentproto mailing-list discussion of July 2026, in the thread +on the draft minutes of the AGENTPROTO BoF, Stephen Farrell posed a +gating scenario . In his words: + +
  • + If (a,b,c) is a comms path between agents (perhaps within a tree) +and if 'c' is actually a newly created entity, but one that needs +access to a long-term secret credential accessible at 'a' (e.g. pwd +or SSH private key) and where that credential must not be exposed +to 'b' nor easily abused - then how's that going to work? +
+ +He emphasized that "the scenario I posited is one where 'b' creates +'c' and so is in a fine place to cheat" . + +The list discussion produced concrete mitigations, collected in a +reply by Shawn Sammartano , who credited most of +them to existing mechanisms: + + + exact, single-use, attenuated permission slips bound to request +bytes; + hardware-protected keys, and threshold signing; + short-lived credentials, and forward-moving counters; + delegation budgets, and delays with cancellation windows; + approval separated from the creator. Sammartano also stated the hard case plainly: "If b builds +c, then b can read c's key, so b can be c. No message format fixes +that, mine included." + + +The author proposed an enforcement/observation framing in response +to that discussion . The control-topology test of + refines that framing by distinguishing +adversary-resistant detection coverage from a particular finding +made from evidence already obtained. Farrell posed the scenario. +This document does not attribute the generalized test to him. +Applied to the scenario: + + + Exact, single-use, attenuated authority bounds what the grant +authorizes, where it is enforced. It does not establish that an +action attributed to c was not performed by b, where b created or +hosts c and can obtain or invoke c's signing capability (rules 2 +and 6 of ). + A message format can carry the relevant control or evidence. It +cannot create the required independence (). + A prevention claim at that boundary needs an enforcement point b +does not control and cannot bypass. A claim that covered misbehavior cannot be concealed needs +evidence b cannot forge, on a path b cannot silently prune +(). Attestation and threshold signing supply such +points only in deployments that actually place them outside b. + What is missing in the hard case is not another field. It is a +point outside b that either enforces or observes, and no message +format creates one. + + +This is narrower than solving credential custody. It makes the +assurance claim and its trust boundary reviewable before a mechanism +is chosen, which is what a chartering or design review needs. + +
+
Acknowledgments + +The scenario of was posed by Stephen Farrell +. The mitigation list and the plain statement of +the key-custody limit were collected by Shawn Sammartano +, who also confirmed the enforcement/observation +framing used here ; Charles Eckel proposed +that 'a' authorize 'c' to do something specific on 'a's behalf, +rather than expose a long-term credential . Yuning Jiang raised the continuity of an +identity across restarts, instance changes, and key rotation, which is +how the question behind rule 10 of entered this work +. The distinction itself is older and is drawn +in . +Vladimir Ikher is the author's co-author on +the earlier work from which the bases of and +the ceiling of are restated here. This document +also benefited from the broader agentproto and agent2agent +mailing-list discussions of 2026 on evidence, delegation, and audit. The +author thanks their participants without implying that any of them +endorses this document. + +Douglas Wadkins reviewed a pre-submission draft; the statement of +scope in , the additions to , +and the qualification in are responses to his +comments. + +
+
Document development disclosure + +This document was drafted with substantial assistance from generative +AI tools, working from the author's prior publications, +specifications, and mailing-list correspondence, at the author's +direction. It also incorporates material arising from adversarial +review conducted with such tools: the wording of several rules, and the +separation of analytical justification from documented practical +confirmation stated in , were reached that way. The author reviewed the resulting text and is responsible +for its content, citations, and attributions. +discusses LLM use in IETF discussions and explicitly excludes +Internet-Draft and RFC text from its scope. This disclosure is +voluntary. + +The author also has an implementation interest in this area: the +WEXP appraisal layer is the author's own +work. This document is usable independently of it. No organizational +independence between the two works is claimed. + +
+ + + + + + + + diff --git a/published/01/README.md b/published/01/README.md new file mode 100644 index 0000000..c9c0bc9 --- /dev/null +++ b/published/01/README.md @@ -0,0 +1,31 @@ +# Published CBEE -01 + +[Datatracker](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/01/) · [Official HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-01.html) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-01) · [All revisions](../README.md) + +- IETF posting event: **2026-09-23T04:00:40Z** (UTC). +- Date inside the document: **23 September 2026**. +- Intended status: Informational; individual Internet-Draft. + +Clarifies independence as limits on forgery, concealment, and circumvention; defines support and separates evidence bases; adds non-inference rules 11–13 and revises reporting distinctions. See the published Changes from -00 appendix. + +## Frozen files + +The XML and TXT were downloaded from the official IETF archive and checked +byte-for-byte on 18 October 2026. They are preserved without reformatting. +SHA256SUMS covers exactly those two files. + +| File | Bytes | SHA-256 | +| --- | ---: | --- | +| [draft-sergeev-claim-boundaries-01.xml](draft-sergeev-claim-boundaries-01.xml) | 122449 | d59d0e4a85bff662a8f13c34cb1eb1297f2140a62a130ddd2fdedbbdcece0829 | +| [draft-sergeev-claim-boundaries-01.txt](draft-sergeev-claim-boundaries-01.txt) | 111543 | 0d90638366325bbacb368e9d1fd256f7a6117831ff31e10cb49d1b40e8446d35 | + +Verify from this directory with: sha256sum -c SHA256SUMS. +The [machine-readable history](../revisions.json) records the official URLs, +posting events, and file identities for every revision. + +The GitHub release is a later mirror of this existing IETF publication. +Its tag identifies the public archive-import commit; it does not claim that +this Git repository existed on the IETF posting date. Use this directory or +the release assets for -01; the root XML is the current working source. + +The official XML uses legacy RFCXML syntax. Do not convert this archived copy. diff --git a/published/01/SHA256SUMS b/published/01/SHA256SUMS new file mode 100644 index 0000000..f5912ff --- /dev/null +++ b/published/01/SHA256SUMS @@ -0,0 +1,2 @@ +d59d0e4a85bff662a8f13c34cb1eb1297f2140a62a130ddd2fdedbbdcece0829 draft-sergeev-claim-boundaries-01.xml +0d90638366325bbacb368e9d1fd256f7a6117831ff31e10cb49d1b40e8446d35 draft-sergeev-claim-boundaries-01.txt diff --git a/published/01/draft-sergeev-claim-boundaries-01.txt b/published/01/draft-sergeev-claim-boundaries-01.txt new file mode 100644 index 0000000..8f3d08c --- /dev/null +++ b/published/01/draft-sergeev-claim-boundaries-01.txt @@ -0,0 +1,2464 @@ + + + + +Network Working Group M. Sergeev +Internet-Draft Independent Researcher +Intended status: Informational 23 September 2026 +Expires: 27 March 2027 + + + Claim Boundaries for Execution Evidence + draft-sergeev-claim-boundaries-01 + +Abstract + + Systems that act in the world produce logs, receipts, approvals, + traces, attestations, provenance statements, and transparency + records. These artifacts are routinely offered as evidence that an + action was authorized, performed, or completed. This document states + a discipline for bounding such claims: the strength of an execution- + related claim is limited by what the available evidence actually + observed, constitutes, or proves, and by the control and observation + topology at the boundary that produced it. Message formats, + signature validity, receipt validity, and registration do not create + observation or independence that did not exist. No message format + can supply the independent enforcement or observation dependencies + that a prevention or adversary-resistant detection-coverage guarantee + requires. An appendix works through a scenario in which one party + creates another and may be able to act in its name. The document + defines no protocol, no record format, and no registry. It collects + non-inference rules, a control-topology test for prevention and + detection claims, a worked example, and reporting distinctions for + evidence that does not support the claim asserted over it. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 27 March 2027. + + + + + +Sergeev Expires 27 March 2027 [Page 1] + +Internet-Draft Claim Boundaries September 2026 + + +Copyright Notice + + Copyright (c) 2026 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Scope and non-goals . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The bounding principle . . . . . . . . . . . . . . . . . . . 5 + 4. Evidence bases: what did the evidence observe? . . . . . . . 6 + 5. The claim ceiling . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Non-inference rules . . . . . . . . . . . . . . . . . . . . . 9 + 7. A claim-boundary review lens . . . . . . . . . . . . . . . . 13 + 8. The control-topology test . . . . . . . . . . . . . . . . . . 14 + 8.1. Independence and the claim at issue . . . . . . . . . . . 17 + 9. When stronger claims become supportable . . . . . . . . . . . 19 + 10. Worked example: a payment . . . . . . . . . . . . . . . . . . 22 + 11. Reporting what the evidence supports . . . . . . . . . . . . 23 + 12. Applicability beyond AI agents . . . . . . . . . . . . . . . 26 + 13. Related work . . . . . . . . . . . . . . . . . . . . . . . . 27 + 14. Security considerations . . . . . . . . . . . . . . . . . . . 30 + 15. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 + 16. Informative References . . . . . . . . . . . . . . . . . . . 31 + Appendix A. The (a,b,c) scenario worked through . . . . . . . . 38 + Appendix B. Three public findings . . . . . . . . . . . . . . . 40 + Appendix C. Changes from -00 . . . . . . . . . . . . . . . . . . 41 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 43 + Document development disclosure . . . . . . . . . . . . . . . . . 43 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 44 + + + + + + + + + + + +Sergeev Expires 27 March 2027 [Page 2] + +Internet-Draft Claim Boundaries September 2026 + + +1. Introduction + + An operator states that "the payment was executed". The artifact + behind the statement is a signed log entry produced by the operator's + own service. The signature verifies. The schema validates. The + entry was registered with a transparency service. None of that + establishes that the payment reached the payment network, only that + the operator recorded and registered a well-formed statement saying + so. + + Gaps of this kind are routine wherever execution-related evidence is + consumed: audit pipelines, compliance reporting, supply-chain + attestation, and incident forensics. They appeared recently and + sharply in the IETF's agent-protocol discussions of 2026 + (Appendix A), in protocols for AI agents, where one party's software + performs actions whose records are produced largely by the acting + side itself. + + The failure mode is semantic and assurance inflation: the strength of + a claim silently grows as an artifact moves between parties, formats, + and summaries. A record of an invocation is cited as proof of + execution. A valid signature is read as truth of the signed + statement. The presence of an audit trail is read as completeness of + coverage. An authorization is reported as an action performed. Each + step feels small, but together they produce a claim that no producing + boundary ever observed. + + This document states the bounding discipline in one place, in + protocol-neutral terms, so that specifications, deployments, and + reviews can name the exact point at which a claim outruns its + evidence. + +1.1. Scope and non-goals + + This document is descriptive. It defines no wire format, no + transport, no carrier, no record or receipt format, no authority or + authorization mechanism, no registry, and no generic evidence + protocol. It does not compete with, extend, or profile any of the + systems discussed in Section 13. It states analytic limits that hold + whichever of those systems carries the evidence. Because it + specifies no protocol behavior, it does not use BCP 14 requirement + keywords: statements of the form "X does not establish Y" are claims + about what an artifact can support, not conformance requirements. + + This document states a claim-appraisal discipline, not an evidence- + design discipline. It identifies when available evidence does or + does not establish a claim, from the position of a relying party + deciding what to conclude from what it has. It does not prescribe + + + +Sergeev Expires 27 March 2027 [Page 3] + +Internet-Draft Claim Boundaries September 2026 + + + the complete set of observations, bindings, retention mechanisms, or + architecture that would have to be put in place in advance so that a + given claim remains determinable later. Enforcement or observation + at the time of an action and determination at a later time are + related, but they are not the same requirement. What further + material should have been captured or bound at action time, where, + and by whom, is related work and outside the scope of this document. + + The discipline is not new in its parts. Bounded claim statements are + already in use in specific domains: a time-stamp token is evidence + that a datum existed before a particular time, and the authority + time-stamps only a hash of the datum and does not examine it + [RFC3161]; DomainKeys Identified Mail (DKIM) distinguishes the + signing domain from the purported author and limits its integrity + assertion to the content covered by the signature [RFC6376]; + certificate transparency describes its logs as making misissuance + detectable rather than preventing it [RFC9162]; supply-chain + transparency describes itself as holding issuers accountable rather + than preventing dishonest ones [RFC9943]. This document collects + such statements as one discipline for execution-related evidence and + claims no priority for any individual rule. + +2. Terminology + + This document uses the following terms descriptively. It uses + "claim", "evidence", and "relying party" in their general senses. In + the Remote ATtestation procedureS (RATS) architecture [RFC9334], + Evidence and Attestation Results are distinct artifacts, and either + can serve as evidence here. A RATS Claim is a piece of asserted + information inside such an artifact, while a claim here is a + statement offered for reliance. Where a RATS term is meant, it is + capitalized. + + Claim: A statement offered for reliance, concerning an action: that + it was intended, authorized, invoked, performed, completed, or had + an effect. + + Evidence: Artifacts offered in support of a claim: records, logs, + receipts, signatures, attestations, provenance statements, + transparency entries, and similar. + + Producing boundary: The vantage point, component, or interface at + which a piece of evidence was produced, together with what that + vantage point could observe and who controls it. This document + uses "producing boundary" throughout as its genus term for that + vantage point. + + Interested party: A party whose conduct the claim describes or whose + + + +Sergeev Expires 27 March 2027 [Page 4] + +Internet-Draft Claim Boundaries September 2026 + + + incentives are served by the claim being accepted; typically the + operator of the acting system. + + Relying party: A party deciding whether to accept the claim. + + Control topology: The arrangement of which parties control which + enforcement points, observation points, keys, and delivery paths + relevant to a claim. + + Independence: A property of deployment and control. A statement of + independence names a component and its role: enforcement, + observation, delivery, or evaluation. It can instead name a + record or the grounds of a premise. It names a party or a + coalition (parties acting together), a period, and a threat model. + The named thing is independent of that party with respect to a + capability if the party lacks that capability over it. + Section 8.1 names three capabilities: forgery, concealment, and + circumvention. Which of them matter depends on the claim. + Independence describes control. Whether the evidence supports the + claim is a separate question (Section 3). A label, a field value, + a distinct key, an organizational name, or a count of components + does not by itself establish independence. + +3. The bounding principle + + The strength of an execution-related claim is bounded by: + + 1. what the available evidence actually observed, constitutes, or + proves, at the boundary that produced it; and + + 2. the control and observation topology at that boundary: who + operated it, who could bypass it, and through whose hands its + output travels. + + Message format, signature validity, receipt validity, and + registration do not raise either bound. A format can carry a + statement about control or observation, but it cannot create control + or observation that did not exist. A signature authenticates bytes + under a key. By itself it establishes neither the truth of what the + bytes assert nor the signer's control of the boundary they describe. + A receipt's evidential force depends on the property being checked, + the observations or proofs that support it, and the applicable trust + and deployment assumptions. Successful verification of a + registration receipt can support that a statement was registered + under the service's policy. Registration alone does not establish + that the event described in the statement occurred. + + + + + +Sergeev Expires 27 March 2027 [Page 5] + +Internet-Draft Claim Boundaries September 2026 + + + These limits concern what follows from the stated evidence and + premises. They do not preclude an inference from complementary + observations whose relationships and load-bearing assumptions are + established. Cryptographic verification can support those + assumptions. It does not supply a missing observation by + authenticating a statement about it. + + Support does not have to come from direct observation of the claimed + action. Section 9 describes the other routes and their premises. + + In this document, evidence supports a claim when the claim follows + from the evidence under the stated premises. One practical test + checks this. Try to describe two cases in which the relying party + holds the same evidence under the same premises, but the claim is + true in one case and false in the other. If both cases are possible + under those premises, the evidence does not support the claim as + stated. Failing to find such a pair does not prove that none exists. + Evidence that only makes a claim more likely does not support the + claim in this sense, although it can still support a weaker claim + (Section 11). + +4. Evidence bases: what did the evidence observe? + + Execution-related artifacts answer different questions, and the + differences are load-bearing. At minimum, the following bases are + worth distinguishing: + + Observation: Some event concerning the action was recorded or + reported. Absence of a record alone is not an observation that an + event did not occur. + + Intent: A specific intention, plan, approval, or decision concerning + the exact action is evidenced. This establishes neither the + validity of the approval nor anything about performance. + + Invocation: The exact request crossed an observed invocation + boundary. This does not establish that the invoked operation + executed or had an effect. + + Execution: Performance of the exact action was evidenced at a + boundary in a position to observe execution. This does not + establish completion of a larger process, a durable external + effect, goal satisfaction, correctness, or policy compliance. + Section 9 addresses claims about an effect, its persistence, and + its finality. + + + + + + +Sergeev Expires 27 March 2027 [Page 6] + +Internet-Draft Claim Boundaries September 2026 + + + The observation base asks only whether some event concerning the + action was recorded or reported. Elsewhere in this document, an + observation is an event seen at a boundary in a position to see it + (Sections 3 and 9). Evidence at the observation base need not be an + observation in that sense. + + These bases are distinct questions about one action. They are not + levels on one scale, and they need not be mutually exclusive. A + conclusion from one base to another holds only under stated premises. + Evidence relevant to one base does not, merely by being assigned to + that base, satisfy the evidential criteria relied on for another. + Distinctions of this kind, between stages of an action's lifecycle + whose evidence does not carry across, are long established in + distributed-systems practice (for example the separation of a remote + procedure call's invocation from its execution and its result). One + executable realization that binds exact predicates to these four + bases appears in [I-D.sergeev-wexp-core]. This document does not + depend on it. + + Other distinctions cut across the bases. Verification reach (who can + check a record) is orthogonal to claim strength: a third-party- + verifiable invocation record is still invocation evidence. And + asserted content differs from observed content: a mediator's record + may faithfully report what the mediator asserts about a downstream + outcome it never observed. A useful record says at which boundary it + was produced and whether each statement in it was observed there or + merely asserted there. + + The action referred to by a claim should be identified at the + relevant boundary. A business intention, an authorization, a request + attempt, an execution, and a durable effect need not have a one-to- + one relation. Retries, proxies, and idempotent processing can change + those relations. A composite claim depends on evidence establishing + the particular bindings it uses. This document prescribes no common + identifier format. + +5. The claim ceiling + + In this document, a kind of claim is a family of claims to which the + same type of evidence is relevant, such as the bases of Section 4. + For a stated kind of claim, and under stated premises, a producing + boundary limits the claims its evidence can support. Call that limit + its claim ceiling. The term does not presume that all claims of one + kind are comparable, or that one uniquely strongest claim exists. + + A boundary in a position to observe invocations, but not execution, + cannot by its observations warrant execution claims. That holds no + matter how many well-formed execution assertions its records carry. + + + +Sergeev Expires 27 March 2027 [Page 7] + +Internet-Draft Claim Boundaries September 2026 + + + The underlying idea is old and this document claims no priority for + it: a conclusion cannot be stronger than the vantage from which its + supporting evidence was produced. Section 13 describes prior + formulations. + + A claim ceiling is an exclusion rule, not an evidence source. It can + prevent a stronger claim from being supported, but it never creates + support, so a supported claim still requires positive evidence at its + own base. + + A ceiling is also only as good as the grounding of the boundary + description itself. A boundary descriptor asserted by the producer + is only the producer's own account. Section 8.1 describes what + grounds a statement about who controls a boundary. + + The accepted boundary description must apply to the time and + deployment context of the claimed action. A later assessment or a + current configuration does not, by itself, establish the earlier + boundary's properties. + + The same applies to any premise that would make the producer's + records informative without observation. Where a claim rests on the + producer's incentives or objectives being known, that knowledge is + itself a premise requiring its own grounding. An alignment asserted + by the producer is only the producer's own account. + + This document defines independence in terms of control. Payment, + contract, or ownership can give one party the means to direct another + party's output or decision. They count here to the extent that they + give that capability. + + A record that requires no later cooperation from the party whose + conduct is at issue is not, for that reason, independent of that + party. A record it made at the time and left in place needs nothing + from it afterwards and remains its own account of itself. The + distinction between independence from cooperation and independence of + the evidence itself follows an exchange with Douglas Wadkins; see + [I-D.wadkins-agentproto-action-determinability]. + + A claim ceiling is relative. It is stated for one kind of claim, at + one observation boundary, with the support relation proper to that + kind: which evidence supports which claim of that kind. Examples are + the bases of Section 4 and, separately, the prevention claims and the + detection claims of Section 8. + + Claims of different kinds are not ranked against one another by a + ceiling. An execution claim and a detection claim are different + kinds of claim, not points on one scale, and this document defines no + + + +Sergeev Expires 27 March 2027 [Page 8] + +Internet-Draft Claim Boundaries September 2026 + + + scalar scale, level, or score on which all claims are ordered. + "Stronger" and "weaker" in this document are always read within the + kind of claim at issue. + +6. Non-inference rules + + The following rules restate Section 3 as individual limits. Each + names an inference that is invalid without additional, separately + established premises. None is original here; scoped versions of + several appear in the documents cited in Section 13. + + Each rule is justified analytically. An example or a standards + reference given with a rule is an illustration, and it is not + presented as a documented incident. Claims about practical + occurrence or consequences require their own support. + + The list is not closed. A reader who finds a promotion these rules + do not name has found a gap in this section, not a license for the + promotion. + + 1. Successful signature verification does not by itself establish + the truth of an event claim in the signed content. Establishing + that correspondence requires grounds beyond signature validity. + Separately, signature validity alone does not establish the + signer's control of the boundary described by the claim. The + same distinction is drawn for verifiable credentials, where + verifiability of a credential does not imply the truth of the + claims encoded in it [VC-DATA-MODEL], and for signed + Decentralized Identifier (DID) documents, where proofs in the + document do not by themselves necessarily prove control over the + DID [DID-CORE]. + + 2. Attribution of an actor is not proof of actorship. That a + record is attributed to a party -- by a key, an identifier, or a + credential associated with that party -- does not establish that + the party performed the action, where another party can obtain, + invoke, or emulate the attributed capability. Where one party + creates or hosts another and can reach that other's signing or + authenticating capability, an action attributed to the hosted + party may have been performed by the host. Where a record + reaches the relying party through intermediaries, attribution + established at one step of that path does not carry to the next + without that step's own basis. A transport can establish which + component delivered a record. A source that the deliverer names + inside the record is the deliverer's assertion, unless the + record carries its own verifiable binding to that source. + + + + + +Sergeev Expires 27 March 2027 [Page 9] + +Internet-Draft Claim Boundaries September 2026 + + + 3. A receipt, record, or registration is not external execution or + effect. Registration establishes that a statement entered a log + or service under that service's policy. Matching records held + by different parties establish that their contents agree + (correspondence), not that the parties agree. Correspondence + does not establish which event preceded which (precedence), and + it does not establish occurrence. + + 4. Presence of records is not completeness of coverage. A set of + records, each individually authentic, does not establish that + the set is all the records there are. Detecting omission + requires more than the authenticity of each record: an + independently grounded expectation of the complete population, + which the set itself may carry, or a recording boundary that + cannot be bypassed. + + 5. Absence of a record is not non-occurrence, unless the + observation regime supports that inference. The inference from + "no record" to "no event" is valid only where a declared, + enforced recording boundary meets three conditions. It covers + the event class. It cannot be bypassed by the parties in + question. And gaps in the record stream are themselves + detectable, for example against a pre-declared cadence or + sequence carried in the records and watched by a party outside + the producer. Otherwise absence is only absence. + + Such an inference also requires an identified interval, evidence + that the required recording and delivery coverage held for that + interval, and resolution of relevant delays and gaps. + Detectability of a gap does not license a non-occurrence claim + while the gap remains unresolved. The conclusion is limited to + the specified event class, population, and interval under the + stated assumptions. + + Bypass of the recording boundary is not the only way a record + can fail to appear. A record may have been made and then + withheld, whether by a retention policy that removed it or by a + disclosure decision that did not produce it + [AP-SCHROCK-RETENTION]. Where either is possible, the result is + a statement about the evidence set examined and not about the + recording boundary, and the conditions above are not met by the + boundary alone. + + 6. Authority granted is not action performed. Authorization + evidence, however exact, single-use, and attenuated, bounds what + a grant permits at the point where it is enforced. It does not + establish that the authorized action occurred. What is missing + is evidence on the action's own basis: an observation of + + + +Sergeev Expires 27 March 2027 [Page 10] + +Internet-Draft Claim Boundaries September 2026 + + + invocation or of execution, at a boundary in a position to make + it, or a record that constitutes the action rather than + describing it (Section 4 and Section 9). + + 7. Internal observation is not independent observation of an + external effect. An observation made inside the acting party's + boundary can establish, at most, what that boundary observed, + and a record's statements about effects at other systems are + assertions. In particular, a record minted by the deciding or + authorizing side cannot by itself establish the order of its own + decision against an effect that side does not observe. Other + evidence carried in the same record is appraised under the + routes and premises of Section 9, regardless of its source. + + 8. Time and sequence evidence is bounded by the observation and + control properties of its source, like any other evidence. A + timestamp or sequence number is only as strong as the party and + mechanism that produced it: one minted by the interested party + over its own record orders that record, not the world. This is + not a claim that time evidence is worthless. Trusted time- + stamping has a distinct and stronger evidentiary role: a time- + stamp token from an appropriately trusted authority is evidence + that a datum existed before a particular time [RFC3161]. And a + sequencing mechanism whose observational domain covers both of + two events can order them. The rule is that the strength of the + time or sequence claim follows the source, and must not be read + past what that source observed and controlled. + + 9. A missing or unverifiable load-bearing premise cannot be + silently promoted. Where support for a claim depends on a + premise that was not evaluated, or that only the interested + party can vouch for, the claim inherits that limitation. The + report names the claims that are supported, and keeps the status + of each premise that was not evaluated. A conditional claim + states the premise it depends on (Section 11). + + + + + + + + + + + + + + + + +Sergeev Expires 27 March 2027 [Page 11] + +Internet-Draft Claim Boundaries September 2026 + + + 10. Current authentication, when its verified scope is limited to a + present binding, does not by itself establish identity + continuity or succession relative to an earlier subject. + Identity continuity, succession, and the present applicability + of prior authorization, standing, or reputation are distinct + claims. Each requires grounds covering the specific relation or + applicability asserted under the relevant identity and + authorization rules. A record's evidentiary force depends on + those rules and its verified properties, not merely on its + statement of the claim. DID Core states the corresponding limit + for persistent identifiers: absent published operational + policies, requesting parties are not expected to assume that an + identifier is persistent for the same subject [DID-CORE]. + + 11. Behavior observed under one set of conditions does not establish + the same behavior under other conditions without grounds for + carrying the conclusion across. A test, an audit, or a + monitored run observes a system under the conditions it applies. + The result describes those conditions. Carrying it to other + conditions needs grounds that the two do not differ in anything + the behavior depends on. Where the system can detect that it is + being tested or observed, results obtained under those + conditions do not by themselves supply such grounds, since the + system can make its behavior depend on them. Appendix B reads + the emissions case this way. + + 12. Multiplicity is not independence. A number of records, keys, + services, or organizational names does not by itself establish + independent support. Where one party has a capability that + matters to the claim over several of them, their number adds + nothing against that party (Section 8.1). Independence is + judged claim by claim, for the components on whose correctness + the support for that claim relies. + + 13. Coherence is not corroboration. The detail, internal + consistency, plausibility, or fluency of an account produced by + the interested party does not by itself support the claim that + what it describes occurred. A fabricated account can have all + of these properties, so they do not distinguish a true claim + from a false one (the test of Section 3). This holds with + particular force for accounts generated by software, including + language models, whose output can be fluent whether or not it + matches the events it describes. Support needs grounds beyond + these qualities, and evidence carried with the account can + provide them by one of the routes of Section 9. + + + + + + +Sergeev Expires 27 March 2027 [Page 12] + +Internet-Draft Claim Boundaries September 2026 + + + Every rule here is stated against premises. The premises a + conclusion rests on, their grounds, and their status should be + available directly or by unambiguous reference. A premise accepted + as a matter of policy is not thereby independently established. + Where the premises change, whether the conclusion remains warranted + has to be checked rather than assumed. + + Aggregation, transformation, summarization, and re-signing remove + none of these limitations. A pipeline that normalizes, merges, or + re-encodes evidence inherits each relevant limitation of its inputs + unless a specific limitation is specifically resolved by additional + evidence. An unsupported widening of a claim at the output of such a + pipeline is a defect to locate, not a result to report. + +7. A claim-boundary review lens + + The rules above can be applied as a short checklist when reviewing a + specification, a deployment, or an evidence design. For a given + claim, ask: + + 1. Exact claim. What exact claim, about what exact action, is + being made? + + 2. Producing boundary. Which boundary produced the supporting + evidence, and what could that boundary observe? + + 3. Control. Who controls that boundary? Can the interested party + or coalition forge its output, conceal it, or circumvent it + (Section 8.1)? Which of these capabilities matter to the claim + being made? Did the limits on them hold for the period the + claim depends on? What grounds those limits? + + 4. Ceiling. For the kind of claim at issue, what claim or claims + can that boundary warrant? Does the asserted claim exceed them? + + 5. Positive evidence. Is there positive evidence at the claim's + own base? A ceiling supplies no evidence, and a signature or a + registration supports only the predicate that its verification + establishes. + + + + + + + + + + + + +Sergeev Expires 27 March 2027 [Page 13] + +Internet-Draft Claim Boundaries September 2026 + + + 6. Prevention, detection coverage, or a particular finding. If the + claim is that misbehavior is prevented, which independently + controlled enforcement point does it rest on (Section 8)? If + the claim is that misbehavior of a specified class cannot be + concealed, which independently controlled observation and + delivery dependencies does that coverage rest on? For a claim + that a particular event was detected, which evaluation act + (evaluator, predicate, evidence basis, window or context) is + identified? + + 7. Basis for a claimed effect. Which route of Section 9 supports + the claim? The routes described there include observation at a + boundary outside the interested party's control, a record that + constitutes the action, and evidence whose verification + establishes a predicate. Where the support rests on another + basis, is that basis stated? What limits its scope? + + 8. Completeness and absence. Does the claim depend on the record + set being complete, or on an absence meaning non-occurrence? Is + that supported (rules 4 and 5)? What interval and delivery + horizon were evaluated, and were relevant gaps resolved? + + 9. Pipeline widening. Does any step between production and + reliance widen the claim beyond what the producing boundary + supported? + + 10. Reporting. Does the report separate whether each evaluation was + made from what it found (Section 11)? Does it name the + supported claims, and the reason for any evaluation that was not + made? Is anything silently rounded up? + + The considerations sections of [RFC3552] (security) and [RFC6973] + (privacy) are the models for this genre: a document states, in its + own terms, what its mechanisms do and do not establish, and what + residual exposure remains. This lens applies the same documentation + discipline to the semantic strength of execution-related claims. It + is a review aid, not a conformance procedure. + +8. The control-topology test + + Claims that an architecture prevents or detects misbehavior are + execution-related claims about the architecture itself, and they are + bounded the same way. Farrell's (a,b,c) scenario, described in + Appendix A, motivates the control-topology test used here. Stated + mechanism-neutrally: + + Prevention: A claim that party B is prevented from performing or + + + + +Sergeev Expires 27 March 2027 [Page 14] + +Internet-Draft Claim Boundaries September 2026 + + + forging an action requires an enforcement point that B does not + control and cannot bypass, positioned so that the action cannot + complete without it. A component outside B's control that is not + actually required for the action prevents nothing. + + Detection coverage: A claim that misbehavior in a specified class + cannot be concealed by B requires the following. + + Evidence: adequate to distinguish that misbehavior under the + stated assumptions. + + Controls: delivery or omission controls that prevent B from + hiding it without an observable indication. + + The claim should state its coverage, timing, and failure limits. + These coverage conditions are distinct from establishing that a + particular event was detected from evidence already obtained. + + Independence: The prevention and coverage properties above depend on + independence in the sense of Section 8.1. The components + concerned are the enforcement point, the observation point, and + the delivery path. The party concerned is the stated party or + coalition. + + An architecture claiming prevention or adversary-resistant detection + coverage should state: + + * which independently controlled enforcement or observation + dependencies the guarantee rests on; + + * what the relevant limits on forgery, concealment, and + circumvention are (Section 8.1); + + * what happens when a dependency is unavailable or cannot be + validated. + + Without those dependencies, that guarantee is not established against + adversarial B, whatever its message formats carry. This does not + invalidate a narrower finding supported by evidence that has actually + been received and evaluated. + + A protected observation path is not, by itself, sufficient for + detection. The evidence must support a check that distinguishes the + specified misconduct under the stated assumptions. An observable gap + can establish a loss of coverage without establishing which + underlying event occurred. + + + + + +Sergeev Expires 27 March 2027 [Page 15] + +Internet-Draft Claim Boundaries September 2026 + + + A claim that a particular event was detected requires an identifiable + evaluation act. The record should name which evaluator evaluated, + which predicate was checked and with what result, and on what + evidence basis. Where a window or context applies, it should name + that too. + + Such a finding does not, by itself, establish that all events of that + class were detectable or detected. A path that could have revealed + an event does not show that anyone looked. This document defines no + format for stating those items. + + Existing mechanisms slot into this test rather than exempting + themselves from it. Remote attestation [RFC9334] contributes where + all of the following hold: + + * the Evidence covers the property at issue; + + * the adversarial party can neither forge nor substitute the + Evidence or the Attestation Result, nor control the Verifier, its + Appraisal Policy for Evidence, or the Endorsements and Reference + Values it relies on; + + * the result is freshly and securely bound to the relevant actor and + action. + + RFC 9334 permits its roles to be aggregated into one entity, so + independence from a given party is a property of the deployment, not + of the architecture. + + Threshold signing [RFC9591] contributes a prevention dependency + exactly where the adversarial party or coalition cannot reach the + threshold without an independently controlled signer that checks the + exact operation and can withhold its share. These mechanisms + contribute only to the properties and dependencies actually + established by their deployment. + + OAuth sender-constraining mechanisms such as Demonstrating Proof of + Possession (DPoP) [RFC9449] can limit the use of stolen tokens. They + do not by themselves prevent B from invoking a key through a signing + interface B controls. That holds whether the key was provisioned by + another party or stored as non-exportable (Section 11.4 of + [RFC9449]). + + An isolated execution environment, including a trusted execution + environment (TEE), can contribute an enforcement dependency where B + cannot modify or bypass the relevant checks. Claims about effects + outside that environment still require an appropriate evidence basis. + + + + +Sergeev Expires 27 March 2027 [Page 16] + +Internet-Draft Claim Boundaries September 2026 + + + The Workload Identity in a Multi System Environment (WIMSE) + architecture [I-D.ietf-wimse-arch] separates workload authentication + from authorization and permits different placements of policy + enforcement. The test therefore asks who controls the deployed + enforcement point and which operations it covers, rather than + treating workload identity or credential provisioning as evidence + that the claimed operation occurred. + + The independently controlled point need not be cryptographic. A + preserving repository may be audited and certified against a + published standard [ISO16363], by a body the repository does not + control and which is itself accredited under a separate regime + [CCSDS652-1]. That contributes a detection dependency if the audit + observes the practice at issue and if any suppression of an adverse + finding by the audited party would become visible. + + That contribution is limited by the audit's scope, period, sampling, + access, and reporting arrangements. Certification alone does not + establish complete observation of all relevant conduct, nor the + visibility of every suppressed adverse finding. The recursion + terminates in an accreditation body that some party must be prepared + to treat as terminal. + + The test is indifferent to whether the point outside the party in + question is a key, a verifier, or an accreditation regime. It asks + only whether the deployment placed one there, and what that point + actually covers. + +8.1. Independence and the claim at issue + + A statement of independence says which capabilities of the party + matter to the claim at issue. It says what grounds the limit on each + of them. This document does not say which grounds suffice to + establish that such a limit holds. + + The capabilities in question are these. + + Forgery: The party can make a relying party accept false evidence. + One way is to fabricate the evidence, substitute or replay it, or + alter it without detection. Another is to direct the component + that produces the evidence, so that its output is false. + + Concealment: The party can act outside the recording boundary, so + that the activity is not recorded there. It can also suppress, + withhold, or delay evidence that exists. + + Circumvention: The party can complete the action without the + enforcement point, or direct the decision of that point. + + + +Sergeev Expires 27 March 2027 [Page 17] + +Internet-Draft Claim Boundaries September 2026 + + + Where this document says "bypass", bypassing an enforcement point is + circumvention and bypassing a recording boundary is concealment. + + A claim needs limits only on the capabilities that matter to it. A + capability matters to a claim if the party could use it to leave the + relying party holding the same evidence while the claim is false. + That is the test of Section 3, applied to what the party can do. + Take a particular finding made from evidence already received. + Forgery matters to it, and so does the binding of the evidence to the + exact action (Section 9). A payment network's record of transfer T + can support that T occurred. This holds although the operator could + have withheld the record or made other transfers elsewhere. + Concealment matters to completeness and to detection coverage (rules + 4 and 5). The same record does not support that these are all of the + operator's transfers. Concealment can also matter to a particular + finding, where omitted evidence would change the finding. + Circumvention matters to prevention. The limits have to hold for the + period the claim depends on. A present assessment does not by itself + establish that the limits held earlier. + + Independence does not make an observation relevant to the claim. An + observer outside the operator's control that saw a command sent has + not thereby seen it executed. A separate question remains: can the + observation distinguish a true claim from a false one (Section 3)? + + A dependency can enter where evidence is formed, where it is + delivered, and where it is evaluated. An independent evaluator can + verify the interested party's own account, but the account does not + become an independent observation. Control over delivery gives the + capability to conceal, and it can also permit substitution or replay, + but it does not give control over the source. An independent + component does not make a record presented as its output authentic: + the operator can present a forged confirmation from an independent + payment network. The relying party therefore checks origin, binding + to the exact action, and any required freshness separately + (Section 9). + + Two sources that take a fact from the same origin both depend on that + origin for that fact. Two logs that each copy the operator's message + are not two observations of execution (rule 3). Where one party has + the relevant capability over several components, those components do + not count separately against that party. Three services that act, + record, and check, run by one operator who can change their code or + their records, divide the work but not the control. The useful + question is which error or fabrication the second source rules out. + Independence from one party does not establish independence from a + coalition that includes it. + + + + +Sergeev Expires 27 March 2027 [Page 18] + +Internet-Draft Claim Boundaries September 2026 + + + A statement of independence is itself a claim, with a producing + boundary and a ceiling. Its grounds can stop at a premise that a + party accepts as a matter of policy. A claim that relies on the + statement then stays conditional on that premise. The premise + travels with that claim when it is passed on (Sections 6 and 11). + The audit example in Section 8 shows one such premise. Section 9 + describes evidence whose source need not be independent. + +9. When stronger claims become supportable + + The discipline does not only rule claims out. Stronger claims about + a particular effect become supportable when the effect is observed at + a boundary capable of observing it. That capability is judged under + the stated threat and control model. The evidence of that + observation must also be protected against undetected fabrication or + alteration by the interested party. Coverage claims additionally + depend on the observation and delivery conditions described in + Section 8. + + An external footprint is one important route to such observation. + Examples are movement on a payment rail, and resource or + configuration records in an external provider's control plane. In + each, a system the interested party does not control observed + something at its own boundary, and a relying party can check that + system's records against the claim. + + It is not the only route. The observing boundary may be any of + several things: + + * an external service, a counterparty, or a settlement system; + + * an external control plane; + + * the relying party's own observation boundary, where the relying + party itself observes the effect: a state change in a system it + operates, or a delivery it takes receipt of itself; + + * another point that is in a position to observe the relevant fact + and that the interested party does not control under the stated + threat model. + + A distinct third party is not always necessary. The relying party's + own observation may provide the required evidence, subject to the + same claim-specific trust and deployment assumptions. + + A further route relies on a record constituting the precise action + claimed, rather than describing a separate action: + + + + +Sergeev Expires 27 March 2027 [Page 19] + +Internet-Draft Claim Boundaries September 2026 + + + * a signed order that is the order; + + * a recorded state transition on a ledger that is the transfer; + + * a recorded command whose issuance is itself the claimed action; + + * a write-ahead entry that defines the commit. + + Such a record supports that precise claim, because issuing or + accepting it constitutes the action under the applicable rules. The + evidence must establish the conditions that give the record that + constitutive effect, including any applicable authority, acceptance, + and commit or finality conditions. A record on a branch that was + never accepted does not constitute the action merely by resembling + one that would. + + What it supports is bounded by the action it constitutes and extends + no further. A ledger entry that is the transfer establishes the + transfer, not that goods moved. A signed order that is the order + establishes the order, not that it was carried out. Where a record + describes an action it does not constitute, this route does not + apply. + + Another route relies on evidence whose verification itself + establishes a predicate. Examples are a proof of computation, a + proof of possession, and a response to a fresh challenge. The source + of such evidence does not need to be independent of the interested + party. Successful verification establishes the proved predicate, + under the premises of the verification. Those premises include the + soundness of the proof system, the integrity of the verifier, and + that the statement verified is the one the claim names. Where + soundness bounds the probability of a false acceptance rather than + excluding it, treating it as exact is an idealization, and a report + that relies on it should say so. A claim that does not follow from + that predicate needs its own evidentiary grounds and the bindings it + requires. For a proof of computation, such claims can concern + whether the committed inputs match the facts they stand for. They + can concern who performed the computation, when a policy was applied, + or whether an external effect followed. Signature verification is + the familiar case: the proved predicate is that the bytes were signed + under the key, and rule 1 applies to anything beyond it. + + The qualifications below travel with these routes: + + + + + + + + +Sergeev Expires 27 March 2027 [Page 20] + +Internet-Draft Claim Boundaries September 2026 + + + * The observing boundary supports claims at its own observation + boundary and no further. A payment network's record establishes + what the network observed about a transfer at its boundary, not + that a business obligation was satisfied. A relying party's own + observation establishes what the relying party observed at its + boundary, and no more. + + * The observation, whether an external footprint or the relying + party's own, must be bound to the exact action claimed. A + matching amount, timestamp, or counterparty is correlation, and + correlation supports weaker claims than a validated binding. + + * The protection afforded by the observing boundary is itself a + threat-model statement. For a particular finding, the relevant + protection is against the operator of the acting system + fabricating or undetectably altering the evidence for the claimed + observation. Against the operator of the observing boundary + itself, the route gives no additional support. Where the relying + party observes at its own boundary, the claim rests on the relying + party's own observation, which is independent of the interested + party but not of the relying party. + + * An effect is observed at a time. The observation does not, by + itself, establish that the effect persisted or is final. A + transfer can be reversed, a write can be rolled back, and a ledger + branch can be abandoned. A claim of a durable or final effect + needs evidence of the conditions that make it so. The rules of + the system where the effect occurs set those conditions. That + evidence needs one of the routes of this section. + + * Ordering claims, such as that the decision preceded the effect, + require an ordering relation whose observational domain includes + both terms. That means one boundary that observed both, or + records from the two boundaries that can be securely related and + ordered. Matching records alone establish neither the order of + the records nor the order of the events. + + * The capability to conceal does not, by itself, invalidate evidence + that has been received (Section 8.1). Subject to the + qualifications above, the received evidence may support a + particular finding within its observational and temporal scope. A + finding that depends on the completeness of a specified evidence + set, or on absence as evidence of non-occurrence, requires the + corresponding coverage and gap-resolution basis (rules 4 and 5). + + + + + + + +Sergeev Expires 27 March 2027 [Page 21] + +Internet-Draft Claim Boundaries September 2026 + + +10. Worked example: a payment + + Consider an agent that reports having paid a supplier. Three + evidence artifacts and a report combining them are on the table. The + point of the example is that they support different claims, and that + a report must keep separate what each boundary observed from what it + merely asserts. + + 1. A self-produced execution record. The operator's own service + emits a signed record: "paid supplier S, amount X, at time T". + Observed at that boundary: that the operator's service produced + and signed this statement. Asserted, not observed there: that + the payment reached S. What it supports on its own: that the + operator stated a payment; not that the payment occurred (rules + 1, 3, 7). + + This example assumes that the record contains only the operator's + own statement. If it carries independently verifiable evidence + from another source, that evidence is appraised at its own + producing boundary. The party assembling the container does not + determine every item's origin. + + 2. A transparency registration. The signed record is registered + with a transparency service, which returns a receipt carrying an + inclusion proof. Observed: that this statement was registered + under the service's policy. Any claim about registration time + depends on the time evidence provided and its verified scope. + What it does not establish: the truth of the statement or the + occurrence of the payment (rule 3). Registration raises + auditability, not the claim ceiling. + + 3. External payment-network evidence. A record from the payment + network -- a settlement entry or network-issued confirmation -- + that the network observed a transfer matching the action. + Observed at a boundary outside the operator's control: that the + network saw a transfer with these attributes. This is the + footprint of Section 9, and it must be bound to the exact action: + a bare amount-and-time match is only correlation. Its strength + holds against the operator, not against the payment network's own + operator. + + 4. A composite report. A report that draws on all three should + read, in substance, as three statements. The operator asserts a + payment (1). The assertion is registered and independently + checkable as an assertion (2). And where (3) is present and + bound to the exact action, a system outside the operator observed + a matching transfer at its boundary. That last supports a + payment-reached-the-network claim, to the extent the binding + + + +Sergeev Expires 27 March 2027 [Page 22] + +Internet-Draft Claim Boundaries September 2026 + + + holds and that evidence is protected against fabrication or + undetected alteration by the operator. With only artifacts (1) + and (2), the supportable claim is that the operator stated and + registered a payment, not that a payment occurred. + + A report over these artifacts could read as follows. Evaluator V + checked the origin of each artifact and the binding of the network + record to the payment. V accepts one named premise: the network's + record is reliable for the event it reports. Assume that the record + reports that a transfer was seen, and says nothing about finality. V + did not assess whether the set covers all of the operator's payments. + + * A statement of the payment was signed under the operator's key. + Evaluated. Supported: the signature verifies. + + * The statement was registered. Evaluated. Supported: the receipt + verifies, within its scope. + + * The network observed a transfer bound to this payment. Evaluated. + Supported: origin and binding were checked, under the named + premise. + + * The payment to S is final. Evaluated. Unsupported by this set: + the evidence evaluated does not establish the conditions for + finality (Section 9). + + * These are all of the operator's payments in the period. Not + evaluated: completeness was not assessed (rule 4). + + Suppose instead that only the amount and the time match, and the + binding is not established. The third entry is then unsupported for + this payment. That the network saw some transfer remains supported. + + The example makes no universal assertion about what any particular + service observes. What a given payment service, transparency + service, or agent runtime actually observed is a fact about that + deployment, to be stated from its evidence, not assumed from its + role. + +11. Reporting what the evidence supports + + Where evidence does not support the claim asserted over it, the + useful output is not a bare failure. For each claim, a report says + whether the evaluation was made and, if it was, what it found. These + are separate questions. An outcome-binding profile drew a related + line earlier: its indeterminate state, used when required evidence is + missing, unauthenticated, unpinned, or not exactly bound, is not a + comparison outcome [I-D.schrock-ep-outcome-binding]. + + + +Sergeev Expires 27 March 2027 [Page 23] + +Internet-Draft Claim Boundaries September 2026 + + + Whether the evaluation was made: + + Evaluated: The relevant assessment ran over identified evidence, in + an identified appraisal context. + + Not evaluated: The assessment did not run, the identified evidence + could not be obtained, or the premise was outside the evaluation's + scope. This status supplies no finding for or against the claim. + It does not mean the claim is false, and it does not determine + what the available evidence would support if evaluated. Nor is it + permission to discard evidence that positively supports a claim at + its own base. A claim well supported at its own base stays + supported, even while another claim is not evaluated. It is also + not a reason to repeat an action whose outcome is unknown, since + the first attempt may have completed. That profile states the + same limit for its indeterminate state + [I-D.schrock-ep-outcome-binding]. + + Unverifiable: A reason for "not evaluated" that belongs to the + evaluator. The statement is one that the evaluator in question + cannot check from the evidence and inputs available to it at + the time of evaluation. The standing example is a producer's + description of its own deployment, which an evaluator may be + unable to check without deployment access or other adequate + evidence about that deployment. The category is relative to an + evaluator and to an evidence or input set. Where they matter, + it is relative to an evaluation context or time as well. A + statement can pass from verifiable to unverifiable while the + record itself is unchanged. The evaluator that could check it + may cease to exist, or lose its access or the means to + interpret what it holds. Such statements can still be worth + carrying. The report names the reason and the premise that was + not checked. Where a statement rests only on the producer's + account, the report says so. A reader can then see which parts + of a composite claim rest on trust. A report that fixes the + category without fixing the evaluator and the moment says less + than it appears to. + + What the evaluation found: + + Supported: The evidence evaluated supports the claim as stated, + under the stated premises. + + Unsupported: The assessment ran over the evidence evaluated, and + + + + + + + +Sergeev Expires 27 March 2027 [Page 24] + +Internet-Draft Claim Boundaries September 2026 + + + that evidence failed it. This is a finding about the evaluated + evidence, relative to the evidence set and the appraisal context + in which it was evaluated. It is not a property of the world, and + a different evidence set may support the claim. Where the + assessment ran and the evidence evaluated lacks what the claim + needs, the claim was evaluated and the finding is unsupported. + + Refuted: The evidence supports the negation of the claim. Absence + of a record refutes a claim of occurrence only where rule 5 of + Section 6 permits the inference from absence to non-occurrence. + The report should state that finding and its basis explicitly, + rather than treating it as mere absence of support. + + One reporting practice applies to both questions: + + Downgrade to the supportable claim: Where the asserted claim is + unsupported or not evaluated, report the strongest claim of the + kind at issue that the evidence does support, or the supported + claims where there is no unique strongest one, alongside the + asserted claim, with its status and any finding. A claim + supported at another base is a separate finding, not a downgrade; + support at one base is not inferred from support at another + (Section 4). "Invocation: supported. Execution: unsupported by + the evidence evaluated" is actionable; "invalid" is not. + + Collapsing "not evaluated" into "unsupported", or either into + "refuted", destroys information a relying party needs: "we checked + and it failed" and "we could not check" call for different decisions. + These terms are not a result-code set. One report can say that a + claim was not evaluated because a premise is unverifiable, and also + identify a weaker claim that is supported. + + A support assessment over the available evidence can complete while a + required premise is not evaluated. The report identifies these + assessments separately. + + Each of these terms is relative to the evidence actually evaluated, + and a report is more useful when it says what that evidence was. The + evaluated set may itself be incomplete or selected. Every record in + it can verify while records that would have changed the outcome were + never delivered: rule 4 of Section 6, met again at the reporting + layer. + + A verdict applies to the evidence basis it names, and a verdict that + names no basis invites exactly the widening this document is about. + + + + + + +Sergeev Expires 27 March 2027 [Page 25] + +Internet-Draft Claim Boundaries September 2026 + + + Appraisal results travel. One evaluator's result may be consumed by + a later composite report: that a claim was not evaluated, for + instance. The later relying party then needs to distinguish an + attributable appraisal from an unattributed conclusion. + + Propagated or aggregated appraisal results should therefore retain + enough provenance to identify: + + * who or what appraised; + + * the evidence or input basis, or a stable reference to it; + + * the predicate, profile, or evaluation context under which the + result was reached, including the boundary at which the appraisal + was made. + + Without that, "not evaluated" degrades across aggregation into + somebody's unattributed conclusion. That is the aggregation limit of + Section 6 arriving at the reporting layer. Where evaluated evidence + or received appraisals support incompatible findings, the report + identifies the conflict and any premise used to resolve it. + + This is a consideration for reporting designs. It is not a record + format and not a general retention requirement. The provenance of an + appraisal identifies who is reported to have appraised what, under + which context. By itself it establishes neither that the appraisal + ran as reported nor that the underlying event occurred. + + A reporting design that preserves these distinctions makes inflation + visible: every summary that would erase one of them is a place where + a stronger claim would otherwise silently replace a weaker one. + +12. Applicability beyond AI agents + + Nothing in this discipline is stated in terms specific to AI agents. + The same bounding questions apply to: + + * audit logging and monitoring pipelines, where the questions are + what the log source observed and who can write to it; + + * evidence collection and archiving practice [RFC3227]; + + * signed system logs [RFC5848]; + + * transparency systems ([RFC9162], [RFC9943]); + + * long-term evidence records [RFC4998]; + + + + +Sergeev Expires 27 March 2027 [Page 26] + +Internet-Draft Claim Boundaries September 2026 + + + * compliance reporting and incident forensics; + + * operational telemetry, which is self-reported by instrumented code + and designed for diagnosis rather than adjudication. + + Agent systems sharpened the problem. Actions are initiated by + software whose records are produced mostly at the acting side, and + delegation chains multiply the boundaries across which claims travel + and inflate. But the rules in Section 6 are stated as properties of + evidence rather than of agents. + + One domain is worked here: the long-term preservation of records, + where no agent acts and no payment is made. A preserving repository + holds a record deposited by its creator. Fixity evidence can support + a claim that deposited bytes have not changed relative to an accepted + baseline. Identity and provenance evidence may support an + authenticity assessment under stated assumptions. Archival + diplomatics drew this distinction earlier and for a different + substrate. It separates a record's reliability at the point of + creation, the accuracy of its content, and its authenticity + [INTERPARES] [DURANTI1998]. Neither finding, by itself, establishes + that the record was reliable when created or that its content was + accurate. Preservation does not convert custody integrity into truth + of the original content. That is an instance of the claim ceiling of + Section 5. + + A gap in a deposited series supports no conclusion about what was + never deposited, unless the deposit regime was declared, enforced, + and observable to a party outside the depositor (rule 5). Whether a + preserved record can still be evaluated depends on the record, the + available representation and provenance information, and the + evaluator's knowledge and access. This illustrates the evaluator- + and time-relative unverifiability of Section 11. The Open Archival + Information System (OAIS) reference model addresses continued + understandability for an identified Designated Community [ISO14721]. + + Appendix B gives three public findings that state the same bounds + outside agent systems. Applicability to the other domains listed + above is asserted on the same grounds and is not worked case by case + here. + +13. Related work + + The following work provides existing mechanisms and domain-specific + treatments relevant to these limits. This document collects selected + implications for the appraisal of execution-related claims. + + Non-bypassable mediation and tamper-evident logging: Two older + + + +Sergeev Expires 27 March 2027 [Page 27] + +Internet-Draft Claim Boundaries September 2026 + + + lineages give this discipline its positive content. In the + reference-monitor lineage, a security-relevant decision is + enforced only where every access is mediated by a mechanism the + controlled party cannot bypass and cannot tamper with [ANDERSON72] + -- the prevention half of Section 8. In the tamper-evident and + transparency-logging lineage, alteration or equivocation in a + record set can be made externally detectable [SCHNEIER-KELSEY] + [RFC9162] -- the detection half. This document restates the + boundary conditions those lineages already identified. It adds no + mechanism, and claims none of them. + + Attestation: RFC 9334 [RFC9334] defines remote-attestation roles, + appraisal flows, and trust assumptions, and the Entity Attestation + Token (EAT) [RFC9711] provides an attested claims set. This + document draws on those concerns to organize a review discipline + for execution-related claims across artifact classes. It defines + no remote-attestation machinery. + + Transparency and receipts: CBOR Object Signing and Encryption (COSE) + Receipts [RFC9942] prove properties of a verifiable data + structure, such as inclusion and consistency. Successful + verification supports the specified data-structure predicate under + the applicable cryptographic and trust assumptions. It does not, + by itself, establish that an event described in a registered + statement occurred. Supply Chain Integrity, Transparency, and + Trust (SCITT) [RFC9943] applies transparency mechanisms to supply- + chain statements and explicitly addresses the limits posed by + dishonest issuers. Certificate transparency provides inclusion + and consistency checks over log views [RFC9162]. A misbehaving + log can nevertheless present inconsistent views to different + clients. Detecting that behavior depends on comparing relevant + observations, or on other mechanisms that address such split + views. These are existing examples of bounded evidence claims. + + Supply-chain step attribution: in-toto [IN-TOTO] binds the artifacts + flowing between the steps of a software supply chain, the order of + the steps, and the identity of the party that signed for each, + against a layout declared in advance by the project owner. Its + analysis states the assumptions under which that binding holds, + and how the guarantees degrade under key compromise. Both are + boundary statements of the kind this document asks producers to + make explicit. + + Provenance: PROV [PROV-DM] models provenance as asserted + descriptions that feed trust assessment, not as verdicts. + + Prior formulations by the author: The four bases of Section 4 and + + + + +Sergeev Expires 27 March 2027 [Page 28] + +Internet-Draft Claim Boundaries September 2026 + + + the ceiling of Section 5 restate, in generic terms and without the + level scale used there, content levels and the boundary axiom + (Axiom BC) of earlier joint work with Vladimir Ikher [WITMODEL]. + The Witnessability Conceptual Core states the generalization of + that axiom as a derived rule [WCC-CORE]. The appraisal core of + the Witnessed Execution Protocol (WEXP) [I-D.sergeev-wexp-core] + gives an exclusion-only operational realization that binds exact + predicates to the four bases. This document preserves that + exclusion-only role. It makes no claim of independent discovery + or priority, and its rules can be stated and applied without + either work. The author's interest in WEXP is disclosed below. + + Agent-protocol evidence work: Individual Internet-Drafts address + per-claim verifier, binding, freshness, and failure discipline + [I-D.bu-agentproto-security-principal-binding]; enrollment and + key-binding assumptions [I-D.yossif-enrollment-problem]; evidence + of authorization decisions [I-D.bradleyb-audit-decision-records]; + and an architecture for auditing agents' interactions and + delegation [I-D.kuehlewind-audit-architecture]. Work on agent + control delivery and outcome reconciliation + [I-D.abak-agent-control-delivery-evidence] distinguishes issuer- + side emission, required-target resolution, receiver-side + observation, enforcement outcome, and observation of the resulting + control effect. + + An outcome-binding profile [I-D.schrock-ep-outcome-binding] + separates the authorization of an action from its observed effect. + It binds signed observations from executors, systems of record, + and independent observers to the same authorization, action + digest, and operation, with exact-equality checks on the action + and source bindings, plus relying-party-defined observation-window + requirements. It treats a declared control domain as relying- + party policy input rather than proof of independence. And it + returns an indeterminate state when required evidence is missing + or unauthenticated. + + A further draft [I-D.wadkins-agentproto-action-determinability] + states mechanism-independent requirements for making a claimed + agent transition independently determinable after the original + interaction has ended. It addresses the binding of the material + action and its governing conditions, a verification procedure that + establishes that those conditions actually governed the transition + when it occurred, determination without requiring cooperation from + an original participant whose conduct or assertion is material to + the facts determined, and negative, transferred, or incomplete + transitions. + + + + + +Sergeev Expires 27 March 2027 [Page 29] + +Internet-Draft Claim Boundaries September 2026 + + + These works address related questions at specific boundaries. The + discipline here can be applied to the claims made over their + evidence. + + Non-inference rules stated for a record format: In the agent2agent + discussion of a dimensional model for agent-protocol proposals, + Blake Morrison set out rules for records carried under different + extensions of one format [AP-MORRISON-RULES]. They are related + limits on inference across records and extensions. They are + proposals made on a mailing list, and they are cited as + independent work, not as support for this document. + + Authentication and admissibility in evidence law: The separation of + what an artifact is from what its content establishes is + normative, not only analytic. Under the United States Federal + Rules of Evidence, a certified record generated by an electronic + process, and a certified copy authenticated by digest comparison, + are self-authenticating. The advisory committee states limits on + that [FRE902]. Such a certification establishes authenticity + only. Authenticating a machine output establishes that the output + came from that system, rather than that the information it carries + is reliable. The burdens, admissibility rules, and remedies of + evidence law remain outside this document's scope. + + Assurance cases: The claims-argument-evidence tradition provides + structured argumentation over evidence. ISO/IEC/IEEE 15026-2 + specifies requirements for assurance-case structure terminology + [ISO15026-2], and the Goal Structuring Notation community standard + provides a notation for such arguments [GSN]. The presence of an + assurance case or a graphical representation does not, by itself, + establish that a particular evidential inference is justified. + +14. Security considerations + + This document specifies no new protocol mechanisms. Its subject is + the prevention of a class of security failures that occur at the + semantic layer: relying parties accepting claims stronger than the + evidence supports. + + Cautions about the discipline itself, including its misuse: + + * The discipline does not make a dishonest or compromised evidence + source honest. It bounds what a relying party should infer. It + does not improve the evidence. + + + + + + + +Sergeev Expires 27 March 2027 [Page 30] + +Internet-Draft Claim Boundaries September 2026 + + + * The discipline does not make an evaluator correct either. Every + finding is conditional on the correctness of the evaluator and of + the tools and inputs it relies on. That condition is a premise of + every report, whether or not the report states it. + + * "Not evaluated" is not a license to discard evidence. A report + that one claim was not evaluated, or is unsupported, is not a + basis for setting aside evidence that positively supports another + claim at its own base. The correct output is that supported + claim, reported as such (Section 11). + + * Deliberately unobservable topology is a limitation to report, not + an exoneration. An interested party may arrange that its + enforcement or observation points cannot be checked by anyone + else. The report then says which evaluation failed or could not + be made (Section 11). Unobservability does not support the + corresponding prevention or detection-coverage guarantee, and it + is not evidence of good behavior. This does not extend to every + case-level finding that received evidence may support. + + * Conformance vocabulary is itself inflatable. "Consistent with the + claim-boundary discipline" is not a property a document or product + can certify by assertion. The test is whether specific claims are + bounded by specific producing boundaries, checked claim by claim. + + * Detection mechanisms can leak information. Making refusals, gaps, + or suppression observable to an external party discloses timing + and frequency information to that party. Deployments should weigh + the observability required by Section 8 against what the + observation channel itself reveals; RFC 6973 [RFC6973] gives the + model for stating that residual exposure. + +15. IANA considerations + + This document has no IANA actions. + +16. Informative References + + [ANDERSON72] + Anderson, J. P., "Computer Security Technology Planning + Study", ESD-TR-73-51, Vol. II, HQ Electronic Systems + Division (AFSC), October 1972, + . + + + + + + +Sergeev Expires 27 March 2027 [Page 31] + +Internet-Draft Claim Boundaries September 2026 + + + [AP-ECKEL] Eckel, C., "Re: DRAFT minutes from the AGENTPROTO BoF", + message to the agentproto@ietf.org mailing list, 30 July + 2026, . + + [AP-FARRELL-ABC] + Farrell, S., "Re: DRAFT minutes from the AGENTPROTO BoF", + message to the agentproto@ietf.org mailing list, 29 July + 2026, . + + [AP-FARRELL-CHEAT] + Farrell, S., "Re: DRAFT minutes from the AGENTPROTO BoF", + message to the agentproto@ietf.org mailing list, 30 July + 2026, . + + [AP-JIANG-CONTINUITY] + Jiang, Y., "Re: draft-bu-agentproto-security-principal- + binding-06 published: focused review request", message to + the agent2agent mailing list, 15 September 2026, + . + + [AP-LIU-DPOP] + Liu, D., "Re: DRAFT minutes from the AGENTPROTO BoF", + message to the agentproto@ietf.org mailing list, 30 July + 2026, . + + [AP-MORRISON-RULES] + Morrison, B., "Re: New I-D : A Dimensional Model for + Characterizing AI Agent Protocol Proposals and Their + Substrates", message to the agent2agent mailing list, 4 + September 2026, + . + + [AP-SAMMARTANO] + Sammartano, S., "Re: DRAFT minutes from the AGENTPROTO + BoF", message to the agentproto@ietf.org mailing list, 30 + July 2026, + . + + [AP-SAMMARTANO-FRAMING] + Sammartano, S., "Re: DRAFT minutes from the AGENTPROTO + BoF", message to the agentproto@ietf.org mailing list, 30 + + + +Sergeev Expires 27 March 2027 [Page 32] + +Internet-Draft Claim Boundaries September 2026 + + + July 2026, + . + + [AP-SCHROCK-RETENTION] + Schrock, I., "Re: New I-D : A Dimensional Model for + Characterizing AI Agent Protocol Proposals and Their + Substrates", message to the agent2agent mailing list, 14 + September 2026, + . + + [AP-SERGEEV-GATE] + Sergeev, M., "Re: DRAFT minutes from the AGENTPROTO BoF", + message to the agentproto@ietf.org mailing list, 30 July + 2026, . + + [CCSDS652-1] + Consultative Committee for Space Data Systems, + "Requirements for Bodies Providing Audit and Certification + of Candidate Trustworthy Digital Repositories", + CCSDS 652.1-M-3, Issue 3, December 2024, + . + + [DID-CORE] World Wide Web Consortium, "Decentralized Identifiers + (DIDs) v1.0", W3C Recommendation, Sections 9.2 and 9.11, + 19 July 2022, + . + + [DURANTI1998] + Duranti, L., "Diplomatics: New Uses for an Old Science", + Scarecrow Press, 1998. + + [EPA-VW] United States Environmental Protection Agency, "Learn + About Volkswagen Violations", agency overview of the Clean + Air Act violations, including the Notice of Violation of + 18 September 2015, 10 June 2026, . + + [EPA-VW-NOV] + United States Environmental Protection Agency, "Notice of + Violation", letter to Volkswagen AG, Audi AG, and + Volkswagen Group of America, Inc., 18 September 2015, + . + + + + + +Sergeev Expires 27 March 2027 [Page 33] + +Internet-Draft Claim Boundaries September 2026 + + + [FRE902] United States, "Federal Rules of Evidence, Rule 902(13) + and Rule 902(14), with Advisory Committee Notes", December + 2017, . + + [GRENFELL2] + Grenfell Tower Inquiry, "Grenfell Tower Inquiry: Phase 2 + Report, Volume 1", HC 19-I, Part 1, Chapter 2, paragraphs + 2.122-2.123, September 2024, + . + + [GSN] SCSC Assurance Case Working Group, "Goal Structuring + Notation Community Standard, Version 3", SCSC 141C, 2021, + . + + [HAMILTON] Court of Appeal (Criminal Division), England and Wales, + "Hamilton & Ors v Post Office Ltd", [2021] EWCA Crim 577, + paragraphs 136-137, 23 April 2021, + . + + [I-D.abak-agent-control-delivery-evidence] + Abak, A. T., "Evidence Requirements for Agent Control + Delivery and Outcome Reconciliation", Work in Progress, + Internet-Draft, draft-abak-agent-control-delivery- + evidence-01, 4 September 2026, + . + + [I-D.bradleyb-audit-decision-records] + B, B., "Signed Decision Records for Agent Authorization: + Disclosures, Entry Emission, and Ordering Evidence", Work + in Progress, Internet-Draft, draft-bradleyb-audit- + decision-records-00, 13 August 2026, + . + + [I-D.bu-agentproto-security-principal-binding] + Bu, S., "Security Principal and Verifier Binding for Agent + Communication Protocols", Work in Progress, Internet- + Draft, draft-bu-agentproto-security-principal-binding-07, + 15 September 2026, . + + + + + +Sergeev Expires 27 March 2027 [Page 34] + +Internet-Draft Claim Boundaries September 2026 + + + [I-D.fengfar-led] + Farrell, S. and C. Feng, "Dealing with LLMs in IETF + Discussions", Work in Progress, Internet-Draft, draft- + fengfar-led-01, 6 August 2026, + . + + [I-D.ietf-wimse-arch] + Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload + Identity in a Multi System Environment (WIMSE) + Architecture", Work in Progress, Internet-Draft, draft- + ietf-wimse-arch-08, 6 July 2026, + . + + [I-D.kuehlewind-audit-architecture] + Kuehlewind, M. and H. Birkholz, "An Architecture for + Auditing Agent Delegation and Interactions", Work in + Progress, Internet-Draft, draft-kuehlewind-audit- + architecture-01, 7 September 2026, + . + + [I-D.schrock-ep-outcome-binding] + Schrock, I., "Outcome Binding for Authorized Actions and + Independently Observed Effects", Work in Progress, + Internet-Draft, draft-schrock-ep-outcome-binding-00, 28 + July 2026, . + + [I-D.sergeev-wexp-core] + Sergeev, M. and V. Ikher, "The Witnessed Execution + Protocol (WEXP): Core Specification", Work in Progress, + Internet-Draft, draft-sergeev-wexp-core-01, 16 August + 2026, . + + [I-D.wadkins-agentproto-action-determinability] + Wadkins, D. L., "Independent Determinability of Agent + Actions", Work in Progress, Internet-Draft, draft-wadkins- + agentproto-action-determinability-00, 10 September 2026, + . + + [I-D.yossif-enrollment-problem] + Yossif, M. K., "Problem Statement: Enrollment and Key- + Binding Assumptions in Execution Authority Evidence", Work + in Progress, Internet-Draft, draft-yossif-enrollment- + + + +Sergeev Expires 27 March 2027 [Page 35] + +Internet-Draft Claim Boundaries September 2026 + + + problem-00, 22 July 2026, + . + + [IN-TOTO] Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, + R., and J. Cappos, "in-toto: Providing farm-to-table + guarantees for bits and bytes", 28th USENIX Security + Symposium, August 2019, + . + + [INTERPARES] + Duranti, L., "The Long-term Preservation of Authentic + Electronic Records: Findings of the InterPARES Project", + 2005, . + + [ISO14721] International Organization for Standardization, "Space + Data System Practices -- Reference model for an open + archival information system (OAIS)", also issued as CCSDS + 650.0-M-3, December 2024, ISO 14721:2025, Edition 3, March + 2025. + + [ISO15026-2] + ISO/IEC/IEEE, "Systems and software engineering -- Systems + and software assurance -- Part 2: Assurance case", + ISO/IEC/IEEE 15026-2:2022, 2022. + + [ISO16363] International Organization for Standardization, "Space + data and information transfer systems -- Audit and + certification of trustworthy digital repositories", + ISO 16363:2025, Edition 2, March 2025. + + [PROV-DM] World Wide Web Consortium, "PROV-DM: The PROV Data Model, + W3C Recommendation", April 2013, + . + + [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, + "Internet X.509 Public Key Infrastructure Time-Stamp + Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August + 2001, . + + [RFC3227] Brezinski, D. and T. Killalea, "Guidelines for Evidence + Collection and Archiving", BCP 55, RFC 3227, + DOI 10.17487/RFC3227, February 2002, + . + + + + + + +Sergeev Expires 27 March 2027 [Page 36] + +Internet-Draft Claim Boundaries September 2026 + + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, + DOI 10.17487/RFC3552, July 2003, + . + + [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence + Record Syntax (ERS)", RFC 4998, DOI 10.17487/RFC4998, + August 2007, . + + [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog + Messages", RFC 5848, DOI 10.17487/RFC5848, May 2010, + . + + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + . + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + . + + [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate + Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, + December 2021, . + + [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and + W. Pan, "Remote ATtestation procedureS (RATS) + Architecture", RFC 9334, DOI 10.17487/RFC9334, January + 2023, . + + [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., + Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of + Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, + September 2023, . + + [RFC9591] Connolly, D., Komlo, C., Goldberg, I., and C. A. Wood, + "The Flexible Round-Optimized Schnorr Threshold (FROST) + Protocol for Two-Round Schnorr Signatures", RFC 9591, + DOI 10.17487/RFC9591, June 2024, + . + + [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. + Wallace, "The Entity Attestation Token (EAT)", RFC 9711, + DOI 10.17487/RFC9711, April 2025, + . + + + +Sergeev Expires 27 March 2027 [Page 37] + +Internet-Draft Claim Boundaries September 2026 + + + [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. + Fournet, "CBOR Object Signing and Encryption (COSE) + Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, + . + + [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, + Y., and S. Lasker, "An Architecture for Trustworthy and + Transparent Digital Supply Chains", RFC 9943, + DOI 10.17487/RFC9943, June 2026, + . + + [SCHNEIER-KELSEY] + Schneier, B. and J. Kelsey, "Secure Audit Logs to Support + Computer Forensics", ACM Transactions on Information and + System Security, Vol. 2, No. 2, pp. 159-176, + DOI 10.1145/317087.317089, May 1999, + . + + [VC-DATA-MODEL] + World Wide Web Consortium, "Verifiable Credentials Data + Model v2.0", W3C Recommendation, Section 1.1, 15 May 2025, + . + + [WCC-CORE] Sergeev, M. A., "Witnessability Conceptual Core 1.0", + DOI 10.5281/zenodo.21865251, July 2026, + . + + [WITMODEL] Sergeev, M. A. and V. Ikher, "Toward a Witnessability + Model for AI and Software Execution Systems: A Boundary- + Based Framework for Classifying Execution Evidence", + Version 1.1, bridge revision; also at DOI 10.2139/ + ssrn.6994720, August 2026, + . + +Appendix A. The (a,b,c) scenario worked through + + In the agentproto mailing-list discussion of July 2026, in the thread + on the draft minutes of the AGENTPROTO BoF, Stephen Farrell posed a + gating scenario [AP-FARRELL-ABC]. In his words: + + If (a,b,c) is a comms path between agents (perhaps within a tree) + and if 'c' is actually a newly created entity, but one that needs + access to a long-term secret credential accessible at 'a' (e.g. + pwd or SSH private key) and where that credential must not be + exposed to 'b' nor easily abused - then how's that going to work? + + + + +Sergeev Expires 27 March 2027 [Page 38] + +Internet-Draft Claim Boundaries September 2026 + + + He emphasized that "the scenario I posited is one where 'b' creates + 'c' and so is in a fine place to cheat" [AP-FARRELL-CHEAT]. + + The list discussion produced concrete mitigations, collected in a + reply by Shawn Sammartano [AP-SAMMARTANO], who credited most of them + to existing mechanisms: + + * exact, single-use, attenuated permission slips bound to request + bytes; + + * hardware-protected keys, and threshold signing; + + * short-lived credentials, and forward-moving counters; + + * delegation budgets, and delays with cancellation windows; + + * approval separated from the creator. Sammartano also stated the + hard case plainly: "If b builds c, then b can read c's key, so b + can be c. No message format fixes that, mine included." + + The author proposed an enforcement/observation framing in response to + that discussion [AP-SERGEEV-GATE]. The control-topology test of + Section 8 refines that framing by distinguishing adversary-resistant + detection coverage from a particular finding made from evidence + already obtained. Farrell posed the scenario. This document does + not attribute the generalized test to him. Applied to the scenario: + + * Exact, single-use, attenuated authority bounds what the grant + authorizes, where it is enforced. It does not establish that an + action attributed to c was not performed by b, where b created or + hosts c and can obtain or invoke c's signing capability (rules 2 + and 6 of Section 6). + + * A message format can carry the relevant control or evidence. It + cannot create the required independence (Sections 3 and 8.1). + + * A prevention claim at that boundary needs an enforcement point b + does not control and cannot circumvent. A claim that covered + misbehavior cannot be concealed needs evidence b cannot forge, on + a path b cannot silently prune (Section 8). Attestation and + threshold signing supply such points only in deployments that + actually place them outside b's control. + + * What is missing in the hard case is not another field. It is a + point outside b's control that either enforces or observes, and no + message format creates one. + + + + + +Sergeev Expires 27 March 2027 [Page 39] + +Internet-Draft Claim Boundaries September 2026 + + + This is narrower than solving credential custody. It makes the + assurance claim and its trust boundary reviewable before a mechanism + is chosen, which is what a chartering or design review needs. + +Appendix B. Three public findings + + Three public findings state the same bounds outside agent systems, in + the words of the bodies that made them. + + In the English prosecutions arising from the Post Office Horizon + accounting system, the Court of Appeal found that the prosecutor + "treated what was no more than a shortfall shown by an unreliable + accounting system as an incontrovertible loss", and that defendants + were convicted "on the basis that the Horizon data must be correct, + and cash must therefore be missing, when in fact there could be no + confidence as to that foundation" [HAMILTON]. The load-bearing + premise was the reliability of that system. The court recorded that + the prosecutor was under a duty to investigate subpostmasters' claims + that there were problems with it, and it found "failures of + investigation and disclosure". On the reading taken here, that is + the position rule 9 of Section 6 names. The claim rested on a + premise the relying party was required to test and did not adequately + test. The judgment does not address what a bounded report of the + same evidence would have said, and it is not cited for that part of + the rule. + + In the inquiry into the Grenfell Tower fire, the panel examined the + performance criteria applied in large-scale fire tests of external + wall systems. Failure to meet those criteria would show a system + unlikely to comply with the applicable requirement. But "the + converse was not necessarily true": a system might meet the criteria + and yet fail to comply with that requirement [GRENFELL2]. A bounded + test result can tell against a claim in one direction without + establishing it in the other. + + In the third case the test results were genuine outputs of a genuine + test. Vehicles were certified against emissions standards on the + strength of those results [EPA-VW-NOV]. Software detected the test + condition and enabled full emissions controls only then, so the + vehicles "meet emissions standards in the laboratory or testing + station, but during normal operation" emitted nitrogen oxides at + levels up to forty times the standard [EPA-VW]. The result + established the behavior of the vehicle under the conditions the test + applied, which was all it had ever observed. The certificate carried + it to a claim about the vehicle in use (rule 11 of Section 6). + + + + + + +Sergeev Expires 27 March 2027 [Page 40] + +Internet-Draft Claim Boundaries September 2026 + + + These authorities reached findings within their own legal and + regulatory settings. The findings are their own, and their + connection to the rules stated here is this document's reading. + +Appendix C. Changes from -00 + + This appendix is to be removed before publication as an RFC. + + * Independence is defined once, as limits on three capabilities of a + named party or coalition: forgery, concealment, and circumvention + (Sections 2 and 8.1). The earlier definition treated them as one + property. Section 5 no longer repeats the audit example, which + stays in Section 8. + + * Section 2 adds a note on the RATS terms. + + * Section 3 says in which sense this document uses "support", adds a + practical test of it, and points to the routes of Section 9. Its + first bound and the abstract now name what evidence constitutes or + proves, not only what it observed. + + * Section 4 no longer describes the bases as ordered. They are + distinct questions about one action. It now points to Section 9 + for claims about an effect, and it separates the observation base + from an observation in the sense used elsewhere in the document. + + * Section 5 speaks of kinds of claim rather than claim dimensions. + + * Section 6 adds rules 11 to 13: behavior observed under different + conditions, multiplicity of sources, and the coherence of an + account produced by the interested party. Rules 1 to 10 keep + their numbers. Rule 2 adds attribution along a delivery path. + Rule 3 no longer reads matching records as agreement between the + parties. Rule 4 limits itself to the authenticity of individual + records, and rule 7 to the boundary's own observation. The last + sentence of rule 9 now follows the reporting terms of Section 11. + The preamble is shorter. + + * Section 7 revises four items: item 3 names the three capabilities, + item 5 no longer says that a signature or registration supplies no + evidence, item 7 asks which route of Section 9, or which other + stated basis, supports a claimed effect, and item 10 follows + Section 11. + + + + + + + + +Sergeev Expires 27 March 2027 [Page 41] + +Internet-Draft Claim Boundaries September 2026 + + + * Section 9 adds a route through evidence whose verification + establishes a predicate. It adds a qualification on the time and + finality of an observed effect, and it names as an idealization + the treatment of probabilistic soundness as exact. The closing + advice on deployment design is removed, because Section 1.1 puts + evidence design out of scope. + + * Section 10 ends with a sample report. + + * Section 11 separates whether an evaluation was made from what it + found, and notes the related line drawn earlier in + [I-D.schrock-ep-outcome-binding]. The status that -00 called "not + established" is now "not evaluated", because the rules use + "establish" for the relation between evidence and a claim. + Downgrading is now a reporting practice that applies to both + questions, and a claim supported at another base is a separate + finding, not a downgrade. + + * Sections 12 and 13 are shorter. The three public findings move to + Appendix B; the Grenfell summary now follows the inquiry's + wording, and the emissions summary also cites the Notice of + Violation [EPA-VW-NOV]. The paragraph on archival preservation + moves from Section 13 to Section 12. The discussion of Federal + Rule of Civil Procedure 37(e) and the separate paragraph on the + considerations-section genre are removed. Section 7 still names + that genre. + + * Section 13 corrects the paraphrase of requirement DET-3: -00 + omitted the qualifier that limits the cooperation clause to + participants whose conduct or assertion is material. The + paraphrase now follows the published wording of + [I-D.wadkins-agentproto-action-determinability]. + + * Section 13 now lists all five distinctions drawn in + [I-D.abak-agent-control-delivery-evidence]; -00 omitted required- + target resolution. It also cites sources for the reference- + monitor and tamper-evident logging lineages [ANDERSON72] + [SCHNEIER-KELSEY]. + + * Section 14 narrows its opening sentence, and adds that every + finding is conditional on the correctness of the evaluator. The + item on unobservable topology now refers to Section 11 for the + reporting terms. + + * The abstract no longer names the source of the scenario. + Section 8, Appendix A, and the Acknowledgments do. + + + + + +Sergeev Expires 27 March 2027 [Page 42] + +Internet-Draft Claim Boundaries September 2026 + + +Acknowledgments + + The scenario of Appendix A was posed by Stephen Farrell + [AP-FARRELL-ABC]. The mitigation list and the plain statement of the + key-custody limit were collected by Shawn Sammartano [AP-SAMMARTANO], + who also confirmed the enforcement/observation framing used here + [AP-SAMMARTANO-FRAMING]; Charles Eckel proposed that 'a' authorize + 'c' to do something specific on 'a's behalf, rather than expose a + long-term credential [AP-ECKEL]. Dapeng Liu proposed sender- + constrained tokens (DPoP) so that 'b' could not present a token bound + to 'c's key [AP-LIU-DPOP]; Section 8 discusses what they do and do + not prevent. Yuning Jiang raised the continuity of an identity + across restarts, instance changes, and key rotation, which is how the + question behind rule 10 of Section 6 entered this work + [AP-JIANG-CONTINUITY]. The distinction itself is older and is drawn + in [DID-CORE]. Vladimir Ikher is the author's co-author on the + earlier work [WITMODEL] from which the bases of Section 4 and the + ceiling of Section 5 are restated here. This document also benefited + from the broader agentproto and agent2agent mailing-list discussions + of 2026 on evidence, delegation, and audit. The author thanks their + participants without implying that any of them endorses this + document. + + Douglas Wadkins reviewed a pre-submission draft; the statement of + scope in Section 1.1, the additions to Section 11, and the + qualification in Section 12 are responses to his comments. + +Document development disclosure + + This document was drafted with substantial assistance from generative + AI tools, working from the author's prior publications, + specifications, and mailing-list correspondence, at the author's + direction. It also incorporates material arising from adversarial + review conducted with such tools: the wording of several rules, and + the separation of analytical justification from documented practical + confirmation stated in Section 6, were reached that way. In this + version, the treatment of independence (Sections 2, 3, 8.1, and 9), + rules 12 and 13 of Section 6, and the reporting terms of Section 11 + were revised or added the same way. The author reviewed the + resulting text and is responsible for its content, citations, and + attributions. The use of large language models (LLMs) in IETF + discussions is the subject of [I-D.fengfar-led], which explicitly + excludes Internet-Draft and RFC text from its scope. This disclosure + is voluntary. + + + + + + + +Sergeev Expires 27 March 2027 [Page 43] + +Internet-Draft Claim Boundaries September 2026 + + + The author also has an implementation interest in this area: the WEXP + appraisal layer [I-D.sergeev-wexp-core] is the author's own work. + This document is usable independently of it. No organizational + independence between the two works is claimed. + +Author's Address + + Mikhail Sergeev + Independent Researcher + Email: mikhailsergeev369@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sergeev Expires 27 March 2027 [Page 44] diff --git a/published/01/draft-sergeev-claim-boundaries-01.xml b/published/01/draft-sergeev-claim-boundaries-01.xml new file mode 100644 index 0000000..a38b85e --- /dev/null +++ b/published/01/draft-sergeev-claim-boundaries-01.xml @@ -0,0 +1,2334 @@ + + + + + + + + + + +]> + + + + + Claim Boundaries for Execution Evidence + + + Independent Researcher +
+ mikhailsergeev369@gmail.com +
+ + + + + + + evidence claims audit attestation agents + + + + + + +Systems that act in the world produce logs, receipts, approvals, traces, +attestations, provenance statements, and transparency records. These +artifacts are routinely offered as evidence that an action was +authorized, performed, or completed. This document states a discipline +for bounding such claims: the strength of an execution-related claim is +limited by what the available evidence actually observed, constitutes, +or proves, and by the control and observation topology at the boundary +that produced it. Message formats, signature validity, receipt validity, +and registration do not create observation or independence that did not +exist. No message format can supply the independent enforcement or +observation dependencies that a prevention or adversary-resistant +detection-coverage guarantee requires. An appendix works through a +scenario in which one party creates another and may be able to act in +its name. The document defines no protocol, no record format, and no +registry. It collects non-inference rules, a control-topology test for +prevention and detection claims, a worked example, and reporting +distinctions for evidence that does not support the claim asserted over +it. + + + + + + + + + + + + + + +
Introduction + +An operator states that "the payment was executed". The artifact behind +the statement is a signed log entry produced by the operator's own +service. The signature verifies. The schema validates. The entry was +registered with a transparency service. None of that establishes that +the payment reached the payment network, only that the operator recorded +and registered a well-formed statement saying so. + +Gaps of this kind are routine wherever execution-related evidence is +consumed: audit pipelines, compliance reporting, supply-chain +attestation, and incident forensics. They appeared recently and sharply +in the IETF's agent-protocol discussions of 2026 (), in protocols +for AI agents, where one party's software performs actions whose records +are produced largely by the acting side itself. + +The failure mode is semantic and assurance inflation: the strength of a +claim silently grows as an artifact moves between parties, formats, and +summaries. A record of an invocation is cited as proof of execution. A +valid signature is read as truth of the signed statement. The presence +of an audit trail is read as completeness of coverage. An authorization +is reported as an action performed. Each step feels small, but together +they produce a claim that no producing boundary ever observed. + +This document states the bounding discipline in one place, in +protocol-neutral terms, so that specifications, deployments, and reviews +can name the exact point at which a claim outruns its evidence. + +
Scope and non-goals + +This document is descriptive. It defines no wire format, no transport, +no carrier, no record or receipt format, no authority or authorization +mechanism, no registry, and no generic evidence protocol. It does not +compete with, extend, or profile any of the systems discussed in +. It states analytic limits that hold whichever of those +systems carries the evidence. Because it specifies no protocol behavior, +it does not use BCP 14 requirement keywords: statements of the form "X +does not establish Y" are claims about what an artifact can support, not +conformance requirements. + +This document states a claim-appraisal discipline, not an +evidence-design discipline. It identifies when available evidence does +or does not establish a claim, from the position of a relying party +deciding what to conclude from what it has. It does not prescribe the +complete set of observations, bindings, retention mechanisms, or +architecture that would have to be put in place in advance so that a +given claim remains determinable later. Enforcement or observation at +the time of an action and determination at a later time are related, but +they are not the same requirement. What further material should have +been captured or bound at action time, where, and by whom, is related +work and outside the scope of this document. + +The discipline is not new in its parts. Bounded claim statements are +already in use in specific domains: a time-stamp token is evidence that +a datum existed before a particular time, and the authority time-stamps +only a hash of the datum and does not examine it ; DomainKeys +Identified Mail (DKIM) distinguishes the signing domain from the +purported author and limits its integrity assertion to the content +covered by the signature ; certificate transparency describes +its logs as making misissuance detectable rather than preventing it +; supply-chain transparency describes itself as holding +issuers accountable rather than preventing dishonest ones . +This document collects such statements as one discipline for +execution-related evidence and claims no priority for any individual +rule. + +
+
+
Terminology + +This document uses the following terms descriptively. It uses "claim", +"evidence", and "relying party" in their general senses. In the Remote +ATtestation procedureS (RATS) architecture , Evidence and +Attestation Results are distinct artifacts, and either can serve as +evidence here. A RATS Claim is a piece of asserted information inside +such an artifact, while a claim here is a statement offered for +reliance. Where a RATS term is meant, it is capitalized. + +
+
Claim:
+
+ A statement offered for reliance, concerning an action: that it was +intended, authorized, invoked, performed, completed, or had an effect. +
+
Evidence:
+
+ Artifacts offered in support of a claim: records, logs, receipts, +signatures, attestations, provenance statements, transparency entries, +and similar. +
+
Producing boundary:
+
+ The vantage point, component, or interface at which a piece of +evidence was produced, together with what that vantage point could +observe and who controls it. This document uses "producing boundary" +throughout as its genus term for that vantage point. +
+
Interested party:
+
+ A party whose conduct the claim describes or whose incentives are +served by the claim being accepted; typically the operator of the +acting system. +
+
Relying party:
+
+ A party deciding whether to accept the claim. +
+
Control topology:
+
+ The arrangement of which parties control which enforcement points, +observation points, keys, and delivery paths relevant to a claim. +
+
Independence:
+
+ A property of deployment and control. A statement of independence +names a component and its role: enforcement, observation, delivery, or +evaluation. It can instead name a record or the grounds of a premise. +It names a party or a coalition (parties acting together), a period, +and a threat model. The named thing is independent of that party with +respect to a capability if the party lacks that capability over it. + names three capabilities: forgery, concealment, and +circumvention. Which of them matter depends on the claim. Independence +describes control. Whether the evidence supports the claim is a +separate question (). A label, a field value, a distinct +key, an organizational name, or a count of components does not by +itself establish independence. +
+
+ +
+
The bounding principle + +The strength of an execution-related claim is bounded by: + + + what the available evidence actually observed, constitutes, or +proves, at the boundary that produced it; and + the control and observation topology at that boundary: who operated +it, who could bypass it, and through whose hands its output travels. + + +Message format, signature validity, receipt validity, and registration +do not raise either bound. A format can carry a statement about control +or observation, but it cannot create control or observation that did not +exist. A signature authenticates bytes under a key. By itself it +establishes neither the truth of what the bytes assert nor the signer's +control of the boundary they describe. A receipt's evidential force +depends on the property being checked, the observations or proofs that +support it, and the applicable trust and deployment assumptions. +Successful verification of a registration receipt can support that a +statement was registered under the service's policy. Registration alone +does not establish that the event described in the statement occurred. + +These limits concern what follows from the stated evidence and premises. +They do not preclude an inference from complementary observations whose +relationships and load-bearing assumptions are established. +Cryptographic verification can support those assumptions. It does not +supply a missing observation by authenticating a statement about it. + +Support does not have to come from direct observation of the claimed +action. describes the other routes and their premises. + +In this document, evidence supports a claim when the claim follows from +the evidence under the stated premises. One practical test checks this. +Try to describe two cases in which the relying party holds the same +evidence under the same premises, but the claim is true in one case and +false in the other. If both cases are possible under those premises, the +evidence does not support the claim as stated. Failing to find such a +pair does not prove that none exists. Evidence that only makes a claim +more likely does not support the claim in this sense, although it can +still support a weaker claim (). + +
+
Evidence bases: what did the evidence observe? + +Execution-related artifacts answer different questions, and the +differences are load-bearing. At minimum, the following bases are worth +distinguishing: + +
+
Observation:
+
+ Some event concerning the action was recorded or reported. Absence of +a record alone is not an observation that an event did not occur. +
+
Intent:
+
+ A specific intention, plan, approval, or decision concerning the exact +action is evidenced. This establishes neither the validity of the +approval nor anything about performance. +
+
Invocation:
+
+ The exact request crossed an observed invocation boundary. This does +not establish that the invoked operation executed or had an effect. +
+
Execution:
+
+ Performance of the exact action was evidenced at a boundary in a +position to observe execution. This does not establish completion of a +larger process, a durable external effect, goal satisfaction, +correctness, or policy compliance. addresses claims +about an effect, its persistence, and its finality. +
+
+ +The observation base asks only whether some event concerning the action +was recorded or reported. Elsewhere in this document, an observation is +an event seen at a boundary in a position to see it (Sections + and ). Evidence at the observation base +need not be an observation in that sense. + +These bases are distinct questions about one action. They are not levels +on one scale, and they need not be mutually exclusive. A conclusion from +one base to another holds only under stated premises. Evidence relevant +to one base does not, merely by being assigned to that base, satisfy the +evidential criteria relied on for another. Distinctions of this kind, +between stages of an action's lifecycle whose evidence does not carry +across, are long established in distributed-systems practice (for +example the separation of a remote procedure call's invocation from its +execution and its result). One executable realization that binds exact +predicates to these four bases appears in . +This document does not depend on it. + +Other distinctions cut across the bases. Verification reach (who can +check a record) is orthogonal to claim strength: a +third-party-verifiable invocation record is still invocation evidence. +And asserted content differs from observed content: a mediator's record +may faithfully report what the mediator asserts about a downstream +outcome it never observed. A useful record says at which boundary it was +produced and whether each statement in it was observed there or merely +asserted there. + +The action referred to by a claim should be identified at the relevant +boundary. A business intention, an authorization, a request attempt, an +execution, and a durable effect need not have a one-to-one relation. +Retries, proxies, and idempotent processing can change those relations. +A composite claim depends on evidence establishing the particular +bindings it uses. This document prescribes no common identifier format. + +
+
The claim ceiling + +In this document, a kind of claim is a family of claims to which the +same type of evidence is relevant, such as the bases of . For a +stated kind of claim, and under stated premises, a producing boundary +limits the claims its evidence can support. Call that limit its claim +ceiling. The term does not presume that all claims of one kind are +comparable, or that one uniquely strongest claim exists. + +A boundary in a position to observe invocations, but not execution, +cannot by its observations warrant execution claims. That holds no +matter how many well-formed execution assertions its records carry. + +The underlying idea is old and this document claims no priority for it: +a conclusion cannot be stronger than the vantage from which its +supporting evidence was produced. describes prior +formulations. + +A claim ceiling is an exclusion rule, not an evidence source. It can +prevent a stronger claim from being supported, but it never creates +support, so a supported claim still requires positive evidence at its +own base. + +A ceiling is also only as good as the grounding of the boundary +description itself. A boundary descriptor asserted by the producer is +only the producer's own account. describes what grounds +a statement about who controls a boundary. + +The accepted boundary description must apply to the time and deployment +context of the claimed action. A later assessment or a current +configuration does not, by itself, establish the earlier boundary's +properties. + +The same applies to any premise that would make the producer's records +informative without observation. Where a claim rests on the producer's +incentives or objectives being known, that knowledge is itself a premise +requiring its own grounding. An alignment asserted by the producer is +only the producer's own account. + +This document defines independence in terms of control. Payment, +contract, or ownership can give one party the means to direct another +party's output or decision. They count here to the extent that they give +that capability. + +A record that requires no later cooperation from the party whose conduct +is at issue is not, for that reason, independent of that party. A record +it made at the time and left in place needs nothing from it afterwards +and remains its own account of itself. The distinction between +independence from cooperation and independence of the evidence itself +follows an exchange with Douglas Wadkins; see +. + +A claim ceiling is relative. It is stated for one kind of claim, at one +observation boundary, with the support relation proper to that kind: +which evidence supports which claim of that kind. Examples are the bases +of and, separately, the prevention claims and the detection +claims of . + +Claims of different kinds are not ranked against one another by a +ceiling. An execution claim and a detection claim are different kinds of +claim, not points on one scale, and this document defines no scalar +scale, level, or score on which all claims are ordered. "Stronger" and +"weaker" in this document are always read within the kind of claim at +issue. + +
+
Non-inference rules + +The following rules restate as individual limits. Each +names an inference that is invalid without additional, separately +established premises. None is original here; scoped versions of several +appear in the documents cited in . + +Each rule is justified analytically. An example or a standards reference +given with a rule is an illustration, and it is not presented as a +documented incident. Claims about practical occurrence or consequences +require their own support. + +The list is not closed. A reader who finds a promotion these rules do +not name has found a gap in this section, not a license for the +promotion. + + + Successful signature verification does not by itself establish the +truth of an event claim in the signed content. Establishing that +correspondence requires grounds beyond signature validity. +Separately, signature validity alone does not establish the signer's +control of the boundary described by the claim. The same distinction +is drawn for verifiable credentials, where verifiability of a +credential does not imply the truth of the claims encoded in it +, and for signed Decentralized Identifier (DID) +documents, where proofs in the document do not by themselves +necessarily prove control over the DID . + Attribution of an actor is not proof of actorship. That a record is +attributed to a party -- by a key, an identifier, or a credential +associated with that party -- does not establish that the party +performed the action, where another party can obtain, invoke, or +emulate the attributed capability. Where one party creates or hosts +another and can reach that other's signing or authenticating +capability, an action attributed to the hosted party may have been +performed by the host. Where a record reaches the relying party +through intermediaries, attribution established at one step of that +path does not carry to the next without that step's own basis. A +transport can establish which component delivered a record. A source +that the deliverer names inside the record is the deliverer's +assertion, unless the record carries its own verifiable binding to +that source. + A receipt, record, or registration is not external execution or +effect. Registration establishes that a statement entered a log or +service under that service's policy. Matching records held by +different parties establish that their contents agree +(correspondence), not that the parties agree. Correspondence does not +establish which event preceded which (precedence), and it does not +establish occurrence. + Presence of records is not completeness of coverage. A set of +records, each individually authentic, does not establish that the set +is all the records there are. Detecting omission requires more than +the authenticity of each record: an independently grounded +expectation of the complete population, which the set itself may +carry, or a recording boundary that cannot be bypassed. + Absence of a record is not non-occurrence, unless the observation +regime supports that inference. The inference from "no record" to "no +event" is valid only where a declared, enforced recording boundary +meets three conditions. It covers the event class. It cannot be +bypassed by the parties in question. And gaps in the record stream +are themselves detectable, for example against a pre-declared cadence +or sequence carried in the records and watched by a party outside the +producer. Otherwise absence is only absence. +Such an inference also requires an identified interval, evidence that +the required recording and delivery coverage held for that interval, +and resolution of relevant delays and gaps. Detectability of a gap +does not license a non-occurrence claim while the gap remains +unresolved. The conclusion is limited to the specified event class, +population, and interval under the stated assumptions. +Bypass of the recording boundary is not the only way a record can +fail to appear. A record may have been made and then withheld, +whether by a retention policy that removed it or by a disclosure +decision that did not produce it . Where +either is possible, the result is a statement about the evidence set +examined and not about the recording boundary, and the conditions +above are not met by the boundary alone. + Authority granted is not action performed. Authorization evidence, +however exact, single-use, and attenuated, bounds what a grant +permits at the point where it is enforced. It does not establish that +the authorized action occurred. What is missing is evidence on the +action's own basis: an observation of invocation or of execution, at +a boundary in a position to make it, or a record that constitutes the +action rather than describing it ( and ). + Internal observation is not independent observation of an external +effect. An observation made inside the acting party's boundary can +establish, at most, what that boundary observed, and a record's +statements about effects at other systems are assertions. In +particular, a record minted by the deciding or authorizing side +cannot by itself establish the order of its own decision against an +effect that side does not observe. Other evidence carried in the same +record is appraised under the routes and premises of +, regardless of its source. + Time and sequence evidence is bounded by the observation and control +properties of its source, like any other evidence. A timestamp or +sequence number is only as strong as the party and mechanism that +produced it: one minted by the interested party over its own record +orders that record, not the world. This is not a claim that time +evidence is worthless. Trusted time-stamping has a distinct and +stronger evidentiary role: a time-stamp token from an appropriately +trusted authority is evidence that a datum existed before a +particular time . And a sequencing mechanism whose +observational domain covers both of two events can order them. The +rule is that the strength of the time or sequence claim follows the +source, and must not be read past what that source observed and +controlled. + A missing or unverifiable load-bearing premise cannot be silently +promoted. Where support for a claim depends on a premise that was not +evaluated, or that only the interested party can vouch for, the claim +inherits that limitation. The report names the claims that are +supported, and keeps the status of each premise that was not +evaluated. A conditional claim states the premise it depends on +(). + Current authentication, when its verified scope is limited to a + present binding, does not by itself establish identity continuity or + succession relative to an earlier subject. Identity continuity, + succession, and the present applicability of prior authorization, + standing, or reputation are distinct claims. Each requires grounds + covering the specific relation or applicability asserted under the + relevant identity and authorization rules. A record's evidentiary + force depends on those rules and its verified properties, not merely + on its statement of the claim. DID Core states the corresponding + limit for persistent identifiers: absent published operational + policies, requesting parties are not expected to assume that an + identifier is persistent for the same subject . + Behavior observed under one set of conditions does not establish the + same behavior under other conditions without grounds for carrying the + conclusion across. A test, an audit, or a monitored run observes a + system under the conditions it applies. The result describes those + conditions. Carrying it to other conditions needs grounds that the + two do not differ in anything the behavior depends on. Where the + system can detect that it is being tested or observed, results + obtained under those conditions do not by themselves supply such + grounds, since the system can make its behavior depend on them. + reads the emissions case this way. + Multiplicity is not independence. A number of records, keys, + services, or organizational names does not by itself establish + independent support. Where one party has a capability that matters to + the claim over several of them, their number adds nothing against + that party (). Independence is judged claim by claim, + for the components on whose correctness the support for that claim + relies. + Coherence is not corroboration. The detail, internal consistency, + plausibility, or fluency of an account produced by the interested + party does not by itself support the claim that what it describes + occurred. A fabricated account can have all of these properties, so + they do not distinguish a true claim from a false one (the test of + ). This holds with particular force for accounts + generated by software, including language models, whose output can be + fluent whether or not it matches the events it describes. Support + needs grounds beyond these qualities, and evidence carried with the + account can provide them by one of the routes of . + + +Every rule here is stated against premises. The premises a conclusion +rests on, their grounds, and their status should be available directly +or by unambiguous reference. A premise accepted as a matter of policy is +not thereby independently established. Where the premises change, +whether the conclusion remains warranted has to be checked rather than +assumed. + +Aggregation, transformation, summarization, and re-signing remove none +of these limitations. A pipeline that normalizes, merges, or re-encodes +evidence inherits each relevant limitation of its inputs unless a +specific limitation is specifically resolved by additional evidence. An +unsupported widening of a claim at the output of such a pipeline is a +defect to locate, not a result to report. + +
+
A claim-boundary review lens + +The rules above can be applied as a short checklist when reviewing a +specification, a deployment, or an evidence design. For a given claim, +ask: + + + Exact claim. What exact claim, about what exact action, is being +made? + Producing boundary. Which boundary produced the supporting evidence, +and what could that boundary observe? + Control. Who controls that boundary? Can the interested party or +coalition forge its output, conceal it, or circumvent it +()? Which of these capabilities matter to the claim +being made? Did the limits on them hold for the period the claim +depends on? What grounds those limits? + Ceiling. For the kind of claim at issue, what claim or claims can +that boundary warrant? Does the asserted claim exceed them? + Positive evidence. Is there positive evidence at the claim's own +base? A ceiling supplies no evidence, and a signature or a +registration supports only the predicate that its verification +establishes. + Prevention, detection coverage, or a particular finding. If the claim +is that misbehavior is prevented, which independently controlled +enforcement point does it rest on ()? If the claim is +that misbehavior of a specified class cannot be concealed, which +independently controlled observation and delivery dependencies does +that coverage rest on? For a claim that a particular event was +detected, which evaluation act (evaluator, predicate, evidence basis, +window or context) is identified? + Basis for a claimed effect. Which route of supports +the claim? The routes described there include observation at a +boundary outside the interested party's control, a record that +constitutes the action, and evidence whose verification establishes a +predicate. Where the support rests on another basis, is that basis +stated? What limits its scope? + Completeness and absence. Does the claim depend on the record set +being complete, or on an absence meaning non-occurrence? Is that +supported (rules 4 and 5)? What interval and delivery horizon were +evaluated, and were relevant gaps resolved? + Pipeline widening. Does any step between production and reliance +widen the claim beyond what the producing boundary supported? + Reporting. Does the report separate whether each evaluation was made + from what it found ()? Does it name the supported + claims, and the reason for any evaluation that was not made? Is + anything silently rounded up? + + +The considerations sections of (security) and +(privacy) are the models for this genre: a document states, in its own +terms, what its mechanisms do and do not establish, and what residual +exposure remains. This lens applies the same documentation discipline to +the semantic strength of execution-related claims. It is a review aid, +not a conformance procedure. + +
+
The control-topology test + +Claims that an architecture prevents or detects misbehavior are +execution-related claims about the architecture itself, and they are +bounded the same way. Farrell's (a,b,c) scenario, described in , +motivates the control-topology test used here. Stated +mechanism-neutrally: + +
+
Prevention:
+
+ A claim that party B is prevented from performing or forging an action +requires an enforcement point that B does not control and cannot +bypass, positioned so that the action cannot complete without it. A +component outside B's control that is not actually required for the +action prevents nothing. +
+
Detection coverage:
+
+ A claim that misbehavior in a specified class cannot be concealed by B +requires the following. + + +
+
Evidence:
+
+ adequate to distinguish that misbehavior under the stated +assumptions. +
+
Controls:
+
+ delivery or omission controls that prevent B from hiding it +without an observable indication. +
+
+ + The claim should state its coverage, timing, and failure limits. These +coverage conditions are distinct from establishing that a particular +event was detected from evidence already obtained. +
+
Independence:
+
+ The prevention and coverage properties above depend on independence in +the sense of . The components concerned are the +enforcement point, the observation point, and the delivery path. The +party concerned is the stated party or coalition. +
+
+ +An architecture claiming prevention or adversary-resistant detection +coverage should state: + + + which independently controlled enforcement or observation dependencies +the guarantee rests on; + what the relevant limits on forgery, concealment, and circumvention +are (); + what happens when a dependency is unavailable or cannot be validated. + + +Without those dependencies, that guarantee is not established against +adversarial B, whatever its message formats carry. This does not +invalidate a narrower finding supported by evidence that has actually +been received and evaluated. + +A protected observation path is not, by itself, sufficient for +detection. The evidence must support a check that distinguishes the +specified misconduct under the stated assumptions. An observable gap can +establish a loss of coverage without establishing which underlying event +occurred. + +A claim that a particular event was detected requires an identifiable +evaluation act. The record should name which evaluator evaluated, which +predicate was checked and with what result, and on what evidence basis. +Where a window or context applies, it should name that too. + +Such a finding does not, by itself, establish that all events of that +class were detectable or detected. A path that could have revealed an +event does not show that anyone looked. This document defines no format +for stating those items. + +Existing mechanisms slot into this test rather than exempting themselves +from it. Remote attestation contributes where all of the +following hold: + + + the Evidence covers the property at issue; + the adversarial party can neither forge nor substitute the Evidence or +the Attestation Result, nor control the Verifier, its Appraisal Policy +for Evidence, or the Endorsements and Reference Values it relies on; + the result is freshly and securely bound to the relevant actor and +action. + + +RFC 9334 permits its roles to be aggregated into one entity, so +independence from a given party is a property of the deployment, not of +the architecture. + +Threshold signing contributes a prevention dependency +exactly where the adversarial party or coalition cannot reach the +threshold without an independently controlled signer that checks the +exact operation and can withhold its share. These mechanisms contribute +only to the properties and dependencies actually established by their +deployment. + +OAuth sender-constraining mechanisms such as Demonstrating Proof of +Possession (DPoP) can limit the use of stolen tokens. They +do not by themselves prevent B from invoking a key through a signing +interface B controls. That holds whether the key was provisioned by +another party or stored as non-exportable (). + +An isolated execution environment, including a trusted execution +environment (TEE), can contribute an enforcement dependency where B +cannot modify or bypass the relevant checks. Claims about effects +outside that environment still require an appropriate evidence basis. + +The Workload Identity in a Multi System Environment (WIMSE) architecture + separates workload authentication from +authorization and permits different placements of policy enforcement. +The test therefore asks who controls the deployed enforcement point and +which operations it covers, rather than treating workload identity or +credential provisioning as evidence that the claimed operation occurred. + +The independently controlled point need not be cryptographic. A +preserving repository may be audited and certified against a published +standard , by a body the repository does not control and +which is itself accredited under a separate regime . That +contributes a detection dependency if the audit observes the practice at +issue and if any suppression of an adverse finding by the audited party +would become visible. + +That contribution is limited by the audit's scope, period, sampling, +access, and reporting arrangements. Certification alone does not +establish complete observation of all relevant conduct, nor the +visibility of every suppressed adverse finding. The recursion terminates +in an accreditation body that some party must be prepared to treat as +terminal. + +The test is indifferent to whether the point outside the party in +question is a key, a verifier, or an accreditation regime. It asks only +whether the deployment placed one there, and what that point actually +covers. + +
Independence and the claim at issue + +A statement of independence says which capabilities of the party matter +to the claim at issue. It says what grounds the limit on each of them. +This document does not say which grounds suffice to establish that such +a limit holds. + +The capabilities in question are these. + +
+
Forgery:
+
+ The party can make a relying party accept false evidence. One way is +to fabricate the evidence, substitute or replay it, or alter it +without detection. Another is to direct the component that produces +the evidence, so that its output is false. +
+
Concealment:
+
+ The party can act outside the recording boundary, so that the activity +is not recorded there. It can also suppress, withhold, or delay +evidence that exists. +
+
Circumvention:
+
+ The party can complete the action without the enforcement point, or +direct the decision of that point. +
+
+ +Where this document says "bypass", bypassing an enforcement point is +circumvention and bypassing a recording boundary is concealment. + +A claim needs limits only on the capabilities that matter to it. A +capability matters to a claim if the party could use it to leave the +relying party holding the same evidence while the claim is false. That +is the test of , applied to what the party can do. Take a +particular finding made from evidence already received. Forgery matters +to it, and so does the binding of the evidence to the exact action +(). A payment network's record of transfer T can support +that T occurred. This holds although the operator could have withheld +the record or made other transfers elsewhere. Concealment matters to +completeness and to detection coverage (rules 4 and 5). The same record +does not support that these are all of the operator's transfers. +Concealment can also matter to a particular finding, where omitted +evidence would change the finding. Circumvention matters to prevention. +The limits have to hold for the period the claim depends on. A present +assessment does not by itself establish that the limits held earlier. + +Independence does not make an observation relevant to the claim. An +observer outside the operator's control that saw a command sent has not +thereby seen it executed. A separate question remains: can the +observation distinguish a true claim from a false one ()? + +A dependency can enter where evidence is formed, where it is delivered, +and where it is evaluated. An independent evaluator can verify the +interested party's own account, but the account does not become an +independent observation. Control over delivery gives the capability to +conceal, and it can also permit substitution or replay, but it does not +give control over the source. An independent component does not make a +record presented as its output authentic: the operator can present a +forged confirmation from an independent payment network. The relying +party therefore checks origin, binding to the exact action, and any +required freshness separately (). + +Two sources that take a fact from the same origin both depend on that +origin for that fact. Two logs that each copy the operator's message are +not two observations of execution (rule 3). Where one party has the +relevant capability over several components, those components do not +count separately against that party. Three services that act, record, +and check, run by one operator who can change their code or their +records, divide the work but not the control. The useful question is +which error or fabrication the second source rules out. Independence +from one party does not establish independence from a coalition that +includes it. + +A statement of independence is itself a claim, with a producing boundary +and a ceiling. Its grounds can stop at a premise that a party accepts as +a matter of policy. A claim that relies on the statement then stays +conditional on that premise. The premise travels with that claim when it +is passed on (Sections and ). The audit +example in shows one such premise. +describes evidence whose source need not be independent. + +
+
+
When stronger claims become supportable + +The discipline does not only rule claims out. Stronger claims about a +particular effect become supportable when the effect is observed at a +boundary capable of observing it. That capability is judged under the +stated threat and control model. The evidence of that observation must +also be protected against undetected fabrication or alteration by the +interested party. Coverage claims additionally depend on the observation +and delivery conditions described in . + +An external footprint is one important route to such observation. +Examples are movement on a payment rail, and resource or configuration +records in an external provider's control plane. In each, a system the +interested party does not control observed something at its own +boundary, and a relying party can check that system's records against +the claim. + +It is not the only route. The observing boundary may be any of several +things: + + + an external service, a counterparty, or a settlement system; + an external control plane; + the relying party's own observation boundary, where the relying party +itself observes the effect: a state change in a system it operates, or +a delivery it takes receipt of itself; + another point that is in a position to observe the relevant fact and +that the interested party does not control under the stated threat +model. + + +A distinct third party is not always necessary. The relying party's own +observation may provide the required evidence, subject to the same +claim-specific trust and deployment assumptions. + +A further route relies on a record constituting the precise action +claimed, rather than describing a separate action: + + + a signed order that is the order; + a recorded state transition on a ledger that is the transfer; + a recorded command whose issuance is itself the claimed action; + a write-ahead entry that defines the commit. + + +Such a record supports that precise claim, because issuing or accepting +it constitutes the action under the applicable rules. The evidence must +establish the conditions that give the record that constitutive effect, +including any applicable authority, acceptance, and commit or finality +conditions. A record on a branch that was never accepted does not +constitute the action merely by resembling one that would. + +What it supports is bounded by the action it constitutes and extends no +further. A ledger entry that is the transfer establishes the transfer, +not that goods moved. A signed order that is the order establishes the +order, not that it was carried out. Where a record describes an action +it does not constitute, this route does not apply. + +Another route relies on evidence whose verification itself establishes a +predicate. Examples are a proof of computation, a proof of possession, +and a response to a fresh challenge. The source of such evidence does +not need to be independent of the interested party. Successful +verification establishes the proved predicate, under the premises of the +verification. Those premises include the soundness of the proof system, +the integrity of the verifier, and that the statement verified is the +one the claim names. Where soundness bounds the probability of a false +acceptance rather than excluding it, treating it as exact is an +idealization, and a report that relies on it should say so. A claim that +does not follow from that predicate needs its own evidentiary grounds +and the bindings it requires. For a proof of computation, such claims +can concern whether the committed inputs match the facts they stand for. +They can concern who performed the computation, when a policy was +applied, or whether an external effect followed. Signature verification +is the familiar case: the proved predicate is that the bytes were signed +under the key, and rule 1 applies to anything beyond it. + +The qualifications below travel with these routes: + + + The observing boundary supports claims at its own observation boundary +and no further. A payment network's record establishes what the +network observed about a transfer at its boundary, not that a business +obligation was satisfied. A relying party's own observation +establishes what the relying party observed at its boundary, and no +more. + The observation, whether an external footprint or the relying party's +own, must be bound to the exact action claimed. A matching amount, +timestamp, or counterparty is correlation, and correlation supports +weaker claims than a validated binding. + The protection afforded by the observing boundary is itself a +threat-model statement. For a particular finding, the relevant +protection is against the operator of the acting system fabricating or +undetectably altering the evidence for the claimed observation. +Against the operator of the observing boundary itself, the route gives +no additional support. Where the relying party observes at its own +boundary, the claim rests on the relying party's own observation, +which is independent of the interested party but not of the relying +party. + An effect is observed at a time. The observation does not, by itself, +establish that the effect persisted or is final. A transfer can be +reversed, a write can be rolled back, and a ledger branch can be +abandoned. A claim of a durable or final effect needs evidence of the +conditions that make it so. The rules of the system where the effect +occurs set those conditions. That evidence needs one of the routes of +this section. + Ordering claims, such as that the decision preceded the effect, +require an ordering relation whose observational domain includes both +terms. That means one boundary that observed both, or records from the +two boundaries that can be securely related and ordered. Matching +records alone establish neither the order of the records nor the order +of the events. + The capability to conceal does not, by itself, invalidate evidence +that has been received (). Subject to the +qualifications above, the received evidence may support a particular +finding within its observational and temporal scope. A finding that +depends on the completeness of a specified evidence set, or on absence +as evidence of non-occurrence, requires the corresponding coverage and +gap-resolution basis (rules 4 and 5). + + +
+
Worked example: a payment + +Consider an agent that reports having paid a supplier. Three evidence +artifacts and a report combining them are on the table. The point of the +example is that they support different claims, and that a report must +keep separate what each boundary observed from what it merely asserts. + + + A self-produced execution record. The operator's own service emits a +signed record: "paid supplier S, amount X, at time T". Observed at +that boundary: that the operator's service produced and signed this +statement. Asserted, not observed there: that the payment reached S. +What it supports on its own: that the operator stated a payment; not +that the payment occurred (rules 1, 3, 7). +This example assumes that the record contains only the operator's own +statement. If it carries independently verifiable evidence from +another source, that evidence is appraised at its own producing +boundary. The party assembling the container does not determine every +item's origin. + A transparency registration. The signed record is registered with a +transparency service, which returns a receipt carrying an inclusion +proof. Observed: that this statement was registered under the +service's policy. Any claim about registration time depends on the +time evidence provided and its verified scope. What it does not +establish: the truth of the statement or the occurrence of the +payment (rule 3). Registration raises auditability, not the claim +ceiling. + External payment-network evidence. A record from the payment network +-- a settlement entry or network-issued confirmation -- that the +network observed a transfer matching the action. Observed at a +boundary outside the operator's control: that the network saw a +transfer with these attributes. This is the footprint of +, and it must be bound to the exact action: a bare +amount-and-time match is only correlation. Its strength holds against +the operator, not against the payment network's own operator. + A composite report. A report that draws on all three should read, in +substance, as three statements. The operator asserts a payment (1). +The assertion is registered and independently checkable as an +assertion (2). And where (3) is present and bound to the exact +action, a system outside the operator observed a matching transfer at +its boundary. That last supports a payment-reached-the-network claim, +to the extent the binding holds and that evidence is protected +against fabrication or undetected alteration by the operator. With +only artifacts (1) and (2), the supportable claim is that the +operator stated and registered a payment, not that a payment +occurred. + + +A report over these artifacts could read as follows. Evaluator V checked +the origin of each artifact and the binding of the network record to the +payment. V accepts one named premise: the network's record is reliable +for the event it reports. Assume that the record reports that a transfer +was seen, and says nothing about finality. V did not assess whether the +set covers all of the operator's payments. + + + A statement of the payment was signed under the operator's key. +Evaluated. Supported: the signature verifies. + The statement was registered. Evaluated. Supported: the receipt +verifies, within its scope. + The network observed a transfer bound to this payment. Evaluated. +Supported: origin and binding were checked, under the named premise. + The payment to S is final. Evaluated. Unsupported by this set: the +evidence evaluated does not establish the conditions for finality +(). + These are all of the operator's payments in the period. Not evaluated: +completeness was not assessed (rule 4). + + +Suppose instead that only the amount and the time match, and the binding +is not established. The third entry is then unsupported for this +payment. That the network saw some transfer remains supported. + +The example makes no universal assertion about what any particular +service observes. What a given payment service, transparency service, or +agent runtime actually observed is a fact about that deployment, to be +stated from its evidence, not assumed from its role. + +
+
Reporting what the evidence supports + +Where evidence does not support the claim asserted over it, the useful +output is not a bare failure. For each claim, a report says whether the +evaluation was made and, if it was, what it found. These are separate +questions. An outcome-binding profile drew a related line earlier: its +indeterminate state, used when required evidence is missing, +unauthenticated, unpinned, or not exactly bound, is not a comparison +outcome . + +Whether the evaluation was made: + +
+
Evaluated:
+
+ The relevant assessment ran over identified evidence, in an identified +appraisal context. +
+
Not evaluated:
+
+ The assessment did not run, the identified evidence could not be +obtained, or the premise was outside the evaluation's scope. This +status supplies no finding for or against the claim. It does not mean +the claim is false, and it does not determine what the available +evidence would support if evaluated. Nor is it permission to discard +evidence that positively supports a claim at its own base. A claim +well supported at its own base stays supported, even while another +claim is not evaluated. It is also not a reason to repeat an action +whose outcome is unknown, since the first attempt may have completed. +That profile states the same limit for its indeterminate state +. + + +
+
Unverifiable:
+
+ A reason for "not evaluated" that belongs to the evaluator. The +statement is one that the evaluator in question cannot check from +the evidence and inputs available to it at the time of evaluation. +The standing example is a producer's description of its own +deployment, which an evaluator may be unable to check without +deployment access or other adequate evidence about that +deployment. The category is relative to an evaluator and to an +evidence or input set. Where they matter, it is relative to an +evaluation context or time as well. A statement can pass from +verifiable to unverifiable while the record itself is unchanged. +The evaluator that could check it may cease to exist, or lose its +access or the means to interpret what it holds. Such statements +can still be worth carrying. The report names the reason and the +premise that was not checked. Where a statement rests only on the +producer's account, the report says so. A reader can then see +which parts of a composite claim rest on trust. A report that +fixes the category without fixing the evaluator and the moment +says less than it appears to. +
+
+
+
+ +What the evaluation found: + +
+
Supported:
+
+ The evidence evaluated supports the claim as stated, under the stated +premises. +
+
Unsupported:
+
+ The assessment ran over the evidence evaluated, and that evidence +failed it. This is a finding about the evaluated evidence, relative to +the evidence set and the appraisal context in which it was evaluated. +It is not a property of the world, and a different evidence set may +support the claim. Where the assessment ran and the evidence evaluated +lacks what the claim needs, the claim was evaluated and the finding is +unsupported. +
+
Refuted:
+
+ The evidence supports the negation of the claim. Absence of a record +refutes a claim of occurrence only where rule 5 of +permits the inference from absence to non-occurrence. The report +should state that finding and its basis explicitly, rather than +treating it as mere absence of support. +
+
+ +One reporting practice applies to both questions: + +
+
Downgrade to the supportable claim:
+
+ Where the asserted claim is unsupported or not evaluated, report the +strongest claim of the kind at issue that the evidence does support, +or the supported claims where there is no unique strongest one, +alongside the asserted claim, with its status and any finding. A claim +supported at another base is a separate finding, not a downgrade; +support at one base is not inferred from support at another +(). "Invocation: supported. Execution: unsupported by the +evidence evaluated" is actionable; "invalid" is not. +
+
+ +Collapsing "not evaluated" into "unsupported", or either into "refuted", +destroys information a relying party needs: "we checked and it failed" +and "we could not check" call for different decisions. These terms are +not a result-code set. One report can say that a claim was not evaluated +because a premise is unverifiable, and also identify a weaker claim that +is supported. + +A support assessment over the available evidence can complete while a +required premise is not evaluated. The report identifies these +assessments separately. + +Each of these terms is relative to the evidence actually evaluated, and +a report is more useful when it says what that evidence was. The +evaluated set may itself be incomplete or selected. Every record in it +can verify while records that would have changed the outcome were never +delivered: rule 4 of , met again at the reporting layer. + +A verdict applies to the evidence basis it names, and a verdict that +names no basis invites exactly the widening this document is about. + +Appraisal results travel. One evaluator's result may be consumed by a +later composite report: that a claim was not evaluated, for instance. +The later relying party then needs to distinguish an attributable +appraisal from an unattributed conclusion. + +Propagated or aggregated appraisal results should therefore retain +enough provenance to identify: + + + who or what appraised; + the evidence or input basis, or a stable reference to it; + the predicate, profile, or evaluation context under which the result +was reached, including the boundary at which the appraisal was made. + + +Without that, "not evaluated" degrades across aggregation into +somebody's unattributed conclusion. That is the aggregation limit of + arriving at the reporting layer. Where evaluated +evidence or received appraisals support incompatible findings, the +report identifies the conflict and any premise used to resolve it. + +This is a consideration for reporting designs. It is not a record format +and not a general retention requirement. The provenance of an appraisal +identifies who is reported to have appraised what, under which context. +By itself it establishes neither that the appraisal ran as reported nor +that the underlying event occurred. + +A reporting design that preserves these distinctions makes inflation +visible: every summary that would erase one of them is a place where a +stronger claim would otherwise silently replace a weaker one. + +
+
Applicability beyond AI agents + +Nothing in this discipline is stated in terms specific to AI agents. The +same bounding questions apply to: + + + audit logging and monitoring pipelines, where the questions are what +the log source observed and who can write to it; + evidence collection and archiving practice ; + signed system logs ; + transparency systems (, ); + long-term evidence records ; + compliance reporting and incident forensics; + operational telemetry, which is self-reported by instrumented code and +designed for diagnosis rather than adjudication. + + +Agent systems sharpened the problem. Actions are initiated by software +whose records are produced mostly at the acting side, and delegation +chains multiply the boundaries across which claims travel and inflate. +But the rules in are stated as properties of evidence +rather than of agents. + +One domain is worked here: the long-term preservation of records, where +no agent acts and no payment is made. A preserving repository holds a +record deposited by its creator. Fixity evidence can support a claim +that deposited bytes have not changed relative to an accepted baseline. +Identity and provenance evidence may support an authenticity assessment +under stated assumptions. Archival diplomatics drew this distinction +earlier and for a different substrate. It separates a record's +reliability at the point of creation, the accuracy of its content, and +its authenticity . Neither finding, by +itself, establishes that the record was reliable when created or that +its content was accurate. Preservation does not convert custody +integrity into truth of the original content. That is an instance of the +claim ceiling of . + +A gap in a deposited series supports no conclusion about what was never +deposited, unless the deposit regime was declared, enforced, and +observable to a party outside the depositor (rule 5). Whether a +preserved record can still be evaluated depends on the record, the +available representation and provenance information, and the evaluator's +knowledge and access. This illustrates the evaluator- and time-relative +unverifiability of . The Open Archival Information System +(OAIS) reference model addresses continued understandability for an +identified Designated Community . + + gives three public findings that state the same bounds +outside agent systems. Applicability to the other domains listed above +is asserted on the same grounds and is not worked case by case here. + +
+
Related work + +The following work provides existing mechanisms and domain-specific +treatments relevant to these limits. This document collects selected +implications for the appraisal of execution-related claims. + +
+
Non-bypassable mediation and tamper-evident logging:
+
+ Two older lineages give this discipline its positive content. In the +reference-monitor lineage, a security-relevant decision is enforced +only where every access is mediated by a mechanism the controlled +party cannot bypass and cannot tamper with -- the +prevention half of . In the tamper-evident and +transparency-logging lineage, alteration or equivocation in a record +set can be made externally detectable +-- the detection half. This document restates the boundary conditions +those lineages already identified. It adds no mechanism, and claims +none of them. +
+
Attestation:
+
+ RFC 9334 defines remote-attestation roles, appraisal +flows, and trust assumptions, and the Entity Attestation Token (EAT) + provides an attested claims set. This document draws on +those concerns to organize a review discipline for execution-related +claims across artifact classes. It defines no remote-attestation +machinery. +
+
Transparency and receipts:
+
+ CBOR Object Signing and Encryption (COSE) Receipts prove +properties of a verifiable data structure, such as inclusion and +consistency. Successful verification supports the specified +data-structure predicate under the applicable cryptographic and trust +assumptions. It does not, by itself, establish that an event described +in a registered statement occurred. Supply Chain Integrity, +Transparency, and Trust (SCITT) applies transparency +mechanisms to supply-chain statements and explicitly addresses the +limits posed by dishonest issuers. Certificate transparency provides +inclusion and consistency checks over log views . A +misbehaving log can nevertheless present inconsistent views to +different clients. Detecting that behavior depends on comparing +relevant observations, or on other mechanisms that address such split +views. These are existing examples of bounded evidence claims. +
+
Supply-chain step attribution:
+
+ in-toto binds the artifacts flowing between the steps of a +software supply chain, the order of the steps, and the identity of the +party that signed for each, against a layout declared in advance by +the project owner. Its analysis states the assumptions under which +that binding holds, and how the guarantees degrade under key +compromise. Both are boundary statements of the kind this document +asks producers to make explicit. +
+
Provenance:
+
+ PROV models provenance as asserted descriptions that feed +trust assessment, not as verdicts. +
+
Prior formulations by the author:
+
+ The four bases of and the ceiling of restate, in +generic terms and without the level scale used there, content levels +and the boundary axiom (Axiom BC) of earlier joint work with Vladimir +Ikher . The Witnessability Conceptual Core states the +generalization of that axiom as a derived rule . The +appraisal core of the Witnessed Execution Protocol (WEXP) + gives an exclusion-only operational +realization that binds exact predicates to the four bases. This +document preserves that exclusion-only role. It makes no claim of +independent discovery or priority, and its rules can be stated and +applied without either work. The author's interest in WEXP is +disclosed below. +
+
Agent-protocol evidence work:
+
+ Individual Internet-Drafts address per-claim verifier, binding, +freshness, and failure discipline +; enrollment and +key-binding assumptions ; evidence of +authorization decisions ; and +an architecture for auditing agents' interactions and delegation +. Work on agent control delivery +and outcome reconciliation + distinguishes issuer-side +emission, required-target resolution, receiver-side observation, +enforcement outcome, and observation of the resulting control effect. + + + An outcome-binding profile +separates the authorization of an action from its observed effect. It +binds signed observations from executors, systems of record, and +independent observers to the same authorization, action digest, and +operation, with exact-equality checks on the action and source +bindings, plus relying-party-defined observation-window requirements. +It treats a declared control domain as relying-party policy input +rather than proof of independence. And it returns an indeterminate +state when required evidence is missing or unauthenticated. + + A further draft +states mechanism-independent requirements for making a claimed agent +transition independently determinable after the original interaction +has ended. It addresses the binding of the material action and its +governing conditions, a verification procedure that establishes that +those conditions actually governed the transition when it occurred, +determination without requiring cooperation from an original +participant whose conduct or assertion is material to the facts +determined, and negative, transferred, or incomplete transitions. + + These works address related questions at specific boundaries. The +discipline here can be applied to the claims made over their evidence. +
+
Non-inference rules stated for a record format:
+
+ In the agent2agent discussion of a dimensional model for +agent-protocol proposals, Blake Morrison set out rules for records +carried under different extensions of one format +. They are related limits on inference across +records and extensions. They are proposals made on a mailing list, and +they are cited as independent work, not as support for this document. +
+
Authentication and admissibility in evidence law:
+
+ The separation of what an artifact is from what its content +establishes is normative, not only analytic. Under the United States +Federal Rules of Evidence, a certified record generated by an +electronic process, and a certified copy authenticated by digest +comparison, are self-authenticating. The advisory committee states +limits on that . Such a certification establishes +authenticity only. Authenticating a machine output establishes that +the output came from that system, rather than that the information it +carries is reliable. The burdens, admissibility rules, and remedies of +evidence law remain outside this document's scope. +
+
Assurance cases:
+
+ The claims-argument-evidence tradition provides structured +argumentation over evidence. ISO/IEC/IEEE 15026-2 specifies +requirements for assurance-case structure terminology , +and the Goal Structuring Notation community standard provides a +notation for such arguments . The presence of an assurance case +or a graphical representation does not, by itself, establish that a +particular evidential inference is justified. +
+
+ +
+
Security considerations + +This document specifies no new protocol mechanisms. Its subject is the +prevention of a class of security failures that occur at the semantic +layer: relying parties accepting claims stronger than the evidence +supports. + +Cautions about the discipline itself, including its misuse: + + + The discipline does not make a dishonest or compromised evidence +source honest. It bounds what a relying party should infer. It does +not improve the evidence. + The discipline does not make an evaluator correct either. Every +finding is conditional on the correctness of the evaluator and of the +tools and inputs it relies on. That condition is a premise of every +report, whether or not the report states it. + "Not evaluated" is not a license to discard evidence. A report that +one claim was not evaluated, or is unsupported, is not a basis for +setting aside evidence that positively supports another claim at its +own base. The correct output is that supported claim, reported as such +(). + Deliberately unobservable topology is a limitation to report, not an +exoneration. An interested party may arrange that its enforcement or +observation points cannot be checked by anyone else. The report then +says which evaluation failed or could not be made (). +Unobservability does not support the corresponding prevention or +detection-coverage guarantee, and it is not evidence of good behavior. +This does not extend to every case-level finding that received +evidence may support. + Conformance vocabulary is itself inflatable. "Consistent with the +claim-boundary discipline" is not a property a document or product can +certify by assertion. The test is whether specific claims are bounded +by specific producing boundaries, checked claim by claim. + Detection mechanisms can leak information. Making refusals, gaps, or +suppression observable to an external party discloses timing and +frequency information to that party. Deployments should weigh the +observability required by against what the observation +channel itself reveals; RFC 6973 gives the model for +stating that residual exposure. + + +
+
IANA considerations + +This document has no IANA actions. + +
+ + + + + + + + + + + + + + Secure Audit Logs to Support Computer Forensics + + + + + + + + + +ACM Transactions on Information and System Security, Vol. 2, No. 2, pp. 159-176 + + + Notice of Violation + + United States Environmental Protection Agency + + + +letter to Volkswagen AG, Audi AG, and Volkswagen Group of America, Inc. + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Computer Security Technology Planning Study + + + + + +ESD-TR-73-51, Vol. II, HQ Electronic Systems Division (AFSC) + + + + + Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) + + + + + + + This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] + + + + + + + + + Guidelines for Evidence Collection and Archiving + + + + + A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. + + + + + + + + + + Guidelines for Writing RFC Text on Security Considerations + + + + + All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. + + + + + + + + + + Evidence Record Syntax (ERS) + + + + + + In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK] + + + + + + + + + Signed Syslog Messages + + + + + + This document describes a mechanism to add origin authentication, message integrity, replay resistance, message sequencing, and detection of missing messages to the transmitted syslog messages. This specification is intended to be used in conjunction with the work defined in RFC 5424, "The Syslog Protocol". [STANDARDS-TRACK] + + + + + + + + + DomainKeys Identified Mail (DKIM) Signatures + + + + + + DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. + This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] + + + + + + + + + + Privacy Considerations for Internet Protocols + + + + + + + + + + This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. + + + + + + + + + Certificate Transparency Version 2.0 + + + + + + This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. + This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. + Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. + + + + + + + + + Remote ATtestation procedureS (RATS) Architecture + + + + + + + + In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. + + + + + + + + + OAuth 2.0 Demonstrating Proof of Possession (DPoP) + + + + + + + + + This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. + + + + + + + + + The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures + + + + + + + This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime-order groups and hash functions. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. + + + + + + + + + The Entity Attestation Token (EAT) + + + + + + + An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. + An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. + + + + + + + + + CBOR Object Signing and Encryption (COSE) Receipts + + + + + + + CBOR Object Signing and Encryption (COSE) Receipts prove properties of a Verifiable Data Structure (VDS) to a verifier. VDSs and associated Proof Types enable security properties, such as minimal disclosure, transparency, and non-equivocation. Transparency helps maintain trust over time and has been applied to certificates, end-to-end encrypted messaging systems, and supply chain security. This specification enables concise transparency-oriented systems by building on Concise Binary Object Representation (CBOR) and COSE. The extensibility of the approach is demonstrated by providing CBOR encodings for Merkle inclusion and consistency proofs. + + + + + + + + + An Architecture for Trustworthy and Transparent Digital Supply Chains + + + + + + + + Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. + + + + + + + + + + The Witnessed Execution Protocol (WEXP): Core Specification + + + + + + + + + + + + + Security Principal and Verifier Binding for Agent Communication Protocols + + + + + + + + + + An Architecture for Auditing Agent Delegation and Interactions + + + + + + + + + + + + + Signed Decision Records for Agent Authorization: Disclosures, Entry Emission, and Ordering Evidence + + + + + + + + + + Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence + + + + + + + + + + Outcome Binding for Authorized Actions and Independently Observed Effects + + + + + + + + + + Workload Identity in a Multi System Environment (WIMSE) Architecture + + + + + + + + + + + + + + + + Independent Determinability of Agent Actions + + Strakewright + + + + + + + + Evidence Requirements for Agent Control Delivery and Outcome Reconciliation + + + + + + + + + + Dealing with LLMs in IETF Discussions + + + + + + + + + + + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Re: DRAFT minutes from the AGENTPROTO BoF + + + + + +message to the agentproto@ietf.org mailing list + + + Verifiable Credentials Data Model v2.0 + + World Wide Web Consortium + + + +W3C Recommendation, Section 1.1 + + + Decentralized Identifiers (DIDs) v1.0 + + World Wide Web Consortium + + + +W3C Recommendation, Sections 9.2 and 9.11 + + + Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates + + + + + +message to the agent2agent mailing list + + + Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates + + + + + +message to the agent2agent mailing list + + + Re: draft-bu-agentproto-security-principal-binding-06 published: focused review request + + + + + +message to the agent2agent mailing list + + + Toward a Witnessability Model for AI and Software Execution Systems: A Boundary-Based Framework for Classifying Execution Evidence + + + + + + + + +Version 1.1, bridge revision; also at DOI 10.2139/ssrn.6994720 + + + Witnessability Conceptual Core 1.0 + + + + + + + + + + Hamilton & Ors v Post Office Ltd + + Court of Appeal (Criminal Division), England and Wales + + + +[2021] EWCA Crim 577, paragraphs 136-137 + + + Grenfell Tower Inquiry: Phase 2 Report, Volume 1 + + Grenfell Tower Inquiry + + + +HC 19-I, Part 1, Chapter 2, paragraphs 2.122-2.123 + + + Learn About Volkswagen Violations + + United States Environmental Protection Agency + + + +agency overview of the Clean Air Act violations, including the Notice of Violation of 18 September 2015 + + + in-toto: Providing farm-to-table guarantees for bits and bytes + + + + + + + + + + + + + + + + + +28th USENIX Security Symposium + + + PROV-DM: The PROV Data Model, W3C Recommendation + + World Wide Web Consortium + + + + + + + Diplomatics: New Uses for an Old Science + + + + + +Scarecrow Press + + + The Long-term Preservation of Authentic Electronic Records: Findings of the InterPARES Project + + + + + + + + + Space Data System Practices -- Reference model for an open archival information system (OAIS) + + International Organization for Standardization + + + + +also issued as CCSDS 650.0-M-3, December 2024 + + + Space data and information transfer systems -- Audit and certification of trustworthy digital repositories + + International Organization for Standardization + + + + + + + + Requirements for Bodies Providing Audit and Certification of Candidate Trustworthy Digital Repositories + + Consultative Committee for Space Data Systems + + + + + + + + Systems and software engineering -- Systems and software assurance -- Part 2: Assurance case + + ISO/IEC/IEEE + + + + + + + + Goal Structuring Notation Community Standard, Version 3 + + SCSC Assurance Case Working Group + + + + + + + + Federal Rules of Evidence, Rule 902(13) and Rule 902(14), with Advisory Committee Notes + + United States + + + + + + + + + + + + +
The (a,b,c) scenario worked through + +In the agentproto mailing-list discussion of July 2026, in the thread on +the draft minutes of the AGENTPROTO BoF, Stephen Farrell posed a gating +scenario . In his words: + +
  • + If (a,b,c) is a comms path between agents (perhaps within a tree) and +if 'c' is actually a newly created entity, but one that needs access +to a long-term secret credential accessible at 'a' (e.g. pwd or SSH +private key) and where that credential must not be exposed to 'b' nor +easily abused - then how's that going to work? +
+ +He emphasized that "the scenario I posited is one where 'b' creates 'c' +and so is in a fine place to cheat" . + +The list discussion produced concrete mitigations, collected in a reply +by Shawn Sammartano , who credited most of them to +existing mechanisms: + + + exact, single-use, attenuated permission slips bound to request bytes; + hardware-protected keys, and threshold signing; + short-lived credentials, and forward-moving counters; + delegation budgets, and delays with cancellation windows; + approval separated from the creator. Sammartano also stated the hard +case plainly: "If b builds c, then b can read c's key, so b can be c. +No message format fixes that, mine included." + + +The author proposed an enforcement/observation framing in response to +that discussion . The control-topology test of + refines that framing by distinguishing adversary-resistant +detection coverage from a particular finding made from evidence already +obtained. Farrell posed the scenario. This document does not attribute +the generalized test to him. Applied to the scenario: + + + Exact, single-use, attenuated authority bounds what the grant +authorizes, where it is enforced. It does not establish that an action +attributed to c was not performed by b, where b created or hosts c and +can obtain or invoke c's signing capability (rules 2 and 6 of +). + A message format can carry the relevant control or evidence. It cannot +create the required independence (Sections and +). + A prevention claim at that boundary needs an enforcement point b does +not control and cannot circumvent. A claim that covered misbehavior +cannot be concealed needs evidence b cannot forge, on a path b cannot +silently prune (). Attestation and threshold signing +supply such points only in deployments that actually place them +outside b's control. + What is missing in the hard case is not another field. It is a point +outside b's control that either enforces or observes, and no message +format creates one. + + +This is narrower than solving credential custody. It makes the assurance +claim and its trust boundary reviewable before a mechanism is chosen, +which is what a chartering or design review needs. + +
+
Three public findings + +Three public findings state the same bounds outside agent systems, in +the words of the bodies that made them. + +In the English prosecutions arising from the Post Office Horizon +accounting system, the Court of Appeal found that the prosecutor +"treated what was no more than a shortfall shown by an unreliable +accounting system as an incontrovertible loss", and that defendants were +convicted "on the basis that the Horizon data must be correct, and cash +must therefore be missing, when in fact there could be no confidence as +to that foundation" . The load-bearing premise was the +reliability of that system. The court recorded that the prosecutor was +under a duty to investigate subpostmasters' claims that there were +problems with it, and it found "failures of investigation and +disclosure". On the reading taken here, that is the position rule 9 of + names. The claim rested on a premise the relying party +was required to test and did not adequately test. The judgment does not +address what a bounded report of the same evidence would have said, and +it is not cited for that part of the rule. + +In the inquiry into the Grenfell Tower fire, the panel examined the +performance criteria applied in large-scale fire tests of external wall +systems. Failure to meet those criteria would show a system unlikely to +comply with the applicable requirement. But "the converse was not +necessarily true": a system might meet the criteria and yet fail to +comply with that requirement . A bounded test result can +tell against a claim in one direction without establishing it in the +other. + +In the third case the test results were genuine outputs of a genuine +test. Vehicles were certified against emissions standards on the +strength of those results . Software detected the test +condition and enabled full emissions controls only then, so the vehicles +"meet emissions standards in the laboratory or testing station, but +during normal operation" emitted nitrogen oxides at levels up to forty +times the standard . The result established the behavior of +the vehicle under the conditions the test applied, which was all it had +ever observed. The certificate carried it to a claim about the vehicle +in use (rule 11 of ). + +These authorities reached findings within their own legal and regulatory +settings. The findings are their own, and their connection to the rules +stated here is this document's reading. + +
+
Changes from -00 + +This appendix is to be removed before publication as an RFC. + + + Independence is defined once, as limits on three capabilities of a +named party or coalition: forgery, concealment, and circumvention +(Sections and ). The earlier +definition treated them as one property. no longer repeats +the audit example, which stays in . + adds a note on the RATS terms. + says in which sense this document uses "support", adds a +practical test of it, and points to the routes of . +Its first bound and the abstract now name what evidence constitutes or +proves, not only what it observed. + no longer describes the bases as ordered. They are distinct +questions about one action. It now points to for +claims about an effect, and it separates the observation base from an +observation in the sense used elsewhere in the document. + speaks of kinds of claim rather than claim dimensions. + adds rules 11 to 13: behavior observed under +different conditions, multiplicity of sources, and the coherence of an +account produced by the interested party. Rules 1 to 10 keep their +numbers. Rule 2 adds attribution along a delivery path. Rule 3 no +longer reads matching records as agreement between the parties. Rule 4 +limits itself to the authenticity of individual records, and rule 7 to +the boundary's own observation. The last sentence of rule 9 now +follows the reporting terms of . The preamble is shorter. + revises four items: item 3 names the three capabilities, item +5 no longer says that a signature or registration supplies no +evidence, item 7 asks which route of , or which other +stated basis, supports a claimed effect, and item 10 follows +. + adds a route through evidence whose verification +establishes a predicate. It adds a qualification on the time and +finality of an observed effect, and it names as an idealization the +treatment of probabilistic soundness as exact. The closing advice on +deployment design is removed, because puts +evidence design out of scope. + ends with a sample report. + separates whether an evaluation was made from what it +found, and notes the related line drawn earlier in +. The status that -00 called "not +established" is now "not evaluated", because the rules use "establish" +for the relation between evidence and a claim. Downgrading is now a +reporting practice that applies to both questions, and a claim +supported at another base is a separate finding, not a downgrade. + Sections and are shorter. The three +public findings move to ; the Grenfell summary now follows +the inquiry's wording, and the emissions summary also cites the Notice +of Violation . The paragraph on archival preservation +moves from to . The discussion of Federal +Rule of Civil Procedure 37(e) and the separate paragraph on the +considerations-section genre are removed. still names that +genre. + corrects the paraphrase of requirement DET-3: -00 omitted +the qualifier that limits the cooperation clause to participants whose +conduct or assertion is material. The paraphrase now follows the +published wording of +. + now lists all five distinctions drawn in +; -00 omitted +required-target resolution. It also cites sources for the +reference-monitor and tamper-evident logging lineages +. + narrows its opening sentence, and adds that every finding +is conditional on the correctness of the evaluator. The item on +unobservable topology now refers to for the reporting +terms. + The abstract no longer names the source of the scenario. , +, and the Acknowledgments do. + + +
+
Acknowledgments + +The scenario of was posed by Stephen Farrell . +The mitigation list and the plain statement of the key-custody limit +were collected by Shawn Sammartano , who also confirmed +the enforcement/observation framing used here ; +Charles Eckel proposed that 'a' authorize 'c' to do something specific +on 'a's behalf, rather than expose a long-term credential . +Dapeng Liu proposed sender-constrained tokens (DPoP) so that 'b' could +not present a token bound to 'c's key ; +discusses what they do and do not prevent. Yuning Jiang raised the +continuity of an identity across restarts, instance changes, and key +rotation, which is how the question behind rule 10 of +entered this work . The distinction itself is +older and is drawn in . Vladimir Ikher is the author's +co-author on the earlier work from which the bases of + and the ceiling of are restated here. This +document also benefited from the broader agentproto and agent2agent +mailing-list discussions of 2026 on evidence, delegation, and audit. The +author thanks their participants without implying that any of them +endorses this document. + +Douglas Wadkins reviewed a pre-submission draft; the statement of scope +in , the additions to , and the +qualification in are responses to his comments. + +
+
Document development disclosure + +This document was drafted with substantial assistance from generative AI +tools, working from the author's prior publications, specifications, and +mailing-list correspondence, at the author's direction. It also +incorporates material arising from adversarial review conducted with +such tools: the wording of several rules, and the separation of +analytical justification from documented practical confirmation stated +in , were reached that way. In this version, the +treatment of independence (Sections , , +, and ), rules 12 and 13 of +, and the reporting terms of were revised +or added the same way. The author reviewed the resulting text and is +responsible for its content, citations, and attributions. The use of +large language models (LLMs) in IETF discussions is the subject of +, which explicitly excludes Internet-Draft and RFC +text from its scope. This disclosure is voluntary. + +The author also has an implementation interest in this area: the WEXP +appraisal layer is the author's own work. This +document is usable independently of it. No organizational independence +between the two works is claimed. + +
+ + + + + + + diff --git a/published/02/README.md b/published/02/README.md index 1e4e0ee..55712db 100644 --- a/published/02/README.md +++ b/published/02/README.md @@ -1,12 +1,29 @@ # Published CBEE -02 -These XML/TXT files preserve the posted revision without editing. -Verify locally with `sha256sum -c SHA256SUMS` from this directory. +[Datatracker](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) · [Official HTML](https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.html) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-02) · [All revisions](../README.md) -- https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.xml -- https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.txt -- https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/ +- IETF posting event: **2026-10-15T22:59:21Z** (UTC). +- Date inside the document: **15 October 2026**. +- Intended status: Informational; individual Internet-Draft. -Preparation and original archive verification were recorded on 15–16 October 2026. -Subsequent copies preserve those identities. The IETF archive remains authoritative; -a copy operation does not establish a fresh network verification or new publication. +Adds the Certificate Transparency example and distinguishes an authorization-status report from evidence that its result was available to or used by a decision-maker. Clarifies reference time and consultations without a current answer, plus references and acknowledgments. See the published Changes from -01 to -02 appendix. + +## Frozen files + +The XML and TXT were downloaded from the official IETF archive and checked +byte-for-byte on 18 October 2026. They are preserved without reformatting. +SHA256SUMS covers exactly those two files. + +| File | Bytes | SHA-256 | +| --- | ---: | --- | +| [draft-sergeev-claim-boundaries-02.xml](draft-sergeev-claim-boundaries-02.xml) | 137287 | d6d01ebc5d446991a2a4e65497171adaf4b37637d9bd36c5c017be6490b622b7 | +| [draft-sergeev-claim-boundaries-02.txt](draft-sergeev-claim-boundaries-02.txt) | 117649 | 67d93ac09bd572bb01b5e00c3101daa6ee3a2217f5e23d2bb02658d6a731ccc0 | + +Verify from this directory with: sha256sum -c SHA256SUMS. +The [machine-readable history](../revisions.json) records the official URLs, +posting events, and file identities for every revision. + +The GitHub release is a later mirror of this existing IETF publication. +Its tag identifies the public archive-import commit; it does not claim that +this Git repository existed on the IETF posting date. Use this directory or +the release assets for -02; the root XML is the current working source. diff --git a/published/README.md b/published/README.md new file mode 100644 index 0000000..620ca50 --- /dev/null +++ b/published/README.md @@ -0,0 +1,47 @@ +# Published CBEE revisions + +The IETF archive is authoritative. This directory preserves every posted +revision of draft-sergeev-claim-boundaries, including superseded editions. +The root XML is the current working source; these XML/TXT snapshots are frozen. + +| Revision | IETF posting event (UTC) | Document date | Downloads and checksums | +| --- | --- | --- | --- | +| [-02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) | 2026-10-15T22:59:21Z | 15 October 2026 | [Archive](02/) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-02) | +| [-01](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/01/) | 2026-09-23T04:00:40Z | 23 September 2026 | [Archive](01/) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-01) | +| [-00](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/00/) | 2026-09-16T23:37:06Z | 17 September 2026 | [Archive](00/) · [GitHub release](https://github.com/Witnessability/cbee-spec/releases/tag/draft-sergeev-claim-boundaries-00) | + +## Changes between revisions + +### -02 + +Adds the Certificate Transparency example and distinguishes an authorization-status report from evidence that its result was available to or used by a decision-maker. Clarifies reference time and consultations without a current answer, plus references and acknowledgments. See the published Changes from -01 to -02 appendix. + +### -01 + +Clarifies independence as limits on forgery, concealment, and circumvention; defines support and separates evidence bases; adds non-inference rules 11–13 and revises reporting distinctions. See the published Changes from -00 appendix. + +### -00 + +Initial individual Internet-Draft: the bounding principle, claim ceilings, non-inference rules, a control-topology test, and worked examples. + +## Provenance and verification + +Posting timestamps come from the [Datatracker revision events](https://datatracker.ietf.org/api/v1/doc/docevent/?doc__name=draft-sergeev-claim-boundaries&type=new_revision&limit=100&format=json). The -00 posting date in UTC is 16 September, while its document date is +17 September; these are different fields. GitHub release creation dates reflect +the later public archive import, not the original IETF posting dates. + +All six XML/TXT files were downloaded directly from https://www.ietf.org/archive/id/ +and their byte counts and SHA-256 hashes were checked on 18 October 2026. +See [revisions.json](revisions.json) and each revision’s SHA256SUMS. + +The command make check verifies the full revision inventory against pinned hashes. +The release workflow additionally compares the selected pair with the live +IETF archive and verifies the uploaded GitHub assets. It does not submit to IETF. + +Historical tags point to the public commit holding the frozen archive. The root +XML at that commit may belong to a later revision; the historical release assets +and published/NN/ directory identify the exact requested edition. + +Earlier private development history and correspondence are not imported. + +[Back to the project](../README.md) diff --git a/published/revisions.json b/published/revisions.json new file mode 100644 index 0000000..7508e5c --- /dev/null +++ b/published/revisions.json @@ -0,0 +1,71 @@ +{ + "document": "draft-sergeev-claim-boundaries", + "latest_published_revision": "02", + "authority": "IETF archive", + "history_source": "https://datatracker.ietf.org/api/v1/doc/docevent/?doc__name=draft-sergeev-claim-boundaries&type=new_revision&limit=100&format=json", + "revisions": [ + { + "revision": "00", + "ietf_posted_at": "2026-09-16T23:37:06Z", + "document_date": "17 September 2026", + "datatracker": "https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/00/", + "summary": "Initial individual Internet-Draft: the bounding principle, claim ceilings, non-inference rules, a control-topology test, and worked examples.", + "files": [ + { + "name": "draft-sergeev-claim-boundaries-00.xml", + "bytes": 151463, + "sha256": "640d2f2804cd2d7aeb495ed1294a03908906aa10b6e8bfd1d848b73e97ee5076", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-00.xml" + }, + { + "name": "draft-sergeev-claim-boundaries-00.txt", + "bytes": 97001, + "sha256": "6167510091e13a39e8f3116091f5207d69b0da6a7bd0b550e0372b68c8a88b59", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-00.txt" + } + ] + }, + { + "revision": "01", + "ietf_posted_at": "2026-09-23T04:00:40Z", + "document_date": "23 September 2026", + "datatracker": "https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/01/", + "summary": "Clarifies independence as limits on forgery, concealment, and circumvention; defines support and separates evidence bases; adds non-inference rules 11\u201313 and revises reporting distinctions. See the published Changes from -00 appendix.", + "files": [ + { + "name": "draft-sergeev-claim-boundaries-01.xml", + "bytes": 122449, + "sha256": "d59d0e4a85bff662a8f13c34cb1eb1297f2140a62a130ddd2fdedbbdcece0829", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-01.xml" + }, + { + "name": "draft-sergeev-claim-boundaries-01.txt", + "bytes": 111543, + "sha256": "0d90638366325bbacb368e9d1fd256f7a6117831ff31e10cb49d1b40e8446d35", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-01.txt" + } + ] + }, + { + "revision": "02", + "ietf_posted_at": "2026-10-15T22:59:21Z", + "document_date": "15 October 2026", + "datatracker": "https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/", + "summary": "Adds the Certificate Transparency example and distinguishes an authorization-status report from evidence that its result was available to or used by a decision-maker. Clarifies reference time and consultations without a current answer, plus references and acknowledgments. See the published Changes from -01 to -02 appendix.", + "files": [ + { + "name": "draft-sergeev-claim-boundaries-02.xml", + "bytes": 137287, + "sha256": "d6d01ebc5d446991a2a4e65497171adaf4b37637d9bd36c5c017be6490b622b7", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.xml" + }, + { + "name": "draft-sergeev-claim-boundaries-02.txt", + "bytes": 117649, + "sha256": "67d93ac09bd572bb01b5e00c3101daa6ee3a2217f5e23d2bb02658d6a731ccc0", + "url": "https://www.ietf.org/archive/id/draft-sergeev-claim-boundaries-02.txt" + } + ] + } + ] +} diff --git a/requirements.txt b/requirements.txt new file mode 100644 index 0000000..6d48ec8 --- /dev/null +++ b/requirements.txt @@ -0,0 +1,2 @@ +xml2rfc==3.34.1 + diff --git a/review/editor-copy.md b/review/editor-copy.md new file mode 100644 index 0000000..6e16947 --- /dev/null +++ b/review/editor-copy.md @@ -0,0 +1,835 @@ +# Claim Boundaries for Execution Evidence + +**Generated editor's reading copy, not a separate IETF publication.** + +Source SHA-256: `d6d01ebc5d446991a2a4e65497171adaf4b37637d9bd36c5c017be6490b622b7`. Edit the [RFCXML](../draft-sergeev-claim-boundaries.xml), not this file. + +[Published -02](https://datatracker.ietf.org/doc/draft-sergeev-claim-boundaries/02/) · [Publication history](../published/README.md) · [Contributing](../CONTRIBUTING.md) + +## Abstract + +Systems that act in the world produce logs, receipts, approvals, traces, attestations, provenance statements, and transparency records. These artifacts are routinely offered as evidence that an action was authorized, performed, or completed. This document states a discipline for bounding such claims: the strength of an execution-related claim is limited by what the available evidence actually observed, constitutes, or proves, and by the control and observation topology at the boundary that produced it. Message formats, signature validity, receipt validity, and registration do not create observation or independence that did not exist. No message format can supply the independent enforcement or observation dependencies that a prevention or adversary-resistant detection-coverage guarantee requires. An appendix works through a scenario in which one party creates another and may be able to act in its name. The document defines no protocol, no record format, and no registry. It collects non-inference rules, a control-topology test for prevention and detection claims, a worked example, and reporting distinctions for evidence that does not support the claim asserted over it. + + + +# Introduction + +An operator states that "the payment was executed". The artifact behind the statement is a signed log entry produced by the operator's own service. The signature verifies. The schema validates. The entry was registered with a transparency service. None of that establishes that the payment reached the payment network, only that the operator recorded and registered a well-formed statement saying so. + +Gaps of this kind are routine wherever execution-related evidence is consumed: audit pipelines, compliance reporting, supply-chain attestation, and incident forensics. They appeared recently and sharply in the IETF's agent-protocol discussions of 2026 ([abc](#abc)), in protocols for AI agents, where one party's software performs actions whose records are produced largely by the acting side itself. + +The failure mode is semantic and assurance inflation: the strength of a claim silently grows as an artifact moves between parties, formats, and summaries. A record of an invocation is cited as proof of execution. A valid signature is read as truth of the signed statement. The presence of an audit trail is read as completeness of coverage. An authorization is reported as an action performed. Each step feels small, but together they produce a claim that no producing boundary ever observed. + +This document states the bounding discipline in one place, in protocol-neutral terms, so that specifications, deployments, and reviews can name the exact point at which a claim outruns its evidence. + + + +## Scope and non-goals + +This document is descriptive. It defines no wire format, no transport, no carrier, no record or receipt format, no authority or authorization mechanism, no registry, and no generic evidence protocol. It does not compete with, extend, or profile any of the systems discussed in [related](#related). It states analytic limits that hold whichever of those systems carries the evidence. Because it specifies no protocol behavior, it does not use BCP 14 requirement keywords: statements of the form "X does not establish Y" are claims about what an artifact can support, not conformance requirements. + +This document states a claim-appraisal discipline, not an evidence-design discipline. It identifies when available evidence does or does not establish a claim, from the position of a relying party deciding what to conclude from what it has. It does not prescribe the complete set of observations, bindings, retention mechanisms, or architecture that would have to be put in place in advance so that a given claim remains determinable later. Enforcement or observation at the time of an action and determination at a later time are related, but they are not the same requirement. What further material should have been captured or bound at action time, where, and by whom, is related work and outside the scope of this document. + +The discipline is not new in its parts. Bounded claim statements are already in use in specific domains: a time-stamp token is evidence that a datum existed before a particular time, and the authority time-stamps only a hash of the datum and does not examine it [RFC3161](#RFC3161); DomainKeys Identified Mail (DKIM) distinguishes the signing domain from the purported author and limits its integrity assertion to the content covered by the signature [RFC6376](#RFC6376); certificate transparency describes its logs as making misissuance detectable rather than preventing it [RFC9162](#RFC9162); supply-chain transparency describes itself as holding issuers accountable rather than preventing dishonest ones [RFC9943](#RFC9943). This document collects such statements as one discipline for execution-related evidence and claims no priority for any individual rule. + + + +# Terminology + +This document uses the following terms descriptively. It uses "claim", "evidence", and "relying party" in their general senses. In the Remote ATtestation procedureS (RATS) architecture [RFC9334](#RFC9334), Evidence and Attestation Results are distinct artifacts, and either can serve as evidence here. A RATS Claim is a piece of asserted information inside such an artifact, while a claim here is a statement offered for reliance. Where a RATS term is meant, it is capitalized. + +**Claim:** + +A statement offered for reliance, concerning an action: that it was intended, authorized, invoked, performed, completed, or had an effect. + +**Evidence:** + +Artifacts offered in support of a claim: records, logs, receipts, signatures, attestations, provenance statements, transparency entries, and similar. + +**Producing boundary:** + +The vantage point, component, or interface at which a piece of evidence was produced, together with what that vantage point could observe and who controls it. This document uses "producing boundary" throughout as its general term for that vantage point. + +**Interested party:** + +A party whose conduct the claim describes or whose incentives are served by the claim being accepted; typically the operator of the acting system. + +**Relying party:** + +A party deciding whether to accept the claim. + +**Control topology:** + +The arrangement of which parties control which enforcement points, observation points, keys, and delivery paths relevant to a claim. + +**Independence:** + +A property of deployment and control. A statement of independence names a component and its role: enforcement, observation, delivery, or evaluation. It can instead name a record or the grounds of a premise. It names a party or a coalition (parties acting together), a period, and a threat model. The named thing is independent of that party with respect to a capability if the party lacks that capability over it. [independence](#independence) names three capabilities: forgery, concealment, and circumvention. Which of them matter depends on the claim. Independence describes control. Whether the evidence supports the claim is a separate question ([principle](#principle)). A label, a field value, a distinct key, an organizational name, or a count of components does not by itself establish independence. + + + +# The bounding principle + +The strength of an execution-related claim is bounded by: + +1. what the available evidence actually observed, constitutes, or proves, at the boundary that produced it; and +2. the control and observation topology at that boundary: who operated it, who could bypass it, and through whose hands its output travels. + +Message format, signature validity, receipt validity, and registration do not raise either bound. A format can carry a statement about control or observation, but it cannot create control or observation that did not exist. A signature authenticates bytes under a key. By itself it establishes neither the truth of what the bytes assert nor the signer's control of the boundary they describe. A receipt's evidential force depends on the property being checked, the observations or proofs that support it, and the applicable trust and deployment assumptions. Successful verification of a registration receipt can support that a statement was registered under the service's policy. Registration alone does not establish that the event described in the statement occurred. + +These limits concern what follows from the stated evidence and premises. They do not preclude an inference from complementary observations whose relationships and load-bearing assumptions are established. Cryptographic verification can support those assumptions. It does not supply a missing observation by authenticating a statement about it. + +Support does not have to come from direct observation of the claimed action. [constructive](#constructive) describes the other routes and their premises. + +In this document, evidence supports a claim when the claim follows from the evidence under the stated premises. One practical test checks this. Try to describe two cases in which the relying party holds the same evidence under the same premises, but the claim is true in one case and false in the other. If both cases are possible under those premises, the evidence does not support the claim as stated. Failing to find such a pair does not prove that none exists. Evidence that only makes a claim more likely does not support the claim in this sense, although it can still support a weaker claim ([reporting](#reporting)). + + + +# Evidence bases: what did the evidence observe? + +Execution-related artifacts answer different questions, and the differences are load-bearing. At minimum, the following bases are worth distinguishing: + +**Observation:** + +Some event concerning the action was recorded or reported. Absence of a record alone is not an observation that an event did not occur. + +**Intent:** + +A specific intention, plan, approval, or decision concerning the exact action is evidenced. This establishes neither the validity of the approval nor anything about performance. + +**Invocation:** + +The exact request crossed an observed invocation boundary. This does not establish that the invoked operation executed or had an effect. + +**Execution:** + +Performance of the exact action was evidenced at a boundary in a position to observe execution. This does not establish completion of a larger process, a durable external effect, goal satisfaction, correctness, or policy compliance. [constructive](#constructive) addresses claims about an effect, its persistence, and its finality. + +The observation base asks only whether some event concerning the action was recorded or reported. Elsewhere in this document, an observation is an event seen at a boundary in a position to see it (Sections [principle](#principle) and [constructive](#constructive)). Evidence at the observation base need not be an observation in that sense. + +These bases are distinct questions about one action. They are not levels on one scale, and they need not be mutually exclusive. A conclusion from one base to another holds only under stated premises. Evidence relevant to one base does not, merely by being assigned to that base, satisfy the evidential criteria relied on for another. Distinctions of this kind, between stages of an action's lifecycle whose evidence does not carry across, are long established in distributed-systems practice (for example the separation of a remote procedure call's invocation from its execution and its result). One executable realization that binds exact predicates to these four bases appears in [I-D.sergeev-wexp-core](#I-D.sergeev-wexp-core). This document does not depend on it. + +Other distinctions cut across the bases. Verification reach (who can check a record) is orthogonal to claim strength: a third-party-verifiable invocation record is still invocation evidence. And asserted content differs from observed content: a mediator's record may faithfully report what the mediator asserts about a downstream outcome it never observed. A useful record says at which boundary it was produced and whether each statement in it was observed there or merely asserted there. + +The action referred to by a claim should be identified at the relevant boundary. A business intention, an authorization, a request attempt, an execution, and a durable effect need not have a one-to-one relation. Retries, proxies, and idempotent processing can change those relations. A composite claim depends on evidence establishing the particular bindings it uses. This document prescribes no common identifier format. + + + +# The claim ceiling + +In this document, a kind of claim is a family of claims to which the same type of evidence is relevant, such as the bases of [bases](#bases). For a stated kind of claim, and under stated premises, a producing boundary limits the claims its evidence can support. Call that limit its claim ceiling. The term does not presume that all claims of one kind are comparable, or that one uniquely strongest claim exists. + +A boundary in a position to observe invocations, but not execution, cannot by its observations warrant execution claims. That holds no matter how many well-formed execution assertions its records carry. + +The underlying idea is old and this document claims no priority for it: a conclusion cannot be stronger than the vantage from which its supporting evidence was produced. [related](#related) describes prior formulations. + +A claim ceiling is an exclusion rule, not an evidence source. It can prevent a stronger claim from being supported, but it never creates support, so a supported claim still requires positive evidence at its own base. + +A ceiling is also only as good as the grounding of the boundary description itself. A boundary descriptor asserted by the producer is only the producer's own account. [independence](#independence) describes what grounds a statement about who controls a boundary. + +The accepted boundary description must apply to the time and deployment context of the claimed action. A later assessment or a current configuration does not, by itself, establish the earlier boundary's properties. + +The same applies to any premise that would make the producer's records informative without observation. Where a claim rests on the producer's incentives or objectives being known, that knowledge is itself a premise requiring its own grounding. An alignment asserted by the producer is only the producer's own account. + +This document defines independence in terms of control. Payment, contract, or ownership can give one party the means to direct another party's output or decision. They count here to the extent that they give that capability. + +A record that requires no later cooperation from the party whose conduct is at issue is not, for that reason, independent of that party. A record it made at the time and left in place needs nothing from it afterwards and remains its own account of itself. The distinction between independence from cooperation and independence of the evidence itself follows an exchange with Douglas Wadkins; see [I-D.wadkins-agentproto-action-determinability](#I-D.wadkins-agentproto-action-determinability). + +A claim ceiling is relative. It is stated for one kind of claim, at one observation boundary, with the support relation proper to that kind: which evidence supports which claim of that kind. Examples are the bases of [bases](#bases) and, separately, the prevention claims and the detection claims of [topology](#topology). + +Claims of different kinds are not ranked against one another by a ceiling. An execution claim and a detection claim are different kinds of claim, not points on one scale, and this document defines no scalar scale, level, or score on which all claims are ordered. "Stronger" and "weaker" in this document are always read within the kind of claim at issue. + + + +# Non-inference rules + +The following rules restate [principle](#principle) as individual limits. Each names an inference that is invalid without additional, separately established premises. None is original here; scoped versions of several appear in the documents cited in [related](#related). + +Each rule is justified analytically. An example or a standards reference given with a rule is an illustration, and it is not presented as a documented incident. Claims about practical occurrence or consequences require their own support. + +The list is not closed. A reader who finds a promotion these rules do not name has found a gap in this section, not a license for the promotion. + +1. Successful signature verification does not by itself establish the truth of an event claim in the signed content. Establishing that correspondence requires grounds beyond signature validity. Separately, signature validity alone does not establish the signer's control of the boundary described by the claim. The same distinction is drawn for verifiable credentials, where verifiability of a credential does not imply the truth of the claims encoded in it [VC-DATA-MODEL](#VC-DATA-MODEL), and for signed Decentralized Identifier (DID) documents, where proofs in the document do not by themselves necessarily prove control over the DID [DID-CORE](#DID-CORE). +2. Attribution of an actor is not proof that the attributed party performed the action. That a record is attributed to a party -- by a key, an identifier, or a credential associated with that party -- does not establish that the party performed the action, where another party can obtain, invoke, or emulate the attributed capability. Where one party creates or hosts another and can reach that other's signing or authenticating capability, an action attributed to the hosted party may have been performed by the host. Where a record reaches the relying party through intermediaries, attribution established at one step of that path does not carry to the next without that step's own basis. A transport can establish which component delivered a record. A source that the deliverer names inside the record is the deliverer's assertion, unless the record carries its own verifiable binding to that source. +3. A receipt, record, or registration is not external execution or effect. Registration establishes that a statement entered a log or service under that service's policy. Matching records held by different parties establish that their contents agree (correspondence), not that the parties agree. Correspondence does not establish which event preceded which (precedence), and it does not establish occurrence. +4. Presence of records is not completeness of coverage. A set of records, each individually authentic, does not establish that the set is all the records there are. Detecting omission requires more than the authenticity of each record: an independently grounded expectation of the complete population, which the set itself may carry, or a recording boundary that cannot be bypassed. +5. Absence of a record is not non-occurrence, unless the observation regime supports that inference. The inference from "no record" to "no event" is valid only where a declared, enforced recording boundary meets three conditions. It covers the event class. It cannot be bypassed by the parties in question. And gaps in the record stream are themselves detectable, for example against a pre-declared cadence or sequence carried in the records and watched by a party outside the producer. Otherwise absence is only absence. + + Such an inference also requires an identified interval, evidence that the required recording and delivery coverage held for that interval, and resolution of relevant delays and gaps. Detectability of a gap does not license a non-occurrence claim while the gap remains unresolved. The conclusion is limited to the specified event class, population, and interval under the stated assumptions. + + Bypass of the recording boundary is not the only way a record can fail to appear. A record may have been made and then withheld, whether by a retention policy that removed it or by a disclosure decision that did not produce it [AP-SCHROCK-RETENTION](#AP-SCHROCK-RETENTION). Where either is possible, the result is a statement about the evidence set examined and not about the recording boundary, and the conditions above are not met by the boundary alone. +6. Authority granted is not action performed. Authorization evidence, however exact, single-use, and attenuated, bounds what a grant permits at the point where it is enforced. It does not establish that the authorized action occurred. What is missing is evidence on the action's own basis: an observation of invocation or of execution, at a boundary in a position to make it, or a record that constitutes the action rather than describing it ([bases](#bases) and [constructive](#constructive)). +7. Internal observation is not independent observation of an external effect. An observation made inside the acting party's boundary can establish, at most, what that boundary observed, and a record's statements about effects at other systems are assertions. In particular, a record minted by the deciding or authorizing side cannot by itself establish the order of its own decision against an effect that side does not observe. Other evidence carried in the same record is appraised under the routes and premises of [constructive](#constructive), regardless of its source. +8. Time and sequence evidence is bounded by the observation and control properties of its source, like any other evidence. A timestamp or sequence number is only as strong as the party and mechanism that produced it: one minted by the interested party over its own record orders that record, not the world. This is not a claim that time evidence is worthless. Trusted time-stamping has a distinct and stronger evidentiary role: a time-stamp token from an appropriately trusted authority is evidence that a datum existed before a particular time [RFC3161](#RFC3161). And a sequencing mechanism whose observational domain covers both of two events can order them. The rule is that the strength of the time or sequence claim follows the source, and must not be read past what that source observed and controlled. +9. A missing or unverifiable load-bearing premise cannot be silently promoted. Where support for a claim depends on a premise that was not evaluated, or that only the interested party can vouch for, the claim inherits that limitation. The report names the claims that are supported, and keeps the status of each premise that was not evaluated. A conditional claim states the premise it depends on ([reporting](#reporting)). +10. Current authentication, when its verified scope is limited to a present binding, does not by itself establish identity continuity or succession relative to an earlier subject. Identity continuity, succession, and the present applicability of prior authorization, standing, or reputation are distinct claims. Each requires grounds covering the specific relation or applicability asserted under the relevant identity and authorization rules. A record's evidentiary force depends on those rules and its verified properties, not merely on its statement of the claim. DID Core states the corresponding limit for persistent identifiers: absent published operational policies, requesting parties are not expected to assume that an identifier is persistent for the same subject [DID-CORE](#DID-CORE). +11. Behavior observed under one set of conditions does not establish the same behavior under other conditions without grounds for carrying the conclusion across. A test, an audit, or a monitored run observes a system under the conditions it applies. The result describes those conditions. Carrying it to other conditions needs grounds that the two do not differ in anything the behavior depends on. Where the system can detect that it is being tested or observed, results obtained under those conditions do not by themselves supply such grounds, since the system can make its behavior depend on them. [findings](#findings) reads the emissions case this way. +12. Multiplicity is not independence. A number of records, keys, services, or organizational names does not by itself establish independent support. Where one party has a capability that matters to the claim over several of them, their number adds no independent assurance against that party ([independence](#independence)). Independence is judged claim by claim, for the components on whose correctness the support for that claim relies. +13. Coherence is not corroboration. The detail, internal consistency, plausibility, or fluency of an account produced by the interested party does not by itself support the claim that what it describes occurred. A fabricated account can have all of these properties, so they do not distinguish a true claim from a false one (the test of [principle](#principle)). This holds with particular force for accounts generated by software, including language models, whose output can be fluent whether or not it matches the events it describes. Support needs grounds beyond these qualities, and evidence carried with the account can provide them by one of the routes of [constructive](#constructive). + +Every rule here is stated against premises. The premises a conclusion rests on, their grounds, and their status should be available directly or by unambiguous reference. A premise accepted as a matter of policy is not thereby independently established. Where the premises change, whether the conclusion remains warranted has to be checked rather than assumed. + +Aggregation, transformation, summarization, and re-signing remove none of these limitations. A pipeline that normalizes, merges, or re-encodes evidence inherits each relevant limitation of its inputs unless a specific limitation is specifically resolved by additional evidence. An unsupported widening of a claim at the output of such a pipeline is a defect to locate, not a result to report. + + + +# A claim-boundary review lens + +The rules above can be applied as a short checklist when reviewing a specification, a deployment, or an evidence design. For a given claim, ask: + +1. Exact claim. What exact claim, about what exact action, is being made? +2. Producing boundary. Which boundary produced the supporting evidence, and what could that boundary observe? +3. Control. Who controls that boundary? Can the interested party or coalition forge its output, conceal it, or circumvent it ([independence](#independence))? Which of these capabilities matter to the claim being made? Did the limits on them hold for the period the claim depends on? What grounds those limits? +4. Ceiling. For the kind of claim at issue, what claim or claims can that boundary warrant? Does the asserted claim exceed them? +5. Positive evidence. Is there positive evidence at the claim's own base? A ceiling supplies no evidence, and a signature or a registration supports only the predicate that its verification establishes. +6. Prevention, detection coverage, or a particular finding. If the claim is that misbehavior is prevented, which independently controlled enforcement point does it rest on ([topology](#topology))? If the claim is that misbehavior of a specified class cannot be concealed, which independently controlled observation and delivery dependencies does that coverage rest on? For a claim that a particular event was detected, which evaluation act (evaluator, predicate, evidence basis, window or context) is identified? +7. Basis for a claimed effect. Which route of [constructive](#constructive) supports the claim? The routes described there include observation at a boundary outside the interested party's control, a record that constitutes the action, and evidence whose verification establishes a predicate. Where the support rests on another basis, is that basis stated? What limits its scope? +8. Completeness and absence. Does the claim depend on the record set being complete, or on an absence meaning non-occurrence? Is that supported (rules 4 and 5)? What interval and delivery horizon were evaluated, and were relevant gaps resolved? +9. Pipeline widening. Does any step between production and reliance widen the claim beyond what the producing boundary supported? +10. Reporting. Does the report separate whether each evaluation was made from what it found ([reporting](#reporting))? Does it name the supported claims, and the reason for any evaluation that was not made? Is anything silently rounded up? + +The considerations sections of [RFC3552](#RFC3552) (security) and [RFC6973](#RFC6973) (privacy) are the models for this genre: a document states, in its own terms, what its mechanisms do and do not establish, and what residual exposure remains. This lens applies the same documentation discipline to the semantic strength of execution-related claims. It is a review aid, not a conformance procedure. + + + +# The control-topology test + +Claims that an architecture prevents or detects misbehavior are execution-related claims about the architecture itself, and they are bounded the same way. Farrell's (a,b,c) scenario, described in [abc](#abc), motivates the control-topology test used here. Stated mechanism-neutrally: + +**Prevention:** + +A claim that party B is prevented from performing or forging an action requires an enforcement point that B does not control and cannot bypass, positioned so that the action cannot complete without it. A component outside B's control that is not actually required for the action prevents nothing. + +**Detection coverage:** + +A claim that misbehavior in a specified class cannot be concealed by B requires the following. + +**Evidence:** + +adequate to distinguish that misbehavior under the stated assumptions. + +**Controls:** + +delivery or omission controls that prevent B from hiding it without an observable indication. + +The claim should state its coverage, timing, and failure limits. These coverage conditions are distinct from establishing that a particular event was detected from evidence already obtained. + +**Independence:** + +The prevention and coverage properties above depend on independence in the sense of [independence](#independence). The components concerned are the enforcement point, the observation point, and the delivery path. The party concerned is the stated party or coalition. + +An architecture claiming prevention or adversary-resistant detection coverage should state: + +- which independently controlled enforcement or observation dependencies the guarantee rests on; +- what the relevant limits on forgery, concealment, and circumvention are ([independence](#independence)); +- what happens when a dependency is unavailable or cannot be validated. + +Without those dependencies, that guarantee is not established against adversarial B, whatever its message formats carry. This does not invalidate a narrower finding supported by evidence that has actually been received and evaluated. + +A protected observation path is not, by itself, sufficient for detection. The evidence must support a check that distinguishes the specified misconduct under the stated assumptions. An observable gap can establish a loss of coverage without establishing which underlying event occurred. + +A claim that a particular event was detected requires an identifiable evaluation act. The record should name which evaluator evaluated, which predicate was checked and with what result, and on what evidence basis. Where a window or context applies, it should name that too. + +Such a finding does not, by itself, establish that all events of that class were detectable or detected. A path that could have revealed an event does not show that anyone looked. This document defines no format for stating those items. + +Certificate Transparency (CT) [RFC6962](#RFC6962) [RFC9162](#RFC9162) illustrates a limited omission control. Consider a TLS client whose policy requires valid Signed Certificate Timestamps (SCTs) from specified logs before accepting a certificate. Assume the client uses authentic log keys, validates the SCTs correctly, and the SCTs cannot be forged. If the issuing certification authority (CA) or stated coalition cannot change or bypass the client's enforcement of that policy, acceptance requires signed log promises bound to the certificate or its corresponding precertificate. For an issued certificate, the submitter need not be the CA. SCTs may be presented alongside the certificate. + +Each SCT promises that the corresponding entry will be added to the log within the log's Maximum Merge Delay, measured from the SCT timestamp. It does not establish that the entry was added. Inclusion needs separate evidence, such as an inclusion proof verified against an authenticated signed tree head. Another route is to reconstruct the complete tree, verify that it contains the entry, and confirm that its root matches the root in that authenticated tree head. Inclusion does not establish consistency of all log views. A verified consistency proof establishes the append-only relationship between the specific authenticated tree states checked. Detecting conflicting views depends on comparing relevant observations. The gossip mechanism for that exchange is outside the scope of [RFC9162](#RFC9162). + +A stronger claim that specified misbehavior cannot be concealed by the CA or coalition depends on the required independent controls over logs, observation, and evidence delivery ([independence](#independence)). The claim should state its coverage, timing, and failure limits. It should also state the relevant limits on forgery, concealment, and circumvention by the CA or coalition. Verifying an SCT does not establish these conditions. The acceptance control does not establish a complete record of certificate issuance. Certificates never presented on a path where the client enforces the policy are outside its scope. A claim that misissuance was detected from CT evidence requires an identifiable evaluation act using evidence adequate for the predicate being checked. Being able to obtain that evidence does not show that a monitor or other evaluator checked it or found misissuance. + +Existing mechanisms slot into this test rather than exempting themselves from it. Remote attestation [RFC9334](#RFC9334) contributes where all of the following hold: + +- the Evidence covers the property at issue; +- the adversarial party can neither forge nor substitute the Evidence or the Attestation Result, nor control the Verifier, its Appraisal Policy for Evidence, or the Endorsements and Reference Values it relies on; +- the result is freshly and securely bound to the relevant actor and action. + +RFC 9334 permits its roles to be aggregated into one entity, so independence from a given party is a property of the deployment, not of the architecture. + +Threshold signing [RFC9591](#RFC9591) contributes a prevention dependency exactly where the adversarial party or coalition cannot reach the threshold without an independently controlled signer that checks the exact operation and can withhold its share. These mechanisms contribute only to the properties and dependencies actually established by their deployment. + +OAuth sender-constraining mechanisms such as Demonstrating Proof of Possession (DPoP) [RFC9449](#RFC9449) can limit the use of stolen tokens. They do not by themselves prevent B from invoking a key through a signing interface B controls. That holds whether the key was provisioned by another party or stored as non-exportable (Section 11.4 of [RFC9449](#RFC9449)). + +An isolated execution environment, including a trusted execution environment (TEE), can contribute an enforcement dependency where B cannot modify or bypass the relevant checks. Claims about effects outside that environment still require an appropriate evidence basis. + +The Workload Identity in a Multi System Environment (WIMSE) architecture [I-D.ietf-wimse-arch](#I-D.ietf-wimse-arch) separates workload authentication from authorization and permits different placements of policy enforcement. The test therefore asks who controls the deployed enforcement point and which operations it covers, rather than treating workload identity or credential provisioning as evidence that the claimed operation occurred. + +The independently controlled point need not be cryptographic. A preserving repository may be audited and certified against a published standard [ISO16363](#ISO16363), by a body the repository does not control and which is itself accredited under a separate regime [CCSDS652-1](#CCSDS652-1). That contributes a detection dependency if the audit observes the practice at issue and if any suppression of an adverse finding by the audited party would become visible. + +That contribution is limited by the audit's scope, period, sampling, access, and reporting arrangements. Certification alone does not establish complete observation of all relevant conduct, nor the visibility of every suppressed adverse finding. The recursion terminates in an accreditation body that some party must be prepared to treat as terminal. + +The test is indifferent to whether the point outside the party in question is a key, a verifier, or an accreditation regime. It asks only whether the deployment placed one there, and what that point actually covers. + + + +## Independence and the claim at issue + +A statement of independence says which capabilities of the party matter to the claim at issue. It says what grounds the limit on each of them. This document does not say which grounds suffice to establish that such a limit holds. + +The capabilities in question are these. + +**Forgery:** + +The party can make a relying party accept false evidence. One way is to fabricate the evidence, substitute or replay it, or alter it without detection. Another is to direct the component that produces the evidence, so that its output is false. + +**Concealment:** + +The party can act outside the recording boundary, so that the activity is not recorded there. It can also suppress, withhold, or delay evidence that exists. + +**Circumvention:** + +The party can complete the action without the enforcement point, or direct the decision of that point. + +Where this document says "bypass", bypassing an enforcement point is circumvention and bypassing a recording boundary is concealment. + +A claim needs limits only on the capabilities that matter to it. A capability matters to a claim if the party could use it to leave the relying party holding the same evidence while the claim is false. That is the test of [principle](#principle), applied to what the party can do. Take a particular finding made from evidence already received. Forgery matters to it, and so does the binding of the evidence to the exact action ([constructive](#constructive)). A payment network's record of transfer T can support that T occurred. This holds although the operator could have withheld the record or made other transfers elsewhere. Concealment matters to completeness and to detection coverage (rules 4 and 5). The same record does not support that these are all of the operator's transfers. Concealment can also matter to a particular finding, where omitted evidence would change the finding. Circumvention matters to prevention. The limits have to hold for the period the claim depends on. A present assessment does not by itself establish that the limits held earlier. + +Independence does not make an observation relevant to the claim. An observer outside the operator's control that saw a command sent has not thereby seen it executed. A separate question remains: can the observation distinguish a true claim from a false one ([principle](#principle))? + +A dependency can enter where evidence is formed, where it is delivered, and where it is evaluated. An independent evaluator can verify the interested party's own account, but the account does not become an independent observation. Control over delivery gives the capability to conceal, and it can also permit substitution or replay, but it does not give control over the source. An independent component does not make a record presented as its output authentic: the operator can present a forged confirmation from an independent payment network. The relying party therefore checks origin, binding to the exact action, and any required freshness separately ([constructive](#constructive)). + +Two sources that take a fact from the same origin both depend on that origin for that fact. Two logs that each copy the operator's message are not two observations of execution (rule 3). Where one party has the relevant capability over several components, those components do not count separately against that party. Three services that act, record, and check, run by one operator who can change their code or their records, divide the work but not the control. The useful question is which error or fabrication the second source rules out. Independence from one party does not establish independence from a coalition that includes it. + +A statement of independence is itself a claim, with a producing boundary and a ceiling. Its grounds can stop at a premise that a party accepts as a matter of policy. A claim that relies on the statement then stays conditional on that premise. The premise travels with that claim when it is passed on (Sections [noninference](#noninference) and [reporting](#reporting)). The audit example in [topology](#topology) shows one such premise. [constructive](#constructive) describes evidence whose source need not be independent. + + + +# When stronger claims become supportable + +The discipline does not only rule claims out. Stronger claims about a particular effect become supportable when the effect is observed at a boundary capable of observing it. That capability is judged under the stated threat and control model. The evidence of that observation must also be protected against undetected fabrication or alteration by the interested party. Coverage claims additionally depend on the observation and delivery conditions described in [topology](#topology). + +An external footprint is one important route to such observation. Examples are movement on a payment rail, and resource or configuration records in an external provider's control plane. In each, a system the interested party does not control observed something at its own boundary, and a relying party can check that system's records against the claim. + +It is not the only route. The observing boundary may be any of several things: + +- an external service, a counterparty, or a settlement system; +- an external control plane; +- the relying party's own observation boundary, where the relying party itself observes the effect: a state change in a system it operates, or a delivery it takes receipt of itself; +- another point that is in a position to observe the relevant fact and that the interested party does not control under the stated threat model. + +A distinct third party is not always necessary. The relying party's own observation may provide the required evidence, subject to the same claim-specific trust and deployment assumptions. + +A further route relies on a record constituting the precise action claimed, rather than describing a separate action: + +- a signed order that is the order; +- a recorded state transition on a ledger that is the transfer; +- a recorded command whose issuance is itself the claimed action; +- a write-ahead entry that defines the commit. + +Such a record supports that precise claim, because issuing or accepting it constitutes the action under the applicable rules. The evidence must establish the conditions that give the record that constitutive effect, including any applicable authority, acceptance, and commit or finality conditions. A record on a branch that was never accepted does not constitute the action merely by resembling one that would. + +What it supports is bounded by the action it constitutes and extends no further. A ledger entry that is the transfer establishes the transfer, not that goods moved. A signed order that is the order establishes the order, not that it was carried out. Where a record describes an action it does not constitute, this route does not apply. + +Another route relies on evidence whose verification itself establishes a predicate. Examples are a proof of computation, a proof of possession, and a response to a fresh challenge. The source of such evidence does not need to be independent of the interested party. Successful verification establishes the proved predicate, under the premises of the verification. Those premises include the soundness of the proof system, the integrity of the verifier, and that the statement verified is the one the claim names. Where soundness bounds the probability of a false acceptance rather than excluding it, treating it as exact is an idealization, and a report that relies on it should say so. A claim that does not follow from that predicate needs its own evidentiary grounds and the bindings it requires. For a proof of computation, such claims can concern whether the committed inputs match the facts they stand for. They can concern who performed the computation, when a policy was applied, or whether an external effect followed. Signature verification is the familiar case: the proved predicate is that the bytes were signed under the key, and rule 1 applies to anything beyond it. + +The qualifications below travel with these routes: + +- The observing boundary supports claims at its own observation boundary and no further. A payment network's record establishes what the network observed about a transfer at its boundary, not that a business obligation was satisfied. A relying party's own observation establishes what the relying party observed at its boundary, and no more. +- The observation, whether an external footprint or the relying party's own, must be bound to the exact action claimed. A matching amount, timestamp, or counterparty is correlation, and correlation supports weaker claims than a validated binding. +- The protection afforded by the observing boundary is itself a threat-model statement. For a particular finding, the relevant protection is against the operator of the acting system fabricating or undetectably altering the evidence for the claimed observation. Against the operator of the observing boundary itself, the route gives no additional support. Where the relying party observes at its own boundary, the claim rests on the relying party's own observation, which is independent of the interested party but not of the relying party. +- An effect is observed at a time. The observation does not, by itself, establish that the effect persisted or is final. A transfer can be reversed, a write can be rolled back, and a ledger branch can be abandoned. A claim of a durable or final effect needs evidence of the conditions that make it so. The rules of the system where the effect occurs set those conditions. That evidence needs one of the routes of this section. +- Ordering claims, such as that the decision preceded the effect, require an ordering relation whose observational domain includes both terms. That means one boundary that observed both, or records from the two boundaries that can be securely related and ordered. Matching records alone establish neither the order of the records nor the order of the events. +- The capability to conceal does not, by itself, invalidate evidence that has been received ([independence](#independence)). Subject to the qualifications above, the received evidence may support a particular finding within its observational and temporal scope. A finding that depends on the completeness of a specified evidence set, or on absence as evidence of non-occurrence, requires the corresponding coverage and gap-resolution basis (rules 4 and 5). + + + +# Worked example: a payment + +Consider an agent that reports having paid a supplier. Three evidence artifacts and a report combining them are on the table. The point of the example is that they support different claims, and that a report must keep separate what each boundary observed from what it merely asserts. + +1. A self-produced execution record. The operator's own service emits a signed record: "paid supplier S, amount X, at time T". Observed at that boundary: that the operator's service produced and signed this statement. Asserted, not observed there: that the payment reached S. What it supports on its own: that the operator stated a payment; not that the payment occurred (rules 1, 3, 7). + + This example assumes that the record contains only the operator's own statement. If it carries independently verifiable evidence from another source, that evidence is appraised at its own producing boundary. The party assembling the container does not determine every item's origin. +2. A transparency registration. The signed record is registered with a transparency service, which returns a receipt carrying an inclusion proof. Observed: that this statement was registered under the service's policy. Any claim about registration time depends on the time evidence provided and its verified scope. What it does not establish: the truth of the statement or the occurrence of the payment (rule 3). Registration raises auditability, not the claim ceiling. +3. External payment-network evidence. A record from the payment network -- a settlement entry or network-issued confirmation -- that the network observed a transfer matching the action. Observed at a boundary outside the operator's control: that the network saw a transfer with these attributes. This is the footprint of [constructive](#constructive), and it must be bound to the exact action: a bare amount-and-time match is only correlation. Its strength holds against the operator, not against the payment network's own operator. +4. A composite report. A report that draws on all three should read, in substance, as three statements. The operator asserts a payment (1). The assertion is registered and independently checkable as an assertion (2). And where (3) is present and bound to the exact action, a system outside the operator observed a matching transfer at its boundary. That last supports a payment-reached-the-network claim, to the extent the binding holds and that evidence is protected against fabrication or undetected alteration by the operator. With only artifacts (1) and (2), the supportable claim is that the operator stated and registered a payment, not that a payment occurred. + +A report over these artifacts could read as follows. Evaluator V checked the origin of each artifact and the binding of the network record to the payment. V accepts one named premise: the network's record is reliable for the event it reports. Assume that the record reports that a transfer was seen, and says nothing about finality. V did not assess whether the set covers all of the operator's payments. + +- A statement of the payment was signed under the operator's key. Evaluated. Supported: the signature verifies. +- The statement was registered. Evaluated. Supported: the receipt verifies, within its scope. +- The network observed a transfer bound to this payment. Evaluated. Supported: origin and binding were checked, under the named premise. +- The payment to S is final. Evaluated. Unsupported by this set: the evidence evaluated does not establish the conditions for finality ([constructive](#constructive)). +- These are all of the operator's payments in the period. Not evaluated: completeness was not assessed (rule 4). + +Suppose instead that only the amount and the time match, and the binding is not established. The third entry is then unsupported for this payment. That the network saw some transfer remains supported. + +The example makes no universal assertion about what any particular service observes. What a given payment service, transparency service, or agent runtime actually observed is a fact about that deployment, to be stated from its evidence, not assumed from its role. + + + +# Reporting what the evidence supports + +Where evidence does not support the claim asserted over it, the useful output is not a bare failure. For each claim, a report says whether the evaluation was made and, if it was, what it found. These are separate questions. An outcome-binding profile drew a related line earlier: its indeterminate state, used when required evidence is missing, unauthenticated, unpinned, or not exactly bound, is not a comparison outcome [I-D.schrock-ep-outcome-binding](#I-D.schrock-ep-outcome-binding). + +Whether the evaluation was made: + +**Evaluated:** + +The relevant assessment ran over identified evidence, in an identified appraisal context. + +**Not evaluated:** + +The assessment did not run, the identified evidence could not be obtained, or the premise was outside the evaluation's scope. This status supplies no finding for or against the claim. It does not mean the claim is false, and it does not determine what the available evidence would support if evaluated. Nor is it permission to discard evidence that positively supports a claim at its own base. A claim well supported at its own base stays supported, even while another claim is not evaluated. It is also not a reason to repeat an action whose outcome is unknown, since the first attempt may have completed. That profile states the same limit for its indeterminate state [I-D.schrock-ep-outcome-binding](#I-D.schrock-ep-outcome-binding). + +**Unverifiable:** + +A reason for "not evaluated" that belongs to the evaluator. The statement is one that the evaluator in question cannot check from the evidence and inputs available to it at the time of evaluation. The standing example is a producer's description of its own deployment, which an evaluator may be unable to check without deployment access or other adequate evidence about that deployment. The category is relative to an evaluator and to an evidence or input set. Where they matter, it is relative to an evaluation context or time as well. A statement can pass from verifiable to unverifiable while the record itself is unchanged. The evaluator that could check it may cease to exist, or lose its access or the means to interpret what it holds. Such statements can still be worth carrying. The report names the reason and the premise that was not checked. Where a statement rests only on the producer's account, the report says so. A reader can then see which parts of a composite claim rest on trust. A report that fixes the category without fixing the evaluator and the moment says less than it appears to. + +What the evaluation found: + +**Supported:** + +The evidence evaluated supports the claim as stated, under the stated premises. + +**Unsupported:** + +The assessment ran over the evidence evaluated, and that evidence failed it. This is a finding about the evaluated evidence, relative to the evidence set and the appraisal context in which it was evaluated. It is not a property of the world, and a different evidence set may support the claim. Where the assessment ran and the evidence evaluated lacks what the claim needs, the claim was evaluated and the finding is unsupported. + +**Refuted:** + +The evidence supports the negation of the claim. Absence of a record refutes a claim of occurrence only where rule 5 of [noninference](#noninference) permits the inference from absence to non-occurrence. The report should state that finding and its basis explicitly, rather than treating it as mere absence of support. + +One reporting practice applies to both questions: + +**Downgrade to the supportable claim:** + +Where the asserted claim is unsupported or not evaluated, report the strongest claim of the kind at issue that the evidence does support, or the supported claims where there is no unique strongest one, alongside the asserted claim, with its status and any finding. A claim supported at another base is a separate finding, not a downgrade; support at one base is not inferred from support at another ([bases](#bases)). "Invocation: supported. Execution: unsupported by the evidence evaluated" is actionable; "invalid" is not. + +Collapsing "not evaluated" into "unsupported", or either into "refuted", destroys information a relying party needs: "we checked and it failed" and "we could not check" call for different decisions. These terms are not a result-code set. One report can say that a claim was not evaluated because a premise is unverifiable, and also identify a weaker claim that is supported. + +A support assessment over the available evidence can complete while a required premise is not evaluated. The report identifies these assessments separately. + +Each of these terms is relative to the evidence actually evaluated, and a report is more useful when it says what that evidence was. The evaluated set may itself be incomplete or selected. Every record in it can verify while records that would have changed the outcome were never delivered: rule 4 of [noninference](#noninference), met again at the reporting layer. + +A verdict applies to the evidence basis it names, and a verdict that names no basis invites exactly the widening this document is about. + +Appraisal results travel. One evaluator's result may be consumed by a later composite report: that a claim was not evaluated, for instance. The later relying party then needs to distinguish an attributable appraisal from an unattributed conclusion. + +Propagated or aggregated appraisal results should therefore retain enough provenance to identify: + +- who or what appraised; +- the evidence or input basis, or a stable reference to it; +- the predicate, profile, or evaluation context under which the result was reached, including the boundary at which the appraisal was made. + +Without that, "not evaluated" degrades across aggregation into somebody's unattributed conclusion. That is the aggregation limit of [noninference](#noninference) arriving at the reporting layer. Where evaluated evidence or received appraisals support incompatible findings, the report identifies the conflict and any premise used to resolve it. + +This is a consideration for reporting designs. It is not a record format and not a general retention requirement. The provenance of an appraisal identifies who is reported to have appraised what, under which context. By itself it establishes neither that the appraisal ran as reported nor that the underlying event occurred. + +Consider a decision about whether a specified activity may continue. An accurate report of an authorization-status check does not by itself establish that the reported result was available to, or used by, the decision-maker. This remains so when the report states that no current answer was available. Admission of the continuation does not by itself establish that authorization was current. The applicable meaning of "current", including its reference time, is part of the appraisal context. + +A claim about the basis of the decision needs grounds covering the relation between the exact decision, the continuation, the authorization-status input consulted for that decision, and the outcome of that consultation, including whether a current answer was returned. Merely identifying the consulted input does not establish the outcome of the consultation or that any returned result was used in making the decision. Whether admission is permitted when status is unknown is a separate policy question. + +A reporting design that preserves these distinctions makes inflation visible: every summary that would erase one of them is a place where a stronger claim would otherwise silently replace a weaker one. + + + +# Applicability beyond AI agents + +Nothing in this discipline is stated in terms specific to AI agents. The same bounding questions apply to: + +- audit logging and monitoring pipelines, where the questions are what the log source observed and who can write to it; +- evidence collection and archiving practice [RFC3227](#RFC3227); +- signed system logs [RFC5848](#RFC5848); +- transparency systems ([RFC9162](#RFC9162), [RFC9943](#RFC9943)); +- long-term evidence records [RFC4998](#RFC4998); +- compliance reporting and incident forensics; +- operational telemetry, which is self-reported by instrumented code and designed for diagnosis rather than adjudication. + +Agent systems sharpened the problem. Actions are initiated by software whose records are produced mostly at the acting side, and delegation chains multiply the boundaries across which claims travel and inflate. But the rules in [noninference](#noninference) are stated as properties of evidence rather than of agents. + +One domain is worked here: the long-term preservation of records, where no agent acts and no payment is made. A preserving repository holds a record deposited by its creator. Fixity evidence can support a claim that deposited bytes have not changed relative to an accepted baseline. Identity and provenance evidence may support an authenticity assessment under stated assumptions. Archival diplomatics drew this distinction earlier and for a different substrate. It separates a record's reliability at the point of creation, the accuracy of its content, and its authenticity [INTERPARES](#INTERPARES) [DURANTI1998](#DURANTI1998). Neither finding, by itself, establishes that the record was reliable when created or that its content was accurate. Preservation does not convert custody integrity into truth of the original content. That is an instance of the claim ceiling of [ceiling](#ceiling). + +A gap in a deposited series supports no conclusion about what was never deposited, unless the deposit regime was declared, enforced, and observable to a party outside the depositor (rule 5). Whether a preserved record can still be evaluated depends on the record, the available representation and provenance information, and the evaluator's knowledge and access. This illustrates the evaluator- and time-relative unverifiability of [reporting](#reporting). The Open Archival Information System (OAIS) reference model addresses continued understandability for an identified Designated Community [ISO14721](#ISO14721). + +[findings](#findings) gives three public findings that state the same bounds outside agent systems. Applicability to the other domains listed above is asserted on the same grounds and is not worked case by case here. + + + +# Related work + +The following work provides existing mechanisms and domain-specific treatments relevant to these limits. This document collects selected implications for the appraisal of execution-related claims. + +**Non-bypassable mediation and tamper-evident logging:** + +Two older lineages give this discipline its positive content. In the reference-monitor lineage, a security-relevant decision is enforced only where every access is mediated by a mechanism the controlled party cannot bypass and cannot tamper with [ANDERSON72](#ANDERSON72) -- the prevention half of [topology](#topology). In the tamper-evident and transparency-logging lineage, alteration or equivocation in a record set can be made externally detectable [SCHNEIER-KELSEY](#SCHNEIER-KELSEY) [RFC9162](#RFC9162) -- the detection half. This document restates the boundary conditions those lineages already identified. It adds no mechanism, and claims none of them. + +**Attestation:** + +RFC 9334 [RFC9334](#RFC9334) defines remote-attestation roles, appraisal flows, and trust assumptions, and the Entity Attestation Token (EAT) [RFC9711](#RFC9711) provides an attested claims set. This document draws on those concerns to organize a review discipline for execution-related claims across artifact classes. It defines no remote-attestation machinery. + +**Transparency and receipts:** + +CBOR Object Signing and Encryption (COSE) Receipts [RFC9942](#RFC9942) prove properties of a verifiable data structure, such as inclusion and consistency. Successful verification supports the specified data-structure predicate under the applicable cryptographic and trust assumptions. It does not, by itself, establish that an event described in a registered statement occurred. Supply Chain Integrity, Transparency, and Trust (SCITT) [RFC9943](#RFC9943) applies transparency mechanisms to supply-chain statements and explicitly addresses the limits posed by dishonest issuers. Certificate transparency provides inclusion and consistency checks over log views [RFC9162](#RFC9162). A misbehaving log can nevertheless present inconsistent views to different clients. Detecting that behavior depends on comparing relevant observations, or on other mechanisms that address such split views. These are existing examples of bounded evidence claims. + +**Supply-chain step attribution:** + +in-toto [IN-TOTO](#IN-TOTO) binds the artifacts flowing between the steps of a software supply chain, the order of the steps, and the identity of the party that signed for each, against a layout declared in advance by the project owner. Its analysis states the assumptions under which that binding holds, and how the guarantees degrade under key compromise. Both are boundary statements of the kind this document asks producers to make explicit. + +**Provenance:** + +PROV [PROV-DM](#PROV-DM) models provenance as asserted descriptions that feed trust assessment, not as verdicts. + +**Prior formulations by the author:** + +The four bases of [bases](#bases) and the ceiling of [ceiling](#ceiling) restate, in generic terms and without the level scale used there, content levels and the boundary axiom (Axiom BC) of earlier joint work with Vladimir Ikher [WITMODEL](#WITMODEL). The Witnessability Conceptual Core states the generalization of that axiom as a derived rule [WCC-CORE](#WCC-CORE). The appraisal core of the Witnessed Execution Protocol (WEXP) [I-D.sergeev-wexp-core](#I-D.sergeev-wexp-core) gives an exclusion-only operational realization that binds exact predicates to the four bases. This document preserves that exclusion-only role. It makes no claim of independent discovery or priority, and its rules can be stated and applied without either work. The author's interest in WEXP is disclosed below. + +**Agent-protocol evidence work:** + +Individual Internet-Drafts address per-claim verifier, binding, freshness, and failure discipline [I-D.bu-agentproto-security-principal-binding](#I-D.bu-agentproto-security-principal-binding); enrollment and key-binding assumptions [I-D.yossif-enrollment-problem](#I-D.yossif-enrollment-problem); evidence of authorization decisions [I-D.bradleyb-audit-decision-records](#I-D.bradleyb-audit-decision-records); and an architecture for auditing agents' interactions and delegation [I-D.kuehlewind-audit-architecture](#I-D.kuehlewind-audit-architecture). Work on agent control delivery and outcome reconciliation [I-D.abak-agent-control-delivery-evidence](#I-D.abak-agent-control-delivery-evidence) distinguishes issuer-side emission, required-target resolution, receiver-side observation, enforcement outcome, and observation of the resulting control effect. + +An outcome-binding profile [I-D.schrock-ep-outcome-binding](#I-D.schrock-ep-outcome-binding) separates the authorization of an action from its observed effect. It binds signed observations from executors, systems of record, and independent observers to the same authorization, action digest, and operation, with exact-equality checks on the action and source bindings, plus relying-party-defined observation-window requirements. It treats a declared control domain as relying-party policy input rather than proof of independence. And it returns an indeterminate state when required evidence is missing or unauthenticated. + +A further draft [I-D.wadkins-agentproto-action-determinability](#I-D.wadkins-agentproto-action-determinability) states mechanism-independent requirements for making a claimed agent transition independently determinable after the original interaction has ended. It addresses the binding of the material action and its governing conditions, a verification procedure that establishes that those conditions actually governed the transition when it occurred, determination without requiring cooperation from an original participant whose conduct or assertion is material to the facts determined, and negative, transferred, or incomplete transitions. + +These works address related questions at specific boundaries. The discipline here can be applied to the claims made over their evidence. + +**Non-inference rules stated for a record format:** + +In the agent2agent discussion of a dimensional model for agent-protocol proposals, Blake Morrison set out rules for records carried under different extensions of one format [AP-MORRISON-RULES](#AP-MORRISON-RULES). They are related limits on inference across records and extensions. They are proposals made on a mailing list, and they are cited as independent work, not as support for this document. + +**Authentication and admissibility in evidence law:** + +Comparable distinctions appear in rules of evidence. Under the United States Federal Rules of Evidence, electronic-process records and copies of electronic data may be self-authenticated when they satisfy the conditions of Rules 902(13) and 902(14), respectively [FRE902](#FRE902). The specified certification addresses authentication; it does not by itself establish admissibility on other grounds or the reliability of the information reported. The burdens, admissibility rules, and remedies of evidence law remain outside this document's scope. + +**Assurance cases:** + +The claims-argument-evidence tradition provides structured argumentation over evidence. ISO/IEC/IEEE 15026-2 specifies requirements for assurance-case structure terminology [ISO15026-2](#ISO15026-2), and the Goal Structuring Notation community standard provides a notation for such arguments [GSN](#GSN). The presence of an assurance case or a graphical representation does not, by itself, establish that a particular evidential inference is justified. + + + +# Security Considerations + +This document specifies no new protocol mechanisms. Its subject is the prevention of a class of security failures that occur at the semantic layer: relying parties accepting claims stronger than the evidence supports. + +Cautions about the discipline itself, including its misuse: + +- The discipline does not make a dishonest or compromised evidence source honest. It bounds what a relying party should infer. It does not improve the evidence. +- The discipline does not make an evaluator correct either. Every finding is conditional on the correctness of the evaluator and of the tools and inputs it relies on. That condition is a premise of every report, whether or not the report states it. +- "Not evaluated" is not a license to discard evidence. A report that one claim was not evaluated, or is unsupported, is not a basis for setting aside evidence that positively supports another claim at its own base. The correct output is that supported claim, reported as such ([reporting](#reporting)). +- Deliberately unobservable topology is a limitation to report, not an exoneration. An interested party may arrange that its enforcement or observation points cannot be checked by anyone else. The report then says which evaluation failed or could not be made ([reporting](#reporting)). Unobservability does not support the corresponding prevention or detection-coverage guarantee, and it is not evidence of good behavior. This does not extend to every case-level finding that received evidence may support. +- Conformance vocabulary is itself inflatable. "Consistent with the claim-boundary discipline" is not a property a document or product can certify by assertion. The test is whether specific claims are bounded by specific producing boundaries, checked claim by claim. +- Detection mechanisms can leak information. Making refusals, gaps, or suppression observable to an external party discloses timing and frequency information to that party. Deployments should weigh the observability required by [topology](#topology) against what the observation channel itself reveals; RFC 6973 [RFC6973](#RFC6973) gives the model for stating that residual exposure. + + + +# IANA Considerations + +This document has no IANA actions. + +# Informative References + + + +**[SCHNEIER-KELSEY]** Bruce Schneier, John Kelsey. [Secure Audit Logs to Support Computer Forensics](https://www.schneier.com/wp-content/uploads/2016/02/paper-auditlogs.pdf). DOI 10.1145/317087.317089. May 1999. ACM Transactions on Information and System Security, Vol. 2, No. 2, pp. 159-176 + + + +**[EPA-VW-NOV]** United States Environmental Protection Agency. [Notice of Violation](https://www.epa.gov/sites/default/files/2015-10/documents/vw-nov-caa-09-18-15.pdf). . 18 September 2015. letter to Volkswagen AG, Audi AG, and Volkswagen Group of America, Inc. + + + +**[AP-LIU-DPOP]** Dapeng Liu. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/HdNkJZ48W0sg5JxK2gFkYkAK_Bs). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[ANDERSON72]** James P. Anderson. [Computer Security Technology Planning Study](https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/ande72.pdf). . October 1972. ESD-TR-73-51, Vol. II, HQ Electronic Systems Division (AFSC) + + + +**[RFC3161]** C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). RFC 3161; DOI 10.17487/RFC3161. August 2001. + + + +**[RFC3227]** D. Brezinski, T. Killalea. Guidelines for Evidence Collection and Archiving. BCP 55; RFC 3227; DOI 10.17487/RFC3227. February 2002. + + + +**[RFC3552]** E. Rescorla, B. Korver. Guidelines for Writing RFC Text on Security Considerations. BCP 72; RFC 3552; DOI 10.17487/RFC3552. July 2003. + + + +**[RFC4998]** T. Gondrom, R. Brandner, U. Pordesch. Evidence Record Syntax (ERS). RFC 4998; DOI 10.17487/RFC4998. August 2007. + + + +**[RFC5848]** J. Kelsey, J. Callas, A. Clemm. Signed Syslog Messages. RFC 5848; DOI 10.17487/RFC5848. May 2010. + + + +**[RFC6376]** D. Crocker, T. Hansen, M. Kucherawy. DomainKeys Identified Mail (DKIM) Signatures. STD 76; RFC 6376; DOI 10.17487/RFC6376. September 2011. + + + +**[RFC6962]** Ben Laurie, Adam Langley, Emilia Kasper. [Certificate Transparency](https://www.rfc-editor.org/rfc/rfc6962). RFC 6962; DOI 10.17487/RFC6962. June 2013. + + + +**[RFC6973]** A. Cooper, H. Tschofenig, B. Aboba, J. Peterson, J. Morris, M. Hansen, R. Smith. Privacy Considerations for Internet Protocols. RFC 6973; DOI 10.17487/RFC6973. July 2013. + + + +**[RFC9162]** B. Laurie, E. Messeri, R. Stradling. Certificate Transparency Version 2.0. RFC 9162; DOI 10.17487/RFC9162. December 2021. + + + +**[RFC9334]** H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan. Remote ATtestation procedureS (RATS) Architecture. RFC 9334; DOI 10.17487/RFC9334. January 2023. + + + +**[RFC9449]** D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite. OAuth 2.0 Demonstrating Proof of Possession (DPoP). RFC 9449; DOI 10.17487/RFC9449. September 2023. + + + +**[RFC9591]** D. Connolly, C. Komlo, I. Goldberg, C. A. Wood. The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures. RFC 9591; DOI 10.17487/RFC9591. June 2024. + + + +**[RFC9711]** L. Lundblade, G. Mandyam, J. O'Donoghue, C. Wallace. The Entity Attestation Token (EAT). RFC 9711; DOI 10.17487/RFC9711. April 2025. + + + +**[RFC9942]** O. Steele, H. Birkholz, A. Delignat-Lavaud, C. Fournet. CBOR Object Signing and Encryption (COSE) Receipts. RFC 9942; DOI 10.17487/RFC9942. June 2026. + + + +**[RFC9943]** H. Birkholz, A. Delignat-Lavaud, C. Fournet, Y. Deshpande, S. Lasker. An Architecture for Trustworthy and Transparent Digital Supply Chains. RFC 9943; DOI 10.17487/RFC9943. June 2026. + + + +**[I-D.sergeev-wexp-core]** Mikhail Sergeev, Vladimir Ikher. [The Witnessed Execution Protocol (WEXP): Core Specification](https://datatracker.ietf.org/doc/html/draft-sergeev-wexp-core-01). Internet-Draft draft-sergeev-wexp-core-01. 16 August 2026. + + + +**[I-D.bu-agentproto-security-principal-binding]** Songbo Bu. [Security Principal and Verifier Binding for Agent Communication Protocols](https://datatracker.ietf.org/doc/html/draft-bu-agentproto-security-principal-binding-08). Internet-Draft draft-bu-agentproto-security-principal-binding-08. 14 October 2026. + + + +**[I-D.kuehlewind-audit-architecture]** Mirja Kuehlewind, Henk Birkholz. [An Architecture for Auditing Agent Delegation and Interactions](https://datatracker.ietf.org/doc/html/draft-kuehlewind-audit-architecture-01). Internet-Draft draft-kuehlewind-audit-architecture-01. 07 September 2026. + + + +**[I-D.bradleyb-audit-decision-records]** Bradley B. [Signed Decision Records for Agent Authorization: Disclosures, Entry Emission, and Ordering Evidence](https://datatracker.ietf.org/doc/html/draft-bradleyb-audit-decision-records-00). Internet-Draft draft-bradleyb-audit-decision-records-00. 13 August 2026. + + + +**[I-D.yossif-enrollment-problem]** Mohamad Khalil Yossif. [Problem Statement: Enrollment and Key-Binding Assumptions in Execution Authority Evidence](https://datatracker.ietf.org/doc/html/draft-yossif-enrollment-problem-00). Internet-Draft draft-yossif-enrollment-problem-00. 22 July 2026. + + + +**[I-D.schrock-ep-outcome-binding]** Iman Schrock. [Outcome Binding for Authorized Actions and Independently Observed Effects](https://datatracker.ietf.org/doc/html/draft-schrock-ep-outcome-binding-00). Internet-Draft draft-schrock-ep-outcome-binding-00. 28 July 2026. + + + +**[I-D.ietf-wimse-arch]** Joseph Salowey, Yaroslav Rosomakho, Hannes Tschofenig. [Workload Identity in a Multi System Environment (WIMSE) Architecture](https://www.ietf.org/archive/id/draft-ietf-wimse-arch-08.html). Internet-Draft draft-ietf-wimse-arch-08. 06 July 2026. + + + +**[I-D.wadkins-agentproto-action-determinability]** Douglas Wadkins. [Independent Determinability of Agent Actions](https://datatracker.ietf.org/doc/draft-wadkins-agentproto-action-determinability/). Internet-Draft draft-wadkins-agentproto-action-determinability-00. 10 September 2026. + + + +**[I-D.abak-agent-control-delivery-evidence]** Ali Toygar Abak. [Evidence Requirements for Agent Control Delivery and Outcome Reconciliation](https://www.ietf.org/archive/id/draft-abak-agent-control-delivery-evidence-02.html). Internet-Draft draft-abak-agent-control-delivery-evidence-02. 11 October 2026. + + + +**[I-D.fengfar-led]** Stephen Farrell, Chong Feng. [Dealing with LLMs in IETF Discussions](https://www.ietf.org/archive/id/draft-fengfar-led-01.html). Internet-Draft draft-fengfar-led-01. 06 August 2026. + + + +**[AP-FARRELL-ABC]** Stephen Farrell. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/wrQqZW9Dh3Yj6N7gV9RcfN5R8Kk). . 29 July 2026. message to the agentproto@ietf.org mailing list + + + +**[AP-SERGEEV-GATE]** Mikhail Sergeev. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/ORdiqDGi8Fno6ROXHmSljQFmEOY/). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[AP-ECKEL]** Charles Eckel. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/dZgLXO2xr3tr8pF0yejOZhj49-0). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[AP-FARRELL-CHEAT]** Stephen Farrell. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/zDQjiJvUhMiv5EX2Jpgbdacs3eo). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[AP-SAMMARTANO]** Shawn Sammartano. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/ike9opEcHLoS6QDdkJ0SKzSA96Y). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[AP-SAMMARTANO-FRAMING]** Shawn Sammartano. [Re: DRAFT minutes from the AGENTPROTO BoF](https://mailarchive.ietf.org/arch/msg/agentproto/ALrRxQEqT6VmBd6jBTuIKETcno8). . 30 July 2026. message to the agentproto@ietf.org mailing list + + + +**[VC-DATA-MODEL]** World Wide Web Consortium. [Verifiable Credentials Data Model v2.0](https://www.w3.org/TR/2025/REC-vc-data-model-2.0-20250515/). . 15 May 2025. W3C Recommendation, Section 1.1 + + + +**[DID-CORE]** World Wide Web Consortium. [Decentralized Identifiers (DIDs) v1.0](https://www.w3.org/TR/2022/REC-did-core-20220719/). . 19 July 2022. W3C Recommendation, Sections 9.2 and 9.11 + + + +**[AP-MORRISON-RULES]** Blake Morrison. [Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates](https://mailarchive.ietf.org/arch/msg/agent2agent/bRdOV5Ou66hFkNd5kt7Wd4KqHAg/). . 04 September 2026. message to the agent2agent mailing list + + + +**[AP-SCHROCK-RETENTION]** Iman Schrock. [Re: New I-D : A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates](https://mailarchive.ietf.org/arch/msg/agent2agent/kWvHTqephUemSNjbGQWGmoZkYSU/). . 14 September 2026. message to the agent2agent mailing list + + + +**[AP-JIANG-CONTINUITY]** Yuning Jiang. [Re: draft-bu-agentproto-security-principal-binding-06 published: focused review request](https://mailarchive.ietf.org/arch/msg/agent2agent/WtvC4rdcZ4dNxjpzIm1FM0y4-0o/). . 15 September 2026. message to the agent2agent mailing list + + + +**[WITMODEL]** Mikhail A. Sergeev, Vladimir Ikher. [Toward a Witnessability Model for AI and Software Execution Systems: A Boundary-Based Framework for Classifying Execution Evidence](https://doi.org/10.5281/zenodo.21970802). . August 2026. Version 1.1, bridge revision; also at DOI 10.2139/ssrn.6994720 + + + +**[WCC-CORE]** Sergeev. Witnessability Conceptual Core 1.0. DOI 10.5281/zenodo.21865251. July 2026. + + + +**[HAMILTON]** Court of Appeal (Criminal Division), England and Wales. [Hamilton & Ors v Post Office Ltd](https://caselaw.nationalarchives.gov.uk/ewca/crim/2021/577). . 23 April 2021. [2021] EWCA Crim 577, paragraphs 136-137 + + + +**[GRENFELL2]** Grenfell Tower Inquiry. [Grenfell Tower Inquiry: Phase 2 Report, Volume 1](https://assets.publishing.service.gov.uk/media/66d817aa701781e1b341dbd3/CCS0923434692-004_GTI_Phase_2_Volume_1_BOOKMARKED.pdf). . September 2024. HC 19-I, Part 1, Chapter 2, paragraphs 2.122-2.123 + + + +**[EPA-VW]** United States Environmental Protection Agency. [Learn About Volkswagen Violations](https://www.epa.gov/vw/learn-about-volkswagen-violations). . 10 June 2026. agency overview of the Clean Air Act violations, including the Notice of Violation of 18 September 2015 + + + +**[IN-TOTO]** Santiago Torres-Arias, Hammad Afzali, Trishank Karthik Kuppusamy, Reza Curtmola, Justin Cappos. [in-toto: Providing farm-to-table guarantees for bits and bytes](https://www.usenix.org/system/files/sec19-torres-arias.pdf). . August 2019. 28th USENIX Security Symposium + + + +**[PROV-DM]** World Wide Web Consortium. [PROV-DM: The PROV Data Model, W3C Recommendation](https://www.w3.org/TR/prov-dm/). . April 2013. + + + +**[DURANTI1998]** Luciana Duranti. Diplomatics: New Uses for an Old Science. . 1998. Scarecrow Press + + + +**[INTERPARES]** Luciana Duranti. [The Long-term Preservation of Authentic Electronic Records: Findings of the InterPARES Project](https://www.interpares.org/book/index.cfm). . 2005. + + + +**[ISO14721]** International Organization for Standardization. Space Data System Practices -- Reference model for an open archival information system (OAIS). ISO 14721:2025, Edition 3. March 2025. also issued as CCSDS 650.0-M-3, December 2024 + + + +**[ISO16363]** International Organization for Standardization. Space data and information transfer systems -- Audit and certification of trustworthy digital repositories. ISO 16363:2025, Edition 2. March 2025. + + + +**[CCSDS652-1]** Consultative Committee for Space Data Systems. [Requirements for Bodies Providing Audit and Certification of Candidate Trustworthy Digital Repositories](https://ccsds.org/Pubs/652x1m3.pdf). CCSDS 652.1-M-3, Issue 3. December 2024. + + + +**[ISO15026-2]** ISO/IEC/IEEE. Systems and software engineering -- Systems and software assurance -- Part 2: Assurance case. ISO/IEC/IEEE 15026-2:2022. 2022. + + + +**[GSN]** SCSC Assurance Case Working Group. [Goal Structuring Notation Community Standard, Version 3](https://scsc.uk/scsc-141c). SCSC 141C. 2021. + + + +**[FRE902]** United States. [Federal Rules of Evidence, Rule 902(13) and Rule 902(14), with Advisory Committee Notes](https://www.govinfo.gov/content/pkg/USCODE-2024-title28/html/USCODE-2024-title28-app-federalru-dup2-rule902.htm). . December 2017. Amendments effective 1 December 2017; text in the 2024 edition of the United States Code. + + + +# The (a,b,c) scenario worked through + +In the agentproto mailing-list discussion of July 2026, in the thread on the draft minutes of the AGENTPROTO BoF, Stephen Farrell posed a gating scenario [AP-FARRELL-ABC](#AP-FARRELL-ABC). In his words: + +- If (a,b,c) is a comms path between agents (perhaps within a tree) and if 'c' is actually a newly created entity, but one that needs access to a long-term secret credential accessible at 'a' (e.g. pwd or SSH private key) and where that credential must not be exposed to 'b' nor easily abused - then how's that going to work? + +He emphasized that "the scenario I posited is one where 'b' creates 'c' and so is in a fine place to cheat" [AP-FARRELL-CHEAT](#AP-FARRELL-CHEAT). + +The list discussion produced concrete mitigations, collected in a reply by Shawn Sammartano [AP-SAMMARTANO](#AP-SAMMARTANO), who credited most of them to existing mechanisms: + +- exact, single-use, attenuated permission slips bound to request bytes; +- hardware-protected keys, and threshold signing; +- short-lived credentials, and forward-moving counters; +- delegation budgets, and delays with cancellation windows; +- approval separated from the creator. Sammartano also stated the hard case plainly: "If b builds c, then b can read c's key, so b can be c. No message format fixes that, mine included." + +The author proposed an enforcement/observation framing in response to that discussion [AP-SERGEEV-GATE](#AP-SERGEEV-GATE). The control-topology test of [topology](#topology) refines that framing by distinguishing adversary-resistant detection coverage from a particular finding made from evidence already obtained. Farrell posed the scenario. This document does not attribute the generalized test to him. Applied to the scenario: + +- Exact, single-use, attenuated authority bounds what the grant authorizes, where it is enforced. It does not establish that an action attributed to c was not performed by b, where b created or hosts c and can obtain or invoke c's signing capability (rules 2 and 6 of [noninference](#noninference)). +- A message format can carry the relevant control or evidence. It cannot create the required independence (Sections [principle](#principle) and [independence](#independence)). +- A prevention claim at that boundary needs an enforcement point b does not control and cannot circumvent. A claim that covered misbehavior cannot be concealed needs evidence b cannot forge, on a path b cannot silently prune ([topology](#topology)). Attestation and threshold signing supply such points only in deployments that actually place them outside b's control. +- What is missing in the hard case is not another field. It is a point outside b's control that either enforces or observes, and no message format creates one. + +This is narrower than solving credential custody. It makes the assurance claim and its trust boundary reviewable before a mechanism is chosen, which is what a chartering or design review needs. + + + +# Three public findings + +Three public findings state the same bounds outside agent systems, in the words of the bodies that made them. + +In the English prosecutions arising from the Post Office Horizon accounting system, the Court of Appeal found that the prosecutor "treated what was no more than a shortfall shown by an unreliable accounting system as an incontrovertible loss", and that defendants were convicted "on the basis that the Horizon data must be correct, and cash must therefore be missing, when in fact there could be no confidence as to that foundation" [HAMILTON](#HAMILTON). The load-bearing premise was the reliability of that system. The court recorded that the prosecutor was under a duty to investigate subpostmasters' claims that there were problems with it, and it found "failures of investigation and disclosure". On the reading taken here, that is the position rule 9 of [noninference](#noninference) names. The claim rested on a premise the relying party was required to test and did not adequately test. The judgment does not address what a bounded report of the same evidence would have said, and it is not cited for that part of the rule. + +In the inquiry into the Grenfell Tower fire, the panel examined the performance criteria applied in large-scale fire tests of external wall systems. Failure to meet those criteria would show a system unlikely to comply with the applicable requirement. But "the converse was not necessarily true": a system might meet the criteria and yet fail to comply with that requirement [GRENFELL2](#GRENFELL2). A bounded test result can tell against a claim in one direction without establishing it in the other. + +In the third case the test results were genuine outputs of a genuine test. Vehicles were certified against emissions standards on the strength of those results [EPA-VW-NOV](#EPA-VW-NOV). Software detected the test condition and enabled full emissions controls only then, so the vehicles "meet emissions standards in the laboratory or testing station, but during normal operation" emitted nitrogen oxides at levels up to forty times the standard [EPA-VW](#EPA-VW). The result established the behavior of the vehicle under the conditions the test applied, which was all it had ever observed. The certificate carried it to a claim about the vehicle in use (rule 11 of [noninference](#noninference)). + +These authorities reached findings within their own legal and regulatory settings. The findings are their own, and their connection to the rules stated here is this document's reading. + + + +# Changes + +This appendix is to be removed before publication as an RFC. + + + +## Changes from -01 to -02 + +- [topology](#topology) adds a Certificate Transparency example that distinguishes a signed incorporation promise, evidence of inclusion, consistency of the checked log states, detection coverage, and a particular detection. The example states its client-policy and control assumptions. +- [reporting](#reporting) distinguishes an accurate authorization-status report from the grounds that the reported result was available to or used by the decision-maker considering whether an activity may continue. It makes the reference time for current status part of the appraisal context, covers consultations that return no current answer, and leaves admission policy separate. +- [RFC6962](#RFC6962) is added alongside the existing [RFC9162](#RFC9162) reference. The Acknowledgments credit Blake Morrison's contributed CT example. The development disclosure distinguishes work on -01 from the additions in this revision. +- The evidence-law example makes the conditions and limits of self-authentication explicit. The InterPARES reference identifies its editor, the Rule 902 reference distinguishes amendment and compilation dates, and the Bu and Abak references cite updated revisions. Small wording changes clarify terminology and non-inference rules 2 and 12; CT and CA are expanded at first use. +- No protocol, record format, registry, result-code set, or new numbered non-inference rule is introduced. + + + +## Changes from -00 to -01 + +- Independence is defined once, as limits on three capabilities of a named party or coalition: forgery, concealment, and circumvention (Sections [terminology](#terminology) and [independence](#independence)). The earlier definition treated them as one property. [ceiling](#ceiling) no longer repeats the audit example, which stays in [topology](#topology). +- [terminology](#terminology) adds a note on the RATS terms. +- [principle](#principle) says in which sense this document uses "support", adds a practical test of it, and points to the routes of [constructive](#constructive). Its first bound and the abstract now name what evidence constitutes or proves, not only what it observed. +- [bases](#bases) no longer describes the bases as ordered. They are distinct questions about one action. It now points to [constructive](#constructive) for claims about an effect, and it separates the observation base from an observation in the sense used elsewhere in the document. +- [ceiling](#ceiling) speaks of kinds of claim rather than claim dimensions. +- [noninference](#noninference) adds rules 11 to 13: behavior observed under different conditions, multiplicity of sources, and the coherence of an account produced by the interested party. Rules 1 to 10 keep their numbers. Rule 2 adds attribution along a delivery path. Rule 3 no longer reads matching records as agreement between the parties. Rule 4 limits itself to the authenticity of individual records, and rule 7 to the boundary's own observation. The last sentence of rule 9 now follows the reporting terms of [reporting](#reporting). The preamble is shorter. +- [lens](#lens) revises four items: item 3 names the three capabilities, item 5 no longer says that a signature or registration supplies no evidence, item 7 asks which route of [constructive](#constructive), or which other stated basis, supports a claimed effect, and item 10 follows [reporting](#reporting). +- [constructive](#constructive) adds a route through evidence whose verification establishes a predicate. It adds a qualification on the time and finality of an observed effect, and it names as an idealization the treatment of probabilistic soundness as exact. The closing advice on deployment design is removed, because [scope-and-non-goals](#scope-and-non-goals) puts evidence design out of scope. +- [payment](#payment) ends with a sample report. +- [reporting](#reporting) separates whether an evaluation was made from what it found, and notes the related line drawn earlier in [I-D.schrock-ep-outcome-binding](#I-D.schrock-ep-outcome-binding). The status that -00 called "not established" is now "not evaluated", because the rules use "establish" for the relation between evidence and a claim. Downgrading is now a reporting practice that applies to both questions, and a claim supported at another base is a separate finding, not a downgrade. +- Sections [applicability](#applicability) and [related](#related) are shorter. The three public findings move to [findings](#findings); the Grenfell summary now follows the inquiry's wording, and the emissions summary also cites the Notice of Violation [EPA-VW-NOV](#EPA-VW-NOV). The paragraph on archival preservation moves from [related](#related) to [applicability](#applicability). The discussion of Federal Rule of Civil Procedure 37(e) and the separate paragraph on the considerations-section genre are removed. [lens](#lens) still names that genre. +- [related](#related) corrects the paraphrase of requirement DET-3: -00 omitted the qualifier that limits the cooperation clause to participants whose conduct or assertion is material. The paraphrase now follows the published wording of [I-D.wadkins-agentproto-action-determinability](#I-D.wadkins-agentproto-action-determinability). +- [related](#related) now lists all five distinctions drawn in [I-D.abak-agent-control-delivery-evidence](#I-D.abak-agent-control-delivery-evidence); -00 omitted required-target resolution. It also cites sources for the reference-monitor and tamper-evident logging lineages [ANDERSON72](#ANDERSON72) [SCHNEIER-KELSEY](#SCHNEIER-KELSEY). +- [security](#security) narrows its opening sentence, and adds that every finding is conditional on the correctness of the evaluator. The item on unobservable topology now refers to [reporting](#reporting) for the reporting terms. +- The abstract no longer names the source of the scenario. [topology](#topology), [abc](#abc), and the Acknowledgments do. + + + +# Acknowledgments + +The scenario of [abc](#abc) was posed by Stephen Farrell [AP-FARRELL-ABC](#AP-FARRELL-ABC). The mitigation list and the plain statement of the key-custody limit were collected by Shawn Sammartano [AP-SAMMARTANO](#AP-SAMMARTANO), who also confirmed the enforcement/observation framing used here [AP-SAMMARTANO-FRAMING](#AP-SAMMARTANO-FRAMING); Charles Eckel proposed that 'a' authorize 'c' to do something specific on 'a's behalf, rather than expose a long-term credential [AP-ECKEL](#AP-ECKEL). Dapeng Liu proposed sender-constrained tokens (DPoP) so that 'b' could not present a token bound to 'c's key [AP-LIU-DPOP](#AP-LIU-DPOP); [topology](#topology) discusses what they do and do not prevent. Yuning Jiang raised the continuity of an identity across restarts, instance changes, and key rotation, which is how the question behind rule 10 of [noninference](#noninference) entered this work [AP-JIANG-CONTINUITY](#AP-JIANG-CONTINUITY). The distinction itself is older and is drawn in [DID-CORE](#DID-CORE). Vladimir Ikher is the author's co-author on the earlier work [WITMODEL](#WITMODEL) from which the bases of [bases](#bases) and the ceiling of [ceiling](#ceiling) are restated here. This document also benefited from the broader agentproto and agent2agent mailing-list discussions of 2026 on evidence, delegation, and audit. The author thanks their participants without implying that any of them endorses this document. + +Douglas Wadkins reviewed a pre-submission draft; the statement of scope in [scope-and-non-goals](#scope-and-non-goals), the additions to [reporting](#reporting), and the qualification in [applicability](#applicability) are responses to his comments. + +Blake Morrison contributed the Certificate Transparency omission-control example in [topology](#topology). + + + +# Document development disclosure + +This document was drafted with substantial assistance from generative AI tools, working from the author's prior publications, specifications, and mailing-list correspondence, at the author's direction. It also incorporates material arising from adversarial review conducted with such tools: the wording of several rules, and the separation of analytical justification from documented practical confirmation stated in [noninference](#noninference), were reached that way. In -01, the treatment of independence (Sections [terminology](#terminology), [principle](#principle), [independence](#independence), and [constructive](#constructive)), rules 12 and 13 of [noninference](#noninference), and the reporting terms of [reporting](#reporting) were revised or added the same way. In this revision, the Certificate Transparency example in [topology](#topology) was edited from Blake Morrison's contribution with assistance from such tools. The authorization-status clarification in [reporting](#reporting) was also developed with such assistance. The author is responsible for this document's content, citations, and attributions. The use of large language models (LLMs) in IETF discussions is the subject of [I-D.fengfar-led](#I-D.fengfar-led), which explicitly excludes Internet-Draft and RFC text from its scope. This disclosure is voluntary. + +The author also has an implementation interest in this area: the WEXP appraisal layer [I-D.sergeev-wexp-core](#I-D.sergeev-wexp-core) is the author's own work. This document is usable independently of it. No organizational independence between the two works is claimed. diff --git a/tests/test_release.py b/tests/test_release.py new file mode 100644 index 0000000..bd8a33b --- /dev/null +++ b/tests/test_release.py @@ -0,0 +1,110 @@ +"""Release safety tests; no network calls or GitHub writes. +SPDX-License-Identifier: BSD-3-Clause +""" +import hashlib +import importlib.util +from pathlib import Path +import unittest +from unittest.mock import patch + +ROOT = Path(__file__).resolve().parents[1] +spec = importlib.util.spec_from_file_location("release_tools", ROOT / "tools/release.py") +release = importlib.util.module_from_spec(spec) +spec.loader.exec_module(release) + + +class ReleaseTests(unittest.TestCase): + def setUp(self): + self.tag = release.BASE + "-00" + self.sha = "a" * 40 + self.xml = f''.encode() + self.files = {self.tag + ".xml": self.xml, self.tag + ".txt": b"Published test fixture\n"} + self.sums = "".join(hashlib.sha256(data).hexdigest() + " " + name + "\n" for name, data in self.files.items()).encode() + + def test_identifiers(self): + self.assertEqual(release.identifiers("00", self.sha), self.tag) + + def test_bad_revisions(self): + for value in ("0", "-00", "000", "../00", "00;echo bad", "١٢"): + with self.subTest(value=value), self.assertRaises(ValueError): + release.identifiers(value, self.sha) + + def test_exact_commit_required(self): + for value in ("main", "HEAD", "a" * 39, "A" * 40, "x" * 40): + with self.subTest(value=value), self.assertRaises(ValueError): + release.identifiers("00", value) + + def test_snapshot(self): + release.verify_snapshot(self.tag, self.files, self.sums) + + def test_real_historical_archives_preserved(self): + for revision in ("00", "01", "02"): + tag = release.BASE + "-" + revision + directory = ROOT / "published" / revision + files = {tag + "." + ext: (directory / (tag + "." + ext)).read_bytes() for ext in ("xml", "txt")} + with self.subTest(revision=revision): + release.verify_snapshot(tag, files, (directory / "SHA256SUMS").read_bytes()) + + def test_wrong_document(self): + xml = self.xml.replace(b"-00", b"-01") + files = dict(self.files, **{self.tag + ".xml": xml}) + with self.assertRaises(ValueError): + release.verify_snapshot(self.tag, files, self.sums) + + def test_mutated_archive(self): + files = dict(self.files, **{self.tag + ".txt": b"Changed\n"}) + with self.assertRaises(ValueError): + release.verify_snapshot(self.tag, files, self.sums) + + def test_duplicate_missing_or_extra_checksums(self): + for sums in (self.sums + self.sums, b"", self.sums + b"0" * 64 + b" extra.txt\n"): + with self.subTest(sums=sums), self.assertRaises(ValueError): + release.verify_snapshot(self.tag, self.files, sums) + + def test_external_entity(self): + xml = b']>' + self.xml + with self.assertRaises(ValueError): + release.verify_snapshot(self.tag, dict(self.files, **{self.tag + ".xml": xml}), self.sums) + + def test_matching_tag(self): + with patch.object(release, "api", return_value={"object": {"type": "commit", "sha": self.sha}}): + release.check_tag(self.tag, self.sha, required=True) + + def test_tag_must_not_move(self): + with patch.object(release, "api", return_value={"object": {"type": "commit", "sha": "b" * 40}}): + with self.assertRaises(ValueError): + release.check_tag(self.tag, self.sha) + + def test_annotated_tag(self): + with patch.object(release, "api", side_effect=[{"object": {"type": "tag", "sha": "c" * 40}}, {"object": {"type": "commit", "sha": self.sha}}]): + release.check_tag(self.tag, self.sha, required=True) + + def test_archive_response(self): + name = self.tag + ".xml" + with patch.object(release.urllib.request, "urlopen") as opened: + response = opened.return_value.__enter__.return_value + response.status = 200 + response.geturl.return_value = "https://www.ietf.org/archive/id/" + name + response.read.return_value = self.xml + self.assertEqual(release.official_bytes(name), self.xml) + + def test_bad_archive_response(self): + name = self.tag + ".xml" + for url, status, data in ( + ("https://example.invalid/archive/id/" + name, 200, self.xml), + ("http://www.ietf.org/archive/id/" + name, 200, self.xml), + ("https://www.ietf.org/archive/id/wrong.xml", 200, self.xml), + ("https://www.ietf.org/archive/id/" + name, 404, self.xml), + ("https://www.ietf.org/archive/id/" + name, 200, b""), + ("https://www.ietf.org/archive/id/" + name, 200, b"x" * (release.LIMIT + 1)), + ): + with self.subTest(url=url, status=status, size=len(data)), patch.object(release.urllib.request, "urlopen") as opened: + response = opened.return_value.__enter__.return_value + response.status, response.geturl.return_value, response.read.return_value = status, url, data + with self.assertRaises(ValueError): + release.official_bytes(name) + + +if __name__ == "__main__": + unittest.main() + diff --git a/tests/test_tools.py b/tests/test_tools.py new file mode 100644 index 0000000..016b8b0 --- /dev/null +++ b/tests/test_tools.py @@ -0,0 +1,131 @@ +"""Editorial-tool regressions, not protocol conformance tests. +SPDX-License-Identifier: BSD-3-Clause +""" +import importlib.util +from pathlib import Path +import shutil +import tempfile +import unittest +import xml.etree.ElementTree as ET + +ROOT = Path(__file__).resolve().parents[1] +spec = importlib.util.spec_from_file_location("draft_tools", ROOT / "tools/draft.py") +tools = importlib.util.module_from_spec(spec) +spec.loader.exec_module(tools) + + +class EditorialTools(unittest.TestCase): + @classmethod + def setUpClass(cls): + cls.data = tools.SOURCE.read_bytes() + + def test_current_source(self): + self.assertEqual(tools.parse_source(self.data).get("version"), "3") + + def test_archive(self): + tools.verify_archive() + + def test_archive_mutation_rejected(self): + with tempfile.TemporaryDirectory() as temporary: + copy = Path(temporary) / "00" + shutil.copytree(tools.ARCHIVES, copy) + file = copy / "00" / next(iter(tools.POSTED["00"])) + file.write_bytes(file.read_bytes() + b"\n") + with self.assertRaises(ValueError): + tools.verify_archive(copy) + + def test_checksum_mutation_rejected(self): + with tempfile.TemporaryDirectory() as temporary: + copy = Path(temporary) / "00" + shutil.copytree(tools.ARCHIVES, copy) + (copy / "02" / "SHA256SUMS").write_text("bogus\n") + with self.assertRaises(ValueError): + tools.verify_archive(copy) + + def test_wrong_identity_rejected(self): + with self.assertRaises(ValueError): + tools.parse_source(self.data.replace(tools.BASE.encode(), b"draft-other", 1)) + + def test_external_entity_rejected(self): + with self.assertRaises(ValueError): + tools.parse_source(b']>' + self.data) + + def test_xinclude_rejected(self): + node = ET.fromstring(self.data) + ET.SubElement(node, "{http://www.w3.org/2001/XInclude}include", {"href": "file.xml"}) + with self.assertRaises(ValueError): + tools.parse_source(ET.tostring(node)) + + def test_local_source_rejected(self): + node = ET.fromstring(self.data) + ET.SubElement(node, "artwork", {"src": "file.xml"}) + with self.assertRaises(ValueError): + tools.parse_source(ET.tostring(node)) + + def test_duplicate_anchor_rejected(self): + node = ET.fromstring(self.data) + anchor = next(e.get("anchor") for e in node.iter() if e.get("anchor")) + ET.SubElement(node, "section", {"anchor": anchor}) + with self.assertRaises(ValueError): + tools.parse_source(ET.tostring(node)) + + def test_missing_xref_rejected(self): + node = ET.fromstring(self.data) + ET.SubElement(node, "xref", {"target": "missing-anchor"}) + with self.assertRaises(ValueError): + tools.parse_source(ET.tostring(node)) + + def test_working_revision_can_advance(self): + original = ET.fromstring(self.data) + original.set("docName", tools.BASE + "-03") + self.assertTrue(tools.parse_source(ET.tostring(original)).get("docName").endswith("-03")) + + def test_reading_copy_matches(self): + self.assertEqual(tools.READING.read_text(), tools.render_reading(self.data)) + + def test_reading_copy_includes_every_section_and_reference(self): + root = ET.fromstring(self.data) + reading = tools.render_reading(self.data) + for node in root.iter(): + if node.tag in ("section", "reference") and node.get("anchor"): + self.assertIn(f'id="{node.get("anchor")}"', reading) + for details in root.iter("refcontent"): + self.assertIn(tools.inline(details), reading) + + def test_reading_copy_preserves_definition_terms_and_nested_definitions(self): + root = ET.fromstring(self.data) + reading = tools.render_reading(self.data) + for term in root.iter("dt"): + self.assertIn("**" + " ".join(tools.inline(term).split()) + "**", reading) + sample = ET.fromstring('
Outer
Meaning.
Inner
Detail.
') + rendered = tools.block(sample) + for text in ("**Outer**", "Meaning.", "**Inner**", "Detail."): + self.assertIn(text, rendered) + + def test_missing_historical_revision_rejected(self): + with tempfile.TemporaryDirectory() as temporary: + copy = Path(temporary) / "published" + shutil.copytree(tools.ARCHIVES, copy) + shutil.rmtree(copy / "01") + with self.assertRaises(ValueError): + tools.verify_archive(copy) + + def test_artwork_indentation(self): + node = ET.fromstring(" A\n |\n B") + self.assertEqual(tools.block(node), "```text\n A\n |\n B\n```\n\n") + + def test_reference_section(self): + node = ET.fromstring('') + paragraph = ET.Element("t") + paragraph.append(node) + self.assertIn("Section 12.2 of [RFC9334](#RFC9334)", tools.block(paragraph)) + + def test_no_published_claim_in_reading_copy(self): + reading = tools.render_reading(self.data) + self.assertIn("not a separate IETF publication", reading) + self.assertIn(tools.sha256(self.data), reading) + + +if __name__ == "__main__": + unittest.main() + diff --git a/tools/draft.py b/tools/draft.py new file mode 100644 index 0000000..96b08a8 --- /dev/null +++ b/tools/draft.py @@ -0,0 +1,285 @@ +#!/usr/bin/env python3 +"""Small editorial helpers. RFCXML validation/rendering is delegated to xml2rfc. + +No online idnits, rights attestation, submission, or protocol conformance claim. +SPDX-License-Identifier: BSD-3-Clause +""" +from __future__ import annotations + +import argparse +import difflib +import hashlib +import html +import importlib.metadata +import json +from pathlib import Path +import re +import shutil +import subprocess +import sys +import tempfile +import xml.etree.ElementTree as ET + +ROOT = Path(__file__).resolve().parents[1] +BASE = "draft-sergeev-claim-boundaries" +SOURCE = ROOT / (BASE + ".xml") +READING = ROOT / "review/editor-copy.md" +BASELINE = "02" +ARCHIVES = ROOT / "published" +ARCHIVE = ARCHIVES / BASELINE +POSTED = { + "00": { + BASE + "-00.xml": "640d2f2804cd2d7aeb495ed1294a03908906aa10b6e8bfd1d848b73e97ee5076", + BASE + "-00.txt": "6167510091e13a39e8f3116091f5207d69b0da6a7bd0b550e0372b68c8a88b59", + }, + "01": { + BASE + "-01.xml": "d59d0e4a85bff662a8f13c34cb1eb1297f2140a62a130ddd2fdedbbdcece0829", + BASE + "-01.txt": "0d90638366325bbacb368e9d1fd256f7a6117831ff31e10cb49d1b40e8446d35", + }, + "02": { + BASE + "-02.txt": "67d93ac09bd572bb01b5e00c3101daa6ee3a2217f5e23d2bb02658d6a731ccc0", + BASE + "-02.xml": "d6d01ebc5d446991a2a4e65497171adaf4b37637d9bd36c5c017be6490b622b7", + }, +} + + +def sha256(data: bytes) -> str: + return hashlib.sha256(data).hexdigest() + + +def parse_source(data: bytes) -> ET.Element: + if re.search(br" str: + if element is None: + return "" + result = html.escape(element.text or "", quote=False) + for child in element: + value = inline(child) + if child.tag in ("strong", "em", "tt"): + marker = {"strong": "**", "em": "*", "tt": "`"}[child.tag] + value = marker + value + marker + elif child.tag == "xref": + target = child.attrib["target"] + value = f"[{value or target}](#{target})" + if child.get("section"): + value = f"Section {child.get('section')} of {value}" + elif child.tag == "eref": + target = child.attrib["target"] + value = f"[{value or target}]({target})" + result += value + html.escape(child.tail or "", quote=False) + return result + + +def block(element: ET.Element, level: int = 1) -> str: + tag = element.tag + if tag == "section": + anchor = html.escape(element.get("anchor", ""), quote=True) + heading = f'\n\n' if anchor else "" + heading += "#" * min(level, 6) + " " + inline(element.find("name")) + "\n\n" + return heading + "".join(block(c, level + 1) for c in element if c.tag != "name") + if tag == "t": + return " ".join(inline(element).split()) + "\n\n" + if tag == "dl": + return "".join(block(child, level) for child in element) + if tag == "dt": + return "**" + " ".join(inline(element).split()) + "**\n\n" + if tag == "dd": + return ("".join(block(child, level) for child in element) + if len(element) else inline(element).strip() + "\n\n") + if tag in ("ul", "ol"): + lines = [] + for index, item in enumerate(element.findall("li"), 1): + value = "".join(block(c, level) for c in item).strip() or inline(item).strip() + prefix = f"{index}. " if tag == "ol" else "- " + lines.append(prefix + value.replace("\n", "\n ")) + return "\n".join(lines) + "\n\n" + if tag in ("artwork", "sourcecode"): + return "```text\n" + (element.text or "").strip("\n") + "\n```\n\n" + if tag == "blockquote": + return "\n".join("> " + line for line in "".join(block(c, level) for c in element).strip().splitlines()) + "\n\n" + if tag == "table": + rows = [] + for index, row in enumerate(element.findall(".//tr")): + cells = [" ".join(inline(c).split()).replace("|", r"\|") for c in row] + rows.append("| " + " | ".join(cells) + " |") + if index == 0: + rows.append("| " + " | ".join("---" for _ in cells) + " |") + return "\n".join(rows) + "\n\n" + if tag == "references": + return "# Informative References\n\n" + "".join(block(c) for c in element if c.tag == "reference") + if tag == "reference": + anchor = element.attrib["anchor"] + front = element.find("front") + if front is None: + raise ValueError("Reference has no front matter") + authors = ", ".join(a.get("fullname") or a.get("surname") or inline(a.find("organization")) for a in front.findall("author")) + date = front.find("date") + when = " ".join(date.get(k, "") for k in ("day", "month", "year")).strip() if date is not None else "" + title = inline(front.find("title")) + if element.get("target"): + title = f"[{title}]({element.get('target')})" + series = "; ".join(c.get("name", "") + " " + c.get("value", "") for c in element.findall("seriesInfo")) + details = " ".join(inline(c) for c in element.findall("refcontent")) + return f'\n\n**[{anchor}]** {authors}. {title}. {series}. {when}. {details}\n\n' + return "".join(block(c, level) for c in element) + + +def render_reading(data: bytes) -> str: + root = parse_source(data) + front = root.find("front") + assert front is not None + out = "# " + inline(front.find("title")) + "\n\n" + out += "**Generated editor's reading copy, not a separate IETF publication.**\n\n" + out += f"Source SHA-256: `{sha256(data)}`. Edit the [RFCXML](../{BASE}.xml), not this file.\n\n" + out += f"[Published -{BASELINE}](https://datatracker.ietf.org/doc/{BASE}/{BASELINE}/) · [Publication history](../published/README.md) · [Contributing](../CONTRIBUTING.md)\n\n" + abstract = front.find("abstract") + if abstract is not None: + out += "## Abstract\n\n" + block(abstract) + for note in front.findall("note"): + out += "## " + inline(note.find("name")) + "\n\n" + out += "".join(block(c) for c in note if c.tag != "name") + for part in ("middle", "back"): + element = root.find(part) + if element is not None: + out += block(element) + return out.rstrip() + "\n" + + +def verify_archive(directory: Path = ARCHIVES) -> None: + revisions = {p.name for p in directory.iterdir() if p.is_dir()} + if revisions != set(POSTED): + raise ValueError("Published revision inventory differs from the pinned inventory") + for revision, files in POSTED.items(): + folder = directory / revision + actual = {p.name for p in folder.iterdir() if p.suffix in (".xml", ".txt")} + if actual != set(files): + raise ValueError("Published file inventory differs: " + revision) + checks = [] + for name, expected in files.items(): + if sha256((folder / name).read_bytes()) != expected: + raise ValueError("Published snapshot changed: " + name) + checks.append(f"{expected} {name}\n") + if (folder / "SHA256SUMS").read_bytes() != "".join(checks).encode("ascii"): + raise ValueError("Published checksum list changed: " + revision) + + +def check() -> None: + data = SOURCE.read_bytes() + root = parse_source(data) + verify_archive() + if READING.read_text(encoding="utf-8") != render_reading(data): + raise ValueError("Reading copy is stale: run make review") + print(f"PASS: source identity {root.get('docName')}, anchors/xrefs, published hashes, and reading copy") + print("This is not a grammar, semantic, rights, online-reference, or conformance verdict.") + + +def build() -> None: + check() + expected = (ROOT / "requirements.txt").read_text().strip().removeprefix("xml2rfc==") + actual = importlib.metadata.version("xml2rfc") + if actual != expected: + raise ValueError(f"Expected xml2rfc {expected}, got {actual}; install requirements.txt") + formatter = shutil.which("xml2rfc") + if formatter is None: + raise RuntimeError("xml2rfc command is missing; install requirements.txt") + data = SOURCE.read_bytes() + name = parse_source(data).attrib["docName"] + output = ROOT / "build" + output.mkdir(exist_ok=True) + # Invalidate a previous success record before any fallible rendering. + manifest = output / "build.json" + manifest.unlink(missing_ok=True) + artifacts = {} + with tempfile.TemporaryDirectory(prefix="cbee-render-") as temporary: + temporary = Path(temporary) + for ext, flag in (("txt", "--text"), ("html", "--html")): + copies = [] + for attempt in (1, 2): + destination = temporary / str(attempt) / f"{name}.{ext}" + destination.parent.mkdir(exist_ok=True) + command = [formatter, str(SOURCE), flag, "--no-network", "--skip-config-files", "--out", str(destination)] + result = subprocess.run(command, cwd=ROOT, capture_output=True, text=True, timeout=180) + (output / f"xml2rfc-{ext}-{attempt}.log").write_text( + "$ " + " ".join(command) + "\n\n" + result.stdout + "\n" + result.stderr, + encoding="utf-8") + if result.returncode != 0: + raise RuntimeError(f"xml2rfc failed for {ext}; see build log") + copies.append(destination.read_bytes()) + if copies[0] != copies[1]: + raise RuntimeError(f"Repeated {ext} build differs in this environment") + (output / f"{name}.{ext}").write_bytes(copies[0]) + artifacts[f"{name}.{ext}"] = sha256(copies[0]) + (output / f"{name}.xml").write_bytes(data) + artifacts[f"{name}.xml"] = sha256(data) + old = (ARCHIVE / (BASE + "-02.xml")).read_text(encoding="utf-8") + new = data.decode("utf-8") + diff = "".join(difflib.unified_diff(old.splitlines(True), new.splitlines(True), fromfile="published/-02.xml", tofile="working.xml")) + (output / "diff-from-02.txt").write_text(diff or "No source changes: working XML matches published -02 byte-for-byte.\n", encoding="utf-8") + comparison = difflib.HtmlDiff(wrapcolumn=110).make_file(old.splitlines(), new.splitlines(), "Published -02", "Working XML", context=True, numlines=3) + (output / "diff-from-02.html").write_text(comparison, encoding="utf-8") + try: + commit = subprocess.check_output(["git", "rev-parse", "HEAD"], cwd=ROOT, text=True, stderr=subprocess.DEVNULL).strip() + except (OSError, subprocess.CalledProcessError): + commit = None + report = { + "scope": "Official RFCXML rendering and same-environment repeat; not online idnits or semantic validation", + "git_commit": commit, "document": name, "source_sha256": sha256(data), + "formatter": "xml2rfc", "formatter_version": actual, "python": sys.version.split()[0], + "same_environment_repeat": True, "outputs": artifacts, + "source_matches_published_02": data == (ARCHIVE / (BASE + "-02.xml")).read_bytes(), + "txt_matches_published_02": artifacts[name + ".txt"] == POSTED[BASELINE][BASE + "-02.txt"], + "submission_performed": False, + } + manifest.write_text(json.dumps(report, indent=2) + "\n", encoding="utf-8") + (output / "SHA256SUMS").write_text("".join(f"{digest} {file}\n" for file, digest in sorted(artifacts.items())), encoding="utf-8") + (output / "index.html").write_text( + 'CBEE editor build' + '

CBEE editor build

This is a generated working copy, not a separate IETF publication.

' + f'

Commit: {html.escape(commit or "uncommitted local build")}
Source SHA-256: {sha256(data)}

' + f'

Read HTML · TXT · XML

' + f'

Source diff from -02 · Published IETF -{BASELINE}

' + '

Build success is not proof of model correctness or IETF endorsement.

\n', encoding="utf-8") + print(json.dumps(report, indent=2)) + + +def main() -> int: + parser = argparse.ArgumentParser(description=__doc__) + parser.add_argument("command", choices=("review", "check", "build")) + args = parser.parse_args() + try: + if args.command == "review": + READING.parent.mkdir(exist_ok=True) + READING.write_text(render_reading(SOURCE.read_bytes()), encoding="utf-8") + print(READING.relative_to(ROOT)) + elif args.command == "check": + check() + else: + build() + except (OSError, ValueError, RuntimeError, ET.ParseError, importlib.metadata.PackageNotFoundError, subprocess.SubprocessError) as exc: + print(f"FAIL: {exc}", file=sys.stderr) + return 1 + return 0 + + +if __name__ == "__main__": + raise SystemExit(main()) + diff --git a/tools/release.py b/tools/release.py new file mode 100644 index 0000000..4c910c0 --- /dev/null +++ b/tools/release.py @@ -0,0 +1,181 @@ +#!/usr/bin/env python3 +"""Mirror an already posted I-D as a GitHub Release; never submit to IETF. + +SPDX-License-Identifier: BSD-3-Clause +""" +from __future__ import annotations +import argparse +import hashlib +import json +from pathlib import Path +import re +import subprocess +import tempfile +import urllib.parse +import urllib.request +import xml.etree.ElementTree as ET + +ROOT = Path(__file__).resolve().parents[1] +REPO = "Witnessability/cbee-spec" +BASE = "draft-sergeev-claim-boundaries" +LIMIT = 3_000_000 +LEGACY_XML_SHA256 = { + "640d2f2804cd2d7aeb495ed1294a03908906aa10b6e8bfd1d848b73e97ee5076", + "d59d0e4a85bff662a8f13c34cb1eb1297f2140a62a130ddd2fdedbbdcece0829", +} + + +def run(*args: str) -> str: + return subprocess.check_output(args, cwd=ROOT, text=True, stderr=subprocess.PIPE, timeout=120).strip() + + +def identifiers(revision: str, commit: str) -> str: + if not re.fullmatch(r"[0-9]{2}", revision): + raise ValueError("Revision must be two digits, such as 00") + if not re.fullmatch(r"[0-9a-f]{40}", commit): + raise ValueError("Use the full, lowercase 40-character source commit SHA") + return BASE + "-" + revision + + +def verify_snapshot(tag: str, files: dict[str, bytes], sums: bytes) -> None: + expected = {tag + ".xml", tag + ".txt"} + if set(files) != expected: + raise ValueError("Archive must contain exactly this revision's XML and TXT") + source = files[tag + ".xml"] + # Only the exact official -00/-01 bytes may carry their original internal + # DTD (four numeric character entities). Never accept a new/modified DTD. + if (re.search(br" bytes: + url = "https://www.ietf.org/archive/id/" + name + req = urllib.request.Request(url, headers={"User-Agent": "cbee-github-release/1"}) + with urllib.request.urlopen(req, timeout=30) as response: + final = urllib.parse.urlsplit(response.geturl()) + if (response.status != 200 or final.scheme != "https" + or final.netloc not in {"www.ietf.org", "ietf.org"} + or final.path != "/archive/id/" + name or final.query or final.fragment): + raise ValueError("Unexpected official archive response") + data = response.read(LIMIT + 1) + if not data or len(data) > LIMIT: + raise ValueError("Empty or oversized archive response") + return data + + +def api(endpoint: str, missing_ok: bool = False): + command = ["gh", "api", "--hostname", "github.com", f"repos/{REPO}/{endpoint}"] + result = subprocess.run(command, cwd=ROOT, capture_output=True, text=True, timeout=120) + if result.returncode: + if missing_ok and "(HTTP 404)" in result.stderr: + return None + raise RuntimeError("GitHub request failed: " + result.stderr.strip()) + return json.loads(result.stdout) + + +def check_tag(tag: str, commit: str, required: bool = False) -> None: + ref = api("git/ref/tags/" + tag, missing_ok=not required) + if ref is None: + return + obj = ref["object"] + for _ in range(4): + if obj["type"] != "tag": + break + obj = api("git/tags/" + obj["sha"])["object"] + if obj.get("type") != "commit" or obj.get("sha") != commit: + raise ValueError("Existing tag points elsewhere; it will not be moved") + + +def publish(tag: str, commit: str, files: dict[str, bytes], out: Path) -> dict: + check_tag(tag, commit) + existing = api("releases/tags/" + tag, missing_ok=True) + if existing is None: + latest = api("releases/latest", missing_ok=True) + later = latest and re.fullmatch(re.escape(BASE) + r"-[0-9]{2}", latest.get("tag_name", "")) + latest_flag = "--latest=false" if later and latest["tag_name"] > tag else "--latest" + run("gh", "release", "create", tag, "--repo", REPO, "--target", commit, + "--title=-" + tag[-2:], "--notes-file", str(out / "release-notes.md"), + latest_flag, *(str(out / name) for name in files)) + record = api("releases/tags/" + tag) + check_tag(tag, commit, required=True) + if (record["draft"] or record["prerelease"] or record["tag_name"] != tag + or record["name"] != "-" + tag[-2:]): + raise ValueError("Release metadata differs; nothing will be overwritten") + assets = record["assets"] + if len(assets) != len(files) or {a["name"] for a in assets} != set(files): + raise ValueError("Release assets differ; inspect the release without overwriting it") + with tempfile.TemporaryDirectory(prefix="cbee-release-readback-") as temporary: + run("gh", "release", "download", tag, "--repo", REPO, "--dir", temporary) + for name, data in files.items(): + if (Path(temporary) / name).read_bytes() != data: + raise ValueError("Downloaded release asset differs: " + name) + return {"url": record["html_url"], "id": record["id"], "tag": tag, + "commit": commit, "assets_verified": True, "created": existing is None} + + +def main() -> None: + parser = argparse.ArgumentParser(description=__doc__) + parser.add_argument("--revision", required=True) + parser.add_argument("--commit", required=True) + parser.add_argument("--notes", default="") + parser.add_argument("--publish", action="store_true", help="Create the GitHub Release after verification") + args = parser.parse_args() + tag = identifiers(args.revision, args.commit) + out = ROOT / "build/release" / args.revision + out.mkdir(parents=True, exist_ok=True) + report_path = out / "verification.json" + report_path.unlink(missing_ok=True) + # The archive commit must belong to the checked-out public main history. + run("git", "merge-base", "--is-ancestor", args.commit, "HEAD") + def at(path: str) -> bytes: + return subprocess.check_output(["git", "show", args.commit + ":" + path], cwd=ROOT, timeout=30) + folder = "published/" + args.revision + "/" + files = {tag + "." + ext: at(folder + tag + "." + ext) for ext in ("xml", "txt")} + sums = at(folder + "SHA256SUMS") + verify_snapshot(tag, files, sums) + for name, data in files.items(): + if official_bytes(name) != data: + raise ValueError("IETF archive differs from the selected snapshot: " + name) + files["SHA256SUMS"] = sums + for name, data in files.items(): + (out / name).write_bytes(data) + intro = args.notes.strip() or "Published IETF revision -" + args.revision + "." + notes = (intro + f"\n\n[Published Internet-Draft](https://datatracker.ietf.org/doc/{BASE}/{args.revision}/)" + + f" · [Official XML](https://www.ietf.org/archive/id/{tag}.xml)" + + f" · [Official TXT](https://www.ietf.org/archive/id/{tag}.txt)\n\n" + + "The attached XML and TXT match the IETF archive byte-for-byte; SHA256SUMS covers both.\n" + + f"\nArchive commit: `{args.commit}`. Exact historical files are under `published/{args.revision}/`.\n\n" + + "This tag records the public archive import; it does not reconstruct the original private editing history. " + + "The root XML remains the current working source and may have a different revision.\n\n" + + "This GitHub release records an existing individual Internet-Draft publication. " + + "It is not a new IETF submission, a working-group adoption, or an IETF consensus statement.\n") + (out / "release-notes.md").write_text(notes, encoding="utf-8") + report = {"tag": tag, "archive_commit": args.commit, "ietf_archive_matches": True, + "ietf_submission_performed": False, + "sha256": {name: hashlib.sha256(data).hexdigest() for name, data in files.items()}} + if args.publish: + report["github_release"] = publish(tag, args.commit, files, out) + report_path.write_text(json.dumps(report, indent=2) + "\n", encoding="utf-8") + print(json.dumps(report, indent=2)) + + +if __name__ == "__main__": + main() +