AccessPreflightAPI documentation
Open console
Ship with confidence

Verify signed evidence manifests

Evidence manifests bind report identity and policy provenance to exact canonical bytes. AccessPreflight signs the SHA-256 digest of those bytes with Ed25519.

Retrieve the manifest and public keys

curl --fail-with-body \
  --url "https://api.accesspreflight.com/v1/scans/${SCAN_ID}/reports/evidence" \
  --header "Authorization: Bearer ${ACCESSPREFLIGHT_API_KEY}" \
  --output evidence.json

curl --fail-with-body \
  --url 'https://api.accesspreflight.com/.well-known/accesspreflight-evidence-keys.json' \
  --output accesspreflight-evidence-keys.json

The public key set is intentionally unauthenticated. Retired keys remain published so older evidence can still be verified.

Verification procedure

  1. Parse the manifest envelope without altering the signed canonical payload.
  2. Select the public key whose key_id matches the signature metadata.
  3. Confirm the key was valid for the evidence timestamp and has not been used outside its declared lifecycle.
  4. Hash the exact canonical evidence-manifest bytes with SHA-256.
  5. Verify the Ed25519 signature according to the declared algorithm.
  6. Verify referenced artifact digests before trusting downloaded report files.

Do not pretty-print, normalize line endings, reorder JSON keys, or reconstruct the payload before hashing. Signature verification is over exact canonical bytes, not a semantically equivalent object.

What signed evidence does and does not prove

Evidence schema 1.0 signs the canonical evidence-manifest payload. That payload records SHA-256 digests for the canonical JSON and accessible HTML reports, so verifiers can bind those downloaded bytes to the signature.

Artifact In the v1 signed scope? Integrity handling
Evidence manifest payload Yes Ed25519 signature over its canonical bytes
Canonical JSON report Yes, by referenced digest Compare its SHA-256 with the signed manifest
Accessible HTML report Yes, by referenced digest Compare its SHA-256 with the signed manifest
XLSX report and ACR workbook No Use the response SHA-256-backed ETag; archive it separately
Source file and screenshot No by default Preserve your own content-addressed source/build evidence

Do not describe an XLSX, ACR, source, or screenshot as signed under evidence schema 1.0 merely because it was downloaded beside a signed manifest.

It can show that an artifact and its recorded policy/engine provenance have not changed since signing by the identified AccessPreflight key.

It does not prove:

  • that every applicable accessibility requirement was automated;
  • that manual review was performed correctly;
  • that a legal regime applies to the customer;
  • that the source stayed unchanged after the scan;
  • that the product or service is certified compliant.

Source files and screenshots are excluded from evidence by default. Keep your own source revision or content-addressed build artifact when reproducibility requires it.

Search documentation