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
- hyper-spec:artifactKind
- attestation (declarations document; the checker side of maker-checker; L2)
- hyper-spec:claimPredicates
- finding-approved
- hyper-spec:claimPredicates
- finding-rejected
- hyper-spec:claimPredicates
- changes-requested
Sources
- www.iso.org
- ISO/IEC 27042:2015 §6.4 — the review record: each person carrying out any process should keep accurate and detailed contemporaneous notes of their actions and results, including decisions taken with reasons (the reasoning field is the reviewer's structured form of this); verified against the standard text 2026-08-03
- 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 carry an enveloped JSF signature by that Fulcio identity, using ES384, ES512, or ML-DSA-65 or ML-DSA-87 identified by their FIPS 204 OIDs.
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 an element-form BOM-Link to the L2 Finding's document component, and whose externalReferences carry an entry of type 'bom' marked hyper-spec:role 'findingRef', naming that same component and paired with at least one hash of it. 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 the attestation's map MUST carry a row citing this requirement. 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-approved
- allowed-values
- finding-rejected
- allowed-values
- changes-requested
- terminal
- finding-approved
- terminal
- finding-rejected
- non-terminal
- changes-requested
- vocabulary
- closed
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 provides that the notes should include decisions taken, including reasons for the decision; 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 under the same serialNumber, which re-enters review. The attestation MUST carry metadata.timestamp recording when the outcome was signed, so a finding's approvals can be ordered. 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. A finding collects several outcomes over its review loop, so 'current' means the latest by timestamp — which is why the attestation is dated. Revision as a new object rather than an edit 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)