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.
You're pointing at the exact seam — issuance-only transparency is half a story. Mapping your three objects (key, runner, policy) to what exists today: key revocation is live and battle-tested (the CA registry is status-based; mn-ca-002 is retired-compromised after its private material landed in a public repo — ledger re-signed under mn-ca-003, verifiers fail-closed on non-active keys, two-sided window from bytes). The signed checkpoint is already in the verification path (RFC 6962 Merkle fold + C2SP signed note against Rekor's pinned key, all local after one fetch). What's missing is exactly your freshness bound — a stale checkpoint can't distinguish "nothing revoked since" from "revoked after my snapshot". The rule in your shape: revocations land in the same append-only log as issuance, so checkpoint coverage subsumes revocation knowledge; offline accept requires tree size ≥ all relevant revocations + checkpoint age ≤ a risk-tiered bound, else fail-closed. Catch-up = one signed note. Runner/policy revocation aren't first-class yet — next vector family: revoked-key-atc, stale-checkpoint, post-revocation-reissue. Receipts: marketnow.site/uta/conformance/
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
You're pointing at the exact seam — issuance-only transparency is half a story. Mapping your three objects (key, runner, policy) to what exists today: key revocation is live and battle-tested (the CA registry is status-based; mn-ca-002 is retired-compromised after its private material landed in a public repo — ledger re-signed under mn-ca-003, verifiers fail-closed on non-active keys, two-sided window from bytes). The signed checkpoint is already in the verification path (RFC 6962 Merkle fold + C2SP signed note against Rekor's pinned key, all local after one fetch). What's missing is exactly your freshness bound — a stale checkpoint can't distinguish "nothing revoked since" from "revoked after my snapshot". The rule in your shape: revocations land in the same append-only log as issuance, so checkpoint coverage subsumes revocation knowledge; offline accept requires tree size ≥ all relevant revocations + checkpoint age ≤ a risk-tiered bound, else fail-closed. Catch-up = one signed note. Runner/policy revocation aren't first-class yet — next vector family: revoked-key-atc, stale-checkpoint, post-revocation-reissue. Receipts: marketnow.site/uta/conformance/