Context
This is a reply to @alexshev's comment (2026-09-09) on Visa Has a Trusted Agent Protocol. Mastercard Has Verifiable Intent. Here's the Layer Neither One Gives You — a comment that aged well, because the three things it asked for are now the three things that exist:
"The proposed layering is clearest when revocation is modeled alongside issuance. A merchant needs to know not only that a trust artifact was transparently published, but whether a key, runner, or policy was revoked at the decision time and how a disconnected verifier catches up later. A signed checkpoint plus a bounded freshness rule would make that offline story concrete."
Three asks, three live artifacts. Pointing at each.
1. Revocation is modeled alongside issuance
The UTA conformance suite (schema 1.5.0) carries revoked-atc — a properly signed, anchored, in-window card whose only defect is revocation, with expected_verify: false. A runner can no longer clear every issuance-side check and silently ignore the revocation side: the suite prices that evasion at a full failure.
- Suite index (13 vectors + sidecars): https://www.marketnow.site/uta/conformance/vectors/_index.json
- Reference scorer (documents each property it defends): https://www.marketnow.site/uta/conformance/score-runner.mjs
2. The signed checkpoint is a real Rekor entry
The anchors are Sigstore Rekor entries, not self-attested files. anchor-record-v5.json is Rekor log_index 2787622029 (integrated 2026-09-10T21:52:48Z) and ships its statement, countersignature, and inclusion proof — with the v2→v5 chain published beside it. A disconnected verifier catches up by verifying inclusion against the public log, not by trusting our server:
3. The bounded freshness rule is a release chain
The freshness reference turned out to be exactly the bounded rule from the comment: a persistent release identity, monotone counters (r1→r2), local state, and an anchor floor — written up as rollback resistance, with the r1→r2 advance exercised for real hours after the chain was born:
The rule a disconnected verifier can enforce with those pieces: accept a trust artifact only if its release is not older than the newest anchored release minus the floor.
The part that is still open
Policy-level revocation at decision time. Card revocation is in the suite; a named policy losing its endorsement without a new release is not yet a vector. If you have a concrete shape in mind, it would slot naturally next to revoked-atc — and the anchor floor is already the half of it that an offline verifier can check.
Top comments (0)