A visual walkthrough of the protocol, in the order the pieces come into play. Each diagram is a
picture of a rule stated normatively elsewhere — follow the links to the authoritative text. Colour is
consistent throughout: green is a pass / permitted path, red is a fail / refused one, and
blue marks informational or neutral machinery.
Grantauthority to use a subject within a bounded scope — the object everything else binds to
points at its revocation state by status.uri + status.index
Status Liststatic, signed revocation artefact — one bit per grant
The Grant is the hub: an Attestation, Decision Record, and the Media / Memory profiles each bind back to it by grant_id, while the Grant itself points at its Status List by status.uri and status.index.
A grant is only valid if two independent parties have signed it — the subject (or their custodian)
consents, and the issuer issues. Neither signature implies the other.
Grantcarries exactly two detached signatures, distinct roles — a verifier validates both; neither implies the other
requiredconsentsigned by the subject or custodian — authorises the use itself
requiredissuancesigned by the issuer — issues the grant
Every grant binds two independent signatures — consent from the subject (or custodian) and issuance from the issuer. Both are required; a grant missing either is refused at gate 1.
A grant can be delegated, but never widened. A child is always a subset of its parent, so the whole
chain stays at least as revocable as its slowest link.
Parent grantwidest scope · longest validity · highest cap
→
Child grant⊆ parent · narrower or equal
→
Grandchild grant⊆ child · narrower or equal
Attenuation-only: a child grant MUST NOT widen scope, extend the validity window, or raise the lease cap beyond its parent. The effective chain horizon = the maximum over all links — a chain is only as revocable as its slowest link.
Delegation only narrows. Each child grant is a subset of its parent; revocation responsiveness of the whole chain is bounded by its slowest link.
At the point of use, a conformant verifier runs the same five gates everywhere, in order, failing
closed at the first failure. This is the heart of the protocol.
Grant presented at the point of usechecked fresh every time — never cached (SPEC-CORE §5)
1 · Signaturesconsent + issuance both verify over the canonical grant
✔ PERMITTED_CONFORMANTsigned decision record emitted
pass / permittedfail / refusedinfo / neutral
H2A verification runs the same five gates everywhere, in order, failing closed at the first failure. Green is the single pass path; any gate can branch to a red REFUSED_* decision, labelled with the reason code the reference verifier emits.
Gate 3 above fetches a signed status list. The signature matters because it encodes who is
allowed to revoke: revocation authority is custody of the signing key. The issuer holds it; an
implementer only fetches and verifies, and fails closed.
revocation authorityIssuer / fiduciary domainholds the private signing key revoke = set the bit · re-sign · publish serves GET /status/:id · GET /pubkey POST /revoke — fiduciary authority required
fetch-and-verify onlyImplementer domainholds the issuer's public key as a trust anchor fetch → verify signature → read bit fails closed on unreachable / unsigned / wrongly-signed / stale no /revoke · serves no list of its own
signed status list flows one way →
Possession of the key is the authority: whoever can sign the list can clear the bit. Keeping the key out of the implementer is what makes the split provable, not just asserted.
ADR-009 — revocation authority is custody of the status-list signing key. The issuer signs and revokes; the implementer only fetches and verifies the signed list and fails closed. It has no revoke endpoint and serves no list of its own.
H2A does not stop a third-party executor. When a transmission happens outside conformance, that fact
is recorded — explicitly, and then anchored — so it stands as admissible evidence rather than being
silently lost.
Transmission occurs outside conformanceH2A does not stop a third-party executor
recorded, not blocked
Decision Record — TRANSMITTED_NON_CONFORMANTwith a populated non_conformant_transmission (downstream_ref, why) — the standard's primary output
H2A evidences; it does not enforce. A transmission outside conformance is recorded explicitly as a signed Decision Record, then anchored with a qualified timestamp (RFC 3161 / eIDAS) and an independent witness co-signature so it stands as admissible evidence.
Conformance is honest by construction: each level claims only what it can prove. A deployment sits at
the highest rung it fully implements — and no higher.
L1 · Verifiableobjects validate · signatures verify · the verification algorithm runs and fails closed
adds
L2 · AttestedL1 + point-of-use attestations & decision records for every act, against a resolvable, short-TTL signed status list the verifier checks (ADR-009)
adds
L3 · AnchoredL2 + external anchoring: eIDAS-qualified TSA timestamps + independent witness co-signature — the level an underwriter can rely on
Conformance is honest by construction — each level claims only what it can prove. L1 verifies, L2 attests against a signed status list, L3 anchors externally. L3 is underwriter-grade.