Hypermedia Security: Publish Approval Specification
v1.0.0Hypermedia Au
Publish Approval (release maker-checker; approver distinct from report author)
The publish-approval attestation: maker-checker at the release boundary. The report author signs the Publication (the maker side); here an approver whose Fulcio identity differs from the author signs the disclosure decision. Three predicates, mirroring finding-approval by design: approved-for-disclosure (terminal — the report may be delivered, and a delivered publication is frozen), disclosure-rejected (terminal — kept, marked rejected), changes-requested (non-terminal — a new publication version follows via its supersedes link). At release the approver re-verifies the composition: every disclosed finding enumerated and disclosable. This is the last standard in the CyberBench case-provenance pack.
Machine attestation: /attestations/publish-approval/v1
Relationships
References
- references →Hypermedia Security: Publication BOM Specification
- composition-standard →Hypermedia Security: Publication BOM Specification
- disclosability →Hypermedia Security: Finding Approval Specification
- target-standard →Hypermedia Security: Timestamp Token Specification
Referenced by
- Hypermedia Security: Publication BOM Specification(checker-standard)
About this standard
- artifact-kind
- attestation (declarations document; maker-checker at the release boundary; L3)
- claim-predicates
- approved-for-disclosure,disclosure-rejected,changes-requested
Sources
- www.iso.org
- ISO 21043-5:2025 (Forensic sciences — Part 5: Reporting) — cited at title/scope level (clause text not verified first-hand): includes requirements relating to the review of case records and reports and the issuance and control of reports — the duties the release approval and the delivered-is-frozen rule discharge
- www.rfc-editor.org
- RFC 3161 — the publication-seal's independent-time anchor, governed by timestamp-token/v1 (SPEC-2)
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
PAPP-001 Approver Identity MUST
assessors[] MUST identify the approver, and the attestation MUST be signed by that identity (Fulcio-verified).
The release decision is attributed to a named, cryptographically bound actor — who let the report out is part of the record, exactly as who wrote it is.
PAPP-002 Target Publication Reference MUST
The attestation MUST carry exactly one claim whose target is the L3 Publication version by BOM-Link and paired hash. The hash binds the release decision to the exact report bytes reviewed.
Version-specific by construction: the approval covers the bytes the approver read, not a mutable pointer. A revised report is a new publication version needing its own release decision.
PAPP-003 Approver Distinct From Author MUST
The approver's Fulcio identity MUST differ from the report author's. This MUST be enforced by comparing two Fulcio-verified identities, never by comparing name strings, and MUST be asserted as a map row. The verifier performs the comparison against the Publication's signing identity.
The single-author-fraud control at the outermost boundary: the person who wrote the report cannot be the person who releases it. Cryptographic identity, not a name, is what makes the separation unfakeable.
PAPP-004 Approval Predicate MUST NOT
The claim predicate MUST be exactly one of: approved-for-disclosure (terminal — the publication may be delivered), disclosure-rejected (terminal — retained, marked rejected), changes-requested (non-terminal — returns to the report author; a new publication version follows, linked via cyberbench:supersedes). Closed set. A delivered publication MUST be the version carrying approved-for-disclosure and MUST NOT change after delivery.
The same review machine as finding-approval, with the report vocabulary — the send-back state exists here by deliberate mirroring, so iterative review of a report is as defensible and as signed as iterative review of a finding. Delivered-is-frozen makes 'which report did you give them' a question with exactly one answer.
- allowed-values
- approved-for-disclosuredisclosure-rejectedchanges-requested
- terminal
- approved-for-disclosuredisclosure-rejected
- non-terminal
- changes-requested
- vocabulary
- closed (locked v1.0.0)
PAPP-005 Approval Rationale MUST
The claim MUST carry a non-empty reasoning field stating the basis for the release decision, for every predicate including changes-requested.
The rationale is what shows a real release review happened — the reviewer's own words on why this report, with these findings, may (or may not) leave the enclave. ISO 21043-5's review-of-reports duty is discharged in this field.
- iso-basis
- ISO 21043-5:2025 review of case records and reports (title/scope level)
PAPP-006 Findings Enumerated MUST
Before signing approved-for-disclosure, the approver MUST verify that the Publication's compositions carry aggregate complete, that the assemblies enumerate every finding the report discloses, and that each composed finding is disclosable: a current terminal finding-approved from an identity distinct from that finding's author. This verification MUST be asserted as a map row.
The release-time re-check of the whole chain: nothing reaches the recipient that is not enumerated, and nothing enumerated lacks its own independent approval. Together with the publication's own completeness claim this is the double lock on undisclosed or unapproved content.
PAPP-007 Independent Timestamp SHOULD
The publication-seal's RFC 3161 token SHOULD exist in the sidecar index and verify per timestamp-token/v1 at the time of attestation. Where the token is not yet available, the attestation MUST record that the anchor is pending.
SHOULD, not MUST, for the same reason as the catalog attestation's anchor row: the token arrives from an external service moments after the seal, and the attestation may be produced before the round-trip completes. The token itself remains mandatory at the timestamp-token/v1 level — this row records whether the release approver could already verify it.
- level
- SHOULD
- target-standard
- https://sec.hypermedia.au/standards/timestamp-token/v1