Hypermedia Security: Finding Approval Specification
v1.0.0Hypermedia Au
Finding Approval (maker-checker; approver B distinct from author A)
The finding-approval attestation: the checker side of maker-checker. The author signs the finding and its analysis-provenance (the maker side); here a second, cryptographically distinct identity signs the review outcome. Three predicates: finding-approved (terminal, positive), finding-rejected (terminal, negative), changes-requested (non-terminal — a signed send-back that bumps the finding version and re-enters review). approver-not-equal-author is enforced by comparing two Fulcio-verified identities, never name strings. The invariant every downstream object leans on: a finding version entering a publication must carry exactly one current terminal finding-approved from an identity distinct from its author.
Machine attestation: /attestations/finding-approval/v1
Relationships
References
- references →Hypermedia Security: Analysis Provenance Specification
- references →Hypermedia Security: Finding BOM Specification
Referenced by
- Hypermedia Security: Finding BOM Specification(references)
- Hypermedia Security: Finding BOM Specification(target-standard)
- Hypermedia Security: Publication BOM Specification(disclosability)
- Hypermedia Security: Publish Approval Specification(disclosability)
About this standard
- artifact-kind
- attestation (declarations document; the checker side of maker-checker; L2)
- claim-predicates
- finding-approved,finding-rejected,changes-requested
Sources
- www.iso.org
- ISO/IEC 27042:2015 §6.4 — the review record: contemporaneous notes of actions, results, decisions taken and reasons (the reasoning field is the reviewer's structured form of this); verified against the standard text 2026-07-11 (SPEC-9 note)
- www.rfc-editor.org
- RFC 2119 (as clarified by RFC 8174) — requirement key words; only capitalised forms are normative
- sec.hypermedia.au
- website
FAPP-001 Approver Identity MUST
assessors[] MUST identify the approver (approver B), and the attestation MUST be signed by that identity (Fulcio-verified).
The reviewer is a named, cryptographically bound actor: the identity in assessors[] is the identity on the signature. Who reviewed is as much a part of the record as what they decided.
FAPP-002 Target Finding Reference MUST
The attestation MUST carry exactly one claim whose target is the L2 Finding by BOM-Link and paired hash. The hash binds the approval to the exact finding version reviewed.
The paired hash is what makes the approval version-specific: it approves the bytes that were reviewed, not a mutable pointer. A later finding version is a different object with its own approval.
FAPP-003 Approver Distinct From Author MUST
The approver's Fulcio identity MUST differ from the finding 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 finding's author identity; the schema alone cannot.
Maker-checker is the single-author-fraud control: the person who made a finding cannot be the person who approves it for disclosure. Binding on cryptographic identity, not a name, is what makes 'a different person' unfakeable — a renamed account is still the same key.
FAPP-004 Approval Predicate MUST
The claim predicate MUST be exactly one of: finding-approved (terminal, positive), finding-rejected (terminal, negative), changes-requested (non-terminal, returns to the author). Closed set. changes-requested MUST bump the Finding BOM version.
The three outcomes are the review state machine's transitions. finding-approved and finding-rejected are terminal; changes-requested is a signed send-back — signing it is intentional, producing a defensible record of substantive iterative review rather than an untracked back-channel. A rejected finding is kept, marked rejected; nothing is deleted.
- allowed-values
- finding-approvedfinding-rejectedchanges-requested
- terminal
- finding-approvedfinding-rejected
- non-terminal
- changes-requested
- vocabulary
- closed (locked v1.0.0)
FAPP-005 Approval Rationale MUST
The claim MUST carry a non-empty reasoning field stating the basis for the outcome. The rationale is required for every predicate, including changes-requested.
The rationale is the review's substance, not a formality: it is what an auditor reads to see that a real second look happened. ISO/IEC 27042 §6.4 requires records of decisions taken and reasons; the reviewer's reasoning is that record for the approval decision.
- iso-basis
- ISO/IEC 27042 §6.4 (decisions taken and reasons)
FAPP-006 Supersession And Publication Invariant MUST NOT
A changes-requested outcome MUST result in a new signed Finding version that links to and supersedes the version it replaces; the superseded version is kept and marked superseded, never edited in place. A finding version composed into a Publication MUST carry exactly one current terminal finding-approved from an identity distinct from its author; a finding whose only approval is changes-requested or finding-rejected MUST NOT be disclosed.
This is the rule the publication layer enforces at composition time: nothing reaches a report without a live, distinct-identity approval. Revision as a new object (rather than an edit) is what keeps the history intact — the review trail shows every version and every outcome, so a challenge to 'what changed and why' is answered from the record.
- enforced-at
- publication composition (publication/v1); finding versioning (finding/v1)