Executable review

draft-hawkins-scitt-attested-agent-payment-01 — Attested Payment Authorization for Autonomous Agents

What this is

Executable evidence produced during a re-verification of draft-hawkins-scitt-attested-agent-payment, whose -01 revision adopted the eight blocking findings of a review of its -00. The document publishes no test vectors, so the checks below were written from the published specification to test its grammar, its sequencing rules and the wire definitions its own text makes load-bearing.

The text under test is the rendered -01, sha256 9e6deb7c735a5f776809e3e1431c7e67e1ecc664ab2c0a94895d51778f4080a7. The recorded outputs were reproduced byte for byte on a second reviewer-operated Linux x86_64 machine under a different Python version, and independently by the document’s author on a third platform.

This is not an implementation of the profile. It is a set of checks against it.

Result

The eight blocking items raised against -00 are substantially adopted in -01: key binding, key attributes and freshness, code identity and mediation, the separation of issuance-time from transaction-time evidence, the aggregate bound, instruction identity, constraint consumption, and supersession with issuer verification. Where an item closed, it is named as closed.

Reissuance can restart the aggregate allowance. Two of the adopted corrections compose badly. The aggregate is evaluated against an enumeration the executor maintains per scope, and the scope digest changes whenever a reissuance changes any scope member, including a refreshed expiry, while the subject of the authorization sequence stays constant. The sequence continues; the accounting starts over. Section 6 recommends reissuance in preference to long lifetimes, so the path is the recommended one: exercising it, the sequencing model registers twenty-four hourly reissues in one sequence and settles 1,200,000 inside the twenty-four hour window of a 50,000 aggregate, in payments each within the per-payment bound, with the per-payment bound and the aggregate predicate of Check 6 passing for every settlement. The question the text has to answer is whether an aggregate bound belongs to the individual scope or to the authorization sequence. The converse construction shows the same question from the other side: identical scope bytes can appear as a reissuance in one sequence and as the initial scope of another, both registrations conformant, and the text does not say whether the two share one accounting state.

Four load-bearing values have no interoperable definition. The scope digest is computed over prescribed deterministic-CBOR bytes, but no hash function is named for it; the only normative SHA-256 in the document fixes the key thumbprint. The subject claim is said to be the scope digest, while the architecture's normative grammar types that claim as text and the profile specifies no textual representation for the digest. The sequence number is required to exist and to be monotonic, with no claim or member label, no type, no encoding, and no stated result for two statements carrying the same number. The execution digest names its four fields but no hash function, no serialization and no timestamp precision, so the recomputation it promises to any party holding the payment's terms is not yet defined; and the payment intent identifier, introduced elsewhere to distinguish payment instructions, is absent from those fields, so two distinct payments differing only in that identifier have identical digest inputs.

One normative contradiction in the definition of limits. The prose defining the minimum contents of limits requires a per-payment amount and an aggregate over a stated window; another member permits scopes whose limits carry only a per-payment bound; the published grammar follows the second reading. Two independent implementations of the same bytes can disagree on whether a scope is valid at all. One consequence resolves with it: a per-payment-only scope carries no executor member, and the replay rule binds one executor, so the same signed instruction handed to two executors settles twice with each executor conformant.

Two grammar gaps the CDDL does not enforce. The grammar accepts an aggregate bound without the window the prose requires with it, and without the executor member the prose makes required in that case. Both are expressible in CDDL by group choice, so both are repairable rather than limits of the language.

Both pre-declared semantic targets came back clean. The subject stays constant across reissuance and revocation under every conformant scenario exercised, including inverted registration order; and a signed but position-less answer cannot be treated as a determinate absence of supersession. The first is clean at the semantic level and qualified by the wire gaps above. The second is clean, with one editorial suggestion: the outcome for a service that does not advertise supersession queries is obtained compositionally rather than stated.

The absence of test vectors is recorded as a recommendation rather than as a finding. A specification can be fully defined without executable examples; the recommendation is that a grammar described as an algorithm's input contract ships something to exercise it against.

Review: sent to the SCITT mailing list on 18 August 2026. Read the review →

Files

Every file below is listed in SHA256SUMS. Download the whole set into one directory and run sha256sum -c SHA256SUMS to confirm integrity; the manifest lists plain file names, with no paths.

Download all evidence (.zip) — the bundle sent with the review, containing the eight artifacts and their manifest.

How to re-verify

All three checks can be rerun from the files published here. No unpublished author-side material is required.

pip install cbor2==6.1.4 pycddl==0.6.4
python3 check_cddl_v3.py       | cmp - check_cddl_v3.out
python3 check_sequencing_v4.py | cmp - check_sequencing_v4.out
python3 check_wire_v2.py       | cmp - check_wire_v2.out

Three silent exits mean the recorded outputs reproduce byte for byte. The outputs published here were produced under Python 3.12.3 and reproduced under Python 3.14.4; the checks depend on the deterministic CBOR encoding and on the CDDL validator, not on the interpreter version.

Nothing beyond SHA-256 and OpenTimestamps is needed for the integrity of the set itself:

sha256sum -c SHA256SUMS
ots verify SHA256SUMS.ots

Provenance and limits

The checks were written from the published text. Where the document could not be resolved without asking its author, the ambiguity is reported as a finding rather than resolved by asking; the four wire gaps above are that rule applied four times.

The harness declares its own choices where the text makes none, and two of those declarations are themselves findings. It hashes the prescribed deterministic-CBOR bytes with SHA-256 because a digest is needed to run at all, and the text names no function for that digest. It keys its accounting enumeration by scope digest, which is a model of what the text requires per scope rather than something the text prescribes.

What the harness exercises is stated where it matters. It models the aggregate-accounting predicate and the per-payment bound, not the full nine-check settlement procedure, and its output says so. The counting consequence of two payments sharing one execution digest is recorded as an ambiguity, because whether an enumeration preserves repeated identical digests is not specified; it is not reported as a demonstrated undercount. The sequence-number gap has nothing executable in it and is recorded from the text alone.

The packaged reproduction was performed by the same reviewer on a separate machine, not by an independent operator. It establishes that the recorded outputs are reproducible across two machines and two interpreter versions.

The evidence set published here was subsequently reproduced by an independent operator: Walter Hawkins, the author of the document under test, on macOS arm64 under Python 3.9.6, having read the three checks before running them, with no network access and no subprocess execution, obtaining output byte-identical to the packaged runs. That is an operator-independent reproduction of the published evidence set, not an independent implementation of the profile, and it is recorded here with his agreement.

Neither reproduction establishes that the readings of the text encoded in the checks are correct: that remains open to the author and to anyone else who reads the document.

An archival manifest covering the text under test, the review as delivered, the executable evidence and the delivered evidence bundle has an OpenTimestamps proof whose earliest attestation is Bitcoin block 962746, of 16 August 2026, before delivery. Its SHA-256 is eb40bc6fdc1460da95a6f4c5ae946bc21643342e6448b4d71d71313a125f5f39. The evidence manifest published here is anchored separately. Verification of both proofs was performed against a Bitcoin full node under the reviewer's own control; the block hashes used came from that node, not from a block explorer.

The evidence on this page was anchored before the review was delivered. The order is established by the anchors, not by this statement.

Source

Produced by Tiago Pinto, Portugal, August 2026. Code is BSD-3-Clause. This page is served from the author's own server, in static HTML, without JavaScript, without analytics, without cookies, without external dependencies.