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 provenance records follow the same data model the rest of the ecosystem reads, and externally signed C2PA assets validate through the Hashproof API.
• 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, chromaprint for audio, and optionally ISCC and a neural SSCD-style hash). Files that look similar to a human have similar image soft bindings even if the bytes differ; audio fingerprints match on identical bytes. 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 verifiers that do not yet understand ML-DSA can still validate the manifest through the Hashproof API. 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 the API verify endpoint reports it as simulated rather than as real PQ protection.