Validator

The JPEG Trust validator checks the Trust Record embedded in a JPEG or PNG image, offline. It reports four separate assessments and a verdict for the checks you select. Use it from the Validate record page, the REST API, or the command line.

What it checks

AssessmentQuestion it answers
Embedding Is there a readable Trust Record in the file?
Integrity Do the claim signatures, assertion hashes and the hard binding over the image content all verify? Time-stamps and stapled revocation responses are checked here too.
Manifest signer trust Does the signer's certificate chain lead to one of the trust anchors you selected? Only evaluated when anchors are given.
JPEG Trust โ€” Conformance Does the record follow ISO/IEC 21617-1: its structure, Trust Declaration, assertions (actions, metadata, rights, identity, training and mining, soft binding, Trust Reports), time-stamps and privacy rules?

With separate identity or time-stamp authority anchors, the report adds identity credential trust and time-stamp authority trust. These sections never change the verdict.

Reading the verdict

Readability and integrity are always required. Signer trust and conformance are added when you select them (on the page, or with --require-trust and --require-conformance).

VerdictMeaning
Pass (exit 0) Every selected check has affirmative evidence.
Fail (exit 1) A selected check failed: the validator demonstrated a violation.
Incomplete (exit 3) Nothing failed, but some selected check could not be decided (unknown), for example because evidence is missing or a feature is outside what the validator checks.

Each check is pass, fail, unknown or not applicable. The validator never guesses: unsupported or unavailable evidence is reported as unknown, not as a pass. Status fields inside an uploaded Trust Indicator Set are never treated as evidence.

A scoped conformance pass

A conformance pass means every applicable rule the validator implements passed, within its declared scope (shown in the report, for example jpt-validator-scope-3). It is not a claim of conformance with the whole standard. A few rules are excluded from the scope because they cannot be decided from a file (such as whether a declaration was really made at creation time); they stay unknown without blocking a pass and are listed in the report.

Metadata and rights expressions pass only when they use known vocabularies: XMP properties from Dublin Core, XMP, XMP Rights, Photoshop, TIFF, Exif and IPTC for cawg.metadata, and ODRL 2.2 terms without a profile for jpt.rights. Anything else is reported as unknown.

Trust anchors

Signer trust needs a bundle of CA certificates in PEM format (CA certificates only, not end-entity certificates). The same anchors are used for time-stamp authorities. On the Validate record page you can use the server's trust list (when the server has one), upload your own bundle, or skip signer trust. Whether a signer should be trusted is ultimately a Trust Profile decision, so an untrusted signer is never a conformance failure.

REST API

POST /validate on the backend (proxied by the website as /api/validate) takes a multipart form and returns the full report with the verdict.

curl
curl -F "image=@photo.jpg" \
     -F use-default-anchors=true \
     -F require-trust=true -F require-conformance=true \
     http://localhost:8000/validate

Fields: image, optional trust-anchors (PEM file) or use-default-anchors, identity-trust-anchors, timestamp-anchors, require-trust and require-conformance. The response is { verdict, exit_code, require_trust, require_conformance, trust_anchor_source, report }.

Command line

validator CLI
cargo run --manifest-path validator/Cargo.toml -p jpegtrust-validator-cli -- \
  validate photo.jpg --trust-anchors roots.pem --require-trust --require-conformance --summary

--summary shows each assessment's heading and counts, listing only failed checks; --format json prints the full report. The exit code is the verdict (0, 1 or 3; 2 for usage errors).

Next steps