C2PA

What it is

A C2PA manifest is a structured set of cryptographic claims attached to a content asset: who signed it, what tools touched it, what assertions the signer is making about it (e.g. “this was AI-generated”, “this is the original camera capture”), and whether the bits you have match the bits the signer attested to.

The standard defines the on-disk format, the signing algorithms (Ed25519, ES256), the assertion vocabulary, and the verification procedure. It does not define the network layer. There is no canonical place to look up provenance if the file no longer carries the embedded manifest, and that gap is what Hashproof fills.

Why we use it

• It is a real standard, backed by Adobe, Microsoft, the BBC, the New York Times, and many others. Building against it now means your manifests are valid wherever any other C2PA-conformant validator runs.
• It is the regulatory anchor. The EU AI Act Article 50, the US Executive Order on AI, and similar regimes all reference machine-readable disclosure; C2PA is what they have in mind.
• It is open. No license fees, no proprietary verification step. Anyone with the manifest and the signer's public key can verify.

Hard binding vs soft binding

A hard binding is a cryptographic hash of the file (SHA-256 in our case). Two files have the same hard binding if and only if they are byte-identical.

A soft binding is a perceptual hash (we support DCT-pHash, dHash, ISCC, chromaprint, and an optional neural SSCD-style hash). Files that look or sound similar to a human have similar soft bindings even if the bytes differ. This is how we recover provenance after a JPEG is re-encoded, cropped, or re-uploaded.

Hashproof stores both types automatically when you sign or store a manifest, and our resolver tries hard binding first and falls back to soft binding. See Manifests for the storage shape.

Trust list

The C2PA spec ships with a public trust list of certificate authorities whose signers it considers trusted by default. Our verification result reports trustStatus: 'trusted' when the manifest validates AND the signer is on the trust list, and 'untrusted' when the manifest validates but the signer is unknown. Untrusted is not the same as invalid; it is up to your application to decide what to do with it.

Post-quantum hybrid signatures

Every Hashproof signature is also signed with ML-DSA-65 (NIST PQC finalist) when the runtime supports it. The PQ signature is added as a custom assertion alongside the classical ES256 signature, so C2PA-conformant verifiers that do not yet understand ML-DSA still validate the manifest correctly. When ML-DSA is unavailable in the runtime, we fall back to a simulated PQ assertion that carries no cryptographic guarantee but is clearly labeled as such, so verifiers cannot be tricked into reporting it as real PQ-protected.